From owner-freebsd-questions@FreeBSD.ORG Mon Oct 18 11:02:59 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37718106566B for ; Mon, 18 Oct 2010 11:02:58 +0000 (UTC) (envelope-from freebsd-questions@pp.dyndns.biz) Received: from smtprelay-h32.telenor.se (smtprelay-h32.telenor.se [213.150.131.5]) by mx1.freebsd.org (Postfix) with ESMTP id B24C28FC14 for ; Mon, 18 Oct 2010 11:02:57 +0000 (UTC) Received: from ipb4.telenor.se (ipb4.telenor.se [195.54.127.167]) by smtprelay-h32.telenor.se (Postfix) with ESMTP id 00B2BEB65B for ; Mon, 18 Oct 2010 13:02:55 +0200 (CEST) X-SENDER-IP: [85.226.59.55] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwxAAbGu0xV4js3PGdsb2JhbAChKgwBAQEBNS29JoVJBI1Pgmc X-IronPort-AV: E=Sophos;i="4.57,345,1283724000"; d="scan'208";a="1682619513" Received: from c-373be255.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.226.59.55]) by ipb4.telenor.se with ESMTP; 18 Oct 2010 13:02:55 +0200 Received: from [192.168.69.70] ([192.168.69.70]) by gatekeeper.pp.dyndns.biz (8.14.4/8.14.4) with ESMTP id o9IB2r4J082467; Mon, 18 Oct 2010 13:02:54 +0200 (CEST) (envelope-from freebsd-questions@pp.dyndns.biz) Message-ID: <4CBC295D.80002@pp.dyndns.biz> Date: Mon, 18 Oct 2010 13:02:53 +0200 From: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20101016 Lightning/1.0b3pre Thunderbird/3.1.3 MIME-Version: 1.0 To: Robert Bonomi References: <201010171736.o9HHaOc6003135@mail.r-bonomi.com> In-Reply-To: <201010171736.o9HHaOc6003135@mail.r-bonomi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org, nlandys@gmail.com Subject: Re: UDP packet spoofed LAN source address? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 11:02:59 -0000 On 2010-10-17 19:36, Robert Bonomi wrote: >> From owner-freebsd-questions@freebsd.org Sun Oct 17 09:04:59 2010 >> Date: Sun, 17 Oct 2010 16:06:12 +0200 >> From: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?= >> >> To: Nerius Landys >> Cc: FreeBSD Mailing List >> Subject: Re: UDP packet spoofed LAN source address? >> >> On 2010-10-17 06:56, Nerius Landys wrote: >>> This is really more of a networking question. >>> I'm wondering, in a typical scenario, for example my server is in a data >>> center with a typical colocation company. >>> >>> I am editing someone else's code, and this code handles incoming UDP >>> packets. The code handles UDP packets that have a source address being from >>> the LAN differently. It gives those packets special treatment. To check >>> whether a source address is a LAN address, it does the typical checks for >>> 10.0.0.0, 172.16.0.0, 192.168.0.0, 127.0.0.0, and it also checks every >>> assinged IP address with netmask to see if the source address on the UDP >>> packet came from that network. >>> >>> My question is - how possible (in these typical environments) is it to send >>> a UDP packet from far away that claims to have a source address being a LAN >>> address? Will such a packet typically make it to my server, or will a >>> router along the way stop it from arriving? >>> >>> Maybe, is there a simple 10 line C program that I can run and compile to >>> check if this scenario is possible on _my_ server? >>> >>> - Nerius >> >> Section 3 of RFC1918 (http://www.ietf.org/rfc/rfc1918.txt) states the >> following, and I quote: >> >> "Routers in networks not using private address space, especially those >> of Internet service providers, are expected to be configured to reject >> (filter out) routing information about private networks." >> >> This makes it _highly_ unlikely that your server will be hit by spoofed >> packets with a source address belonging to any of those private IP >> ranges. > > > Wrong _WRONG_, *W*R*O*N*G*!!!! > > THAT STATEMENT IS ABSOLUTELY INCORRECT. > > "routing informatin" works on _destination_ addresses *ONLY*. The RFC > languate means thhat you cannot -reach- an RFC-1918 *destination* address > over the public internet. because no routing for those DESTINATION addrsses > ic carried in the routing tables. > > > The rest of your analysis is similarly similarly flawed. > > As a matter of 'reality' *NOBODY* providing 'transit' services filters on > source addresses. > > 'Leaf' networks -- those with 'upstream' connectivity, but no 'downstream' > clients -- are well advised to -themseleves- implement ingress/egress > filtering at their border to block packets with 'inappropriate' _source_ > addresses. > > This blocking has to be done with considerable care, however. There are > some types of packets with 'un-routable' source addresses that *are* > absolutely legitimate, and tht you -have- to let through, or you will have > _major_ usability problems. > > > It is also a GOOD IDEA to filter traffic, in _and_ out, to certain ports > that are 'meaningful' *only* in a LAN environment. > > Robert, I have 3 comments: 1) RFC1918 does _not_ explicitly define routing information as only destination address. 2) Cisco recommend themselves to filter out RFC1918 based on _source_ address as described here: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml#ex If you're unfamiliar with Cisco's standard ACL syntax you can find it described here: http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00800a5b9a.shtml#standacl I don't claim that every router out there is configured this way (I have no way to verify that) but if you were employed by me and didn't follow basic Cisco recommendations, you would have to look for a new employer. 3) Shouting does _not_ make a false statement correct, even if I'm fully aware that there are people that believe so. Also, if you chose to argue in demeaning wordings like "your analysis is flawed", on a public mailing list, please atleast try to explain why the analysis is flawed. It's generally a very good idea to always provide references to what you claim if you want to be taken seriously. Just a friendly suggestion. Have a pleasant day. Morgan