Active Defense for web server - Part 4

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
Today, a very quick introduction to logparser and how we can use it to actively defend against offensive attacks.

Process
Logparser is a very versatile tool from Microsoft. It can chew it's way through all sorts of data, from text files to event logs, very quickly.

The very wise Professor Windows explains some of the background and usage at http://technet.microsoft.com/en-us/library/bb878032.aspx.

For this series, we are going to strictly focus on the reading of the IIS logs we setup in part 2.

The general concepts for this series came about from reading http://www.symantec.com/connect/articles/forensic-log-parsing-microsofts-logparser, and some of the topics covering blue team tactics on pauldotcom.com.

Once you have downloaded and installed the latest version of logparser from Microsoft onto your webserver, do a basic Nikto scan of your test website to generate some entries in the logs.

If your using Bactrack simply open a shell and type
   /pentest/scanners/nikto/nikto.pl -host http://yourip/

Once that is done, let's use loparser to check the logs on the webserver using the following command
C:\Program Files\Log Parser 2.2>logparser -o:xml "SELECT c-ip AS ClientIP, cs(user-agent) AS ClientUserAgent, cs-uri-stem as URIStem, cs-uri-query as URIQuery,COUNT(*) AS [Requests] INTO attacker.xml FROM C:\WINDOWS\system32\LogFiles\wherever your logs are WHERE cs-uri-stem LIKE '%cmd.exe%' OR cs-uri-stem LIKE '%...%' OR cs-uri-stem LIKE '%\%' OR cs-uri-query LIKE '%\%3c%' OR cs-uri-query LIKE '%\%3e%' OR cs-uri-query LIKE '%\"%' OR cs-uri-query LIKE '%\'%' OR cs-uri-query LIKE '%#%' OR cs-uri-query LIKE '%\%' GROUP BY ClientIp, ClientUserAgent, URIStem, URIQuery ORDER BY Requests DESC"
 
 
 Explanation
  -o specifies the output type
  SELECT is saying which log entries we are interested in. Refer back to part 2 for more details on the logging.
  AS says we are going to treat each line as a whole
  WHERE is now going trough each of the fields and looking for matches. For example, cs-uri-stem LIKE '%cmd.exe%' is looking in the cs-uri-stem field in each log entry for   the word cmd.exe in the request.
NOTE: I highly encourage you to look into other types of attack data that can be gleaned from the logs and add searches for them in your logparser query. There are lot's of good examples in the Symantec/Security Focus article above, or in the hacker sample script included with the logparser install.
  GROUP BY is used to select what we will write in our output
  ORDER BY is used to sort the output. In this case it will be the same order as the logs.

Since we didn't specify a location for the output of the file the xml will be in the logparser directory. Open it up and look through the results.

You should see lots of entries like
 - <ROW>
  <ClientIP>192.168.100.129</ClientIP>
  <ClientUserAgent>Mozilla/4.75+(Nikto/2.1.3)+(Evasions:None)+(Test:003295)</ClientUserAgent>
  <URIStem>/cgi-bin/..%5c..%5c..%5cwinnt/system32/cmd.exe</URIStem>
  <URIQuery>/c+dir</URIQuery>
  <Requests>1</Requests>
  </ROW>
- <ROW>
  <ClientIP>192.168.100.129</ClientIP>
  <ClientUserAgent>Mozilla/4.75+(Nikto/2.1.3)+(Evasions:None)+(Test:003296)</ClientUserAgent>
  <URIStem>/iisadmpwd/..%5c..%5cwinnt/system32/cmd.exe</URIStem>
  <URIQuery>/c+dir</URIQuery>
  <Requests>1</Requests>
  </ROW>

So that we know how to get some data out of the log files, what can we do with it?

Well, if we create a batch file
c:\scripts\parse.bat
C:\Program Files\Log Parser 2.2\logparserlogparser -i:iisw3c -o:csv -headers off "SELECT DISTINCT c-ip INTO c:\block\badguys.txt FROM %1 WHERE TO_LOWERCASE(cs-uri-stem) LIKE '%%cmd.exe' OR TO_LOWERCASE(cs-uri-stem) LIKE '%%.exe%%' OR TO_LOWERCASE(cs-uri-stem) = '%%select' OR cs-uri-stem LIKE '%%&%%' OR cs-uri-stem LIKE 'select' OR cs-uri-stem LIKE '%' OR cs-uri-query LIKE '%%\%%3c%%'"
Explanation
 -i the input is going to be iis logs, -o the output will be csv turn off headers, select only distinct ips.

And run it and provide a logfile as an argument
c:\scripts\parse.bat c:\windows\system32\logfiles\specificlogfile
A file will be created with the attackers IP in it.
Then if we run a script like this one
c:\scripts\simplewaf.bat
@echo
cd c:\block
for /f %%i in (badguys.txt) do netsh ipsec static add filter filterlist="Banned IPs" srcaddr=%%i dstaddr=yourip description="Banned IPs" protocol=any srcport=0 dstport=0"

Explanation
 We are doing a simple for loop that will iterate through each "line" in the file presented in argument. For each IP it finds, it is adding the IP to the list of IPs in the IPSec policy that was created in part 3.

So, assuming that the IP of your attacker is different then the one you were using for testing in the previous post, or if you removed it, the IP that you ran the nikto scan from should be added to the IPSec rule and the attacker can no longer connect from that IP.

We can do something similar on a Windows 2008 server
c:\scripts\simplewaf.bat
for /f %i in (c:\block\badguys.txt) do netsh advfirewall firewall add rule name="Bad IP %i" protocol=TCP dir=in localport=80 remoteip=%i action=block ENABLE
Explanation
 This one, I'm not very happy with. It is creating a new firewall rule for each IP instead of just adding IPs to an existing rule. If I find a better way to do this in the future,  I will edit this post.

Next Steps
By scheduling the parse.bat and the simplewaf.bat to run daily/hourly or even more frequently you could have a very simple web application firewall that blocks attacking IPs, but you can  probably see we could run into some major problems. We will save that for next time....

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.

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.

Active Defense for web server - Part 1

Took a while, but I think I finally got something "new" worth sharing.

Again as with most things I do, this really isn't anything new, but is really a mash up of other people's ideas.

The purpose of this series is to do a little offensive defense of a web server (mostly focused on Microsoft).

We will start with some background: setting up IIS and logging, using ipsec as a firewall in Windows 2003, using command line commands to manage a firewall in Windows 2008 and mining logs with Logparser.

With that knowledge we will be able to set up a script to implement a very simple "web application firewall".

We will conclude the series with a look at URLscan, a better version of the script and a Linux version of the "web application firewall".

Stay tuned...