What I don't get is how that's secure or workable if your public IP
address is dynamic?
This solution could work if you find your IP doesn't change often, or if you only need access for a short time. It adds an extra layer of security as SSH isn't exposed to traffic outside of the CIDR you supply.
If a specific CIDR doesn't work, you could try on or more board CIDR ranges that your ISP is likely to use, this will still limit access from a large percentage of the Internet, and that's a win for security.
what happens when my ISP changes my public IP and I can no longer ssh
into my instance?
You can login to the AWS Console, or use the CLI to update the Security Group rule on the fly.
You could write a script that interacts with the CLI directly. It could be as simple as something that checks for the Port 22 rule
against your current IP and updates it if it's different. Of course running such a script might raise more security questions itself :)
Is an IP firewall the best way to secure SSH?
While it's nice to limit ssh traffic to only trusted IP sources where practical, the thing that makes ssh secure is the use of private keys and sensible configuration.
Key items to consider:
- Add a passphrase to your SSH private key
- Disable password auth to SSH
- Disable root login to SSH
- Audit all user accounts for SSH public keys
You could also do a few things to get rid of the 'noise' associated with brute force attacks:
- Run ssh on a higher port
- Use software like fail2ban which will dynamically log numerous failed attempt and block IP ranges for specified periods of time
It seems to be an issue with the default security group when I created the ecs cluster
The default SG is
So basically no traffic can reach the ec2 instance that hosts the docker process.
I added a very permissive security group and it is working and I can reach the healthcheck url
Best Answer
TL/DR: the way bridge networking works is by assigning a port number to the task and expose it to the main ENI of the instance. So you would not hit any ENI/IP limit. If you are still eager to take advantage of the plus of AWS VPC networking mode you may be exploring the Trunk ENI solution that allows you to create virtual ENI to overcome the number of ENIs limit you are pointing out.
The full story: https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/networking-networkmode.html
Also, have you considered Fargate? It hides ALL of this and more.