A destructive force can always leak information through HTTP packets. Should I bother configuring outbound rules on my firewall?

Question

I know my way around firewalls, but I am in no way a security expert. And recently, I am wondering how to effectively configure the outbound rules of any company's firewall.

For the question's sake, let's assume there is a state-of-the-art antivirus software installed on every client computer and web access is proxied and scanned for virus activity. Let's assume they are perfectly configurated, but an unknown virus, or specifically designed application (that does not require root rights) is executed on the computer in user space.

In theory, I would track all software that is used and configure the firewall to let through destination ports HTTP(S)/80+443, "Message Submission"/587 and IMAPS/993, as well as any destination port, that is necessary for LOB applications.

But that could easily be 10 to 20 destination ports, or more. They would have to be documented and updated, which would cause a great amount of work and is prone to errors, when any malware could just encapsule any information in a HTTP packet and send it to port 80 of the receiving end.

And that were, what I would do: If I were to write a virus to leak company information, or to join them to a botnet, I would not even bother connecting with the receiving/controlling server through port 6667/IRC, as it's usually blocked. I would simply encapsule all information in a HTTP packet and connect to destination port 80/HTTP.

I read about Deep Packet Inspection, but it seems to me, that I would have to know exactly how the destructive packet has to look like. In other words, I would have to create a DPI filter, that is able to differentiate between a file that is legally transferred via HTTP from a user, and a file that is illegally transferred via HTTP from malware.

With this thought, I don't see why I should do any more work on any firewall than allow any service from LAN to WAN.

Answer 1

You're confusing several things.

First, pretty much every standard protocol (save for FTP which you should avoid like plague) has only a handful of standard ports. Since these ports are standards, they will not change often and therefore will not need to be updated.

Now, some applications will require specific ports to be opened, Typically, that's handled through an exception process: the application owner will submit a request to the firewall team for an access to be open. Usually, this request is limited to a specific range of internal systems, going to a specific range of external system with a specific list of ports. This request can then be filled as documentation and, if it is granted, the firewall configuration can be updated accordingly.

But your questions shows that you're approaching this incorrectly. What you're asking would be like asking if locking your home door is worth the effort since you know that some people have access to bulldozers. The proper process for designing a strategy for protection is:

1. Identify the assets you want to protect
2. Identify the threats you want them protected against
3. Identify the proper measures to mitigate those threats
4. Audit your result
5. Go back to step 1.

You seem not to do any of these except step 3.

Answer 2

If your goal is to stop a virus or an active attacker from exfiltrating company data stored on a PC that can execute arbitrary code on the same client PC, you're hosed.

There's a vast number of sites to dump data to that are the same sites your users ALSO need legitimate access too. You simply can't block these. Unless you're willing to block essentially most of the internet, forget it, you can't do this through blocking.

In the end, the approach of blocking the attacker ONCE HE HAS THE DATA is fruitless. It's like trying to stop an unknown thief who's just stolen the Mona Lisa from leaving the country. There's just way too many ways out, and you don't know what he/she looks like anyway. The really dumb thieves never would have gotten this far anyway.

Instead, you should focus more on limiting access to data in the first place, and deleting information no longer relevant. What's your data retention policy? Attackers can't steal data that's been deleted.

Answer 3

How much you invest in knowledge, products and configuration depends on how high your risk is. There is no solution which will offer 100% security but there is a great difference between the security a simple packet filter firewall can offer or which application level gateways can do:

• Packet filter firewalls can only filter at the packet level (IP, port, protocol). Some claim to do some application level filtering but this is restricted to matching the content of single packets and can thus usually easily bypassed.
• DPI solutions look deeper into the traffic and can detect application protocols and do some analysis to detect malware in traffic etc. But they are usually restricted to (mostly) passive analysis and can thus often be bypassed by using uncommon protocol features or a slightly invalid protocol which nevertheless is understood by the client application (i.e. browser or mail client).
• Application level gateways can not only inspect the traffic at the application level but can also sanitize it and can this way enforce a consistent interpretation of the traffic in the gateway and the client. That does not mean that they all do it properly, i.e. most application level gateways for web I have seen can still be simply bypassed.

What you find in the various products is often a mix of technologies, i.e. some fast packet filtering for the basic stuff, some passive DPI for the more advanced stuff and sometimes application level gateways for web and mail.

