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.<div>
<br></div><div>What do you think?</div><div><br></div><div>- Bruce<br><br><div class="gmail_quote">On Sat, Jul 23, 2011 at 12:07 PM, Paul Belanger <span dir="ltr"><<a href="mailto:pabelanger@digium.com">pabelanger@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On 11-07-23 11:48 AM, Patrick Lists wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/23/2011 04:00 PM, Paul Belanger wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A UAS rejecting an offer contained in an INVITE SHOULD return a 488<br>
(Not Acceptable Here) response. Such a response SHOULD include a<br>
Warning header field value explaining why the offer was rejected.<br>
</blockquote>
<br>
If the choice is to get hacked/DDOS'ed/etc or compliance with an RFC<br>
created by people who had no appreciation for the rather ugly world out<br>
there then why not throw the RFC out of the window and *not* reject an<br>
invite with a 488? It sounds like an interesting option to add to<br>
"10"/trunk. Better secure than compliant & sorry. Why not do a little<br>
Microsoft Embrace & Extent? Like e.g. Sonus and Cisco do with their<br>
interpretation of SIP.<br>
<br>
</blockquote></div>
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.<br>
<br>
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).<br>
<br>
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.<div class="im"><br>
<br>
-- <br>
Paul Belanger<br>
Digium, Inc. | Software Developer<br>
twitter: pabelanger | IRC: pabelanger (Freenode)<br>
Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a><br>
<br>
--<br>
______________________________<u></u>______________________________<u></u>_________<br></div><div><div></div><div class="h5">
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/<u></u>mailman/listinfo/asterisk-<u></u>users</a><br>
</div></div></blockquote></div><br></div>