1001 Best Practices for a secure AWS Cloud Project

?

Amazon Web Services (AWS) : a cloud service provider that even Martians had heard about and probably deploying with. AWS Still leader in the Gartner’s Magic Quadran since 2011, but the questions are the same for everyone that want to take the leap :

• Is it safe ?
• how to use it safly ?
• Can amazon or US gouvernement fetch my data following the patriot act ?

Cloud computing a 'security nightmare,' -- Cisco CEO - 2009

In the last five years the everything store holding had added more that 6000 features and reached 103 services on AWS, as of this writing. AWS is a wide selection of services that cover every and any IT today's needs.

With the emergence of cloud services such as AWS, the threat landscape has evolved, Using a shared cloud make it easy for a malicious attacker to get information about the OS, IP, and different ressources in a short time, you will not undergo the targeted attacks but more the random one that badly make damages.

Enough speeking let's get down to business.

Reconnaissance :

A well planned attack begin by a reconnaissance step, this one consists of identification and sweeping all DNS, MAIL, MOBILE, and IoT servers,.. document published by the users for the victime company

Amazon host identification is a easy exercice for a script kiddies, since amazon is publishing the ip range on their website IP range per region, i don't know if it's a good idea but it make it easy to guess which host is up/down instantly from a ssh / ping (icmp ) Python script dialer.

For an experienced hacker, it's easy like dialing a number on the phone from a phone book and seek the one that rings.

let's do that for fun an see what we can find :

...    
   {
      "ip_prefix": "52.95.254.0/24",
      "region": "eu-west-3",
      "service": "AMAZON"
    },
   {
      "ip_prefix": "54.239.1.16/28",
      "region": "eu-west-3",
      "service": "AMAZON"
    },
    {
      "ip_prefix": "54.239.1.16/28",
      "region": "eu-west-3",
      "service": "AMAZON"
    },
....
37 range left         

Every machine DNS is composed this way

ec2-(IP with dash separator) + (Region) +.compute.amazonaws.com        

let's pick up one of those IPs

Example : For a machine located in Paris  Region eu-west-3 : 54.239.1.16

> dig ec2-54-239-1-16.eu-west-3.compute.amazonaws.com
;; AUTHORITY SECTION:

eu-west-3.compute.amazonaws.com. 899 IN	SOA	dns-external-master.amazon.com. root.amazon.com. 2049 28800 900 604800 900
ec2-(IP with dash separator) + (Region) +.compute.amazonaws.com
        

This one is off .

For a plugged server the response is slightly different :

;; ANSWER SECTION:

ec2-XX-XXX-XXX-XX.eu-west-3.compute.amazonaws.com. 21599 IN A XX.XXX.XXX.XX        

I see you telling that getting DNS content is not very hard even for on on-premise machine..,unlike your fashion data center, where you expose only a exchange MX server and a web portal, being on the cloud force you to add more open machine to manage and do the daily administrating work that get the attacking surface bigger.

From this trivial information an attacker could start inpecting deeply the instance by doing some fingers command to get all useful information about the running operating system...

CI/CD zero-days project :

What probably make you safer in your on-premise is that the external attacker has probably no idea of the operating system version or the firewall WAF intrusion detection your shielded with. Imaging the time that it takes to a hackers or a group of hackers to find a zero-days and challenge the amazon linux AMI (since it's the free and the most used one). It's easy to test in a real target victime environment. indeed an EC2 instance is easy to procure. I guess that study and challenge the lasted patched red hat/amzon linux AMI is a windfall for a malicious attacker.

Here's same of the best practices to use the cloud correctly and begging it for a rain rather than lightning...

At AWS console level :

First and foremost the AWS console security :

• Avoid using root account :

Forget that you have the sesame key and create a less privileged account each one can do and attribute specific roles (IAM is user friendly for that) .

• Activate MFA on your root account

Force every user to create a two factor authentication to avoid the hack of weak password

At the operating System level :

• Build and run your own AMI

Many tools allows you today to create and customize and distribute your operation system and use as an (AMI) amazon machine image reference.

• Encrypting your Elastic Volume : Elastic Block Store (EBS) :

AWS, a company based in the United States, is subject to US laws, including the Patriot Act.?probably the best way to make sure that the data is safe in the cloud, is to encrypt this one with a solid encryption mechanism. AWS provide a wide selection for encryption security including HSM.

• Enforce your defense with SeLinux

Lot of company do it the lasy way and try to avoid the system security level firewalls netfilter .....Selinux, it's a bad strategy. i strongly adivse to enable Firewalld/netfilter Selinux this one offer more control on process and a clean system ressources isolation.

• Runinng inspector for patch management

Being in the cloud doesn't change the habit of patching and inspecting the operation system on a regular bases. CVE Databases and github could be very useful for detecting weak insecure library.

• Pentesting

No need to explain that doing penetration test is a wise decision for a security that care about his reputation.

The last and the hardest advice that i can give is try do deploy different operating system on different Avalability Zone, with this strategy you make sure that i case that one Availability Zone is compromised you can relay on another one that use different technology.

Before going farther let me remind you the attacking surface principle and what you probably risk being on the cloud :

In the time i was junior in this domain, i heard that it's best to deploy two different hardware in two different datacenter for the same company. this helps to reduce the attack surface, and prevent from hardware and low level (assembly ) attacks.

At the network level :

• Avoiding port mapping/scanning is you first defense for that : avoid using standard port, make sure the application is hardened enough to not communicate the system version. No need to tell you to disable ping (icmp)
• Using Vlan (as a network segregation) optimize internal server communication and harden your network security
• Put your weak link in the subnet of the subnet of your VPC or even better in a VPC dedicated for backend apps and data store.
• Block your database machine for doing outbond traffic.

I've seen some DevOps updating database from the internet,

• Unless it people is operating from all over the world, you can create a sg with the remote ip authorized to connect from outside
• Create a security group per server group even it sound obuvious

At the back-end or the Database level :

Dont expose your database directly !

• Close the unsed network port : RPC ....
• Expose as much as possible the the back-end data over an API and make sure to set a quota on it.
• No need to set an elastic ip for the database
• Make the database unreachable other way than from the bastion serveur
• Put the database in a separate VPC-DATA

Monitoring / Supervision / Profiling:

I spend lot of time to try to explain the difference between supervsion / Monitoring and Profiling will do it one last time with some use case

Supervision : the system that check the stat of a host, port, service, api , DB.....

Monitoring : a system that watch the ressource usage and probably telling you.. please scale up or down..

Profiling : A system that detect a normal usage from a strange one : detect a DDOS attack for example.

for more please refer to my previous articles :

The Monitoring Stack as a Microservice

Please interact and leave a feedback

Disclaimer

... if you're looking for the rest of 1001 best practices, you need to convert it to binary.

Any actions and or activities related to the material contained within this topic is solely your responsibility.The misuse of the information in this topic can result in criminal charges brought against the persons in question. The authors and linkedin will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this website to break the law.