| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| We use Header Rejection in R61 to protect against spyware/adware. Since SmartDefense applies to all interfaces, spyware-infected people on the Internet cannot connect to our web server behind FW-1 because Header Rejection is blocking them. Is there any way around this without disabling the Header Rejection protections for everyone? Does R62/R65 work differently? Thanks, Ray |
| |||
| Quote:
With R62/65 you have the profiles option if you have different firewalls, but otherwise no. |
| |||
| Bummer. It really needs a "do not enforce on external interface" selection. Since I can apply the protection to just a resource, how much of a performance hit would I take if I created an HTTP resource in the rule that allows the proxy server outbound and changed the setting to apply to resources only and not all HTTP traffic? We're talking R61 here. It seems to me that this protection was moved to the kernel in NGX from the security server for performance reasons, so I guess I would be un-doing that. We already have the HTTP security server running but it's on a very low volume rule. On a similar note, I could probably get away with activating the custom error page, but the warning about it affecting performance makes me leery. Do you have any idea what would happen response-wise? Does the performance hit affect every single connection regardless of whether it trips the error page or not? We're only talking about a T-1 here. Thanks for the prompt response, Ray Last edited by RayPesek; 2007-06-20 at 20:22. |
| |||
| There is another way, but unfortunately it will turn all SmartDefense into Monitor only for those hosts. This is covered in SK #sk31918 On your Manager
// List of devices to disable SmartDefense services IPList={<192.168.0.1>,<192.168.0.2>,<192.168.0.3>} ; Note that you can also use an IP ranges by using the following syntax: IPList = {<IP_start,IP_end>,<IP_start,IP2_end>}; Find the following line: #define ACTIVATE_WS_GLOBAL_DEFENSE (tcp, dport in http_services,ADD_INSPECTION(SPII_WEBSEC_ID)) or 1 Change it to the following: #define ACTIVATE_WS_GLOBAL_DEFENSE (src not in IPList,dst not in IPList, tcp, dport in http_services,ADD_INSPECTION(SPII_WEBSEC_ID)) or 1 Find the following line: #define ACTIVATE_WS_SERVER_DEFENSE ( tcp, get from web_server_rules to sr10, ADD_INSPECTION_WITH_PARAMS(SPII_WEBSEC_ID, sr10)) or ACTIVATE_WS_GLOBAL_DEFENSE Change it to the following: #define ACTIVATE_WS_SERVER_DEFENSE ( src not in IPList,dst not in IPList, tcp, get from web_server_rules to sr10, ADD_INSPECTION_WITH_PARAMS(SPII_WEBSEC_ID, sr10)) or ACTIVATE_WS_GLOBAL_DEFENSE Save your changes, open the SmartDashboard and push the security policy to your gateway. -Greg |
| |||
| Thanks! I did not know about that. I think it is better to just un-block th header reject patterns I see in the logs. As much as I do not want to do that, it is a bit better than turning everything off. Ray |
| |||
| I totally agree, however we've come across a number of scenarios where it has been necessary to "monitor only" all smartdefense to specific hosts - such as to our proxy servers from our internal clients because both http and https use port 80 and the HTTP Method "CONNECT", Altiris Servers because they stick the data in an AVI stream inside HTTP and DNS because of the way some of our internal apps and Lucent QiP operate... |
![]() |
| Thread Tools | |
| Display Modes | |
| |