Hello! I am a second year university student and I have been assigned to do a security configuration assessment on an AWS environment using the CIS AWS benchmarks. In the document they mention that no security groups or Network ACLs should be present that allows ingress from 0.0.0.0/0 to all ports. In my environment there is a bastion host that is being accessed over the Internet via SSH. The security group for the bastion host restricts connections from anything other than port 22 but all IP addresses are allowed (0.0.0.0/0). How would one minimise the opening by specifying IP addresses when no definite IP address can be set (multiple locations, different and constantly changing public IP addresses)? Or is this not an issue?
The internal hosts accessed through the bastion host have security groups in place that allow only connections from the bastion host.
SSM allows you to close port 22 entirely and access EC2 using AWS credentials. Ideally use SAML based authentication to generate short lived credentials.
If it’s a small company and doesn’t require heaps of access. You can create a script or something that runs a Linda to add and remove your IP after a particular amount of time. Say it adds your IP for 24 hours then removes it automatically. Then you could close port 22.
The other is using a VPN, but that just moves the public connection further downstream because the VPN would be open to the public as well. But a VPN server that only has access to the bastion host would be considered slightly more secure. Also Something like OpenVPN allows for MFA and domain managed auth and that can add extra security.
If you do leave 22 open to the world you want to ensure you have met the CIS benchmarks for security on it in relation to auditing, alerting and security. So start with things like fail2ban and cloudwatch alerts.
I personally think having to get temp creds from AWS to call a lambda and supply your IP before you can SSH is a really neat little trick. Even more so that it auto cleans them up.
If it is a small company, 0 security budget leave it like that - anyone ssh into the host, as long as they have the pem file, or ditch the ssh and use ssm session manager
If they are really adamant about ssh access security
setup a vpn between the outside network and the ec2 network. Ssh into the ec2 after connecting to the vpn
Furthermore if they have a budget and a desire to future proof their security posture, then a sso solution should be put in place. Something like okta. Allows the developer to login and assume role depending on what task they wan to accomplish. The assume role can be done using mfa.
Anything other than this ootions, gives the impression of playing whack a mole with the threat landscape.
I’ve used port knocking on a bastion for a small network and it worked reliably. Since the SSH port isn’t always open the host draws less attention. Three knocks on the specified, non-sequential ports opens the SSH port to your IP for a couple seconds. Just long enough to establish your connection then closes the port behind you.
If the locations are within the same geographic area e.g., the UK then you could geo-block IP addresses from outside the country. I would imagine if security was a concern you would use a static public IP and restrict it to just that. Getting one nowadays is very trivial and inexpensive. I even have a static for my home broadband.
Although there’s a little more to set up (AD, and some networking), we like using WorkSpaces as there’s a secure client that can be used from different platforms (Windows, MacOS, iPad, we even got it working on Google Chromebook) and it’s a client-based OS (Windows 10 / Linux).
You can configure the clients to spin down after a certain number of idle hours. There are different sizes for the clients (similar to EC2). They’re automatically backed up twice a day I think, and patches and updates are applied for you.
For security, we typically set one up for each user who needs bastion-type access…that way if they leave our company, we just delete their WorkSpace and AD entry.
We leave the bastion off until we leave it. Then, we only expose it to the IP address that’s needed (typically office IP / VPN). We use SSM to actually login so that you don’t have credential rotation to worry about.
Thank you for your input but users from multiple locations are going to be accessing the bastion instance so I think geo-blocking IPs based on their location will be a problem.
I tried this a few years ago. Wanted to use workspaces instead of openvpn for access to our internal tools. But, I found it painfully slow. Didn’t want to subjugate my coworkers to that. Maybe it’s gotten better?
we just started using it about nine months ago, so I can’t comment on any improvement, but I’m running Windows 10 on a 2 vCPU, 4GB ‘Standard’ configuration and it seems pretty nimble to me.
I’m not doing anything spectacular on it…just using it for browsing to sites that require a fixed source IP (our Workspaces go through a NAT Gateway to provide a single outbound source IP.) I can access those sites from the office or at home or anywhere b/c the IP is the same on my Workspace. Also for RDS access using tools like MySQL Workbench and Oracle SQL Developer.