LoFP LoFP / network

network rule

TitleTags
authorized administrators or automation may purge multiple queues during maintenance, testing, disaster recovery, or application resets. confirm the client, authenticated rabbitmq user, affected queues, and change window before escalating. add exceptions for verified administrative sources rather than reducing the queue-cardinality threshold.
authorized red-team or penetration testing tooling exercising the cve-2026-20253 exploit chain. legitimate splunk user activity should not produce postgresql connection-string keywords, suspicious filesystem targets, empty basic auth credentials, or unauthenticated 400 responses on the recovery endpoints.
authorized vulnerability scanners (nessus, tenable, qualys, etc.) running cve-2026-41940 plugins will reproduce the exploit shape. validate against scan windows and source ips of approved scanners before escalating.
backup deduplication engines, migration utilities, and filesystem sync tools can generate high volumes of legitimate nfs writes. validate the source against known backup or storage-management hosts before escalating.
cloud agents (ssm, waagent, cloud-init, instance connect) and authorized scanners may reach the same paths during provisioning or health checks. exclude known agent user agents, source hosts, or parent processes after baselining.
database administrators and scheduled data-processing jobs may legitimately use copy program for import or export workflows. confirm the command, client address, database role, maintenance context, and resulting process activity before escalating.
database administrators may install approved native mysql user-defined functions during planned maintenance. validate the function and library names, the client address, the maintenance window, and whether the shared library was supplied through an approved software deployment process.
database administrators, deployment automation, test teardown jobs, and schema migration tools may issue destructive commands legitimately. validate the client address, target resource, change window, and associated administrator activity before escalating.
developers or database administrators may deploy approved javascript udfs in environments where scripted functions are intentionally enabled. validate the function body, client address, cassandra version, configuration, and change window before escalating.
downloading rar or powershell files from the internet may be expected for certain systems. this rule should be tailored to either exclude systems as sources or destinations in which this behavior is expected.
if you have front-facing proxies that provide authentication and tls, this rule would need to be tuned to eliminate the source ip address of your reverse-proxy.
internal hosts that legitimately send mail to external mail transfer agents listening on tcp port 26 may cause false positives. mail servers or applications with known external smtp relays can be excluded by source or destination ip address as this is expected behavior.
iot (internet of things) devices and networks may use telnet and can be excluded if desired. some business work-flows may use telnet for administration of older devices. these often have a predictable behavior. telnet activity involving an unusual source or destination may be more suspicious. telnet activity involving a production server that has no known associated telnet work-flow or business requirement is often suspicious.
legacy internal applications, industrial control systems, or embedded devices may still require deprecated tls versions or weak ciphers. exclude known legacy destination ips or subnets after validation.
legitimate acme certificate renewal agents (cert-manager, certbot, caddy) use acme-tls/1 during tls-alpn-01 challenges. a single incomplete challenge due to a network timeout can occur normally, but five or more incomplete sessions from the same source within the detection window is abnormal even for misconfigured acme clients. tls decode_error or illegal_parameter alerts can also be produced by buggy tls clients or misconfigured load balancers. suppress by adding known acme client source ips or acme ca validation ip ranges to an exception list.
legitimate nfs root squashing misconfiguration, administrative automation, or backup appliances may present uid 0 from known infrastructure. confirm the source ip against approved nfs client inventories before closing.
legitimate postgresql recovery operations performed by splunk administrators through the backup and restore api. these should be rare and originate from known management networks. if such operations occur in your environment, scope exceptions by source ip or approved management network rather than suppressing the rule entirely.
legitimate site-to-site or client vpns that use ipsec nat traversal will establish outbound tunnels on udp port 4500. where these tunnels are expected, the internal source hosts or external vpn gateway ip addresses can be excluded. requiring both the source and destination port to be 4500 already removes alerts caused by an external server coincidentally replying to an ephemeral udp source port of 4500.
misconfigured phones, expired credentials, or provisioning errors can generate repeated register failures from a single device. validate the client, affected extensions, and registration state before escalating.
new application servers, autoscaled workloads, cache warmers, deployment jobs, administrative tools, and failover systems may legitimately write to memcached for the first time. validate the client and server roles, affected keys, deployment context, and application behavior before escalating.
publicly accessible thrift apis, partner integrations, remote offices, and routed environments that preserve public client addresses can generate legitimate alerts. validate the client, service, method, server role, and expected network path before escalating.
shared egress addresses, managed service providers, help desks, identity-provider outages, password rotation, or several legitimate users entering incorrect credentials before another user successfully authenticates may trigger this rule. add exceptions only for confirmed shared-service sources and scope them to the relevant appliance.
some legitimate provisioning or monitoring tools enumerate extensions during onboarding. validate the source against known pbx management systems before closing.
some network security policies allow rdp directly from the internet but usage that is unfamiliar to server or network owners can be unexpected and suspicious. rdp services may be exposed directly to the internet in some networks such as cloud environments. in such cases, only rdp gateways, bastions or jump servers may be expected expose rdp directly to the internet and can be exempted from this rule. rdp may be required by some work-flows such as remote access and support for specialized software products and servers. such work-flows are usually known and not unexpected.
this rule could identify benign domains that are formatted similarly to fin7's command and control algorithm. alerts should be investigated by an analyst to assess the validity of the individual observations.
this rule should be tailored to either exclude systems, as sources or destinations, in which this behavior is expected.
this rule should be tailored to exclude systems, either as sources or destinations, in which this behavior is expected.
vnc connections may be made directly to linux cloud server instances but such connections are usually made only by engineers. vnc is less common than ssh or rdp but may be required by some work flows such as remote access and support for specialized software products or servers. such work-flows are usually known and not unexpected. usage that is unfamiliar to server or network owners can be unexpected and suspicious.
vnc connections may be received directly to linux cloud server instances but such connections are usually made only by engineers. vnc is less common than ssh or rdp but may be required by some work-flows such as remote access and support for specialized software products or servers. such work-flows are usually known and not unexpected. usage that is unfamiliar to server or network owners can be unexpected and suspicious.