DROPnet

DROPnet is a lightweight, real-time intrusion prevention system designed to detect and block abusive network traffic at the kernel level.

It is intended for servers exposed to the internet, particularly SSH endpoints, and is optimized for high-noise environments where automated bots, brute-force attempts, and credential stuffing attacks are common. As is the unfortunate nature when it comes to the cosmic background noise of the internet as we know it.

Overview

DROPnet continuously monitors system authentication logs (systemd journal) and identifies malicious patterns such as:

• Failed SSH login attempts.
• Invalid user enumeration.
• Authentication failures from unknown hosts.
• Repeated brute-force behavior from the same source IP.

When abusive behavior is detected, the offending IP is automatically added to a kernel-level IP set (ipset), where it is blocked instantly by firewall rules via iptables or UFW integration.

Resource Efficiency

By enforcing bans at the kernel (netfilter) level before all other traffic, DROPnet reduces system load in a few ways:

• CPU: Malicious SSH traffic is dropped in the kernel before reaching sshd, eliminating the spawn for authentication processes, PAM checks, or session handling.
• Memory: Prevents spawning of SSH child processes (sshd-session, PAM stacks) for repeated or automated login attempts.
• I/O reduction: Reduces system log volume by stopping repeated authentication failures from ever being written to disk or forwarded. It can't write what it never gets.
• Log pipeline efficiency: Decreases pressure on logging systems such as journald and SIEM collectors (e.g. Wazuh), which no longer need to ingest or parse high-frequency brute-force events, as it isn't getting as many anymore.
• Network bandwidth: Dropped packets are discarded immediately at the firewall layer, preventing TCP handshake completion and repeated retransmission attempts from bots.

Impact on Logging Systems (Wazuh / SIEM)

Once an IP is added to the DROPnet ipset, subsequent traffic from that source is blocked at the network layer before a session is established. This has a direct impact on observability tools such as Wazuh and other SIEMs.

SSH authentication logs are only generated if a connection reaches sshd as mentioned earlier in efficiency - this doesn't happen anymore for dropped IPs. After banning, traffic is dropped in the kernel before reaching the SSH daemon as a result, no new authentication events are generated for that IP.

Wazuh will therefore no longer receive repeated "Failed password", "Invalid user", or "authentication failure" events from already-blocked sources when it comes to, in the current revision, SSH. Though the first one-or-two attempts may still get through before DROPnet kicks in; this is normal. Depending on your DROPnet configuration. After it does kick in though repeat-offenders won't get through.

DROPnet shifts enforcement from log-based detection to pre-authentication packet filtering, meaning an SIEM sees fewer events not because visibility is lost and now you've gone blind, but because malicious traffic is being prevented from reaching the application layer in the first place.

How It Works (in a nutshell)

1. Log Monitoring: DROPnet reads live system authentication logs using journalctl.

2. Pattern Detection: It matches known attack signatures using regex-based rules.

3. Abuse Scoring: IPs are tracked within a rolling time window to detect repeated abuse.

4. Automatic Banning: Offending IPs are added to an ipset (dnsrail-dropnet) with a configurable timeout (default: 3 days).

5. Kernel-Level Blocking: iptables/UFW rules drop traffic from banned IPs at line rate in the kernel.

Key Features

• Real-time detection of SSH brute-force attacks.
• Kernel-level blocking using ipset and iptables.
• Time-based bans (default: 3 days).
• Automatic log parsing via systemd journal.
• Low overhead, suitable for VPS and production servers as well SOHO and embedded systems.
• Designed for automation and fleet deployment, we know, because we deploy it on ours.

Requirements

• Linux (systemd-based distro example given, but any is fine)
• ipset using apt install ipset -y, or sudo pacman -S ipset
• iptables or UFW must be installed before running
• Python 3.8 or higher

Getting Started and Firewall Integration

DROPnet requires a firewall rule provided by iptables or ufw through /etc/ufw/before.rules modification.

iptables is the most simple as you'd expect:

sudo ipset create dnsrail-dropnet hash:ip timeout 259200 && iptables -I INPUT 1 -m set --match-set dnsrail-dropnet src -j DROP

ufw takes a few steps to ensure it works appropriately. Start by modifying the before.rules by running nano /etc/ufw/before.rules and adding the following under the ufw-before-input section:

-A ufw-before-input -m set --match-set dnsrail-dropnet src -j DROP

then reload UFW: sudo ufw reload

Here is an example of a properly configured ufw before.rules.

# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines


# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT

# drop DNSRail DROPnet defined packets
-A ufw-before-input -m set --match-set dnsrail-dropnet src -j DROP

followed by the remainder of your default rules. As you can see only:

-A ufw-before-input -m set --match-set dnsrail-dropnet src -j DROP

exists after:

-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT

but before everything else typically:

# quickly process packets for which we already have a connection
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Configuring systemd

Using systemd is standard for most distros at the moment. So our guide will follow the principle that you're using systemd too. Start by creating a service: sudo nano /etc/systemd/system/dropnet.service Insert into it the following:

[Unit]
Description=Dropnet Intrusion Prevention Engine
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
WorkingDirectory=/REPLACE_WITH_DIR/dropnet
ExecStartPre=/bin/sleep 5
ExecStart=/usr/bin/python3 -u /REPLACE_WITH_DIR/dropnet.py

Restart=always
RestartSec=2

StandardOutput=journal
StandardError=journal
SyslogIdentifier=dropnet

# IMPORTANT: remove problematic isolation
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

You'll want to modify this template so that REPLACE_WITH_DIRs are reflective of the directory you cloned dropnet into.

After saving you'll run sudo systemctl daemon-reload && sudo systemctl enable dropnet && sudo systemctl start dropnet.

FAQ

Does DROPnet block traffic immediately?

Yes. Once an IP is added to the ipset, traffic from that source is dropped at the kernel (netfilter) level instantly. This prevents the request from reaching services such as SSH entirely.

---

Does DROPnet still generate logs after an IP is banned?

No additional authentication logs are generated for already-banned IPs because the traffic is blocked before it reaches sshd. This reduces noise in system logs and SIEM tools like Wazuh.

---

How long are IPs banned for?

By default, and with this guide, IPs are banned for 3 days (259200 seconds). This is implemented using ipset time-based entries, not persistent firewall rules, yet.

---

Can I change the ban duration?

Yes. The ban duration is controlled by the BAN_LENGTH variable in the configuration section of the script. It can be adjusted to any valid timeout value supported by the ipset.

---

Does DROPnet persist across reboot?

Not automatically. As it was designed for VPS systems and always-on infrastructure. ipset entries are stored in memory and will be cleared on reboot unless explicitly restored using a saved state or a startup script. This is being developed on.

---

What happens if ipset is full or unavailable?

If ipset is unavailable or fails, DROPnet will continue to log detected IPs but will not be able to enforce kernel-level blocking until the set is restored.

An “overflow” mechanism is planned for future revisions. However, if traffic volume is high enough to stress ipset capacity, the system is likely under sustained attack.

In production deployments, ipset exhaustion is typically mitigated by increasing maxelem, tuning timeout strategies, or switching to higher-level controls such as ASN-based aggregation and upstream network protection (if available). Whilst DROPnet can help mitigate "cosmic-noise", and legitimate attacks it, in itself, is not a replacement for DDoS protection alone.

---

Does DROPnet replace fail2ban?

DROPnet focuses on ultra-low latency response by acting directly on streamed authentication logs and inserting offending IPs into a kernel-level ipset for immediate enforcement.

While fail2ban also enforces bans at the firewall level (iptables/nftables), it typically operates through log parsing and periodic rule evaluation, which can introduce additional delay between attack attempt and enforcement.

DROPnet is designed to minimise this delay by reacting in real time to journal events and applying immediate kernel-level filtering via ipset and rule in the INPUT chain which typically sits "above" (in front of) fail2ban.

---

Is DROPnet safe to use on production servers?

Yes, provided firewall rules are correctly configured and SSH access is not locked out. It is recommended to whitelist known administrative IPs before deployment. We're developing a built-in whitelist in future releases.

---

Can DROPnet block legitimate users?

Yes, if thresholds are configured too aggressively or if legitimate users repeatedly fail authentication. It is recommended to tune THRESHOLD and CATCH_TIME based on traffic patterns or add them to a whitelist.

---

Does DROPnet inspect packet contents?

No. DROPnet does not perform deep packet inspection. It only reacts to system authentication logs generated by SSH and system services.

Support

For support, you can reach out on discord as Charlie, or InTheMansion irc channels #lobby, #mansionsec, #dnsrail or #vulpinelinux.

License

dropnet © 2026 by DNSRail is licensed under:

Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International