Windows Web Server Setup (IIS) & Configuration
Joseph Frost
Aspiring Junior Cyber Security Analyst | CompTIA Security+ Certified | SC-200 Certified | TryHackMe Top 1% | 3D Artist
In this segment, I focus on setting up and securing an Internet Information Services (IIS) Web Server on Windows Server 2022. Going over installation and implementing crucial security measures like HTTPS enforcement and request filtering, I will cover the essentials to safeguard the web portion of digital infrastructure. This part lays the groundwork for advanced topics, including Linux Deployment and Splunk integration in my upcoming articles, emphasising the importance of a robust and secure web server setup.
Setting up the IIS Web Server
Before doing anything, the IP address should be made static once again which I simply changed the IPv4 up by 1 number just I covered previously.
To get the website up and running, the first thing I needed to do was ensure the Internet Information Services (IIS) was installed on my Windows Server 2022, the initial steps are similar to the last windows server. Here’s how I navigated through the installation:
After the Server restarts and is promoted to an IIS web server I just followed the steps I took the same as earlier in ‘Adding a Windows Workstation’ in part 2. To add the server to the domain, in which I applied just a select few of the GPOs to add to the server selection as this isn’t a Domain Controller.
For installing the website which i’ll be later monitoring in Splunk these are the steps I took:
1. Open the IIS manager which can simply be found by a windows search ‘IIS’.
2. In the IIS manager, I right clicked on ‘Sites’ and selected ‘Add Website’. There is a website here by default but I'll remove this and add my own just from a template I got for free online.
3. Enter the site name for my website in the ‘Site name’ Field and pointed it towards a template I got online for free and I left the host name blank as I’ll be configuring the DNS server to point the IP address to a custom defined ‘intranet’:
4. After selecting ok the website should be accessible by simply putting in the web server ip address or 'localhost' which worked for me.
I then added the IP address to my DNS server, meaning any computers or servers configured to the DNS server can access the personally defined intranet, the steps were fairly straightforward.
1. I opened the server manager and selected DNS to then open the DNS manager
2. In the DNS server manager, I navigated to my Active Directory in Forward Lookup Zones, right clicked it and selected ‘New Host (A or AAAA)...’
3. I gave it a name, in my case, simply “Intranet” and added the IP address of the web server.
4. And now the website should be accessible on all configured workstations/web servers that point to the DNS:
Web server hardening
Start by enforcing connection by HTTPS, as this is a local server I will be creating a self signed certificate. While self-signed certificates provide encryption, they are not trusted by clients by default and will result in a browser warning about the certificate’s validity. For production environments , it’s essential to obtain a certificate from a trusted Certificate Authority (CA).
1. To create a certificate this can be done through the IIS manager by selecting the server and in the middle panel selecting ‘Server Certificates’.
2. I then selected ‘Create Self-Signed Certificate’ on the right pane, named it something relevant and chose ‘personal’.
3. Then I selected the website again on the server managed and selected ‘Bindings’ and added a new binding to https, left the host name blank , made sure it went to port 443 as this is for encrypted web traffic and then selected my newly made certificate.
4. To enforce that users access the https version of the website I’ll be using URL Rewrite, which has to be downloaded separately from here:
5. After I installed it using the x64 installer it required a reboot and it was visible on my feature view pane when selecting the websites, which I opened up:
领英推荐
6. Then selected ‘Add Rule(s)...’ in the right panel and selected ‘Blank rule’ under inbound rules and clicked ‘OK’.
7. I gave the rule a name, e.g. “Redirect to HTTPS” and in ‘Match URL’, set ‘Requested URL’ to ‘ Matches the Pattern’ and ‘Using’ to ‘Regular Expressions’. For the pattern, I used (.*) to match all requests.
8. Under conditions I clicked ‘Add’ and set:
And in the action section set:
Putting it all together, https://{HTTP_HOST}/{R:1} is like a formula that says, “Take me to the secure version of the site I requested, and don’t forget the specific page I wanted to see!” It ensures you move from HTTP to HTTPS smoothly, without losing track of where you were going.
And to test this out I initially tried to access the intranet through edge but it didn’t give any indication that it moved me to the https version, likely due to cookies, but I tried on chrome and this did move me over (with a warning of the self signed certificate) And I also tried curl from cmd which also showed the same:
Meaning it’s successfully enforcing https!
HTTP Verbs
Just like OS hardening it's a good practice to reduce the attack surface as much as possible, one of those ways is through request filtering. Commonly only ‘GET’, ‘POST’ and possibly ‘PUT’ or ‘DELETE’ are needed for web applications, and methods such as ‘TRACE, ‘OPTIONS’, ‘CONNECT’, and ‘DEBUG’ which can be exploited in various attacks or used to get information about a web server should be Denied.
Query Strings Restricting Dangerous Query strings can protect a web server from SQL and XSS injections, if an application doesn’t require dynamic query strings for its functionality it would be wise to consider blocking or strictly validating them, but this requires knowledge of what is considered normal for your application. As this is just a template I'll be leaving this step.
Headers
Certain headers can leak sensitive information about your server or be used in attacks; it's less common to block specific headers globally as this depends on the needs of the website. Again As this is a template I'll be leaving this step as it depends on the type of application in use.?
File Extensions
Prevent serving files that your web application does not use. Blocking extensions such as ‘.exe, ‘.bat’, ‘.cs’, ‘.ps1’ can mitigate the risk of serving malicious files or leaking sensitive information.
Paths
Restricting access to sensitive paths that contain administrative functions, sensitive data, or are not intended to be publicly accessible should be restricted, this can be done in the URL section of request filtering.?
OWASP Top Ten
It’s also best to adhere to best practices, such as the OWASP top 10 to understand the type of attacks web applications may be susceptible to and configure the web server accordingly. OWASP provides documentation on securing web applications, including recommendations for input validation which can inform your decisions on what to block. As this is quite expensive and somewhat out of scope of this project I've covered some of the basics most sites set up on IIS can take to reduce the attack surface.
The OWASP top 10 exploits can be accessed from here:
Going further WAF (Web Application Firewall) can be used to protect a web server and come in a few varieties, such as software, hardware and cloud based which can serve as a protective layer between the web server and internet and can aid in protecting against OWASP exploits, to avoid going too far down the rabbit hole i’ll be leaving this out as well.
This marks the end of Part 3 of my 5-part series. The upcoming segment, Part 4: Linux Deployment (Including Splunk) will be going into depth on setting up Splunk in RHEL including the forwarder service and how to push logs from each respective server such as DNS, IIS and Firewall.