Michael, Yes you can very easily permit multiple ranges of IP addresses. It uses a standard network masks for wildcards. A good basic reference is located here: http://www.voip-info.org/wiki/index.php?page=Asterisk+sip+permit-deny-mask
So if your users would always be coming from the same /24 network, you could setup something like: deny=0.0.0.0/0.0.0.0 permit=1.2.3.4/255.255.255.0 permit=4.3.2.1/255.255.255.0 Which would only allow registrations from users coming from 1.2.3.x or 4.3.2.x IP addresses. Granted if your users are always on the move and could be coming from almost anywhere, ACLs like that don't work too well. In that case, making sure your secrets are secure is the most important thing. And if you are permitting certain extensions remote access, you should always lock down local extensions to only register from your internal network: ie: deny=0.0.0.0/0.0.0.0 permit=192.168.1.0/255.255.255.0 While you should still have secure secrets with those as well, the above would prevent any access from off your network. And since the ACLs are configured on a per peer basis, you can define the rules specifically for each extension as you see fit. -James On 07/23/2010 03:49 AM, Michael wrote: > James > > Thanks for the explaination. It's good to better understand, how to counter > these attacks. > > I need to dig a bit into these asterisk ACL settings to see if it is > possible to give a range of peer IPs (as the external ones are on dynamic > IP). > > Otherwise, the adaptive ban also seems to work nicely. > > Cheers > > Michael > > James Babiak wrote: > > >> Michael, >> >> While obviously you'll want to block these attacks when you see them, as >> long as you use secure credentials for these remote extensions, you >> shouldn't have to worry too much about this attacker actually managing >> to compromise a SIP account. While you'll probably want to keep the >> extension numerical (though you don't need to), the password should be >> secure. That will eliminate 99% of attacks from being successful, >> limiting it just to a nuisance. >> >> While a dedicated and direct attack (for example: from an employee, >> etc.) against your PBX changes things a bit, almost all attempts are >> random people/groups on the Internet scanning to find any IP that's >> listening on 5060UDP. Once they find you, they will attempt to scan for >> easily compromisable accounts. >> >> These attackers are going to try very simple brute force attacks. They >> don't know if the extension is valid or not, so they aren't going to >> invest too much time trying to brute force every single possible >> password on every single possible account. Even one account could take >> eons to work through every possible combination of characters. They will >> most likely be trying the extension number for the password, 'password', >> 'secret', etc. In my opinion, the most common error in that record is >> using the extension number for the password (ie: 1234:1234), which >> happens all too frequently. >> >> You can also use Asterisk's built in peer ACL settings in the sip >> configuration file to prohibit registrations from non-specified IP >> addresses. You should always enable this for all local extensions, and >> if the remote phones will be coming from static IP addresses (or static >> netblocks) you can do that for them as well. If the latter is possible, >> then outside of a security vulnerability in the host system, Asterisk >> itself, or the client location, you can pretty much lock down the pbx >> from remote access attacks. >> >> And as discussed, you can use the firewall plugins to prevent connection >> attempts like this in the future. Including blacklisting the IPs you see >> trying to probe your system. >> >> -James >> >> On 07/20/2010 03:29 AM, Michael wrote: >> >>> I used the sip-voip plugin. It worked fine. However, security is not >>> enough, it seems to me. I am experiencing hacker attacks on the open port >>> 5060. >>> >>> So, I am wondering, what could be a better solution. Maybe would be >>> interesting to not use port 5060 for external devices. Then the firewall >>> would need to convert it to 5060 for incoming connections. Is this >>> possible? >>> >>> Thanks >>> >>> Michael >>> >>> P.S.: >>> Attacks come from 204.119.22.247, trying dozens of username/password >>> combinations per second. Just a matter of time until they find a valid >>> combination. At the moment, I blocked all external devices (there are >>> only two anyway). >>> >>> Philip Prindeville wrote: >>> >>> >>> >>>> On 7/11/10 12:13 PM, Lonnie Abelbeck wrote: >>>> >>>> >>>>> On Jul 11, 2010, at 1:04 PM, Philip Prindeville wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>> Pass EXT->Local | UDP | Source: 0/0 | Port: 10000-20000 >>>>>>> >>>>>>> (The port range here should exactly match your /etc/asterisk/rtp.conf >>>>>>> rtpstart-rtpend port range. Alternatively you can enable the >>>>>>> 'sip-voip' plugin, but personally I keep the 'sip-voip' plugin >>>>>>> disabled and use the above firewall rule.) >>>>>>> >>>>>>> Hope this helps. >>>>>>> >>>>>>> Lonnie >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> The problem with this is it opens up ALL ports 10000-20000, not just >>>>>> those that are being used by RTP. >>>>>> >>>>>> I really, really recommend using the SIP-VOIP plugin instead. >>>>>> >>>>>> -Philip >>>>>> >>>>>> >>>>>> >>>>> In practice I use a *much* smaller port range for RTP, rather than the >>>>> default 10000-20000. >>>>> >>>>> Opening a very small UDP port range for RTP is not a problem for me. >>>>> >>>>> Yes, I know you like the "sip-voip" plugin. :-) >>>>> >>>>> Lonnie >>>>> >>>>> >>>>> >>>> What's not to like about it? :-) >>>> >>>> More to the point, I like exposing only the barest minimal attack >>>> surfaces whenever I can. >>>> >>>> >>>> >>>> >>>> >>>> >>> > ------------------------------------------------------------------------------ > >>> >>> >>>> This SF.net email is sponsored by Sprint >>>> What will you do first with EVO, the first 4G phone? >>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>>> >>>> >>> >>> >>> > ------------------------------------------------------------------------------ > >>> This SF.net email is sponsored by Sprint >>> What will you do first with EVO, the first 4G phone? >>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>> _______________________________________________ >>> Astlinux-users mailing list >>> Astlinux-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to >>> pay...@krisk.org. >>> >>> >> >> > ------------------------------------------------------------------------------ > >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Astlinux-users mailing list > Astlinux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > pay...@krisk.org. > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Astlinux-users mailing list Astlinux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org.
