"Supposedly"/"Allegedly"/"Theoretically", rumor mill has it that a worm exploit of sorts has been published. My Russian is so so, not good enough to make sense it a majority of what was posted. A translation made me want to yank my hair out. // CLIP On September, 19th, 2005 19th September in ? the expert in the field of safety Andrey Vladimirovym (? dr_nicodimus), known as the co-author of the book " Wi-Foo: The Secrets of Wireless Hacking ", the information on the termination of " brain storm ", directed on operation ? in the software of products of company Cisco has been published. As a result of research in Cisco IOS and methods of a writing exploit and shellcode methods of introduction of a code have been developed for this platform. Mechanisms of realization ................... a worm for IOS are developed." // END CLIP Someone set us up the bomb! Translations are horrible. Further down the road in this article, someone points to "Cisco Games" from an ezine. So here is that copy with no silly little uploader javafoofoofoo scripting bs. www.infiltrated.net/cisco/ciscogames.html =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x97B43D89 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x97B43D89 "Just one more time for the sake of sanity tell me why explain the gravity that drove you to this..." Assemblage
----- Original Message ----- From: "J. Oquendo" <sil@politrix.org> To: <nanog@nanog.org> Sent: Monday, September 19, 2005 10:23 AM Subject: IOS exploit
"Supposedly"/"Allegedly"/"Theoretically", rumor mill has it that a worm exploit of sorts has been published. My Russian is so so, not good enough to make sense it a majority of what was posted. A translation made me want to yank my hair out.
i'll help with the translation :) On Sept 9, Andrey Vladimirov (aka dr_nicodimus), known as a co-author of the book 'Wi-Foo: The Secrets of Wireless Hacking', published information about the end [result] of a "brainstorm session" aimed at [developing ways of] exploiting vulnerabilities in software running on Cisco products. This research has led to the development of techniques which can be used to inject executable code into Cisco IOS as well as to write exploits and shellcode for this platform. Methods of implementing a cross-platform worm targetting IOS have also been developed. A plethora of vulnerabilities have been discovered in the "firmware" implementation of the routing protocol EIGRP. As a demonstration, an attack from one Cisco aimed at another was successful in launching an irc server on the target. --- not translating the rest, since it's largely non-technical and contains a derogatory reference to coders in a certain asian country. --- -p --- paul galynin
Reading through the original Russian posting here http://www.securitylab.ru/news/240415.php&direction=re&template=General&cp1= It seems that someone has built an IOS worm that follows an EIGRP vector from router to router. I would say that means that enterprise networks are in more immediate danger than ISPs, however... This could be the first of many. The article does say that this is based on cross platform exploits but it isn't clear whether they mean "across different Cisco platforms" or whether there is some way for PCs to infect routers. The article has the tone of something written by a 3rd party therefore some of the facts may be a bit twisted. They do use this opportunity to point out that security through obscurity ain't all it's cracked up to be. Advice for reading Russian. When you get into difficulty, run the Russian through a machine translator using the PROMT engine like http://translation1.paralink.com and then GO BACK AND RE-READ the original Russian. Your brain will now be able to make a more accurate translation on the second pass. --Michael Dillon
Michael.Dillon@btradianz.com wrote:
Reading through the original Russian posting here http://www.securitylab.ru/news/240415.php&direction=re&template=General&cp1= It seems that someone has built an IOS worm that follows an EIGRP vector from router to router.
A while back I emailed the following text to a closed mailing list. I figure now that quite a few cats are out of the bag it is time to get more public attention to these issues, as the Bad Guys will very soon start doing just that. Ciscogate by itself ALONE, and now even just a story about worms for Routers is enough for us to be CLEAR that worms will start coming out. We do learn from history. So.. as much as people don't like to talk much on the issues involving the so-called "cooler" stuff that can be done with routers, now is the time to start. Here is one possible and simple vector of attack that I see happening in the future. It goes down-hill from there. I wrote this after the release of "the three vulnerabilities", a few months back. Now we know one wasn't even just a DDoS, and that changes the picture a bit. Begin quoted text ----->>> More on router worms - let's take down the Internet with three public POCs and some open spybot source code. -------------------------------------- People, I have given this some more thought. Let's forget for a second the fact that these vulnerabilities are dangerous on their own (although it's a DoS), and consider what a worm, could cause. If the worm used the vulnerability, it would shoot itself in the leg as when network is down, it can't spread. Now, imagine if a VX-er will use an ancient trick and release the worm, waiting for it to propagate for 2 or 3 days. Then, after that seeding time when the say.. not very successful worm infected only about 30K machines around the world, each infected host will send out 3 "One Packet Killers" as I like to call them to the world. Even if the packet won't pass one router, that one router, along with thousands of others, will die. Further, the latest vulnerabilities are not just for Cisco, there is a "One Packer Killer" for Juniper as well. So, say this isn't a 0-day. Tier-1 and tier-2 ISP's are patched (great mechanism to pass through as these won't filter the packed out if it is headed somewhere else), how many of the rest will be up to date? Let's give the Internet a lot of credit and say.. 60% (yeah right). That leaves us with 30% of the Internet dead, and that's really a bad scenario as someone I know would say. Make each infected system send the one packet spoofed (potentially, not necessarily these vulnerabilities) and it's hell. Make them send it every day, once! And the net will keep dying every day for a while. As a friend suggested, maybe even fragment the packet, and have it re-assembled at the destination, far-away routers (not sure if that will work). These are all basic, actually very basic, techniques, and with the source to exploits and worms freely available.... We keep seeing network equipment vulnerabilities coming out, and it is a lot "cooler" to bring down an ISP with one packet rather than with 1,000,000,000,000,000. I am sure the guys at Cisco gave this some thought, but I don't believe this is getting enough attention generally, and especially not with AV-ers. It should. This may seem like I am hyping the situation, which is well-known. Still well-known or not, secret or not, it's time we prepared better in a broader scale. How? Gadi. ----->>> End quoted text. I would really like to hear some thoughts from the NANOG community on threats such as the one described above. Let us not get into an argument about 0-days and consider how many routers are actually patched the first... day.. week, month? after a vulnerability is released. Also, let us consider the ever decreasing vulnerability-2-exploit time of development. I don't want the above to sound as FUD. My point is not to yell "death of the Internet" but rather to get some people moving on what I believe to be a threat, and considering it on a broader scale is LONG over-due. The cat is out of the bag, as as much as I avoided using "potentially" and "possibly" above to pass my point.. this is just one possible scenario and I believe we need to start getting prepared to better defending the Internet as an International Infrastructure. As I am sure that this will be an interesting discussion, I am also sure this will eventually derail to a pointless argument over an un-related matter, here on NANOG. I'd appreciate if people who are interested would also email me off-list so that we can see how we can perhaps proceed with some activity. Thanks, Gadi Evron. -- Available for consulting: +972-50-5428610 / ge@linuxbox.org.
* Gadi Evron:
I would really like to hear some thoughts from the NANOG community on threats such as the one described above. Let us not get into an argument about 0-days and consider how many routers are actually patched the first... day.. week, month? after a vulnerability is released.
The bad guys obviously aren't interested in taking down the Internet. I wouldn't worry too much. 8-)
I don't want the above to sound as FUD. My point is not to yell "death of the Internet" but rather to get some people moving on what I believe to be a threat, and considering it on a broader scale is LONG over-due.
I would ask some people who have experienced meltdowns on large-scale networks, due to Slammer, Blaster or something else. Basically, what do you do when you don't have management access to your network gear anymore, and stuff like that. To some extent, what you fear has already happened, and we could learn from that.
On Mon, 19 Sep 2005, Florian Weimer wrote:
* Gadi Evron:
I would really like to hear some thoughts from the NANOG community on threats such as the one described above. Let us not get into an argument about 0-days and consider how many routers are actually patched the first... day.. week, month? after a vulnerability is released.
The bad guys obviously aren't interested in taking down the Internet. I wouldn't worry too much. 8-)
I don't want the above to sound as FUD. My point is not to yell "death of the Internet" but rather to get some people moving on what I believe to be a threat, and considering it on a broader scale is LONG over-due.
I'm curious as to why people think that the problem isn't being addressed?
I would ask some people who have experienced meltdowns on large-scale networks, due to Slammer, Blaster or something else. Basically, what do you do when you don't have management access to your network gear anymore, and stuff like that.
To some extent, what you fear has already happened, and we could learn from that.
* Christopher L. Morrow:
I'm curious as to why people think that the problem isn't being addressed?
Do you see a business case for ISPs to help mass-market customers to clean up their infected PCs? I still hear claims from the ISP folks that anything but prevention isn't viable, and all available data suggests that prevention is an utter and complete failure. (Okay, maybe I'm exaggerating a bit, but you get the idea.)
On Mon, 19 Sep 2005, Florian Weimer wrote:
* Christopher L. Morrow:
I'm curious as to why people think that the problem isn't being addressed?
Do you see a business case for ISPs to help mass-market customers to clean up their infected PCs?
Nope, but I see a business case for software vendors to fix their problems, and for education of the people that are a problem. I'm not sure it'll fix the problem either, but blocking ports hasn't been wholey effective either, especially not when you consider RPC-over-http now :( hurray!
I still hear claims from the ISP folks that anything but prevention isn't viable, and all available data suggests that prevention is an
Mostly this is probably true. Consumer ISP's are in a rough battle of idiots/users versus 'next exploit against the most common platform deployed'. Sure there are stupidities committed by other than software vendors (how many routers have login passwd: cisco and no vty acl? How many cayman/dsl routers are out there with default userid/passwd and remove management enabled? How many wireless AP's are there with default admin setup? ... for fun, try the one at the Baron's Cove Inn in Sag Harbor... poor folks :( ) The issue of 'are consumer users getting better/worse/owned/deleted' isn't really the problem, the issue is "Is the Internet being treated as 'Critical Infrastructure' by some people in a position to make it 'better'?" I'd say that yes, there are lots of folks that consider their little piece of the Internet to be 'critical' and who are making steps where they can to ensure it's protected to the best of their ability. Just because folks aren't out beating drums daily doesn't mean the work isn't getting done. So, what leads you to believe it's NOT getting fixed/looked-at/worked/considered?
utter and complete failure. (Okay, maybe I'm exaggerating a bit, but you get the idea.)
I think Sean Donelan has some numbers about this... or we could google search the nanog archives :)
On Mon, 19 Sep 2005 21:16:57 -0000, "Christopher L. Morrow" said:
I'm curious as to why people think that the problem isn't being addressed?
This one is amenable to "Pentagon Pizza" analysis, similar to the big flurry of IOS patching around April of last year for the RST issue. Anybody been seeing flaps/burbs with their Tier1 peers during maintenance windows the last few days? :)
On Mon, 19 Sep 2005 Valdis.Kletnieks@vt.edu wrote:
On Mon, 19 Sep 2005 21:16:57 -0000, "Christopher L. Morrow" said:
I'm curious as to why people think that the problem isn't being addressed?
This one is amenable to "Pentagon Pizza" analysis, similar to the big flurry of IOS patching around April of last year for the RST issue.
Anybody been seeing flaps/burbs with their Tier1 peers during maintenance windows the last few days? :)
what, for that silly cisco worm? I mean... uhm... nevermind.
On Tue, 20 Sep 2005, Gadi Evron wrote:
I'm curious as to why people think that the problem isn't being addressed?
Can you be any more cryptic? :)
I can, but my name isn't randy bush :) Actually what I was thinking was: ISP's business depends upon their (and others actually) network working properly, for them large scale 'internet killer' outages are not a good thing. They employee (larger ISP's atleast) folks to think about this problem and plan reaction to it.... even plan preventitive measures for it :) Oh, and atleast the US and UK Gov'ts are interested in 'infrastructure', though often their interest ends with the phrase: "Someone should make a law..." at which point the ISP person(s) say: "And I'll move my <insert bad thing that needs regulation now> off to the Cayman Islands/Russia/China where your 'law' doesn't matter... so lets make this solution not about the 'law' so much as making people realize it's the best thing to do." So, how isn't it being addressed?
So, how isn't it being addressed?
The idea of Critical Infrastructure gets addressed in many countries. Some of them do not include ISP's in the equation as they are a private business. Some day, but can't force ISP's to cooperate. Whatever gets done and re-done is local, whether by ISP or country and there is almost nothing getting done to treat this as a global, macro problem, and actually put in measures to combat it. Hence International Infrastructure. Gadi.
On Tue, 20 Sep 2005 08:44:33 +0200, Gadi Evron said:
Whatever gets done and re-done is local, whether by ISP or country and there is almost nothing getting done to treat this as a global, macro problem, and actually put in measures to combat it.
RFC2827 came out in May 2000. Based on its deployment history, where providers just have to act locally, I suspect that a requirement that providers act globally will result in either: a) I'll be collecting a pension and not really caring before it happens. b) We have a curious patchwork of laws foisted upon us, from various state, province, and country governments. In either case, I'm not going to hold my breath waiting for something workable to show up - that's a long time to spend being an odd shade of blue....
RFC2827 came out in May 2000.
And that's something I will drink to every day. What has happened with it since?
Based on its deployment history, where providers just have to act locally, I suspect that a requirement that providers act globally will result in either:
a) I'll be collecting a pension and not really caring before it happens.
b) We have a curious patchwork of laws foisted upon us, from various state, province, and country governments.
In either case, I'm not going to hold my breath waiting for something workable to show up - that's a long time to spend being an odd shade of blue....
There are solutions that don't have to be based on legislation. I don't have all the answers but acknowledging the problems is something that should be done. Gadi.
On Wed, 21 Sep 2005 01:17:25 +0200, Gadi Evron said:
And that's something I will drink to every day. What has happened with it since?
Exactly.
a) I'll be collecting a pension and not really caring before it happens.
b) We have a curious patchwork of laws foisted upon us, from various state, province, and country governments.
In either case, I'm not going to hold my breath waiting for something workable to show up - that's a long time to spend being an odd shade of blue....
There are solutions that don't have to be based on legislation. I don't have all the answers but acknowledging the problems is something that should be done.
See likely outcome (a). Keep in mind that the problem isn't the providers that already do altruistic things like BCP38, actually reading their abuse@ mailbox, and dealing with zombied users. Said solution will have to deal effectively with the problematic providers. And quite frankly, if they haven't gotten the ROI message regarding cleaning house *yet*, they're unlikely to do it unless "Do it or go to jail/other penalties" happens. To stem the usual flood of tired suggestions, I'd recommend *not* following up with "If we all did XYZ" unless you have in fact gotten at least one problem provider (whom you were *not* employed by at the time) to implement XYZ.
On Tue, 20 Sep 2005 Valdis.Kletnieks@vt.edu wrote:
On Tue, 20 Sep 2005 08:44:33 +0200, Gadi Evron said:
Whatever gets done and re-done is local, whether by ISP or country and there is almost nothing getting done to treat this as a global, macro problem, and actually put in measures to combat it.
RFC2827 came out in May 2000.
Based on its deployment history, where providers just have to act locally, I suspect that a requirement that providers act globally will result in either:
Well.. it could be worse, according to the results in http://spoofer.csail.mit.edu/, at least by some metrics, about 2/3 or 3/4 of networks are unspoofable. That's already pretty good improvement.. FWIW, here in Finland the regulatory body is mandating certain amount of spoofing prevention and other things. Transit providers (to whatever definition of 'transit') could maybe also be a bit more strict on what they accept from downstream.. Btw. Juniper's Feasible Path uRPF (mentioned in RFC3704) is your friend, even on multihomed/asymmetric links. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Wed, 21 Sep 2005, Pekka Savola wrote:
Btw. Juniper's Feasible Path uRPF (mentioned in RFC3704) is your friend, even on multihomed/asymmetric links.
So, say I'm a large consumer broadband ISP, and I made the decision some years ago to use net-10 as my infrastructure space? How does 'feasible path' help block 10.x.x.x sources exactly?
Btw. Juniper's Feasible Path uRPF (mentioned in RFC3704) is your friend, even on multihomed/asymmetric links. So, say I'm a large consumer broadband ISP, and I made the decision some years ago to use net-10 as my infrastructure space? How does 'feasible path' help block 10.x.x.x sources exactly?
as ye sow, so shall ye reap when you shoot yourself in the foot, just because you are so neurally broken that the signal takes years to register in your brain, it does not mean that your foot does not have a hole in it. randy
On Wed, 21 Sep 2005, Randy Bush wrote:
Btw. Juniper's Feasible Path uRPF (mentioned in RFC3704) is your friend, even on multihomed/asymmetric links. So, say I'm a large consumer broadband ISP, and I made the decision some years ago to use net-10 as my infrastructure space? How does 'feasible path' help block 10.x.x.x sources exactly?
as ye sow, so shall ye reap
when you shoot yourself in the foot, just because you are so neurally broken that the signal takes years to register in your brain, it does not mean that your foot does not have a hole in it.
somewhat agreed :) At the time I'd think that the providers in question (lots of other normal network people made the same 'decision' I might add) didn't think it'd be a good idea to get a /8 allocation from *RIR for internal infrastructure that they never planned on being reachable from the outside world. anyway, I just don't want folks to get the wrong impression about either uRPF or 'feasible path'. They are tools, they have implications when used, if you don't understand them you will be making holes in someone's feets :(
On Wed, 21 Sep 2005, Christopher L. Morrow wrote:
On Wed, 21 Sep 2005, Pekka Savola wrote:
Btw. Juniper's Feasible Path uRPF (mentioned in RFC3704) is your friend, even on multihomed/asymmetric links.
So, say I'm a large consumer broadband ISP, and I made the decision some years ago to use net-10 as my infrastructure space? How does 'feasible path' help block 10.x.x.x sources exactly?
Sorry, I don't understand the context to see the problem. If you use 10.x.x.x internally in your backbone, you're fine because that cruft shouldn't be coming at your direction from the customers. If you also use 10.x.x.x to assign addresses to the CPE boxes (which is what I think you're saying), the customer can only spoof one /30 from 10/8 (or whatever has been assigned on the CPE and/or the point-to-point link). You may also consider using uRPF at the CPE box to disallow the customer from spoofing anything in that infrastructure space (particularly the /30). At your borders (upstream/peers), you will naturally block all of 10/8 at egress. While uRPF might or might not be sufficient to protect *your* infrastructure from worms (if the customer happens to spoof "just the right way"), it should be useful in preventing spoofing affecting others' infrastructure. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Thu, 22 Sep 2005, Pekka Savola wrote:
On Wed, 21 Sep 2005, Christopher L. Morrow wrote:
On Wed, 21 Sep 2005, Pekka Savola wrote:
Btw. Juniper's Feasible Path uRPF (mentioned in RFC3704) is your friend, even on multihomed/asymmetric links.
So, say I'm a large consumer broadband ISP, and I made the decision some years ago to use net-10 as my infrastructure space? How does 'feasible path' help block 10.x.x.x sources exactly?
Sorry, I don't understand the context to see the problem.
Sorry, I'll restate my question. Based on this reading of the 7.3 docs on junipers website (http://tinyurl.com/dodme): feasible-paths: Consider all feasible paths during the unicast reverse-path check. I think if a packet enters an interface with this configuration set will have it's source address checked for a path in the FIB... not a path back down the same interface, just any path, say to china or your dsl link or whatever. So, assuming the network above where 10/8 is in the FIB any packet with a source inside 10/8 will pass this check, yes?
If you use 10.x.x.x internally in your backbone, you're fine because that cruft shouldn't be coming at your direction from the customers.
why not? their hosts all can spoof sources, they SHOULD have filters on their CPE to prevent spoofed sources out of their network, but that's not widely deployed is it? (well not reliably deployed atleast)
If you also use 10.x.x.x to assign addresses to the CPE boxes (which is what I think you're saying), the customer can only spoof one /30
Nope, I'm saying all my infrastructure is numbered from 10/8 (my fictional networks infrastructure...). The customers might have real addresses in 24/8 or 168.157/16 or anyother legittimate ip range.
You may also consider using uRPF at the CPE box to disallow the customer from spoofing anything in that infrastructure space (particularly the /30).
Sure, but I don't run the CPE, the customer does... it's their decision though I may suggest strongly to them that it'd be a cost savings to them to do uRPF strict, or acls or something along those lines, they don't have to take my suggestions.
At your borders (upstream/peers), you will naturally block all of 10/8 at egress.
my border is very broad and it's not feasible to use acls on all equipment that makes up that edge :( (for the sake of arguement, which is now far afield from the original question: "Feasible path won't stop someone spoofing space thats in my FIB, will it?"
While uRPF might or might not be sufficient to protect *your* infrastructure from worms (if the customer happens to spoof "just the right way"), it should be useful in preventing spoofing affecting others' infrastructure.
Also, consider the cases where customers push packets your way (for uRPF strict, which isn't available for JunOS, but is for IOS depending on platform/code/hardware-rev... ugh!) and never send you a route for the traffic back to them? Maybe they are just a transit and don't even hear the routes for their customer who chose a 'cheaper' path that doesn't include them nor me directly on this link in question? uRPF is not the be-all-end-all of the spoofing problem. It has some significant implications for networks and customers. Simply blindly saying: "turn on uRPF XXX-mode and all is good" is simply irresponsible. But, back on the original question: "does urpf feasible path stop a 'customer' from spoofing sources that are in the FIB?" My reading of the documentation suggest not :( So, what does it accomplish? (extend the use of net-10 to perhaps other private or unallocated ranges used for other purposes...) It may stop some portion of spoofed packets from the customer, but likely not anything of consequence, certainly not if they use tried-and-true juno2.c :( or others of it's ilk. -Chris
On Thu, 22 Sep 2005, Christopher L. Morrow wrote:
Sorry, I'll restate my question. Based on this reading of the 7.3 docs on junipers website (http://tinyurl.com/dodme):
The juniper documentation is notoriously bad...
feasible-paths: Consider all feasible paths during the unicast reverse-path check.
I think if a packet enters an interface with this configuration set will have it's source address checked for a path in the FIB... not a path back down the same interface, just any path, say to china or your dsl link or whatever. So, assuming the network above where 10/8 is in the FIB any packet with a source inside 10/8 will pass this check, yes?
Not quite (feasible path check is different from loose RPF) -- I didn't understand the documentation myself at first we had to open a case to get this cleared :-(. I was not sure of your example, but I think what you're saying.. Let me try to clarify. Let's assume you have a router with one interface to the customer with 1.1.1.0/24 and 10.1.1.0/30 on that link. If you enable strict uRPF towards the customer, only packets coming from 1.1.1.0/24 or 10.1.1.0/30 are accepted (except if you have a more specific route). Now, let's consider you have the second interface to the customer (let's say on the same router, for simplicity) which has the same 1.1.1.0/24 but different 10.1.2.0/30. With simple strict uRPF, only one of the interfaces is active at the time. If the traffic is asymmetric, packets will get dropped coming from the wrong customer's interface. Feasible RPF (or possibly manual tuning of route preferences to affect strict RPF) helps here. It allows packets from 1.1.1.0/24 from both interfaces no matter which one is active at the moment. So, you could consider feasible path RPF to be "strict RPF++". The customer cannot send packets (on either interface) from any source address other than 1.1.1.0/24, 10.1.1.0/30, and 10.1.2.0/30 -- even if you have a route to one of these networks pointing somewhere else.
If you use 10.x.x.x internally in your backbone, you're fine because that cruft shouldn't be coming at your direction from the customers.
why not? their hosts all can spoof sources, they SHOULD have filters on their CPE to prevent spoofed sources out of their network, but that's not widely deployed is it? (well not reliably deployed atleast)
By "shouldn't be coming" I meant "shouldn't be accepted if you use strict/feasible uRPF towards the customer". The packets may get there but they'll be dropped.
At your borders (upstream/peers), you will naturally block all of 10/8 at egress.
my border is very broad and it's not feasible to use acls on all equipment that makes up that edge :( (for the sake of arguement, which is now far afield from the original question: "Feasible path won't stop someone spoofing space thats in my FIB, will it?"
If it's your customer, you can prevent them from spoofing. If it's not your customer, you obviously can't do much. (FWIW, we drop all the packets at peering/upstream links with our source addresses, but it may not be an option for you.) One could run RPF on some such links but doing so is a bit risky as it assumes that the routing announcements are always sane.
Also, consider the cases where customers push packets your way (for uRPF strict, which isn't available for JunOS, but is for IOS depending on platform/code/hardware-rev... ugh!)
Uhh? uRPF strict is definitely availabe for JunOS.. we've used it for 3-4 years towards all the customers..
and never send you a route for the traffic back to them? Maybe they are just a transit and don't even hear the routes for their customer who chose a 'cheaper' path that doesn't include them nor me directly on this link in question?
For uRPF to work, you have to have a route toward the interface. With feasible path strict uRPF, the route doesn't need to be active (e.g., it can be prepended so that it's never used).
uRPF is not the be-all-end-all of the spoofing problem. It has some significant implications for networks and customers. Simply blindly saying: "turn on uRPF XXX-mode and all is good" is simply irresponsible.
Well, I think if you DO turn on uRPF strict, there WILL NOT be spoofing, but in many cases you break stuff if you're not careful so I agree in general that just there will need to be additional discussion.
But, back on the original question:
"does urpf feasible path stop a 'customer' from spoofing sources that are in the FIB?"
Yes. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
oh the joys of urpf :( On Thu, 22 Sep 2005, Pekka Savola wrote:
On Thu, 22 Sep 2005, Christopher L. Morrow wrote:
Sorry, I'll restate my question. Based on this reading of the 7.3 docs on junipers website (http://tinyurl.com/dodme):
The juniper documentation is notoriously bad...
you don't say? :)
feasible-paths: Consider all feasible paths during the unicast reverse-path check.
I think if a packet enters an interface with this configuration set will have it's source address checked for a path in the FIB... not a path back down the same interface, just any path, say to china or your dsl link or whatever. So, assuming the network above where 10/8 is in the FIB any packet with a source inside 10/8 will pass this check, yes?
Not quite (feasible path check is different from loose RPF) -- I didn't understand the documentation myself at first we had to open a case to get this cleared :-(. I was not sure of your example, but I think what you're saying..
Let me try to clarify.
Let's assume you have a router with one interface to the customer with 1.1.1.0/24 and 10.1.1.0/30 on that link. If you enable strict uRPF towards the customer, only packets coming from 1.1.1.0/24 or 10.1.1.0/30 are accepted (except if you have a more specific route).
Now, let's consider you have the second interface to the customer (let's say on the same router, for simplicity) which has the same 1.1.1.0/24 but different 10.1.2.0/30. With simple strict uRPF, only one of the interfaces is active at the time. If the traffic is asymmetric, packets will get dropped coming from the wrong customer's interface.
Feasible RPF (or possibly manual tuning of route preferences to affect strict RPF) helps here. It allows packets from 1.1.1.0/24 from both interfaces no matter which one is active at the moment. So, you could consider feasible path RPF to be "strict RPF++".
The customer cannot send packets (on either interface) from any source address other than 1.1.1.0/24, 10.1.1.0/30, and 10.1.2.0/30 -- even if you have a route to one of these networks pointing somewhere else.
Meaning the customer also has 23.23.23.0/24 which they have routed into your network on some other router on your network, that traffic isn't accepted on the 2 links above... which is much more like 'strict' mode.
If it's your customer, you can prevent them from spoofing.
If it's not your customer, you obviously can't do much. (FWIW, we drop all the packets at peering/upstream links with our source addresses, but it may not be an option for you.) One could run RPF on some such links but doing so is a bit risky as it assumes that the routing announcements are always sane.
This has proven very untrue :(
Also, consider the cases where customers push packets your way (for uRPF strict, which isn't available for JunOS, but is for IOS depending on platform/code/hardware-rev... ugh!)
Uhh? uRPF strict is definitely availabe for JunOS.. we've used it for 3-4 years towards all the customers..
the documentation again is probably lacking :( it doesn't mention strict, just 'active' and 'feasible'.
and never send you a route for the traffic back to them? Maybe they are just a transit and don't even hear the routes for their customer who chose a 'cheaper' path that doesn't include them nor me directly on this link in question?
For uRPF to work, you have to have a route toward the interface. With feasible path strict uRPF, the route doesn't need to be active (e.g., it can be prepended so that it's never used).
often it's never sent on this link at all, I don't pretend to understand why a customer would do this, they just do.
uRPF is not the be-all-end-all of the spoofing problem. It has some significant implications for networks and customers. Simply blindly saying: "turn on uRPF XXX-mode and all is good" is simply irresponsible.
Well, I think if you DO turn on uRPF strict, there WILL NOT be spoofing, but in many cases you break stuff if you're not careful so I agree in general that just there will need to be additional discussion.
But, back on the original question:
"does urpf feasible path stop a 'customer' from spoofing sources that are in the FIB?"
Yes.
excellent! learned something new today :)
On Thu, 22 Sep 2005, Christopher L. Morrow wrote:
Not quite (feasible path check is different from loose RPF) -- I didn't understand the documentation myself at first we had to open a case to get this cleared :-(. I was not sure of your example, but I think what you're saying..
Let me try to clarify.
Let's assume you have a router with one interface to the customer with 1.1.1.0/24 and 10.1.1.0/30 on that link. If you enable strict uRPF towards the customer, only packets coming from 1.1.1.0/24 or 10.1.1.0/30 are accepted (except if you have a more specific route).
Now, let's consider you have the second interface to the customer (let's say on the same router, for simplicity) which has the same 1.1.1.0/24 but different 10.1.2.0/30. With simple strict uRPF, only one of the interfaces is active at the time. If the traffic is asymmetric, packets will get dropped coming from the wrong customer's interface.
Feasible RPF (or possibly manual tuning of route preferences to affect strict RPF) helps here. It allows packets from 1.1.1.0/24 from both interfaces no matter which one is active at the moment. So, you could consider feasible path RPF to be "strict RPF++".
The customer cannot send packets (on either interface) from any source address other than 1.1.1.0/24, 10.1.1.0/30, and 10.1.2.0/30 -- even if you have a route to one of these networks pointing somewhere else.
Meaning the customer also has 23.23.23.0/24 which they have routed into your network on some other router on your network, that traffic isn't accepted on the 2 links above... which is much more like 'strict' mode.
No, I just described here the simple case. The feasible path strict uRPF works if the customer connects to two routers as well. It's just required that all the prefixes are routed towards the customer's each interface (even if the routes would not be active). In the case of BGP, it requires that the customer advertises all the prefixes on each link, and that's it. What *isn't* supported, however, that forwards traffic to the ISP on a link without proper advertisements (when using BGP or a routing protocol) on *all* links. As said, the preferences can be adjusted in any suitable manner (this is different from plain strict uRPF), but the consistent advertisement must be there.
Also, consider the cases where customers push packets your way (for uRPF strict, which isn't available for JunOS, but is for IOS depending on platform/code/hardware-rev... ugh!)
Uhh? uRPF strict is definitely availabe for JunOS.. we've used it for 3-4 years towards all the customers..
the documentation again is probably lacking :( it doesn't mention strict, just 'active' and 'feasible'.
The configuration is done at two different places: under the forwarding options, you configure whether you want "plain" or "feasible". Under interfaces where you activate uRPF, you configure strict (the default) or loose.
and never send you a route for the traffic back to them? Maybe they are just a transit and don't even hear the routes for their customer who chose a 'cheaper' path that doesn't include them nor me directly on this link in question?
For uRPF to work, you have to have a route toward the interface. With feasible path strict uRPF, the route doesn't need to be active (e.g., it can be prepended so that it's never used).
often it's never sent on this link at all, I don't pretend to understand why a customer would do this, they just do.
Yeah, this is one of the things that cannot be fixed other than by educating the user. For example, smuggle it in the contract, and when the packets get dropped, explain the situation ;-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
At your borders (upstream/peers), you will naturally block all of 10/8 at egress.
my border is very broad and it's not feasible to use acls on all equipment that makes up that edge :( (for the sake of arguement, which is now far afield from the original question: "Feasible path won't stop someone spoofing space thats in my FIB, will it?"
The solution is a double border, possibly with VRF and inter-VRF routing Internal border sees 10/8 and 10/8 is in the FIB. 10/8 packets can be spoofed here, Infrastructure connects her External border doesn't see 10/8, 10/8 is NOT in the FIB, 10/8 packets can't be spoofed. Internet connects here. Internal <-> External links use routable IP space to not infect external with infrastructure routes. External border cannot talk to infrastructure IPs but it doesn't need to. External can route through infrastructure to customer CPE 10/8 can still be spoofed on the infrastructure but it will have to come from a customer, not from the Internet.
Also, consider the cases where customers push packets your way (for uRPF strict, which isn't available for JunOS, but is for IOS depending on platform/code/hardware-rev... ugh!) and never send you a route for the traffic back to them? Maybe they are just a transit and don't even hear the routes for their customer who chose a 'cheaper' path that doesn't include them nor me directly on this link in question?
This sounds like a broken design. Why have one way links? If a customer pushes packets my way and they don't announce that route to me I will drop the packets at my edge. If they want to send me those packets they need to announce. They can announce with AS path prepend x 1000 so I don't send them any traffic but the route needs to exist.
"does urpf feasible path stop a 'customer' from spoofing sources that are in the FIB?"
No, but you don't use feasible path on links aimed at your customer, you use strict. If your router doesn't support strict then talk to your purchasing department. -- Matthew S. Crocker Vice President Crocker Communications, Inc. Internet Division PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com
On Thu, 22 Sep 2005, Matthew Crocker wrote: <snip making networking more complicated than required>
Also, consider the cases where customers push packets your way (for uRPF strict, which isn't available for JunOS, but is for IOS depending on platform/code/hardware-rev... ugh!) and never send you a route for the traffic back to them? Maybe they are just a transit and don't even hear the routes for their customer who chose a 'cheaper' path that doesn't include them nor me directly on this link in question?
This sounds like a broken design. Why have one way links? If a
I didn't say I endorsed it, just that it happens, often. It's not a one way link either, the link may have thousands of routes advertised up it, just not a few key ones which are sources of traffic. Like I said earlier this morning, I have no idea why customers don't just send a prepended-to-hell route along this path for backup, but they don't... often.
customer pushes packets my way and they don't announce that route to me I will drop the packets at my edge. If they want to send me those
and you are breaking them... that's bad.
packets they need to announce. They can announce with AS path prepend x 1000 so I don't send them any traffic but the route needs to exist.
Sure, and every customer knows bgp/route-maps/policy as well as you... my point wasn't that it was a good or bad thing, just that it is.
"does urpf feasible path stop a 'customer' from spoofing sources that are in the FIB?"
No, but you don't use feasible path on links aimed at your customer,
great now we have conflicting answers :) perhaps I'll ask on j-nsp for clarification.
you use strict. If your router doesn't support strict then talk to your purchasing department.
The problem isn't the router, it's the cards in the router often :( Also, it's supposed to work according to the vendor, until you test and verify it doesn't :( doh! hint, don't by Engine-3 cards for your 12000's unless you don't care about urpf strict. hurray!
On Sep 19, 2005, at 9:23 AM, J. Oquendo wrote:
"Supposedly"/"Allegedly"/"Theoretically", rumor mill has it that a worm exploit of sorts has been published. My Russian is so so, not good enough to make sense it a majority of what was posted.
<snip> http://www.translate.ru/url/tran_url.asp?lang=ru&url=http%3A%2F% 2Fwww.securitylab.ru%2Fnews% 2F240415.php&direction=re&template=General&cp1=NO&cp2=NO&autotranslate=o n&transliterate=on&psubmit2.x=45&psubmit2.y=17 Stef Network Fortius, LLC
exploit of sorts has been published. My Russian is so so, not good enough to make sense it a majority of what was posted.
http://www.translate.ru/url/tran_url.asp?lang=ru&url=http%3A%2F%
Do you honestly believe that this URL enables one to "make sense" of the majority of what was posted? I think most people will get a clearer view by reading the three postings from people who know some Russian. --Michael Dillon
participants (11)
-
Christopher L. Morrow -
Florian Weimer -
Gadi Evron -
J. Oquendo -
Matthew Crocker -
Michael.Dillon＠btradianz.com -
Network Fortius -
Paul G -
Pekka Savola -
Randy Bush -
Valdis.Kletnieks＠vt.edu