Permalänk

Skydd mot synflood

Hej. Jag labbar lite i skolan, och försöker sätta upp en brandvägg med iptables i Ubuntu Server. Från en dator kör jag en synflood, som spoofar MAC-adresser och avsändar-IP. Med iptables har jag en regel i stil med:

iptables -A FORWARD –p tcp --syn -m limit --limit 5/second --limit-burst 8 -j ACCEPT

Jag har även syncookies aktiverade. Problemet är att, även om jag lyckas skydda klienten bakom brandväggen, så kommer jag ju inte åt någon tjänst utifrån så länge attacken pågår. Vad finns det för lösningar?

Permalänk
Medlem

Finns väl egentligen inget man kan göra om attacken tar upp det mesta av bandbredden. Brandväggen måste ju också bearbeta alla paket som den får, oavsett om de droppas eller acceptas vilket kommer att stjäla resurser.

Permalänk
Medlem

http://www.securityfocus.com/infocus/1729

Tänk vad man kan hitta om man googlar. *hint hint*

Permalänk
Citat:

Ursprungligen inskrivet av SwedishPshyco
http://www.securityfocus.com/infocus/1729

Tänk vad man kan hitta om man googlar. *hint hint*

Jo då, jag har googlat, varit inne på den där sidan och snurrat också
Men, det står samma sak där som på alla andra sidor:

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

vilket jag testat, utan resultat. Med iptables lyckas jag hålla brandväggen vid liv, men den kan ju inte skilja på ett "riktigt" SYN från de i attacken.

Permalänk
Medlem

Att skydda sig helt mot sånt är som att skydda sig mot att det springer flera hundra personer i en korridor mot din dörr. Även om dörren är stängd så kommer korridoren vara full och du ha problem att ta dig ut därifrån.

Permalänk
Citat:

Ursprungligen inskrivet av bogg
Att skydda sig helt mot sånt är som att skydda sig mot att det springer flera hundra personer i en korridor mot din dörr. Även om dörren är stängd så kommer korridoren vara full och du ha problem att ta dig ut därifrån.

Absolut, jag förstår problemet, men det finns ju bland annat hårdvarubrandväggar som står emot sådana attacker. Är enda lösningen att ha bra prestanda och en rejäl internetpipa?

Grejen är den, att vi har testat attacken mot ett antal system i grundutförande, och den enda som står emot är Windows 2003 Server, som fortfarande klarar nya, riktiga, anslutningar under attacken. Eftersom det fungerar i Windows borde det ju rimligtvis fungera i *nix också?

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Ghost_Overdoze
Absolut, jag förstår problemet, men det finns ju bland annat hårdvarubrandväggar som står emot sådana attacker. Är enda lösningen att ha bra prestanda och en rejäl internetpipa?

Grejen är den, att vi har testat attacken mot ett antal system i grundutförande, och den enda som står emot är Windows 2003 Server, som fortfarande klarar nya, riktiga, anslutningar under attacken. Eftersom det fungerar i Windows borde det ju rimligtvis fungera i *nix också?

Japp, det ska det ju göra.

Har du testat sätta upp lite state-värden i iptables på Linux burken?

T.ex. nått liknande:

iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Permalänk
Citat:

Ursprungligen inskrivet av bogg
Japp, det ska det ju göra.

Har du testat sätta upp lite state-värden i iptables på Linux burken?

T.ex. nått liknande:

iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Japp, just så kör jag. Men det tillåter ju som sagt bara anslutningar som skapats innan attacken påbörjat - alla nya SYN blockeras ju under attacken (eller försvinner i mängden när jag bara släpper igenom ett begränsat antal per sekund). Klurigt det här.

Permalänk
Hedersmedlem
Citat:

Ursprungligen inskrivet av Ghost_Overdoze
Absolut, jag förstår problemet, men det finns ju bland annat hårdvarubrandväggar som står emot sådana attacker. Är enda lösningen att ha bra prestanda och en rejäl internetpipa?

Grejen är den, att vi har testat attacken mot ett antal system i grundutförande, och den enda som står emot är Windows 2003 Server, som fortfarande klarar nya, riktiga, anslutningar under attacken. Eftersom det fungerar i Windows borde det ju rimligtvis fungera i *nix också?

Paketfiltret med det fantasifulla namnet 'pf' som finns i de tre vanligaste fria BSD-varianterna, har en funktion kallad synproxy. När den är aktiv för en pass-regel innebär det att brandväggen själv hanterar upprättandet av alla anslutningar. Först när en korrekt trevägs handskakning är genomförd med den anslutande parten släpps något alls fram till servern och resurser allokeras för anslutningen på sedvanligt sätt. Detta tillsammans med dynamisk skalning av timeoutvärden under belastning och pf's effektiva state-hantering borde ge en bra möjlighet att stå emot de otvättade horderna.

Permalänk
Citat:

Ursprungligen inskrivet av Aphex
Paketfiltret med det fantasifulla namnet 'pf' som finns i de tre vanligaste fria BSD-varianterna, har en funktion kallad synproxy. När den är aktiv för en pass-regel innebär det att brandväggen själv hanterar upprättandet av alla anslutningar. Först när en korrekt trevägs handskakning är genomförd med den anslutande parten släpps något alls fram till servern och resurser allokeras för anslutningen på sedvanligt sätt. Detta tillsammans med dynamisk skalning av timeoutvärden under belastning och pf's effektiva state-hantering borde ge en bra möjlighet att stå emot de otvättade horderna.

Det där låter ju som att det skulle kunna fungera i praktiken, tack för tipset. Får kika lite på vad det finns för motsvarigheter (om några) med iptables.