Re: [WEB SECURITY] Query: Are Firewalls obsolete in an Enterprise Web Service Environment?

[Nathanael Hoyle <nhoyle@xxxxxxxxxxxxx>]

william fitzgerald wrote:
> Dear Web Application Experts,
>
> Are Firewalls (Network Access Controls) obsolete in regard to Enterprise 
>  Web Service Environments?

<snip>

In a word, no.  I think one reason you may see so much discussion on 
application-layer security with web applications is that it is far less 
well understood and 'solved' than is network-layer security.  Most of 
the industry has had to deal with network-layer security for all types 
of servers for quite some time, and many tools and best practices have 
been developed to address these issues.  Web applications are a unique 
security challenge in that they require extremely broad/public access to 
potentially insecure applications.

Not having a firewall in place however, is roughly equivalent to leaving 
your back door open.  Assuming that your server is listening on even one 
port more than what is directly used for the web application (and this 
is almost always true, whether it is a Windows or Linux based server), 
you are unnecessarily increasing your attack surface area by allowing 
access to these ports from outside.  If an attacker is successful in 
exploiting a vulnerability in a network service unrelated to your web 
application that still allows sufficient compromise to read privileged 
data or perform unauthorized modifications, all your brilliant, 
carefully filtered application layer controls are irrelevant.  The 
ability, for instance, to directly access the data in your database 
makes all of your application-layer login controls useless.

You mentioned defense-in-depth, and that is very much the motto still. 
To give you some idea of my typical approach in setting up a Linux 
server providing web application services (which is nothing brilliant or 
new in theory, but not often done in practice, unfortunately):

1) Uninstall every software package from the machine which is not 
necessary for the correct operation of the server.  This means the GUI, 
compilers, debuggers, etc.  A properly set up environment will use a 
separate, non internet-facing development/test staging system for things 
like debugging.  Don't give an attacker any extra tools, or introduce 
possible holes that don't need to be there.

2) Disable every system service that is not needed for the correct 
operation of the server.  In most cases, if you don't need it, you 
should remove the package for it as well, as above, but some services 
you may not be able to remove readily (especially on a Windows system).

3) Ensure that each process is running with the least suitable 
privilege.  This means sandboxed users for each daemon at a minimum so 
that these processes lack the privileges to interfere with other parts 
of the system.  It also means chroot jails where possible.  Not all 
software supports either proper privilege separation or chroot jailed 
environments.  Strongly consider replacing ones that don't with ones 
that do for a given task, if possible.

4) Use mandatory access controls (MACs) if possible (e.g. selinux) with 
a 'strict' fine-grained policy which explicitly grants each process/user 
only the minimum set of privileges required for proper operation. 
Careful use of audit2allow will simplify this.  Review your audit logs.

5) For every needed service, listen only on unix domain sockets if 
possible rather than network sockets.  Set appropriate user permissions 
for the unix domain sockets.  Where you can't use unix domain sockets, 
listen only on the localhost/loopback address if possible for your 
application.

6) Consider using tcpwrappers in addition to a firewall.

7) Use iptables and make use of its stateful packet inspection 
capabilities.  Allow only the traffic that you must have.  Firewalling 
is a broad topic, outside the scope of this email, but:

* drop and log invalid packets, regardless of their source
* drop and log packets from undesirable/blacklisted ip's
* allow established/related traffic
* allow new connections to deliberately exposed services
* drop and (limit) log remaining packets

REVIEW your logs.

8) Use a network (hardware) based firewall in front of the host.  This 
is not quite redundant.  Flaws that allow traversal of either one of the 
two firewalls which does not allow traversal of the other are mitigated.

9) Modify your pam (or other authorization config) settings to require 
users to be in wheel (or similar group) to perform su operation. 
Enforce password complexity requirements (passwdqc and such pam 
modules), expire passwords regularly.

10) If you are using ssh for access, disable root logins.  Disable port 
forwarding if you are not using it.  Ideally also disable cleartext 
password authentication and used (passworded) keys for authentication.

11) Make sure apache or other web server is only loading the modules 
needed by your application.  Endless holes posted in mod_rewrite don't 
matter if you don't need it and have set it not to load.

This obviously doesn't begin to address physical security, that's 
entirely separate.  But for network-based security, after performing the 
above steps, I would consider the server to be approximately ready to 
begin the phase of application-layer security.

Defense in depth still matters.

Just a few thoughts,
Nathanael Hoyle
Unix/Linux Systems Administrator

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]