You have a firewall between your management network and your administrative network right? You use active-directory authentication yeah? Well, funny as it may seem, the information gathered by your logging infrastructure is very sensitive. It contains verbose output regarding the historical and real-time status of your environment. In my opinion, the information container with it should be treated the same as Personally Identifiable Information (PII) or Card Holder Data (CAD). So what do you need to do from a network point of view?

Walls of fire

Whilst this post focuses on Log Insight – there are common ports amongst other log systems such as ELK stack and Loggly. ELK stack, known as the Elastic Search – Logstash, and Kibana – is an OpenSource system that is used vastly throughout Service Provider, Enterprise, and hosting environments. These are Syslog, Web management ports and others.

You require some ports to be opened?

Log Insight operates over well known ports and some custom ports. Assuming that you plop a firewall between your management environment and your administrative environment you will need to open the following ports.

The following ports are required for Log Insight and its cluster to ingest records from sources that send data to the Log Insight cluster.

Data ingest to log cluster

514/UDP    Syslog
514/TCP    Syslog
1514/TCP   Syslog-TLS (SSL)
9000/TCP   Log Insight Ingestion AP


The following ports are used by the Log Insight web UI. This allows visualisation and execution of actions against the analytics engine. Kibana can be set to this port when using the ELK stack for visualisation.



Master node ports

In particular to Log Insight the following ports should be opened to the master node. Whilst the master node can failover to other workers, it is important that access to these ports are controlled.

16520:16580/TCP     Thrift RPC
59778/TCP           log4j server
12543/TCP           database server

If you are using VMware’s NSX and choose to implement the distributed firewall against the log cluster these ports must be allowed. These can be composed of numerous, granular service groups assigned to VM-tags that match the name of Log Insight Workers.

What about Log servers themselves?

Whilst the previous lists defined the access ports inbound to a Log cluster there are numerous ports required by the logging servers to talk to various endpoints for logging and functionality.

Standard ports

Log Insight appliance       NTP server                  123 UDP
Log Insight appliance       Log Insight Appliance       59778, 16520-16580 TCP
Log Insight appliance       Mail Server                 465 TCP
Log Insight appliance       Log Insight Master node     12543 TCP


Active Directory ports

If you choose AD integration then the following ports are required.

Log Insight master        Active Directory      389 TCP, UDP
Log Insight master        Active Directory      636 TCP
Log Insight master        Active Directory      3268 TCP
Log Insight master        Active Directory      3269 TCP


The ports 389 + 636 are for Active Directory itself. The ports 3268 + 3269 are for the Active Directory Global Catalog services.

DNS Server

If you are using FQDN for LI Integrated Load Balancer ( then DNS should be used. This is also in conjunction if you are using domain name resolution against assets that logs are associated to. This allows cross-referential lookup into vRealise Operations.

Log Insight master       DNS server       53 TCP, UDP


Lockdown the following ports due to them not being used any more. Unfortunately at the time of writing they are open.

Log Insight appliance      Log Insight          111 TCP, UDP
Log Insight appliance      Log Insight Tomcat   9007 TCP


These Tomcat services are not longer function but were left open. RPCbind service and Tomcat services can safely be blocked in a Log Insight 2.5 environment.

Agent ports

Log Insight uses local agents on guests to pass information. For example, extracting WMI logs the agent will push these to the Log Insight ingestion API port. These need to be open.

Log Insight Win Agent       Log Insight appliance        9000 TCP


FQDN / Load Balanced IP.

If you are using a clustered log managed environment then you will need to ensure that access to the VIP is provided at all times. This will be the destination of all syslog data sent for logging. It is important that your rules reflect that. If you are using FQDN then you can create FQDN rules for ASA/SRX if that is your firewall. If you’re using NSX then define the IP address.


There is a lot of sensitive information within this cluster. It is a treasure trove of information. The more endpoints that are sending data the richer the information if compromised. Versions, errors, patch status, login attempts and more. protecting this environment should be a number one focus. It is quite easy to do, after all, as most the posts are well-known they might even be pre-defined service groups!

It is a tactical security hardening exercise and one that shouldn’t take too long to get in working order.

3 thoughts on “Securing a logging environment

  1. Nice recap Anthony !
    There are Linux agents as well from version 2.5, and now default port from agents is cfapi over SSL, so tcp/9543 (this changed in version 2.5).

    From the doc: “The communication port that the agent uses to send events to the Log Insight server. The default values are 9543 for cfapi with SSL enabled, 9000 for cfapi with SSL disabled and 514 for syslog”


    1. Thanks Romain.

      This is good to know that there is now a Linux client. I have a few hosts I would like to log. I will add these ports to the post.


Leave a Reply

Your email address will not be published. Required fields are marked *