A Firewall is Not a Catch All

Posted: October 3, 2011 in Random pontifications
Tags: , , , , , , ,

After discussing many times on Ubuntu Forums different types of security methodologies in Linux and Ubuntu I’ve come to a realization. Many users are not really sure how a firewall works, how it’s defeated, and how NAT routing figures into any of it. Nothing wrong with that, I mean most users just want it to work, they don’t really care how. That’s totally understandable.

That being said, some have expressed a desire to have a deeper understanding of firewall methodology in Ubuntu, how it can protect you and how it can be defeated by potential attackers. I’m going to explain the upsides, downsides , and differences in how firewalls behave and help you secure your machine. The most important thing that needs to be taken from this is that a Firewall is not a catch all. It’s not going to prevent everything. It’s better to look at a firewall as a filter that allows and rejects certain traffic based on where it wants to go and how it wants to get there.

A few things to clarify before we start though. There are different types of firewalls, and I will briefly explain what they are and how they work.

    • Stateless Firewall : These firewalls block traffic solely on their source and destination. Not too many of these are still running around, although on older unmaintained corporate networks they are often seen. They are also often used in web hosting as running a more advanced firewall takes more resources, thus lowers the bottom line profit margin.
    • Stateful Firewall : These by far are the most common type in the desktop user space, and also very common in the enterprise world. They validate traffic based on the same things that stateless firewalls do , with one exception. A stateful firewall is also going to check that a proper 3 way TCP hand shake is occuring. If another packet that is considered anomalous is introduced first instead of TCP SYN, the traffic will be dropped as illegitimate. This is useful against certain types of denial of service attacks, and exploits that otherwise require a malformed packet being sent.
    • Deep Packet Inspection Firewalls : These are much more complex , more expensive and much more rare. These types of firewalls examine the packet’s contents as opposed to the packet’s header to try to determine if the packet is malicious in nature and based on signatures or heuristics blocking the traffic or allowing it. These can be likened to Intrusion Prevention Systems.
    • *NAT Firewall : This is sort of a misnomer, a network address translation router in and of itself is not a firewall. Many contain a stateful firewall, some even contain a deep packet firewall. However the reason these are generally accepted as a type of firewall is they delimit the traffic that can reach the internal network they “protect”. In some cases, if ports are not forwarded, and or data management zones are not set up, internal machines will not be accessible to incoming connections from the outside world. Keep this in mind as we get further into this explanation, as some of the myths behind the NAT router will be debunked here.

For this article we are going to do a demonstration (I love demos ;-)). We will be using an Ubuntu 8.04 LTS Server installation running a variety of services. Additionally we will use varying levels of iptables rules to illustrate the impact they have on certain attack methods. It is important to note, this is not designed to show off awesome 0 day exploits ; these are all old vulnerabilities (though still very commonly exploited). What we are looking at is the various methods an attacker has to gain control of a machine after its exploit. We will be focusing on the use and implementation of two common types of shell code. Shell code is the code injected after a successful exploit to give the attacker a shell on the machine, and thus control it. The two types of shell code we will be looking at are bind shells and reverse shells.

      • Bind Shells : Work just like starting a service like SSH or Apache, they bind to a port and listen for an incoming connection.
      • Reverse Shells : Work the opposite of a bind shell. The attacker starts a service on their system and gives the exploited system instructions to connect back to them.

We will be testing these shells against 3 common configurations. The first is without a firewall at all, this is rather common to see in some high performance production machines, as they rely on their administrator’s ability to secure the running services, over the need for a firewall. The second is with a restrictive inbound policy but no real outbound policy, this is similar to a NAT router with ports forwarded. The third and final configuration is a restrictive inbound and restrictive outbound firewall.

No Firewall

In this set up our server is running completely exposed to the world ; this is akin to having no iptables firewall, and being in a data management zone or connected directly to the Internet.

Bind Shell

After our successful exploitation of the system : we choose to create a bind shell, remember a bind shell is a listener running on the target itself. Because there is no firewall this is successful, you can see our bind shell running on port 4141 in this netstat output from the target.

Reverse Shell

Since our bind shell was successful it is safe to assume our reverse shell will also be successful, and as we can see it is.

Restrictive Inbound Firewall Without Outbound Rules

In this portion we will test the same exploit against the same machine this time the machine will have iptables rules that allow inbound traffic only to the service ports needed and will allow all outbound traffic. In this case we can express our rules in terms of iptables as such

iptables -A OUTPUT -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 23 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 139 -j ACCEPT
iptables -A INPUT -p tcp --dport 445 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
iptables -A INPUT -p tcp --dport 5432 -j ACCEPT
iptables -A INPUT -p tcp --dport 8009 -j ACCEPT
iptables -A INPUT -p tcp --dport 8180 -j ACCEPT
iptables -A INPUT -p tcp --dport 21107 -j ACCEPT
iptables -A input -j REJECT

These rules will allow inbound traffic only to our specific services as well as connections requested by the machine. So let’s try the same exploit and shell code with this firewall configuration.

Bind Shell

As we can see our exploit code works — however , no session is created, that is because our iptables rules did not allow a connection to the bind shell

Reverse Shell

Now we can see, if we’re looking at our iptables rules and what they do our reverse shell should be highly effective. As we can see it is.

Restrictive Outbound Rules

Really our only chance at defeating the reverse shell is to create strict outbound rules so let us try again with more restrictive outbound policies. We will be using this set of iptables rules

iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -j REJECT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 23 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 139 -j ACCEPT
iptables -A INPUT -p tcp --dport 445 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
iptables -A INPUT -p tcp --dport 5432 -j ACCEPT
iptables -A INPUT -p tcp --dport 8009 -j ACCEPT
iptables -A INPUT -p tcp --dport 8180 -j ACCEPT
iptables -A INPUT -p tcp --dport 21107 -j ACCEPT
iptables -A input -j REJECT

This set of iptables rules limits outbound connections only to DNS lookups, and associated connections. The server needs to do DNS lookups or the services might not be functional.

Bind Shell

Our inbound rules haven’t changed so we will not test this here, our bind shell will still be ineffective.

Reverse Shell

In our default configuration with our listener on port 4141 this will not work : the target’s connection to port 4141 outbound will be stopped by the iptables firewall. Our shell has failed, however, we do know for this server to work it must at LEAST be able to make outbound DNS queries, what happens if we set our listener to port 53. Sure enough our reverse shell is successful the second time around.

What about NAT routers

What I’ve demonstrated here is all well and good in terms of a system that has exposed services, but what about a system behind a NAT router like a desktop system that has no services running. Will these techniques be effective there too?

That changes the method of exploitation, but the basic principles still apply. For instance say that your browser is vulnerable and exploited by a malicious website, or you download a malicious executable, obviously due to the placement of the router and lack of port forwarding a bind shell would fail. However a reverse shell would have the same rate of success.

We will do a small example with a desktop system now, this system is running Ubuntu 10.04.3 LTS (fully updated), is behind a NAT router with no ports forwarded and the system is running the ufw firewall in a fairly restrictive configuration, which allows nothing except http, https and dns outbound, and nothing inbound This is what some would call a relatively secure desktop system.

In this particular case since there are no services running our method of exploiting the system will be different, the user will be viewing a malicious web site that will execute our payload for us (this is why things like NoScript are very important). Alternatively, we could use a malicious deb package or odt/pdf document. However this exploit will work fine for these purposes, since ultimately we’re just showing how iptables and a NAT router deal with this threat.

As we can see when the exploit is triggered the shell is generated properly despite the firewall configuration. This is the same as in the third example with the server, this time we are utilizing port 443 for our listener, because it is safe to assume a desktop user would want access to https sites. We obviously could have gone with the defacto 53, or 80, 80 would be the most obvious choice, since to visit a compromised website in the first place port 80 traffic must have been allowed.

What about the router?

It functions on the same principle as iptables does (most routers are using iptables anyway). Since the connection originated inside the network, it is assumed it is legitimate traffic, and likewise the returned information is appropriately forwarded on. The same as if you were to visit a website, if the router were to block this type of connection you would not be able to share internet access.

Conclusion

Hopefully this has been helpful in understanding the ways that a firewall/router can and can not protect your system. It should also help to emphasize that as always security is a layered approach, and not just one application or another. A culmination of applications such as iptables, Apparmor and things like NoScript, is vital to a truly secure system.

I hope this was informative and entertaining, I had alot of fun writing this and hope it is useful to someone.

Happy Monday everyone!

Advertisements
Comments
  1. dangertux says:

    Fixed a ton of typos on this — particularly a broken iptables script so if you wish to follow it you actually can now…

    Probably should proofread better =/

  2. Dan says:

    Thanks for the excellent article, I have one question, if I may. I followed a link from the Ubuntu forums to this, the post of your was a reply in an Application firewall thread and my question is related.

    Taking the NAT scenario above, the exploit is allowed to work, because anything is allowed to make outbound connections on port 443. What would happen if I had an Application firewall running, where, instead of anything being allowed out on port 443, only a certain process were allowed out, firefox for example. Would the exploit fail?

    Many thanks

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s