- NLNOG - mailman3.nlnog.net

Vraagje mbt logging en kosten ivm Bewaarplicht ...
by erik＠bais.name 04 Nov '08

04 Nov '08

Hi, Ik ben gevraagt om ter voorbereiding voor een gesloten zitting van de 1ste kamer Commissie van Justitie wat inzage te geven in kosten mbt bewaarplicht. Deze zitting is op 11 November. De gegevens welke gebruikt worden, zullen door onafhankelijke EDP auditors bekeken worden tijdens de zitting. Dit zal waarschijnlijk de laatste mogelijkheid zijn om deze gegevens nogmaals bij de CvJ voor te leggen en wat de impact gaat zijn van dit besluit voor de ISP. Om dit correct te doen, ben ik momenteel wat gegevens bij elkaar aan het verzamelen en zou hier graag jullie willen vragen om de volgende info te verschaffen (dit mag ook private als je de gegevens niet publiekelijk wil delen.) De gegevens die ik heb, zijn 3 jaar oud en ik heb deze uit mijn presentatie gehaald toen ik nog bij IS werkte. Wat zie je als website logging per dag per website: Mijn inschatting momenteel is 7MB per dag gemiddeld. Hoeveel website's host je momenteel ? Hoeveel storage ga je nodig hebben per dedicated / virtueel dedicated server per jaar ? Colo is niet van de hoster en hoef je niet mee te nemen. Maillogging: Voor een omgeving waarbij je ongeveer 30.000 mailboxen host, krijg je ongeveer 3GB aan logfiles per dag. Wat zie je zelf in je eigen omgeving en hoeveel mailboxes host je ? DHCP / Radius logging. Hoeveel log-gegevens zie je uit deze omgeving per dag ? Deze DHCP / Radius logging is puur de logging van de technische informatie, maar weet je over 10 maanden nogaan welke klant je welk IP nr hebt uitgedeelt ? En wat is de impact als je ook IPv6 gaat aanbieden aan je klanten ? Kan je dan nog steeds per IP adres over 10 mnd met 100% zekerheid aangeven wie de eigenaar was op moment X ? Als je dit niet kan (wat wel een requirement is), hoeveel denk je dat het gaat kosten om de integratie te maken en qua opslag, zodat je dit wel kan doen. ( integratie kosten en additionele opslag kosten om bij iedere IP record in de Radius / DHCP timestamp ook een identifier ( acct nr ? ) op te slaan ) Hoeveel van jullie hebben SOX complient storage ( en hoe groot is deze), waarbij het mogelijk is om logfiles read-only op te slaan zodat het niet aangepast kan worden (tampering) waarbij de gegevens ook daarwerkelijk als bewijslast zou kunnen worden gebruikt ? Wat ga je denk je nodig hebben aan pure ( netto ) storage en daarnaast nog de RAID overhead en komt er dan nog aan backup storage bij. Hoeveel backups ga je maken en hoelang ga je die data ( van de backups ) bewaren.) Uiteraard heb ik niet veel tijd gekregen om de info te verzamelen, dus als je dit zou kunnen verstrekken binnen 24 uur, zou ik dat heel erg op prijs stellen. Mvg, Erik Bais

3 5

197/8 allocated to AfriNIC
by leo.vegoda＠icann.org 29 Oct '08

29 Oct '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The IANA IPv4 registry has been updated to reflect the allocation of one /8 IPv4 block to AfriNIC in October 2008: 197/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Regards, Leo Vegoda Number Resources Manager, IANA -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFJCBdMvBLymJnAzRwRApYGAJ9DfmQ2fvbfMgCVW1M8ZfiMnqSvgACgrCha /biQ/NJ9HS09avyV3UTRlRY= =wQ6t -----END PGP SIGNATURE-----

1 0

Virbl toont nu ook meldingen van whitelisted hosts
by marks＠bit.nl 18 Oct '08

18 Oct '08

Ola, naar aanleiding van een 12000 meldingen van whitelisted hosts op Virbl van een enkele partij die ik niet nader zal noemen, heb ik vanmorgen in Virbl getyped dat meldingen van whitelisted hosts ook opgenomen worden in de database. Dat wil *niet* zeggen dat ze ook op de list terecht komen, maar *wel* dat de evidence wordt opgeslagen en dat je in de login-area de evidence ervan ook kunt zien. Ik hoop dat men daarop ook actie gaat ondernemen zodat we steeds minder meldingen zien van whitelisted hosts. -- Mark Schouten, Unix/NOC-engineer BIT BV | info at bit.nl | +31 318 648688 MS8714-RIPE | B1FD 8E60 A184 F89A 450D A128 049B 1B19 9AD6 177FF

