DDoS aanval op TransIP

Afdrukvoorbeeld

Toon 40 bericht(en) van dit onderwerp op één pagina

08/04/13, 14:49
Wido

Citaat:

Oorspronkelijk geplaatst door Apoc

Hoe je het ook wendt of keert; uiteindelijk is er geen enkele oplossing om DDoS aanvallen geheel te stoppen (tenzij de aanval tegen 1 specifieke site gericht is, maar niet wanneer het tegen een heel netwerk gericht is).

Binnen elk redelijk budget :)

Natuurlijk kan jij het dikste netwerk ter wereld bouwen, maar als het ruim 10- miljoen (noem maar wat) per jaar kost omdat online te houden dan is het het ook niet echt waard.

Citaat:

Oorspronkelijk geplaatst door Apoc

Wellicht zou het nuttig kunnen zijn om een wereldwijde database aan te leggen van IPs die zijn waargenomen tijdens aanvallen. Daar zitten dan uiteraard ook legitieme verbindingen tussen, maar dat zou te filteren moeten zijn door data van verschillende aanvallen met elkaar te vergelijken. Ten eerste zou je aan de hand daarvan geautomatiseerde abuse notificaties kunnen sturen naar providers. Ten tweede zou je aan de hand van de IP database (en het monitoren van hoe goed een provider ervoor zorgt dat problemen opgelost worden) je dan weer per netwerk (en per subnet) een risicotabel kunnen maken, en die uit je BGP tabel halen tijdens zo'n aanval. Je blokkeert dan natuurlijk ook tal van onschuldige bezoekers, maar dan ben je in ieder geval voor een deel van het internet bereikbaar. Daarnaast zou dit ook nog wel eens een goede motivator voor providers kunnen zijn om meer aandacht aan het afhandelen van abuse te besteden (je ziet m.i. bij nogal wat providers dat er weinig aandacht uit gaat naar het afhandelen van abuse, omdat ze er geen commercieel belang bij hebben).

Aan zo'n aanpak zullen vast ook haken en ogen zitten, maar je moet toch ergens beginnen..

Probleem is dat veel verkeer gespoofed is. Zeker met UDP is dat een probleem, maar met TCP heb je het ook in de vom van SYN-attacks.

hping3 is hier een smerige tool bij.

Wat veel partijen zouden moeten doen is in hun routers controleren of de source van het pakketje wel uit hun netwerk kán komen en dat gebeurd vaak niet.

Je kan dus gewoon vanaf jouw thuis verbinding vaak gewoon als afzender het IP-adres van een webserver in het DC opgeven en die routers kijken alleen naar de destination. Zo kan je continue random source adressen opgeven.

Een jaartje terug hadden wij een DDoS in die vorm, daar kwamen 1.5 Mpps binnen vanaf ongeveer het "hele internet" (gespoofed dus). Dit leek érg op hping3 verkeer, want de source poort was altijd 1234. Dat was een kwestie van voldoende machines neer zetten en met iptables op sport 1234 filteren.
08/04/13, 15:41
Apoc

Klopt, ik dacht in mijn redenering al een stapje verder vooruit. Uiteindelijk is het denk ik onontkomelijk dat alle netwerken anti-spoofing (zoals jij omschreef) zullen moeten implementeren (en daartoe geforceerd zullen moeten gaan worden).
08/04/13, 21:50
Mark17

Een lijst met partijen die BCP38 volgen voor uitgaand verkeer (aan de rand van hun netwerk of op meer punten) kan al een motivator zijn voor een aantal partijen. Dat is een goede anti-spoofing maatregel die als iedereen het invoert kan helpen. Zolang niet bekend is wie dit volgt is het voor klanten ook niet mogelijk bewust te kiezen voor een partij die dit wel doet. Bij normaal gebruik merkt geen enkele klant er wat van (als het goed is).

Transits zouden het ook voor hun klanten kunnen forceren door filters te plaatsen als ze weten welke ranges die klant heeft.
09/04/13, 09:28
Wido

Citaat:

Oorspronkelijk geplaatst door Mark17

