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 \
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
- 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
* 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/...
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.
-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
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
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
-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
-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
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
-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
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 =
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 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
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
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
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
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
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
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
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?
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
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
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
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)
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
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.
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
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
30 matches
Mail list logo
