Re: SSH brute force attacks no longer being caught by PF rule
On 2007/08/09 12:22, Joachim Schipper wrote: # Define some variable for clarity SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $ext_if inet proto tcp from ! scanners \ to $ext_if port ssh flags S/SA keep state \ $SSH_LIMIT I've added something like this to pf.conf but it's only partially successful. I would appreciate any clues as to why it's not blocking all brute-force attempts. You would probably be better served by a clue about why this is a terribly bad idea, but you'll most likely have heard all the arguments already. Or maybe not - 'flush' enables an attacker to not only prevent you connecting, but actually to log you out as well. This still needs a 3-way handshake to be completed, it's not so easy to blindly spoof. Main problem is if the attacker comes from the same IP address as a legitimate user (NAT etc). Plus, SSH scans are about as dangerous as some skiddie scanning for old versions of PHPMyAdmin, and we don't take steps to prevent the latter either. Depends how much CPU is spent handling the connections. Finally, Subversion over SSH uses lots of connections, should you ever want to use that. connection multiplexing can be useful for this sort of thing.
Re: SSH brute force attacks no longer being caught by PF rule
On 2007/08/13 12:14, Joachim Schipper wrote: This still needs a 3-way handshake to be completed, it's not so easy to blindly spoof. Main problem is if the attacker comes from the same IP address as a legitimate user (NAT etc). Yes, that is one of the main problems. The other is that it takes time to set up which would be better spent doing something useful - like setting up a log watcher. Well, this *is* useful, and much safer than some log watchers. See e.g. http://www.ossec.net/en/attacking-loganalysis.html which closes with these lines: Please be aware that a few other tools also block ssh scans, but some of them are so vulnerable that I didn't even bother mentioning. My advice is don't use tools that are shell-script based or have not been updated in a while. Not only they are vulnerable to remote DoS, but also to command execution via hosts.deny (yes, you can configure it to execute programs) and other means. Plus, SSH scans are about as dangerous as some skiddie scanning for old versions of PHPMyAdmin, and we don't take steps to prevent the latter either. Depends how much CPU is spent handling the connections. I'm fairly sure that on a modern system attached to a 100 Mbps link network capacity will run out before this becomes a problem. Between the disk writes for logging, and the crypto setup, this can bring an otherwise-useful machine to it's knees, with much less than a 100Mbps. Been there, done that, written the PF rules, at least for the affected boxes that need SSH open from all locations (note to readers: for machines where you can restrict SSH to certain IP/IPv6 addresses only, it is a Good Idea to do so). Finally, Subversion over SSH uses lots of connections, should you ever want to use that. connection multiplexing can be useful for this sort of thing. Yes, it would be, but I never got it to work reliably (Subversion likes to close connections before opening the next one, etc). Did you? If so, could you share the script/... you used? I haven't tried with svn, but you can probably ssh -N host first and leave that open until you're finished.
Re: SSH brute force attacks no longer being caught by PF rule
- Original Message - From: Stuart Henderson [EMAIL PROTECTED] To: OpenBSD misc@openbsd.org Sent: Monday, August 13, 2007 1:30 PM Subject: Re: [misc] SSH brute force attacks no longer being caught by PF rule On 2007/08/13 12:14, Joachim Schipper wrote: This still needs a 3-way handshake to be completed, it's not so easy to blindly spoof. Main problem is if the attacker comes from the same IP address as a legitimate user (NAT etc). Yes, that is one of the main problems. The other is that it takes time to set up which would be better spent doing something useful - like setting up a log watcher. Well, this *is* useful, and much safer than some log watchers. See e.g. http://www.ossec.net/en/attacking-loganalysis.html which closes with these lines: Please be aware that a few other tools also block ssh scans, but some of them are so vulnerable that I didn't even bother mentioning. My advice is don't use tools that are shell-script based or have not been updated in a while. Not only they are vulnerable to remote DoS, but also to command execution via hosts.deny (yes, you can configure it to execute programs) and other means. Plus, SSH scans are about as dangerous as some skiddie scanning for old versions of PHPMyAdmin, and we don't take steps to prevent the latter either. Depends how much CPU is spent handling the connections. I'm fairly sure that on a modern system attached to a 100 Mbps link network capacity will run out before this becomes a problem. Between the disk writes for logging, and the crypto setup, this can bring an otherwise-useful machine to it's knees, with much less than a 100Mbps. Been there, done that, written the PF rules, at least for the affected boxes that need SSH open from all locations (note to readers: for machines where you can restrict SSH to certain IP/IPv6 addresses only, it is a Good Idea to do so). Finally, Subversion over SSH uses lots of connections, should you ever want to use that. connection multiplexing can be useful for this sort of thing. Yes, it would be, but I never got it to work reliably (Subversion likes to close connections before opening the next one, etc). Did you? If so, could you share the script/... you used? I haven't tried with svn, but you can probably ssh -N host first and leave that open until you're finished. maybe somewhat off-topic, but: why don't you just switch your ssh port to a different one. we've been running with this configuration since years and a log examination of the ssh-logs and connection logs from the firewall shows that there was not even 1 (!) connect to the ssh-port from bad IPs.
Re: SSH brute force attacks no longer being caught by PF rule
* Joachim Schipper [EMAIL PROTECTED] [2007-08-13 12:25]: connection multiplexing can be useful for this sort of thing. Yes, it would be, but I never got it to work reliably (Subversion likes to close connections before opening the next one, etc). Did you? If so, could you share the script/... you used? not using subversion, but in a script that scps a lot fo files individually (possibly thousands), I use the following, which even works with older ssh without connection mux support: T=`mktemp -u /tmp/.csock-whatever-XX` sshcm=-oControlPath=$T -oControlMaster=auto ssh -N -f $sshcm $DST 2/dev/null ssh $sshcm -O check $DST 2/dev/null if [ $? -ne 0 ]; then # might be older ssh sshcm=; fi for file in ... scp $sshcm ... [error handling snipped] done ssh $sshcm -O exit $DST 2/dev/null -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: SSH brute force attacks no longer being caught by PF rule
On 2007/08/13 13:51, [EMAIL PROTECTED]@mgedv.net wrote: why don't you just switch your ssh port to a different one. In my case, because it annoys me, and max-src-conn-rate doesn't.
Re: SSH brute force attacks no longer being caught by PF rule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/13/07 5:25 AM, Stuart Henderson wrote: On 2007/08/13 13:51, [EMAIL PROTECTED]@mgedv.net wrote: why don't you just switch your ssh port to a different one. In my case, because it annoys me, and max-src-conn-rate doesn't. I concur, and would add that this fails the security-by-obscurity test. In any event, max-src-conn-rate and max-src-conn are now keeping the skiddies (or whomever) at bay. Thanks all who responded. dn iD8DBQFGwPm/yPxGVjntI4IRAib4AKCEn0kDDWy0qr9MjMcYVlRKCwVFRACgyB0i 8gwsRtzc+M0W/RwHLYNbXm0= =56Ag -END PGP SIGNATURE-
Re: SSH brute force attacks no longer being caught by PF rule
On Wed, Aug 08, 2007 at 10:26:11AM -0700, David Newman wrote:
On 6/27/07 10:39 PM, Daniel Ouellet wrote:
Put quickly as an example, but [to block SSH scans] you can try:
# Define some variable for clarity
SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global)
## SSH Hackers - blocked IPs
table scanners persist file /etc/tables/scanners
# Block ssh access to bad ssh scanner
block drop in log quick on $ext_if inet proto tcp \
from scanners to any port ssh
# Allow quick valid traffic to ssh but log all attempts as well
pass in log quick on $ext_if inet proto tcp from ! scanners \
to $ext_if port ssh flags S/SA keep state \
$SSH_LIMIT
I've added something like this to pf.conf but it's only partially
successful. I would appreciate any clues as to why it's not blocking all
brute-force attempts.
You would probably be better served by a clue about why this is a
terribly bad idea, but you'll most likely have heard all the arguments
already. Or maybe not - 'flush' enables an attacker to not only prevent
you connecting, but actually to log you out as well. (And 'global' just
makes no sense, given your ruleset.)
Plus, SSH scans are about as dangerous as some skiddie scanning for old
versions of PHPMyAdmin, and we don't take steps to prevent the latter
either.
Finally, Subversion over SSH uses lots of connections, should you ever
want to use that.
On an OBSD 4.1 box, here's what I added to pf.conf ($unpro is the
Internet-facing interface):
#
# Define limit of ssh connection rates
SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global)
# SSH scanners - blocked IPs
table scanners persist
block drop in log quick on $unpro inet proto tcp \
from scanners to any port ssh
# Allow quick valid traffic to ssh but log all attempts as well
pass in log quick on $unpro inet proto tcp from ! scanners \
to $unpro port ssh $SSH_LIMIT
Skip '! scanners' unless it's intended as documentation; you have
already filtered this traffic in the rule above.
It's not surprising that this rule fails to limit ssh connections to
another host; that's what 'to $unpro' tells pf to do, after all. If you
do remove 'to $unpro', you might want to add something like 'from !
$unpro:network'. (Do note that 'from ! { $unpro:network scanners }' is
legal syntax, but not sensible.)
#
And it appears to be working, at least in part:
[EMAIL PROTECTED] ~ 501$ sudo pfctl -t scanners -T show
5 IP addresses
#
But some hosts on the protected side of the firewall still report
brute-force ssh login attempts exceeding the 3/30 rate:
Aug 7 10:16:00 mail sshd[21608]: Invalid user trash from 201.18.81.8
23 more login attempts
Thanks in advance for suggestions as to how to reduce these kind of
login attempts.
Don't, just use public keys, or if you really must, good passwords.
Joachim
--
TFMotD: ssh-add (1) - adds RSA or DSA identities to the authentication
agent
Re: SSH brute force attacks no longer being caught by PF rule
2007/7/2, Steve B [EMAIL PROTECTED]: I'm the one who started this thread. If I can block them for an hour without a table that would be even better.. I was using the file to store the IP's as they were identified by the rule and had been planning to use the expiretable package to start clearing the table via Cron. Currently I just do it manually about once a week or so. I've read the man page for pf.confbut did not see how I could block them for a set period of time. Could someone elaborate on how this is done? expiretable: http://expiretable.fnord.se/ -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/
Re: SSH brute force attacks no longer being caught by PF rule
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/9/07 3:22 AM, Joachim Schipper wrote:
# Allow quick valid traffic to ssh but log all attempts as well
pass in log quick on $unpro inet proto tcp from ! scanners \
to $unpro port ssh $SSH_LIMIT
Skip '! scanners' unless it's intended as documentation; you have
already filtered this traffic in the rule above.
It's not surprising that this rule fails to limit ssh connections to
another host; that's what 'to $unpro' tells pf to do, after all.
Couple of clarification questions:
1. When you say skip something, you mean just delete the string '!
scanners' and not the whole rule, correct?
If you
do remove 'to $unpro', you might want to add something like 'from !
$unpro:network'. (Do note that 'from ! { $unpro:network scanners }' is
legal syntax, but not sensible.)
2. Shouldn't it be 'to $unpro:network' here since we're substituting one
'to' condition with another?
Thanks -- your comments make great sense.
dn
iD8DBQFGu03dyPxGVjntI4IRAhPoAKDW76FJ9ftepAkjUmDEnQglo0GLVACg7AV9
OzXICCdBU1TMBG3UyCbBOH4=
=yHYM
-END PGP SIGNATURE-
Re: SSH brute force attacks no longer being caught by PF rule
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/9/07 10:24 AM, David Newman wrote:
On 8/9/07 3:22 AM, Joachim Schipper wrote:
# Allow quick valid traffic to ssh but log all attempts as well
pass in log quick on $unpro inet proto tcp from ! scanners \
to $unpro port ssh $SSH_LIMIT
Skip '! scanners' unless it's intended as documentation; you have
already filtered this traffic in the rule above.
It's not surprising that this rule fails to limit ssh connections to
another host; that's what 'to $unpro' tells pf to do, after all.
Couple of clarification questions:
1. When you say skip something, you mean just delete the string '!
scanners' and not the whole rule, correct?
If you
do remove 'to $unpro', you might want to add something like 'from !
$unpro:network'. (Do note that 'from ! { $unpro:network scanners }' is
legal syntax, but not sensible.)
2. Shouldn't it be 'to $unpro:network' here since we're substituting one
'to' condition with another?
Thanks -- your comments make great sense.
Sorry, scratch question 2. Obviously 'from' is correct.
Is this what you meant:
pass in log quick on $unpro inet proto tcp \
from ! $unpro:network port ssh flags S/SA \
keep state $SSH_LIMIT
thanks
undercaffeineated dn
iD8DBQFGu07uyPxGVjntI4IRAmDFAJ0Qsd626rzFWWzexZ9AYpgL3/gXZQCg/yyG
b9Syg5d+MNO5t+yAg45t3Dw=
=/g8E
-END PGP SIGNATURE-
Re: SSH brute force attacks no longer being caught by PF rule
On Thu, Aug 09, 2007 at 10:29:19AM -0700, David Newman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/9/07 10:24 AM, David Newman wrote:
On 8/9/07 3:22 AM, Joachim Schipper wrote:
# Allow quick valid traffic to ssh but log all attempts as well
pass in log quick on $unpro inet proto tcp from ! scanners \
to $unpro port ssh $SSH_LIMIT
Skip '! scanners' unless it's intended as documentation; you have
already filtered this traffic in the rule above.
It's not surprising that this rule fails to limit ssh connections to
another host; that's what 'to $unpro' tells pf to do, after all.
Couple of clarification questions:
1. When you say skip something, you mean just delete the string '!
scanners' and not the whole rule, correct?
Yes.
If you
do remove 'to $unpro', you might want to add something like 'from !
$unpro:network'. (Do note that 'from ! { $unpro:network scanners }' is
legal syntax, but not sensible.)
2. Shouldn't it be 'to $unpro:network' here since we're substituting one
'to' condition with another?
Thanks -- your comments make great sense.
Sorry, scratch question 2. Obviously 'from' is correct.
Is this what you meant:
pass in log quick on $unpro inet proto tcp \
from ! $unpro:network port ssh flags S/SA \
keep state $SSH_LIMIT
No, more along the lines of
pass in log quick on $unpro inet proto tcp \
to port ssh keep state $SSH_LIMIT
(Note that 'flags S/SA' and 'keep state' are the default in 4.1 and
later, but 'keep state' must be explicitly given for $SSH_LIMIT -
'(max-src-conn-rate 3/30, overload scanners)' - to be legal.)
Or, if you want to add ! $unpro:network,
pass in log quick on $unpro inet proto tcp \
from ! $unpro:network to port ssh keep state $SSH_LIMIT
where my $SSH_LIMIT is different from yours, missing 'flush global'.
All of this looks a lot like IPTables-in-pf, though [1]. And only works
because you have a 'default allow' policy (the above rule does not match
on traffic from the local network, but with a 'default deny' policy this
would mean you would be unable to ssh from the local network at all.
Which is not what you want.) The way I'd write this rule would be
pass in on $unpro inet proto tcp to port ssh \
keep state (max-src-conn-rate 3/30, overload scanners)
pass in on $unpro inet proto tcp from $unpro:network to port ssh
which a) works with a 'default deny' policy, should you ever implement
one, and b) also avoid defining a macro that's only used once and does
not necessarily clarify matters.
Joachim
[1] I should know, I spent half the day writing pf-in-IPTables. Debian
is fine, for some values of fine, for webservers, but firewalls... well,
just note there's no MoTD below.
--
It can be difficult to translate into iptables the artistic intent of a
pf rule that says pass out quick on $cheap_gin
-- Anthony de Boer, in ASR
Re: SSH brute force attacks no longer being caught by PF rule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/27/07 10:39 PM, Daniel Ouellet wrote: Steve B wrote: The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? Put quickly as an example, but you can try: # Define some variable for clarity SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners # Block ssh access to bad ssh scanner block drop in log quick on $ext_if inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $ext_if inet proto tcp from ! scanners \ to $ext_if port ssh flags S/SA keep state \ $SSH_LIMIT I've added something like this to pf.conf but it's only partially successful. I would appreciate any clues as to why it's not blocking all brute-force attempts. On an OBSD 4.1 box, here's what I added to pf.conf ($unpro is the Internet-facing interface): # # Define limit of ssh connection rates SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) # SSH scanners - blocked IPs table scanners persist block drop in log quick on $unpro inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $unpro inet proto tcp from ! scanners \ to $unpro port ssh $SSH_LIMIT # And it appears to be working, at least in part: [EMAIL PROTECTED] ~ 501$ sudo pfctl -t scanners -T show 61.146.178.13 61.189.145.103 67.76.237.190 161.200.144.108 193.254.31.194 # But some hosts on the protected side of the firewall still report brute-force ssh login attempts exceeding the 3/30 rate: Aug 7 10:16:00 mail sshd[21608]: Invalid user trash from 201.18.81.8 Aug 7 10:16:08 mail sshd[21610]: Invalid user aaron from 201.18.81.8 Aug 7 10:16:11 mail sshd[21612]: Invalid user gt05 from 201.18.81.8 Aug 7 10:16:18 mail sshd[21614]: Invalid user william from 201.18.81.8 Aug 7 10:16:22 mail sshd[21616]: Invalid user stephanie from 201.18.81.8 Aug 7 10:16:59 mail sshd[21628]: Invalid user gary from 201.18.81.8 Aug 7 10:17:07 mail sshd[21632]: Invalid user guest from 201.18.81.8 Aug 7 10:17:11 mail sshd[21634]: Invalid user test from 201.18.81.8 Aug 7 10:17:17 mail sshd[21636]: Invalid user oracle from 201.18.81.8 Aug 7 10:19:24 mail sshd[21717]: Invalid user apache from 201.18.81.8 Aug 7 10:19:43 mail sshd[21723]: Invalid user lab from 201.18.81.8 Aug 7 10:19:55 mail sshd[21729]: Invalid user oracle from 201.18.81.8 Aug 7 10:20:00 mail sshd[21736]: Invalid user svn from 201.18.81.8 Aug 7 10:20:06 mail sshd[21745]: Invalid user iraf from 201.18.81.8 Aug 7 10:20:13 mail sshd[21747]: Invalid user swsoft from 201.18.81.8 Aug 7 10:20:18 mail sshd[21749]: Invalid user production from 201.18.81.8 Aug 7 10:20:23 mail sshd[21751]: Invalid user guest from 201.18.81.8 Aug 7 10:20:28 mail sshd[21753]: Invalid user gast from 201.18.81.8 Aug 7 10:20:34 mail sshd[21755]: Invalid user gast from 201.18.81.8 Aug 7 10:20:40 mail sshd[21762]: Invalid user oliver from 201.18.81.8 Aug 7 10:20:45 mail sshd[21767]: Invalid user sirsi from 201.18.81.8 Aug 7 10:20:50 mail sshd[21769]: Invalid user nagios from 201.18.81.8 Aug 7 10:20:55 mail sshd[21771]: Invalid user nagios from 201.18.81.8 Aug 7 10:20:59 mail sshd[21773]: Invalid user nagios from 201.18.81.8 Thanks in advance for suggestions as to how to reduce these kind of login attempts. dn iD8DBQFGufyzyPxGVjntI4IRAty2AJ9WDCqLqkWyhx/KuciGINow6Upb5wCfUuP+ GfZ8lnaun1QPItnFK5c4MNU= =tjbD -END PGP SIGNATURE-
Re: SSH brute force attacks no longer being caught by PF rule
Although this doesn't answer your actual pf question, you might try using a tool called Grok (http://www.semicomplete.com/projects/grok/). It's a pretty decent log watcher written in Perl, designed to do exactly this sort of thing. You define matches and reactions in its config file (match = Illegal user %USERNAME% from %IP%; reaction = pfctl -t scanners -T add %IP%;). It does have a few quirks though. We've encountered problems with having multiple rules watching the same log. But, all in all, probably a better way to do what it looks like you want to do. - R. On 8/8/07, David Newman [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/27/07 10:39 PM, Daniel Ouellet wrote: Steve B wrote: The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? Put quickly as an example, but you can try: # Define some variable for clarity SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners # Block ssh access to bad ssh scanner block drop in log quick on $ext_if inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $ext_if inet proto tcp from ! scanners \ to $ext_if port ssh flags S/SA keep state \ $SSH_LIMIT I've added something like this to pf.conf but it's only partially successful. I would appreciate any clues as to why it's not blocking all brute-force attempts. On an OBSD 4.1 box, here's what I added to pf.conf ($unpro is the Internet-facing interface): # # Define limit of ssh connection rates SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) # SSH scanners - blocked IPs table scanners persist block drop in log quick on $unpro inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $unpro inet proto tcp from ! scanners \ to $unpro port ssh $SSH_LIMIT # And it appears to be working, at least in part: [EMAIL PROTECTED] ~ 501$ sudo pfctl -t scanners -T show 61.146.178.13 61.189.145.103 67.76.237.190 161.200.144.108 193.254.31.194 # But some hosts on the protected side of the firewall still report brute-force ssh login attempts exceeding the 3/30 rate: Aug 7 10:16:00 mail sshd[21608]: Invalid user trash from 201.18.81.8 Aug 7 10:16:08 mail sshd[21610]: Invalid user aaron from 201.18.81.8 Aug 7 10:16:11 mail sshd[21612]: Invalid user gt05 from 201.18.81.8 Aug 7 10:16:18 mail sshd[21614]: Invalid user william from 201.18.81.8 Aug 7 10:16:22 mail sshd[21616]: Invalid user stephanie from 201.18.81.8 Aug 7 10:16:59 mail sshd[21628]: Invalid user gary from 201.18.81.8 Aug 7 10:17:07 mail sshd[21632]: Invalid user guest from 201.18.81.8 Aug 7 10:17:11 mail sshd[21634]: Invalid user test from 201.18.81.8 Aug 7 10:17:17 mail sshd[21636]: Invalid user oracle from 201.18.81.8 Aug 7 10:19:24 mail sshd[21717]: Invalid user apache from 201.18.81.8 Aug 7 10:19:43 mail sshd[21723]: Invalid user lab from 201.18.81.8 Aug 7 10:19:55 mail sshd[21729]: Invalid user oracle from 201.18.81.8 Aug 7 10:20:00 mail sshd[21736]: Invalid user svn from 201.18.81.8 Aug 7 10:20:06 mail sshd[21745]: Invalid user iraf from 201.18.81.8 Aug 7 10:20:13 mail sshd[21747]: Invalid user swsoft from 201.18.81.8 Aug 7 10:20:18 mail sshd[21749]: Invalid user production from 201.18.81.8 Aug 7 10:20:23 mail sshd[21751]: Invalid user guest from 201.18.81.8 Aug 7 10:20:28 mail sshd[21753]: Invalid user gast from 201.18.81.8 Aug 7 10:20:34 mail sshd[21755]: Invalid user gast from 201.18.81.8 Aug 7 10:20:40 mail sshd[21762]: Invalid user oliver from 201.18.81.8 Aug 7 10:20:45 mail sshd[21767]: Invalid user sirsi from 201.18.81.8 Aug 7 10:20:50 mail sshd[21769]: Invalid user nagios from 201.18.81.8 Aug 7 10:20:55 mail sshd[21771]: Invalid user nagios from 201.18.81.8 Aug 7 10:20:59 mail sshd[21773]: Invalid user nagios from 201.18.81.8 Thanks in advance for suggestions as to how to reduce these kind of login attempts. dn iD8DBQFGufyzyPxGVjntI4IRAty2AJ9WDCqLqkWyhx/KuciGINow6Upb5wCfUuP+ GfZ8lnaun1QPItnFK5c4MNU= =tjbD -END PGP SIGNATURE-
Re: SSH brute force attacks no longer being caught by PF rule
3 times in 30 seconds as a src connection rate is pretty conservative and you don't have a connection rate trap. I run max-src-conn 5, max-src-conn-rate 5/5 and nail every one. Of course you'll see the first few attempts, but once they tickle that max-src-conn rule they get shutdown. -- ~Allie D. On Wed, August 8, 2007 10:26, David Newman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/27/07 10:39 PM, Daniel Ouellet wrote: Steve B wrote: The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? Put quickly as an example, but you can try: # Define some variable for clarity SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners # Block ssh access to bad ssh scanner block drop in log quick on $ext_if inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $ext_if inet proto tcp from ! scanners \ to $ext_if port ssh flags S/SA keep state \ $SSH_LIMIT I've added something like this to pf.conf but it's only partially successful. I would appreciate any clues as to why it's not blocking all brute-force attempts. On an OBSD 4.1 box, here's what I added to pf.conf ($unpro is the Internet-facing interface): # # Define limit of ssh connection rates SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) # SSH scanners - blocked IPs table scanners persist block drop in log quick on $unpro inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $unpro inet proto tcp from ! scanners \ to $unpro port ssh $SSH_LIMIT # And it appears to be working, at least in part: [EMAIL PROTECTED] ~ 501$ sudo pfctl -t scanners -T show 61.146.178.13 61.189.145.103 67.76.237.190 161.200.144.108 193.254.31.194 # But some hosts on the protected side of the firewall still report brute-force ssh login attempts exceeding the 3/30 rate: Aug 7 10:16:00 mail sshd[21608]: Invalid user trash from 201.18.81.8 Aug 7 10:16:08 mail sshd[21610]: Invalid user aaron from 201.18.81.8 Aug 7 10:16:11 mail sshd[21612]: Invalid user gt05 from 201.18.81.8 Aug 7 10:16:18 mail sshd[21614]: Invalid user william from 201.18.81.8 Aug 7 10:16:22 mail sshd[21616]: Invalid user stephanie from 201.18.81.8 Aug 7 10:16:59 mail sshd[21628]: Invalid user gary from 201.18.81.8 Aug 7 10:17:07 mail sshd[21632]: Invalid user guest from 201.18.81.8 Aug 7 10:17:11 mail sshd[21634]: Invalid user test from 201.18.81.8 Aug 7 10:17:17 mail sshd[21636]: Invalid user oracle from 201.18.81.8 Aug 7 10:19:24 mail sshd[21717]: Invalid user apache from 201.18.81.8 Aug 7 10:19:43 mail sshd[21723]: Invalid user lab from 201.18.81.8 Aug 7 10:19:55 mail sshd[21729]: Invalid user oracle from 201.18.81.8 Aug 7 10:20:00 mail sshd[21736]: Invalid user svn from 201.18.81.8 Aug 7 10:20:06 mail sshd[21745]: Invalid user iraf from 201.18.81.8 Aug 7 10:20:13 mail sshd[21747]: Invalid user swsoft from 201.18.81.8 Aug 7 10:20:18 mail sshd[21749]: Invalid user production from 201.18.81.8 Aug 7 10:20:23 mail sshd[21751]: Invalid user guest from 201.18.81.8 Aug 7 10:20:28 mail sshd[21753]: Invalid user gast from 201.18.81.8 Aug 7 10:20:34 mail sshd[21755]: Invalid user gast from 201.18.81.8 Aug 7 10:20:40 mail sshd[21762]: Invalid user oliver from 201.18.81.8 Aug 7 10:20:45 mail sshd[21767]: Invalid user sirsi from 201.18.81.8 Aug 7 10:20:50 mail sshd[21769]: Invalid user nagios from 201.18.81.8 Aug 7 10:20:55 mail sshd[21771]: Invalid user nagios from 201.18.81.8 Aug 7 10:20:59 mail sshd[21773]: Invalid user nagios from 201.18.81.8 Thanks in advance for suggestions as to how to reduce these kind of login attempts. dn iD8DBQFGufyzyPxGVjntI4IRAty2AJ9WDCqLqkWyhx/KuciGINow6Upb5wCfUuP+ GfZ8lnaun1QPItnFK5c4MNU= =tjbD -END PGP SIGNATURE-
Re: SSH brute force attacks no longer being caught by PF rule
On 8/8/07, Daniel Cid [EMAIL PROTECTED] wrote: Please, don't use grok for that! From what I saw it is vulnerable to very simple log injection attacks (you need much more string regexes): http://www.ossec.net/en/attacking-loganalysis.html Ack. Thanks for pointing that out. Some attacks can be fixed with a slightly more complicated regex, but I'll have to crawl through the code some also and see how it parses the regex. (Or maybe just use ossec.) Gee, and I have so much time, too... - R.
Re: SSH brute force attacks no longer being caught by PF rule
I just had to reply with this info because I already had an attempted brute force in the last hour. All you need to do is make your rule tighter and add a connection rate ratio to start collecting IP's. ( I use logsentry/logcheck) Security Violations =-=-=-=-=-=-=-=-=-= Aug 8 11:48:16 traci sshd[1099]: Failed password for invalid user root from 72.11.128.61 port 42049 ssh2 Aug 8 11:48:17 traci sshd[25952]: Failed password for invalid user root from 72.11.128.61 port 42104 ssh2 Aug 8 11:48:18 traci sshd[2543]: Failed password for invalid user root from 72.11.128.61 port 42149 ssh2 Aug 8 11:48:19 traci sshd[14785]: Failed password for invalid user root from 72.11.128.61 port 42193 ssh2 Aug 8 11:48:20 traci sshd[75]: Failed password for invalid user root from 72.11.128.61 port 42242 ssh2 Unusual System Events =-=-=-=-=-=-=-=-=-=-= Aug 8 11:48:16 traci sshd[1099]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:16 traci sshd[28065]: input_userauth_request: invalid user root Aug 8 11:48:16 traci sshd[1099]: Failed password for invalid user root from 72.11.128.61 port 42049 ssh2 Aug 8 11:48:16 traci sshd[28065]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:17 traci sshd[25952]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:17 traci sshd[4408]: input_userauth_request: invalid user root Aug 8 11:48:17 traci sshd[25952]: Failed password for invalid user root from 72.11.128.61 port 42104 ssh2 Aug 8 11:48:17 traci sshd[4408]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:18 traci sshd[2543]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:18 traci sshd[23885]: input_userauth_request: invalid user root Aug 8 11:48:18 traci sshd[2543]: Failed password for invalid user root from 72.11.128.61 port 42149 ssh2 Aug 8 11:48:18 traci sshd[23885]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:19 traci sshd[14785]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:19 traci sshd[22134]: input_userauth_request: invalid user root Aug 8 11:48:19 traci sshd[14785]: Failed password for invalid user root from 72.11.128.61 port 42193 ssh2 Aug 8 11:48:19 traci sshd[22134]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:20 traci sshd[75]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:20 traci sshd[12103]: input_userauth_request: invalid user root Aug 8 11:48:20 traci sshd[75]: Failed password for invalid user root from 72.11.128.61 port 42242 ssh2 Aug 8 11:48:20 traci sshd[12103]: Received disconnect from 72.11.128.61: 11: Bye Bye pfctl -t DoS_hosts -T show -v 72.11.128.61 Cleared: Wed Aug 8 11:48:20 2007 In/Block:[ Packets: 6 Bytes: 240 ] In/Pass: [ Packets: 0 Bytes: 0 ] Out/Block: [ Packets: 0 Bytes: 0 ] Out/Pass:[ Packets: 0 Bytes: 0 ] -- ~Allie D. On Wed, August 8, 2007 10:26, David Newman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/27/07 10:39 PM, Daniel Ouellet wrote: Steve B wrote: The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? Put quickly as an example, but you can try: # Define some variable for clarity SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners # Block ssh access to bad ssh scanner block drop in log quick on $ext_if inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $ext_if inet proto tcp from ! scanners \ to $ext_if port ssh flags S/SA keep state \ $SSH_LIMIT I've added something like this to pf.conf but it's only partially successful. I would appreciate any clues as to why it's not blocking all brute-force attempts. On an OBSD 4.1 box, here's what I added to pf.conf ($unpro is the Internet-facing interface): # # Define limit of ssh connection rates SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) # SSH scanners - blocked IPs table scanners persist block drop in log quick on $unpro inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $unpro inet proto tcp from ! scanners \ to $unpro port ssh $SSH_LIMIT # And it appears to be working, at least in part: [EMAIL PROTECTED] ~ 501$ sudo pfctl -t scanners -T
Re: SSH brute force attacks no longer being caught by PF rule
Allie D. wrote: I just had to reply with this info because I already had an attempted brute force in the last hour. All you need to do is make your rule tighter and add a connection rate ratio to start collecting IP's. we use pf os fingerprinting to only allow ssh connections from openbsd hosts. that pretty much solves the problem... ( I use logsentry/logcheck) Security Violations =-=-=-=-=-=-=-=-=-= Aug 8 11:48:16 traci sshd[1099]: Failed password for invalid user root from 72.11.128.61 port 42049 ssh2 Aug 8 11:48:17 traci sshd[25952]: Failed password for invalid user root from 72.11.128.61 port 42104 ssh2 Aug 8 11:48:18 traci sshd[2543]: Failed password for invalid user root from 72.11.128.61 port 42149 ssh2 Aug 8 11:48:19 traci sshd[14785]: Failed password for invalid user root from 72.11.128.61 port 42193 ssh2 Aug 8 11:48:20 traci sshd[75]: Failed password for invalid user root from 72.11.128.61 port 42242 ssh2 Unusual System Events =-=-=-=-=-=-=-=-=-=-= Aug 8 11:48:16 traci sshd[1099]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:16 traci sshd[28065]: input_userauth_request: invalid user root Aug 8 11:48:16 traci sshd[1099]: Failed password for invalid user root from 72.11.128.61 port 42049 ssh2 Aug 8 11:48:16 traci sshd[28065]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:17 traci sshd[25952]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:17 traci sshd[4408]: input_userauth_request: invalid user root Aug 8 11:48:17 traci sshd[25952]: Failed password for invalid user root from 72.11.128.61 port 42104 ssh2 Aug 8 11:48:17 traci sshd[4408]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:18 traci sshd[2543]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:18 traci sshd[23885]: input_userauth_request: invalid user root Aug 8 11:48:18 traci sshd[2543]: Failed password for invalid user root from 72.11.128.61 port 42149 ssh2 Aug 8 11:48:18 traci sshd[23885]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:19 traci sshd[14785]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:19 traci sshd[22134]: input_userauth_request: invalid user root Aug 8 11:48:19 traci sshd[14785]: Failed password for invalid user root from 72.11.128.61 port 42193 ssh2 Aug 8 11:48:19 traci sshd[22134]: Received disconnect from 72.11.128.61: 11: Bye Bye Aug 8 11:48:20 traci sshd[75]: User root from 72.11.128.61 not allowed because not listed in AllowUsers Aug 8 11:48:20 traci sshd[12103]: input_userauth_request: invalid user root Aug 8 11:48:20 traci sshd[75]: Failed password for invalid user root from 72.11.128.61 port 42242 ssh2 Aug 8 11:48:20 traci sshd[12103]: Received disconnect from 72.11.128.61: 11: Bye Bye pfctl -t DoS_hosts -T show -v 72.11.128.61 Cleared: Wed Aug 8 11:48:20 2007 In/Block:[ Packets: 6 Bytes: 240 ] In/Pass: [ Packets: 0 Bytes: 0 ] Out/Block: [ Packets: 0 Bytes: 0 ] Out/Pass:[ Packets: 0 Bytes: 0 ]
Re: SSH brute force attacks no longer being caught by PF rule
On 6/28/07, Martin Schrvder [EMAIL PROTECTED] wrote: 2007/6/28, J.D. Bronson [EMAIL PROTECTED]: so if it wont write to a file...I presume it blocks whats listed in /etc/tables/scanners permanently and then only blocks NEW offenders via kernel memory? (can someone clarify my understanding of that? Do you really need a file? In my experience blocking the offenders for 1h is enough; they very rarely come back later. Best Martin I'm the one who started this thread. If I can block them for an hour without a table that would be even better.. I was using the file to store the IP's as they were identified by the rule and had been planning to use the expiretable package to start clearing the table via Cron. Currently I just do it manually about once a week or so. I've read the man page for pf.confbut did not see how I could block them for a set period of time. Could someone elaborate on how this is done? Steve
Re: SSH brute force attacks no longer being caught by PF rule
Steve B [EMAIL PROTECTED] writes: I'm the one who started this thread. If I can block them for an hour without a table that would be even better. Sure, you could have a frequently running cron job which does a pfctl -t bruteforce -T expire 3600 (OpenBSD 4.1 onwards) or use expiretable. At the very bottom of http://home.nuug.no/~peter/pf/en/bruteforce.html I have examples of both. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: SSH brute force attacks no longer being caught by PF rule
I have a question about this.. Will NEW offenders be added to /etc/tables/scanners as they are discovered and therefore not just remain in kernel? It would be nice since doing a reboot wipes out kernel kept IPs... table scanners persist file /etc/tables/scanners vs table scanners persist Thanks :) -JD Date: Thu, 28 Jun 2007 01:39:37 -0400 From: Daniel Ouellet [EMAIL PROTECTED] User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) To: OpenBSD misc@openbsd.org Subject: Re: SSH brute force attacks no longer being caught by PF rule Sender: [EMAIL PROTECTED] Steve B wrote: The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? Put quickly as an example, but you can try: # Define some variable for clarity SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners # Block ssh access to bad ssh scanner block drop in log quick on $ext_if inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $ext_if inet proto tcp from ! scanners \ to $ext_if port ssh flags S/SA keep state \ $SSH_LIMIT You may also want to add a section to always make sure you will have SSH access to your box before you block all SSH access like you did should someone spoof your source IP to log yourself out as well with may be something like: # Allow quick ssh access to good guys on main interface. pass in quick on $ext_if inet proto tcp from goodguys \ to $ext_if port ssh flags S/SA keep state Daniel
Re: SSH brute force attacks no longer being caught by PF rule
At 08:56 AM 06/28/2007, Stuart Henderson wrote: On 2007/06/28 08:46, J.D. Bronson wrote: Will NEW offenders be added to /etc/tables/scanners as they are discovered and therefore not just remain in kernel? No, pf does not write to files. How about cron(8) and pfctl(8) instead? so if it wont write to a file...I presume it blocks whats listed in /etc/tables/scanners permanently and then only blocks NEW offenders via kernel memory? (can someone clarify my understanding of that? I would ideally like to stop attacks and then write the offenders in a file so I dont loose these during a reboot... what if I cron something like this: pfctl -t scanners -T show /etc/tables/scanners pfctl -f /etc/pf.conf Would that work??
Re: SSH brute force attacks no longer being caught by PF rule
On 2007/06/28 08:46, J.D. Bronson wrote: Will NEW offenders be added to /etc/tables/scanners as they are discovered and therefore not just remain in kernel? No, pf does not write to files. How about cron(8) and pfctl(8) instead?
Re: SSH brute force attacks no longer being caught by PF rule
On Wed, Jun 27, 2007 at 09:54:04PM -0700, Steve B wrote: The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners ## Packet Filtering ## block quick from scanners block in all ## Pass SSH traffic ## pass in log on $ext_if inet proto tcp from any to any port = ssh flags S/SA keep state (source-track rule, max-src-conn 10, max-src-conn-rate 5/60, overload scanners flush global, if-bound, sr c.track 60) 'pass in log' suggests the solution; try to connect via SSH and let tcpdump listen on pflog0. Joachim -- TFMotD: perlnewmod (1) - preparing a new module for distribution
Re: SSH brute force attacks no longer being caught by PF rule
On Thu, 28 Jun 2007 09:02:43 -0500 J.D. Bronson [EMAIL PROTECTED] wrote: At 08:56 AM 06/28/2007, Stuart Henderson wrote: On 2007/06/28 08:46, J.D. Bronson wrote: Will NEW offenders be added to /etc/tables/scanners as they are discovered and therefore not just remain in kernel? No, pf does not write to files. How about cron(8) and pfctl(8) instead? so if it wont write to a file...I presume it blocks whats listed in /etc/tables/scanners permanently and then only blocks NEW offenders via kernel memory? (can someone clarify my understanding of that? I would ideally like to stop attacks and then write the offenders in a file so I dont loose these during a reboot... what if I cron something like this: pfctl -t scanners -T show /etc/tables/scanners pfctl -f /etc/pf.conf Would that work?? The persist thing got me at first too, but the FAQ is quite clear and does not actual say it writes anywhere. I just assumed it for reasons beyond this discussion. Anyway, persist keeps it even if no rules are not using it. The file part is strictly for pre-populating when pf starts up. I am not sure why you have both of those... the top line to output would be fine, and have your pf ruleset use the file at startup to read them in.
Re: SSH brute force attacks no longer being caught by PF rule
On 2007/06/28 09:02, J.D. Bronson wrote: At 08:56 AM 06/28/2007, Stuart Henderson wrote: On 2007/06/28 08:46, J.D. Bronson wrote: Will NEW offenders be added to /etc/tables/scanners as they are discovered and therefore not just remain in kernel? No, pf does not write to files. How about cron(8) and pfctl(8) instead? so if it wont write to a file...I presume it blocks whats listed in /etc/tables/scanners permanently and then only blocks NEW offenders via kernel memory? (can someone clarify my understanding of that? yes. when the ruleset is loaded, the table in memory is populated with the contents of /etc/tables/scanners. when someone hits overload, they are just added to the table in memory. I would ideally like to stop attacks and then write the offenders in a file so I dont loose these during a reboot... what if I cron something like this: pfctl -t scanners -T show /etc/tables/scanners pfctl -f /etc/pf.conf Would that work?? no need to reload the ruleset each time, and your table file will grow quite large by using to append each time; this would be better: TMPFILE=`mktemp -p /etc/tables scanners.XX` || exit 1 pfctl -t scanners -Ts $TMPFILE mv $TMPFILE /etc/tables/scanners this is all from a 'how to do it' point-of-view, I don't think it's all that useful. if an attacker is still active, they'll hit overload soon enough anyway.
Re: SSH brute force attacks no longer being caught by PF rule
J.D. Bronson wrote: At 08:56 AM 06/28/2007, Stuart Henderson wrote: On 2007/06/28 08:46, J.D. Bronson wrote: Will NEW offenders be added to /etc/tables/scanners as they are discovered and therefore not just remain in kernel? No, pf does not write to files. How about cron(8) and pfctl(8) instead? so if it wont write to a file...I presume it blocks whats listed in /etc/tables/scanners permanently and then only blocks NEW offenders via kernel memory? (can someone clarify my understanding of that? I would ideally like to stop attacks and then write the offenders in a file so I dont loose these during a reboot... what if I cron something like this: pfctl -t scanners -T show /etc/tables/scanners pfctl -f /etc/pf.conf Would that work?? I was trying to help giving you an example that would work, as you said it was working before and not anymore. But I guess you need to go back and read the faq, and the man page on pf and cron. Looks like you want others to do the work for you and giving you the answer, or even more details is like doing the setup for you and you will not remember or understand it properly to do it right the next time around. Sorry, I really was going to send you more but deleted my email. It wouldn't be the right way to help you. Configuring a firewall is important to make sure you protect yourself and your office, etc. Do your homework first, then if you have question you sure can asked and will be more then happy to help. Feeding you with a spoon is the wrong thing to do here as firewall is to important for you not to understand it fully. I sure don't want to be mean, but I think that's the best way to help you. I fell it wouldn't be helping you doing so. If you are not sure of something, why not testing it and see. (; Best, Daniel
Re: SSH brute force attacks no longer being caught by PF rule
Guys...I was not the one that started this thread.. I just chimed in and asked for a tweak on the setup. I have what I need for now :) -JD At 11:54 AM 06/28/2007, Daniel Ouellet wrote: J.D. Bronson wrote: At 08:56 AM 06/28/2007, Stuart Henderson wrote: On 2007/06/28 08:46, J.D. Bronson wrote: Will NEW offenders be added to /etc/tables/scanners as they are discovered and therefore not just remain in kernel? No, pf does not write to files. How about cron(8) and pfctl(8) instead? so if it wont write to a file...I presume it blocks whats listed in /etc/tables/scanners permanently and then only blocks NEW offenders via kernel memory? (can someone clarify my understanding of that? I would ideally like to stop attacks and then write the offenders in a file so I dont loose these during a reboot... what if I cron something like this: pfctl -t scanners -T show /etc/tables/scanners pfctl -f /etc/pf.conf Would that work?? I was trying to help giving you an example that would work, as you said it was working before and not anymore. But I guess you need to go back and read the faq, and the man page on pf and cron. Looks like you want others to do the work for you and giving you the answer, or even more details is like doing the setup for you and you will not remember or understand it properly to do it right the next time around. Sorry, I really was going to send you more but deleted my email. It wouldn't be the right way to help you. Configuring a firewall is important to make sure you protect yourself and your office, etc. Do your homework first, then if you have question you sure can asked and will be more then happy to help. Feeding you with a spoon is the wrong thing to do here as firewall is to important for you not to understand it fully. I sure don't want to be mean, but I think that's the best way to help you. I fell it wouldn't be helping you doing so. If you are not sure of something, why not testing it and see. (; Best, Daniel
Re: SSH brute force attacks no longer being caught by PF rule
J.D. Bronson wrote: Guys...I was not the one that started this thread.. I just chimed in and asked for a tweak on the setup. Sorry for my mistake then. I should refrain from replying on lack of sleep. (; I have what I need for now :) Glad it help you never the less.
Re: SSH brute force attacks no longer being caught by PF rule
2007/6/28, J.D. Bronson [EMAIL PROTECTED]: so if it wont write to a file...I presume it blocks whats listed in /etc/tables/scanners permanently and then only blocks NEW offenders via kernel memory? (can someone clarify my understanding of that? Do you really need a file? In my experience blocking the offenders for 1h is enough; they very rarely come back later. Best Martin
Re: SSH brute force attacks no longer being caught by PF rule
Steve B wrote: The rule I've had in my pf.conf file to catch and block forceful SSH attempts no longer appears to be working. I see the entries in my authlog, but the IPs are no longer getting added to my table. I suspect I screwed something up, but so far I am at a loss to see where. Could someone pass another set of eyes over the relevant parts of my pf.conf? Put quickly as an example, but you can try: # Define some variable for clarity SSH_LIMIT=(max-src-conn-rate 3/30, overload scanners flush global) ## SSH Hackers - blocked IPs table scanners persist file /etc/tables/scanners # Block ssh access to bad ssh scanner block drop in log quick on $ext_if inet proto tcp \ from scanners to any port ssh # Allow quick valid traffic to ssh but log all attempts as well pass in log quick on $ext_if inet proto tcp from ! scanners \ to $ext_if port ssh flags S/SA keep state \ $SSH_LIMIT You may also want to add a section to always make sure you will have SSH access to your box before you block all SSH access like you did should someone spoof your source IP to log yourself out as well with may be something like: # Allow quick ssh access to good guys on main interface. pass in quick on $ext_if inet proto tcp from goodguys \ to $ext_if port ssh flags S/SA keep state Daniel
