cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
28161
Views
15
Helpful
11
Replies

Snort Dropping Packets

SteamCoconut
Level 1
Level 1

My access control policy has all traffic set to allow, and is then forwarded to my intrusion policy. My intrusion policy is NOT set to drop. Running show asp drop command on my 4110 FTD shows that almost all of the drops are coming from snort-drop. When I run a packet trace from the FMC for an internal IP address, to a public IP address over port 80 on the data port the result ends up in a snort drop, and I am not sure why... Any help would be greatly appreciated. 

 

Below are outputs for show interface, show asp drop, and a packet trace.

 

Interface Ethernet1/1 "data", is up, line protocol is up
Hardware is EtherSVI, BW 1000 Mbps, DLY 1000 usec
MAC address 7070.8bb7.8e4e, MTU 1500
IPS Interface-Mode: passive
IP address unassigned
Traffic Statistics for "data":
15700519748 packets input, 10991399804502 bytes
0 packets output, 0 bytes
15756174740 packets dropped
1 minute input rate 9708 pkts/sec, 7640212 bytes/sec
1 minute output rate 0 pkts/sec, 0 bytes/sec
1 minute drop rate, 9741 pkts/sec
5 minute input rate 10721 pkts/sec, 8119043 bytes/sec
5 minute output rate 0 pkts/sec, 0 bytes/sec
5 minute drop rate, 10754 pkts/sec

 

Frame drop:
Invalid TCP Length (invalid-tcp-hdr-length) 2
Invalid UDP Length (invalid-udp-length) 2
Flow is denied by configured rule (acl-drop) 1326
Slowpath security checks failed (sp-security-failed) 42
Dst MAC L2 Lookup Failed (dst-l2_lookup-fail) 8024996
Snort requested to drop the frame (snort-drop) 15727665754
Snort instance is down (snort-down) 1108990
Snort instance is busy (snort-busy) 128465
FP L2 rule drop (l2_acl) 3
Dispatch queue tail drops (dispatch-queue-limit) 1593
Packets processed in IDS modes (ids-pkts-processed) 11316601
Not a blocking packet (none) 2
Blocked or blacklisted by snort (snort-module) 179
Blocked or blacklisted by the IPS preprocessor (ips-preproc) 102

Last clearing: Never

Flow drop:

Last clearing: Never

 

Phase: 1
Type: NGIPS-MODE
Subtype: ngips-mode
Result: ALLOW
Config:
Additional Information:
The flow ingressed an interface configured for NGIPS mode and NGIPS services will be applied

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268434434
access-list CSM_FW_ACL_ remark rule-id 268434434: ACCESS POLICY: Inline Active Policy - Mandatory
access-list CSM_FW_ACL_ remark rule-id 268434434: L7 RULE: Allow All
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be reached

Phase: 3
Type: NGIPS-EGRESS-INTERFACE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
Ingress interface data is in NGIPS passive mode.The flow will not egress the device

Phase: 4
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 220284463, packet dispatched to next module

Phase: 5
Type: EXTERNAL-INSPECT
Subtype:
Result: ALLOW
Config:
Additional Information:
Application: 'SNORT Inspect'

Phase: 6
Type: SNORT
Subtype:
Result: DROP
Config:
Additional Information:
Snort Trace:
Packet: TCP, SYN, seq 705363242
Session: new snort session
AppID: service unknown (0), application unknown (0)
Firewall: allow rule, 'Allow All' , allow
Snort id 5, NAP id 2, IPS id 1, Verdict PASS
Snort Verdict: (block-packet) drop this packet

Result:
input-interface: data
input-status: up
input-line-status: up
Action: drop
Drop-reason: (none) Not a blocking packet

1 Accepted Solution

Accepted Solutions

So you're just passively mirroring a port into FTD using the Gigamon? In that case the packets will always be dropped after inspection since they have no place to go (no egress interface).

View solution in original post

11 Replies 11

Marvin Rhoads
Hall of Fame
Hall of Fame

You can check the details of how Snort is handling your flow with:

system support firewall-engine-debug

Run that in one command window and then open a second window. Re-run the packet tracer command with the same parameters. The debug window should show you exactly which ACP or Intrusion rule is blocking the flow.

 

Here's an example debug output which highlights the blocking rule:

