just seen my first IPv6 network abuse scan, is this the start for more?
Hi, Since recently we noticed Neighbour table overflow warnings from the kernel on a lot of Linux machines. As this was very annoying for us and our customers I started to dump traffic and tried to find the cause. I discovered a external IPv6 host was doing a (rather useless due to the amount of addresses) IPv6 ICMP scan on our network recurring daily and mostly during the nights, sometimes with speeds of 1000 scans per second. Due to the ammount of IPv6 neighbor discoveries from our routers resulting from this scan the Neighbour table overflow messages appeared on the machines. Are there more people who have seen this behaviour recently? Is this a start of hackers/spammers onto the IPv6 network? This is the first scan I have seen. I already contacted the ISP for the source address. No answer yet. If I have more news I will post them here. regards, Igor Ybema the Netherlands
Re: just seen my first IPv6 network abuse scan, is this the start for more?
Not necessarily so useless, as it was hitting your boxen, eh? True :) Any noticeable effect on router CPU? Not visible in the graphs. A Foundry XMR was the router and all load on the CPU's in the router didn't change anything. regards, Igor
Re: just seen my first IPv6 network abuse scan, is this the start for more?
Hi, Since recently we noticed Neighbour table overflow warnings from the kernel on a lot of Linux machines. As this was very annoying for us and our customers I started to dump traffic and tried to find the cause. sounds for me as an typicall IPv6 DoS attack. (see RFC3756) Sheng Jiang has discussed this issue in his draft: http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 regards, -F signature.asc Description: OpenPGP digital signature
Re: just seen my first IPv6 network abuse scan, is this the start for more?
On Sep 3, 2010, at 6:43 PM, Matthias Flittner wrote: sounds for me as an typicall IPv6 DoS attack. (see RFC3756) GMTA. Suggest checking to see if the targets have in fact been compromised (perhaps co-opted as botnet CCs, malware drop sites, et. al.?), and are being targeted by a rival gang. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
Re: just seen my first IPv6 network abuse scan, is this the start for more?
Sheng Jiang has discussed this issue in his draft: http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 If I understand the RFC correctly it is based on an attack within the same subnet. Looks a lot like arp-flooding. However this scan was from a external host. The only traffic I saw on the subnet was normal/valid NA lookups from the router towards an increasing IPv6-address (starting with ::1, then ::2 etc). On the router side I clearly saw the icmp traffic from the source doing a scan on these destination hosts. None of these IPv6 addresses are alive so no succes in scanning for comprised machines. regards, Igor
Re: just seen my first IPv6 network abuse scan, is this the start for more?
On Sep 3, 2010, at 7:02 PM, Igor Ybema wrote: The only traffic I saw on the subnet was normal/valid NA lookups from the router towards an increasing IPv6-address (starting with ::1, then ::2 etc). This could be a deliberately-induced DDoS due to the annoying ND stuff in IPv6, or just an ICMP sweep. Did it seem to concentrate on certain ranges, were the target addresses progressive, et. al.? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
Re: ISP port blocking practice
On Sep 2, 2010, at 8:54 PM, Patrick W. Gilmore wrote:
On Sep 2, 2010, at 11:48 PM, Owen DeLong wrote:
We should be seeking to stop damaging the network for ineffective anti spam
measures (blocking outbound 25 for example) rather than to expand this
practice to bidirectional brokenness.
Since at least part of your premise ('ineffective anti-spam measures') has
been objectively proven false to fact for many years, I guess we can ignore
the rest of your note.
Really? So, since so many ISPs are blocking port 25, there's lots less spam
hitting our networks?
That's really news to me... I'm still seeing an ever increasing number of
attempts to deliver spam on my mailservers.
I'd say that it has been pretty ineffective.
Also, just so everyone doesn't think I'm in favor of damaging the network,
I would much prefer a completely open 'Net. Who wouldn't? Since that is not
possible, we have to do what we can to damage the network as little as
possible. Port 25 blocking is completely unnoticeable to something on the
order of 5-nines worth of users, and the rest should know how to get around
it with a minimum of fuss (including things like ask your provider to
unblock in many cases).
Not really true. First, i dispute your 5-nines figure, second, yes, i can
usually get around it, but seems each network requires a different workaround.
Since, like many of us, I use a lot of transient networks, having to
reconfigure for each unique set of brokenness is actually wasting more of my
time than the spam this brokenness was alleged to prevent.
I suppose I should just shut up and run an instance of my SMTP daemon on port
80. After all, since IPv4 addresses are so abundant, rather than use port
numbers for services, let's use IP addresses and force everything to ports 80
and 443.
Owen
Re: ISP port blocking practice
On Sep 2, 2010, at 9:08 PM, Jack Bates wrote:
Patrick W. Gilmore wrote:
We should be seeking to stop damaging the network for ineffective anti spam
measures (blocking outbound 25 for example) rather than to expand this
practice to bidirectional brokenness.
Since at least part of your premise ('ineffective anti-spam measures') has
been objectively proven false to fact for many years, I guess we can ignore
the rest of your note.
He's right though. tcp/25 blocks are a hack. Easy man's way out. Honestly,
it'd be nicer if edge or even core systems could easily handle higher level
filtering for things like this. There's plenty of systems that watch traffic
patterns and issue blocks based on those patterns.
I was working with a hotel today concerning just that. They were only doing a
generic 500 connections in x period, block mac. They are now adding a tighter
rule for 15 tcp/25 connections in 1 minute, block tcp/25 (or mac, doesn't
matter to me). Of course, we didn't see valid reasons for mail blasts to be
leaving a hotel and 15/minute is plenty of grace for a normal user. At an ISP
level, it would work fine, though methods for determining exceptions would
have to be planned (though that could easily be handled by customer
classifications like everything else).
This seems to me like it would be much more effective and less damaging without
being significantly harder to implement.
Also, just so everyone doesn't think I'm in favor of damaging the network,
I would much prefer a completely open 'Net. Who wouldn't? Since that is
not possible, we have to do what we can to damage the network as little as
possible. Port 25 blocking is completely unnoticeable to something on the
order of 5-nines worth of users, and the rest should know how to get around
it with a minimum of fuss (including things like ask your provider to
unblock in many cases).
Blocking inbound vs outbound is another story, though. Getting people to
implement spoof protections is more useful. I'd be interested to see your
data for concluding 5-nines of users, or did you just make that up?
I'm all for anti-spoof (BCP-38) and strict/loose (as appropriate) RPF. I
implement those things on networks I run. That's not damage, that's blocking
things that shouldn't happen.
I'd also like to see his data to support his claim that it is somehow effective
at reducing spam.
Owen
Re: ISP port blocking practice
Really? So, since so many ISPs are blocking port 25, there's lots less spam hitting our networks? It's been extremely effective in blocking spam sent by spambots on large ISPs. It's not a magic anti-spam bullet. (If you know one, please let us know.) workaround. Since, like many of us, I use a lot of transient networks, having to reconfigure for each unique set of brokenness is actually wasting more of my time than the spam this brokenness was alleged to prevent. Is there some reason you aren't able to configure your computers to use tunnels or SUBMIT? They seem to work pretty well for other people. R's, John
Re: ISP port blocking practice
On Sep 2, 2010, at 10:41 PM, Franck Martin wrote:
Have you heard of the submission port?
Yes... Many of the idiots that block outbound 25 also block outbound 587 and
sometimes 465.
Why Clients of an hotel would run a MTA anyhow?
Huh? I think you misunderstand... The problem is hotels blocking people from
submitting outbound
messages to their home MTA, not people trying to run an MTA inside their hotel
room. NAT pretty
much guarantees running an MTA inside the hotel room is impossible in most
circumstances.
(That might improve when IPv6 starts hitting hotel rooms, but, for now, it's
just not there).
Yes, some hotels offer you the option of a public IP (and usually when I take
that option, I have
fewer network problems in general. One of the reasons I tend to prefer Hilton
brands when possible.)
Owen
- Original Message -
From: Jack Bates jba...@brightok.net
To: NANOG list nanog@nanog.org
Sent: Friday, 3 September, 2010 4:08:54 PM
Subject: Re: ISP port blocking practice
Patrick W. Gilmore wrote:
We should be seeking to stop damaging the network for ineffective anti spam
measures (blocking outbound 25 for example) rather than to expand this
practice to bidirectional brokenness.
Since at least part of your premise ('ineffective anti-spam measures') has
been objectively proven false to fact for many years, I guess we can ignore
the rest of your note.
He's right though. tcp/25 blocks are a hack. Easy man's way out.
Honestly, it'd be nicer if edge or even core systems could easily handle
higher level filtering for things like this. There's plenty of systems
that watch traffic patterns and issue blocks based on those patterns.
I was working with a hotel today concerning just that. They were only
doing a generic 500 connections in x period, block mac. They are now
adding a tighter rule for 15 tcp/25 connections in 1 minute, block
tcp/25 (or mac, doesn't matter to me). Of course, we didn't see valid
reasons for mail blasts to be leaving a hotel and 15/minute is plenty of
grace for a normal user. At an ISP level, it would work fine, though
methods for determining exceptions would have to be planned (though that
could easily be handled by customer classifications like everything else).
Also, just so everyone doesn't think I'm in favor of damaging the network,
I would much prefer a completely open 'Net. Who wouldn't? Since that is
not possible, we have to do what we can to damage the network as little as
possible. Port 25 blocking is completely unnoticeable to something on the
order of 5-nines worth of users, and the rest should know how to get around
it with a minimum of fuss (including things like ask your provider to
unblock in many cases).
Blocking inbound vs outbound is another story, though. Getting people to
implement spoof protections is more useful. I'd be interested to see
your data for concluding 5-nines of users, or did you just make that up?
Jack
Re: ISP port blocking practice
It may be a recommended practice from MAAWG, but, it's still damage to the network which is often routed around. It's a minor inconvenience to spammers and a slightly bigger problem for legitimate users. I don't see the win here. Just because they recommend it doesn't make it a good recommendation. MAAWG appears to have a single priority... Reducing spam by whatever means possible, regardless of cost or efficacy. Some of their recommendations (most, even) are good and useful. Some are easy to implement, ineffective, and ill-conceived. Outbound blocking of port 25 from people attempting to reach their home MTA/MSA with TLS and SMTP-AUTH just because they don't have a static address is an example of easy to implement, ineffective, and ill-conceived. Owen On Sep 2, 2010, at 8:56 PM, Franck Martin wrote: Blocking outbound port 25 in certain conditions (mainly anything with a dynamic IPv4), is a recommended practice from MAAWG.org and others, they have a few useful documents for ISPs to deal with their network. - Original Message - From: Owen DeLong o...@delong.com To: Zhiyun Qian zhiy...@umich.edu Cc: NANOG list nanog@nanog.org Sent: Friday, 3 September, 2010 3:48:20 PM Subject: Re: ISP port blocking practice We should be seeking to stop damaging the network for ineffective anti spam measures (blocking outbound 25 for example) rather than to expand this practice to bidirectional brokenness. Owen Sent from my iPad On Sep 3, 2010, at 12:25 PM, Zhiyun Qian zhiy...@umich.edu wrote: I skimmed through these specs. They are useful but seems only related specific to IP spoofing prevention. I see that IP spoofing is part of the asymmetric routing story. But I was more thinking that given that IP spoofing is not widely adopted, the other defenses that they can more perhaps more easily implement is to block incoming traffic with source port 25 (if they already decided to block outgoing traffic with destination port 25). But according to our study, most of the ISPs didn't do that at the time of study (probably still true today). -Zhiyun On Sep 2, 2010, at 9:20 PM, Suresh Ramasubramanian wrote: BCP38 / RFC2827 were created specifically to address some quite similar problems. And googling either of those two strings on nanog will get you a lot of griping and/or reasons as to why these aren't being more widely adopted :) --srs On Fri, Sep 3, 2010 at 7:47 AM, Zhiyun Qian zhiy...@umich.edu wrote: Suresh, thanks for your interest. I see you've had a lot of experience in fighting spam, so you must have known this. Yes, I know this spamming technique has been around for a while. But it's surprising to see that the majority of the ISPs that we studied are still vulnerable to this attack. That probably indicates that it is not as widely known as we would expect. So I thought it would be beneficial to raise the awareness of the problem. In terms of more results, the paper is the most detailed document we have. Otherwise, if you interested in the data that we collected (which ISPs or IP ranges are vulnerable to this attack). We can chat offline. Regards. -Zhiyun
Re: ISP port blocking practice
On Sep 3, 2010, at 8:12 AM, Owen DeLong wrote:
On Sep 2, 2010, at 8:54 PM, Patrick W. Gilmore wrote:
On Sep 2, 2010, at 11:48 PM, Owen DeLong wrote:
We should be seeking to stop damaging the network for ineffective anti spam
measures (blocking outbound 25 for example) rather than to expand this
practice to bidirectional brokenness.
Since at least part of your premise ('ineffective anti-spam measures') has
been objectively proven false to fact for many years, I guess we can ignore
the rest of your note.
Really? So, since so many ISPs are blocking port 25, there's lots less spam
hitting our networks?
That's really news to me... I'm still seeing an ever increasing number of
attempts to deliver spam on my mailservers.
I'd say that it has been pretty ineffective.
I'm not even going to bother replying with the multiple fallacies / logical
errors you have made. I've known you for too long to assume you are that
stupid, so I have to assume you are trolling. Which is beneath you.
Also, just so everyone doesn't think I'm in favor of damaging the network,
I would much prefer a completely open 'Net. Who wouldn't? Since that is
not possible, we have to do what we can to damage the network as little as
possible. Port 25 blocking is completely unnoticeable to something on the
order of 5-nines worth of users, and the rest should know how to get around
it with a minimum of fuss (including things like ask your provider to
unblock in many cases).
Not really true. First, i dispute your 5-nines figure
Perhaps a bit of hyperbole. Let's call it 3 nines. And before you dispute
that more than 1 in a thousand notice, I'd like to see even the slightest
shread of evidence.
second, yes, i can usually get around it, but seems each network requires a
different workaround.
My turn to dispute. SSH tunnels work on all but one network I've tried, even
on port 22. And I've tried quite a few networks. Oh, and 100% of those
networks allowed VPN.
If you mean home networks require different hops to get port 25 opened, how
many homes do you have?
Since, like many of us, I use a lot of transient networks, having to
reconfigure for each unique set of brokenness is actually wasting more of my
time than the spam this brokenness was alleged to prevent.
First, life sux. I'm OK causing you more pain to save the 'Net from devolving
into a useless mass of pure abuse.
Second, if you are not following the RFCs and using the submit port, you get no
sympathy.
Third, see above with SSH tunnels VPN.
I suppose I should just shut up and run an instance of my SMTP daemon on port
80. After all, since IPv4 addresses are so abundant, rather than use port
numbers for services, let's use IP addresses and force everything to ports 80
and 443.
Or you could follow the rules and use SUBMIT.
But I agree with the just shut up part. :)
--
TTFN,
patrick
Re: ISP port blocking practice
On Sep 3, 2010, at 8:22 AM, Owen DeLong wrote: On Sep 2, 2010, at 10:41 PM, Franck Martin wrote: Have you heard of the submission port? Yes... Many of the idiots that block outbound 25 also block outbound 587 and sometimes 465. Could you point to more than one instance? I've not yet found one. And I think I spend at least as much time in hotels 3G airports etc. as you anyone else here. -- TTFN, patrick
Re: just seen my first IPv6 network abuse scan, is this the start for more?
On Sep 3, 2010, at 3:46 AM, Dobbins, Roland wrote: On Sep 3, 2010, at 5:14 PM, Igor Ybema wrote: I discovered a external IPv6 host was doing a (rather useless due to the amount of addresses) IPv6 ICMP scan on our network recurring daily and mostly during the nights, sometimes with speeds of 1000 scans per second. Not necessarily so useless, as it was hitting your boxen, eh? ; Plus, setting bots to go scan isn't very labor-intensive. All the talk about how scanning isn't viable in IPv6-land due to large netblocks doesn't take into account the benefits of illicit automation. Uh... He mentioned 1000 addresses/second... At that rate, scanning a /64 will take more than 18,000,000,000,000,000 seconds. Converted to hours, that's 5,000,000,000,000 hours which works out to 208,333,333,333 days or roughly 570,776,255 years. If you want to scan a single IPv6 subnet completely in 1 year, you will need to automate 570,776,255 machines scanning at 1000 ip addresses per second, and, your target network will need to be able to process 570,776,255,000 packets per second. Yes, you can do a certain amount of table-overflow DOS with an IPv6 scan, but, you really can't accomplish much else in practical terms. Note that hinted scanning, based upon DNS treewalking and so forth, is a useful refinement. Yes, you can find hosts for which you already know the addresses easily this way. Obviously, there are a few other tricks that make it easy to find individual targets (such as the convention of making a router subnet::1). However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space. Due to the ammount of IPv6 neighbor discoveries from our routers resulting from this scan the Neighbour table overflow messages appeared on the machines. Any noticeable effect on router CPU? Probably not a lot. Probably even less on the boxes reporting the neighbor table overflow. Other than generating some noisy error messages, this should have been pretty much a non- event. Owen
Re: just seen my first IPv6 network abuse scan, is this the start for more?
However this scan was from a external host. The only traffic I saw on the subnet was normal/valid NA lookups from the router towards an increasing IPv6-address (starting with ::1, then ::2 etc). On the router side I clearly saw the icmp traffic from the source doing a scan on these destination hosts. typically this fill the NC with faked entries and exhaust the node's cache resources. This interrupts the normal functions of the targeted IPv6 node. In other words: The attacker sends a lot of ICMPv6 echo requests to your /64 subnet. Your router has to resolve this addresses internaly (each NA is stored in NC of the router). The node's cace resources are exhausted and no normal NA could be stored. I think that was your problem. Unfortunately is there no standardized way to mitigate this attacks, yet. However there are many approaches which could help or could be discussed. (like http://www.freepatentsonline.com/20070130427.pdf or other) best regards, -F signature.asc Description: OpenPGP digital signature
seek cable/dsl provider in Troy MI 48083 USA
Hi, for a customer at Stephenson Highway Troy, MI 48083 USA we seek an internet access/service provider, cable/xdsl/... would be ok, fixed ip-address prefered. Please answer off-list. Thank you for your kind support, Have a nice weekend, Jürgen Marenda, ILK
Re: just seen my first IPv6 network abuse scan, is this the start for more?
On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote: However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space. Concur, but I still maintain that lots of illicit automation plus refined scanning via DNS, et. al. is a viable practice. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
Re: ISP port blocking practice
Patrick W. Gilmore wrote: Yes... Many of the idiots that block outbound 25 also block outbound 587 and sometimes 465. Could you point to more than one instance? I've not yet found one. And I think I spend at least as much time in hotels 3G airports etc. as you anyone else here. I can't remember the ISP, but yes, I've run across this. I had to have my helpdesk inform the customer that they'll have to complain and gripe at the ISP they were using or make other arrangements as I only support 25/587 (customer didn't want to use webmail). Problem is, people hear block ports, they get in the habit, and the next thing you know, they are blocking ports out of ignorance with no comprehension of what they are breaking. I'd much rather see rate detection setups that let me send however I want, but limit the connections per time interval. It implies that some thought might go into determining the rates. Of course, the only setup I've done like this in testing in my network involved flow analyzers and dynamic acl's. Jack
Re: ISP port blocking practice
Patrick W. Gilmore wrote: On Sep 3, 2010, at 8:22 AM, Owen DeLong wrote: On Sep 2, 2010, at 10:41 PM, Franck Martin wrote: Have you heard of the submission port? Yes... Many of the idiots that block outbound 25 also block outbound 587 and sometimes 465. Could you point to more than one instance? I've not yet found one. And I think I spend at least as much time in hotels 3G airports etc. as you anyone else here. FWIW, I had it happen at a local library. Used their webform to send a message mentioning that blocking 25 was good, but blocking 587 and 465 was bad. It took several days but they did fix it. jc
Re: ISP port blocking practice
FWIW, I had it happen at a local library. Used their webform to send a message mentioning that blocking 25 was good, but blocking 587 and 465 was bad. It took several days but they did fix it. that was the condition at narita red carpet a few years back. had to pull a chain at ugs in chicago to find someone who knew what i meant. randy
Re: largest OSPF core
On Sep 2, 2010, at 11:11 AM, Nick Hilliard wrote:
On 02/09/2010 13:20, lorddoskias wrote:
I'm just curious - what is the largest OSPF core (in terms of
number of
routers) out there?
You don't expect anyone to actually admit to something like this? :-)
Of course I do -- 'tis much for your reputation to have wrangled a
poorly designed, ugly network under control than to have only worked
at places with smooth sailing I *don't* expect the owner /
designers of these to come forward, rather those who inherited a pile
of choss to share war stories... :-P
I worked on a network that had 350 routers in an (non-zero) area.
Now, ~350 routers in an area doesn't sound *that* impressive, but on
average these devices had 6 interfaces in OSPF, and many of these
links were of the form:
[router A]-- {GRE} --- [firewall]-- {GRE in IPSEC} ---
[Internet]--- {GRE in IPSEC} ---[firewall]---{GRE} --- [router B]
Routers A and B would form an OSPF adjacency. Much of this was an
overlay network (over the Internet) and so the firewalls would build
IPSec tunnels. Of course, said firewalls would not pass OSPF, so we
had to build GRE tunnels between routers A and D and run OSPF over
those -- traffic would enter the router, get encapsulated in GRE and
then the GRE would be encapsulated in IPSec and tossed into the void
In other places (in the same OSPF area) we would purchase parallel
T1 / E1s that we would run MLPPP over, and / or plain DS3s.
Oh, did I mention that network was primarily to support international
call centers that had been outsourced to wherever was *really* cheap,
and that many places with very cheap labor have very poor
infrastructure? It was not uncommon to have interfaces that would
bounce 5 or 10 times a day*
W
*: And yes, we did 'ave to get up out of shoebox at twelve o'clock at
night and lick road clean wit' tongue. We had two bits of cold gravel,
worked twenty-four hours a day at mill for sixpence every four years,
and when we got home our Dad would slice us in two wit' bread knife.
Nick
--
It's a mistake trying to cheer up camels. You might as well drop
meringues into a black hole. -- Terry Prachett
Re: ISP port blocking practice
On Thu, Sep 2, 2010 at 11:04 PM, Daniel Senie d...@senie.com wrote: Ingress filtering is the correct tool for the job. Not really. Ingress filtering only ever protected you from being the source of spooding attacks, not the destination. The point of Zhiyun's results is that it doesn't fully protect you from being the source either. Frankly, Zhiyun offers the first truly rational case I've personally seen for packet filtering based on the TCP source port. You should give his work more careful scrutiny. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: ISP port blocking practice
On 03/09/2010 16:16, Randy Bush wrote: that was the condition at narita red carpet a few years back. had to pull a chain at ugs in chicago to find someone who knew what i meant. and people wonder why developers implement * over http/https. Sigh. Nick
verizon outage
anyone experiencing issues with verizon in western mass? -- James Jones +1-413-667-9199 ja...@freedomnet.co.nz
Re: ISP port blocking practice
I have had it happen in some metro areas on sprint. I have experienced it in at least a dozen hotels over the last 12 months. I have run into it in various airports with free public wifi. I have run into the problem in several coffee shops. By far, the worst offenders are the most expensive hotels where the Internet access, damaged as it is generally goes for $25+ per day. I almost always end up getting free Internet as a result because I report the issue as a problem and their technical support usually can't spell tcp let alone understand what I mean when I say a port is blocked. Even worse is the ones that silently redirect your smtp (regardless of port) session to their MTA. Fortunately, my configuration is good enough that it just breaks in these cases, but I know many people who thought they were connecting to their own server via TLS only to later discover that their mail was relayed in clear text through several third party servers. (most mua's seem to have an unfortunate default to ssl or tis if available and keep right on sending even if tis negotiations are rejected.) Owen Sent from my iPad On Sep 4, 2010, at 12:08 AM, JC Dill jcdill.li...@gmail.com wrote: Patrick W. Gilmore wrote: On Sep 3, 2010, at 8:22 AM, Owen DeLong wrote: On Sep 2, 2010, at 10:41 PM, Franck Martin wrote: Have you heard of the submission port? Yes... Many of the idiots that block outbound 25 also block outbound 587 and sometimes 465. Could you point to more than one instance? I've not yet found one. And I think I spend at least as much time in hotels 3G airports etc. as you anyone else here. FWIW, I had it happen at a local library. Used their webform to send a message mentioning that blocking 25 was good, but blocking 587 and 465 was bad. It took several days but they did fix it. jc
Juniper to Watchguard IPSEC
Anyone have any experience with IPSEC between a WG Firebox and Juniper SRX/SSG? Running into some problems and beginning to think there might be some incompatibilities in their IPSEC options. TIA, Bryan
Re: verizon outage
On Fri, Sep 3, 2010 at 12:51 PM, James Jones ja...@freedomnet.co.nz wrote: anyone experiencing issues with verizon in western mass? o this isn't the outages list, that one MAY have more info for you o there are many verizons... which one are you talking about? (wireless, dsl/fios, fUUNET, private-line services, private-network services...) -Chris
Re: just seen my first IPv6 network abuse scan, is this the start for more?
On Sep 3, 2010, at 9:49 40AM, Dobbins, Roland wrote: On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote: However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space. Concur, but I still maintain that lots of illicit automation plus refined scanning via DNS, et. al. is a viable practice. See http://www.cs.columbia.edu/~smb/papers/v6worms.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: ISP port blocking practice
I use SSL only and even then, it requires authentication. --Curtis On 9/3/2010 1:00 PM, Owen DeLong wrote: I have had it happen in some metro areas on sprint. I have experienced it in at least a dozen hotels over the last 12 months. I have run into it in various airports with free public wifi. I have run into the problem in several coffee shops. By far, the worst offenders are the most expensive hotels where the Internet access, damaged as it is generally goes for $25+ per day. I almost always end up getting free Internet as a result because I report the issue as a problem and their technical support usually can't spell tcp let alone understand what I mean when I say a port is blocked. Even worse is the ones that silently redirect your smtp (regardless of port) session to their MTA. Fortunately, my configuration is good enough that it just breaks in these cases, but I know many people who thought they were connecting to their own server via TLS only to later discover that their mail was relayed in clear text through several third party servers. (most mua's seem to have an unfortunate default to ssl or tis if available and keep right on sending even if tis negotiations are rejected.) Owen Sent from my iPad On Sep 4, 2010, at 12:08 AM, JC Dilljcdill.li...@gmail.com wrote:
Re: just seen my first IPv6 network abuse scan, is this the start for more?
Sent from my iPad On Sep 3, 2010, at 11:19 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote: However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space. Concur, but I still maintain that lots of illicit automation plus refined scanning via DNS, et. al. is a viable practice. Care to elaborate? I'm betting you could find a handful of hosts on my network that are published in DNS (in which case you either already had their names, so, not sure what the scan does for you). I bet you would not easily find the rest. The prefix is 2620:0:930::/48. Have fun, you have my permission to sweep the address space twice. If we are still alive when you think you found everything, or, enough to have learned something from scanning that is meaningful and couldn't have been learned without scanning, send me your information and I'll let you know how well you did. Owen --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
Re: ISP port blocking practice
Sent from my iPad On Sep 3, 2010, at 10:10 PM, John Levine jo...@iecc.com wrote: Really? So, since so many ISPs are blocking port 25, there's lots less spam hitting our networks? It's been extremely effective in blocking spam sent by spambots on large ISPs. It's not a magic anti-spam bullet. (If you know one, please let us know.) That simply hasn't been my experience. I still get lots of spam from booted hosts in large provider networks, and yes, that includes many that block 25. As near as I can tell, 25 blocking is not affecting spammers at all, just legitimate users. There was a time when it was effective, but the spammers have long since adapted. Now we are only breaking the Internet. We are no ,onger accomplishing anything ireful. It's pure momentum. workaround. Since, like many of us, I use a lot of transient networks, having to reconfigure for each unique set of brokenness is actually wasting more of my time than the spam this brokenness was alleged to prevent. Is there some reason you aren't able to configure your computers to use tunnels or SUBMIT? They seem to work pretty well for other people. Many of the transient networks I deal with block 22, 25, 465, and 587. They also often block protocols 41 and 43 or do not provide a public address, rendering those protocols unusable anyway. Yes, I am now running ssh and s,tp processes on ports 80 and 443 to get around this, but, that consumes an extra address for something that should be handled by a port number. Personally, i'd rather use port numbers for l4 uniqueness rather than IP Addresses. Owen R's, John
Re: just seen my first IPv6 network abuse scan, is this the start for more?
On Fri, Sep 3, 2010 at 9:49 AM, Dobbins, Roland rdobb...@arbor.net wrote: On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote: However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space. Concur, but I still maintain that lots of illicit automation plus refined scanning via DNS, et. al. is a viable practice. These are very big numbers, so I don't see how. If you use easy to guess/remember host/service names and put them in public DNS then those IP addresses are in some sense already public (whether IPv4 or IPv6). The definition of easy to guess is pretty much everything which has ever been used in a wordlist for password cracking programs (plus the code which generates variants of same). Real attackers are going to flood your DNS servers, not do brute force IPv6 ICMP scans. Even a pure brute force DNS scan of all 10 character long hostnames (asuming a-z0-9) is going to take around 5000 times fewer queries then a full ICMP v6 scan of a /64. (Which at an attack speed of 1000pps is still going to take around 100,000 years.) For machines which you want to make it REALLY hard to find, but need publicly accessible addresses, you shouldn't put them in publicly queryable DNS servers at all and use a random number generator to generate their static IPv6 addresses. Even if you put a thousand of these machines in a single subnet, it is going to take half a million years at reasonable packet rates before even one of them is discovered. Hmm, thinking about it in terms of passwords might help. Many people consider a totally random 10 character monocase+numbers password to be reasonably secure against brute force attacks. ICMP scanning a /64 is thousands of times more difficult and all it gives you is the existence of the machine. Even if you find that needle in a hay stack , you don't get access to its resources. I took a quick look at the paper that SMB linked to and I would argue that for wide area attacks, packet sniffing is going to be how people find your hidden addresses.Compromising SMB wi-fi hotspot hardware and logging every address accessed is one possibility. Or just compromise people's laptops and have them run network sniffers which generate seen address lists which are forwarded to dummy gmail accounts. Bill Bogstad
Re: just seen my first IPv6 network abuse scan, is this the start for more?
Steven Bellovin wrote: See http://www.cs.columbia.edu/~smb/papers/v6worms.pdf Or my lame take on the matter http://geekmerc.livejournal.com/1421.html -Jack *saves yours to read up later*
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith p...@cisco.com. Routing Table Report 04:00 +10GMT Sat 04 Sep, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 330158 Prefixes after maximum aggregation: 151682 Deaggregation factor: 2.18 Unique aggregates announced to Internet: 162121 Total ASes present in the Internet Routing Table: 34721 Prefixes per ASN: 9.51 Origin-only ASes present in the Internet Routing Table: 30112 Origin ASes announcing only one prefix: 14633 Transit ASes present in the Internet Routing Table:4609 Transit-only ASes present in the Internet Routing Table:102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 1987 Unregistered ASNs in the Routing Table: 969 Number of 32-bit ASNs allocated by the RIRs:757 Prefixes from 32-bit ASNs in the Routing Table: 991 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:191 Number of addresses announced to Internet: 2279348416 Equivalent to 135 /8s, 220 /16s and 24 /24s Percentage of available address space announced: 61.5 Percentage of allocated address space announced: 65.7 Percentage of available address space allocated: 93.7 Percentage of address space in use by end-sites: 84.6 Total number of prefixes smaller than registry allocations: 156259 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:80332 Total APNIC prefixes after maximum aggregation: 27557 APNIC Deaggregation factor:2.92 Prefixes being announced from the APNIC address blocks: 77315 Unique aggregates announced from the APNIC address blocks:34057 APNIC Region origin ASes present in the Internet Routing Table:4177 APNIC Prefixes per ASN: 18.51 APNIC Region origin ASes announcing only one prefix: 1170 APNIC Region transit ASes present in the Internet Routing Table:642 Average APNIC Region AS path length visible:3.7 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 543003680 Equivalent to 32 /8s, 93 /16s and 148 /24s Percentage of available APNIC address space announced: 77.1 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:135713 Total ARIN prefixes after maximum aggregation:69909 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 108391 Unique aggregates announced from the ARIN address blocks: 42744 ARIN Region origin ASes present in the Internet Routing Table:13888 ARIN Prefixes per ASN: 7.80 ARIN Region origin ASes announcing only one prefix:5328 ARIN Region transit ASes present in the Internet Routing Table:1377 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22
Re: just seen my first IPv6 network abuse scan, is this the start for more?
On 9/3/10 11:25 AM, Bill Bogstad wrote: On Fri, Sep 3, 2010 at 9:49 AM, Dobbins, Roland rdobb...@arbor.net wrote: On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote: However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space. Concur, but I still maintain that lots of illicit automation plus refined scanning via DNS, et. al. is a viable practice. These are very big numbers, so I don't see how. Consider you have a dual stack deployment. what are the most likely ipv6 numbering schemes you're likely to use to number hosts. If I query one of your hosts in the forward zone and get back and a and a record what can I likely conclude about the numbering scheme for that net? joelja-mac:~ joelja$ host ns3.xx.net ns3.xxx.net has address .xxx.0.81 ns3.xxx.net has IPv6 address :xxx:1::81 if you do stateful dhcp v6 assignment what are the likely constraints as to the size of the pool you're going to use for that subnet. This is like brute force password guessing... there's some high probability answers that are low hanging fruit you reach for them, they don't exist you move on. If you use easy to guess/remember host/service names and put them in public DNS then those IP addresses are in some sense already public (whether IPv4 or IPv6). The definition of easy to guess is pretty much everything which has ever been used in a wordlist for password cracking programs (plus the code which generates variants of same). Real attackers are going to flood your DNS servers, not do brute force IPv6 ICMP scans. Even a pure brute force DNS scan of all 10 character long hostnames (asuming a-z0-9) is going to take around 5000 times fewer queries then a full ICMP v6 scan of a /64. (Which at an attack speed of 1000pps is still going to take around 100,000 years.) For machines which you want to make it REALLY hard to find, but need publicly accessible addresses, you shouldn't put them in publicly queryable DNS servers at all and use a random number generator to generate their static IPv6 addresses. Even if you put a thousand of these machines in a single subnet, it is going to take half a million years at reasonable packet rates before even one of them is discovered. Hmm, thinking about it in terms of passwords might help. Many people consider a totally random 10 character monocase+numbers password to be reasonably secure against brute force attacks. ICMP scanning a /64 is thousands of times more difficult and all it gives you is the existence of the machine. Even if you find that needle in a hay stack , you don't get access to its resources. I took a quick look at the paper that SMB linked to and I would argue that for wide area attacks, packet sniffing is going to be how people find your hidden addresses.Compromising SMB wi-fi hotspot hardware and logging every address accessed is one possibility. Or just compromise people's laptops and have them run network sniffers which generate seen address lists which are forwarded to dummy gmail accounts. Bill Bogstad
Re: verizon outage
Found out its related to the outage in NJ On 3/09/10 1:12 PM, Christopher Morrow wrote: On Fri, Sep 3, 2010 at 12:51 PM, James Jonesja...@freedomnet.co.nz wrote: anyone experiencing issues with verizon in western mass? o this isn't the outages list, that one MAY have more info for you o there are many verizons... which one are you talking about? (wireless, dsl/fios, fUUNET, private-line services, private-network services...) -Chris
Re: eBGP Multihop
On Sep 2, 2010, at 2:30 AM, Graham Beneke wrote: I have been asked to investigate moving an entire network to multi-hop on all the eBGP sessions. Basically all upstreams, downstreams and peers will eBGP with a route reflector located in the core. This RR will be some kind of quagga or similar box. The dev guys want to be able to poke at the BGP feeds directly and do *magic* that standard router aren't capable of. My gut feel is that this is a bad idea. Besides anything else it makes sane link state detection very challenging - especially where we have multiple sessions with a peer. Is their any BCP or operational experience that agrees or disagrees with my gut. ;-) Multihop eBGP is a debugging tool that a developer left in the production code. Tony
Re: just seen my first IPv6 network abuse scan, is this the start for more?
On Sep 4, 2010, at 12:19 AM, Steven Bellovin wrote: See http://www.cs.columbia.edu/~smb/papers/v6worms.pdf I've seen it and concur with regards to worms (which don't seem to be very popular, right now, excepting the 'background radiation' of old Code Red, Nimda, Blaster, Nachi, SQL Slammer, et. al. hosts). I believe that hinted scanning is still viable, and I'd argue that the experience of the OP who kicked off this thread is an indication of same. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
Re: ISP port blocking practice
On Sep 3, 2010, at 10:23 PM, William Herrin wrote: Frankly, Zhiyun offers the first truly rational case I've personally seen for packet filtering based on the TCP source port. While the paper is entertaining and novel, and reflects a lot of creativity and hard work on the part of the research team, it's doubtful that any serious spammer has ever sent spam this way. I've certainly never run across it, nor do I know anyone else who has done so. The lack of citations of documented cases in the footnotes, or indeed any projections or discussion of the postulated commonality of this technique tends to support the above view, IMHO. Spammers typically do business with botmasters, and those botmasters have thousands/tens of thousands/hundreds of thousands/millions of bots at their disposal. The supposed economies of scale achieved by 'triangular spamming' (a better name would be something like 'bifurcated false-flag proxying', as spamming is just a use-case of the more generalized, though esoteric technique described in the paper) are far outweighed by its operational complexity and the sheer volume of botnets available to pump out spam 24/7. The supposed performance benefits described in the paper are likely considerably exaggerated, given the RTT and resultant latency of the return traffic via the remote proxy half. The sheer economies of scale offered by conventional botnets greatly outweigh the benefits and caveats of the described technique. The use of routers cracked via credential brute-forcing (no iACLs, no vty ACLs, no AAA, 'cisco/cisco') and configured with GRE tunnels and NAT, sometimes in conjunction with prefix-hijacking, is a more commonly-used spamming technique than that described in the paper. There are a lot of really smart people engaged in all kinds of security-related research, and it's encouraging to see such talented folks thinking outside of the box. In future, vetting of postulated scenarios with the operational community prior to embarking upon lengthy, resource-intensive research projects may be one way to ensure that subsequent efforts are even more tightly focused on more proximate threats, and can also help reduce the continued citation of canards such as attempts to overload such opaque, arbitrary, and unreliable metrics as TTL with more significance than they actually warrant. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
RE: just seen my first IPv6 network abuse scan, is this the start for more?
Plus, setting bots to go scan isn't very labor-intensive. All the talk about how scanning isn't viable in IPv6-land due to large netblocks doesn't take into account the benefits of illicit automation. Uh... He mentioned 1000 addresses/second... At that rate, scanning a /64 will take more than 18,000,000,000,000,000 seconds. Converted to hours, that's 5,000,000,000,000 hours which works out to 208,333,333,333 days or roughly 570,776,255 years. If you want to scan a single IPv6 subnet completely in 1 year, you will need to automate 570,776,255 machines scanning at 1000 ip addresses per second, and, your target network will need to be able to process 570,776,255,000 packets per second. Yes, you can do a certain amount of table-overflow DOS with an IPv6 scan, but, you really can't accomplish much else in practical terms. Since I mentioned a thread about technology prognostication... Right now 1000 pps per host seems like a number that is on the high end of what could go reasonably unnoticed by a comprised bot-machine. I'm sure if we roll back our clocks to IPv4's origination we'd have never imagined 1000pps scans. If history is any judge, the technology will grow faster and farther than we can see from here. Designers will put stupid kludges in their code [because the space is so vast] like picking Fibonacci numbers as unique inside of large sections of space -- who knows. The point is that while every smart person thinks this is a lot of space for current attack technology, in some period of time, it may not seem to difficult and safe to hide in. Moreover, when every enterprise has a /48 or better, network admins are going to need to be able to track down machines/devices/ear pieces/what have you on a better basis then trapping them when they speak up. There is a huge potential for sleepers in IPv6 space that we don't see any more in IPv4 (because the tools are better). Eventually someone will find an approach to do this kind of surveying and then make it cheap enough everyone can do it. (how often do security-admins use NMAP/Nessus/what have you to survey their own space -- an IPv6 analog will *need* to be created eventually). Just my thoughts, Deepak
Re: just seen my first IPv6 network abuse scan, is this the start for more?
In a message written on Fri, Sep 03, 2010 at 04:33:23PM -0400, Deepak Jain wrote: Moreover, when every enterprise has a /48 or better, network admins are going to need to be able to track down machines/devices/ear pieces/what have you on a better basis then trapping them when they speak up. There is a huge potential for sleepers in IPv6 space that we don't see any more in IPv4 (because the tools are better). Eventually someone will find an approach to do this kind of surveying and then make it cheap enough everyone can do it. (how often do security-admins use NMAP/Nessus/what have you to survey their own space -- an IPv6 analog will *need* to be created eventually). If you are the network admin, walking the L2 devices MAC tables and comparing with the L3 devices ARP/ND/whatever tables is likely more efficient for sparse address space. Also keep in mind, IPv6 devices will often have multiple addresses, and may move addresses quite regularly. For instance, I use privacy or temporary addresses, my machine hops to a new IPv6 address every 10 minutes. A scan will likely be out of date before it completes for these sorts of addresses. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpHD382k11bO.pgp Description: PGP signature
Re: ISP port blocking practice
On Sep 4, 2010, at 3:11 AM, Dobbins, Roland wrote: I've certainly never run across it, nor do I know anyone else who has done so. I stand corrected - it seems I do in fact know someone who's observed this technique used to send spam, albeit in the past when POTS dial-up pools were the de facto access method for the masses and before the technical and commercial maturity of the botnet business model. I still maintain that even if it's being used today, it's rare, and essentially a corner-case. This isn't meant to detract from the novelty and creativity of the paper in question, but rather to posit the view that it isn't necessarily something for operators to get too worked up about, in the scheme of things. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
Re: ISP port blocking practice
On Sep 3, 2010, at 8:02 PM, Patrick W. Gilmore wrote: Could you point to more than one instance? I've not yet found one. I've yet to run across this, either, FWIW, except on extremely restrictive special-purpose endpoint networks. Doesn't mean that it doesn't happen, but it doesn't seem to be nearly as prevalent as TCP/25 blockage on general SP access networks. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
Re: Juniper to Watchguard IPSEC
On Fri, Sep 3, 2010 at 10:03 AM, Welch, Bryan bryan.we...@arrisi.comwrote: Anyone have any experience with IPSEC between a WG Firebox and Juniper SRX/SSG? Running into some problems and beginning to think there might be some incompatibilities in their IPSEC options. Not WG but I had trouble getting a SSG to talk to a Cisco until I realized the SSG (ScreenOS) has to have a proxy-id defined, which the Cisco required to complete the SA. But perhaps you're using Junos on your SSGs if you're talking SRX as well. -Iain
BGP Update Report
BGP Update Report Interval: 26-Aug-10 -to- 02-Sep-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS541681217 2.6% 588.5 -- BATELCO-BH 2 - AS35567 62345 2.0% 593.8 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 3 - AS432329881 0.9% 6.7 -- TWTC - tw telecom holdings, inc. 4 - AS638925846 0.8% 6.7 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 5 - AS815123885 0.8% 15.6 -- Uninet S.A. de C.V. 6 - AS13880 22045 0.7%1296.8 -- ACI-AS - american century investments 7 - AS346421519 0.7% 489.1 -- ASC-NET - Alabama Supercomputer Network 8 - AS982920014 0.6% 24.4 -- BSNL-NIB National Internet Backbone 9 - AS11492 19618 0.6% 15.6 -- CABLEONE - CABLE ONE, INC. 10 - AS32528 17018 0.5%2127.2 -- ABBOTT Abbot Labs 11 - AS553616586 0.5% 144.2 -- Internet-Egypt 12 - AS647816075 0.5% 12.1 -- ATT-INTERNET3 - ATT WorldNet Services 13 - AS14522 14555 0.5% 40.7 -- Satnet 14 - AS20115 14243 0.5% 9.5 -- CHARTER-NET-HKY-NC - Charter Communications 15 - AS19262 14193 0.5% 7.9 -- VZGNI-TRANSIT - Verizon Online LLC 16 - AS35931 14096 0.4%2349.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 17 - AS17974 13648 0.4% 11.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 18 - AS178513061 0.4% 7.3 -- AS-PAETEC-NET - PaeTec Communications, Inc. 19 - AS755213044 0.4% 19.8 -- VIETEL-AS-AP Vietel Corporation 20 - AS650312730 0.4% 14.8 -- Axtel, S.A.B. de C. V. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS35931 14096 0.4%2349.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 2 - AS32528 17018 0.5%2127.2 -- ABBOTT Abbot Labs 3 - AS13880 22045 0.7%1296.8 -- ACI-AS - american century investments 4 - AS11613 830 0.0% 830.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 5 - AS210177301 0.2% 730.1 -- VSI-AS VSI AS 6 - AS15984 729 0.0% 729.0 -- The Joint-Stock Commercial Bank CentroCredit. 7 - AS361291367 0.0% 683.5 -- YAHOO-MAVEN - Yahoo 8 - AS272451310 0.0% 655.0 -- HEIDRICK-CHICAGO - HEIDRICK 9 - AS50441 610 0.0% 610.0 -- KVNO-AS Kassenaerztliche Vereinigung Nordrhein 10 - AS51211 605 0.0% 605.0 -- ZHIGULI-TELECOM-AS LTD Zhiguli-Telecom 11 - AS35567 62345 2.0% 593.8 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 12 - AS541681217 2.6% 588.5 -- BATELCO-BH 13 - AS16861 562 0.0% 562.0 -- REVELEX - Revelex.com 14 - AS346421519 0.7% 489.1 -- ASC-NET - Alabama Supercomputer Network 15 - AS41759 874 0.0% 437.0 -- FRYITUK FRY-IT UK As Number 16 - AS27027 715 0.0% 357.5 -- ANBELL ASN-ANBELL 17 - AS372043278 0.1% 327.8 -- TELONE 18 - AS50150 288 0.0% 288.0 -- LONGLINE-AS LongLine SRL 19 - AS2 275 0.0% 177.0 -- UPOU-LB-AS-AP University of the Philippines - Open University Los Banos Campus 20 - AS167187276 0.2% 259.9 -- EMBARQ-HMBL - Embarq Corporation TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 129.66.128.0/17 10541 0.3% AS3464 -- ASC-NET - Alabama Supercomputer Network 2 - 129.66.0.0/17 10536 0.3% AS3464 -- ASC-NET - Alabama Supercomputer Network 3 - 130.36.35.0/24 8476 0.2% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.34.0/24 8475 0.2% AS32528 -- ABBOTT Abbot Labs 5 - 63.211.68.0/22 8183 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - 213.196.79.0/247228 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 7 - 213.196.72.0/247226 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 8 - 213.196.77.0/247226 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 9 - 213.196.75.0/247226 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 10 - 213.196.74.0/247226 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 11 - 213.196.76.0/247226 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 12 - 213.196.78.0/247226 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 13 - 213.196.73.0/247226 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 14 - 148.204.141.0/24 7092 0.2% AS8151 -- Uninet S.A. de C.V. 15 - 198.140.43.0/245834 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 16 - 190.65.228.0/225480 0.1% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 17 - 77.69.148.0/24 4329 0.1% AS5416 -- BATELCO-BH 18 - 77.69.141.0/24 4329 0.1%
The Cidr Report
This report has been generated at Fri Sep 3 21:11:43 2010 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
27-08-10333965 206952
28-08-10335080 207017
29-08-10335271 207124
30-08-10335262 204429
31-08-10335183 207029
01-09-10335387 206535
02-09-10335293 206645
03-09-10335608 206587
AS Summary
35292 Number of ASes in routing system
15028 Number of ASes announcing only one prefix
4451 Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
97246976 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 03Sep10 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 335536 206530 12900638.4% All ASes
AS6389 3824 278 354692.7% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4451 1906 254557.2% TWTC - tw telecom holdings,
inc.
AS19262 1814 284 153084.3% VZGNI-TRANSIT - Verizon Online
LLC
AS4766 1866 514 135272.5% KIXS-AS-KR Korea Telecom
AS13343 1682 528 115468.6% SCRR-13343 - Road Runner
HoldCo LLC
AS22773 1181 66 111594.4% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS4755 1483 428 105571.1% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS17488 1346 302 104477.6% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS5668 1134 91 104392.0% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS18566 1087 63 102494.2% COVAD - Covad Communications
Co.
AS6478 1332 387 94570.9% ATT-INTERNET3 - ATT WorldNet
Services
AS8151 1526 625 90159.0% Uninet S.A. de C.V.
AS10620 1204 323 88173.2% Telmex Colombia S.A.
AS1785 1790 957 83346.5% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS8452 1150 408 74264.5% TEDATA TEDATA
AS7545 1384 696 68849.7% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS7303 796 115 68185.6% Telecom Argentina S.A.
AS4808 933 302 63167.6% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS4804 678 73 60589.2% MPX-AS Microplex PTY LTD
AS28573 1123 578 54548.5% NET Servicos de Comunicao S.A.
AS7552 653 121 53281.5% VIETEL-AS-AP Vietel
Corporation
AS17676 605 77 52887.3% GIGAINFRA Softbank BB Corp.
AS4780 685 161 52476.5% SEEDNET Digital United Inc.
AS7018 1474 953 52135.3% ATT-INTERNET4 - ATT WorldNet
Services
AS18101 844 323 52161.7% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS7011 1155 666 48942.3% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
AS14420 568 87 48184.7% CORPORACION NACIONAL DE
TELECOMUNICACIONES - CNT EP
AS22047 555 81 47485.4% VTR BANDA ANCHA S.A.
AS24560 1020 548 47246.3% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS3356 1141 676 46540.8% LEVEL3 Level 3 Communications
Total 40484
Re: ISP port blocking practice
It's been extremely effective in blocking spam sent by spambots on large ISPs. It's not a magic anti-spam bullet. (If you know one, please let us know.) That simply hasn't been my experience. I still get lots of spam from booted hosts in large provider networks, and yes, that includes many that block 25. As near as I can tell, 25 blocking is not affecting spammers at all, just legitimate users. I know people at large ISPs with actual data. Port 25 blocking is quite effective. R's, John
RE: ISP port blocking practice
It's extremely effective for us (not a large provider by any means). We block outbound 25 on all dynamic IP customers - to date it's never been a problem for our customers. Customer's who have static assignments are not blocked by default. Paul -Original Message- From: John R. Levine [mailto:jo...@iecc.com] Sent: Friday, September 03, 2010 3:20 PM To: Owen DeLong Cc: nanog@nanog.org Subject: Re: ISP port blocking practice It's been extremely effective in blocking spam sent by spambots on large ISPs. It's not a magic anti-spam bullet. (If you know one, please let us know.) That simply hasn't been my experience. I still get lots of spam from booted hosts in large provider networks, and yes, that includes many that block 25. As near as I can tell, 25 blocking is not affecting spammers at all, just legitimate users. I know people at large ISPs with actual data. Port 25 blocking is quite effective. R's, John
Re: ISP port blocking practice
On 9/3/2010 3:19 PM, John R. Levine wrote: I know people at large ISPs with actual data. Port 25 blocking is quite effective. Well no one has said it in this thread yet, so I guess it's my turn. :) When talking about spam it often happens that people make statements along the lines of, Spam still exists, therefore $FOO is not an effective countermeasure. I chose to respond to this message to say that this line of thinking is flawed because this message (to some degree at least) demonstrates that blocking 25 outbound IS effective (again, to some degree); which leads to my larger point. There is no one magic bullet for spam. It's a hydra of a problem if there ever was one, and _every_ option needs to be weighed, both the costs and the benefits. I know that a lot of you know this, but the consistent repetition of the same logical fallacy just gets under my skin, and like I said, it was my turn. Doug
Re: just seen my first IPv6 network abuse scan, is this the start for more?
Sent from my iPad On Sep 4, 2010, at 4:12 AM, Joel Jaeggli joe...@bogus.com wrote: On 9/3/10 11:25 AM, Bill Bogstad wrote: On Fri, Sep 3, 2010 at 9:49 AM, Dobbins, Roland rdobb...@arbor.net wrote: On Sep 3, 2010, at 7:58 PM, Owen DeLong wrote: However, scanning in IPv6 is not at all like the convenience of comprehensive scanning of the IPv4 address space. Concur, but I still maintain that lots of illicit automation plus refined scanning via DNS, et. al. is a viable practice. These are very big numbers, so I don't see how. Consider you have a dual stack deployment. I do... what are the most likely ipv6 numbering schemes you're likely to use to number hosts. In my case, there are seven numbering schemes in use. If I query one of your hosts in the forward zone and get back and a and a record what can I likely conclude about the numbering scheme for that net? joelja-mac:~ joelja$ host ns3.xx.net ns3.xxx.net has address .xxx.0.81 ns3.xxx.net has IPv6 address :xxx:1::81 In my case, this will only help you find the other hosts which have DNS entries in IPv6. Any host which does not have an record already uses a different numbering scheme entirely. Even the hosts that do have s are broken up into different numbering ranges based on my own criteria. if you do stateful dhcp v6 assignment what are the likely constraints as to the size of the pool you're going to use for that subnet. 1. Stateful DHCP on a subnet is the exception, not the rule. 2. On networks with DHCP, I would give at least a 48 bit pool. This is like brute force password guessing... there's some high probability answers that are low hanging fruit you reach for them, they don't exist you move on. In other words, you'll get lucky on a few networks where the administrator failed to move beyond IPv4think. If you use easy to guess/remember host/service names and put them in public DNS then those IP addresses are in some sense already public (whether IPv4 or IPv6). The definition of easy to guess is pretty much everything which has ever been used in a wordlist for password cracking programs (plus the code which generates variants of same). Real attackers are going to flood your DNS servers, not do brute force IPv6 ICMP scans. Even a pure brute force DNS scan of all 10 character long hostnames (asuming a-z0-9) is going to take around 5000 times fewer queries then a full ICMP v6 scan of a /64. (Which at an attack speed of 1000pps is still going to take around 100,000 years.) Good luck getting 1000 dns answers per second from most zones. I suspect a useful DNS scan would be limited to something more like 200 qps. Even then, you'll trip over my query rate limiter unless you use a whole lot of hosts to do the scan. For machines which you want to make it REALLY hard to find, but need publicly accessible addresses, you shouldn't put them in publicly queryable DNS servers at all and use a random number generator to generate their static IPv6 addresses. Even if you put a thousand of these machines in a single subnet, it is going to take half a million years at reasonable packet rates before even one of them is discovered. Or better yet, have the, cycle through privacy addresses using dynamic updates tom private name server. Hmm, thinking about it in terms of passwords might help. Many people consider a totally random 10 character monocase+numbers password to be reasonably secure against brute force attacks. ICMP scanning a /64 is thousands of times more difficult and all it gives you is the existence of the machine. Even if you find that needle in a hay stack , you don't get access to its resources. About 6,000 times to be slightly more precise. 36^10 is. ~3,656,158,440,000,000 2^64 is.18,446,744,073,709,551,616 addresses. I took a quick look at the paper that SMB linked to and I would argue that for wide area attacks, packet sniffing is going to be how people find your hidden addresses.Compromising SMB wi-fi hotspot hardware and logging every address accessed is one possibility. Or just compromise people's laptops and have them run network sniffers which generate seen address lists which are forwarded to dummy gmail accounts. Bill Bogstad I think that's much more likely. Owen
Re: ISP port blocking practice
I asked around and got this presentation, but you can search for OP25B too: http://www.anacom.pt/streaming/Honda.pdf?contentId=988141field=ATTACHED_FILE Some non-anecdotal data about the effectiveness of blocking port 25.
p
Re: just seen my first IPv6 network abuse scan, is this the start for more?
I was not attempting to defend security through obscurity. It doesn't ultimately help at all. However, compared to the network and other resource costs of scanning, even at more than a billion pps, I think there will be more effective vectors of attack that are more likely to be used in IPv6. In IPv4, an exhaustive scan is quite feasible. In IPv6, scanning a single subnet is 4 billion times harder than scanning the entire IPv4 Internet. My point isn't that hiding hosts in arbitrarily large address space makes them safe. My point is that scanning is not the vector by which they are most likely to get discovered. Owen Sent from my iPad On Sep 4, 2010, at 6:03 AM, Deepak Jain dee...@ai.net wrote: Plus, setting bots to go scan isn't very labor-intensive. All the talk about how scanning isn't viable in IPv6-land due to large netblocks doesn't take into account the benefits of illicit automation. Uh... He mentioned 1000 addresses/second... At that rate, scanning a /64 will take more than 18,000,000,000,000,000 seconds. Converted to hours, that's 5,000,000,000,000 hours which works out to 208,333,333,333 days or roughly 570,776,255 years. If you want to scan a single IPv6 subnet completely in 1 year, you will need to automate 570,776,255 machines scanning at 1000 ip addresses per second, and, your target network will need to be able to process 570,776,255,000 packets per second. Yes, you can do a certain amount of table-overflow DOS with an IPv6 scan, but, you really can't accomplish much else in practical terms. Since I mentioned a thread about technology prognostication... Right now 1000 pps per host seems like a number that is on the high end of what could go reasonably unnoticed by a comprised bot-machine. I'm sure if we roll back our clocks to IPv4's origination we'd have never imagined 1000pps scans. If history is any judge, the technology will grow faster and farther than we can see from here. Designers will put stupid kludges in their code [because the space is so vast] like picking Fibonacci numbers as unique inside of large sections of space -- who knows. The point is that while every smart person thinks this is a lot of space for current attack technology, in some period of time, it may not seem to difficult and safe to hide in. Moreover, when every enterprise has a /48 or better, network admins are going to need to be able to track down machines/devices/ear pieces/what have you on a better basis then trapping them when they speak up. There is a huge potential for sleepers in IPv6 space that we don't see any more in IPv4 (because the tools are better). Eventually someone will find an approach to do this kind of surveying and then make it cheap enough everyone can do it. (how often do security-admins use NMAP/Nessus/what have you to survey their own space -- an IPv6 analog will *need* to be created eventually). Just my thoughts, Deepak
Re: Juniper to Watchguard IPSEC
Sent from my iPad On Sep 4, 2010, at 6:50 AM, Iain Morris iain.t.mor...@gmail.com wrote: On Fri, Sep 3, 2010 at 10:03 AM, Welch, Bryan bryan.we...@arrisi.comwrote: Anyone have any experience with IPSEC between a WG Firebox and Juniper SRX/SSG? Running into some problems and beginning to think there might be some incompatibilities in their IPSEC options. Not WG but I had trouble getting a SSG to talk to a Cisco until I realized the SSG (ScreenOS) has to have a proxy-id defined, which the Cisco required to complete the SA. But perhaps you're using Junos on your SSGs if you're talking SRX as well. Same requirement in JunOS as well. Owen -Iain
Re: just seen my first IPv6 network abuse scan, is this the start for more?
On 9/3/2010 17:12, Owen DeLong wrote: I was not attempting to defend security through obscurity. It doesn't ultimately help at all. However, compared to the network and other resource costs of scanning, even at more than a billion pps, I think there will be more effective vectors of attack that are more likely to be used in IPv6. In IPv4, an exhaustive scan is quite feasible. In IPv6, scanning a single subnet is 4 billion times harder than scanning the entire IPv4 Internet. My point isn't that hiding hosts in arbitrarily large address space makes them safe. My point is that scanning is not the vector by which they are most likely to get discovered. Even so, it won't stop the uninitiated from scanning the crap out of IPv6 space. ~Seth
Re: ISP port blocking practice
On Fri, 03 Sep 2010 08:12:01 -0400, Owen DeLong o...@delong.com wrote: Really? So, since so many ISPs are blocking port 25, there's lots less spam hitting our networks? Less than there could be. It appears a lot less effective because there are so many ISPs not doing any blocking. Both of my residential connections are open, and always have been. (even dialup was unblocked. which I always found odd since the UUNET wholesale dialup agreement requires the RADIUS response contain a packet filter limiting port 25 to your mail server(s).) If I block port 25 on my network, no spam will originate from it. (probablly) The spammers will move on to a network that doesn't block their crap. As long as there are such open networks, spam will be rampant. If, overnight, every network filtered port 25, spam would all but disappear. But spam would not completely disappear -- it would just be coming from known mailservers :-) thus enters outbound scanning and the frustrated user complaints from poorly tuned systems... --Ricky
Re: ISP port blocking practice
Composed on a virtual keyboard, please forgive typos. On Sep 3, 2010, at 23:50, Owen DeLong o...@delong.com wrote: I think you overestimate the efficacy of this. First, why [snip] I think I see the problem here. You are using logic though experiments, while others have this thing called data. I'm going to go with data over your assumptions. Call me silly, but that's how I roll. -- TTFN, patrick
Re: ISP port blocking practice
Does the data show that blocking was effective, as in the host didn't detect the block and proceed around it, or, merely that lots of hosts try the direct approach first? Yes. R's, John
Re: just seen my first IPv6 network abuse scan, is this the start for more?
On Sep 4, 2010, at 7:12 AM, Owen DeLong wrote: My point is that scanning is not the vector by which they are most likely to get discovered. I do agree with this, definitely, with regards to blind scanning. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
