Few people have a full understanding of the how to appropriately design secure network connectivity at the enterprise internet edge (including me). The root of the problem is that not one person knows everything. Security guys often do not fully understand the art of packet herding and that packet herders don’t really understand the complexities of application security vulnerabilities. My background is in network engineering and systems administration but I took over the network security SME position at my enterprise going on two years ago.
I figured I would do a quick blog to identify a few key design components I have learned and figured out along the way that feel are critical to building a secure infrastructure. This will basically be a quick rundown of suggestions layer by layer as we move from the edge into the interior of the network with some links you may find useful for further research. Please note that this is specifically discussing secure web / e-commerce design.
The first key component is the design framework. A few key security principals come into play here, first and foremost is the notion of defense in depth. In addition it is highly suggested to use a dual-nic trusted/un-trusted network model as a complement to a layered defense in depth approach. The whitepaper below from the SANS institute has some good information on the subject. It is generally agreed that the dual-nic network model is far more secure than a typical DMZ model but it obviously requires some advanced planning.
I think it would be good to provide a brief description of the model which starts with a DMZ environment in which we will call the un-trusted side since it represents an area of low trust. Front end servers have a NIC in this DMZ environment and they received requests from the outside world on this NIC. Additionally, servers are configured with a second NIC connected to an inside network DMZ called the trusted network configured with an internal, RFC 1918 address. It is generally advisable to provide firewall services for this network as well but it is an area of higher trust. Front end servers then make any back-end requests on these NICs. To be optimally efficient, front end servers should only receive requests on the un-trusted NIC and only make request on the trusted NIC.
An additional layer can be added by placing a load balancer in front of the front end servers. Load balancers actually terminate the TCP sessions originated from hosts on the internet. They then turn around, acting as a proxy, and re-initiation another session to the appropriate VIP pool members. This provides several benefits, namely scale-ability, efficiency, flexibility and security. Several of the load balancer vendors provide additional application layer security features, namely F5. You can go a little crazy with it but they provide several additional features that can be used to augment your security model like web scraping protection, in F5 this is provided in the Application Security Manager (ASM). You can read more about these features in the whitepaper below.
As far as the devices themselves we will start at the edge with the edge routers. Device hardening using best practice suggestions from the hardware vendor is a critical first step but be cautious and remember that these are suggestions and one size may not fit all. Be sure to understand exactly what each configuration item will and will not accomplish and do your due diligence to research third party suggestions. The next area for edge routers is basic IP filtering.
One key point to remember is that the firewalls are not the end all be all of network security, rather they are simply the front line. Firewalls are great for filtering out traffic and reducing your footprint of exposure. This is true of any edge router filtering you choose to employ as well. It is generally accepted as best practice to filter RFC 1918 and 3330 addresses. There are also some great RFCs which outline best practice guidelines for ingress filtering, RFC 2827 and the updated RFC 3704 which covers multi-homed networks.
The key point to keep in mind is that your edge router can provide some basic spoofing protection by straight blocking large chucks of IP space that should never be used as source addresses on the internet. Depending on the capacity of your router hardware you can add some additional filtering capabilities but I would limit filtering to very large, known blacklisted IP blocks. RFC 5782 defines DNS blacklist services best practice. Note: use extreme caution if you choose to implementing these solution.
Protecting your edge routers against BGP attacks is another key area of concern. Rather than documenting at length in this blog I decided to link a nice Cisco whitepaper I have used in the past. It is getting a little dated but it has some great best practice suggestions as well as several valuable links. RFC 4272 also contains several best practice guidelines.
Edge Firewall and get rid of NAT
As we move down the list we move to the edge firewall. Again start with your hardware manufacturer edge firewall hardening guides. It is advisable to do some research for additional third party recommendations. The next big item of debate is to NAT or not to NAT. The answer is simple DON’T NAT, its a useless relic of the past that in no way equates to security. I much prefer simply routing the public IPs through the edge firewall and straight to a load balancer. Just remember stateful packet inspection and ACLs provide security NAT does nothing other than break end-to-end security mechanisms.
Front End / Back End environment separation
In addition to using dual NICs it is generally a good idea to build two separate environments on two different firewall pairs and/or clusters, a front-end environment and a back-end environment. Depending on the size and complexity of our environment you may be able to get by with a HA firewall pair for front end and a separate HA firewall pair for back end. The back end environment, as the name suggests, is where you will place database and any other sensitive file servers.
So, in summary, inbound web requests should look like this:
End host sources secure SSL session => (Internet Cloud) => Edge Routers => Edge Firewall un-trusted DMZ => (optional) Load Balancer => Un-trusted web server NIC =/= Trusted web server NIC initiates a database fetch to the back end server => Edge firewall trusted DMZ (RFC 1918) => Data center network core => Back-End firewall => High security database DMZ server
Outbound Internet Access
It is highly suggested for enterprises to use a web proxy solution to provide internet access for internal clients. However, some major North American companies are still using a default route to the internet and allowing internal clients to directly communicate with the outside world. There are some that will debate that using a default route and filtering traffic with a web content filter of sorts is an effective solution but in my experience this is not the case. I look at it this way; by default, web content filters allow all traffic and try to restrict bad traffic. On the other hand proxy servers by default do not allow any traffic, rather you have to specify which traffic you will permit. The simple act of allowing internal clients to talk directly to the outside world is a dangerous practice. For example an infected client machine to ‘call home’ using encrypted packets that a content filters and firewalls are helpless to prevent.
Most any proxy servers will provide web filtering mechanisms, internet access policy enforcement and most provide some flavor of data loss prevention, SSL offloading, activity logging and audit capabilities. In the reverse fashion from the inbound connectivity module, proxy servers should receive request on trusted interfaces and only make requests on un-trusted interfaces.
I have uploaded a visual reference enterprise edge modular edge architecture diagram:
Good podcast discussing internet facing application security with border routers, firewalls and ids/ips:
If you are running a predominately Cisco environment the Cisco SAFE blueprint is a good source for some baseline design components: