FTP Helper on the LAN interface

[mikee]

I know that the standard traffic pattern in pfSense is traffic going from the LAN to the WAN. So if I need to access an FTP active server that is in the WAN the ftp helper opens back the port given in the PORT command. Under this pattern there is no need for the helper to listen to any other interface than that defined as WAN (having a gateway)

But there is an scenario where this model falls short and I have just hit one. Supose you have three pfSenses in line: one in a branch office, and another two in the main office all connected and with access to the internet.

The branch office device has a IPSec VPN with one of the devices of the main office. The other device in the main office is the one used to go to internet. Suppose you are requested to have the highest security as possible even in the internal traffic going to the branch office so you do not have an 'Allow Any Any rule' for traffic coming from the main office (LAN interface of the pfSense that hold the VPN with the branch) but only allow reply traffic (connections initiated from the branch office flow. Reverse ones do not, except for given services).

The branch office is configured in hub mode with a Catch-All trafic pattern that sends ALL the traffic generated in it to the main office including internet access. This is very common in corporate sites where all traffic has to undergo the coporate rules to go to internet. So the pfSense in main office that holds the VPN with the branch office delivers all internet traffic to the other pfSense in the main office (this is the only 'internet allowed' one). Hope this is clear and do not mess anyone.

Now a user in the branch office tries to open an active FTP session with a server in the internet. The traffic flow is to the local pfSense to the VPN to the remote main office pfsense to the 'internet allowed' pfsense that is where the NAT conversion happen and where the FTP helper notice that this is an active session and opens the back route for the ftp data.

So far so good but as the intermediate pfSense (the one that hold the VPN with the branch) is NOT listening to FTP in the LAN interface and the security policy does not allow non existing traffic from the main office to the branch this return traffic is dropped here. So no active FTP for the branch users.

This is easily fixed by defining a Allow any:20 -> any:any rule in the LAN side of the intermediate firewall but this defeats in great manner the security model as someone in the main office could use port 20 to bypass the enterprise security model.

It would be waaaay beter that we were able to enable FTP inspection in the LAN interfae of this intermediate router thus allowing back only the specific FTP data channel and avoiding any other tries to send data through it.

Not that I am complainig about the features of such a good platform that pfSense. But I would like to see this feature in some future release.

Thanks for your job.

[stephenw10]

@mikee said in FTP Helper on the LAN interface:

Suppose you are requested to have the highest security as possible

Now a user in the branch office tries to open an active FTP session with a server in the internet.

Those two things are mutually exclusive. FTP is inherently insecure so if you have a high level of security FTP should fail. IMO at least.

You could probably start the proxy service manually and have it use the internal interface as the outgoing connection.

But better to just stop using FTP in favour of pretty much anything else.

Steve

[johnpoz]

@mikee said in FTP Helper on the LAN interface:

Suppose you are requested to have the highest security as possible

As already stated you wouldn't be using FTP if that was the case..

Use SFTP and now you only have the 1 port, and non of the PITA you get with control and data channel and active/passive sort of connections.

The active ftp helper wasn't even there for a while..

FTP should of died off 10 years ago... You can not honestly mention security and ftp in the same breath dude ;)

[mikee]

@stephenw10 Well, not always it is in your hands to decide what to use. If you have files to get and those files are served through an FTP connection then you have to use FTP no matter how insecure you may feel it is.

I, as network administrator, am not in the position to tell the users what to use to do their job but to provide them with the best means to do it as easily as possible (at least that is what they expect from you).

Not to say to try to convince the ones that are supplying the files that FTP is dead. :-)

Still my point stands: the whole thing will be more secure with inspection than having to wide open to all traffic from a given port (usually 20 but that may change).

[mikee]

@johnpoz said in FTP Helper on the LAN interface:

FTP should of died off 10 years ago... You can not honestly mention security and ftp in the same breath dude ;)

Unfortunately this applies to too many things today like windows, email, you bank account...:-)

[stephenw10]

So the problem here is that on one of these firewalls the upstream port for outgoing FTP control is not WAN right?

Did you try setting the bind address to that interfaces IP? Or adding a VIP and using that?

Steve

[mikee]

@stephenw10 Hi Steve. Thanks for your ideas. You are quite right. Under the point of view of the intermediate firewall the LAN interface behaves like if it were a logical WAN (data goes from IPSEC to LAN and back).

Did you try setting the bind address to that interfaces IP?

What do you mean with the 'bind address'? So sorry, but I do not understand what you are trying to express.

Or adding a VIP and using that?

Not so far. What type should be? IP Alias or other? (I assume that not a proxy ARP and the CARP is for other uses, right?). And what is the point here? How do you use this secondary IP address and/or make the FTP data replies go through it?

I have thought about setting a gateway in the LAN interface definition just to make it behave like a WAN interface (and disable the NAT for it) but I have not tried it so far. Do not know if this would be enough or even good for the health of the whole firewall.

[Derelict]

The bind address is the address the server chooses to open the listening port on.

Servers can chooss to listen on one, more than one, or all local addresses.

Clients can choose to bind connections they make to source from any local address as well.

[mikee]

@derelict Ahhh!. Ok. Thanks delerict. Thanks for your reply. I did not thought about that kind of binding because I relate that concept more to server's connections as you clearly express. Let us then retake the original question:

@stephenw10 said in FTP Helper on the LAN interface:

Did you try setting the bind address to that interfaces IP?

I assume we cannot be talking of the server side because we do not own any of the servers the user connects to. So the only binding we could address is that of the client. But I cannot not see the point here either because the client has only one IP address so there is only one binding possible, right?. Even if she had more than one IP address, under the point of view of the pfSense, FTP traffic will still come from some internal IP address:port to the IP of the FTP server, will route it to the device that connects to internet (following its configured routing rules) and still not inspect the FTP session, so it will not create the reverse rule in the LAN interface that opens that channel to the expected FTP data stream and traffic still will be dropped.

Or I am missing something else here?

The problem (I think it is clear now but just in case) is not that there is any routing problem, it is that the pfsense rule set does not dinamically adapt to the FTP sessions that flow through it and do not use it's WAN interface. The user can connect with the remote server and all work fine to the point where the download is requested, the PORT command is issued and the data connection is waited back for. I have a capture in that pfSense that shows that it sees everything (I agree with you that completely insecure as you can see the user and password for example) but it does not act upon passing the PORT command to the FTP server.

What about setting a gateway to the LAN interface? Will this do the trick? Will this have any negative impact in the rest of traffic flowing through the firewall (because of implicit rules and the like)?

Though agreed that this is not the best protocol to use, the need to put a rule that open the connection to all traffic comming from port 20 from any to any for the useer to be able to operate is way more insecure than opening an temporary explicit rule from the FTP server's IP to the IP and bound port of the user's FTP client that is what the FTP proxy does.

@johnpoz said

The active ftp helper wasn't even there for a while..

Yes. That's true. This was a lot worse years ago but, fortunately, now we have tools to try to fix things that does not perform well. I am trying to use them. :-)

[stephenw10]

If you set the source address as the internal IP that is the setting the -a switch:

[2.4.4-RELEASE][admin@5100.stevew.lan]/root: ps -auxww | grep ftp
proxy   80363   0.0  0.1   6268   2328  -  Ss   19:01      0:00.00 /usr/sbin/ftp-proxy -a 10.100.10.2

So that is the IP the proxy uses as the source for control traffic leaving it. Therefore as long as the routing from that firewall is correct it I expect it to work.

https://www.freebsd.org/cgi/man.cgi?query=ftp-proxy&apropos=0&sektion=0&manpath=FreeBSD+11.2-RELEASE+and+Ports

Note that you cannot reply on policy routing for this as traffic from the proxy itself will always use the system routing table.

Steve

[mikee]

@stephenw10 Hi Steve. I did not thought about going directly into the shell. Now I understand what you were refering to when you wrote about 'binding'. Thanks.

[stephenw10]

I would expect that to work unless the routing is wrong on that firewall. If it is you can probably add a static route for the FTP server in question via the other pfSense box.

Steve

[mikee]

@stephenw10 The dark side of using proxies is that you lose the IP of the original requestor. This is something that I did not take into consideration when using what pfSense does in the case of the WAN interface as an example.

As NAT is usually applied in the WAN interface most of the times, over that interface it already happens the 'proxy' conversion: the change the source IP of the packet with the public external IP. I do not want that side effect. What I was really after is what the RELATED keyword does in iptables. I was after something like:

iptables -A INPUT -p tcp -i eth0 --dport 21 -j ACCEPT
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

In this construct you do not alter the traffic flow. You only open the system for reverse connections and only for the specific, related, one. But there is no iptables in pfsense and I do not know if there is something alike that may have the same effect in the traffic.