As for a malware which is already inside: If it just wants to phone home (Command and Control communication) then it might be a bit effective to block some ports like IRC. But current malware usually uses HTTP anyway so it makes more sense to employ a blacklist of known C&C servers. Once these are known such blacklists can often be implemented at the packet filter level already (i.e. target IP address) but your packet filter has to support such things. But some malware uses twitter or blogging sites for C&C which makes it really hard to block.

At the end you can make it harder for an attacker so that he moves to easier targets. Unfortunately, if you have really interesting data the hacker will not do this because these data might be worth a lot of money. So you need to employ breach detection system ... - it only gets more complex for both you and the attacker and the money/effort needed on both sides will increase. Which means that in the end you need to know first what you need to protect, how much is it worth and how much money you can spend in products, training, knowledge, support ... to fight any attackers.

Answer 4

Stephane is right, it is quite hard to block everything possible. Rather, I would also start with security/risk analysis to identify which data/systems should be protected at which level. And then search for methods to implement desired protection level. If some protection is not possible, or is extremely complicated technically, there could be compensating controls. E.g., if blocking all "illegal" HTTP packets is not possible, than you could train staff working with high security data to avoid getting viruses through e-mail and suspicious web-pages etc.

As a technical solution to your question, it could be not only DPI, but also application firewalls, or software that offers security controls per application, for GNU/Linux it could be:

• Application level firewalling with iptables
• AppArmor
• SELinux

In addition, you could have a look on Data Loss Prevention systems.

Finally, in our research group we have a concept of kind of DPI filter (http://www.lock-keeper.org/), that only allows specific pre-defined types of packets to go through, while everything else is blocked. However, IMHO, this is not meant for daily Internet usage, rather this is for cases, when you need to regularly send some data to the server over Internet, but do not want to open an access to this server. In this case you could configure a firewall so, that it, for example, allows only text files of pre-defined format and size to be sent over FTP once per day within predefined time period, and blocks everything else, even if it is a valid FTP connection.

Answer 5

Firewalls aren't going to prevent espionage, but there are many other threats that they can help prevent. For example:

• If you don't want just any workstation within your organization to spew spam onto the Internet, it makes sense to block TCP port 25 outbound, and require them to use your mail server.
• To guard against DNS-based attacks, you may want to block TCP/UDP port 53 outbound, such that everyone has to use your DNS server.
• Certain Windows networking protocols are useful within an organization, but rarely useful on the Internet, and more likely to be used for harm than good.
• SNMP transmits a lot of information, including secret community strings, using cleartext. It makes sense to block SNMP outbound in case a misconfigured device leaks such information.

Answer 6

Daniel, I definitely understand where you're coming from. Doing outbound traffic filtering seems like such a pain in the backside. And, well, it can be a real pain in the backside, depending on how you do it and what you hope to accomplish. Moreover, users complain to everyone they can whenever things they want to access for legitimate work purposes (and sometimes for less legitimate, non-work purposes) are inadvertently or deliberately blocked by a filtering scheme, and generally make themselves a pain. And, as you stated, many clever attackers and their malware have found ways through pretty much even the best thought-out filtering schemes with a disturbing frequency of success. So, what's the point of doing outbound filtering at all?

Well, really, outbound filtering is useful in much the same way that having an anti-malware program running on your network's PCs is useful, or trying to filter spam & phishing emails when they hit your mail server is useful. Or doing user education about the dangers of spearfishing, or putting password policies in place, or implementing application whitelisting, on doing plenty of other things that even if "successful" won't detect or stop all attacks. The point is not whether some particular measure you can take will detect/stop all attacks; nothing will do that. The point is whether it will detect or stop some attacks. Or, more exactly, whether it will probably be effective enough in detecting/stopping some attacks that it deserves to be one element of your layered, defense-in-depth security regime. And deciding that also requires looking at the resources that implementing the measure would take (including your time and attention) and other considerations, like the level of security risk that your organization is or isn't prepared to accept for the data/systems that you are building defenses.

I don't know that I can tell you that "It's worth it for you to do X in the way of outbound filtering, no more and no less" without knowing more about the resources you have the authority to bring to bear and how sensitive/otherwise important, in your organization's eyes, what you are trying to protect is. But I think I can point out that doing outbound filtering isn't by any means an all-or-nothing thing. For example, as others have said putting simple static firewall rules place to block outgoing traffic from ports you know with near certainty aren't going to need access to the Internet during authorized employee usage is a basic but effective measure that can stop from communicating or hinder the impacts of some kinds of malware. If you want to get more elaborate, doing proxying of all http & https traffic going to the Internet and blocking any connection going to and/or from any remote IPs on a blacklist that you subscribe to would require more set-up & maintenance work (and potentially a financial outlay of some kind, depending on what blacklist service you went with). But it would (probably) block/hinder some more malicious activity. And, of course, filtering measures things get more elaborate and potentially more resource intensive from there.

But my overall point is: there probably is some degree of filtering that makes sense for you to do, in terms of effectiveness in stopping some attacks vs. the resources needed for set-up and maintenance. The fact that you don't want to go to one extreme, trying to do resource-intensive things that still perhaps won't stop many sophisticated threats, doesn't mean you should go to the other and do no nothing at all.

As for what specific degree of filtering measures make sense for your case, only you can really answer that. But I'd suggest that you might take a good second at whether some of the basics, at least, would have some value.

Answer 7

We don't bother except for 137,138,139,445 to block Windows networking. If we had concern over accident for other things that default on we would debate blocking them too (ref: 200_success's answer on SNMP). It's far too late to protect against malice at this point.

