4 Common Cloud Misconfigurations & What To Do About Them
Blog Article Published: 11/14/2019
By Kevin Tatum, IT Security Engineer at ExtraHop
In a recent report, McAfee uncovered the rise of Cloud-Native Breaches and the state of multi-cloud adoption. We'll define the top 4 cloud misconfiguration goofs from their list, how they can affect your organization, and what to do about them.
When it comes to personal data, the mid-2010s were a bit of a reckoning. Your credit card information, health records, and even your love life became subject to breaches. Today, nearly everyone can relate to the hassle of switching out a debit or credit card, and these issues persist—especially as enterprises move their IaaS (Infrastructure as a Service) to the cloud.
In recent years, nearly 70 percent of exposed records—5.4 billion total—were caused by unintentional internet exposure due to misconfigured services and portals—services like Amazon Simple Storage Service, known as S3. (Luckily, S3 misconfiguration is a very avoidable issue.)
As McAfee found, most of these misconfigurations go unreported and, in many cases, unnoticed.
If only 1% of IaaS issues are reported, that means a whole slew of companies inadvertently leak data or fail to report for fear of bad PR. Worse, one-quarter of the McAfee survey respondents said it takes longer than 24 hours to correct misconfigurations.
In summary, McAfee highlights significant visibility, reporting, and misconfiguration errors that are preventable. Here are the top offenders in the McAfee list and the ways they can affect your organization, followed by a remedy for these common problems.
4 Common Security Group Setting Misconfigurations
Unrestricted Outbound Access
Outbound traffic should always use the principle of minimalist authority. Many AWS users only configure inbound ports in security groups, but outbound ports can also be a huge security risk. Limiting outbound traffic helps direct traffic to only the applications and servers that need to communicate. This helps reduce the risk and impact of internal network scans, lateral movement, and data exfiltration.
Your servers may only need SSH or RDP inbound ports to manage them. It's rare for one of those application servers to SSH to all of the other servers in the network. Many common hacker tactics use random ports for Command and Control actions, reverse shells, or to spread malware.
Unrestricted Access to Non-HTTP/HTTPS Ports
Web servers are designed to host websites and web services to the internet, and they can also host other services like SSH or RDP for management or databases. But it's important to block these from the whole internet. If these ports remain improperly configured, it can open you up to attackers looking to exploit or brute force the authentication. If you open up these ports to the internet, make sure they're limited to accept traffic from particular addresses such as your office.
Unrestricted Inbound Access on Uncommon Ports
Some services use a high numbered TCP or UDP port to obfuscate what is running in the environment, but security through obscurity never really works. It doesn't protect you from a determined hacker or even a random internet scan. Some services also open uncommon ports without really letting you know.
Does your web server have a statistics page? Do you have PHPMyAdmin running on port 8443? Are you leaking Apache Tomcat services on port 8080? You must restrict high-level ports to only the necessary systems, and usually, that is not the internet. PHPMyAdmin on the internet makes us shudder.
Unrestricted ICMP Access
ICMP is a useful protocol, but leaving it open to the internet can leave you vulnerable to more straightforward, older attacks. One of the most common uses of ICMP is to use ICMP Echo to verify that your servers are online and responsive.
ICMP Echo is an excellent diagnostic tool for IT professionals. Unfortunately, it's also a great tool for hackers. A quick ping scan of the internet using Nmap or Fping can let attackers know that you have a server online, which becomes ripe for a focused attack. There are several more complicated ways to find a server on the internet, so why do a bad actor's job for them?
Attackers can use ICMP for much more than finding servers, however. As an example, a ping flood overwhelms a server with too many ICMP messages. Though simple, a ping flood is an effective type of Denial of Service attack, which becomes even more effective when multiple attackers or botnets are involved to create a Distributed Denial of Service (DDoS).
The ping sweep and ping flood may be ancient methods, but they're still put to use because they work. Do yourself a favor and block ICMP.
How Network Detection and Response (NDR) Can Help
Most cloud environments have dozens, if not hundreds, of these security risks. And really, each server needs its own set of rules.
While the ability to quickly build servers and services in the cloud has its advantages, it also comes with some of the most significant security risks. When you use default rules, it's easy to miss one rule on a single server—and if an appropriate rule is overlooked, your whole environment can quickly be compromised.
One reason cloud security has lagged so far behind traditional security is that, until very recently, network traffic in the cloud was extremely difficult to capture and parse effectively. Monitoring network communications in real time through network detection and response (NDR) is the quickest and easiest way for security teams to stay on top of complex, dynamic environments, and without NDR in the cloud, SecOps struggled to maintain the same deep visibility and rapid threat detection as is possible on-premises.
With the advent of traffic mirroring in AWS and Azure, that gap has finally begun to close.
Download a complimentary copy of the Beginners' Guide to Network Detection and Response to learn more about NDR solutions.