[olug] more secure FTP server?
rob.townley at gmail.com
Thu Aug 15 20:52:13 UTC 2013
Is anonymous FTP an option?
On Thu, Aug 15, 2013 at 9:35 AM, Lou Duchez <lou at paprikash.com> wrote:
> This is all good advice, thanks! It's especially helpful to know that brute
> force attacks aren't the main threat, and I need to think more in terms of
> known logins and passwords.
> There are one or two situations, I find, where I am still stuck with FTP, so
> the question is how to secure it. These seem to be good measures:
> - eliminate all non-essential FTP accounts
> - change to a non-default port
> - use iptables to block access from untrusted IPs
> - reset passwords frequently
> About resetting passwords ... how about adding this line to your crontab:
> 0 * * * * /bin/echo login:password$(/bin/date +\%m\%d\%H) |
> Every hour, on the hour, it will change a given account's password to some
> fixed string followed by the month, day, and hour. That means that, even if
> a password is hacked via whatever malware, it's good for no more than an
> hour, and would have to be used immediately to cause any trouble. Whereas a
> trusted user would be able to get past that hourly hurdle pretty easily.
> A person could get even more tricky, in case they're worried about hackers
> noticing the pattern with passwords: the $RANDOM environment variable could
> be used to generate the password. It would also be necessary to publish the
> random number somewhere -- say, on a Web page in a nondescript location --
> but it could be done.
>> Getting FTP passwords jacked is extremely common and in the vast majority
>> of cases the culprit is end user malware. There are a couple prolific
>> strains that shim the Windows TCP/IP stack and sniff passwords (which FTP
>> transmits in plain text), and a couple more that read saved passwords from
>> common client software such as Filezilla and SmartFTP. In both cases, they
>> then typically transmit the stolen credentials to the attacker, and the
>> accessible to the FTP user) is carried out by a drone machine on a botnet
>> or something like that (which is why you might have seen an unexpected
>> connection from a foreign country).
>> The best advice I can give you, the preferred course of action, is to not
>> use FTP. FTP is a junky old protocol that provides no security. It is
>> low-hanging fruit and a favored target of script kiddies and botnet
>> operators. If you run FTP and have any number of users above about 2 you
>> will constantly be on the defensive against stuff like this.
>> Instead, use SFTP. SFTP is an SSH-based protocol, so if you are running
>> SSH, you are probably already running it -- if not, it's a one-liner
>> edit to enable it. Most client FTP software supports it; in Filezilla you
>> can change your saved FTP connection profiles to SFTP connections by
>> clicking a radio button. It operates over SSH so it is fully encrypted
>> end-to-end, and the jerks who bingoed your FTP server don't know/don't
>> about it and don't target it like they do FTP. It also works with
>> Authentication Modules the same way SSH does, so you can add multi-factor
>> authentication e.g. Google Authenticator into your login flow pretty
>> If you want to continue to run FTP, the best defense against this is to
>> educate your end users: Keep your Windows machine virus-free, NEVER save
>> your password in your FTP client, don't use the same password for FTP as
>> for anything else because it flies across the network in clear text, etc.
>> You might also take some preventative measures like generous blacklisting
>> of foreign IP ranges your users aren't likely to log in from (or just
>> default-deny connections and whitelist end user IPs instead), set up FTP
>> over SSL, and add some kind of two-factor auth to VSFTP (which I'm told is
>> possible but I haven't messed with it, and I don't know how good client
>> support for it is).
>> On Aug 12, 2013 9:07 PM, "Lou Duchez" <lou at paprikash.com> wrote:
>>> ... I think maybe I spoke too soon -- VSFTPD seems to do a fine job of
>>> logging when I test it myself. I had assumed it was a brute-force attack
>>> because the IP that the hack originated from is in Bavaria, but as far as
>>> can tell, a brute-force attack would have been logged and Fail2Ban would
>>> have shut that down (that's what happened when I tested it myself).
>>> Malware on a user machine? Packet sniffer? All I can do is talk to end
>>> users, change the passwords, and try to lock the FTP down by IP.
>>> So one of my Web sites got hacked via FTP. Looking into it, here is
>>>> problem. I am running VSFTPD, and I am also running Fail2Ban to monitor
>>>> the VSFTPD log and detect failed login attempts. It's a good system.
>>>> a nearly flawless system. The one flaw in this is, apparently, VSFTPD
>>>> doesn't bother to write much of anything to the log(s) when there are
>>>> errant login attempts, so Fail2Ban doesn't have anything to work with.
>>>> Does anyone know how to make VSFTPD more talkative in the case of failed
>>>> logins? Or can anyone recommend a better FTP server, one that bothers
>>>> log these things properly?
>>>> I realize that there are other measures I can take too, such as limiting
>>>> the IPs, changing the port, and not using FTP except when nothing else
>>>> do. And I'm looking into that. but I'd also like to be running a good
>>>> OLUG mailing list
>>>> OLUG at olug.org
>>> OLUG mailing list
>>> OLUG at olug.org
>> OLUG mailing list
>> OLUG at olug.org
> OLUG mailing list
> OLUG at olug.org
More information about the OLUG