Secure A Multi-Server Security Engine Installation With HTTPS

The second part of this tutorial will explain how to set up and secure the installation of the multi-server CrowdSec security engine. In the first part, we explain how to set up the CrowdSec security engine on multiple servers, one of which serves as the parent server and the other two forward the alert to it.

This section will solve the security problems caused by plaintext HTTP communication in previous multi-server security engine installations. To solve this problem, we recommend establishing communication between security engines through encrypted channels. This solution allows server 2 or server 3 to trust the identity of server 1 and avoid man-in-the-middle attacks.

Using self-signed certificate

Create a certificateFirst, you need to create a certificate. This can be achieved by following a single line command:

openssl req -x509 -newkey rsa:4096 -keyout encrypted-key.pem -out cert.pem -days 365 -addext "subjectAltName = IP:172.31.100.242"

Currently, the security engine cannot request the password for the private key when it is started. Therefore, you can choose to manually decrypt the private key every time you start or reload the security engine, or store the key unencrypted. Either way, to delete the password, you can use the following command:

openssl rsa -in encrypted-key.pem -out key.pem

Then, after the security engine is started, the unencrypted key file can be safely deleted.

Configure the security engine to use the self-signed certificate On server 1, you need to configure the security engine to use the generated certificate. As shown below, the /etc/crowdec/config.yaml and api.server options in the tls.cert_file section of the following tls.key_file excerpt are set to the generated certificate file.

api:
  server:
    log_level: info
    listen_uri: 10.0.0.1:8080
    profiles_path: /etc/crowdsec/profiles.yaml
    online_client: # Crowdsec API credentials (to push signals and receive bad 

    tls:
      cert_file: /etc/crowdsec/ssl/cert.pem
      key_file: /etc/crowdsec/ssl/key.pem

On the client, the configuration change occurs in both files. First, modify /etc/crowdec/config.yaml to accept a self-signed certificate by setting insecure_skip_verify to true.

You also need to change HTTP to HTTPS in the /etc/crowdsec/local_api_credentials.yaml file to reflect these changes. This small change must be done on all three servers (Server 1, Server 2 and Server 3).

Note: Remember that if Server 1 is also used as a log processor, you must also do this LAPI configuration on this server.

url: https://10.0.0.1:8080/
login: <login>
password: <password></password></login>

Side note: Obviously, using a self-signed certificate does not provide any warranty on ownership of the LAPI server. Servers using the service (server 2 or server 3 in this setting) are still vulnerable to man-in-the-middle attacks, but at least this setting provides encrypted communication. This is why the InsecureSkipVerify option is needed.

Certificates issued by Certificate Authority

Services such as Let's Encrypt or Amazon ACM can resolve the /etc/hosts issue by issuing certificates for fully qualified domain names that can be added to InsecureSkipVerify or local DNS servers. You can then populate /etc/crowdsec/local_api_credentials.yaml with this specified fully qualified domain name.

This does work and prevents the InsecureSkipVerify option from being set. As long as the DNS configuration is trusted, this ensures that communication between the client and the server is not tampered with, but this should still be considered a workaround.

Using PKI

The process of configuring and managing SSL public key infrastructure (PKI) is not within the scope of this tutorial, but I strongly recommend that you check out the official OpenSSL documentation. A simple PKI solution is sufficient to meet the needs of this security engine setup.

According to the OpenSSL documentation, there are some things worth mentioning.

To be used in our CrowdSec TLS scenario, certificate requests must be issued with the topic alternative name corresponding to the IP of the Crowdsec LAPI server. This can be done by locating the SAN environment variables when calling OpenSSL for certificate requests (see Step 3.3 in OpenSSL Simple PKI Scheme).

openssl req -x509 -newkey rsa:4096 -keyout encrypted-key.pem -out cert.pem -days 365 -addext "subjectAltName = IP:172.31.100.242"

Before starting the CrowdSec security engine, the common part of the root certificate and the signed certificate (the bundled file created in step 4.5 of the OpenSSL simple PKI scheme) must be added to the local certificate store. In this setup, this is necessary to connect to the LAPI server. There are many ways to do this, the golang source code specifies the location of the expected certificate, or you can use the SSL_CERT_FILE environment variable in the systemd service file to specify where to look for the certificate when starting the security engine.

Update instructions on CrowdSec and TLS authentication

After this article was first published, we have added a new feature to the security engine, where you can now not only protect communications on TLS, but also ensure authentication with certificates. In the official documentation, you can find a good example showing how to use certificates for TLS authentication between security engines or between security engines and remediation components.

Conclusion

This article focuses on how to protect communication between different CrowdSec security engine installations. The use case considered is security engine installation in a private network, but this can also be deployed on public networks with internet communications. In this case, a third-party certificate can easily solve the problem.

As needed, we propose three different methods to achieve secure TLS communication between security engines—using self-signed certificates, using certificates issued by certificate authorities, and using SSL public key infrastructure.

The first solution (using a self-signed certificate) is only suitable for situations where you want to ensure encrypted communication without authentication. The second solution can only be considered when you can modify local DNS resolution. The third solution is the most complex, but it suits most use cases and may be the best choice when security issues are serious.

I hope this tutorial will be helpful to you. Thank you for reading, please stay tuned!

If you have any questions or feedback, please feel free to contact us through our Discord and Discourse community platforms.

The above is the detailed content of Secure A Multi-Server Security Engine Installation With HTTPS. For more information, please follow other related articles on the PHP Chinese website!