I'm having problems with simultanous brute force attempts on my Windows Server 2008 R2 and the MS-SQL Server which is on it.

  • I have renamed the Windows Administrator account (Administrator)
  • I have renamed and disabled the SQL Server account (sa)
  • I have installed Windows Security Essentials to serve as AntiVirus

I have been adviced to lock down the firewall for ALL inbound and outbound connection EXCEPT for the ones that are truely necessary. But i dont know precisely how to do it and which ports that are truely necessary.

I have also been adviced to totally lock down for connecting to the SQL server via SQL authentication and only do it with Windows authentication. But can my ASP Classic application still use the SQL server then?

The server are being used to webhosting, SQL database hosting and mailserver (POP3, SMTP & IMAP). The server has also Parallels PLESK installed, including HORDE Webmail.

I have taken a screenshot of the server's firewall settings ( http://www.oltm.dk/x/settings.jpg ) and exported the firewall inbound-rules ( http://www.oltm.dk/x/inbound.txt ) and outbound-rules ( ww.oltm.dk/x/outbound.txt )

I am brand new to Windows Server 2008 R2, so forgive me, if I am missing something completely obvious :)



I generally agree with locking down everything that isn't necessary. Right now it looks like you have everything open.

ASP classic should still be able to access SQL directly, but you'll need to go into IIS and change the user account it is impersonating and give that account access to whatever info is needed in SQL. I would recommend creating a new account just for this and only giving that account access to the files and components it needs to do its job. I would agree that outside SQL access is generally not a good way to go. I'd also probably do a bit of SQL scripting and make sure that the new user account can't do things like delete or modify the schema. Basically cut down your exposure as much as possible.

It looks like you probably only need 25,110,143,80,443, whatever port your webmail is running under if it isn't IIS integrated and any remote access ports you might need (3389 if you need RDP). Keep in mind that you can allow ports internally and restrict ports externally (hence the three sections in windows firewall).

Do you have a hardware firewall in front of this box? You might consider that as well. In my opinion, I'd rather have another dedicated appliance deal with the traffic load than bog down a SQL/IIS box with bogus access attempts.

| improve this answer | |
  • Hi mike. --- The SQL SA account has been totally disabled and I have created a new user for each new database with access to only that database and of course given it a complex password. How do i script the SQL accounts to disallow them to delete or modify the schemas? --- So i should disable every inbound rule except for 25, 110, 143, 80, 443 and 3389? --- I have already tried to disable the rules 1433 and 1434 but my website can still access the database. Is this because it is internal? :) – Behrens Nov 10 '11 at 11:04
  • if the web and sql are internal, they should only be able to access each other and the firewall shouldn't come into play for the most part. You should only enable the ports you need to work. the ones i named are for web, mail and remote desktop. as far as the schema, for my sql install, the only things that the web servers account can access are stored procs that are setup in such a way to prevent SQl injection attacks and to prevent any changes to the database that aren't part of the web server's needs. – MikeAWood Nov 17 '11 at 3:44
  • I have locked it all down and disabled all ports except for the ones mentioned above. The SQL Port-rule are still enabled but with scoped to my own ip-adress. And now there are no more attempts in the logs :) Thanks for help mate. – Behrens Nov 17 '11 at 11:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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