| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| Host tried to open tcp service port, port xxxx FireWall-1 does not allow FTP through any port that it considers to be a "service." Any service of type TCP defined in FireWall-1 is placed into a table called tcp_services. If an FTP connection requests a port that is in the tcp_services table (i.e. it's the same port as that of a defined TCP service), the connection will be denied. This "feature" will generally only be noticeable if you define TCP ports in large groups or if you are transferring a large number of files. Most machines, when they load up, start allocating "outbound" connections at source port 1025 and higher. One workaround would be to define the service as type Other with the following in the Match field: tcp, dport >= x, dport In NGAI, you can disable this check in Smart Defense, under Network Security > Dynamic Ports. Select the option "allow data connections to all defined services' ports". If this doesn't work, try the next method listed. In NG FP1 and later: Backup the $FWDIR/lib/base.def on the management station Edit the $FWDIR/lib/base.def and add the following line: #define NO_SERVER_PORT_CHECK right below the line (at the top of the file): #define _base_def This effectively disables the macros that check for defined services. Push the security policy to the enforcement points. FireWall-1 4.0 and FireWall-1 4.1 has the following in base.def : // ports which are dangerous to connect to define NOTSERVER_TCP_PORT(p) { (not ( ( p in tcp_services, set sr10 RCODE_TCP_SERV, set sr11 0, set sr12 p, set sr1 0, log bad_conn) or ( p < 1024, set sr10 RCODE_SMALL_PORT, set sr11 0, set sr12 p, set sr1 0, log bad_conn) ) ) }; You change it so it reads: // ports which are dangerous to connect to define NOTSERVER_TCP_PORT(p) { (not ( p < 1024, set sr10 RCODE_SMALL_PORT, set sr11 0, set sr12 p, set sr1 0, log bad_conn) ) }; In FireWall-1 3.0 change the macro definition for NOTSERVER_TCP_PORT to: #define NOTSERVER_TCP_PORT(p) ( p > 1024 ) (Note if you have a 4.x managment console managing a 3.x firewall, make the above change in $FWDIR/lib30/base.def as well) -------------------------------------------------------------------------------- Extra Background -------------------------------------------------------------------------------- For those that have security concerns about such a solution, it might be helpful to explain what FireWall-1 does with FTP. In the case of active-mode FTP, client A tells server B that it wants to transfer information and tells the server what port to do this on. FireWall-1 sees the FTP PORT command and opens a unidirectional connection from server B on source port 20 to client A on the specified port. In the case of passive mode FTP, client A tells server B that it wants to transfer information in passive mode by sending the PASV command. Server B responds with an IP and port number to use. FireWall-1 then opens a unidirectional connection from client A to server B on the specified port. However, it flags the connection so only server B can actually send data. A unidirectional TCP connection basically means that originator of the connection is the only one allowed to send data, the other end can only ack or NACK the data. If the other end attempts to send any data back through a unidirectional connection, FireWall-1 will prevent it and log the error "violated unidirectional connection." So what does this mean? Basically, if the client attempts to send any data through the "data" portion of an FTP connection, FireWall-1 will drop it. Of course, this doesn't apply for a "bidirectional FTP" service, which can be created if necessary. It also means that "other hosts" (e.g. host C) cannot use this hoel. If you connect to trusted servers only, there should be no concern. Even with FTP servers of indeterminite trust, the FTP Server could simply choose to use a non-defined port in FireWall-1 and still compromise your network, though that would require collusion with someone inside your network. As such, the check for a "defined service" does not provide any real protection. If you're still concerned about this, you can use the FTP Security Server, an FTP "proxy" server (allow only FTP connections from this proxy server), or use a different protocol entirely. -------------------------------------------------------------------------------- -- RobertGraham - 23 Feb 2004 FAQForm FAQs.Class: ServicesFAQs, TroubleshootingFAQs FAQs.OS: FAQs.Version: |
![]() |
| Thread Tools | |
| Display Modes | |
| |