Docs
test1test2
6.5
6.5
  • ElastiFlow Documentation
  • Unified Flow Collector
    • General Configuration
    • Changelog
    • Maxmind GeoIP2 and GeoLite2
    • RiskIQ PassiveTotal
    • Network Interfaces
    • User-Defined Metadata
    • Docker
    • Linux
    • Unified Flow Collector Introduction
    • System Requirements
    • Supported IEs
    • AWS VPC Flow Log IEs
    • IPFIX IEs
    • Netflow IEs
    • sFlow IEs
  • Unified SNMP Collector
    • Device Groups
    • Changelog
    • Devices
    • Downloading Definitions
    • Enumerations
    • Objects
    • Object Groups
    • User-Defined Metadata
    • Docker
    • Network Interfaces
    • United SNMP Collector Introduction
    • Linux
    • Scheduling Rediscovery
  • Monitoring ElastiFlow
    • Liveness & Readiness
    • Metrics
    • Prometheus & Grafana
  • Configuration Reference
    • YAML Configuration Files
    • Configuration Reference Overview
    • Common
      • API
      • Licensing
      • Overview
      • Logging
      • HTTP output
      • Elasticsearch output
      • Kafka output
      • Monitor output
      • OpenSearch output
      • Splunk output
      • stdout output
      • Processor
    • Unified Flow Collector
      • Overview
      • Community/Conversation IDs
      • EF_PROCESSOR_ENRICH_TOTALS_IF_NO_DELTAS
      • Overview
      • RiskIQ PassiveTotal
      • Maxmind
      • User-Defined Metadata
      • Overview
      • Overview
      • User-Defined Metadata
      • Overview
      • Benchmark Input
      • Netflow/IPFIX/sFlow (UDP)
      • Licensing
      • Decoder/Processor
      • Sample Rate
      • Configuration Changes
    • Unified SNMP Collector
      • User-Defined Metadata
      • Overview
      • Licensing
      • SNMP Poller
      • EF_PROCESSOR_SNMP_ENUM_DEFINITIONS_DIRECTORY_PATH
  • API Reference
    • API Reference Overview
    • SNMP Operations
  • Data Platforms
    • Elastic
      • Basic Cluster
      • Advanced Cluster
      • Single Server
      • Multi-Tier Cluster
      • Single "Lab" Server
      • Elasticsearch
      • ElastiFlow vs. Filebeat and Logstash
      • RHEL/CentOS
      • Ubuntu/Debian
      • Kibana
      • ML
        • Network Security
        • Machine Learning
        • Availability
          • Network Availability
          • DHCP
          • LDAP
          • DNS
          • NTP
          • RADIUS
          • TCP Sessions
        • Network Security Activity
          • Rare Autonomous System
          • Network Activity
          • Rare Conversation
          • Rare Geolocation
        • Network Security Brute Force
          • Brute Force CLI Access
          • Brute Force Remote Desktop Access
          • Brute Force Attacks
        • Network Security DDoS
          • Denial-of-Service
          • ICMP Flood Attack
          • SYN Flood Attack
          • TCP DDoS Attack
          • UDP Amplification Attack
        • Network Security Recon
          • ICMP Scan
          • Reconnaissance
          • Port Scan
        • Performance
          • Unusual ASN Traffic Volume
          • Unusual Network Interface Traffic Volume
          • Network Performance
    • Opensearch
      • Dashboards
      • Auth Sig V4
    • Splunk
      • Default Search Macro
      • Configuring Data Input & Index
      • Splunk App Installation
    • Output Configuration
  • Additional Guides
    • Catalyst (sFlow)
    • FortiGate
    • hsflowd
    • Configuring Flow Sampling on Juniper Routers
    • Junos OS (sFlow)
    • MikroTik RouterOS
    • OpenWRT (softflowd)
    • Ubiquiti EdgeRouter
    • SonicWall
    • Junos OS
    • Extending SNMP Device Support
    • Flow Device Support Overview
    • SNMP Device Support Overview
    • Generating A Support Bundle
  • FAQ
    • Flows stopped showing up in Kibana (Disk(s) Full)
    • Common reasons why you have discrepancies between ElastiFlow data & reality
    • What Are Snapshots?
    • Importing the wrong dashboards (No data)
  • Knowledge Base
    • Config
      • Elasticsearch Authentication Failure
      • CA Certificate Path Incorrect
      • license/error Invalid Segments
    • Flow
      • Bidirectional Flow Support
      • Configure the UDP Input
      • Flow Records Not Received
      • Netflow v9/IPFIX Template Not Receieved
      • Unsupported sFlow Structures
    • General
      • License Has Expired
      • License Agreement Not Accepted
    • Install
      • .deb Upgrade Fails File Overwrite
    • Operation
      • Flow Collector Queues 90% Full
      • Dashboard Updates
      • Change elastiflow-* Index Name?
  • Elastic Stack Deployment
  • Download Links
