More OpenFlow goodness?

Trying to keep up with OpenFlow developments while that is not my "dayjob" at the same time as doing multiple other non-work things (raising a family, trying to stay healthy, studying additional technologies, ...) is not easy, so forgive me for potential blunders...

With that off my chest, I came across another interesting side benefit from using OpenFlow in the context of access-layer security: minimizing inadvertent disclosure of sensitive configuration information.

Yes, we can use things like load configurations from TFTP or other places, but being able to rely on dynamic configuration of the forwarding plane makes that process even easier. As a side note, more and more I think of OpenFlow in a similar way to controller-based wireless deployments, but without that mandatory tunnelling back to the controller. :-)

From F5's DevCentral blog entry at http://devcentral.f5.com/weblogs/macvittie/archive/2011/12/07/your-network-architecture-now-on-e-bay-for-9.95.aspx
"Imagine that instead of routing and processing decisions being triggered by traffic arriving on a port that some piece of data inside the traffic triggered the execution of the proper policy, including where the next “hop” in the network should be. Essentially, dynamically building the path through the network based on the content rather than on static, preconfigured paths."


Sounds familiar, doesn't it? :-)

To me, there's two ways of looking at this:

• OpenFlow as an alternative to F5's vision of 'content-driven network security configuration'
• OpenFlow as a complement to that vision

Now, F5 obviously wants to be able to provide the inspection of traffic to generate that proper policy, but perhaps it should consider a more harmonious integration with OpenFlow instead...

Not enough hours in the day to keep up with all this...

Pushing the OpenFlow discussion forward.

Just listened to - and loved! - the recent Packet Pushers discussion on OpenFlow. Ethan and Greg with guests Ivan and Derrick put together a great episode with very interesting insights that made time fly for me as I listened.

I think some considerations made on the show deserve some comments:

• Architecturally, Ivan made a point of how we should have a stable IP core and a more 'flexible' access/edge layer, which is where the OpenFlow goodness comes in. YES! That makes perfect sense: the challenges we're looking at adresssing - multi-tenancy, virtualized topologies, compliance compartmentalization, ... - are much more focused on access layers. Of course there is a need to define how the core addresses these topics, but solving them at the access layer is paramount.
• Greg espouses a long-term view of OpenFlow that I think is also correct. The notion of redoing a whole new network now to accommodate OpenFlow is not practical, but the effect of OF on network design is likely to be felt in a few years.
• There was some discussion on whether some features (LLDP/CDP, LACP, ...) will have to be implemented locally and how that might contrary to the unstated goal of commoditizing the access switches. Frankly, I don't think this is an issue. Just like 'commodity switches' have had to slowly incorporate functionality (think VLANs, QOS, POE, ... which can now all be had on consumer-level gear) I think these 'essential' functions will also find their way into the more commoditized product lines over time.
• The scaling limitations are ever present. That being said, I am wondering if the current limitations (as described in the show) of 600-1000 new flows/sec shouldn't be looked at as new flow setups, but as EXCEPTIONs to pre-existing flow setups. Think about this scenario
• a) OpenFlow controller is 'aware' and instantiates expected flows from each access switch port as part of maintenance window: "IP traffic from source A coming on port X going to destination B is allowed and goes out port y" and so on.
• b) Then, only when *exceptions* to that occur ('bad hacker takes over source A and attacks server C instead') does the controller need to get involved - and can then do all the kungfu-magic of redirecting traffic to a network forensics device or something...

So yes, there are scaling limitations, but the power of pre-programming flows might be tapped to alleviate a lot of that. If this is correct, then the issues to consider are really how many flow rules can a switch realistically host in its policy rule table, how many flows can a switch host overall (not unlinke a firewall) and what happens in the failure scenarios of overloading policies and/or concurrent flows. Again, just like a firewall...

Finally, in my opinion, the current thinking on the applicability of OpenFlow to enterprise networks - specifically as it relates to the functions of the OpenFlow controller - can be summarized as:

Guess where the OpenFlow controller sits...

