Sunday, September 4, 2016

A new definition for established traffic

For many years now, the firewall has been the mainstay of network security.  Firewalls make up the core of almost any security regulation, and if not regulated, is a general best practice among security practitioners for segmenting network traffic.  In recent years, Gartner has coined the term "Next Generation Firewall" which essentially stands for firewall capability at the layer 7 level, rather than the traditional layer 4.   

Firewalls generally come in two types, stateful and stateless.  Stateless firewalls are also known as "access control lists".  Keeping no memory, or state, these firewalls can only apply rules to the currently intercepted traffic.  Stateful firewalls, on the other hand, keep track of state and can use this in decision making going forward.  One key feature difference between these two types is the concept of established traffic.  Established traffic is the term applied to data sent that is a "response" to traffic that has already been allowed.  The core idea is that if the originating traffic is allowed, the response should also be allowed.  Let's dive into an example. 

Say a client would like to communicate with a web server.  A general best practice is to allow communication from the internet to the web server (or proxy).  This is required in order for the web server to serve content.  A webserver would be pretty useless if it could not talk back to the client with it's response to the client request.  In stateless firewalls, one would have to allow all traffic originating from that web server which is destined for the internet.  This can be a bad security practice as we, generally, want to control outbound communication.  A stateful firewall, on the other hand, can use the established traffic concept to allow that response through without the need for an allow rule. 

This definition and application of established traffic has worked well for use cases such as web servers.  But what about other traffic?  Specifically, traffic where outbound communication is required, but we still want it to be controlled.  This is where I propose that we need to extend the concept of established traffic. 

Many organizations struggle with implementing a comprehensive set of controls to protect client networks from attack.  Without getting too technical, controls are needed to prevent all stages of the attack lifecycle (recon, delivery&exploitation, installation, command&control). Generally speaking, the  following set is employed in some fashion: 
  • Antivirus on the desktop 
  • Web filtering as a proxy 
  • Blocking of traffic not through a proxy 
  • IDS/IPS on incoming traffic 
  • SSL/TLS Decryption as required 

There are several problems with the above control set.  Even if applied correctly, and ignoring the costs of doing so, this solution is still not complete.  Some of the ones that I can think of are: 
  • Antivirus is great for Windows, but incomplete on other platforms/devices 
  • Proxy cannot always be set up, especially in a BYOD environment. 
  • SSL/TLS decryption is an invasion of privacy and becoming more and more ineffective as sites use certificate pinning 
  • Controls are ineffective when devices leave the corporate network 

So, given the above, what is a company to do?  Outbound communication is required for the business to function, but, in allowing this, open up attack vectors that allow for the delivery, exploitation, installation, and command of client machines.  One solution to this problem that I really like is the idea of DNS firewalling.   

In DNS firewalling, hosts have their DNS pointed at a particular DNS firewall.  The DNS firewall can then intercept DNS requests, enforce policy at that point, and only service IP addresses back that are known good (or at least, thought to be known good).  Here are some pros: 
  • Solution does not require interception of raw traffic 
  • Solution allows for both whitelisting and blacklisting 
  • Standard approaches such as threat intelligence and behavioral monitoring can be employed 
  • Solution extends beyond the corporate network 

Further to the list above, the solution helps with some of the most current domain switching techniques that modern malware is employing.  At this point, you are probably asking, what does this have to do with established traffic? 

I think that the definition of established traffic needs to include communication with a specific IP, if and only if, that IP has been returned as a result of a DNS request made (to an approved DNS server) and if it conforms to an approved port. 

Let's look at a firewall setup for a client network that needs access to the internet.  This client network has been configured to use some type of DNS firewalling service. 
1) Allow DNS traffic to DNS firewall from client network 
2) Block DNS traffic to internet from client network 
3) Allow HTTP/HTTPS/Other to Internet from client network 
4) Deny all traffic 

The addition and requirement of firewall rule 3 is dangerous.  Any IP based communication, on an approved port, will be allowed to the internet, and I cannot guarantee that this request was first processed by my DNS firewall. I need a firewall provision that ensures that communication with an IP is first approved by my DNS firewall, then allowed.  Hence the addition to the idea of established traffic. 

In my research, most DNS firewall capabilities are focused on the DNS request/response.  While they do offer integration with other devices, no firm method has been devised as of yet to govern this type of traffic.  I'm curious what people in the community do to solve for this, and if there are any products that integrate the network and DNS firewalls seamlessly.  All comments are welcome!

No comments:

Post a Comment