So are you going to allow someone else to run it now? At 14:08 2/04/01 +1200, you wrote:

nope, there isn't one. We turned of Auckland because of continued dos attacks.

-----Original Message----- From: owner-nznog(a)list.waikato.ac.nz [mailto:owner-nznog(a)list.waikato.ac.nz]On Behalf Of Pete Sent: Monday, 2 April 2001 2:02 p.m. To: nznog(a)list.waikato.ac.nz Subject: NZ Undernet server

Hi all

Does anyone know of a public Undernet IRC server within 'NZ' ?

After receiving a HUGE bill from my isp for traffic to the SanDiego server I'm keen to find another 'local' relay. I note that auckland.nz.undernet.org is non-existant now.

Thanks in advance

Pete

Pete Mundy - Technician Advanced Communications +64-3-546-9169 / +64-25-480-840 E-Mail: Pete(a)AdvComm.Co.NZ

--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

On Mon, Apr 02, 2001 at 02:08:01PM +1200, Tony Wicks wrote:

nope, there isn't one. We turned of Auckland because of continued dos attacks.

Actually, I believe auckland.nz.undernet.org is alive and well and sitting on a single connection to an APE switch in the Sky Tower. It's largely invisible, of course, since no sane ISP which attaches to more than one exchange wants to provide even internal transit to the exchange subnet. Joe --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

On Mon, Apr 02, 2001 at 02:43:45PM +1200, Tony Wicks wrote:

No Joe I can assure you it is quite dead and sitting in my server room out the back. It **was** vlan'd up to ape from there, true. But when the kiddies couldn't dos the server they just started working their way round the rest of our network. The server has an APE ip address, but it also had a real world ip that it used for connection to the rest of the server network on another interface.

Aah :) Sorry about the noise, then. Joe --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

My feeling is, any attack is a bad attack. No matter what degree of redundancy you try to achieve, no matter how many peripheral links the server may have, if it is unwanted by the lusers, they'll attack it. And they're sneaky. And they're persistent. And, they tend to have access to a lot of potatos/second. It would seem that labelling it with a neon "Someone Elses Problem" sticker is the best outcome - I for one would be unhappy having too much to do with providing any network space for such a device. In any case, given the dog-in-a-manger stigma that has existed in regards to the NZ undernet server in last years, I doubt anything will ever happen, at least, not in our lifetimes. T. On Mon, 2 Apr 2001, J S Russell wrote:

On Mon, 2 Apr 2001, Tony Wicks wrote:

...

nope, there isn't one. We turned of Auckland because of continued dos attacks.

I'm certainly missing auckland.nz.undernet.org, as well.

Just out of interest, how were they attacking the server? It was on an APE address, and I presume you were keeping it's world-accessable IP very secret. Were the flooding dickheads simply attacking AsiaOnLine NZ networks directly, hoping to saturate your international connections and drive the server offline? Or were the DoS attacks coming from domestic sources?

There must be a way to circumvent these pesky floods, or at least route around them (and hence make them useless, which will in turn make them go away.)

Perhaps a server run by an incorporated society rather than a specific ISP, fed by bandwidth sourced from multiple interested NZ ISP's? This way it could have multiple paths out to us and eu undernet servers. Of course, it'd still have to have secret real-world IP's and again be on an APE or WIX address for domestic access.

That would be very difficult to attack, and bandwidth from each of the ISP's in question could perhaps be constrained at the international AP, limiting the effects of floods on each of the ISP's in question.

JSR

--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

Tim J. Shackleton ------------------+ +- Business http://www.netlink.co.nz/ Networks Admin/Programmer ----------+ +- Personal http://www.netnet.net.nz/ Netlink LTD -- DDI +64 4 922 8476 --+ +------------- Pager 64 +26 253 4356 +64 29 650 476 -- Cellular ---------+ +------------------------------------ ----------------- " All your base are belong to us! " --------------------- --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

Nothing an old-fashioned lynching won't fix :)

Or am I just being a bright-eyed bushy-tailed hippie?

JSR

