I’m contacting you because I’ve found a very big vulnerability with the lastest version of Mikrotik.
Practically I’ve seen that thousands of DNS requests were sent from my Mikrotik to the same domain “USADF.GOV”.
Analyzing the issue, I’ve noticed that seems like the port 53 UDP (DNS Service) was open for the world, in this way every people are able to use my Public IP to resolve names, like a Public DNS Service.
I’ve found this problem also from other Customers.
The problem seems tied to the latest version of Mikrotik, have you already seen that issue?
Do you have a solution?
This just sounds like you didn’t set up your firewall properly. Not a vulnerability.
If you enable DNS cacheing then the router will do it regardless, it is up to you then as the user to ensure that only requests you want answered are responded to. Usually a dro pUDP-53 rule from the WAN interface is enough.
It is a problem that you or a fellow admin have created yourself!
The default configuration of MikroTik routers does NOT have this problem.
However, when you have removed the firewall or made incorrect changes to it, it can happen (as with ANY router!).
When you have used very old RouterOS versions and have updated all the time without resetting the configuration, and especially when you use PPPoE to connect to internet, it is a good idea to reset to defaults because the default firewall is now more resistant to making incorrect changes.
However, it is very important that you use real information about how the firewall works when configuring it, NOT view some video on YouTube as a source of information!
Many videos there are made by beginners who just unpacked their first MikroTik and proudly announce how they did something, and are completely incorrect.
We have a lot of Customers that are using Mikrotik and we’ve found that issue only in the last months before that all worked properly and we’ve changed nothing.
We work also with a lot of Dealers in the world and they are Mikrotik programmers and they’ve still experienced that issues recently, without having made changes.
I’ll check the rules and I’ll ask them to do the same and I’ll update you.
In the meanwhile thanks a lot for your help.
With best regards,
Which version of software are they running? There were some vulnerabilities published last year It’s possible that these routers got exploited and opened to wide world.
a. current config is leaky and needs to be fixed.
b. current config is fine but leaky which leads one to conclude a potentially compromised firmware from past poorly done configs (and net install was not used to fix the issue).
Either way Marco, you have serious issues to deal with and not deflect.
Can you share an export of firewall settings (both filter and nat rules)? Maybe you are dst-nating dns queries from the wan side at nat rules, and allowing dstnated packets on the filter rules.
Is your wan interface added to the WAN interface-list?
wrong bucko!
The default rules include this rule which stops that BS cold.
More likely the routers were compromised for other reasons and the above issue were just symptoms.
/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
add action=accept chain=input comment=“defconf: accept ICMP” protocol=icmp
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
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
add action=drop chain=forward comment= “defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat
connection-state=new in-interface-list=WAN
Default config contains universal drop rule. You shouldn’t need those individual drop rules. If you need them, you are clearly missing some important part. (you or someone else likely deleted that)
To confirm original, unmodified defconf, please run
/system default-configuration print
Among many other lines, you should see following (exported from 6.47.1):
/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"
}
As you can see, on the 6th line (5th/last “input” rule), it drops everything from not-LAN. Afaik, this rule was always there.
If your default-configuration does not contain this, please post the WHOLE result of the command. Not just part of it.
If your default-configuration contains this, it is a proof that the critical rule got somehow removed from your running config. In that case I would strongly recommend to properly secure the router, or even completely reinstall it from scratch.
To all. Look at the date of the thread. For some reason alfred998 responded to a thread that is 1 1/2 year old. Where m4rk did not post his config. I guess he did see that and left the thread.
Always forget to check gravediggers