5.0.3 smtp ips drop doesn't work fully?

Help
1

Greetings,

I’m running 5.0.3 in IPS and only monitor source/dest port 25. Looking at eve it says drop

{“timestamp”:“2020-06-17T08:05:32.839965-0500”,“flow_id”:575006279918989,“event_type”:“drop”,“src_ip”:“93.177.102.176”,“src_port”:61048,“dest_ip”:“x.x.x.x”,“dest_port”:25,“proto”:“TCP”,“drop”:{“len”:52,“tos”:0,“ttl”:53,“ipid”:41502,“tcpseq”:3107473674,“tcpack”:1532258928,“tcpwin”:123,“syn”:false,“ack”:true,“psh”:false,“rst”:true,“urg”:false,“fin”:false,“tcpres”:0,“tcpurgp”:0}}

but yet the email still comes through (based on time stamp 08:05:32)?

Received: from ([127.0.0.1])
by [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id QSWBfFDhn1Yx for <>;
Wed, 17 Jun 2020 08:05:32 -0500 (CDT)
Received: from bananahorizon.icu (bananahorizon.icu [93.177.102.176])
by (Postfix) with ESMTP id 4935815A0007
for ; Wed, 17 Jun 2020 08:05:29 -0500 (CDT)

Here’s the only prior record between 07:56:20 and 08:05:32

{“timestamp”:“2020-06-17T07:56:20.000155-0500”,“flow_id”:242397530740470,“event_type”:“flow”,“src_ip”:“93.177.102.176”,“src_port”:62886,“dest_ip”:“x.x.x.x”,“dest_port”:25,“proto”:“TCP”,“flow”:{“pkts_toserver”:3,“pkts_toclient”:0,“bytes_toserver”:3052,“bytes_toclient”:0,“start”:“2020-06-17T07:55:18.251638-0500”,“end”:“2020-06-17T07:55:18.251962-0500”,“age”:0,“state”:“new”,“reason”:“timeout”,“alerted”:false},“tcp”:{“tcp_flags”:“00”,“tcp_flags_ts”:“00”,“tcp_flags_tc”:“00”}}

It seems to me suricata blocks partially or something wrong with my setup?

Thanks.

2

How does your configuration look like and can you give us more details on your setup?

3

Hi Andreas,

I compiled it from source with nfq enabled. I run it with sudo suricata -c /etc/suricata/suricata.yaml -q 0

I wanted to get start with smtp first in IPS mode so I renamed the original /var/lib/suricata/rules/suricata.rules and replaced the content with DROP Spamhaus rules.

drop ip [5.134.128.0/19,5.183.60.0/22,5.188.10.0/23,23.92.80.0/20,23.239.64.0/19,24.233.0.0/19,27.126.160.0/20,27.146.0.0/16,36.0.8.0/21,36.37.48.0/20,36.116.0.0/16,36.119.0.0/16,37.252.220.0/22,41.77.240.0/21,41.93.128.0/17,42.0.32.0/19,42.1.128.0/17,42.96.0.0/18,42.128.0.0/12,42.160.0.0/12] any -> $HOME_NET any (msg:"ET DROP Spamhaus DROP Listed Traffic Inbound group 1"; reference:url,www.spamhaus.org/drop/drop.lasso; threshold: type limit, track by_src, seconds 3600, count 1; classtype:misc-attack; flowbits:set,ET.Evil; flowbits:set,ET.DROPIP; sid:2400000; rev:2763; metadata:affected_product Any, attack_target Any, deployment Perimeter, tag Dshield, signature_severity Minor, created_at 2010_12_30, updated_at 2020_06_14;)

and so on…

Here’s the rules section from suricata.yaml

default-rule-path: /var/lib/suricata/rules

rule-files:
  - suricata.rules

Everything else is default and log files are eve and stats.

build-info

Features: NFQ PCAP_SET_BUFF AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK PCRE_JIT HAVE_NSS HAVE_LUA HAVE_LIBJANSSON TLS MAGIC RUST
SIMD support: SSE_4_2 SSE_4_1 SSE_3
Atomic intrinsics: 1 2 4 8 16 byte(s)
64-bits, Little-endian architecture
GCC version 7.5.0, C version 199901
compiled with _FORTIFY_SOURCE=2

i also have these after starting suricata in IPS mode

sudo iptables -I INPUT -p tcp --sport 25  -j NFQUEUE
sudo iptables -I OUTPUT -p tcp --dport 25 -j NFQUEUE
4

So the mail is sent to the same system suricata is running on? Since in the iptables you don’t have the NFQUEUE jump in the FORWARD section.

And try to remove the threshold keyword in the rule, this might result in just one attempt being blocked within 3600s.

Can you reproduce it with a pcap?