Skip to content

Commit

Permalink
Update README.md
Browse files Browse the repository at this point in the history
  • Loading branch information
aleksibovellan authored Jun 7, 2023
1 parent 9942626 commit cfec071
Showing 1 changed file with 21 additions and 12 deletions.
33 changes: 21 additions & 12 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,27 +1,36 @@
## opnsense-suricata-nmaps
# OPNsense's Suricata IDS/IPS Detection Rules Against Nmap Scans
v. 1.3 / June 6th 2023 by Aleksi Bovellan
## v. 1.4 / June 7th 2023 by Aleksi Bovellan

Because there weren't so many working alerts against Nmap scans built in OPNSense - or even in Suricata's ET Telemetry Pro ruleset - especially against different types of slower Nmap scans, I wrote a bundle of my own Suricata rules to try to catch them all. These rules look for specific Nmap scan packet sizes, other packet specifications and known timing intervals. These rules react to Nmap scan speeds between -T5-T1, and to fragmented Nmap scans too, but without creating too many false alerts, at least in a personal / home / SoHo network setup. See examples below. Expect to see alerts now and then triggered from WAN interface, as a result of everyday scanning and probing. (Detecting the slowest Nmap scans take more time, since the packet rates get so slow.)
Because there weren't many working alert rules against Nmap scans built in OPNSense - or even in Suricata's ET Telemetry Pro ruleset - especially against slower Nmap scan speeds like the -T0, I wrote a bundle of my own Suricata rules to try to catch them all.

Included:

- 3 x Suricata rules to detect most Nmap scans WITHOUT port ranges. (Scan types include at least: -Pn, -sS, -sT, -sU, -A, -f)
- 3 x Suricata rules to detect most Nmap scans WITH more specific, common, or known port targets or ranges. (Scan types include at least: -Pn, -sS, -sT, -sU, -A, -f)
- Bonus: 4 x Suricata rules against any connection attempts to/from port 4444 TCP/UDP (MetaSploit / MeterPreter / NetCat)
- Suricata rules to detect most Nmap scans WITHOUT port ranges. (Scan types include at least: -sS, -sT, -sU, -Pn, -f)
- Suricata rules to detect most Nmap scans WITH more specific, common, or known port targets or ranges. (Scan types include at least: -sS, -sT, -sU, -Pn, -f)
- Suricata rules against any connection attempts to and from TCP/UDP port 4444 (MetaSploit / MeterPreter / NetCat)

(If running both OPNSense/Suricata and CrowdSec at the same time, CrowdSec bans source IP addresses running Nmap scan speeds down to -T2, but not to for -T1-T0. You can always whitelist your own attacking IP address for testing purposes. CrowdSec also ignores fragmented Nmap scans.)
These rules work by looking at specific Nmap packet window sizes, other packet specifications, ports and known Nmap timing intervals. The rules react to Nmap scan speeds between -T5-T0, and to fragmented Nmap scans too, but without creating too many false positive alerts, at least in a personal / home / SoHo network setup. Expect to see some alerts triggered from WAN interface now and then, as the result of everyday scanning and probing.

# STEALTHY NMAP EXAMPLES USING: Nmap 7.9+ / Kali Linux 2023+ VS. OPNsense 23.1+ / Suricata 6.0+ / CrowdSec 1.5+ / FreeBSD 13.1+
Detecting the slowest Nmap -T0 scans - especially the UDP version - can take time, a LOT of time, since the packet rates get so slow. Also, for the Nmap -T0 detection rules to work without triggering too may false positives, their port ranges had to be limited to a list of known ports only. But at -T1 or faster Nmap scan speeds, the detection rules target all ports, and offer some known port identification as an added bonus for better logging purposes, with such more specific alert rules having the word "KNOWN" in their descriptions.

(If running both OPNSense/Suricata and CrowdSec at the same time, CrowdSec bans source IP addresses detected running Nmap scan speeds down to -T2, but not to -T1-T0. You can always whitelist your own attacking IP address in CrowdSec for testing purposes. CrowdSec also ignores fragmented Nmap scans.)

## STEALTHY NMAP EXAMPLES USING: Nmap 7.9+ / Kali Linux 2023+ VS. OPNsense 23.1+ / Suricata 6.0+ / CrowdSec 1.5+ / FreeBSD 13.1+

- nmap -sS -Pn -T0 -> DETECTED BY SURICATA
- nmap -sT -Pn -T0 -> DETECTED BY SURICATA
- nmap -sU -Pn -T0 -> MIGHT BE DETECTED BY SURICATA, BUT THIS WOULD TAKE A VERY LONG TIME
- nmap -sS -Pn -T0 -f -> DETECTED BY SURICATA
- nmap -sU -T0 -f -> DETECTED BY SURICATA
- nmap -sS -Pn -T1 -> DETECTED BY SURICATA
- nmap -sT -Pn -T1 -> DETECTED BY SURICATA
- nmap -sU -Pn -T1 -> DETECTED BY SURICATA
- nmap -sS -Pn -T1 -f -> DETECTED BY SURICATA
- nmap -sU -T1 -f -> DETECTED BY SURICATA
- nmap -T0 scan types -> NOT DETECTED BY SURICATA (TOO SLOW PACKET RATES AT -T0, 1 PACKET / 5 MINUTES)

# USAGE:
## USAGE:

- Save the "local.rules" file, or write all alerts in it into -> /usr/local/etc/suricata/rules/local.rules
- Reload OPNSense's Web GUI's "INTRUSION DETECTION" ‘RULES’ LIST + APPLY RULES
- Save the "local.rules" file, or write all alerts in it, into Suricata's default location -> /usr/local/etc/suricata/rules/local.rules
- If previous custom rules file existed, check for resulting duplicate rule sid numbers after copy-pasting
- Reload OPNSense's Web GUI's "INTRUSION DETECTION" ‘RULES’ LIST
- APPLY Rules

0 comments on commit cfec071

Please sign in to comment.