Are GCP default firewall-rules a security-concern? [closed]

Question

Whenever you create a project in GCP there is a default firewall-rule called: "default-allow-ssh", which allows 0.0.0.0/0 on port 22, which makes it easy to ssh into the machines with external ip from the browser. But that allows any machine from the internet to access my machine on port 22, and bots are constantly trying to access whatever they can find. I suppose they would still need to crack the password or ssh-key or something, but isn't that a very dangerous default setup rule? There are not really any warnings when you spin up a new machine with external-ip, and I was expecting GCP to have a more restricted approach. If anyone can help me clarify this, it would be much appreciated. And if I remove this default rule and still want to access my machines through ssh, which approach would be simple and secure?

Megen

Answer 1

Without this rule, when you try to SSH in using the gcloud command-line tool, the request would be immediately rejected, so AFAIK, the Compute Engine's choice here was optimized toward ease of getting started with GCE.

I also think that password authentication is disabled by default, so any attacker has two avenues of entry:

1. Crack an SSH private key
2. Exploit a vulnerability in the SSH agent binary

I think the first is pretty far fetched given today's technology. If this were sufficiently easy, we'd have much bigger problems in the world.

The second seems like something to worry about if you didn't have automatic security patches deployed by Google Cloud Platform on a regular basis. Yes, this is still vulnerable to 0-day exploits, but given that Google's security team were the ones who discovered several of the recent security vulnerabilities in popular projects (e.g., I'm pretty sure that Heartbleed was discovered, patched, and disclosed by Google), it's pretty likely that if there were a security bug in the SSH agent used by all of GCE VMs, Google would get it patched faster than anyone else would.

That said, if you really don't like this rule, I'm pretty sure you can go in and change the rule's definition so that it only allows some specific list of IPs or subnets by default for all of your VMs.

Darden

Answer 2

You can see the log where some are trying to access your ssh if you don't change the default ssh configuration:

$ cat /var/log/auth.log | grep sshd
Sep 25 00:30:22 webserver sshd[692]: Server listening on 0.0.0.0 port 22.
Sep 25 00:30:22 webserver sshd[692]: Server listening on :: port 22.
Sep 25 00:36:39 webserver sshd[757]: Connection closed by 54.38.240.250 port 37596 [preauth]
Sep 25 00:48:45 webserver sshd[822]: Invalid user ftp from 195.50.5.30 port 53050
Sep 25 00:48:45 webserver sshd[822]: input_userauth_request: invalid user ftp [preauth]
Sep 25 00:48:45 webserver sshd[822]: Connection closed by 195.50.5.30 port 53050 [preauth]
Sep 25 00:58:43 webserver sshd[896]: Connection closed by 5.39.77.131 port 37428 [preauth]
Sep 25 01:01:01 webserver sshd[911]: Connection closed by 92.238.55.31 port 46940 [preauth]
Sep 25 01:01:47 webserver sshd[919]: Connection closed by 92.238.55.31 port 47690 [preauth]
Sep 25 01:06:25 webserver sshd[977]: Connection closed by 118.25.45.196 port 48778 [preauth]
Sep 25 01:22:19 webserver sshd[1093]: Connection closed by 18.144.67.59 port 50210 [preauth]
Sep 25 01:22:27 webserver sshd[1095]: Unable to negotiate with 18.144.67.59 port 60026: no matching host key type found. Their offer: ecdsa-sha2-nistp384 [preauth]
Sep 25 01:22:39 webserver sshd[1098]: Unable to negotiate with 18.144.67.59 port 47974: no matching host key type found. Their offer: ecdsa-sha2-nistp521 [preauth]
Sep 25 01:22:54 webserver sshd[1100]: Connection closed by 18.144.67.59 port 35310 [preauth]
Sep 25 01:23:03 webserver sshd[1102]: Unable to negotiate with 18.144.67.59 port 45398: no matching host key type found. Their offer: ssh-dss [preauth]
Sep 25 01:26:51 webserver sshd[1127]: Invalid user mc from 195.50.5.30 port 40116
Sep 25 01:26:51 webserver sshd[1127]: input_userauth_request: invalid user mc [preauth]
Sep 25 01:26:51 webserver sshd[1127]: Connection closed by 195.50.5.30 port 40116 [preauth]
Sep 25 02:05:02 webserver sshd[1404]: Invalid user celery from 195.50.5.30 port 55410
Sep 25 02:05:02 webserver sshd[1404]: input_userauth_request: invalid user celery [preauth]
Sep 25 02:05:02 webserver sshd[1404]: Connection closed by 195.50.5.30 port 55410 [preauth]

As long as you use public key/private key in proper way, it should be OK, but I want to decrease the chance to be attacked, so I always do the following:

Please make sure that you create your public key/private key pair and register the public key to your gcp's instance configuration and confirm that you can do ssh.

Then I make some limitation to use the ssh like allowing ssh connection only from limited range of IP address.

Check your IP from whatismyip or something, then, let's say my IP is 95.24.79.236 (this is not actually my IP though), I usually change the allowed IP range to 95.24.79.0/24 which would allow 95.24.79.0 - 95.24.79.255, which would be than completely open to all IP range.

After that, I change the ssh's port number 22 with a port between 1024 and 65536. You can change the port number of ssh by:

1. Change firewall rule of GCP's "default-allow-ssh" to replace the port 22 with some other number.
2. Get into your gcp server then make a backup of your config:

$ sudo cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.org

3. Let's say I will change the port to 2222 for example. Then you can change the port number by running this:

$ sudo sed -i -e "s/#Port 22/Port 2222/g" /etc/ssh/sshd_config

4. Reload sshd:

$ sudo systemctl restart sshd

5. Now you can do ssh by:

$ ssh -p 2222 user@your-gcp-external-ip

Wingover