All- Sorry to "shotgun" so many questions at everyone, but i didnt want to make 3 different posts about this as it could all be the same issue(???).
Background: Im running 8.3.1, with non-transparent proxy, and none of the controls enabled (url, smartfilter, etc). I believe the following issues are related to using non-transparent proxying or my application defense itself.
Ive read the post about this from PhilM and still have a remaining question. Is the official fix to build a custom application? This dosent seem like the proper answer as it would appear to me to potientally bypass the proper app defense. Thoughts?
HTTPS traffic flagged as ISAKMP
Over the past two months we have had problems (simliar on all 12 of our firewalls), where HTTPS traffic is flagged as ISAKMP. This problem went away for a bit after the last application signature update, however it is back! In the event below you can clearly see that the port is 443, however its being flagged as ISAKMP, however it is hitting the appropriate ruleset which only contains HTTP and HTTPS.
2013-05-31 06:36:52 -0400 f_http_proxy a_libproxycommon t_nettraffic p_major
pid: 1772 logid: 0 cmd: 'httpp' hostname: xxx.x.x event: session end
application: ISAKMP app_risk: low app_categories: tunnels
netsessid: 222aa51a87d44 srcip: x.x.x.x srcport: 54171
srczone: internal protocol: 6 dst_geo: US dstip: x.x.x.x
dstport: 443 dstzone: external bytes_written_to_client: 15979
bytes_written_to_server: 1461 rule_name: Internet Servicesn cache_hit: 1
start_time: 2013-05-31 06:36:52 -0400
URL too long
Some site searches are denied. The event viewer shows the following (below). I turned off all of our URL app defenses, smartfilter, etc. Its pretty much a IP filter at this point but im still getting this error.
2013-05-31 08:01:32 -0400 f_http_proxy a_proxy t_attack p_minor
pid: 1771 logid: 0 cmd: 'httpp' hostname: xxx.x.x
category: appdef_violation event: request filter netsessid: 268c251a8910c
srcip: x.x.x.x srcport: 10886 srczone: internal dst_local_port: 80
protocol: 6 src_local_port: 0 dst_geo: US dstip: x.x.x.x
dstport: 80 dstzone: external attackip: x.x.x.x attackzone: internal
rule_name: Internet Services
reason: Request denied by request filter: URL too long.
usairways.com (pick any date and flight and hit search)
burgerking.com (do a search at the top)
Does anyone have any thoughts. I contacted support but they were not able to duplicate ANY of these errors.
Shutting off the app defense all together seems to correct both problems. (defense group, select "none" for http) HTTPS/HTTP traffic is identified correctly and the URL length is no longer a problem. Indicating that both of these problems are with the http app defense.
Message was edited by: mathew.d.hailey on 5/31/13 7:35:21 AM CDT
Message was edited by: mathew.d.hailey on 5/31/13 7:45:34 AM CDT
Message was edited by: mathew.d.hailey on 6/7/13 9:24:44 AM CDT