On Fri, 27 Feb 2015 11:46:33 + (UTC)
Stuart Henderson wrote:
> On 2015-02-26, D'Arcy J.M. Cain wrote:
> > On Thu, 26 Feb 2015 21:49:15 +0100
> > Otto Moerbeek wrote:
> >> > What are you looking for specifically? I thought I posted all
> >> > the relevant rules and outputs. In particular I
On 2015-02-26, D'Arcy J.M. Cain wrote:
> On Thu, 26 Feb 2015 21:49:15 +0100
> Otto Moerbeek wrote:
>> > What are you looking for specifically? I thought I posted all the
>> > relevant rules and outputs. In particular I showed that the
>> > problem IP was in the AUTOBLOCK table with "pfctl -tAUT
On Thu, Feb 26, 2015 at 05:02:48PM -0500, Ted Unangst wrote:
> D'Arcy J.M. Cain wrote:
> > On Thu, 26 Feb 2015 15:22:36 -0500
> > "Ted Unangst" wrote:
> > > Well, there's what should happen and what does happen. The behavior
> > > described sounds a lot like it's keeping state. You can check with
On 26 Feb 2015 at 23:16, D'Arcy J.M. Cain wrote:
> On Thu, 26 Feb 2015 17:02:48 -0500
> "Ted Unangst" wrote:
> > > all udp 98.158.139.74:5060 <- 207.35.13.14:5060
> > > MULTIPLE:MULTIPLE
> > >
> > > What does "MULTIPLE:MULTIPLE" mean?
> >
> > multiple packets have passed, in both directions. i.
On Thu, 26 Feb 2015 17:02:48 -0500
"Ted Unangst" wrote:
> > all udp 98.158.139.74:5060 <- 207.35.13.14:5060
> > MULTIPLE:MULTIPLE
> >
> > What does "MULTIPLE:MULTIPLE" mean?
>
> multiple packets have passed, in both directions. i.e., you have a
> state.
And yet;
# pfctl -vv -sr | grep sip
@14
On Thu, 26 Feb 2015 14:53:28 -0800
Philip Guenther wrote:
> On Thu, Feb 26, 2015 at 2:40 PM, Edgar Pettijohn
> wrote:
> > pass in log on $ext_if proto udp from any to any port 5060 no state
> >
> > I didn't see anywhere in pf.conf(5) that shows "no state" as an option.
>
> Hmm? It's *first* me
On Thu, Feb 26, 2015 at 2:40 PM, Edgar Pettijohn
wrote:
> pass in log on $ext_if proto udp from any to any port 5060 no state
>
> I didn't see anywhere in pf.conf(5) that shows "no state" as an option.
Hmm? It's *first* mention is on line 139 of the manpage:
pass The packet is passed; stat
pass in log on $ext_if proto udp from any to any port 5060 no state
I didn't see anywhere in pf.conf(5) that shows "no state" as an option.
D'Arcy J.M. Cain wrote:
> On Thu, 26 Feb 2015 15:22:36 -0500
> "Ted Unangst" wrote:
> > Well, there's what should happen and what does happen. The behavior
> > described sounds a lot like it's keeping state. You can check with
> > pfctl -ss.
>
> all udp 98.158.139.74:5060 <- 207.35.13.14:5060
On Thu, 26 Feb 2015 15:22:36 -0500
"Ted Unangst" wrote:
> Well, there's what should happen and what does happen. The behavior
> described sounds a lot like it's keeping state. You can check with
> pfctl -ss.
all udp 98.158.139.74:5060 <- 207.35.13.14:5060 MULTIPLE:MULTIPLE
What does "MULTI
On Thu, 26 Feb 2015 21:49:15 +0100
Otto Moerbeek wrote:
> > What are you looking for specifically? I thought I posted all the
> > relevant rules and outputs. In particular I showed that the
> > problem IP was in the AUTOBLOCK table with "pfctl -tAUTOBLOCK -Ts".
>
> Well, from what you describe
On Thu, Feb 26, 2015 at 01:53:38PM -0500, D'Arcy J.M. Cain wrote:
> On Thu, 26 Feb 2015 18:25:49 +0100
> Otto Moerbeek wrote:
> > On Thu, Feb 26, 2015 at 12:11:34PM -0500, Ted Unangst wrote:
> > > Yes, that's how stateful firewalls work. Existing states don't
> > > evaluate the ruleset. You proba
D'Arcy J.M. Cain wrote:
> On Thu, 26 Feb 2015 12:11:34 -0500
> "Ted Unangst" wrote:
> > D'Arcy J.M. Cain wrote:
> > > So why would packets continue to come in for 2.5 hours? My guess is
> > > that the hacker is keeping the connection open and attacking over it
> > > for 2.5 hours. Does the packe
On Thu, 26 Feb 2015 18:25:49 +0100
Otto Moerbeek wrote:
> On Thu, Feb 26, 2015 at 12:11:34PM -0500, Ted Unangst wrote:
> > Yes, that's how stateful firewalls work. Existing states don't
> > evaluate the ruleset. You probably want to look into pfctl -k.
>
> The OP has a "no state" on the relevant
On Thu, 26 Feb 2015 12:11:34 -0500
"Ted Unangst" wrote:
> D'Arcy J.M. Cain wrote:
> > So why would packets continue to come in for 2.5 hours? My guess is
> > that the hacker is keeping the connection open and attacking over it
> > for 2.5 hours. Does the packet filter not apply to existing
> > c
On Thu, Feb 26, 2015 at 12:11:34PM -0500, Ted Unangst wrote:
> D'Arcy J.M. Cain wrote:
> > So why would packets continue to come in for 2.5 hours? My guess is
> > that the hacker is keeping the connection open and attacking over it
> > for 2.5 hours. Does the packet filter not apply to existing
D'Arcy J.M. Cain wrote:
> So why would packets continue to come in for 2.5 hours? My guess is
> that the hacker is keeping the connection open and attacking over it
> for 2.5 hours. Does the packet filter not apply to existing
> connections? Is there some way to change that behaviour?
Yes, that
I am running pf under NetBSD. As far as I know it is pretty much stock
OpenBSD pf. I asked this question in the NetBSD mailing list but
didn't gat a useful answer. I hope that someone here has a deeper
understanding of how pf works. Note the examples here are from
November last year but it is s
18 matches
Mail list logo
