Step-by-Step Secure IIS Baseline Setup in an Active Directory Environment

Internet Information Services (IIS) is Microsoft’s web server for hosting websites, applications, and APIs on Windows. It’s built into Windows Server, tightly integrates with Active Directory, and supports technologies like ASP.NET, PHP, and HTTPS. IIS is widely used in enterprise environments for secure, scalable web hosting.

Install IIS

Open Add Roles and Features Wizard and keep defaults and click “Next“.

Select “Role-based or feature-based installation” then “Next” till you get to the “Select server role” section.

 

Select “Web Server (IIS)” and then “Add Features” with the popup then click “Next“.

 

Leave defaults and click “Next” till you get to “Select role services”.

Select Install Options

Common HTTP Features

✅ Safe / Recommended

  • Default Document
    Lets IIS serve index.html, default.aspx, index.php, etc., when no file is specified.
    🔒 Safe, standard behavior. Needed for most sites.
  • HTTP Errors
    Controls how IIS handles errors (e.g., 404, 500).
    🔒 Safe, and important for customizing error pages to avoid exposing version info.
  • Static Content
    Required to serve images, CSS, JavaScript, and HTML.
    🔒 Essential for almost every site.

⚠️ Risky / Disable Unless Needed

  • Directory Browsing
    Shows file listings if there’s no default document.
    ⚠️ Major information disclosure risk (attackers can see file names, structure, configs).
    ❌ Leave unchecked unless it’s for a controlled lab/demo.
  • HTTP Redirection
    Redirect requests to another URL.
    🔒 Safe, but only enable if you specifically need redirects (e.g., force HTTPS, move old pages). Otherwise, leave off.
  • WebDAV Publishing
    Lets clients upload/edit files directly via HTTP.
    ⚠️ Huge attack surface (brute force, misconfigurations, upload vulnerabilities).
    ❌ Always disable unless you 100% need WebDAV.

Health and Diagnostics

✅ Safe / Recommended

  • HTTP Logging
    Logs all HTTP requests (date, time, IP, URL, status codes).
    🔒 Essential for auditing, troubleshooting, and detecting attacks.
    ✅ Always enable.

⚠️ Optional / Only Enable if Needed

  • Custom Logging
    Lets you create non-standard log formats.
    ⚠️ Rarely needed, can increase complexity and expose sensitive data if misconfigured.
    ❌ Leave off unless you have a specific compliance or SIEM requirement.
  • Logging Tools
    Adds GUI tools for analyzing logs.
    🔒 Safe, but not required for security. Install only if you prefer to manage logs through IIS Manager instead of PowerShell/Event Viewer.
  • Request Monitor
    Tracks worker process requests in real time.
    ⚠️ Useful for troubleshooting “hung” requests, but increases resource usage.
    ✅ Good for dev/test, optional for production unless you actively monitor app health.
  • Tracing
    Enables detailed request tracing (IIS Failed Request Tracing / FREB).
    ⚠️ Can log sensitive info (headers, query strings) and generate large files.
    ❌ Keep off in production, enable only when debugging.

🚫 Not Recommended for Secure Baseline

  • ODBC Logging
    Logs IIS activity directly to a database.
    ⚠️ Adds complexity, database attack surface, and performance overhead.
    ❌ Avoid unless you have a very specific requirement.

Performance

✅ Safe / Recommended

  • Static Content Compression
    Compresses files like CSS, JS, and images before sending them to clients.
    🔒 Safe, improves performance, reduces bandwidth.
    ✅ Recommended for production.

⚠️ Optional / Use With Care

  • Dynamic Content Compression
    Compresses pages generated on the fly (e.g., PHP, ASP.NET).

⚠️ Benefits performance, but:

  • Uses more CPU (may hurt server under heavy load).
  • Historically linked to BREACH/CRIME attacks when used with TLS + secrets in responses (e.g., CSRF tokens in compressed HTML).
  • Not needed if most dynamic content is already optimized/cached.
    ❌ Disable for a strict secure baseline, enable only if tested safe in your environment.

Security

✅ Safe / Recommended

  • Request Filtering
    Blocks dangerous requests (e.g., ../, large payloads, certain verbs).
    🔒 Essential hardening. Always enable.

⚠️ Enable Only If Needed

  • Windows Authentication
    Uses Kerberos/NTLM and integrates with Active Directory.
    ✅ Enable if your site/app requires domain logins.
    🔒 In an AD environment, prefer Kerberos-only if possible.
    ❌ Leave off if the app uses forms-based or another auth method.
  • IP and Domain Restrictions
    Restricts access by client IP ranges.
    ✅ Useful for admin panels, internal apps, or phpMyAdmin lockdown.
    ❌ Don’t enable globally unless you plan to configure rules.
  • URL Authorization
    Lets you define allow/deny rules for paths.
    ✅ Powerful for fine-grained access control.
    ❌ Not needed if your app already handles authorization.
  • Centralized SSL Certificate Support
    Useful if managing many certs across servers with shared storage.
    ✅ Only enable in large farms.
    ❌ Not needed on a single standalone server.
  • Client Certificate Mapping Authentication / IIS Client Certificate Mapping
    Maps client TLS certs to Windows accounts.
    ✅ Needed only for environments requiring mutual TLS.
    ❌ Overkill for most setups.

🚫 Not Recommended (for secure baseline)

  • Basic Authentication
    Sends credentials in Base64 (cleartext unless HTTPS enforced).
    ⚠️ Weak; avoid in AD environments.
  • Digest Authentication
    Legacy, rarely used.
    ❌ Disable — stick with Windows Authentication instead.

Application Development
(For this setup, no modules will be enabled. These features will be covered in a future post.)

✅ Needed Only If Your Apps Require It

  • .NET Extensibility 3.5 / 4.8
    Required for ASP.NET apps targeting those frameworks.
    🔒 Safe if patched, but avoid installing unless you actually run .NET sites.
  • ASP.NET 3.5 / 4.8
    Lets IIS host ASP.NET applications.
    ✅ Enable only if hosting .NET web apps.
    ❌ Leave off if running PHP/MySQL-only apps.
  • Application Initialization
    Pre-loads applications so they’re warm before first request.
    ✅ Performance feature; not a security risk. Only needed for .NET/ASP apps.
  • WebSocket Protocol
    Needed for apps that use real-time communication (chat, SignalR, etc.).
    ⚠️ Expands attack surface. Only install if explicitly required.
  • CGI (for FastCGI/PHP)
    IIS installs FastCGI under the CGI feature.
    ✅ Required if you want to run PHP on IIS (FastCGI only — not legacy CGI).
    ❌ If you’re not running PHP, leave it off.

🚫 Legacy / Risky – Avoid Unless Absolutely Required

  • ASP (Classic ASP)
    Very old tech, high risk of vulnerabilities.
    ❌ Avoid in modern environments.
  • ISAPI Extensions / ISAPI Filters
    Legacy extension model (pre-.NET).
    ⚠️ Can be abused for privilege escalation / DLL injection.
    ❌ Don’t enable unless required for a legacy vendor app.
  • Server Side Includes (SSI)
    Old feature allowing inline includes in HTML.
    ⚠️ Prone to injection attacks.
    ❌ Avoid in secure setups.

FTP Server
(Not enabled in this setup. If FTP is ever required, configure it with SSL certificates (FTPS only) and disable unencrypted FTP to protect credentials and data.)

🚫 Baseline (Recommended)

For a secure web server setup, do not install FTP unless you absolutely need it. It increases attack surface and is a common target.

⚙️ If FTP is Required

If at some point you do enable FTP:

  • FTP Service
    Core FTP publishing service. Needed for FTP access.
    ⚠️ Should only be enabled if your environment specifically requires FTP.
  • FTP Extensibility
    Adds advanced functionality (custom providers, event handling).
    ✅ Only enable if your workflows depend on it.

🔒 Security Best Practices (If FTP is Enabled)

  1. Enforce SSL/TLS (FTPS)
  • Configure FTP to require SSL certificates for authentication and data transfer.
  • This prevents credentials from being sent in cleartext.

2. Disable Plain FTP

  • Never allow unencrypted FTP (port 21 without TLS).

3. Use Windows Authentication or Strong Accounts

  • Disable anonymous FTP unless absolutely required.
  • Lock accounts down to specific directories.

4. Firewall Rules

  • Restrict FTP access to trusted IP ranges.
  • Avoid exposing it publicly if possible.

Management Tools

✅ Safe / Recommended

  • IIS Management Console
    The standard GUI for managing IIS.
    ✅ Recommended if you’ll administer via the Windows interface.
    🔒 No security risk by itself.

⚠️ Optional / Enable Only If Needed

  • IIS Management Scripts and Tools
    Adds command-line tools and scripting (like appcmd.exe).
    ✅ Good for automation and scripting deployments.
    ❌ Not required for basic setups.
  • Management Service
    Allows remote IIS management over HTTPS with IIS Manager.
    ⚠️ Expands attack surface (remote access).
    ✅ Enable only if you need to manage IIS remotely, and always require SSL + strong credentials.
    ❌ Leave off if you’ll manage locally or via RDP.

🚫 Legacy / Risky – Avoid

  • IIS 6 Management Compatibility (and sub-features: Metabase, Scripting Tools, WMI)
    These exist for backwards compatibility with old IIS 6 scripts/configs.
    ⚠️ Legacy, adds unnecessary attack surface, rarely needed in modern environments.
    ❌ Disable unless running old vendor apps that depend on them.

✅ Secure IIS Base Install – Key Points

  • Common HTTP Features → Enable Default Document, HTTP Errors, Static Content; disable Directory Browsing, WebDAV.
  • Health & Diagnostics → Enable HTTP Logging; leave others off unless troubleshooting.
  • Performance → Enable Static Content Compression; disable Dynamic Compression.
  • Security → Enable Request Filtering; use Windows Authentication if needed; disable Basic/Digest/Auth mapping.
  • Application Development → Skip for now (only add CGI/FastCGI later if PHP is required).
  • FTP Server → Not installed; if ever enabled, enforce FTPS only.
  • Management Tools → Enable IIS Management Console; disable legacy IIS 6 features and remote management unless required.

Then click “Install“.

Now you will have access to the “Internet Information Services (IIS) Manager“.

🔍 Port Scanning New IIS Installations

Whenever you bring a new IIS server online, part of a secure baseline should include a post-installation port scan. Even if you’ve carefully selected role services, Windows can sometimes expose additional services or leave defaults enabled.

Using a tool like Nmap, you can quickly confirm:

  • Which ports are open (e.g., 80/443 for web traffic).
  • Whether unnecessary services (FTP, WebDAV, RPC, etc.) are exposed.
  • If version banners are leaking service details.

Scan results from Kali Linux

