User Guide Functional Overview Requirements Architecture System Installation NetEye Additional Components Installation Setup The neteye Command Director NetEye Self Monitoring Tornado Business Service Monitoring IT Operation Analytics - Telemetry Geo Maps NagVis Audit Log Shutdown Manager Reporting ntopng Visual Monitoring with Alyvix Elastic Stack IT Operations (Command Orchestrator) Asset Management Service Level Management Cyber Threat Intelligence - SATAYO NetEye Update & Upgrade How To NetEye Extension Packs Troubleshooting Security Policy Glossary
module icon Requirements
Requirements for a Node Cluster Requirements and Best Practices NetEye Satellite Requirements TCP and UDP Ports Requirements Additional Software Installation
Functional Overview Requirements Architecture System Installation NetEye Additional Components Installation Setup The neteye Command Introduction to NetEye Monitoring Business Service Monitoring IT Operation Analytics Visualization Network Visibility Log Management & Security Orchestrated Datacenter Shutdown Application Performance Monitoring User Experience Service Management Service Level Management & Reporting Requirements for a Node Cluster Requirements and Best Practices NetEye Satellite Requirements TCP and UDP Ports Requirements Additional Software Installation Introduction Single Node Cluster NetEye Master Master-Satellite Architecture Underlying Operating System Acquiring NetEye ISO Image Installing ISO Image Single Nodes and Satellites Cluster Nodes Configuration of Tenants Satellite Nodes Only Nodes behind a Proxy Additional NetEye Components Single Node Cluster Node Satellites Nodes only Verify if a module is running correctly Accessing the New Module Cluster Satellite Security Identity and Access Management External Identity Providers Configure federated LDAP/AD Emergency Reset of Keycloak Configuration Advanced Configuration Authorization Resources Tuning Advanced Topics Basic Concepts & Usage Advanced Topics Monitoring Environment Templates Monitored Objects Import Monitored Objects Data Fields Deployment Icinga 2 Agents Configuration Baskets Dashboard Monitoring Status VMD Permissions Notifications Jobs API Configuring Icinga Monitoring Retention Policy NetEye Self Monitoring 3b Concepts Collecting Events Add a Filter Node WHERE Conditions Iterating over Event fields Retrieving Payload of an Event Extract Variables Create a Rule Tornado Actions Test your Configuration Export and Import Configuration Example Under the hood Development Retry Strategy Configuration Thread Pool Configuration API Reference Configure a new Business Process Create your first Business Process Node Importing Processes Operators The ITOA Module Configuring User Permissions Telegraf Metrics in NetEye Telegraf Configuration Telegraf on Monitored Hosts Visualizing Dashboards Customizing Performance Graph The NetEye Geo Map Visualizer Map Viewer Configuring Geo Maps NagVis 3b Audit Log 3b Overview Shutdown Manager user Shutdown Manager GUI Shutdown Commands Advanced Topics Overview User Role Management Cube Use Cases ntopng and NetEye Integration Permissions Retention Advanced Topics Overview User Roles Nodes Test Cases Dashboard Use Cases Overview Architecture Authorization Elasticsearch Overview Enabling El Proxy Sending custom logs to El Proxy Configuration files Commands Elasticsearch Templates and Retentions El Proxy DLQ Blockchain Verification Handling Blockchain Corruptions El Proxy Metrics El Proxy Security El Proxy REST Endpoints Agents Logstash Elastic APM Elastic RUM Log Manager - Deprecated Overview Authorization in the Command Orchestrator Module Configuring CLI Commands Executing Commands Overview Permissions Installation Single Tenancy Multitenancy Communication through a Satellite Asset collection methods Display asset information in monitoring host page Overview Customers Availability Event Adjustment Outages Resource Advanced Topics Introduction Getting Started SATAYO Items Settings Managed Service Mitre Attack Coverage Changelog Before you start Update Procedure Single Node Upgrade from 4.41 to 4.42 Cluster Upgrade from 4.41 to 4.42 Satellite Upgrade from 4.41 to 4.42 DPO machine Upgrade from 4.41 to 4.42 Create a mirror of the RPM repository Sprint Releases Feature Troubleshooting Tornado Networking Service Management - Incident Response IT Operation Analytics - Telemetry Identity Provider (IdP) Configuration Introduction to NEP Getting Started with NEPs Online Resources Obtaining NEP Insights Available Packages Advanced Topics Upgrade to NetEye 4.31 Setup Configure swappiness Restarting Stopped Services Enable stack traces in web UI How to access standard logs Director does not deploy when services assigned to a host have the same name How to enable/disable debug logging Activate Debug Logging for Tornado Modules/Services do not start Sync Rule fails when trying to recreate Icinga object How to disable InfluxDB query logging Managing an Elasticsearch Cluster with a Full Disk Some logs are not indexed in Elasticsearch Elasticsearch is not functioning properly Reporting: Error when opening a report Debugging Logstash file input filter Bugfix Policy Reporting Vulnerabilities Glossary 3b

