[asterisk-users] Why Nat=yes Nat=no Option?
klaus.mailinglists at pernau.at
Thu Nov 13 13:15:12 CST 2008
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
Proxy (Asterisk, Openser ...) on IP 22.214.171.124
This proxy uses a gateway for PSTN located at 126.96.36.199 (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
Now, the customers SIP client at 188.8.131.52 REGISTERs to the proxy with
Contact: sip:0900123456 at 184.108.40.206.
If now there is an incoming call to the customer, the Proxy/Asterisk
will send the INVITE to 220.127.116.11 = 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.
More information about the asterisk-users