What follows is a clarification of a statement in the advisory by John McDonald and Thomas Lopatic which can be retrieved in its entirety from the BUGTRAQ archive: 38A1B3D9.9D16EBAEat_private">http://www.securityfocus.com/templates/archive.pike?list=1&date=2000-02-8&thread=38A1B3D9.9D16EBAEat_private Here is the relevant portion: "FireWall-1 monitors the packets sent from the FTP server to the client, looking for the string "227 " at the beginning of each packet. Upon a match, FireWall-1 will extract the destination IP address and the destination port given in the packet payload, verify that the specified IP address corresponds to the source address of the packet, and allow an incoming TCP connection through the firewall according to the destination IP address and the destination port extracted from the datagram." It then goes on to describe some restrictions on this TCP connection one of which is that "it cannot be to a port that is listed in FireWall-1's list of well-known TCP services." This is true of the default inspect code in the base.defs file. It really depends on the definition of the NOTSERVER_TCP_PORT macro. If the macro is modified the behavior changes. This is the reason for the difference between v3.0 and v4.x that is mentioned in the original advisory. See http://www.phoneboy.com/fw1/faq/0106.html for discussion of a change to NOTSERVER_TCP_PORT that removes the restriction on ports that are in FW-1's list of TCP services and as a result only restricts ports <1024. A Nokia machine running FW-1 4.0 with a base.defs modified according to the phoneboy FAQ item listed above has been tested and a connection can be made to any port *not matched* by the NOTSERVER_TCP_PORT macro. -paul
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:38:40 PDT