11-08-2023, 06:43 PM
When it comes to hardening your web server against potential threats, blocking certain HTTP methods can be a straightforward yet effective step to improve your security posture. I’ve been configuring the Request Filtering module on IIS (that’s Internet Information Services for those not as familiar with it) for a while now, and I want to share how I go about blocking methods like TRACE or DELETE. Trust me, it’s not as complicated as it may seem, and I always like to keep things practical and easy to follow.
First off, let’s remember why we care about blocking certain HTTP methods in the first place. Some methods, including TRACE or DELETE, can introduce vulnerabilities that attackers might exploit, such as cross-site tracing or unauthorized deletion of web resources. By blocking these methods, I can reduce the attack surface of my web applications.
So, let’s get started! When I begin the process, I usually fire up IIS Manager. If you haven’t accessed it before, it’s that handy tool where you can manage your websites and applications. You can usually find it in your Windows Administrative Tools or just type “IIS” in the search bar.
Once you’re in IIS Manager, the first thing I recommend is locating the site you want to configure. You’ll see a tree structure on the left side where your sites are listed. Just click on the one where you want to apply the request filtering. You’ll find a bunch of features in the middle pane, and honestly, it can feel a bit overwhelming, but don’t let that stress you out! Just look for the "Request Filtering" option, and give it a click.
Now, here’s where you get to actually block those pesky HTTP methods. The Request Filtering feature opens up to several tabs like “Allowed HTTP Verbs”, “URL”, and “File Name Extensions.” We’re interested in the “HTTP Verbs” tab. It’s primarily where you’ll configure which HTTP methods are allowed and which you want to block. What I typically do is take a look at the default methods listed there first.
You might notice that some of those methods are already allowed. For instance, GET, POST, PUT, and a few others generally hang around on this list. What we want to do is explicitly add the methods we wish to block. So, to do that, look for the “Denied HTTP Verbs” section. How I usually approach this is by hitting the “Deny Verb” option, which you can usually find at the top of the screen. This will prompt you to type in the HTTP method you want to block.
So if I want to block TRACE, I just type in “TRACE” and hit OK. It’s surprisingly straightforward! I repeat the process for DELETE, typing that in as well. I appreciate how intuitive this interface is because it feels like I’m just having a conversation with the tool. Once you’ve added those methods, you should see them appear in the Denied HTTP Verbs list.
Now, I often find myself checking to ensure everything’s set up properly. I like to go back and skim through the entire list of Denied HTTP Verbs to confirm that TRACE and DELETE are indeed there. It feels good to look at that list and know I’ve taken an extra step to secure the web application.
After adding the methods to be blocked, I recommend testing to make sure everything works as expected. I usually use a tool like Postman or curl, which lets me manually send requests. It’s a great way to check if the server is blocking those methods as it should. In Postman, you can set the request type to TRACE or DELETE, and if everything’s configured correctly, you should receive a response indicating that the method is not allowed.
Another thing I like to keep in mind is to review the logs. IIS logs can be super helpful in identifying unwanted attempts to use blocked methods, and they provide a clear picture of what’s happening on the server. I recommend checking logs after you block those methods as it helps me understand if someone has been trying to misuse them. Use a text editor or a log viewer to sift through entries after you’ve made your adjustments.
It’s great to see how many people are connecting with their applications and using them for various activities. One time, I noticed a spike in attempts to use blocked methods in the logs, and that clued me in on a possible probe or attack against my server.
It’s not just about blocking methods; it’s also about ways to observe and respond. Having that visibility allows me to adjust configurations or enhance security measures if I ever feel there’s a need.
Also, if you’re looking for a more permanent solution across multiple sites, you might consider using the web.config file. You know, that little XML file that’s often located in the root directory of your web application? I like to keep everything tidy and consistent, so I’ll often add the HTTP verbs I want to deny directly to this file.
You just need to open web.config in a text editor and insert the relevant XML snippet for denying HTTP verbs. It looks something like this:
<configuration>
<system.webServer>
<security>
<requestFiltering>
<deny verb="TRACE" />
<deny verb="DELETE" />
</requestFiltering>
</security>
</system.webServer>
</configuration>
Just make sure you have the right format in place, and save your changes. Once it’s saved, it’s good to go. For me, using web.config feels like programming a stretch of code into my security pipeline. Every time I tweak it, there’s a traceable history of the changes I’ve made, and that just helps me sleep better at night.
After any edits to the web.config or the Request Filtering module, I always recommend restarting the website or the server if needed. It’s like giving the whole system a little nudge to make sure it’s up-to-date with the latest configurations you’ve applied.
So, once you’re done, just keep an eye on everything. As with most security practices, vigilance is key. Things in our digital lives are always changing, and having the ability to adapt is what keeps us effective in our roles. I constantly remind myself and my peers to stay proactive. Block those methods, monitor the logs, adapt as necessary, and you’ll be well on your way to creating a more secure web server environment.
To wrap things up, while blocking HTTP methods like TRACE and DELETE might seem like a small act, it’s all about layering security as you build your applications. This is just one of those practical steps that anyone who’s serious about their server security should implement. Each method you block serves as a protective barrier that makes it harder for attackers to exploit vulnerabilities. And honestly, who doesn’t want to stay one step ahead of potential threats?
I hope you found my post useful. By the way, do you have a good Windows Server backup solution in place? In this post I explain how to back up Windows Server properly.
First off, let’s remember why we care about blocking certain HTTP methods in the first place. Some methods, including TRACE or DELETE, can introduce vulnerabilities that attackers might exploit, such as cross-site tracing or unauthorized deletion of web resources. By blocking these methods, I can reduce the attack surface of my web applications.
So, let’s get started! When I begin the process, I usually fire up IIS Manager. If you haven’t accessed it before, it’s that handy tool where you can manage your websites and applications. You can usually find it in your Windows Administrative Tools or just type “IIS” in the search bar.
Once you’re in IIS Manager, the first thing I recommend is locating the site you want to configure. You’ll see a tree structure on the left side where your sites are listed. Just click on the one where you want to apply the request filtering. You’ll find a bunch of features in the middle pane, and honestly, it can feel a bit overwhelming, but don’t let that stress you out! Just look for the "Request Filtering" option, and give it a click.
Now, here’s where you get to actually block those pesky HTTP methods. The Request Filtering feature opens up to several tabs like “Allowed HTTP Verbs”, “URL”, and “File Name Extensions.” We’re interested in the “HTTP Verbs” tab. It’s primarily where you’ll configure which HTTP methods are allowed and which you want to block. What I typically do is take a look at the default methods listed there first.
You might notice that some of those methods are already allowed. For instance, GET, POST, PUT, and a few others generally hang around on this list. What we want to do is explicitly add the methods we wish to block. So, to do that, look for the “Denied HTTP Verbs” section. How I usually approach this is by hitting the “Deny Verb” option, which you can usually find at the top of the screen. This will prompt you to type in the HTTP method you want to block.
So if I want to block TRACE, I just type in “TRACE” and hit OK. It’s surprisingly straightforward! I repeat the process for DELETE, typing that in as well. I appreciate how intuitive this interface is because it feels like I’m just having a conversation with the tool. Once you’ve added those methods, you should see them appear in the Denied HTTP Verbs list.
Now, I often find myself checking to ensure everything’s set up properly. I like to go back and skim through the entire list of Denied HTTP Verbs to confirm that TRACE and DELETE are indeed there. It feels good to look at that list and know I’ve taken an extra step to secure the web application.
After adding the methods to be blocked, I recommend testing to make sure everything works as expected. I usually use a tool like Postman or curl, which lets me manually send requests. It’s a great way to check if the server is blocking those methods as it should. In Postman, you can set the request type to TRACE or DELETE, and if everything’s configured correctly, you should receive a response indicating that the method is not allowed.
Another thing I like to keep in mind is to review the logs. IIS logs can be super helpful in identifying unwanted attempts to use blocked methods, and they provide a clear picture of what’s happening on the server. I recommend checking logs after you block those methods as it helps me understand if someone has been trying to misuse them. Use a text editor or a log viewer to sift through entries after you’ve made your adjustments.
It’s great to see how many people are connecting with their applications and using them for various activities. One time, I noticed a spike in attempts to use blocked methods in the logs, and that clued me in on a possible probe or attack against my server.
It’s not just about blocking methods; it’s also about ways to observe and respond. Having that visibility allows me to adjust configurations or enhance security measures if I ever feel there’s a need.
Also, if you’re looking for a more permanent solution across multiple sites, you might consider using the web.config file. You know, that little XML file that’s often located in the root directory of your web application? I like to keep everything tidy and consistent, so I’ll often add the HTTP verbs I want to deny directly to this file.
You just need to open web.config in a text editor and insert the relevant XML snippet for denying HTTP verbs. It looks something like this:
<configuration>
<system.webServer>
<security>
<requestFiltering>
<deny verb="TRACE" />
<deny verb="DELETE" />
</requestFiltering>
</security>
</system.webServer>
</configuration>
Just make sure you have the right format in place, and save your changes. Once it’s saved, it’s good to go. For me, using web.config feels like programming a stretch of code into my security pipeline. Every time I tweak it, there’s a traceable history of the changes I’ve made, and that just helps me sleep better at night.
After any edits to the web.config or the Request Filtering module, I always recommend restarting the website or the server if needed. It’s like giving the whole system a little nudge to make sure it’s up-to-date with the latest configurations you’ve applied.
So, once you’re done, just keep an eye on everything. As with most security practices, vigilance is key. Things in our digital lives are always changing, and having the ability to adapt is what keeps us effective in our roles. I constantly remind myself and my peers to stay proactive. Block those methods, monitor the logs, adapt as necessary, and you’ll be well on your way to creating a more secure web server environment.
To wrap things up, while blocking HTTP methods like TRACE and DELETE might seem like a small act, it’s all about layering security as you build your applications. This is just one of those practical steps that anyone who’s serious about their server security should implement. Each method you block serves as a protective barrier that makes it harder for attackers to exploit vulnerabilities. And honestly, who doesn’t want to stay one step ahead of potential threats?
I hope you found my post useful. By the way, do you have a good Windows Server backup solution in place? In this post I explain how to back up Windows Server properly.
