[olug] more secure FTP server?

Fri Aug 16 03:14:43 UTC 2013

Can you use TCP Wappers to limit IP's?

Ben "Obi-Wan" Hollingsworth, www.Jedi.com
Sent from my Samsung Galaxy Note® II

-------- Original message --------
From: Lou Duchez <lou at paprikash.com> 
Date: 2013/08/15  4:32 PM  (GMT-06:00) 
To: Omaha Linux User Group <olug at olug.org> 
Subject: Re: [olug] more secure FTP server? 

It's not, unfortunately.  But I've narrowed it down to only three 
accounts that might ever require access from the WAN, and I've put them 
on hourly passwords.

The biggest problem is that I can't configure VSFTPD to be selective as 
to which IPs it will allow logins from.  Wish I could do that; I know it 
can be done for SSH (and therefore for SFTP as well).  Maybe I'll have 
to run multiple instances of VSFTPD on different ports, with different 
iptables rules for each port.

> 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
> _______________________________________________
> 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