Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
MarkusPL
New Contributor

#FortiGate60 custom #IPS_signature - http response

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;  )

 

1 Solution
pminarik
Staff
Staff

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.

[ corrections always welcome ]

View solution in original post

7 REPLIES 7
gfleming
Staff
Staff

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).

Cheers,
Graham
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
Contributor III

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.

geek
geek
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,

 

 

geek
geek
pminarik
Staff
Staff

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.

[ corrections always welcome ]
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

Labels
Top Kudoed Authors