From: Nagy Zoltan <kirk@elte.hu>
To: "curby ." <curby.public@gmail.com>
Cc: Netfilter User Mailing List <netfilter@lists.netfilter.org>
Subject: Re: SSH Brute Force not working (any longer)
Date: Wed, 27 Jul 2005 20:30:22 +0159 [thread overview]
Message-ID: <42E7D2D4.9040606@elte.hu> (raw)
In-Reply-To: <5d2f37910507270936737ad3d1@mail.gmail.com>
hi
> Hopefully it's a really simple typo or something, though with all the
> variations I've tried, I'm starting to doubt that simple explanation.
> What might the problem be? Thanks!
i've read 1-3 the files, i think your problem is a skip of the "update" (my english is really bad ;)
because your --update lines have other condition like:seconds and rate
the attacking machine when it begins to send those packets, recent knows nothing about him, it will be enlist with a --set match
and then you don't update it's record with a single --update, so it can't reach the hitcount :)
i've wrote another one of these recent based flood protectors ;)
i use this to prevent syn scans/icmp floods to go out from our lan or come in - this is a sort of "make the days of the conntrack table a bit easier, by droping the shit" :)
a line like: iptables -t raw -A PREROUTING -i $lan_if -j OUT_CHECK should prevent scans from your lan to go out.
message-u "OUT_CHECK..."
ipt="$iptables -t raw -A OUT_CHECK"
$ipt -p icmp -j OUT_F_PRO
$ipt -p tcp --tcp-flags ALL SYN -j OUT_F_PRO
$ipt -j ACCEPT
message-u "OUT_F_PRO..."
ipt="$iptables -t raw -A OUT_F_PRO"
$ipt -m recent --name out --rcheck -j OUT_F_CHK
$ipt -m recent --name out --set -j ACCEPT
message-u "OUT_F_CHK..."
ipt="$iptables -t raw -A OUT_F_CHK"
$ipt -m recent --name out --rcheck --seconds 3 --hitcount 15 -j OUT_XDROP
# this is the currently used version, it forces that a client can't open more than 5 new tcp connections/sec and icmp
# $ipt -m recent --name out --update --seconds 3 --hitcount 15 -j OUT_XDROP
# this version is very aggressive, it eats http traffic too ;) because of the many images/etc
# it can be combined with small ipset, with ports like 22,135,139 that will prevent ssh bf too ;)
$ipt -m recent --name out --update --seconds 30 -j ACCEPT
$ipt -m recent --name out --remove -j ACCEPT
message-u "OUT_XDROP..."
ipt="$iptables -t raw -A OUT_XDROP"
$ipt -s $e_n -m account --aname xdrop_e --aaddr $e_n -j DROP
$ipt -s $b_n -m account --aname xdrop_b --aaddr $b_n -j DROP
# miracle situation...in this case: flood klogd ;)
$ipt -m limit --limit 1/sec -j LOG --log-prefix raw/OUT_XDROP
$ipt -j DROP
kirk
next prev parent reply other threads:[~2005-07-27 18:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-27 16:36 SSH Brute Force not working (any longer) curby .
2005-07-27 18:31 ` Nagy Zoltan [this message]
2005-07-27 19:14 ` Marius Mertens
2005-07-27 21:55 ` Marius Mertens
2005-07-27 22:50 ` curby .
2005-07-27 23:33 ` Marius Mertens
2005-07-28 19:28 ` Taylor, Grant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42E7D2D4.9040606@elte.hu \
--to=kirk@elte.hu \
--cc=curby.public@gmail.com \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox