I am trying to implement automatic deployment from Codeship by using a Capistrano style script to allow it to SSH onto my servers and pull from my git repository after my tests have passed. The problem is that SSH access to the servers is restricted by IP address, and Codeship advise that you should open up your firewall to the range of IP addresses that AWS use for their east coast EC2 instances: https://codeship.com/documentation/faq/enabling-access-to-servers/
However, I am not sure about doing this because there is a large number of IP addresses: https://ip-ranges.amazonaws.com/ip-ranges.json
My concern is, apart from this being a tedious process (there are 43 IP address ranges for east coast EC2), does this not defeat the purpose of restricting IP addresses, as it would make this precaution useless if a potential attacker were to use an east coast EC2 instance?
Assuming your instance is hosted within the same region as Codeship (us-east-1) then your best bet is to setup an EC2 security group as described here.
I appreciate that this isn't the case for everyone, so assuming you're using iptables then I'd suggest a similar approach to that described in CloudFlare's documentation and to setup a bash script run through a crontab to keep the current ip ranges up to date should they change.
In regards to security, since you're opening the port to the entire AWS region, yes there is an increased attack surface. It sounds like you've already disabled password auth, so brute force attacks are unlikely, but a sensibly configured fail2ban jail should take care of most of the nasties.
Related
I have an Amazon EC2 instance that hosts different services (cassandra db, elasticsearch, rabbitmq, mysql...) used by several developers at different locations. Since these developers have dynamic IP addresses, and this EC2 instance is used only for development, I left inbound access to required ports opened to 0.0.0.0. I'm aware that this is absolutely not recommended, and I should limit access, but I don't want to change the rules every day as someone's IP address change.
However, I just got report from Amazon that my instance is used for DoS attack, so I would like to fix this.
My question is if it is possible to make a rule that will limit access to several ranges such as:
94.187.128.0 - 94.187.255.255
147.91.0.0 - 147.91.255.255
Definitely yes, because the ranges you meant aren't just ranges but match CIDR.
The range which cannot be expressed as CIDR won't be accepted:
You can use IPcalc or similar site to make it easier.
If it fits you, you can use port range like 2000-3000, or, better, use custom ports for the services. Then the range will be e.g. 2000-2001, and using port ranges you can fit one user into one rule.
Alternative, more secure but more difficult way: a web page, user connects there with proper security key. If the key is recognized then a script on the server adds rule to a group using the client's IP. Another script by cron deletes the rules older than X hours. To check it deeper you may want to look e.g. here: On apache side check Two-way SSL authentication, on AWS side check API and Command Overview
Amazon only gives you a certain number of static ip address and the local (private) ips of each EC2 instance can change when the machine is restarted. This makes creating a stable platform where EC2 instances depend on each other ridiculously hard to use as far as I can tell.
I've search online a lot about various solutions and so far have found nothing reasonable outside of assigning an elastic ip address on ever EC2 even if its not public facing. Does anyone have any other good ideas that is actually easy to execute on?
Thanks!
See the AWS team's response to question Static local IP:
The internal IP address of EC2 instances is allocated via DHCP. On
instance shutdown, or when the DHCP lease expires, the IP address is
returned to the general EC2 DHCP pool of addresses available for other
instances.
There is no way to guarantee that you will obtain the same DHCP
address across reboots.
Edit: The answer is to use Amazon VPC. There is no downside except a trivial amount of extra setup because now you control the router. It's a world apart from plain old EC2 instance on AWS. It's so necessary in fact that VPC will be enabled for all future AWS setups by default. See this post for more information: http://www.reddit.com/r/aws/comments/1a3n0r/ec2_update_virtual_private_clouds_for_everyone/
The stock answers are:
Use AWS VPC so you have complete control over instance addressing
Use Elastic IPs, which will resolve to the instance's local address (not the public, as you'd expect) when used to communicate between EC2 instances
I stumbled upon third option. There's ec2-ssh by the Instragram folks. It's a python shell script that you install globally and lets you both query the public dns of your ec2 instances by tag name and also ssh in via tag name as well.
The documentation for it is virtually nonexistent. I've written down the steps to install below:
To install ec2-ssh:
sudo yum install python-boto (python wrapper for ec2 api)
git clone https://github.com/Instagram/ec2-ssh
In your ~/.bash_profile set your AWS access key and secret like so:
export AWS_ACCESS_KEY_ID=XYZ123
export AWS_SECRET_ACCESS_KEY=XYZ123
cd into the bin folder of the repo, there will be two files:
ec2-host and ec2-ssh
copy them to your /usr/bin or /usr/local/bin.
Now you can do awesome stuff like:
$ ec2-host ZenWorker
ec2-999-xy-999-99.compute-1.amazonaws.com
and
$ ec2-ssh ZenWorker
Connecting to ec2-999-xy-999-99.compute-1.amazonaws.com.
Note that in your regular shell scripts you can use backticks to call these global tools. I've timed these calls and they take between 0.25 and 0.5 second using an EC2 instance, so that's really the only downside. Perhaps you can live with the delay, or use the fact that public DNS only changes for an instance on reboot to work up a solution.
Note that these two programs are commandline scripts and you don't need any Python knowledge to use them. For PHP fans, or those that also want an easy way to scp files without knowing the changing public DNS, you can checkout ec2dns.
I was in the same situation once. I still dont have the expertise to solve it properly. My ugly solution was to use elb not really for load balancing but just for the endpoint.
But I think a good solution can be obtained by using aws vpc.
Here's another Ruby solution for Updating Route 53 DNS from instance on AWS. You shouldn't reference raw 3rd party system IP addresses in your applications or server configurations.
you can change Ip Address using Elastic Ip:
You Can Do Using C# Code:
var associateRequest = new AssociateAddressRequest
{
PublicIp = your Elastic Ip,
InstanceId = Your Instance Id Which You Assign
};
amazonEc2Client.AssociateAddress(associateRequest);
after That DeAssociate It.
var disAssociateRequest = new isassociateAddressRequest(publicIp.ElasticIpAddress1);
AmazonEc2Client.DisassociateAddress(your Elastic Ip);
your Public Ip Will Change
I want to use the Amazon Web Service free micro-instance for my different projects for testing and personal purpose. But I required some static-public IP on which I can run my server.
Is that possible? From where I can buy just IP and use it with my AWS?
EC2 Elastic IP Addresses
Elastic IPs are tied to an account, not an instance.
You need to look at AWS VPC for this.
Whilst VPC is free outside of the usual instance pricing, it doesn't work with Micro instances (the cheapest ones).
When not using VPC, you're assigned IP addresses through DHCP. When the DHCP lease expires, or you restart, your IP is released back to the pool.
VPC lets you use private IP addressing, you can use it with Elastic IPs and is much easier to integrate with a physical infrastructure setup.
If you're only testing/investigating AWS and have little or no budget to use anything other than a Micro instance, I'd just suck it up and deal with the changing of IPs.
If you've got a budget that lets you use instances other than Micro, then go for VPC.
Also, if you're doing more than testing/investigating I'd recommend starting with VPC straight away as trying to migrate from a non VPC to a VPC infrastructure is a massive PITA.
For every AWS account, 5 free elastic ips are provided. You have to just allocate them to required instance. But make sure that the allocate address(newly created elastic ip) in in use, because you will billed if the Elastic ip is not in use.
Looks like they have configured ARP statically so you can only use the IP address on an instance that was bound to that instance through the EC2 management console.
I just configured one of my instances to use a static IP address other than the one assigned through the management console and rebooted the instance.
I'm still receiving ARP responses on the old address but not receiving ARP responses on the new address at all.
Unfortunately for me, I have a not responding instance (NFS File Server) stuck in a stopping state while I attempt to terminate it.
The IP Address bound to that instance cannot be re-assigned to a replacement instance so now I have to reconfigure
On the whole pricing delima: When you come to think of it, there is a limited amount of static IPs so there must some pricing (supply and demand). This pricing is two fold: 1) for upto a limited number (5 per account) you don't have to pay. 2) if you created one you need to use it if you don't you'll be billed (to prevent every user to get 5 static IPs)
I sell a product that runs on Amazon EC2. A company now wants to purchase and install it within their perimeter... This also implies the use of a VPN connection to the EC2 datacenter.
I want to test my product using Amazon VPN (VPC) before handing over the code. Must I change my code to make it work across VPC? If I run on Windows, then wants the quickest and easiest desktop VPN client avaialable that will allow me to connect across VPN to the Amazon datacenter?
Make sure you setup NAT servers and set your routes in the AWS console. Your client can have some security infrastructure for extending their data center to the cloud - firewall rules at the VPC level etc. Disable firewall rules on the server you deploy to since your VPC already takes care of this. As root execute the following command. service iptables stop (you probably already know this I am guessing)
Is it important for your app to run across VPCs?
Depending on how large the company you are selling to is, their security team may give them the run around to have VPC to VPC communication. Is it important for your software to span across VPCs?
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