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:[EMAIL PROTECTED] 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 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
