What's new
By:

Remote ssh attempts even though ssh is “LAN only”

T

table45

New Around Here
Hi all!

Experienced sysadmin here, but not a router expert.

TL;DR – My TUF-BE3600 had system log entries (bad password/no such user account) for a Vietnamese IP address attempting to SSH in, BUT remote/WAN SSH access is disabled, the firewall is enabled, and I can't remotely SSH access to it myself, so is there a setup issue or is it a bug?

Background
Woke up to my home internet being unresponsive. Wifi was up but no websites or apps could connect. Bounced wifi on my phone then rebooted the phone and still not working so I switched to looking at the router - instead of rebooting it decided to check it out first because why not.
  • I could connect to the router via its local wifi network using the ASUS app and web interface
  • I could also connect to it (with the app only) via mobile data
  • Devices connected to the router couldn't connect to any internet sites
  • On the router itself I could ping google, do dns lookups etc so its internet connection was working
  • While doing all the above I then happened to notice unexpected things as per below.
  • It all starting working again as soon as I rebooted the router
The weirdness I found before rebooting
Netstat ơn the router listed a connection on port 22 (SSH) from vietnam, (and also two connections to AWS EC2 instances that I figure are the remote connection to ASUS for remote management via the app):

tcp 115-xxxxmywanip.ip4.superloop.au:ssh dynamic-ip-adsl.viettel.vn:35916
tcp 115-xxxxmywanip.ip4.superloop.au:54202 ec2-54-200-198-224. us-west-2.compute.amaz...
tcp 115-xxxmywanip.ip4.superloop.au:42033 ec2-54-169-185-136. ap-southeast-1.ap-southeast-1.compu...
Click to expand...

The ssh connection was only there for a few seconds as it was gone the next time I ran netstat.

In the router's system.log at the same time you can see me successfully connecting to the router with my iPhone at 9:55:25 followed shortly after by a bad password attempt from 171.243.149.253 (which resolves to dynamic-ip-adsl.viettel.vn to match what was seen in netstat), followed by some login attempts for nonexistent users (wasn't me of course):

Jan 31 09:55:25 HTTPD: [LOGIN][https][APP] successed (192.168.50.144) [me from my phone]
Jan 31 09:55:32 dropbear[3483]: Bad password attempt for 'admin' from 171.243.149.253:40852
Jan 31 09:55:40 rc_service: httpds 3963:notify_rc start_webs_update
Jan 31 09:55:41 dropbear[3498]: Login attempt for nonexistent user
Jan 31 09:56:00 dropbear[3516]: Login attempt for nonexistent user
Jan 31 09:56:00 dropbear[3517]: Login attempt for nonexistent user
Jan 31 09:56:31 dropbear[3697]: Login attempt for nonexistent user
Jan 31 09:56:46 dropbear[3699]: Login attempt for nonexistent user
Click to expand...

Over the last 10 days of logs, the ONLY other dropbear events are successful logins for me connecting via its local Wifi 192.168.50.0 network. I guess the timing of me logging in to see what was broken, with this attempt was just a really massive coincidence (?). Happily the router admin password is unique, long, and randomly generated as are all my passwords.

But...correct me if I'm wrong, this shouldn't be happening!
  • "Enable SSH" was set to "LAN only"! --> It shouldn't be allowing remote connections
  • Router firewall was enabled

After the reboot I checked the following:
  • A remote port scan using online port scanners doesn't find any open ports on my public IP4 address, and trying to SSH in remotely doesn't work either (it times out)
  • I then changed “Enable SSH” to "LAN and WAN" and only then could I SSH to my router remotely (have changed it back of course), and I could see this router firewall rule appear and disappear "-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT" during this test
  • SSH port was still default of 22
  • There's no authorised SSH keys set up
  • Unrelated, but "Enable Web Access from WAN" is "No"
  • Firmware is still on latest version
The router is only about a month old, and I patched it straight away when I bought it.

So…how did this happen??
 
FWIW below is a dump of the firewall rules, which I haven’t customised and by my review would block inbound ssh to the router.
[some log/output rules removed to stay under character limit]

Code: 
admin@TUF-BE3600-DC58:/tmp/home/root# iptables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   23  1501 URLFI      udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 INPUT_PING  icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
  163 30645 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    1    44 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
  169 36497 PTCSRVWAN  all  --  !br0   *       0.0.0.0/0            0.0.0.0/0           
   31  2746 PTCSRVLAN  all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
    0     0 DROP       tcp  --  !lo    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:5152
   31  2746 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
  148 35561 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
    0     0 INPUT_ICMP  icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
   21   936 WGSI       all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   21   936 WGCI       all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   21   936 OVPNSI     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   21   936 OVPNCI     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   21   936 SDN_FI     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   21   936 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  348  149K NWFF       all  --  *      *       0.0.0.0/0            0.0.0.0/0           
  348  149K URLFF      all  --  *      *       0.0.0.0/0            0.0.0.0/0           
  348  149K IPSEC_DROP_SUBNET_ICMP  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
  348  149K IPSECSSDN  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
  348  149K IPSEC_STRONGSWAN  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   62  3856 TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x06/0x02 TCPMSS clamp to PMTU
  312  141K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
   36  7694 WGSF       all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   36  7694 OVPNSF     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0           
    1    40 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
    0     0 DNSFILTER_DOT  tcp  --  br+    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:853
   35  7654 WGCF       all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   35  7654 OVPNCF     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   35  7654 VPNCF      all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   35  7654 SDN_FF     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 397 packets, 67754 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   89  6368 OUTPUT_DNS  udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 u32 "0x0>>0x16&0x3c@0x8>>0xf&0x1=0x0"
    0     0 OUTPUT_DNS  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x8>>0xf&0x1=0x0"
  424 70477 OUTPUT_IP  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain ACCESS_RESTRICTION (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain DNSFILTER_DOT (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain FUPNP (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain IControls (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT_ICMP (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 13
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain INPUT_PING (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           

Chain IPSECSSDN (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain IPSEC_DROP_SUBNET_ICMP (1 references)
 pkts bytes target     prot opt in     out     source               destination         


Chain OUTPUT_IP (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 logdrop_ip  all  --  *      *       0.0.0.0/0            193.201.224.0/24    
    0     0 logdrop_ip  all  --  *      *       0.0.0.0/0            51.15.120.245       
    0     0 logdrop_ip  all  --  *      *       0.0.0.0/0            45.33.73.134        
    0     0 logdrop_ip  all  --  *      *       0.0.0.0/0            190.115.18.28       
    0     0 logdrop_ip  all  --  *      *       0.0.0.0/0            51.159.52.250       
    0     0 logdrop_ip  all  --  *      *       0.0.0.0/0            190.115.18.86       

Chain OVPNCF (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain OVPNCI (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain OVPNSF (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain OVPNSI (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain PControls (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain PTCSRVLAN (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain PTCSRVWAN (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain SDN_FF (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  br55   eth0    0.0.0.0/0            0.0.0.0/0           
   35  7654 ACCEPT     all  --  br0    eth0    0.0.0.0/0            0.0.0.0/0           
    0     0 SDN_IA     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain SDN_FI (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  br55   *       0.0.0.0/0            0.0.0.0/0            multiport dports 53,67,68
    0     0 DROP       all  --  br55   *       0.0.0.0/0            192.168.50.1        
    0     0 ACCEPT     all  --  br55   *       0.0.0.0/0            0.0.0.0/0            state NEW

Chain SDN_IA (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  br+    br+     0.0.0.0/0            0.0.0.0/0           


Chain URLFF (1 references)
 pkts bytes target     prot opt in     out     source               destination         
      

Chain URLFI (1 references)
 pkts bytes target     prot opt in     out     source               destination         



           
admin@TUF-BE3600-DC58:/tmp/home/root#
 
Your firewall rules look OK, but I'm guessing they were dumped after you rebooted the router and the problem went way?

One thing that confused me, you said "I could also connect to it (with the app only) via mobile data". So are you saying that the router is accessible from the internet using the app?

Another frequent cause for concern is AiCloud. Have you ever enabled that?
 
table45 said:
  • I could also connect to it (with the app only) via mobile data
Click to expand...
Typically if you can access your Asus router using the Asus app from outside the local network (i.e. using mobile data not WiFi) that indicates you have enabled the remote access features of the router. Those features typically require ports or services to be open on the router's WAN side so the app can access the router remotely.
[Wireless Router] How to set up ASUS wireless router to access WebGUI/Router App from WAN?

If using the Asus app, check that the Settings > System Settings > Remote Access option is disabled (turned off).
From the router GUI, see Administration > System > Remote Access Config. Ensure the option(s) Enable Web Access from WAN is disabled.
Double check that if you haven enabled SSH that it is configured for LAN Only.

If you have any other features enabled that are accessible from the router's WAN side, like AiCloud, Alexa support, or any sort of USB device access, make sure to disable them. AiCloud has been repeatedly patched by Asus due to it apparently being an intrusion access point for malware. With remote features disabled, check to see if the issue persists or repeats.
 
Last edited:
ColinTaylor said:
Your firewall rules look OK, but I'm guessing they were dumped after you rebooted the router and the problem went way?
Click to expand...
That’s correct. But I hadn’t done anything to them beforehand either.

ColinTaylor said:
One thing that confused me, you said "I could also connect to it (with the app only) via mobile data". So are you saying that the router is accessible from the internet using the app?
Click to expand...
Yes, the app can connect via what it calls “Secure Link”. It’s not open to the internet as such, it’s open to ASUS servers and the app connects to ASUS.

To be clear the web interface is disabled. Portscans show nothing open on the router because it isn’t listening - it connects to ASUS rather than the other way around, which is why you don’t see any firewall rule allowing an inbound connection for the app, because it’s an outbound connection.
 
bennor said:
Typically if you can access your Asus router using the Asus app from outside the local network (i.e. using mobile data not WiFi) that indicates you have enabled the remote access features of the router. Those features typically require ports or services to be open on the router's WAN side so the app can access the router remotely.
Click to expand...
As I replied just before that’s not how the ASUS app connections work, there are no open ports required to be listening on the router. The router establishes and maintains a tcp connection to ASUS servers in the cloud, and does not need to listen for inbound connections. Portscans show no ports open (except when I verified that ssh was open when I set it to “lan and wan” to verify the portscan was working correctly. The web interface would listen for inbound connections which I agree creates an attack surface, but I’ve never had that enabled.

bennor said:
If using the Asus app, check that the Settings > System Settings > Remote Access option is disabled (turned off).
Click to expand...
This is enabled, but not related to web access or ssh access. It’s just for remote connections for the app via ASUS as above.

bennor said:
From the router GUI, see Administration > System > Remote Access Config. Ensure the option(s) Enable Web Access from WAN is disabled.
Double check that if you haven enabled SSH that it is configured for LAN Only.
Click to expand...
Correct, web access from wan is disabled and always has been. SSH has always been off or lan only.

bennor said:
If you have any other features enabled that are accessible from the router's WAN side, like AiCloud, Alexa support, or any sort of USB device access, make sure to disable them. AiCloud has been repeatedly patched by Asus due to it apparently being an intrusion access point for malware. With remote features disabled, check to see if the issue persists or repeats.
Click to expand...
Aicloud and Alexa have never been enabled. Aiprotection has been disabled either for the whole time or from during the first day when I was installing the router - (can’t remember if it was enabled by default but it’s been off ever since I set up the router).
 
Going back earlier in the logs, you can see a wan connectivity problem, that seemingly fixed itself, but the router didn’t handle that well - when I woke up it wasn’t routing my internet traffic even though the wan and wifi were working separately, so maybe the firewall not blocking things is related to that.

Earlier before I woke up:
Jan 31 05:47:33 WAN(0) Connection: WAN was exceptionally disconnected.
Jan 31 05:47:34 udhcpc_wan[3909]: hnd_get_phy_status: Temporarily Router cannot get the PHY() status...
Jan 31 05:47:34 wan: finish adding multi routes
Jan 31 05:47:34 kernel: Crossbow TCP Pure ACK Enabled
Jan 30 19:47:34 wan_up: Find a 2.5G port on [eth0]
Jan 30 19:47:35 ping_target_with_size: Ping test is complete.
Jan 30 19:47:37 ping_target_with_size: Successful to ping target(115.186.xx.xx) with size(79)
Jan 30 19:47:37 wan_up: Restart DDNS
Jan 30 19:47:37 dhcp client: renew 115.186.xx.xx/255.255.254.0 via 115.186.xx.xx for 600 seconds.
Jan 31 05:47:43 WAN(0) Connection: WAN was restored.
Jan 31 05:47:46 ntp: start NTP update
Click to expand...


Compared to a reboot there’s a number of log entries that don’t happen compared to the above wan outage:

Jan 1 10:01:05 wan: finish adding multi routes
Jan 1 10:01:05 wan_up: Find a 2.5G port on [eth0]
Jan 1 10:01:05 kernel: Crossbow TCP Pure ACK Enabled
Jan 1 10:01:06 WAN(0) Connection: WAN was restored.
Jan 1 10:01:06 ping_target_with_size: Ping test is complete.
Jan 1 10:01:08 ntp: start NTP update
Jan 1 10:01:08 ping_target_with_size: Successful to ping target(115.186.xx.xx) with size(79)
Jan 1 10:01:08 wan_up: Restart DDNS
Jan 1 10:01:08 dhcp client: bound 115.186.xx.xx/255.255.254.0 via 115.186.xx.xx for 600 seconds.
Jan 31 10:25:01 rc_service: ntp 4970:notify_rc restart_stubby
Jan 31 10:25:01 rc_service: ntp 4970:notify_rc restart_diskmon
Jan 31 10:25:01 rc_service: waitting "restart_stubby"(last_rc:restart_autowan) via ntp ...
Jan 31 10:25:02 disk_monitor: Finish
Jan 31 10:25:02 disk monitor: be idle
Jan 31 10:25:07 networkmap: start scan...
Jan 31 10:25:09 dhcp6 client: bound address 2401:d005:xxxxx/128, prefix 2401:d005:xxxxxxx::/56
Jan 31 10:25:09 rc_service: dhcp6c 5024:notify_rc stop_dnsmasq
Jan 31 10:25:10 rc_service: dhcp6c 5024:notify_rc start_dnsmasq 255
Jan 31 10:25:11 rc_service: dhcp6c 5024:notify_rc restart_samba
Jan 31 10:25:11 Samba Server: smb daemon is stopped
Click to expand...
 
@table45, If a WAN side inbound SSH connection is being made to the router then the firewall is letting it through rather than outright dropping the connection. The question is what has instructed the router firewall to allow that connection? If you've double checked and disabled all methods of WAN side access (SSH, Asus app, AiCloud, AiDisk, port forwarding rules, DDNS, auto firmware update, etc.) on the router, then something else is apparently causing the router firewall to allow the WAN side SSH connection through to the router.

Do you have client on the local network that is configured to access the router's GUI? For example, something like a Synology NAS with the DSM Router Configuration feature enabled to configure router port forwarding rules to allow Synology NAS DiskStation to be accessible over the internet? If so disable that client's router GUI access feature and see if the issue returns.

If you haven't done so already, might also be a good idea to check the local network clients as well for any security issues (malware, antivirus, etc.) just in case a network client somehow is involved in this issue.

As a last resort, if you haven't done so already, you could do a hard factory reset on the router followed by a manual configuration (do not import a saved router CFG file) and monitor to see if the issue occurs again.
 
Thanks for replying.
bennor said:
Do you have client on the local network that is configured to access the router's GUI? For example, something like a Synology NAS with the DSM Router Configuration feature enabled to configure router port forwarding rules to allow Synology NAS DiskStation to be accessible over the internet? If so disable that client's router GUI access feature and see if the issue returns.
Click to expand...
I don’t have anything funky setup at all - no nas, no vpn, no forwarding or triggering and so on. Boring I know but I get enough action at work to not want it at home :)
bennor said:
If you haven't done so already, might also be a good idea to check the local network clients as well for any security issues (malware, antivirus, etc.) just in case a network client somehow is involved in this issue.
Click to expand...
The only clients with access are up to date iPhones/ipads/appletvs, and an up to date Mac mini which had been turned off for a week or two leading up to this. There’s a locked down school windows laptop but it wasn’t even physically here for a couple of days either.

bennor said:
As a last resort, if you haven't done so already, you could do a hard factory reset on the router followed by a manual configuration (do not import a saved router CFG file) and monitor to see if the issue occurs again.
Click to expand...
If it happens again I’ll have to do that. Will wait and see if I get another one of those wan errors and check it out afterwards.
 
Could be a forwarded port.
 
I’d have to suspect the workings of the protect_srv daemon at this point. This controls the PTCSRVWAN chain as far as I can tell. Closed source voodoo, so no idea what it’s doing inside, but seems like that’s the only point of entry from wan.
 
Have you tried setting a different ssh port?
 
You must log in or register to reply here.

Similar threads

S
SSH password auth suddenly stops working for admin user
Replies
0
Views
337
Samosa
S
I
dropbear[...]: Login attempt for nonexistent user from [External IP]
Replies
19
Views
2K
dave14305
dave14305
P
[Security] SSH port opened to WAN even though "Enable SSH" is set to "LAN only"
Replies
3
Views
967
Viktor Jaep
Viktor Jaep
joegreat
OpenVPN error/warning "write UDPv4: No buffer space available"
Replies
18
Views
1K
joegreat
joegreat
RMerlin
Release Asuswrt-Merlin 3004.388.10 is now available
15 16 17
Replies
324
Views
48K
nabice
N

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Total: 2,990 (members: 11, guests: 2,979)
Back
Top
✖