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
Related
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.
I have an Apache server running on an EC2 instance, from which I am serving a PHP webpage that lists EC2 instances under my account, allows for toggling them on/off, etc.
The problem is that the AWS SDK call (specifically describeInstances, but in general) can't reach the endpoint. I have looked into what IP ranges AWS uses, described here. I would like to avoid putting all of those IP ranges into my security group if possible. Because the endpoint resolves to different IPs in different requests, there doesn't seem to be one IP range that will work (besides 0.0.0.0/0, which I don't want to use).
Is there a way to allow outbound access to specifically AWS-provided services without manually entering all of these IP ranges? It seems like there should be a better way to do this.
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
I would like to restrict access to objects stored in an Amazon S3 bucket.
I would like to allow all the users on our LAN (they may or may not have amazon credentials since the entire infrastructure is not on AWS). I have seen some discussion around IP address filtering and VPC endpoint. Can someone please help me here? I am not sure if I can use VPC endpoint since all users on our lan are not in Amazon VPC.
Is this possible?
Thanks
Most likely your corporate LAN uses static IP addresses. You can create S3 policies to allow access (or deny) based upon IP addresses. Here is a good AWS article on this:
Restricting Access to Specific IP Addresses
VPC Endpoints are for VPC to AWS Services connectivity (basically using Amazon's private Internet instead of the public Internet. VPC Endpoints won't help you with Corporate connectivity (except if you are using Direct Connect).
Here is how I would solve it,
Configure
Configure Users from a corporate directory who use identity federation with SAML.
Create Groups
Apply Policies to Group
This will give fine-grained control and less maintenance overhead.
This will help you not only to control S3 but any future workloads you migrate to AWS and permissions to those resources as well.
IP based filtering are prone to security risk and with high maintenance in the long run and not scalable.
EDIT:
Adding more documentation to do the above,
Integrating ADFS with AWS IAM:
https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/
IAM Groups:
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_create.html