* You are viewing the archive for February 25th, 2012

app_rpt and chan_usbradio removal from trunk

On Thu, Feb 23, 2012 at 11:56:12AM -0600, Josh Freeman wrote:
> Just to inform the list -
>
> App_rpt and chan_usbradio are still regularly used and maintained, but
> now live in a repository at ohnosec.org along with the forked-off builds
> of Asterisk 1.4 and Zaptel that are required to have them work properly.
>
> I’m told there is some fundamental incompatibility between canonical
> Zaptel/DAHDI and the radio application that can’t be effectively worked
> around, or would take more effort than it would be worth to fix and keep
> up with DAHDI changes. This was the motivation for forking Asterisk and
> maintaining a separate codebase.

I’d appreciate some more details. Is it related to dahdi_cfg? pciradio
(is it still used?) ?

Bug reports would be welcomed.

SIP and NAT best practices in Asterisk

What should I do in order to to be as secure as possible and with “clean” logs?

Well, for an article about Asterisk security best practices, consider reading this article.

About SIP and NAT best practices, in short, the simplest answer is to always use ‘nat=yes’ (or at least ‘nat=force_rport’ in recent versions of Asterisk that support it), until you come across a SIP endpoint that fails to work properly with that setting. If you do come across such an endpoint, try hard to get it to work with that setting; if you can’t, then set ‘nat=no’ for that endpoint, and understand that the endpoint’s name could be discoverable using the attack methods previously disclosed.

If the endpoint’s configuration is suitably locked down (permit/deny, for example) this may not be a concern for you. If it’s not locked down (for example, if it has to register to your Asterisk server from random locations), then the next step would be to seriously consider requesting that the user of that endpoint consider switching to some other SIP endpoint.

Finally, to date, the only endpoints that have been identified that do not work with Asterisk’s ‘rport’ handling forced upon them are Cisco phones. In that case, you could consider using a Digium IP phone in order to take the most out of your Asterisk Installation.

 

(Thanks to Kevin P. Fleming for his elaborated answers on the Asterisk Mailing List)