[asterisk-users] Iptables configuration to handle brute, force registrations?

[Warren Selby]

On Tue, Apr 5, 2011 at 2:40 PM, Steve Edwards <asterisk.org at sedwards.com>wrote:
<snip>

>
> Are there possibly other drawbacks that I'm not seeing/remembering? I've
>> been running an iptables based setup for some time, never really jumped into
>> the fail2ban wagon
>>
>
> I've never used fail2ban either. I don't think it's advantages are
> functional, but the more somewhat intangible:
>
> ) It's included with several of the all-in-one Asterisk distributions.
>
> ) It's documented.
>
> ) It's more flexible
>
> ) Somebody else gets to enhance and maintain the code.
>
>
Fail2ban is "easy".  It's well documented and can be setup in just a few
minutes.  It's got an easy way to setup a whitelist that doesn't get banned
(so you don't ban yourself or any of your trunks, etc), and you can use it
for more than just "asterisk" blocking (I use it to monitor ssh and ftp as
well).  You can easily copy config files between systems, etc, plus all the
things you mentioned Steve.

That being said, it has several downsides too, i.e - whenever fail2ban is
restarted, the fail2ban chains are flushed (this is occurs on system
restarts as well).  If you need to make changes to your iptables setup (i.e
change an IP address of a service provider), you really want to unload
fail2ban, make your changes directly to iptables, then save your new
iptables setup, then restart fail2ban.  Otherwise you'll end up saving your
fail2ban chains in with your regular chains, and when you restart fail2ban,
it'll try to add new f2b chains.  And for some reason people seem to think
that it requiring Python is a bad thing.  But then again, I'm not running it
on small systems - most of the systems I've put it on have plenty of excess
cpu and memory, so that hasn't been an issue for me.

-- 
Thanks,
--Warren Selby, dCAP
http://www.selbytech.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20110405/648cb44a/attachment.htm>