Recently one of my clients had one of their servers attacked. The intrusion detection caught it, and I believe a lot of the malicious stuff they were trying were correctly filtered out by asp.net as dangerous requests, but in order to understand more about what was/is going on, I worked with 2 tools to help look at the situation a little deeper.
First, I wanted to look at the live requests coming to the server and see the payloads they contained. To do this, I installed WireShark on the server, and started to capture traffic.
Wireshark as 2 types of filters: capture filters and display filters. From the capture side of things, you can really cut down on the noise if you filter out the stuff you don’t care about. So I used a capture filter of tcp port 80 or tcp port 443
Then, while the capture is running you can type in a display filter so that you can tell if you are getting the specific type of request you are interested in during the current trace. In this case, I was only interested in http POSTs, so I could use this filter http.request.method == “POST”
This way you can let the trace run until you see records start to come through that match both filters.
The other thing I wanted to do was to look at log files to see how the traffic to the site changed over time. To do this I installed MS Log Parser and the Log Parser Lizard. With these two tools it allows for a nice UI and SQL queries against the data. As you can see below, the requests/attacks started at 5:52.
I’ve been looking around trying to find a good description of the specifics of how single sign on works with an ADFS server. This is the best I was able to figure out.
I recently had some problems running telerik Sitefinity on my dev machine. When I clicked on the Pages menu, it would give me a popup telling me that IIS 8.0 returned a 404.
All the help online talked about reregistering the WCF stuff using Servicemodelreg.exe, but doing that seemed to screw stuff up even more. Others also talked about using aspnet_regiis, but that doesn’t work in Windows 8.
Finally, I found this post that dealt with the exact issue. Adding the WCF Services under Turn Windows features on or off worked perfectly.
Thanks to http://proq.blogspot.com/
Here are some great articles talking about properly enabling compression in IIS6.
I had made some of these changes in the past, but I noticed that they had since been overwritten or not persisted. I believe with the changes to the metabase file it will help keep the compression working.
Have you ever come across this error message?
Forbidden IP address of the client has been rejected
If you are using Small Business Server you might come into this quite fast as by default it will lock down IIS to keep machines who are not on the same subnet from accessing the web server.
This means if you VPN in you can’t browse the intranet site. Oops, that’s not good.
To fix this problem, you need to edit the website and iis application properties in IIS. On the Directory Security tab edi the IP address and domain name restrictions. Change the settings on there from “Deny” to “Grant” and you will be all set.
After debugging it for a while, I found the problem to be that URLScan had been installed on the server (Windows 2000 Server), which was preventing any requests with dots in the folder name.
URL Scan is a tool that MS suggested everyone install a while back that acts to filter out many malicious attacks.
So, with the default settings any request for a file inside the scriptsSystem.Web.Extensions folder would be denied as a 404 b/c of URL Scan.
To fix this, you need to edit the UrlScan.ini file, located in %WINDIR%System32InetsrvURLscan. Near the top of the file, change AllowDotInPath from 0 to 1.
The run iisreset to restart IIS and you should be ok!
More info on URLScan is available here:
Here is a nice article on creating a test (bogus) SSL certificate for your local develoment machine.
ScottGu has a nice article on how to do something similar with IIS7, which is going to be the webserver on Vista machines.