SDN Switches Not Hard To Compromise, Researcher Says 105
alphadogg writes: Software-defined switches hold a lot of promise for network operators, but new research due to be presented at Black Hat will show that security measures haven't quite caught up yet. Gregory Pickett, founder of the Chicago-based security firm Hellfire Security, has developed several attacks against network switches that use Onie, the Linux-based Open Network Install Environment that competes with OpenDaylight. Being able to exploit the vulnerability to put malware on SDN switches would have full visibility into all of the traffic running through the switch, enabling large-scale spying.
Not Supprising (Score:1)
I recall thinking "Oh, no" when I saw the first HP presentation on the subject...
Re:Not Supprising (Score:5, Insightful)
So long as "features" count for more than security, this will continue.
Re: (Score:2, Interesting)
So long as "features" count for more than security, this will continue.
So long as people waste their time and resources guarding wires rather than systems this will continue. Most of the need for SDN in the first place originates with fools continuing to pursuit castle defense during the space age.
--
"Finally, we will access, disclose and preserve personal data, including your content (such as the content of your emails, other private communications or files in private folders), when we have a good faith belief that doing so is necessary."
Yep (Score:3)
I recall thinking "Oh, no" when I saw the first HP presentation on the subject...
Yep.
If you can software define the entire switch (or other network device), you can software design an invisible-to-the-rest-of-it tap component for it. B-b
Re: (Score:2, Insightful)
You can do this as well for current 'hardware defined' network components. All switch fabric ICs that I know of can transfer packet data to the host cpu, this is normally used to implement the high end L3 features (and of course to allow access to the management CLI/GUI). If you can update the host CPU firmware with a tap component it will be as invisible as this SDN hack. I even know of one ASIC where you could in theory make it capture all data, put ETH/IP/UDP header before it and then send it out. The ho
Re: (Score:1)
Why did you downvote the guy? This is his first post that makes sense
because he's a known spammer and generally a douche. in his own eyes he is always right and anybody who disagrees with him has some sort of personal grudge or jealousy against him. that's the way he is - no dissent is ever legitimate. everything is somehow personal, even things like system configuration and web browsers. you can't argue with people like him, and if you sincerely try, he just convinces himself he's being "persecuted" and pats himself on the back for his unquestioning dedication.
if you've
Re: (Score:2)
Re: (Score:2)
SDN is not a smart idea at this time... (Score:4, Insightful)
If and when the human race learns to code software that is very hard or impossible to compromise, SDN may have a place, but before that, it is an exceptionally bad idea. It is also not a new bad idea, but an old one that has been renamed. For example, "Active Networking" did try this thing before.
Re: (Score:3)
Who let the insane one in here again?
Re: (Score:2)
after you gave apk crap on his program
Talking about yourself in the third person makes many a psychiatric warning light go off...
Re: (Score:2)
Re: (Score:1)
He seems to be under the delusion that he has "challenged" me, when I could not care less about him or his "views". Some kind of megalomania, I think. That he posts as AC probably shows that he is at Karma-minimum because most people immediately notice the insanity dripping from his posts.
Re: (Score:2)
Re: (Score:2)
If and when the human race learns to code software that is very hard or impossible to compromise, SDN may have a place, but before that, it is an exceptionally bad idea. It is also not a new bad idea, but an old one that has been renamed. For example, "Active Networking" did try this thing before.
No system or network is perfectly secure and a SDN can be protected just like any other sensitive and imperfect infra can be protected.
Re: (Score:2)
No, it cannot. It does require a complete lack of understanding how networks can and cannot be protected to make such a claim however.
Is that so?
Since you are confident enough to make such a statement, I invite you to explain why it is not possible.
Re: (Score:2)
Incidentally, lack of any detailed and coherent response from you will only confirm that you are just another overly arrogant and obnoxious person on this website whose mouth spits out comments that they make out of ignorance and cannot actually back up with anything substantial.
Re: (Score:1)
Nice, self-serving BS. There is absolutely no point in explaining anything to you as you are convinced you already have the absolute truth, while you clearly do not even understand the basics. I encourage you to look up the Dunning-Kruger effect though, and try to understand what it means to be on the left side of the graph.
Re: (Score:2)
Nice, self-serving BS. There is absolutely no point in explaining anything to you as you are convinced you already have the absolute truth, while you clearly do not even understand the basics. I encourage you to look up the Dunning-Kruger effect though, and try to understand what it means to be on the left side of the graph.
I am not convinced that I know the absolute truth (should such a thing even exist). Hell I could even be wrong and I'd love to learn from whatever you could teach me. I invited you to explain your point to me.
As I suspected from reading your other posts, you were unable to actually put forth anything to substantiate your casually obnoxious statement.
Maybe you're right and I have a complete lack of understanding here.
Maybe,
Personally I think you opened your mouth and said something that you are incompetent
Re: (Score:2)
Re: (Score:2)
You do understand that all networks are running software today right? More importantly big networks are incredibly hard to upgrade in a timely fashion; primarily due to the problem that in most cases you have to take part of the network offline. Even in fully redundant networks the politics slow the whole upgrade process down. I look forward to the time when we can run a cluster of controllers and upgrade them in service.
Onie =! OpenDayLigth (Score:2, Interesting)
As far as I'm concerned, OpenDayLight is not a bare-metal OS installed on the network assets running the Data Plane... ODL is an SDN controller running on the Management Plane. "SDN Ready" switches in general are just regular switches compatible with OpenFlow... the article doesn't make much sense. Let see...
Security updates (Score:2)
Given the amount of security updates we had on Linux servers those days, it is not surprising a lot of vulnerabilities exists in embedded Linux systems.
It would require a lot of work from distribution maintainers and system administrators to keep that stuff ahead of the vulnerability curve?
This is what happens when you move the control... (Score:5, Insightful)
... plane outside the confines of the device and make it communicate over a common (not hardened and not separate) channel/network.
The trick is only permiting access... (Score:3)
... to the control interface from a specific port. And then you plug that port into one of your servers that is deep in your security bubble by default... and then you VNC or RDP into that when you want to access the SDN.
Its when you allow access through any port that things become stupid.
Re: (Score:2)
And then you leave the root keys, and the details on how to access and configure the server, on a trivially accessable wiki, especially with root keys stored unencrypted by developers and admins by policy "because we trust the people we work with" and "because we have a firewall".
Re: (Score:3)
No... The only people that can touch the server are people that are hand picked and trusted. Can they do bad things? Sure. You have to trust someone. But a senior admin betraying you is not the same thing as a shithead hacker walking into your operation and writing "I WAS HERE" with his urine.
The trick is to backstop exposed systems to the security of secured systems. Where in the security is not actually breached unless the secure systems are breached. And then you make breaching those a matter of certain
Re: (Score:2)
> No... The only people that can touch the server are people that are hand picked and trusted.
You seem to be _extremely_ optimistic about most security enviromments. I don't deny that your guidelines are sensible and appropriate, or that they are rigorous and thoughtful. But they're violated, in practice and in policy even in most so-called "secure" environments. As most networks grow and mature, there are extremely frequent holes drilled and policies violated for the ease and convenience of the administ
Re: (Score:2)
Depends on the implementation, no?
Many of them are encrypted, proprietary, and sufficiently uncommon that there isn't an off the shelf hack for it.
That said, I take your point. I'm just trying to point out that you can shield one thing with another. Ideally for the deep deep stuff you need to walk up and touch it to get access. But most people aren't willing to deal with that.
What exactly is a SDN, anyway? (Score:3)
It kind of seems cloud-ish in its specifics.
Is it a generic switching backplane that allows arbitrary software loads and more elaborate centralized configuration, perhaps enabling more exotic topologies?
How far are we away from this now? Most switches anymore seem like specialist PCs with a zillion NICs that boot some variant of linux or bsd and allow for pretty exotic topologies as it is, limited only by the interconnect hardware they have.
Or is it something tied to virtualization where its meant to describe networks that only exist in hypervisor clusters?
Re: (Score:1)
You know how something like a Cisco 6k L2/L3 switch/router can route and switch, and when it routes the first packet in a flow it can then store the decision out on the blades so that subsequent packets simply get switched, and that routing decision is done using routing logic on a generalized processor in the supervisor module while the switching is done by ASICs? Now imagine that the same thing happens but where the control-plane decision happens using some off-board service that controls all the switche
Re: (Score:1)
As I understood it, just a few months ago, only a few SDNs actually were switching on the ASICS, and they were not the freebies.
Have things changed, and is it now possible to use the ASICs from most SDN projects ?
Re: (Score:1)
Depends what you want to do. Most current not extremely-high-end switch fabric ASICs can do approximately what an expensive L2/L3 managed switch can do. This gets you there for 99.9% of traffic. Some exotic configuration can probably not be handled by the ASIC, but these few packets then go through the CPU. As long as you are switching streams (eg, wait for trigger packet, update asic config) the performance loss is minimal. If you are doing heavy per packet things then they all have to go through the CPU.
Re: (Score:2)
And that's just the switches. Have a look at a really advanced network device, like the F5 Big-IP load balancer. That loads Linux plus a proprietary real time OS called TMOS, is a full proxy for most common traffic types like TCP, and as a full proxy it can intercept an
ah yes - the new Corporate Buzzword (Score:2)
word came down a few months ago from on high - we need to learn how to do SDN and become experts at it - we have none of it in our environment and no one knows how to support it or what our use for it would be - and we're the network guys but Cisco must be trying to sell us something
or Somewhere...someone...got their hands on a Network Week magazine - one of our dumbass Level 1 phone dorks musta left it in the john.
Software-defined switches .. (Score:2)
Re: (Score:2)
I don't get it either. I can understand wanting to dynamically open firewall ports here and there (which is also dangerous, and another subject), but I don't get why you'd need to mess with vlans and such like dynamically. When I worked on massive scale, the architects talked about "data centre holes" where you had space available but couldn't use it because of limitations in the network. I assume SDNs solve that problem, but then so does HAProxy instead of using hardware load balancers.
Either way, I could
Re: (Score:2)
There are actually uses. a robust virtualization server can support an SDN to set up a completely internal testing network. This can be far faster, and far cheaper, than bringing in new switches and new cabling and new configuration environments.
Re: (Score:2)
You can do this now with VMware, create a vSwitch with no NICs attached and connect machines that can only talk to each other. I think distributed vSwitches can carry this further and extend these across nodes, although as a more expensive licensed feature people usually map these internal test networks to an isolated VLAN so they can span nodes.
virtualization (Score:2)
Cloud computing tied to networking leads to the need to reconfigure the network very flexibly and potentially frequently. This is where SDN comes in.
Suppose you have a big beefy virtualization host. You run a bunch of VMs on it, some of which might themselves be acting as full-fledged routers pushing gigabits/sec of packets. (Yes, this is possible right now.) You want to have strict control over which VMs can talk to which other VMs, you want to control which virtual networks can connect to which physica
Re: (Score:2)