-----Original Message----- From: Alex Bik [mailto:alex at bit.nl]
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.
Over vertrouwen gesproken .. Al zie ik wel een voordeel .. in sommige routers zou ik met veel plezier onze prefix's op een block zetten. Met vriendelijke groeten, Erik Bais -------- I S - I N T E R N E D - S E R V I C E S - B V -------- domeinregistratie - webhosting - colocating - dedicated servers www.is.nl - info at is.nl - T: 0299-476185 Gorslaan 18 - 1441 RG - Purmerend ---------------------------------------------------------------
On Wed, 22 Oct 2003, Erik Bais wrote:
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.
Over vertrouwen gesproken ..
Hoezo? Je kunt daar hooguit je eigen netwerk mee slopen. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
From: Alex Bik [mailto:alex at bit.nl] 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.
On Wed, 22 Oct 2003, Erik Bais wrote:
Over vertrouwen gesproken ..
On woensdag, okt 22, 2003, at 15:26 Europe/Amsterdam, Alex Bik wrote:
Hoezo? Je kunt daar hooguit je eigen netwerk mee slopen.
Zie jij operators op korte termijn meer filtering op source prefix toepassen dan nu het geval is? -- Niels. --
On Wed, 22 Oct 2003, Niels Bakker wrote:
Zie jij operators op korte termijn meer filtering op source prefix toepassen dan nu het geval is?
Ja. Misschien is het tijd voor een AMS-IX filtering awareness day :) -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Wed, Oct 22, 2003 at 04:04:34PM +0200, Alex Bik wrote:
On Wed, 22 Oct 2003, Niels Bakker wrote:
Zie jij operators op korte termijn meer filtering op source prefix toepassen dan nu het geval is?
Ja. Misschien is het tijd voor een AMS-IX filtering awareness day :)
Volgende EOF ? Inclusief praktijk sessie waar we even de sukkel die kazaa oid op heeft gestart op het meeting LAN uitleggen hoe effectief filteren werkt. MarcoH
On Wed, 22 Oct 2003, MarcoH wrote:
Volgende EOF ? Inclusief praktijk sessie waar we even de sukkel die kazaa oid op heeft gestart op het meeting LAN uitleggen hoe effectief filteren werkt.
Dat hebben ze denk ik op de laatste RIPE meeting wel gemerkt toen ik Monica demonstreerde hoe ze met behulp van de Packet Shaper die ik had meegenomen heel effectief edonkey,kazaa,napster en gnutella kon fileteren :) -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
-----BEGIN PGP SIGNED MESSAGE----- Alex Bik wrote:
On Wed, 22 Oct 2003, MarcoH wrote:
Volgende EOF ? Inclusief praktijk sessie waar we even de sukkel die kazaa oid op heeft gestart op het meeting LAN uitleggen hoe effectief filteren werkt.
Dat hebben ze denk ik op de laatste RIPE meeting wel gemerkt toen ik Monica demonstreerde hoe ze met behulp van de Packet Shaper die ik had meegenomen heel effectief edonkey,kazaa,napster en gnutella kon fileteren :)
Je gaat toch niet zeggen dat mensen die toch wel een redelijke netwerkverbinding zouden moeten hebben @ work en waarschijnlijk ook thuis zelfs dat ene weekje nog moeten zuigen van die dingen toch? En idd die Packet Shaper werkte heel fijn :) Alex Bik wrote:
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.
Met ORF kan je dus een filter definieren met source en destination. Het is allemaal helaas nog draft, maar het komt wel.
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.
Dat was idd geen slechte beslissing om dat toen te doen idd. Zowiezo kost het je anders veel knaken en nu is bereikbaarheid van je lokale klanten 'gegarandeert'. Hopelijk krijgen ze geen andere rare ideeen though. Niels bakker wrote:
On woensdag, okt 22, 2003, at 15:26 Europe/Amsterdam, Alex Bik wrote:
Hoezo? Je kunt daar hooguit je eigen netwerk mee slopen.
Zie jij operators op korte termijn meer filtering op source prefix toepassen dan nu het geval is?
IMHO, maar ik ben geen ISP ofzo en weet ook niet of dat gedaan wordt, zou het iig niet verkeerd zijn als je met je peers en zeker je transit goed contact heb en een systeem om bepaalde prefixen te kunnen blackholen. Dat is namelijk ook effectief wat BIT doet met die PI space doet alleen per BGP en totaal niet meer te vinden upstream. De blackholes per BGP (secsup url) Boudewijn Visser wrote:
(overigens, ook zonder spoofing ,of met spoofing binnen dezelfde netwerk range, kunnen natuurlijk heel grote DDos'en gedaan worden. Ze zijn dan alleen makkelijker te traceren )
Zoals bijv van die schattige IPv6 tunnelbrokers die gewoon alles maar doorlaten. Leuke anonieme source dus... Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP5a3JSmqKFIzPnwjEQJtMQCcDCjT3sBaHUgH1CvQA6Kx2cHuJjsAnA49 fvveiXXjckufDSraTYm9zgMl =Ae1q -----END PGP SIGNATURE-----
On Wed, 22 Oct 2003, Jeroen Massar wrote:
Je gaat toch niet zeggen dat mensen die toch wel een redelijke netwerkverbinding zouden moeten hebben @ work en waarschijnlijk ook thuis zelfs dat ene weekje nog moeten zuigen van die dingen toch?
Ik ben bang van wel..
Daarom zou je ook in andere netwerken moeten kunnen filteren op source EN destination. Alleen packets van <x> naar <y> droppen dus.
Met ORF kan je dus een filter definieren met source en destination. Het is allemaal helaas nog draft, maar het komt wel.
Dan nog heb je een probleem, want er wordt steeds vaker niet een adres gekozen wat vervolgens als src gebruikt wordt, maar voor elk packet een ander adres. Dan ga je dus het hele Internet filteren, dat schiet ook niet op.
Dat was idd geen slechte beslissing om dat toen te doen idd. Zowiezo kost het je anders veel knaken en nu is bereikbaarheid van je lokale klanten 'gegarandeert'. Hopelijk krijgen ze geen andere rare ideeen though.
Onze klanten hebben er sowieso geen last van gehad, ook niet voor transit. De IRC servers zitten in een andere prefix dan onze klanten. Overigens hebben we net weer een DoS attack je gehad. Beetje laf, 26mbit/68kpps. In de eerste minuut tenminste, daarnaa is het nog een beetje gestegen, naar zo'n 50mbit. Toen na een half uur DoSsen de doos nog niet van het Internet aflazerde was de lol er blijkbaar af en hield het weer op. Alleen via Level3 dit keer: http://noc.bit.nl/traffic/uplink/level3.html -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Wed, 22 Oct 2003, Alex Bik wrote:
Onze klanten hebben er sowieso geen last van gehad, ook niet voor transit. De IRC servers zitten in een andere prefix dan onze klanten.
Als je transit(s) vol zit(ten), hebben je klanten daar ook last van. Ookal zit die irc doos in een andere prefix. -- /- Met vriendelijke groet/With kind regards, -\ <- Peter Batenburg - ProServe B.V. - www.proserve.nl -> \- tel: +31-184-423815 - fax: +31-184-417160 -/
Hi!
Onze klanten hebben er sowieso geen last van gehad, ook niet voor transit. De IRC servers zitten in een andere prefix dan onze klanten.
Als je transit(s) vol zit(ten), hebben je klanten daar ook last van. Ookal zit die irc doos in een andere prefix.
Als je die niet exporteert naar je transits dan zie ik geen probleem. Bye, Raymond.
On Wed, 22 Oct 2003, Raymond Dijkxhoorn wrote:
Onze klanten hebben er sowieso geen last van gehad, ook niet voor transit. De IRC servers zitten in een andere prefix dan onze klanten. Als je transit(s) vol zit(ten), hebben je klanten daar ook last van. Ookal zit die irc doos in een andere prefix. Als je die niet exporteert naar je transits dan zie ik geen probleem.
Zover ik weet doen ze dit wel. Dus totdat je de announcement naar de transits er uit knalt, hebben je klanten er last van. -- /- Met vriendelijke groet/With kind regards, -\ <- Peter Batenburg - ProServe B.V. - www.proserve.nl -> \- tel: +31-184-423815 - fax: +31-184-417160 -/
Hi, | > > Als je transit(s) vol zit(ten), hebben je klanten daar ook last van. Ookal | > > zit die irc doos in een andere prefix. | > Als je die niet exporteert naar je transits dan zie ik geen probleem. | | Zover ik weet doen ze dit wel. Dus totdat je de announcement naar de | transits er uit knalt, hebben je klanten er last van. Kunnen je klanten er last van hebben. Het komt nagenoeg nooit voor dat een verbinding satureert. Als dit wel het geval is wordt er binnen 1800 seconden actie ondernomen om het verkeer weg te krijgen. Dat geddos is altijd vervelend natuurlijk en het kan zijn dat er verkeer komt waar onze klanten last van hebben. Last betekent dan 'vertraging' en enkel ingaand. Onze klanten douwen over 't algemeen uitgaand verkeer dus vooralsnog is die PI truc prima afdoend. -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________
On Wed, 22 Oct 2003, Pim van Pelt wrote:
| Zover ik weet doen ze dit wel. Dus totdat je de announcement naar de | transits er uit knalt, hebben je klanten er last van. Kunnen je klanten er last van hebben. Het komt nagenoeg nooit voor dat een verbinding satureert. Als dit wel het geval is wordt er binnen 1800 seconden actie ondernomen om het verkeer weg te krijgen. Dat geddos is altijd vervelend natuurlijk en het kan zijn dat er verkeer komt waar onze klanten last van hebben. Last betekent dan 'vertraging' en enkel ingaand. Onze klanten douwen over 't algemeen uitgaand verkeer dus vooralsnog is die PI truc prima afdoend.
Misschien gaan we nu een beetje te OT en ik bedoel het helemaal niet aanvallend, maar waarom hosten jullie die (DDoS gevoelige) irc services nog eigenlijk? Kijk, ik kan begrijpen dat je undernet o.i.d. een warm hart toe draagt, maar weegt dit op tegen alle narigheid die je er van hebt, vooral ook tegenover je klanten? -- /- Met vriendelijke groet/With kind regards, -\ <- Peter Batenburg - ProServe B.V. - www.proserve.nl -> \- tel: +31-184-423815 - fax: +31-184-417160 -/
On Wed, 22 Oct 2003, ProServe - Peter Batenburg wrote:
Misschien gaan we nu een beetje te OT en ik bedoel het helemaal niet aanvallend, maar waarom hosten jullie die (DDoS gevoelige) irc services nog eigenlijk? Kijk, ik kan begrijpen dat je undernet o.i.d. een warm hart toe draagt, maar weegt dit op tegen alle narigheid die je er van hebt, vooral ook tegenover je klanten?
IRC hoort bij het Internet. Het zou jammer zijn als het zou verdwijnen omdat de bakken af en toe een DDoS voor hun kiezen krijgen. De machines komen voor een deel bij ISP's vandaan die ze hebben laten vallen als een baksteen omdat ze de DoS attacks te vervelend vonden en omdat de dozen geen geld opleveren. Gelukkig draait bij ons niet alles om geld. Anyway, aan de andere kant hebben we natuurlijk een verantwoordelijkheid naar onze klanten en hebben we een goede naam hoog te houden. We hebben dat opgelost door de dozen in een aparte prefix te stoppen (twee eigenlijk) zodat we de announcements kunnen intrekken als het te gortig wordt. Klanten hebben daar eigenlijk nooit last van, we hebben drie transitboeren. De backhaul vanaf AMS-IX naar Ede zijn twee paar dark fibers. Daar kan wel wat verkeer doorheen. Tot nu toe zijn de beslissingen om de announcements naar transitboeren in te trekken dan ook vooral commercieel van aard geweest; het past vaak wel door de pijpen, maar je krijgt wel een rekening van je transitboer(en). Verder zijn we natuurlijk bijzonder eigenwijs. Dus hoe harder de kiddies proberen te DoSsen, hoe harder wij ons best gaan doen om ze de vinger te geven. De DoS van vanavond hield na een half uurtje ook vanzelf op toen het niet bleek te lukken. Maar: Het blijft vervelend natuurlijk. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Wed, 22 Oct 2003, Alex Bik wrote:
On Wed, 22 Oct 2003, ProServe - Peter Batenburg wrote:
Misschien gaan we nu een beetje te OT en ik bedoel het helemaal niet aanvallend, maar waarom hosten jullie die (DDoS gevoelige) irc services nog eigenlijk? Kijk, ik kan begrijpen dat je undernet o.i.d. een warm hart toe draagt, maar weegt dit op tegen alle narigheid die je er van hebt, vooral ook tegenover je klanten?
IRC hoort bij het Internet. Het zou jammer zijn als het zou verdwijnen omdat de bakken af en toe een DDoS voor hun kiezen krijgen. De machines komen voor een deel bij ISP's vandaan die ze hebben laten vallen als een baksteen omdat ze de DoS attacks te vervelend vonden en omdat de dozen geen geld opleveren. Gelukkig draait bij ons niet alles om geld.
Ging vooral om een netwerk afdeling met cisco's die tegen een beheer afdeling van hetzelfde bedrijf meldt dat er geen filters worden gezet want "dat doen we niet voor klanten", meer grote bedrijven politiek dan geld dus. En na een paar maanden van dat geneuzel dan geef je het maar op als beheerder. -- Sten Spans There is a crack in everything that's how the light gets in.
On Sun, 26 Oct 2003, Sten wrote:
Ging vooral om een netwerk afdeling met cisco's die tegen een beheer afdeling van hetzelfde bedrijf meldt dat er geen filters worden gezet want "dat doen we niet voor klanten", meer grote bedrijven politiek dan geld dus. En na een paar maanden van dat geneuzel dan geef je het maar op als beheerder.
Tja, als je Cisco's gebruikt kan ik me voorstellen dat je niet te veel wilt filteren :) -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
Hi Alex,
Ging vooral om een netwerk afdeling met cisco's die tegen een beheer afdeling van hetzelfde bedrijf meldt dat er geen filters worden gezet want "dat doen we niet voor klanten", meer grote bedrijven politiek dan geld dus. En na een paar maanden van dat geneuzel dan geef je het maar op als beheerder.
Tja, als je Cisco's gebruikt kan ik me voorstellen dat je niet te veel wilt filteren :)
Op TUD filteren we vrij veel, verkeer is maar 400-500 mbit ofzo, maar op zich trekken die Ciscos zich daar niet zoveel van aan (6509's). Bye, Raymond.
On Sun, 26 Oct 2003, Raymond Dijkxhoorn wrote:
Op TUD filteren we vrij veel, verkeer is maar 400-500 mbit ofzo, maar op zich trekken die Ciscos zich daar niet zoveel van aan (6509's).
Hadden ze bij Vuurwerk geen 7200-tje?' Is dat trouwens wat, zo'n 6500 met layer 3 shit? -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
Hi!
Op TUD filteren we vrij veel, verkeer is maar 400-500 mbit ofzo, maar op zich trekken die Ciscos zich daar niet zoveel van aan (6509's).
Hadden ze bij Vuurwerk geen 7200-tje?' Is dat trouwens wat, zo'n 6500 met layer 3 shit?
De engine is vergelijkbaar met een 7500, best ok op zich. We zijn nu bezig met een early field test, met de firewalling blades. Virtual firewalling meuk, op zich bevalt het goed. Bye, Raymond.
On Sun, 26 Oct 2003, Raymond Dijkxhoorn wrote:
De engine is vergelijkbaar met een 7500, best ok op zich. We zijn nu bezig met een early field test, met de firewalling blades. Virtual firewalling meuk, op zich bevalt het goed.
Daar hoorde ik laatst wat over ja (die blades). We doen dit jaar weer de connectivity op de HCC beurs, daar komt ook wat van die zooi te staan (wij doen de uplink, de HCC heeft bij Cisco een pallet hardwware geregeld). -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
Hoi!
De engine is vergelijkbaar met een 7500, best ok op zich. We zijn nu bezig met een early field test, met de firewalling blades. Virtual firewalling meuk, op zich bevalt het goed. Daar hoorde ik laatst wat over ja (die blades). We doen dit jaar weer de
Enige nadeel van de firewall blade is dat je in combinatie met de MSFC-2 ('de router') in sommige gevallen je verkeer met policy routes moet forceren door je firewall blade. Op zich geen probleem, ware het niet dat een typo in 1x je netwerk bloot legt; iets wat bij een box-in-the-middle minder makkelijk fout gaat. Ik ben overigens benieuwd at de oude catalyst 'ik heb het druk dus forward ik naar alles' problemen doen in combinatie met veel packets. I.e. untrust vlan aan de ene kant je 65xx in, door de MSFC-2 naar het firewall blade, hopla naar een dmz vlan. Bij een split-box oplossing sterft hooguit je firewall; je mag hopen dat de doos niet 'raar' gaat doen in de shared-box oplossing.. Greets, Nils Swart nils.swart at attorn.nl
Hi!
Ik ben overigens benieuwd at de oude catalyst 'ik heb het druk dus forward ik naar alles' problemen doen in combinatie met veel packets. I.e. untrust vlan aan de ene kant je 65xx in, door de MSFC-2 naar het firewall blade, hopla naar een dmz vlan. Bij een split-box oplossing sterft hooguit je firewall; je mag hopen dat de doos niet 'raar' gaat doen in de shared-box oplossing..
De routering van die meuk gaat plaat vinden op je firewalling blades. Althansm n de early field test. We wachten nog op een versie waar ook de PDM voor 'af' is, dan kunnen we er echt wat mee richting de endusers. Bye, Raymond.
On Sun, 26 Oct 2003, Raymond Dijkxhoorn wrote:
De engine is vergelijkbaar met een 7500, best ok op zich. We zijn nu bezig met een early field test, met de firewalling blades. Virtual firewalling meuk, op zich bevalt het goed.
Is dit de Arrowpoint geintegreerde fw/contentswitching blade? Tx, Said.
On Sun, 26 Oct 2003, Alex Bik wrote:
On Sun, 26 Oct 2003, Raymond Dijkxhoorn wrote:
Op TUD filteren we vrij veel, verkeer is maar 400-500 mbit ofzo, maar op zich trekken die Ciscos zich daar niet zoveel van aan (6509's).
Hadden ze bij Vuurwerk geen 7200-tje?'
hadden ja, het zijn al jaren 7513's. Het punt was meer dat we graag rate limits wilden hebben bij de netwerk entry points. Zodat iig de impact op het vuurwerk netwerk wat kleiner zou zijn. 7513's krijg je dood met 100mbit aan syn, een 10mbit limit voor die range zou erg veel problemen hebben opgelost. Maar er werd zo moeilijk gedaan dat er maar besloten is om de dozen te verhuizen. -- Sten Spans There is a crack in everything that's how the light gets in.
On Wed, 22 Oct 2003, ProServe - Peter Batenburg wrote:
Onze klanten hebben er sowieso geen last van gehad, ook niet voor transit. De IRC servers zitten in een andere prefix dan onze klanten.
Als je transit(s) vol zit(ten), hebben je klanten daar ook last van. Ookal zit die irc doos in een andere prefix.
Is dat zo? Bedankt voor de tip! Damn, hoe lossen we dat op... Ehm, even denken hoor.. Aparte prefix, transit, peering, bgp, communities... Zou het mogelijk zijn om z'n prefix in zo'n geval alleen naar je peers te announcen denk je? -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Wed, 22 Oct 2003, Alex Bik wrote:
Onze klanten hebben er sowieso geen last van gehad, ook niet voor transit. De IRC servers zitten in een andere prefix dan onze klanten. Als je transit(s) vol zit(ten), hebben je klanten daar ook last van. Ookal zit die irc doos in een andere prefix. Is dat zo? Bedankt voor de tip! Damn, hoe lossen we dat op... Ehm, even denken hoor.. Aparte prefix, transit, peering, bgp, communities... Zou het mogelijk zijn om z'n prefix in zo'n geval alleen naar je peers te announcen denk je?
Mja, zo bedoelde ik het helemaal niet. Pim gaf zelf aan dat als dit gebeurt er binnen 30 minuten wat aan gedaan wordt. Zijn IRC services het echt waard om een klant max. 30 minuten problemen te laten ondervinden? (en dat evt. meerdere keren per maand/week whatever) Nogmaals, dit is echt niet aanvallend bedoelt, ik vraag me gewoon af wat er achter zit. -- /- Met vriendelijke groet/With kind regards, -\ <- Peter Batenburg - ProServe B.V. - www.proserve.nl -> \- tel: +31-184-423815 - fax: +31-184-417160 -/
On Wed, 22 Oct 2003, ProServe - Peter Batenburg wrote:
Mja, zo bedoelde ik het helemaal niet. Pim gaf zelf aan dat als dit gebeurt er binnen 30 minuten wat aan gedaan wordt. Zijn IRC services het echt waard om een klant max. 30 minuten problemen te laten ondervinden?
Uiterlijk 30 min. Na 1 min worden Pim, Sabri en ik ge-sms-ed. Dat is het begin van de DoS, dan zijn de packet en traffic rates nog niet zo hoog. Dan kun je het in de gaten houden en kijken of het nodig is announcements in te trekken. Zie ook m'n vorige mail hierover, de beslissingen om dat te doen zijn tot nu toe vooral commercieel van aard geweest, we hebben natuurlijk geen zin om een dikke rekening van $transitboer te krijgen. Het netwerk trekt het meestal wel. Wat er achter zit: De ouderwetse opvatting dat het Internet een 'community' is waaraan eenieder wat bijdraagt (zo mirroren we ook vanalles) en natuurlijk pure eigenwijzigheid. Je laat je natuurlijk niet op je huid zitten door een stelltje van die kutblagen. Bring 'em on! -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
Hi, | Mja, zo bedoelde ik het helemaal niet. Pim gaf zelf aan dat als dit | gebeurt er binnen 30 minuten wat aan gedaan wordt. Zijn IRC services | het echt waard om een klant max. 30 minuten problemen te laten | ondervinden? (en dat evt. meerdere keren per maand/week whatever) | Nogmaals, dit is echt niet aanvallend bedoelt, ik vraag me gewoon af wat | er achter zit. Je zegt constant dat de klanten er problemen van ondervinden en dat is echt niet zo. Lang voordat het verkeer een niet-tolereerbare grens dreigt te overschreiden wordt er al ingegrepen. Al doen we dit dagelijks, niemand merkt het behalve wat prive spulletjes die ook in die PI space zitten. Ik heb nog nooit een klant horen klagen over de connectiviteit van en naar BIT. Onze IP uplinks hebben pre-defined filters (die wegens policy niet altijd aanwezig kunnen zijn), maar aan de hand van een ticketnummer kunnen we binnen 15 minuten upstream laten filteren. Ook kunnen we met communities de PI ranges opdoeken, zoals besproken. Dat is uiterst effectief en heeft eigenlijk maar weinig effect op nederlandse chatters, onze doelgroep. We hebben voldoende capaciteit om een dos uit te zingen, maar zoals Alex al zei is de BGP truc alleen maar een financieel lapmiddel, om de 95% cap voor te blijven. Verder kan ik deze thread gerust afsluiten met de melding dat wij (en in het bijzonder Sabri en ik) die IRC dozen als hobby onderhouden. We werken erg hard op de zaak en hebben voldoende vertrouwen in het netwerk om dit soort dingen te kunnen doen. IRC is een voorbeeld, maar DNSBL en een IPv6 tunnelbroker horen daar ook bij. Ik kan ook opmerken dat als er een dienst is die netwerk gezondheid mooi grafisch weergeeft, dan is het wel een IRC doos met 8000 users erop. Als er dan waar dan ook iets mis gaat zie je 't meteen aan die ircd. -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________
On Wed, Oct 22, 2003 at 08:57:44PM +0200, Pim van Pelt wrote: Hi,
Ik kan ook opmerken dat als er een dienst is die netwerk gezondheid mooi grafisch weergeeft, dan is het wel een IRC doos met 8000 users erop. Als er dan waar dan ook iets mis gaat zie je 't meteen aan die ircd.
Ik had het niet beter kunnen zeggen. Als er van die 8000 users opeens 3000 wegvallen, weet je dat er iets grondig stuk is. Het is om die reden dat ik in de tijd van m6-brakheid meerdere malen "first-post" had. -- Sabri Berisha "I route, therefore you are" "Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.
-----BEGIN PGP SIGNED MESSAGE----- Sabri Berisha wrote:
On Wed, Oct 22, 2003 at 08:57:44PM +0200, Pim van Pelt wrote:
Ik kan ook opmerken dat als er een dienst is die netwerk gezondheid mooi grafisch weergeeft, dan is het wel een IRC doos met 8000 users erop. Als er dan waar dan ook iets mis gaat zie je 't meteen aan die ircd.
Ik had het niet beter kunnen zeggen. Als er van die 8000 users opeens 3000 wegvallen, weet je dat er iets grondig stuk is. Het is om die reden dat ik in de tijd van m6-brakheid meerdere malen "first-post" had.
Alex.... kijk een nlborrel opportunity: Borrel ter bedanking van de Nederlandse Internet Vrijwilligers :) Aka de mensen die de public/non-commercial services staande en draaiende houden. Ik denk dat zeker Erik dat deze week wel hard nodig heeft. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP5bfRymqKFIzPnwjEQKKogCggQGYuMzfHjMwYVl8sSGVLvhCOwcAnAnB knuyOiBNIunn4dRZ7jfTlqGz =wkye -----END PGP SIGNATURE-----
[...]
Daarom zou je ook in andere netwerken moeten kunnen filteren op source EN destination. Alleen packets van <x> naar <y> droppen dus.
Met ORF kan je dus een filter definieren met source en destination. Het is allemaal helaas nog draft, maar het komt wel.
Uhm, kun je me een iets preciezere URL geven ('k ben lui..) , want dat stukje heb ik in de drafts dan nog even over het hoofd gezien. Ook heb ik in de ORF docs nog geen koppeling tussen *route* filter en *packet forwarding filter* gezien. Die maak je gewoonlijk door een nullroute (destination) dan wel met hulp van uRPF (source null route), maar ik zie niet hoe je via dat mechanisme een *combinatie* van source en destination maakt. Nu kun je natuurlijk wel BGP misbruiken als puur data transport voor een packet filter, maar ORF noch jullie draft extensie ervan bieden dat, voor zo ver ik heb gezien. [..]
Boudewijn Visser wrote:
(overigens, ook zonder spoofing ,of met spoofing binnen dezelfde netwerk range, kunnen natuurlijk heel grote DDos'en gedaan worden. Ze zijn dan alleen makkelijker te traceren )
Zoals bijv van die schattige IPv6 tunnelbrokers die gewoon alles maar doorlaten. Leuke anonieme source dus...
Qua bron van problemen totaal verwaarloosbaar tov gehackte/geinfecteerde IPv4 dozen. Boudewijn
participants (13)
-
alex＠bit.nl -
bvisser-nlnog＠xs4all.nl -
erik＠is.nl -
jeroen＠unfix.org -
marcoh＠marcoh.net -
niels.bakker＠ams-ix.net -
nils.swart＠attorn.nl -
peter＠proserve.nl -
pim＠bit.nl -
raymond＠prolocation.net -
sabri＠cluecentral.net -
said＠ouissal.net -
sten＠blinkenlights.nl