Project

General

Profile

Actions

Bug #1865

closed

IPS (inline) mode no logging in drop.log

Added by Mister X over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

Description

Hello,

I did install suricata(3.1.1) on Kali linux & enabled drop in suricata.yaml & added the following 2 rules to the end of drop.rules file:

alert icmp any any <> any any (msg:" Alert ICMP"; itype: 8;)
drop tcp any any <> any any (msg:"Alert TCP XMAS"; flags:FPU; classtype:misc-attack; sid:10000003; rev:1;)

-> then I did :
iptables -I INPUT -j NFQUEUE
iptables -I OUTPUT -j NFQUEUE
iptables -I FORWARD -j NFQUEUE

>then startet suricata in inline mode -> did ping from another VM to this one -> icmp Alert was logged in fast.log
>then did xMas-Scan in zenmap from another VM to this one -> tcp Drop was not logged in drop.log but I know packets were dropped, because:

"Verdict: Accepted 10, Dropped 10, Replaced 0"

I also did change the "drop" rule in drop.rules file to "alert tcp any any <> any any (msg:"Alert TCP XMAS";...)" and repeated the xMas-Scan
-> no tcp Alert logging in fast.log (also not in drop.log)

Why does'nt suricata log tcp-Drop or tcp-Alert in inline mode ? (In IDS mode everything gets logged)

Thanks in Advance

Actions #1

Updated by Victor Julien over 7 years ago

I think there are currently 2 ways 'silent drops' can happen:

1. some stream engine packet rejections (need to check)

2. dropped packet when an entire flow is dropped. If a drop in the flow causes the rest of that flow's packets to be dropped, the drops after the first are silent. At the time this seemed a good idea in an attempt to prevent log flooding.

Actions #2

Updated by Victor Julien over 7 years ago

  • Priority changed from Immediate to Normal
Actions #3

Updated by Victor Julien over 7 years ago

https://github.com/inliniac/suricata/pull/2225 adds an option for the EVE drop record logging:

- drop:
    alerts: yes      # log alerts that caused drops
    flows: all       # start or all: 'start' logs only a single drop
                     # per flow direction. All logs each dropped pkt.

The 'flows: all' option logs every dropped packet instead of just the first ones per flow.

It will not always contain a drop reason though. If the stream engine drops it or all packets in a flow are dropped because a drop rule matched earlier, it will not contain sure info yet.

Actions #4

Updated by Andreas Herz over 7 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD
Actions #5

Updated by Victor Julien over 7 years ago

  • Status changed from New to Closed
  • Assignee deleted (OISF Dev)
  • Target version deleted (TBD)
Actions

Also available in: Atom PDF