Thursday, September 27, 2012

Protecting your servers from your hosts

          It seems the phrase "hard exterior with a soft & chewy interior" is a phrase being bandied about pretty frequently these days in relation to the security of many enterprise networks. The gist of the phrase is that we often spend lots of time and money protecting ourselves from external attacks, thus creating a hard shell at the perimeter, but provide no defense on the interior of the network from attacks by devices already internal to the network.

          In many cases, there are no security controls protecting against a compromised host or a malicious insider attacking other hosts or servers. I have often been surprised at the lack of any ACLs limiting connections from hosts to servers. While clients have legitimate business needs to access resources on the server farm, limiting connections to only the required ports and from the required hosts can help narrow down the threat surface and prevent attacks.

          Firewalls or layer 3 switches/routers should be configured with access lists to eliminate unnecessary connections. Generally speaking, your average user does not need to make SQL connections to the database servers, SSH connections to Linux devices, or SMTP connections to pretty much anything, so these types of connections should be denied by default. Ideally, protocols such as SSH, RDP, or other forms of remote management that are necessary for system admins to perform their duties will be locked down to only the system admin's IP address. The use of "jump servers" can be a good choice when dealing with a large number of system administrators, because it allows for all remote admin connections to come from the same source address. While this certainly won't eliminate all attacks, if properly implemented and logged, it will give network defenders a better chance of discovering and hopefully preventing future malicious activity.

Stay tuned for a future post dealing with protecting clients workstations from each other!

No comments:

Post a Comment