Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So far in nearly all of the companies I have worked for, I have not seen host implemented firewalls (iptables) employeed for internal servers or desktops. Just wondering how prevelent this is out there in the world.

Furthermore, is this a good thing or a bad thing and why?

share|improve this question

closed as not constructive by squillman, voretaq7 Jul 19 '12 at 21:22

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

generally I'm looking at internal servers and desktops. Not special things like DMZs and internet facing systems to clearify – mdpc Aug 4 '11 at 19:33
up vote 1 down vote accepted

Firewalls between the DMZ and the internal network are common. Within the internal network probably not as much. Windows has it's default firewall which everyone hates and some people disable. Specifically setup firewalls, probably not very often as you would need so many holes in the firewall to let the employees work that anything an attacker might want to do wouldn't take them very long to find a machine which has the access.

That said I worked at one company which had about 12 different internal networks with DENY all firewalls between them. Getting anything done was a nightmare and took hours of work to get the specific firewall hole that you needed opened up.

share|improve this answer

At my place of employment (a medium-sized private liberal arts university), we use three different firewalls. First, there's a perimeter firewall that polices all traffic between our internal network and the internet. Second, each VLAN has a firewall. Third, each host (whether Linux or Windows) has its own host-based firewall.

All firewalls are configured with a default deny on inbound traffic and we poke holes only where necessary. There are generally no rules on outbound traffic (except things like blocking SMTP, DNS, etc) Yes, this means that there's a bit of extra work that needs to happen to, say, open up ports 80/443 for a new webserver (network team needs to modify the perimeter firewall and the VLAN firewall, and the systems team needs to modify iptables rules), but the benefits are well worth it.

For instance, say we didn't use host-based firewalls and some box in our Linux server VLAN got compromised. In this situation, the compromised host would have access to all ports on the other servers in that VLAN, possibly allowing other hosts to be compromised as well. With host-based firewalls, though, you limit your damage. In our case, we only allow traffic to specific ports from only the subnets where they need to be accessed from. For instance, we generally only allow access to port 22 (ssh) on our servers from the subnet where our team's workstations live.

In conclusion, my feeling is that implementing host-based firewalls while at times is cumbersome, is well worth the extra effort.

share|improve this answer

Nowadays the old fashioned firewalls don`t protect any more. The common attacks are lauched against the open http or https server ports - these have to be open to provide your service.

Apart from that you can use IP-binding for your services and bind neccessary services to localhost, so they can`t be contacted from the outside. With that setup you will not need a firewall any longer.

An exception might be a server in your internal network where external support has access (not with admin-priviledges) on that server you might want to prevent connects to other servers not associated with that server (outbound firewall). Or you can do this by routing-rules as well: Forbid any route by default and explicitely allow where to connect to (again: no firewall needed here).

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.