[stephenw10]

That is pretty much what the proxy does.

You can have a chain of pfSense boxes and use ftp though them all then only difference I see with what you're doing is that the second box in the chain is not using WAN as it's upstream connection for the ftp traffic.

How is it failing for you right now? You see traffic blocked? You see it leaving via the wrong interface?

Where do you need to see the original source IP that you do not?

Steve

[mikee]

@stephenw10 Hi Steve. Thanks for your reply. The fail happens as soon as the client issues the PORT command and closes the connection waiting for the FTP server to call back to the tcp port that it was told to use.

The first pfSense (the one in the branch office closest to the user connecting to the FTP server, call it pfs1) has no problems with this because pfs1 takes all that traffic and sends it through the VPN so no problems at all forth and back. The VPN has no restrictions regarding traffic flows. All ports open inside the VPN.

When the intermediate pfsense (pfs2) receives the encrypted traffic (it is the VPN endpoint) decrypts it, looks in its routing table and deliver it (through the LAN interface) to the last pfSense in the chain (pfs3) that, in turn, applies NAT and delivers it to the external internet FTP server. All this working fine, no drops no wrong deliveries.

pfs3 must have the proxy ftp listening in the WAN interface as it is able to track the connection back from the FTP server and traffic flows. pfs2, on the contrary, has not tracked anything over the FTP session so it blocks the incoming replies and drops the traffic. It can be seen in the firewall log: denied by default rule.

I have configured a rule in the LAN interface of pfs2 to allow this traffic (allow any:20/tcp to any:any/tcp) so now FTP replies are able to pass but this is a security hole: any with this knowledge will be able to send unsolicited traffic through pfs2 to the branch office.

If I configure the ftp proxy in the LAN interface of pfs2 as suggested (a clever suggestion by the way) then I am sure that it will work too without the need of that insecure rule but at the price of losing who made the FTP request. The net monitors in pfs3 will not be able to match FTP sessions to IPs as ALL traffic will come from the same IP, the one of the LAN interface of pfs2 where the proxy is applied.

Of course this can be avoided by monitoring in pfs2 too but it should be far more convenient not to have to do all this just to let ftp connections flow back through it by adding traffic inspection (the conntrack RELATED option).

There are only these options: open ports, track the connection or proxy it. If pfSense has any mecanism to track them then should will be the preferred way, else proxy it if you can or are allowed then open ports. If any of those solutions does not apply then tell the useer not to use FTP anymore :-)

[stephenw10]

Mmm, OK. Well as you say the ultimate solution here is to stop using FTP. But until then those are the choices; more secure or more visibility. I'd have to assess exactly what risk opening port 20 to other internal hosts is. I'm thinking it's probably not huge. Especially when compared to using FTP over the public internet.
You could probably lock it down further, does that rule need to be any destination IP? Does it need to be any source IP, how many servers are they connecting to?

Steve

[Derelict]

Not that I am complainig about the features of such a good platform that pfSense. But I would like to see this feature in some future release.

FTP will probably not receive any love at this point.

The real solution is for your side to put in the money and effort to get off of that old, antiquated, obsolete, insecure, firewall-unfriendly protocol that is active FTP.

Even IF you use ip_conntrack_ftp in iptables that is only going to be effective as long as the protocol is unencrypted and insecure with usernames and passwords flying about in-the-clear etc.

[mikee]

@stephenw10 Hi Steve. I think that the rule is the only one possible if you don't want to be all day chasing system cn¡hanges. There are several users receiving their IPs by DHCP from a class C pool so they may change their IP without notice (I know that there exist reservations but not applied to client PCs) and there are several (do not know how many) servers. I understand that we can lock it down and even put a rule for each client PC so that control granularity can be as fine as you want but I think this does not deserve the time and effort involved.

The actual security is what it is reasonable to be (easily explainable if you have to) for the kind of service we have to deal with without not having to be all day hooked onto the firewall if we do not have any other automatic mechanism to achieve that goal.

Thanks for your implication in this.

[johnpoz]

WTF does that have to do with moving away from the DEAD protocol that is FTP??

That has to be some sort of google translate gibberish? Or your stoned? ;)

[mikee]

@derelict You are right. The fact that the protocol is insecure does not change the fact that is is still being used and that there are those that offer the service the ones that have to change it. We have to deal with that.

Perhaps if certificates had not been so difficult and expensive until the entry of LetsEncript in the field...