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.
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
i have more than 30 production Windows severs in all AWS regions. I would like to connect all servers from one base bastion host. can any one please let me know which one is good choice? How can i setup one bastion host to communicate all servers which is different regions and different VPC's? Kindly anyone give advice for this?
First of all, I would question what are you trying to achieve with a single bastion design? For example, if all you want is to execute automation commands or patches it would be significantly more efficient (and cheaper) to use AWS System Manager Run Commands or AWS System Manager Patch Manager respectively. With AWS System Manager you are getting a managed service that offers advance management capabilities with highest security principles built-in. Additionally, with SSM almost all access permissions could be regulated via IAM permission policies.
Still, if you need to set-up bastion host for some other purpose not supported by SSM, the answer includes several steps that you need to do.
Firstly, since you are dealing with multiple VPCs (across regions), one way to connect them all and access them from you bastion's VPC would be to set-up a Inter-Region Transit Gateway. However, among other, you would need to make sure that your VPC (and Subnet) CIDR ranges are not overlapping. Otherwise, it will be impossible to properly arrange routing tables.
Secondly, you need to arrange that access from your bastion is allowed in the inbound connections of your target's security group. Since, you are dealing with peered VPCs you will need to properly allow your inbound access based on CIDR ranges.
Finally, you need to decide how you will secure access to your Windows Bastion host. Like with almost all use-cases relying on Amazon EC2 instances, I would stress to keep all the instances in private subnets. From private subnets you can always reach the internet via NAT Gateways (or NAT Instances) and stay protected from unauthorized external access attempts. Therefore, if your Bastion is in private subnet you could use the capability of SSM to establish a port-forwarding session to your local machine. In this way, you enable yourself the connection while even your bastion is secured in private subnet.
Overall, this answer to your question involves a lot of complexity and components that will definitely incur charges to your AWS account. So, it would be wise to consider what practical problem are you trying to solve (not shared in the question)? Afterwards, you could evaluate if there is an applicable managed service like SSM that is already provided by AWS. In the end, from a security perspective, granting access to all instances from a single bastion might not be best practice. If you consider scenarios in which you bastion is compromised for whatever reason, you basically compromised all of your instances across all of the regions.
Hope it gives you slightly better understanding of your potential solution.
Please help
We blocked all the outgoing traffic by removing 0.0.0.0/0 and added only our VPC so as our application connects to the EC2
Now the problem is EC2 is not able to communicate with any of AWS Services itself; we are not able to use SSM, update our RPM, etc. ..
we added few of the IP range based on the errors we faced; which we fear not the correct way of blocking the outbound connections
Thank you, appreciate your support in advance
You should actually take a look at using VPC endpoints where possible within your VPC.
If you configure these outbound communication will be via the subnet ranges that the interface endpoints are located in with the exception of S3 and DynamoDB.
If you use either of these services, in the outbound of the security group you can whitelist the source of the prefix list for these services.
By doing this its easier to manage (AWS IP ranges change all the time), and is more secure as the egress stays within the AWS network never connecting to the service endpoints via the public internet.
If this approach is not for you, you would need to subscribe to ip-range changes which would trigger a Lambda function. This Lambda function would access the ip-ranges.json file and retrieve all ranges valid for your application. These IP ranges would then be added to a customer managed prefix list that you define.
The prefix list would be added as an outbound destination allowing port 443 (HTTPS) outbound access, of course this method would require you to build the Lambda function.
I have EC2 Instance with Windows Server, i'm using it only with RDP. Can I somehow block outbound traffic from browser to specific domain (eg. abc.example.com) or URL? I'd rather do it in the AWS Dashboard so that RDP users do not have access to whitelist this domain/URL.
How can I achieve this? Thanks!
There is not a native AWS solution for this, of course you could allow only specific IP addresses. The problem with this is for domains these may change, when you look at Cloud you can see that many services (such as load balancers and CDNs) will be changing their IP address.
The ideal solutions is that you would deploy a software (running on EC2) that is able to filter outbound traffic based on domain name. There are solutions on the AWS Marketplace, as well as filtering using a dumb proxy.
The network setup would involve you creating a number of subnets containing the EC2 instances. These would have a route table forwarding all traffic (0.0.0.0/0) to a NAT.
Then for all applications that need to have their outbound traffic filtered they would update their route table to route all traffic (0.0.0.0/0) to the ENI of one of the filtering hosts (ideally in the same AZ).
More information: https://aws.amazon.com/blogs/security/how-to-set-up-an-outbound-vpc-proxy-with-domain-whitelisting-and-content-filtering/
You can configure Access Control Lists (ACL) and Security Groups to filter outbound traffic. However, both of those tools only allow filtering based on IP address, not domain.
If you are confident that the IP addresses won't change, then you can configure these services. If you aren't interested in maintaining a blacklist, then you might need to check on some OS-level limits.
The simplest and easiest way is to implement an Aviatrix FQDN egress filter. It just serves the purpose from a centralized user interface to whitelist/blacklist the URLs in every VPC.
Next Generation Firewall (NGFW) implementation, just to achieve URL / FQDN filtering is an overkill, esp. from the cost point of view whereas proxy implementation has its complexity and doesn't provide centralized control, every VPC has to be managed separately.
The easiest way is to get an Aviatrix launch partner like SDxWORx, enable it with discounted PAYG pricing.
https://aws.amazon.com/marketplace/pp/prodview-laruhupdkcpuy/
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.