Iptables - zabezpieczenie serwera ssh

zet120 · Post autor: **zet120** » 03 lipca 2010, 14:53

Witam!
Po skonfigurowaniu i uruchomieniu usługi ssh na domowym serwerze już po kilku chwilach w logach obserwuję:

Jul  2 23:15:57 mail sshd[13576]: Invalid user apache from 200.201.180.130
Jul  2 23:15:59 mail sshd[13578]: reverse mapping checking getaddrinfo for mvx [200.201.180.130] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul  2 23:15:59 mail sshd[13578]: Invalid user dan from 200.201.180.130
Jul  2 23:16:02 mail sshd[13580]: reverse mapping checking getaddrinfo for mvx [200.201.180.130] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul  2 23:16:02 mail sshd[13580]: Invalid user dan from 200.201.180.130
Jul  2 23:16:04 mail sshd[13582]: reverse mapping checking getaddrinfo for mvx [200.201.180.130] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul  2 23:16:04 mail sshd[13582]: Invalid user dan from 200.201.180.130
Jul  2 23:16:07 mail sshd[13584]: reverse mapping checking getaddrinfo for mvx [200.201.180.130] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul  2 23:16:07 mail sshd[13584]: Invalid user dan from 200.201.180.130
Jul  2 23:16:09 mail sshd[13586]: reverse mapping checking getaddrinfo for mvx [200.201.180.130] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul  2 23:16:09 mail sshd[13586]: Invalid user electra from 200.201.180.130
Jul  2 23:16:12 mail sshd[13588]: reverse mapping checking getaddrinfo for mvx [200.201.180.130] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul  2 23:16:12 mail sshd[13588]: Invalid user student from 200.201.180.130
Jul  2 23:16:15 mail sshd[13590]: reverse mapping checking getaddrinfo for mvx [200.201.180.130] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul  2 23:16:15 mail sshd[13590]: Invalid user student from 200.201.180.130
Jul  2 23:16:17 mail sshd[13592]: reverse mapping checking getaddrinfo for mvx [200.201.180.130] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul  2 23:16:17 mail sshd[13592]: Invalid user student from 200.201.180.130

Zatem wyłączyłem logowanie za pomocą hasła, zmieniłem port na "wyższy" oraz chciałem do roboty zaprząc iptables.

W sieci znalazłem np. taki fragment:

Kod: Zaznacz cały

#iptables -I INPUT -m tcp -p tcp --dport 22 -j REJECT
#iptables -I INPUT -m tcp -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT
#iptables -I INPUT -m tcp -p tcp --dport 22 -m state --state RELATED,ESTABLISHED -j ACCEPT

Teoretycznie Iptables po trzech nieudanych próbach logowania powinien na trzy minuty zablokować możliwość połączenia.
Ale działa to inaczej, a mianowicie po czterech próbach rzeczywiście połączenie jest blokowane, ale na około 15-20 sekund
Dlaczego?
Dla porządku cały konfig Iptables:

Kod: Zaznacz cały

#!/bin/sh

# czyszczenie starych regul
iptables -F
iptables -X
iptables -t nat -X
iptables -t nat -F

# ustawienie domyslnej polityki
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -i lo -j ACCEPT
iptables -A FORWARD -o lo -j ACCEPT
# iptables -A INPUT -i eth0 -j ACCEPT

# utrzymanie polaczen nawiazanych
iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED
iptables -A FORWARD -j ACCEPT -m state --state ESTABLISHED,RELATED
iptables -A OUTPUT -j ACCEPT -m state --state ESTABLISHED,RELATED

# Samba
iptables -A INPUT -s 192.168.2.0/24 -p udp --dport 137 -j ACCEPT
iptables -A INPUT -s 192.168.2.0/24 -p udp --dport 138 -j ACCEPT
iptables -A INPUT -s 192.168.2.0/24 -p tcp --dport 139 -j ACCEPT
iptables -A INPUT -s 192.168.2.0/24 -p tcp --dport 445 -j ACCEPT

# SSH
#iptables -I INPUT -m tcp -p tcp --dport 2223 -j REJECT
#iptables -I INPUT -m tcp -p tcp --dport 2223 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT
#iptables -I INPUT -m tcp -p tcp --dport 2223 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Bind
iptables -A INPUT -s 0/0 -p udp --dport 53 -j ACCEPT

