[asterisk-users] Why Nat=yes Nat=no Option?

[Klaus Darilion]

Alex Balashov schrieb:
> Klaus Darilion wrote:
> 
>> This is a different scenario. In this case of course I want the public 
>> IP of the client, not of the load balancer. So, yes - in this case 
>> nat=no is useful for Asterisk. Nevertheless I ignore the IP provided by 
>> the client in the contact header completely - I always use the public IP 
>> of the client. Thus, in a loadbalancer setup I would configure the load 
>> balancer to ignore the advertised IP but use the "received" IP 
>> (implementation depends on the actual setup and used components).
>>
>> But as a basic rule - never ever trust the client. Storing and using the 
>> Contact provided by the client without any screening is dangerous.
> 
> Hm.  Interesting.  I am curious:  I agree that validation should be in 
> place, but why do you think that distrust of the client's contact URI 
> should be elevated to a "basic rule?"  What incentive do UACs have to 
> provide an illegitimate contact URI?  So the UAS will send responses 
> somewhere else, to another UAC that will reject the request because it 
> the dialog/transaction parameters do not match?  Man-in-the-middle 
> attacks from spoofed requests containing bogus contact domains?  That 
> can also be carried out with IP spoofing and other more traditional 
> means on the IP layer itself.

Nono - it is not about replies. it is about how incoming calls will be 
routed. Consider the following scenario, which is general for SIP 
proxies/PBXs:

Proxy (Asterisk, Openser ...) on IP 1.1.1.1

This proxy uses a gateway for PSTN located at 2.2.2.2 (either belongs to 
the proxy operator or is a gateway from a termination provider).

Very often the authentication between gateway and proxy is done based on 
IP address.

Now, the customers SIP client at 3.3.3.3 REGISTERs to the proxy with 
Contact: sip:0900123456 at 2.2.2.2.

If now there is an incoming call to the customer, the Proxy/Asterisk 
will send the INVITE to 2.2.2.2 = the gateway. The gateway happily 
accepts the call - as you see there is lots of fraud possibilities.

I did several security audits and many ITSPs were vulnerably for this 
kind of attack.

There are some methods to prevent this (like e.g. blacklists in openser) 
but a simple workaround which works fine in most ITSP setups is to 
ignore the user provided contact.


> But there is a difference between screening and distrusting by default, 

yes it is. But if the service is a POTS replacement and call forwarding 
will be done using a web interface it is easier to use the source 
IP:port instead of screening.

> particularly in scenarios where it may be explicitly undesirable for the 
> received IP to be used as the contact, such as in switch assemblies 
> where the signaling agents are partitioned somehow.

yes, yes. true. of course my example is for a very simple setup. But in 
such complex scenarios there is still fraud potential and 
screening/replacing the contact will not be done by the registrar, but 
by the ingress point into the SIP network (e.g. load balancer, outbound 
proxy, SBC, P-CSCF ... - call it what you want)


> I think the question here really is about good default behaviours and 
> assumptions, not whether validation for security is a good idea, though. 

I think the default value is ok. I works for 99% and it increases 
security. If someone has a big complex setup he probably has the 
knowledge of the nat= setting and knows the impacts of changing the value.

>   In the scenario in the last paragraph, I may wish to allow contact 
> addresses from other hosts on the same originating subnet but not on 
> foreign networks (validation), but not to use the received IP 
> (assumption of NAT).

If you have such requirements then change the nat= setting, screen the 
contact values and you are fine. But IMO nat=yes is a good default setting.

klaus