Scripts and resources for multi-cloud (AWS, Azure, GCP) security tooling running on Linux. There's also a script for getting similar results on a Mac.
This repository contains:
- Scripts for various environments to setup a multi-cloud security Linux testing machine with tooling
- Example snippets to demonstrate how to run most of the services
- An example of a recommended networking setup
- Scripts to generate a virtual machine and network
- Scripts to tear down cloud resources
- Some external resources that might be of interest when working with security and pentesting
You should create and use a relevant pentesting IAM profile when using these tools so results are realistic.
- Amazon Web Services EC2 (RHEL Linux 2)
- Azure VM (Ubuntu 18.04)
- Google Cloud Platform Compute Engine (Debian GNU 9)
- Mac OS X
The script installs:
- Utilities: jq, Docker
- Brew (Only for Mac)
- Python 3
- wafw00f
- Nikto
- ScoutSuite
- Metasploit
- Photon
- Utilities: AWS CLI v2, Awsume
- Prowler
- S3Scanner
- pacu
- LambdaGuard
For Prowler to work, you should ideally create (and use) an IAM user based on the SecurityAuditor managed role. Read more at Prowler: IAM policy or Prowler: Bootstrap script.
If you want to run an extra setup (or just don't like CLIs) here's how you can get Kali Linux going on VirtualBox:
- VirtualBox
- Kali Linux images for VMware, VirtualBox and Hyper-V
- How to install Kali Linux on VirtualBox
Make sure to check how and when you need to make a pentesting request with any of the clouds. Usually you don't need to do that anymore, since at least the multi-cloud tools should just use the respective API to pull data and then analyze it.
Always ensure that you only attempt to affect your own projects, resources and infrastructure. Also make sure that people in your organization that need to be informed of these activities know about the pentesting.
Excerpt of the linked resources:
AWS customers are welcome to carry out security assessments or penetration tests against their AWS infrastructure without prior approval for 8 services [...] Customers are not permitted to conduct any security assessments of AWS infrastructure, or the AWS services themselves.
Those eight permitted services are:
- Amazon EC2 instances, NAT Gateways, and Elastic Load Balancers
- Amazon RDS
- Amazon CloudFront
- Amazon Aurora
- Amazon API Gateways
- AWS Lambda and Lambda Edge functions
- Amazon Lightsail resources
- Amazon Elastic Beanstalk environments
Prohibited activities are:
- DNS zone walking via Amazon Route 53 Hosted Zones
- Denial of Service (DoS), Distributed Denial of Service (DDoS), Simulated DoS, Simulated DDoS
- Port flooding
- Protocol flooding
- Request flooding (login request flooding, API request flooding)
In case of "Other Simulated Events" should be emailed to an email address viewable in the below resources.
- https://aws.amazon.com/security/penetration-testing/
- https://aws.amazon.com/premiumsupport/knowledge-center/penetration-testing/
Excerpt of the linked resources:
Acceptable testing includes
- Tests on your endpoints to uncover the Open Web Application Security Project (OWASP) top 10 vulnerabilities
- Fuzz testing of your endpoints
- Port scanning of your endpoints
One type of test that you can’t perform is any kind of Denial of Service (DoS) attack. This includes initiating a DoS attack itself, or performing related tests that might determine, demonstrate or simulate any type of DoS attack.
- https://docs.microsoft.com/en-us/azure/security/azure-security-pen-testing
- https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement)
I will use an example for how to set up the suggested networking for AWS. The settings and concepts are essentially the same for GCP and Azure.
Create or host the machine in its own secure VPC.
Suggested name: PentestingMachines-VPC
Suggested CIDR: 192.168.0.0/24
Create one subnet per Availability Zone in your new VPC.
Suggested name: PentestingMachines-Subnet1a
Suggested CIDR: 192.168.100.0/27
Suggested name: PentestingMachines-Subnet1b
Suggested CIDR: 192.168.100.32/27
Suggested name: PentestingMachines-Subnet1c
Suggested CIDR: 192.168.100.64/27
Create a Security Group. Get your IP from http://whatismyip.host or a similar service.
Suggested name: PentestingMachines-SG
Inbound Rules:
- HTTP, Protocol: TCP, Port Range: 80, Source:
0.0.0.0/0 - HTTP, Protocol: TCP, Port Range: 80, Source:
::/0 - SSH, Protocol: TCP, Port Range: 22, Source:
XXX.XXX.XXX.XXX/32 - HTTPS, Protocol: TCP, Port Range: 443, Source:
0.0.0.0/0 - HTTPS, Protocol: TCP, Port Range: 443, Source:
::/0
Outbound Rules:
- All Traffic, Protocol: All, Port Range: All,
0.0.0.0/0
Create a new Network Access Control List. Associate your NACL explicitly with your subnets. Get your IP from http://whatismyip.host or a similar service.
Suggested name: PentestingMachines-NACL
Inbound rules:
- Rule #100: SSH (22), Port Range: 22, Source:
XXX.XXX.XXX.XXX/32, ALLOW - Rule #200: All ICMP - IPv4, Port Range: ALL, Source:
0.0.0.0/0, ALLOW - Rule #300: All TCP, Port Range: 0-65535, Source:
0.0.0.0/0, ALLOW - Rule *: All Traffic, Port Range: ALL, Source:
0.0.0.0/0, DENY
Outbound rules:
- Rule *: All Traffic, Port Range: ALL, Source:
0.0.0.0/0, DENY
Create a new Internet Gateway.
Suggested name: PentestingMachines-IGW
If you need a new route table, then create one. Associate your new (above) subnets explicitly with this route table.
Add a new route for 0.0.0.0/0 to point to your new Internet Gateway, so regular internet traffic can work correctly.
Suggested name: PenPentestingMachines-RT
Allocate a new Elastic IP. Allow it to be reassociated. Associate your instance with this IP.
Ensure that it uses your new security group and VPC!