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