Episode 30 — Windows Services: RDP, SMB, IIS Hardening
In Episode Thirty, titled “Windows Services: R D P, S M B, I I S Hardening,” we focus on the services most often exposed, misunderstood, and targeted in enterprise environments. Remote access, file sharing, and web hosting are indispensable, yet each expands the attack surface in distinct ways that require deliberate controls rather than defaults. Hardening here is not about clever tricks; it is about trimming unnecessary features, applying strong authentication and encryption, and watching for drift so posture stays aligned with intent. When these services are reduced to well-defined, well-audited roles, they become predictable components instead of gateways for lateral movement. The throughline is simple: expose only what you must, bind every exposure to identity, and record everything meaningful that happens.
Remote Desktop remains a workhorse, so the first guardrail is to make sure only known users can approach it in the first place. Network Level Authentication—first mentioned here as N L A—forces authentication before a full desktop session is created, shrinking the opportunity for resource exhaustion and credential prompts on compromised hosts. Restricted groups complete the picture by ensuring that only designated administrators can log on via Remote Desktop, with those memberships managed centrally rather than ad hoc on each machine. Combining N L A with explicit logon rights for a small set of groups removes ambiguity about who is allowed to start a session. The result is a clear contract: no anonymous pre-session, and no surprise accounts with remote logon privileges.
Encryption settings decide whether Remote Desktop can be observed or modified in transit, and Transport Layer Security—introduced here as T L S—should be mandatory. Servers ought to present modern certificates that match their names, while clients are configured to require T L S with strong cipher suites and to reject fallback to weak protocols. Older security layers that permit deprecated cryptography or self-signed confusion should be disabled so there is no silent downgrade path. Certificate validation errors must be treated as genuine risk rather than dismissed as “expected” in test environments. When session negotiation starts from a hardened baseline, impersonation and interception attempts have far less room to maneuver.
For organizations that need Internet-facing Remote Desktop, channeling access through Remote Desktop Gateway—first referenced as R D Gateway—with multi-factor authentication, or M F A, dramatically reduces exposure. The gateway centralizes policy, records who connected and for how long, and offers the right place to enforce device posture checks or conditional access rules. Tying the gateway to strong identity means a password alone is never enough to open the door, and integrating auditing ensures session starts, stops, and resource mappings are captured for later review. Administrators should prefer per-user or per-group resource authorization rather than broad network tunnels that grant more reach than necessary. This pattern keeps the edge thin and the oversight thick.
Hardening cannot stop at authentication; the listening surface itself must be narrowed until only intended paths remain. Limit the number of listeners by disabling unused protocols, binding services explicitly to required interfaces, and configuring firewall scopes so remote access is reachable only from known networks or jump hosts. Egress controls are just as important, preventing exposed servers from calling out to arbitrary destinations during compromise attempts. Host firewalls, upstream firewalls, and microsegmentation reinforce one another when rules match the documented purpose of each machine. In the end, trust is shaped by where packets are allowed to originate and where they are permitted to go.
File sharing over Server Message Block—first introduced as S M B—demands basic hygiene before anything else. Version one must be disabled permanently across clients and servers, because its weaknesses are well known and widely exploited. Mixed environments should be mapped so that legacy dependencies are surfaced and replaced rather than tolerated indefinitely. Decommissioning S M B v1 is not merely an upgrade task; it is a prerequisite for credible containment of wormable attacks. Once the minimum protocol level is enforced, the conversation can move on to integrity and confidentiality controls that modern S M B versions support.
Strong S M B deployments insist on signing to prevent tampering and, where appropriate, enable S M B encryption to protect data in motion beyond the local network. Enforcement should be set so that unsigned connections are refused rather than accepted with a warning, because optional integrity is the same as no integrity at all. Administrators need to understand the performance implications and scope encryption to shares that carry sensitive data or traverse untrusted links. The guiding principle is that file operations represent business records and deserve protection equal to their importance. When integrity and encryption are normalized, attackers lose easy leverage within common workflows.
Share design often reveals whether least privilege is a slogan or a practice. Avoid granting access to “Everyone,” and prefer deny-by-default models where groups are added intentionally for read, modify, or full control as justified by the data’s purpose. Separate share permissions from NT F S permissions so that both must agree before a risky action can occur, and ensure ownership is assigned to accountable teams who review membership changes regularly. Administrative shares should remain restricted to support functions and monitored for unusual access patterns. Careful mapping between business roles and group memberships keeps the file layer aligned with real responsibilities.
Web workloads ride on Internet Information Services—first mentioned as I I S—and the safest starting posture is a minimal one. Remove modules and handlers that are not required by the application so the server does not parse content types or routes it will never legitimately handle. Disable sample sites, help pages, and diagnostics in production that reveal version details or configuration hints. Keep administrative interfaces off public interfaces and limit them to management networks and jump hosts. Minimalism is not about austerity; it is about reducing the code that an adversary can convince the server to execute.
Transport security for I I S should be explicit and current, beginning with H T T P S bindings that use modern protocols and ciphers and ending with strict browser behavior. Enable H S T S—first referenced as H S T S—to instruct clients to use encrypted connections on return visits, and maintain a certificate lifecycle that includes automated renewal, clear ownership, and timely revocation when keys are replaced. Hostnames, Subject Alternative Name fields, and chain validation must be correct everywhere to avoid training users to ignore errors. When the certificate story is boring and predictable, the application story can focus on business logic rather than chasing handshake issues.
A robust front door also filters what reaches the application, which is where request filtering and limits prove their worth. Configure allowed verbs, file name extensions, and maximum request sizes so unexpected traffic is discarded early and cheaply. Turn on detailed logging that includes client IP, requested resource, user identity when present, and user-agent strings so investigators can reconstruct events with confidence. Rate limiting at the server or an upstream gateway helps keep brute force and enumeration in check without depending solely on the application to respond gracefully. The goal is a web tier that answers legitimate questions precisely and ignores noise.
Application pool identities often decide whether a minor web exploit becomes a full system compromise. Assign least-privileged, dedicated identities to each pool, avoid running as built-in administrators, and isolate pools so one application cannot read or modify another’s content or secrets. Where possible, use per-site pools and restrict file system rights to only the directories that site needs to touch. Recycling policies should be tuned to balance stability with resource cleanup, and secrets needed by the application should live in a vault rather than in configuration files. Isolation, identity, and secret discipline make exploitation harder and recovery cleaner.
Hardened services still drift without observation, so monitoring baselines for ports, events, and configuration changes closes the loop. Record which listeners should exist, which certificates should be bound, which S M B dialects are allowed, and which I I S modules are present, then alert on deviations from that baseline. Event streams such as Remote Desktop logons, failed S M B authentications, and I I S request anomalies belong in centralized analysis where correlation can reveal early signs of attack. Configuration management systems should enforce desired state and report when they had to correct a machine that wandered. In practice, staying hardened means detecting and reversing entropy before an adversary does.
When all of these controls operate together, exposed Windows services shrink to their essentials without sacrificing function. Remote access becomes identity-anchored and encrypted end-to-end, file sharing honors integrity and least privilege, and web hosting runs only what the application needs with clear boundaries and evidence. Each piece is modest on its own—an authentication mode here, a filter there, a baseline everywhere—but the combined effect is a service layer that resists casual probing and slows determined attacks. That is the definition of good hardening: fewer features, sharper rules, and a posture that changes only on purpose.