UDP packet spoofed LAN source address?

[Morgan Wesström]

On 2010-10-17 19:36, Robert Bonomi wrote:
>> From owner-freebsd-questions at 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?=
>>  <freebsd-questions at pp.dyndns.biz>
>> To: Nerius Landys <nlandys at gmail.com>
>> Cc: FreeBSD Mailing List <freebsd-questions at freebsd.org>
>> 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