ssh śmieci w logach
Mnóstwo skryptów powstało w celu ataku na niezabezpieczone demony ssh. Standardowy atak polega na przeczesaniu zakresu adresów IP w celu odnalezienia otwartych portów 22 (enumeration) a następnie atak na działającego tam demona.
Jest kilka metod mogących zabezpieczyć przed tego typu aktywnością:
- blokada na poziomie sshd_config:
- opcja PermitRootLogin powinna być ustawiona na no, co automatycznie zabezpieczy przed wejściem z zewnątrz na konto root (pozostaje droga zwykłe konto -> su/sudo),
- opcja MaxStartups pozwoli na uruchomienie tylko odpowiedniej ilości watków nasłuchujących i podtrzymujących przez LoginGraceTime otwarte połączenie a stanie niezautoryzowanym - dodatkowo podanie listy trzech parametrów, np, 10:30:60 powoduje uruchomienie ssh w trybie pozwalającym maksymalnie na 10 połaczeń anonimowych, z czego co trzecia próba połączenia będzie odrzucanoa (30%), która to liczba będzie rosła wraz z nasileniem ataku aż do 60% odrzuconych połączeń,
- opcj PermitEmptyPasswords powinna być ustalona na nie - w ten sposób zabezpieczymy się przed ustawieniem pustego hasła i możliwością zalogowania na taie konto - oczywiście nie broni nas to przed atakaiem na konto test/test, dupa/dupa czy inną ambitną kombinacją,
- w skrajnej sytuacji możemy zabronić logowania ssh bez posiadania klucza prywatnego powiązanego z danym loginem - co niestety powoduje konieczność posiadania takiego klucza przy sobie w celu wykonywania zadań administracyjnych - przydatna tu będzie opcja PasswordAuthentication
- blokada na poziomie iptables - możliwe są dwa warianty tej blokady. Jednym z nich jest totalne zablokowanie danego IP przez demona pilnującego logów, takiego jak napisany w pythonie fail2log (zasada działania zbliżona do portsentry), wsparta dodatkowo wpisaniem złego hosta do hosts.deny - czyli wykorzystanie warstwy tcpwrappers chorniącej przy okazji inne usługi mające wkompilowane korzystanie z tego rodzaju zabezpieczeń. Minusem takiego rozwiązania jest możliwy atak typu Denial Of Service, który spowoduje wyblokowanie pewnych klas IP, co może być minusem w wypadku serwera z którego korzystają sieci publiczne typu uzytkownicy neostrady. Drugim jest ograniczenie ilości połaczeń napływających do serwera za pomocą modułów iptables. Przykładowe polecenia wyglądają następująco:
/sbin/iptables -I INPUT -p tcp –dport 22 -i $EXTERNAL_INTERFACE -m state –state NEW -m recent –set
/sbin/iptables -I INPUT -p tcp –dport 22 -i $EXTERNAL_INTERFACE -m state –state NEW -m recent –update –seconds 60 –hitcount 3 -j DROP
Pierwsza z tych linijek spowoduje zaznaczenie, że połączenia z łączego się z portem 22 adresu IP mają wejść w pulę testowaną, druga zaś określa, iż jesli w przeciągu 60 sekund z danego adresu liczba połączeń przekroczy 2, to wszystkie następne są dropowane. Powinno to zdecydowanie zmniejszyć liczbę wpisów w logach. Oczywiście tu także minusem może być tymczasowa odmowa połączenia z naszym hostem - ale jej prawdopodbieństwo jest dużo niższe… i na dodatek zmienne w czasie (60 sekund).
Nie są to oczywiście wszystkie możliwe sposoby - więcej na temat można znaleźć w artykule autorstwa Ryana Twomey opublikowanym na linux.com do którego lektury zapraszam.