(As a side note, I remember a cartoon with the same message from many years ago but with a flowchart instead, but couldn't find it online. If anyone can point me to it, greatly appreciated!)

Great, great show guys! Thanks!

[Open] the gates and Security [Flow]s in ...

The momentum behind OpenFlow is significant, with major vendors announcing real products, a number of startups working on innovation and lots of interested organizations - basically every cloud or service provider, along with titans such as Google, Facebook and Yahoo - collaborating on how to bring this technology forward. Two key events just in the past month included the OpenNetSummit at Stanford and the PacketPushers/TechFieldDay OpenFlow Symposium just this week.

Ethan Banks (@ecbanks) provided a great summary of the Symposium here  and Chris Hoff (@beaker) expanded on the security aspects of this on his post today . My take on it is to explore the ramifications for security architecture a bit more, specifically within the context of enterprise security, primarily as it relates to access-layers.

Before delving into that, security *for* OpenFlow itself seems pretty straightforward: the switches talk to the controllers over a secure SSL channel and believe what the controller tells them. This means that if the controller is compromised, or if the switches can be misled to talk to a different controller, game over.

This highlights a key point: OpenFlow itself is just a protocol. As Ethan mentioned, the "Openflow magic" happens on the controller side "when we see vendors writing clever applications". There are several vendors working on OpenFlow controllers right now, from NEC to Nicira to Big Switch and others.

So, what can OpenFlow (and the broader topic of "Software-Defined Networking") bring to network security architecture?

• "Firewall" at the true edge. By implementing functionality that can dynamically instruct switches to pass, modify and drop packets, OpenFlow in essence, creates true "edge" firewalls with the benefit of centralized control and probably kills off NAC to boot. All that we tried to do with NAC and 802.1x - tying wired access to identity, responding to changes in endpoint security posture, ... - becomes viable with an Openflow-enabled switch. 
• As a side benefit, we get to implement the recommendation that packet filtering be done as close to the source as possible. 
• "Transparent" network changes. One of the more painful aspects for client-side user experience with NAC was having to switch VLANs after authenticating. Several applications - such as Windows RDP - would not handle that gracefully. An OpenFlow-enabled environment can just enforce rules itself (see above) or change VLAN parameters transparently. To make a long story short, the notion of making changes to flows *TRANSPARENTLY* means that security can 'blend in' that much better. 
• As a special case of these transparent changes, directing traffic to specialized security devices (WAFs, forensics, DLP, ...) can be made more elegantly and with more granularity.

• Realize the potential of IF-MAP. As vendors moved to implement IF-MAP to provide a framework for security orchestration, adoption has not been as wide as expected. Having an OpenFlow controller being able to subscribe to MAP events and alter the network based on that enhances the value of the technology as well, IMHO.
• We can now envision an architecture where higher-level security applications - maybe DLP, maybe WAF, maybe a client-side host-security suite - leverage IF-MAP to publish security events and can rely on a controller to boot sytems off the network or direct them to collection areas.

Well, this is all fine and dandy. What are some of the limitations?

• OpenFlow is still new, both in terms of protocol and ecosystem evolution. There will be lots of new things to discover, vendors to spring up and consolidate, etc... before we get into the... ahem... flow of things. 
• OpenFlow's centralized architecture will certainly have scalability and latency implications: the flow of traffic from the switch forwarding plane to the switch CPU to the OpenFlow controller will introduce delays making it impractical for environments such as low-latency trading, high-performance computing and the like. Also, as Ethan mentioned in his post, the notion of managing individual flows (also referrred to as microflows) will introduce challenges to controller scalability.
• Well, for all the power that OpenFlow offers, it can still only visualize flows in the context of L2-L4 attributes: what port is connected, what the IP address is, what protocol, etc... In the meantime, it comes as no surprise to anyone that the threat profile has long since changed to the application layers, exploiting Adobe PDF, Flash, SQL Injections, Cross-Site Scriptings, ... To me, what this will mean is that these higher-layer security controls - be they Web Application Firewalls (WAFs), Data Loss Prevention (DLP), Network Forensics, Host Security Agents ... - still need to intercept and inspect traffic. 

So, don't ditch your load balancers, WAFs, IPS, ... just yet. Quite the contrary: if the future is such that simple access control will be 'solved' with OF, these other control points will become more critical.

This is a truly exciting time to be in networking/security. Ultimately I think @beaker is right that security will be a killer app for OpenFlow, at least in the enterprise realm. Follow PacketPushers (packetpushers.net) and others for more discussion on new developments...

By all means let me know your thoughts or if I made any egregious mistakes above. This is new to me too...

To quote Brian Tracy - “Move out of your comfort zone. You can only grow if you are willing to feel awkward and uncomfortable when you try something new.”

Reducing SSH Brute Force attacks in Vyatta

Here's my first real post on this blog...

One of the most annoying things of having an Internet gateway that accepts inbound SSH is the constant barrage of SSH brute force attacks, trying stupid username/passwords and filling up log files and just generally being a nuisance. No, I don't use "root/toor" or other credentials...

I recently moved our home gateway from an ASA5505 to a Vyatta box (will write about it in more detail later) but one of the most rewarding things I found is that it is quite easy to block traffic in Vyatta's firewall code (basically a front-end to iptables) based on recent traffic. To make a long story short, just use rules similar to these ones as part of your "local" firewall policy to severely limit what these SSH brute force bots can do...

 rule 5 { 
     action accept 
     description "Accept Established" 
     state { 
         established enable 
         related enable 
     } 
 } 
 rule 9 { 
     action drop 
     description "Limit inbound SSH connections" 
     destination { 
         port ssh 
     } 
     protocol tcp 
     recent { 
         count 3
         time 30 
     } 
     state { 
         new enable 
     } 
 } 
 rule 10 { 
     action accept 
     description "Accept inbound SSH" 
     destination { 
         port ssh 
     } 
     protocol tcp 
     state { 
         new enable 
     } 
 } 


How to interpret these rules?

• Rule 5 is a typical "allow established" rule for general TCP traffic.
• Rule 9 will drop inbound SSH packets (with TCP SYN flag set) if it sees more than 3 within a 30 second interval.
• Rule 10 will allow inbound SSH packets with TCP SYN flags.

This means that any brute force script will either have to slow down to a crawl or will just annoy you for a couple of entries. All in all, a significant reduction.


Hope this helps...