Hello, I would like to harden my asterisk 13.35.0 setup. I think that disabling some methods would higher security. I am using chan_sip, which method I need to disable with “disallowed_methods =” in sip.conf? Here is list of allowed methods on my server:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Thanks for you help!!
hmm you can probaly survive on just
INVITE, ACK, CANCEL, BYE
but removing any do not realy improve security
you will get 1000% more security by upgrading to Asterisk 20 and lates LTS version of Linux
as 13 is EOL and there have been found and fixed several security issues in the meantime
and if you want to harden your setup (apply to Asterisk 20 as well)
you should look at changing modules.conf from autoload to only load modules that you are using
and also look at asterisk.conf to ensure that asterisk do not run as root
yes and no
if DTMF is set to SIP INFO it will not work but if it set to rfc2833 it has no affect
but tell your bos that Asterisk 13 is not NIS2 complient
and trying to harden it by limiting the Allow list is like putting tape over the keyhole on a convertible from the 90s
if you want to secure it and still use Asterisk 13 you need to put a Kamailio in front
everything else is just a wast of time as it will not prevent hackers from taking over
even with Asterisk 20 I would still recoment Kamailio as an SBC
If your boss isn’t concerned about security, why should you be.
Although I have’t actually measured this, I would imagine 99%+ of attacks using SIP itself use the INVITE method. I’d also expect 100% of attackers to ignore Allow header, and I’m pretty sure that chan_sip doesn’t disable the method handler just because it is not allowed by Allow.
Privilege escalation attacks are more likely to be made on the various APIs than via SIP.
I think most attacks are toll fraud attempts, and running non-root doesn’t help, for those, as there is no privilege escalation
95% of those here will have forgotten, or never known, how to configure chan_sip and the remaining 5% have probably never used that option. I’m pretty sure it only changes the Allow line and doesn’t actually block them, but it isn’t worth my while checking the source code, to make sure…
I relented and looked at the code. It has no effect on what Asterisk accepts, or Asterisk’s Allow line. What it actually records is what Asterisk should not use outbound to the peer. Even then, it looks like it only affects two methods, MESSAGE (completely breaks it) and UPDATE (prevents changes being sent in early dialogue).
you have to prevent it on the clint side (not a solution)
are the XXX a public or private adress
what do you mean by the server do not support ipv6
witch os are you running this on
<RANT> tell your boss that he needs to come into to 21 centory and update and get on the ipv6 train </RANT>
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.