Kunsten at afvikle DDoS 101

Nu er der en masse snak om DDoS på version2 i disse dage - grundet "forskellige omstændigheder", og lad os gerne holde debatten herunder til de tekniske dele, tak

Men hvad er DDoS? DDoS er Distributed Denial of Service, altså distribueret ude-af-drift angreb ... og hvad er så DoS, ude-af-drift?

Ude af drift betyder at den sædvanlige funktion af en server eller service er utilgængelig og er et område der ofte er overset. Vi taler i sikkerhedskredse om CIA, Confidentiality, Integrity og Availability som vigtige principper der skal guide vores sikkerhed. Konkret betyder det at for Version2 og andre medier på internet skal hjemmesiden være tilgængelig, high availability, mens min private side sagtens kan være nede - fordi min produktivitet og produktion ikke er afhængig af hjemmesiden.

Et typisk denial of service er et request som af en eller anden årsag forårsager en skadevirkning, enten som enkeltstående request som får serveren til at gå ned, eller en stribe request som giver høj belastning på serveren - eller udtømmer andre ressourcer som gør at normal service ikke kan opretholdes. Gode eksempler på denial of service er det klassiske ping-of-death https://en.wikipedia.org/wiki/Ping_of_death hvor man med en enkelt pakke med størrelse 65,536-byte kunne få systemerne til at gå ned. Der findes en god side om det på Wikipedia https://en.wikipedia.org/wiki/Denial-of-service_attack

Dengang i 1990'erne var det også simpelt at udføre SYN-flooding, hvor man ved at sende en masse TCP-SYN pakker kunne fylde operativsystemets tabeller op - således at der var en masse halve forbindelser, og ingen nye forbindelser kunne oprettes, før det timede ud. Se evt. https://en.wikipedia.org/wiki/Syn_flood . Måden man bekæmper SYN flood er blandt andet at time forbindelserne hurtigere ud, specielt når tabellen er ved at løbe tør. En anden metode er at bruge SYN cookies hvor man sender svar tilbage, men ikke behøver at huske hvem som er igang med at oprette forbindelserne. Når der kommer et reelt svar og man skal lave forbindelsen - så kan det rekonstrueres. Dette betyder at man ikke under et angreb behøver at vedligeholde en tabel med 1.000.000 halvåbne forbindelser for at servicere de sædvanlige måske 10.000 brugere. https://en.wikipedia.org/wiki/SYN_cookies

Når vi så spoler frem til idag, så er billedet en del mere komplekst end man skulle tro - der er mange niveauer at udføre angreb på og mange tidligere benyttede angreb virker ikke alene og forsvar mod diverse angreb er forsøgt indført.

DDoS beskyttelse er ikke simpelt. Gentag efter mig: DDoS beskyttelse er ikke simpelt.

Når vi taler om DDoS så er det rigtigt at vi i vist omfang kan gøre ting for at minimere effekten, og lad os straks give det videre:

• Start med at hærde dine services - sluk for unødvendige features, fjern dele af konfiguration som ikke benyttes. Specielt for Apache HTTP, så fjern default config og lav din egen!
• Sørg for at have opdateret software på dine servere OG netværksenheder. Vi har udvalgt en bestemt version af firmware til firewalls for at få bestemt funktionalitet.
• Sørg for at tune dit system til høj belastning - køb MEGET gerne ekstra hardware, mere ram osv. Indimellem kan almindelig "success" virke som et DoS, se slashdot-effekten :-)
• Sørg for at teste dine services, for tiden er jeg begyndt at blive glad for https://tsung.erlang-projects.org/ til test af HTTP servere
• Sørg for at monitorere dine services - vi bruger selv pingdom.com samt Xymon, Nagios, m.fl. - husk at reagere på alarmer ;-)
• Sørg for at opsamle logs og netflow fra netværket (sflow, jflow, netflow, IPfix) - jeg skal i denne uge se på logstash igen https://logstash.net/
• Sørg for at løbende at grafe/opsamle din baseline for drift - således at det er nemt at se når noget er unormalt

uha, det lyder som meget arbejde - tjoeh, det er vel et minimum hvis du vil have en god service ;-) OG det er altsammen noget som sparer dig tid i forbindelse med et DDoS.

Når der kommer DDoS

Når du bliver ramt af DDoS er det altid på det mest ubelejlige tidspunkt, hvor du står med den lille baby på armen, har tynd mave, konen er ude i byen, og dit internet er gået ned og mobilen er løbet næsten tør for strøm. Tænk gerne på det på denne måde, så du har en kommandovej planlagt til at give sagen videre til næste mand. Vi informerer generelt i hele organisationen hvis der er angreb (vi har en lille driftsorganisation) og alle mand springer til og hjælper.

Forløbet er nogenlunde sådan,

• alarmer om at noget er galt, høj CPU, services der svarer langsomt eller slet ikke
• Første man mistænker DoS, informerer opad "tror der er DDoS/DoS"
• Vi undersøger, logs, sessions, antal pakker pr sek, mbits gennem netværket - det resulterer typisk i at antagelsen bekræftes og vi opgraderer til "Ja, der er DDoS/DoS mod kunde X og de bruger pt. ICMP flood/UDP flood/TCP flood/SYN-attack", whatever. Det vigtigste her er at få identificeret hvad der er under angreb, og hvad strategi der benyttes lige pt.
• Vi informerer kunden som er under angreb og eventuelt andre berørte kunder (det er svært i kampens hede) - typisk sker det ved at vi sikrer at telefonsupporten svarer "Ja, vi har nogle problemer, vi sender information ud hurtigst muligt"

Godt, angrebet er igang og hvad så? Du har generelt følgende muligheder:

• Forsøg at blokere bestemt IP-adresser - der er jævnligt enkelte IP-adresser som sender ekstreme antal requests og de ryger i skraldespanden - stateless filter helt ude i edge mod andre netværk, væk!
• Forsøg at blokere større ranges som udelukkende sender skadelig traffik - hvis den pågældende service primært bruges i DK kan man forsøge at etablere en liste over europæiske adresser som benyttes som en positivliste - dem der må tilgå servicen. Det har en andre god effekt at HVIS der stadig modtages skidt kan man bedre spore det og får oftere hurtig respons fra en tysk ISP, end en ISP i Thailand eller Bolivia.
• Sæt flere servere i spil, VMware/Xen/HyperV - her hjælper det hvis man har en procedure for at deploye flere servere :-)
• Skru ned for antal requests som tillades ind - rate limiting og diverse max connections pr source IP og max connections pr destionation IP
• luk evt. for dele af service, skift forsiden ud således at den er mere simpel og ikke har det der spørgeskema der laver 10 SQL requests for at vise en lille graf :-)
• Brug alt hvad din infrastruktur tillader dig, læs din firewall manual før der er brug for det

Sørg for under hele seancen at have ledelsen på plads til at tage beslutningerne, nogle filtre og begrænsninger vil afskære kunder fra at få service, men igen uden disse vil ingen kunder måske kunne bruge servicen overhovedet. Du skal yderligere være klar til at angriberne skifter taktik eller blander flere slags angreb.

Hvis du har en offentlig hjemmeside af en vis størrelse bør du allerede nu have tænkt over hvordan angreb håndteres.

Testværktøjer

Til at teste servere benytter jeg næsten altid BackTrack Linux https://www.backtrack-linux.org/ og jeg har to små maskiner med 10Gbit netkort som jeg har indkøbt og tunet til at kunne sende 9,5Gbit/s (målt med iperf over 60 sekunder). Til dagens morskab vil jeg nøjes med at introducere en ting idag, en gammelkendt klassiker tcpreplay https://tcpreplay.synfin.net/ som bruges til at gensende PCAPs, altså packet capture dumps, som er filer med netværkspakker. Dette program kan læse en PCAP, og sende ud på et vilkårligt netkort, evt. kan man ændre visse parametre (tcpreplay-edit). PCAP filen kan du nemmest lave ved at starte tcpdump, eksempelvis

tcpdump -s 1500 -w icmp-echo-100000.cap icmp

Det sidste på linien er det filter der udvælger pakkerne der opsamles. Jeg kunne skrive "icmp or tcp" for at opsamle begge dele. Derefter laver jeg typisk et lille script, som blot kalder kommandoen, det sikrer at jeg næste gang kan huske hvad jeg gjorde og nemmere kan gentage tests.

hlk@xpc02:~/packetfactory$ cat boom2.sh 
sudo /pentest/sniffers/tcpreplay/tcpreplay -t -i eth2 -K 
     -l 5 /home/hlk/packetfactory/590000-packets.cap

Dette vil sende pcap filen ud med max hastighed (-t) på ethernet eth2 med caching af filen i memory (-K) og loop 5 gange. Lækkert lille DoS forsøg.

hlk@xpc02:~/packetfactory$ ./boom2.sh 
sh: warning: setlocale: LC_ALL: cannot change locale (da_DK.UTF-8)
sending out eth2 
File Cache is enabled
processing file: /home/hlk/packetfactory/590000-packets.cap
processing file: /home/hlk/packetfactory/590000-packets.cap
processing file: /home/hlk/packetfactory/590000-packets.cap
processing file: /home/hlk/packetfactory/590000-packets.cap
processing file: /home/hlk/packetfactory/590000-packets.cap
Actual: 2950000 packets (123900000 bytes) sent in 3.38 seconds.   
    Rated: 36656804.0 bps, 279.67 Mbps, 872781.06 pps
Statistics for network device: eth2
    Attempted packets:         2950000
  Successful packets:        2950000
  Failed packets:            0
    Retried packets (ENOBUFS): 0
    Retried packets (EAGAIN):  0

Bemærk: dette er en Shuttle PC med Intel netkort - vi snakker altså ikke om et kæmpe server, men ikke desto mindre kan den levere et fint lille DoS med ~300Mbit og 872k pakker pr sekund!

Sponseret indhold

Webinar: Det er ikke nok at sikkerhedskopiere din data

It-sikkerhed

Hvis du skal ændre enkelte dele af pakken, eksempelvis ethernet destination MAC, kan det gøres nemt med tcpreplay-edit:

sudo /pentest/sniffers/tcpreplay/tcpreplay-edit --enet-dmac=80:ee:73:16:e1:57 
    -C -t -i eth2 -K -l 1000 /home/hlk/packetfactory/tcpflood.pcap 

Næste indlæg vil handle om packetfu, https://github.com/todb/packetfu