To disable or not disable, that is the question ;) for ufw on cloud instances

Staking & Delegation Operate a Stake Pool
1

Just wondering how people handle ufw which is native to ubuntu 20.04 LTS regular installs in the cloud. If you try to configure ufw on the cloud and mess up, essentially locking yourself out of your own instance, then it looks like you have extra work to do to get back in, like via the website console login; therefore, I just removed/uninstalled ufw from my instance. GCE already has it’s own firewall I suppose, although I haven’t gotten that far yet.

What’s other people’s take on running ufw on the cloud, when the VM instance service provider already has it’s own firewall usually?

2

Hi,

Yes on google cloud / AWS and for other cloud providers the system is built so you don’t have to setup ufw on individual instances, but instead use built-in firewall and seperate each project in different project folders. But for extra security (like bp nodes) you can setup local fw.

Btw on google cloud you can also manage users from GCP console, so you don’t have to create users on individual instances. So a lot of things you can do directly from dashboard.

1 Like
3

Thanks for your help, Lauris.
The further I get into learning about servers, cloud instances, etc., the more I come to realize there is a dizzying array of choices on how to set up a server and protect it.

Take for example ssh’ing to your cloud instance. You can disable password entry and just use your private key to connect to your instance, this way avoiding a hacker brute-forcing your instance if you have a weak password and he has discovered your ssh port, and he has spoofed your public IP address, for example. In theory though, exposing your private key to the public network even though it’s through a secure ssh connection sounds a little sketchy. So an alternative to this would be use a strong ssh login password, do not use your private key to connect to your instance for long periods, but rather install a login attempt blocker on your instance, that jails IP addresses for a certain amount of time after a few attempts, this really will discourage them from trying to brute force your instance especially if the hackers sdon’t know if you have a strong password or not, but the downside to this is it adds bloat to your operating system resources since your running a IP blocking daemon. In either case they are both good solutions, but not 100% secure. The best way to secure a server I coming to learn is too put as many roadblocks as possible to any hacker that attempts to break into your server, or knock it off line (e.g., DDOS), this way the time, effort, and cost he expends trying to get into your server far exceeds the value he will get from breaking into your server.
My problem with just running a server is I get lost in the details. First I tried hybrid Nix install, which is too buggy still, a full Nix install, but takes up a lot of hard disk space when you try to back up the files, then went to home install which is not secure enough for many reasons, and there’s also docker, VM, the former using up less resources.

I’m sorta taking a “cardano” approach with my server, researching many possibilities first, then trying to find a way to set up the most secure server first with high uptime and low-latency, so I don’t waste time once I have a running instance on mainnet with delegates and try to change things then when having a good server depends on keeping delegates happy. The research phase is taking a long time, but I have a lot of ideas.

4

I have enabled 2 factor authentication on my ssh logins, so if even some miracle/nightmare happens and someone get’s my private keys and guesses the password for them… they still have to have the physical authenticator. Also, my ssh keys are set to expire. The 2factor authentication and key expiration is easily done on GCP, but if you are on other platforms, there is also an option to install 2 factor authentication.

for DDOS there are also solutions which you can implement… so yes, there are a lot of things you can do nowadays to protect your servers/services.

cheers,
Lauris

1 Like
5

It’s easy to mess up on cloud instances…I locked my self out just by enabling ufw…that’s all I did…I forgot default settings on most firewalls are to block all incoming (and allow all outgoing) I believe, so when I was done with the gce session…I just logged out or closed the window…and was not able to log back in later in the day, so I just deleted the instance and did new one…no worries though…I hadn’t gotten around to even starting the bp node installation, so I just lost a little bit of time.

I have 2FA on GCE too, but I don’t tie any of my cell phone numbers to my gmail accounts. I only tie a single gmail account to all other ones which rarely if ever gets used, and the one email account is only used for the sole purpose of securing those emails which I use for logins, if my email login accounts were to ever get hacked. Don’t know if this is a good practice, but it’s how I manage 2FA security when it comes to losing my cell phones or getting gmail accounts which I actually use for logins hacked.

I wanted to try something new…so yesterday I ordered FIDO2 security keys…I believe GCE supports them…and I just found out today that if you have a google/android phone running android 7 or later, you can use it as a physical key to verify websites you visit by using google phone biometric login for google services, but I don’t know if GCE is one of the supported google services. I believe the FIDO2 security keys I ordered support GCE logins…we’ll see…they need to be used physically on the computer in conjunction with google chrome web browser which is installable on Ubuntu.

That’s a good idea about setting expiration dates for your keys…I don’t do that, but it’s a good practice. I’m aware of DDOS security implementations for servers through reading stuff on the internet, but I just never used them because I’ve never set up a 24/7 server on the cloud or at home before that would be worth protecting like this one.

6

I was wrong. I didn’t have 2FA enabled on any aspect of GCloud, but do have it enabled on many other websites.
Anyway, it took me about a day to set up 2FA hardware key authentication just on my main gmail account using a 3rd-party 2FA hardware key brand, not google’s somewhat expensive hardware keys. I’ve never used hardware keys before, primarily because i only use linux as my operating system, for which many hardware keys haven’t work natively in the past, so I I’ve only used google 2FA authentication app via my cell phone in the past. Anyway, I didn’t know hardware keys are so effective and space-saving.
I’m hooked on them now. No more cell phones or password-only protected websites where my passwords are so long and have so much entropy (impossible to memorize), I need an encrypted USB to store them safely. Now, I can just leave even my user/password combo on my laptop in plaintext, and even if my laptop gets stolen, and they have access to my user/pass combo, the 2FA hardware key is still required for authentication. Since it’s 3rd-party cheap solution (only $18), I wasn’t sure it would work on gmail and other google services, but it does, including google cloud! So, I got lucky with this 3rd-party cheaper alternative to google’s more expensive hardware key solution.

Anyway, this particular hardware key is limited in the websites it can protect - hopefully, they’ll add more website support in the future. Right now it protects against logins to a number of google products and services, like GCloud, and also Amazon, AWS, and a few other major websites, so access to any GCE VM instances via web browser login are denied, for example.

How did you get 2FA on your actual ssh-to-VM instance logins?

Is key rotation the same as replacing expired keys or just replacing keys after a certain amount of time has passed? Do you know if GCE has an automated process for that, so you don’t have to waste time if you forget to do it manually?

I’m going to try to set up key-rotation tonight, trying to be a little more productive today…that 2FA was not easy to set up because additional key info was missing. You can install Chromium on Ubuntu,but it’s a somewhat stripped-down version of Chrome, so my key doesn’t work on that browser, but miraculously it does work on firefox, which the key manufacturer didn’t bother to even mention that browser as being one of the supported browsers - I wonder if they even know that about their own product? :confused: Also had trouble because it’s not enough to just install hardware key by itself, your google account requires at least one additional secondary authentication method that involves your phone being linked to your gmail account, something which I wanted to avoid if my cell phone gets gets lost or stolen; i.e., google authenticator, android cell phone internal key (android 7.0 or later), phone SMS messaging, etc., just in case the primary (main) secondary method fails I suppose, and you get locked out of your account with no other way to get in as a secondary backup method since it’s a 2FA process, my guess.

7

Finally got hardware key bound to VM instance ssh logins. It’s similar to gmail HW key login except in this case you need to plug the device in first before using the ssh command via CLI, whereas in gmail, you can use user/pass combo first, then it will prompt you for HW key. If you try doing that with ssh CLI command (without HW key inserted) it will just give you a denied login attempt. It was NOT an easy process. The actual HW key setup took less than 5 minutes - very, very easy - but hunting down the specific information on gcloud documentation on how set it up in the first place was not only confusing but took hours and hours.
Still gotta figure key rotation though. Still somewhat confused about that - It’s the documentation. >:/ They throw sooo much info at you, it’s difficult to separate the relevant from the irrelevant for your specific needs - hopefully, it gets easier with time.