TCP and UDP Ports Requirements

This section contains a list of TCP and UDP ports that should be opened on Corporate Network and/or Private (Heartbeat) Network to allow NetEye to operate correctly. These requirements apply on both NetEye Single Node and Cluster installations, except for cluster-specific ports.

It is important to remember that Private (heartbeat) Network should not be directly accessible from external networks. For security reasons, we suggest to open only the ports used by the running services and close everything else.

Note

All ports are listed with their default values as assigned by IANA or by the respective software producers.

System Ports

Make sure the following system ports are always opened, because they refer to basic functionalities of NetEye. The ports listed in Table 4 are to be opened on a Corporate Network in order to allow its communication with the NetEye.

Additionally, the communication between the NetEye and Corporate Network should be built with respect to the NetEye architecture, which means selected ports are to be opened on the Master Node or its Satellite.

Table 2 TCP/UDP Ports Requirements for System and Management Communication between Corporate Network and the NetEye Cluster

Protocol/Port

Service

Instance

Description

RMCP TCP 5900

iDRAC Access, Inbound

Master, Satellite

Systems that need to manage a node via iDRAC should reach each Management IP Address on iDRAC dedicated ports. Please refer to Dell’s Support Documentation to understand the required ports.

TCP 80, 443

NetEye Management Interface and System Updates, Inbound

Master, Satellite

Systems used to manage NetEye should reach the Cluster Virtual IP via HTTP/S. Satellites use those ports to receive data from agents.

TCP 22

Node SSH Console, Inbound

Master, Satellite

Systems used to manage deep NetEye configuration and node configuration should reach every Physical Node IP via SSH.

TCP 25,465

SMTP, Oubound

Master

To allow sending of notifications, the required ports for SMTP outbound should be allowed from each Physical Node IP to the selected SMTP Relay Server. If the Icinga2 notification feature is enabled on a Satellite as well, same ports should be opened on the latter.

UDP 123

NTP, Outbound

Master, Satellite

Each node should be able to reach the official internal time source server with NTP Protocol.

TCP 636, 3269

LDAP Authentication and Authorization, Outbound

Master

To allow your Active Directory user accounts the ability to access NetEye, each node must be able to contact at least one DC on both ports 636 (LDAP) and 3269 (Global Catalog) encrypted over SSL. To allow your LDAP user account the ability to access NetEye, each node must be able to contact your LDAP Source on port 636 (or the Port of your choice).

TCP 7422

NATS Leaf Nodes

Master (Inbound), Satellite (Outbound)

Satellites should be able to reach the NetEye Master NATS Leaf Node port in order to send data generated on the Satellite to the Master.

TCP 4222

NATS Server

Master (Inbound), Satellite

In order to send data from a NATS Client (e.g. a Telegraf) directly to NetEye, port 4222 should be opened (NATS TCP port).

The ports in Table 3 should be opened on the Private (heartbeat) Network and include the cluster requirements specified by RedHat.

Table 3 Cluster-internal Port Requirements

Protocol/Port

Required for

Description

UDP 623

iDRAC fencing

TCP 2224

Node-to-node communication

It is required to open port 2224 on each node to allow pcs to talk from any node to all nodes in the cluster, including itself. [[1]]

TCP 2347

neteye-agent service.

TCP 3000

Grafana

TCP 3121

Pacemaker Remote nodes

Required on all nodes if the cluster has any Pacemaker Remote nodes. [[2]]

TCP 3306

MariaDB

TCP 4748

Tornado API

Communication with Tornado API from the GUI and for testing.

TCP 5403

Quorum device host

Required on the quorum device host when using a quorum device with corosync-qnetd. [[3]]

TCP 5404

Corosync multicast UDP

Required on corosync nodes if corosync is configured for multicast UDP.

TCP 5405, 5406

Required on all corosync nodes

TCP 5664

Icinga 2

Required by Icinga 2 for intra-cluster communication [[4]]

TCP 7788-7799

DRBD

Port range may be extended as new resources or services are added.

TCP 8086

InfluxDB

TCP 8000

Lampo

Table Notes:


Monitoring Requirements

Monitoring should never be carried out on the private (heartbeat) cluster network.

At present, the NetEye Cluster’s Virtual IP is used for passive monitoring (i.e., by devices autonomously sending information to NetEye) and agent deployment, while the Physical Node’s IP is used for active monitoring (i.e., requests from NetEye to devices).

We distinguish the following types of monitoring:

  • Active monitoring through ICMP consisting of direct ICMP requests from NetEye to monitored devices

  • Active monitoring through SNMP is similar to previous, but using the SNMP protocol in spite of ICMP

  • Passive monitoring through SNMP uses SNMP trap events sent from monitored devices to NetEye

  • Mail-based monitoring is based on emails sent by devices or users to NetEye that trigger specific events

