6

I see my previous question was closed as duplicate of Why block outgoing network traffic with a firewall?. The answers that everyone agree with mention the value of blocking outgoing connections (to limit the call-home-and-get-additional-instructions ability of bad-ware), but not so much the effectiveness of using a port white-list that includes HTTP and HTTPS. This new question requests additional attention in that area..

Obviously incoming connections must be blocked. (except to a white-list of address+port combinations - for example in case you are running a webserver on your network)

Requirements: Assuming that it is mandatory to allow web browsing (keep HTTPS and HTTP and DNS as open)... Is this below analysis correct? (Remember, all of these below are except for the white-list of IP addresses, which is useful for blocking DNS and SMTP, but not acceptable for blocking HTTP and HTTPS)

  • Restricting SMTP would have significant real value.
  • Restricting DNS would have a little real value.
  • Having some white list of ports and blocking all the others has some real value so the bot-writers who just 'make up' a port will have no success.
  • Opening additional ports is not a security risk on a one at a time level. If you have already opened HTTP/HTTPS, then you are not going to gain a measurable advantage by limiting out things like NTP, FTP, WHOIS.
  • Requiring a Proxy before using HTTP/HTTPS would be the only real way (given the above requirements) to have significant real value, particularly if you configured the Proxy on the browser level (the second or third place a bot would look for a proxy config), instead of the computer-wide level (the first place a bot will look for a proxy config). (you may need to add a white-list of addresses for your Windows automatic updates so that a proxy is not required for those)

Are there inaccuracies in this analysis? Should there be more to this analysis?

Community
  • 1
700 Software
  • 13,807
  • 3
  • 52
  • 82
  • ICMP ping and DNS tunneling can be used to create a bidirectional covert channel out of your network. – Matrix Dec 21 '12 at 18:44

2 Answers2

1

In my opinion this is a pretty well rounded analysis but there are a couple points that could use improving.

Basic bidirectional firewalling is a good start but unless you have the ability to get into the actual application level traffic - be that with a HTTP proxy application level firewall or what have you - there is still a major hole in your security.

A lot of firewalls today - even those that advertise application level analysis - don't do application level filtering for all protocols. Picking a common port number for a malicious cause is a pretty easy way to get around a tightened down firewall. Whenever you can it is always best to whitelist your definitions, even for the semi common protocols.

As an example I've previously experimented with a TCP service bound to port 123 on an outside host I was experimenting with. I was surprised that I was able to get to it from a protected internal network without any additional firewall rules. Turns out the the NTP definition included both UDP and TCP ports and was allowed out to anywhere.

About the only protocols I don't do that with are HTTP, HTTPS, FTP, and SMTP. Each of those has some kind of application level filter available configured for my my clients.

EDIT:

All this changing terminology is making me feel old.. Looks like the suggested terminology for the device I'm thinking of is a UTM (Unified Threat Management) gateway.

Tim Brigham
  • 3,762
  • 3
  • 29
  • 35
  • **Application level filtering** This would definitely allow me prevent non-HTTP traffic on port 80. Perhaps it would even require some browser-like functionality like a reasonable user agent and other http request headers, or even require reasonable request patterns (GET the page before you POST to it). That, or similar filtering, would be good security, but still *could* be bypassed by the bad-ware - assuming the author went through that much trouble. Is that right? – 700 Software Dec 20 '12 at 18:34
1

I recommend you use firewalls on operating system where you can set which executable has access to network resources. There, you can for example allow only firefox.exe, windows update and windows time synchronization process to have access. The rest you block and log. Advanced firewall supplied with Windows 7 supports this. In addition you can use also officially supplied AppLocker where you can set which executables and DLLs are allowed to run. Default policy will allow everything from ProgramFiles and Windows directories, which require Admin privileges to write to.

Network firewalls, like the one you are setting up (I presume), are crude tools. It's like trying to regulate water pressure in houses by using a damn on a river. They have their uses, but don't forget:

If all you have is a hammer, everything looks like a nail.

Matrix
  • 3,988
  • 14
  • 25
  • That is a neat recommendation. But what about my analysis. Does it look correct to you? – 700 Software Dec 21 '12 at 19:12
  • Advanced malware will use ports 80/443/TCP to establish outgoing connection to control server and will even use proper HTTP protocol to communicate, just like your browser does with "AJAX" applications. It might also use HTTPS (SSL) to prevent sniffing. Your analysis is centered around whitelisting ports and blocking the rest. There is more to network security than that. Without knowing what you want to achieve (the end goal), I cannot be more specific. – Matrix Dec 21 '12 at 19:43
  • I like your recommendation as it actually 'works', instead of 'helps'. This is one half of what I am trying to accomplish with this question. The other half is **what's the value of specific common rules on port level firewalls**, which I have written out above, but I don't want to assume that I have done it correctly. I totally agree that this port white-list solution can be circumvented. The primary reason I am even considering this is because there will be *some* mal-ware that does not bother following common white-lists. – 700 Software Dec 21 '12 at 20:58
  • If looking purely from the "ports perspective", then your evaluation is correct. In practice, if you implement this port white-listing policy, you will stop some malware. – Matrix Dec 22 '12 at 00:01