ā07-23-2024 07:32 AM
Trying to map a drive from Hub Server to Management Site Server. Hub site is protected by a FTD 2130, when I try and map the drive I am getting denied by a Snort Drop (Rule ID 268434432). The users kept trying to connect an eventually it looks like Snort blacklisted the flow. Seeing the snort drops in a packet capture via FMC.
Access Policy is passing the traffic (Hub Host 10.6.1.150 to Mgmt Host 10.1.1.151 tcp/445 and tcp/139) but kicks it over to snort for further processing.
I see the rule ID hits on the FTD via CLI and I see hits but where do I find that rule in FMC? When I look in the Polices-->Intrusion-->Snort3 Base Policy that ID doesn't show up. Additionally where is the black list and can I clear it?
I added both IP's to the Security Intelligence Global-Do-Not-Block-List but that didn't do anything
Any assistance/information would be appreciated
ā07-23-2024 09:32 AM
Can you share packet tracer for this traffic
Run it twice
MHM
ā07-23-2024 02:31 PM
https://jasonmurray.org/posts/2020/pacettracerfirepower/
use the packet capture with packet trace option
If this trusted traffic you can move this acl into prefilter and where it bypasses snort.. only if you trust it.
ā07-24-2024 12:36 AM
You have to go to FMC-->Policies--->Intrusion--->Snort2-->PolicyInformation-->Rules
Review and Modify the Rule:-
Review the rule's action (drop, alert, etc.) and modify it if necessary.
Ensure the rule is correctly configured to avoid false positives or unnecessary blocks.
Policy Deployment:
After making any changes, deploy the updated policy to your FTD device to ensure the changes take effect.
ā07-25-2024 05:24 AM
ā07-25-2024 05:44 AM
Ok...I see the rule ID's are actual numbers for the ACL Policy lines. I got into CLI and went into the /var/sf/detection_engine/xxxxx/folders and looked at the ngfw.rules file and the ruleid: 268434432 corresponds to the deny any any rule at the end of the config. But it looks like snort is kicking the traffic to that deny rule...but no reason why?
Earlier in the packet trace I see where the Access Policy permitted the traffic but kicked it to snort...is there a snort log to explain why its killing the traffic?
ā07-25-2024 05:48 AM
can I see
show run acl <<- FTD CLI
MHM
ā07-25-2024 06:20 AM
That might be difficult....there are a ton of rules and I need to vet the export though our security office so they can redact any verbiage they dont want going out. I can more easily pull any rules that are specified in the packet trace if that would work
ā07-25-2024 06:43 AM
access-list CSM_FW_ACL_ advanced permit tcp ifc inside-low object <10.6.1.150> ifc outside object <10.1.1.151> object-group SMB-TCP rule-id 268449798
a
this ACP is define as L7 rule ?
are you use Geo
are you use APP not port
MHM
ā07-25-2024 06:45 AM
hmmmm....we shouldn't be using any of that. This should be a basic ip/port to ip/port. Let me dive into the rule
ā07-25-2024 06:42 AM
Here is the redacted ACL list with entries that match the packet trace...on a side note since my Systems team was complaining I modified the prefilter rule for this traffic flow to bypass inspection for this specific flow and that worked like a charm. Mapped drive worked like a charm.
ā07-25-2024 06:59 AM - edited ā07-25-2024 07:00 AM
Why we buy high price FW if all traffic bypass via prefilter. I know it will work and I can suggest that but
for any issue we bypass traffic then the FW will useless
so run firewall-engine-debug and see SID and GID of snort drop then use filter to find the reason
NOTE:- this need to remove prefilter
> system support firewall-engine-debug
Please specify an IP protocol: tcp
Please specify a client IP address: x.x.x.x
Please specify a client port:
Please specify a server IP address: x.x.x.x
Please specify a server port: 445
Monitoring firewall engine debug messages
MHM
ā07-25-2024 07:54 AM
Pulled the prefilter, and ran the debug. Not seeing any SID/GID....simply kicks it down to rule 180 which the default action Block rule. Its almost acting like it kicks the packet to snort...snort see's its already black listed and kicks the packet back out to the default block action.
Also checked my rules and every rule that I have is listed as a L7 rule. I'm not using any Applications/Users/URL's. Just IP's/Zone/Ports
ā07-25-2024 12:06 PM
access-list NGFW_ONBOX_ACL remark rule-id 268435458: ACCESS POLICY: NGFW_Access_Policy
access-list NGFW_ONBOX_ACL remark rule-id 268435458: L7 RULE: testappid
access-list NGFW_ONBOX_ACL advanced permit object-group |acSvcg-268435458 ifc outside any ifc inside any rule-id 268435458
access-list NGFW_ONBOX_ACL remark rule-id 268435459: ACCESS POLICY: NGFW_Access_Policy
access-list NGFW_ONBOX_ACL remark rule-id 268435459: L7 RULE: testurl
access-list NGFW_ONBOX_ACL advanced permit object-group |acSvcg-268435459 any any rule-id 268435459 <<- the prefilter hit this
access-list NGFW_ONBOX_ACL remark rule-id 268435461: ACCESS POLICY: NGFW_Access_Policy
access-list NGFW_ONBOX_ACL remark rule-id 268435461: L5 RULE: testgeo
access-list NGFW_ONBOX_ACL advanced permit object-group |acSvcg-268435461 any any rule-id 268435461
This is how rules are seen on Snort side:
268435458 deny 1 any any 2 any any any any (appid 948:5, 1079:5) (ip_protos 6)
# End rule 268435458
268435459 deny any any any any any any any any (urlcat 2027) (urlrep le 0) (urlrep_unknown 1)
268435459 deny any any any any any any any any (urlcat 2006) (urlrep le 0) (urlrep_unknown 1)
# End rule 268435459
268435461 deny 1 any any any any any any any (dstgeo 643) <<- the snort hit this
# End rule 268435461
so same as your case
there are multi Snort Rule and prefliter show in packet tracer hit the first one
rule-id 268449798
rule_id = 268434432
so when you check rule-id in snort there is something write beside the deny any any it can urlcat or dstgeo or other can you share the output
MHM
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