Dear Sirs,

I've setup a mikrotik RB 951Ui as PPPoe client to act as router for a LAN, we got a STATIC PUBLIC IP.
After a few days the connections list in firewall showed more than 800 entries, all from unknows src address to PublicStaticIP:53.

I've already setup 4 differents microtik in the same situation PPPOE CLIENT TO LAN without any issue.

Is this an attack? why this happen?
How can this be stopped???

See this: http://forum.mikrotik.com/viewtopic.php ... 76#p445176

Your DNS server is probably configured as "open".

Substitute in-interface with yoyr ones and it should work

Thanks for the help, now after a night I've 70Mb of traffic blocked, now would ask my ISP to check, what's happen

Seems better with:

chain=input action=add-src-to-address-list protocol=udp address-list=DROPPED address-list-timeout=20m connection-limit=10,32 in-interface=ppp-wan dst-port=53 log=yes log-prefix="DROPDNS"

Seems better with:

chain=input action=add-src-to-address-list protocol=udp address-list=DROPPED address-list-timeout=20m connection-limit=10,32 in-interface=ppp-wan dst-port=53 log=yes log-prefix="DROPDNS"

If you're looking to track the sources so you can do something with the list of addresses (suppose you're participating in a realtime blacklist service's scanning network, etc) then this is useful.

If you're just trying to stop them from relaying dns requests off of your router, then a default drop everything from the WAN policy is fine, and consumes less resources.

input chain:
1) accept packets in established,related connection state (i.e. "I asked for it, or already approved it")
2) allow certain things (e.g. icmp, connections from trusted sources, connections from LAN interfaces, etc)
3) throw everything else in the trash

A lean & mean configuration is much better than an intricate, inefficient one that ends up doing the same thing (drop unwanted packets) but in a complicated way that takes more steps to reach the same conclusion.

Thanks for your reply ZeroByte, everything seems fine now.

But can I ask you why if with the rule of:

chain=input action=drop in-interface=ppp-wan

and enabling:

Ip/DNS / allow remote request

the world can call the dns port?

But can I ask you why if with the rule of:

chain=input action=drop in-interface=ppp-wan

and enabling:

Ip/DNS / allow remote request

the world can call the dns port?

Well, earlier in the chain, I'm sure you have a rule to allow established,related connections, right?
Any existing connections when you set the default drop policy would still be allowed by the established,related rule... that's one way. You could go into the connections table and remove any that had port 53 if you wanted to drop those immediately.

If new connections are working, then basically, you must have a rule which is permitting the traffic somehow; either you have a rule further up in the chain which permits DNS in the input chain, or the requests are coming in via a different interface.

Go into the firewall filter screen, and use the filter drop-down at the top-right corner of the window to select the input chain. This will make it easier to read that single chain, and you can make 100% sure that there aren't any rules permitting the traffic.

I suppose it's possible there could be an "accept" rule in the prerouting chain of the masquerade table, but I don't think an accept rule there would be able to override the filter table, but it's something to consider since the prerouting chain of mangle is called before the input chain of filter is called.

generally thats another reason why always good idea to "whitelisting" access to Majority of feats/services are good idea in networking.
and despite been 25yrs old DNS and NTP exploitations - remain quite popular.
partially because spoofing is too easy(full bogon lists are(like Cymru-supplied)are too fat and unpopular, sadly).
similarly importing domainlists from malwaredomains( http://www.malwaredomains.com/) to ROS - combined with Peter Lowe ads lists( http://pgl.yoyo.org/adservers/) its mean nearly 22k domains and imply nearly 17Mb of RAM usage for DNS service Alone. and in most ROS builds since 6.9 (generally after ~6.13)ROS simply hang after attempts of importing such amount of and make inconsistent config, irrepairable from WB or WebUI (unseen options, that working and living own life) and imply netinstall usage to recover devices.