News over the last few years has been thick with reports of major data breaches on corporate network infrastructure. In the cases of the Panama Papers, the OPM leak, and the Hacking Team leak, the results were catastrophic leaks of extremely confidential information.
In truth, a determined and well-resourced attacker can always find a way in. In the case of the Bangladeshi central bank attack, reports suggest they did almost nothing to secure their infrastructure prior to the attack, and it wound up costing them tens of millions of dollars.
In each case, though, one thing was common: the hacks were made possible because of basic flaws in the network infrastructure and a failure to take security seriously.
The Four Horsemen of the Netpocalypse
The most common network threats fall into four main categories: malware, phishing, denial of service (DoS) attacks, and advanced persistent threats (APTs).
The bad news is that it’s impossible to create a perfect defense. They’ll always be able to find and exploit vulnerabilities in your defensive security infrastructure.
The good news is that it’s neither extremely hard nor overly expensive to mount a reasonably effective defense.
Let’s start with a review of these four main categories and some quick “TL;DR” suggestions on how you can set up some great network infrastructure defenses for those particular attacks.
Then, let’s dig in to some best practices when it comes to defending your entire network infrastructure as a whole. Ready?
Pencils up please.
Malware and ransomware
Malware is the modern term for what we used to call a computer virus. It’s usually deployed starting with a small “dropper” program that then contacts a command-and-control host to get further instructions and download additional malware.
One of the most dangerous types is ransomware, which immediately sets about encrypting all your files, including all files on any network shares. It then offers to give you the key to unlock your files in exchange for paying a ransom.
Protecting your network infrastructure against malware and ransomware
Most malware isn’t targeted. By that I mean it’s produced with the general intent of catching somebody—anybody—not you in particular.
Malware writers often exploit software vulnerabilities in common applications like your web browser, Flash, Word, or Excel. In many cases, they also exploit operating system vulnerabilities.
Software patches and endpoint protection
First, keep up with software patches. If you apply all patches as soon as they’re released, you’ll be ahead of just about all malware threats.
Second, use a good endpoint protection system. Anti-virus packages are still valuable tools, but the problem is that malware writers have started adopting clever tricks like encrypting the code with random and frequently changing keys. That means the malware will never appear with the same checksum twice, and the internal byte sequences will be obscured.
To combat random keys, modern endpoint protection software generally includes some sort of sandboxing feature. The suspected malware is unpacked in a safe, virtualized environment and allowed to install itself and run while the scanning software carefully monitors it for signs of any malicious actions.
Most good endpoint protection systems also monitor the real endpoint workstations for signs of malicious software actions and try to block the malware before it’s too late.
A second line of defense
The second line of defense is to assume the first piece of malware will actually be a dropper, and that it will reach back across the Internet to a Command and Control server for further instructions and further software packages.
We can often catch the infections by implementing good scanning on the network edge. This is different from a traditional Intrusion Detection System (IDS), which largely monitors inbound connections. Here, we’re monitoring outbound connections.
We’re looking for several key indications of compromise including:
- Connecting to known malware domains or C&C systems
- Downloading suspicious files
- Traffic patterns that appear to indicate interactive VPN-like activities, which might indicate a remote access Trojan (RAT)
I actually don’t consider phishing to be an IT security problem. It’s a social engineering attack in which an attacker essentially tricks a person into doing something—transferring money, divulging sensitive info/passwords, or installing malicious software are all examples we’ve seen.
Because phishing isn’t really a technological attack, technological solutions are generally ineffective. Closing the door to an email-based phishing attack doesn’t necessarily close the door against a similar attack conducted over the telephone or through the mail. This is old-style fraud—it has always existed, and it will always exist.
Defenses against phishing
There are two main defenses against phishing.
The first is education. You can reduce the chances you or your client will suffer from a phishing attack if everyone is vigilant and aware of what phishing looks like. But this really only reduces the chances.
The other defense against phishing is procedural. Make it a well established and rigidly adhered to process that money transfers are never done without verbal confirmation from a few specifically named individuals. The CEO will never email the head of accounting requesting a money transfer to a mysterious supplier in a foreign country. And even if they do, standard procedure is to call the CEO’s cell phone and verify the instructions.
Denial of service
Denial of service (DoS) attacks can be launched fairly easily by unskilled attackers, and they can be carried out without needing access to your internal infrastructure.
The simplest DoS attacks try to overwhelm your Internet link by sending huge amounts of traffic so that legitimate business traffic gets shut out. More sophisticated DoS attacks involve less traffic, instead using up other resources within the network infrastructure.
DoS attacks are sometimes done to disrupt business, and sometimes to extract a ransom to make the attacks stop.
Defenses against denial of service
You really can’t protect against most DoS attacks. The best approach is to use a protection service provider like CloudFlare or Arbor Networks to interrupt the attacks somewhere upstream from your infrastructure.
Protection services typically work by directing your traffic through their infrastructure before it gets to you. They’ll either automatically detect attacks or allow you to specify you’re under attack. Then they simply redirect the malicious packets into the trash can, and only forward the legitimate traffic to you.
Another good way of mitigating DoS attacks is to put public-facing infrastructure on a cloud service provider with ample resources. That way, if you’re attacked, there’s no effect on your real infrastructure, just on the web hosting provider, which will generally have robust DoS mitigation systems.
More sophisticated attacks are generally based on software vulnerabilities, it’s hard to create permanent defenses against them. But regularly patching Internet-facing infrastructure goes a long way to minimizing risk.
Advanced persistent threats (APT)
Advanced persistent threats (APT) are the attacks everybody fears. In an APT, the attackers manage to build a back door into your infrastructure, then quietly extract your most valuable data. The effectiveness of this type of attack depends on the skill of the attackers, and your ability to detect and stop them.
APT attacks often start out as malware or phishing attacks. The attacker has to somehow get a foothold inside the infrastructure. Then, typically, the attacker instructs the initial dropper software to download a remote access Trojan that allows them interactive access.
Defenses against APTs
The defenses against APT attacks include everything we said about malware attacks. It’s also useful to monitor your Internet links for the typical signatures of remote access Trojan (RAT) traffic patterns. However, if your attackers are skilled, an APT attack can go undetected for considerable lengths of time as they move within your network infrastructure, looking for data.
For this reason, in addition to prevention and detection, it’s useful to have good forensic abilities when it comes to APT attacks. In particular, it can be very useful to maintain thorough logs of every access to every file and system on your infrastructure, so you can reconstruct what user IDs accessed what resources from what systems.
Another useful forensic capability is some sort of packet capture or traffic flow monitoring tool. NetFlow-based systems can keep track of every conversation that takes place, including source and destination addresses, protocols, and amount of data transferred. This is often supplemented by detailed packet capture data, which can show you exactly what was transferred.
Effective ways to block *most* inbound and outbound network attacks
At the risk of being condescending, the first and most obvious security element against inbound attack is a firewall. Pretty much any commercial firewall is suitable, but I generally recommend using a more sophisticated next-generation or unified threat management (UTM) firewall.
Since everybody these days uses private IP addressing, a firewall is also the right place to do your address translation between internal and external address spaces.
A firewall also has the ability to filter incoming or outgoing connections based on simple Layer 3 and Layer 4 elements in the packet header. These include internal and external IP addresses, as well as TCP and UDP port numbers.
A firewall also has to be stateful, which means it keeps track of every individual session passing through it. You shouldn’t be able to get packets past a firewall simply by constructing them to look like part of a pre-existing session.
Intrusion detection and prevention systems
It’s also useful to couple a firewall with an intrusion detection system or intrusion prevention system (IDS/IPS). An IDS/IPS is a device that watches every packet and session to look for signs of malicious activity. Generally, more serious problems cause the IDS/IPS to use prevention mode—where it drops the session. Less serious issues are merely detected—resulting in an alert.
Most IDS/IPS devices use a combination of factors to detect malicious behavior. They reject sessions that don’t appear to be following the established rules for the protocol they’re using. And they use signature-based detection to look for known patterns of malicious behavior.
To be really effective, you need to make sure those signatures are kept up to date, which largely means some sort of subscription model.
The reason I like next-generation or UTM firewalls is that they include an IDS/IPS in the same box, and display IDS alerts on the same management interface. Such a two-in-one device is cost-effective and simplifies management.
Reverse proxies and web application firewalls
Inbound protection you can deploy at the network edge is a reverse proxy, a device that masquerades as a web server. The real server sits somewhere inside the network infrastructure, and the reverse proxy passes the data to and from that real server. (Obviously, you only need this type of protection if you have some sort of server that’s accessible from the Internet.)
In many cases, a reverse proxy is used to translate between an insecure protocol like HTTP (which might be all that one of your legacy applications server supports), and a more secure one like HTTPS for anything on the public Internet.
The problem with reverse proxies is that they don’t inspect the contents of the traffic they’re relaying. That’s fine for protocol-based attacks, but not for application-based attacks.
For this reason, I’m not a huge fan of reverse proxies unless they’re also web application firewalls (WAF). A WAF is also a device that sits between the Internet and a web server, but it explicitly sanitizes every request coming from the remote user. At a minimum, it will remove quotation marks and other special characters that are typical of SQL injection attacks.
Some WAF devices can also be configured to know exactly what types of data are allowed in specific fields on a web page that accepts input. Some WAFs will even monitor the connection between a web server and a database to ensure that an otherwise innocent-looking request didn’t somehow result in a huge table dump.
Another device frequently exposed to the public Internet is an email server. I’ve seen attackers directly trying to do malicious things to an email server, but more typically, they’re trying to deliver malware or spam. So I like to deploy an email scanner in front of an email server. (Note that you can completely avoid the need for this type of defense if you use an outsourced email service.)
Email scanners are concerned with two problems: They want to eliminate or at least reduce spam, and they want to reduce malware attacks by scanning for viruses. Imagine that an incoming email message has a virus in an attachment. If the email scanner catches it, it quarantines the message and the end user doesn’t see it. If the email scanner doesn’t catch it, then you have to hope whatever anti-malware system you have on that user’s workstation will catch it. For this reason, it makes sense to use completely different malware scanning systems on emails scanners and workstations. I’ll discuss malware scanning systems in more detail later.
The simplest and least expensive thing you can do to protect against outbound attacks is to use a really robust domain name system (DNS). Malware has three ways to call home for instructions. It can use:
- Hard-coded IP addresses—but they’re very easy to block once discovered
- Domain names the malware rotates through on a programmed schedule
- Compromised legitimate sites or advertising services
DNS-based protection can be a useful first line of defense against the second type of attack. Interestingly, though, there do appear to be some malware systems that use DNS queries for communicating with other command-and-control traffic. That is, the results of a DNS query might be interpreted by the malware to mean something other than an IP address. This is another way a good DNS filtering system can be helpful in combatting malware.
Another useful line of defense against outbound attacks is probably the same IDS/IPS you’ve deployed for inbound protection. But this time we’re interested in different types of attacks with a completely different set of signatures. Now, you’re looking for malware inside a network infrastructure as it tries to connect to command-and-control (C&C) servers on the Internet. You’re also looking for indications of unauthorized VPNs or remote access Trojans (RATs).
If you use a central authentication system like LDAP or Active Directory, (and I believe you should) then you get another excellent defensive tool essentially for free. Simply monitor LDAP or Active Directory logs. Look for repeated failed logins, which might be an indication of somebody attempting a brute force attack. Also, look for people logging in when they shouldn’t be, or logging into systems they shouldn’t be on, particularly users with special privileges, like system administrators.
Probably the most effective types of APT attack is one where the attackers steal legit user credentials. They simply log in and poke around until they find something interesting.
Web proxy servers
The next thing to look at for protection against outbound attack is a web proxy server, a system that intercepts all outbound web requests and tries to serve them locally. For example, if somebody just loaded a particular web page, the proxy can take the page from its cache and send it back to the user immediately.
Proxy servers provide better overall performance, as well as an opportunity to centrally scan all web content, including encrypted SSL content, and reject things that look malicious.
I don’t like to make a proxy my first line of defense. It can obscure and limit the effectiveness of some other tools. For example, if you see a DNS request or an outbound connection to a known malware domain, it’s a multi-step process to track it back to a particular workstation.
And I haven’t found that the scanning capabilities of most proxies are any better than those found on the best UTM firewalls anyway.
The important thing a web proxy buys you is the ability to decrypt and inspect HTTPS (SSL) content.
Forensic packet capture
If I had all the security tools we’ve already discussed, and I really needed something more to help me deal with incident response following an attack, I’d look at forensic packet capture tools. These are carefully optimized and targeted network protocol analyzers that record interesting looking sessions. They then allow you to search through a massive historical database of these sessions.
Forensic tools are mostly useful during the incident response process when you’re trying to figure out what systems might have been affected by an attack, what credentials might have been compromised, and what data stolen or altered. That’s useful information, but it’s obviously not the starting point.
The sandbox tries to unpack the files and run them in a special, isolated virtual machine seperate from your network infrastructure. As it does so, it watches carefully for any signs of malicious behavior. The hope is to prevent malware from ever reaching a workstation, particularly important for crypto-viruses, which deploy as soon as they’re downloaded, and immediately start destroying files.
Sandbox detection can usually be done so fast that the end user isn’t even aware their download was intercepted. However, sometimes malware can evade detection in a sandbox. A sandbox should never be considered a replacement for good endpoint security.
Bringing network infrastructure defenses together
Once you have several essential elements of network security up and running, you’ll quickly find you don’t have the resources to look at all of them. Firewall and IDS logs alone accumulate at rates of kilobits per second, even after filtering. Active Directory and DNS logs are often just as bad. There’s no way a human can monitor these systems in real time. Instead, you need a way of storing, filtering, and correlating messages into something meaningful.
Initially, it might be enough to use the management tools that come with your equipment. A good UTM firewall generally has a management GUI. You can always use the GUI on your domain controller to look at Active Directory logs. And most endpoint security systems also have a central console.
But at a certain point, it’s just too many consoles that aren’t sharing information with one another.
This is where a security incident event management (SIEM) system becomes useful. Often the SIEM doubles as a searchable, long-term storage system for log messages. Some organizations deploy these functions separately, but ideally, I like them to be together.
The SIEM is a single pane of glass that correlates information it receives from the various security systems you’ve deployed across your network infrastructure, and presents you with all the relevant information about each event.
For example, if somebody is attacking a web server, you might receive relevant data about the attack from the firewall, the IDS/IPS, the WAF, and perhaps the Active Directory server. The SIEM rolls all of that information together, so you don’t have to manually search through each of the different data sources to understand exactly what’s going on.
Effective security requires many tools working together. You’ll often hear the expression “defense in depth”, and this is what it means. One of the most important tasks is to identify your risk areas. Then allocate your budget and your time carefully to cover the highest risks first.
The other point that I really want to stress is that tools alone are not security. You can’t lock the door and expect that will keep out all the burglars. Somebody has to be looking at the tools, investigating every single anomaly and eliminating the threats as they appear. Even the risks will change over time, so you need to continually re-evaluate your highest risk areas to make sure your network infrastructure is appropriately covered.
Get your free 14-day Auvik trial.
Thanks for sharing this wonderful article. I learned a lot from it. It’s worth the read.
Keep it up!
Thanks for your feedback! Glad you found the post helpful.