1 0

Virbl notificaties
by marks＠bit.nl 11 Oct '08

11 Oct '08

Ola, men kan nu notificaties instellen in Virbl. Op het moment dat je dat hebt gedaan (dit gaat per AS) kun je iedere twaalf uur mail verwachten op het moment dat er een host in je AS gelist staat. Is dat niet het geval, dan krijg je ook geen mail. Je kunt ook je wachtwoord aanpassen. Have fun. -- Mark Schouten, Unix/NOC-engineer BIT BV | info at bit.nl | +31 318 648688 MS8714-RIPE | B1FD 8E60 A184 F89A 450D A128 049B 1B19 9AD6 177FF

1 0

Redundante ISC DHCP setup
by arjan＠vanderoest.net 08 Oct '08

08 Oct '08

Heeft iemand ervaring met een redundante ISC-DHCPD setup? Wij lopen onder omstandigheden tegen het onderstaande verhaal aan. Voor de volledigheid omschrijf ik de hele sequence maar, omdat een en ander een aaneenschakeling van 'als, mits" lijkt te zijn. We hebben twee machines in failover config staan, in separate netwerken. Clients zitten niet in het lokale subnet maar praten via een 'sort-of' DHCP relay. Bij het ontvangen van de DISCOVER stuurt de relay deze gedupliceerd door naar beide servers. Een van beiden stuurt een OFFER, de andere logt "load balance to peer default". De relay stuurt de OFFER door naar de client, maar om nog onduidelijke redenen komt deze niet altijd aan. De client doet een timeout en stuurt vervolgens nog een DISCOVER met een identieke transaction-id. De relay stuurt deze weer door naar beide servers en blijkbaar interpreteert de redundante setup de hernieuwde DISCOVER met identieke transaction-id als een teken van transmissie problemen. In antwoord daarop sturen _beide_ servers een OFFER, het IP in deze offers is niet identiek en ook geen van beiden identiek aan de eerste OFFER. Dit gedrag van twee offers en de aanname dat dit het gevolg is van de herhaalde discover met identiek transaction-id is nergens op gebaseerd, bij deze tweede offer logt geen van beide servers namelijk een bijzondere melding. De relay stuurt beide offers door naar de client. De client selecteert (op nog onbekende gronden) een OFFER en stuurt een REQUEST naar het IP van de versturende server. De relay dupliceert dit pakket weer en stuurt het door naar de bij hem 2 bekend zijnde DHCP servers. Beide servers sturen een ACK, we nemen vooralsnog ongefundeerd aan dat beide servers dit doen omdat ze een failure-state vermoeden op grond van de herhaalde DISCOVER. Onder normale omstandigheden zou een enkele REQUEST ook een enkele ACK tot gevolg hebben, met een melding omtrent load-balancing op de 2e server. Beide servers zetten hun eigen IP in de server identifier in de ACK. De relay stuurt beide ACK's door naar de client. Een intermediate device (tussen relay en client) dropt de tweede ACK (commentaar: er is een sort of statemachine geimplementeerd die ook actief het DHCP verkeer in de gaten houdt en het blijkbaar nodig acht om de tweede ACK te droppen). Hier is sprake van een race-condition: als de eerste ACK van de machine blijkt te zijn waar de REQUEST heen is gegaan dan accepteert de client hem. Komt de ACK van de tweede machine aan dan pikt (in ieder geval die DHCP implementatie van Windows XP) de client hem niet, waarschijnlijk als gevolg van de server identifier. Er volgt weer een timeout van de client en het hele circus start opnieuw. Het droppen van de 2e ACK is geen probleem indien er geen twee OFFERS worden gedaan, die tweede ACK komt namelijk niet, ook al wordt de REQUEST wel degelijk richting beide servers gestuurd. De 2e server reageert in dat geval namelijk met een 'lease owned by peer' en stuurt in dat geval helemaal niets terug richting de client. Concreet mijn vraag: is het geschetste gedrag van de DHCP servers (eerst _een_ OFFER en bij herhaling van de DISCOVER met identieke transaction-id allebei een OFFER) zoals het zou moeten zijn? Elke andere input, behalve in reactie op bovenstaande vraag, is uiteraard ook welkom.

