<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffcc" text="#000099">
<br>
<br>
On 04/05/2011 03:06 PM, <a class="moz-txt-link-abbreviated" href="mailto:asterisk-users-request@lists.digium.com">asterisk-users-request@lists.digium.com</a>
wrote:
<blockquote
cite="mid:mailman.17730.1302030407.2723.asterisk-users@lists.digium.com"
type="cite">
<pre wrap="">Message: 12
Date: Tue, 5 Apr 2011 13:36:21 -0500
From: Sherwood McGowan <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:sherwood.mcgowan@gmail.com"><sherwood.mcgowan@gmail.com></a>
Subject: Re: [asterisk-users] Iptables configuration to handle brute,
force registrations?
To: Asterisk Users Mailing List - Non-Commercial Discussion
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:asterisk-users@lists.digium.com"><asterisk-users@lists.digium.com></a>
Cc: Bill Michaelson <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:bill@cosi.com"><bill@cosi.com></a>
Message-ID: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:BANLkTimQrbfMQpOiNRPHr_RjekOLbWPYGg@mail.gmail.com"><BANLkTimQrbfMQpOiNRPHr_RjekOLbWPYGg@mail.gmail.com></a>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Apr 5, 2011 at 1:31 PM, Bill Michaelson <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:bill@cosi.com"><bill@cosi.com></a> wrote:
</pre>
<blockquote type="cite" style="color: rgb(0, 0, 0);">
<pre wrap=""><span class="moz-txt-citetags">> </span> fail2ban might be good for this.
<span class="moz-txt-citetags">></span>
<span class="moz-txt-citetags">></span>
</pre>
</blockquote>
<pre wrap="">I think you missed the point, which is reducing the need for an external
application that searches logs in order to determine whether or not to block
an IP.
Why run fail2ban and add overhead when you can just do the same thing with
iptables itself?
</pre>
</blockquote>
I apologize for jumping into the middle without reading the
beginning of the discussion in which this central requirement to
avoid an external application was stated, as I now infer from Mr.
McGowan. Sorry for missing the point.<br>
<br>
I'll have to read up on fail2ban also. I thought it monitored the
tails of logs. I did not know that it searched them.<br>
<br>
My intent was to suggest using an established tool that would
consolidate the IP blocking and unblocking function for all ports
into a single application without imposing additional maintenance
overhead of new code for this purpose. Obviously, I'm not seeing
the big picture. Sorry for my myopic comments and for cluttering
the list. I won't make the mistake of offering worthless
contributions in the future.<br>
<br>
</body>
</html>