This is the second part of my posts on what the 1983 move War Games can teach us about security. Here, I want to talk about the part of the movie where David Lightman (Matthew Broderick’s character) realizes that he almost started World War III and is in the process of throwing away any evidence that he hacked into NORAD. At that moment, the NORAD supercomputer WOPR calls David. Later in the movie, McKittrick (Dabney Coleman’s character) says it’s impossible for the WOPR to call someone. Well, he was obviously wrong, because the WOPR did call out. Fail! Which brings us to our second lesson.
LESSON 2: Have good controls and policies around your outbound traffic.
Most organization have a firewall and tend to pay at least a little attention to inbound traffic. They only allow specific ports and protocols to specific internal IPs. TCP/80 and TCP/443 to WEBSERVER1, TCP/25 to EMAIL1, etc. But what is equally important is to restrict the traffic that goes out of the organization. Many times, SQL servers or print servers or Domain Controllers (you know, the thing with all of the passwords) have open access to the Internet. Why? There are very, very few instances where those types of servers need access to the Internet.
It’s far better to apply the Policy of Least Privilege to outbound connections for all servers. Only open up what is necessary. How about configuring a set of firewall rules for outbound server traffic that are similar to the inbound rules? Default deny for all outbound connections, but with rules to allow the specific ports and protocols for services that are needed. So you allow UPD/53 outbound for your DNS server, outbound UPD/123 for your NTP server, outbound TCP/80 and TCP/443 for your WSUS server, and so on. Then deny everything else from your servers.
I know what you’re thinking. This seems like a big pain in the butt. It will require an analysis of your server traffic to determine what is necessary and what isn’t Why do this? Well, there are two main reasons why this is beneficial:
First, it makes life on any attacker more difficult. Remember, it’s not a matter of if you get hacked, it’s when. So, when you get attacked, you would like to know about it. Putting up barriers, making the attacker’s life more difficult, causes him to make more noise in your environment. Let’s say an attacker compromises a web server. He manages to hop from your web server to a back end database that holds user account information. He tries to upload the data from the SQL server to his server. But he can’t because you have rules on the firewall that prevent the SQL server from making connections to the Internet. Now he has to copy the data to another server or back to the web server to get it out of your organization. All of these extra actions will, hopefully, trigger alerts on a network IDS or will be caught in a log review. But you are causing the attacker to do more things, to spread more fingerprints around your environment. Making an attacker’s life more difficult is always a good thing.
Second, it makes incident detection a little easier. If you pare down outbound server connections to only what is necessary, you should know what is normal outbound traffic and what isn’t for your servers. So if you do a log review of denied outbound connections and find one of your restricted servers all of a sudden trying to get to out to an IP in Romania or China, you have something actionable, something you need to investigate. If no restrictions are in place, it makes detecting suspicious connections much more difficult.