Ekstra Bladet lagt ned i cyberangreb

"Ved et SYN-flood attack sender angriberen en lang række SYN-forespørgsler til serveren, men undlader at svare på de SYN-ACK-meddelelser, der kommer retur." - Hvis IPen er spoofed, så kommer SYN-ACK beskederne vel ikke retur til angriberen (men til den spoofede IP)?

Da angriber vil have "mest muligt" ud af sine ressourcer og ikke agter at svare på SYN-ACK, så giver det fin mening af spoofe afsender adressen. På den made havner SYN-ACK pakken hos en helt forkert modtager (som naturligvis heller ikke bekræfter den). Angriberens udstyr skal således ikke modtage (og ignorere) SYN-ACK pakken.

Der findes et nemt modtræk til at beskytte imod SYN-flood-angreb: SYN cookies http://en.wikipedia.org/wiki/SYN_cookies

Er der virkelig nogen der i forvejen ikke beskytter mod SYN flooding? Det er ikke ligefrem 0day...

SYN flood går ud på at tage så mange resourcer som muligt. En default firewall er ikke beregnet til større angreb.

Hvis man ikke har enten tænkt over det, eller oplevet det, så vil de fleste IKKE have indstillingerne som afviser angrebet effektivt. Jeg har skrevet mere om det tidligere på V2 http://www.version2.dk/blog/hvad-er-ddos-distributed-denial-of-service-1... Sådan som tommelfingerregel vil jeg sige at "host OS" typisk har default indstillinger for firewalls i 10.000-100.000 sessions, mens hardware load balancers typisk ligger i 2-cifrede millioner sessions - 16 millioner mener jeg at kunne huske på en af vores "dårligste" hardware load balancere.

Konklusionen er, undersøg hvad din nuværende firewall har af begrænsninger, forestil dig worst case og find ud af hvor meget tid du vil bruge på at tune og/eller indkøbe mere hardware. Så hvis du er doven skal du måske se på en hardware loadbalancer. Ideen er så at du smider loadbalancer helt ud foran din normale firewall og det er idag muligt at få load balancere som er "ICSA Certified firewalls", så din lokale CSO stadig er glad :-)

Alternativt find ud af hvad du tillader i din firewall og smid alt andet væk med STATELESS filtre som afviser uden at koste nævneværdige resourcer (senest testet i sommers på små Juniper SRX240, og sat i produktion for kunder på samme type enhed).

Lidt modificeret fra en kunde - Junos stateless filtre:

term allow-services {  
    from {  // lad dig ikke forvirre, det er indgående traffik  
        destination-address {   
            10.1.2.0/24;  // det subnet hvor dine web servere er  
        }  
        protocol tcp;  
        destination-port [ 80 443 8080 ]; // lidt udvalgte porte  
    }  
    then accept;  
}  
term block-unneeded {  
    from {  
        destination-address {  
            10.1.2.0/24; // samme subnet som ovenfor  
        }  
        protocol-except icmp;  
    }                             
    then {                        
        discard;                  
    }                             
} 

Det betyder at vores enheder bagved kun skal se på udvalgte protokoller og porte.

Korrekt, det er at sammenligne med spam mails hvor afsender e-mail adressen bliver spoofet. Så får spammerne ikke alle mails tilbage fra servere som ikke kunne levere mailen.
I øvrigt bliver det også sværere at blokere mailene og SYN pakkerne, da man ikke bare kan filtrere på afsender adressen.

Jeg har lært at man ikke bør køre med SYN-cookies til dagligt, da det har nogle ulemper. Stor er min overraskelse derfor da jeg lige vil checke om min maskine er sat op til at bruge SYN-cookies:

baldur@neaira:~$ sysctl -q net.ipv4.tcp_syncookies
net.ipv4.tcp_syncookies = 1

Jeg noterer også at alle vores servere har det slået til, selvom det ikke er noget vi har rodet med.

Hvis reklamematerialet ellers passer, så burde vores servere være immune for SYN-flooding. Ironisk nok kan det være at vores firewall ikke er immun, hvis et SYN-angreb kan overbelaste dens connection-tracking-engine.

"De har haft en masse udstyr til rådighed, og det har sandysnligvis været centralt placeret på internettet"
Det lyder som noget der kræver større arbejde at arrangere og udføre, og hvad opnår de ved at fx EkstraBladet er nede en periode? Jeg kan ikke lige se sammenhæng mellem anstrengelserne og målet.

Det kan være HCL. Nu de gentagne gange har haft bt.dk m.fl. nede de sidste par uger, det kunne være de mente eb.dk var alt for stabil :-)

Man skal ikke afvise at det var "for sjov".

Jeg snakkede en gang med en gut som ville bevise en pointe over for mig og lagde CocaCola.com ned i et kvarters tid. Kender ikke styrken af det angreb han anvendte, men det var som sagt blot for at bevise han kunne. Samme fyr har tidligere været med til at ligge Runescape ned, og de er bestemt vant til at håndtere angreb fra alskens afkroge.

Og nej jeg har intet med den slags pjat at gøre, men man møder uundgåeligt nogle interessante mennesker på forskellige fora.
Og nej jeg har heller ikk hans mail eller anden ID mere. :)