Exploit na serwerze SSH zero-day - Sugestie, aby się chronić

Według Internet Storm Center wydaje się, że istnieje exploit SSH zero-day.

Tutaj jest kod dowodu koncepcji i odniesienie:

• http://secer.org/hacktools/0day-openssh-remote-exploit.html
• http://isc.sans.org/diary.html?storyid=6742

Wydaje się to poważnym problemem, więc każdy administrator systemu Linux / Unix powinien zachować ostrożność.

Jak się chronić, jeśli problem nie zostanie załatany na czas? Lub jak ogólnie radzisz sobie z exploitami zero-day?

* Zamieszczę moją sugestię w odpowiedziach.

Komentarz od Damiena Millera (programisty OpenSSH): http://lwn.net/Articles/340483/

W szczególności poświęciłem trochę czasu na analizę dostarczonego przez niego śladu pakietu, ale wydaje się, że składa się on z prostych ataków siłowych.

Więc nie jestem przekonany, że w ogóle istnieje 0day. Jedynym jak dotąd dowodem są anonimowe plotki i niepotwierdzalne transkrypcje włamań.

Moją sugestią jest zablokowanie dostępu SSH do zapory ogniowej wszystkim innym osobom oprócz twojego adresu IP. Na iptables:

/sbin/iptables -A INPUT --source <yourip> -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -j DROP

Zgodnie z postem SANS, ten exploit does not work against current versions of SSH, a zatem nie jest tak naprawdę 0dayem. Połącz swoje serwery i wszystko powinno być w porządku.

Złóż skargę do swoich dostawców

W ten sposób wszyscy otrzymują nowszą wersję.

FYI, oryginalne źródło historii: http://romeo.copyandpaste.info/txt/ssanz-pwned.txt

Istnieją również dwie podobne historie (hackowanie astalavista.com i inna strona): romeo.copyandpaste.info/txt/astalavista.txt
romeo.copyandpaste.info/txt/nowayout.txt

Wygląda na to, że ktoś ma plan: romeo.copyandpaste.info/ („Zachowaj prywatność 0dni”)

Kompiluję SSH, aby używać tcprules i mam niewielką liczbę reguł zezwalających, odrzucając wszystkie inne.

Zapewnia to również, że próby hasła są prawie całkowicie wyeliminowane, a gdy przesyłane mi są raporty o próbach włamań, mogę traktować je poważnie.

Nie uruchamiam ssh na porcie 22. Ponieważ często loguję się z różnych maszyn, nie lubię uniemożliwiać dostępu przez iptables .

Jest to dobra ochrona przed atakami zero-day - które na pewno przejdą po domyślnej konfiguracji. Jest mniej skuteczny przeciwko komuś, kto próbuje narazić tylko mój serwer. Skanowanie portów pokaże, na którym porcie używam ssh, ale skrypt atakujący losowe porty SSH pominie moje hosty.

Aby zmienić port, wystarczy dodać / zmodyfikować port w pliku / etc / ssh / sshd_config .

Chciałbym zaporę ogniową i czekać. Mój instynkt jelitowy jest jedną z dwóch rzeczy:

A> mistyfikacja. Według podanych do tej pory drobnych i brakujących informacji, jest to albo…

lub...

B> Jest to próba „zadymienia i oszustwa”, powodująca obawy dotyczące 4.3. Dlaczego? Co jeśli ty, jakaś organizacja hakerów, znajdziesz naprawdę fajny exploit zero-day w sshd 5.2.

Szkoda tylko, że najnowsze wersje (Fedora) zawierają tę wersję. Żadne istotne podmioty nie wykorzystują tego w produkcji. Wiele zastosowań RHEL / CentOS. Wielkie cele. Dobrze znane jest backportowanie RHEL / CentOS wszystkich poprawek bezpieczeństwa w celu zachowania pewnego rodzaju podstawowej kontroli wersji. Zespoły stojące za tym nie mogą kichać. RHEL opublikował (czytam, musiałbym wykopać link), że wyczerpał wszystkie próby znalezienia jakiejkolwiek usterki w 4.3. Słowa, których nie wolno lekceważyć.

Wróćmy do pomysłu. Haker postanawia w jakiś sposób wywołać zamieszanie około 4,3, powodując masową histerię wobec UG do 5,2p1. Pytam: ilu z was już ma?

Aby stworzyć jakiś „dowód” na nieudane przekierowanie, cała „wspomniana grupa” musiałaby teraz przejąć jakiś wcześniej skompromitowany system ( WHMCS ? Poprzedni SSH?), Stworzyć logi z pewnymi półprawdami (atak „e” zweryfikował zdarzyło się, ale niektóre rzeczy nie dały się zweryfikować przez cel) mając nadzieję, że ktoś „ugryzie”. Wystarczy jeden większy by zrobić coś drastycznego (... HostGator ...), aby uczynić to nieco poważniejszym, w obliczu rosnącego niepokoju i zamieszania.

Wiele dużych podmiotów może backportować, ale niektóre mogą po prostu aktualizować. Te, które się aktualizują, są teraz otwarte na prawdziwy atak zero-dniowy, jak dotąd bez ujawnienia.

Widziałem dziwniejsze rzeczy. Na przykład grupa celebrytów umiera z rzędu ...

Zmienić na Telnet? :)

Żartując na bok, jeśli masz poprawnie skonfigurowaną zaporę ogniową, już pozwala ona na dostęp SSH tylko do kilku hostów. Więc jesteś bezpieczny.

Szybką poprawką może być zainstalowanie SSH ze źródła (pobranie go z openssh.org), zamiast używania starych wersji, które są obecne w najnowszych dystrybucjach Linuksa.