I don’t understand at which connections this rule applies and what is protecting from DDoS( it protects the router from WAN?, it protects an exposed web server i am running?)
I have seen that very often adds my laptop’s lan ip to attackers list and some public ip’s at ddos-target list. Shouldn’t be the opposite? Also these public ip’s that are added at target list, most of them are cdn ip’s from alibaba and cloudflare. They not seem to be harmful.
Hi,
it mainly protects an exposed server, but at the same time it tries to save resources, as attacking sources will be dropped in the prerouting chain, which saves resources on the router.
#this is jumping for all connections to the chain detect-ddos, I think you should just extend this rule, so that it only applies to your servers:
/ip/firewall/filter/add chain=forward connection-state=new action=jump jump-target=detect-ddos
#this is just checking the traffic if it is too much at once from the same src and dst IP, if it's OK, then jut jumps back to the forward chain:
/ip/firewall/filter/add chain=detect-ddos dst-limit=32,32,src-and-dst-addresses/10s action=return
It should be applied only to the inbound connections, so that your Laptop or whatever going out to the Internet doesn’t get dropped.
I would not worry about configuring this at all if I had no public services exposed to the Internet. If I had some, I would use some other firewall then MT…
BR
Woland
Good i understand now, but why adds my local devices as attackers and some CDN ip’s as targets? should i change the jump rule from forward to input?
[/quote]
It adds your local device because the parameters of the dst-limit should be adjusted to your servers capacity. It is not meant for your outgoing Internet connections, but they still jump to detect-ddos chain. Every new connection forwarded through the router is directed to that chain. You should therefore add a restriction like this if you have a web server with an IP 1.1.1.1 with a public service TCP80+443:
If you don´t have a public facing service (server), forget the whole DoS protection.
Ah almost forgot: changing the forward chain to input would be a terrible idea: input chain covers everything with the destination of the router itself.
@anav :
You can´t do anything against an attack on your side if the attack exhausts your bandwidth, that’s true. But: DoS protection is still important on the server side, to not let the servers resources exhausted. (Anyway there are some very expensive appliances, specifically made for this purpose and also any real NG firewall has many features for this.)
Exactly, and thus if serious use another appliance as an edge router.
Another thought is that if on is hosting something with a server, it best not be gaming server as that is archaic to do in this day and age.
There is a reason why people use steam and other professional setups.
First> If one has to run a server (expose something on the internet). Then at least attempt to ensure only allowed public IPs are permitted in the DST NAT Rules.
Stated differently, if you dont know who the users are, then one is a fool to open up ones internet …
Every public IP can be expressed as an IP address if static, OR a free dyndns URL name from many providers and the router resolves those to IP.
So, there is no reason not to have a closed access list so to speak.
The nice thing about MT devices when you apply a source address or list. PORTs no longer appear as closed, they do not appear at all on scans!
Second. Any server should required encrypted log in. If you are using user name and password without encryption man, you really are a sucker for punishment.
Third. Any server should be on its own VLAN and not be attached to any other devices. Internet ONLY.
Fourth. In addition to encrypted user name and login, an additional radius server login or something equating to two Factor authentication would be sweet!! If its website based what about a cpatcha etc as well.
Fifth. Either a built in Server mechanism that locks out the user after X attempts. If that is not possible then perhaps I recall there are ways to mechanism on MT to handle login attempts that do not work. This is where a capture and block for 72 hours kinda makes sense to me… If the user is legit then an email or text can be used to talk to the admin for a reset…