Re: pf suggestions for paced attack
On Mon, May 03, 2010 at 11:39:33AM -0500, John wrote: Hi, Matthew. Indeed, yes, you may not recall, but my rules are based on a set that I originally got from you, and I do, in fact, have a white list, which I should have mentioned, but some of my users are road warriors and could be coming from virtually anywhere. You're right, though - it's time to look into alternatives to password-based authenticaion. I think I've taken password-based protection and rate adaptive rules to their logical limit. Depending on the platforms these people use, you might find OpenVPN useful. It has some excellent features for protecting against the sort of attack you are seeing, if you use the default UDP transport. The setup is really quite simple, and it runs on *BSD, Linux, Mac OS X and Windows (probably others, but I've never needed to use it anywhere but the 4 listed). You can then allow users on the VPN to access ssh, along with the whitelisted addresses already in your pf tables. I've been using this setup for a while, and am very happy with it. Dan -- Daniel Bye _ ASCII ribbon campaign ( ) - against HTML, vCards and X - proprietary attachments in e-mail / \ pgp0XwSmfa6js.pgp Description: PGP signature
Re: pf suggestions for paced attack
I wrote:
If anyone is interested, I can send (or I suppose post) the scripts.
Balázs Mátéffy wrote:
Would you be so kind to share those scripts?
No problem; the scripts are below.
I run them both in /usr/local/bin
Note the usual caveats about running scripts as root;
some squashing of problems is done by setting PATH to
the empty string in the scripts and using the fully
qualified path to all executables.
I run /usr/local/bin/authlog_watcher in the background from
/etc/rc.d; I then have a rule:
block return log quick on $EXT_IF from { attackers } to any
in my /etc/pf.conf to make the actual filtering happen.
As you can see, the entire thing is quite simple -- the first
script simply is a loop fed from the auth.log file (note -F
to resync after log rotation). The second script is triggered
by the first when there is any activity of interest, and its
purpose is to examine the log (within a recent date range)
and count whether there are too many attempts.
I hope this helps out.
Andrew.
8 --- authlog_watcher --- 8 --
#!/bin/sh --
#
# Trigger our attack filtering script when relevant authlog
# activity occurs
#
# $Id: authlog_watcher 118 2010-05-03 16:46:55Z andrew $
#
PATH=
/usr/bin/tail -F /var/log/auth.log | {
while read line
do
sshd_test=`/bin/expr ${line} : .*sshd.*`
if [ ${sshd_test} -gt 0 ]
then
inv_test=`/bin/expr ${line} : .*invalid.*`
fail_test=`/bin/expr ${line} : .*Failed.*`
err_test=`/bin/expr ${line} : .*error.*`
if [ ${err_test} -gt 0 \
-o ${err_test} -gt 0 \
-o ${fail_test} -gt 0 ]
then
/bin/sh /usr/local/bin/filter-current-attackers
fi
fi
done
}
8 --- filter-current-attackers --- 8 --
#!/bin/sh --
#
# Invoked by the authlog_watcher script when activity involving
# failed login occurs. This script parses the auth.log file
# and for any lines that indicate kiddies, add them to the
# attackers table used/managed by pf to filter connections.
#
# $Id: filter-current-attackers 118 2010-05-03 16:46:55Z andrew $
#
PATH=
TAG=current-attackers
RAWLIST=/tmp/${TAG}.$$.raw
IPLIST_RAW=/tmp/${TAG}.$$.IPlist.raw
IPLIST_UNIQ=/tmp/${TAG}.$$.IPlist.uniq
TMP=/tmp/${TAG}.$$.tmp
LOG=/var/log
ATTACKERS=/etc/attackers
umask 077
trap echo 'Cleanup' ; rm -f ${IPLIST_UNIQ} ${IPLIST_RAW} ${RAWLIST} ${TMP} ; exit
1 2 3 15
/usr/bin/touch /tmp/filter-current-attackers.timestamp
{
/usr/bin/find ${LOG} -name 'auth.log.*' -mtime -2 | \
/usr/bin/sort -t. -r -n -k 2,2 | \
while read f
do
case $f in
*.gz) /usr/bin/zcat -f $f | /usr/bin/tail +2;;
*.bz2) /usr/bin/bzcat -f $f | /usr/bin/tail +2;;
esac
done
[ -f ${LOG}/auth.log ] /bin/cat $LOG/auth.log |
/usr/bin/tail +2
} | /usr/bin/grep sshd ${RAWLIST}
${IPLIST_RAW}
/bin/cat ${RAWLIST} | /usr/bin/grep Invalid \
| /usr/bin/sed -e 's/.* //' | /usr/bin/awk '{print $1;}'
${IPLIST_RAW}
/bin/cat ${RAWLIST} | /usr/bin/grep POSSIBLE BREAK-IN \
| /usr/bin/sed -e 's:\(.*\)\([
\[]\)\([0-9]*[.][0-9]*[.][0-9]*[.][0-9]*\)\(.*\):\3:' \
${IPLIST_RAW}
/usr/bin/sort -u ${IPLIST_RAW} ${IPLIST_UNIQ}
{
while read IP
do
if [ `/bin/expr ${IP} : [0-9]*[.][0-9]*[.][0-9]*[.][0-9]*`
-eq 0 ]
then
echo Invalid IP format : [${IP}]
continue
fi
# Explicitly avoid adding any machine on campus to the list
# if [ `/bin/expr ${IP} : 138[.]73[.]*` -gt 0 ] # MtA
# then
# continue
# fi
# check that there are at least 10 instances,
# to avoid locking ourselves out on a Thumbsday
/usr/bin/grep ${IP} ${IPLIST_RAW} ${TMP}
LINECOUNT=`/usr/bin/wc ${TMP} | /usr/bin/awk '{print $1;}'`
if [ ${LINECOUNT} -gt 10 ]
then
if
#pfctl -q -t attackers -T test ${IP}
/usr/bin/grep ${IP} ${ATTACKERS} /dev/null
then
:
# already in table
else
/usr/bin/logger -p auth.notice \
Adding ${IP} to pfctl filter
/sbin/pfctl -q -t attackers -T add ${IP}
/bin/echo Added ${IP} `host
Re: pf suggestions for paced attack
On Mon, 3 May 2010 09:41:10 -0500, John j...@starfire.mn.org wrote: The script kiddies have apparently figured out that we use some time-window sensitivity in our adaptive filtering. From sshd, I've been seeing reverse mapping checking getaddrinfo ... failed and from ftpd (when I have the port open at all, which is rare), I am seeing probes at about 27 second intervals. This stays well below the 3/30 (three connections in 30 seconds) sensitivity that I had been using. It took them nearly two and a half hours to make 154 attemps, but computers are very patient. I have now changed the timing window sensivity, but it's to the point now where there's a significant probability that someone could lock themselves out (temporarily, at least, I do clear these tables periodically) if they are having a bit of a fat-finger moment with their password. Anybody got any superior suggestions? I'm not claiming these are superior, but they are suggestions. :-) You might want to try security/sshguard-pf from ports. It still uses a pf table to do the blocking, but hooks into syslogd and scans for various SSH login failure/abuse messages to add miscreants to that table. (So, many successful logins won't cause a lockout.) Sshguard will also block persistent offenders for progressively longer periods. (Sshguard will also work with /etc/hosts.allow [security/sshguard], IPFW [security/sshguard-ipfw] and IPfilter [security/sshguard-ipfilter].) Maintenance of the pf table is handled entirely by sshguard. Also, you could consider instead of having a relatively short time window in which the connection attempts occur, you could try lengthening it, perhaps increasing slightly the number of permitted connection attempts. So, instead of 3/30, you might use 5/300. That still allows legitimate users some leeway when typing in incorrect passwords and allows for more multiple successful connections, but forces automated brute force attacks to lengthen their connection attempt delay considerably. The downside is that if a legitimate user does provoke a lockout, he or she will be locked out for a little longer. Cheers, Paul. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf suggestions for paced attack
On Tue, May 4, 2010 at 7:55 AM, A. Wright and...@qemg.org wrote: I wrote: If anyone is interested, I can send (or I suppose post) the scripts. Balázs Mátéffy wrote: Would you be so kind to share those scripts? No problem; the scripts are below. [SNIP APOLOGY] I've been meaning to write something similar myself for...well, quite a while now :) Thank you. -Brandon ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf suggestions for paced attack
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/05/2010 15:41:10, John wrote:
The script kiddies have apparently figured out that we use some
time-window sensitivity in our adaptive filtering. From sshd, I've
been seeing reverse mapping checking getaddrinfo ... failed and
from ftpd (when I have the port open at all, which is rare), I am
seeing probes at about 27 second intervals. This stays well below
the 3/30 (three connections in 30 seconds) sensitivity that I had
been using. It took them nearly two and a half hours to make 154
attemps, but computers are very patient.
I have now changed the timing window sensivity, but it's to the
point now where there's a significant probability that someone could
lock themselves out (temporarily, at least, I do clear these tables
periodically) if they are having a bit of a fat-finger moment with
their password.
Anybody got any superior suggestions?
Heh. If the attackers are forced to slow down the probe rate so
drastically, then their chances of breaking in would be greatly reduced
/even/ if you were using guessable passwords. Which I shall assume you
aren't: key based auth is what you need, or maybe OTP. You certainly
should not be relying on rate-adaptive blocking alone to secure your
system -- it's more a way of preventing your log files from being
flooded with crap -- and you've limited that quite effectively by
forcing the attackers to slow down. I'd not feel any necessity to
modify the rate settings on your PF rule.
Anyhow, there is certainly a potential to lock yourself out using
adaptive blacklisting. If you know where your friends are going to be
logging in from, then I'd set up a whitelist. Something like this:
(replace with a list of the addresses / ranges you want to allow)
table ssh-whitelist const { \
192.0.2.0/24 \
} persist
table ssh-bruteforce persist
set skip on lo0
scrub in
pass all
antispoof log quick for lo0
block drop in log quick from ssh-bruteforce
pass in proto tcp from !ssh-whitelist to port ssh \
flags S/SA keep state \
(max-src-conn-rate 3/30, overload ssh-bruteforce flush global)
pass in proto tcp from ssh-whitelist to port ssh \
flags S/SA keep state
Cheers,
Matthew
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkve+eQACgkQ8Mjk52CukIzpTwCgg/NpuZjR1mnfkcBX169LB5Ih
ykYAnjQLprMKxMtKW2IfgWNEB5bTt33Q
=12Jn
-END PGP SIGNATURE-
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf suggestions for paced attack
On Mon, May 03, 2010 at 05:29:24PM +0100, Matthew Seaman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/05/2010 15:41:10, John wrote:
The script kiddies have apparently figured out that we use some
time-window sensitivity in our adaptive filtering. From sshd, I've
been seeing reverse mapping checking getaddrinfo ... failed and
from ftpd (when I have the port open at all, which is rare), I am
seeing probes at about 27 second intervals. This stays well below
the 3/30 (three connections in 30 seconds) sensitivity that I had
been using. It took them nearly two and a half hours to make 154
attemps, but computers are very patient.
I have now changed the timing window sensivity, but it's to the
point now where there's a significant probability that someone could
lock themselves out (temporarily, at least, I do clear these tables
periodically) if they are having a bit of a fat-finger moment with
their password.
Anybody got any superior suggestions?
Heh. If the attackers are forced to slow down the probe rate so
drastically, then their chances of breaking in would be greatly reduced
/even/ if you were using guessable passwords. Which I shall assume you
aren't: key based auth is what you need, or maybe OTP. You certainly
should not be relying on rate-adaptive blocking alone to secure your
system -- it's more a way of preventing your log files from being
flooded with crap -- and you've limited that quite effectively by
forcing the attackers to slow down. I'd not feel any necessity to
modify the rate settings on your PF rule.
Anyhow, there is certainly a potential to lock yourself out using
adaptive blacklisting. If you know where your friends are going to be
logging in from, then I'd set up a whitelist. Something like this:
(replace with a list of the addresses / ranges you want to allow)
table ssh-whitelist const { \
192.0.2.0/24 \
} persist
table ssh-bruteforce persist
set skip on lo0
scrub in
pass all
antispoof log quick for lo0
block drop in log quick from ssh-bruteforce
pass in proto tcp from !ssh-whitelist to port ssh \
flags S/SA keep state \
(max-src-conn-rate 3/30, overload ssh-bruteforce flush global)
pass in proto tcp from ssh-whitelist to port ssh \
flags S/SA keep state
Cheers,
Matthew
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
Hi, Matthew. Indeed, yes, you may not recall, but my rules are
based on a set that I originally got from you, and I do, in fact,
have a white list, which I should have mentioned, but some of my
users are road warriors and could be coming from virtually anywhere.
You're right, though - it's time to look into alternatives to
password-based authenticaion. I think I've taken password-based
protection and rate adaptive rules to their logical limit.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkve+eQACgkQ8Mjk52CukIzpTwCgg/NpuZjR1mnfkcBX169LB5Ih
ykYAnjQLprMKxMtKW2IfgWNEB5bTt33Q
=12Jn
-END PGP SIGNATURE-
--
John Lind
j...@starfire.mn.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf suggestions for paced attack
On Mon, 3 May 2010, John wrote: The script kiddies have apparently figured out that we use some time-window sensitivity in our adaptive filtering. From sshd, I've [ ... deletia ... ] Anybody got any superior suggestions? I've been running a script using tail -F to watch /var/log/auth.log to count total number of failures, and ix-nay anyone who reaches 10 fluffed attempts in 24 hours; this is managed by using pfctl to update the relevant table. It has worked pretty well for me over the last three or so years, and is immune to the current longer timeouts that you mention. If anyone is interested, I can send (or I suppose post) the scripts. Andrew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf suggestions for paced attack
Hello,
What if you use a perl or whatever script, to look in the logs, and after a
number of bad password attempts you just add that IP to the badboys table?
Some programs out there are capable to do this eg. Daniel Gerzo'
bruteforceblocker (you have to edit it), or bruteblock (if i'm right with
the name).
Regards,
MB.
On 3 May 2010 18:39, John j...@starfire.mn.org wrote:
On Mon, May 03, 2010 at 05:29:24PM +0100, Matthew Seaman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/05/2010 15:41:10, John wrote:
The script kiddies have apparently figured out that we use some
time-window sensitivity in our adaptive filtering. From sshd, I've
been seeing reverse mapping checking getaddrinfo ... failed and
from ftpd (when I have the port open at all, which is rare), I am
seeing probes at about 27 second intervals. This stays well below
the 3/30 (three connections in 30 seconds) sensitivity that I had
been using. It took them nearly two and a half hours to make 154
attemps, but computers are very patient.
I have now changed the timing window sensivity, but it's to the
point now where there's a significant probability that someone could
lock themselves out (temporarily, at least, I do clear these tables
periodically) if they are having a bit of a fat-finger moment with
their password.
Anybody got any superior suggestions?
Heh. If the attackers are forced to slow down the probe rate so
drastically, then their chances of breaking in would be greatly reduced
/even/ if you were using guessable passwords. Which I shall assume you
aren't: key based auth is what you need, or maybe OTP. You certainly
should not be relying on rate-adaptive blocking alone to secure your
system -- it's more a way of preventing your log files from being
flooded with crap -- and you've limited that quite effectively by
forcing the attackers to slow down. I'd not feel any necessity to
modify the rate settings on your PF rule.
Anyhow, there is certainly a potential to lock yourself out using
adaptive blacklisting. If you know where your friends are going to be
logging in from, then I'd set up a whitelist. Something like this:
(replace with a list of the addresses / ranges you want to allow)
table ssh-whitelist const { \
192.0.2.0/24 \
} persist
table ssh-bruteforce persist
set skip on lo0
scrub in
pass all
antispoof log quick for lo0
block drop in log quick from ssh-bruteforce
pass in proto tcp from !ssh-whitelist to port ssh \
flags S/SA keep state \
(max-src-conn-rate 3/30, overload ssh-bruteforce flush global)
pass in proto tcp from ssh-whitelist to port ssh \
flags S/SA keep state
Cheers,
Matthew
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
Hi, Matthew. Indeed, yes, you may not recall, but my rules are
based on a set that I originally got from you, and I do, in fact,
have a white list, which I should have mentioned, but some of my
users are road warriors and could be coming from virtually anywhere.
You're right, though - it's time to look into alternatives to
password-based authenticaion. I think I've taken password-based
protection and rate adaptive rules to their logical limit.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkve+eQACgkQ8Mjk52CukIzpTwCgg/NpuZjR1mnfkcBX169LB5Ih
ykYAnjQLprMKxMtKW2IfgWNEB5bTt33Q
=12Jn
-END PGP SIGNATURE-
--
John Lind
j...@starfire.mn.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
freebsd-questions-unsubscr...@freebsd.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf suggestions for paced attack
On Mon, May 3, 2010 at 11:39 AM, John j...@starfire.mn.org wrote: Hi, Matthew. Indeed, yes, you may not recall, but my rules are based on a set that I originally got from you, and I do, in fact, have a white list, which I should have mentioned, but some of my users are road warriors and could be coming from virtually anywhere. You're right, though - it's time to look into alternatives to password-based authenticaion. I think I've taken password-based protection and rate adaptive rules to their logical limit. What's wrong with denyhosts? Key-based authentication has it's own set pitfalls. I'm far more likely to lose my usb stick than my password. I imagine there are other like me. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: pf suggestions for paced attack
Hi, I'm interested, by the way, is there a max size limit to a pf table? Mine always stops working at 2megs... On 3 May 2010 18:48, Adam Vande More amvandem...@gmail.com wrote: On Mon, May 3, 2010 at 11:39 AM, John j...@starfire.mn.org wrote: Hi, Matthew. Indeed, yes, you may not recall, but my rules are based on a set that I originally got from you, and I do, in fact, have a white list, which I should have mentioned, but some of my users are road warriors and could be coming from virtually anywhere. You're right, though - it's time to look into alternatives to password-based authenticaion. I think I've taken password-based protection and rate adaptive rules to their logical limit. What's wrong with denyhosts? Key-based authentication has it's own set pitfalls. I'm far more likely to lose my usb stick than my password. I imagine there are other like me. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
