Re: [Fail2ban-users] Modify fail2ban to issue a REJECT instead of a DROP

[Tom H. <to...@wh...>]

On 27/05/11 16:58, J4K wrote:
> On 05/27/2011 04:44 PM, Tom Hendrikx wrote:
>> On 27/05/11 15:52, J4K wrote:
>>> Cher tous,
>>>
>>> 	I've been running fail2ban on a server for several months now.  Its a
>>> great tool.
>>>
>>> However, it always bans the offending IP with a REJECT.  This offers no
>>> real protection against scanners. (A proper scanning piece of software
>>> would set the time out to 5 seconds & not leave it at ~100 seconds).
>>>
>>> >From what I understand in the case of a heavy DDOS would be to its
>>> detriment, as the upstream routers have to always keep the IP connection
>>> in their tables until the connection naturally times out.
>>>
>>> Using a REJECT instead allows upsteam routers to correctly mitigate the
>>> attack (clears the state from the routers tables thus leaving the router
>>> not prone to overload with massive connection tables), and allows
>>> legitimate IPs to receive an ICMP and then gracefully tear down the
>>> connection.
>>>
>>> With this in mind, I would like to change my installation of fail2ban to
>>> REJECT instead of DROP.   I think that the files to adjust are these:
>>>
>>> ./shorewall.conf
>>> ./iptables-multiport-log.conf
>>> ./iptables.conf
>>> ./iptables-allports.conf
>>> ./iptables-new.conf
>>> ./iptables-multiport.conf
>>>
>>>
>> In the action.d/iptables*.conf, you'll find some iptables command line.
>>
>> Some of these contain the uppercase word DROP. replace this with REJECT,
>> and restart fail2ban. It depends on which action(s) you have defined in
>> jail.conf, which action file you need to edit.
>>
>> The blacklist policy of shorewall is defined within shorewalls config
>> file, look for BLACKLIST_DISPOSITION in shorewall.conf
>>
>> Regarding the choice between DROP and REJECT, it depends on your
>> upstream if they handle this different. you should discuss with them if
>> they have any use for this.
>> At least, with REJECT you're sending traffic back to the attacker, thereby
>> - telling him you're still there, despite the attacks
>> - doubling  the traffic on the upstream routers (both the attackers
>> request and your answers need to be transferred).
>>
>> With DROP, you're not only starving the connection pool on the router
>> (which is your point), but also (depending on the attack tool used) the
>> connection pool of the attacker.
>>
>> In the worst case scenario, nobody gives a damn about what you are
>> sending back, and your server hosting provider sends you a nice fat bill
>> for extra traffic ;)
>>
> Hi Tom,
> 
>     Thank-you for the info. I shall amend accordingly.
> 
>     I disagree with the last point.  I think this argument is wrong:
> 
>     Tom wrote: In the worst case scenario, nobody gives a damn about what you are
>     sending back, and your server hosting provider sends you a nice fat bill
>     for extra traffic ;)
> 
> 
>     TCP SYN attack using spoofed IP addresses. 
> 
>     The target is not my machine.
>     The spoofed address is my machine IP.
>     Here is an except from a doc I just found, because I am too lazy on
> a Friday afternoon to write this out myself:
> 

<snip excerpt from url>

> http://www.chrisbrenton.org/2009/07/why-firewall-reject-rules-are-better-than-firewall-drop-rules/
> 
> Therefore, I argue that in the worst case scenario, the victim gives a
> damn about what you are
> sending back.  Sending a REJECT gives the victim are greater chance of
> mitigating the attack. 
> 

This is a specific type of attack, not even targetted on you, your IP is
simply abused by the attacker. I don't think you should change anything
in fail2ban based on a single incident. In stead, add the IP address of
the victim of the attack to your iptables config by hand, sending the
REJECT, or even a ICMP-host-unreachable back to that specific host.

The DROP/REJECT argument in the document you refer to might be a valid
point [*], but this choice should be in your default firewall setup,
f.i. your shorewall or iptables config. Fail2ban is targetted at
specific attacks, to which your standard setup has no answer ready.

If I understand the attack type correctly, the packets that flow from
the victim to you, typically go to high (1024+) port numbers on which no
daemons are listening. If you setup your firewall policy to REJECT all
packets targetted at non-listening ports in stead of DROPping them,
you're already done. Fail2ban never comes into play, and can't add
anything, since you're already returning the best response you can.

That being said, I'm quite curious at the fail2ban filter config that
you use for catching this kind of abuse in the first place.

[*] I'm no network or firewall expert, but quite fluent in linux sytem
administration in general. I had a nice
friday-afternoon-at-the-coffee-machine chat about your issue with one of
our network engineers, hoping to learn something new in the process. Our
discussion was based on the assumption that you were the victim, and you
tried to assist your upstream router in mitigating the attack.


PS: please keep replies on the list.

--
Kind regards,

		Tom