I've seen many attempts at monitoring HTTP/HTTPS outbound. The HTTPS mass intercept is destructive, insulting to your users, and of limited utility. HTTP virus scanning is quite doable but beyond that it gets hard fast.

Don't take 200_success's suggestion about blocking port 53. It blocks too many debugging cases to be useful, and it doesn't block ssh over DNS anyway. Instead configure your clients correctly and monitor. If you see too many direct outbound to be manual dig/nslookup entries, investigate.

For the one case that we considered really high danger list, we decided the best approach is to switch to full white-listing and block all hosts except our own internal DHCP, DNS, SQL, file, and print servers, and got the list it needs to talk to down to two.

Answer 8

You seem more worried about the technical details more than about the rest. Besides the basic golden firewalls rules, as to block ingress and egress networks, the others have to be properly evaluated.

As @Stephane posted, there is a need to identify what to protect when dealing with a firewall policy.

It is of utmost importance to identify what will influence your stance, and what level of security will be needed and the capability of enforcing it successfully.

Some factors to take in consideration:

• Control/operation network

Normally most of this network is not supposed to have any access from the normal network and much less from the outside. At most, it can communicate with a proxy to have access to software updates, and with the internal DNS/NTP servers.

• Servers providing service to the outside

This will be your corporate VPN, DNS, SMTP and proxies servers. They will have direct, somewhat restricted access to the Internet.

• Servers being your presence on the Internet

WWW servers, or other services provided to the exterior. Only the needed services should be open.

• Organisation layers

From instance, in a university, the students quarters have much different requirements from professors networks.

• Sensitivity of departments / information

HR, financials and operations, for instance, should be insulated from other networks. Some of these departments should also have a more restricted policy about using Internet.

• Internal politics

Some places just have a politics as providing full access to the Internet, while others for instance, define Internet will have full access outside work hours, while others may define other kind of restrictions.

• Industry

For instance, in the Education industry it is expected to have the least restrictions, while in an ISP even less but with bandwidth caps, while in banking being very restrictive either in what gets in or what gets out.

However, even often there is a need to not get lost between the distinction [and separation] between the service for customers and the corporate network, where different cultures and rules will apply.

• Perceived acquired rights / resistance to change

There goes against saying that tradition and acquired rights will play a very strong role into what you can achieve.

• User expectations of service vs business needs

The balance between security, the needs/wants of users and quality of servce is always a delicate one, and compromises need to be made. For instance, in a very open environment the expectation to use p2p may not be met when it interferes with voIP and HTTP/S services.

• Law requirements

You may have to keep certain types of logs X time. You might need to cut several protocols, namely bittorrent (several firewalls of big players already come with DPI).

• Documentation and monitoring

All goes without saying to effectively establish a successful firewalling policy, there is a need to know what is happening inside the network and IF all is documented. Audit the service. A big name player will be more than happy to help if that mens the possibility of scoring a sale.

• Support of management

Finally, the process as to be fully supported by the upper management, and most of the decisions of what has to be allowed or cut have to be approved by them.

• Evolution/Restrictions of technology

Restrictions on costs, resources, and requests/needs will influence the decisions on all the above points, and the technology you will use.

Mostly in the fast-paced world of technology field, when focusing on the technical side, some of the strategies and decisions you may be using can be or will be shortly outdated. As an example, some vendors are trying to sell me solutions that soon will have impaired functionality due to the widespread proliferation of VPN/encryption for personal use.