[TriLUG] Securely and Accurately transmit passwords
jonc at nc.rr.com
jonc at nc.rr.com
Thu Oct 4 09:47:12 EDT 2007
Wow, a lot of good responses. First, here is a link to Denyhost:
http://denyhosts.sourceforge.net/
If you don't know what this is, STOP. Click on the link. Download. Use.
If you know what this is. Relax. Smile. Finish your coffee.
It's not a panacea that cures all ills, but it is one of the easiest security apps to use.
At my corp we use mostly https, but we also use ssh and smb to move files around and to let us poke our noses into remote and local spots.
With SSH most systems do NOT allow any direct login for root, and shouldn't. That is a great policy, and I agree 100% on that... the 'sudo -s" policy anyway :-)
Your IP rules are good and I'm glad you mentioned them here. There is a lot that folks can do at the firewall level to stop flood-type attacks. Don't discount Denyhosts though. It is a very simple app that you can easily modify to guard more than just your ssh logins.
It's been a long time since I first started mangling Denyhost, but at this point it examines multiple logs for me and depending on the log entries, denies access to multiple services. I really like this app. And its written in python!
By default Denyhost uses the "hosts.deny" file to stop bad guys from accessing services on your server. It also sends you a summary of IP's and services locked out each hour (as well as warnings of the number of legitimate uses for that hour). The summaries are a bit of an over-kill for me and I generally just let them collect up for a month and then dump them.
Jon (smiling and drinking his coffee) Carnes
---- Kevin Hunter <hunteke at earlham.edu> wrote:
> At 9:49p -0400 on 03 Oct 2007, Jon Carnes wrote:
> > The maximum number of times I let folks try a password (before
> > locking the account for an hour) is 10 times. Tell me how some
> > cracker is going to use a dictionary attack and crack one of my
> > accounts. Unless he lucks into the password in the first 10 tries,
> > his app is simply going to be spinning its' wheels uselessly for the
> > next 59 minutes and 59 seconds...
> >
> > Also, most admins I know use the security app Denyhosts. It was
> > mentioned by someone else earlier in this thread. I have some very
> > strict Denyhost rules for my secure accounts (admin/root accounts).
>
> Hrm. I assume we're talking ssh here? Pardon my naivety, but at the
> point you have power users with admin privileges, why do you allow ssh
> to root at all (except from within your network; even then . . .)?
> What's wrong with good ol' "sudo su -"? Second question, why don't you
> use ssh keys with a passphrase for your admins? (And with passphrases,
> presumably refer back to this discussion :-P)
>
> > If a hacker
>
> Hey now! I consider myself a hacker! Don't you mean cracker? ;-)
>
> > is trying to break into a secure account, the python app
> > Denyhosts locks out all the IP's used in his attacks. The hacker
> > would have to harvest the entire net to stand a chance of breaking
> > in, and even then he'll only have a window of opportunity of 10
> > attempts every hour.
>
> Again, pardon my naivety (I'm fairly new to these waters), but assuming
> you mean ssh why do you need to use the python app Denyhosts? Can't
> this be done at the firewall level (since ssh uses a new connection for
> new login attempts)? Something like this in the netfilter rule file:
>
> # allow ssh connection attempts, both in- and out-going, but protect
> # against brute force ssh attacks
> $IPTABLES -A OUTPUT -p tcp -d 0/0 --dport 22 -j ACCEPT
> $IPTABLES -A INPUT -p tcp -d 0/0 --dport 22 -m state --state NEW -m \
> recent --set --name SSH -j ACCEPT
> $IPTABLES -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 \
> --hitcount 4 --rttl --name SSH -j LOG \
> --log-prefix "SSH Brute force"
> $IPTABLES -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 \
> --hitcount 4 --rttl --name SSH -j DROP
>
> This is what I have set up on my machine. Does Denyhosts do it better?
>
> ... /me reads further posts before clicking send, then kicks self
>
> Two different levels. The firewall method blocks individual IPs but
> still leaves accounts open to distributed attacks. I assume denyhosts
> blocks off the user account with /bin/false, *, !, or something? The
> description touts that it doesn't need firewall built into the kernel;
> but if you've netfilter compiled in, wouldn't the firewall approach be
> less expensive cpu-wise?
>
> Questioning my security practices,
>
> Kevin
> --
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
More information about the TriLUG
mailing list