Tim J. Shackleton ------------------+ +- Business http://www.netlink.co.nz/ Networks Admin/Programmer ----------+ +- Personal http://www.netnet.net.nz/ Netlink LTD -- DDI +64 4 922 8476 --+ +------------- Pager 64 +26 253 4356 +64 29 650 476 -- Cellular ---------+ +------------------------------------ ----------------- " All your base are belong to us! " --------------------- --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

On Mon, Apr 02, 2001 at 04:23:31PM +1200, Steve Phillips wrote:

How effective this would be is another story, I know that when the server had been running on a real world IP in the past some of the larger attacks ended up taking out pretty much all the country, even tho - stricly speaking it should only have filled up our own international capacity.

I don't remember being "taken out" when I was at CLEAR, nor later when I was doing some work for Telstra Saturn, although I remember reading reports of "New Zealand's international internet circuits" being "taken down". "Pretty much all the country" is an IDGism for "Telecom and customers", I always thought. Joe --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

At 16:33 2/04/2001 +1200, J S Russell wrote:

On Mon, 2 Apr 2001, Steve Phillips wrote:

...

This idea was floated as well, however you still run into the problem whereby someone can simply take out large portions of New Zealands international capacity and if the servers real IP is hidden then the DoS kiddies will simply hit everything they can and the innocent users will suffer.

...

That would be very difficult to attack,

Not really..

Huh - I was underestimating the scale of the attacks by an order of magnitude or two, then.

Ouch.

I can see why you would get to the stage of simply killing the service altogether.

JSR

As Steve well knows, ive sat in on the backend of a few fairly large DoS attacks - and have a good idea what hit auckland* :P Its rather a shame that the server had to go down - It has a large number of fans, myself included - and a lot of us are all looking forward to it coming back.. ... The question is, when? And where? I agree with some of whats been said here to this point - Is there an effective way of limiting its top limit international bandwidth such that the rest of *.nz arent affected? I would think if we could achieve that, we've solved the problem. *hoping* :) Mark. --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

I know a few in here have tried to propose another undernet server in NZ and found it rejected for various reasons. Let me just say that the NZ undernet server was not "owned" by ICONZ or Asiaonline. ICONZ and later on Asiaonline sponsored the bandwidth as well as telehousing of the server. I am more than grateful for their support on this since the server was introduced in January 1995. The server is owned by the admin of the server which was Rowan Smith, who happened to worked at ICONZ/Asiaonline. There were IRC operators there who definitely didn't work for ICONZ/Asiaonline. Needless to say it is unfortunately the DDOS attacks on Undernet have started targetting leaf servers rather than the hubs. However the problem now is the DDOS attacks that will be aimed at any Undernet IRC server in NZ, sooner or later. We thought we had the problem solved but it turns out they then turned to attacking the big ISPs in NZ hoping that one of them was the server sponsor. Of course we can't pin point x attack at y hours on z day was due to ppl targetting the IRC server. Also due to the more than Network operators (potentially media) in here, I do not wish to publicise too much. However things do filter back to us and certain coincidences can either be by chance coincidences or actually DDOS in tandem. Measures will be taken to ensure that if another server in NZ is linked to Undernet it will be another red flag etc. It would also be good to have a server on a central location where other ISPs have access to it (as before>. It is also clear that we may not be able to find one main sponsor but perhaps have a group of sponsors. Unfortunately I am supposed to be working on this and have done nilch to date. I'll pull up my socks and work on it soon. I would like to hear from anyone who is interested in helping with this. It will mean a limited mailing list as I would prefer if hack kiddies don't use public lists to find out what is planned etc. Do note that such help doesn't guarantee server approval for linking NOR does it guarantee an IRC operator status on any resulting server. I know someone is going to say "security through obscurity". However in this case it is worth staying a step ahead of the DOS kiddies. Lin Nah currently wearing hat of Undernet IRC Admin --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

On Mon, 2 Apr 2001, J S Russell wrote:

The problem is, you'd have to go back upstream quite a ways. To a major NAP or two in the US, you'd _have_ to take it back out of NZ, we're the ass-end of the net at best. :)

It's not something with an easy answer.

Maybe :) An interesting idea which came up at a meeting here a while ago : As people might be aware, adding routes to null0 isn't the most effective way sometimes of dropping flood traffic. Sending it to an IP address, and then staticly associating a bogus mac address to that IP is often better - the router simply forwards the packet out onto the lan, and the ethernet swallows it. This puts less load on the router. Now a thought I had while thinking about this... could a BGP community be agreed upon between peers, such that (for example) any static routes to the bogus IP/mac on my router are exported to my upstream with this community set. They see the community, set the next-hop address to their version of the blackhole IP, and possibly pass it on further upstream. Pro: A reasonably easy way to blackhole a target IP at upstream or peer ISPs without having to get their NOC to implement changes on routers. If the trust relationship for these communities extended far enough upstream, the target IP effectively disappears off the net. Con: You'd have to trust the downstreams who are injecting these blackhole routes. This could be done careful use of prefix or access-lists, allowing people to propagate /32 blackhole routes for IPs under their control. Thoughts? [1] Ok, so some configuration might also be needed on the switch to stop the traffic being flooded all over the place. David Robb --- Senior Network Engineer IHUG NZ "The Earth is a single point of failure" --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

