[asterisk-users] Securing Asterisk - How to avoid sending, "SIP/2.0 603 Declined"

[Bruce B]

I agree with the ditching of RFC rules in favor of security. After-all, I am
amazed this is not already part of the SIP stack. Anyhow, as I was thinking
about the IPTABLES a messy solution can actually be built. If it's possible
to run a script - system() - before Answer() or ACK then it's possible to
run a a check on the IP and then add it to the outbound IPTABLE rules so the
packet when generated by SIP 2.0 doesn't get out of the system and stops at
the IPTABLES. This way only registered users have access and script kiddies
would never know that the IP is a SIP server.

What do you think?

- Bruce

On Sat, Jul 23, 2011 at 12:07 PM, Paul Belanger <pabelanger at digium.com>wrote:

> On 11-07-23 11:48 AM, Patrick Lists wrote:
>
>> On 07/23/2011 04:00 PM, Paul Belanger wrote:
>>
>>> A UAS rejecting an offer contained in an INVITE SHOULD return a 488
>>> (Not Acceptable Here) response. Such a response SHOULD include a
>>> Warning header field value explaining why the offer was rejected.
>>>
>>
>> If the choice is to get hacked/DDOS'ed/etc or compliance with an RFC
>> created by people who had no appreciation for the rather ugly world out
>> there then why not throw the RFC out of the window and *not* reject an
>> invite with a 488? It sounds like an interesting option to add to
>> "10"/trunk. Better secure than compliant & sorry. Why not do a little
>> Microsoft Embrace & Extent? Like e.g. Sonus and Cisco do with their
>> interpretation of SIP.
>>
>>  Personally, I don't see this as a solutions.  SIP already provides some
> ability to help with security (EG: TLS, SRTP) however that is basically the
> extent of it.
>
> The way I see it, it is outside the scope of SIP; it's a signaling
> protocol. If 'security' is really something you want to establish, many
> existing tools are available to handle this (EG: VPN, firewalls, encryption,
> etc).
>
> As previously mentioned, there is no easy, simple solution. Securing ones
> services takes work (and time) to do it right.  Most people don't want to
> spend the effort monitoring it.
>
>
> --
> Paul Belanger
> Digium, Inc. | Software Developer
> twitter: pabelanger | IRC: pabelanger (Freenode)
> Check us out at: http://digium.com & http://asterisk.org
>
> --
> ______________________________**______________________________**_________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>              http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>  http://lists.digium.com/**mailman/listinfo/asterisk-**users<http://lists.digium.com/mailman/listinfo/asterisk-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20110724/dd05c32c/attachment.htm>