Here is the use case
We have multiple ec2 instances within a VPC.
We want to allow access certain websites related to our work only and block the rest.
The list is not static and we may need to add more sites based our policy.
Security Group - outbound rules allow traffic based on only IP not websites.
Is there any way to allow or block traffic in ec2 instance based on the websites?
Firewall may be one option, but updating rules to multiple machines might be an overhead.
Thanks
You can try blocking traffic from a single IP/IP ranges,just by doing following things:
Open your VPC dashboard.
Open the Network ACL.
Open the ACL editor and add a rule to block the traffic.
This is a reference tutorial link for the same.
Blocking traffice in EC2
Related
Is it possible to block an entire country from access my website within a security group rule in an Amazon EC2 instance instead of using iptables or something else?
As the others commented, it is hard to block the traffic from particular countries, if someone is smart enough to use a proxy.
But you can use some simple ways to filter most traffic from a range of IPs (not all customers know to use proxy)
One is to set Network ACL in aws. Please go though aws document Network ACLs as a start.
Another way if you can manage route 53 for your website, enable geolocation route policy and transfer the traffic from some countries to a fake website. You can go through the document here Choosing a Routing Policy
Using Amazon VPC, what is the best possible way to attach multiple instances to a single ip address?
My company needs the ability to open/shutdown instances upon request and traffic. All instances created must have the same ip address attached, as the service I try to connect to allows only certain IPs that I can define every once in a while.
You want to use Elastic Load Balancer (ELB). It was built specifically for the purpose of balancing a large number of requests to the same IP across several EC2 instances.
http://aws.amazon.com/elasticloadbalancing/
If you want to whitelist the IPs of your instances to some other third party service, then you would have to use elastic IPs in that case. You can not associate one IP to more than one instance.
However, if you want only one endpoint for your service, you can very well use load balancer as also suggested above.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Currently moving to Amazon EC2 from another VPS provider. We have your typical web server / database server needs. Web servers in front of our database servers. Database servers are not directly accessible from the Internet.
I am wondering if there is any reason to put these servers into an AWS Virtual Private Cloud (VPC) instead of just creating the instances and using security groups to firewall them off.
We are not doing anything fancy just a typical web app.
Any reason to use a VPC or not using a VPC?
Thanks.
NOTE: New accounts in AWS launch with a "default VPC" enabled immediately, and make "EC2-Classic" unavailable. As such, this question and answer makes less sense now than they did in August 2012. I'm leaving the answer as-is because it helps frame differences between "EC2-Classic" and the VPC product line. Please see Amazon's FAQ for more details.
Yes. If you're security conscious, a heavy CloudFormation user, or want complete control over autoscaling (as opposed to Beanstalk, which abstracts certain facets of it but still gives you complete access to the scaling parameters), use a VPC. This blog post does a great job summarizing both the pros and cons. Some highlights from the blog post (written by kiip.me):
What’s Wrong with EC2?
All nodes are internet addressable. This doesn’t make much sense for nodes which have no reason to exist on the global internet. For example: a database node should not have any public internet hostname/IP.
All nodes are on a shared network, and are addressable to each other. That means an EC2 node launched by a user “Bob” can access any of EC2 nodes launched by a user “Fred.” Note that by default, the security groups disallow this, but its quite easy to undo this protection, especially when using custom security groups.
No public vs private interface. Even if you wanted to disable all traffic on the public hostname, you can’t. At the network interface level each EC2 instance only has one network interface. Public hostnames and Elastic IPs are routed onto the “private” network.
What's Great About the VPC
First and foremost, VPC provides an incredible amount of security compared to EC2. Nodes launched within a VPC aren’t addressable via the global internet, by EC2, or by any other VPC. This doesn’t mean you can forget about security, but it provides a much saner starting point versus EC2. Additionally, it makes firewall rules much easier, since private nodes can simply say “allow any traffic from our private network.” Our time from launching a node to having a fully running web server has gone from 20 minutes down to around 5 minutes, solely due to the time saved in avoiding propagating firewall changes around.
DHCP option sets let you specify the domain name, DNS servers, NTP servers, etc. that new nodes will use when they’re launched within the VPC. This makes implementing custom DNS much easier. In EC2 you have to spin up a new node, modify DNS configuration, then restart networking services in order to gain the same effect. We run our own DNS server at Kiip for internal node resolution, and DHCP option sets make that painless (it just makes much more sense to type east-web-001 into your browser instead of 10.101.84.22).
And finally, VPC simply provides a much more realistic server environment. While VPC is a unique product to AWS and appears to “lock you in” to AWS, the model that VPC takes is more akin to if you decided to start running your own dedicated hardware. Having this knowledge beforehand and building up the real world experience surrounding it will be invaluable in case you need to move to your own hardware.
The post also lists some difficulties with the VPC, all of which more or less relate to routing: Getting an internet gateway or NAT instance out of the VPC, communicating between VPCs, setting up a VPN to your datacenter. These can be quite frustrating at times, and the learning curve isn't trivial. All the same, the security advantages alone are probably worth the move, and Amazon support (if you're willing to pay for it) is extremely helpful when it comes to VPC configuration.
Currently VPC has some useful advantages over EC2, such as:
multiple NICs per instance
multiple IP's per NIC
'deny'-rules in security-groups
DHCP options
predictable internal IP ranges
moving NICs and internal IPs between instances
VPN
Presumably Amazon will upgrade EC2 with some of those features as well, but currently they're VPC-only.
VPCs are useful if your app needs to access servers outside of EC2, e.g. if you have a common service that's hosted in your own physical data center and not accessible via the internet. If you're going to put all of your web and DB servers on EC2, there's no reason to use VPC.
Right now VPC is the only way to have internal load balancers
If you choose RDS to provide your database services, you can configure DB Security Groups to allow database connections from a given EC2 Security Groups, then even if you have dynamic IP addresses in your EC2 cluster, the RDS will automatically create the firewall rules to allow connections only from your instances, reducing the benefit of a VPS in this case.
VPS in the other hand is great when your EC2 instances have to access your local network, then you can establish a VPN connection between your VPS and your local network, controlling the IP range, sub networks, routes and outgoing firewall rules, which I think is not what you are looking for.
I would also highly recommend trying the Elastic Beanstalk, which will provide a console that makes easy to setup your EC2 cluster for PHP, Java and .Net applications, enabling Auto Scaling, Elastic Load Balancer and Automatic Application Versioning, allowing easy rollback from bad deployments.
You have raised a good concern here.
I would like to focus on the viability in terms of cost...
What about the cost factor?
I think You will be paying for that server per hour. Even if you pick $20-$50 dollars a month instance it will be something you will pay the rest of your server life. The VPN server is something you can easily set on old hardware very cheap and even free for open source solution.
Adding VPN to existing AWS servers park make sense, setting a solo VPN server on AWS doesn't. I don't think it is the best cost-effective option but that just my opinion.
Thanks,
Alisa
Is there any way to make new instances added to an autoscaling group associate with an elastic IP? I have a use case where the instances in my autoscale group need to be whitelisted on remote servers, so they need to have predictable IPs.
I realize there are ways to do this programmatically using the API, but I'm wondering if there's any other way. It seems like CloudFormation may be able to do this.
You can associate an Elastic IP to ASG instances using manual or scripted API calls just as you would any other instance -- however, there is no automated way to do this. ASG instances are designed to be ephemeral/disposable, and Elastic IP association goes against this philosophy.
To solve your problem re: whitelisting, you have a few options:
If the system that requires predictable source IPs is on EC2 and under your control, you can disable IP restrictions and use EC2 security groups to secure traffic instead
If the system is not under your control, you can set up a proxy server with an Elastic IP and have your ASG instances use the proxy for outbound traffic
You can use http://aws.amazon.com/vpc/ to gain complete control over instance addressing, including network egress IPs -- though this can be time consuming
There are 3 approaches I could find to doing this. Cloud Formation will just automate it but you need to understand what's going on first.
1.-As #gabrtv mentioned use VPC, this lends itself to two options.
1.1-Within a VPC use a NAT Gateway to route all traffic in and out of the Gateway. The Gateway will have an Elastic IP and internet traffic then whitelist the NAT Gateway on your server side. Look for NAT gateway on AWS documentation.
1.2-Create a Virtual Private Gateway/VPN connection to your backend servers in your datacenter and route traffic through that.
1.2.a-Create your instances within a DEDICATED private subnet.
1.2.b-Whitelist the entire subnet on your side, any request from that subnet will be allowed in.
1.2.c Make sure your routes in the Subnet are correct.
(I'm skipping 2 on purpose since that is 1.2)
3.-The LAZY way:
Utilize AWS Opsworks to do two things:
1st: Allocate a RESOURCE Pool of Elastic IPs.
2nd: Start LOAD instances on demand and AUTO assign them one elastic ip from the Pool.
For the second part you will need to have the 24/7 instances be your minimum and the Load instances be your MAX. AWS Opsworks now allows Cloud Watch alarms to trigger instance startup so it is very similar to ASG.
The only disadvantage of Opsworks is that instances aren't terminated but stopped instead when the load goes down and that you must "create" instances beforehand. Also you depend on Chef solo to initiate your instances but is the only way to get auto assigning EIPs to your newly created instances that I could find.
Cheers!
We usually blacklist IPs address with iptables. But in Amazon EC2, if a connection goes through the Elastic Load Balancer, the remote address will be replaced by the load balancer's address, rendering iptables useless. In the case for HTTP, apparently the only way to find out the real remote address is to look at the HTTP header HTTP_X_FORWARDED_FOR. To me, blocking IPs at the web application level is not an effective way.
What is the best practice to defend against DoS attack in this scenario?
In this article, someone suggested that we can replace Elastic Load Balancer with HAProxy. However, there are certain disadvantages in doing this, and I'm trying to see if there is any better alternatives.
I think you have described all the current options. You may want to chime in on some of the AWS forum threads to vote for a solution - the Amazon engineers and management are open to suggestions for ELB improvements.
If you deploy your ELB and instances using VPC instead of EC2-classic, you can use Security Groups and Network ACLs to restrict access to the ELB.
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/USVPC_ApplySG.html
It's common to run an application server behind a reverse proxy. Your reverse proxy is layer you can use to add DoS protection before traffic gets to your application server. For Nginx, you can look at the rate limiting module as something that could help.
You could set up an EC2 host and run haproxy there by yourself (that's what Amazon is using anyways!). Then you can apply your iptables-filters on that system.
Here's a tool I made for those looking to use Fail2Ban on aws with apache, ELB, and ACL: https://github.com/anthonymartin/aws-acl-fail2ban