I noticed something weird earlier today,

My one dsl line is current not active (ie there are no devices routing through it).

It is my backup line.

But I noticed every second there was a full upload spike on my PPPoE interface.

I packet sniffed the traffic and I got the following:
I dont have any devices talking on this interface so it can only be coming form the outside.

Disable DNS access from the WAN.

How Do I do that?

Does this mean that some one is using my router as a DNS server?

I have added a temp firewall rule to drop incoming to port 53, But then will this not disable me to do dns resolution as well?

How Do I do that?
I have added a temp firewall rule to drop incoming to port 53, But then will this not disable me to do dns resolution as well?

If your rules are on the "input" chain, matching only dst-port, then no - it won't disable your router from making DNS requests, and/or disable receiving of replies to them.

A firewall rule like: is IMHO best suited to block outside DNS requests, assuming you have only one local interface (in the example above called "LAN"; adjust accordingly), and one or more outside ones.


(EDIT: Opps... yeah, action=drop indeed... added)

Could I replace not LAN with the public interface name?

Could I replace not LAN with the public interface name?

Yes you can, but the you also have to put the action to block.

Yes Thanks,

I figured that one.

So I just duplicate that rule for my 3 public interfaces.

Yes Thanks,

I figured that one.

So I just duplicate that rule for my 3 public interfaces.

Yes. But make sure to block port 53 for both UDP and TCP. Though most malicious DNS traffic is UDP, some may try TCP as well.

Ok thanks,

While Im at it,

What other important firewall rules should I have on my router?

Ok thanks,

While Im at it,

What other important firewall rules should I have on my router?

Block TCP and UDP port=0.

No valid traffic ever uses them, but malicious one that tries to do a DDoS attack does.

Also, and this is more optional... perhaps block echo (and other ICMP) requests to your inner devices from the outside? You can still do that AND still allow yourself to do ping FROM the inside to the outside.

In total, my rules look a little something like:

ros code

/ip firewall filter
add action=reject chain=forward icmp-options=8 \
    in-interface=!local out-interface=local protocol=icmp reject-with=icmp-host-unreachable
add action=drop chain=forward icmp-options=17 \
    in-interface=!local out-interface=local protocol=icmp
add action=drop chain=forward icmp-options=15 \
    in-interface=!local out-interface=local protocol=icmp
add action=drop chain=forward port=0 protocol=tcp
add action=drop chain=forward port=0 protocol=udp

With the exception of the last two, you'll again need to duplicate those rules for each public interface, instead of using "!local".

Note: The first rule blocks ping requests, and instead of dropping them, returns "host unreachable", so that to an attacker, it looks the same as if you didn't had a local network... dropping ping requests would alert them something is going on IF they also try various other IPs at your router, only to see some of them go "host unreachable" and others "timeout" due to the drop.... Actually, come to think of it... maybe I could just drop them, since I'm blocking ALL ping requests, and not just some... but if you need more fine grained control, you'll need to use "reject" instead of "drop".

Shouldn't my firewall block every port unless I have opened it?
Either with a nat rule or simply by masquerading?

Yes, You should open up whatever ports you need to, and then drop all traffic at the end of the firewall filter.

Shouldn't my firewall block every port unless I have opened it?
Either with a nat rule or simply by masquerading?

By default, RouterOS lets everything in, but yes, you could change that by allowing what you need, and then adding a rule that would match everything else (by merely not matching anything specific at all), and have it with action=drop.

With masquerade, AFAIK, RouterOS will proceed with port 0 as with any other port by default, i.e. when it's a destination from the outside to the inside, it will check if there's a dst-nat for it, and drop it if not, but if someone from your local network is sending packets with port=0, then by default, RouterOS will just NAT them, as with any other port. The rules above about port=0 would prohibit not only the outside from sending/receiving packets on port=0, but also your local network from trying to do that to the world.