When I try to create a new instance on AWS, I get a warning:<p>`Rules with source of 0.0.0.0/0 allow all IP addresses to access your instance. We recommend setting security group rules to allow access from known IP addresses only.`<p>What are alternative security measures that I can apply to protect my servers?
If you don't allow password logins so ssh only accepts public/private keypair authentication I think you have a secure setup. Limiting the IPs allowed to connect in the firewall will block the bots that probe port 22 and brute-force attacks, but those aren't going to succeed anyway. As far as I know it's not possible to brute force or otherwise hack ssh with ssl keypair authentication directly. An attacker would need access to your ssl private key. The ssh protocol resists MITM attacks as well.<p>If anyone knows about actual working attacks on ssh servers that don't allow password authentication I'd like to know about it. I don't mean state-level attackers who would probably hack into your laptop or strong-arm the hosting provider.
You could try using Tailscale. It's a wireguard based mesh VPN. Just set it up on your device, your server, and you're good to go. You can just only allow SSH over Tailscale, without worrying about anybody else trying to get in.<p>Other alternatives include ZeroTier and Nebula afaik, but I've never tried either.<p>(Still use SSH keys regardless though.)
Oracle has a generous free tier for OCI instances/VMs, and includes a public IP. You can use that as an ssh bastion/jumphost.<p>Or if don’t want to do business with Oracle, you can find VPS/VM providers who offer tiny instances for $10-12/yr or less. You don’t need much ram for a bastion. 128M ram would do the trick, and even 64M (you’d have to use a stripped down image/distro though).<p>There are even providers who offer instances for even less $ and only give you an ipv6 range + NAT IPv4 address with a small port range. This would also work perfectly fine as a bastion.
An AWS specific solution would be to use Systems Manager Sessions Manager to provide access into the instances and disallow all public access to the instances. No SSH. Identity is provided by IAM. As long as you use AWS cli and have configured it to login with your IAM creds, you can simply get a session via SSM. Added bonus is the ability to easily get an audit log in cloudwatch/S3. And no SSH keys/Linux user accounts to manage.<p>We use this for all our bastion hosts.
Set your current IP in the security group and update it whenever it changes. You could make the update through the aws cli, this way you don’t have to login into the console every time
ip=$(curl <a href="https://api.ipify.org" rel="nofollow">https://api.ipify.org</a>)<p>tag_name="tmpip"<p>tag_time=$(date -u '+%Y-%m-%dT%H:%M:%SZ')<p>aws ec2 authorize-security-group-ingress --group-id sg-86169665d2453e4 --protocol tcp --port 22 --cidr "$ip/32" --tag-specifications "ResourceType=security-group-rule,Tags=[{Key=Name,Value=${tag_name}},{Key=added,Value=${tag_time}}]"<p>The tag enables replacing the existing rule via tag Name, the further you go the easier it is to use the API SDKs
Use ssh pubkey auth and disable password. Set up a totp challenge after pubkey auth. Switch the default ssh port. Restrict ssh login to 1 user who's name isn't 'root' or 'ubuntu' or something everyone would look for. Wrap that in wireguard, and have ssh only listen on the wireguard interface if your worried, but that's an unnecessary extra step.
Even if you don’t have a static IP, you can probably restrict to a /24 subnet or maybe /16.<p>Additionally, you can ensure password access is disabled and use ssh keys along with 2FA.