Share via

Microsoft Security Best Practices to Protect Internet Facing Web Servers

  • Article

Nowadays, internet facing web servers are exposed to high security risks. We quite commonly see web servers being hacked (eg: malicious code being injected in website content), and then clients that are browsing the website are most likely to be transparently compromised (aka drive-by download). And there is also the denial of service risk, the information leakage risk, etc. just to name a few of them.

Therefore, we would like here to precise things regarding web server security best practices.

Please keep in mind that any security filtering system has got to be thoroughly tested, on a regular basis, with business app/site to be protected, to avoid a potential denial of service condition (legitimate requests being caught by mistake).

To mitigate the risks for your internet facing servers, it is really important to consider the following steps and best practices:

Network flow

Identify the network flow, in terms of requests: if you know the regular network flow the server is supposed to receive and send, then you can allow and check (content/requests inspection) them, while other traffic/flow would be denied by default (by Firewall). This is a network isolation measure, that will reduce the risk of a malware spread (or a successful intrusion getting deeper into the production network).

Network

DMZ

Make sure your DMZ has no possibility to directly access your LAN with "source to any" or "source to many"-like rule (firewall/routers rules to be double-checked).

Make sure there is no way to directly request your web server, bypassing security filtering layers. There should be at least a 3-layers filter for your web server:

  • Protocols and sources accepted: firewall (and routers).
  • Dynamic network traffic inspection: NIPS (Network Intrusion Protection System) that will detect/block malicious network requests. You might want to have a look at the MAPP to find a Microsoft partner (www.microsoft.com/security/mapp/ ). Please also keep in mind that NIDS will only aim to detect, not block, the malicious traffic (contrary to NIPS), but in the other hand they will not create any denial of service risk for business flows.
  • Application-oriented security: WAF (Web Application Firewall), just next to the web app/site, that will allow to harden the requests control, and tighten the filter to match the specificities of the web application. ModSecurity for IIS7 (see: http://www.modsecurity.org/)  is an example of a tool that can be used for robust audit logging of HTTP(S) transactions and virtual patching of identified vulnerabilities.  Along with the bundled OWASP ModSecurity Core Rule Set (CRS), it offers essential protections against application layer attacks and information leakages.

Network isolation

Make sure that clients can't directly send requests to your server (from a TCP point of view), that could facilitate attacks otherwise. Thus ensure network isolation, DMZ-minded, by deploying a reverse proxy as a front-end of the web server. This will allow to more easily manage the network flow that can legitimately be sent to the server (including other needs like load balancing). Forefront UAG could be an example of such a solution, or any other one from the MAPP program. Note that some reverse proxies may offer advanced security features.

ASP.Net

Code injection

Follow security best practices for ASP.Net code, to protect against code injection: http://msdn.microsoft.com/en-us/magazine/hh580736.aspx  and SQL injection: http://msdn.microsoft.com/en-us/library/ms161953(SQL.105).aspx . 

SDL

From a more global point of view, please refer to SDL: http://msdn.microsoft.com/en-us/security/aa570401.aspx . Audit the hosted code on a regular basis.

Encryption

Harden cyphered network communications as much as possible, taking into account the available implementations of SSL/TLS on the Windows systems you are running: http://blogs.msdn.com/b/benjaminperkins/archive/2011/10/07/secure-channel-compatibility-support-with-ssl-and-tls.aspx . By default, our recommendation is TLS 1.1/1.2. Please keep in mind this has to be enabled on both client and server side.

Domain isolation

Make sure that the machines within the DMZ are not joined to the regular production domain. AD isolation is at forest layer, therefore it is highly recommended not to have the production AD in DMZ. Please either use another forest, or deploy AD Lightweight Directory Services. 

Application listing

Implement white/blacklisting of applications, through AppLocker for example: http://technet.microsoft.com/en-us/library/ee791890(v=ws.10).aspx

Chain of evidence

Make sure you have got all the relevant (and required?) traceability chain: this meaning possible correlation between firewall's, reverse-proxy's, and web server's logs. Please make attention not to only enable "errors" logging, for instance in IIS logs. Last, please consider archiving the logs.

Backup & restore

Create a back-up of web server data, on a regular basis.

Create images of Windows systems, in an integer state, on a regular basis (at least, at deployment time). This may be helpful in case of a security incident, both to return to production mode as quick as possible, and also to investigate.

Audit & monitoring

Audit your equipements: firewall rules, NIPS rules, WAF rules, reverse-proxy settings, on a regular basis.

Application layer

Follow security best practices for application layer products, database layer ones, and web server layer.

But there are also other security best practices that we do recommend you to consider, even for this web server scenario. Please refer to this article: http://social.technet.microsoft.com/wiki/contents/articles/12432.general-security-advice-and-best-practices.aspx 

We hope this helps.