1 0

NLWhitelist in dnswl
by marks＠bit.nl 25 Sep '08

25 Sep '08

Goeieavond, sinds vandaag is de nlwhitelist opgenomen in dnswl.org. Dat is een whitelist die wat meer internationaal gebruikt wordt (ook in spamassassin bijvoorbeeld). http://www.dnswl.org/search.pl?s=1002 Al met al wel handig, komt mail nog wat vaker aan. ;) PS: Er staan nog wat zaken op de NLWhitelist die opgeruimd moeten worden. Dat zal in de komende weken gaan gebeuren. -- Mark Schouten, Unix/NOC-engineer BIT BV | info at bit.nl | +31 318 648688 MS8714-RIPE | B1FD 8E60 A184 F89A 450D A128 049B 1B19 9AD6 17FF

1 0

Atrivo/Intercage brandje naar ams-ix ?
by marcoh＠marcoh.net 24 Sep '08

24 Sep '08

Mogguh, Lijkt erop de intercage brand is overgeslagen naar NL, een deel van de machines duikt nu op achter een ams-ix poort. Iemand die hier meer van weet, misschien zelfs ECATEL die iets kan toelichten ? Begin forwarded message: > From: "Paul Ferguson" <fergdawgster at gmail.com> > Date: September 24, 2008 6:42:53 AM GMT+02:00 > To: "Russell Mitchell" <russm2k8 at yahoo.com> > Cc: nanog at nanog.org > Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It may be true that Estdomains has moved a couple of the external- > facing a > hosting hosts into the a Netherlands hosting provider in conjunction > with > this whole situation -- folks are watching very carefully. > > estdomains.com A 94.102.49.3 > storefront.estdomains.com A 94.102.49.5 > www.estdomains.com A 94.102.49.4 > www.estsecure.com A 94.102.49.5 > > AS | IP | AS Name > 29073 | 94.102.49.3 | ECATEL-AS AS29073, Ecatel Network > > % Information related to '94.102.48.0 - 94.102.63.255' > > inetnum: 94.102.48.0 - 94.102.63.255 > netname: NL-ECATEL-20080829 > descr: Ecatel LTD > country: NL > org: ORG-EL38-RIPE > admin-c: RvE16-RIPE > tech-c: RvE16-RIPE > status: ALLOCATED PA > mnt-by: RIPE-NCC-HM-MNT > mnt-lower: ECATEL-MNT > mnt-routes: ECATEL-MNT > source: RIPE # Filtered > > organisation: ORG-EL38-RIPE > org-name: Ecatel LTD > org-type: LIR > address: Ecatel LTD > Reinier van Eeden > P.O.Box 19533 > 2521 CA The Hague > NETHERLANDS > phone: +31702204015 > fax-no: +31702204015 > e-mail: r.eeden at ecatel.net > admin-c: RvE16-RIPE > mnt-ref: ECATEL-MNT > mnt-ref: RIPE-NCC-HM-MNT > mnt-by: RIPE-NCC-HM-MNT > source: RIPE # Filtered > > > DNSLogger: > > estdomains.com A 94.102.49.3 > estdomains.com A 216.255.176.238 > estdomains.com NS ans1.esthost.com > estdomains.com NS ans2.esthost.com > estdomains.com NS temp1.estdomains.com > estdomains.com NS ns1.estdomains.com > estdomains.com NS temp2.estdomains.com > estdomains.com NS ns2.estdomains.com > > http://www.bfk.de/bfk_dnslogger.html > > Thanks, > > - - ferg MarcoH

5 14

Atrivo/Intercage brandje naar ams-ix ?
by jeroen＠easyhosting.nl 24 Sep '08

24 Sep '08

Aantal verhelderende artikeltjes over Intercage / Atrivo http://www.spamhaus.org/news.lasso?article=636 http://www.securityfocus.com/news/5654 At 09:54 24-9-2008, Raymond Dijkxhoorn wrote: >Hi! > >Wat me op niet verbaasd, kan iemand zich nog Iquarus herinneren? Ja daar >is ook en NL-NOG thread over geweest. Diezelfde meneer van Eeden zat daar >toen ook achter. En host nu kennelijk Atrivo. Ik vind dit meer dan toeval. Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl

2 1

Virbl, de NLWhitelist en telefoontjes
by teun＠teun.tv 22 Sep '08

22 Sep '08

