[olug] more secure FTP server?

Fri Aug 16 05:30:34 UTC 2013

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
>