Join Log in
Score:1
Harry avatar Server

iptables hashlimit rate is not working as expected

in flag
Harry

I wrote the following firewall rule:

iptables -A INPUT -m hashlimit --hashlimit 1/hour --hashlimit-burst 3 --hashlimit-mode srcip,dstport --hashlimit-name ssh -j ACCEPT

I was expecting the burst to be recharged by 1 after one hour but actually it is recharged by one even sooner than one minute. I am sending messages from the same source IP and same destination port, so I was expecting it to accept 3 connections and then 1 per hour. But it is accepting more (one every 20-30 seconds). If I use --limit 1/hour I can observe the expected behaviour, but I need to use hashlimit because I need to filter per srcip and dstport. What am I doing wrong? Thank you!

192
0 + 0
it flag
parkamark
Try adding `-p tcp --syn --dport 22` to the rule - at the moment, you're matching everything where as you probably only want to be matching TCP SYN packets destined to port 22. If this is your intent, drop the `dstport` in the `hashlimit-mode` because it's superfluous.
0
Reply
Score:0
avatar Server
cn flag
Almost Anonymous

One problem is --hashlimit 1/hour should be --hashlimit-upto 1/hour if using -j ACCEPT

see man iptables-extensions

0 + 0
Score:0
Martin avatar Server
kz flag
Martin

I think you are running into expiring entries. An exempt from the manpage:

  --hashlimit-burst amount
         Maximum initial number of packets to match: this number gets recharged by
         one every time the limit specified above is not reached, up to this number;
         the default  is  5. When  byte-based rate matching is requested, this
         option specifies the amount of bytes that can exceed the given rate.
         This option should be used with caution -- if the entry expires, the burst
         value is reset too.

And the amount of time any hash entry is saved is specified with the option --hashlimit-htable-expire. I do not know what the default value for this entry is, but I guess it is a lot shorter than one hour, which would explain why you can connect faster than the expected amount.

You should consider tuning those values some more, allowing one per minute for example - in this case, your server only has to remember the last minute's IPs, and not the last hour worth of IPs.

0 + 0
Harry avatar
in flag
Harry
Thank you very much for your reply. I just tryed to put `--hashlimit-htable-expire 999999999` so that the expiration time should be of 16 minutes, but it is still accepting a connection every 20-30 seconds.
0
Reply
Martin avatar
kz flag
Martin
I tested this with ```--hashlimit-above 1/minute --hashlimit-burst 3 --hashlimit-htable-expire 300000``` and it worked as expected. So either your kernel is buggy or I have no clue why your example is not working... Please try it with 1/minute instead of 1/hour, and see if it is still the same.
0
Reply
Harry avatar
in flag
Harry
I tried using what you suggested but it is still not working as expected (still accepting 1 connection every ~30 seconds). Anyway I would need to limit connections a lot more than 1/minute, so I'd need a very big number as expire value since it is in milliseconds.
0
Reply
Martin avatar
kz flag
Martin
is there a reason why you prefer hashlimit to limit ? if the latter works as expected, I'd recommend using this instead. It is quite hard to figure out why it is not working, I think we already ruled out usage errors - the way you use it should work,, Since it doesn't - use something else instead.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.