The company I'm working for has had a security audit done which has identified low OSPF router priorities as a security risk. The generic blurb quoted in the explanation says that a malicious user can use this to influence routing decisions.
I've never heard of this as a vulnerability, its not mentioned in Cisco's router hardening guide, I can find no reference to this as a vunerability, and it doesn't make sense anyway.
- OSPF DR status is not pre-emptive. A router configured with a higher priority on a network segment will win the DR election ONLY if the current DR is lost, so this doesn't really represent a DoS vector.
- Even if this happens OSPF router priority influences the DR/BDR election per network segment, not the priority of links or routes.
- A malicious user does not need to be the DR on any network segment in order to influence routing, it simply needs to be fully adjacent and able to flood LSA’s.
I know there are reasons why you might nail down your DR, but is this really a security vulnerability? Has anyone heard of it? If so what is the vulnerability exactly?
Thanks in advance.
Like you i am struggling to see the risk.
Even if changing the priority would make a difference (and it doesn't as you say unless you can somehow reboot certain routers or deny them service) if someone got access to a router i can think of many things they could do that would have a far more damaging effect eg. shutting down an interface as a simple example, adding static routes to redirect traffic etc etc.
From my experience with security audits a lot of this type of thing is generated by software ie. they plug in every conceivable thing they can think of into the software and it churns out a huge report which the only way to effectively implement is to literally disconnect all network devices and go back to sharing data with memory sticks
Perhaps someone else can see the potential issue but honestly if they can get access to a router i think changing the OSPF priority is the least of your concerns.
Edit - potentially the person could add a router to the network segment running OSPF etc. but again as you say it is not preemptive. And if they can add a router then you definitely need to be looking at physical access to the networking devices.
I agree with comments so far, DR/BDR's are interface (segment specific- not router) so a malicious user would need physical access to the broadcast segment to attached and form an adjacency.
Saying that, if it was was possible to do this, the potential is still there for a router to form an adjacency and become a future potential DR/BDR
As you guys have said, Once the DR/BDR are elected even a new router with a better priortiy would not become either the DR/BDR when attched, but what if for some reason there is only a DR present on this segment and for some reason the routers are all drothers? - then this new router would become at least a BDR ( future DR)
So now if a DR/BDR election was inticated and this new router is elected as the new DR it would casue all drothers to send allDRrouter MC traffic towards it and in reply the new DR would send updates back via AllSpfrouter MC address
Again all this can be easliy negated by apllying ospf interface or area authentication?
Please don't forget to rate any posts that have been helpful.
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
I too cannot see DR priority as a security risk, as the real risk would be allowing an "unknown" router join your network.
In theory, if we get on a low performance router, and set its priority to make it the DR, such that it's effectively becomes a DoS attack, we have deeper security concerns such as how did someone get on a router to change its priority and/or cause the current DR to drop to force a DR election. If someone has such unauthorized access, they can do much more than change DR priority.
In my experience, some security folk are the equivalent of script kiddies, they don't really understand the technology and what's really relevant or not from a security perspective. Often they just use some "checklist", which may be incorrect. Often if there's not a deep understanding of the technology, a false sense of security is created.
Just one example, years ago I had "security folk" tell me you cannot have the default administrator account with the name "administrator". I asked why, and the answer was, well that's an account that hackers would want to attack, so we don't want to make it obvious. I said okay, then I wrote a simple program, as a non-admin user, and asked the OS for all the account names with administrator access (which it provided). I told them, personally, I would be more interested in how secure the passwords are on all the administrator accounts, how many failed logon attempts are allowed, unusual account usage activity, etc., rather than the name of one of many administrator accounts, but sure, let's rename it, we'll then be so much more secure.
Same place, "security folk" insisted system require passwords to use both upper and lower case. I said sure, good long term practices, but you do realize older clients don't internally support lowercase passwords, so when they logon, OS translates any lowercase to upper case. I.e., so since a logon program can request old logon handling, you've not really improved the password space.
However, the important thing was, we complied with both the security checklist items.
However, the important thing was, we complied with both the security checklist items
I think that's the key point here. It's often a case of being seen to be complying rather than any actual gain you get from implementing it. That's my main problem with things like security audits. Unless you get a very good company what happens is that their software can find a few important things but they get lost among all the other largely irrelevant stuff.
The good audit companies sort through all this stuff and only highlight what is really is an issue but in my experience that doesn't always happen.
Thanks all, couldn't see if I was missing something.
This was my first main reaction :-) " if they can get access to a router i think changing the OSPF priority is the least of your concerns."
As you all point out, if you're following all the other security guidelines for OSPF the chances of this happening are minimal, the risk it presents is hard to identify, so its pretty much junk to pad the report out.
The weird thing is theres other stuff they missed, even though its quite clearly in the Cisco router hardening guidelines.
The whole report seems pretty hit and miss to me, I hope they didn't pay too much for it :-)
I have this observation to offer about the preemptive aspects of DR election. If someone has the ability to set OSPF priority and sets it to 0 on the current active DR then that router immediately ceases to be DR. So in this case it is preemptive.
Having said that I will agree with my colleagues that I think it is a stretch to identify priority for DR election as a vulnerability. And certainly agree that if someone has the ability to change OSPF priority then they certainly have the ability to change things that have more impact than election of DR.
I too don't see it as a big risk. Rarely do I have more than two routers on a segment running OSPF and in that case I can set the link to point-to-point and get rid of DR and that potential attack vector.
Of course one should implement MD5 authentication of the OSPF packets which means that the attacker would first need to know the digest to be able to attack the IGP.
You could set your priorities to 255 and 254 for DR and BDR which would at least make it more difficult to launch such an attack. The attacker would have to be directly adjacent because of the TTL of OSPF packets which means the attacker needs physical access.
Like the others said there are far more likely attacks than this and easier to perform and with greater damage if sucessful.
Please rate helpful posts.