I have a network that has a single point of entry the WAN. The WAN exposes about 10 static IP's that resolve internally to servers that are in the same subnet. Meaning that if you RDP over 3389 to SQLPrimary1 from it you can RDP to all the other devices on the network. Each server has it's firewall disabled. There is no IPS, IDS, SPI nothing. We are however running Microsoft Security Essentials on all servers (FWIW). :sigh:

I need to implement a strategy for protecting the network from inbound threats, outbound threats, zero-day threats, patch vulnerabilities and good heuristics.

  1. If I run IDS I need it to have all traffic run through the firewall directly into my IDS (Security Onion on Linux) and then back to my network. Right?

    • If I run Security Onion non-stop will it add noticeable latency on my network? I think at present we are utilizing about 2% of our network. Is and IDS system something you run full-time?
  2. Are V-LANS secure? Meaning if I isolate my mission critcal stuff on one VLAN and other resources on other VLAN's is that safest? If not how else could I partition my network so that mission critical data is still safe from beta, web servers and such? Would you use multiple firewalls? What would be the best practice?

  3. We have customers in all 48 states and the U.K. and each of them must connect to our data and web servers. I'd like to impose VPN connections on our customers but I'm wondering:

    • Is that overkill?
    • If not would VPN clients licensed from my firewall vendor be more secure and/or efficient than Microsoft's own VPN software?
    • Would VPN create tons of overhead and congestion?
  4. I have to monitor 2 server datacenters that depend on each other. We have one in the UK and one in the US. I think the easiest way to make sure both datacenters have internet connections is by establishing site-to-site VPN tunnels between US and UK.

    • Is that an effective way to monitor connectivity at each site or would something else me more effective?
  5. If anyone remembers the "ILOVEYOU" virus that crushed SQL servers around 2000/2001 or so. Would anti-virus software of current quality be able to stop that kind of attack? Are attacks like that relevant anymore with IPS and SPI firewalls.

    • When it comes to anti-virus on database servers real-time protection is a great way to go because it doesn't lock .mdf and .ldf files. Would it be wise to schedule downtimes to unmount .mdf/.ldf and full-text indexes to physically scan them for viruses using AV software?
  6. Are there any open source tools that you can use to run your own penetration tests and get a list of action items along with the results?

We are a total windows shop and I'd love to hear some others thoughts and ideas on how to approach these issues.

  1. You route relevant traffic through your IDS yes. Latency will depend on your device's performance.
  2. VLANS are secure if implemented correctly. Make sure to also use 802.1x (PNAC) to authenticate devices at layer 2. Make sure you do not start routing between your VLANS (unless appropriate)
  3. Depends what type of VPN you employ, layer 3 or layer 2 VPN. Make sure that you also use two-factor authentication on your VPN. It's not overkill in my opinion as you are trying to prevent access to your business critical data and services in a controlled manner. Make sure you also appropriately log all connections.
  4. This can be done by a point-to-point tunnel. If the machine is available on the internet you could also perform certain checks from the WAN using a separate, dedicated monitoring machine (ICMP, HTTP,...). You should only allow management protocols like SSH and SNMP to be used from your point-to-point tunnel. Your monitoring machine can check if the machine is connected to the WAN with the first checks and then can see if all services are running smoothly. This is also to avoid a scenario where your monitoring server starts reporting your machine is critical whereas your VPN tunnel just went down (which is also critical but not necessarily device related).
  5. Always use an AV. Remember that the ILOVEYOU virus was a VBS script which was executed by a user. You should not be using your servers to surf the internet, download or open files sent to you by unknown people. You should only execute already tested scripts and binaries which can be trusted. (trustworthy source). Make sure to also use EMET.
  6. This is off-topic. If you are serious about your business you should invest in a vulnerability scanner like Nessus.
| improve this answer | |

This is a partial answer:

re #5: "ILOVEYOU" was such a big deal for two reasons. First, SQL servers were directly exposed to the Internet. Second, and just as important, a large number of administrators completely and utterly failed to follow any sort of best practices, such as regularly applying patches, that would have prevented the attack. Unfortunately, I still run into large numbers of admins that haven't learned this lesson.

To prevent that kind of attack: keep your patches up to date and don't expose the servers to the Internet. Also I have yet to see an AV product that is built to work on a database server. The type of file access required on those machines is such that a typical AV product will cause far more issues than they protect against.

See http://support.microsoft.com/kb/309422 The exclusion list covers pretty much every directory and file sql server uses; which means the only reason you should have AV software on it is if the server is badly misconfigured and misused. In other words, don't allow anyone to remote into it and work from the desktop and don't allow file shares or really any service OTHER than the sql services to be accessible. Then use your network points to monitor the traffic going into it.

| improve this answer | |
  • This was awesome. SQL server is a keystone to our viability. Your guidance and that link were super helpful. Thanks! I tried to vote your answer as an answer but I guess you cannot share answers. – Rex Winn Dec 10 '13 at 21:49

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