Nov 102012
 

The other day I was checking the traffic stats for my WordPress blog to see which of my posts were the most popular. I was a little concerned to see that wp-login.php was in the Top 5 total requests almost every month.  Since I’m the only author on my blog my logins could not possibly account for the traffic hitting that page.

image

The only explanation could be that the additional traffic was coming from automated hacking attempts. Any server administrator concerned about security knows that “footprinting” is one of the first things a hacker will do when checking for vulnerable sites. I checked a few of my non-wordpress sites and sure enough every couple of days page requests were coming in for wp-login.php and urls for other CMS products such as Plesk’s Cpanel.

Using log parser I wanted to see how many IPs were hitting my login page during a particular month. I like to keep my complex queries in a separate query file and then output the results to a text file. In a previous post I showed how you can leverage this technique to automate log parser to run multiple queries at once. Here’s the query I used to check every log file for my site in the month of October. So this query outputs a simple text file clearly showing thousands of requests to wp-login.php from across the internet during the month of October.

logparser.exe file:wplogin.sql?destination=wpadmin.txt -o:NAT

Here is the SQL query contained in wplogin.sql. I am using a couple of advanced techniques such as searching in multiple log files and filtering the dates to get a results for one month:

SELECT c-ip, COUNT(*) AS TotalHits
FROM ./log/u_ex*.log  TO %destination%
where (EXTRACT_FILENAME(cs-uri-stem) = 'wp-login.php'
and TO_STRING(To_timestamp(date, time), 'MM')='10'
GROUP BY c-ip
ORDER BY TotalHits DESC

Having always followed best practices for hosting sites I was confident that my sites were not vulnerable to these automated probes but it was still a bit irksome to know they were occurring. And there’s always the possibility of some zero-day exploit showing up so I decided the simplest thing do was to block them. IIS now has a great new module available for Dynamic IP Restrictions however that would only block the requests once a threshold was reached. I needed something more “nuclear”. I wanted a means to block everyone hitting that page except for me and the help of the IIS Url Rewrite module a simple rewrite rule was going to do the trick.

In another previous post I showed how easy it was to use Url Rewrite for SEO and security. Now you can see how to tighten security even more by aborting requests based on almost any criteria. In my particular case I wanted to abort requests to wp-login.php from any IP address except for my own IP. So the next logical question is “what’s my ip address?” There are several sites online which can offer you this information. Probably the easiest to remember is whatsmyip.org. When you visit that site, your public IP address is displayed very clearly at the top of the page. This is the IP that you want to put in the rule below. It is important to note the use of “negate=true”. This means all IPs except for the one referenced. The next logical question is what if I need to login to WordPress from more than 1 IP address such as from home and at the office? This is a simple matter of just adding an additional condition to the rule below.

<rewrite>
      <rules>   
    <rule name="Block wp login" stopprocessing="true">
          <match url="(^wp-login.php)" ignorecase="true" />
          <conditions>
            <add negate="true" pattern="10\.10\.10\.10" input="{REMOTE_ADDR}" />
          </conditions>
          <action type="AbortRequest" />
        </rule>
      </rules>
<rewrite>

So in summary Log Parser makes it very easy to get quick extracts of data from your web site’s logs and IIS 7’s Url Rewrite module not only offers powerful rewriting and redirecting of urls but also an easy way to tighten the security of your site. Thanks for reading.

Share and Enjoy

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS
Sep 132012
 

Before IIS 7, if you wanted to do url rewriting with IIS 6 you had to use a 3rd party program such as ISAPI Rewrite by helicontech.com. This was a good program but it wasn’t native to IIS and there were limitations such as a site hosting more than 1 domain with different applications running.

With IIS 7 url rewriting and redirecting has never been easier thanks to Microsoft’s Url Rewrite module. The rewriting is done by rules which are specified in the web.config under <system.webserver> element. Using IIS Manager you can use the Url Rewrite gui to create and maintain your rules.


You can also just put the rules directly into the web.config without using the gui. For example:

<system.webserver>
<rewrite>
<rules>
<rule name="xyz">...blah...</rule>
</rules>
<rewrite>
</system.webserver>

IIS 7 Url Rewrite WWW

One of the most common needs for SEO is to force your site to use www for all page requests so that search engines will go to www.mydomain.com instead of domain.com. This is very easy to do with IIS 7′s Url Rewrite. Here is the rule:

<rewrite>
<rules>
<rule name=”Redirect to www” patternSyntax=”Wildcard” stopProcessing=”true”>  
<match url=”*” />
<conditions>
<add input=”{HTTP_HOST}” pattern=”peterviola.com” />
  </conditions>
 <action type=”Redirect” url=”http://www.peterviola.com/{R:0}” />
</rule>
</rules>
<rewrite>

This works really well and it is a completely seamless experience for your web site visitors.  Here is how the rule looks in the IIS Manager gui.

IIS 7 Url Rewrite HTTP to HTTPS

Probably the 2nd most common use of Url Rewrite is for sites that have SSL certificates installed and need to seamlessly redirect page requests using the certificate for either the entire site or a particular folder. Here is the Url Rewrite rule for redirecting requests on the entire site. You simply detect if the request is not secure and then redirect to the secure channel:

<rewrite>
<rules>
<rule name="HTTP Redirect to HTTPS" enabled="true" stopProcessing="true">
<match url="(.*)" ignoreCase="false" />
<conditions>
<add input="{HTTPS}" pattern="off" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
</rule>
</rules>
</rewrite>

IIS 7 Url Rewrite HTTP to HTTPS on Subfolder

The example above is great but running your entire site in HTTPS will have a performance impact so you don’t need to do it unless there is a specific business requirement for it. So then we need a rule to redirect requests to HTTPS for just one folder. In this example we’ll use a folder called “/secure”. In this instance we use the same rule as above however now we only want page requests for the “secure” folder. This is done by modifying the “match url” element.

<rewrite>
<rules>
<rule name="HTTPS on subfolder" enabled="true">
<match url="(^secure/.*)" ignoreCase="false" />
<conditions>
<add input="{HTTPS}" pattern="off" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
</rule>
<rules>
<rewrite>

We’ve covered 3 of the most common uses of IIS 7 Url Rewrite but if you notice the rules above are really for redirecting and not url rewriting. We’ll cover more examples on rewriting in an upcoming post.

Share and Enjoy

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS