Skip to main content
SupermanInNY
SupermanInNY
New Member
October 8, 2009
Question

Firewall policy ID sequence/order

  • October 8, 2009
  • 8 replies
  • 12504 views
Hi All, I have Transparent mode settings for a FG200A-HD unit. I have WAN1 going to the DataCenter and INTERNAL going to my servers. I have a class of IP Addresses. 5 of those IPs belong to a specific client who needs IPS protection, primarily due to DoS attacks. Light attacks, yet still annoying. I' ve set up the UTM-IPS profile and it worked great and blocks away attackers. However, I belive I was setting up the Firewall rules incorrectly,. and I belive I had it such that the ENTIRE class was being put behind the IPS rule. The reason I believe this, is because Servers with IPs that were not supposed to be behind the IPS policy were all of sudden showing pages of ' Blocked because of IPS Attack' . And I know that these were not supposed to be ' enjoying' the IPS service. I know I can set the Addresses in a Group, .but for this ' exercise' I decided to have a single entry for each IP. I named them Starttech-1 through Starttech-5. Now, here is my confusion about the Firewall Policies order. Attached you can see the CURRENT setup: 1. Am I protecting the Starttech IPs? - assume the IPS profile is correct. (Yes/No) 2. Am I letting all other IPs go through with just ' regular' firewall services? - assume my policies are correct. (Yes/No). My previous Setup had the Firewall rule ID 3 BEFORE ID6 (as shown in my picture). I have just swapped them, so ID-6 is now showing First - so the picture is showing the Current status. 3. Is this how I should have it? 4. Was the previous order a mistake? (where ID-3 came before ID-6). Thanks for any input on this. -Sup.

    8 replies

    rwpatterson
    rwpatterson
    New Member
    October 8, 2009
    3 will never get hit because 6 comes before it and handles all the same systems included in 6... Policies are read/executed from the top down. (I am assuming that IPS group is included in ' all' ;)
    emnoc
    emnoc
    New Member
    October 8, 2009
    Yes that 100% correct. You always put the most specific rules before the least specific. Since you have a PP attach to that rule you could also pull the rule up in the monitor and see if it' s being matched. You will find nothing will show up for Policy ID #3.
    SupermanInNY
    SupermanInNYAuthor
    New Member
    October 8, 2009
    Hi rwpatterson and emnoc, I understand that it now better so thank you for clarifying that point. However, why would IPs that are NOT included in the IPS are showing the ' blocked' message? That is what confuses me. -Sup.
    A
    Anonymous_User
    Contributor
    October 9, 2009
    Here is a tip to verify if Policies are used : " Technical Tip : Troubleshoot and verify if traffic is hitting a Firewall Policy" http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=100139 -J.
    SupermanInNY
    SupermanInNYAuthor
    New Member
    October 9, 2009
    I created a walkthrough document with step-by-step pictures of how I' ve set up my FG200A-HD to be used for my WebHosting environment. This is a very simple setup, Transparent mode and just acts as a Firewall and few IPs with IPS protection. With that said, Even though only few IPs need the IPS protection, it appears that all of the IPS are somehow showing a message of " Blocked by IPS" . I have high loads on the FG200A-HD, ranging in the upper 50% to 95%, and the IPS attack detection Statistics are showing 1789 attacks detected in 22 hours. If you have some ideas as to why IPs that are NOT in the IPS profile are seeing the " Blocked by IPS" message, I' ll be happy to hear from you. the walkthrough is 700K in a Word document - only 4 pages, and can be d/l from: http://www.wsco.com/fg200a/Fortigate200A-HD-Step-by-Step-1.doc I suggest to zoom in at 200% to see the pictures clearly. Thanks for any input. -Sup.
    emnoc
    emnoc
    New Member
    October 9, 2009
    Post New Thread
    hey that looks great. You should take a instructor course ;) Now on the policy order, if you would look at what your originally post and the doc, the ordering is changed ( policy ID 3 & 6 ) Now if you review the attack log, the attack will logged the Policy ID that triggered that event. Lastly a off subject tip, you might need to trim and adjust your dos/ids signatures to reduce false positives. Good job and good luck, your doing it right.
    SupermanInNY
    SupermanInNYAuthor
    New Member
    October 9, 2009
    order, if you would look at what your originally post and the doc, the ordering is changed ( policy ID 3 & 6 )
    Thanks for the complements :) Did I set it right? Did I miss a step or otherwise need to make modification? Yes,. ID 3 & 6 were changed following the discussion in this thread, so that the CORRECT order is in the step-by-step document (as well as in the physical machine). I am still facing two issues: 1. For whatever reason, IPs that are in the ALL and not in the IPS group, are seeing " Blocked by IPS" messages. 2. High loads on the CPU of the box. The only thing I can think that might trigger the " Blocked by IPS" in the ALL policy/group (which shouldn' t happen) is actually related to the High Loads of the CPU, possibly due to an aggressive attack. Is that likely? Would FG300A be more resilient to attacks than the FG200A? Does it have a more powerful CPU that can handle higher loads? Or will FG300A handle same CPU load, just with a GB interface compared to the 100Mbit of the FG200A? I recieved a private msg from Ken with the following info in response to my problem: " I don' t see how? Unless the Protection Profile is enable for ips-sensors, the IDS/IPS is disable. Are your 100% sure it' s not permit and being deny with some " log traffic" enable?" Can you comment / explain me this further? What is the ' log traffic' he is referring to and how does that affect my setup? Last, " trim and adjust your dos/ids signatures to reduce false positives." How? or better ask: Which specifically? Today, I actually have only ONE server that is supposed to be behind the IPS protection. The other 20 servers are vanilla firewall. The settings that I have for that server seem to do the work for that server, but if you think I should change values, please provide me with suggested sample values. Thanks, -Sup.
    emnoc
    emnoc
    New Member
    October 10, 2009
    The high cpu should be normal for when IDS/IPS has been enable. For a FGT300 vrs 200 model, what does your thru-put look like and how does that compare to what fortinet forecasts? On the number of attacks issues, have you identified what attacks and if they are positive, or false-positives. What you might wnat to do is to lookup the attack definition as stated on fortinet ( it should be linked with the log to the http site ) and then remediate the problem and monitor some more. Every IDS/IPS I' ve worked on deployed, needed alot of hand holding for the 1st 1-3months to trim the sensors or to build custom signature or predefined overrides. What version of code are you running? What action are you taking ( pass/block/log )? Are you running any quarantine ? and if yes how long in the jail ? ;) are your ids-signs up to date ? If you have alot of attacks to one server, I would look at that server and probably run a vulnerability scan or two at it for the services you defined the IDS for. That' s my suggestion.
    SupermanInNY
    SupermanInNYAuthor
    New Member
    October 10, 2009
    I barely have any traffic, at peek time it stands at 30Mbit, but for the most part it runs at 20Mbit. So the throughput is not an issue. We have been running this configuration of blocking traffic for a month and a half and it seems to run smoothly with no effect on true clients, at least non that we were recieving any reports on. At the first couple of week we had very low values and indeed we blocked users, but once we removed the FTP traffic scanning and pushed up the values to what we have today, it seems OK. 
        Most recent transactions(maximum 20).	   Date & Time 	From 	To 	Service 	Attack  2009-10-10 17:09:14 	66.249.71.89 	XX.YY.141.105 	http 	tcp_reassembler: TCP.Stealth.Activity, paw  2009-10-10 17:08:37 	94.230.94.40 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 29 times  2009-10-10 17:08:07 	94.230.94.40 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 3 times  2009-10-10 17:07:17 	94.230.94.40 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 8 times  2009-10-10 17:04:53 	79.183.107.177 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 11 times  2009-10-10 17:04:19 	79.183.107.177 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 10 times  2009-10-10 17:03:48 	79.183.107.177 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 4 times  2009-10-10 17:01:52 	79.177.139.245 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 12 times  2009-10-10 16:59:52 	84.228.191.5 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 16 times  2009-10-10 16:58:25 	84.108.102.242 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 18 times  2009-10-10 16:57:51 	84.108.102.242 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 4 times  2009-10-10 16:55:58 	84.111.9.115 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 16 times  2009-10-10 16:55:28 	84.111.9.115 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 11 times  2009-10-10 16:54:48 	84.111.9.115 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 10 times  2009-10-10 16:54:15 	84.111.9.115 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 8 times  2009-10-10 16:53:44 	77.125.171.239 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 11 times  2009-10-10 16:53:11 	77.125.171.239 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 9 times  2009-10-10 16:52:02 	84.0.211.91 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 33 times  2009-10-10 16:51:30 	84.0.211.91 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 9 times  2009-10-10 16:50:52 	84.0.211.91 	XX.YY.141.105 	http 	anomaly: tcp_src_session, 71 > threshold 70, repeats 6 times
    All the traffic being IPS' ed is on a single IP, so it makes things easy to identify. This is a Web Hosting Server, so it serves regular PHP and HTML pages. I don' t think that a single tcp_src_session should exceed 70 sessions. Am I wrong about this? What values would you change to reduce false-positive attacks? My thoughts about migrating from 200A to 300A was related to the how good does it effectively battle attacks, and that was due to the high CPU usage I was seeing. But, if there is no ' stronger' cpu to battle here, then there is no real added value to my current setup. thanks, -Sup.
    emnoc
    emnoc
    New Member
    October 11, 2009
    I wouldn' t get to excite about those. You really need to review the fortiguard and Kb for info http://www.fortiguard.com/encyclopedia/vulnerability/tcp.stealth.activity.html fwiw, That' s a very low severity alert.
    SupermanInNY
    SupermanInNYAuthor
    New Member
    October 11, 2009
    anomaly: tcp_src_session, 71 > threshold 70, repeats 29 times
    OH,. I wasn' t concerned about the " tcp_reassembler: TCP.Stealth.Activity, paw" I don' t care for that one,. I do see those, but actually not that many. My primary concern is this one: " anomaly: tcp_src_session, 71 > threshold 70, repeats 29 times " Over 70 sessions from a single source seems to me very unlikely as a normal activity. But perhaps I' m wrong? When you visit a website, a forum, etc,. should you have more then 70 sessions originating from YOUR compuer to the Server? That is to my understanding an attack of some sort. That needs to be blocked.
    Terms & ConditionsAccessibility statement