|
All Archives /
aussie-isp /
2003-01
|
<<< Date >>> | |
| Permanent Link | ||
|
Date: Thu, 2 Jan 2003 12:52:59 +1100 (EST)
From: James Spenceley To: Jason Andrade Cc: Bob Purdon - lists, Noel Butler, aussie-isp Message-Id: <20030102115852.E75015-100000@marvin.iroute.org> In-Reply-To: <Pine.GSO.4.44.0212280806240.11825-100000@sunburn.dstc.edu.au> Subject: Re: [Oz-ISP] austnet death |
Followups: |
|
> > Bob Purdon wrote ... > > I still recall those 100+mbps (no, not a typo) DDoS attacks, which IIRC, > > were caused by a few script kiddies wanting to engage in 'genital > > comparison' by seeing which IRC network they could wipe out first. > > A nasty side effect was that they wiped out a couple of wholesale > > providers for varying periods during these attacks, which caused other > > innocent parties to suffer. innocent party = lack of BW *or* lack of sleep ;-) > i would be interested in hearing about other ISPs ideas on dealing with > DoS situations, both reactive and proactive. the two most common scenarios > seem to be: There are certainly a couple of things we have done to be proactive, and there a some of things people can do to assist in such attacks. * Identification, be aware of which customers are hosting IRC servers. They will be DDoS and it will wake you up, if you have the IP/netblocks handy it makes for much faster fixes. * Separation, if possible keep said IRC box on a separate globally routeable netblock. Attacks get worse the further upstream you go, so you might find that your upstream will blackhole that network in order to stem impact to their network and other "innocent" parties. * If you run an IRC server alert you upstreams, work with them on a proactive plan on the best way to deal with such attack. * If you are multi-homed and/or have significant peering. Consider announcing the IRC server in a simple method say via only a single provider. Attempting to trackdown sources of attacks over many sessions across shared/public peering is quite difficult. > o attacker has control or access to a large number of overseas machines > (usually windows based and on some high speed link, e.g cable) which > are used to shape a number of udp streams all blasting at the same > target here > > consequence - between tens and thousands of 1-100Mbit streams with an > aggregate bandwidth of sufficient size or rate (tens of thousands PPS) > that affects the: > > . OS of the machine offering the service > . router of the ISP where the machine is hosted > . upstream bandwidth of the ISP (affecting all their customers) > . routers of the wholesale provider(s) of the ISP > . the international links of the wholesale provider(s) of the ISP > (affecting all their downstream ISP customers) Always work in progress, the simplest method is to locate the destination block, stop announcing it to all but your most proactive peer/upstream and then get them to ACL the attack and pass it on their upstream/peer - Hot Potato Style. Clever BGP will make the application much faster. I've seen cases where an upstream has absorbed hundreds of mbps for weeks. If it becomes a problem for them they will track the source further, in most cases a large US provider can and will absorb this level of attack. It probably puts the glut of capacity to some use ;-) As the net evolves further this may change. In much the same way Australian wholesale providers should do the same. Historically it was commonplace for upstrems to refuse to ACL an attack. Typically the excuse was they would be charged for that data and not recoupe any revenue from the customer, but with such competition nowadays this shouldn't be the case. It probably worth a phone call to ask. > o attacker has control or access to a smaller number of domestic machines > and basically repeats the attack above. this usually only affects domestsic > transit links but has many of the same consequences as above. Not that common, only in the worst of attacks (global) do you see much if any domestic host participation. I guess this says something about the clue level of most Australia Net users or maybe just our size in the grand scheme of things. I've never seen an exploits/worm/trjoan that is country aware. > Some IRC networks now only allow for domestic connectivity of end users to try > and get around the first situation but this has proven to be quite difficult to > implement as some wholesale vendors appear to leak routes and/or ignore prefixes > which then exposes paths to attack machines. Ahh well, they have the wrong upstream ;-) > -jason -- James ---- email "unsubscribe aussie-isp" to m a j o r d o m o @ a u s s i e . n e t to be removed. |
|