Installation

Sizing and Placement 

Before installing sensors, decide how many you need and where they sit. Two rules answer both questions.

Count probes by zone, not by volume 

A single probe handles a high flow rate on its own, so raw throughput rarely decides the count. What decides it is network segmentation: a probe sees only the traffic on the segment it sits in. Deploy one probe per isolated zone (for example Core, DMZ, and each cloud or branch segment) and let each probe monitor its own segment. Placing a probe inside the zone it watches also keeps captured traffic from crossing segment boundaries, which matters for audited environments. Only the pull from the cluster crosses the firewall.

Separate the flow rate from the log rate 

Two figures often get quoted together and then double-counted:

Flows per second and NetFlow bandwidth are the probe’s workload.
Events per second (EPS) is the cluster’s log-ingest workload, handled by the data nodes, not the probe.

Size the probe from the flow rate and the cluster from the EPS. They are different resources; do not add them together.

Hardware 

Size the probe to the production figures for the ELS Network Node in System Requirements; that table is the single source for component hardware. Local disk on the probe holds buffered and cached data, so size it against how long the probe must retain flows or captures. Full packet capture (PCAP) raises the disk and interface requirements substantially, so size those cases against the expected capture rate and retention.

Standalone Sensor Deployment 

The Network Probe can be installed on a dedicated host as a standalone sensor, without the Data Node, ELS Console, or SIEM components. Run the installer in interactive mode with the -p|--network-probe flag to preselect Network Probe, then answer No to the remaining component prompts:

cd install
./install.sh -i -p

Note

Do not use -n|--noninteractive for a standalone sensor, because -n answers “Yes” to every component prompt and installs the full stack. See Non-interactive Installation Mode for details.

See Installation for installer prerequisites and options.

Network Probe Service Installation 

Energy Logserver Network Probe is installed as part of the main installation package. The service is managed via systemd.

Service Management 

Note

The Network Probe service requires license-service to be running. If license-service is not active, the Network Probe will fail to start.

Start Network Probe service:

systemctl start logserver-probe

Enable Network Probe to start on boot:

systemctl enable logserver-probe

Check service status:

systemctl status logserver-probe

Bundled Services 

The Network Probe installation includes the following components, each running as a separate systemd service:

Component	Service	Description
Network Probe	`logserver-probe`	Pipeline engine for log ingestion and processing
Kafka	`kafka.service`	Message queue for data transport between probe and Data Node
Zookeeper	`zookeeper.service`	Coordination service required by Kafka
Zeek	`zeek`	Network traffic analyzer (NDR)
Suricata	`suricata.service`	Network IDS/IPS engine
pmacct (NetFlow)	`nfacctd@instance1`	NetFlow/IPFIX collector
pmacct (sFlow)	`sfacctd@instance1`	sFlow collector

Note

Not all services are required in every deployment. Enable only the components relevant to your use case. Services can be managed from the GUI via the Management Interface.

Warning

Zeek, Suricata, and pmacct require a dedicated network interface for traffic capture. Configure the listening interface before starting these services:

Zeek: /opt/zeek/etc/node.cfg
Suricata: /etc/suricata/suricata.yaml
pmacct (NetFlow): /etc/pmacct/nfacctd-instance1.conf
pmacct (sFlow): /etc/pmacct/sfacctd-instance1.conf

Configuration Files 

Network Probe configuration files are located in:

Main configuration: /etc/logserver-probe/logserver-probe.yml
Pipeline configurations: /etc/logserver-probe/pipelines.yml and /etc/logserver-probe/pipelines.d/
Input/Filter/Output configs: /etc/logserver-probe/conf.d/
JVM options: /etc/logserver-probe/jvm.options

TLS Configuration 

Default Configuration (7.6.1 and later)

Since version 7.6.1, there is a default configuration for enabled algorithms at /etc/logserver-probe/java.properties.

Make sure there is the following definition in /etc/logserver-probe/jvm.options:

-Djava.security.properties=/etc/logserver-probe/java.properties

You can edit this file and after restarting Network Probe, changes will be applied.

Manual Configuration (7.6.0 and before)

For versions 7.6.0 and earlier, follow these steps:

Create file /etc/logserver-probe/java.properties with content:

   security.useSystemPropertiesFile=false
   jdk.tls.ephemeralDHKeySize=2048
   jdk.certpath.disabledAlgorithms=MD2, SHA1, MD5, DSA, RSA keySize < 2048
   jdk.tls.disabledAlgorithms=DH keySize < 2048, TLSv1.1, TLSv1, SSLv3, SSLv2, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256, DHE_DSS, RSA_EXPORT, DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_DSS_EXPORT, DH_RSA_EXPORT, DH_anon, ECDH_anon, DH_RSA, DH_DSS, ECDH, 3DES_EDE_CBC, DES_CBC, RC4_40, RC4_128, DES40_CBC, RC2, HmacMD5, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA
   jdk.tls.legacyAlgorithms=

Add to /etc/logserver-probe/jvm.options:

   -Djava.security.properties=/etc/logserver-probe/java.properties

After restarting Network Probe service, changes will be applied.

MasterAgent TLS 

Since version 7.6.1, MasterAgent has predefined strong ciphers already set. Updating is recommended.

For MasterAgent configuration, see Agents and Language Settings.

Post-installation Verification 

Verify Network Probe is running:

systemctl status logserver-probe

Check Network Probe logs:

journalctl -u logserver-probe -f

Verify Network Probe is listening on configured ports:

netstat -tuln | grep java

Test pipeline configuration:

/usr/share/logserver-probe/bin/logstash --config.test_and_exit