Implementing Lightweight East-West Firewalls with F5
In 2005, perpetual diva Miss Piggy portrayed all four of the directional witches (North, South, East and West) in Jim Henson’s Muppet’s Wizard of Oz. Despite a vigorous and, occasionally violent, performance, she was snubbed at the Academy Awards, ultimately losing out to Reese Witherspoon (Walk the Line). Maybe the Academy Awards voters understood this key principle that escaped our porcine starlet:
East and West are fundamentally different from North and South.
This is certainly true for the modern enterprise datacenter architecture.
When you look at an architectural diagram of a single datacenter, the Internet is at the top (North) and users at the bottom (South). In between are the DMZ and services. These services are applications, virtualized servers and databases and they communicate with each other laterally (often portrayed west to east).
N-S networking is considered the traditional perimeter and the conventional home of giant firewalls. E-W is the home of virtualized services, and sometimes N-S security teams don’t get invited to play in the sandboxes. So E-W traffic can be left unguarded. But it shouldn’t be that way; network policy can be implemented quickly with the F5 load-balancers already in place.
Let’s take a look at an example E-W layout.
Security in an East-West Network Security
Traffic is flowing from the web servers east-ward through a middleware cluster and ultimately to the database cluster at the east end. All good.
There should never be traffic going from the web servers to the development network, right? Web servers are a huge threat surface: when they get hacked we don’t want the attackers to be able to get into the intellectual property in development.
The same goes for the middleware network, it should only talk to the database cluster network. And connections from the database cluster should never go into the development network either. Let’s redraw the diagram with the red lines to indicate connections that we want to prevent.
So how can we implement this in a way that doesn’t disrupt everything or require new hardware?
Lightweight Firewall Rule for Web Apps Cluster via F5
In the example above, there is an F5 application delivery controller (ADC) in between the web applications and middleware and another in front of the database cluster. Suppose the ADCs are providing simple load balancing for the application traffic running west to east.
The web servers are the most interesting section of the architecture. They accept traffic from the Internet (via the ADC) and are typically configured to use the ADC as their default gateway. About the default gateway: historically, the ADC has always passed the original client IP address to the web server for logging purposes. The web server then has to use the ADC as the default gateway when it replies back the client (otherwise the traffic would go around the ADC, and that doesn’t work for proxy and cache services).
On the F5 we’ll create three VLANs and virtual server objects to represent the three types of flows that we’re looking for.
- web-app1 : inbound traffic to web application.
- middleware : eastbound requests into middleware
- web-gw : default gateway traffic (mostly traffic from web-pool)
The web-app1 virtual server defines a single public address for inbound web traffic to our application.
net vlan internet { }
ltm virtual web-app1 {
description "internet to web app"
destination 71.237.39.99:http
pool web-pool
profiles { http { } tcp { } }
vlans { internet }
}Because the web servers are accepting routable IP addresses (see sidebar), they have their default gateways set to a wildcard virtual server at the F5. The return traffic will be matched to the incoming flows.
|
Web Servers: 192.168.2.0/24 Middleware: 10. 0.0.0/8 Development: 20.0.0.0/8 Database Cluster:172.16.0.0/16 |
Notice the destination 0.0.0.0:any. This is necessary to allow the webservers to communicate to the outside world. But suppose that an attacker got a shell on the web-server. He could then use the wildcard server to tunnel through to the development network (20.0.0.0). Not what we want. So we define a lightweight firewall rule (fw-enforced-policy web-gw) to prevent packets from getting into the development network.
security firewall policy web-gw {
rules {
w-to-m {
action reject
description "Disallow development"
log yes
destination {
addresses { 20.0.0.0/8 { } }
}
}
}
}Here’s what that rule looks like in the GUI.
We’re not specifying the source network because this is only enabled on the “web” VLAN anyway (and therefore wouldn’t be acting on other traffic).
Lightweight Firewall Rule for Middleware Cluster via F5
The middleware virtual server defines a single address for the web servers to communicate to a pool of middleware servers.
ltm virtual middleware {
description "webapp to middleware"
source 192.168.2.0/24
destination 192.168.2.202:7001
pool mid-pool
profiles { tcp { } }
vlans { web }
}The middleware virtual server has a source network specification which will act as a firewall rule all by itself. Only traffic originating from the web network will be able to pass through to the middleware cluster. It doesn’t get much more lightweight than this.
If we want to prevent connections originating from the middleware tier cluster westward to the web app cluster, we can define a global firewall rule to handle this. Note that we leave a “hole” for development to push to the web app cluster.
Lightweight Firewall Rule for Database Cluster via F5
The right-hand F5 ADC will very similar to the left-hand ADC. For our simple example, we have a virtual server balancing to a single pool of database servers and they should only be accessed from the middleware.
Just as we did for the web app cluster, we can use the source and destination attributes of the virtual server to create an east-bound flow.
ltm virtual mid-to-db {
description "middleware to database"
source 10.0.0.0/8
destination 10.10.10.10:3306
pool db-pool
profiles { tcp { } }
vlans { middleware }
}We’ll also add a global firewall rule to prevent connections originating from the database cluster back toward the middleware or development. Add one exception: every Saturday night from 8PM to midnight the database clusters will be allowed to access the Internet to pull down updates.
Is that Lightweight enough for you Miss Piggy? “Hiiii-yaaah!”
See how easy and lightweight that was? Much of the security enforcement is already bound into the definitions of the virtual server objects themselves, leaving us with just handful of global firewall rules.
Full disclosure here: I simplified this configuration a little bit for clarity. The full configuration is larger and you’d probably have a SNAT pool in between the clusters where default gateways are used. But hopefully you get the gist that it is possible, with relatively little effort, to attach lightweight firewall rules to manage the east-west traffic in your datacenter.
