When you install IIS, it automatically creates a Default Web Site under “C:\inetpub\wwwroot“. While convenient for quick testing and administrative tools like “phpinfo()” or “phpMyAdmin“, it also becomes a potential security risk if left accessible from your network.
By default, this site listens on all interfaces and allows anonymous access — meaning anyone on the same LAN could discover it through port scans or misconfigured DNS.
🛡️ Why Lock Down the Default Site
The Default Web Site should never serve public content. Instead, it’s best used as a local-only admin zone where you can securely run utilities, test PHP configurations, or perform maintenance.
Locking it to localhost ensures:
- 🔒 No network exposure: Only accessible from the server itself (via RDP).
- 🧠 Reduced attack surface: phpMyAdmin, phpinfo, and other tools aren’t reachable externally.
- 🧰 Safer administration: You can manage your IIS, PHP, and database environment locally without opening ports or enabling FTP.
- 🧩 Cleaner site separation: Production sites can stay public-facing, while your admin tools live in a private, isolated zone.
By restricting the Default Web Site to 127.0.0.1 and enforcing HTTPS, you’re applying the principle of least privilege — giving access only to what’s absolutely necessary.
🔧 Recommended Prerequisite Posts
Requesting and Signing an IIS SSL Certificate with an Ubuntu Certificate Authority
Quick Reference – Certificate Request Details
When requesting a certificate for IIS, collect the following details first (see Requesting and Signing an IIS SSL Certificate with an Ubuntu Certificate Authority for full instructions):
| Field | Example | Purpose |
|---|---|---|
| Common Name (CN) | srv2.bugbounty.lab | Primary DNS name of the IIS server. |
| Subject Alternative Names (SAN) | FQDN, localhost, 127.0.0.1, LAN IP | Defines all valid hostnames and IPs used to access the site. |
| Organization (O) | BugBounty Lab | Optional metadata for internal CA records. |
| Organizational Unit (OU) | IT | Optional field for internal use. |
| Country (C) | AU | Optional field for CA identification. |
Follow the steps and prerequisites outlined below to create, sign, and apply your SSL certificate. When configuring the SAN (Subject Alternative Name) file, update it to match your environment.
In this example, the following entries were used:
[alt_names] DNS.1 = srv2.bugbounty.lab DNS.2 = localhost IP.1 = 127.0.0.1 IP.2 = 10.10.20.22
Finish creating, signing, and applying your SSL certificate before continuing with the hardening steps.
Testing the Current Configuration
To verify the configuration, test the connection from another machine. In this example, we’ll use a Kali Linux system to confirm access. In an earlier post, we installed PHP and created a phpinfo.php file in the web root.
From the Kali machine, open a browser and navigate to:
http://10.10.20.22/phpinfo.php
⚠️ Why Viewing phpinfo() is a Security Risk
The phpinfo() page exposes detailed configuration data about your web server and PHP environment — information that attackers can use for reconnaissance and targeted exploitation.
Even if hosted internally, leaving this page accessible increases risk because it reveals:
- 🔍 PHP version and extensions, which can be matched to known vulnerabilities.
- 🔑 Loaded modules, file paths, and environment variables, including usernames and directory structures.
- 🧱 Server details, such as OS version, web server software, and document root locations.
- 📦 Configuration options like upload directories, session paths, and include locations that can be abused for file inclusion or privilege escalation.
For these reasons, the Default Web Site should be restricted to localhost-only access once initial testing and configuration are complete.
Tools such as phpinfo(), phpMyAdmin, web-based stats dashboards, or other administrative utilities can reveal sensitive system details that attackers can exploit — even inside an internal network.
If these tools are required for diagnostics or management, they should only be accessed through a secured RDP session or a temporary local testing environment, never over the network.
Testing Open Ports
Before making any configuration changes, it’s important to think like a security tester — verify, don’t assume. I always start by running an Nmap scan against the server to identify which ports are open and confirm what services are exposed.
This helps ensure that our configuration changes don’t accidentally create new openings or weaken the existing security posture.
CMD: sudo nmap 10.10.20.22
Output:
┌──(zeroscorpion㉿kali)-[~]
└─$ sudo nmap 10.10.20.22
[sudo] password for zeroscorpion:
Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-12 16:14 AEDT
Nmap scan report for 10.10.20.22
Host is up (0.00084s latency).
Not shown: 996 filtered tcp ports (no-response)
PORT STATE SERVICE
80/tcp open http
443/tcp open https
3389/tcp open ms-wbt-server
5985/tcp open wsman
MAC Address: 56:51:9B:EA:3D:AC (Unknown)
The primary ports of interest are port 80 (HTTP) and port 443 (HTTPS). We confirmed that port 80 is open by accessing the test page at: http://10.10.20.22/phpinfo.php
Port 443 was also verified as open earlier when we created the secure IIS baseline site during the initial setup process.
🧩 Add HTTPS Binding for Local Access Only
Open “IIS Manager“, expand “Sites“, and select “Default Web Site“. In the Actions panel on the right, click “Bindings“. to view and edit the site’s connection settings.
Click “Add“.
Open IIS Manager, expand Sites, and select Default Web Site.
In the Actions panel, click Bindings…, then choose Add and configure the following settings:
| Setting | Value | Description |
|---|---|---|
| Type | https | Ensures encrypted connections using SSL/TLS. |
| IP address | 127.0.0.1 | Restricts access to the local system only. |
| Port | 443 | Standard HTTPS port. |
| Host name | localhost | Matches the SAN entry in your certificate. |
| Require Server Name Indication (SNI) | ✔️ Checked | Recommended when hosting multiple SSL sites. |
| Disable Legacy TLS | ✔️ Checked | Blocks insecure TLS versions (1.0 and 1.1). |
| Disable QUIC | ✔️ Checked | Optional; QUIC is not required for internal administration. |
| SSL certificate | LocalHost | Select your trusted internal certificate issued by your CA. |
We also need to create a binding to cover ipv6 connections also
| Setting | Value | Description |
|---|---|---|
| Type | https | Ensures encrypted connections using SSL/TLS. |
| IP address | [::1] | Restricts access to the local system only. |
| Port | 443 | Standard HTTPS port. |
| Host name | localhost | Matches the SAN entry in your certificate. |
| Require Server Name Indication (SNI) | ✔️ Checked | Recommended when hosting multiple SSL sites. |
| Disable Legacy TLS | ✔️ Checked | Blocks insecure TLS versions (1.0 and 1.1). |
| Disable QUIC | ✔️ Checked | Optional; QUIC is not required for internal administration. |
| SSL certificate | LocalHost | Select your trusted internal certificate issued by your CA. |
Result: The Default Web Site is now accessible only via https://localhost, ensuring that administrative tools such as phpMyAdmin or phpinfo remain restricted to RDP or local sessions and are never exposed over the network.
🧩 Removing the HTTP Binding
The final step is to remove the port 80 (HTTP) binding. Since we only want IIS to communicate securely over HTTPS (port 443), this prevents any unencrypted connections.
To do this, open the Site Bindings window, select the HTTP binding, and click Remove. This ensures the Default Web Site is accessible only via HTTPS, eliminating any risk of insecure traffic.
We test again with NMAP
CMD: sudo nmap 10.10.20.22
Output:
┌──(zeroscorpion㉿kali)-[~] └─$ sudo nmap 10.10.20.22 [sudo] password for zeroscorpion: Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-12 16:55 AEDT Nmap scan report for 10.10.20.22 Host is up (0.00099s latency). Not shown: 997 filtered tcp ports (no-response) PORT STATE SERVICE 443/tcp open https 3389/tcp open ms-wbt-server 5985/tcp open wsman MAC Address: 56:51:9B:EA:3D:AC (Unknown)
Results:
We can now confirm that only port 443 (HTTPS) is open, and port 80 (HTTP) has been successfully closed. IIS is now accepting secure connections only. When attempting to access the site externally via https://10.10.20.22/phpinfo.php the connection fails — confirming that remote access is blocked and the potential vulnerability has been mitigated.
Summary
At first glance, leaving the Default Web Site accessible may seem harmless — especially in an internal or test environment. However, small oversights like this can expose powerful administrative tools such as phpinfo(), phpMyAdmin, or server status pages to anyone on the network.
These pages reveal detailed system information, configuration data, and software versions that can be used in targeted attacks.
By restricting the Default Web Site to localhost-only access and enforcing HTTPS, we’ve effectively removed another potential attack surface.Hardening isn’t about fixing only the obvious problems — it’s about closing every unnecessary door, no matter how small.
Each eliminated risk strengthens your overall security posture and keeps your IIS environment resilient against compromise.