Hello, yesterday I enabled a rule in Firewall filter raw to block incoming DNS requests (port 53 tcp/udp) for a Interface list wich contain all wan ports.

the router get public ips in two wan ports by dhcp from my ISP's.

And I found the rule is blocking a full stream of 1600 packets each second.....around 700kbps, or 5GB of data in less than 24 hours.

This make sense for you?

Its a lot for me.

[img]https://imgur.com/bEfJvAg [img]
https://imgur.com/bEfJvAg

Edited: I forgot to mention that the cpu reduced its usage from 60-70% down to 35-45%.

Wow interesting. What happens if you log everything for a min. Is it all different IPs?

There is tons of traffic on the net especially on common ports.
That is why the default firewall rules are setup as they are and work from the getgo and changing them is not a trivial matter.

You haven't provided any context. If it is your home router, and you didn't have any rules blocking access to your DNS before, bots around the planet got used to the possibility to use your device as a DNS amplifier for DDoS attacks, and it will take some time until they find out it does not make any sense any more and unlist you. The principle of the attack is to send a small DNS query to these publicly open DNS caches, for which a large response is known to be sent (I have seen a 4 kbyte response to 100 byte query in the wild). The sender uses the address and port the DDoS target is listening at as the source address and port of the query, so the DNS sends the much larger response to the victim service.

Another possibility is that some of the device on the LAN side of your router is sending its DNS queries using port 53 as source, so the drop rule in raw is actually dropping the responses to these queries. And the device really wants to know the answer so it repeats the queries all the time.

You would have to sniff the traffic to find out which variant is the correct one, i.e. whether the packets being dropped are queries or responses.

@Sindy , this is the main router of a wisp network, actually is used for load balancing requests between two wan interfaces, behind this router is another router wich manage the traffic and clients.

This is actually my setup: ROUTER BALANCER --> ROUTER MANAGER --- > OSPF --> SERVICE ROUTERS --> CLIENTS

will perform some tests with the sniffer tool according your comments. thank you, later will post what I find.

Wow interesting. What happens if you log everything for a min. Is it all different IPs?

Here you can find the LOG fo the RAW rule
https://1drv.ms/u/s!Agwzi1XZjF4OgZFz8uQ ... A?e=RyB0BE


https://imgur.com/a/eXygGcT

Is DNS attack by bots , I guess

@Sindy , this is the main router of a wisp network, actually is used for load balancing requests between two wan interfaces, behind this router is another router wich manage the traffic and clients.

This is actually my setup: ROUTER BALANCER --> ROUTER MANAGER --- > OSPF --> SERVICE ROUTERS --> CLIENTS

will perform some tests with the sniffer tool according your comments. thank you, later will post what I find.

Extremely useful information and I am curious as to an optimal setup for this device when Sindy replies.
I would assume the default firewall rules should suffice as there is no specific traffic rules here...........

..
Is DNS attack by bots , I guess

You are not "really" being attacked, but are being used to attack some other internet user
If this packets are not dropped, it will have an impact on your upstream link as well as use additional resources on your router though.

Will be better to drop these in firewall filter (input / forward) instead of firewall raw

/export hide-sensitive file=anynameyouwish

As both me and @CZFan have pointed out, it is not a DNS attack against your router, it is a deployment of a security hole on your router (if there actually was one, maybe allow-remote-requests was set to no?) for attacking someone else. And the real targets of the attacks were the source addresses of the DNS requests shown in your log.

The only thing you can do now is to wait - once you've prevented the requests from being responded, your router's address should slowly get recognized as useless for the purpose by all the bots and the traffic should gradually disappear.

To spend as little CPU as possible while not blocking "legal" responses to DNS queries sent by your NATed customers from port 53 (which do exist in the wild as @CZFan can confirm), the best solution would be to filter udp packets coming from other ports than 53 to port 53 of your router's address using a switch chip rule, as switch chip rules are processed on wirespeed and don't consume the CPU at all. If there is no switch chip supporting rules in your router and no external switch supporting L3 filtering, a rule in raw is in my opinion less CPU consuming than one in filter if these DNS queries form up a significant share of the incoming traffic. 1600 120-byte packets per second are roughly 2 Mbit/s, how many per cent of your uplink bandwidth is that?