Anybody have a pointer to scripts to map IP to AS?
There are still 10K-20K hosts spewing M$SQL slammer/sapphire packets,
and I'd like to start blocking routing to those irresponsible AS's
that haven't blocked their miscreant customers.
Anybody have a pointer to scripts to map IP to AS?
Google is your friend 
There are still 10K-20K hosts spewing M$SQL slammer/sapphire packets,
and I'd like to start blocking routing to those irresponsible AS's
that haven't blocked their miscreant customers.
Then you'd better reach over to all of your upstream routers and just pull
the plug, since you are likely to see Sapphire packets from here on in, on a
regular basis.
Of course, if blocking "irresponsible isp's" is really your agenda, you'd
better start blocking those with Code Red/Nimda, Slapper, etc...
Enjoy your private corner of the world, devoid of connectivity...
Anybody have a pointer to scripts to map IP to AS?
I suspect the easiest thing to do would be to write some code to query a
looking glass, perhaps even install your own for this....
There are still 10K-20K hosts spewing M$SQL slammer/sapphire packets,
and I'd like to start blocking routing to those irresponsible AS's
that haven't blocked their miscreant customers.
but automatically blocking AS's that send some 1434/udp traffic your way
sounds like a really bad idea and would setup an easy way to DoS your
network by "tricking" you into blocking certain AS's. Why not just block
1434/udp at your ingress points and be happy?
> Anybody have a pointer to scripts to map IP to AS?
Google is your friend
> There are still 10K-20K hosts spewing M$SQL slammer/sapphire packets,
> and I'd like to start blocking routing to those irresponsible AS's
> that haven't blocked their miscreant customers.Then you'd better reach over to all of your upstream routers and just pull
the plug, since you are likely to see Sapphire packets from here on in, on a
regular basis.
Better is to do the whois lookup and send pre-formatted e-mail about the infected server as people did after Code-Red.
-Hank
There are still 10K-20K hosts spewing M$SQL slammer/sapphire packets,
and I'd like to start blocking routing to those irresponsible AS's
that haven't blocked their miscreant customers.
Its too early for such harsh measures. Unless you can live without
most major consumer ISPs.
I don't have the AS data handy. but here a quick list of the top 20
domains with number of Sapphire infected hosts:
948 uu.net ( 943 of which are 'da.uu.net' )
796 attbi.com ( 501 are client.attbi.com. 295 client2.attbi.com. )
490 qwest.net ( 488 are da.qwest.net )
445 att.net ( 438 are dial-access.att.net)
416 rr.com
408 btopenworld.com
395 rasserver.net
376 comcast.net
333 ipt.aol.com
304 com.br
279 pacbell.net
272 tpnet.pl
267 dsl-verizon.net
259 net.au
253 ttd.es
243 cable.rogers.com
224 mindspring.com (152 are dialup.mindspring.com)
220 dyn.optonline.net
217 net.br
205 ne.jp
>Then you'd better reach over to all of your upstream routers and just pull
>the plug, since you are likely to see Sapphire packets from here on in, on a
>regular basis.Better is to do the whois lookup and send pre-formatted e-mail about the
infected server as people did after Code-Red.
We are doing that with the reports we get for DShield. However, in particular
with consumer ISPs, there does not seem to be too much effort to notify
infected customers.
On the other hand, how hard is it for an ISP to monitor port 1434 and call
up a customer whenever there is a 'flareup'? I think this would be the easiest
way to get rid of this problem. I see that port 80 / code red is harder as
it essentially requires content inspection. But Sapphire should be rather
easy to detect by watching outbound traffic.
On Thu, Feb 20, 2003 at 08:09:31AM -0500, William Allen Simpson quacked:
Anybody have a pointer to scripts to map IP to AS?
There are still 10K-20K hosts spewing M$SQL slammer/sapphire packets,
and I'd like to start blocking routing to those irresponsible AS's
that haven't blocked their miscreant customers.
You can use a quick perl wrapper around whois, or you
could use this terribly ugly hacked up traceroute-ng that I
wrote to do lookups:
http://nms.lcs.mit.edu/software/ron/lookup_as.c
Compile with
gcc -DSTANDALONE=1 lookup_as.c -o lookup_as -lm
And then run. It gets the job done, but it's ugly. 
-Dave
Careful. Many whoisds don't appreciate automated queries & will block YOUR
ip address for sometime if you cross their max query rate threshold.
Dave (and anyone that downloads lookup_as.c),
Grab a newer version of traceroute.c -- There is a CLASSFULL piece of code within the 2.9.3 code-base used in lookup_as.c. The newer traceroute.c code removes the 192/8 & 128/8 testing. This is a cut-n-paste from the newer traceroute-nanog-6.3.0/traceroute.c. It can be cut-n-pasted into your code...
/*
* Lookup origin of the net in radb.
*/char *lookup_as(in)
struct in_addr in;
{
static char query[100];
static unsigned char *addr_ptr;
static char *sp;
char *get_origin();addr_ptr = (unsigned char *) (&in.s_addr);
#ifdef FORCE_NATURAL_MASK
if (addr_ptr[0] >= 192) {
sprintf (query, "%d.%d.%d.0",addr_ptr[0],addr_ptr[1],addr_ptr[2]);
} else if (addr_ptr[0] >= 128) {
sprintf (query, "%d.%d.0.0",addr_ptr[0],addr_ptr[1]);
} else {
sprintf (query, "%d.0.0.0",addr_ptr[0]);
}
#else
sprintf (query,"%d.%d.%d.%d",addr_ptr[0],addr_ptr[1],addr_ptr[2],addr_ptr[3]);
#endif /* FORCE_NATURAL_MASK */sp = get_origin(query);
/* printf("as_lookup: get_origin returned %d\n",sp); */
if (0==sp) {
return((char *)&nullstring);
} else {
return(sp);
}}
Or you could use the following shell script...
#!/bin/sh
exec whois "$1@whois.ra.net"
...which is somewhat quicker and does what lookup_as.c does.
Martin
I should have been a bit more specific. The hacked up traceroute-ng
queries the radb, not a whoisd. I've never had problems
being blocked when doing radb queries, but YMMV, of course. I also
suggest that people be nice and rate-limit their queries so that
others don't have to do it for them...
-Dave
On Thu, Feb 20, 2003 at 12:04:51PM -0500, George Bakos quacked:
M$SQL is different from other infections mentioned, as it hits the
entire net so quickly. The only thing keeping it in bay is widespread
backbone filtering, which isn't feasible in the long term.
Just like random source addresses, the only answer is edge filtering
(preventing the bad packets from reaching the backbones).
Worse, it only takes 1 infected host to re-infect the entire net in
about 10 minutes. So, the entire 'net has to cooperate, or we'll see
continual re-infection.
Unfortunately, this is a cost that prevents pain to others, rather
than self-inflicted pain. Another pollution of the commons issue.
Johannes Ullrich wrote:
We are doing that with the reports we get for DShield. However, in particular
with consumer ISPs, there does not seem to be too much effort to notify
infected customers.
That is the problem! There are only 2 incentives that I'm aware of:
1) blocking routing to that AS (fast).
2) sue the AS as a nuisance (slow).
It has been 3 weeks. Those that haven't implemented edge filtering are
bad actors, and need an incentive to clean up their act.
On the other hand, how hard is it for an ISP to monitor port 1434 and call
up a customer whenever there is a 'flareup'? I think this would be the easiest
way to get rid of this problem. I see that port 80 / code red is harder as
it essentially requires content inspection. But Sapphire should be rather
easy to detect by watching outbound traffic.
I agree!
Grab a routing table snapshot from the routeviews archive and run it through
parse_bgp_dump from CAIDA's CoralReef package. Then use CAIDA::ASFinder or
Net::Patricia to do the lookups.
Bradley
You could just rune trace from a cisco router (or do a trace from a looking glass). It shows the AS numbers along the path. Just pick out the last one. It also has the advantage of telling you who is really announcing it at this time rather then who ‘should’ be announcing it.
Guessing a script could be written using RANCID or some code from lookingglass quite quickly.
Tracing the route to w2.scd.yahoo.com (66.218.71.81)
1 sjc3-core5-pos6-0.atlas.algx.net (165.117.48.62) 204 msec 204 msec 200 msec
2 sjc3-yahoo.peer.algx.net (165.117.67.110) 200 msec 200 msec 4 msec
3 ge-0-0-0-p32.pat2.pao.yahoo.com (216.115.100.76) [AS 10310] 200 msec 0 msec
ge-0-0-0-p31.pat2.pao.yahoo.com (216.115.100.68) [AS 10310] 200 msec
4 vl28.bas1.scd.yahoo.com (216.115.101.42) [AS 10310] 200 msec 204 msec 200 msec
5 w2.scd.yahoo.com (66.218.71.81) [AS 26101] 0 msec 204 msec 228 msec
Worse, it only takes 1 infected host to re-infect the entire net in
about 10 minutes. So, the entire 'net has to cooperate, or we'll see
continual re-infection.
Only if people didn't fix their servers. And if they didn't, this
"reverse" denial of service attack is a good reminder.
Unfortunately, this is a cost that prevents pain to others, rather
than self-inflicted pain. Another pollution of the commons issue.
Seems to me that filtering is no longer necessary unless you have reason
to believe your customers are going to install new vulnerable boxes or
vulnerable software on existing boxes AND their pipe to you is so big
the excess traffic is going to hurt you more than them.
This little script works fairly well. Just feed it a file with the each
network on a seperate line. Obviously don't overload the route servers by
running it too often.
"new vulnerable boxes" has to be assumed as the default state for any new
installs, until such time as the vulnerability is patched in the base install,
and has been out for so long that installing the unpatched version will
inspire "ewww that's old" comments...
I've been pretty disappointed with some of the responses on this issue.
Yes, we filter both incoming and outgoing 1434 udp. No, we cannot keep
doing that forever, the router CPU utilization is pretty high. We only
logged for a couple of hours before turning that off (weeks ago)....
I'm of the technical opinion that everyone will need to filter outgoing
1434 udp forever. Yet, since we are (currently) free of infection,
that's the direction we don't _need_ to filter.
Now, some folks have expressed the opinion we should just all drop
filters and let the infected machines DoS our networks, hoping against
experience that the miscreant customers will notice their bad machines
and fix them promptly.
That's technically incompetent!
For one thing, experience shows that the miscreant won't notice they're
infected for DAYS! Why do you think there are 20K+ still infected?
For another thing, I'm happy for all those of you that have such huge
resources to overspecify your networks and equipment. The rest of us
were swamped. We don't have any (that's right: zero zip nil) M$
machines in the operational network (only Linux, *BSD, Macs), and we
still lost all accounting, network management, and basic services,
until the border filters were in place.
Iljitsch van Beijnum wrote:
Maybe the best approach is to try and deliberately infect the entire
local net every few minutes or so to detect new vulnerable systems while
the people installing them are still on the premises.
Gosh, should we do that for every known virus/worm/vulnerability?
Or maybe you don't actually own and/or have legal and financial
accountability for your own network?
Is there anybody around here serious about actually cleaning up the
mess, and thinking of network operational mechanisms to prevent such
things in the future?
Maybe you won't like this one either, but here goes.
I'd be very interested in hearing how opeators feel about 'pushback'.
It may make more sense near ingress edges or where there is limited
aggregate capacity on the egress (a bottleneck), but debating that point
is probably secondary.
You can refer to some of the material, particularly by Bellovin, Floyd
and others here:
<http://www.icir.org/pushback/>
In the simplest scenario, pushback could be similarly deployed to the
way RED is deployed (if you consider that easy or useful or not, I'm not
sure). Signals do not even necessarily need to propagate to upstream
routers, rather anomalous traffic (based on a simple, hopefully, policy)
could be dropped more aggressively. This response could be automatic or
require intervention. I think there are a number interesting properties
to this approach, especially since if it behaves similar as one might
hope, it could still allow some valid traffic through. Hint: think
about what will happen if a Slammer/Sapphire-like worm hits port
25/53/80 and cannot be easily filtered without affecting all traffic on
those ports.
Coming up with a policy that determines what is anomalous is one of the
hard parts. Vendor implementation being another, but you can kind of do
this sort of thing already if you're so inclined.
Thoughts?
John
I'd be very interested in hearing how opeators feel about 'pushback'.
the only interesting thing i have seen in this space
randy
I've been pretty disappointed with some of the responses on this issue.
I'm of the technical opinion that everyone will need to filter outgoing
1434 udp forever.
Forget it. That's a port used for legitimate traffic. Besides, filtering
on port numbers is a flawed proposition to begin with. The fact that it
more or less works is just luck. Too bad we can't filter on competence.
Now, some folks have expressed the opinion we should just all drop
filters and let the infected machines DoS our networks, hoping against
experience that the miscreant customers will notice their bad machines
and fix them promptly.
That's technically incompetent!
Thank you. I agree that at this time it is often not feasible to simply
not filter. But that's certainly the place I want to be in the future.
If a customer wants to spew out 50 Mbps worth of UDP I don't want that
to influence my network. So either I forward the traffic and the
customer pays for the bandwidth or I rate limit it and they live with
the packet loss.
For one thing, experience shows that the miscreant won't notice they're
infected for DAYS! Why do you think there are 20K+ still infected?
Most of those are dial-up so their traffic isn't all that much and
they're hard to track down. Depending on how the OS works, such a host
may not even experience a very significant slowdown.
For another thing, I'm happy for all those of you that have such huge
resources to overspecify your networks and equipment. The rest of us
were swamped. We don't have any (that's right: zero zip nil) M$
machines in the operational network (only Linux, *BSD, Macs), and we
still lost all accounting, network management, and basic services,
until the border filters were in place.
Strange.
By the way: I manage ~ 4 networks. One just upgraded to "huge resources"
and they didn't feel the extra 100 Mbps traffic from two infected
customer boxes (I filtered it anyway, good netizen as I am). Another has
more or less adequate resources; one router also had 2 infected boxes on
the local network but this one could handle it. The next router (behind
a 1:3 funnel) had a meltdown even though the hardware is identical.
Always use CEF, kids. Two other networks are more or less underpowered,
but no real trouble (one also with two infected boxes).