-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 are the relevant parts:
>
> /
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
On Feb 8, 2011, at 7:47 PM, Luke Jee wrote:
> Hi Vadyam,
>
> try this:
> table
>
> remove persist, i remember it means table will readonly
That contradicts the manual:
Tables may be defined with the following two attributes:
persist The persist flag forces the kernel to keep the
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 post a vital part). We also ca
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,
can we?
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 relevant parts:
>>
>> /etc/ssh/sshd_config
>>
>> PasswordAu
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
> MaxAuthTries 1
>
> /etc/pf.conf
>
> block
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
pass quick
14 matches
Mail list logo
