August 2008 - Test - lists.nanog.org

Re: interger to I P address
by Johnny Eriksson 27 Aug '08

27 Aug '08

> Robert D. Scott wrote: > > The harder way: > > > > Decimal: 1089055123 > > Hex (dashes inserted at octals): 40-E9-A9-93 > > Decimal (of each octet): 64-233-169-147 > > IP Address: 64.233.169.147 > > The Python way > > >>> import socket, struct > >>> socket.inet_ntoa(struct.pack('>l', 1089055123)) > '64.233.169.147' The Tops-10/DDT way: .r ddt DDT 0! 1089055123. lsh 4$x <> $10r$8o0/ 64.,233.,169.,147.,0. ^Z . --Johnny

5 4

RE: Level 3 TPA routing today?
by David Hubbard 27 Aug '08

27 Aug '08

From: Jon Lewis [mailto:jlewis@lewis.org] > > We have gigE to Level3 in Orlando, and saw something happen > around 1pm today. Customers were complaining of latency and > packet loss, and our traffic to/from L3 dropped noticably if > only for a few minutes. It sounded like based on Craig's post yesterday they did have some known issue and were working to resolve it around that time, ~8 pm EST. I turned our gig link to them back on around 4 AM EST and have not had any complaints so far today. Traffic is up compared to yesterday afternoon too, back where it would normally be. The tech I spoke to this morning said he had no knowledge of any issues yesterday, of course my ticket also had none of the information I sent in to them yesterday or even a clear description of what the problem was.... Dave

5 5

Revealed: The Internet's Biggest Security Hole
by Frank 27 Aug '08

27 Aug '08

