MikroTik

Posted: **Tue Nov 19, 2024 5:52 pm**

Good morning, I would like some assistance on how can I approach this issue. I have an NVR with some cameras behind a Mikrotik router and my problem is that the ISP provider is telling me that I'm exceeding the bandwidth plan they assigned to me. Even without me checking the NVR my WAN port does show at capacity and I assume I'm being DDoS'ed. Sadly the ISP does not provide DDoS protection so I am on my own.

I just assumed that whitelisting the public IPs from where I am accessing would be enough and deny any other traffic using the RAW rules so I don't get my WAN saturated. And it did removed the saturation, but now I can't see the NVR.

I'm attaching the configuration of my router (censoring some IPs, sorry if that's a problem). As it is right now, when the drop rule is off, I can check the NVR by inserting the public IP of the router on the browser but with the rule on, I can't. at least I get to keep access to the winbox, but yeah.

Posted: **Tue Nov 19, 2024 6:33 pm**

You're not being DDOSed but you are probably compromised, part of a botnet or being used for DNS amplification attacks or any combination of them.

You need to have a read of the manual - https://help.mikrotik.com/docs/spaces/R ... 574/Filter

Firstly though:

Disconnect your WAN interface from your router.

Remove all your current firewall rules, Raw and NAT included.

Sort out your interface lists with WAN and LAN and here's an example of a default firewall configuration.

/interface list member add list=LAN interface=bridge comment="defconf"
/interface list member add list=WAN interface=ether1 comment="defconf"
/ip firewall nat add chain=srcnat out-interface-list=WAN ipsec-policy=out,none action=masquerade comment="defconf: masquerade"
/ip firewall 
filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
filter add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"
filter add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"
filter add chain=input action=accept dst-address=127.0.0.1 comment="defconf: accept to local loopback (for CAPsMAN)"
filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
filter add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept in ipsec policy"
filter add chain=forward action=accept ipsec-policy=out,ipsec comment="defconf: accept out ipsec policy"
filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"
filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"

Connect up your WAN again and test your internet access. Then you can move on to your NAT rules.

Posted: **Tue Nov 19, 2024 6:42 pm**

That is why STEAM exists, and why folks should not attempt to host games at home. Bots will be knocking on the door day and night.

Suggestions
1. Limit users by source-address-list
a. users must have a static WANIP address
b. users must have a dynamic WANIP address ( and they must create a dydndns URL/name for their connection - many can be had for free )
c. If possible use NON STANDARD game PORTs for entry into the router and then remap them in dst nat rules to the gaming ports on your servers.
d. if limited number of users try using wireguard for them to access your LAN servers and not open up any game ports to the net

2. Petition Wireguard to add zerotrustcloudflare as an optional package as this bypasses one opening up their ports for such things.

Posted: **Wed Nov 20, 2024 8:32 pm**

Well, the issue that I have originally was resolved 'cuz on my wisdom I was allowing the incoming traffic from my IPs to the network but I wasn't allowing the traffic from my network to reach my IPs back.

I will notherless check out those sugguestions as they sound better than just "blocking all incoming traffic except the one from this couple IPs"

MikroTik

Whitelisting all traffic

Whitelisting all traffic

Re: Whitelisting all traffic

Re: Whitelisting all traffic

Re: Whitelisting all traffic