The provider side solution for DDoS attacks is quite simple... unfortunatly, it's also quite expensive and involves having multiple service centers that are load/geographically balanced with a general massive over provisioning for everything (something that may be a little difficult to accomplish for an IRC network whos' financial model is... well... non-existant at best). The basic idea behind this philosophy is that when faced with large numbers, division is one of your best friends... divide and conquer... you know all that basic stuff they teach you in CS101. From another angle, avoiding the distribution of content goes against the church of the meme... who cares of anyone is looking at it; your content will inevitably end up in somebodies cache, increasing the chance that someone will see it without you having to give it to them. Just because you have an ASN doesn't mean that you're somehow qualified to determin what should be routed globally and what should not. If you want to do it for your own address space, that's fine; however, I do not know of any tier 1 carrier who would be crazy enough to indescriminatly knock their customers off the air because "their traffic profile looked suspicious", let alone other carriers' customers. Any carrier that did would soon find themselves the pariah of their fomer peers and an easy target for lawyers of even modest caliber. Beyond that, black-holing address space at the BGP level is a slippery slope prone to political (and other) exploitation. I like my DDoS solutions to come from the edge of the network, thank you. If you're too small to engineer global service correctly, then I can see how the outlined solution could appear seductive, but the end solution should involve opt-in from your edges and peers (that way nobody can complain when they disappear off the face of the internet for whatever no-good reason). Simon Lyall wrote:

I'm surprised there are not more comments on this. What are other people using to reduce the impact of floods?

On Tue, 3 Apr 2001, David Robb wrote:

...

An interesting idea which came up at a meeting here a while ago :

As people might be aware, adding routes to null0 isn't the most effective way sometimes of dropping flood traffic. Sending it to an IP address, and then staticly associating a bogus mac address to that IP is often better - the router simply forwards the packet out onto the lan, and the ethernet swallows it. This puts less load on the router.

Now a thought I had while thinking about this... could a BGP community be agreed upon between peers, such that (for example) any static routes to the bogus IP/mac on my router are exported to my upstream with this community set. They see the community, set the next-hop address to their version of the blackhole IP, and possibly pass it on further upstream.

Pro: A reasonably easy way to blackhole a target IP at upstream or peer ISPs without having to get their NOC to implement changes on routers. If the trust relationship for these communities extended far enough upstream, the target IP effectively disappears off the net.

Con: You'd have to trust the downstreams who are injecting these blackhole routes. This could be done careful use of prefix or access-lists, allowing people to propagate /32 blackhole routes for IPs under their control.

Thoughts? [1] Ok, so some configuration might also be needed on the switch to stop the traffic being flooded all over the place.

--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

As people might be aware, adding routes to null0 isn't the most effective way sometimes of dropping flood traffic. Sending it to an IP address, and then staticly associating a bogus mac address to that IP is often better - the router simply forwards the packet out onto the lan, and the ethernet swallows it. This puts less load on the router.

