[balrog84]

Jest tu jakiś życzliwy Mirek, który w miarę ogarnia jak loguje #linux, a właściwie to bardziej jak działają reguły #iptables? Bo mam następujący problem.
Serwer SSH otwarty na domyślnym porcie na świat, co chwilę jest odpytywany (brute force na root), i chciałem DROP-ić te pakiety jakimś prostym rozwiązaniem, żeby ograniczyć ilość wpisów w auth.log

/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

Po dodaniu iptables -L zwraca:

Chain INPUT (policy ACCEPT)
target prot opt source destination 
ACCEPT all -- anywhere anywhere 
ACCEPT all -- anywhere anywhere 
ACCEPT all -- localhost anywhere 
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED 
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh 
 tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: SET name: DEFAULT side: source 
DROP tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: UPDATE seconds: 15 hit_count: 4 name: DEFAULT side: source 
...

Mam w sumie 2 pytania, czy ACCEPT dla SSH powinien być wyżej niż DROP z uwagi na rozpoznany atak? Chodzi mi o to jak właściwie traktować te pozycje w regułach IPTABLES. Czy jeśli to jest OK i działa to czy /var/log/auth.log nadal będzie logował te próby? Bo jak tego nie poustawiam to tam cały czas widać fail-e logowania z jednego IP. Czas też różny ustawiałem. Wrzuciłem oczywiście fragment tylko dotyczący usługi SSH, dalsze reguły nie zastępują tego co tu widać.

[RRybak]

@balrog84: trochę z innej strony. Możesz zainstalować sobie fail2ban, który zrobi to wszystko za Ciebie, także na innych usługach. No chyba, że chcesz się iptables uczyć ;)

[sq4ind]

@balrog84: nie tedy droga... fail2ban i to po prostu dziala :)

[balrog84]

@RRybak: Wiem o fail2ban, to mam w planach, gdy będę miał serwer na nowo postawiony, tu niestety na razie to rozwiązanie odpada. A także chciałbym zrozumieć tak prostą funkcję zaimplementowaną w iptables.

[rumcajs666]

@balrog84: Zacznij od zmiany portu dla SSH.

[balrog84]

@rumcajs666: OK, w sumie to jest bardzo proste i skuteczne, dla rozwiązania problemu. Tylko mimo wszystko chciałbym zrozumieć czy poprawna kolejność reguł w łańcuchu to:
a)
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
DROP ... wg wzorca
czy b)
DROP ... wg wzorca
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh

[RRybak]

@balrog84: na chłopski rozum, pierwsze dopasowanie decyduje o pakiecie.
a) dopasujesz wszystko, do dropa nigdy nie dojdzie
b) drop decyduje, do accepta dojdzie wszystko co nie spasowało przed chwilą

[RRybak]

@balrog84: i mając to na uwadze, patrz co robisz -I (insert), czy -A (append)

[rumcajs666]

@balrog84: Tak jak zostało napisane wyżej, regułki rozpatrujesz patrząc od góry. Pakiet wpada w pierwszy pasujący slot.

[balrog84]

@rumcajs666: @RRybak: Dzięki to w zasadzie najistotniejsze co chciałem zrozumieć, bo jak się czyta manual to jakoś tak niejasno to jest. Czyli to jest mega ważne, a wiele gotowych prostych firewall'i na iptables nie ma komentarza, że przy dopisaniu o dalsze reguły, trzeba się pilnować. Będę rzeźbił dalej, aż zacznie to działać zgodnie z moimi oczekiwaniami. ( ͡° ͜ʖ ͡°)