DD-WRT nie odpowiada na ping?

Jeżeli chcemy zmusić nasze dd-wrt do odpowiedzi ping to należy dodać regułę na firewallu.

Zakładka Administration -> Commands -> Firewall

iptables -A OUTPUT -p icmp --icmp-type echo-reply -d 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -d A.B.C.D -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j DROP

Zapisujemy i restartujemy urządzenie.

Hasło roota w trybie recovery serwera, a Ezeelogin

Po wdrożeniu Ezeelogin na naszych serwerach hostingowych, administratorzy mają możliwość logowania się przez serwer-bramę, bądź używając kluczy.

W przypadku uruchomienia serwera w trybie recovery (np. przy problemie z systemem fsck systemu plików), Debian domyślnie wymaga podania hasła użytkownika root, które jest automatycznie zmieniane na losowe, nieznane hasło przez Ezeelogin.

Poniższe polecenie po podaniu poświadczeń administratora głównego Ezeelogin pozwala na wyświetlenie listy haseł.

php /usr/local/ezeelogin/ezlexport.php tmp && cat tmp | cut -d \’|\’ -f 1,4 && rm tmp

Polecenie nie sprawdza licencji – może zostać wywołane po jej wygaśnięciu.

Przechowywanie kluczy SSH programu PuTTY w KeePass

Powyżej wersji 0.60 klient SSH PuTTY posiada wsparcie dla tzw. agenta uwierzytelniania. Dołączona do programu wersja – Pageant – pozwala na załadowanie do pamięci wielu kluczy i uwierzytelnianie nimi nie tylko połączeń z lokalnego komputera, ale w przypadku połączeń przez serwery OpenSSH również kolejnych sesji (agent forwarding).

KeeAgent – plugin do KeePass \”podszywający się\” pod Pageanta pozwala na przechowywanie kluczy SSH w rekordach bazy kdbx programu KeePass.

Aby dodać plugin do menadżera kluczy, z pobranego ze strony projektu archiwum kopiujemy plik KeeAgent.plgx do katalogu instalacji. Przy ponownym uruchomieniu, zostanie on skompilowany i załadowany.
Pliki kluczy SSH (ppk) dodajemy do rekordów w \”zaawansowanych\” jako załączniki. Jeżeli są zabezpieczone hasłem – podajemy je jako hasło we wpisie.

Następnie przechodzimy do konfiguracji PuTTY.
\"\"
Wybierając opcję \”Attempt authentication using Pageant\” zapewniamy sobie możliwość logowania kluczem z odblokowanej bazy KeePass z komputera lokalnego.
Opcja \”Allow agent forwarding\” pozwala na użycie Pageanta w uwierzytelnianiu kolejnych połączeń z serwera do którego jesteśmy zalogowani. Nie powinno się używać tej opcji na serwerach, którym nie ufamy – klucze mogą zostać użyte wtedy również przez administratora systemu (podobnie jak hasło, które wpisywaliśmy jak dotąd).

Po właściwej konfiguracji, po połączeniu do serwera który rozpoznaje nasz klucz powinno ukazać nam się powiadomienie jak i gotowa do pracy sesja zdalnej konsoli.

\"\"

Zmiana domyślnych pakietów językowych w Windows 7 z włączonym BitLocker

Czasem konieczne jest doinstalowanie dodatkowych pakietów językowych do systemu np. w celu zwiększenia kompatybilności z oprogramowaniem (np. Check_MK) lub spójności interface\’u (niestety – oprogramowanie Lenovo dla laptopów Thinkpad). Teoretycznie, jest to proces łatwy, prosty i przyjemny – kreator prowadzi użytkownika za \”rączkę\”. Aż do pierwszego uruchomienia ponownie.

Jeżeli wykorzystywany jest BitLocker w obecności TPM (Trusted Platform Module), dokonywana jest weryfikacja środowiska uruchomieniowego systemu Windows 7 – w szczególności, sprawdzane są sumy kontrolne plików systemowych. W przypadku zmiany domyślnego języka ekranu logowania, ulega zmianie plik winresume.exe, lecz nie jego suma.

W celu przywrócenia poprawnego działania konieczny niestety będzie klucz odzyskiwania BitLocker. Po poprawnym odszyfrowaniu partycji i włączeniu systemu w celu regeneracji należy wyłączyć i włączyć ponownie ochronę klucza szyfrującego korzystając z BitLocker Drive Encryption Configuration Tool. W uprzywilejowanym wierszu poleceń wykonujemy:

manage-bde -protectors c: -disable
manage-bde -protectors c: -enable

