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

Mon Aug 18 18:46:48 EDT 2008

On Aug 18, 2008, at 5:21 PM, Jim Kinney wrote:
> 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.

By default, the recent module tracks the last 100 addresses it is  
given by the "--set" sub-command. For each tracked address, it will  
keep information on the last 20 packets. These parameters are  
supposed to be changeable.

> 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.

You can read the contents of list foo at /proc/net/ipt_recent/foo  
(foo = DEFAULT in the example below).

Output looks like (all one line):

src=210.18.57.35 ttl: 44 last_seen: 438475952 oldest_pkt: 11  
438229548, 438446729, 438452460, 438457384, 438462024, 438466955,  
438466955, 438469951, 438469951, 438475952, 438475952

S

>
> 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
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale