My internet facing relay recently had a PCI scan done on it, and it came back with a “SSL Certificate - Signature Verification Failed Vulnerability”. It does have a self-signed cert on it, but what I’m confused about is the usage of the cert for BigFix. If I query port 52311 with
I’ll confess I’m not a cert guru, but based on the information I’ve read about internet relays I don’t know that certs are even involved in the process for BigFix agents outside my network. Is that correct or am I missing something?
I may have answered my own question. The Internet facing relay obviously had relay diagnostics enabled which was allowing HTTPS connections (d’oh!) and explains why it was flagging a cert on port 52311. This is recommended per documentation to be disabled. I’ve disabled that and we’ll see if it goes away.
The client is supposed to connect to the relay using HTTPS if both the client and the relay support HTTPS, which they all should.
The root of trust for the relay/client comes from the Masthead, not from a typical root CA signed SSL certificate, so the fact that a relay uses a certificate not signed from a traditional root CA is not an insecurity, since the clients should ONLY trust a cert signed by the Masthead, which is even more restrictive than traditional SSL.
Turning off relay diagnostics on a DMZ relay is a good idea regardless.
Look at the output of that OpenSSL command and compare it to the info inside the masthead file.
This I always found a bit iffy. Although the masthead ensures that only validated endpoints can connect to the relay it does not secure the data that gets exchanged. As far as I know the default leaves reports sent through the chain in clear text. The client logfile then clearly states “Encryption: optional encryption with no certificate; reports in clear text”. Default 9.x behaviour does set encryption of reports to “if possible” but extra steps are then needed from the Bigfix Administration Tool on the Root Server to generate, deploy and use a key.
Regarding the Relay Diagnostics Page: I always wondered why this is enabled by default. Should be turned off unless you really need it, even on your intranet.
This is not actually the case. If you are running the newest version of BigFix then all client to relay to relay communication should be over HTTPS.
This does require an extra step, but you are right, the default for new installs should be that the key gets generated for this automatically so that report encryption happens by default.
If you do have a existing install you can do these steps at anytime.
I enabled MLE and Enhance Security on my instance and it was painless this past year. You just want to make sure your clients are at 9.1 and higher. My BigFix instance recently passed a 3rd party Pen Test with no High/Med risk discoveries.
Excellent. Thanks for everyone’s input. So with the certificates being contained within the masthead file, what does that look like? I tried popping open a masthead.afxm file and while I see a signature I don’t see anything that jumps out at me as a cert. Is there specific documentation around masthead files that anyone recommends besides the Configuration Guide?
I don’t think the root cert is in the masthead file. The root of trust is in the masthead file. The client knows to trust the certificates that are signed by the private key due to the matching public key in the masthead file.
Even without HTTPS the client knows to only trust the root server with a private key that matches the public key in the masthead. HTTPS just adds encryption to the communication path, while Report encryption protects both the report contents in transit, but also on disk on relays. Only the root server or decrypting relays, if configured, can decrypt the client reports if report encryption is on, which I would recommend.
If you look at the root certificate of the relays, it has info that matches what is in the masthead. It isn’t so much that the cert as in the masthead, but the root cert is directly connected to the masthead.
I would provide examples, but I really need to have a fake masthead I can share.
