To our Valued Customers, We would like to take this opportunity to respond to the Raptor Firewall 6.5 HTTP issue recently reported on http://www.securiteam.com/securitynews/Raptor_Firewall_HTTP_Forwarding_Vulnerability.html. The first point we would like to make is that although we do agree with the authors as it relates to the security implication of the described HTTP functionality we do not accept the assertion that this is a product related issue with the Raptor Firewall (HTTP proxy). Rather, our Raptor Firewall HTTP proxy is RFC-compliant, and as such it is behaving consistently with the specification as described in RFC 2616. From a pure protocol perspective, this is a valid HTTP connection and thus the traffic is being allowed through the firewall with a proper rule. However, recognizing the security impact of this configuration, the Raptor Firewall provides you with the capability to shut down this functionality by setting a configuration option (http.noproxy) through our configuration files or the RMC. The online documentation states: "To Prevent the Raptor System from being used as a Proxy If you're using service redirection on the Raptor system (for example, for connections to your Web server) and you don't want to allow users connecting through the Raptor system to be able to use it as a proxy, create a Rule and enter the following into the Advanced Services tab: http.noproxy" This provides you with more security protection, in addition to the added flexibility (vs. a packet filter or stateful inspection product) since it eliminates the need for completely shutting down the proxy capability of your internal Web servers. Additionally, in an effort to provide the highest level of managability and security to our customers, we will introduce an enhancement to our Management Console (GUI) whereby the HTTP.NOPROXY functionality will be permanently exposed. We also intend to change the default to disable the HTTP proxy capability on all external interfaces, and leave it enabled on all internal interfaces. This will provide your security administrator the option to manage the default behavior as desired while defaulting to a more secure initial state "out-of-the-box". In summary the recommendation to shutdown the HTTP proxy and replace it with a TCP GSP is the wrong approach. This solution relegates your Web servers to the mercy of application-level attacks and it is comparable to protecting your servers with a packet filter or stateful inspection firewall, something we do not recommend. Sincerely, William J. Aguilar and Tasha van Es Symantec Corp. Technical Product Managers Lysel Christian To: Alexander Bochmann <[EMAIL PROTECTED]>@SMTP@Exchange, Lysel Emre Christian Emre <[EMAIL PROTECTED]>@SMTP@Exchange <chlys@wmdata cc: [EMAIL PROTECTED]@SMTP@Exchange, .com> [EMAIL PROTECTED]@SMTP@Exchange Subject: [rapt] RE: Raptor 6.5 http vulnerability 03/26/2001 03:34 PM Please respond to Lysel Christian Emre <chlys@wmdata .com> Note, the patch can be downloaded from (for the international version): ftp://ftp.axent.com/pub/RaptorFirewall/International/Patches/NT6.5/ > From: Alexander Bochmann [mailto:[EMAIL PROTECTED]] > > 1. Problem Description > > The Raptor firewall is vulnerability for forwarding http > > request on other port numbers than 80, if a rule allows http > > traffic. > > When an extern or internal client, configures itself to use > > the nearest interface as proxy, it's possible to access other > > ports that 80 on the target host. > > > > 2.1 Non Vulnerable Versions > > Raptor firewall 6.0.2. > > Depending on the configuration and on how you try it, 6.0.2 > also seems to be vulnerable. We have not noticed this. > I already noticed some months ago that the Raptor (6.0.2) > firewall's http gateway possibly leaks information about an > internal network with the method you described, if redirected > services are used. It does not leaks information about the internal network. The apache webserver can leak information from error pages: ..... Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, <email of webmaster> and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. ---------------------------------------------------------------------------- ---- Apache/1.3.9 Server at <hostname> Port <port> ....... > It's possible to brute-force IP addresses used on a DMZ > network: If you use the http gateway on the external > interface as proxy, you can access internal IPs (and > internal DNS names) directly - just try them all ;) This should generate some logs! And can also be blocked by: http.urlpattern > Example: > > > setenv http_proxy http://external.firewall.name:80/ > > > Now go on with something like... > > > lynx -mime_header http://192.168.95.1:80/ > > > ...you will either get 403 or 503 errors from the gateway > (depending on it's configuration) for the destination: > > > lynx -mime_header http://192.168.95.2:80/ This is the internal interface for the firewall, right? > HTTP/1.1 503 Service Unavailable > MIME-Version: 1.0 > Server: Simple, Secure Web Server 1.1 > Date: Mon, 26 Mar 2001 14:59:29 GMT > Connection: close > Content-Type: text/html > [.. etc ..] > > ...or, if you are lucky, an answer from a web server: > > % lynx -mime_header http://192.168.95.74:80/ And this is a request to the webserver? http.remove-header, should remove the headers :) > HTTP/1.1 200 OK > Date: Mon, 26 Mar 2001 14:43:19 GMT > Server: Apache/1.3.17 (Unix) mod_perl/1.24_01 PHP/3.0.18 > Last-Modified: Thu, 15 Feb 2001 08:23:04 GMT > Accept-Ranges: bytes > Content-Length: 2490 > Connection: close > Content-Type: text/html > > <!doctype html public "-//IETF//DTD HTML//EN"> > [.. etc ..] * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * Sponsored by FireTower, Inc. - Internet Security Consulting & Sales * * Before posting, please check the following resources: * Patches/Hotfixes... http://www.symantec.com/techsupp/files/ raptor_firewall/raptor_firewall.html * Raptor FAQs........ http://websupport.axent.com/ * FireTower FAQs..... http://www.firetower.com/faqs/ * List Archives...... http://firetower.com/archives.html * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
