vermin.eu.org

Specjalista IT na tru^Hopie

Entries Comments



ssh śmieci w logach

24 September, 2005 (11:47) | debian(ized), logs | By: vermin

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.

Comments

Pingback from vermin.eu.org » Blog Archive » o sshd słów kilka
Time: 29/10/05, 18:26

[...] W poprzednim artykule o ssh pisałem o opcji logowania się za pomocą kluczy. Ponieważ z różnych ważnych powodów musiał zostać podniesiony poziom zabezpieczeń (ot choćby żeby pokazać, jak to sie człowiek stara ), zaimplementowałem w końcu ten przemiły sposób logowania. Polega on w skrócie na tym, iż potrzebna jest para kluczy - klucz publiczny, umieszczany na serwerze, oraz klucz prywatny, znajdujące się w posiadaniu użytkownika. Literatura mówi, iż klucz prywatny jest nieodtwarzalny z klucza publicznego, ale klucz publiczny z prywatnego już tak. Ponadto rzeczy zakodowane kluczem publicznym odczytywane są tylko za pomoca komplementarnego klucza prywatnego i vice versa, rzeczy zakodowane przy pomocy klucza prywatnego odczytywane są tylko przy pomocy klucza publicznego. To pierwsze przydaje się do szyfrowania, to drugie do autentykacji. Tyle teorii, przejdźmy do rzeczy. Przede wszystkim musiałem ustawić ssh - /etc/sshd_config przeszło następujące zmiany: [...]

Pingback from vermin.eu.org » Blog Archive » atak brute force na vsftpd/proftpd, czyli o słowo blokowaniu
Time: 29/07/06, 20:18

[...] O ile SSH się w miarę łatwo zabezpiecza przed zbyt duża ilością wpisów, to już serwery FTP zabezpieczyć trudniej. Z pomocą przychodzą dwa narzędzia - pierwsze z nich to znane z pakietu *sentry Logsentry, zaś drugie, nad którym się skupię - fail2ban. Obydwa działają tak samo - monitorują logi i na tej zasadzie podejmują odpowiednie działania. Obydwa mają zbliżone zalety i tą samą wadę - regexpy1. Obydwa używają /etc/deny.hosts lub iptables. Obydwu nie ma w stable [...]

Write a comment