Aby uniknąć konieczności użycia klucza odzyskiwania BitLocker, możemy pierwsze z poleceń wykonać przed instalacją pakietów językowych, drugie z nich po zmianie języka.

Konfiguracja Vyatta na serwerach OVH

Wykorzystując serwery OVH do wirtualizacji sprzętowej VMware ESXi pojawia się problem konfiguracji sieci na maszynach wirtualnych korzystających z IP failover. Prezentujemy kilka podejść, przy czym obecnie stosujemy równolegle dwa ostatnie z nich.

Podejście 1 – routing OVH bezpośrednio na maszynę

  1. Tworzymy adres MAC wirtualny w Usługi -> MAC wirtualny ustawiając typ \”vmware\” i ustawiamy go konfigurując adres sprzętowy interrface\’u sieciowego maszyny w vSphere Client.
  2. Konfigurujemy go z maską /32 jako adres IP hosta, dodajemy statyczne trasy do oraz przez gw serwera fizycznego (jego IP z końcówką .254)

    ip addr add 178.32.231.141/32 dev eth0
    route add  172.31.223.254 via eth0
    route add default gw 172.31.223.254

Podejście 2 – routing przez Vyatta, DNAT+SNAT

  1. Podobnie jak w 1, przypisujemy IP failover, ale do istniejącego adresu MAC interface\’u WANowego Vyatty (eth0).
  2. Konfigurujemy podsieć NATowaną na interface\’ie LANowym, NAT i DNS forward.

    set interfaces ethernet eth1 address 192.168.0.1/24
    set service nat rule 1 type destination
    set service nat rule 1 inbound-interface eth0
    set service nat rule 1 destination address 178.32.231.141
    set service nat rule 1 inside-address address  192.168.0.100
    set service nat rule 2 type source
    set service nat rule 2 outside-address 178.32.231.141
    set service nat rule 2 source address 192.168.0.100
    set service dns forwarding system

  3. Konfigurujemy sieć na serwerze wirtualnym podpiętym do LAN

    ip addr add 192.168.0.100/24 dev eth0
    ip route add default gw 192.168.0.1
    echo \”nameserver 192.168.0.1\” >> /etc/resolv.conf

Podejście 3 – routing przez Vyatta, static route

  1. Podobnie jak w 1, przypisujemy IP failover, ale do istniejącego adresu MAC interface\’u WANowego Vyatty (eth0).
  2. Konfigurujemy na obu interface\’ach Vyatty ten sam IP routera

    set interfaces ethernet eth0 address 178.33.137.225/32
    set interfaces ethernet eth1 address 178.33.137.225/32

  3. Ustawiamy domyślną trasę dla routera

    set protocols static route 0.0.0.0/0 next-hop 176.31.233.254

  4. Tworzymy trasę statyczną do serwera wirtualnego (directly connected)

    set protocols static interface-route 178.32.231.141/32 next-hop-interface eth1

  5. Konfigurujemy sieć na serwerze wirtualnym podpiętym do LAN

    ip addr add 178.32.231.141/32 dev eth0
    ip route add 178.33.137.225/32 dev eth0
    ip route add default via 178.33.137.225

Podejście 4 – routing przez Vyatta, failover RIPE

  1. Podobnie jak w 1, przypisujemy IP failover, ale do istniejącego adresu MAC interface\’u WANowego Vyatty (eth0).
  2. Konfigurujemy na obu interface\’ach Vyatty ten sam IP routera – z zewnątrz z maską /32, wewnątrz z maską podsieci

    set interfaces ethernet eth0 address 178.33.137.225/32
    set interfaces ethernet eth1 address 178.33.137.225/29

  3. Ustawiamy domyślną trasę dla routera

    set protocols static route 0.0.0.0/0 next-hop 176.31.233.254

  4. Konfigurujemy sieć na serwerze wirtualnym podpiętym do LAN

    ip addr add 178.33.137.226/29 dev eth0
    ip route add default via 178.33.137.225

Anonymous – czy da się obronić przed hakerami?

\"Anonymous\"

Ostatnie miesiące to bardzo gorący okres w branży IT, a zwłaszcza wśród programistów i techników zajmujących się zabezpieczeniami. Powodem nerwowej atmosfery jest grupa zwąca siebie Anonymous, która niemal bezkarnie grasuje w przestrzeni wirtualnej, włamując się na strony o bardzo wysokich poziomach zabezpieczeń. Pokazali w ten sposób, że nikt nie może czuć się bezpieczny.

Czytaj dalej