System Virtualisation and the Software Defined Data Centre (SDDC) have lead to radical changes in how we design and implement security in our environments.
When designing a new environment, we need to consider the different paths of traffic that will need securing. These will be our North to South traffic: client to server, and East to West Traffic: server to server.
As with every design, it will be driven by the customer’s requirement, however this blog will hopefully provide some food for thought.
The North/South Divide
North to South traffic is generally described as client to server traffic: traffic that is sourced externally to your environment, which needs access to within the environment. Typically this type of traffic has been regarded as WAN to LAN, which would normally be dealt with by a perimeter gateway firewall.
Traditionally North/South traffic represented the majority of traffic in the data center and as such perimeter firewalls were usually large physical firewalls with as much throughput required as possible. This can still be the case for large enterprise deployments, however with more and more multi-tenant networks and cloud environments popping up aiming at non-enterprise customers, it soon becomes impractical to deploy and manage physical firewalls for each customer.
This is where virtual firewalls have gained popularity. Whilst they might not offer throughput rates the larger physical firewalls can offer, the ease of deployment into each customer and scalability for the integrator make them very appealing. Furthermore, each major firewall vendor has a virtualised offering, allowing security admins to keep utilizing platforms they know and trust.
East Meets West
East meets West traffic historically has been thought of as small volumes of traffic between servers within the same network. However, with the popularity of multi-tiered virtualised environments and applications architectures using the scale out approach, server-to-server traffic has been increasing significantly and as such requires greater controls. From this increase in East to West traffic we have seen the development of distributed networks and firewalls.
Where traditionally, traffic directed to firewalls and inter-host traffic on the same logical segment was poorly dealt with or ignored; a distributed firewall can inspect the packets before they even hit the wire, thus securing traffic between servers on the same network segment.
A distributed firewall is an embedded stateful firewall service on the hypervisor kernel. All participating hypervisors collectively become one firewall. Every VM is connected to a hypervisor and therefore directly connected to the distributed firewall. If you understand the concept behind distributed vSwitches, then you will understand distributed firewalls.
Since traffic is no longer directed to a firewall for inspection, we effectively remove a potential bottleneck in the network and reduce the need for a high throughput perimeter “North/South” firewall.
The distributed firewall policy is centrally defined and works using container groups. Each VM can be statigically or dynamically placed into a container group, where security policies are enforced between different container groups, allowing the security policy to be decoupled from IP addressing.
Distributed firewalls perform standard port and protocol inspection along with the ability for VPNs, however for further application awareness, we need to look into Next Generation firewalls.
Next Generation Firewalls
Next Generation firewalls are able to detect and block sophisticated attacks by inspecting the application level as well as the port and protocol level.
For example, is all traffic on TCP port 443 really https or is someone using TCP port 443 to tunnel other traffic such as torrent downloads?
Once again, like the North/South traffic flow, Next Gen firewalling has been around for a while, so how does it fit in with virtual networking? With increased application threats, not only do we need Next Gen firewalling on our North/South traffic, but also on our East/West traffic. Due to this we need a Next Gen firewall that can interface with/work alongside or indeed replace our distributed firewalls.
Currently Gyrocom are reviewing two vendors in this area: Palo Alto and a newcomer to the market vArmour.
Palo Alto have already built up a good reputation with their Next Generation firewalling and have spent a lot of time with VMware integrating this into VMware NSX.
The Palo Alto VM for NSX can be deployed to build on the VMware distributed firewall to provide L4-L7 firewalling. It is also designed to use the same workload containers used in the VMware distributed firewall.
Panorama- the Palo Alto management software- can manage not only these virtual instances, but also physical appliances providing North/South services using the same security policies.
vArmour is a new comer to the market and looks to be geared toward the open stack deployments of SDN. It is labeled as a distributed Next Gen firewall, however it requires enforcement points to be placed throughout the network, so it is unclear whether or not it offers the fully distributed services that the NSX Firewall does. However if, like Palo Alto, it is designed to complement an Openstack kernel firewall, it will provide a good alternative to the Palo Alto firewall.
This blog has covered quite a lot of ground today, so in order to round it off, here is a quick summay:
North to South traffic = Client to Server
East to West traffic = Server to Server
o High throughput, single tenant environments
o Protecting your hypervisor
- Virtual firewalls
o Scalability in Multi tenant environments
o Rapid deployment
- Distributed Virtual firewalls
o Security at the first and last hop
o Scalability and centralised management
o Security that can migrate with the workload
- Next Generation firewalls
o L4-L7 security – Application aware
o Managed centrally alongside the distributed firewall
The Palo Alto & vArmour Next Gen Firewalls are just about to undergo testing in Gyrocom’s multi hypervisor Openstack with NSX lab. Stay tuned for a results Blog!
That’s it from me for now, but pop back soon for my next installment, which will cover Security Event and Incident Management for your SDN deployment.