Top 3 AWS security configuration mistakes

Top 3 AWS security configuration mistakes

Cloud security experts from Palo Alto Networks have warned about three critical misconfigurations that are most common in most organizations and have contributed to the majority of cloud attacks.

Many organizations have rapidly adopted cloud services, such as Amazon Web Services (AWS), in order to reap tremendous business benefits. IT and DevOps teams can deploy cloud systems and services faster with more flexibility, while also reducing costs.

With the cloud benefits, however, also come the security challenges. Security teams often are playing catch-up after discovering and fixing configuration issues.

Nathaniel “Q” Quist, Sr. Threat Researcher with Palo Alto Network’s Public Cloud Security team, spent several years collecting information from hundreds of AWS cloud environments. His team learned three common mistakes that have lead to the majority of public cloud threats.

“We found that within the last year, 65% of attacks were due to misconfiguration,” Quist warned in a recent blog post.

The findings are consistent with many of the headlines related to cloud breaches. For instance, exposing Port 22 or remote desktop protocol (RDP) wide open to the public internet. Just this June, a GoldBrute botnet targeted 1.5M exposed RDP servers. Last year, GoScanSSH malware targeted default and weak passwords on internet-facing systems with SSH exposed.

The team provided some good lessons learned and how organizations can avoid the three most common AWS configuration mistakes.

1) Security Group Allows Internet Traffic

Most of the cloud security providers, like AWS, allow outbound (or egress) traffic by default. Although CSPs do block ingress traffic by default, organizations need to make sure their security group policies restrict traffic to only necessary source and destination addresses. In addition, they should periodically review changes to security groups.

To address this issue, Quist and the Cloud Security team provides two good security practices for Security Groups:

  • Inbound – check for and remove any ‘Inbound Rules’ that have a source value of ‘0.0.0.0/0’ or ‘::/0’.
  • Outbound – add a row to the ‘Outbound Rule’ with the correct protocol (e.g., TCP, UDP, ICMP) and IP address/net range.

In both cases, you should minimize inbound and outbound network connections to only what is appropriate for your organization.

2) AWS Security Group allows internet access to Port 22 (SSH)

Organizations should never allow Port 22 on any system open to the internet. Attackers can compromise the SSH service or launch a brute force attack that could lead to access to your cloud environment. SSH is the typical way administrators can securely connect and login to UNIX-based systems.

The Cloud Security team suggests removing any rule (from ‘Inbound Rule’ tab of security group) that has a ‘Port Range’ value with port 22.

In addition, organizations should employ a jump box (or bastion host) with multi-factor authentication (MFA) as better method to login and gain access to your AWS environment. For smaller organizations, you can restrict SSH access from small set of trusted IPs, instead of “all”.

3) AWS Security Group allows internet access to Port 3389 (RDP)

Similar to Port 22, systems should also never have Port 3389 used for RDP wide open to the internet. Hackers can brute force internet-exposed systems with RDP running or exploit RDP-related vulnerabilities. RDP is the way Admins login remotely to most Windows systems.

The Cloud Security team suggests removing any rule (from ‘Inbound Rule’ tab of security group) that has a ‘Port Range’ value with port 3389.

Likewise, enterprises can deploy jump boxes or at very least restrict inbound access to only trusted IPs.

In summary, Quist emphasizes organizations should never make any of these three configuration mistakes that hackers can easily exploit. The team also recommends you implement “guardrails” such as their Prisma cloud solution.