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. http://isc.sans.org/port_details.html?port=1434 -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
On Thu, 20 Feb 2003, William Allen Simpson wrote:
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... -- Yours, J.A. Terranson sysadmin@mfn.org
At 08:07 AM 20-02-03 -0600, Alif The Terrible wrote:
On Thu, 20 Feb 2003, William Allen Simpson wrote:
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
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...
-- Yours, J.A. Terranson sysadmin@mfn.org
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.
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! -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
On Thu, 20 Feb 2003, William Allen Simpson wrote:
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.
On Thu, 20 Feb 2003 22:11:06 +0100, Iljitsch van Beijnum said:
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
"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? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
On Fri, 21 Feb 2003 17:25:46 -0500 William Allen Simpson <wsimpson@greendragon.com> wrote:
I've been pretty disappointed with some of the responses on this issue.
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
On Fri, 21 Feb 2003, William Allen Simpson wrote:
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).
I'll bite.. ----- Original Message ----- From: "William Allen Simpson" <wsimpson@greendragon.com> To: <nanog@merit.edu> Sent: Friday, February 21, 2003 2:25 PM Subject: Re: M$SQL cleanup incentives [snip]
I'm of the technical opinion that everyone will need to filter outgoing 1434 udp forever. [snip] 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?
Which is it? Where do you draw the line between something that's big enough to block forever and something that's not worth tracking down? You lambast him for attempting a solution that is foolish to apply for every known possible problem where if your solution was applied as such, we'd have a swiss-cheese internet in which any commonly used destination port is blocked due to the scads of IIS/bind/fingerd/ftpd/whatever worms. Have fun filtering.
Or maybe you don't actually own and/or have legal and financial accountability for your own network?
Or maybe he likes having a network his customers can actually use. --Doug
Doug Clements wrote:
Which is it? Where do you draw the line between something that's big enough to block forever and something that's not worth tracking down?
Where it causes a network meltdown. The objective reality is pretty clear to some (many? most?) of us.
You lambast him for attempting a solution that is foolish to apply for every known possible problem
You bet I do!
where if your solution was applied as such, we'd have a swiss-cheese internet in which any commonly used destination port is blocked due to the scads of IIS/bind/fingerd/ftpd/whatever worms.
In one part of your response, you note I don't advocate a 1-size-fits- all solution, and then the second part, assume 1-size-fits-all. That's inconsistent logic in your argument.
Have fun filtering.
Filtering is not fun. That's why I'm trying to get everyone to cooperate in eradication of this particular problem, so that we could drop filters. (Look at the subject line.) Right now, whether you know it or not, filtering is all that's holding the Internet as a whole together.... If you didn't filter, you're actually depending on the good graces of the rest of us that did! Should we start using more loaded words, like "parasite"? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
On Sat, Feb 22, 2003 at 09:25:24AM -0500, William Allen Simpson wrote:
Doug Clements wrote:
Which is it? Where do you draw the line between something that's big enough to block forever and something that's not worth tracking down?
Where it causes a network meltdown. The objective reality is pretty clear to some (many? most?) of us.
I see. So you're still filtering port 25 from the Morris sendmail worm. The issue I had with your argument is "forever". You should realize as well as anyone that the course of software development and implementation will mitigate the threats of the slammer worm until it's nothing more than a bad memory.
Filtering is not fun. That's why I'm trying to get everyone to cooperate in eradication of this particular problem, so that we could drop filters. (Look at the subject line.)
The first step in eradication is detection. I presume that since you're taking this stance, you're checking your filter logs and attempting to notify the appropriate partys for each hit. If you're not, then our buddy trying to infect all the machines on his network every so often is being more effective in wiping out the worm.
Right now, whether you know it or not, filtering is all that's holding the Internet as a whole together.... If you didn't filter, you're actually depending on the good graces of the rest of us that did!
If you "didn't" filter or "don't" filter? We definately filtered when the worm first came out. We don't block port 1433 anymore (nor does any of our upstreams), but we still report suspicious traffic. Regardless of what everyone else is doing, the worm is not causing a meltdown anymore. The correct course of action is to remove filters as resources allow, and investigate infected machines as they are noticed. I'm sorry, but I'm not seeing your case for implementing permament filters for this or anything else. --Doug
On Sat, 22 Feb 2003, Doug Clements wrote:
The issue I had with your argument is "forever". You should realize as well as anyone that the course of software development and implementation will mitigate the threats of the slammer worm until it's nothing more than a bad memory.
Unlikely in this case. A reasonably fast system infected with slammer is capable of generating enough traffic to make the Cisco 2900XL switch its plugged into incapable of passing normal traffic. All it takes is one infected customer's system to really foul up the network it's attached to. The only plus side is, this is perfect justification to management for replacing any switches customers connect to with newer ones that (at least claim to) do per-port rate limiting. If your network is able to contain slammer infected boxes without melting down, who cares if you have a few infected customers? You don't need to filter, and they'll all be encouraged to fix their systems sooner. I setup inbound 1434/udp filters the 3rd time we had a customer (different ones each time) get (re-?)infected weeks after the initial outbreak. Sure, some DNS replies and assorted other packets will get dropped, but AFAIK, nobody has complained or even noticed...and we've had no more re-infections since the filters were put in place. I don't believe we'll have to filter 1434/udp forever, but I plan to leave the filters in place until we no longer need them or until they hurt more than they help. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Thus spake <jlewis@lewis.org>
If your network is able to contain slammer infected boxes without melting down, who cares if you have a few infected customers? You don't need to filter, and they'll all be encouraged to fix their systems sooner.
As one hoster put it to me, DoS and worm traffic is billable so it's not in the hoster's interests to protect customers -- quite the opposite in fact.
I don't believe we'll have to filter 1434/udp forever, but I plan to leave the filters in place until we no longer need them or until they hurt more than they help.
What will you do when a similar worm appears on 53/udp or some other heavily-used port? We lucked out with Sapphire because MS/SQL is generally safe to block on public networks, but its speed can be easily applied to other protocols we can't afford to block. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Sat, 22 Feb 2003, Stephen Sprunk wrote:
As one hoster put it to me, DoS and worm traffic is billable so it's not in the hoster's interests to protect customers -- quite the opposite in fact.
Whether or not the traffic is billable is irrelevant if your network is effectively down. One infected host connected to a 2900XL effectively kills the switch. I was fortunate enough to be on vacation and not even have net access when the initial slammer wave hit. But when I was back and on-call, we had a single customer get (re-?)infected, killing the switch they were on and noticably slowing down the network for the whole POP.
What will you do when a similar worm appears on 53/udp or some other heavily-used port? We lucked out with Sapphire because MS/SQL is generally
Be screwed unless we've completed planned upgrades. But in this case, I can filter until we've upgraded our network to hardware that's better able to deal with such traffic. Just because filtering might not always work doesn't mean it shouldn't be done when it does work. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Doug Clements wrote:
I see. So you're still filtering port 25 from the Morris sendmail worm.
Funny thing, I was a researcher visiting at Cornell, and had just left in the car for the 9.5 hour drive home when it struck. I've often wished I'd stuck around for a few more hours for the excitement. Anyway, we didn't need to put in a long term block, as everyone took down their systems and cleaned them. I didn't even find out about the problem until over a day later, by which time it was long gone. Ah, the days when we all cooperated.... Well, of course, there were fewer systems involved. ;-) Then again, there were fewer people to fix them, too.
The issue I had with your argument is "forever". You should realize as well as anyone that the course of software development and implementation will mitigate the threats of the slammer worm until it's nothing more than a bad memory.
Sure. I'll be happy to modify that *forever* to "when all M$ systems have been cleaned and updated." Let us all know when that happens, will you?
The first step in eradication is detection. I presume that since you're taking this stance, you're checking your filter logs and attempting to notify the appropriate partys for each hit.
For some silly reason, not all operators are notifying their own customers, even when reported. Anyway, we passed the detection phase long ago, and the second step in eradication is quarantine. That's what I'm talking about!
If you're not, then our buddy trying to infect all the machines on his network every so often is being more effective in wiping out the worm.
Fascinating. I'm sure his legal department will have an opinion on that. However, we could help protect him from legal issues by adopting self-help as a "Best Current Practice." Are you ready and willing to write up the internet-draft?
If you "didn't" filter or "don't" filter? We definately filtered when the worm first came out. We don't block port 1433 anymore (nor does any of our upstreams), but we still report suspicious traffic. Regardless of what everyone else is doing, the worm is not causing a meltdown anymore.
The reason is that many of us are _still_ filtering. Some who removed filters put them back.
correct course of action is to remove filters as resources allow, and investigate infected machines as they are noticed.
Unfortunately, I haven't seen a lot of investigation. Perhaps you can explain why the infection rate is still the same after 3 weeks? Anyway, I'll chalk you in the column for removing all filters, and hoping for the best. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
On Sat, 22 Feb 2003, William Allen Simpson wrote:
I see. So you're still filtering port 25 from the Morris sendmail worm.
Funny thing, I was a researcher visiting at Cornell, and had just left in the car for the 9.5 hour drive home when it struck. I've often wished I'd stuck around for a few more hours for the excitement.
Anyway, we didn't need to put in a long term block, as everyone took down their systems and cleaned them. I didn't even find out about the problem until over a day later, by which time it was long gone.
Ah, the days when we all cooperated....
In 1988 we had ad-hoc responses, with people posting to various USENET newsgroups or some mailing lists still working, about what they were seeing and how to fix it. There was no CERT, BBN (and others) disconnected from the net (and took many people downstream with them), even though most people knew each other they didn't all have alternate contact information, and most of the methods the Morris worm used in 1988 are still being used *effectively* today. 1) Backdoor in SENDMAIL 2) Buffer overflow in Fingerd 3) Password guessing in Rsh/Rexec Some people blocked the ports used. Some people still block ports such as Finger (79) and rsh/rexec (513/514). But generally ports were blocked by the local institution, not on the ARPANET. The version numbers change, the executables change, but the basic problems haven't changed in 30 years. We still have backdoors, buffer overflows and pasword guessing. We still have ad-hoc response by people sharing solutions on mailing lists. The people who cut themselves off from the open process are still slower to get stuff fixed. And we still have weak methods for contacting people through alternate methods. I wish it was as easy as paying a managed security company to watch out for me. But unfortunately, paying several thousand dollars for the privilege of getting "confidential alerts" which look amazingly similar to what I wrote on a public mailing list a few hours earlier is a bit silly.
Sean, Plus ca change, plus c'est le meme chose. Of course the past is with us: look at Bob Metcalfe's RFC 602 (1973). Have we fixed anything over the nearly 30 years? How recently have you seen a password on a Post-It? How many folks have their spouse's/significant other's/ offspring's name as a password? How many uninstalled fixes can dance on a port? Peter
On Thu, 20 Feb 2003, William Allen Simpson wrote:
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? ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
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
http://isc.sans.org/port_details.html?port=1434 -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
-- -------------------------------------------------------------------- jullrich@euclidian.com Collaborative Intrusion Detection join http://www.dshield.org
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 -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
Careful. Many whoisds don't appreciate automated queries & will block YOUR ip address for sometime if you cross their max query rate threshold.
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
-- George Bakos Institute for Security Technology Studies Dartmouth College gbakos@ists.dartmouth.edu voice 603-646-0665 fax 603-646-0666 Key fingerprint = D646 8F91 F795 27EC FF8B 8C95 B102 9EB2 081E CB85
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:
Careful. Many whoisds don't appreciate automated queries & will block YOUR ip address for sometime if you cross their max query rate threshold.
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
-- George Bakos Institute for Security Technology Studies Dartmouth College gbakos@ists.dartmouth.edu voice 603-646-0665 fax 603-646-0666 Key fingerprint = D646 8F91 F795 27EC FF8B 8C95 B102 9EB2 081E CB85
-- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
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 --------------------- At 10:07 AM 2/20/2003 -0500, David G. Andersen wrote:
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
-- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
### On Thu, 20 Feb 2003 09:11:02 -0800, "Martin J. Levy" <mahtin@mahtin.com> ### casually decided to expound upon "David G. Andersen" <dga@lcs.mit.edu>, ### William Allen Simpson <wsimpson@greendragon.com> the following thoughts ### about "Re: scripts to map IP to AS?": MJV> Dave (and anyone that downloads lookup_as.c), MJV> MJV> Grab a newer version of traceroute.c -- There is a CLASSFULL piece of code MJV> within the 2.9.3 code-base used in lookup_as.c. The newer traceroute.c MJV> code removes the 192/8 & 128/8 testing. This is a cut-n-paste from the MJV> newer traceroute-nanog-6.3.0/traceroute.c. It can be cut-n-pasted into MJV> your code... Just a reminder to everyone who intends to query the IRR/RADB... Please be nice to the RADB whois server and don't DoS it. Open a persistant connection instead of one for each prefix lookup. For RADB and any other IRR server running IRRd, this can be accomplished by sending a "!!" in the beginning and keeping the connection open on your end in a seperate thread or something that you then issue the query to. For RIPE Whois based IRR servers, use the "-k" flag. -- /*===================[ Jake Khuon <khuon@NEEBU.Net> ]======================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --------------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=========================================================================*/
On Thu, 20 Feb 2003 12:14:28 PST, Jake Khuon <khuon@NEEBU.Net> said:
Just a reminder to everyone who intends to query the IRR/RADB... Please be nice to the RADB whois server and don't DoS it. Open a persistant
Are there any recommendations for caching of the results? Do, don't, not for over 72 hours, etc? I think most people that do an AS-enabled traceroute are always going to be getting the same answers back for the first few hops to *ANYWHERE* - caching at least "your local neighborhood" could dramatically cut the number of queries.... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
### On Thu, 20 Feb 2003 15:25:52 -0500, Valdis.Kletnieks@vt.edu casually ### decided to expound upon khuon@NEEBU.Net (Jake Khuon) the following ### thoughts about "Re: scripts to map IP to AS? ": VK> Are there any recommendations for caching of the results? Do, don't, not for VK> over 72 hours, etc? I think most people that do an AS-enabled traceroute VK> are always going to be getting the same answers back for the first few hops VK> to *ANYWHERE* - caching at least "your local neighborhood" could dramatically VK> cut the number of queries.... Another option would be to download IRRd and run it locally in mirror/caching mode then just point your whois queries to it. -- /*===================[ Jake Khuon <khuon@NEEBU.Net> ]======================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --------------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=========================================================================*/
VK> Date: Thu, 20 Feb 2003 15:25:52 -0500 VK> From: Valdis.Kletnieks JK> Just a reminder to everyone who intends to query the JK> IRR/RADB... Please be nice to the RADB whois server and JK> don't DoS it. Open a persistant connection instead of one VK> Are there any recommendations for caching of the results? Do, VK> don't, not for over 72 hours, etc? I think most people that VK> do an AS-enabled traceroute are always going to be getting VK> the same answers back for the first few hops to *ANYWHERE* - VK> caching at least "your local neighborhood" could dramatically VK> cut the number of queries.... Better yet, a DNS authd that resolves origin-asn.1.0.0.127.in-addr.arpa IN TXT appropriately. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
On Thu, 20 Feb 2003, William Allen Simpson wrote:
Anybody have a pointer to scripts to map IP to AS?
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 At 08:09 AM 2/20/2003 -0500, William Allen Simpson wrote: 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. http://isc.sans.org/port_details.html?port=1434 <http://isc.sans.org/port_details.html?port=1434> -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 -tdawson -tdawson@sprintlabs.com
On Thu, 20 Feb 2003, William Allen Simpson wrote:
Anybody have a pointer to scripts to map IP to AS?
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. -- Simon Lyall. | Newsmaster | Work: simon.lyall@ihug.co.nz Senior Network/System Admin | Postmaster | Home: simon@darkmere.gen.nz Ihug Ltd, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz #!/usr/bin/perl -U $host = "route-server.cerf.net" ; use IO::Socket; open(FILE,"$ARGV[0]"); @length = <FILE>; chop(@length); # Open connection $remote = IO::Socket::INET->new( Proto => "tcp", PeerAddr => $host, PeerPort => 23, ); unless ($remote) { die "cannot connect to remote host $host" } $remote->autoflush(1); # send "sh ip bgp ip" for each ip while($count<@length) { # set AS number to zero $asnum = 0; #print "$length[$count] \n"; # Chop of the /24 /16 bit etc ($network) = split(/\//, $length[$count]); print $remote "show ip bgp $network \n \n"; while (defined ($line = <$remote> )) { # break when we have out first result last if ( $line=~/localpref/ ); last if ( $line=~/not in table/ ); # Checked for Cerf's AS number # print "line is $line \n"; if ($line=~/17233/) { # Get rid of bogus stuff after a "," # print "$line \n"; ($line) = split(/,/, $line); # print "$line \n"; # Grab last number in the list @Fld = split(' ', $line); $asnum=$Fld[$#Fld]; } } # printf "$length[$count]\tAS$asnum.\n"; printf "AS$asnum.\t$length[$count]\n"; open(OUTPUT,">>$ARGV[1]"); printf OUTPUT "AS$asnum.\t$length[$count]\n"; close(OUTPUT); sleep 5; $count++ ; # following clears any extra lines returned by the command. while ( defined ($line = <$remote> )) { last if ( $line=~/route-server/ ); } } # Close conenction. close $remote;
participants (21)
-
Alif The Terrible -
Bradley Dunn -
David G. Andersen -
Doug Clements -
E.B. Dreger -
George Bakos -
Hank Nussbacher -
Iljitsch van Beijnum -
Jake Khuon -
jlewis＠lewis.org -
Johannes Ullrich -
John Kristoff -
Martin J. Levy -
Peter Salus -
Randy Bush -
Sean Donelan -
Simon Lyall -
Stephen Sprunk -
Travis Dawson -
Valdis.Kletnieks＠vt.edu -
William Allen Simpson