NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Port forwarding of ANY kind opens all ports!!!
R7000 with FW V1.0.11.110_10.2.100
connected to the internet via cox isp through a CM1100 cable modem
I have configured port forwarding for ssh using nonstandard incoming "world" port to another nonstandard sshd server port on my linux box. As soon as I apply this chanage I start getting attacks on all sorts of ports.....See small sample below from my auth logs.
THE ONLY WAY that all inbound attempts are stopped by the R7000 is to have NO port forwarding whatsoever enabled.
It seems, there is a HUGE bug in the NAT filtering/prot forwarding implementation!
These needs fixing!!
Feb 8 02:10:04 archimedes sshd[1154]: Invalid user jeremy from 115.182.105.68 port 37561
Feb 8 02:10:04 archimedes sshd[1154]: pam_unix(sshd:auth): check pass; user unknown
Feb 8 02:10:04 archimedes sshd[1154]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.182.105.68
Feb 8 02:10:06 archimedes sshd[1156]: Invalid user akhan from 115.236.52.122 port 60446
Feb 8 02:10:06 archimedes sshd[1156]: pam_unix(sshd:auth): check pass; user unknown
Feb 8 02:10:06 archimedes sshd[1156]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.236.52.122
Feb 8 02:10:07 archimedes sshd[1154]: Failed password for invalid user jeremy from 115.182.105.68 port 37561 ssh2
Feb 8 02:10:07 archimedes sshd[1156]: Failed password for invalid user akhan from 115.236.52.122 port 60446 ssh2
Feb 8 02:10:08 archimedes sshd[1158]: User root from 106.121.179.45 not allowed because not listed in AllowUsers
Feb 8 02:10:08 archimedes sshd[1158]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=106.121.179.45 user=root
Feb 8 02:10:08 archimedes sshd[1156]: Received disconnect from 115.236.52.122 port 60446:11: Bye Bye [preauth]
Feb 8 02:10:08 archimedes sshd[1156]: Disconnected from invalid user akhan 115.236.52.122 port 60446 [preauth]
Feb 8 02:10:09 archimedes sshd[1154]: Received disconnect from 115.182.105.68 port 37561:11: Bye Bye [preauth]
Feb 8 02:10:09 archimedes sshd[1154]: Disconnected from invalid user jeremy 115.182.105.68 port 37561 [preauth]
Feb 8 02:10:10 archimedes sshd[1158]: Failed password for invalid user root from 106.121.179.45 port 61091 ssh2
Feb 8 02:10:10 archimedes sshd[1158]: Received disconnect from 106.121.179.45 port 61091:11: Bye Bye [preauth]
Feb 8 02:10:10 archimedes sshd[1158]: Disconnected from invalid user root 106.121.179.45 port 61091 [preauth]
6 Replies
> I have configured port forwarding for ssh using nonstandard incoming
> "world" port [...]That's a good idea.
> [...] to another nonstandard sshd server port on my linux box. [...]
Because you want to make your own life harder? What's wrong with
using the default port (22) on your own LAN?> [...] See small sample below from my auth logs.
Have you looked at the router log?
> It seems, there is a HUGE bug in the NAT filtering/prot forwarding
> implementation!Or the user made a HUGE error.
I haven't done any port forwarding on an R7000 with recent firmware,
so I know nothing, and Netgear has released some remarkable bugs, but I
find it a little hard to believe that they've broken this feature this
badly. And this is the only such report. It also seems unlikely that
you're getting many SSH attacks on "another nonstandard sshd server
port". Around here, I've seen attacks on port 22, but almost none on my
own 'nonstandard incoming "world" port'.If I believed that I had such a problem, I'd try a few things:
Double-check the port-forwarding rule(s) (which I can't see from
here). Ensure that there's no DMZ server defined. Disable UPnP.Double-check the sshd configuration. "netstat -an"? Is it really
listening on some non-standard port?Scan the router log for SSH connection attempts. Which ports are
shown there?Settings reset, and manual reconfiguration.
Load some well-tested older firmware version (V1.0.9.42_10.2.44 was
popular), reset, reconfigure.> These needs fixing!!
Something might.
antinode wrote:> I have configured port forwarding for ssh using nonstandard incoming
> "world" port [...]That's a good idea.
Indeed
> [...] to another nonstandard sshd server port on my linux box. [...]
Because you want to make your own life harder? What's wrong with
using the default port (22) on your own LAN?Port 22 is the defacto ssh port so that would be the first hit IF attackes made it through the router, so I changed it internally as a test
> [...] See small sample below from my auth logs.
Have you looked at the router log?
Yes but forgot to paste that in the first post. What I did paste was from /var/log/auth.log on my linux server. I have a nice chunck of router log I will paste below.
> It seems, there is a HUGE bug in the NAT filtering/prot forwarding
> implementation!Or the user made a HUGE error.
Agreed a possibility but given the evidence and my ability to follow simple directions.....
I haven't done any port forwarding on an R7000 with recent firmware,
so I know nothing, and Netgear has released some remarkable bugs, but I
find it a little hard to believe that they've broken this feature this
badly. And this is the only such report. It also seems unlikely that
you're getting many SSH attacks on "another nonstandard sshd server
port". Around here, I've seen attacks on port 22, but almost none on my
own 'nonstandard incoming "world" port'.If I believed that I had such a problem, I'd try a few things:
Double-check the port-forwarding rule(s) (which I can't see from
here). Ensure that there's no DMZ server defined. Disable UPnP.DMZ and UPnP are BOTH DISABLED.
Double-check the sshd configuration. "netstat -an"? Is it really
listening on some non-standard port?I do know how to config sshd and YES it is listening only on the specific port ( I wll need to change this now). I can not access the server except using that port ssh -p (as a second check)
Scan the router log for SSH connection attempts. Which ports are
shown there?PLEASE SEE BELOW
Settings reset, and manual reconfiguration.
Load some well-tested older firmware version (V1.0.9.42_10.2.44 was
popular), reset, reconfigure.> These needs fixing!!
Something might.
Here is a short snippet of the router logs showing every attack that hit the router was directed to 51519 on 192.168.9.53 BUT the forwarding was set to allow ONLY ONE inbound port number and NONE of those identify below are it. Its as .
R7000 Router Log snippit
[LAN access from remote] from 103.84.194.111:53772 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:13:47
[LAN access from remote] from 181.49.246.20:42622 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:13:32
[LAN access from remote] from 101.226.21.105:60298 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:13:29
[LAN access from remote] from 66.70.142.214:35772 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:13:29
[LAN access from remote] from 139.59.32.156:47552 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:13:27
[LAN access from remote] from 203.151.144.160:46238 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:13:27
[LAN access from remote] from 103.84.194.111:49193 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:12:49
[LAN access from remote] from 183.195.121.197:48760 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:12:45
[LAN access from remote] from 172.81.239.224:60536 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:12:31
[LAN access from remote] from 42.192.8.30:40266 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:11:57
[LAN access from remote] from 62.94.153.133:54741 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:11:52
[LAN access from remote] from 103.84.194.111:44615 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:11:51
[LAN access from remote] from 183.195.121.197:36359 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:11:00
[LAN access from remote] from 103.84.194.111:40036 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:10:54
[DHCP IP: (192.168.9.56)] to MAC address 98:09:CF:90:A8:98, Tuesday, Feb 09,2021 13:10:50
[LAN access from remote] from 203.151.144.160:57884 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:10:38
[LAN access from remote] from 181.49.246.20:56168 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:10:33
[LAN access from remote] from 181.209.23.195:58494 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:10:30
[LAN access from remote] from 66.70.142.214:53520 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:10:17
[LAN access from remote] from 172.81.239.224:47760 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:10:04
[LAN access from remote] from 120.88.46.226:51886 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:10:03
[LAN access from remote] from 103.84.194.111:35457 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:09:55
[LAN access from remote] from 101.226.21.105:47115 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:09:53
[LAN access from remote] from 139.59.32.156:60330 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:09:52
[LAN access from remote] from 42.192.8.30:55398 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:09:27
[LAN access from remote] from 183.195.121.197:52196 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:09:19
[LAN access from remote] from 103.84.194.111:59111 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:08:58
[LAN access from remote] from 62.94.153.133:60806 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:08:42
[LAN access from remote] from 103.84.194.111:54533 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:07:58
[LAN access from remote] from 203.151.144.160:41342 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:07:53
[LAN access from remote] from 181.49.246.20:41480 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:07:47
[LAN access from remote] from 172.81.239.224:34982 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:07:35
[LAN access from remote] from 120.88.46.226:36680 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:07:15
[LAN access from remote] from 66.70.142.214:43044 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:07:06
[LAN access from remote] from 103.84.194.111:49953 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:07:01
[LAN access from remote] from 42.192.8.30:42268 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:06:46
[LAN access from remote] from 181.209.23.195:43880 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:06:30
[LAN access from remote] from 101.226.21.105:33928 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:06:19
[LAN access from remote] from 139.59.32.156:44864 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:06:04
[LAN access from remote] from 103.84.194.111:45375 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:06:01
[LAN access from remote] from 62.94.153.133:38639 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:05:21
[LAN access from remote] from 183.195.121.197:39808 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:05:11
[LAN access from remote] from 203.151.144.160:52876 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:05:03
[LAN access from remote] from 103.84.194.111:40796 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:05:03
[LAN access from remote] from 181.49.246.20:55026 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:04:49
[LAN access from remote] from 194.147.140.91:44416 to 192.168.9.53:80, Tuesday, Feb 09,2021 13:04:40
[LAN access from remote] from 120.88.46.226:49704 to 192.168.9.53:51519, Tuesday, Feb 09,2021 13:04:20> [...] I can not access the server except using that port ssh -p (as a
> second check)That's on your LAN?
> Here is a short snippet of the router logs showing every attack that
> hit the router was directed to 51519 on 192.168.9.53 [...]That makes sense if the "Internal Port" in your port-forwarding rule
is 51519.> [...] BUT the forwarding was set to allow ONLY ONE inbound port number
> [...]_Which_ "ONE inbound port number"? 22?
> [...] and NONE of those identify below are it. Its as .
The _source_ port numbers in that log are insignificant.> Double-check the port-forwarding rule(s) (which I can't see from
> here). [...]I still haven't seen your port-forwarding rule for SSH, but my
current inference is that you got its port numbers backward. That is,
the external port number is 22, and the internal port number is 51519.
What you _want_ in the rule is a non-standard _external_ port number
(for security/obscurity), and a standard (maximally convenient)
_internal_ port number. And a server which listens at that standard
port, of course.The fact that you're getting apparently real SSH attacks (as
evidenced by "invalid user" messages in the server system log), with
high-frequency, also suggests that your router is listening at the
standard SSH port.> Port 22 is the defacto ssh port so that would be the first hit IF
> attackes made it through the router, so I changed it internally as a
> testNot a threat if you configure port forwarding (and DMZ and UPnP)
properly.