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

[william fitzgerald <wfitzgerald@xxxxxxxx>]

Thanks Nathanael,

I agree that network-level access control is a well understood concept 
compared to the flurry of new applications being developed today.

I agree that if no firewall is in place a bastion host is required and 
even at that a firewall should probably be deployed.

I like the fact you mentioned TCP Wrappers (host based proxy firewall) 
also. In have used it and had a feeling no one bothered anymore ;-)

Is there any publications, research and/or white papers that illustrate 
the need for a holistic approach to Service Oriented Architectures.

What are the kinds of requests are made to system administrators to 
permit enterprise SOA web services?

Surely its not just please open port 80 and 443 to all.
Netfilter example: iptables -A FORWARD -p tcp --dport http,https -j ACCEPT

Presumably a network administrator may need to restrict both incoming 
and outgoing web service traffic, for example to a specific web service 
server from selected business partners IP subnets:
iptables -A FORWARD -i eth0 -s 193.1.1.0/0 -d  -p tcp --dport http -j ACCEPT
iptables -A FORWARD -o eth1 -s 192.168.1.1 -d 192.168.1.1 -p tcp --sport 
http -j ACCEPT

While the Web service application maybe able to handle DoS attacks, 
presumably a network administrator can help at the lower layers and thus 
help in providing a holistic security approach:
iptables -A FORWARD -i eth0  -d 192.168.1.1-p tcp -dport http --syn -m 
limit --limit 5/s -j ACCEPT

regards,
Will.



Nathanael Hoyle wrote:
> 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

--
William M. Fitzgerald,
PhD Student,
Telecommunications Software & Systems Group,
ArcLabs Research and Innovation Centre,
Waterford Institute of Technology,
WIT West Campus,
Carriganore,
Waterford.
Office Ph: +353 51 302937
Mobile Ph: +353 87 9527083
Web: www.williamfitzgerald.org
     www.linkedin.com/in/williamfitzgerald
     www.ryze.com/go/wfitzgerald




----------------------------------------------------------------------------
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]