Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When Jeff and the StackOverflow team were interviewed on Hanselminutes last fall, Scott was critical of some of the decisions that were made with respect to securing the StackOverflow servers.

My question is, what is the recommended approach to securing a website? Assuming I'm developing an ASP.Net application with a SQL Server database on a separate physical machine, what steps do I need to take to secure my environment from attacks?


locked by HopelessN00b Dec 5 '14 at 4:32

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as not constructive by Joel Spolsky Apr 30 '09 at 18:35

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Some things that come to mind:

  • Web server in DMZ behind hardware firewall
  • SQL Server in separate DMZ/private network separated from Web server by hardware firewall
  • Uninstall/disable all unnecessary services on web server.
  • Web server not on a domain.
  • Minimize local accounts on web server.
  • use URLScan (even if on IIS 6.0) because of web server fingerprinting
  • Use IPSEC policy on web server to block all traffic inbound/bound to SQL Server to only ports that are necessary.
  • Use a non-privileged SQL Server login with minimal rights (whatever it needs to access the database for the application) as the login to connect back to SQL Server.
  • Disable default user accounts. Create new accounts with non-standard names. Use those to run services, etc.

Not the answer you're looking for? Browse other questions tagged or ask your own question.