[olug] more secure FTP server?

Kevin sharpestmarble at gmail.com
Fri Aug 16 05:52:49 UTC 2013 

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
>

More information about the OLUG mailing list