looking for pull traffic
tom at unitedlayer.com
Fri Nov 14 09:26:42 UTC 2003
On Thu, 13 Nov 2003, Richard A Steenbergen wrote:
> The traffic is too short and bursty to be of any benefit, even when you
> can successfully filter it so that no other operations are impacted.
I think that would be the biggest trick in order to even ratios - keep
other services unaffected.
I think most DOS traffic is hard to wrangle.
> I also stand by my opinion that DoS does not happen without a reason.
I happen to agree with that %100.
Most of the times I get DOS on my network its either:
2. The EFF
#2 doesn't happen that often, but when it does, its sortof entertaining to
figure out where/what/why. Most people love the EFF, and are happy to help
sort out problems :)
#1 happens more often, but I generally tend to keep a good lot of
direct customers, and the people targeted are customers of customers.
> Those kinds of targets are generally not only engaged in some activity
> which invites attack (such as running an IRC server), they are actively
> encouraging it by their behavior, and probably should be booted anyways
> for other reasons that you just don't know about yet.
I've seen a few ISP's who run IRC servers reserve IP blocks for them, and
only announce said blocks to peers. Seems like a good way to cut down on
the number of people to contact when you have DOS aimed at it.
> The only benefit to having a hefty outbound ratio is that you have plenty
> of headroom to work with when attacks do come in. Unless you happen to
> notice that a large amount of the traffic is coming from certain Asian
> Pacific networks, and intentionally peer with them to setup choke points.
I'd be curious to see in terms of percentages, which networks source the
most DOS and then keep them on INOC-DBA SpeedDial.
I had in fact suggested to a certain Asian Pacific network that we should
peer so that when someone on their network did launch a DOS against one of
my customers, it would only cause problems there :)
Whats next, DOS-NAP?
More information about the NANOG