SDN Switches Not Hard To Compromise, Researcher Says
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.
I recall thinking "Oh, no" when I saw the first HP presentation on the subject...
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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...
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?
... plane outside the confines of the device and make it communicate over a common (not hardened and not separate) channel/network.
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
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
... 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.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
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?
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 ever met a religious fanatic, it's not exactly the same thing but it's similar. apk wants to prove to everyone how clever and correct he is, how much smarter he is than anyone who disagrees with him in the slightest. when that doesn't work it's like some kind of bitter defeat, a societal failure to recognize how special he is and how flawless his solutions are. he's known to throw temper tantrums in the form of personal attacks and massive spamming sprees. his hostfile program is his favorite thing to spam us with, sometimes dozens of posts in a single discussion, each one several pages long. he must have a lot of proxies to get around the posting limits as easily as he does.
in short he's a nuisance and a pest, the kind of person who resists learning and, in all likelihood, has nothing better to do.
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.
----------
ah honey, we're all resplendent - Bill Mallonee
Software-defined switches .. a solution in search of a problem .. discuss ...
Because even when the thought makes sense, the presentation is worse than the work of a brain-damaged third-grader?
Ezekiel 23:20
I have absolutely no idea what "ab+" is, nor do I care, nor do I understand how it could possibly fix your incomprehensible and borderline psychotic diction if it hasn't done so yet.
Ezekiel 23:20
Third person again...
Ezekiel 23:20
I haven't written that comment, despite being in agreement with it. But I guess that this public statement is kind of redundant, because 1) you will never get it into your thick skull and 2) everyone else already understood that anyway.
Ezekiel 23:20
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 physical networks (or possibly which vlans/vxlans on which physical networks). Now combine this with SR-IOV or PCI passthrough where a given physical ethernet device can be logically switched between different customers depending on which VM it's attached to at any given time.