Hi Robert,
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.
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.
Feel free to let me know if you need anymore clarity on this.
-Ryan
On 9/3/2014 8:49 AM, Robert Nystrom wrote:
Hello Everyone,
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.
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?
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.
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.
TIA, Rob
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
