Contributor
•
1 Message
How to stop uverse equipt with DMZPlus enabled from responding to external internet ping requests?
TLDR: How do I stop my Uverse 5031NV Residential Gateway from responding to ping requests from the internet when DMZPlus is enabled?
Background:
My reason for going into "bridge mode" is lack of confidence AT&T is adequately patching firmware in their UVerse RGs. Considering how many zero day and other defects have been published this year in software, firmware, and hardware, I need to do my part to protect myself.
Making my situation different from most, my apartment is literally 15 yards away from a high speed rail/public transit stop. The transit line next to my apartment has high traffic as it goes directly downtown. Additionally, several community colleges are on this transit line. I have concerns of a young network eng using my WiFi network to test concepts they just learned in class or read about online. Although my wifi power setting is very low, the elevated position of my apartment relative to the transit stop, results in me providing 4 bars of wifi coverage to strangers at the train stop.
Technical Problem:
Although, I have a different model UVerse RG, this article from the AT&T Community Forum, outline the same problem: "Pace 5268AC Responds to Pings in DMZplus mode": https://forums.att.com/t5/AT-T-Internet-Features/Pace-5268AC-Responds-to-Pings-in-DMZplus-mode/td-p/5130591
Regrettably, the article does not indicate steps needed to stop Uverse equipment with DMZPlus enabled from responding to ping requests.
Here is what I have done:
1. Determined status of my LAN to the outside world before making any config changes by running shields up from GRC.com: https://www.grc.com/x/ne.dll?bh0bkyd2
2. I noted all tests passed.
3. Placed 5031NV in "bridge mode" by following these steps: https://forums.att.com/t5/AT-T-Internet-Equipment/How-to-Bridge-PACE-5031-NV-to-3rd-Party-Router/td-p/3612175#M12227
4. Ran shields up from GRC.com, all port in stealth mode but failed due to network responding to ping requests.
5. The Asus RT-N66U is running AsusWRT-Merlin. Under Firewall, I confirmed RESPOND TO ICMP ECHO (PING) REQUEST FROM WAN is set to NO.
6. From the Google Play Store, I loaded Ping Test by B.G. Best Games and ran ping using my cell network.
7. The ping from my cell phone was successful. This confirmed GRC.com's finding, my LAN's edge device is visible to the whole internet - BAD!
8. Restored Uverse Residential Gateway to normal config.
9. Ran tests from GRC.com and my cell phone, my LAN's edge device is not visible to the world.
10. Tried "bridge mode" again with a Netgear WNDR3400v2 using Netgear's firmware.
11. GRC.com test results same as step #4 and ping from cell phone was successful. Again, my LAN's edge device is visible to the world - BAD.
12. Restored RG to normal Uverse config.
13. Ran shields up from GRC.com, all tests passed and ping from phone failed - GOOD.
14. On Uverse 5031NV, I went to FIREWALL-->ADVANCED SETTING and unchecked BLOCK PING and saved.
15. Ping was successful from both GRC.com and my phone - BAD.
16. Restored check in box for BLOCK PING and saved.
17. As expected, ping failed from both GRC.com and my phone - GOOD.
Based on the above actions, along with the complaint stated in question "Pace 5268AC Responds to Pings in DMZplus mode", it appears as if some Unverse gateways respond to ping requests by default when DMZPlus is enabled. Can someone with more knowledge of UVerse tell me how do I disable this feature?
In the event this feature cannot be disabled, what steps do I take to effectively combat hack attempts while in "bridge mode"?
Dlpoole
Tutor
•
6 Messages
5 years ago
I have a similar setup for precisely the same reasons - an AT&T/Pace 5031NV Residential Gateway in DMZ+ and a PepWave Surf SOHO router behind it with its WAN interface configured to ignore pings. I just went through a similar analysis to yours after GRC Shields UP reported a FAIL on pings, although I simply unplugged the router to observe that there was a ping response from the RG alone. I also traced it from my AT&T cell phone and saw the same response. I haven' t duplicated your steps of trying non-DMZ+ mode, but have no reason to expect anything different.
I 've used "Shields Up" before without receiving a FAIL, but I don't know that Steve Gibson hasn't since added ICMP response to the FAIL determination on his probe, nor do I know that AT&T hasn't pushed a firmware update to the 5031NV that newly introduced this behavior.
On the other hand, we may be kidding ourselves to believe that an intruder needs ICMP to identify our RGs. A port scan from the cellular network with the router disconnected finds responses on ports 80 and 443. These are probably for the RG's admin web pages which I can find no option for disabling. A port scan from the cell phone several months ago found two other open ports above 6xxxx, of which ShieldsUP confirmed one but not the other. Unfortunately I kept no written record of what they were. In any case, they are no longer open from AT&T's cellular network now.
I decided to stay in DMZ+ mode and rely on the PepWave Surf SOHO's firewall to protect my clients from probes on the Internet. That particular router also allowed me to create three Wi-Fi APs, with two on isolated VLANS for guests and my video streamers so as to provide them Internet access while protecting our workhorse computers from them. The streamers and other IoT devices are a particular risk because they're not necessarily patched, but should one of them be compromised, it should be limited to attacking the others, or the Internet.
I consider any open port from the RG itself in DMZ+ mode with nothing connected behind it to be undesirable at the least, but I doubt that AT&T will correct it unless (or until) its network is attacked by a botnet of its own RGs. The risk to them from compromised customer IoT devices is probably far greater and they know I won't churn over it because the sole alternative I have is worse in many other ways.
I think we have to do our part and hope for the best.
0
0