[asterisk-dev] bypass "contactdeny" option with nat=yes

[Klaus Darilion]

Am 04.05.2010 22:06, schrieb Paul Belanger:
>>> The solution is rather easy - in case of nat=yes the rcvd-address should
>>> be screened instead of the Contact URI.
>>
>> I agree. Contactdeny should be used for what we SAVE in the registry,
>> not only what we receive from the devices.
>
> Klaus: Are you able to attach a patch to your issue?

Actually I already have a patch, but I want to discuss the requirements 
to solve this issue before submitting the patch:

Requirements:
- a user should not be possible to register a contact which causes 
Asterisk to send requests to destinations which are forbidden
- a user should not be possible to detect those forbidden destinations 
(if possible)

Basically when solving the above requirements we have to differ 2 cases: 
nat=yes and nat=no

nat=no: Asterisk uses the address of the contact URI to send requests to 
the user (domains will be resolved during registration, not during 
request sending). So it is rather easy - the (optionally resolved) 
address will be compared against the permitted/denied contacts. In this 
case it is possible for a user to find denied IP addresses by just 
sending REGISTERs with Contact URIs starting by 1.1.1.1 up to 
255.255.255.255 - there is no way to prevent this.


nat=yes (this is what is usually used in typical customer<->VoIPprovider 
setups): nat=no: Asterisk uses the address from which the REGISTER 
request was received to send requests to the user. So, as the contact 
URI is never used for routing it makes no sense to screen the contact 
URI, only the address from which the REGISTER was received is verified 
against the permitted/denied contacts. Thus, even if a user sends 
REGISTERs with Contact URIs starting by 1.1.1.1 up to 255.255.255.255 
the user can not detect the forbidden destinations as only the 
src-address is checked. To detect the forbidden (sensitive) destination 
the user would need to use src-IP spoofing and both, the user's and the 
provider's ISP doe not prevent src-IP spoofing.


My Conclusion: In case of nat=no the current behavior is OK, in case of 
nat=yes the code should be changed to screen only the src-address of the 
request.

Any comments?

regards
Klaus

regards
Klaus