Blocking port 53 incoming only.
Blocking port 53 incoming only.
I want to close port 53 to incoming requests after being advised by my ISP that I have a potential Open DNS Resolver. Obviously, I need clients on my network to make DNS queries, but I have no use for devices outside my network querying device(s) on my network for DNS entries. So I want to block the port from accepting any incoming traffic. How is this done?
"We're writing to let you know that a device connected to your home network has been identified as having a potential Open DNS Resolver (ODNSR) vulnerability.
An open DNS resolver lets any computer system on the internet use it, not just the intended local or authorised users on networks that you control and/or trust.
It is therefore important that you follow the advice in this letter.
What has happened?
We suspect the device may have been misconfigured by you, someone in your household or without your knowledge. If the settings are left unchanged they can be exploited to unwittingly participate in malicious activities, for example a Distributed Denial of Service (DDoS) attack."
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
@woozle It's concerning isn't it.
"With DMZ and UPnP not in use incoming requests on port 53 can't end up on one of your client devices". None of my clients are acting as an ODNSR, none of them are configured to serve DNS queries: it's the router. My tp-link AX3000 (AX53) Wi-Fi router is serving DNS requests from outside my LAN. The simplest way to prevent this is to block port 53, but there is no simple way to do this on the offending device. Hence my profound frustration with tp-link...so I don't have my VirginMedia services throttled or curtailed I have an (overkill) solution:
Thanks tp-link...
- Copy Link
- Report Inappropriate Content
Hi,
There is no provision on the AX3000 to block external requests on port 53.
But the Archer AX3000 should not forward incoming requests on port 53 to client devices connected to its local network, unless you have activated "DMZ" for one of the clients or a client has added forwarding of port 53 via UPnP (you could check the latter via the "UPnP Client List").
- Copy Link
- Report Inappropriate Content
@woozle I'm dismayed that I bought a Wi-Fi router on the strength of good reviews as it would integrated with my home automation well, only to find out that I cannot block a single port on it! What kind of inept implementation have I blundered into. I use Linux, I don't tolerate this kind of absence of control I may have to look for an alternative, hopefully i can install an open source firmware on this router and make it useful.
- Copy Link
- Report Inappropriate Content
The idea is that when exposing a client device directly to the Internet via the "DMZ" feature, then it is the responsibility of that exposed client to shield itself against incoming threats.
And UPnP can be deactivated on the AX3000 router. (and probably should be deactivated by anyone who knows how to setup port forwarding rules manually)
- Copy Link
- Report Inappropriate Content
@woozle I haven't configured a DMZ since I'm not serving anything to the Internet at this time, I might put my website back up in the future, but currently I have no need. Am I misinterpreting you by thinking, so if I disable UPnP, I can control ports with port forwarding and triggering, effectively blocking and opening them to specific traffic? Which is exactly what I require (as unfortunately there is no DD-Wrt/Open-WRT firmware that supports the AX53).
- Copy Link
- Report Inappropriate Content
With UPnP activated the local client devices (or more precisely the software running on them) can basically add port forwarding rules on their own to the router.
Port forwarding rules that have been added by clients via UPnP would show up in the UPnP Client List, like illustrated in the screenshot below.
Now, if the user needed the rules "test2" and "test3" to make some legit features work inside the LAN, but wanted to get rid of rule "test1" that allows access to an internal Open DNS Resolver from the Internet, then he should deactivate UPnP and instead just add the rules "test2" and "test3" manually via the "Port Forwarding" menu.
Question is, do you see a entry for port 53 in the UPnP Client List of your AX3000?
- Copy Link
- Report Inappropriate Content
@woozle Yeah, I reviewed my router last night and uPnP is not turned on. I checked Port Forwarding and only ports 80 and 443 are being forwarded. Yeah, the router is still still operating as an ODNSR. I'm clutching at straws now, could I forward port 53 to a reserved IP with no client attached as a workaround for this?
- Copy Link
- Report Inappropriate Content
Sure, you can forward port 53 to an unused IP address.
But I don't understand why the problem is happening in the first place? With DMZ and UPnP not in use incoming requests on port 53 can't end up on one of your client devices.
Have you already examined what online port checkers (for example portchecker.co) say about port 53 ?
- Copy Link
- Report Inappropriate Content
@woozle It's concerning isn't it.
"With DMZ and UPnP not in use incoming requests on port 53 can't end up on one of your client devices". None of my clients are acting as an ODNSR, none of them are configured to serve DNS queries: it's the router. My tp-link AX3000 (AX53) Wi-Fi router is serving DNS requests from outside my LAN. The simplest way to prevent this is to block port 53, but there is no simple way to do this on the offending device. Hence my profound frustration with tp-link...so I don't have my VirginMedia services throttled or curtailed I have an (overkill) solution:
Thanks tp-link...
- Copy Link
- Report Inappropriate Content
Perhaps someone from TP-Link should join this conversation for further investigation. @Marvin_S
By the way, the firewall of the Archer AX53 (menu Advanced -> Security -> Firewall, option "SPI Firewall") is switched ON, right?
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 932
Replies: 11
Voters 0
No one has voted for it yet.