On Tue, Oct 21, 2003 at 05:28:07PM +0200, Arjan wrote:
On Tue, 21 Oct 2003 at 17:19 +0200, Raymond Dijkxhoorn wrote:
Zie veel packetloss richting het xs4all netwerk en ook sites en services doen niet veel.
Ik heb wel een announce gezien in xs4all.announce, last van attacks op de RBL servers ?
Gezien het feit dat de ircdoos helemaal pleitos is, al een tijdje (en de rest er nog wel) lijkt het me een attack op ircnet. En dat is weer niet geheel onvoorstelbaar...
We hebben de afgelopen dagen verschillende floods ontvangen, irc zat er vandaag niet bij ;-) Hoogste synflood rate die we gezien hebben was zo'n 1,3 miljoen pps. Door de laatste flood raakte een van de Juniper dozen in de stress waardoor er tussen 2 lokaties vanmiddag packetloss ontstond.
Misschien niet alleen vanmiddag; Op moment (tue 23.00) heeft de popserver problemen om NIS (en NFS?) te bereiken : fetchmail: POP3> PASS * fetchmail: POP3< yp_match: clnt_call: RPC: Timed out (en andere kuren : fetchmail: POP3< -ERR This user has no maildir. fetchmail: This user has no maildir. ) idem voor www.xs4all.nl, momenteel slecht bereikbaar. (vanaf xs4all DSL ) Hm, krijg de neiging om stuurman aan de wa^H^H^H consultant te gaan uithangen .... Boudewijn [is overigens ook serieus bereid om mee te denken over oplossingen & workarounds ]
-----BEGIN PGP SIGNED MESSAGE----- Boudewijn Visser wrote:
Erik Bos wrote:
We hebben de afgelopen dagen verschillende floods ontvangen, irc zat er vandaag niet bij ;-) Hoogste synflood rate die we gezien hebben was zo'n 1,3 miljoen pps. Door de laatste flood raakte een van de Juniper dozen in de stress waardoor er tussen 2 lokaties vanmiddag packetloss ontstond.
Wat een gekinder ook weer. Er moet echt iets aan gebeuren gewoon. Zie onderaan.
idem voor www.xs4all.nl, momenteel slecht bereikbaar.
Page opent nu (23:31) wel maar de graphics komen nouwelijks door vanaf mijn Cistron DSL.
Boudewijn
Ik krijg je mailtje voor de 3de keer nu al, ff een SMTP trappen denk ik dat die niet resend. Al gok ik dat dit ook door de beschreven probs komt.
[is overigens ook serieus bereid om mee te denken over oplossingen & workarounds ]
De nuttige content van mijn mailtje.... Ten eerste ben ik sinds kort op de hoogte dat Team Cymru een DDoS route server heeft waarvandaan ze dus per BGP een route announcen die je kan nullrouten, net als het Bogon Route Server systeem. Ze announcen niet de infected hosts, maar wel de control centers die over het algemeen op een compromised machine bevind. Als je hierover verdere info wilt neem contact met hun op en vertel ISP blabla en dan zullen ze je er verder denk ik wel vertellen hoe het steekt precies. De info is niet public want anders weten de kids natuurlijk dat ook weer aan te pakken. Team Cymru uit http://www.cymru.com/contact.html Daarnaast hebben ik in samenwerking met Rob Thomas (Cymru), Michel Py en William Leibzon van Completewhois, dat wat van de week op NANOG werd geannounced de volgende draft gesubmit voor de komende IETF: "Redistribution of Cooperative Filtering Information" http://arneill-py.sacramento.ca.us/draft-py-idr-redisfilter-00.txt Het is een voorgestelde ORF extensie die het mogelijk maakt om filters te reannouncen. Zo kan je bijv de BGP announcement al stoppen voordat je iets raakt. Het omgedraaide van de Bogon Route Servers dus. Ook heel handig voor DDoS filtering dus. We zouden dit systeem voor de AMS-IX op kunnen zetten zodat er iig filters komen tussen de partijen die we (ehm jullie) vertrouwen dat ze confidentieel omgaan met de info want als de kids weten hoe het steekt... pisang. Daarom zeg ik over het bovenstaande ook niet echt veel want dit wordt publicly archived. En hier in nederland zitten (!hoi!) genoeg kinderen zoals we zelf helaas maar al te goed weten en die snappen dit best. Ik denk, van mij perspectief gezien, dat we het op zich qua trust en samenwerking best goed doen in .nl, vooral als er bier in het geding komt. Wie stuurt Erik en Team overigens een kratje want die zal wel vet moeten overwerken hierdoor. Er staat 15 minutes op de agenda van de IDR WG, hopelijk wordt het aangenomen en wordt het, zoals bij ORF ging, snel geimplementeerd. Ciscos en Junipers snappen het over het algemeen al terwijl ORF nog in draft status is. Al ga ik er vanuit dat het wel even zou duren totdat het er in zit natuurlijk, maar we hebben hoop. Zo'n filter zou heel handig zijn, je kan dan iig ook op 1 plek een filter definieren en *flop* al je routers snappen hem. (u)RPF er bij et tada. Uitgebreide voorbeelden op aanvraag :) 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/AwUBP5WqJSmqKFIzPnwjEQJMwgCfdHP3nYHl4tpJrKDsQ5TDfSp76cgAoJ77 9NPf6aG+V2H23zaTzpNYp4M1 =zdUI -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Boudewijn Visser wrote:
[..]
idem voor www.xs4all.nl, momenteel slecht bereikbaar.
Page opent nu (23:31) wel maar de graphics komen nouwelijks door vanaf mijn Cistron DSL.
Boudewijn
Ik krijg je mailtje voor de 3de keer nu al, ff een SMTP trappen denk ik dat die niet resend. Al gok ik dat dit ook door de beschreven probs komt.
Yup. Ik zie ongeveer nu pas [+- uur vertraging] m'n (sorry, 3 voudig inderdaad) mails. Achteraf wel logisch, dat ook nlnog-smtp -> xs4all vertraagd was.
[is overigens ook serieus bereid om mee te denken over oplossingen & workarounds ]
[Jeroen : draft RFC, BGP enhancements voor route filtering, ddos controller filtering ed ] In eerste instantie dacht ik wat beperkter, nl het probleem dat xs4all servers zo te zien hun eigen back end niet goed konden bereiken. Daarnaast zou ik ietwat hogere prioriteit voor verkeer van de eigen netwerkranges met pop/smtp e.d. ook wel op prijs stellen ;-) Maar goed, denken over oplossing om het probleem op grotere schaal aan te pakken is zeker ook nodig .
De nuttige content van mijn mailtje....
[knip team Cymru hidden BGP feed ]
Daarnaast hebben ik in samenwerking met Rob Thomas (Cymru), Michel Py en William Leibzon van Completewhois, dat wat van de week op NANOG werd geannounced de volgende draft gesubmit voor de komende IETF:
"Redistribution of Cooperative Filtering Information" http://arneill-py.sacramento.ca.us/draft-py-idr-redisfilter-00.txt
Het is een voorgestelde ORF extensie die het mogelijk maakt om
Om de mensen wat zoekwerk te besparen : ORF - Outbound Route Filter Vertel je peer wat je niet wilt zien aan routes, en je krijgt ze ook niet.
filters te reannouncen. Zo kan je bijv de BGP announcement al stoppen voordat je iets raakt. Het omgedraaide van de Bogon Route Servers dus. Ook heel handig voor DDoS filtering dus. We zouden dit systeem voor de AMS-IX op kunnen zetten zodat er iig filters komen tussen de partijen die we (ehm jullie) vertrouwen dat ze confidentieel omgaan met de info want als de kids weten hoe het steekt... pisang. Daarom zeg ik over het
Mwww. Geen gek idee om niet al te publiek te speculeren, maar, ik neem aan dat je niet bedoeld om die draft RFC in te zetten, want daar ontbreekt de vendor support nog voor. Iets anders zou misschien wel mogelijk zijn, maar alleen zinvol als de bronnen zitten bij de (andere) deelnemers aan het initiatief. Ik heb een beetje het idee dat degenen die zouden deelnemen aan zoiets degenen zijn die toch al weinig een bron van problemen zijn, en indien wel, toch al snel bereikbaar om er op de gewone manier wat aan te doen.
bovenstaande ook niet echt veel want dit wordt publicly archived. En hier in nederland zitten (!hoi!) genoeg kinderen zoals we zelf helaas maar al te goed weten en die snappen dit best.
[..]
Zo'n filter zou heel handig zijn, je kan dan iig ook op 1 plek een filter definieren en *flop* al je routers snappen hem. (u)RPF er bij et tada. Uitgebreide voorbeelden op aanvraag :)
Bovenstaande kan ieder voor zich al doen, naar source danwel destinations droppen en de informatie daarvoor via (i)BGP verspreiden. Wat sneller en makkelijker dan op een aantal plaatsen allemaal filters zetten. Boudewijn
-----BEGIN PGP SIGNED MESSAGE----- Boudewijn Visser [mailto:bvisser-nlnog at xs4all.nl] wrote: <SNIP>
Daarnaast hebben ik in samenwerking met Rob Thomas (Cymru), Michel Py en William Leibzon van Completewhois, dat wat van de week op NANOG werd geannounced de volgende draft gesubmit voor de komende IETF:
"Redistribution of Cooperative Filtering Information" http://arneill-py.sacramento.ca.us/draft-py-idr-redisfilter-00.txt
Het is een voorgestelde ORF extensie die het mogelijk maakt om
Om de mensen wat zoekwerk te besparen :
ORF - Outbound Route Filter
Vertel je peer wat je niet wilt zien aan routes, en je krijgt ze ook niet.
Ik had het er in mijn hoofd bij getyped, alleen je moet dus niet tig dingen door elkaar doen, I forgot. Niet iedereen zal hier mee bekend zijn nog, het is vrij nieuw ook. Je kan momenteel dus afaik alle filters die je normaal definieert zoals "10.0.0.0/8 le 32" per BGP aan je peer vertellen maar ook ASpath filters zijn mogelijk. Nadeel was dus dat dit aan je peer wordt verteld en niet verder aan andere routers.
filters te reannouncen. Zo kan je bijv de BGP announcement al stoppen voordat je iets raakt. Het omgedraaide van de Bogon Route Servers dus. Ook heel handig voor DDoS filtering dus. We zouden dit systeem voor de AMS-IX op kunnen zetten zodat er iig filters komen tussen de partijen die we (ehm jullie) vertrouwen dat ze confidentieel omgaan met de info want als de kids weten hoe het steekt... pisang. Daarom zeg ik over het
Mwww. Geen gek idee om niet al te publiek te speculeren, maar, ik neem aan dat je niet bedoeld om die draft RFC in te zetten, want daar ontbreekt de vendor support nog voor.
Nopes, die draft moet eerst nog door de politieke molen, maar dat gebeurt binnenkort, kijken wat ie doet :)
Iets anders zou misschien wel mogelijk zijn, maar alleen zinvol als de bronnen zitten bij de (andere) deelnemers aan het initiatief.
Je kan momenteel een cisco/zebra oid pakken en dan de routes van ddos'ers (sources) announcen met een bepaalde community oid. Zie oa. http://www.secsup.org/CustomerBlackHole/
Ik heb een beetje het idee dat degenen die zouden deelnemen aan zoiets degenen zijn die toch al weinig een bron van problemen zijn, en indien wel, toch al snel bereikbaar om er op de gewone manier wat aan te doen.
Ja, dat is helaas zeker zo, maar als je dus samen werkt kan je iig zorgen dat die traffic niet bij de deelnemers komen. Een upstream zou bovenstaand mechanisme kunnen maken waardoor hun die IP's al nullrouten, geen traffic naar jou. Filteren van die prefixen is netter en sneller though.
bovenstaande ook niet echt veel want dit wordt publicly archived. En hier in nederland zitten (!hoi!) genoeg kinderen zoals we zelf helaas maar al te goed weten en die snappen dit best.
[..]
Zo'n filter zou heel handig zijn, je kan dan iig ook op 1 plek een filter definieren en *flop* al je routers snappen hem. (u)RPF er bij et tada. Uitgebreide voorbeelden op aanvraag :)
Bovenstaande kan ieder voor zich al doen, naar source danwel destinations droppen en de informatie daarvoor via (i)BGP verspreiden. Wat sneller en makkelijker dan op een aantal plaatsen allemaal filters zetten.
Dat filters plaatsen kan dan op 1 plek want je verzend de info per BGP en ORF. Huidige ORF werkt nu dus alleen tussen 2 routers. 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/AwUBP5XYZymqKFIzPnwjEQIoOwCfYePMK/XTgNDtyakAfbMzMudbevUAn2Qc 99QXrQ7Mi0aQYGiIvxx5t1jE =0i2D -----END PGP SIGNATURE-----
On Wed, 22 Oct 2003, Jeroen Massar wrote:
Je kan momenteel een cisco/zebra oid pakken en dan de routes van ddos'ers (sources) announcen met een bepaalde community oid. Zie oa. http://www.secsup.org/CustomerBlackHole/
Zijn er dan ook afspraken gemaakt met de DDoS kiddies dat ze geen gespoofde adressen meer gebruiken? -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
participants (3)
-
alex＠bit.nl -
bvisser-nlnog＠xs4all.nl -
jeroen＠unfix.org