how to use ip_conntrack_ftp module

Running FTP is a bad as using TELNET to connect to your servers.

There are sooooooo many better alternatives. SFTP, SCP, Web based File managers, etc.

@math:

IPTABLESMODULES="ipconntrackftp" module to firewall ftp. To actually address your question, ipconntrack_ftp is built into Linode kernels and does not have to be loaded to be used. You can probably leave this empty – since it sounds like configuring this makes it try to insmod it -- and the functionality already exists in the kernel.

If you're familiar with configuring Linux, the entire configuration of a Linode-built kernel is available in /proc/config.gz (which you can read with, say…)

zgrep CONNTRACK /proc/config.gz

The thread you initially poked dealt specifically with UML, and the "modules cannot be inserted" stance was correct at the time. These days, under Xen, I have inserted several modules into a running Linode kernel just fine. That's why it's important to check a thread's date before replying to it. :)

In this specific case, however, it is unnecessary.

@vonskippy:

Web based File managers
Not to pick a fight with you, but I'm not sure I'd call those better than FTP. That falls under my same gripe as with phpMyAdmin.

FTP is inherently INSECURE.

Web based File Managers come in numerous flavours, some are very secure, some not so much. But across the board, if they use HTTPS they're a factor or two better then FTP.

FTPS or FTPES are no worse than HTTPS because the control channel is encrypted. If you need to encrypt data as well, then you're better off with SFTP (FTP over SSH).

Also consider moving FTP to different port to avoid bots trying to bruteforce.

That said, the only bad thing about FTP is that it uses passwords, so if you really need improved security, use SFTP with pubkey auth.

@Azathoth:

FTPS or FTPES are no worse than HTTPS because the control channel is encrypted. If you need to encrypt data as well, then you're better off with SFTP (FTP over SSH).

HTTPS would be encrypting the data too, making FTPS/FTPES worse by your standard.

Also note that if CONFIGNFCONNTRACK_FTP is actually needed, it relies on being able to sniff the control channel traffic. Obviously, if the control channel is encrypted, it will not be able to do so and it won't work.

A little background: the default mode of FTP (active mode) opens a connection from the server to the client to transfer files, which fails with NAT. So, you can either have the NAT anticipate that connection and set up the forwarding (which is what conntrack is for), or you can have the client open a connection to the server (sensible). The latter is called "passive mode" and is generally supported by many things.

However, it requires that the server pretty much be wide open for incoming connections on random ports, which tweaks some security-minded people. Also, the server can't be behind a NAT, or you have the same problem and need to use conntrack.

Fortunately, 15 years ago, this problem was solved using SSH, which multiplexes the data channel(s) with the control channel and only requires one TCP stream. Strangely, while telnet is almost unheard-of these days, ftp is still out there.

Hello,

I plain to use sshguard (http://www.sshguard.net/ ) monitoring my FTP server - hope this make FTP connection more secure

specially I do my best to use conntrack_ftp but dont work for me.

thank you very much

best regards

@math:

hope this make FTP connection more secure
Does nothing to make your FTP connection more secure. FTP sends username and passwords in clear text. Therefore there is no need to hammer on a FTP server to try and "crack" into it (which is what sshguard helps prevent).

@vonskippy:

@math:

hope this make FTP connection more secure
Does nothing to make your FTP connection more secure. FTP sends username and passwords in clear text. Therefore there is no need to hammer on a FTP server to try and "crack" into it (which is what sshguard helps prevent).

Just because auth is in clear text doesn't mean there is no reason to attack an FTP server. If an attacker has no way to grab the clear text password, a dictionary attack can still be done, just like against any other server.