Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Witam,
Ostatnio zauważyłem, wzmożone próby zdobycia konta root przez ok 1500 nieudanych logowań do ssh. Oczywiście doinstalowałem fail2ban i w zasadzie uspokoiło się z alarmami. Postanowiłem trochę poluzować fail2ban i przy okazji przyjrzeć się sposobom jakie są wykorzystywane do tego typu ataków. Interesują mnie takie informacje: jakie hasła i loginy były wysłane w celu autoryzacji. Troszkę poszukałem w sieci i znalazłem honeyd jednak nie bardzo rozumiem mechanikę działania takiego oprogramowania. Oraz to czy spełni on moje oczekiwania. Może najpierw wyjaśnię topologie mojej sieci.
WAN >> router DIR-300 >> router2 192.168.0.200 >> klienci roter2 192.168.2.0/24 oraz 192.168.1.0/24
Router2 jest dostępny z zewnątrz ponieważ mam przekierowanie portu 22 z którego sam korzystam.
Teraz tak chciałem zainstalować honeypotd na 192.168.0.200 jednak jest to realna maszyna i zabawy honeyd mogłyby się na niej skończyć słabo dlatego też obawiam się takiego postępowania.
Druga rzecz jaka nasuwa mi się do głowy to instalacja honeyd na maszynie np. 192.168.1.10 i co za tym idzie przekierowanie portu na nią ale tym samym stracę łączność z router2 i dodatkowo 192.168.1.10 nie pracuje 24/h.
W takiej sytuacji wydaje mi się jedynie realne instalowanie honeyd na 192.168.0.200 tylko jak to zrobić żeby samemu nie wpaść w swoje sidła? może autoryzacja tylko po kluczach? ale czy to z kolei nie pozbawi funkcjonalności mojej pułapki. Chciałem poznać Wasze zdanie w tym temacie. Może są inne rozwiązania tego problemu, których chwilowo nie znam.
Ostatnio edytowany przez karol (2012-05-10 11:12:04)
Offline
Do zablokowania włamu przez ssh spróbuj iptables hashlimit:
http://www.zolv.eu/node/60
albo intables recent:
http://www.ducea.com/2006/06/28/using-iptables-to-b … orce-attacks/
Do tego
MaxAuthTries {liczba}
w sshd_config, i sshd na inny port, najlepiej 4 - 5 cyfrowy (nie musi działać na domyślnym 22).
Możesz też na routerze zrobić przekierowanie, zeby był widoczny w necie na porcie np 13139 lub innym.
Ograniczenie logowania do kluczy, i wyłączenie haseł tesktowych, to też niezły pomysł, można to zrobić tylko dla roota, można dla wszystkich lub dla grupy użyszkodników.
To by było na tyle
;-)
Ostatnio edytowany przez Jacekalex (2012-05-10 12:41:08)
Offline
Nie chodzi mi o całkowite zablokowanie tylko o logowanie tego co się dzieje np:
login pass from:
root root 72.158.250.1
root pAssword 72.158.250.1
root Admin1234 72.158.250.1
squid squid 72.158.250.1
Chyba rozumiem jak ma to wyglądać na domyślnych ustawieniach ustawić honeyd a na kosmicznym porcie będzie działało prawdziwe ssh z którego sam będę korzystał. Dobrze myślę?
Offline
Logowanie masz w /var/log/messages lub syslogu lub auth.log, to kwestia wygrepowania z logu, co trzeba.
Można też skierować logi ssh bezpośrednhio do bazy Sql za pośrednictwem rsysloga.
A kombinować możesz na 10010 sposobów.
Offline
To akurat sam honeyd też potrafi.
Poza tym przy skrypcie nawet nmap w trybie sV pokaże, ze coś nie tak z wersją.
Lepiej od skryptu postawić chroota z drugim ssh, hasłem wygenerowanym przez
head -c99 /dev/urandom | mimencode
albo najlepiej wyłączonym kontem root.
I niech się tam potem włamują ;)
Chociaż zazwyczaj wystarcza poczytać komentarze w pliku sshd_config:
# the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication
Wtedy root jest dostepy tylko po kluczu dsa/rsa.
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2012-05-11 09:43:17)
Offline
mam wrażenie, że jakieś automaty z chin lubią macać port 22. ja sobie przestawiłem na swoim routerku żeby ssh nasłuchiwał na 222 i logi wyglądają trochę spokojniej
Offline
Dokładnie tak jak pisze Rychu, załóż jakąś blokadę, bo czytanie logów to ci się szybko znudzi, każdy ze sposobów wymienionych przez kolegów jest skuteczny.
Offline
swoją droga to zmieniony port może wykryć chyba nmap
Offline
Swoją droga, jak ktoś chce zablokować nmapa to można pokombinować albo z celem TARPIT, albo hashlimit, żeby nmap tego innego portu nawet w pół roku nie znalazł
W dodatku roboty sieciowe zazwyczaj lecą po domyślnych portach,
i badają jeden potencjalny cel nie dlużej, niż minutę, a nie pół dnia.
Offline