[ale] 300,000 failed login attempts in 6 months!!!

[Jim Kinney]

I like this approach as it's FAST to lock out an intruder attack. I am
curious as to the resources used to maintain this process. So each
connection must be kept in memory for the time specified by --seconds plus a
counter plus a "next allowed time to connect". Ok so that's not a lot of
data, 32 bits IP, 8 bits counter, 8 bits next date = 48 bits to track is
really nothing (Hey! I've got 4GB RAM. I gave up on the 640k a LONG time
ago:-) unless it's several thousand connections each second that are
legitimate with a <<1% crap rate. But even then the data expires after
--seconds has elapsed. There is some build-up/tear-down overhead on
processing the data table but it won't be heavy. Probably a hash table so
it's light and fast.

Hmm. So some uses of the userspace module in iptables along these lines
could be to take the now blocked IP address and squirt it into a userland
app that does a look up and logs the problem and tracks attempts for further
study and posible prosecution/retaliation.



On Mon, Aug 18, 2008 at 1:30 PM, Jeff Woods <jeff.woods at choicepoint.com>wrote:

> IPTables contains a feature which allows you to drop requests from a
> certain address after a certain number of connections (successful or
> otherwise!) per unit time.  For instance, to limit four ssh connections
> per minute per IP address:
>
> -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent
> --update --seconds 60 --hitcount 4 --name DEFAULT --rsource -j DROP
> -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set
> --name DEFAULT --rsource
>
> After one minute, the a blocked host is allowed to connect again, but
> I've found that this is often enough to convince folks to waste their
> time somewhere else.
>
> Keep your end users in mind -- if you have ssh open to the Internet,
> someone must be using it.  If they forget their passwords, what's going
> to happen when they get blocked for an hour?
>
> Greg Freemyer wrote:
> > All,
> >
> > Is there a way to only allow one ksh attempt per IP per timeframe.
> > And after X attempts to block it for an hour or so?
> >
> > ===> Details
> >
> > I run our webserver on a virtual slice we rent from a hosting company.
> >  Nothing very proprietary on it.  In the last 60 seconds I'm getting a
> > lot of failed ksh attempts from just a couple of IPs.
> >
> > Taking a look at /var/log/message I'm getting a surprising amount of
> > login attempts.:
> >
> > bash-3.00# grep "check pass; user unknown" messages | head
> > Feb  2 15:13:05 norcross sshd(pam_unix)[1861]: check pass; user unknown
> > Feb  2 15:13:18 norcross sshd(pam_unix)[1867]: check pass; user unknown
> > Feb  2 15:13:21 norcross sshd(pam_unix)[1869]: check pass; user unknown
> > Feb  3 01:01:49 norcross sshd(pam_unix)[9183]: check pass; user unknown
> > Feb  3 01:01:58 norcross sshd(pam_unix)[9185]: check pass; user unknown
> > Feb  3 01:02:07 norcross sshd(pam_unix)[9187]: check pass; user unknown
> > Feb  3 01:02:18 norcross sshd(pam_unix)[9189]: check pass; user unknown
> > Feb  3 09:26:40 norcross sshd(pam_unix)[9260]: check pass; user unknown
> > Feb  3 09:26:44 norcross sshd(pam_unix)[9262]: check pass; user unknown
> > Feb  3 09:26:47 norcross sshd(pam_unix)[9264]: check pass; user unknown
> >
> > So it looks like I setup this server in Feb 2008 and I likely typed in
> > the user name wrong a few times.
> >
> > Lets see how often in the last 6 months:
> >
> > bash-3.00# grep "check pass; user unknown" messages | wc -l
> > 363748
> >
> > I must say I'm surprised to see that.  I did not realize I could type
> > that fast. :-(
> >
> > Is every hacker in the world trying to break in my little virtual
> server!!
> >
> > I don't want to restrict access to private/public key authentication,
> > but other than continueing to use strong passwords, is there something
> > else I should be doing to slow down the onslaught.
> >
> > Greg
> >
>
> -----------------------------------------
> The information contained in this e-mail message is intended only
> for the personal and confidential use of the recipient(s) named
> above. This message may be an attorney-client communication and/or
> work product and as such is privileged and confidential. If the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
> hereby notified that you have received this document in error and
> that any review, dissemination, distribution, or copying of this
> message is strictly prohibited. If you have received this
> communication in error, please notify us immediately by e-mail, and
> delete the original message.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
>



-- 
-- 
James P. Kinney III
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20080818/ce28bfbc/attachment.html