FTP over SSL fails with VPN-1/FireWall-1

[BarryStiefel]

FTP over SSL fails with VPN-1/FireWall-1



FTP over SSL is specified in RFC-2228.

Firewalls do not normally pass FTP connections encrypted with SSL commonly referred to as FTP over SSL. The reason for this is simple: A firewall cannot inspect the FTP control connection because it is encrypted. VPN-1/FireWall-1 therefore cannot predict the FTP ports used by the FTP over SSL session. Some people have been able to get this to work by simply applying FTPAndNewlines, assuming the ports used are the standard TCP port 21 for control and 20 for data.

Some variants of FTP over SSL operate over different ports using port 990 for control and port 989 for data. In this case, you simply need to create the following TCP services:

• ftp-ssl-control: port 990
• ftp-ssl-data: port number ">1024" (greater than 1024), source port 989

In other words, ftp-ssl-data accepts connections with a destination port of any TCP high port provided the source port is 989. The rulebase to permit access looks like the following:

Source Destination Service Action ftp-client ftp-server ftp-ssl-control accept ftp-server ftp-client ftp-ssl-data accept

Note that in no case will FTP over SSL be supported with HIDE Network Address Translation (NAT). This is because FireWall?-1 is unable to see the "control" portion of the connection and cannot "munge" the ports to work with HIDE NAT. It can be made to work with Static NAT.

-- PhoneBoy - 16 Jan 2004

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

[ddiggler]

I currently went through a swap of a CheckPoint 4.1 FW running on Windows NT 4.0 (this was before my time...don't shot me :)..). We replaced it with 2 SecurePlatform NGX R61 enforcement modules with HA.

We have a multi-DMZ segment design with multiple inbound (IIS;DNS;SMTP..etc) and outbound (SMTP;HTML;DNS..etc) connections. Since there is no direct upgrade from 4.1 to NGX, I had to recreate all the rules and such. Everything when flawlessly except for 2 SSL over FTP connections. We have two client computers on our DMZ that does an outbound connection to a customer. These systems are using static NAT's and work perfectly with the 4.1 FW-1. For the life of me I could not get this connection to work through NGX R61. I would see the outbound connection on 21 then an inbound connection from the customer on >1023 but the log entry for the >1023 connection back in from the customer was an alert from SmartDefense..I didn't see any real drops. Just for the sake of testing I put rules in to allow all services to and from the client and our customer with the same outcome.

What am I missing here?

(I apologize for the lack of details. I was up until 3:00AM last night trying to get this for work. I ended up having to put the old 4.1 FW-1 back into production. I will give you more details when I set this up in the lab. I have to get this to work before the second attempt.)

[Lackie]

What is the alert that you received from SmartDefense?

[ddiggler]

Here are the log entries. I tried updating and disabling SmartDefense with the same outcome. There is an outbound FTP(21) connection to the customer then the customer tries to connect back on the translated source port. I am going to setup some VM sessions to try to replicate the problems. I can't put these new firewalls back in because of the same IP's.

Number: 138657
Date: 22Jul2006
Time: 23:27:37
Product: VPN-1 Pro/Express
Interface: eth2
Origin: <Active_Node>
Type: Log
Action: Accept
Protocol: tcp
Service: ftp (21)
Source: <DMZ_Device>
Destination: <External_Customer>
Rule: 26
Current Rule Number: 26-Standard
Rule Name: Outbound Connect
NAT rule number: 14
NAT additional rule number: 0
Source Port: 1757
XlateSrc: <DMZ_Device_NAT>
Information: service_id: ftp


Number: 138669
Date: 22Jul2006
Time: 23:27:42
Product: SmartDefense
Interface: eth1
Origin: <Active_Node>
Type: Log
Action: Monitor Only
Protocol: tcp
Service: ftp (21)
Source: <DMZ_Device>
Destination: <External_Customer>
Source Port: 1757
Attack Name: FTP Bounce
Attack Information: The packet was modified due to a potential Bounce Attack (Telnet Options)


Number: 138726
Date: 22Jul2006
Time: 23:27:53
Product: SmartDefense
Origin: <Active_Node>
Type: Alert
Action:
Protocol: tcp
Service: ftp (21)
Source: <DMZ_Device>
Destination: <External_Customer>
Source Port: 1754
Attack Name: FTP Bounce
Attack Information: The packet was modified due to a potential Bounce Attack (Telnet Options)
Information: Total logs: 2
Suppressed logs: 1


Number: 138727
Date: 22Jul2006
Time: 23:27:53
Product: SmartDefense
Origin: <Active_Node>
Type: Alert
Action:
Protocol: tcp
Service: 1754
Source: <External_Customer>
Destination: <DMZ_Device_NAT>
Source Port: ftp (21)
Attack Name: FTP Bounce
Attack Information: The packet was modified due to a potential Bounce Attack (Telnet Options)
Information: Total logs: 4
Suppressed logs: 3


Number: 139321
Date: 22Jul2006
Time: 23:29:42
Product: SmartDefense
Origin: <Active_Node>
Type: Alert
Action:
Protocol: tcp
Service: 1757
Source: <External_Customer>
Destination: <DMZ_Device_NAT>
Source Port: ftp (21)
Attack Name: FTP Bounce
Attack Information: The packet was modified due to a potential Bounce Attack (Telnet Options)
Information: Total logs: 6
Suppressed logs: 5

[kva.kva]

IMHO you need to uncheck FTP Bounce in SmartDefence or set for it option "Monitor Only".
http://secureknowledge.checkpoint.co....do?id=sk31459
But before it make sure, that these connections are valid .

[ddiggler]

I did find people posting solutions that said to modify the BASE.DEF file. I searched the BASE.DEF for FTP and it found nothing. This may have changed since NG FPx

Example: http://lists.virus.org/fw1-0503/msg00446.html

[ddiggler]

I tried disabling SmartDefense all together and it still didn't work.

[kva.kva]

Don't forget install policy after that and try to use "monitor only" option for FTP Bounce.

[ddiggler]

I did install the policy afterwards. I think I know whats going on. When you disable SmartDefense all of the options get unchecked....except for FTP Bounce. I was disabling all of SmartDefense and assumed it was disabling all of SmartDefense....I will never learn not to assume.. LOL.

I will try changing it to monitor. It doesn't appear that you can just disable it.

BTW, Can you post the CP articale from above into the forum. That powers that be decided not to get support....That's why were in this little perdicument..

Thanks.

[kva.kva]

Symptoms
Valid FTP connection is being dropped as an FTP bounce attack by the NGX R60 Security Gateway.

...
Solution
In order to allow valid FTP connections that are being dropped as FTP bounce attacks, apply the following procedure:

...In the upper-right corner of the FTP Bounce window, check the box 'Monitor only - no protection'...
...Reinstall the Security Policy on the Security Gateway...

[ddiggler]

I was able to get this working. It was a combination of checking the monitor only - no protection within SmartDefense for FTP Bounce and using one rule with FTP-BIDIR as the service. Normal FTP doesn't work. Even if you make an inbound rule to allow >1023 to this device. 'ANY' also does not work when set for the service. You have to specifically assign one outbound rule with FTP-BIDIR as the service.

Thanks for all your help...

[fab_lab_99]

My system:

Check Point VPN1 FP 3 r55

I have an FTP server in my DMZ, which I need to reach from public Internet, and connect via FTP over TLS, listening port 2121 and data port 2120.
So I natted its private IP address with a static Nat, and then did the following:

RULE 01:

SOURCE: Ftp Server
DESTINATION: Ftp CLient
SERVICES:

1. >1024, source port 2120

2. port 2121 (FTP-BIDIR)

RULE 02:

SOURCE: Ftp CLient
DESTINATION: Ftp Server
SERVICES:

1. port 2121

2. port 2121 (FTP-BIDIR)

In this way, I could connect from my client (with its public IP address) via FTP over TLS, though not having disabled FTP BOUNCE ATTACK in Smart Defense Consolle.
But I realized that I had to set my FTP client to work in Active Mode, because in classic Passive mode I could not connect.
In this second case, in facts, when I tried to connect, connection seemed to proceed to be established but then:

1. ftp client sends command 'PASV'; ftp server answers 'entering passive mode';
2. ftp client sends command 'LIST'; connection hangs for some seconds;
3. after timeout has exceeded, connection is rejected;

Now, I can't understand why this happens. I am quite sure it is an issue related to Check Point configuration. In facts, if I try to
connect from a client located on the same lan of ftp server (say, in DMZ), connection is established in active or passive mode.
But more strange is that when my public ftp client is set in passive mode and can't succesfully connect to the server, I have no logs on Check Point of
dropped packets. Anyone has some suggestions ?

[Richard Poon]

Hi there,

I have similar problem at our site. The FTP over SSL fails with similar symptom. It looks like the session is timeout while waiting for response from the FTP server. I finally figured out that it is the "FTP Bounce" protection being enabled in CheckPoint's SmartDefense feature. I resolved the issue by changing it to "Monitor" from "Protect".

Hope this help.

Richard

[dvast8ya]

Hi,

We're running NG AI R55 and we're also having issues with FTP over SSL and getting this on SmartView Tracker: Attack Info: The packet was modified due to a potential Bounce attack.
We just want to disable this FTP Bounce check on SmartDefense, but it's grayed out. R55 does not have the option to set it to monitor only. Is there a work around for disabling FTP Bounce check on R55???

[membree]

FTP over TLS is not recognizable as FTP by VPN-1 because the control traffic is encrypted. The solution is to create a FTP control service but do not specify a Protocol Type, or specify the type "FTP_BASIC", and explicitly allow any required data ports.

Since the firewall can't decrypt FTPS control traffic, it can't dynamically allow the required ports for FTP data inbound or outbound so we only allow PASV FTPS and have configured our FTPS servers for a specific range of PASV DATA ports that are explicitly allowed by the rule.


The new FTPS standard is very Firewall unfriendly, it is too bad that the opportinity wasn't taken to fix the FTP protocol so that it was firewall friendly.

[gluperini]

Hi,
I'm a newbie in checkpoint environment and use, and I have some kind of the same issues using FTP over SSL.
The FP seems to work well, the authentification is OK, but after, my ftp client is disconnected from my server.
When I check the logs (smatview tracker), I can see that the FTP erquest have been droped by the Firewall (NG AI R55) with this error:
Message_info: FTP command ended without a new line charactere.

So do you you think this a problem of encryption request that are blocked by the Firewall, is there a way to fix it ?

[membree]

As I mentioned in my previous post (2006-05-01) FTPS will not work using the standard FTP service. This is because the traffic is encrypted so the Firewall can't inspect it.

You must create a separate service for FTPS control traffic that either doesn't specify a protocol type (in Advanced service properties) or specifies "FTP_BASIC". Use "FTP_BASIC" if you want the service to also work with encrypted FTP (note that it doesn't enforce FTP protocol so this may not be a good idea), leave it blank if it is only for FTPS (also doesn't enforce FTP protocol but there is no other choice). You must also explicitly allow any required Data ports. I recommend that you only allow PASV mode FTPS and that you configure a specific range of PASV data ports on your FTPS server (100 ports would generally do) and only open them. Using standard (or PORT) mode FTPS requires that you allow any possible data ports to the client and is not a good idea.

If your FTPS server is NATed you have a problem unless the FTPS server can be configured to supply its NAT address rather than its real address in the PORT commands it returns to the client (some servers will allow this). Another possibility is that some servers can be configured to not supply an IP address in the PORT command but I don't know if all FTPS clients are compatible with this option.

I will add an additional post with some general FTPS info.

[membree]

FTP is a notoriously firewall unfriendly protocol, this issue has been dealt with by intelligent firewalls that monitor the FTP control traffic and do what is required to make it work, while limiting some of the potential security problems inherent in the protocol. Unfortunately, the IETF have chosen to make FTPS work identically to FTP but with the addition of TLS encryption, fixing none of the FTP issues and creating more. With FTPS, the control traffic is encrypted so it is not possible for a firewall to see what is going on so we are essentially back to the day of the dumb packet filter when dealing with FTPS. In fact, standard Firewall FTP protocol inspection will block FTPS traffic as being invalid and potentially dangerous.\

FTP and FTPS have two modes PORT (or standard) and PASV (passive).
With PORT mode, the FTP client initiates a connection to the FTP server on the control channel, and sends a PORT command that provides the server with an IP address and TCP port (generally a random port >1024) that it should connect back to for data transfer. With FTP the firewall monitors this conversation and automatically opens the reverse connection, ensuring that the IP supplied is actually the client IP and, in some cases, that the port is not a well known service port. With FTPS the firewall can't monitor the connection so doesn't know any of this. Since inbound firewall connections are typically blocked by firewalls, FTPS PORT mode can not work unless the firewall is manually opened for all traffic on all high ports from the FTPS server address, not a very good solution.
With PASV mode, the FTP client initiates a connection to the FTP server on the control channel and sends a PASV command to the server, which replies with an IP address and port (generally a random port > 1024) that the client should connect to for data transfer. With FTP the firewall monitors this conversation and automatically opens the connection, ensuring that the IP supplied is actually the server IP and, in some cases, that the port is not a well known service port. With FTPS the firewall can't monitor the connection so doesn't know any of this. Outbound firewall connections that aren't to well known services may be blocked by firewalls, when this is the case, FTPS PASV mode can not work unless the firewall is manually opened for all traffic on all high ports to the FTPS server address, also not a very good solution but much better than PORT mode.

A mitigating circumstance with many FTPS servers is that the range of ports that will be used for the PASV data connection can be specified, improving the situation substantially from that specified by the FTP standard. Since a unique port range can be specified (eg 52600-52699), firewall rules only need to allow access to the control port and this range. Unfortunately the standard is all high ports so there is no standard limited range. So even when the port range is limited, it will likely be different for each FTPS site.

There are also serious issues with NAT and FTP/FTPS since the protocol specifies the client or server IP address in the control traffic. If a client (PORT mode) or server (PASV mode) is NATed, FTP/FTPS breaks. With FTP, firewalls are generally smart enough to modify the control traffic when NATing. With FTPS, this is not possible because the control traffic is encrypted.

FTPS is not compatible with NAT. However, some clients and/or some servers have means of getting around the NAT issue but this is not universal and can make things more complicated and non-standard on both ends. Some FTPS servers can be configured to supply a user provided (ie NAT) address to the client rather than real address in the commands they return to the client. Another possibility is that some FTPS servers can be configured to use EPSV (Extended Passive Mode) and not supply an IP address in the commands they return to the client, however, I don't know if all FTPS clients are compatible with this option.

If possible, FTPS should be avoided and some other more firewall friendly protcol such as HTTPS or SFTP should be used. If FTPS must be used, I recommend that only PASV mode (with a limited range of data ports) be used. PORT mode is even more firewall unfriendly than PASV mode and is also incompatible with client side NAT.



Some references:
- ftps - FTP-SSL and FTP-TLS (RFC4217) - the state of play
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
- FTP SSL through a NAT Firewall
http://geekswithblogs.net/lance/arch.../23/50912.aspx
- Secure FTP Over SSL and NAT WhitePaper
www.stdnet.com/uploads/media/MOVEit-DMZ-FTPS-NAT-Whitepaper.PDF


Some free FTP/FTPS clients:
- FileZilla (http://sourceforge.net/projects/filezilla/), a very nice FTP client with FTPS capability.
- MOVEit Freely (http://www.stdnet.com/moveitfreely/), a scriptable, drop in replacement for the Microsoft command line FTP that addes FTPS and PASV capablilty.
- cURL (http://curl.haxx.se/)


A commercial FTPS server proxy:
- FTP Guardian (http://www.tcpdata.com/ftpg_overview.shtml). This product allows you to add FTPS support to Microsofts IIS FTP or other FTP servers that don't natively support it.