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;)
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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.
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
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.
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?
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!
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.
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.
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;)
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.
Hi hmtay,
I sended you by PM our config file and the output of "diagnose autoupdate versions".
Thanks!
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1536 | |
1029 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.