My requirement is :
For a given AWS account,automate to open a port xyz for all the VPCs of that account for a cidr x.x.x.x/x.Later we would like to apply the same for all the other aws accounts from aws organizations.
My approach is using boto3 api....Get the list of all the VPCs of given account,get it's attached SGs and NACLs and attach the required rule.
Or other solution is as per documentation given for aws network firewall.
I am here to know if there are any better ideas of implementing this.
Thankyou!
It is not possible to "open a port for VPCs".
Each resource attached to an Amazon VPC is associated with Security Group(s). You would need to add an Inbound rule to a Security Group to permit access to a resource.
I would highly recommend against blindly opening a particular port for all resources. It is much more secure to only open access to specific resources that require that access.
Echoing #jarmod's advice, in general you should not modify NACL rules unless you have a very specific reason to do so (eg for creating a DMZ). Security Groups provide adequate access control for the majority of situations.
Related
Periodic review of ssl_access https logs reveals more than a few pesky vulnerability probers out there. I wish to specifically block these inbound IPs in a programmatic way, e.g. aws ec2 authorize-security-group-ingress or similar. There is plenty of material describing how to restrict access to a few known IPs but I cannot seem to find anything that describes permitting all except a handful (perhaps a dozen or so).
You can't do that with security groups. Your options are:
AWS Network ACLs
AWS Web Application Firewall
Use something on your EC2 instance like fail2ban
Overview: Users will be logging into windows EC2 instance directly from their source ip and the source ip tends to change often.
Current State: We have provided IAM users access to modify/create/delete security groups.
Need: Users have an option to add wide open security group rules, which expose unnecessary vulnerabilities.
Is there a way to restrict users adding wide open inbound access(0.0.0.0) to security group rules/restrict them to add only their source ip to the inbound access rule of the security group?
My initial Findings: I checked the IAM docs, I didn't find any way to achieve this. Is there any better workaround to achieve this rather than getting alert/notification after they have added a wide open security group rule?
Unfortunately you've combined two separate things: who can configure security groups (which is managed by IAM permissions), and how security groups are configured (which is up to EC2). You can't do what you've asked for in IAM alone.
This example on the AWS blog shows how you can use Systems Manager to remediate security groups automatically. It's possible that AWS Firewall Manager can help too, but I haven't used it myself.
I would like to create simple rule in AWS security group which would, by default, enable access to specific port ONLY to the instances running in specific AWS region (for example: us-east-1).
I know that security groups are tied to specific AWS region and with that assumption, I thought there is some straightforward way to create rule in security group for specific port which would disable access for requests coming from instances in other AWS regions.
While google-ing around, I've found a list of ip ranges for specific regions on AWS: https://ip-ranges.amazonaws.com/ip-ranges.json but list is not small so adding list of all ip ranges for specific region would be my last resort.
Thanks in advance.
The list that you are referencing ip-ranges.json only lists AWS resources and not other IP addresses that may exist in other regions.
Security groups are not tied to an AWS region. Security Groups are a software defined network (SDN) firewall attached to a network interface. Security Groups have no inherit knowledge of AWS Regions.
Short of using geolocation, there is no reliable method to know where traffic originates when it arrives at the AZ of your instance. An AWS region does not use only a specified IP address range. An AWS region can change the addressing ranges (adding, deleting, etc.) at any time. AWS supports Bring Your Own IP which further makes this impossible.
I have hosted few services on AWS however all are public and can be accessed from anywhere which is a security threat, could you please let me know how to keep the services specific to internal users of organization without any authentication medium.
I found a workaround for this, if you have list of IP range may be a network administrator can help you, take that and put them in load balancers under security group.
You should spend some time reviewing security recommendations on AWS. Some excellent sources are:
Whitepaper: AWS Security Best Practices
AWS re:Invent 2017: Best Practices for Managing Security Operations on AWS (SID206) - YouTube
AWS re:Invent 2017: Security Anti-Patterns: Mistakes to Avoid (FSV301) - YouTube
AWS operates under a [Shared Responsibility Model, which means that AWS provides many security tools and capabilities, but it is your responsibility to use them correctly!
Basic things you should understand are:
Put public-facing resources in a Public Subnet. Everything else should go into a Private Subnet.
Configure Security Groups to only open a minimum number of ports and IP ranges to the Internet.
If you only want to open resources to "internal users of organization without any authentication medium", then you should connect your organization's network to AWS via AWS Direct Connect (private fiber connection) or via an encrypted VPN connection.
Security should be your first consideration in everything you put in the cloud — and, to be honest, everything you put in your own data center, too.
Consider a LEAST PRIVILEGE approach when planning Network VPC Architecture, NACL and Firewall rules as well as IAM Access & S3 Buckets.
LEAST PRIVILEGE: Configure the minimum permission and Access required in IAM,Bucket Policies, VPC Subnets, Network ACL and Security Groups with a need to know White-list approach.
Start from having specific VPCs with 2 Main Segments of Networks 1-Public and the other 2-Private.
You will place your DMZ components on the Public segment,
Components such as Internet Facing Web Server, load Balancers,
Gateways, etc falls here.
For the Rest such as Applications, Data, or Internal Facing
LoadBalancers or WebServers make sure you place them in the Private
Subnet where you will use an Internal IP address from specified
Internal Range to refer to the Components Inside the VPC.
If you have Multiple VPCs and you want them to talk with each
other you can Peer them together.
You also can use Route53 Internal DNS to simplify naming.
Just in case, If you need to have Internet access from the Private segment
you can Configure a NAT Gateway on the public subnet and handle
Outgoing Traffic routed to Internet from the NAT Gateway.
S3 Buckets can be Configured and Servered as VPC-END points. (Routing via an Internal Network rather than Internet Routed to S3 Buckets/Object).
In IAM you can create Policies to whitelist source IP and attached to Roles and Users which is a great combination to Mix Network VPN Connections/white-listed IPs and keep Network Access in harmony with IAM. That means even Console Access could be governed by a White-listed Policy.
I able to find that in my research there are some of the ways to find all our aws resources but will you suggest any solution to find public resources in aws our account.
Unfortunately, there is no easy way that you can find all resources that are allowed to communicate with outside world. However, the only way for most of the resources in AWS can connect to the internet through a VPC that is configured to allow access to 0.0.0.0/0 network with Security Group and ACL. So what you can do is to search for VPC ID on resources categories and if any results you get can connect to the internet.
This can be a very tedious task and this is NOT 100% guaranteed to find all resources as some resources has self-sustained VPC per resource such as S3. So my suggestion is you get used to using tags for resources.
Also maybe think about using infrastructure as code approach using something like Terraform.
If you have all of your instances in a VPC you could enable VPC Flow Logs on your VPC and then monitor all VPC traffic that way.
For the instances that are not in VPC's you could have CloudWatch logs enabled for that instance and then monitor the traffic that way.
Your instances should have security groups attached to them so that you could monitor the rules, and see if you have an OutBound Set to 0.0.0.0/0
You can give Netflix's Security Monkey a try. The tool will make a complete report of all secure and insecure AWS assets including Security Groups, IAM Policies and S3 Buckets. In fact, it also provides a ticketing like system to collab on such problems.
You can use IAM Access Analyzer console