Why Monitoring Outgoing Traffic Will Help Find Out if Your Server’s Been Compromised

Novice server administrators often think of server security in the same way soldiers think of a fortress under siege. The enemy is on the outside, and those inside the fortress are safe, provided no one breaches the gates or climbs the walls. The defensive strategy focuses on keeping the enemy out.

However, the fortress metaphor is misleading. A well-secured server is more like a town on market day than a fortress. The walls are high, but the gates are open. A server is useful only when people can access the services it hosts. It needs software to run those services, and it needs to communicate with the outside world.

The software comes from platforms that the server administrator doesn’t control and usually will not have scrutinized. Zero-day vulnerabilities are weak spots in the fortress’ walls. Every open port is a potential vulnerability. Configuration errors often cause vulnerabilities that can be exploited.

Once the outer defenses are breached, attackers use the server’s network resources to steal data or to launch more attacks. Their activity creates a trail of network requests and resource usage spikes, which are invisible unless you’re looking for them. A server administrator is more likely to see the tell-tale signs of an attacker by scrutinizing activity within the city walls than attacks coming from the outside.

It’s challenging to keep the enemy out while allowing friends to pass unhindered. In addition to doing everything possible to secure the perimeter, server and network administrators should focus on the enemy within.

Let’s look at some of the ways an attacker might breach your server and use its resources for no good.

How Does Malware Infect a Server?

Your server executes millions of lines of code that you have never seen. Even the most skilled and security-conscious server administrator lacks the time and the knowledge to assess every piece of software running on a server. The Linux kernel alone has over 25 million lines of code spread over 62,000 files. Libraries, tooling, utility software, and applications add millions more.

It’s unlikely that a server administration or application developer has scrutinized even the code that makes up their application. It almost certainly includes dozens of libraries installed by NPM, Composer, or other package managers. The app may pull in JavaScript files hosted on third-party CDNs. Content management system plugins add yet more code.

Last year, over 4,000 websites, including government websites, were compromised by cryptomining malware. The attackers used the servers’ resources to run code that generated Monero coins and sent them to a wallet controlled by the attacker.

How did the cryptomining malware get on the server in the first place? Instead of targeting 4,000 websites, the attacker targeted a piece of software that was already installed on the sites. They hacked the servers of an accessibility plugin called Browsealoud and added a few lines of code to its files. When the plugin’s users updated it, the malicious code came along for the ride.

The sites that used Browsealoud trusted the plugin’s vendor and so they made no effort to check the code. Consequently, thousands of servers were used to make money for criminals. Supply-chain attacks are increasingly common because it’s far easier to compromise one server than to compromise thousands.

There are a few ways to determine whether your server has been infected via a supply chain attack. Malware scanning software may be able to spot the harmful code. But keeping an eye on your server’s outgoing traffic is the most reliable method. The malware will make requests to command-and-control servers. Cryptomining malware and credit card scraping software deliver data to third-party servers, so check your logs for frequent requests to addresses you don’t recognize.

Supply-chain attacks are only one of the many ways in which an attacker might take control of a server’s resources. Others include:

  • Software vulnerabilities. Bugs in the code running on the server might allow an attacker to elevate their access or run code via SQL injection, cross-site scripting, and many other techniques. The best way to mitigate the risk of software vulnerabilities is to update regularly. Updates apply patches that fix vulnerabilities. However, zero-day vulnerabilities – those that criminals know about and developers don’t – mean that updates aren’t enough. Monitoring outgoing network traffic will help to spot breaches.
  • Configuration errors. It is not uncommon for configuration errors to open up vulnerabilities. Database configuration errors are a particularly common source of data theft. Some databases have insecure default configurations to make testing and deployment easier. Administrators who don’t change from the default configuration are inviting attack.
  • Malicious Insiders. An insider with trusted access to a server might deliberately install malicious code or open up a backdoor that allows criminals to do the same. Malicious insiders are often current or former employees with a grudge.

There are best-practice security strategies to mitigate all of these risks, but the only way to completely protect a server is to take it off the network and lock it in a vault – something that is not possible with a server. The risk of compromise is ever-present, and outbound traffic (also called egress traffic) may be your best clue.

Combatting Malicious Outgoing Traffic

The firewall is your friend. Identify the outgoing ports that the services running on your server need. Implement a “zero-tolerance” policy that blocks all outgoing traffic that isn’t essential for the server to do its job.

On a Linux server, tools such as “iptraf” and “iftop” can help you to monitor network traffic from the server. Manually monitoring network traffic can be tedious and time-consuming, but tools like Nagios collate logs from many services and present them in a searchable and easily used interface. These tools may be available via your Linux distribution’s software repositories.

Matthew Davis

Author Bio: Matthew Davis — Matthew works as a writer for Future Hosting, a leading provider of VPS hosting. He focuses on data news, cybersecurity, and web development topics. You can usually find his hiding behind a computer screen, searching for the next breaking news in the tech industry. For more great articles, check out FH’s blog.

Matthew Davis is a guest blogger. All opinions are his own.

The post Why Monitoring Outgoing Traffic Will Help Find Out if Your Server’s Been Compromised appeared first on CCSI.

*** This is a Security Bloggers Network syndicated blog from CCSI authored by Guest Author. Read the original post at: https://www.ccsinet.com/blog/outgoing-traffic-monitoring-compromised-server/