Een lijst met partijen die BCP38 volgen voor uitgaand verkeer (aan de rand van hun netwerk of op meer punten) kan al een motivator zijn voor een aantal partijen. Dat is een goede anti-spoofing maatregel die als iedereen het invoert kan helpen. Zolang niet bekend is wie dit volgt is het voor klanten ook niet mogelijk bewust te kiezen voor een partij die dit wel doet. Bij normaal gebruik merkt geen enkele klant er wat van (als het goed is).

Transits zouden het ook voor hun klanten kunnen forceren door filters te plaatsen als ze weten welke ranges die klant heeft.

Het hele niet filteren van source verkeer is inderdaad een groot onderdeel van dit probleem.

Overigens kunnen lang niet alle routers dit aan, vaak moet zoiets over de CPU wat bij veel pps een probleem wordt.
09/04/13, 10:18
visser

Citaat:

Oorspronkelijk geplaatst door Wido

Het hele niet filteren van source verkeer is inderdaad een groot onderdeel van dit probleem.

Overigens kunnen lang niet alle routers dit aan, vaak moet zoiets over de CPU wat bij veel pps een probleem wordt.

Gewoon source IP filteren , zonder logging, duwt forwarding in een zwaar pad ? Bij welk merk/model zou dat zijn ?

In elk geval voor Cisco en Juniper is het zeker niet waar, en gaat een recht-recht aan filter met minimale overhead in hetzelfde forwarding pad als verkeer zonder filter.

Op veel apparatuur is het mogelijk en makkelijk om te filteren naar 'reverse path' (unicast RPF). Dan wordt alleen verkeer geaccepteerd met een source adres waarvan de route terug naar het interface gaat waarover dat verkeer binnen kwam.

