Are you a member of CheckMates?
×
Sign in with your Check Point UserCenter/PartnerMap account to access more great content and get a chance to win some Apple AirPods! If you don't have an account, create one now for free!
Hey everyone, lately I have been playing around with management server deployments in Azure and thought I would share some of what I learned along the way.
What I am trying to accomplish:
Setup a lab environment with a small number of gateways, some on-prem and some virtual in the cloud. All managed by a CloudGuard Management Server instance in Azure.
Today we will focus on the Secure Management Server Deployment (SMS) from the Marketplace in Azure.
Where to start:
Usually I start with existing documentation.
These are pretty good, they cover the basics and for lab deployments, will get you up and running in no time. However, they didn't really go deep enough for me. I wanted to do things more like a real world production environment. Enabling some all the "best practice" features that often get skipped in lab demonstrations. Sometimes the best way to learn is to try to do things the hard way!
Where I ran into trouble (#1):
The first change I made to typical lab deployment process was to enable SSH public key access instead of a password. This is more secure and generally considered a best practice for cloud resources that will be publicly accessible.
The auto-generate feature is handy, but will leave you with a dedicated key object, not a key value in a Key Vault. So you may have to do some clean-up later. My preference is to use Putty KeyGen or a similar tool to make your own. I completed the deployment, skipping the Hash value fields for now, and then configured Putty for making my connections using my key file.
Note: if you do want to use the auto-gen feature to have Azure create the keys and are using Putty, you will need to use the Putty KeyGen utility to convert the Pem file Azure gives you to the Putty Ppk format. Otherwise you get an error about an invalid file type when you try to connect.
In my case it didn't matter which way I created the keys, I couldn't get it to connect. Deployment would finish without a problem, but once the server was up all my connections would fail with the same error:
I doublechecked all of my settings on the VM and the NSG, but everything was correctly configured by the wizard and locked down to access only from my public IP. I could confirm my access under connections in the VM properties but still not connect. It didn't make sense. Looking back at the error, I realized my client was talking to the server and the server was presenting the public Key I gave it, so why wasn't this working?
The Solution:
Turns out when I was making my initial connection in Putty, I was leaving the username blank. This made sense to me because in my mind I was using the SSH keys instead of the username and password. What didn't register right away is that we are really just replacing the password part of that combination and the system still needs to know the user context for any connections it receives.
All I needed to do was give it the username, and BAM, I was in!
Where I ran into trouble (#2):
Now I had access to my SMS via SSH and was ready to start the fun stuff. So I fired up my Smart Console to get connected and start configuring. That's when I ran into this:
Wait, what am I supposed to do with that? When you select SSH keys in the deployment wizard, there is no place to define a password. This had me scratching my head for a minute, I was pretty sure that "admin" was the right user, makes sense it would line up with the SSH access, but what would the password be? Then I remembered that Smart Console supports different connection types:
This looked promising, so I figured I would try the Certificate file connection and just point it at my Pem file I got for the SSH access. But… then when you try to navigate to your private key file, you find that the GUI will only accept P12 file types.
Now at this point you probably realize keys and certificates are not my strong suite. It is true, I am a little rusty in this area but I do know a little. One of the things I learned in the past came back to me now. I remembered that a private key file and a privately key certificate are not the same thing. So the GUI limitation here tipped me off, I was on the wrong track.
The solution:
The KEY here (forgive the pun) is thinking about the user context again. We still have an "admin" user on the system, however we deployed it such that the user is essentially defined without traditional password but with a private key, and the user is authorized for SSH connections with that private key. What we need to do is, to go back to our SSH connection and simply define a password from the CLI. That looks like this:
[AzureSMS]> set user admin password
New password: [type_password]
Verify new password: [type_password]
[AzureSMS]> save config
That’s it. This password can then be used for admin account (including the https portal and the Smart Console).
Where I ran into trouble (#3):
This wasn't an issue so much as something that did make sense to me as I went through the deployment. Going back to the deployment wizard we see the system prompting us for Serial Console and Maintenance mode password hashes. First time through I skipped these, but this also seemed like a best practice for production systems so after solving the SSH key access issues I went back to redeploy and dig into this deeper.
Serial Console.
Interesting, it wants us to enter the Hash value instead of the password itself. (probably this is due to this value being controlled by the underlying Linux system rather than any Azure service) I don't have a lot of experience with OpenSSL, but have used it for various certificate related tasks over the years, so getting it installed was not a problem.
Good how-to video if you need some help here:
How to Install and Use OpenSSL on Windows (2023)
However, once I started playing around with the command provided "openssl.exe passwd -6 [passwordstring]" I noticed results that didn't make sense.
- The output was different every time when using the same password string value.
- The output didn't look like a hash value (specifically: the special characters)
- While I was at it, why is MS pointing me to use OpenSSL in the first place? Why not just pass the string into a stream and use Get-FileHash in PowerShell? That seems like a more "Microsofty" way to get hashes….
An example of what I was seeing vs what I expected with a simple "test01" txt string.
Side Note: if you are insterested in where I got PS from for the Get-FileHash, you can find the sample code here:
Turns out all of these things are connected.
The solution(s):
Going searching I found that I am not the first person to scratch my head at the OpenSSL outputs:
https://stackoverflow.com/questions/62278968/opessl-sha-512-string-charset
And very importantly:
https://en.wikipedia.org/wiki/Crypt_(C)
Now it all started coming together. The OpenSSL utility is using random Salt values by default when you run the command. This is what make the output different every time. You can test this by running the command with a specified Salt value and then see that it will produce a consistent output.
That got me part to the way there, but why does the output look like that? Well that is where the Crypt format comes in. This is actually a complex format in that it is storing multiple values, not just the Hash. Other values (the salt for instance) are encoded together with the Hash into a single string output.
Key pull quote from the Wikipedia article:
"More formally, crypt provides cryptographic key derivation functions for password validation and storage on Unix systems."
Considering that what we are doing here is passing a value that the underlying Linux system with write to a file, this all makes sense now. 🙂 We need to give the underlying OS (a Linux System) a value that it understands so that it will work when a user tries to authenticate to it.
Armed with this new knowledge, I went back to the OpenSSL and created my needed string with confidence.
In this example I copied the whole line, from "$6…" -> "…51" into the Azure wizard text box.
Side Note: When we specify the Serial Console password via hash value this way, it also sets the valid password for the admin account. So going back to the previous section, there would be no need to connect via SSH and set the password manually!
Maintenance Mode
OK, now we are better prepared for this one. Obviously what we are trying to do here is generate a Hash/complex output string (this time pbkdf2) that will be valid for GRUB bootloader on the underlying OS to use.
We can't use OpenSSL here. It isn't really stated anywhere but you will need access to Linux workstation or server here to run the command and generate required output.
In this case I copied everything from "grub…" -> "…CC" into the Azure wizard text box.
Note: if using Ubuntu, this command is grub-mkpasswd-pbkdf2 instead of grub2-mkpasswd-pbkdf2
https://www.thegeekdiary.com/grub2-mkpasswd-pbkdf2-command-not-found/
Conclusion
Now we have a production quality SMS server deployment running in Azure and are ready to start deploying gateways and building policy. Good enough progress for today's post, but I will leave you with one last lesson learned about Smart Console once you get this far. In some cases you may see a Certificate error: Cert Authority is Invalid.
If you happen to see this when you try to manage your license:
And this when you go to look at your logs:
It is good indication that the traffic between your local machine (where Smart Console is running) and the Azure SMS server is being Https inspected. This breaks the connections between smart console and some of the services it accesses on port 443. Recommended practice here will be to bypass inspection for traffic to the SMS Server IP address. This will clear up the certificate error and you will be good to go.
With that, I am out. Hope you found something useful here and have a great day!