The following monitoring requirements apply to the server that is to be monitored. Active and passive monitoring have different requirements in terms of ports. Moreover, also the operating system installed on the devices to be monitored influences the ports to be opened; all are reported in Table 4. Depending on the monitoring tasks activated, additional considerations are described in section Additional Remarks for Monitoring.

Table 4 Monitoring Requirements

Protocol/Port

Description

Monitoring

ICMP

Test via ping to check if a host is alive

Active/Passive

TCP 4222, 4244

(APM)

Active/Passive

TCP 5001

plugin check_iperf

Passive

TCP 5665

server monitoring (ICINGA2 protocol)

Active

UDP 161

Device/server monitoring (SNMP protocol)

Active

UDP 162

TRAP SNMP

Passive

TCP 135

Windows server monitoring (WMI protocol) and Windows admin user (more ports are required)

Active, Windows devices only

TCP 22

Linux Server monitoring (SSH protocol with check_by_ssh)

Active, Linux devices only

Additional Remarks for Monitoring

Depending on the services enabled on the cluster, take into account the following:

  • For Sahi and/or check_webpage, create a dedicated user account if required.

  • Enable the SNMP v2c protocol and community on all servers and devices.

  • Enable all TCP and UDP ports needed for specific monitoring requirements, such as check_tcp and/or check_udp for network service ports like: 53 (DNS), 123 (NTP), 3306 (MySQL), etc. For a full list of reserved ports, you can consult this website.

  • You may need to contact your NetEye 4 consultant for the following requirements:

    • Create a database monitoring user, where the rights granted will depend on the database’s vendor

    • Create a user on HyperV systems

    • Allow connections between NetEye 4 and all VLANs/Subnets involved in monitoring

Individual Module Requirements

Individual NetEye modules may have their own specific requirements that will need to be taken into consideration if a particular Module is to be enabled. When configuring cluster nodes, you should also make sure that the following requirements are included for each node.

Note

Please pay attention to the type of Network - Corporate or Private - each port requirement applies to.

ntopng

The following ports must be opened on the NetEye Master side in order to allow the communication between ntopng, nProbe, and Redis. The ports are inbound.

Table 5 ntopng Corporate Network Port Requirements

Port

Service/Description

TCP 5556

zmq (nProbe client)

TCP 6363

nProbe (Netflow collector)

Table 6 ntopng Private Network Port Requirements

Port

Service/Description

TCP 6379

Redis

Elastic Stack

The following ports need to be opened either on the part of Corporate or Private (heartbeat) Network to be able to receive, process and store log data. Please note that all the ports are inbound and refer to the Master instance only.

Table 7 Elastic Stack Corporate Network Port Requirements

Port

Description

TCP/UDP 514

syslog/rsyslog

TCP 6161

syslog/splunk

UDP 2055

Netflow listening port (Netflow protocol)

TCP 5044

Logstash input for Beats

TCP 5045

Logstash input for Elastic Agent

TCP 9200

Elasticsearch

TCP 8220

Fleet Server

TCP 8200

APM Server

Note

Port 9200 should be opened if there are Satellite Nodes that send data for the Elasticsearch service

Table 8 SIEM Private (heartbeat) Network Port Requirements

Port

Description

TCP 4950

El Proxy

TCP 5061

Kibana

Moreover, the following domains should be reachable for ensuring correct functioning of your Elastic Stack installation:

Domain

Port

Intended Use

epr.elastic.co

443 TCP

Elastic Package Registry (mandatory in all SIEM installations)

geoip.elastic.co

443 TCP

Elastic GeoIP endpoint

storage.googleapis.com

443 TCP

GeoLite2 City, GeoLite2 Country, and GeoLite2 ASN GeoIP2 databases used by Elastic GeoIP processor

SLM

The SLM Daemon needs a dedicated inbound port to be opened on the Master instance to operate correctly. The requirement refers to the Corporate Network.

Table 9 SLM Port Requirements

Port

Description

TCP 4949

SLM daemon

Alyvix

In order for Alyvix Service to successully communicate with NetEye the following port should be opened on a Corporate Network, relative to both Master and Satellite instances.

Table 10 Alyvix Port Requirements

Port

Description

TCP 4222

While TCP 4222 grants Inbound connection from Alyvix Service to NetEye, TCP 443 should also be opened to allow Outbound connection from NetEye to Alyvix Service

Single Purpose Nodes

Elastic-only nodes work only as part of Elasticsearch cluster and communicate on the private (heartbeat) network, therefore they do not expose any ports required by other services.

Voting-only nodes only provide quorum to several components of NetEye cluster: DRBD, PCS, and Elasticsearch. Like Elastic-only nodes, they do not expose any service and communicate with other cluster nodes on the private (heartbeat) cluster network; therefore no port should be explicitly opened.