LoFP LoFP / network

network rule

TitleTags
approved rmm deployments, one-time support sessions, product migrations, and security testing can trigger this rule. recursive resolvers or dns forwarders can also appear as the client when sensor placement does not preserve the originating endpoint address.
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 security testing may deliberately write a harmless forged pitboss or ppe record to validate exposure or detection. confirm the source and testing window. normal pitboss and packet-engine records should not contain shell separators, command substitution, pipes, or redirection.
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.
cdn, cloud load-balancer, software-update, and telemetry hostnames can be long and change often. recursive resolvers, forwarders, nat gateways, and localhost dns listeners can also combine queries from many endpoints under one client address. dns research, testing, and security tools can generate null or unusually long txt queries. validate the apex domain and whether the source is an endpoint before treating the activity as tunneling.
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.
custom health checks that call hostgaplugin /versions or /vmsettings with curl. exclude the specific user agent or host group after validating the script.
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.
development servers, lab environments, newly stood-up self-hosted services on public ips (vps, homelab, nas, cameras, and similar iot), and some vendor appliances may use recently issued self-signed certificates. exclude known internal development egress or validated vendor destinations after review.
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.
managed service provider, helpdesk, migration, software inventory, and lab systems may legitimately contact multiple rmm vendors. recursive resolvers can aggregate queries from many endpoints and must be identified before treating the client ip as one asset.
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 administrators or vpn users, travel, mobile networks, isp address rotation, managed service providers, and first observations after integration onboarding or retention loss can trigger this rule.
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.
new or infrequently used iot devices, telemetry agents, application messaging services, test environments, and broker migrations can create legitimate first-seen relationships. sensor onboarding or retention gaps can also cause existing relationships to appear new.
newly deployed legitimate site-to-site or client vpn gateways, or established gateways that were inactive for more than 5 days, will generate an alert when first observed. where these peers are expected, their external destination ip addresses can be excluded.
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.
split-horizon dns, vpn transitions, service discovery, failover, hairpin nat, and dual-stack names that publish a public a record with a unique-local aaaa record can legitimately produce public and private answers for the same name. recursive resolvers, dns forwarders, and localhost listeners can also aggregate many endpoints under one client address. security products may sinkhole suspicious domains to loopback or private addresses with short ttls. confirm the domain, resolver placement, and client identity before adding an exception, and scope exceptions by registered domain or client rather than globally.
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.