Ataki typu SYN Flood

[minimarek 3]

Witam. Jestem administratorem serwera dedykowanego, na który od pewnego czasu przeprowadzane są częste ataki SYN Flood. Jak Mogę sobie z nimi radzić. Powodują one niedostępność usług znajdujących się na serwerze.

W Firewallu mam następującą regułę ustalającą limit połączeń:

 

iptables -A syn-flood -m limit --limit 30/s --limit-burst 200

 

 

W czasie ataku ten limit zostaje przekroczony i nie ma możliwości korzystania z usług znajdujących się na nim. Wszystkie pakiety wysyłane są na port 22 (port jest pusty).

Adresy IP w pakietach oczywiście są sfałszowane.

 

W jaki sposób mogę poznać prawdziwe IP napastników (komputerów, z których wysyłane są pakiety).

Jak mogę zablokować odpowiadanie na pakiety SYN wysłane z konkretnego IP lub na konkretny port (chciałbym, aby serwer nie próbował nawiązać połączenia z pakietami wysłanymi na port 22).

Jak jeszcze mogę się w takiej sytuacji zabezpieczyć?

Próbowałem ustawić net.ipv4.conf.all.rp_filter na 1 jednak to nic nie dało (może trzeb w jądrze załączyć jakąś opcję?).

net.ipv4.conf.all.log_martians ustawione na 1 również nie przynosi efektów i nie są logowane żadne dodatkowe akcje.

[shad 38]

Blokada SYN wiąże się z niemożnością komunikacji przez dany port, więc może po prostu zablokuj dany port?

[minimarek 3]

Wszystkie nieużywane porty na serwerze mam zablokowane. Moja domyślna polityka to:

iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT ACCEPT

 

Potem mam tylko kilka wyjątków dodanych.

[Pan Kot 1535]

Po pierwsze wg mnie rulesy są zbyt duże. 10 synów na sekundę z burstem 50 to już za dużo.

Po drugie wkleje Ci kawałek swojego sysctl.conf

# Smurf Attack
net.ipv4.icmp_echo_ignore_broadcasts = 1

#  Bad ICMP Attack
net.ipv4.icmp_ignore_bogus_error_responses = 1

# SynFlood Attack
net.ipv4.tcp_syncookies = 1

# Logi ze spofowanych IP
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

# Source routed
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# Reverse path filtering
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

 

Jeśli we właściwy sposób ustawisz powyższe ustawienia to raczej nie powinno być większych problemów. Jeśli jednak będą to jestem pewny, że nie dostajesz tu czystego synflood'a, a synflood połączony z udp floodem, który jest o wiele bardziej popularniejszy.

[Gość patrys]

Ustawienie limitu na ilość pakietów zablokuje dostęp po przekroczeniu limitu, choć po co liczyć pakiety na port 22 jak można dać DROP ?

Większe ataki SYN mogą być tylko blokowane przez zewnętrzny sprzęt, lokalnie można przeżyć tylko mniejsze "zabawy".

Ale nie polecam używać iptables lokalnie w przypadku otrzymania ataku, bo:

a) jest w stanie tylko policzyć pakiety SYN i zablokować całą komunikacje z flagą S.

b) obciążenie które będzie generował przez to czy moduły typu connlimit będzie zabijało maszynę.

[minimarek 3]

@Archi

Przy każdym restarcie systemu ładuje mu takie ustawienia, więc raczej są poprawne:

 

sysctl net.ipv4.ip_forward=0
sysctl net.ipv4.tcp_syncookies=1
sysctl net.ipv4.tcp_max_syn_backlog=2048
sysctl net.ipv4.tcp_synack_retries=3
sysctl net.ipv4.conf.all.accept_source_route=0
sysctl net.ipv4.conf.all.rp_filter=1
sysctl net.ipv4.conf.all.log_martians=1
sysctl net.ipv4.tcp_rfc1337=1

 

Problemy jednak cały czas występują.

 

Ustawienie limitu na ilość pakietów zablokuje dostęp po przekroczeniu limitu, choć po co liczyć pakiety na port 22 jak można dać DROP ?

Większe ataki SYN mogą być tylko blokowane przez zewnętrzny sprzęt, lokalnie można przeżyć tylko mniejsze "zabawy".

Ale nie polecam używać iptables lokalnie w przypadku otrzymania ataku, bo:

a) jest w stanie tylko policzyć pakiety SYN i zablokować całą komunikacje z flagą S.

b) obciążenie które będzie generował przez to czy moduły typu connlimit będzie zabijało maszynę.

 

Właśnie też doszedłem do wniosku, że zliczanie pakietów nie ma sensu. Myślisz, że sprzęt z Xeon W3520 i 24GB RAM nada się jako firewall przed docelowym serwerem (miałby za zadanie jedynie filtrować ruch, który w czasie ataku osiąga ~80Mbps). Jeśli tak, to jakiego oprogramowania użyć (zwykły iptables? może z modułem geoip?).

[kafi 2425]

Nie dziwne jest dla was to, że input policy jest ustawione na drop,

a ataki przychodzą na port 22 na którym nic nie ma,

no więc rozpoczyna się zabawa w connection tracking?

 

Przecież w teorii w takiej konfiguracji jakiekolwiek pakiety (czy to SYN, czy SYN/ACK czy inne) powinny być z automatu dropowane.

Jeśli nadal występuje problem to IMO nic innego nie pozostaje jak zewnętrzny firewall, bo to sam system nie wyrabia się.

[minimarek 3]

Przeanalizowałem logi i jednak byłem w błędzie - serwer nie podejmuje próby odpowiedzi na te pakiety. Myślałem tak dlatego, bo serwer całkowicie nie odpowiadał podczas ataku - było to spowodowane limitem nałożonym w iptables. Po jego zwiększeniu podczas ataku jest dostęp do wszystkich usług ale oczywiście trochę mniej płynny. Myślę, że sam system wyrabia bo ma zawsze wolne około 26GB RAM i 6 nieużywanych wątków procesora Xeon E3 1245v2. Sprawdzę jak będzie się spisywał drugi serwer (z łaczem 1Gbit) jako firewall.

[Pan Kot 1535]

Ja myślałem, że to na jakieś 80 leci, mój błąd zatem . Jeśli rzeczywiście nie ma OpenSSH na porcie 22 to pakiety i tak są DROP'owane, skoro nie ma żadnego allow na 22 i policy drop.

 

W tym wypadku pomoże tylko zewnętrzny firewall, możesz minimalizować straty jeszcze software'owymi firewallami, które operują na iptables np. CSF, ale dużej zmiany raczej nie zauważysz.

[kafi 2425]

Myślę, że sam system wyrabia bo ma zawsze wolne około 26GB RAM i 6 nieużywanych wątków procesora Xeon E3 1245v2

Napisałem, że system nie wyrabia, a nie że sprzęt nie wyrabia To nie kwestia zasobów a samego kernela do którego i tak te pakiety muszą dojść zanim zostaną przez niego zignorowane. Poza tym zauważ, że portów tcp masz tak naprawdę 65k, więc backlog nie jest z gumy

[minimarek 3]

A jak z pytaniem z pierwszego postu? Jest jakiś sposób żeby poznać IP z jakich wysyłane są te pakiety?

[furek 37]

Zainstaluj Tsharka.