01-30-2024 09:12 AM
HI All,
We have had an incident today that one of the objects are suddenly blacklisted and traffic getting dropped by snort, even though our intrusion policy is not inline and doing IDS. I've looked at global block list in the SI objects, but not listed.
Added to the global do-not-block-list but this didn't do anything, so as a workaround, I've moved the rule to prefilter with fastpath to bypass snort.
Anyone able to tell me why this has happened, and how I can remove the object from the blacklist?
It would be good to know if there are a way to prevent this from happening in the future.
Result:
input-interface: AWS-1(vrfid:0)
input-status: up
input-line-status: up
output-interface: INSIDE(vrfid:0)
output-status: up
output-line-status: up
Action: drop
Time Taken: 664020 ns
Drop-reason: (ssl-preproc) Blocked or blacklisted by the SSL preprocessor, Drop-location: frame 0x000000aaae0c1ff0 flow (NA)/NA
The whole out put of packet-tracer below. As you can see it is hitting the correct access rule at phase 4, but further down the line it gets dropped.
> packet-tracer input AWS-1 tcp fqdn ctxxapd03.mydomain.com 1234 10.1.120.165 80
Mapping FQDN ctxxapd03.mydomain.com to IP address 10.116.20.124
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 22760 ns
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: INPUT-ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Elapsed time: 25605 ns
Config:
Additional Information:
Found next-hop 10.1.4.3 using egress ifc INSIDE(vrfid:0)
Phase: 3
Type: OBJECT_GROUP_SEARCH
Subtype:
Result: ALLOW
Elapsed time: 0 ns
Config:
Additional Information:
Source Object Group Match Count: 24
Destination Object Group Match Count: 11
Object Group Search: 264
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Elapsed time: 995 ns
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit tcp ifc AWS-1 object-group FMC_INLINE_src_rule_268489841 ifc INSIDE object SCAP01 object-group HTTP rule-id 268489841
access-list CSM_FW_ACL_ remark rule-id 268489841: ACCESS POLICY: PROD-ACP - Default
access-list CSM_FW_ACL_ remark rule-id 268489841: L7 RULE: AWS_XAP>SCA_test-30-01-2024
object-group network FMC_INLINE_src_rule_268489841(hitcnt=0)
description: Auto Generated by FMC from src of UnifiedNGFWRule# 712 (UK1-PROD-ACP/default)
network-object object CTXXAPD03(hitcnt=0)
network-object object CTXXAPD02(hitcnt=0)
object-group service HTTP tcp
port-object eq www
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be reached
Phase: 5
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Elapsed time: 995 ns
Config:
class-map class-default
match any
policy-map global_policy
class class-default
set connection advanced-options UM_STATIC_TCP_MAP
service-policy global_policy global
Additional Information:
Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 995 ns
Config:
Additional Information:
Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Elapsed time: 995 ns
Config:
Additional Information:
Phase: 8
Type: FOVER
Subtype: standby-update
Result: ALLOW
Elapsed time: 46658 ns
Config:
Additional Information:
Phase: 9
Type: FLOW-EXPORT
Subtype:
Result: ALLOW
Elapsed time: 1707 ns
Config:
Additional Information:
Phase: 10
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 52917 ns
Config:
Additional Information:
Phase: 11
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Elapsed time: 569 ns
Config:
Additional Information:
Phase: 12
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Elapsed time: 51210 ns
Config:
Additional Information:
New flow created with id 431942314, packet dispatched to next module
Phase: 13
Type: EXTERNAL-INSPECT
Subtype:
Result: ALLOW
Elapsed time: 14225 ns
Config:
Additional Information:
Application: 'SNORT Inspect'
Phase: 14
Type: SNORT
Subtype:
Result: DROP
Elapsed time: 444389 ns
Config:
Additional Information:
Snort Trace:
Packet: TCP, SYN, seq 1616583676
Session: new snort session
AppID: service unknown (0), application unknown (0)
Firewall: starting AC rule matching, zone 24 -> 28, geo 0 -> 0, vlan 0, sgt 0, src sgt type 0, dest_sgt_tag 0, dest sgt type 0, user 9999997, icmpType 0, icmpCode 0
Firewall: block rule, id 268468368, drop
Snort: processed decoder alerts or actions queue, drop
Snort id 6, NAP id 2, IPS id 0, Verdict BLOCKFLOW, Blocked by SSL
Snort Verdict: (black-list) black list this flow
Result:
input-interface: AWS-1(vrfid:0)
input-status: up
input-line-status: up
output-interface: INSIDE(vrfid:0)
output-status: up
output-line-status: up
Action: drop
Time Taken: 664020 ns
Drop-reason: (ssl-preproc) Blocked or blacklisted by the SSL preprocessor, Drop-location: frame 0x000000aaae0c1ff0 flow (NA)/NA
Solved! Go to Solution.
01-31-2024 08:34 AM
There are few bugs in various versions related to FQDN. E.g. this one. Do conditions match your ACP rule?
FTD: Firewall is not matching ACP rules with multiple FQDN objects configured
CSCwh64784
Symptom: Traffic does not match an ACP rule which has more than one FQDN object specified as source or destination networks. Instead, another rule below will be matched. Conditions: 1) An ACP rule is configured with more than one FQDN object as a matching condition. 2) There are no IP-based objects in source or destination networks. Workaround: For FQDN-based rules specify only one FQDN object. If needed, create a separate rule for every FQDN that should be matched. Further Problem Description: When only FQDN objects are used as a network condition, the rule will be ignored by the firewall, even if a DNS server is reachable and FQDNs are successfully resolved.
01-30-2024 09:21 AM - edited 01-31-2024 07:12 AM
Check below
MHM
01-30-2024 10:45 AM
Thanks @MHM Cisco World .
we don’t have SSL policy enabled, and intrusion policy not applied to the affected rules either. Really confused.
01-30-2024 11:15 AM - edited 01-31-2024 07:12 AM
Check below
MHM
01-30-2024 12:18 PM
so there's currently NO SSL policies, can I confirm what you are suggesting is to create a new one and assign that to the access control policy?
Many thanks,
01-30-2024 12:30 PM - edited 01-31-2024 07:13 AM
Check below
MHM
01-30-2024 12:38 PM
I mean we do not have any SSL policies at all, so no SSL policy applied to the ACP.
01-30-2024 12:56 PM - edited 01-31-2024 07:14 AM
Check below
thanks a lot
MHM
01-30-2024 01:16 PM
thanks @MHM Cisco World only problem is that I have 20+rules that contain the
object group with the blacklisted object :'(
But thanks for clarifying that for me, much appreciated.
01-30-2024 11:15 PM
@MHM Cisco World, could you explain please how's that possible that a SYN packet generated by the packet-tracer to TCP/80 can match SSL Policy (if any exists) and "Do not decrypt" default action? Did you notice that port is 80 and not 443?
@atsukane, this drop has nothing to do with block lists. From the packet-tracer output it appears that the packet was dropped because it hits ACP "deny" rule. It also displays rule#. What is not clear is how this relates to SSL preprocessor. Can you disable "ACP > Advanced > TLS Server Identity Discovery > Early Application Detection" in Access Control Policy and test?
Firewall: starting AC rule matching, zone 24 -> 28, geo 0 -> 0, vlan 0, sgt 0, src sgt type 0, dest_sgt_tag 0, dest sgt type 0, user 9999997, icmpType 0, icmpCode 0
Firewall: block rule, id 268468368, drop
Snort: processed decoder alerts or actions queue, drop
Snort id 6, NAP id 2, IPS id 0, Verdict BLOCKFLOW, Blocked by SSL
Snort Verdict: (black-list) black list this flow
01-31-2024 03:50 AM
thank you @tvotna
I've disabled Early Application Detection as suggested, unfortunately packet-tracer is still showing the same drop reason.
And the rule id in the firewall block rule is the default action.
Thanks,
01-31-2024 04:06 AM
How did you configure the default action in ACP and how did you configure the rule which should have matched for this traffic?
01-31-2024 04:24 AM
The default action in the ACP is "Access Control: Block All Traffic".
And looking at one of the affected rules, it has Allow action, the source and destination zones specified (AWS to INSIDE) the source destination networks specified, it's got 11 individual FQDN objects as the source, and 2 hosts objects as the destination.
I've confirmed the affected machine's FQDN is resolving correctly.
The source zone is mapped to two AWS direct connect interfaces that are in the ECMP zone.
We've enabled ECMP over the weekend, not sure if this has anything to do with it.
01-31-2024 05:49 AM
What is HTTP on the right? Is it application name or a port?
01-31-2024 05:59 AM
it's a port object
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide