Lots of crap in Firewall logs - request rules review please?

genki · October 23, 2020, 1:30pm

Hi,
I have configured my new HAP AC2 and it’s fantastic.
Looking for some help with a review of my Firewall rules please?

The problem I am having is that I see a lot of blocks from my Xfinity Cable internet connection on ether1 and I’m wondering how do I fix this?

These are not IP Addresses on my network, they appear to be bridging in from my Xfinity connection, which is a Motorola Modem connection to the HAP AC2 on port ether1.

04:46:53 firewall,info Invalid Input Chain FW Rule #2 : in:ether1 out:(unknown 0), src-mac 00:01:5c:74:96:46, proto TCP (RST), 108.177.111.138:443->76.25.57.137:62661, len 40
04:47:22 firewall,info Invalid Input Chain FW Rule #2 : in:ether1 out:(unknown 0), src-mac 00:01:5c:74:96:46, proto TCP (RST), 45.135.232.39:47625->76.25.57.137:1522, len 40
04:47:53 firewall,info Invalid Input Chain FW Rule #2 : in:ether1 out:(unknown 0), src-mac 00:01:5c:74:96:46, proto TCP (ACK,FIN,PSH), 17.125.250.130:443->76.25.57.137:58857, len 83
04:47:55 firewall,info Invalid Input Chain FW Rule #2 : in:ether1 out:(unknown 0), src-mac 00:01:5c:74:96:46, proto TCP (RST), 193.27.228.172:53295->76.25.57.137:17223, len 40
04:48:02 firewall,info Invalid Input Chain FW Rule #2 : in:ether1 out:(unknown 0), src-mac 00:01:5c:74:96:46, proto TCP (RST), 45.129.33.57:55506->76.25.57.137:7769, len 40
04:48:30 firewall,info Invalid Input Chain FW Rule #2 : in:ether1 out:(unknown 0), src-mac 00:01:5c:74:96:46, proto TCP (ACK,FIN,PSH), 17.125.250.130:443->76.25.57.137:58857, len 83
04:48:42 firewall,info !public_from_LAN forward: in:bridge out:ether1, src-mac bc:a8:a6:72:9d:72, proto UDP, 192.168.1.250:60112->172.29.0.1:53, len 138
04:48:42 firewall,info Invalid Input Chain FW Rule #2 : in:ether1 out:(unknown 0), src-mac 00:01:5c:74:96:46, proto TCP (RST), 45.129.33.24:53437->76.25.57.137:20713, len 40
04:48:47 firewall,info !public_from_LAN forward: in:bridge out:ether1, src-mac bc:a8:a6:72:9d:72, proto UDP, 192.168.1.250:60112->172.29.0.1:53, len 138

Here are the rules
/ip firewall address-list
add address=0.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=172.16.0.0/12 comment=RFC6890 list=not_in_internet
add address=192.168.0.0/16 comment=RFC6890 list=not_in_internet
add address=10.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=169.254.0.0/16 comment=RFC6890 list=not_in_internet
add address=127.0.0.0/8 comment=RFC6890 list=not_in_internet
add address=224.0.0.0/4 comment=Multicast list=not_in_internet
add address=198.18.0.0/15 comment=RFC6890 list=not_in_internet
add address=192.0.0.0/24 comment=RFC6890 list=not_in_internet
add address=192.0.2.0/24 comment=RFC6890 list=not_in_internet
add address=198.51.100.0/24 comment=RFC6890 list=not_in_internet
add address=203.0.113.0/24 comment=RFC6890 list=not_in_internet
add address=100.64.0.0/10 comment=RFC6890 list=not_in_internet
add address=240.0.0.0/4 comment=RFC6890 list=not_in_internet
add address=192.88.99.0/24 comment=“6to4 relay Anycast [RFC 3068]” list=not_in_internet
/ip firewall filter
add action=accept chain=input comment=“defconf: accept established,related,untracked” connection-state=established,related,untracked
add action=drop chain=input comment=“defconf: drop invalid” connection-state=invalid log=yes log-prefix=“Invalid Input Chain FW Rule #2”
add action=accept chain=input comment=“defconf: accept ICMP” protocol=icmp src-address=192.168.1.0/24
add action=accept chain=input comment=“defconf: accept to local loopback (for CAPsMAN)” dst-address=127.0.0.1
add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN src-address=192.168.1.0/24
add action=accept chain=forward comment=“defconf: accept in ipsec policy” ipsec-policy=in,ipsec
add action=accept chain=forward comment=“defconf: accept out ipsec policy” ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=“defconf: fasttrack” connection-state=established,related
add action=accept chain=forward comment=“defconf: accept established,related, untracked” connection-state=established,related,untracked
add action=drop chain=forward comment=“defconf: drop invalid” connection-state=invalid log=yes log-prefix=“Invalid Input Chain FW Rule #10”
add action=drop chain=forward comment=“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=fasttrack-connection chain=forward comment=“Darren added fastrack DNS rule - 10/17” dst-port=53 protocol=tcp
add action=fasttrack-connection chain=forward comment=“Darren added fastrack DNS UDP 10/17” dst-port=53 protocol=udp
add action=drop chain=forward comment=“Drop incoming from internet which is not public IP” in-interface=ether1 log=yes log-prefix=!public src-address-list=not_in_internet
add action=drop chain=forward comment=“Drop tries to reach not public addresses from LAN” dst-address-list=not_in_internet in-interface=bridge log=yes log-prefix=!public_from_LAN out-interface=!bridge
/ip firewall nat
add action=masquerade chain=srcnat comment=“defconf: masquerade” ipsec-policy=out,none out-interface-list=WAN
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes

Thank you for any help

anav · October 23, 2020, 3:47pm

I dont see anything viciously wrong with your rules…
The one thing I dont understand is why you have a source address here.
add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN src-address=192.168.1.0/24

The whole point of that line is to block all attempt to reach the router directly (mostly) from the WAN side (good rule)
However by adding source address you have defeated the rule by stating any attempt not from the LAN (usually thus the WAN) but the attempt has to come from that address which is clearly not the whole internet.

Also not sure of those DNS rules in the forward chain?? what were you trying to accomplish. Typically they are put in the input chain (or perhaps redirect in dst Nat).

Personally I would pair it down somewhat…
/ip firewall address-list
add address=desktop_IP list=adminaccess
add address=laptop_IP list=adminaccess
add address=ipad_IPvlan20 list=adminaccess
add address=ipad_IPvlan30 list=adminaccess

/ip firewall filter
add action=accept chain=input comment=“defconf: accept established,related,untracked” connection-state=established,related,untracked
add action=drop chain=input comment=“defconf: drop invalid” connection-state=invalid log=yes log-prefix=“Invalid Input Chain FW Rule #2”
add action=accept chain=input comment=“defconf: accept ICMP” protocol=icmp src-address=192.168.1.0/24
add action=accept chain=input comment=“defconf: accept to local loopback (for CAPsMAN)” dst-address=127.0.0.1

add action=accept chain=input in-interface-list=LAN source-address-list=adminaccess [**]
add action=accept chain=input [for any services you want LAN folks to be able to use the router provides such as DNS]
add action=drop comment=“Drop all Else” Only put this one in after you create the list and rule for admin access.

**** For example your desktop IP, your laptop IP, your ipad IP, all static from whichever LAN or VLAN, put into a list so you can access the router.
THe default rules allow ANY LAN user to fully the access the router. This is sub optimal from a security aspect. If LAN users need access to DNS then put that in the input chain separately.

add action=accept chain=forward comment=“defconf: accept in ipsec policy” ipsec-policy=in,ipsec
add action=accept chain=forward comment=“defconf: accept out ipsec policy” ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=“defconf: fasttrack” connection-state=established,related
add action=accept chain=forward comment=“defconf: accept established,related, untracked” connection-state=established,related,untracked
add action=drop chain=forward comment=“defconf: drop invalid” connection-state=invalid log=yes log-prefix=“Invalid Input Chain FW Rule #10”

add action=accept chain=forward comment=“allow port forwarding” connection-nat-state**=dstnat** connection-state=new in-interface-list=WAN
add action=accept chain=forward [add any rules for traffic you wish to allow - such as LAN to Internet, or VLAN to internet, or shared printer on one vlan, or admin access to all vlans etc…]
add action=drop chain=forward comment=“Drop all else”

genki · October 25, 2020, 10:40pm

Hi Anav,

Thank you for taking the time to answer my question. I appreciate it and learned from it.

I adjusted my firewall rules with the helpful changes that you suggested.

I still see the traffic hitting my router, but now I understand better why the traffic is there and in the logs
The DNS rules are to “speed” up DNS traffic… just something I saw on the Internet if i recall.

Since I added your rule to drop traffic input to the router from the WAN, I can “see” a lot of bad actors hitting my router.. very interesting to see the rate at which things are attempting to connect to my router.

Anyway thanks!!

anav · October 25, 2020, 11:50pm

Rule of thumb, dont add stuff you see from the internet.
Best to come here and point to it and ask does this really work… etc..

genki · October 26, 2020, 12:26am

Okay, here’s the youtube video about fast track for DNS on MikroTik

https://www.youtube.com/watch?v=PPR6gg50m8o

I watched a lot of this guy’s videos to try and learn some basics of configuration.

Should I not trust it?

Sob · October 26, 2020, 1:44am

Maybe other videos can be good, but this one is questionable, kind of false advertising. It can make your DNS faster, but only in specific case.

The idea of fasttrack is to skip a lot of processing for connection, lower CPU load, don’t let it become bottleneck and get higher throughput. It helps most for connections with lots of data. DNS traffic consists of tiny requests and usually only a little bit larger responses. And clients in most cases use UDP, so it’s literally one packet with request and one packet with response.

I can’t say that the video is nonsense, because the guy limited some devices using queues and fasttracked packets bypass those, so it can do something useful. But if you don’t have queues, then don’t bother, it won’t help you at all (ok, it may save a microsecond or two, but you will never notice that). I’m actually not sure if it will help even when you do have queues, because I don’t know if connection can be fasttracked from very first packet. But let’s assume the guy tested it and it works like that.

vecernik87 · October 26, 2020, 2:01am

Excellent example of “do NOT trust that” video. The video itself is nice and well explained but there are two major issues which are easy to miss:

1) Those rules are are opening your network to the world. The author did not specify which interface it applies to, therefore it will allow any DNS traffic from internet, to your LAN. I admit it is unlikely for the attacker to reach your router from the internet, yet using your LAN address, but hey - we are talking security here, right?

2) It is pointless because DNS does not affect your internet speed much. Fasttrack is great for connections, where are heaps of small packets - that way, it will really take the advantage of the fact that it skips conntrack, queues, firewall etc… Each packet requires a bit of CPU time to be processed, therefore skipping these tasks will save huge amount of CPU. HOWEVER, that is not how DNS works, right? DNS, in 99% of cases consists of exactly two packets: One query, one reply. Speeding this up will take almost no CPU away and the difference will be less than 1ms per DNS query (which will be subsequently cached and not queried again for many minutes or even hours).

Keep in mind, that on the internet, DNS equals to barely 1% of the traffic (volume, not flows of course). Is it worth optimizing? Do you feel that the main reason for your slow internet are DNS queries?