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.
80/TCP HTTP 443/TCP HTTPS
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.
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.
If you are using FQDN for LI Integrated Load Balancer (https://networkinferno.net/LI-LB) 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.
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.