Ah, so I guess this does deserve some further debugging :)
First, make sure those connections are matching the expected rule:
Watch an ongoing scan, note the scanner's IP. Run
# pfctl -vvss | grep -A 2
Note the rule number printed right-most in every third line, and compare them
to the outp
On 2/8/11 11:06 PM, Vadym Chepkov wrote:
>
> On Feb 8, 2011, at 2:58 PM, Mike Tancsa wrote:
>
>> On 2/8/2011 1:11 PM, Vadym Chepkov wrote:
>>> Hi,
>>>
>>> Could somebody help in figuring out why PF configuration meant to prevent
>>> br
On 2/9/11 10:00 PM, Vadym Chepkov wrote:
>
>
> On Feb 9, 2011, at 5:00 AM, Damien Fleuriot wrote:
>
>> Looks like my previous message didn't make it to the list.
>>
>>
>> @OP: nothing indicates that your table is getting populated correctly.
>>
>> While this doesn't address your main issue, yo
On Feb 10, 2011, at 2:52 AM, Daniel Hartmeier wrote:
>
>> Feb 8 11:27:57 castor sshd[57332]: Invalid user ashley from 113.185.0.16
>
> diff = 3, count -= 8770 * 3 / 60, += 1000, count = 9332, last = 57
>
> Now count is larger than your limit 9000, and the threshold is
> triggered, after 15 con
On Wed, Feb 09, 2011 at 03:55:42PM -0500, Vadym Chepkov wrote:
> Feb 8 11:27:01 castor sshd[57304]: Invalid user ariane from 113.185.0.16
count = 1000, last = 01
> Feb 8 11:27:04 castor sshd[57306]: Invalid user armand from 113.185.0.16
diff = 3, count -= 1000 * 3 / 60, += 1000, count = 1950,
hat if something else doesn't
work as expected and I blindly trust it?
Vadym
>
> On 2/8/11 11:06 PM, Vadym Chepkov wrote:
>>
>> On Feb 8, 2011, at 2:58 PM, Mike Tancsa wrote:
>>
>>> On 2/8/2011 1:11 PM, Vadym Chepkov wrote:
>>>> Hi,
>
On Feb 9, 2011, at 1:51 PM, Daniel Hartmeier wrote:
> On Tue, Feb 08, 2011 at 08:07:52PM -0500, Vadym Chepkov wrote:
>
>> No idea, why it didn't stop after 9 attempts.
>
> The connection rate is not calculated precisely, from pf.conf(5)
>
> max-src-conn-rate /
> Limit the rate
On Tue, Feb 08, 2011 at 08:07:52PM -0500, Vadym Chepkov wrote:
> No idea, why it didn't stop after 9 attempts.
The connection rate is not calculated precisely, from pf.conf(5)
max-src-conn-rate /
Limit the rate of new connections over a time interval. The con-
necti
On 2/8/11 11:06 PM, Vadym Chepkov wrote:
>
> On Feb 8, 2011, at 2:58 PM, Mike Tancsa wrote:
>
>> On 2/8/2011 1:11 PM, Vadym Chepkov wrote:
>>> Hi,
>>>
>>> Could somebody help in figuring out why PF configuration meant to prevent
>>> brutal
tion meant to prevent
>> brutal SSH attacks doesn't work.
>
> Check your pflog. The ruleset itself seems fine (if it is complete and you
> did not forget to post a vital part). We also can assume that pf is enabled,
> can we?
> _
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 8 Feb 2011 20:38, vchepkov@ wrote:
On Feb 8, 2011, at 8:36 PM, Helmut Schneider wrote:
Here are entries with pass in log enabled:
19:59:08.149358 rule 5/0(match): pass in on bce1: 93.174.31.134.36872 >
38.X.X.X.22: Flags [S], seq 4417
On Feb 8, 2011, at 8:36 PM, Helmut Schneider wrote:
>> Here are entries with pass in log enabled:
>>
>> 19:59:08.149358 rule 5/0(match): pass in on bce1: 93.174.31.134.36872 >
>> 38.X.X.X.22: Flags [S], seq 441726758, win 5840, options [mss 1460,sackOK,TS
>> val 395810874 ecr 0,nop,wscale 7],
Here are entries with pass in log enabled:
19:59:08.149358 rule 5/0(match): pass in on bce1: 93.174.31.134.36872 >
38.X.X.X.22: Flags [S], seq 441726758, win 5840, options [mss
1460,sackOK,TS val 395810874 ecr 0,nop,wscale 7], length 0
And 38.x.x.x is the external ip of your gateway?! (my las
I should have mentioned it.
Some IPs do get into abusive_hosts table, but some do not and I don't
understand, why, how do they avoid of getting caught.
Vadym
On Feb 8, 2011, at 8:07 PM, Vadym Chepkov wrote:
>
> On Feb 8, 2011, at 7:11 PM, Vadym Chepkov wrote:
>
>>
>> On Feb 8, 2011, at 7:0
Hi Vadyam,
try this:
table
remove persist, i remember it means table will readonly
On Wed, Feb 9, 2011 at 2:11 AM, Vadym Chepkov wrote:
> Hi,
>
> Could somebody help in figuring out why PF configuration meant to prevent
> brutal SSH attacks doesn't work.
>
> Here
On Feb 8, 2011, at 7:11 PM, Vadym Chepkov wrote:
>
> On Feb 8, 2011, at 7:01 PM, Helmut Schneider wrote:
>
Check your pflog. The ruleset itself seems fine (if it is complete and you
did not forget to post
a vital part). We also can assume that pf is enabled, can we?
>>>
>>> Wha
table persist
block on fxp0 from { , } to any
>
> On Wed, Feb 9, 2011 at 2:11 AM, Vadym Chepkov wrote:
> Hi,
>
> Could somebody help in figuring out why PF configuration meant to prevent
> brutal SSH attacks doesn't work.
>
> Here ar
On Feb 8, 2011, at 7:01 PM, Helmut Schneider wrote:
>>> Check your pflog. The ruleset itself seems fine (if it is complete and you
>>> did not forget to post
>>> a vital part). We also can assume that pf is enabled, can we?
>>
>> What should I be looking for in pflog? I can't find anything ssh
Check your pflog. The ruleset itself seems fine (if it is complete and
you did not forget to post
a vital part). We also can assume that pf is enabled, can we?
What should I be looking for in pflog? I can't find anything ssh related.
I posted full ruleset too.
[...]
[root@castor /var/log]# fo
On Feb 8, 2011, at 5:26 PM, Helmut Schneider wrote:
>> Could somebody help in figuring out why PF configuration meant to prevent
>> brutal SSH attacks doesn't work.
>
> Check your pflog. The ruleset itself seems fine (if it is complete and you
> did not forget to p
Could somebody help in figuring out why PF configuration meant to prevent
brutal SSH attacks doesn't work.
Check your pflog. The ruleset itself seems fine (if it is complete and you
did not forget to post a vital part). We also can assume that pf is enabled,
c
On Feb 8, 2011, at 2:58 PM, Mike Tancsa wrote:
> On 2/8/2011 1:11 PM, Vadym Chepkov wrote:
>> Hi,
>>
>> Could somebody help in figuring out why PF configuration meant to prevent
>> brutal SSH attacks doesn't work.
>>
>> Here are the
On 2/8/2011 1:11 PM, Vadym Chepkov wrote:
> Hi,
>
> Could somebody help in figuring out why PF configuration meant to prevent
> brutal SSH attacks doesn't work.
>
> Here are the relevant parts:
>
> /etc/ssh/sshd_config
>
> PasswordAuthentication no
Hi,
Could somebody help in figuring out why PF configuration meant to prevent
brutal SSH attacks doesn't work.
Here are the relevant parts:
/etc/ssh/sshd_config
PasswordAuthentication no
MaxAuthTries 1
/etc/pf.conf
block in log on $wan_if
table persist
block drop in quick from
24 matches
Mail list logo