<div dir="ltr">Thanks everyone for their insight and advice. This was valuable.<div><br></div><div>Thanks Ryan, Mark, Tim, Russ, Jim, Patrick.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 3, 2014 at 11:15 AM, Ryan Delgrosso <span dir="ltr"><<a href="mailto:ryandelgrosso@gmail.com" target="_blank">ryandelgrosso@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi Robert,<br>
Nope no good reason not to ACL that interface. If its setup
according to Oracle BCP then you would have the sip-interface set to
agents-only and have an agent defined for the other end of the trunk
and then an ACL entry setup for that agent. This would result in
traffic from anywhere but that agent just being dropped. This would
have no impact on distributed media from the peer, so no need to
build an ACL entry or account for media sending endpoints, that will
be handled dynamically by the SBC. <br>
<br>
On the second issue, properly ACL'ing the trunking interface will
mitigate these issues however if there are other interfaces that DO
need to listen publicly to anything then its best to set the sip
interface on those to only allow registered endpoints and then tune
your demotion policies to properly punt offenders to a blacklist.
You are correct about this sort of thing being a gateway to CPU
issues, and proper use of the deny list function is key to
mitigating that exposure. The deny list is implemented in the NIU so
stopping offenders there will preserve CPU cycles. <br>
<br>
Feel free to let me know if you need anymore clarity on this. <br>
<br>
-Ryan<br>
<br>
<div>On 9/3/2014 8:49 AM, Robert Nystrom
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hello Everyone,
<div><br>
</div>
<div>New to the list, so please take it easy on me :-) I'm
reviewing the security configuration for a customer that is
using ACME SBC for SIP trunk to their carrier, and have some
questions. I thought you guys on the list would have a lot of
experience with ACME security architecture and best practices
recommendations.</div>
<div><br>
</div>
<div>First: Customer's ACME is visible from public Internet on
udp/5060, and SIP trunk is only being used to interconnect to
SIP trunk carrier for inbound and outbound dialing. I've
tested the SBC from the Internet and it actually responds to
INVITE and REGISTER messages (with 403 Forbidden). They are
alsonot supposed to be allowing any REGISTER for remote user
MD5 Digest Authentication - but it does respond. Question:
Is there any operational need or business usage case that you
would see that would make this setup a good idea? Because
this appears to be a very risky and poor security. I would
think that the SBC needs to be silently discard/drop any SIP
message rather than respond, as this increases the visible
footprint and encourages malicious actors / scanning tools.
Would think that having ACLs that only permit traffic to/from
the carrier's SBC would be the best configuration. Is their
an opposing view?</div>
<div><br>
</div>
<div>Second: I have written some SIP software that sends
malformed message headers, and have noticed that the SBC
responds with different errors other than 403 Forbidden when
headers have unexpected values. For example, when I send an
INVITE with extra CRLFs, I get a 400 CSeq missing header.
When I send a Contact header of "None", I get 400 Invalid
Contact. This leads me to believe that the SBC sip parser is
parsing all of the SIP message rather than always sending a
403 Forbidden to an IP address sourced from the untrusted
public Internet...this also seems to be very risky. Is there
a specific security configuration with the policies that you
would recommend? It seems like this introduces the risk of
DoS and fuzzing attacks if the SBC is parsing more of the SIP
message rather than just dropping the message based on invalid
source IP. Could lead to cpu and memory issues if the queues
are filled from invalid and fuzzed traffic.</div>
<div><br>
</div>
<div>I have read the Oracle SCME Security Guide (July, 2014),
and learned rudimentary that there are IP ACLs, realm trust
level settings, and traffic queues. But really looking for
practical advice based on experience with ACME. This customer
takes security very seriously, and it is informative of them
to see how the SBC responds, black box, to attacks from the
outside. I'd like to recommend security settings. It seems
like the best would be just to drop/discard any SIP message
from the public Internet...but wanted to get the expert's
opinion on ACME.</div>
<div><br>
</div>
<div>TIA, Rob</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
VoiceOps mailing list
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
<br></blockquote></div><br></div>