Date: Wed, 11 Oct 2006 23:07:36 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: freebsd-net@freebsd.org Subject: Re: A way to disable reception of broadcast UDP? Message-ID: <Pine.BSF.3.96.1061011225059.9930B-100000@gaia.nimnet.asn.au> In-Reply-To: <20061011123403.GC47124@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 Oct 2006, Yar Tikhiy wrote: > Is there a well-known way for a UDP application to tell to the > system that it doesn't want to receive broadcast datagrams? E.g., > it would be very good for TFTP as required by RFC 1123. In general, > accepting broadcast UDP is a security flaw unless the higher proto > was specifically designed to work with broadcast. I know this doesn't address your question regarding the stack, but you could immediately benefit by having a firewall rule dropping all IP traffic on the broadcast address (and the network address) via the outside interface. Working here since '98, counting plenty of them. If you also wanted to limit UDP on the inside, that's just as easy. Cheers, Ian > SO_BROADCAST affects sending only, and not reception. Dropping > broadcast datagrams in the application is not an option because > they can't be told without bogus system-dependent hacks. I found > that our network stack would stop passing broadcast datagrams to > the application as soon as it bound the socket to a particular > address, but the status of this feature is unclear to me. By the > way, it's the reason for a funny problem: Samba's nmbd won't work > if started from inetd bound to a single IP. > > I can remember that, when T/TCP was there, the respective option > must have been enabled on a socket for reception and transmission, > for security reasons. (IIRC there was even a security incident > related to that.) Perhaps SO_BROADCAST should be given similar > semantics? It could improve security of many UDP applications. > > Any ideas? Thanks! > > -- > Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1061011225059.9930B-100000>