The Linux Net Filter kernel module is the mechanism that protects both ingress and egress connections of the Defend-O-Tron.
The Intrusion Detection System (IDS) of the Defend-O-Tron hooks into the AF_PACKET TAP built into the Linux kernel to read packets on a RAW level thus not interfering heavily with the intended traffic flow. (5-10ms delay on average)
Source: https://thermalcircle.de
You can read more on Honeypots here Wikipedia Honeypot and Linux Net Filter
The built-in honeypot is a set of NFT rules that examine traffic destined to a pre-configured list of well known IP protocol ports that are commonly brute force inspected by bad actors.
These ports are not exposed on the Defend-O-Tron as it is not actively on the internet, the rules are configured to check if connections are attempted to the destination IP and port of your firewall/router on the ingress port (ISP-IN) of the device. This mechanism helps relieve the stress of 24/7 port scans to your firewall while trapping and mitigating potential attacks before reaching your firewall/router.
Editing any NFT rules on the Defend-O-Tron requires a reboot.
Currently these ports are configured for the honeypot by default.
It was decided that ICMP is best not put into the honeypot rules, in order to not interfere with Path MTU Discovery (PMTUD) and IPv6, since IPv6 relies heavily on the ICMP6 protocol in various networking negotiations. IPv6 addresses are still blocked if an address is considered a bad actor.
There is lots of opportunity to have a massive list of weak ports being honey potted, however that was counter intuitive since most bad actors start with the common ports first then progress to other intrusion methods if a connection is available. Performance is key here, this is where the IDS on the Defend-O-Tron does a deeper packet inspection allowing this list to stay small and balanced. Minor situational tweaks can be made if your environment requires it.
For example, adding UDP port 5060 to the honeypot will most likely end up with your SIP provider getting blocked and your office not having phone service. Since we don't know in advance of every SIP provider on the planet there's no way to whitelist them. The IDS instead does a packet inspection of the SIP protocol and makes decisions based on the information gathered in the packet. In this case it's a good idea to consider secure SIP over TLS and SRTP as an additional protection mechanism, you can read more here
If a bad actor attempts to scan or connect these ports a log entry is generated that Crowdsec will read and makes a decision based on the scenario for honeypots. If it's found to match then the offender is immediately blocked from any more ingress connection attempts for a period of up to 4 hours (this is currently the maximum time allowed by NFT rules).
These rules will also block connection attempts on the egress (ISP-OUT) if an internal user attempts to connected to one of the banned IP addresses in the log.
If a good actor inadvertently gets blocked there are a few choices for mitigation.
admin@defend-o-tron:~# cscli decisions list
--- Long list of blocked IP's ---
cscli decisions delete -r 1.2.3.0/24 (subnet)
cscli decisions delete -i 1.2.3.4 (single IP)
cscli decisions delete --id 42 (decision ID)
Note: A good actor may get blocked again if they aren't whitelisted, if this is the case they may be not so good and further investigation might be prudent.
This list is curated based on common port scans to potentially weak services. You should ony attempt this if you have a good knowledge of Linux and NFT rules. Edit at your own risk.
There are 3 ACL sets that control the honeypot, they are:
The ACL files control the ports and IP addresses that are being inspected. These are all defined as an NFT list. It is usually not required to edit either the Good or Bad ACL list unless you need to whitelist an internal IP or subnet, however if you need to make changes make sure to backup the files before editing.
NOTE: If you are operating an Internet exposed service that uses a default ACL port then you'll need to remove it from the list. For example: SMTP server on TCP port 25. HINT: It's more secure to use SMTP over TLS on port 465 or 587.
~$ nano /etc/nftables.d/honeypot-acl.nft
# Scanned ports used in honeypot blocking
# TCP Most Common Ports
define tcp-scanports={ 20-21, 22, 23, 25, 445, 1433-1434, 3128, 3306, 3389, 8291 }
#
# UDP Most Common Ports
define udp-scanports={ 69, 135-139, 161 }
~$ nano /etc/nftables.d/goodactors-acl.nft
# Allowed Lists (Good actors)
# IPv4
# Most Common Routers
define goodacl4 = { 192.168.0.0/16 }
# IPv6
# Link Local addresses
define goodacl6 = { fe80::/10 }
~$ nano /etc/nftables.d/badactors-acl.nft
# Block Lists
# Addresses that are always blocked (Bad actors)
#
# IPv4 Bad actors
define badacl4 = { 10.10.10.10 }
# IPv6 Bad actors
define badacl6 = { f000::/64 }
#!/usr/sbin/nft -f
# Copyright (c) 2024 Awesome-O Gadgets.
#
# Honeypot: Logs connection attempts to
# specific ports which Crowdsec parses.
# Ulogd2 group 2 is for honeypot logs.
# See: /etc/ulogd.conf
#
# It was Gero Schäfer's idea to include
# the honeypot for a feedback loop to
# Crowdsec.
#
# Use the honeypots-acl.nft to control which
# ports are considered bad.
#
table inet honeypot {
# ACL's
include "/etc/nftables.d/honeypot-acl.nft"
# ACL Sets
include "/etc/nftables.d/goodactors.nft"
include "/etc/nftables.d/badactors.nft"
set banned-exempt4 {
type ipv4_addr;
flags interval, timeout;
auto-merge
elements=$banexempt4
}
set banned-exempt6 {
type ipv6_addr;
flags interval, timeout;
auto-merge
elements=$banexempt6
}
# Scanned ports used in honeypot blocking
# TCP Common Ports
set tcp-scan-ports {
type inet_service;
flags interval;
elements=$tcp-scanports
}
# UDP Common Ports
set udp-scan-ports {
type inet_service;
flags interval;
elements=$udp-scanports
}
# Checks on the prerouting hook
chain honeypot {
type filter hook ingress devices={ $NIC_INGRESS } priority mangle;
counter
meta nfproto vmap { ipv4: jump honeypot-ip4, ipv6: jump honeypot-ip6 }
}
# IPv4
chain honeypot-ip4 {
counter
ct state { untracked } ip saddr != @banned-exempt4 counter jump check-banned-ip4
ip saddr != @banned-exempt4 counter jump check-banned-ip4
}
chain check-banned-ip4 {
tcp dport @tcp-scan-ports counter log prefix "TCP4 honeypot:" group 2 limit rate 12/minute
# update @bad-actors4 { ip saddr timeout 60m }
udp dport @udp-scan-ports counter log prefix "UDP4 honeypot:" group 2 limit rate 12/minute
# update { ip saddr timeout 60m } @bad-actors4
return
}
# IPv6
chain honeypot-ip6 {
counter
ct state { untracked } ip6 saddr != @banned-exempt6 counter jump check-banned-ip6
ip6 saddr != @banned-exempt6 counter jump check-banned-ip6
}
chain check-banned-ip6 {
tcp dport @tcp-scan-ports counter log prefix "TCP6 honeypot:" group 2 limit rate 12/minute
# update @bad-actors6 { ip6 saddr timeout 60m }
udp dport @udp-scan-ports counter log prefix "UDP6 honeypot:" group 2 limit rate 12/minute
# update ip6 saddr timeout 60m @bad-actors6
return
}
}
You should only attempt this if you have a good knowledge of REGEX, GROK, Crowdsec Parsers and Scenarios. Edit at your own risk. Always backup the original files and test your edits and changes first. Crowdsec has a built in testing utility for parsers and scenarios here Although it's probably a good idea to offer suggestions and wait for the updates instead of attempting this.
Both the Honeypot parser and scenario make use of GROK and REGEX patterns.
There are 2 files that control the Crowdsec Parser/Scenario configuration, they are:
Editing either of these files requires a restart of the docker container
admin@defend-o-tron:~# do-stacks rm crowdsec
[Container gets stopped]
admin@defend-o-tron:~# do-stacks
~$ nano /opt/deploy/crowdsec/config/parsers/honeypot-ban.yaml
name: awesome-o/honeypot-banlog
description: "Parses inbound ban logs from the honeypot mangle rules"
author: "Awesome-O Gadgets"
format: 2.0
debug: false
filter: "evt.Parsed.message contains 'honeypot'"
onsuccess: next_stage
pattern_syntax:
TSTAMP: '%{TIMESTAMP_ISO8601:timestamp}'
HOSTNAME: '%{WORD:log_host}'
HONEY_MAC: 'MAC=%{MAC:srcmac}:%{DATA}:%{MAC:dstmac}:%{DATA}'
HONEY_BAN_BASE_LOG: '%{WORD:ban_type} honeypot: IN=%{WORD:iface} OUT=?(%{DATA:iface_out}) %{HONEY_MAC} SRC=%{IP:src_ip} DST=%{IP:dst_ip} LEN=%{DATA:len} %{GREEDYDATA} PROTO=%{WORD>
nodes:
- grok:
apply_on: message
pattern: '%{HONEY_BAN_BASE_LOG} URGP'
statics:
- meta: log_type
value: honeypot
- grok:
apply_on: message
pattern: ': %{HONEY_BAN_BASE_LOG} SEQ=%{INT:seq}'
statics:
- meta: log_type
value: honeypot
statics:
- meta: service
value: honeypot_banlog
- meta: state_type
expression: evt.Parsed.state
- meta: log_host
expression: evt.Meta.machine
- meta: ban_type
expression: evt.Parsed.ban_type
- meta: ban_protocol
expression: evt.Parsed.proto
- meta: ban_port
~$ nano /opt/deploy/crowdsec/config/scenarios/honeypot-bf.yaml
type: trigger
name: awesome-o/honeypot-bf
description: "Detect bruteforce connection attempts from honeypot mangle rules"
author: 'Awesome-O Gadgets'
version: '1.0'
format: 2.0
debug: false
filter: |
(evt.Meta.log_type == 'honeypot' and evt.Meta.service == 'honeypot_banlog')
distinct: evt.Meta.ban_type
groupby: "evt.Meta.source_ip + '-' + Lower(evt.Meta.ban_protocol + '-' + evt.Meta.ban_type)"
blackhole: 1m
labels:
behavior: "generic:bruteforce"
label: "Honeypot bruteforce scan"
confidence: 3
spoofable: 0
classification:
- attack.T1595
- attack.T1110
service: honeypot-bf
type: bruteforce
remediation: true
The column on the right shows the metadata added from the honeypot rules, as seen on the Crowdsec App dashboard.
Regular Expression, or regex or regexp in short, is extremely and amazingly powerful in searching and manipulating text strings, particularly in processing text files. One line of regex can easily replace several dozen lines of programming codes. However this language takes some time to master and can cause serious side effects if not used correctly. See here
Grok is a regular expression dialect that supports reusable aliased expressions. Grok works really well with syslog logs, Apache and other webserver logs, mysql logs, and generally any log format that is written for humans and not computer consumption.