[asterisk-users] "Register Attacks" End of ENUM ?

[Motiejus Jakštys]

On Sun, Jul 25, 2010 at 3:11 AM, Norbert Zawodsky <norbert at zawodsky.at> wrote:
> Hello again!
>
> after it being "relatively quiet" her for the last weeks, my Astrerisk
> server was the target of 3 of that nasty REGISTER attacks during the
> last days. While I can see not much danger coming from these attacks (I
> use very long, complicated random generated passwords), they are still
> very annoying, because they always lead to my server crashing. (I think
> it's some out of memory condition because its a very tiny server. Slow
> CPU, not much memory...)
>
> Now, as a quick-fix I had the idea to use iptables'  --scr-range rule
> to close the whole adress-range from 0.0.0.0 to 255.255.255.255 EXCEPT
> that small range of my VOIP provider. This should keep out all attacks.
> (At least, I think so). But I'm not a iptables-guru at all !!
>
> But the side-effect would be that ENUM wouldn't work any more.
>
> I still think that the best, clean solution would be, if some mechanism
> was built into asterisk (maybe sip.conf was the right place ???) where
> you could configure from which source (ip-range, ethernet-port or
> whatever...) asterisk  will accept or ignore REGISTER requests. For
> example, in my small installation, valid REGISTERs can only originate
> from the internal LAN, never from the "outside world". So I could
> restrict the range for valid REGISTERs to 192.168.1.0/24.
>
> AFAIK incoming calls would start the conversation with INVITE and those
> still may come from "the outside" (=any IP adress).
>
> Another thought makes me feel nervous: What if some sick brain gets the
> idea of sending INVITEs instead of those REGISTERs...
>
> Norbert

If all you need is block the SIP traffic from external sources, you
may do the following:
# iptables -A INPUT -s 192.168.1.0/24 -p udp --dport 5060 -j ACCEPT
# iptables -A INPUT -p udp --dport 5060 -j DROP

# iptables-save > /etc/iptables.up.rules
and somewhere in init scripts (depending on your lsb release):
# iptables-restore < /etc/iptables.up.rules

fail2ban is more suitable if you have external environment (plus it's
more complicated than just these 2 rules).