(cisco : ip verify unicast source reachable-via rx , Linux : /proc/sys/net/ipv4/conf/*/rp_filter )
Op een ethernet interface met hosts erachter is dat gewoon 'alleen source adressen die binnen dit subnet zitten', en hoef je geen access lists bij te houden.

Als eind-netwerk kun je het in laatste instantie doen op de border router(s) naar je upstreams, en hier 'alleen source IPs uit mijn eigen prefixen" naar buiten laten.
09/04/13, 11:33
Wido

Citaat:

Oorspronkelijk geplaatst door visser

Gewoon source IP filteren , zonder logging, duwt forwarding in een zwaar pad ? Bij welk merk/model zou dat zijn ?

In elk geval voor Cisco en Juniper is het zeker niet waar, en gaat een recht-recht aan filter met minimale overhead in hetzelfde forwarding pad als verkeer zonder filter.

Op veel apparatuur is het mogelijk en makkelijk om te filteren naar 'reverse path' (unicast RPF). Dan wordt alleen verkeer geaccepteerd met een source adres waarvan de route terug naar het interface gaat waarover dat verkeer binnen kwam.

Oa Brocade apparatuur kan dit niet altijd. De XMR kan het wel bijvoorbeeld.

Je moet dan aan de slag met (s)ACL's.
09/04/13, 12:55
visser

Citaat:

Oorspronkelijk geplaatst door Wido

Oa Brocade apparatuur kan dit niet altijd. De XMR kan het wel bijvoorbeeld.

Je moet dan aan de slag met (s)ACL's.

Het ontbreken van uRPF is hinderlijk (en feitelijk al niet van deze tijd), maar zijn Brocades dan ook waar je op doelde met apparatuur die een simpele acl al via de CPU laat lopen ?
09/04/13, 14:33
Wido

Citaat:

Oorspronkelijk geplaatst door visser

Het ontbreken van uRPF is hinderlijk (en feitelijk al niet van deze tijd), maar zijn Brocades dan ook waar je op doelde met apparatuur die een simpele acl al via de CPU laat lopen ?

Het wisselt heel erg per model.

Vooral oudere modellen doen dit via de CPU. Wij hebben net de Brocade CER gekregen en die kan dit wel in hardware doen.

De aanname dat elke router het in hardware afhandeld is niet altijd waar.

Wel zou iedereen dit aan moeten zetten indien mogelijk, dat kan een hoop troep schelen.
09/04/13, 14:56
visser

Citaat:

Oorspronkelijk geplaatst door Wido

Het wisselt heel erg per model.

Vooral oudere modellen doen dit via de CPU. Wij hebben net de Brocade CER gekregen en die kan dit wel in hardware doen.

De aanname dat elke router het in hardware afhandeld is niet altijd waar.

Wel zou iedereen dit aan moeten zetten indien mogelijk, dat kan een hoop troep schelen.

Ik ken de brocade lijnen dus niet, maar dat dit soort pruts designs nog op de markt zijn verbaast me.
("oude modellen" met zo'n spec omschrijving zou ik rond ~2000 dateren ...)
(Nitpickje : echte routers zijn tot een zekere model/performance range meestal toch meer cpu gebaseerd bij veel vendors. Maar hoe dan ook mag je normaal verwachten je dat een 'simpele' feature zoals een gewone korte acl hooguit een kleine overhead t.o.v. de normale forwarding performance kost . Als normale forwarding in hardware gaat, dan ook de acl. Als normale forwarding in een efficient pad door de cpu loopt, dan ook de acl check.) .
09/04/13, 16:03
Stewie

Visser, ik denk dat Wido vooral doelde op de RX en dat is dan ook een oudere architectuur.
09/04/13, 17:18
visser

Citaat:

Oorspronkelijk geplaatst door Stewie

Visser, ik denk dat Wido vooral doelde op de RX en dat is dan ook een oudere architectuur.

Volgens deze link (BigIron RX series packet flow) gaat een IP acl match nog in hardware :
http://www.brocade.com/downloads/doc.../IP.09.03.html

Ik vraag (oa) even door omdat ik niet wil dit het beeld "acl gaat in software" algemeen / onterecht blijft hangen en dan een reden zou zijn om maar weer niks te doen "totdat we nieuwe routers hebben" of "dat moet mijn transit maar doen" .
(Niet specifiek Wido, maar er zijn meer lezers).
09/04/13, 20:05
Tim.Bracquez

Laatste tijd erg met DDOS aanvallen (hier ook), vaak gewoon om concurrentie uit te schakelen. Dan krijgt klant zo'n mailtje: http://pastebin.com/h3tcpxyz
10/04/13, 08:22
PimEffting

Ik heb zeer weinig begrip voor de personen die zoiets doen, het is 't digitale equivalent van een bushokje slopen.
Vorige week hebben wij helaas ook een ddos aanval gehad - vele gigabits inkomend verkeer.

Met honderden bronnen gecombineerd met meerdere bestemmingen binnen je netwerk kun je helaas niet zoveel doen.
Als je verbindingen vol zijn kan geen enkele firewall of ddos mitigation apparaat je meer helpen.
10/04/13, 11:08
Wido

Citaat:

Oorspronkelijk geplaatst door visser

Volgens deze link (BigIron RX series packet flow) gaat een IP acl match nog in hardware :
http://www.brocade.com/downloads/doc.../IP.09.03.html

Ik vraag (oa) even door omdat ik niet wil dit het beeld "acl gaat in software" algemeen / onterecht blijft hangen en dan een reden zou zijn om maar weer niks te doen "totdat we nieuwe routers hebben" of "dat moet mijn transit maar doen" .
(Niet specifiek Wido, maar er zijn meer lezers).

Wellicht dat ik het dan toch verkeerd heb. Ik begreep idd dat de RX-serie van Brocade dit via de CPU deed of dat je sowieso inlevert op je PPS als je met ACL's aan de slag gaat.

Op onze RX'en hebben wij het nu niet aan staan, maar binnenkort gaat de CER het edge (BGP) werk overnemen en mogen die de outbound filtering op zich nemen.

Citaat:

Oorspronkelijk geplaatst door Tim.Bracquez

Laatste tijd erg met DDOS aanvallen (hier ook), vaak gewoon om concurrentie uit te schakelen. Dan krijgt klant zo'n mailtje: http://pastebin.com/h3tcpxyz

Dan ben je toch wel héél triest hoor

Zo'n persoon moet ik niet tegen komen in een donker steegje...
10/04/13, 15:55
Pantsy

Citaat:

Oorspronkelijk geplaatst door Wido

Zo'n persoon moet ik niet tegen komen in een donker steegje...

/sarcasm Gebeurd er dan hetzelfde als met Thor? :p

Toon 40 bericht(en) van dit onderwerp op één pagina