#FortiGate60 custom #IPS_signature - http response

[MarkusPL]

hi everybody,

I'm testing custom IPS signatures with FortiGate 60 (firware v7.0.9 build0444 . The idea is to detect and block http responses  containing certain strings like "<?php" (php opening tag should never appear in the output html code). My web server is located in DMZ protected by Forti (of course, the right IPS profile is attached to the right firewall rule).

since it doesn't work with http (80) I didn't even try with https. In order to exclude server compression I even tried talking  to my web-server using telnet client - without success.

thx for any hints:

I tested many combinations like this:

F-SBID( --name "php_detect1"; --default_action drop_session; --service http --protocol tcp; --app_cat 25; --flow from_server ; --src_addr 86......230/32; --pattern "<?php"; --no_case; --context body; )

F-SBID( --name "php_detect2"; --default_action drop_session; --service http --protocol tcp; --app_cat 25; --flow from_server; --src_port 80 ; --pcre "/<\?php/i"; --context body; )

F-SBID( --name "php_detect3"; --default_action drop_session; --service http  --protocol tcp;  --app_cat 25; --flow bi_direction ; --src_addr 86.....230; --pattern "<?php"; --no_case; --context body;  )

[gfleming]

I'm not too sure but sounds like something you should be using WAF for or restricting it on the Web Server itself (i.e. do not allow PHP files to be listed).

[MarkusPL]

this <?php opening tag was only an example. I prefectly know that webserver shouldn't return php sources.

Anyway I'm still not able to detect any string on FortiGate IPS - neither from client to server (request) nor from server do client (response) on pure http.

[funkylicious]

Hi,

FW has a valid IPS license ?

Are you trying to inject <?php towards the webserver from a client or from the webserver to a client and block it ? If the first choice, then flow is from_client , else as you put it.

I've used this as a reference a while ago to test something and made some custom signatures, worked as intended when i telnet to a host and type that pattern it will close/block the connection.

[MarkusPL]

funkylicious wrote:

> FW has a valid IPS license ?

yea, till 2025 :)

>  Are you trying to inject <?php towards the webserver from a client or from the
> webserver to a client and block it ? If the first choice, then flow is from_client , else as
> you put it.

I prepared a special php script, which returns <?php string to the client

(I simulated situation exactly as if the web server was bad configured and returned php sources)

so flow from_server  is OK I guess. however I tried opposite direction with URL checking and it doesn't work either

[funkylicious]

Hi,

I created the following IPS Signature:

F-SBID ( --name php_detect; --protocol tcp; --flow from_client ; --pattern <?php; --no_case; )

I created a new IPS sensor and selected the signature with action block and packet logging.

Created a firewall rule from client to server with the IPS i just created.

The test I made was from client to server, easier for me:

server : run netcat to listen on port X

client : telnet to server on port X

send string in telnet session with <?php , connection was dropped

Log:

Action	dropped
Threat	4096
Policy ID	92

Intrusion Prevention
Profile Name	block-scanner
Attack Name	php_detect
Attack ID	4865
Incident Serial No.	198897581
Direction	outgoing
Severity	
Message	custom: php_detect,

[pminarik · Accepted solution]

A couple thoughts to share, may or may not be helpful.

• "--protocol tcp" is redundant, "--service http" already assumes TCP. (ref) 
• You mention applying an IPS profile to a policy, yet you are creating an Application Control signature ("--app_cat" makes it an app signature, not IPS) (ref) 
• Any chance the pattern is just very unfortunately always broken up into multiple frames? This may be a documented edge-case, if I'm reading the docs right, see here:

BODY - The search range is the entire body of scanned HTTP, IMAP, SMTP, or POP3 traffic. The decoder has no separate buffer for the body section of above-mentioned traffic. Because of this, body data in different packets is not reassembled. The decoder just locates the beginning and end of the body in a packet payload and tries to match inside of it. If a signature has two patterns in a body section that are to be matched, but the patterns span across two separate packets, the second pattern will not be matched.

[MarkusPL]

pminarik wrote:

>> ("--app_cat" makes it an app signature, not IPS) (ref) 

That was it! that was my mistake! I read somewhere that app_cat is necessary (it was probably related to creating app signatures)

thx you for your help & time

Markus