10.4.19.25-58194 > 10.50.59.236-53 17 AS 1 I 4 new firewall session
10.4.19.25-58194 > 10.50.59.236-53 17 AS 1 I 4 Starting with minimum 17, 'Tagged-GRE', and SrcZone first with zones 1 -> 1, geo 0 -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 617, payload 0, client 2000000617, misc 0, user 9999997, icmpType 0, icmpCode 0
10.4.19.25-58194 > 10.50.59.236-53 17 AS 1 I 4 no match rule order 19, 'URL Monitor', no url
10.4.19.25-58194 > 10.50.59.236-53 17 AS 1 I 4 no match rule order 20, 'Inside-Outside', DstZone
10.4.19.25-58194 > 10.50.59.236-53 17 AS 1 I 4 match rule order 21, id 268434432 action Block
10.4.19.25-58194 > 10.50.59.236-53 17 AS 1 I 4 deny action

 

Marvin Rhoads
Hall of Fame
Hall of Fame

You can check the details of how Snort is handling your flow with

 

system support firewall-engine-debug

Run that in one command window and then open a second window. Re-run the packet tracer command with the same parameters. The debug window should show you exactly which ACP or Intrusion rule is blocking the flow.

 

Here's an example debug output which highlight the blocking rule:

10.4.19.25-58194 > 10.50.59.236-53 17 AS 1 I 4 new firewall session
10.4.19.25-58194 > 10.50.59.236-53 17 AS 1 I 4 Starting with minimum 17, 'Tagged-GRE', and SrcZone first with zones 1 -> 1, geo 0 -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 617, payload 0, client 2000000617, misc 0, user 9999997, icmpType 0, icmpCode 0
10.4.19.25-58194 > 10.50.59.236-53 17 AS 1 I 4 no match rule order 19, 'URL Monitor', no url
10.4.19.25-58194 > 10.50.59.236-53 17 AS 1 I 4 no match rule order 20, 'Inside-Outside', DstZone
10.4.19.25-58194 > 10.50.59.236-53 17 AS 1 I 4 match rule order 21, id 268434432 action Block
10.4.19.25-58194 > 10.50.59.236-53 17 AS 1 I 4 deny action

 

I cannot get a prompt when connecting to module 1 console... getting stuck at Close Network Connection to Exit.

On a 4110 running FTD, log into the FTD logical device management address. Not the chassis management interface.

Packet trace is showing drop, while system debug is showing allow. Unless I am reading it wrong.

 

10.101.0.132-26485 > 151.101.1.67-443 6 AS 4 I 6 new firewall session
10.101.0.132-26485 > 151.101.1.67-443 6 AS 4 I 6 using HW or preset rule order 3, 'Allow All', action Allow and prefilter rule 0
10.101.0.132-26485 > 151.101.1.67-443 6 AS 4 I 6 allow action
10.101.0.132-26485 > 151.101.1.67-443 6 AS 4 I 6 Got end of flow event from hardware with flags E0000009

 

 

#################################################

 

Phase: 1
Type: NGIPS-MODE
Subtype: ngips-mode
Result: ALLOW
Config:
Additional Information:
The flow ingressed an interface configured for NGIPS mode and NGIPS services will be applied

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268434434
access-list CSM_FW_ACL_ remark rule-id 268434434: ACCESS POLICY: Inline Active Policy - Mandatory
access-list CSM_FW_ACL_ remark rule-id 268434434: L7 RULE: Allow All
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be reached

Phase: 3
Type: NGIPS-EGRESS-INTERFACE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
Ingress interface data is in NGIPS passive mode.The flow will not egress the device

Phase: 4
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 266171670, packet dispatched to next module

Phase: 5
Type: EXTERNAL-INSPECT
Subtype:
Result: ALLOW
Config:
Additional Information:
Application: 'SNORT Inspect'

Phase: 6
Type: SNORT
Subtype:
Result: DROP
Config:
Additional Information:
Snort Trace:
Packet: TCP, SYN, seq 273243856
Session: new snort session
AppID: service unknown (0), application unknown (0)
Firewall: allow rule, 'Allow All' , allow
Snort id 6, NAP id 2, IPS id 1, Verdict PASS
Snort Verdict: (block-packet) drop this packet

Result:
input-interface: data
input-status: up
input-line-status: up
Action: drop
Drop-reason: (none) Not a blocking packet

I just noticed this (it was in your initial posting as well):

 

Ingress interface data is in NGIPS passive mode.The flow will not egress the device

 

How are your interfaces setup? It doesn't look like there's an egress interface.

Chassis management port to switch, FTD management port to switch, and data port to Gigamon

So you're just passively mirroring a port into FTD using the Gigamon? In that case the packets will always be dropped after inspection since they have no place to go (no egress interface).

Thanks for clearing that up for me, much appreciated!

You're welcome.

 

I agree the packet-tracer output can be confusing. I had opened a case just last month because it was telling me "blacklist" even though no Security Intelligence blacklist was actually being hit.

 

