Application Firewalls ( technical recipe)

I have harped enough about managing teams and innovation and open source and what have you. Here is then a recipe for a little more meatier dish, a completely FLOSS application level firewall. Schematics on the right.

The problem: protect N internal web servers and applications from internet attacks not only at the connection level, but also at application level.

The ingredients:
A firewall ( redundant for a richer result),
Apache in accelerator mode with SSL capability.
The N servers and their applications.
Mod_security: the inline apache protection module.
A relatively secure internal network.

The recipe: First of all obtain a wildcard chain certificate from an accredited organization such as digicert or thawte. The certificate will be in the form of *.yourdomain.com which will allow you to map hostnames to Virtual SSL hosts to internal servers. You can do that because apache has a little backdoor that will allow multiple virtual SSL hosts with the same certificate , the wildcard one.

Now to cook things up, first of all install mod_security on your server, this will allow you to block SQL injection attacks in real time and other nasties as well. Then season with SSL virtual hosts with the following incantation, some people claim that it works better if done in the whee hours of the morning.

<VirtualHost IP1:443 IP2:443 IP3:443 IP4:443>
DocumentRoot “/var/www/proxy_dir1”
ServerName portal.yourdomain.com:443
SSLEngine on
SSLCertificateFile /etc/httpd/certs/star_domain.crt
SSLCertificateKeyFile /etc/httpd/certs/wilddomain.key
SSLCertificateChainFile /etc/httpd/certs/TrustedRoot.crt
ProxyRequests off
ProxyPreserveHost On
ProxyPass / http://server1.yourdomain.com/
ProxyPassReverse / http://server1.yourdomain.com/
SetEnvIf User-Agent “.*MSIE.*” nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
</VirtualHost>
.
.
.

<VirtualHost IP1:443 IP2:443 IP3:443 IP4:443>
DocumentRoot “/var/www/proxy_dir1”
ServerName billing.yourdomain.com:443
SSLEngine on
SSLCertificateFile /etc/httpd/certs/star_domain.crt
SSLCertificateKeyFile /etc/httpd/certs/wilddomain.key
SSLCertificateChainFile /etc/httpd/certs/TrustedRoot.crt
ProxyRequests off
ProxyPreserveHost On
ProxyPass / http://server2.yourdomain.com/
ProxyPassReverse / http://server2.yourdomain.com/
SetEnvIf User-Agent “.*MSIE.*” nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
</VirtualHost>

Make sure that the server running apache in accelerator mode can resolve server1.yourdomain.com and server2.yourdomain.com. Now you see 4 IP addresses in the Virtualhost statement because you MUST use at least a two node cluster, and since I like my dishes spicy I have employed and active active scheme utilizing the old and proven hearbeat, which makes it a total of 4 ip addresses utilized in the cluster.

To top it off enter the following configuration in the regular virtual hosts section of the apache server to allow for transparent end user transport to the SSL encrypted site.


<VirtualHost *:80>
DocumentRoot “/var/www/proxy_dir”
ServerName portal.yourdomain.com
RedirectMatch (.*) https://portal.yourdomain.com
</VirtualHost>
.
.
.

<VirtualHost *:80>
DocumentRoot “/var/www/proxy_dir”
ServerName billing.yourdomain.com
RedirectMatch (.*) https://billing.yourdomain.com
</VirtualHost>

Now what we have achieved is:

  1. Inline blocking of malicious attacks by mod_security irrespective of encryption.
  2. Protection of production servers from DDOS and like attacks.
  3. SSL encryption on the users’ end to ensure that their data is safe.
  4. Transparent fall through from clear text to SSL site.
  5. SSL off loading to front end servers, it helps OWA tremendously!
  6. Freedom to move about production servers and services with just a change in the internal DNS.
  7. Back end servers do not need certificates.
  8. Disengage application programmers from interfacing with systems guys for changes on the production servers.
  9. Acceleration of applications with minimal fuss.
  10. Concentration of access logging and monitoring.

What we have then is an application multiplexer/accelerator/encryptor/protector for free!. Beware your mileage may vary.

Advertisements

One thought on “Application Firewalls ( technical recipe)

  1. stsimb says:

    Delicious recipe.. But be careful of those web apps or CMSs that are not SSL-aware .. They usually require a “base_url” in their config, and what the owner gives them is http:// and not https:// ..So they craft all their links as plain http, and your RedirectMatch rule points back to a generic homepage, not the actual (encrypted) URI they want ..I’ve actually found very few that can gracefully cope with an SSL off-loading situation, like horde.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: