[olug] more secure FTP server?

Fri Aug 16 12:00:44 UTC 2013

Right, and that's my problem.  I know that user "foo" should connect 
from only one IP, while user "bar" could connect from one of two 
different IPs, and a third user doesn't have a static IP at all.  So if 
I want to limit "foo" to his IP, "bar" to his IPs, and leave the third 
user wide open*, neither iptables nor VSFTPD directly supports that.

Best I can do is set up three different instances of VSFTPD, each 
running on a different port, and each looking at a different "user_list" 
file.  While I'm at it, maybe set up a fourth instance of VSFTPD that 
runs on the default port, with an empty "user_list" file to serve as a 
decoy for hackers.

*: Though it would be smart to block international traffic for most 
purposes.  Check this:

http://krnlpanic.com/wp/blocking-international-network-traffic-from-your-server/

> iptables can't limit what users can connect; it can only limit what IPs can
> connect and how fast. Just wanted to make that clear.
> On Aug 16, 2013 12:30 AM, "Jay Bendon" <jaybocc2 at gmail.com> wrote:
>
>> iptables should let you limit who can connect to FTP services ;)
>>
>> --Jay
>>
>>
>> On Thu, Aug 15, 2013 at 10:14 PM, Obi-Wan <obiwan at jedi.com> wrote:
>>
>>> 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
>>>
>>> _______________________________________________
>>> 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