http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html Two security researchers have demonstrated a new technique to stealthily intercept internet traffic on a scale previously presumed to be unavailable to anyone outside of intelligence agencies like the National Security Agency. The tactic exploits the internet routing protocol BGP (Border Gateway Protocol) to let an attacker surreptitiously monitor unencrypted internet traffic anywhere in the world, and even modify it before it reaches its destination. The demonstration is only the latest attack to highlight fundamental security weaknesses in some of the internet's core protocols. Those protocols were largely developed in the 1970s with the assumption that every node on the then-nascent network would be trustworthy. The world was reminded of the quaintness of that assumption in July, when researcher Dan Kaminsky disclosed<http://blog.wired.com/27bstroke6/2008/07/details-of-dns.html>a serious vulnerability in the DNS system. Experts say the new demonstration targets a potentially larger weakness. "It's a huge issue. It's at least as big an issue as the DNS issue, if not bigger," said Peiter "Mudge" Zatko, noted computer security expert and former member of the L0pht hacking group, who testified to Congress in 1998 that he could bring down the internet in 30 minutes using a similar BGP attack, and disclosed privately to government agents how BGP could also be exploited to eavesdrop. "I went around screaming my head about this about ten or twelve years ago.... We described this to intelligence agencies and to the National Security Council, in detail." The man-in-the-middle attack exploits BGP to fool routers into re-directing data to an eavesdropper's network. Anyone with a BGP router (ISPs, large corporations or anyone with space at a carrier hotel<http://www.fubra.com/blog/2007/10/mac-mini-bgp-routers-part-2.html>) could intercept data headed to a target IP address or group of addresses. The attack intercepts only traffic headed *to* target addresses, not from them, and it can't always vacuum in traffic within a network -- say, from one AT&T customer to another. The method conceivably could be used for corporate espionage, nation-state spying or even by intelligence agencies looking to mine internet data without needing the cooperation of ISPs. BGP eavesdropping has long been a theoretical weakness, but no one is known to have publicly demonstrated it until Anton "Tony" Kapela, data center and network director at 5Nines Data <http://www.5ninesdata.com/>, and Alex Pilosov, CEO of Pilosoft <http://www.pilosoft.com/>, showed their technique at the recent DefCon hacker conference. The pair successfully intercepted traffic bound for the conference network and redirected it to a system they controlled in New York before routing it back to DefCon in Las Vegas. The technique, devised by Pilosov, doesn't exploit a bug or flaw in BGP. It simply exploits the natural way BGP works. "We're not doing anything out of the ordinary," Kapela told Wired.com. "There's no vulnerabilities, no protocol errors, there are no software problems. The problem arises (from) the level of interconnectivity that's needed to maintain this mess, to keep it all working." The issue exists because BGP's architecture is based on trust. To make it easy, say, for e-mail from Sprint customers in California to reach Telefonica customers in Spain, networks for these companies and others communicate through BGP routers to indicate when they're the quickest, most efficient route for the data to reach its destination. But BGP assumes that when a router says it's the best path, it's telling the truth. That gullibility makes it easy for eavesdroppers to fool routers into sending them traffic. Here's how it works. When a user types a website name into his browser or clicks "send" to launch an e-mail, a Domain Name System server produces an IP address for the destination. A router belonging to the user's ISP then consults a BGP table for the best route. That table is built from announcements, or "advertisements," issued by ISPs and other networks -- also known as Autonomous Systems, or ASes -- declaring the range of IP addresses, or IP prefixes, to which they'll deliver traffic. The routing table searches for the destination IP address among those prefixes. If two ASes deliver to the address, the one with the more specific prefix "wins" the traffic. For example, one AS may advertise that it delivers to a group of 90,000 IP addresses, while another delivers to a subset of 24,000 of those addresses. If the destination IP address falls within both announcements, BGP will send data to the narrower, more specific one. To intercept data, an eavesdropper would advertise a range of IP addresses he wished to target that was narrower than the chunk advertised by other networks. The advertisement would take just minutes to propagate worldwide, before data headed to those addresses would begin arriving to his network. The attack is called an IP hijack and, on its face, isn't new. But in the past, known IP hijacks have created outages, which, because they were so obvious, were quickly noticed and fixed. That's what occurred earlier this year when Pakistan Telecom inadvertently<http://news.bbc.co.uk/1/hi/technology/7262071.stm>hijacked YouTube traffic from around the world. The traffic hit a dead-end in Pakistan, so it was apparent to everyone trying to visit YouTube that something was amiss. Pilosov's innovation is to forward the intercepted data silently to the actual destination, so that no outage occurs. Ordinarily, this shouldn't work -- the data would boomerang back to the eavesdropper. But Pilosov and Kapela use a method called AS path prepending that causes a select number of BGP routers to reject their deceptive advertisement. They then use these ASes to forward the stolen data to its rightful recipients. "Everyone ... has assumed until now that you have to break something for a hijack to be useful," Kapela said. "But what we showed here is that you don't have to break anything. And if nothing breaks, who notices?" Stephen Kent, chief scientist for information security at BBN Technologies, who has been working on solutions to fix the issue, said he demonstrated a similar BGP interception privately for the Departments of Defense and Homeland Security a few years ago. Kapela said network engineers might notice an interception if they knew how to read BGP routing tables, but it would take expertise to interpret the data. A handful of academic groups <http://www.routeviews.org/> collect BGP routing information <http://bgpmon.netsec.colostate.edu/index.html> from cooperating ASes to monitor BGP updates that change traffic's path. But without context, it can be difficult to distinguish a legitimate change from a malicious hijacking. There are reasons traffic that ordinarily travels one path could suddenly switch to another -- say, if companies with separate ASes merged, or if a natural disaster put one network out of commission and another AS adopted its traffic. On good days, routing paths can remain fairly static. But "when the internet has a bad hair day," Kent said, "the rate of (BGP path) updates goes up by a factor of 200 to 400." Kapela said eavesdropping could be thwarted if ISPs aggressively filtered to allow only authorized peers to draw traffic from their routers, and only for specific IP prefixes. But filtering is labor intensive, and if just one ISP declines to participate, it "breaks it for the rest of us," he said. "Providers can prevent our attack absolutely 100 percent," Kapela said. "They simply don't because it takes work, and to do sufficient filtering to prevent these kinds of attacks on a global scale is cost prohibitive." Filtering also requires ISPs to disclose the address space for all their customers, which is not information they want to hand competitors. Filtering isn't the only solution, though. Kent and others are devising processes to authenticate ownership of IP blocks, and validate the advertisements that ASes send to routers so they don't just send traffic to whoever requests it. Under the scheme, the five regional internet address registries would issue signed certificates to ISPs attesting to their address space and AS numbers. The ASes would then sign an authorization to initiate routes for their address space, which would be stored with the certificates in a repository accessible to all ISPs. If an AS advertised a new route for an IP prefix, it would be easy to verify if it had the right to do so. The solution would authenticate only the first hop in a route to prevent unintentional hijacks, like Pakistan Telecom's, but wouldn't stop an eavesdropper from hijacking the second or third hop. For this, Kent and BBN colleagues developed Secure BGP (SBGP), which would require BGP routers to digitally sign with a private key any prefix advertisement they propagated. An ISP would give peer routers certificates authorizing them to route its traffic; each peer on a route would sign a route advertisement and forward it to the next authorized hop. "That means that nobody could put themselves into the chain, into the path, unless they had been authorized to do so by the preceding AS router in the path," Kent said. The drawback to this solution is that current routers lack the memory and processing power to generate and validate signatures. And router vendors have resisted upgrading them because their clients, ISPs, haven't demanded it, due to the cost and man hours involved in swapping out routers. Douglas Maughan, cybersecurity research program manager for the DHS's Science and Technology Directorate, has helped fund research at BBN and elsewhere to resolve the BGP issue. But he's had little luck convincing ISPs and router vendors to take steps to secure BGP. "We haven't seen the attacks, and so a lot of times people don't start working on things and trying to fix them until they get attacked," Maughan said. "(But) the YouTube (case) is the perfect example of an attack where somebody could have done much worse than what they did." ISPs, he said, have been holding their breath, "hoping that people don't discover (this) and exploit it." "The only thing that can force them (to fix BGP) is if their customers ... start to demand security solutions," Maughan said.

2 1

US government mandates? use of DNSSEC by federal agencies
by Bill Bogstad 27 Aug '08

27 Aug '08

Not sure what this will actually mean in the long run, but it's at least worth noting. http://www.gcn.com/online/vol1_no1/46987-1.html http://www.whitehouse.gov/omb/memoranda/fy2008/m08-23.pdf Bill Bogstad

8 16

sharktech.net hosts irc-server for botnets
by Ingo Flaschberger 27 Aug '08

27 Aug '08

Dear community, sharktech.net hosts irc-server for botnets and does not respond to abuse notifications. Kind regards, ingo flaschberger geschaeftsleitung --------------------------- netstorage-crossip-flat:fee powered by crossip communications gmbh --------------------------- sebastian kneipp gasse 1 a-1020 wien fix: +43-1-726 15 22-217 fax: +43-1-726 15 22-111 ---------------------------

1 0

Level 3 TPA routing today?
by David Hubbard 27 Aug '08

27 Aug '08

Anyone seeing issues with Level 3 between anywhere and Tampa, particularly Atlanta and Dallas? We've seen lots of outbound issues and customers calling about their sites being down or slow. Ultimately turned our two links to them off and then everyone says looks better. I opened a ticket with them and of course they say no one has reported any issues whatsoever. I sent them a bunch of traces and will try turning them back on later tonight since these non-issues tend to resolve themselves if I wait for a single homed customer to yell loud enough for them to fix it. Thanks, David

8 7

Invalid contact for EP.net / OrgName: JAM
by Chris Stebner 27 Aug '08

27 Aug '08

Anyone with leads on contact info for them? The POC for the ORG: JAM, WM110-ARIN </whois/?queryinput=P%20%21%20WM110-ARIN>, has an invalid phone number (goes to general delivery ATT handler) the email seems to go nowhere as well. Its listed as: Name: Manning, Bill Handle: WM110-ARIN </whois/?queryinput=WM110-ARIN> Company: Address: PO 12317 City: Marina del Rey StateProv: CA PostalCode: 90295 Country: US Comment: RegDate: Updated: 2001-12-17 Phone: +1-310-322-8102 (Office) Email: bmanning(a)karoshi.com Seems to me its a rather large allocation (/15 & /16) not to have contact info for? A customer of mine purchased a block from them some time back and I still need them(JAM) to get rDNS setup. Any help is much appreciated. Regards, Chris

2 2

RE: interger to I P address
by Boyd, Benjamin R 27 Aug '08

27 Aug '08

>>> The harder way: >>> >>> Decimal: 1089055123 >>> Hex (dashes inserted at octals): 40-E9-A9-93 Decimal (of >each octet): >>> 64-233-169-147 IP Address: 64.233.169.147 >> >> The Python way >> >> >>> import socket, struct >> >>> socket.inet_ntoa(struct.pack('>l', 1089055123)) >> '64.233.169.147' > >The Perl way: > >sub ntoa >{ > my $one = shift; > my $four = $one & 0xff; > $one >>= 8; > my $three = $one & 0xff; > $one >>= 8; > my $two = $one & 0xff; > $one >>= 8; > return "$one.$two.$three.$four"; >} > >#or in one line, like ipcalc does: >sub ntoa_in_one_line { join(".", unpack("CCCC", pack("N", $_[0]))); } > >print ntoa(1089055123) . "\n"; >print ntoa_in_one_line(1089055123) . "\n"; > > The PHP way: function convertIntegerToIpv4($integer) { $max_value = pow(2,32); //4,294,967,296 $bug_fix = 0; settype($integer, float); if($integer > 2147483647) $bug_fix = 16777216; if(is_numeric($integer)) { if ($integer >= $max_value || $integer < 0) { return ('Not a valid IPv4 integer'); } $ip = (sprintf("%u.%u.%u.%u", $integer / 16777216, (($integer % 16777216) + $bug_fix) / 65536, (($integer % 65536) + $bug_fix / 256) / 256, ($integer % 256) + $bug_fix / 256 / 256 ) ); return($ip); } else { return(''); } } *************************************************************************************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else.

2 1

interger to I P address
by chartley＠oar.net 27 Aug '08

27 Aug '08

Sorry to be continuing this thread, but I find a certain kind of elegance in bash which isn't actually there, but helps me sleep at night. bash# iptoint(){ oct1=`echo $1|awk -F\. '{print $1}'`; oct2=`echo $1|awk -F\. '{print $2}'`; oct3=`echo $1|awk -F\. '{print $3}'`; oct4=`echo $1|awk -F\. '{print $4}'`; echo $[($oct1<<24)+($oct2<<16 )+($oct3<<8)+$oct4 ];} bash# inttoip(){ echo $[$1>>24].$[($1>>16)&255].$[($1>>8)&255].$[$1&255]; } bash# inttoip 1089055123 64.233.169.147 bash# iptoint 64.233.169.147 1089055123 Chris

5 4

Re: interger to I P address
by bfeeny＠mac.com 27 Aug '08

27 Aug '08

The NANOG way: www.google.com ------Original Message------ From: Boyd, Benjamin R To: Andree Toonk To: nanog(a)nanog.org Sent: Aug 27, 2008 12:38 PM Subject: RE: interger to I P address >>> The harder way: >>> >>> Decimal: 1089055123 >>> Hex (dashes inserted at octals): 40-E9-A9-93 Decimal (of >each octet): >>> 64-233-169-147 IP Address: 64.233.169.147 >> >> The Python way >> >> >>> import socket, struct >> >>> socket.inet_ntoa(struct.pack('>l', 1089055123)) >> '64.233.169.147' > >The Perl way: > >sub ntoa >{ > my $one = shift; > my $four = $one & 0xff; > $one >>= 8; > my $three = $one & 0xff; > $one >>= 8; > my $two = $one & 0xff; > $one >>= 8; > return "$one.$two.$three.$four"; >} > >#or in one line, like ipcalc does: >sub ntoa_in_one_line { join(".", unpack("CCCC", pack("N", $_[0]))); } > >print ntoa(1089055123) . "\n"; >print ntoa_in_one_line(1089055123) . "\n"; > > The PHP way: function convertIntegerToIpv4($integer) { $max_value = pow(2,32); //4,294,967,296 $bug_fix = 0; settype($integer, float); if($integer > 2147483647) $bug_fix = 16777216; if(is_numeric($integer)) { if ($integer >= $max_value || $integer < 0) { return ('Not a valid IPv4 integer'); } $ip = (sprintf("%u.%u.%u.%u", $integer / 16777216, (($integer % 16777216) + $bug_fix) / 65536, (($integer % 65536) + $bug_fix / 256) / 256, ($integer % 256) + $bug_fix / 256 / 256 ) ); return($ip); } else { return(''); } } *************************************************************************************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. Sent from my Verizon Wireless BlackBerry

1 0