Detect port scans and network scans from Cisco FTD firewall deny/block logs.
My setupFirewall logs: %FTD-1-430002 with Action: Block
Rule 100006 fires on every block (confirmed working)
Logs have fields: data.srcip, data.dstip, data.dstport




Port scan detection (same src IP, same dst IP, different ports):
<rule id="100901" level="14" frequency="5" timeframe="90"> <if_matched_sid>100006</if_matched_sid> <same_field>data.srcip</same_field> <same_field>data.dstip</same_field> <different_field>data.dstport</different_field> <description>Port scan from $(data.srcip) to $(data.dstip)</description> </rule>
Network scan detection (same src IP, different dst IPs):
<rule id="100902" level="14" frequency="5" timeframe="90"> <if_matched_sid>100006</if_matched_sid> <same_field>data.srcip</same_field> <different_field>data.dstip</different_field> <description>Network scan from $(data.srcip)</description> </rule>
Others:
<rule id="100903" level="15" frequency="3" timeframe="60" ignore="60">
<if_matched_sid>100006</if_matched_sid>
<same_field>data.srcip</same_field>
<description>Possible scan detected - Multiple blocks from $(data.srcip) in 60 seconds</description>
<group>scan,suspicious,attack</group>
</rule>
Others:
<group name="cisco,ftd,scan_detection,">
<rule id="100903" level="15" frequency="3" timeframe="60" ignore="60">
<if_matched_sid>100006</if_matched_sid>
<same_source_ip />
<description>Possible scan detected - Multiple blocks from $(data.srcip) in 60 seconds</description>
<group>scan,suspicious,attack,</group>
</rule>
</group>
The problem
What I need
A simple, working rule to detect:
Same IP hitting multiple ports on same destination (port scan)
Same IP hitting multiple destination IPs (network scan)
My Question
Thank you for your response.
Here is a sample raw log from my archives.log:
Raw Archives Log
root@pklhr-wazuh:~# grep "FTD-session-4-106023" /var/ossec/logs/archives/archives.log | tail -10
2026 Apr 10 20:28:44 10.40.1.150->/var/log/syslog-logs/10.40.1.150/output.log 2026-04-10T20:28:25.612944+05:00 10.40.1.150 : Apr 10 15:28:25 UTC: %FTD-session-4-106023: Deny tcp src inside:10.40.230.218/20853 dst PDC-SBP-RAAST:192.168.250.20/23432 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
2026 Apr 10 20:28:47 10.40.1.150->/var/log/syslog-logs/10.40.1.150/output.log 2026-04-10T20:28:27.874607+05:00 10.40.1.150 : Apr 10 15:28:27 UTC: %FTD-session-4-106023: Deny tcp src inside:10.40.230.218/20857 dst PDC-SBP-RAAST:192.168.250.20/23432 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
2026 Apr 10 20:28:47 10.40.1.150->/var/log/syslog-logs/10.40.1.150/output.log 2026-04-10T20:28:27.894359+05:00 10.40.1.150 : Apr 10 15:28:27 UTC: %FTD-session-4-106023: Deny tcp src inside:10.40.230.218/20858 dst PDC-SBP-RAAST:192.168.250.20/23432 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
2026 Apr 10 20:28:49 10.40.1.150->/var/log/syslog-logs/10.40.1.150/output.log 2026-04-10T20:28:30.883226+05:00 10.40.1.150 : Apr 10 15:28:30 UTC: %FTD-session-4-106023: Deny tcp src inside:10.40.230.218/20857 dst PDC-SBP-RAAST:192.168.250.20/23432 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
2026 Apr 10 20:28:49 10.40.1.150->/var/log/syslog-logs/10.40.1.150/output.log 2026-04-10T20:28:30.898965+05:00 10.40.1.150 : Apr 10 15:28:30 UTC: %FTD-session-4-106023: Deny tcp src inside:10.40.230.218/20858 dst PDC-SBP-RAAST:192.168.250.20/23432 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
2026 Apr 10 20:28:50 10.40.1.150->/var/log/syslog-logs/10.40.1.150/output.log 2026-04-10T20:28:31.624636+05:00 10.40.1.150 : Apr 10 15:28:31 UTC: %FTD-session-4-106023: Deny tcp src inside:10.40.230.218/20853 dst PDC-SBP-RAAST:192.168.250.20/23432 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
Raw Archives Log
root@pklhr-wazuh:~# grep "FTD-1-430002" /var/ossec/logs/archives/archives.log | tail -10
2026 Apr 10 20:28:43 10.40.1.150->/var/log/syslog-logs/10.40.1.150/output.log 2026-04-10T15:28:24+05:00 10.40.1.150 : %FTD-1-430002: EventPriority: Low, DeviceUUID: 8b35349c-c9e6-11ee-8a48-cc41097683c6, InstanceID: 1, FirstPacketSecond: 2026-04-10T15:28:24Z, ConnectionID: 60326, AccessControlRuleAction: Allow, SrcIP: 10.50.126.69, DstIP: 52.44.34.19, SrcPort: 63578, DstPort: 443, Protocol: tcp, IngressInterface: inside, EgressInterface: Bkup-Wateen, IngressZone: inside, EgressZone: Bkup-Wateen, IngressVRF: Global, EgressVRF: Global, ACPolicy: FINCA-INT-ACP, AccessControlRuleName: BRANCH's-URLs, Prefilter Policy: PDC-PreFilter-Policy, Client: SSL client, ApplicationProtocol: HTTPS, WebApplication: Trend Micro, InitiatorPackets: 3, ResponderPackets: 1, InitiatorBytes: 691, ResponderBytes: 66, NAPPolicy: Balanced Security and Connectivity, SSLPolicy: None, SSLFlowStatus: Success, SSLCipherSuite: Unknown, SSLCertificate: 4841b1641caedd674491a8c0a2ede07db907bdb3, SSLVersion: Unknown, SSLServerCertStatus: Valid, SSLActualAction: Do Not Decrypt, SSLExpectedAction: Do Not Decrypt, URLCategory: Branches_Exception, URLReputation: Unknown, URL: https://api-us1.xbc.trendmicro.com, NAT_InitiatorPort: 63578, NAT_ResponderPort: 443, NAT_InitiatorIP: 58.27.201.38, NAT_ResponderIP: 52.44.34.19, ClientAppDetector: AppID
Thank you for your response.
I tried the rule you shared, but it is still not triggering. Rule 100006 is firing correctly, but the correlation rule based on it is not working.
I suspect it might be due to the dependency chain (100005 → 100006) or possibly field matching or frequency conditions not being met.

Also, I noticed that firedtimes is incrementing for rule 100006, but it seems the correlation rule is not picking it up.
I would appreciate your insight on whether I should:

