Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[les-70]

   I thin I have only had ports open when creating new connections or making major changes such as the changing the modem IP. 

In case it is of relevance I have always saved settings after adding in my own DNS's.    I always keep a copy of the current working config.

[les-70]

  I did a hard reset of my 1.06t and yes I also had the issue.  I then uploaded the last used config file and to begin with the dns settings were there.  However after a reboot they have gone again.    Same as you have found.  I guess what ever I had done I have undone it.  I will probably downgrade to the "open source version" when it is convenient.

[npr]

In my experience the open source firmware is no better than v1.06t for losing the dns settings.

This morning I installed your config file in v1.06t, the same config files I've used before in v1.04t without a problem.
Checking with shieldsup showed the telnet port to be no longer stealth. Deleted two "telnet" entries in the iptables and now stealth.

So, looks like we've now duplicated each others issues.

[s60sc]

I'd noticed too that if a config file is reloaded, or the router is powered down, then telnet reappears, so it must be added to iptables by the config file. It appears the initial iptables settings are created by /var/firewall_init.sh on boot up (/var/atp_boot_track.log), then added to when the config file is loaded but I've not found a script for this. It may be possible to switch off telnet via the web interface, as the following appears in /html/js/security.js

if(a=="HTTP"){this.set("deleteDialogBody",Em.I18n.t("AclHttpDialog"))}else{if(a=="ICMP"){this.set("deleteDialogBody",Em.I18n.t("AclIcmpDialog"))}else{if(a=="SAMBA"){this.set("deleteDialogBody",Em.I18n.t("AclSambaDialog"))}else{if(a=="FTP"){this.set("deleteDialogBody",Em.I18n.t("AclFtpDialog"))}else{if(a=="TELNET"){this.set("deleteDialogBody",Em.I18n.t("AclTelnetDialog"))}}}}}},checkProc:function(){if("0.0.0.0"==this.get("activeItem").get("StartIpAddr")){Em.Logger.log("Enter ACL checkProc StartIpAddr .....");

It may be possible to modify the web interface to bring up this dialog, but as the directory is mounted read only and another poster indicated that modifying read only bricked the router (probably failed hash check on contents) then I don't want to try this.

[npr]

Warning, changes made to the routers iptable DO NOT survive a power cycle! 

I had need to turn my HG635 off for a couple of hours yesterday. Today my routers log is full of entries like these:

00:06:08 15/12/2014   User Level   Notice   User root login fail by telnet 176.35.53.104.
00:05:52 15/12/2014   User Level   Notice   User root login fail by telnet 176.35.53.104.
23:50:34 14/12/2014   User Level   Notice   User root login fail by telnet 190.200.56.168.
23:50:18 14/12/2014   User Level   Notice   User root login fail by telnet 190.200.56.168.
23:50:02 14/12/2014   User Level   Notice   User support login fail by telnet 190.200.56.168.

ShieldsUp shows port 23 as open.
iptable shows a new entry accepting telnet.

Looks like I need to go back to the default config file and not have telnet enabled.

[les-70]

I have been uncertain about that.  I edited iptables when off line and after a reboot and still off line and I thought the edit persisted when I looked at iptables.  I will check this later today.   However I then connected to the line and synced and I found that the edit had been removed. I had TR069 and remote management enabled and that may be a factor as that checks a number things after after a reboot.

[broadstairs]

I have only tested port 23 from the wan side (using a telnet client from my Android phone) with both TR069 and remote management disabled and I have never connected. I do have one of the alternate configs loaded but have never (so far) had to play with any iptables etc to get 23 stealthed. Telnet on the lan works fine. I am currently on 1.04t reloaded by TT at my request to downlevel from 1.06t.

Stuart

[npr]

I had TR069 and remote management enabled and that may be a factor as that checks a number things after after a reboot.

Both were disabled here.

[les-70]

   Your correct.  It does not survive a just reboot.  The offending iptables line seems to appear in different places when it comes back.  That is probably why I had not immediately noticed the return when off line.  It is strange that these issues did not occur right at the beginning nearly 2 months ago.   I am thinking more now on returning one to square one with one of the open source files.

[npr]

I never had this problem with firmware v1.04t when used together with your config file.
So I'm guessing it's a issue with v1.06t when used with your file.

It may be worth going back to your original post which linked to the config file and putting a warning about v1.06t and port 23 becoming open after a reboot.

IMO this feature makes v1.06t unfit for use with the telnet config file. In fact I'm failing to see any benefits of v1.06t over v1.04t. I'm not prepared to risk another reboot causing my routers log again becoming full of hacking attempts, so like you, I'm going back to v1.04t.

Just remembered about the disappearing custom dns in the dhcp server settings -- the settings no longer show in the GUI but are still being assigned to my devices.

This really is buggy firmware, if the router didn't give me a much needed speed boost I think it would be in the bin before now.

[broadstairs]

TalkTalk have just replied to my thread on theDNS issue and said that using your own DNS server addresses is not supported and may not work. IF they can recreate the problem then they will fix it at some future time in a new f/w release..

Stuart

[les-70]

   I have gone back to the 1.04t images in the open source.  Things seem much better and nothing at all seems worse, but as it did in the first place it remains possible to find port 23 open when you do some things.  I will try to see if I can track down which things. 

   One oddity in the opensource files is the file HG635v1.04t_packet_config.bin which is a firmware file but "not as we know it".  You use it like a firmware file but it only replaces the current config with a config that looks identical the actual telnet firmware version HG635v1.04t_multicast_with_multicfg_main.bin.  i.e. it acts identically to a config file and reset get rid of its settings.   It looks like a file that an ISP could use in remote update to get telnet access to the end users modem.   

[npr]

it remains possible to find port 23 open when you do some things.  I will try to see if I can track down which things. 

Is that using the firmware file with or without telnet access?
I had assumed this didn't happen if you load the one without telnet.

I'm really not happy with the security aspect of this router and am very suspicious with how quickly I received hacking attempts when port 23 became open to the world.
Just wondering if this vulnerability has anything to do with the problem.
http://mis.fortunecook.ie/

[les-70]

  The no telnet version is fine on its own. It is use of a "telnet config" with it can sometimes lead to port 23 opening. 

  It is pity that the port forward options seem more limited than in other routers.  In principle you should be able to make the open port 23 harmless by redirecting it to another harmless port.

[kitzuser87430]

What about forwarding to a "spoofed" MAC address.
Ian