This is because Cisco Routers process switch packets to null0, because it is a CPU interface and not a physical interface. I would suggest that we should all place feature requests with our local Cisco vendor (Logical/Datacraft/Cisco Themselves/whatever). If we all place some pressure on Cisco then we might actually see something done about it. I have seen comments about this on NANOG, so I am sure that the feature request has been placed, but it's probable that Cisco are working with their usual latency to industry requests (ie a committee to form a working group to plan the implementaion of the project brief to be delivered to a team of IOS developers for peer-review, which will then prepare a report to return to the working group, which will then liase with Marketting and do a cost-benefit analysis before eventually deciding to implement it - geez, does this sound like ISOCNZ to anyone else?). David's idea about BGP seems like a good one, however, and one that we should be looking into. Also, anyone with the inclination to set up MBGP peering over APE or WIX please contact me at: james.tyson(a)attica.co.nz Cheers. James Tyson --- Samizdat New Media Solutions --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

With CEF, Null0 is a special CEF adjacency - not a CPU interface. So packets black holed to Null0 with "no ip unreachables" turned on the Null0 interface will be get dropped in CEF (on the LC if it is dCEF). For example: interface Null0 no ip unreachables ! ip route <dest to drop> <mask> Null0 ! If you still want to reply to ICMP unreachables, set the "ip icmp rate-limit unreachable" from 500ms to something higher (see below for docs on this feature). On the GSR, "no ip unreachables" did not work until just a few weeks ago. We committed a fix into 12.0(16.5)S (which will be synced into 12.0ST). Barry ----------------------------------- ICMP Unreachables Rate-Limiting ------------------------------ We do have a feature to rate-limit the ICMP Unreachables. The DDTS used to track this is: CSCdp28161 - ICMP error generation rate should be configurable The default is to rate-limit ICMP Unreachables to one per 500 milliseconds since 12.0(8)S. Some people think that this should be set to 1 or 2 seconds. Here are the docs for this feature: A new UI command is introduced to control the icmp unreachable error msg rate. To configure the rate of the icmp unreachable error messages generated, use the ip icmp rate-limit unreachable command. To not rate limit the icmp unreachable error messages, use the no form of this command. ip icmp rate-limit unreachable [DF] <1-4294967295 millisecond> no ip icmp rate-limit unreachable [df] Syntax Description DF to rate limit the icmp unreachable message with code 4, fragmentation needed and DF set. milliseconds rate limit to one message within this milliseconds. Default Both icmp unreachable DF and the rest of icmp unreachable are rate-limited to one per 500 milliseconds. Command Mode Global configuration Examples The following example sets the rate of the icmp unreachable to one message per 10 milliseconds. ip icmp rate-limit unreachable 10 The following example sets no ip icmp rate-limit unreachable DF no rate-limit on the icmp unreachable DF.

-----Original Message----- From: owner-nznog(a)list.waikato.ac.nz [mailto:owner-nznog(a)list.waikato.ac.nz]On Behalf Of James Tyson Sent: Friday, April 06, 2001 6:51 PM To: David Robb Cc: nznog(a)list.waikato.ac.nz Subject: DDOS Attacks, etc.

...

As people might be aware, adding routes to null0 isn't the most effective way sometimes of dropping flood traffic. Sending it to an IP address, and then staticly associating a bogus mac address to that IP is often better - the router simply forwards the packet out onto the lan, and the ethernet swallows it. This puts less load on the router.

This is because Cisco Routers process switch packets to null0, because it is a CPU interface and not a physical interface. I would suggest that we should all place feature requests with our local Cisco vendor (Logical/Datacraft/Cisco Themselves/whatever). If we all place some pressure on Cisco then we might actually see something done about it. I have seen comments about this on NANOG, so I am sure that the feature request has been placed, but it's probable that Cisco are working with their usual latency to industry requests (ie a committee to form a working group to plan the implementaion of the project brief to be delivered to a team of IOS developers for peer-review, which will then prepare a report to return to the working group, which will then liase with Marketting and do a cost-benefit analysis before eventually deciding to implement it - geez, does this sound like ISOCNZ to anyone else?).

David's idea about BGP seems like a good one, however, and one that we should be looking into.

Also, anyone with the inclination to set up MBGP peering over APE or WIX please contact me at: james.tyson(a)attica.co.nz

Cheers.

James Tyson --- Samizdat New Media Solutions

--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog