[olug] more secure FTP server?

[Rob Townley]

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) |
> /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
>
>
> _______________________________________________
> OLUG mailing list
> OLUG at olug.org
> https://lists.olug.org/mailman/listinfo/olug