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 http://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 http://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. http://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. http://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 http://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 http://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 http://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 http://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!

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

Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Bryan Østergaard

Jeg er med til at drive freenode IRC netværket som også fra tid til anden oplever DDoS angreb.

For freenodes vedkommende gælder der det særlige at alle vores servere er sponsoreret af organisationer uden nogen direkte forretningsmæssig forbindelse til freenode. Det betyder blandt andet at hosting betingelserne varierer ret meget fra server til server og vores ansvar varierer tilsvarende. Generelt har vi dog ingen adgang til switche, routere mv. så for os er det enormt vigtigt at have (opdateret!) dokumentation af hvem der er sponsor for de enkelte servere og hvordan vi kan kontakte dem.

Og da vi har servere på (næsten) alle kontinenter har vi selvfølgelig en ekstra udfordring i form af tidszoner.

Generelt er vi ekstra opmærksomme på dokumentation og jeg kan på det stærkeste anbefale at man sørger for at det er i orden så man ved hvordan disse angreb skal håndteres på forhånd. Og husk endelig en "lokal" kopi af dokumentationen så man ikke ender i problemer når ens wiki bliver DDoS'et.

  • 2
  • 0
Troels Arvin

Man bliver så (sommer-)glad, når man ser nogen fremhæve fjernelse/deaktivering af software + patching og den slags; det står i skarp kontrast til de talrige eksempler på tåbelige vejledninger, som anbefaler installation af diverse placeboware. IT-sikkerhed handler om grunding, asketisk systemadministration - ikke om installation af alskens glimmerværk.

Nå, men bortset fra dét: Du nævner logstash, som jeg aldrig havde hørt om før. Og dette får mig til at foreslå: Skriv på tidspunkt gerne om dine erfaringer med programmer/systemer til indsamling af (sys-)logs og præsentation af samme - fx via web-interfaces. Jeg er personligt rigtig glad for en alm. syslog-server, hvor man kan tail'e+grep'e på en messages-fil, men mange vil nok foretrække at have et web-interface i stedet. En god løsning, der opfylder begge behov, ville være interessant at høre om.

  • 0
  • 0
Henrik Kramshøj Blogger

Hvordan kan jeg se om det er ddosing eller bare ekstra trafik på websitet, grundet "succes" som du skriver?

Kan være svært i starten, men når man dykker ned i spikes af traffik og ser det hele er ICMP eller UDP - rettet mod en HTTP server tegner der sig hurtigt et mønster. Tilsvarende kan vi med Netflow se ca. hvor mange data der sendes frem og tilbage, så kortvarige forbindelser som ikke overfører nævneværdige data er mistænkelige.

Ligeledes ser vi på whois for stikprøver af data og hvis de siger chinanet for en server i DK er det tilsvarende mistænkeligt. Vi ser dog også jævnligt en masse connections som ved første øjekast ser underligt ud - men viser sig at komme fra mobiloperatører som har mange kunder bagved IPv4 NAT.

@Troels, ja skal nok se på mere logstash, der er en på campen som gav mig lidt input - fordi vi kom omkring logstash og http://logio.org/ - som ligeledes er spændende med real-time log via browser. Ja, undskyld jeg pusher så mange links ud til værktøjer, jeg håber vel at nogle af jer undersøger dem og melder tilbage :-D

  • 0
  • 0
Michael Myrhøj

Nu er jeg på ingen måde teknisk kyndig nok til at forstå dine forslag, men jeg betvivler ikke det vil virke.

Det du foreslår koster en del administration og dit forslag om at købe rigeligt med hardware til webservere vil helt sikkert glæde jeres serverleverandør ;)

Jeg finder det tilgengæld interessant at der ikke bliver peget nogle af de færdige appliances der er udviklet til at håndtere DDOS angreb? En hurtig google søgning giver i hvert tilfælde rigeligt med hits

  • 0
  • 0
Henrik Kramshøj Blogger

Jeg finder det tilgengæld interessant at der ikke bliver peget nogle af de færdige appliances der er udviklet til at håndtere DDOS angreb? En hurtig google søgning giver i hvert tilfælde rigeligt med hits

Et 10Gbit dual-port netkort med to porte koster i omegnen af 5.000kr Intel 82599 eller Myricom omkring 600-700 EURO. En server koster det en server koster, rimeligt billigt fordi vores søsterselskab køber servere hele tiden :-)

Så i den forbindelse er en dedikeret DDoS appliance ikke interessant for mig, fordi 10Gbit udgaverne er helt urimelige i pris - og passer dårligt ind i vores netværk. BTW vores netværk er ikke specielt stort, men vi har aligevel et antal 10Gbit ud mod andre netværk, så det vil koster x gange appliance prisen ...

Vi har til gengæld investeret i "data center" modellerne af firewalls, som gør det muligt nemt at følge de råd jeg gav ovenfor:
* Skru ned for antal requests som tillades ind - rate limiting og diverse max connections pr source IP og max connections pr destionation IP. Det er noget som de fleste firewalls idag burde kunne, ellers lav en plan for udskiftning.

Dette er ligeledes kun en del af en større strategi som bruger stateless firewall filtre til at fjerne det værste og kun tillader eksempelvis port 80 og 443 til webservice mod bestemte ranges (det letter arbejdet at vi har rigeligt med IP :-) )

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize