About

Nuzzle

Nuzzle is a lightweight, fast packet sniffer that looks for unexpected network scans and potential attacks. It is intended for use by people who run online servers. (Regular home users probably won't have a use for it.)

Use Nuzzle to:

Monitor: Learn about the scans and attacks your server typically receives.
Detect: As part of an intrusion detection system (IDS), Nuzzle rapidly provides insight into the types of scans and attacks your system receives.
Prevent: With Fail2Ban, implement a simple but extremely effective intrusion prevention system (IPS).

Background

There are three common types of network attackers that you are likely to encounter online:

General Purpose Attackers. These people are attacking everyone and looking for the low hanging fruit. (You're online. They're online. They will attack you. It's not personal.) These attackers constantly scan and rescan the internet for potentially vulnerable syustems. Some only do one kind of scan, while others seek out any online system and queue it up for a large number of scans.
Blind Attackers. Performing reconnaissance and checking for vulnerabilities takes time. Sometimes it's faster to skip the reconnaissance. Blind attackers do not check if the victim's system could be vulnerable; they attack first and see if it worked. Similar to the general purpose attackers, these people attack everyone.
Directed Attackers. They don't want "any system"; they want your system. These people are often determined and focused. They may use customized attack methods to target your specific system. However, developing a novel attack takes time. Using Nuzzle as an IPS can slow down or discourage directed attackers.

With each of these attacker types, they often scan (or attack) a wide range of ports on your server. They don't just focus on the specific services that you allow through your firewall.

Nuzzle helps you identify the reconnaissance and attack packets. You can configure it with a list of "known open" services that you provide, so you don't log any permitted accesses. Any packets that attempt to access any other ports are logged by Nuzzle.

Enjoy!

Videos

Want to learn more? See the four-part "No-NOC Networking" video series on YouTube!

Install
Binaries
Audit

Monitor
Usage
Exclusions

Usage

Run Nuzzle without any parameters to see the usage.

$ nuzzle

Nuzzle needs to be told which network interface to use. Use '-i list' to see the available interfaces. For example, my system lists:

$ nuzzle -i list Available interfaces: eth0 eth1

In this case, 'eth0' is my external ethernet interface and 'eth1' is my backup interface. Your interface names will likely be different (and you may only have one listed), but select the external ethernet interface.

Running Nuzzle

Since the program needs to monitor the network interface, it must run as root. Use 'sudo' to tell it to run as root. The '-i eth0' identifies the network interface to monitor and '-t' says to print the time with each detected packet. It will output one line per packet. (If you use grep, sed, or awk to parse the output, then also use '-l' to enable line buffering.)

$ sudo nuzzle -t -i eth0

At any time you can use 'Control-C' to stop the program.

Since we didn't provide any permitted ports, every incoming TCP SYN, UDP, and ICMP packet will be logged. Here are a few sample log entries:

2023-03-26 14:26:10.861174 GMT 52.78.125.80[8/icmp] -> 10.207.45.17 ttl=1 : icmp, ping, traceroute
2023-03-26 14:26:15.528165 GMT 200.59.90.183[10468/tcp] -> 10.207.45.17[23/tcp] ttl=47 seq=ipv4.dst : tcp, scanner
2023-03-26 14:26:17.521909 GMT 92.118.39.91[50953/tcp] -> 10.207.45.17[6001/tcp] ttl=238 seq=3bd3fadd : tcp, scanner
2023-03-26 14:26:18.726130 GMT 61.177.172.124[20956/tcp] -> 10.207.45.17[22/tcp] ttl=50 seq=f458fa45 : tcp, scanner
2023-03-26 14:26:21.740570 GMT 16.62.101.45[8/icmp] -> 10.207.45.17 ttl=236 : icmp, ping

Each log line includes:

The time the packet was received. The '-t' parameter uses microseconds and shows the time in GMT.
The remote (client) network address, port, and protocol. For protocols that do not include ports (e.g., ICMP), it lists the type of packet ("8/icmp" is an echo request packet).
A separator "->" that indicates the packet direction from client to server. It also is a useful clue for scripts that parse the output.
The local (server) network address, with port and protocol as appropriate. (In this example, my server uses 10.207.45.17.) For protocols that do not use server-side ports, no port is listed.
The packet's time to live (TTL) field. For IPv6, the TTL value is the "hop limit" field.
A separator ":" that comes before any analysis description. It also is a useful clue for scripts that parse the output.
Keywords that describe the type of scan. These include the protocol name (icmp, tcp, udp, udplite, sctp, etc.) and any informative detections:
- scanner: Any incoming packet that isn't explicitly permitted is listed as a scanner.
- ping: An ICMP or ICMPv6 echo-request packet.
- private: If the remote network address uses a private (non-routable) network range, then it is listed as "private".
- traceroute: Any incoming packet with a TTL of 1 is identified as a traceroute packet.
- redirect host: Congratulations! Someone tried to send you an ICMP redirect packet (often used for man-in-the-middle attacks). It logs the attack and where the attacker tried to redirect your traffic.
The keywords permit you to easily search through the logs for specific types of packets.

Excluding Expected Traffic

If you're running this on a server, then you should explicitly list the services you provide. For example, if you run a web server (80/tcp and 443/tcp) and a DNS server (53/udp), then you would use:

$ sudo nuzzle -t -i eth0 -T 80,443 -U 53

This tells Nuzzle to ignore (not log) any incoming packets to 80/tcp, 443/tcp, and 53/udp. (53/udp is only needed for someone hosting a DNS server. It's not needed for clients accessing DNS.)

Similarly, you can exclude the logging of incoming packets from known hosts. Such as:

nuzzle -i eth0 -t -H 10.1.15.32 -H 192.168.0.0/16 -H 2805:1bad:deed::/48

This tells Nuzzle to exclude packets from 10.1.15.32, the entire subnet 192.168.0.0/16 (192.168.0.0 to 192.168.255.255), and the IPv6 range 2805:1bad:deed::/48 (any IPv6 address that begins with 2805:1bad:deed:).

Unexpected connection-oriented traffic (TCP) is easy to detect: any incoming TCP SYN request to a port that isn't in the permit list is logged. However, connectionless traffic (UDP) is a little more complicated. It is common for a server to send out a UDP packet and wait for a reply. This can happen during a DNS lookup, setting the computer's time, or streaming a video. For connectionless traffic, Nuzzle listens for any outbound UDP packets and temporarily marks the UDP port as permitted so that replies are not logged.

While Nuzzle won't log typical connections to these excluded ports, it will still list any identify traceroute packets. For example, if a scanner uses 'sudo traceroute -T -p 80', then they will be running traceroute against 80/tcp. Nuzzle will notice the traceroute and log the reconnaissance scan. Nuzzle will also record any instances of parasitic trace scans (paratrace).

About IDS
Configure
Monitor

Configuration

Configuring the system as an IDS requires running Nuzzle as a daemon and the collecting logs.

1. Redirect Logging

When Nuzzle runs as a daemon, it logs to syslog. Create a configuration file that tells syslog to place the logs in /var/log/nuzzle.log.

sudo tee /etc/rsyslog.d/20-nuzzle.conf << EOF
template(name="nuzzlelog_list" type="list") {
    property(name="timereported" dateFormat="year")
    constant(value="-")
    property(name="timereported" dateFormat="month")
    constant(value="-")
    property(name="timereported" dateFormat="day")
    constant(value=" ")
    property(name="timereported" dateFormat="hour")
    constant(value=":")
    property(name="timereported" dateFormat="minute")
    constant(value=":")
    property(name="timereported" dateFormat="second")
    constant(value=" ")
    property(name="hostname")
    constant(value=" ")
    property(name="app-name")
    constant(value=":")
    property(name="msg" spifno1stsp="on" ) # add space if \$msg doesn't start with one
    property(name="msg" droplastlf="on" )  # remove trailing \n from \$msg if there is one
    constant(value="\n")
}

if \$programname == 'nuzzle' then /var/log/nuzzle.log;nuzzlelog_list
& stop
EOF

Then restart the log handler: sudo service rsyslog restart

Typical syslog entries only record the day and time (not the year). This logs the full date and time of the log entry.

2. Enable Log Rotation

The /var/log/nuzzle.log file can get large. Rotate it as needed. This sample code rotates it daily and retains 7 days of logs.

sudo tee /etc/logrotate.d/nuzzle << EOF
/var/log/nuzzle.log
{ 
        rotate 7
        daily
        missingok
        notifempty
        compress
        delaycompress
        create 0644 syslog adm
        postrotate
                /usr/lib/rsyslog/rsyslog-rotate
        endscript
}
EOF

You don't need to restart anything; logrotate will notice the file and start using it.

3. Run Nuzzle as a Daemon!

Add all of your permitted port numbers for TCP using -T and UDP using -U. For example, to permit web, email, and SSH, you would use:

sudo nuzzle -d -i eth0 -T 80,443,22

The "-d" says to run as a daemon and log to syslog. We don't include "-t" for the time since syslog already records the time.

If everything works, then you should be able to watch the logs using: tail -f /var/log/nuzzle.log

To make this permanent, add your Nuzzle start command to /etc/rc.local or wherever your system stores startup scripts. (The location varies based on your operating system distribution.)

Sample Monitoring Tasks

The /var/log/nuzzle.log file contains lines like:

2023-03-27 13:47:20 nuzzle: 16.170.133.34[8/icmp] -> {server_ipv4} ttl=234 : icmp, ping
2023-03-27 13:47:25 nuzzle: 16.171.60.3[8/icmp] -> {server_ipv4} ttl=232 : icmp, ping
2023-03-27 13:47:27 nuzzle: 89.248.163.73[43318/tcp] -> {server_ipv4}[13407/tcp] ttl=243 seq=331ad8a6 : tcp, scanner
2023-03-27 13:47:43 nuzzle: 183.136.225.43[39382/tcp] -> {server_ipv4}[4369/tcp] ttl=111 seq=ipv4.dst : tcp, scanner
2023-03-27 13:47:48 nuzzle: 61.177.173.3[17484/tcp] -> {server_ipv4}[22/tcp] ttl=50 seq=77625732 : tcp, scanner
2023-03-27 13:47:49 nuzzle: 185.224.128.17[41515/tcp] -> {server_ipv4}[1088/tcp] ttl=244 seq=aac859f5 : tcp, scanner

This is very easy to parse using grep, sed, awk, and other command-line tools.

As a scan detector, you can now identify elements like:

The most common IP addresses that are doing scans:
zgrep -hv message /var/log/nuzzle.log* | sed -e 's@^.*nuzzle: @@' -e 's@[ \[].*@@' | sort | uniq -c | sort -n
The most common attacked ports:
zgrep -hv message /var/log/nuzzle.log* | grep '\[' | sed -e 's@^.*\[@@' -e 's@\].*@@' | sort | uniq -c | sort -n
The most common types of attacks and scans:
zgrep -hv message /var/log/nuzzle.log* | sed -e 's@^.* : @@' | sort | uniq -c | sort -n

Estimate the average distance to attacking and scanning systems:

zgrep -hv message /var/log/nuzzle.log* |
  sed -e 's@^.*nuzzle: @@' -e 's@[ \[].*ttl=\([0-9]*\).*@ \1@' |
  sort -u |
(
count=0; sum=0; 
while read ip ttl ; do 
   dist=0;
   if [ $ttl -lt 4 ] ; then continue; # Skip traceroutes
   elif [ $ttl -lt 32 ] ; then ((dist=32-$ttl)) ; # Assume: Win95/98
   elif [ $ttl -lt 64 ] ; then ((dist=64-$ttl)) ; # Assume: Linux, Unix, MacOS, Android
   elif [ $ttl -lt 128 ] ; then ((dist=64-$ttl)) ;  # Assume: Windows
   else continue; # don't make assumptions about large TTLs
   fi
   ((sum=$sum+dist))
   ((count=$count+1))
   done
((avg = $sum / $count))
echo "Average distance to attacker: $avg hops"
)

Identify the most common TCP sequence numbers:
zgrep -hv message /var/log/nuzzle.log* | grep 'seq=' | sed -e 's@^.*seq=@@' -e 's@ .*@@' | sort | uniq -c | sort -n
There are over 4 million possible TCP sequence numbers (in hex: 00000000 to ffffffff). However, some appear more often than others. Repeated sequence numbers often indicate a botnet or scanning service.
- The TCP sequence number is usually initialized with a random 32-bit value. You should see lots of sequence numbers with few sightings. If you have fewer than 4 million records, then some values will not be seen and many will only be seen once or twice.
- Some scanning bots, including the Mirai botnet family, encode the destination's IPv4 address in the sequence number. For example, if your server's IP address is 10.198.99.90, then the sequence number will be "seq=0ac6635a". (That's the IPv4 address in hex.) This encoding reduces the tracking requirement by the scanner since it does not need to track which systems it scanned. Instead, the scanner looks at the sequence number in any reply packet to determine which system replied. This case is logged as "seq=ipv4.dst" and will likely be the most common sequence number logged by Nuzzle.
- Some bots initialize the sequence number with constant values, such as zero ("00000000") or 100 ("00000064"). These are often the 2nd or 3rd most common sequence numbers observed by Nuzzle.
- A few scanning bots encode the destination's IPv4 address in the sequence number but in reverse endian ordering. These is logged as "seq=4vpi.dst" (that's "ipv4" backwards).

About IPS
Configure
Monitor
Risks

Usage: Intrusion Prevention System

Network attackers often scan the system before attacking. (On my own server, I found that 70% of web attacks were preceeded by port scans.) If you can detect the initial scanning, then you can block the offending network address before it finds anything on the server to attack. On my systems, this reduced the overall volume of daily attacks by literally 99%. (A 70% reduction happened within hours. It increased to 90% after a week, and became 99% after 9 months.)

A Nuzzle-based intrusion prevention system (IPS) looks for any unexpected incoming packets and temporarily blocks the scanner from accessing anything on the server. When the scanner triggers a nuzzle log entry, it is denied access to everything on the server. This causes all subsequent scans to find nothing. If the attacker finds nothing, then they have nothing to attack. This will dramatically reduce the number of scans and attacks that your server receives, even on your permitted service ports.

Warning: Don't lock yourself out!

Automated blocking can be dangerous if you configure it incorrectly. Specifically, if you remotely log into the server, then an incorrect configuration may lock you out if you forget to include your login port. For example, if you login over ssh on 22/tcp, then be absolutely sure to permit 22/tcp (-T 22). Similarly, if you forget and 'ping' your server, then you will lock yourself out of the server for 15 minutes.

There are some options to prevent locking yourself out:

Alternate interface: For my own servers, I have two network interfaces (wan and lan). I only run Nuzzle on wan (-i wan). This means that I can always login over the lan.
Exclude logs: If you always login to your server from a specific network address, then you can add that address to the Fail2Ban filter. Edit /etc/fail2ban/filter.d/nuzzle.conf and add another entry to the ignoreregex section that identifies your network address.
Ignore bans: Fail2Ban supports a list of IP addresses and subnets that should never be banned. These can be added to the beginning of /etc/fail2ban/jail.local (create the file if it doesn't exist):
[DEFAULT] ignoreip = 127.0.0.1 192.168.0.0/16
You can list individual network addresses or network ranges in CIDR format (with the "/mask").

Don't forget to restart Fail2Ban: sudo service fail2ban restart

Verify that they are marked as ignored:
1. Get the list of jails:
  sudo fail2ban-client status
  Your output will vary based on your jails. Mine shows:
```
Status
|- Number of jail:	4
`- Jail list:	nuzzle, slowlearner, sshd, ssl
```
2. Select any one of the listed jails and display the ignored IP settings. For example, I have a jail named 'slowlearner':
  sudo fail2ban-client get slowlearner ignoreip
You should see the list of ignored IP addresses, such as:
```
These IP addresses/networks are ignored:
|- 127.0.0.1
|- 192.168.0.0/16
```
Permit hosts: If you always connect to your service from the same network address, then you can use Nuzzle's '-H' parameter to list additional addresses that are permitted and not logged. (You can use -H multiple times, once for each permitted address.)
Permit local: Many cloud services forward external traffic to your internal virtual server. The clients will have external network addresses, but the server is on a private address such as "10.0.100.3". Nuzzle's -P parameter permits any clients that use private network addresses. This way, you can always access the server from inside the cloud.
Console access: Whether it is a physical server with a keyboard and monitor or a virtual server, there is always some kind of console for accessing the system. Nuzzle never blocks console access. If you lock yourself out, then you can always use the console to connect back in.

Monitor Fail2Ban

Fail2Ban includes some great features for monitoring the effectiveness of these rules. For example:

See all active jails

Get a list of all of the current jails:

sudo fail2ban-client status

You should see a "Jail list" line that includes "nuzzle". For example:

Status
|- Number of jail:	2
`- Jail list:	nuzzle, sshd

See banned addresses

Get a list of all of the currently banned network addresses for the jail named 'nuzzle':

sudo fail2ban-client get nuzzle banip

See banned durations

Get a list of all of the currently banned network addresses for the jail named 'nuzzle' with timestamps:

sudo fail2ban-client get nuzzle banip --with-time

This will display entries like:

175.30.72.158 	2023-03-26 10:23:57 + 900 = 2023-03-26 10:38:57
94.102.61.39 	2023-03-26 10:24:05 + 900 = 2023-03-26 10:39:05
89.248.165.66 	2023-03-26 02:47:12 + 28320 = 2023-03-26 10:39:12
163.171.135.24 	2023-03-26 10:24:23 + 900 = 2023-03-26 10:39:23
107.170.239.9 	2023-03-26 10:24:43 + 900 = 2023-03-26 10:39:43

It shows the offending IP address, the time each was first banned, and the time when each ban will expire. Most of your entries should say "+ 900" (seconds), indicating a 15-minute ban. Values greater than 900 means that the IP address repeatedly tried to scan the server even though it was already banned. Values larger than 900 denote persistent attacking IP addresses.

You can sort the list by ban duration, which permits identifying the most persistent addresses:

sudo fail2ban-client get nuzzle banip --with-time | sort +4 -n

In this example (from my logs), 89.248.165.66 has been banned nearly 8 hours. (28,320 seconds is 7 hours 52 minutes.) I then searched through my logs for this IP address (grep 89.248.165.66 /var/log/nuzzle.log) and identified 249 scan attempts, with a new scan every 1-5 minutes. This specific network address is associated with a self-proclaimed "researcher" called Recyber. Recyber regularly scans large chunks of the internet and attacks any services that it discovers.

$ host 89.248.165.66
66.165.248.89.in-addr.arpa domain name pointer recyber.net.

Recyber's web site claims that they assist researchers and universities, but they don't identify who runs Recyber, where they are located, how to contact them, or which universities they work with. A preliminary search for universities and academic publications that say they work with Recyber turned up nothing. (Recyber acquired the domain name in 2021. From 2003-2006, the domain was related to an unrelated finance and real estate service, which does appear in academic papers.)

Interestingly, the scan pattern used by Recyber seems to be coordinated with similar patterns from China, Russia, and North Korea. You'll see this if you watch your logs. After a few hours or days, Recyber will stop and Chang Way (AS57523; associated with Russian, China, and North Korea) will start up doing the same type of slow-but-steady scans for hours or days. Then they will change addresses again to some anonymous cloud provider or back to Recyber. Based on this correlation, it appears that Recyber is a front for attackers in Russia, China, and/or North Korea.

General
IPv4 vs IPv6

General Expectations

Whether you run Nuzzle on a honeypot or a production server, there are some interesting patterns that you might notice. For example:

The longer you are online, the more scans and attacks you will receive. A brand new honeypot on a previously-unused IP address (no inherited traffic from a previous server) might initially see 300-500 scans and attacks per hours. However, after a day or two, it will increase to 1,000 per hour. After a month, it might be 5,000 per hour.
Established, popular online servers (production services) can receive 10,000 scans and attacks per minute if they don't do any filtering to deter scans and attacks. The general formula for determining the attack volume is:

(Duration + Popularity) × Services - Filtering = Volume of scans and attacks
- Duration: The longer a server is online, the more likely it will be discovered by scanners and attackers. This usually peaks after being online for six months.
- Popularity: The easier it is to find the service, the more it will be attacked. Very popular servers are scanned and attacked more often than smaller, unknown services. Unlike the duration, there is no apparent upper limit to the volume impact from popularity; more popular means more attacks.
- Services: The more services you provide, the more it will attract scanners and attackers. They will not just target your existing services; they will scan the entire server and attack anything they find.
- Filters: The more defenses you deploy the fewer scans and attacks you will receive.
Look in the logs for the repeat offenders and subnets that keep performing scans. These identify known-hostile providers. By looking at their hostnames and subnet providers, you can quickly identify who is behind the scans and attacks. These include:
- Hostile providers: Every packet from them is malicious. These are often subnets owned and operated by nation-states or organized crime.
- Mostly-hostile providers: These include cloud and ISP services where over 90% of their packets are scans and attacks. You might occasionally see a regular (non-hostile) user, but most of their bandwidth is hostile.
- Bulletproof hosting providers: These are typically cloud and co-location providers that cater to attackers. They are called bulletproof because, regardless of how much you complain, these providers do little or nothing to stop the abuse that eminates from their networks. Hostile organizations can operate from these networks with impunity.
- Various "research" organizations: These are companies that constantly attack everyone on the internet. They often claim to be performing 'research' or are being used by researchers. These companies include Shodan, Censys, BinaryEdge, Rapid7, Recyber, and many others. These researchers will tell you that they are not "attacking" because they don't have the intent to compromise your system. However, there is no 'intent' flag in the packet. The packets sent by these researchers look just like the packets from the known-hostile services. The only difference between the researchers and the known-hostiles is that the researchers attack more often. The differences between these hostile "researchers" and legitimate researchers include:
  1. Real research uses ethical methods. Constantly attacking other online services and performing unauthorized audits is unethical. When applying tests to other people, good researchers get permission first. Shodan and the other network scanners do not have informed consent.
    
    There's a difference between illegal and illicit. While their actions may not be forbidden by law (illegal), they certainly are unethical and go against social norms and values (illicit).
  2. Many of these "researchers" don't publish their work. In the case of Shodan, they do make their scan findings public, but they don't tell the victims of any potential problems. People who use Shodan to find vulnerabilities will learn about your problems before you learn about them.
  3. They often do not follow the scientific process. Collecting data without a testable hypothesis is problematic. I've seen nothing to indicate that they use external validation. Moreover, most of these hostile scanners lack transparency in their processes.
  4. Related to transparency, many of these groups don't identify themselves when doing the scans. Often, they hide behind cloud providers in order to anonymize their attacks. I think this is because they know that what they are doing is hostile, undesirable, and unethical. They don't want people to know that they are behind the attacks.
  5. Their opt-out methods are either unavailable or do not work. In the case of BinaryEdge, they actively criticize anyone who doesn't want to be attacked by their service.
For newer systems and servers that are not very popular, the amount of ICMP traffic will be near the amount of TCP scans. However, older services, popular services, and systems running multiple services will likely see much more TCP than ICMP.

If you don't block ICMP echo request (ping) packets, they you will see a flood of pings coming from Amazon's AWS cloud. They will come in every minute and be (mostly) synchronized to the second. This isn't "Amazon" scanning you; this is some Amazon cloud customer who has a large number of IP addresses. Oh, and it's not just AWS; it's AWS in Asia.
If you do block ICMP echo request (ping) packets, then you won't see the Amazon ping floods. Instead, you'll notice a wide range of network addresses sending "10 pings at a time", all in one second. The packet contents (ICMP payload) includes a timestamp and your server's IP address. This is likely someone trying to do time-based geolocation. (Data travels at nearly the speed of light. By measuring the round-trip latency, they can estimate the maximum distance. By measuring from a wide range of network locations, they can triangulate your server's location to within a few kilometers.)

IPv4 vs IPv6

The vast majority of scans will come from IPv4. In general, IPv6 accounts for a small fraction of the scans and attacks that you will receive. If you use IPv6, then you'll only be scanned if the attackers can find you. How do they find you? They usually look in DNS for an IPv6 address (AAAA record) associated with your hostname.

If you don't have a DNS record with an IPv6 entry, then you probably won't be scanned over IPv6.
If you don't have an easy way to find your domain name, then they won't find your DNS record and you probably won't be scanned over IPv6.
Even if your server supports IPV6 and you have an IPv6 entry, very few attackers and scan software packages support IPv6. Even if they can scan you, it won't be anywhere near the same volume as IPv4.

Since most attackers use hostname-based lookups, how do they find your hostname? Maybe you're running a well-known or popular web site. Maybe someone posted a link with your domain name in it on some public forum. While unlikely, maybe they downloaded a list of registered domain names from somewhere. More likely is that you have a TLS certificate that lists your hostname. (E.g., https://{your IPv4 address}/ returns a TLS certificate or they connect to your mail server's submission port using TLS. In either case, the TLS certificate lists your domain name.) They will download the TLS certificate over IPv4, query the DNS record for the hostname(s) listed in the TLS certificate, and then scan any resulting AAAA records.

Even if they find your IPv6 address, it may take weeks or months before someone sets up a regular ICMPv6 ping scanner. Based on my honeypot tests (repeatedly tested in early 2023):

It will take less than a day for someone to query your IPv4 system for a TLS certificate (HTTPS or mail submission), query your DNS record for an IPv6 (AAAA) entry, and begin scanning your IPv6 address.
When they find your IPv6 address, the scans and attacks will account for about 0.5% of your hostile traffic. This is before the ping scanners start up.
The ICMPv6 ping scanners may take weeks or months to appear (2 weeks to 2 months), but when they appear the ICMPv6 ping scans will account for half of your daily scans and attacks. This doesn't mean that the volume of IPv4 attacks decreases; it means there is an additional high volume from IPv6.
While IPv6 pings may account for over 300,000 pings per week, TCP scans will slowly increase from 0.5% to 4% of the total TCP scans. (I've seen this take over 6 months.)

Disabling IPv4 pings will quickly reduce the number of pings that your server receives over IPv4. However, disabling IPv6 pings will have zero impact on the flood of IPv6 ping requests. Even though your server isn't answering, the flood will continue unabated.

Nuzzle

Background

Videos

Installation

Pre-compiled Executables?

Windows?

Code Audits

Bugs?

Simple Monitor

Usage

Running Nuzzle

Excluding Expected Traffic

Usage: Intrusion Detection System

Configuration

1. Redirect Logging

2. Enable Log Rotation

3. Run Nuzzle as a Daemon!

Sample Monitoring Tasks

Usage: Intrusion Prevention System

Warning: Don't lock yourself out!

Configurating Nuzzle as an IPS

1. Install Nuzzle as a Daemon

2. Install Fail2Ban

3. Patch Fail2Ban

4. Stop discovery scans

5. Create the Fail2Ban Rules