[asterisk-users] Binding to 0.0.0.0 a security risk?

[Kevin P. Fleming]

On 02/08/2012 04:29 AM, Tony Mountifield wrote:
> In article<4F324279.70909 at Message-ID.plonk.de>,
> Jakob Hirsch<jh at plonk.de>  wrote:
>> Raj Mathur (राज माथुर), 2012-02-08 03:27:
>>> Packets not going out on the same interface as the one they were
>>> received on is a general IP issue, not just for connectionless
>>
>> Right, this was a inaccuracy. It should say "Asterisk does not reply
>> with the IP address with which packets were received". Asterisk (as most
>> applications) does not care about network interfaces, it just handles IP
>> addresses.
>>
>>> protocols.  The same behaviour can be seen with TCP too.  Unless you
>>> mangle with iptables or something, all information about the received
>>
>> A tcp connection is defined by the tuple (source host&port, destination
>> host&port), so if you write to a tcp socket, the kernel knows which
>> source address it has to use (and also which destination address, so the
>> application doesn't need to know that at all).
>> As there's no such relation in udp, the application has to provide the
>> destination address. The kernel then decides which source address to
>> use, as long as the application did not bind() to a specific address.
>
> This is why some UDP servers such as for DNS and NTP create a separate
> socket bound specifically to each local IP address. Then by sending a
> response via the same socket as the request was received on, it can be
> reasonably sure that the response will go out on the right interface.
>
> Maybe Asterisk does or could do the same. I haven't checked.

Well, 'Asterisk' is very broad, because really you are talking about 
each Asterisk module that can bind to sockets... and there are many of them.

In the case of chan_iax2, multiple bindings are possible, and manual 
configuration could be done to individually bind to each address you 
want to provide services on (even if some of those addresses are 
configured on the same interface). Responses will be sent over the same 
socket the request was received on.

In the case of chan_sip, only one UDP binding is possible (and one 
TCP/TLS binding). The code *could* be improved to handle multiple 
bindings, but it would be a large and invasive effort to do so.

I've had thoughts in the past about this, and it would even possible to 
make this automatic (for systems where virtual hosting is being done), 
and have sockets automatically bound to new IP addresses that are 
discovered at run time... but that would still require that chan_sip be 
improved to properly handle fully multi-threaded operation for all of 
its data structures and operations.

Alternatively, Olle Johannson has some patches that allow multiple 
instances of chan_sip to be loaded simultaneously; this could also be 
used to provide the sort of 'multiple binding' being talked about here.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org