Custom signature with ‑‑track client cannot be created

[AtiT]

Hello, I want to create custom signature to firstly monitor HTTP GET and later on to block high GET rate. I created the following signature: F-SBID( --attack_id 9851; --name " GET_per_second" ; --pattern " get" ; --service HTTP; --protocol tcp; --no_case; --rate 10,1; ) I want to add the ‑‑track client; parameter like: F-SBID( --attack_id 9851; --name " GET_per_second" ; --pattern " get" ; --service HTTP; --protocol tcp; --no_case; --rate 10,1; ‑‑track client; ) But I cannot create it because after clicking to OK it says: Index out of range. I found the ‑‑track client; in documentaion here: http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%25205.0%2520Help/ips_signatures.153.4.html Can anyone explain me what I am doing wrong? Thank you! FYI: I am testing it in the lab on FG-80C with OS 5.0.9

[Adrian_Buckley_FTNT]

Remove the attack id. It will show up in the CLI and be automatically assigned by the FortiGate. Trying to specify it ahead of time will cause an error. Otherwise it looks ok.

[AtiT]

Hi, thanks for update. I created a signature without defining the attack id and it generated some and now if I edit the signature is there the id (but other): F-SBID( --attack_id 3639; --name " GET_per_second" ; --pattern " get" ; --service HTTP; --protocol tcp; --no_case; --rate 10,1; ) So it is still defined somehow and who knows whether there will not be another signature from FortiGuard update with the same ID. However I still cannot create a signature with the ‑‑track client; keyword.

[emnoc]

Hi On the attack_id range you can create your own id in the range of ; 1000-9999 You don' t have to let the device automatically create one. You can do like suggest and let the system pick one random and then change it or craft one in the cli when you apply the rule. F-SBID (--name " GET_per_second" ; --protocol tcp; --service HTTP; --track src_ip; --flow from_client; --pattern GET; --no_case; --rate 10,1; ) FWIW; But that rule would be bad and probably trigger hundreds of alerts. For any of the following reasons; if you page have a lot of objects or links in the GET if any multiple clients are coming from a PAT address at a rate of 10;1 count threshold that would be very harsh, if your webserver support HTTPs and they do the " get" in HTTPs encryption the IPS sensor is not a good or sensitive enough for a true layer7 GET flood detection or attack you would probably see a spike and big increase in cpu/memory usage a fortigate is NOT a HTTP get flood protector ...it' s the wrong tool If you have a true DOS HTTP-GET flood, the fortigate is a probably a poor choice for protection imho and my experience working in the DDoS sector. In truth you will fine the fortigate has some great IPS protection at layer3/4 but it makes a for a very sorry get flood protector. You need the right tool for the task at hand. To think you can write a rule like that and not wreak havoc or create additional problems, is being naive. You have to identify what' s being attacked and the SRCs and object. Do like you suggested monitor 1st and adjust accordingly. Look for positive signs of a get flood from your webserver access.log and then apply the rules to the specific src(s) that you see and the URLs that you find. Wireshark/tshark will help identify these objects and rates,etc.... ( e.g tshark -z http,stat, -R ' http.request.method==GET' -R ' ip.addr==x.x.x.x' ) And they probably using z stats with iostats for get a measure over time like how many request per 60/secs get against a specific url. But creating a rule like the sample you provided , would probably be like conducting a heart operation on a subject using a Spanish-American war Calvary sword. The outcome would be bloody and messy and not great for the patient ( webserver )

[netmin]

Just concerning the error: Unlike documented, only " --track dst_ip" and " --track src_ip" appear to work. Everythin else tested up to now throws an ' invalid enum option value' error on the CLI.

[emnoc]

did you try the WebGUI? The cli ca be challenging.

[netmin]

Actually I tried both variants. When using the web GUI (5.0.x) it shows the mentioned error at the same time on the CLI.

[netmin]

More exactly, the error is thrown on the local console (also on 5.2.1). (When trying the example from AtiT above the wrong/encoded " ‑‑" dashes in front of " track client;" were also replaced with default " --" dashes.) ' src_ip' works, ' client' throws this:

[AtiT]

Hello, The --track src_ip; works but I cannot see any difference in the logs, the same logs I have if this keyword is not used. My goal was to have one log during the period defined in --rate matches,duration; for example for --rate 10,1; I want to see one log entry for access during 1 second which reaches the rate 10 - means: 1) for accesses from 10 to X during 1 second I want to see 1 log ( for the -- rate 10,1; settings ) 2) for accesses from 10 to X during 2 second I want to see 2 logs ( for the -- rate 10,1; settings ) Exampe: accesses from 20 to 29 during 1 second ( for the -- rate 10,1; settings ) I want to see 1 log - I was expecting to have a count field using for such information. Let' s say for the example above I want to see one log entry with the count field filled with info how many times the rate (10) for the duration (1s) was reached - I expected: 1 log with number 2 in the column field. This should eliminate the huge ammount of logs and it has more information for me than logging every single access when the rate is reached. But it is not working for me. Of course the rate will be set to more higher value in real case, the --rate 10,1; is only for testing int the lab where is a WAMP server with Drupal installed. This feature is planned to set up on FG-240D with one policy only and only with this one IPS signature. This is the customer' s request and if he pays for it - it is ok for me. But I think FortiDDoS is better solution for this with sequencial access set up for URLs or limit the HTTP_GET method. However the reporting is limited and alerts too. In FAZ I am able to generate report what I want and alert email based on the event handler can be generated and sent to SMS gateway if necessary.

[netmin]

I believe this will not work with IPS logging as you need it. A small test setup using a manually created html site and a defined number of embedded pictures to create a defined number of GET requests may help to understand how the FGT logs detections. When using periodical detections, the duration is a floating window. It is not like statistical detections per seconds, but logging of detections as soon as the condition is met (10 detections) and as long as the condition is met (1 new detection within 1 second, counted from the last 9 detections). With GET requests arriving within milliseconds the 10th and following detections should be logged (or blocked) in a local test. There' s normally only 1 detection per log entry because each request is logged separately.