┌──(zeroscorpion㉿kali)-[~]
└─$ sudo nmap 10.10.20.22
Starting Nmap 7.95 ( https://nmap.org ) at 2025-09-28 12:27 AEST
Nmap scan report for 10.10.20.22
Host is up (0.00086s latency).
Not shown: 997 filtered tcp ports (no-response)
PORT STATE SERVICE
80/tcp open http
3389/tcp open ms-wbt-server
5985/tcp open wsman
MAC Address: 56:51:9B:EA:3D:AC (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 5.07 seconds

✅ Why It Matters

  • Attack Surface Reduction → Detects unintended services before attackers do.
  • Change Validation → Confirms your secure IIS baseline only exposes the ports you expect.
  • Ongoing Monitoring → Regular scans help catch configuration drift over time.

👉 In short: Every new setup (and major change) should be validated with an Nmap scan to make sure only the intended services are listening.

Scan Results

Ok so we can see that port 80 has been opened after the install

🌐 Port 80 (HTTP)

When IIS is installed, port 80 (HTTP) is usually opened by default.

Why it’s insecure:

  • Traffic over port 80 is cleartext → usernames, passwords, and session cookies can be sniffed.
  • Vulnerable to man-in-the-middle (MITM) attacks inside corporate networks.
  • Attackers can downgrade users from HTTPS → HTTP if it’s left open (SSL stripping).

Why it’s important to disable, even internally

  • Internal networks are not automatically “safe” — compromised machines or insider threats can still capture unencrypted traffic.
  • By disabling port 80 and enforcing port 443 (HTTPS) only, you guarantee all communications are encrypted.
  • Helps enforce modern security standards (HSTS, secure cookies, compliance requirements).

Best practice

  • Redirect HTTP → HTTPS if you need user-friendly URLs, but never leave port 80 serving live content.
  • Ideally, block port 80 entirely at the firewall if your apps don’t require redirection.

👉 Short version for your notes:
“Port 80 exposes unencrypted HTTP. Even on internal networks, it should be disabled or redirected to HTTPS, with 443 as the only allowed web port.”

If we browse to the server’s IP address from our Kali machine, we’re presented with the default IIS landing page.

🚫 Default Web Site

When IIS is installed, it creates a Default Web Site bound to port 80 (and sometimes 443).

Why it should be disabled

  • Known target → Attackers are aware of its default path and may probe it for misconfigurations.
  • Unnecessary exposure → If you’re not using it, it’s just another entry point that doesn’t serve your application.
  • Certificate conflicts → The default site can interfere with SSL bindings when multiple sites share the same IP/port.
  • Configuration clarity → Keeps IIS clean so only intended sites are active, reducing confusion during management.

Best practice

  • Stop or remove the Default Web Site.
  • Replace with your own sites bound explicitly to hostnames/IPs.
  • If you want a catch-all, create a custom “blocked/landing” site instead of leaving the default.

Disabling the Default Site

For now, we’ll stop the Default Site. In later posts, we’ll demonstrate how to re-enable it for specific installs, but restrict access to the server itself and secure it with an SSL certificate.

Open “IIS Manager” expand Sites then select the “Default Web Site” and on the right under “Manage Website” select “Stop” and this will stop the default site.

✅ Confirming the Default Site is Disabled

From the Kali machine, run another Nmap scan — this time you’ll see that port 80 is no longer active.

┌──(zeroscorpion㉿kali)-[~]
└─$ sudo nmap 10.10.20.22
Starting Nmap 7.95 ( https://nmap.org ) at 2025-09-28 12:53 AEST
Nmap scan report for 10.10.20.22
Host is up (0.00064s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT STATE SERVICE
3389/tcp open ms-wbt-server
5985/tcp open wsman
MAC Address: 56:51:9B:EA:3D:AC (Unknown)

Visiting the site again from our Kali Machine we can see the site is now down.

📝 Summary

In this baseline IIS setup, we focused on building a minimal and secure foundation:

  • Installed only essential IIS features (Static Content, Default Document, HTTP Errors, HTTP Logging, Static Compression, Request Filtering, IIS Management Console).
  • Left out risky or legacy modules such as Directory Browsing, WebDAV, Dynamic Compression, Basic/Digest Authentication, Classic ASP, ISAPI, and FTP.
  • Stopped the Default Web Site to reduce attack surface and verified with Nmap scans that port 80 was no longer exposed.
  • Emphasized that even in internal networks, unencrypted HTTP (port 80) is insecure and all traffic should be enforced over HTTPS (443).
  • Noted that Application Development modules (e.g., ASP.NET, PHP/FastCGI) will be covered in later posts, enabling them only when required and hardening them properly.

This leaves us with a clean, hardened IIS installation that can serve as a secure baseline for future web applications.