From owner-freebsd-net Fri Apr 26 2:17: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 71AB037B41C; Fri, 26 Apr 2002 02:16:45 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g3Q9GKD24216; Fri, 26 Apr 2002 12:16:20 +0300 (EEST) (envelope-from ru) Date: Fri, 26 Apr 2002 12:16:20 +0300 From: Ruslan Ermilov To: Igor M Podlesny Cc: net@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Subject: Re: patch -- An ingress filter (RFC2827) Message-ID: <20020426091620.GA18917@sunbay.com> References: <20020414180447.A93954@mars-gw.morning.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <20020414180447.A93954@mars-gw.morning.ru> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 14, 2002 at 06:04:47PM +0800, Igor M Podlesny wrote: >=20 > Hello! >=20 > I'd like to know your opinion about this patch >=20 > http://www.morning.ru/~poige/patchzone/ingressfiltering.patch >=20 > which is mine attempt to implement an ingress filter being inspired by > RFC2827 "Network Ingress Filtering: Defeating Denial of Service Attacks > which employ IP Source Address Spoofing". >=20 > (http://www.ietf.org/rfc/rfc2827.txt) >=20 > It should be mentioned IMHO that this code makes another one in ip_input.= c a > kind of redundant -- I mean code checking/blocking the 127/8 network "on > wire". BTW, I suggest if not removing it completely then adding (sys)logg= ing > into, -- 127/8-spoofing certainly should be logged. :) >=20 > Another thing to pay an attention to: I deem it'd be better if a such fil= ter > was built-in into ip_fw.c, allowing such syntax for ipfw(8): >=20 > deny log ip from any to any in via fxp0 spoofed >=20 > But AFAIS in ip_fw.h: >=20 > #define IP_FW_F_IN 0x00000100 > ... > #define IP_FW_F_DME 0x40000000 /* destination =3D me */ >=20 > #define IP_FW_F_MASK 0x7FFFFFFF /* All possible flag bits mask */ >=20 > and u_int32_t fw_flg; >=20 > there is no free space for any additional flags... >=20 > So, I was a bit unsure whether should I expand fw_flg to u_int64_t, and do > any other extensions. For now I decided just to wrote something like a > draft, test it (it seems to be working ;), and asking you, people, for yo= ur > comments/ideas on it. >=20 > P.S. A bit more info on this patch is at http://www.morning.ru/~poige/pat= chzone/ >=20 Style comments: 1. There are many unnecessary whitespace changes. 2. Don't use the `register' keyword. 3. Double `const' doesn't do any good. (I was once confused about this to= o.) 4. ip_fw.c part of the patch has some cruft in it. Functional comments: 1. The use and externalization of ipfw_report() wasn't a good idea. Your patch makes ingressfilter dependent on `options IPFIREWALL' because ip_fw.c is only compiled if this option is present. 2. Comment for ipf_rtaddr() is bogus -- the function returns the pointer to an interface not address. 3. Function name is not good either, the more natural name would be ip_rtifp(). I would also suggest reimplementing the already existing ip_rtaddr() into ip_rtifp(), and implementing ip_rtaddr() in terms of ip_rtifp(). General notes: Ingress filtering in unacceptable in many cases. For example, our site is connected to two ISPs, ISP-A and ISP-B. Each ISP has allocated a network (NET-A and NET-B). Both channels are connected to a single gateway box, and are reachable through interfaces IF-A and IF-B, respectively. The `default' route on this box point to ISP-A through IF-A. Now imagine that you want to ping(8) one of our addresses in NET-B. This packet will appear on our gateway box through IF-B, but ingress filter would discard it because ip_rtifp() lookup would return the IF-A interface for your address (ip_src in the packet). We solve the problem with multiple default routes with `ipfw fwd'. All outgoing packets with the source IP address in NET-B we forward through the IF-B interface. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8yRrkUkv4P6juNwoRAo5oAJ9OJmLOs6m5DZUF7RqLj3O6eIPUEwCeLb3T aSYkgbQ/xKRgDWrNBwF6oTo= =Ovu3 -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message