Windows server security setup (firewalls, SQL server and other points)

Question

Firstly apologies for this being a non-specific question, I'm not really sure where to look for specifics so this is a general discussion of regular issues I'm faced with. I'm going round in circles trying to work with a number of different hosts and their enforced "best practices". I'd like to try and garner some knowledge for myself based around the following statements.

"Using the default SQL server port is less secure than using a random non-standard port"
- this seems to me like security through obscurity which isn't particularly secure?

"Firewalls that offer packet inspection do not need to worry about having a totally open port"
- is it okay to have a completely open inbound port (e.g. in this instance sql) as the security aspect is handled by packet inspection?

"Adding IP based firewall restrictions is not secure due to IP sniffing/spoofing - the correct/best way is to use a VPN between machines."
- this obviously isn't always possible but on server<>server tasks should a VPN be used?

This is drawn from my confusion from having to deal with inheriting the following setups:

HOST A
- hardware firewall all outbound traffic open
- I can manage the inbound traffic by opening ports globally or by IP
- Currently no VPN

HOST B
- hardware firewall I have no control over
- 3 outbound ports open (very restrictive) not able to open any more
- SQL port inbound is completely open which I can restrict using windows firewall
- Currently no VPN

HOST C
- no hardware firewall
- Windows firewall I can manage if needed
- SQL setup to use non-default port
- Currently no VPN

I need these servers to be able to communicate on several different ports which server B does not allow for. To me a VPN between them all looks to be the right approach but am very unfamiliar with this so open to being corrected?

Answer 1

This is a broad question, but I will address the main issues

"Using the default SQL server port is less secure than using a random non-standard port" - this seems to me like security through obscurity which isn't particularly secure?

You are correct. having non default ports as a security measure is overrated. However, it does add some security against simple attacks. If some one want to break into the system, this wouldn't stop him. but if someone (or some thousands) bored hackers run port scanners to look for a SQL server (or any other server) to practice or fool around, a non default port may stop them.

"Firewalls that offer packet inspection do not need to worry about having a totally open port" - is it okay to have a completely open inbound port (e.g. in this instance sql) as the security aspect is handled by packet inspection?

Packet inspection is higher level and more complex then port blocking - and therefor it's more susceptible for attacks, bus, or configuration errors. Generally you should place security measures in the lowest level appropriate, so if port blocking is an option, it will be better then packet inspection

"Adding IP based firewall restrictions is not secure due to IP sniffing/spoofing - the correct/best way is to use a VPN between machines." - this obviously isn't always possible but on server<>server tasks should a VPN be used?

It's true that you can trust IP addresses outside you network as a strong security measure, and VPN will be a more suitable solution. However, assuming the attacker doesn't have control over your ISP or network access equipment, spoofing an IP isn't very simple

Answer 2

SQL is very secure over the internet - if you use a certificate and transport encryption. Not doing so is a security "worst practice", unless using a site-site VPN. Enabling and using transport encryption is not difficult, and enables access without the need for a site-site VPN.

"Adding IP based firewall restrictions is not secure due to IP sniffing/spoofing - the correct/best way is to use a VPN between machines."

To be more specific, sending unencrypted data over that type of connection is insecure. If the data and authentication are encrypted, there are legitimate scenarios for ip restrictions.