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

Application Control: can't override block action with custom signature when HTTPS

The "proxy" category is blocked but we wan't to allow only one legit web site. We created a custom signature with the right pattern. In the override section this custom application is set to "monitor". But this site still blocked.

 

The problem seems that the custom signature worked and I see in the log the "pass" action when the service is HHTP BUT after that the workflow continue to HTTPS service and reach the default signature "Proxy.Websites" and at that time the action is set to "block"... So how to override the bock action? Is it possible to stop the workflow in the custom signature to stop processing after the "allow" action? We set the weight of the signature to 255 but this not working. Here the details:

 

The custom signature:

F-SBID( --attack_id 9524; --name "Permit.proxy.XXX"; --pattern "proxy.XXX.ca"; --protocol tcp; --no_case; --flow from_client; --context host; --app_cat 6; --weight 255;)

 

1 Solution
hmtay_FTNT
Staff
Staff

Adding the discussion on PM for references.

 

The reason the --depend-on and --scan-range dont fix the issue is because the signatures in IPS Definitions in 5.2 do not have those syntax. They are only used in 5.4 and above.  One way you can get around now is to enable Proxy.Websites on Application Control and use the Web Filter's "Proxy Avoidance" to filter proxy websites for now. Then you can add an exception in the Static URL filter for your sites.

View solution in original post

10 REPLIES 10
hmtay_FTNT
Staff
Staff

Hello serinfbco,

 

Can you try this?

 

F-SBID( --attack_id 9524; --name "Permit.proxy.XXX.SSL"; --protocol tcp; --service SSL; --pattern "proxy.XXX.ca"; --no_case; --context host; --app_cat 6; --weight 255;)

 

F-SBID( --attack_id 9525; --name "Permit.proxy.XXX.HTTP"; --protocol tcp; --service HTTP; --flow from_client; --pattern "proxy.XXX.ca"; --context host; --no_case; --app_cat 6; --weight 255;)

 

Homing

serinfbco

Thanks hmtay_FTNT,

 

I tried the signatures and I see they are matching the pattern but the default "Proxy.Websites" application control signature still matching too and this one is set to "block". So I have two signatures matching and one is set to block...

 

We are in flow-base mode.

  

hmtay_FTNT

The default Proxy.Websites signature will match. However, with the custom signatures, it will override that. Did the site work? If not, can I know what is your FortiOS and IPS Engine version?

serinfbco

I see the signature matching but at one time the traffic is beeing block by the default "Proxy.Websites" signature. Yes the site works. I put a network monitor tool and I see where it is blocked: a response packet never reach the client (the picture below). But all others packets before that contains the pattern "proxy.XXX.ca" are allow. Why this one would be blocked? And furthermore we apply application control only to traffic going outside so why the response would be blocked?

 

FortiIOS version v5.2.11,build754

IPS Engine version 3.00441

Thanks!

 

serinfbco

Finally after looking all the logs, I found something really strange. The custom signature is working as expect on the outgoing packet BUT the problem comes from the incoming packet that doesn't make sense. 

 

Ok the Application Control policy is apply to the traffic on this way: Interface 9 (internal) to Interface 10 (external). I can't explain why the IPS Engine sees the private addresse on the external interface... Sorry for my english but the image below explains better the strange behavior. The client IP address is xxx.xxx.xx.118 and the server public IP address is xxx.xxx.xxx.53.

 

 

hmtay_FTNT

Can you modify the following custom signature to these:

 

F-SBID( --attack_id 9524; --name "Permit.proxy.XXX.SSL"; --protocol tcp; --service SSL; --pattern "proxy.XXX.ca"; --no_case; --context host; --app_cat 6; --depend-on 32384; --depend-on 38941; --scan-range 2k,all; --weight 255;)   F-SBID( --attack_id 9525; --name "Permit.proxy.XXX.HTTP"; --protocol tcp; --service HTTP; --flow from_client; --pattern "proxy.XXX.ca"; --context host; --no_case; --app_cat 6; --depend-on 32384; --depend-on 38941; --scan-range 2k,all; --weight 255;)

 

If you already have the set, dont add new ones, modify them. Add the --depend-on and --scan-range syntaxes. If you run into an index error, let me know. 

serinfbco

Thanks hmtay_FTNT,

 

I applied both new signatures but I got the same results. HTTP passed and SSL passed with the custom signature and right after it's blocked by the default "Proxy.Websites" signature. Again the packet blocked is strange because it's in reverse flow without logic. As I said what I see in the log is the source IP (our client) is seen on the external interface and destination IP is seen on the internal interface. I can't see this behavior for others packets logged for "application control". 

 

Just to be sure here the two new custom signatures:

 

F-SBID( --attack_id 1219; --name "Permit.proxy.xxx.SSL";  --protocol tcp; --service SSL; --pattern "proxy.xxx.ca"; --context host; --no_case; --app_cat 6; --depend-on 32384; --depend-on 38941; --scan-range 2k,all; --weight 255;)

 

F-SBID( --attack_id 5475; --name "Permit.proxy.xxx.HTTP"; --protocol tcp; --service HTTP; --pattern "proxy.xxx.ca"; --context host; --no_case; --app_cat 6; --depend-on 32384; --depend-on 38941; --scan-range 2k,all; --weight 255;)

hmtay_FTNT

Hi serinfbco,

 

Can you send me your configuration file and the output to "diagnose autoupdate versions"? You can send it to me in a PM. I will check and see what's wrong. 

 

>>I applied both new signatures but I got the same results. HTTP passed and SSL passed with the custom signature and right after it's blocked by the default "Proxy.Websites" signature. Again the packet blocked is strange because it's in reverse flow without logic. As I said what I see in the log is the source IP (our client) is seen on the external interface and destination IP is seen on the internal interface. I can't see this behavior for others packets logged for "application control". 

 

This would happen on an older IPS Engine + FortiOS combination that dont support custom signature whitelisting. The IPS Engine says the packet is allowed, but they are dropped.

serinfbco

Hi hmtay,

 

I sended you by PM our config file and the output of "diagnose autoupdate versions".

 

Thanks!

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors