Vlákno názorů k článku
Blokujte SSH útoky pomocí DenyHosts

Ja misto DenyHosts pouzivam samotne iptables s recent modulem. V kazdem 300 sekundovem je povoleno jen 5 spojeni od jedne IP adresy:

iptables -A INPUT -p tcp --dport 22 -m recent --name SSH --set
iptables -A INPUT -p tcp --dport 22 -m recent --name SSH \
   --update --seconds 300 --hitcount 5 -j DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Takze robot si zkusi 5 hesel a pak ma na 5 minut utrum. Funguje to bezvadne, v nejnovejsich jadrech i s IPv6.

Roboti skenuji uz i IPv6? :-)

Zatim ne, ale az zacnou, tak na me si neprijdou ;-)

LOL ..................

Ano, scanuji. Mam server pripojeny pres tunnelbroker.net a musel jsem si dat take accesslist i na ipv6…

Diky! …aspon deset znaku ooo jak to obtezuje…

„Takze robot si zkusi 5hesel a pak ma na 5minut utrum“

Coz je ovsem na nic, pokud robot neni robot, ale sit robotu a zkusi kazde heslo z jineho IPcka.

Taky jsem si napsal vlastni skriptik v bashi do syslog-ng. Kdyz se v syslogu objevi zaznam z sshd, tak syslog-ng spusti skript. Ten pak precte chybu a podle druhu chybu zablokuje v iptables port pro dane IP. Nekteri roboti pouze skenuji „did not send identification string“, jini zkousi hesla. Ale i clovek se muze obcas preklepnout, takze to blokuje ruznymi zpusoby.

Tak nesyslete a sup sem s tim :-), kdyz uz jsme ta komuuuunita.

Nastesti jsem zatim nenarazil na pripad kdy by kazde spojeni slo z jine adresy. I kdyz je tech robotu v siti vic tak to stejne kazdeho z nich po par pokusech odstrihne. A dost casto to po tech peti minutach uz znovu nezkousi – asi si reknou ze jsou out a jdou cmuchat jinam.

Nejsou ta pravidla spatne? IMHO to necha projit pet paketu, nikoliv pet otviracich spojeni. Takze selze i jedno bezne.

Pravda, jeste tam patri: -m state –state NEW Diky.

Neni tohle overkill, ktery zbytecne vynuti zapnuti connection tracking?

IMHO by stacilo pridat option –syn

conntrack pouzivam tak jako tak, takze je to asi jedno ;-)