Host tried to open tcp service port, port xxxx

[BarryStiefel]

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, dportIn 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:

1. Backup the $FWDIR/lib/base.def on the management:

2. Edit the $FWDIR/lib/base.def and add the following line: #define NO_SERVER_PORT_CHECKright below the line (at the top of the file):

#define __base_def_This effectively disables the macros that check for defined services.



3. 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 todefine 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 todefine NOTSERVER_TCP_PORT(p) {(not( p < 1024, set sr10 RCODE_SMALL_PORT, set sr11 0, set sr12 p,set sr1 0, log bad_conn))};

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 hole.

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.

-- PhoneBoy - 05 Jan 2004

FAQForm FAQs.Class: ServicesFAQs, TroubleshootingFAQs FAQs.OS: FAQs.Version: