Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: polymath on January 13, 2017, 04:19:28 PM
-
Just bought a ZyXEL VMG3925-B10B-EU01V1F. This is through a retail channel, not an ISP cast-off. Set up went ok and connected to the internet first go. I have not played with the settings other than to get an ADSL 2+ logon.
First place I went to was the Gibson Research Corp Shields Up! site to test response to port probing.
I got a strange response (at least strange to me) to the various port scans.
The common ports scan (about 20 of the most popular ports from 0 to 1057) failed the stealth test. The first half or so of the common ports were stealth but the last 5 or so were closed. I specifically checked port 7547 on its own and that returned a closed result.
The "all service ports" scan (0 to 1055) produced an odder result still. Ports 0 to 4 were closed then most ports were stealth except for groups of 3 ports (about 10 groups of 3) spread across the rest of the range of ports. I ran the "all service ports" scan a second time and the groups of 3 closed ports moved by 1 upwards!
I have attached two images that summarise the "all service ports" scan.
This ZyXEL was intended to replace a Netgear DG834G. With everything the same, except using the Netgear, the Netgear produces a stealth result whatever Shields Up! test is used.
Does anyone recognise this sort of Shields Up! response? More hopefully, does anyone know how to congigure the ZyXEL's settings to give a consistent stealth response?
-
Hello polymath,
That is a strange result...
I have a ZyXEL VMG3925-B10B but ISP supplied, I have, with the kind help from the folks on this forum, installed the latest stock firmware, my router passes the Shield Up! test, all the ports I have tested are reported as Stealth apart from port 7547 which is reported as Closed.
I do get a different result when I test through a VPN connection as I think it is then testing the VPN and not my router.
Have you installed the latest firmware 5.11(AAVF.3)C0 ?
Have you tried a hard reset and then running the Shields Up! test again?
nix
-
I do have the latest firmware. Not sure a hard reset would do much, I have only had the unit a couple of days. Apart from updating to the latest firmware and setting up the ADSL parameters, it is as received.
-
Any idea what 7547 is used for? My 8924 router shows it as stealth.
Stuart
-
7547 is for TR069 I believe.
:)
-
It's best practice to perform a reset and/or restore factory settings after updating firmware, particularly if you're updating from a much older firmware. Are things like upnp on or off? Is TR-069 menu showing and is it disabled?
-
7547 is for TR069 I believe.
:)
Indeed. ;)
Specifically, the port is used by the remote ACS to send a message to the local device, requesting that the latter then initiates a connection from itself to the ACS, using the preconfigured details that have been stored in the CPE.
-
There is no TR069 (or TR064) option in the Maintenance menu. If I do a reset will I have to reinput the ADSL connection settings (e.g user and password)?
-
Does anyone recognise this sort of Shields Up! response?
Yes, I have seen similar. That "diagonal effect" is the result of a defect in the ShieldsUP! (https://www.grc.com/x/ne.dll?bh0bkyd2) tester. :o
When the same circuit was scanned by a remote application of nmap (https://nmap.org/) the correct result was obtained.
-
There is no TR069 (or TR064) option in the Maintenance menu. If I do a reset will I have to reinput the ADSL connection settings (e.g user and password)?
You may need to clear the Rom-D to restore the TR-069. The procedure seems to be the same on most Zyxel VMG models. We've seen this on both retail and ISP issued Zyxels. Buying retail does not always give a "clean" unit.
restore default settings from within the GUI
open telnet and run the command "save_default clean"
after clearing the romd from telnet do not power off the modem
insert a paperclip into the reset hole for around 10 seconds, or until the lights go out and the unit starts to reboot
Here's an AAISP tutorial (http://support.aa.net.uk/VMG1312:_Factory_Reset) for a different model
Here's a recent thread (http://forum.kitz.co.uk/index.php/topic,19022.0.html) on the procedure
-
by the way guys ignore the ping response advice, I like shields up but it is very outdated by advising people to disable echo replies.
In regards to closed ports vs stealth ports, essentially both are as secure as each other, they refuse access, but stealth means it sends no response so it just times out, closed means a specific denied response is sent. The only advantage really is security vs obscurity which isnt real security.
-
OK, some progress. I got rid of nearly all the closed port responses (blue markers). I had configured a DMZ lan address and associated the lan address with a specific MAC address. But I had not connected a network device with the MAC address. Removing the lan ip address / MAC association and removing the DMZ setting cleaned up the GRC results, except for one port. My old Netgear was happy with this DMZ stuff and has always come back as stealth from a Shields Up! test.
The one port that fails is of course 7547. Depending on how one uses Shields Up! (scan single port or range of ports including 7547) it shows as closed or stealth (dropped).
It would be nice to get the ZyXEL to drop stuff to port 7547 consistently. I did try a Firewall Protocol Access Control combination (which I have read about elsewhere on the forum) but so far it has either failed to alter the port 7547 response, or stopped the WAN connection altogether.
The current state is an improvement, especially as nearly all the reported port scans and dos attacks logged by my old router involve ports 23 and 2323 (I know they may not be real dos attacks but that is how it is reported).
Can anyone offer a set of Firewall Protocol / Access Control settings which would ensure port 7547 response is to DROP?
-
Have you tried the advice here? http://www.speedguide.net/port.php?port=7547
-
Can anyone offer a set of Firewall Protocol / Access Control settings which would ensure port 7547 response is to DROP?
I've attached some images that show how I performed the task for my VMG1312-B10D.
The first three images . . .
-
The final three images . . .
-
An nmap scan showing the original status, before applying the above configuration adjustment --
# Nmap 7.12 scan initiated Wed Nov 16 17:15:31 2016 as: nmap -Pn -sS -sV -sU -p 7547 -oN port_7547_scan-1.txt 79.74.208.191
Nmap scan report for 79-74-208-191.dynamic.dsl.as9105.com (79.74.208.191)
Host is up (0.11s latency).
PORT STATE SERVICE VERSION
7547/tcp open unknown
7547/udp open|filtered unknown
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port7547-TCP:V=7.12%I=7%D=11/16%Time=582CDAA6%P=x86_64-redhat-linux-gnu
SF:%r(GetRequest,54,"HTTP/1\.1\x20400\x20Bad\x20Request\r\nContent-Length:
SF:\x200\r\nDate:\x20Wed,\x2016\x20Nov\x202016\x2022:16:09\x20GMT\r\n\r\n"
SF:)%r(HTTPOptions,54,"HTTP/1\.1\x20400\x20Bad\x20Request\r\nContent-Lengt
SF:h:\x200\r\nDate:\x20Wed,\x2016\x20Nov\x202016\x2022:16:09\x20GMT\r\n\r\
SF:n")%r(RTSPRequest,54,"HTTP/1\.1\x20400\x20Bad\x20Request\r\nContent-Len
SF:gth:\x200\r\nDate:\x20Wed,\x2016\x20Nov\x202016\x2022:16:09\x20GMT\r\n\
SF:r\n")%r(FourOhFourRequest,54,"HTTP/1\.1\x20400\x20Bad\x20Request\r\nCon
SF:tent-Length:\x200\r\nDate:\x20Wed,\x2016\x20Nov\x202016\x2022:16:37\x20
SF:GMT\r\n\r\n")%r(SIPOptions,54,"HTTP/1\.1\x20400\x20Bad\x20Request\r\nCo
SF:ntent-Length:\x200\r\nDate:\x20Wed,\x2016\x20Nov\x202016\x2022:16:42\x2
SF:0GMT\r\n\r\n");
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Nov 16 17:17:37 2016 -- 1 IP address (1 host up) scanned in 94.75 seconds
An nmap scan showing the current status, after applying the above configuration adjustment --
# Nmap 7.12 scan initiated Thu Dec 8 06:41:48 2016 as: nmap -Pn -sS -sV -sU -p 7547 -oN port_7547_scan-2.txt 79.74.209.134
Nmap scan report for 79-74-209-134.dynamic.dsl.as9105.com (79.74.209.134)
Host is up.
PORT STATE SERVICE VERSION
7547/tcp filtered unknown
7547/udp open|filtered unknown
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Dec 8 06:43:24 2016 -- 1 IP address (1 host up) scanned in 95.23 seconds
-
burakkucat: Many thanks for the 6 screen shots explaining the protocol and access control settings. I will give those a try.
One small point I noticed on the Add/Edit Access Control screen is the Direction option of WAN to ROUTER. My closest option is WAN to LAN; hopefully it means the same.
-
. . . I noticed on the Add/Edit Access Control screen is the Direction option of WAN to ROUTER. My closest option is WAN to LAN; hopefully it means the same.
"WAN to ROUTER" is an exact match for what is required. The VMG1312-B10D, as a device in its own right, is what I wanted to be inaccessible via port 7547.
"WAN to LAN" is close but not an exact match. Hopefully, though, you will be able to filter the port.
-
I found the WAN to ROUTER option in the Access Control Direction parameter. I have added the 2 Protocol and Access Control settings. The Shields Up! response to a scan of just port 7547 is the same, the port is Closed. So in Shields Up! terms it fails the stealth test.
I guess that at least on this VMG3925-B10B port 7547 response is 'hard coded' to Closed before the Firewall rules in the Web Configurator get a chance.
As the port is Closed I am assuming the TR-069 client is disabled. There are no options in the Maintenance menu for TR-069 or TR-064; even though the manual guide for this device lists them. It is disappointing that every port except 7547 is stealthed, and I cannot see a way of changing that from the Web Confgurator.
-
I prefer to use the ShieldsUP! software as an indicator of those areas that need further examination but not as the provider of an absolute, definitive, answer.
Hence I make an offer . . . something that I have done for other kitizens, in the past . . . Send me a PM, with details of your current IPv4 address and I will perform a remote nmap scan.
-
If you wish the port to report stealth you will need to try restoring TR-069 in the maintenance menu. Disabling it should result in the outcome you desire.
-
As the port is Closed I am assuming the TR-069 client is disabled. There are no options in the Maintenance menu for TR-069 or TR-064; even though the manual guide for this device lists them. It is disappointing that every port except 7547 is stealthed, and I cannot see a way of changing that from the Web Confgurator.
I wonder if you can use the instructions as described by highpriest for the VMG-8924 in an attempt to obtain the supervisor password: http://forum.kitz.co.uk/index.php/topic,19186.msg340936.html#msg340936
If so, you should be able to access or restore the TR-069 menu via the supervisor login. However, I'm not sure if the same commands are available via telnet for the VMG-3925 as it seems to be more similar to the VMG-1312 compared to the VMG-8924 so it may need something slightly different done. I did try a VMG-3925 previously and I recall that it may have gone straight to a busybox prompt when you login via telnet.
-
As far as I recall if the TR-069 menu is hidden by the Rom-D file then it remains hidden when logged in as supervisor.
-
burakkucat reply #19: Thanks for the offer. I am indulging in a bit of ticket tennis with ZyXEL Support at the moment. I will take the ZyXEL ticket to an end point before trying anything else.
-
Polymath I am wondering if you have got anywhere with ZyXEL? I have one of these routers and while the 7547 port is indeed stealth on mine I also have issues with the TR064 and TR-069 menu options missing plus my log fnction does not work despite the log being enabled. I also have a ticket open with ZyXEL but at present they are refusing to do anything as they are convinced my router must be an ISP one which as far as I am aware is simply not true.
Stuart