From: "J. Bakshi" <joydeep@infoservices.in>
To: vesely@tana.it
Cc: netfilter@vger.kernel.org
Subject: Re: can we design a modified fail2ban ?
Date: Mon, 19 Apr 2010 08:46:00 +0530 [thread overview]
Message-ID: <4BCBCAF0.9010407@infoservices.in> (raw)
In-Reply-To: <4BC9DB51.6000407@tana.it>
On 04/17/2010 09:31 PM, Alessandro Vesely wrote:
> On 16/Apr/10 09:28, Jan Engelhardt wrote:
>> On Friday 2010-04-16 05:57, J. Bakshi wrote:
>>>
>>> fail2ban is a popular application to prevent the brute-force attack
>>> against ssh and also against imap, pop3 etc.. But fail2ban actually
>>> blacklist the IP and this is what fail2ban has been designed for.
>>> Now a days [nowadays] we can design the same with iptables.
>>
>> fail2ban has the ability - if I read its own short description right
>> - to
>> already use various blocking methods, including not only /etc/hosts.deny
>> but also iptables.
>
> I don't think it uses netfilter, though. I've read it has to restart a
> daemon in order to unlist an IP --not sure it's still so for the
> current version.
>
>>> I wonder if iptables can
>>> provide more liberty to match IP as well as port combination so that we
>>> don't need to blacklist the IP but only block the attempts from the IP
>>> based on port. Say more than 3 ssh attempt from IP xxx.xxx.xxx.xxx is
>>> detected and no more ssh attempt from the same ip is no more possible
>>> but pop and imap still works. Is it really possible with iptables ? Any
>>> idea ?
>
> The fail2ban doubts I mentioned above are the raison d'etre of ipqbdb.
> It matches IPs for responses, but it leaves it up to the sysadmin to
> configure iptables. For example, an admin may call the NFQUEUE rule
> only for ssh, so as to live pop3 and imap alone; or call NFQUEUE with
> a different queue-num for different services, so as to check client
> IPs against different (Berkeley) databases. Ipqbdb gives a random
> answer for, say, between 2 and 4 attempts, similar to the way stockade
> works. See http://en.wikipedia.org/wiki/Stockade_%28software%29 for a
> short description of such rate limiting approach,
> https://savannah.nongnu.org/projects/ipqbdb/ for ipqbdb itself.
>
> If you are specifically interested in blocking ssh, follow the
> "DenyHosts" link from the "See also" section of that wikipedia page.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hello,
thanks to all of you for your ideas and discussion. I am thank-full to
Richard Horton, who has shown me a great way to design iptables rules
which can work like fail2ban; not only that it can be extended in many
different ways for different purposes. Based on his suggestion I have
made these rule sets and it works as expected, i.e blocking ssh overflow
but the other services i.e. apache, imap etc.. are still accessible.
````````````
# mark packets
iptables -A INPUT -p tcp -m hashlimit --hashlimit-above 2/min
--hashlimit-burst 2 --hashlimit-name hashlimit -m state --state NEW \
-m tcp --dport $SSH_PORT -j MARK --set-xmark 0x1/0xffffffff
# blacklisting interval
iptables -A INPUT -p tcp --dport $SSH_PORT -m recent --rcheck --seconds
60 --name sshoverflow --rsource -j DROP
# blacklist port only based on IP
iptables -A INPUT -p tcp --dport $SSH_PORT -m mark --mark 0x1 -m recent \
--set --name sshoverflow --rsource -j DROP
# accept others
iptables -A INPUT -p tcp -m state --state NEW --dport $SSH_PORT -j ACCEPT
````````````
The only thing which is unusual here is the duration part. what ever
duration is defined here , practically becomes the double. I have tested
with *time* command with different values and every time I have found
that in practical duration becomes double than what is defined . Except
that the rule sets are working well.
Thanks
--
জয়দীপ বক্সী
next prev parent reply other threads:[~2010-04-19 3:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-16 3:57 can we design a modified fail2ban ? J. Bakshi
2010-04-16 7:28 ` Jan Engelhardt
2010-04-17 16:01 ` Alessandro Vesely
2010-04-17 17:58 ` Jan Engelhardt
2010-04-18 13:46 ` Alessandro Vesely
2010-04-18 16:44 ` Jan Engelhardt
2010-04-19 15:18 ` Alessandro Vesely
2010-04-19 3:16 ` J. Bakshi [this message]
2010-04-16 15:29 ` Pascal Hambourg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BCBCAF0.9010407@infoservices.in \
--to=joydeep@infoservices.in \
--cc=netfilter@vger.kernel.org \
--cc=vesely@tana.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox