From owner-freebsd-ipfw Mon Jan 20 15:19: 8 2003
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 49B8037B405
for <freebsd-ipfw@freebsd.org>; Mon, 20 Jan 2003 15:19:07 -0800 (PST)
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38])
by mx1.FreeBSD.org (Postfix) with ESMTP id B625643F43
for <freebsd-ipfw@freebsd.org>; Mon, 20 Jan 2003 15:19:06 -0800 (PST)
(envelope-from crist.clark@attbi.com)
Received: from blossom.cjclark.org (12-234-89-252.client.attbi.com[12.234.89.252])
by rwcrmhc51.attbi.com (rwcrmhc51) with ESMTP
id <2003012023190505100plhqqe>; Mon, 20 Jan 2003 23:19:05 +0000
Received: from blossom.cjclark.org (localhost. [127.0.0.1])
by blossom.cjclark.org (8.12.6/8.12.3) with ESMTP id h0KNJ5eq035871;
Mon, 20 Jan 2003 15:19:05 -0800 (PST)
(envelope-from crist.clark@attbi.com)
Received: (from cjc@localhost)
by blossom.cjclark.org (8.12.6/8.12.6/Submit) id h0KNJ5Pv035870;
Mon, 20 Jan 2003 15:19:05 -0800 (PST)
X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f
Date: Mon, 20 Jan 2003 15:19:05 -0800
From: "Crist J. Clark" <crist.clark@attbi.com>
To: Jian Song <Jian.Song@nominum.com>
Cc: freebsd-ipfw@FreeBSD.ORG
Subject: Re: How to do tcp payload validation
Message-ID: <20030120231904.GE34751@blossom.cjclark.org>
Reply-To: "Crist J. Clark" <cjc@FreeBSD.ORG>
References: <3E280776.3060502@nominum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3E280776.3060502@nominum.com>
User-Agent: Mutt/1.4i
X-URL: http://people.freebsd.org/~cjc/
Sender: owner-freebsd-ipfw@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-ipfw.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-ipfw>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-ipfw>
X-Loop: FreeBSD.ORG
On Fri, Jan 17, 2003 at 01:39:02PM +0000, Jian Song wrote:
> Hi:
>
> I need to do tcp payload validation. Specifically, the tcp stream I am
> looking at contains multiple messages. Each message has a two byte
> length header and immediately follow by the body. I would like to
> monitor the tcp traffic and intercept each message. If there is an
> error, I will send RSTs to both ends of the connection. While I can do
> a BPF tap and do ip reassembly and tcp processing myself, I was
> wondering whether this can be achieved through ipfw or ipfilter. I
> would like a TCP tap which pass tcp payload data to a user process for
> further validation. This way, I don't have to worry about matching ACKs
> and do TCP stream reassembly.
It sounds like what you really want is to just have a proxy running on
the firewall. Write a userland app that just handles the TCP
connection like any other daemon would. I don't see where a
kernel-level firewall would ever have to enter into it, unless for
some reason you cannot change the addresses used by the applications
at either end of the proxied connection. In that case, you can use
transparent proxying via 'fwd' or using natd(8) with ipfw(8), or
ipnat(8) with ipf(8).
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
From owner-freebsd-ipfw Mon Jan 20 16:43:59 2003
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id DD7C937B401
for <freebsd-ipfw@FreeBSD.ORG>; Mon, 20 Jan 2003 16:43:57 -0800 (PST)
Received: from arthur.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79])
by mx1.FreeBSD.org (Postfix) with ESMTP id 67D5D43EB2
for <freebsd-ipfw@FreeBSD.ORG>; Mon, 20 Jan 2003 16:43:57 -0800 (PST)
(envelope-from simon@arthur.nitro.dk)
Received: by arthur.nitro.dk (Postfix, from userid 1000)
id 4E04C10BF8B; Tue, 21 Jan 2003 01:43:54 +0100 (CET)
Date: Tue, 21 Jan 2003 01:43:54 +0100
From: "Simon L. Nielsen" <simon@nitro.dk>
To: freebsd-ipfw@FreeBSD.ORG
Subject: Sanity check in ipfw(8)
Message-ID: <20030121004353.GF351@nitro.dk>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="tmoQ0UElFV5VgXgH"
Content-Disposition: inline
User-Agent: Mutt/1.5.1i
Sender: owner-freebsd-ipfw@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-ipfw.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-ipfw>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-ipfw>
X-Loop: FreeBSD.ORG
--tmoQ0UElFV5VgXgH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hello
I recently found a problem where ipfw2 would allow the user to create
firewall rules that does not make sense like (notice udp and setup) :
ipfw add allow udp from any to any setup
I filed a PR (bin/47120) with a "fix" since I thought this was a trivial
change to check in the ipfw userland program for protocol when
specifying options like setup, icmpoptions and the likes. The fix is not
correct since I did not notice that it is possible to use multiple
protocols with or statements.
Now for the point :-)... Is it interesting to have the extra sanity
check in ipfw(8) ? If it is I will try to make a patch that actually
works, but if it isn't there is not much reason to make a new patch...
Btw. could a committer take a quick look at bin/46785 which is a trivial
change to ipfw -h.
--=20
Simon L. Nielsen
--tmoQ0UElFV5VgXgH
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+LJfJ8kocFXgPTRwRAjiRAKDFQbHvu/JsBWpaYfnnFeByUN1hKgCdFkQe
1Ocyh0OoEpye9wC5u/frlhk=
=W8z8
-----END PGP SIGNATURE-----
--tmoQ0UElFV5VgXgH--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
From owner-freebsd-ipfw Mon Jan 20 16:59:47 2003
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 5DAE937B401
for <freebsd-ipfw@FreeBSD.ORG>; Mon, 20 Jan 2003 16:59:46 -0800 (PST)
Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68])
by mx1.FreeBSD.org (Postfix) with ESMTP id F0F7443F13
for <freebsd-ipfw@FreeBSD.ORG>; Mon, 20 Jan 2003 16:59:45 -0800 (PST)
(envelope-from rizzo@xorpc.icir.org)
Received: from xorpc.icir.org (localhost [127.0.0.1])
by xorpc.icir.org (8.12.3/8.12.3) with ESMTP id h0L0xeTO072941;
Mon, 20 Jan 2003 16:59:40 -0800 (PST)
(envelope-from rizzo@xorpc.icir.org)
Received: (from rizzo@localhost)
by xorpc.icir.org (8.12.3/8.12.3/Submit) id h0L0xeho072940;
Mon, 20 Jan 2003 16:59:40 -0800 (PST)
(envelope-from rizzo)
Date: Mon, 20 Jan 2003 16:59:40 -0800
From: Luigi Rizzo <rizzo@icir.org>
To: "Simon L. Nielsen" <simon@nitro.dk>
Cc: freebsd-ipfw@FreeBSD.ORG
Subject: Re: Sanity check in ipfw(8)
Message-ID: <20030120165940.A65713@xorpc.icir.org>
References: <20030121004353.GF351@nitro.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030121004353.GF351@nitro.dk>; from simon@nitro.dk on Tue, Jan 21, 2003 at 01:43:54AM +0100
Sender: owner-freebsd-ipfw@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-ipfw.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-ipfw>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-ipfw>
X-Loop: FreeBSD.ORG
On Tue, Jan 21, 2003 at 01:43:54AM +0100, Simon L. Nielsen wrote:
...
> I recently found a problem where ipfw2 would allow the user to create
> firewall rules that does not make sense like (notice udp and setup) :
here "not make sense" means "they will never match any packet".
Now, no matter which checks you implement on a single rule, you can
still generate sequences of rules that never match any traffic. E.g.
ipfw add 100 skipto 102 ip from not 1.2.3.4 to any
# you get here with srcip = 1.2.3.4
ipfw add 101 skipto 102 ip from not 1.2.3.4 to any
rule 101 will never match. So...
> Now for the point :-)... Is it interesting to have the extra sanity
> check in ipfw(8) ? If it is I will try to make a patch that actually
No, i don't think it is useful to have extra sanity check in userland,
both for the above reason, and because these checks can be bypassed
using directly the kernel ABI.
There _are_ sanity checks in the kernel but these are only meant
to avoid crashing the box by pushing in random configurations. If
a rule matches no packets, tough -- it is not a problem of the firewall
per se and it does not cause the box to break.
cheers
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
From owner-freebsd-ipfw Mon Jan 20 17:20:52 2003
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 8B99937B401
for <freebsd-ipfw@FreeBSD.ORG>; Mon, 20 Jan 2003 17:20:50 -0800 (PST)
Received: from arthur.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79])
by mx1.FreeBSD.org (Postfix) with ESMTP id ED6FE43F3F
for <freebsd-ipfw@FreeBSD.ORG>; Mon, 20 Jan 2003 17:20:49 -0800 (PST)
(envelope-from simon@arthur.nitro.dk)
Received: by arthur.nitro.dk (Postfix, from userid 1000)
id 6A7B210BF8B; Tue, 21 Jan 2003 02:20:47 +0100 (CET)
Date: Tue, 21 Jan 2003 02:20:47 +0100
From: "Simon L. Nielsen" <simon@nitro.dk>
To: Luigi Rizzo <rizzo@icir.org>
Cc: freebsd-ipfw@FreeBSD.ORG
Subject: Re: Sanity check in ipfw(8)
Message-ID: <20030121012046.GG351@nitro.dk>
References: <20030121004353.GF351@nitro.dk> <20030120165940.A65713@xorpc.icir.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="tvOENZuN7d6HfOWU"
Content-Disposition: inline
In-Reply-To: <20030120165940.A65713@xorpc.icir.org>
User-Agent: Mutt/1.5.1i
Sender: owner-freebsd-ipfw@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-ipfw.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-ipfw>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-ipfw>
X-Loop: FreeBSD.ORG
--tvOENZuN7d6HfOWU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2003.01.20 16:59:40 +0000, Luigi Rizzo wrote:
> > I recently found a problem where ipfw2 would allow the user to create
> > firewall rules that does not make sense like (notice udp and setup) :
> here "not make sense" means "they will never match any packet".
Yes - i should properly have written that.
> Now, no matter which checks you implement on a single rule, you can
> still generate sequences of rules that never match any traffic. E.g.
Yes I know it is not possible to make it catch all eventualities.
> No, i don't think it is useful to have extra sanity check in userland,
> both for the above reason, and because these checks can be bypassed
> using directly the kernel ABI.
>=20
> There _are_ sanity checks in the kernel but these are only meant
> to avoid crashing the box by pushing in random configurations. If
> a rule matches no packets, tough -- it is not a problem of the firewall
> per se and it does not cause the box to break.
Ok - the extra check was only to make the user aware simple errors (that
ipfw1 did not allow). If you don't think the checks should be there then
I can live with that so the PR can be closed.
--=20
Simon L. Nielsen
--tvOENZuN7d6HfOWU
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+LKBu8kocFXgPTRwRAru0AKC33mu6QDZVqvak5GF5qs9eXnmdwQCgl+Aw
j3We+m4RkEDuIxejZPJQ9pI=
=CYL5
-----END PGP SIGNATURE-----
--tvOENZuN7d6HfOWU--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
From owner-freebsd-ipfw Mon Jan 20 17:32:25 2003
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 5320B37B405
for <freebsd-ipfw@FreeBSD.ORG>; Mon, 20 Jan 2003 17:32:24 -0800 (PST)
Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68])
by mx1.FreeBSD.org (Postfix) with ESMTP id E775443F13
for <freebsd-ipfw@FreeBSD.ORG>; Mon, 20 Jan 2003 17:32:23 -0800 (PST)
(envelope-from rizzo@xorpc.icir.org)
Received: from xorpc.icir.org (localhost [127.0.0.1])
by xorpc.icir.org (8.12.3/8.12.3) with ESMTP id h0L1WNTO084359;
Mon, 20 Jan 2003 17:32:23 -0800 (PST)
(envelope-from rizzo@xorpc.icir.org)
Received: (from rizzo@localhost)
by xorpc.icir.org (8.12.3/8.12.3/Submit) id h0L1WN1C084358;
Mon, 20 Jan 2003 17:32:23 -0800 (PST)
(envelope-from rizzo)
Date: Mon, 20 Jan 2003 17:32:23 -0800
From: Luigi Rizzo <rizzo@icir.org>
To: "Simon L. Nielsen" <simon@nitro.dk>
Cc: freebsd-ipfw@FreeBSD.ORG
Subject: Re: Sanity check in ipfw(8)
Message-ID: <20030120173223.A83271@xorpc.icir.org>
References: <20030121004353.GF351@nitro.dk> <20030120165940.A65713@xorpc.icir.org> <20030121012046.GG351@nitro.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030121012046.GG351@nitro.dk>; from simon@nitro.dk on Tue, Jan 21, 2003 at 02:20:47AM +0100
Sender: owner-freebsd-ipfw@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-ipfw.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-ipfw>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-ipfw>
X-Loop: FreeBSD.ORG
On Tue, Jan 21, 2003 at 02:20:47AM +0100, Simon L. Nielsen wrote:
...
> Ok - the extra check was only to make the user aware simple errors (that
> ipfw1 did not allow). If you don't think the checks should be there then
> I can live with that so the PR can be closed.
yes i honestly believe that it is better to avoid the userland code
being too smart. E.g. ipfw accepts things such as
allow ip from any to any 53
which matches both tcp and udp to port 53 -- ipfw1 did not accept
this, and needed two rules for this very common thing.
cheers
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
From owner-freebsd-ipfw Mon Jan 20 17:34:22 2003
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 9587337B401
for <ipfw@freebsd.org>; Mon, 20 Jan 2003 17:34:20 -0800 (PST)
Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5])
by mx1.FreeBSD.org (Postfix) with ESMTP id 7F4DA43F18
for <ipfw@freebsd.org>; Mon, 20 Jan 2003 17:34:19 -0800 (PST)
(envelope-from keramida@freebsd.org)
Received: from gothmog.gr (patr530-a059.otenet.gr [212.205.215.59])
by mailsrv.otenet.gr (8.12.6/8.12.6) with ESMTP id h0L1XxHI005527
for <ipfw@freebsd.org>; Tue, 21 Jan 2003 03:34:09 +0200 (EET)
Received: from gothmog.gr (gothmog [127.0.0.1])
by gothmog.gr (8.12.6/8.12.6) with ESMTP id h0L1XtTp061485
for <ipfw@freebsd.org>; Tue, 21 Jan 2003 03:33:55 +0200 (EET)
(envelope-from keramida@freebsd.org)
Received: (from giorgos@localhost)
by gothmog.gr (8.12.6/8.12.6/Submit) id h0L1Xt0d061484
for ipfw@freebsd.org; Tue, 21 Jan 2003 03:33:55 +0200 (EET)
(envelope-from keramida@freebsd.org)
Date: Tue, 21 Jan 2003 03:33:55 +0200
From: Giorgos Keramidas <keramida@freebsd.org>
To: ipfw@freebsd.org
Subject: bin/47196: ipfw won't format correctly output from 'ipfw show' command
Message-ID: <20030121013355.GC60387@gothmog.gr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-freebsd-ipfw@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-ipfw.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-ipfw>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-ipfw>
X-Loop: FreeBSD.ORG
The attached patch changes ipfw2 to print packet and byte counts with
a wider format, that fixes the problem described in PR bin/47196. Do
you think it's ok to commit this to CURRENT?
--- patch start ---
Index: ipfw2.c
===================================================================
RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.21
diff -u -r1.21 ipfw2.c
--- ipfw2.c 12 Jan 2003 03:31:10 -0000 1.21
+++ ipfw2.c 21 Jan 2003 01:30:03 -0000
@@ -823,7 +823,7 @@
printf("%05u ", rule->rulenum);
if (do_acct)
- printf("%10qu %10qu ", rule->pcnt, rule->bcnt);
+ printf("%20qu %20qu ", rule->pcnt, rule->bcnt);
if (do_time) {
char timestr[30];
@@ -1212,7 +1212,7 @@
return;
}
- printf("%05d %10qu %10qu (%ds)",
+ printf("%05d %20qu %20qu (%ds)",
d->rulenum, d->pcnt, d->bcnt, d->expire);
switch (d->dyn_type) {
case O_LIMIT_PARENT:
--- patch end ---
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
From owner-freebsd-ipfw Mon Jan 20 18:10:28 2003
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 146F437B401; Mon, 20 Jan 2003 18:10:27 -0800 (PST)
Received: from skywalker.rogness.net (skywalker.rogness.net [64.251.173.102])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 47A3043F5F; Mon, 20 Jan 2003 18:10:26 -0800 (PST)
(envelope-from nick@rogness.net)
Received: from skywalker.rogness.net (localhost [127.0.0.1])
by skywalker.rogness.net (8.12.5/8.12.5) with ESMTP id h0L2AeFH047917;
Mon, 20 Jan 2003 19:10:40 -0700 (MST)
(envelope-from nick@rogness.net)
Received: from localhost (nick@localhost)
by skywalker.rogness.net (8.12.5/8.12.5/Submit) with ESMTP id h0L2Acv4047914;
Mon, 20 Jan 2003 19:10:39 -0700 (MST)
X-Authentication-Warning: skywalker.rogness.net: nick owned process doing -bs
Date: Mon, 20 Jan 2003 19:10:34 -0700 (MST)
From: Nick Rogness <nick@rogness.net>
To: Jian Song <Jian.Song@nominum.com>
Cc: "Crist J. Clark" <cjc@FreeBSD.ORG>, <freebsd-ipfw@FreeBSD.ORG>
Subject: Re: How to do tcp payload validation
In-Reply-To: <20030120231904.GE34751@blossom.cjclark.org>
Message-ID: <20030120190425.Y47844-100000@skywalker.rogness.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-ipfw@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-ipfw.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-ipfw>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-ipfw>
X-Loop: FreeBSD.ORG
On Mon, 20 Jan 2003, Crist J. Clark wrote:
> On Fri, Jan 17, 2003 at 01:39:02PM +0000, Jian Song wrote:
> > Hi:
> >
> > I need to do tcp payload validation. Specifically, the tcp stream I am
> > looking at contains multiple messages. Each message has a two byte
> > length header and immediately follow by the body. I would like to
> > monitor the tcp traffic and intercept each message. If there is an
> > error, I will send RSTs to both ends of the connection. While I can do
> > a BPF tap and do ip reassembly and tcp processing myself, I was
> > wondering whether this can be achieved through ipfw or ipfilter. I
> > would like a TCP tap which pass tcp payload data to a user process for
> > further validation. This way, I don't have to worry about matching ACKs
> > and do TCP stream reassembly.
>
> It sounds like what you really want is to just have a proxy running on
> the firewall. Write a userland app that just handles the TCP connection
> like any other daemon would. I don't see where a kernel-level firewall
> would ever have to enter into it, unless for some reason you cannot
> change the addresses used by the applications at either end of the
> proxied connection. In that case, you can use transparent proxying via
> 'fwd' or using natd(8) with ipfw(8), or ipnat(8) with ipf(8).
Or if that doesn't tickle your tube, you can write a something
using divert(4) sockets and interface it with ipfw.
Nick Rogness <nick@rogness.net>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
From owner-freebsd-ipfw Mon Jan 20 21:56:13 2003
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 5B3F337B401
for <freebsd-ipfw@FreeBSD.ORG>; Mon, 20 Jan 2003 21:56:12 -0800 (PST)
Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18])
by mx1.FreeBSD.org (Postfix) with SMTP id B39A243EB2
for <freebsd-ipfw@FreeBSD.ORG>; Mon, 20 Jan 2003 21:56:11 -0800 (PST)
(envelope-from kudzu@tenebras.com)
Received: (qmail 71442 invoked from network); 21 Jan 2003 05:56:11 -0000
Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241)
by 0 with SMTP; 21 Jan 2003 05:56:11 -0000
Message-ID: <3E2CE0FA.2080301@tenebras.com>
Date: Mon, 20 Jan 2003 21:56:10 -0800
From: Michael Sierchio <kudzu@tenebras.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.2b) Gecko/20021016
X-Accept-Language: en-us, en, fr-fr, ru
MIME-Version: 1.0
To: Luigi Rizzo <rizzo@icir.org>
Cc: "Simon L. Nielsen" <simon@nitro.dk>, freebsd-ipfw@FreeBSD.ORG
Subject: Re: Sanity check in ipfw(8)
References: <20030121004353.GF351@nitro.dk> <20030120165940.A65713@xorpc.icir.org> <20030121012046.GG351@nitro.dk> <20030120173223.A83271@xorpc.icir.org>
In-Reply-To: <20030121004353.GF351@nitro.dk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-ipfw@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-ipfw.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-ipfw>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-ipfw>
X-Loop: FreeBSD.ORG
Luigi Rizzo wrote:
> On Tue, Jan 21, 2003 at 02:20:47AM +0100, Simon L. Nielsen wrote:
> ...
>
> >Ok - the extra check was only to make the user aware simple errors (that
> >ipfw1 did not allow). If you don't think the checks should be there then
> >I can live with that so the PR can be closed.
>
>
> yes i honestly believe that it is better to avoid the userland code
> being too smart. E.g. ipfw accepts things such as
>
> allow ip from any to any 53
>
> which matches both tcp and udp to port 53 -- ipfw1 did not accept
> this, and needed two rules for this very common thing.
Shi'ite! Documentation?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
From owner-freebsd-ipfw Tue Jan 21 9:52: 1 2003
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 9ECD237B401
for <freebsd-ipfw@FreeBSD.ORG>; Tue, 21 Jan 2003 09:52:00 -0800 (PST)
Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68])
by mx1.FreeBSD.org (Postfix) with ESMTP id 1B50843F13
for <freebsd-ipfw@FreeBSD.ORG>; Tue, 21 Jan 2003 09:52:00 -0800 (PST)
(envelope-from rizzo@xorpc.icir.org)
Received: from xorpc.icir.org (localhost [127.0.0.1])
by xorpc.icir.org (8.12.3/8.12.3) with ESMTP id h0LHpxTO062011;
Tue, 21 Jan 2003 09:51:59 -0800 (PST)
(envelope-from rizzo@xorpc.icir.org)
Received: (from rizzo@localhost)
by xorpc.icir.org (8.12.3/8.12.3/Submit) id h0LHpxE4062010;
Tue, 21 Jan 2003 09:51:59 -0800 (PST)
(envelope-from rizzo)
Date: Tue, 21 Jan 2003 09:51:59 -0800
From: Luigi Rizzo <rizzo@icir.org>
To: Michael Sierchio <kudzu@tenebras.com>
Cc: "Simon L. Nielsen" <simon@nitro.dk>, freebsd-ipfw@FreeBSD.ORG
Subject: Re: Sanity check in ipfw(8)
Message-ID: <20030121095159.A61957@xorpc.icir.org>
References: <20030121004353.GF351@nitro.dk> <20030120165940.A65713@xorpc.icir.org> <20030121012046.GG351@nitro.dk> <20030120173223.A83271@xorpc.icir.org> <20030121004353.GF351@nitro.dk> <3E2CE0FA.2080301@tenebras.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3E2CE0FA.2080301@tenebras.com>; from kudzu@tenebras.com on Mon, Jan 20, 2003 at 09:56:10PM -0800
Sender: owner-freebsd-ipfw@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-ipfw.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-ipfw>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-ipfw>
X-Loop: FreeBSD.ORG
On Mon, Jan 20, 2003 at 09:56:10PM -0800, Michael Sierchio wrote:
...
> > yes i honestly believe that it is better to avoid the userland code
> > being too smart. E.g. ipfw accepts things such as
> >
> > allow ip from any to any 53
> >
> > which matches both tcp and udp to port 53 -- ipfw1 did not accept
> > this, and needed two rules for this very common thing.
>
> Shi'ite! Documentation?
well it's in the ipfw manpage. I mention that checking for a
non-existing field (e.g. port number in a protocol that does not
have ports) will never match. The manpage describes the features,
but it cannot possibly mention all the ways in which these features
can be used.
cheers
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
From owner-freebsd-ipfw Tue Jan 21 10: 4:13 2003
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 3776D37B401
for <freebsd-ipfw@FreeBSD.ORG>; Tue, 21 Jan 2003 10:04:12 -0800 (PST)
Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18])
by mx1.FreeBSD.org (Postfix) with SMTP id 8200F43F43
for <freebsd-ipfw@FreeBSD.ORG>; Tue, 21 Jan 2003 10:04:11 -0800 (PST)
(envelope-from kudzu@tenebras.com)
Received: (qmail 72898 invoked from network); 21 Jan 2003 18:04:10 -0000
Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241)
by 0 with SMTP; 21 Jan 2003 18:04:10 -0000
Message-ID: <3E2D8B98.10809@tenebras.com>
Date: Tue, 21 Jan 2003 10:04:08 -0800
From: Michael Sierchio <kudzu@tenebras.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.2b) Gecko/20021016
X-Accept-Language: en-us, en, fr-fr, ru
MIME-Version: 1.0
To: Luigi Rizzo <rizzo@icir.org>
Cc: "Simon L. Nielsen" <simon@nitro.dk>, freebsd-ipfw@FreeBSD.ORG
Subject: Re: Sanity check in ipfw(8)
References: <20030121004353.GF351@nitro.dk> <20030120165940.A65713@xorpc.icir.org> <20030121012046.GG351@nitro.dk> <20030120173223.A83271@xorpc.icir.org> <20030121004353.GF351@nitro.dk> <3E2CE0FA.2080301@tenebras.com> <20030121095159.A61957@xorpc.icir.org>
In-Reply-To: <20030121004353.GF351@nitro.dk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-ipfw@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-ipfw.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-ipfw>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-ipfw>
X-Loop: FreeBSD.ORG
Luigi Rizzo wrote:
> On Mon, Jan 20, 2003 at 09:56:10PM -0800, Michael Sierchio wrote:
> ...
>
> >>yes i honestly believe that it is better to avoid the userland code
> >>being too smart. E.g. ipfw accepts things such as
> >>
> >> allow ip from any to any 53
> >>
> >>which matches both tcp and udp to port 53 -- ipfw1 did not accept
> >>this, and needed two rules for this very common thing.
> >
> >Shi'ite! Documentation?
>
>
> well it's in the ipfw manpage. ...
Yes, I guess it is. The problem is that the manpage attempts to
document two commands which are syntactically and semantically
different -- enough that they should be documented separately.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
From owner-freebsd-ipfw Wed Jan 22 10:12:39 2003
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id E9E7F37B401
for <freebsd-ipfw@freebsd.org>; Wed, 22 Jan 2003 10:12:29 -0800 (PST)
Received: from parati.mdbrasil.com.br (parati.mdbrasil.com.br [200.210.70.4])
by mx1.FreeBSD.org (Postfix) with SMTP id 78A5843ED8
for <freebsd-ipfw@freebsd.org>; Wed, 22 Jan 2003 10:12:27 -0800 (PST)
(envelope-from eksffa@freebsdbrasil.com.br)
Received: (qmail 97611 invoked by uid 85); 22 Jan 2003 18:12:25 -0000
Received: from eksffa@freebsdbrasil.com.br by parati.mdbrasil.com.br with qmail-scanner-1.03 (uvscan: v4.1.40/v4181. . Clean. Processed in 24.250774 secs); 22 Jan 2003 18:12:25 -0000
Received: from unknown (HELO freebsdbrasil.com.br) (200.210.42.5)
by parati.mdbrasil.com.br with SMTP; 22 Jan 2003 18:12:00 -0000
Message-ID: <3E2ECDDF.8080400@freebsdbrasil.com.br>
Date: Wed, 22 Jan 2003 14:59:11 -0200
From: Patrick Tracanelli <eksffa@freebsdbrasil.com.br>
Organization: FreeBSD Brasil LTDA
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20030104
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-ipfw@freebsd.org
Subject: PARENT dynamic rules
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-ipfw@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-ipfw.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-ipfw>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-ipfw>
X-Loop: FreeBSD.ORG
Hello there.
I am in the process of rewriting some set of firewall rules from IPFW1 to IPFW2, but i am getting a little bit confused by how the dynamic rules work now. I usually see PARENT, LIMIT and STATE labeled dynamic rules what i think is great for user level understanding of that is going on. I believe the PARENT and LIMIT rules work together, and for sure (i dont know the code deeply) they are responsible for solving the annoying "count" problems that used to happen on LIMIT rules (IPFW1).
But the PARENT rules doesnt seem to expire. I believe that they are PARENT rule created by every host connection to count the number of (child?) rules. I could see that PARENT 0 mean 1 rule by this src or dst address, PARENT 1 for 2 rules and on and on... in a certain moment the LIMIT rules are created (i would like to know exactly when too).
But what i really care the most is those PARENT not expiring. net.inet.ip.fw.dyn_count shows me the number of dyn rules active, that are relatively equiv. to the number of PARENT rules. I would like to understand it to decide about the racional number of max dyn rules i will allow...
The relevant part of my "ipfw -dea list" follows (little bit extense):
[some rules before]
00415 44 57336 deny log ip from { 10.0.0.0/8 or 192.168.0.0/16 or 172.16.0.0/12 or 255.255.255.255 or 0.0.0.0 or 0.0.0.0/8 or 169.254.0.0/16 or 224.0.0.0/4 or 240.0.0.0/4 } to any in via xl1
00705 0 0 deny log ip from any to { 10.0.0.0/8 or dst-ip 192.168.0.0/16 or dst-ip 172.16.0.0/12 or dst-ip 255.255.255.255 or dst-ip 0.0.0.0 or dst-ip 0.0.0.0/8 or dst-ip 169.254.0.0/16 or dst-ip 224.0.0.0/4 or dst-ip 240.0.0.0/4 } out via xl1
00805 0 0 allow gre from 200.187.144.243 to any via xl1
00810 0 0 allow gre from any to 200.187.144.243 via xl1
00900 0 0 check-state
00905 88 6560 allow icmp from 200.187.144.240/29 to any icmptypes 0,3,8,11 in via xl0 keep-state
00910 267 34169 deny log icmp from any to any
01005 5026 512672 allow udp from any to { 200.187.144.243 or dst-ip 200.187.144.246 } dst-port 53 in via xl1 limit src-addr 15
03005 0 0 deny log udp from any to 200.187.144.241 in via xl0
03010 22470 2695460 allow udp from 200.187.144.246 to any dst-port 53 in via xl0 keep-state
03015 680 51680 allow udp from 200.187.144.240/29 123 to 143.107.151.2 dst-port 123 in via xl0 keep-state
04005 72 7523 allow udp from 200.187.144.241 to 200.187.144.246 dst-port 53 out via xl0 keep-state
30005 71838 7509388 allow tcp from 200.203.206.9 to { 200.187.144.243 or dst-ip 200.187.144.246 } dst-port 22 in via xl1 setup keep-state
30010 0 0 allow log tcp from any to 200.187.144.246 dst-port 1723 in via xl1 setup limit src-addr 3
30015 209450 126520958 allow tcp from any to 200.187.144.243 dst-port 25,110,143 in via xl1 setup limit src-addr 10
30020 1547330 449685324 allow tcp from any to 200.187.144.243 dst-port 80 in via xl1 setup limit src-addr 15
30025 154 34692 allow tcp from any to 200.187.144.244 dst-port 21,20,80,443 in via xl1 setup limit src-addr 10
30035 4574 3121652 allow tcp from any 20 to 200.187.144.240/29 dst-port 1024-65535 in via xl1 setup keep-state
32005 1621 209550 allow log tcp from 200.187.144.246 to 200.187.144.241 dst-port 22 in via xl0 setup keep-state
32010 0 0 deny log tcp from any to 200.187.144.241 in via xl0
32015 684761 361115320 allow tcp from 200.187.144.246 to any dst-port 20,21,22,25,80,110,143,443 in via xl0 setup keep-state
[other rules]
65001 103980 49506837 deny log ip from any to any
65535 6 434 deny ip from any to any
## Dynamic rules (515):
01005 0 0 (0s) PARENT 0 udp 200.202.11.1 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 193.194.133.1 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.194.240.1 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 163.185.18.1 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.157.52.1 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 209.240.0.1 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.174.171.1 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 148.177.88.1 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.17.209.1 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.203.163.1 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.215.63.1 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.202.17.1 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.246.143.1 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.135.35.1 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.103.225.1 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 0 tcp 200.195.199.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.183.15.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 199.202.55.2 0 <-> 0.0.0.0 0
30025 0 0 (0s) PARENT 0 tcp 138.121.23.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.152.240.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.194.240.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.52.170.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.195.149.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 204.101.251.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.208.9.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 209.240.0.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 205.173.115.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.185.120.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 148.177.2.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 195.25.12.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.140.240.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.198.176.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.203.255.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 202.144.78.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 170.66.1.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 65.203.232.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.212.39.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.195.199.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 1 udp 80.15.238.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 1 udp 64.37.246.2 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 1 udp 213.61.6.2 0 <-> 0.0.0.0 0
30020 0 0 (0s) PARENT 4 tcp 200.222.81.3 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 143.166.224.3 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 213.158.0.3 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.52.170.3 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.250.225.3 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.202.7.3 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.184.26.3 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 170.66.1.3 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.195.149.3 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.160.2.3 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 193.194.133.3 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.203.161.3 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.181.14.3 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.208.9.3 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.229.135.4 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.218.161.4 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.203.161.4 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.175.5.4 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.175.11.4 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.219.150.4 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.52.170.4 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.195.149.4 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.182.104.4 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.185.44.4 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 216.194.70.5 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.219.150.5 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.52.170.5 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 209.140.200.5 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.228.85.5 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 193.194.133.5 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.223.0.5 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 1 udp 204.176.88.5 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 68.46.192.6 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 198.5.148.6 0 <-> 0.0.0.0 0
30020 511 30710 (176s) LIMIT tcp 200.181.178.85 21489 <-> 200.187.144.243 80
01005 0 0 (0s) PARENT 0 udp 200.193.55.7 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.195.192.7 0 <-> 0.0.0.0 0
30025 0 0 (0s) PARENT 0 tcp 211.66.88.8 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.203.191.8 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.215.189.8 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.203.206.9 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.176.131.9 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.175.8.10 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.152.240.10 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.184.26.10 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.176.2.10 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.192.208.10 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.230.199.10 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.250.190.10 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 216.73.83.10 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 216.73.84.10 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.204.0.10 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 1 udp 64.14.117.10 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.190.77.11 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.175.8.11 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.153.60.11 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.183.132.11 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.189.161.11 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.192.100.11 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.210.249.11 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.160.16.11 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.177.96.11 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.176.2.11 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.44.32.12 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.176.199.12 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 64.0.96.12 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.160.16.13 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.192.208.13 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 168.126.63.13 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.176.2.13 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 1 udp 208.185.54.14 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.176.2.14 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 61.9.208.15 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.190.77.15 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.198.100.16 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 0 tcp 200.176.3.18 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.225.93.18 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 0 tcp 200.176.3.19 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.196.89.19 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 0 tcp 200.176.3.20 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.152.240.20 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.52.208.20 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 205.173.114.20 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.201.164.20 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.192.161.20 0 <-> 0.0.0.0 0
32015 35 11686 (176s) STATE tcp 200.187.144.246 2344 <-> 200.215.181.155 80
01005 0 0 (0s) PARENT 0 udp 200.192.140.21 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.19.74.21 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 199.67.138.21 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.230.128.21 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.199.201.23 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.212.63.24 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 1 tcp 200.194.242.26 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.226.139.26 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.205.123.27 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.196.234.27 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.212.63.29 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.196.66.30 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.204.76.31 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 63.84.236.33 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.189.112.33 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.208.17.34 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.193.137.34 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.189.233.34 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.195.129.35 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.215.1.35 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 216.136.224.35 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 0 tcp 200.150.146.37 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.185.56.37 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.178.0.37 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.186.153.37 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 216.136.224.37 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.214.239.38 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.186.153.38 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 2 tcp 200.189.234.40 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.181.172.41 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.185.42.41 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 194.239.10.41 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.212.56.43 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.215.1.44 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 159.124.4.45 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.176.131.45 0 <-> 0.0.0.0 0
32025 1695 75410 (36s) STATE tcp 200.187.144.244 1697 <-> 207.46.106.61 1863
01005 0 0 (0s) PARENT 0 udp 200.197.200.47 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 0 tcp 200.192.6.48 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 66.218.71.48 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 0 tcp 200.194.242.49 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 66.218.71.49 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.168.32.49 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 12.107.122.50 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.230.199.50 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 66.218.71.50 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.162.192.50 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.162.192.51 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 66.218.71.51 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 66.218.71.53 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 66.218.71.54 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 66.218.71.55 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 66.218.71.56 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.245.207.57 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 209.225.52.57 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 66.218.71.57 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 66.218.71.58 0 <-> 0.0.0.0 0
32015 625 460414 (1s) STATE tcp 200.187.144.246 2487 <-> 200.155.1.42 80
01005 0 0 (0s) PARENT 0 udp 66.218.71.59 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 207.69.200.60 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 64.4.16.60 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 64.4.14.61 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 207.68.162.61 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 64.4.16.61 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 0 tcp 200.174.86.62 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.181.217.65 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.219.184.66 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 64.156.198.66 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 62.4.74.66 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.198.64.66 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.212.174.66 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 211.13.227.66 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 64.124.186.66 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 1 udp 213.41.76.66 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.224.140.66 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.184.42.67 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.199.252.68 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.203.207.71 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.208.29.72 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.203.179.72 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.181.68.75 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 196.27.25.75 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.202.193.76 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.246.143.77 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 208.184.139.82 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.198.64.83 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.181.178.85 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.250.77.85 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 196.27.25.85 0 <-> 0.0.0.0 0
30005 673 136592 (300s) STATE tcp 200.203.206.9 3263 <-> 200.187.144.246 22
01005 0 0 (0s) PARENT 0 udp 66.111.46.90 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 65535 udp 200.222.80.90 0 <-> 0.0.0.0 0
30025 0 0 (0s) PARENT 0 tcp 210.100.220.90 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.222.80.91 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.152.225.91 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 0 tcp 66.218.66.92 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.152.225.92 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 0 tcp 200.194.132.93 0 <-> 0.0.0.0 0
30020 129 6732 (156s) LIMIT tcp 200.181.178.85 22423 <-> 200.187.144.243 80
01005 0 0 (0s) PARENT 0 udp 200.30.0.97 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 66.28.12.98 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 211.169.245.98 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.225.157.99 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.221.11.100 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.221.11.101 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.181.178.102 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.221.11.102 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 63.119.175.103 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 64.41.192.103 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.221.11.103 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.225.157.104 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.103.142.109 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.211.224.110 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.251.233.114 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.161.30.118 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 66.187.232.120 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.193.144.121 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.250.83.129 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 1 udp 200.244.136.130 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.248.206.130 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.215.40.130 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.250.173.130 0 <-> 0.0.0.0 0
30025 0 0 (0s) PARENT 0 tcp 200.183.8.130 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 202.130.158.130 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 208.254.75.130 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 205.252.48.130 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 208.184.39.130 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 63.219.179.130 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 64.35.7.130 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 66.28.34.130 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 1 udp 63.218.7.130 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 1 udp 66.28.255.130 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 63.216.25.130 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.250.2.131 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.185.6.131 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.212.172.132 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 63.212.171.132 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.140.232.133 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 1 tcp 200.162.4.134 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 1 udp 200.162.4.134 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 216.121.96.134 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.198.188.134 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 62.42.230.135 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.204.0.138 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.250.90.139 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.175.89.139 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.175.5.139 0 <-> 0.0.0.0 0
32025 9 1070 (300s) STATE tcp 200.187.144.244 4398 <-> 193.206.158.6 80
01005 0 0 (0s) PARENT 0 udp 200.32.96.140 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 1 udp 212.62.17.145 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.219.165.147 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.190.99.147 0 <-> 0.0.0.0 0
30015 0 0 (19s) PARENT 1 tcp 200.183.200.149 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 198.81.9.149 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.162.4.150 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.225.157.150 0 <-> 0.0.0.0 0
30020 21 4414 (131s) LIMIT tcp 200.171.14.187 1664 <-> 200.187.144.243 80
30025 0 0 (0s) PARENT 0 tcp 200.161.145.152 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.247.217.154 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 204.176.177.155 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.211.8.160 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 130.54.210.161 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 66.28.47.162 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.223.209.163 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.212.186.163 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 2 tcp 200.194.134.165 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 0 tcp 200.194.134.167 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.251.232.167 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.247.247.171 0 <-> 0.0.0.0 0
32025 91 79746 (282s) STATE tcp 200.187.144.244 4392 <-> 131.252.208.32 80
01005 0 0 (0s) PARENT 0 udp 216.136.172.176 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 216.136.172.179 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 0 tcp 200.194.134.183 0 <-> 0.0.0.0 0
30020 0 0 (0s) PARENT 5 tcp 200.171.14.187 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.171.14.187 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 63.123.77.194 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 205.158.108.194 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 63.218.13.194 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.252.68.196 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 64.15.251.198 0 <-> 0.0.0.0 0
03010 3 397 (10s) STATE udp 200.187.144.246 1024 <-> 131.154.1.11 53
01005 0 0 (0s) PARENT 0 udp 205.138.3.200 0 <-> 0.0.0.0 0
30015 251 63044 (121s) LIMIT tcp 200.194.242.26 1338 <-> 200.187.144.243 25
30015 0 0 (0s) PARENT 4 tcp 200.103.136.202 0 <-> 0.0.0.0 0
03010 3 397 (9s) STATE udp 200.187.144.246 1024 <-> 193.205.245.8 53
01005 0 0 (0s) PARENT 0 udp 200.176.115.203 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 194.196.15.207 0 <-> 0.0.0.0 0
03010 3 869 (8s) STATE udp 200.187.144.246 1024 <-> 192.36.148.17 53
01005 0 0 (0s) PARENT 0 udp 66.187.233.210 0 <-> 0.0.0.0 0
32005 395 66466 (300s) STATE tcp 200.187.144.246 2504 <-> 200.187.144.241 22
03010 7 739 (9s) STATE udp 200.187.144.246 1024 <-> 192.106.1.31 53
03010 3 390 (9s) STATE udp 200.187.144.246 1024 <-> 192.12.94.30 53
01005 0 0 (0s) PARENT 0 udp 200.253.253.222 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.185.13.223 0 <-> 0.0.0.0 0
30025 0 0 (0s) PARENT 0 tcp 80.200.104.225 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.205.181.226 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 64.28.86.226 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 209.237.238.228 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 206.64.119.229 0 <-> 0.0.0.0 0
30015 41 16220 (300s) LIMIT tcp 200.183.200.149 59028 <-> 200.187.144.243 25
32025 35 15568 (296s) STATE tcp 200.187.144.244 4396 <-> 216.239.37.101 80
01005 0 0 (0s) PARENT 0 udp 216.46.98.240 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 194.73.82.242 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 206.99.44.245 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 63.212.171.245 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.208.16.246 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.140.237.246 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.247.217.248 0 <-> 0.0.0.0 0
32025 29 16794 (293s) STATE tcp 200.187.144.244 4395 <-> 130.94.185.117 80
01005 0 0 (0s) PARENT 0 udp 210.0.128.250 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 192.138.110.250 0 <-> 0.0.0.0 0
32025 81 72132 (291s) STATE tcp 200.187.144.244 4394 <-> 130.94.185.117 80
01005 0 0 (0s) PARENT 0 udp 143.166.82.251 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 0 tcp 200.204.183.252 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 1 tcp 192.138.110.252 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 143.166.82.252 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 205.152.37.252 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.246.0.252 0 <-> 0.0.0.0 0
30020 587 53450 (171s) LIMIT tcp 200.181.178.85 21003 <-> 200.187.144.243 80
01005 0 0 (0s) PARENT 1 udp 192.138.110.253 0 <-> 0.0.0.0 0
30015 0 0 (0s) PARENT 0 tcp 192.138.110.254 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 200.250.47.254 0 <-> 0.0.0.0 0
01005 0 0 (0s) PARENT 0 udp 206.99.44.254 0 <-> 0.0.0.0 0
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message