port scan are detected but not blocked

[#1]

hi all i got a query that FGT is not blocking portscan, " " I have been performing some basic tests of the IPS capabilities of our fortigate v2.80 - MR5. I started out testing the device' s portscan protection rules but have so far been unable to prevent the portscans from being succesfull. From the logs, I notice that the fortigate detects the scan, but allows it anyway. I tested the device using the following scenario: 1. I opened all the ports between 2 fortigate interfaces 2. I configured all IPS options related to portscans. I enabled them and set the action to drop (and in other tests " clear session" and " drop session" ) 3. I created my own profile (" maarten" ), configured it to follow IPS rules and attached it to the firewall policy that allows sessions betweed the wan1 and internal ports. 4. I enabled logging, so I would be able to follow the device' s reponse === scantop === fortigate === victim (host with ports listening on 22/TCP and 8080/TCP) When scanning my victim using nmap, all open ports are reported acurately. It seems like the fortigate is not blocking my portscan, like you would expect from an IPS.... ==================================================== NMAP and SYSLOG output: ==================================================== Starting nmap 3.70 ( http://www.insecure.org/nmap ) at 2004-10-25 10:18 W. Europ Interesting ports on 192.168.1.1: (The 65533 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 22/tcp open ssh 8080/tcp open http-proxy Nmap run completed -- 1 IP address (1 host up) scanned in 654.401 seconds ==================================================== The fortigate logs: Oct 25 10:17:33 FG.CORP.LAN date=2004-10-25 time=10:12:21 device_id=FGT-602803030270 log_id=0421073001 type=ips subtype=anomaly pri=alert attack_id=100663398 src=172.16.152.162 dst=192.168.1.1 src_port=58020 dst_port=44993 src_int=n/a dst_int=n/a status=dropped proto=6 service=44993/tcp msg=" anomaly: portscan, 1001 > threshold 1000, repeated 67 times[Reference: http://www.fortinet.com/ids/ID100663398]" Oct 25 10:17:35 FG.CORP.LAN date=2004-10-25 time=10:12:23 device_id=FGT-602803030270 log_id=0421073001 type=ips subtype=anomaly pri=alert attack_id=100663402 src=172.16.152.162 dst=192.168.1.1 src_port=58020 dst_port=48556 src_int=n/a dst_int=n/a status=detected proto=6 service=48556/tcp msg=" anomaly: tcp_src_session, 2001 > threshold 2000, repeated 67 times[Reference: http://www.fortinet.com/ids/ID100663402]" Oct 25 10:17:49 FG.CORP.LAN date=2004-10-25 time=10:12:37 device_id=FGT-602803030270 log_id=0421073001 type=ips subtype=anomaly pri=alert attack_id=100663409 src=172.16.152.162 dst=192.168.1.1 src_port=58020 dst_port=53739 src_int=n/a dst_int=n/a status=detected proto=6 service=53739/tcp msg=" anomaly: tcp_dst_session, 5001 > threshold 5000, repeated 3434 times[Reference: http://www.fortinet.com/ids/ID100663409]" Oct 25 10:17:53 FG.CORP.LAN date=2004-10-25 time=10:12:41 device_id=FGT-602803030270 log_id=0022010001 type=traffic subtype=allowed pri=notice vd=root SN=10561 duration=20 rule=7 policyid=7 proto=554/tcp service=554/tcp status=accept src=172.16.152.162 srcname=172.16.152.162 dst=192.168.1.1 dstname=192.168.1.1 src_int=n/a dst_int=n/a sent=40 rcvd=40 sent_pkt=1 rcvd_pkt=1 src_port=58020 dst_port=554 vpn=n/a tran_ip=0.0.0.0 tran_port=0 dir_disp=org tran_disp=noop Oct 25 10:17:53 FG.CORP.LAN date=2004-10-25 time=10:12:41 device_id=FGT-602803030270 log_id=0022010001 type=traffic subtype=allowed pri=notice vd=root SN=10562 duration=20 rule=7 policyid=7 proto=dns service=dns status=accept src=172.16.152.162 srcname=172.16.152.162 dst=192.168.1.1 dstname=192.168.1.1 src_int=n/a dst_int=n/a sent=40 rcvd=40 sent_pkt=1 rcvd_pkt=1 src_port=58020 dst_port=53 vpn=n/a tran_ip=0.0.0.0 tran_port=0 dir_disp=org tran_disp=noop Oct 25 10:17:53 FG.CORP.LAN date=2004-10-25 time=10:12:41 device_id=FGT-602803030270 log_id=0022010001 type=traffic subtype=allowed pri=notice vd=root SN=10567 duration=20 rule=7 policyid=7 proto=3389/tcp service=3389/tcp status=accept src=172.16.152.162 srcname=172.16.152.162 dst=192.168.1.1 dstname=192.168.1.1 src_int=n/a dst_int=n/a sent=40 rcvd=40 sent_pkt=1 rcvd_pkt=1 src_port=58020 dst_port=3389 vpn=n/a tran_ip=0.0.0.0 tran_port=0 dir_disp=org tran_disp=noop Oct 25 10:17:53 FG.CORP.LAN date=2004-10-25 time=10:12:41 device_id=FGT-602803030270 log_id=0022010001 type=traffic subtype=allowed pri=notice vd=root SN=10568 duration=20 rule=7 policyid=7 proto=389/tcp service=389/tcp status=accept src=172.16.152.162 srcname=172.16.152.162 dst=192.168.1.1 dstname=192.168.1.1 src_int=n/a dst_int=n/a sent=40 rcvd=40 sent_pkt=1 rcvd_pkt=1 src_port=58020 dst_port=389 vpn=n/a tran_ip=0.0.0.0 tran_port=0 dir_disp=org tran_disp=noop ========================================================= As you can see, the fortigate firewall/IPS detects the anomaly, but still allows the portscan to continue. There is no IPS response that blocks the entire portscan. I had a tcpdump running on my victim to see if maybe port 22 and 8080 had been scanned before the threhold of the rules had been met. However, this did not seem to be the case. tcpdump reported a probe of port 8080 over a minute after the fortigate first detected the scan. I was wondering if any of you have noticed the same behaviour on your fortigates, or if you have different test results. I have included some details of my configuration below. Kind regards, Maarten Hartsuijker Version:Fortigate-60 2.80,build250,040914 ids-db:2.139(10/19/2004 15:14) config ips group " scan" config rule " Nmap.TCP" set action drop (tried " clear session" and " drop session" options as well) end config rule " SYNScan.Portscan" set action drop (tried " clear session" and " drop session" options as well) end end config ips anomaly " portscan" set action drop (tried " clear session" and " drop session" options as well) set threshold " 1000" end config ips anomaly " syn_flood" set threshold " 2000" end config firewall profile ....... edit " maarten" set imap fragmail set pop3 fragmail set smtp fragmail set ips signature anomaly next end config firewall policy ... edit 2 set srcintf " internal" set dstintf " dmz" set srcaddr " all" set dstaddr " all" set action accept set schedule " always" set service " ANY" set profile_status enable set profile " maarten" next ... end

[#2]

I' m just wondering why you are testing against such old firmware.

[#3]

Actually i just got query from one of my clients... so is should check on the latest firmware... and how about port scan...?

[red_adair]

First: 2.8 MR5 is not " latest" but more like 3 years old Firmware. staying on 2.8 we' re at MR13 or so already. But Major Release v3 is out already like for 2 years and we are at MR6 !. So " FortiOS 3.0 MR6 patch1" is the latest. Second: What can be " blocked" from a portscan ? Potentially a port-scan can be detected while having the ports closed; so what is Fortigate supposed to block ? The Source-IP ? and why... A Portscan itself is nothing bad and ususally good enough to be detected.

[#5]

i want to drop the port scan session, as the open ports can be scaned and would be critical for security.

[red_adair]

what do you mean " drop port scan session" ? A port scan usually does not belong to a session, but rather to a (single) packet probe..... So your question maybe: Can the SRC-IP be blocked permanently/temporarily in an automated way; no it can' t. -R.