# Postfix
iptables -A INPUT -s 0/0 -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -s 0/0 -p tcp --dport 110 -j ACCEPT
iptables -A INPUT -s 0/0 -p tcp --dport 993 -j ACCEPT

# HTTP_Web
iptables -A INPUT -s 0/0 -p tcp --dport 80 -j ACCEPT

# HTTP_SSL
iptables -A INPUT -s 0/0 -p tcp --dport 443 -j ACCEPT

# rTorrent
iptables -A INPUT -s 0/0 -p tcp --dport 31415 -j ACCEPT

Mogę liczyć na wskazówkę?

Edycja:
Szukając rozwiązania trafiłem na coś takiego:

Kod: Zaznacz cały

iptables -N PUKPUK
iptables -A INPUT -j PUKPUK
iptables -A FORWARD -j PUKPUK
iptables -A PUKPUK -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A PUKPUK -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT
iptables -A PUKPUK -m state --state NEW -m tcp -p tcp --dport 22 -j DROP
iptables -A PUKPUK -m state --state NEW -m tcp -p tcp --dport 666 -m recent --name SSH --set -j DROP
iptables -A PUKPUK -m state --state NEW -m tcp -p tcp --dport 999 -m recent --name SSH --remove -j DROP

Obsługa troszkę karkołomna, ale działa jak należy.

snejk · Post autor: **snejk** » 03 sierpnia 2010, 00:54

Kod: Zaznacz cały

#iptables -I INPUT -m tcp -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT

Teoretycznie Iptables po trzech nieudanych próbach logowania powinien na trzy minuty zablokować możliwość połączenia.

Postanowiłem odświeżyć temat ponieważ sam nie mogłem kiedyś zrozumieć zasady działania modułu limit, a może przy okazji komuś też coś rozjaśnię.

Ale działa to inaczej a mianowicie po czterech próbach rzeczywiście połączenie jest blokowane, ale na około 15-20 sekund
Dlaczego?

Ponieważ ustawiłeś, że 3 pakiety (--limit-burst 3) mają być przepuszczane 3 razy na minute (--limit 3/min), czyli raz na 20 sekund wpuszczane są 3 pakiety, więc to co napisałeś się zgadza. Po trzech pakietach przepuszczonych, firewall blokuje kolejne połączenia na 20 sekund i tak od początku. Jeżeli chcesz ustawić limit 3 połączeń na 3 minuty musisz wpisać :

Kod: Zaznacz cały

iptables -I INPUT -m tcp -p tcp --dport 22 -m state --state NEW -m limit --limit 20/h --limit-burst 3 -j ACCEPT

20 razy na godzinę, czyli raz na 3 minuty (60 : 20 = 3) wpuszczone zostaną 3 pakiety na port 22 z ustawioną flagą SYN.

P.S. To mój pierwszy post i zapomniałem się przywitać

grzesiek · Post autor: **grzesiek** » 03 sierpnia 2010, 17:07

Zamiast limit, użyj modułu recent: http://www.debian-administration.org/articles/187
Sam też miałem problemy tego typu i napisałem pewien skrypt, który możesz z powodzeniem zastosować: http://debian.linux.pl/entries/30-Imple ... onie-cz.-1
Co do sshd ustaw niestandardowy port i wyłącz logowania się dla użytkownika root. Można też użyć mało wygodne rozwiązanie jakim jest port knocking.

snejk · Post autor: **snejk** » 04 sierpnia 2010, 00:15

Kod: Zaznacz cały

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
  --set

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
  --update --seconds 600 --hitcount 2 -j DROP

Z tym, że te regułki są pisane z myślą o domyślnej polityce ACCEPT łańcucha INPUT. Jeżeli masz ustawioną politykę, a przepuszczam że tak jest, na DROP to musisz dodać na końcu:

Kod: Zaznacz cały

iptables -A INPUT -p tcp --dport 6344 -i eth0 -j ACCEPT

I teraz wszystko działa elegancko

A jeszcze lepiej jak dodasz --name "nazwa_połączenia" wtedy w pliku:

Kod: Zaznacz cały

/proc/net/ipt_recent/nazwa_połączenia

Masz wypisane adresy ip zablokowane i możesz sobie wydzielić wtedy kilka takich nazw dla rożnych reguł i wiesz dokładnie jaki adres i z jakiego powodu jest przyblokowany.