That's why I also advise running the debugs. That's what TAC does to get a more complete picture when you open a case.

Hi Marvin,

I have the same problem ("My access control policy has all traffic set to allow, and is then forwarded to my intrusion policy. My intrusion policy is NOT set to drop").The snort engine drop my packets
Could you help me please!


I use inline-tap.IF I disable Inline-Tap , Do I have any problem  ?will snort block my packets?

 

Thanks for your help.




1) Show inline-set

Inline-set IN_OUT_PAIR
  Mtu is 1500 bytes
  Fail-open for snort down is off
  Fail-open for snort busy is off
  Tap mode is on
  Propagate-link-state option is on
  hardware-bypass mode is standby
  Interface-Pair[1]:
    Interface: Ethernet3/1 "OUT"
      Current-Status: UP
    Interface: Ethernet3/2 "IN"
      Current-Status: UP
    Bridge Group ID: 631


> packet-tracer input OUT tcp 8.8.8.8 65000 10.10.X.1 23 detailed

Phase: 1
Type: NGIPS-MODE
Subtype: ngips-mode
Result: ALLOW
Config:
Additional Information:
The flow ingressed an interface configured for NGIPS mode and NGIPS services will be applied
 Forward Flow based lookup yields rule:
 in  id=0x2aacdb162280, priority=501, domain=ips-mode, deny=false
        hits=67818, user_data=0x2aacdaee4220, cs_id=0x0, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
        input_ifc=OUT, output_ifc=any

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any4 object-group FMC_INLINE_dst_rule_268434434 rule-id 268434434
access-list CSM_FW_ACL_ remark rule-id 268434434: ACCESS POLICY: ACP - Mandatory
access-list CSM_FW_ACL_ remark rule-id 268434434: L7 RULE: Inbound Traffic
object-group network FMC_INLINE_dst_rule_268434434
 network-object object VLAN_52

Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached
 Forward Flow based lookup yields rule:
 in  id=0x2aacdb3ec360, priority=12, domain=permit, deny=false
        hits=1963697, user_data=0x2aab952464c0, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, ifc=any
        dst ip/id=10.10.X.0, mask=255.255.255.0, port=0, tag=any, ifc=any, vlan=0, dscp=0x0
        input_ifc=any, output_ifc=any

Phase: 3
Type: NGIPS-EGRESS-INTERFACE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
Ingress interface OUT is in NGIPS inline mode.
Egress interface IN is determined by inline-set configuration

Phase: 4
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 843895392, packet dispatched to next module
Module information for forward flow ...
snp_fp_ips_tcp_state_track_lite
snp_fp_snort
snp_fp_ips_mode_adj
snp_fp_tracer_drop
snp_fp_ips_done

Module information for reverse flow ...
snp_fp_ips_tcp_state_track_lite
snp_fp_snort
snp_fp_ips_mode_adj
snp_fp_tracer_drop
snp_fp_ips_done

Phase: 5
Type: EXTERNAL-INSPECT
Subtype:
Result: ALLOW
Config:
Additional Information:
Application: 'SNORT Inspect'

Phase: 6
Type: SNORT
Subtype:
Result: DROP
Config:
Additional Information:
Snort Trace:
Packet: TCP, SYN, seq 1128432634
Session: simulated packet matches existing snort session
AppID: service unknown (0), application unknown (0)
Firewall: allow rule, id 268434434, allow
Snort id 9, NAP id 1, IPS id 0, Verdict PASS
Snort Verdict: (block-packet) drop this packet

Result:
input-interface: OUT
input-status: up
input-line-status: up
Action: Access-list would have dropped,but packet forwarded due to inline-tap
> show asp drop

Frame drop:
  Invalid TCP Length (invalid-tcp-hdr-length)                                 37
  No route to host (no-route)                                                  2
  Flow is denied by configured rule (acl-drop)                             10738
  Slowpath security checks failed (sp-security-failed)                     20039
  Snort requested to drop the frame (snort-drop)                      71613374683
  Snort instance is busy  (snort-busy)                                  49659661
  FP L2 rule drop (l2_acl)                                                     4
  Dispatch queue tail drops (dispatch-queue-limit)                           976
  Packets processed in IDS modes (ids-pkts-processed)                   55091915
  Not a blocking packet (none)                                                18
  Blocked or blacklisted by the stream preprocessor (stream)            51373101
  Blocked or blacklisted by the session preprocessor (session-preproc)                                        510
  Blocked or blacklisted by the reputation preprocessor (reputation)       30369

Last clearing: Never

Flow drop:

Last clearing: Never
>

 

Thanks for your help.

Review Cisco Networking for a $25 gift card