Powered by GitBook
On this page
  • Low NTP Request/Response Ratio
  • Low NTP Responses
  • Low NTP Symmetric Messages
  1. Data Platforms
  2. Elastic
  3. ML
  4. Availability

NTP

The Network Time Protocol (NTP) is a protocol used to synchronize the clocks of computers over a network. Its primary purpose is to ensure that all devices on a network, or across multiple networks, have a consistent and accurate time. This synchronization is crucial for various network operations and services, including logging, time-stamping, and the coordination of time-sensitive transactions. NTP utilizes a hierarchical system of time sources, with various levels (strata) of NTP servers distributing the time. The most accurate timekeepers, often connected to atomic clocks or GPS time sources, are at the top stratum, and they disseminate this time to lower-level servers and ultimately to client machines. This structure ensures that even if a network spans across multiple geographical locations, all devices maintain a time that is closely synchronized with a universal standard.

NTP operates as a request/response protocol. An NTP client initiates a request by sending a message to an NTP server or peer, and in response, the server sends back a message with time information. The protocol is designed to account for network latency, thereby ensuring a high degree of accuracy in time synchronization. By analyzing NTP request and response messages across a network, network administrators can detect disruptions or malfunctions in the NTP service. Since accurate timekeeping is critical for many network functions and security protocols, issues with NTP can lead to serious problems such as data corruption, security breaches, or operational errors. Regular monitoring of NTP messages helps in identifying latency issues, server overloads, or unauthorized attempts to alter network time, ensuring the network's integrity and the accuracy of its time-dependent operations.

Low NTP Request/Response Ratio

The Low NTP Request/Response Ratio anomaly detection job is specifically tailored to monitor the Network Time Protocol (NTP) traffic and identify instances where there is an unusually low volume of NTP messages. NTP is crucial for synchronizing the clocks of computers and network devices, ensuring accurate and consistent timekeeping across an entire network. Under normal operations, NTP clients send time synchronization requests to NTP servers, which then respond with the correct time data.

A significantly low ratio of NTP requests to responses, or an overall reduction in NTP message volume, could indicate several types of network or server issues:

  • NTP Server Issues: If NTP servers are overloaded, malfunctioning, or misconfigured, they may not respond to client requests as expected. This can lead to a reduction in response messages, impacting the time synchronization across the network. Inaccurate or unsynchronized time can affect various time-sensitive operations and security protocols.

  • Network Connectivity Problems: Connectivity issues in the network can prevent NTP requests from reaching the servers or block responses from reaching the clients. Problems could include misconfigured network devices, failing network hardware, or physical connectivity issues that interrupt the normal flow of NTP traffic.

  • Security Threats: A low volume of NTP responses might also indicate potential security threats, such as Denial of Service (DoS) attacks specifically targeting NTP servers. Such attacks could overload the servers, making them unable to process legitimate time synchronization requests.

  • Client Configuration or Operational Changes: On the client side, misconfigurations or changes in the operational environment (like disabling NTP on a large number of clients or switching to a different time synchronization service) could result in a decrease in NTP requests, thereby affecting the overall request/response ratio.

Attributes

Attribute
Information

Analysis

temporal

Downloads

Schema
Link

CODEX

ECS

Low NTP Responses

The Low NTP Responses anomaly detection job is engineered to identify situations where there is an unusually low volume of response messages in the Network Time Protocol (NTP) traffic within a network. NTP is essential for maintaining accurate and synchronized time across computer systems and network devices, which is critical for time-sensitive operations and security protocols. In a standard operation, NTP clients send requests to NTP servers, and these servers respond with the appropriate time information.

An unusually low volume of NTP response messages can signify several potential problems:

  • NTP Server Malfunctions or Overload: If NTP servers are experiencing operational difficulties, such as being overloaded with requests or suffering from hardware or software malfunctions, they might fail to respond adequately to the client requests. This lack of responses can lead to unsynchronized or inaccurately synchronized clocks across the network, affecting time-dependent operations and potentially leading to security vulnerabilities.

  • Network Connectivity Issues: Problems in the network infrastructure, such as misconfigured routers, faulty switches, or damaged cables, could prevent NTP response messages from successfully reaching the clients. Network security settings, like firewall rules, could also inadvertently block NTP responses, disrupting the time synchronization process.

  • Security Incidents: A low volume of NTP responses might be indicative of security incidents, such as targeted Denial of Service (DoS) attacks against NTP servers. These attacks can overwhelm the servers, preventing them from processing and responding to legitimate time synchronization requests.

  • Client-Side Issues: On the client side, issues such as incorrect NTP configurations or network policies that restrict communication with NTP servers can result in a failure to receive necessary time updates, even though the clients are sending out requests.

Attributes

Attribute
Information

Analysis

temporal

Downloads

Schema
Link

CODEX

ECS

Low NTP Symmetric Messages

The Low NTP Symmetric Messages anomaly detection job is designed to monitor the volume of symmetric messages in the Network Time Protocol (NTP) traffic and identify scenarios where this volume is unusually low. In NTP, symmetric mode is used when two NTP servers communicate with each other to synchronize their clocks, typically in a peer-to-peer configuration. This mode is crucial for maintaining accurate time across a network of servers, ensuring that each server has the same time reference.

An unusually low volume of NTP symmetric messages can suggest several potential issues:

  • Server Configuration or Operational Problems: If there is a significant decrease in symmetric message exchanges, it could indicate misconfiguration or operational issues with one or more NTP servers. For instance, if a server is incorrectly configured not to operate in symmetric mode, or if there are changes in the network that affect its ability to communicate with its peers, this could result in fewer symmetric message exchanges.

  • Network Connectivity Issues: Problems in the network infrastructure, such as router misconfigurations, switch failures, or physical connectivity issues, can disrupt the communication between NTP servers operating in symmetric mode. Connectivity issues can prevent the servers from sending or receiving the necessary time synchronization messages, leading to a decrease in symmetric message traffic.

  • Hardware or Software Failures: Hardware failures, such as a server crash or network card malfunction, or software issues, including bugs or corrupted NTP software, can lead to a server’s inability to participate effectively in symmetric time synchronization, thereby reducing the volume of symmetric messages.

  • Security Threats: Unusually low symmetric message traffic could also be a symptom of security incidents. For example, a targeted attack on the NTP infrastructure, such as a Denial of Service (DoS) attack, could impair the servers' ability to communicate, disrupting their symmetric time synchronization.

Attributes

Attribute
Information

Analysis

temporal

Downloads

Schema
Link

CODEX

ECS

PreviousDNSNextRADIUS

elastiflow_codex_avail_ntp_resp_ratio_low
elastiflow_ecs_avail_ntp_resp_ratio_low
elastiflow_codex_avail_ntp_resp_low
elastiflow_ecs_avail_ntp_resp_low
elastiflow_codex_avail_ntp_sym_low
elastiflow_ecs_avail_ntp_sym_low