Hoi, Wat heb ik aan ORF als: a. mijn IP upstreams het niet ondersteunen b. ik tcpsyn en udpfloods krijg met gespoofte source adressen ? Ik zie het niet zo zitten dus als oplossing voor DDoS. -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________
Hoi,
Wat heb ik aan ORF als: a. mijn IP upstreams het niet ondersteunen
Duh. Niets.
b. ik tcpsyn en udpfloods krijg met gespoofte source adressen ?
DDos verkeer van bepaalde source reeksen zo vroeg mogelijk (en een efficiente manier om de gewenste reeksen te communiceren) droppen is altijd nuttig, of het verkeer nou wel of niet gespoofed is. In je eigen netwerk is dat dus bij de borders, en daarbuiten bij de upstream waarover het binnenkomt. Dat je bij gespoofed verkeer dan nog niet weet wat de werkelijke bronnen zijn is jammer, maar in elk geval verminder je wel de problemen binnen jouw netwerk.
Ik zie het niet zo zitten dus als oplossing voor DDoS.
Ik zie het ook niet als -oplossing- voor DDos, maar het kan mi wel een stuk gereedschap worden om de overlast te beperken, en evt opsporing makkelijker te maken. Boudewijn
On Wed, 22 Oct 2003, Boudewijn Visser wrote:
DDos verkeer van bepaalde source reeksen zo vroeg mogelijk (en een efficiente manier om de gewenste reeksen te communiceren) droppen is altijd nuttig, of het verkeer nou wel of niet gespoofed is.
In je eigen netwerk is dat dus bij de borders, en daarbuiten bij de upstream waarover het binnenkomt.
Begrijp ik hieruit dat je hiermee kunt gaan sturen wat anderen aan filteren aan source adressen ook al zijn die adressen niet van hun? Da's introduceert weer een nieuw DoS risico, dan ga je gewoon een willekeurige host DoS-en met als een van de soruce adressen de host die je eigenlijk wilt DoS-en. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Wed, 22 Oct 2003, Boudewijn Visser wrote:
DDos verkeer van bepaalde source reeksen zo vroeg mogelijk (en een efficiente manier om de gewenste reeksen te communiceren) droppen is altijd nuttig, of het verkeer nou wel of niet gespoofed is.
In je eigen netwerk is dat dus bij de borders, en daarbuiten bij de upstream waarover het binnenkomt.
Begrijp ik hieruit dat je hiermee kunt gaan sturen wat anderen aan filteren aan source adressen ook al zijn die adressen niet van hun?
Zie de followup die ik net aan Jeroen+list gemaild heb, waarin ik dat probleem wat meer bespreek. (summary : ik zie er geen echte oplossing voor) Ik zie (helaas) geen manier om, afgezien van pure access-lists, verkeer uit bepaalde source reeksen *en* gericht aan een bepaalde destination te droppen. Een groep netwerken bij elkaar de mogelijkheid geven om verkeer van bepaalde source reeksen te droppen vergt, op z'n zachts gezegd, nogal wat vertrouwen.
Da's introduceert weer een nieuw DoS risico, dan ga je gewoon een willekeurige host DoS-en met als een van de soruce adressen de host die je eigenlijk wilt DoS-en.
Spoofing uitroeien is ook helemaal geen gek idee ;-) Maar zelfs zonder spoofing is het een enorm blik met wormen. [ietwat terugkomend op mijn bovenstaande quote, weinig upstreams zullen hun klanten [of peers] automatisch de mogelijkheid willen geven om verkeer op basis van source adres te droppen, zelfs alleen op hun border router.] Een efficiente manier om ook source filters in je eigen netwerk aan te zetten blijft natuurlijk een nuttige tool. Is het verkeer gespoofed, dan zou de upstream waarvan je het binnenkrijgt er wat aan moeten (en kunnen) doen, ook al is het niet volautomatisch. Boudewijn
On Wed, 22 Oct 2003, Boudewijn Visser wrote:
Een groep netwerken bij elkaar de mogelijkheid geven om verkeer van bepaalde source reeksen te droppen vergt, op z'n zachts gezegd, nogal wat vertrouwen.
Waarvan ik je op voorhand al kan vertellen dat dat dus niet gaat werken. En niet eens alleen om die reden.
Spoofing uitroeien is ook helemaal geen gek idee ;-) Maar zelfs zonder spoofing is het een enorm blik met wormen.
Tjek. Je zou het zo moeten doen dat je filters kan plaatsen in andere netwerken waarvan je het source en destination address van de te droppen packets kunt opgeven mits het destination address binnen het ASN van de aanvrager van zo'n filter valt. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Wed, 22 Oct 2003, Boudewijn Visser wrote: [..]
Spoofing uitroeien is ook helemaal geen gek idee ;-) Maar zelfs zonder spoofing is het een enorm blik met wormen.
Tjek.
Je zou het zo moeten doen dat je filters kan plaatsen in andere netwerken waarvan je het source en destination address van de te droppen packets kunt opgeven mits het destination address binnen het ASN van de aanvrager van zo'n filter valt.
Ja, ik droom ook wel eens van de goede netwerk fee ;-) Boudewijn
On Wed, Oct 22, 2003 at 12:34:07PM +0200, Boudewijn Visser wrote:
DDos verkeer van bepaalde source reeksen zo vroeg mogelijk (en een efficiente manier om de gewenste reeksen te communiceren) droppen is altijd nuttig, of het verkeer nou wel of niet gespoofed is.
In je eigen netwerk is dat dus bij de borders, en daarbuiten bij de upstream waarover het binnenkomt. Dat je bij gespoofed verkeer dan nog niet weet wat de werkelijke bronnen zijn is jammer, maar in elk geval verminder je wel de problemen binnen jouw netwerk.
Bezwaar tegen het blackholen van 80.126.198.1/32 aangezien ik denk dat ik weleens een gespoofed pakketje heb gezien van die host. Adressen blocken die mogelijk gespoofed zijn moet je doen op je access netwerk en niet in transit IMHO. MarcoH
On Wed, Oct 22, 2003 at 12:34:07PM +0200, Boudewijn Visser wrote:
DDos verkeer van bepaalde source reeksen zo vroeg mogelijk (en een efficiente manier om de gewenste reeksen te communiceren) droppen is altijd nuttig, of het verkeer nou wel of niet gespoofed is.
In je eigen netwerk is dat dus bij de borders, en daarbuiten bij de upstream waarover het binnenkomt. Dat je bij gespoofed verkeer dan nog niet weet wat de werkelijke bronnen zijn is jammer, maar in elk geval verminder je wel de problemen binnen jouw netwerk.
Bezwaar tegen het blackholen van 80.126.198.1/32 aangezien ik denk dat ik weleens een gespoofed pakketje heb gezien van die host.
Mis ik dan wat in je netwerk ;-) ?
Adressen blocken die mogelijk gespoofed zijn moet je doen op je access netwerk en niet in transit IMHO.
Uhm, er lopen nu een paar dingen door elkaar misschien ? [access als in klant aansluitingen, of als in access-circuit naar upstream?] Spoofing vanuit je netwerk onmogelijk maken doe je zo dicht mogelijk bij de klant/bron. Mee eens. Maar verkeer wat binnenkomt in te groot volume, gespoofed of niet, wil je ook zo vroeg mogelijk droppen. En dan is het op jouw border, en daarna die van je upstream of peer. En dan verder uitzoeken (door upstream, peer) waar het *werkelijk* vandaan kwam. Als jij 2 Gig verkeer met source adres 80.126.198.1 aangeboden krijgt (dat *moet* gespoofed zijn, zo'n luxe verbinding heb ik niet) zul je dat in eerste instantie op jouw border router droppen, en daarna de juiste upstream(s)bellen om dat te stoppen. (en de bron(nen) te traceren, hopelijk). Maar hoe dan ook wil je het weg van je lijnen. En ja, in zo'n geval is het jammer voor mij, maar feitelijk is er weinig keus, als je netwerk er helemaal vol zit. Boudewijn
On Wed, Oct 22, 2003 at 03:22:44PM +0200, Boudewijn Visser wrote:
Mis ik dan wat in je netwerk ;-) ?
Adressen blocken die mogelijk gespoofed zijn moet je doen op je access netwerk en niet in transit IMHO.
Uhm, er lopen nu een paar dingen door elkaar misschien ? [access als in klant aansluitingen, of als in access-circuit naar upstream?]
Spoofing vanuit je netwerk onmogelijk maken doe je zo dicht mogelijk bij de klant/bron. Mee eens.
Maar verkeer wat binnenkomt in te groot volume, gespoofed of niet, wil je ook zo vroeg mogelijk droppen. En dan is het op jouw border, en daarna die van je upstream of peer. En dan verder uitzoeken (door upstream, peer) waar het *werkelijk* vandaan kwam.
Als jij 2 Gig verkeer met source adres 80.126.198.1 aangeboden krijgt (dat *moet* gespoofed zijn, zo'n luxe verbinding heb ik niet) zul je dat in eerste instantie op jouw border router droppen, en daarna de juiste upstream(s)bellen om dat te stoppen. (en de bron(nen) te traceren, hopelijk). Maar hoe dan ook wil je het weg van je lijnen.
En ja, in zo'n geval is het jammer voor mij, maar feitelijk is er weinig keus, als je netwerk er helemaal vol zit.
Dan nog moet je IMHO het target richting /dev/null zetten, die is toch al down. Zodra je mogelijk gespoofde sources gaat blackholen heb je kans dat die script kiddies 2 vliegen in 1 klap slaan, en de target gaat onderuit en een onschuldig netwerk wordt aan alle kanten richting /dev/null gerouteerd en gaat dus ook plat. MarcoH
On Wed, 22 Oct 2003, MarcoH wrote:
Dan nog moet je IMHO het target richting /dev/null zetten, die is toch al down. Zodra je mogelijk gespoofde sources gaat blackholen heb je kans dat die script kiddies 2 vliegen in 1 klap slaan, en de target gaat onderuit en een onschuldig netwerk wordt aan alle kanten richting /dev/null gerouteerd en gaat dus ook plat.
Daarom zou je ook in andere netwerken moeten kunnen filteren op source EN destination. Alleen packets van <x> naar <y> droppen dus. FYI: De dozen bij ons die de laatste tijd gedossed zijn (IRC servers) zijn niet down geweest. Wel onbereikbaar via transit, omdat daar de attacks vandaan kwamen. Als je gaat filteren op alleen source of alleen destination, geef je de DoS kiddies hun zin. In het ene geval wordt het source adres effectief gedossed, in het andere geval de destination. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Wed, Oct 22, 2003 at 03:22:44PM +0200, Boudewijn Visser wrote:
[knip spoofing, filteren aan de ontvangende kant van een DDos] Zie ook wat Alex schreef.
Dan nog moet je IMHO het target richting /dev/null zetten, die is toch al down. Zodra je mogelijk gespoofde sources gaat blackholen heb je kans dat die script kiddies 2 vliegen in 1 klap slaan, en de target gaat onderuit en een onschuldig netwerk wordt aan alle kanten richting /dev/null gerouteerd en gaat dus ook plat.
Ook als dat target, zeg,je DNS servers zijn, of je pop server ? In het ideale geval wil je filteren op source en destination combinatie. Dat kan natuurlijk, maar alleen door access-lists te gebruiken. Jammer genoeg zijn de filters die je , vanaf 1 punt door je hele netwerk kunt distribueren via BGP (en eventueel naar een ander AS) op alleen source of alleen destination gebaseerd. En een (door jou) BGP getriggerd filter bij een ander AS zal op z'n best dus alleen een destination filter zijn. Wil je meer, dan moet je bellen/mailen e.d. Wat betreft het 'aan alle kanten' deel, ik heb hier (impliciet misschien) vooral de situatie tussen victim AS en het AS van waaruit de victim de stroom verkeer ontvangt in gedachten gehad. Schalen naar wereldwijd vergt echt een hoop wensen aan de goede netwerk fee. Boudewijn
On Wed, 22 Oct 2003, Boudewijn Visser wrote:
Zie ook wat Alex schreef.
Dan nog moet je IMHO het target richting /dev/null zetten, die is toch al down. Zodra je mogelijk gespoofde sources gaat blackholen heb je kans dat die script kiddies 2 vliegen in 1 klap slaan, en de target gaat onderuit en een onschuldig netwerk wordt aan alle kanten richting /dev/null gerouteerd en gaat dus ook plat.
Dat heb ik niet geschreven hoor..
Ook als dat target, zeg,je DNS servers zijn, of je pop server ?
Als je POP server van buiten je netwerk niet bereikbaar is, is dat jammer. De meeste requests zullen toch vanuit je eigen netwerk komen. En voor DNS geldt natuurlijk dat je als ISP die zijn taak serieus neemt minimaal 1 DNS server bij een collega ISP hebt hangen. Zo hebben Vuurwerk en WideXS allebei een fallback mail/dns server bij ons, en wij bij hun.
In het ideale geval wil je filteren op source en destination combinatie. Dat kan natuurlijk, maar alleen door access-lists te gebruiken.
Als je een Cisco hebt :)
Jammer genoeg zijn de filters die je , vanaf 1 punt door je hele netwerk kunt distribueren via BGP (en eventueel naar een ander AS) op alleen source of alleen destination gebaseerd. En een (door jou) BGP getriggerd filter bij een ander AS zal op z'n best dus alleen een destination filter zijn. Wil je meer, dan moet je bellen/mailen e.d.
Yep, of je moet iets om je junipers heen knutselen. Dat kan met XML. Dat zie ik niet echt gebeuren, dus laten we ons GSM abonnement nog maar even niet opzeggen :) -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Wed, 22 Oct 2003, Boudewijn Visser wrote:
Zie ook wat Alex schreef.
Dan nog moet je IMHO het target richting /dev/null zetten, die is toch al down. Zodra je mogelijk gespoofde sources gaat blackholen heb je kans dat die script kiddies 2 vliegen in 1 klap slaan, en de target gaat onderuit en een onschuldig netwerk wordt aan alle kanten richting /dev/null gerouteerd en gaat dus ook plat.
Dat heb ik niet geschreven hoor..
Klopt. Ik bedoelde het niet als quote, maar als 'lees ook wat Alex over het onderwerp schreef' punt. En daarna schreef ik zelf weer verder.
Ook als dat target, zeg,je DNS servers zijn, of je pop server ?
Als je POP server van buiten je netwerk niet bereikbaar is, is dat jammer. De meeste requests zullen toch vanuit je eigen netwerk komen.
Ja, als je er tenminste in slaagt om 't ding binnen je netwerk bereikbaar te houden ;-) [zie het de eerste mails in de thread... ]
En voor DNS geldt natuurlijk dat je als ISP die zijn taak serieus neemt minimaal 1 DNS server bij een collega ISP hebt hangen. Zo hebben Vuurwerk en WideXS allebei een fallback mail/dns server bij ons, en wij bij hun.
Ok, voor DNS kun je dat nog doen ja, zolang je concullega's ook grote verbindingen hebben en eventueel bereid blijven forse dDOSen uit te zitten. Punt blijft (in antwoord op Marco's destination nullrouten) dat je als ISP een aantal destinations zeker niet ge-nullroute wilt, omdat dat evenzeer een DoS is als de flood.
In het ideale geval wil je filteren op source en destination combinatie. Dat kan natuurlijk, maar alleen door access-lists te gebruiken.
Als je een Cisco hebt :)
Nu ja, heb je iets anders dan heet het anders, maar het blijft het verschil tussen een packet filter en nullrouten, eventueel gecombineerd met uRPF.
Jammer genoeg zijn de filters die je , vanaf 1 punt door je hele netwerk kunt distribueren via BGP (en eventueel naar een ander AS) op alleen source of alleen destination gebaseerd. En een (door jou) BGP getriggerd filter bij een ander AS zal op z'n best dus alleen een destination filter zijn. Wil je meer, dan moet je bellen/mailen e.d.
Yep, of je moet iets om je junipers heen knutselen. Dat kan met XML.
Nu ja, in principe kun je met een website, SSL, en 'een paar' scripten iedereen je wilt prima geauthenticeerd zoveel of zo weinig packet filters in je routers laten zetten als je ze toestaat.
Dat zie ik niet echt gebeuren, dus laten we ons GSM abonnement nog maar even niet opzeggen :)
Nope. De telco/circuit switched types hebben een paar dingen echt wel goed door. Boudewijn
participants (4)
-
alex＠bit.nl -
bvisser-nlnog＠xs4all.nl -
marcoh＠marcoh.net -
pim＠bit.nl