[olug] more secure FTP server?

[Lou Duchez]

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) | 
/sbin/chpasswd

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.



> Lou,
>
> 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
> actual attack (usually adding Javascript droppers to any HTML file that is
> 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 config
> 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 care
> about it and don't target it like they do FTP. It also works with Pluggable
> Authentication Modules the same way SSH does, so you can add multi-factor
> authentication e.g. Google Authenticator into your login flow pretty easily.
>
> 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 I
>> 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 the
>>> 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.  It's
>>> 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 to
>>> 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 will
>>> do.  And I'm looking into that.  but I'd also like to be running a good FTP
>>> server.
>>>
>>>
>>> ______________________________**_________________
>>> OLUG mailing list
>>> OLUG at olug.org
>>> https://lists.olug.org/**mailman/listinfo/olug<https://lists.olug.org/mailman/listinfo/olug>
>>>
>> ______________________________**_________________
>> OLUG mailing list
>> OLUG at olug.org
>> https://lists.olug.org/**mailman/listinfo/olug<https://lists.olug.org/mailman/listinfo/olug>
>>
> _______________________________________________
> OLUG mailing list
> OLUG at olug.org
> https://lists.olug.org/mailman/listinfo/olug