On Fri, 27 Feb 2015 11:46:33 + (UTC)
Stuart Henderson s...@spacehopper.org wrote:
On 2015-02-26, D'Arcy J.M. Cain da...@vex.net wrote:
On Thu, 26 Feb 2015 21:49:15 +0100
Otto Moerbeek o...@drijf.net wrote:
What are you looking for specifically? I thought I posted all
the relevant
On 2015-02-26, D'Arcy J.M. Cain da...@vex.net wrote:
On Thu, 26 Feb 2015 21:49:15 +0100
Otto Moerbeek o...@drijf.net 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
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 t...@tedunangst.com wrote:
Well, there's what should happen and what does happen. The behavior
described sounds a lot like it's keeping state. You can
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
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's
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:
On Thu, 26 Feb 2015 12:11:34 -0500
Ted Unangst t...@tedunangst.com 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
On Thu, 26 Feb 2015 12:11:34 -0500
Ted Unangst t...@tedunangst.com 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
On Thu, 26 Feb 2015 18:25:49 +0100
Otto Moerbeek o...@drijf.net 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
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 o...@drijf.net 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
On Thu, 26 Feb 2015 21:49:15 +0100
Otto Moerbeek o...@drijf.net 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
On Thu, 26 Feb 2015 15:22:36 -0500
Ted Unangst t...@tedunangst.com 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
D'Arcy J.M. Cain wrote:
On Thu, 26 Feb 2015 15:22:36 -0500
Ted Unangst t...@tedunangst.com 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 -
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.
On Thu, 26 Feb 2015 14:53:28 -0800
Philip Guenther guent...@gmail.com wrote:
On Thu, Feb 26, 2015 at 2:40 PM, Edgar Pettijohn
ed...@pettijohn-web.com 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
On Thu, Feb 26, 2015 at 2:40 PM, Edgar Pettijohn
ed...@pettijohn-web.com 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
On Thu, 26 Feb 2015 17:02:48 -0500
Ted Unangst t...@tedunangst.com 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
On 26 Feb 2015 at 23:16, D'Arcy J.M. Cain wrote:
On Thu, 26 Feb 2015 17:02:48 -0500
Ted Unangst t...@tedunangst.com 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.,
18 matches
Mail list logo
