API Security adds Continuous Discovery and Risk Scoring PLUS a Free Version | LEARN MORE>

The Graylog blog

Keeping Graylog Secure

Now that you have your brand new Graylog instance up and collecting your organization’s logs, all the data is quickly searchable and available for troubleshooting any issues as they arise.

Just as easy as it is for you to use, an attacker with access to the logs now has a much simpler job of understanding your environment and seeing all of your data.   You need to make sure you are doing all the due diligence you can to protect the data.

There are a few different areas where you can limit the attack surface, so have a plan which includes best practices.  CIA Triad has published some industry best practices which is a good starting framework.

PROTECTING YOUR LOGS: ACCESS CONTROL

Let’s first talk about Access Control.  You need to have a way to limit who can talk to all components of the Graylog infrastructure.  Of the CIA Triad, this falls under the Confidentiality group, ensuring only the right people who need access have access.

If you start at the core and work out the place where the data is stored is in Elasticsearch.  There are options like Search Guard to help in adding an authentication method to Elasticsearch, so connections to the service will require a valid credential.  Additionally, Search Guard can help with role-based access controls.

MongoDB should be set to enforce access control to require usernames and passwords to have access to the database.

Graylog itself starts up with a default password but should be changed upon initial deployment of Graylog by changing the SHA2 value in the field: root_password_sha2.

With all the components requiring a password, now on to network access control recommendations.  It is recommended to put all critical components into a secure enclave if possible, with an access control list or firewall separating the standard user network from the infrastructure components.  This ACL/Firewall should be based around your user privileges, rather than a network address, as those can be spoofed to gain access.  If you can, use Two-Factor authentication on your NAC (Network AccessControl).

ENCRYPTION

Encryption will protect traffic and data in transit, and at rest from being easily read in plain text.  This falls in the Integrity category of the CIA Triad as encryption provides both privacy as well as validation that the data sent from one location is the same as on the other end.  While the discussion of how encryption works is beyond this article, it is good to discuss where to use it.

Taking the same core out approach, the first step will be to make sure all components are talking to each other in an encrypted fashion.  With TLS/SSL, we can force Elasticsearch, MongoDB, and Graylog to all communicate over an encrypted channel.  Encryption, when all components are on the same box, might not be as critical, it is still recommended.  When the Elasticsearch is separated from the Graylog component, encryption is always recommended.  You can read an in-depth article on this process here.

The next layer out is getting the data into the product, and most agents can support encryption to send the logs to Graylog, and some Syslog only devices can support TLS/SSL log shipment.  If you need to send an unencrypted log message into Graylog, it is recommended to have the log collection point as close to the device as possible, and then forwarded via an encrypted channel.  This documentation describes setting up encryption for the agent communication, as well as setting up trusted clients based on certificates.  By setting up the trusted clients, only authorized data is taken into the system.

Web UI should also be encrypted to protect the data in transit to the end-user/analyst viewing the log data.  Validated SSL/TLS certificates should be installed on the console and may be done by a Web Proxy if load balancing between multiple Graylog instances.

Lastly, if you are storing your logs through the archives, the compressed archives can also be encrypted to ensure they are not read by unauthorized parties.  This is very important if you are sending your logs outside your organization, or to the cloud for long term retention.

SEGMENTATION

You can now move into segmentation recommendations.  Segmentation completes the CIA Triad by addressing availability.  Availability ensures all components are available and protected from having failures in hardware as well as network issues.  By segmenting Graylog, you can control who has access to the system ensuring it is up and ready.

As discussed in Access Control, it is recommended to put all critical components into a secure enclave with access control separating the standard user network from the infrastructure components.  This network segmentation should be configured to only allow the ports needed for viewing of the web interface and agent communications to the outside user network.

The network segmentation allows control of what has access to critical infrastructure devices, as well as provide perfect points to monitor traffic in and out, allowing detection if new IP addresses are trying to access resources or if traffic patterns change.

It is not recommended to expose Graylog to the public internet in any fashion, please consider using a VPN to gain access to the Web UI.

OBFUSCATION

Obfuscation is another suggestion for protecting your company’s log data.   It can happen when collecting application logs in debug level, sensitive data finds its way into the log stream.  Logs could contain the full SQL Insert message having items like SSN, Usernames/Passwords, or Credit Card numbers.  In some countries, you are not allowed to store usernames with the log data.

Graylog allows for use of Pipelines to help remove the data from the message or change the value of the message into a hash value as described in this community post.

While not putting the data into the log message is the best approach, this can be used if needed to clean up sensitive data.

MAINTENANCE

Finally, ensuring your software is up on the most current version is critical to protect against exploits.  Elasticsearch, MongoDB, and Graylog all come out with new versions regularly, so adding to your server patch cycle is suggested.

Keeping up with the patches will keep you secure, as well as let you enjoy all the new features.

Get the Monthly Tech Blog Roundup

Subscribe to the latest in log management, security, and all things Graylog Blog delivered to your inbox once a month.