Korzystam z 64-bitowego serwera CentOS 5.7, który ma dziwny problem.
Podczas oglądania moich logów /var/log/secure
zauważyłem, że jedno dziwne IP próbuje połączyć się z ssh z wieloma dziwnymi nazwami użytkowników.
Dane wyjściowe dziennika: http://pastebin.com/raw.php?i=3uYjPrLL
Uruchamiam fail2ban, który już zablokował ten adres IP, a także ręcznie zablokowałem ten adres IP za pomocą iptables.
Uruchamianie iptables -n -L
Mam ten wynik:
Chain fail2ban-SSH (1 references)
target prot opt source destination
DROP all -- 50.115.166.129 0.0.0.0/0
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Więc blok jest na swoim miejscu. Iptables również działa i już zablokowałem wiele adresów IP za pośrednictwem iptables, a wszystkie te bloki działają dobrze.
Ale w jakiś sposób ten adres IP może dostać się do mojej maszyny. Wiesz, jak to możliwe?
fail2ban-SSH
łańcuch nigdy nie jest wywoływany lub jest wywoływany na niewłaściwym etapie przetwarzania. Będziemy musieli zobaczyć wyjście ziptables -L -n -v
powiedzenia czegoś przydatnego.Odpowiedzi:
Problem polega na tym, że Twój
fail2ban-SSH
łańcuch jest stosowany do ruchu do portu 22, który nie jest tam, gdzie nasłuchuje sshd. Dlatego fail2ban przejmuje błędy z dzienników uwierzytelniania i poprawnie aktualizuje łańcuch odmowy. Ale ruch ssh nigdy nie jest wysyłany do tego łańcucha, więc twój złoczyńca, który nie może rozmawiać z portem 22, nadal może rozmawiać z sshd 2222.Zakładając, że używasz standardowego CentOS
/etc/sysconfig/iptables
, musisz zmienić linię wfilter
sekcji, która obecnie mówi coś takiegopowiedzieć
Jeśli chodzi o ręczne upuszczanie, dodano go po wierszach, które mówią
i
więc po prostu nigdy nie zostanie wywołany w celu ograniczenia nowego ruchu do portu 2222 lub kolejnych pakietów w takim połączeniu, ponieważ są one już dozwolone. Kolejność reguł jest ważna w iptables, ponieważ wygrywa pierwszy mecz z dyspozycją.
źródło