Hoi, Op verzoek van m'n collega Mark, die (nog?) geen post rechten heeft op deze lijst stuur ik jullie even een mailtje van hem door over Virbl: Concullegae, Sinds een week of drie is er nieuw leven in Virbl geblazen. In de afgelopen twee jaar heeft Virbl een beetje in een stoffig hoekje gelegen, maar dat is niet meer. Virbl doet weer volledig mee, dat is ook te zien aan het aantal hosts dat er inmiddels op staat; 6368 stuks. En dat het werkt kun je ook nog wel zien op [1]. Notificatie naar de AS-beheerders vanuit Virbl zal in de komende weken weer gaan werken, zodat iedereen kan aangeven of en wanneer hij wil weten dat hosts in zijn netwerk gelist zijn. Gelist staan op Virbl is niet leuk, kunnen we opmaken uit mailtjes die we op virbl at bit.nl krijgen. Voor de Nederlandse ISP is daar een prima workaround voor, de NLWhitelist [2]. Die wordt door Virbl als 'exclude' gebruikt. We zijn nog bezig met het ontwikkelen van een systeem om automatisch valide mailservers te herkennen op basis van mailtjes die bij ons afgeleverd worden en die wij probleemloos kunnen afleveren bij klanten, maar dat is nog WIP. Als je nog niet op de NLWhitelist staat, kijk dan even op [2] voor de voorwaarden en mail dnsbl at bit.nl daarover. Vanmorgen kreeg ik opmerkingen van onze support-afdelings-chief dat ze vrij veel gebeld worden over Virbl, ondanks de meldingen op de site en in de autoreply dat je hierover niet kunt/mag bellen. Het is niet geheel onverwachts dat mensen het toch proberen, maar hij wist me ook te melden in een aantal gevallen mensen door hun ISP naar ons verwezen werden. Ik wil iedereen verzoeken om dat niet te doen, maar te verwijzen naar de website [3]. We zullen nooit telefonisch reageren op opmerkingen/vragen/verzoeken over Virbl. Als je wilt doorverwijzen, verwijs dan alsjeblieft naar diegene die Virbl gebruikt. Nog even wat anders. Virbl ondersteunt IPv6. Dat wil zeggen, Virbl kan het aan en in de txt- en bind-versie van de exports kom je eventueel geliste hosts (dat zijn d'r nog niet zoveel ;)) tegen. Nu kun je met IPv6 twee dingen doen: 1: Op een aparte list zetten. Bijvoorbeeld ipv6.virbl.dnsbl.bit.nl 2: Gewoon mixen met virbl.dnsbl.bit.nl Mijn voorkeur gaat uit naar optie twee, en zeker gezien het feit dat we in Virbl geen wildcard-dingen doen is dat ook niet echt een issue. Maar als de gebruikers het niet willen schiet mijn mening ook niet echt op. Dus, wat is wijsheid? ;) Andere opmerkingen/verbeterpunten over Virbl, ascc, of de NLWhitelist zijn uiteraard van harte welkom op dnsbl at bit.nl! [1]: http://virbl.bit.nl/why.php [2]: http://noc.bit.nl/dnsbl/nlwhitelist/ [3]: http://virbl.bit.nl/ -- Mark Schouten, Unix/NOC-engineer BIT BV | info at bit.nl | +31 318 648688 MS8714-RIPE | B1FD 8E60 A184 F89A 450D A128 049B 1B19 9AD6 177FF:1

7 14

Virbl, logins
by marks＠bit.nl 18 Sep '08

18 Sep '08

Goeiemorgen, Ik heb nog een beetje verder getyped aan de Virbl login area. Je kunt daar nu een aantal zaken: * Mooi grafiekje zien met de stats van je eigen AS * Zien welke hosts in je AS gelist zijn * Evidence bekijken van de hosts die we gezien hebben We hebben hier gisteren even overlegd en besloten dat we delisting vanuit die login-area toestaan. Let wel, dat is eenmalig per week, per host. Als je een host delist en hij komt weer terug, dan ben je gewoon het lul. :) Je hebt nu dus nog een extra functie aldaar: * Suspenden van hosts Have fun! https://virbl.bit.nl/login/ -- Mark Schouten, Unix/NOC-engineer BIT BV | info at bit.nl | +31 318 648688 MS8714-RIPE | B1FD 8E60 A184 F89A 450D A128 049B 1B19 9AD6 177FF

3 2