Hello,
I added port detection rules (TCP and UDP) to my rules - it works fine.
But how can I detect such a access trial like this one on the screenshot (when the source IP and port is always the same and there are about 10 requests per second)?
And would it be possible that the first block-time takes 24h and the second one 14 days?
what u need is blocking with address list and yes u can block it until 14 days
I tried it with “limit” seen here: http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter
I want that IP addresses which sends about 4 requests per minute will added to a blocklist of 1 hour.
The next step would be that when one IP address of this blocklist tries again after one hour that it will be added to a blocklist for 14 days.
Is this configuration possible?
Is there any calculation tool to rate/time,burst for the parameters for 4 requests per minute?
How will it be calculated?
I tried following rule.
When more that 2 requests/minute comes in (also tried with Dst. Limit for port an adress) the IP should be added to the Port_Attack_List.
But when I do not use the inverse feature the IP will be added after first request to the Port_Attack_List - moreover, I only set this rule for SYN packets.
Why must I set the inverse flag - it is not logically for me.
Can the limit measure the packets per time? In the statistics there are only written packets and not the packets per time.
Hi,
Let me try to explain “limit” attribute. It matches packets/bytes up to some limit. If you make rule like
add action=accept chain=input disabled=no limit=5,5 protocol=icmp
it means rule will allow up to 5 pings in 5 seconds. More then this will be processed by next rule, and for this case it is:
add action=add-src-to-address-list address-list=icmp-attack address-list-timeout=12h chain=input disabled=no protocol=icmp
So, after someone exceed 5 pings in 5 seconds, he gets on list. You can try this approach to achieve what you are up to.
Yes I tried 5/5 but per minute.
That means that when 6 packets come in per minute the IP should be added to the Port_Attack_List.
But when I test it the IP will be added after the first packet.
I also tried to set the Dst. Limit (5/5 min, dst. address and port) but it also was unsuccesssfull.
BTW, I use ROS 6.35.
And yes, I have a second rule which blocks the IP addresses which are on the Port_Attack_List on the WAN port.
The problem is that the first rule adds the IP addresses to early to the block list. 
But when I set the inverse flag, it seems to work - is this a bug in 6.35?
Lets try this way. You need 2 rules:
1st rule is matcher, like if someone gets up to 5 packets per second accept this traffic
2nd rule is drop traffic which excedes rule above ( add to address list).
One thing i overlooked:
If you are matching web traffic ( http/https) with such strict rule ( 5 packets in 5 minutes) its expected to get on list. One session carries more then 1 packet per whole session, so its ok to get blacklisted. You should add “connection state new” as additional descriptor.
I tried - it only works if I set the inverse flag for limit. If it is not set the IP will be added after first request to blacklist.
(Port 80 and 443 incoming are excepted from the blacklisting-rule)
Moreover there seems to be another bug.
I use the Dst-limit by “addresses and dst port”.
On the screenshot you see that anyone tries to connect to port 41482. Then another IP also tries to connect so the same target port and will be blacklisted after one request. The source port can be different and is not important for matching. But it would be logically if the second IP also has three retries before getting blacklisted. 
Looks like i’m starting to loose concept. Lets try to re-analyze all rules.
So, you are trying to catch traffic which is not traffic to ports 80 and 443? In that case, i guess you can do it like this:
chain=input action=accept connection-nat-state=!dstnat protocol=tcp dst-port=!80,443 limit=2/1m,0:packet log=no log-prefix=“”
This rule will accept up to 2 packets per minute, without burst allowed.
After this you should place a rule:
chain=input action=add-src-to-address-list connection-nat-state=!dstnat protocol=tcp dst-port=!80,443 address-list=Port_Attack_List log=no log-prefix=“”
This will match all traffic above limit, and place ip’s to address list.
Ok here my rules. The first blocks IPs from blacklist. The second tries to detect TCP requests on WAN port and the thirs should detect UDP requests on WAN port.
Your example accepts incoming requests, I drop it because I only want to count such requests so that I can blacklist the IP after 2 or three requests per minute.
PORT-ATTACK-DROP
chain=input action=drop src-address-list=Port_Attack_List in-interface=WAN log=yes log-prefix="PORT-Attack-DROP"
PORT-ATTACK-DETECT-TCP
chain=input action=add-src-to-address-list tcp-flags=syn connection-state=new protocol=tcp
address-list=Port_Attack_List address-list-timeout=1d in-interface=WAN
dst-port=!80,443 limit=!2/1m,2:packet dst-limit=2/1m,2,addresses-and-dst-port/1m40s log=yes
log-prefix="PORT-ATTACK-DETECT-TCP"
PORT-ATTACK-DETECT-UDP
chain=input action=add-src-to-address-list connection-state=new protocol=udp
address-list=Port_Attack_List address-list-timeout=1d in-interface=WAN
limit=!2/1m,2:packet dst-limit=2/1m,2,addresses-and-dst-port/1m40s log=yes
log-prefix="PORT-ATTACK-DETECT-UDP"
Then i do not understand what are you trying to accomplish. Two rules i have posted will do the next:
2. Will match and allow up to 2 packets per minute, if ports are not 80 and 443
3. Will match and add source to address list if traffic exceeds rule above
I didnt wrote 1st rule , because you have a that rule in your ACL. 1st rule manipulates desired list.
Host with IP X.X.X.X sends 1 request per minute to your public IP, on ports other then 80 and 443. He gets replies (or whatever) , and does not get to address list as long as he does not exceed 2 packets per minute on ports other then 80 and 443.
Same host starts to send more then 2 ( lets say 4 requests per minute) on ports other then 80 and 443. He gets above accepted limit, and 3rd rule puts him on address list. Your 1st rule drops that source IP.
Your example accepts incoming requests, I drop it because I only want to count such requests so that I can blacklist the IP after 2 or three requests per minute.
Yeah, i’m accepting, but just to certain limit and port rules.
EDIT:I think i got it. Use action passthrough instead of accept. This will only count traffic, then pass to next rule.
Like this:
1st rule, drop address list
2nd rule, match traffic up to some limit, then passthrough
3rd rule add to address list
4th rule drop traffic if ports are not 80 and 443.
In this case, traffic would be dropped in both cases ( address list and not on address list sources) but you will be able to add timeout if someone is aggressive. Is this what are you looking for?
1st rule, drop address list
2nd rule, match traffic up to some limit, then passthrough
3rd rule add to address list
4th rule drop traffic if ports are not 80 and 443.
In this case, traffic would be dropped in both cases ( address list and not on address list sources) but you will be able to add timeout if someone is aggressive. Is this what are you looking for?
Yeah, exactly this is it I am looking for. 
But per default my Firewall blocks everything and I have few rules that accept the traffic that is necessary.
If there are unallowed requests the last DROP rule drops the packet. And now I only want to count if the same IP will be dropped more that 2 or 3 times per minute (except port 80 and 443) and blacklist this IP. I only need to count the dropped packets because my firewall drops per default everything except the allowed rules - most configurations will be realized inversed.
Is it not possible to count dropped packets like it did my second and third rule?
I do not understand why only accepted or packets whick passed through can be counted.
I would suggest a set of rules like this:
drop src-address-list=blacklist
… (normal set of rules)
default drop (with match rate limit, e.g. 5/5)
src not in abusers → add src to blacklist timeout=short
src in abusers → add src to blacklist timeout=long
add src to abusers timeout=something like 1 week or 1 month - at least as long as the long blacklist
drop all
This covers all ports and protocols. If you want different thresholds for different protocols, then make a custom chain for each different type of threshold that you want, and have jump rules into these chains for each set of protocols that you want a particular blacklisting policy to follow.
e.g.:
chain=lowtolerance
rate limit=5/5 action=drop
src not in abusers → add src to blacklist timeout=1hr
src in abusers → add src to blacklist timeout=1week
add src to abusers timeout=1month
drop all
chain=hightolerance
rate limit=30/30 action=drop
src not in abusers → add src to blacklist timeout=24hr
src in abusers → add src to blacklist timeout=1week
add src to abusers timeout=1month
drop all
then set your jump rules in the main filter chain before the default drop:
protocol=icmp action=jump jump-target=hightolerance
protocol=tcp dst-port=22,25,53 jump-target=lowtolerance
protocol=udp dst-port=53 jump-target=lowtolerance
and finally - drop all
you could keep separate “abusers” lists for each chain if you like. Also note that the various “tolerance policy” chains don’t match protocols or ports because at that point you don’t care - whatever protocol or port it was that put them into this policy is good enough. Also Also note that as I wrote the jump rules, 22,25,and 53 all share a common “violations threshold” because all of them jump into that chain, so 3 smtp failures and three ssh failures in the same time period would be just as bad as 6 smtp failures.
Thanks, very much - I will try it.
No problem - I recommend you try the simple version first before getting crazy with the chains and multiple policy version.
- drop src-address-list=blacklist
… (normal set of rules)
2)default drop (with match rate limit, e.g. 5/5)
3)src not in abusers → add src to blacklist timeout=short
4)src in abusers → add src to blacklist timeout=long
5)add src to abusers timeout=something like 1 week or 1 month - at least as long as the long blacklist
drop all
The first rule is clear.
I do it before jumping to dmz_to_wan and so on. After the jumps to several zones I have the last drop for input,forward an output (I drop everything except the allowed rules in the different zones).
The second rule is clear - when the last drop (in my case) counts up to the limit a rule after this last drop makes no sense because it is not reachable.
So I thought to put the counting rule after the first rule.
1)PORT-ATTACK-DROP
chain=input action=drop src-address-list=Port_Attack_List in-interface=WAN log=yes log-prefix=“PORT-Attack-DROP”
2)PORT-ATTACK-DETECT-TCP
chain=input action=add-src-to-address-list tcp-flags=syn connection-state=new protocol=tcp
address-list=Port_Attack_List address-list-timeout=1d in-interface=WAN
dst-port=!80,443 limit=5/5m,2:,addresses-and-dst-port/1m40s log=yes
log-prefix=“PORT-ATTACK-DETECT-TCP”
How can I realize the rule 3) to 5)?
I do not understand the “src not in abusedusers” - how can I realize this if-else rule? Do you have please any example for this?
Abusers is a second list. That list is never used to test packets. It’s a “log” of everyone who has been blocked in the past week (if you set 1 week timeouts on the rule that adds IPs to it)
Blacklist is the active list that rule #1 uses to drop stuff.
Entries to this list get a short or long timeout, depending on which “add to blacklist” rule puts them there.
So rule 3 is the short blacklist (source didn’t get blocked recently) and rule 4 is the long ban (source already got blacklisted recently)
Rule 5 will be reached in either case because the action of “add to address list” doesn’t end processing the packet.
Rule 6 (I forgot to number it) is a simple drop rule.
Here’s the syntax for each of rules 3-5:
/ip firewall filter
add chain=input src-address-list=!abusers action=add-src-to-address-list list=blacklist timeout=24h
add chain=input src-address-list=abusers action=add-src-to-address-list list=blacklist timeout=1w
add chain=input action=add-src-to-address-list list=abusers timeout=1month
(I may have some errors in my syntax but I think you get the idea)
Thanks, now it’s clear.
But now I have one last logicaly problem.
chain=input action=add-src-to-address-list tcp-flags=syn connection-state=new protocol=tcp
address-list=Port_Attack_List address-list-timeout=1d in-interface=WAN
dst-port=!80,443 limit=2/1m,2:packet: log=yes log-prefix=“PORT-ATTACK-DETECT-TCP”
The limit-parameter only works if I set the inverse flag.
When I set 5/5 or 5/1 the limit is reached after the first request
If I set the limit to 2/2 and the inversed flag the IP will be added to list at the fourth request.
If I set the limit to 2/2 (withouth inversed flag) the IP will be added to list after the first request.
At my NAT rule for port 80 I only allowed 5 reuqests per minute (there it works fine with the limit 5/5) but it is also combined with the dst-limit - maybe this is reached first.
This is not consistent!
PS: Via Winbox it is not possible to set following limit: limit=2/30s,2:packet
I do not why this behaviaur is different between the NAT rule where the limit logically is correct and works an the limit in filter rules, where I must set the inverse flag to work correctly.
This is a bad idea. NAT isn’t supposed to be doing any access control. Leave that function in the filter.
I think you’re putting too many conditions on your rules. My suggested rules ONLY handle the actual blacklisting. The rate limiting is handled by the previous drop rule which drops traffic based on a rate limit - if this rule drops traffic, then it’s not going to reach the blacklist rules.
Now it works but when I activate the first drop rule for blacklisted IP addresses the other rules for extend the time to long won’t be reached any longer.
So it is only possible to extend the blacklist-time when the short time is expired and a new request from the same IP comes in.
Why it is not possible to add src addr to a list and after this the packet will be dropped - it is only possible either so add IP to list or drop the packet.
And the thing with the inversing flag is also clear. The rule waits until the limit is reached and when it is reached only then the next rule will be checked. Because of this behaviaur the limit in NAT rules also work (also when it is a bad idea).
Moreover, it would be a nice feature when the Address List also would show a column with the dst-port from the connection because of which the IP was put on the adress list. So it would be possible to see immediately which ports remote people try to reach.