Protecting a Server

[lamav]

Hi, Security Experts:

I have a question regarding server security.

How much value is there in restricting user access to only the TCP/UDP ports they need to communicate on and blocking access to any other open ports?

The intuitive thing is to think that blocking the unused ports is a good general practice - best practice. But does that really prevent or even mitigate a hacker (user) from launching a DoS attack on the server on the TCP port that is supposed to be open?

In other words, whether 20 ports are open or only one, does it really make a qualitative difference? What stops the hacker from launching, say, a TCP SYN attack on the open TCP port?

In short, is there really much gained in blocking those other ports.

I am looking for more than just a "general rule of thumb" answer becaue I know what that rule is already. I would like a more in-depth answer that specifically addresses the ability to disbale a server even if only one port is open.

Thanks

[Jon Marshall]

Victor

"How much value is there in restricting user access to only the TCP/UDP ports they need to communicate on and blocking access to any other open ports?"

A lot because each open port at it's most basic represents a set of running code ie. an app within which there are undoubtedly some bugs. The more bits of codes with bugs that are available to the hacker the more likely he/she will find a way to compromise the server.

"But does that really prevent or even mitigate a hacker (user) from launching a DoS attack on the server on the TCP port that is supposed to be open?"

2 different things going on here in this statement. Ports are blocked primarily to stop exploitation of bugs in the code that will allow the hacker to gain access to the server or get the server to do something insecure.

Dos attacks are more about disabling the server or service on the server and as you rightly say this is less to do with ports that are open ie. 2 ports or 10 ports not a huge difference. This is more to do with firewall capabililities, server capabilities and IDS/IPS to repel or rate limit in some way the amount of SYNs allowed through etc.

"In short, is there really much gained in blocking those other ports."

So yes, huge amount gained by blocking unwanted ports. But when talking specifically about DoS attacks the actual number of ports is not as relevant as the measures the firewall/server etc. have to cope with something like a SYN attack.

Hope i've explained this well enough, sure you will let me know if i haven't :-)

Jon

[lamav]

Damn! No matter where I post, there you are! I feel like Jean Valjean being hunted down by Javert. :-)

lol

Seriously, though, can you elaborate more on the purpose of blocking unused ports on a server? I always thought that it was about mitigating a DoS attack. In other words, preventing the attacker from using a packet generator to launch thousands of TCP SYNs on that open port and forcing the server to respond, thereby creating the embryonic connection.

If there's more to it, tell me...is there some good online reading you can recommend about this specific point?

Thanks

[Jon Marshall]

"No matter where I post, there you are! I feel like Jean Valjean being hunted down by Javert. :-)"

Bit of culture on NetPro, who would have thought ??

Well there is a fairly easy answer - Unified Communications/ Wireless, i don't hang out in these forums at all so there you go. Alternatively you could just add to the bottom of your post "Jon need not respond to this question" :-)

"Seriously, though, can you elaborate more on the purpose of blocking unused ports on a server? I always thought that it was about mitigating a DoS attack".

It is but it is also about trying to gain access to a server. DoS attacks are really only concerned with making the server unavailable and hence causing embarrassment/financial loss to a company.

But imagine what a hacker could do if they could actually gain access to a server within your network. From there they could launch attacks, modify data, get sensitive information such as financial accounts/trade secrets etc.

So a firewall/IDS/IPS and servers themselves are used to try and secure your network.

Ideally you want to shut down any unused ports on an Internet accessible server as a starting point, if the port isn't open then it can't be exploited. But sometimes things just aren't that simple. A web server in your DMZ needs to make a connection to an SQL server in your LAN. So your firewall is used not only to restrict what ports on the webserver can be accessed from the Internet but also which ports and IP addresses your DMZ server can communicate with internally. And it's important to restrict this traffic because LAN servers tend to have a lot more vulnerable ports open.

It's also worth mentioning here that this is where stateful firewalls are not enough. If you allow http to the web server and this webserver can make SQL queries there is a chance that a knowledgeable hacker can inject some SQL code into the request which then either modifies/corrupts or returns data from the SQL server that you don't want to reveal. This is where application proxy firewalls come in as they have a much greater understanding of the actual protocol, in this case SQL.

Trouble is stateful firewalls are very generic so they can be used for most protocols ie. TCP/UDP/ICMP etc. Application firewalls are not generic, they are very specific and each new protocol/application needs a new application firewall written for it.

IDS/IPS then becomes useful because it can inspect packets at the protocol level in a way that stateful firewalls generally don't. So and IDS/IPS system can tell if an SQL query is legitimate or not although again legitimate needs defining for your environment. IDS warns, IPS can actually stop the packets but you need to be very careful with IPS that you don't create your own DoS :-)

The other main problem with stateful firewalls is that if you tell it to allow the port that's usually the end of it. If there is bug found in the http software there is nothing a stateful firewall can do for you.

Finally to complete the picture there are extra bits of code added to stateful firewalls, in Cisco's case they were called fixups for pix firewalls 6.x and before and for pix v7.x and beyond and all ASAs they are called inspects. These are a little like application firewalls in that they have an additional limited understanding of the application but they do not have a full understanding of the application. They are used primarily to allow a stateful firewall to handle some "difficult" apps such as FTP etc.

Right i have probably bored you enough. Hope some of this has been useful. A good starting site for all things firewall/security in general is http://www.sans.org, they have a lot of very useful information.

Jon

[lamav]

Jon:

That was a really informative post. Thanks.

The server Im thinking of is not protected by any security appliance. So there are some who want to write an ACL that blocks all but one of the 20 or so appliaction ports that are open to outsiders, which is perfectly fine with me. I can understand it.

But then there is a desire on the part of some to write an ACL that is portable and can be applied across the network with no modifications. So,if you add site-specific information, you will have to change the ACL from site to site...

So, it becomes a matter of priority: security vs convenience..

[hobbe]

I would like to add some to Jon's posts.

but first let me say that I agree with all that is said in the posts above, but there are also more reasons for blocking ports internaly in the network.

One of the reasons one could block ip ports fx in the switches is that you can then get alarms and logs on computers that misbehave.

example:

Computer A (klient) starts to ask everyone on port 445, this is blocked on the switches with an inbound ACL on the switchport exception to this acl is to the servers that the klient needs to access.

An alarm is then raised from the switches stating that klient A is in violation.

An administrator/script can then assess the situation/lock down the switchport and might find out that there are a new virus or a trojan or a hacker or something like that.

There are many things you can do if you just start with finding out that there is a problem. Blocking ports and logging it or even setting off some ip addresses that you can monitor if there ever comes traffic to them can be a livesaver in the end.

fx if you have a virus outbreak you can automatically change the vlan on the switch, for the affected pc, to fx a privatVlanEdge with a patch server in the other end.

There are so many things you can do, but finding out that there is a real problem can sometimes be very hard. And blocking with logging that raises alarms might help you with that.

A compromise if you feel bad about blocking is that you can use ACLs that allows things but logs and only raise the alarm without any other action.

HTH