Sunday, March 20, 2011

Active Defense for web server - Part 3

The following is based on my experiences and (limited) knowledge. I am not an expert in anything, nor will I likely ever be one. My hope is that this might help someone, somewhere, sometime. If nothing else, it might be a good start for discussion.

Preamble
This series is for meant for educational use only, and is intended to be used in a lab environment. These have not been tested in the real world and may cause more problems then they help. It will by no means be an in depth discussion.

Background
As mentioned before we will be creating a simple WAF to actively defend against offensive attacks. We are still laying the groundwork for our scenario, this time by taking a look at blocking traffic.

Process
Please note, I won't go into a lot of details in these posts. There is a lot of information out there on these topics presented by people much smarter then me.

The main thing we will want to do with our simple web application firewall is to block traffic we suspect as malicious. The usual way to do this is with a firewall.

Unfortunately, the Windows firewall included in Windows 2003 is rather simple and does not make a distinction between inbound and outbound traffic.

Lucky for us, IPSec does

There is a great demo and explanation of how to setup a policy by John Strand here
http://www.youtube.com/watch?v=amHaBmOlfgE

As with most things Windows, there are many ways to setup an IPSec policy. You can use the snap in as shown above, via group policy templates, with the command line or even in the registry (under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec). In addition, there is a dedicated tool, the IPSec Policy Agent, IPSeccmd.exe. IPSeccmd.exe is part of Windows XP Service Pack 2 support tools. We will use command line.

First need to create an IPSec Policy.
netsh ipsec static add policy name="Simple WAF" description="Simple WAF" assign=no
This creates a Policy named Simple WAF.

netsh ipsec static add filterlist name="Banned IPs" description="Simple WAF Banned IPs"
This creates a filter list that we will add the attacking ip's to.

netsh ipsec static add filteraction name=Block description="Blocks Traffic" action=block
Here we create a Block action.

netsh ipsec static add filter filterlist="Banned IPs" srcaddr=X.X.X.X dstaddr=The.web.server.ip description="Banned IPs" protocol=any srcport=0 dstport=80
This will add an IP address to our banned IPs filter so we can test.

netsh ipsec static add rule name="Banned IP Rule" policy="Simple WAF" filterlist="Banned IPs" kerberos=no filteraction=Block

This rule definition ties together the policy, the filter and the action

Now, let's check it out using the snap-in.
To get to the IPSec MMC Snap-in click on Start | Settings | Control Panel | Administrative Tools | Local Security Policyor Start | Run | type secpol.msc | OK

Now play a game of search and click, and see if you can find the screens that match up with screen shot below.



Once you have verified the rule, right click on it, select assign, and try to access port 80 from the test box you added to the Banned IPs.

You could do something similar using IPSec in Windows 2008, but it is much easier to use the Windows 2008 firewall.

Again, there are many ways to do this. We will run a simple command from the command line
netsh advfirewall firewall add rule name="Bad IPs" protocol=TCP dir=in localport=80 remoteip=x.x.x.x action=block
This command creates a new rule called Bad IPs, and blocks access to port 80 from the ip listed in remoteip.
See http://www.windowsnetworking.com/articles_tutorials/Configure-Windows-2008-Advanced-Firewall-NETSH-CLI.html for some more examples and instuctions on how to use the netsh command to manage the firewall.

Next Steps
A very quick intro to logparser and a very simple script to use it to look for and then block attackers.

Friday, March 18, 2011

Active Defense for web server - Part 2

The following is based on my experiences and (limited) knowledge. I am not an expert in anything, nor will I likely ever be one. My hope is that this might help someone, somewhere, sometime. If nothing else, it might be a good start for discussion.

Preamble
This series is for meant for educational use only, and is intended to be used in a lab environment. These have not been tested in the real world and may cause more problems then help. It will by no means be an in depth discussion.

Background
As mentioned before we will be creating a simple WAF to actively defend against offensive attacks. This post will start with some basic good practices for setting up IIS and IIS logging on a Windows 2003 or 2008 server.

Process
We start this series with a discussion on best practices. This is obviously not an exhaustive list, but a general guideline.

The most important step is to reduce the attack surface. The web server should be a dedicated web server with all unnecessary Windows services disabled and only the ports required to function open.

Watch which web service extensions are enabled. If there are multiple web apps, make sure you setup separate app pools running under separate non-privileged accounts.

Web applications should be configured to run on a separate drive, and NTFS permissions should be reviewed.

Sensitive data must be transmitted (and stored) securely using SSL/TLS.

Make sure you have a backup and recovery plan for the server, the IIS metabase and the web application.

Review the files in the web application. Remove files that are not needed. Any old files should not just be renamed to .old, or .bak. Store those files somewhere else. The only files in the web application folder should be those required to run the app.

Setup the logging properly. This will be critical for the simpleWAF. This is a great explanation of how to setup logging in IIS 6 http://thelazyadmin.com/blogs/thelazyadmin/archive/2006/02/02/IIS-6-Logging.aspx.
Make sure you select the uri stem and uri query fields.

You should also enable utf8 logging by going to IIS Manager, right-click the local computer, and then click Properties. In UTF-8 Logging, select the Encode Web logs in UTF-8 check box, and then click OK.

UTF8 is a method of encoding that allows for both single and multibyte characters in one string. It is a good security practice to enable the UTF-8 format in case of an attack that might not translate correctly to the default english character set.

Logging in IIS 7 (and 7.5) has some many new security improvements, including an advanced logging option, but for the purposes of this series, the regular logging is all that is required.

To turn on logging, in the Features View, double click on Logging. Click on the select fields to choose what will be logged. In IIS 7, UTF8 is enabled by default.

Next Steps
Quick introduction to using IPSec as a firewall in Windows 2003.