Re: [da] news: Trend Micro launches anti-botnet service
On Sep 25, 2006, at 9:04 PM, Jeff Kell wrote: Well, a prefix hijack either means a router has been pwned, as I suggested, or a router is (as Governor Tarkin put it) far too trusting of its peers. And anyhow, I was speaking of BGP flaps in the context of botnets - has anybody seen an in-the-wild botnet that played BGP games? No, but playing some BGP games could certainly help to *mitigate* them. Turn the CC list into a community. I've thrown the idea around several times but can't get any takers... been there, tried that: http://www.mainnerve.com/security/darknet.html -b
Re: [da] news: Trend Micro launches anti-botnet service
First, I think that forwarding messages from a private list is something that is frowned upon. Secondly -- and speaking as a Trend employee and someone intimately involved in the ICSS/BASE project -- we don't talk/play in the BGP traffic stream. We simply reap potential target data from a BGP/Origina-AS/perfix-announce dataset, and then allow the ICSS/BASE subscribers to make polict decisions on their merit -- whether to allow their downstream hosts to reselve DNS queries to suspect hosts, or not. We do not, in any way, piss into the BGP traffic stream. :-) It's just an intelligence feed -- one of many. - ferg -- brett watson [EMAIL PROTECTED] wrote: On Sep 25, 2006, at 9:04 PM, Jeff Kell wrote: Well, a prefix hijack either means a router has been pwned, as I suggested, or a router is (as Governor Tarkin put it) far too trusting of its peers. And anyhow, I was speaking of BGP flaps in the context of botnets - has anybody seen an in-the-wild botnet that played BGP games? No, but playing some BGP games could certainly help to *mitigate* them. Turn the CC list into a community. I've thrown the idea around several times but can't get any takers... been there, tried that: http://www.mainnerve.com/security/darknet.html -b -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: icmp rpf
On Tue, Sep 26, 2006 at 12:17:27AM -0700, Tony Rall wrote: On Monday, 2006-09-25 at 10:09 MST, Mark Kent [EMAIL PROTECTED] wrote: Mark Smith replied with two paragraphs, but it's not 100% clear to me that he got the reason why I asked. I asked because his initial statement boiled down to numbering on un-announced space breaks PMTUD... but it doesn't, not by itself (which he later expanded). It only does so in the presence of filtering. Which is exactly what one might expect to happen. At least it seems to me that RFC 3704 (BCP 84, http://www.ietf.org/rfc/rfc3704.txt) applies. When your traffic is sourced with dubious addresses, you should expect much of it to disappear. And when this happens, you're hurting your customers and your customers' customers (okay, sometimes it's just your peer's customers - still a concern in my opinion). I think this is the critical point, dubious ip sources have been used/abused in the past and those at big.net that have done something to mitigate the risk to the world from their customers and their customers from the world are doing a community service imnsho ;). I don't see anyone here really advocating spoofed sources (except for perhaps the mobile-ip users out there ;) How many people here have rpf enabled by default on their customer CPE devices they ship? (in your template or whatnot) Do you u-rpf your dsl/cable/dial/fract-t1/t1 customers that are not doing bgp? It's hard to get this implemented across an entire network. At one time I seem to recall someone saying that 7018 was fully bcp-38 compliant, but I could be wrong. While doing u-rpf on your customers won't mitigate attacks against them, it will help mitigate the costs of tracking spoofed attacks across your network infrastructure (which is harder if you're doing mpls) that you incur. Now, i'm guessing i may be the one responsible for the practices of big.net, but i do encourage other big.nets to enable u-rpf strict or loose wherever possible based on their equipment capabilities. Every little bit will help. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: icmp rpf
On Monday, 2006-09-25 at 10:09 MST, Mark Kent [EMAIL PROTECTED] wrote: Mark Smith replied with two paragraphs, but it's not 100% clear to me that he got the reason why I asked. I asked because his initial statement boiled down to numbering on un-announced space breaks PMTUD... but it doesn't, not by itself (which he later expanded). It only does so in the presence of filtering. Which is exactly what one might expect to happen. At least it seems to me that RFC 3704 (BCP 84, http://www.ietf.org/rfc/rfc3704.txt) applies. When your traffic is sourced with dubious addresses, you should expect much of it to disappear. And when this happens, you're hurting your customers and your customers' customers (okay, sometimes it's just your peer's customers - still a concern in my opinion). -- Tony Rall
the anti botnet market for ISPs and corporate networks
Is here. Several companies are rehearsing their old products and buzzwording them for DDoS mitigation or botnets, but not Trend Micro. Trend Micro released a brand new product, implemented with the novel idea of utilizing DNS to detect bots on an ISP or corporate network. Whether by massive requests for a CC (bots phoning home) or massive requests for an MX record (spam bots), looking for negative caching (NX being cached (as the CC is not there yet but requested) and beyond. It works. I don't know if that's what Trend Micro is doing, but it's one step in the right direction to better botnet detection and mitigation. Larry Seltzer wrote a good article on it: http://www.eweek.com/article2/0,1759,2020286,00.asp This idea has been explored before: The Domain Name Service as an IDS - NANOG archives: http://www.irbs.net/internet/nanog/0602/0537.html and: http://blogs.securiteam.com/index.php/archives/321 My poor choice of subject lines with quoting the paper's name (IDS) rather than saying better utilizing DNS to detect infeted hosts and kill CC's got me a lot of flames on being off topic. It also got me a warning on DNS being off-topic, which was withdrawn on-list. The original paper can be found, here: http://staff.science.uva.nl/~delaat/snb-2005-2006/p12/report.pdf (these guys were cool enough to reference me, hehe) Other papers were linked to from the above mentioned post. This is pretty cool, and is worth a look. I guess we will find out what this commercialized technology is worth now that it is out of the home-grown/academic tools realm. Gadi.
Re: TCP receive window set to 0; DoS or not?
At 21:55 08/09/2006, Jim Shankland wrote: Travis Hassloch [EMAIL PROTECTED] writes: The part where it becomes a DoS is when they tie up all the listeners on a socket (e.g. apache), and nothing happens for several minutes until their connections time out. Whether intentional or not, it does have a negative effect. Ah, that makes sense. I was assuming a deliberate attack, which is not actually implicit in the term DoS. A deliberate denial of service is not made easier by shrinking the window. But an implementation that advertises a 0 window in lieu of sending FIN or RST can certainly deny service inadvertently by tying up resources that should have been freed. FYI, this issue was raised at the IETF TCPM WG mailing-list a month ago or so. The OP argued to reduce the amount of time for which a peer could advertise a 0 window. However, the problem is that if the goalis to perform a DoS attack, the attacker could advertise a 1-byte window (or ay other small window). Or he could advertise a 0-window for some time (less than the threshold the OP proposed), then increase the window to, say, one segment, and then go back to advertising a 0 window. The OP had suggested seeing this behaviour tying up all system resources, hence leading to the attacked system to not be able to service legitimate systems. There seemed to be agreement as at the TCPM WG that yu should handle these scenarios at the application layer. Kindest regards, -- Fernando Gont e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
2005-02 implementation: IP assignments for anycasting DNS
Dear Colleagues, Following a request, this announcement is being sent to a few ops focused mailing lists. We are pleased to announce that we will be able to accept e-mailed requests for assignments for anycasting DNS servers from 2 October 2006. The request form and supporting notes will be available from the RIPE Document Store at: http://www.ripe.net/ripe/docs/internet-registries.html We will make a separate announcement when it is possible to make requests via the LIR Portal. Assignments for anycasting DNS will come from reserved blocks: * IPv4 Anycast Assignments (/24) from 194.0.0.0/18 * IPv6 Anycast Assignments (/48) from 2001:0678::/29 You may want to update your filters. Regards, -- leo vegoda RIPE NCC Registration Services Manager pgpsDI9FmXxrK.pgp Description: PGP signature
Re: icmp rpf
At 10:06 25/09/2006, Ian Mason wrote: One of the largest North American network providers filters/drops ICMP messages so that they only pass those with a source IP address that appears in their routing table. This is clearly reasonable as part of an effort to mitigate ICMP based network abuse. As a matter of fact, most ICMP-based attacks don't require spoofing of the source IP address. You do have to spoof the addresses in the original datagram included in the ICMP payload, though. Kindest regards, -- Fernando Gont e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Bad cross post
My apologies to the list for my forward post from the DA list. I was wading through nanog mail and simply not paying attention to subject tags when I replied. Completely unintentional. -b -- sent from my blackberry (typing with thumbs)
Re: icmp rpf
I asked: Who among AS1239, AS701, AS3356, AS7018, AS209 does loose RPF (not just strict RPF on single-homed customers)? and Patrick answered: I'm wondering why that is relevant. It's relevant because it was suggested that loose RPF should be a best common practice so I was curious which of those ASes decided that the benefits outweighed the negatives and actually do it. Don't worry, those were randomly chosen AS. I didn't intend to make any suggestion that the answer would be more important to me for that set of ASes than any other. But, you were correct that I wasn't asking the question I really wanted answered. What I wanted to know was, among the attentive nanog membership, which of you think and/or know that any/all of those AS do loose RPF? The motivation here is that, if asked last week, I would have guessed that none of them run loose RPF. But at least one of them does. The two answers, how many actually do plus whether everyone knew it, will help me decide if I need to spend more time reading nanog email and nanog proceedings (or actually go to a meeting), or not... Thanks, -mark
Re: Comcast contact
Anshuman: A good place to start for operational contacts is both the puck.nether.net site and the www.peeringdb.com. i found this: http://puck.nether.net/netops/nocs.cgi?ispname=comcast and this: (you can log in as a guest)... https://www.peeringdb.com/private/participant_view.php?id=822 now go get them peter cohen. On 9/25/06, Anshuman Kanwar [EMAIL PROTECTED] wrote: Can someone from comcast contact me off list please ? Thanks, Ansh Kanwar Lead Network Engineer -- Citrix Online (AS16815) 5385 Hollister Avenue Santa Barbara, CA 93111 USA --
Re: icmp rpf
On Sep 26, 2006, at 11:57 AM, Mark Kent wrote: I asked: Who among AS1239, AS701, AS3356, AS7018, AS209 does loose RPF (not just strict RPF on single-homed customers)? and Patrick answered: I'm wondering why that is relevant. It's relevant because it was suggested that loose RPF should be a best common practice so I was curious which of those ASes decided that the benefits outweighed the negatives and actually do it. Don't worry, those were randomly chosen AS. I didn't intend to make any suggestion that the answer would be more important to me for that set of ASes than any other. The actual practices of a network are not necessarily a way to look at what best common practices should be. For instance, how many networks are in full compliance with BCP38? Or are you arguing that since essentially no one is compliant, we should scrap the BCP? But, you were correct that I wasn't asking the question I really wanted answered. What I wanted to know was, among the attentive nanog membership, which of you think and/or know that any/all of those AS do loose RPF? The motivation here is that, if asked last week, I would have guessed that none of them run loose RPF. But at least one of them does. The two answers, how many actually do plus whether everyone knew it, will help me decide if I need to spend more time reading nanog email and nanog proceedings (or actually go to a meeting), or not... Good question. waits for answers -- TTFN, patrick
Re: icmp rpf
On Tue, Sep 26, 2006 at 01:41:52PM -0400, Patrick W. Gilmore wrote: For instance, how many networks are in full compliance with BCP38? I've been working towards this on our network for some time but have been hindered by vendor.. uhm, features^Wbugs. eg: halving the TCAM with rpf enabled, one mode globally (loose vs strict) and other challenges. It is hard to imagine that we'll reach that point but that doesn't mean it's not a goal. Or are you arguing that since essentially no one is compliant, we should scrap the BCP? But, you were correct that I wasn't asking the question I really wanted answered. What I wanted to know was, among the attentive nanog membership, which of you think and/or know that any/all of those AS do loose RPF? The motivation here is that, if asked last week, I would have guessed that none of them run loose RPF. But at least one of them does. The two answers, how many actually do plus whether everyone knew it, will help me decide if I need to spend more time reading nanog email and nanog proceedings (or actually go to a meeting), or not... Good question. Well, digging out messages from archives http://www.merit.edu/mail.archives/nanog/2002-05/msg00289.html These features have been available in some form since at least 2002. That has given people at least a 4 year window of time to consider how much to reduce the (quoting barry) noise on the internet. I recall hearing of various root-server operators about what percentage of the packets they get they just can't respond to. This noise has cost to the common infrastructure that is used globally. You wouldn't believe which GTLD operator tried to spin up some government agencies about how bad the reflector attacks were to their infrastructure. It could be interpreted that they wanted a government subsidy to cover these increased infrastructure costs they would have to incur to handle the traffic. This is just one example (recently) of what happens without filters in-place. Not everyone on the list provides access to US Gov't agencies, but if they changed their purchasing to only acquire access from BCP38 compliant providers, would that impact the way you did business? Would it get insert-long-list-of-asns to change their network practices and hardware? I think any reasonable (market based) approaches to help nudge things in the right direction is better than if we were to hear the dreaded R word. That would not be a good situation for most of us. There are plenty that will advocate all sorts of positions, and it's honestly up to us to do the right thing for the right reasons otherwise we may see an even more imperfect solution come our ways. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: decline of customer service
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Lavine Sent: Monday, September 25, 2006 11:50 PM To: nanog Subject: decline of customer service Times have changed, My experience has been recently that ISP's and ASP's have dramatically malnourished their first level support staff which in turn has created a resentful and lazy second teir. I am sick of the It must be your network/cabling/CPE attitude that I am getting from some teir 1 ISP's. I sick of replacing CSU's and checking extended demarcs while some clown in the POP is re-seating cards in the mux. Moreover stop accusing my network of latency issues. I ran the packet capture 100 times and the client is still send a FIN. The reason your application is slow is because your programmers think sockets are something you plug a can opener into. Finally, YOU are my vendor. I pay you money for exceptional service. Thank you for your time. Uh OK. Where did this come from? Did Philip have a seisure? ARE YOU OK PHILIP? :-P Brian
