-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 wo
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.
* 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 scri
- Original Message -
From: "Stuart Henderson" <[EMAIL PROTECTED]>
To: "OpenBSD"
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
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 i
Joachim Schipper wrote:
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 o
On Mon, Aug 13, 2007 at 10:10:14AM +0100, Stuart Henderson wrote:
> On 2007/08/09 12:22, Joachim Schipper wrote:
> > > >
> > > > # Define some variable for clarity
> > > > SSH_LIMIT="(max-src-conn-rate 3/30, overload flush global)"
> > > >
> > > > # Allow quick valid traffic to ssh but log all a
On 2007/08/09 12:22, Joachim Schipper wrote:
> > >
> > > # Define some variable for clarity
> > > SSH_LIMIT="(max-src-conn-rate 3/30, overload 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 ! \
>
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 qu
-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 ! \
>>>to $unpro port ssh $SSH_LIMIT
>>
-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 ! \
>>to $unpro port ssh $SSH_LIMIT
>
> Skip '! ' unless it's intended as documentat
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 c
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 flush global)"
> >
> > ## SS
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
hos
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
Be very careful when parsing logs for automated
remediation...
Thanks,
--
Daniel B. Cid
dcid ( at ) oss
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[
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
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.
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 = "Illeg
-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 ad
"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.
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
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 bloc
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.
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
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) ins
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.
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?
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, bu
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?
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
ks :)
-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
>Subject: Re: SSH brute force attacks no longer being caught by PF rule
>Sender: [EMAIL PROTECTED]
>
>Steve B
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 some
33 matches
Mail list logo
