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 ; 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 ; 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" To: Jian Song 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" 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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" 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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 To: "Simon L. Nielsen" 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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" To: Luigi Rizzo 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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 To: "Simon L. Nielsen" 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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 ; 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 ; 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 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 To: Jian Song Cc: "Crist J. Clark" , 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 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 ; 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 ; 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 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 Cc: "Simon L. Nielsen" , 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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 To: Michael Sierchio Cc: "Simon L. Nielsen" , 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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 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 Cc: "Simon L. Nielsen" , 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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 ; 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 ; 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 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: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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