rbr50v2 and failed login attempts to rpis

[irish-rbr50]

I have an rbr50 as my main router/wifi in front of a cable modem running in modem mode.

I recently added 2 raspberry pis devices as pi-hole dns servers on my home network. However I now find a stream of continuous sshd authentication messages on both, showing various failed logins from external ip addresses using random or no usernames.

I checked https://www.whatismyip.com/port-scanner/ and could not find an open port, but the log messages keep coming on my raspberry pis, such as:

Dec 26 17:47:28 <rpi-name> sshd[3854]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=103.253.24.166
Dec 26 17:47:31<rpi-name> sshd[3854]: Failed password for invalid user web from 103.253.24.166 port 64597 ssh2
Dec 26 17:47:31<rpi-name> sshd[3854]: Connection closed by 103.253.24.166 port 64597 [preauth]
Dec 26 17:47:38<rpi-name> sshd[3866]: Invalid user web from 103.253.24.166 port 64810
Dec 26 17:47:38<rpi-name> sshd[3866]: input_userauth_request: invalid user web [preauth]
Dec 26 17:47:38<rpi-name> sshd[3866]: pam_unix(sshd:auth): check pass; user unknown
Dec 26 17:47:38<rpi-name> sshd[3866]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=103.253.24.166
Dec 26 17:47:40<rpi-name> sshd[3866]: Failed password for invalid user web from 103.253.24.166 port 64810 ssh2
Dec 26 17:47:40<rpi-name> sshd[3866]: Connection closed by 103.253.24.166 port 64810 [preauth]

My question is, how are these attempts coming through the RBR50 and what can I do to stop them?

[antinode · Accepted solution]

> The cable modem is supplied by my ISP, virgin media Ireland and, in
> modem mode has, 1 option, modem mode or router mode.

   Still not as useful a description as, say, a maker and model number
might be.  But, if it really is in modem-only mode, it shouldn't matter.
Is the IP address of the WAN/Internet interface on the RBR50v2 a public
address?

> I have no port forwarding rules, port triggering is disabled, UPnP is
> disabled.

   Did you verify that the ADVANCED > Advanced Setup > UPnp : UPnP
Portmap Table is empty?

   I'm out of possible causes.  If you're really getting outside-world
connections to multiple port-22 destinations, then I don't know what,
other than UPnP, could do it.  Of course, with Netgear router firmware,
almost any bug is possible, including leaving UPnP enabled/active when
the indicator says that it's not.

   My next step would be to configure an explicit dead-end
port-forwarding rule for (external) port 22, as suggested above.
Presumably, that would supercede any residual/misguided UPnP activity
for that port.  If UPnP actually is active, then attempting to add that
rule might fail with a complaint like:

      The specified port(s) are being used by other configurations.
      Please check your configurations of USB Readyshare, Remote
      Management, Port forwarding, Port Triggering, UPnP Port Mapping
      table, RIP, and Internet connection type.

   If that were to happen, then I'd disconnect everything except one
computer from the router's LAN (wired and wireless), restart the router,
and try it again.  (Then restore the normal LAN connections.)

[antinode]

> Model: RBR50|Orbi AC3000 Tri-band WiFi Router

   RBR50 or RBR50v2?  Firmware version?

> [...] a cable modem running in modem mode.

   Not a very detailed description of that device.

> My question is, how are these attempts coming through the RBR50 and
> what can I do to stop them?

   The usual threats for incoming connections are explicit port
forwarding/triggering, DMZ server, and UPnP.

   Presumably, you'd remember if you had explicitly configured port
forwarding for port 22 (SSH).

   You could have no more that one DMZ server, so that wouldn't explain
such annoyances on two different R-Pi systems.

   Only UPnP could be enabled by default (because only it is automatic
enough), so I'd check (and disable) that.  As the RBR50 User Manual
says:

      5. Select the Turn UPnP On check box.
         By default, this check box is selected. [...]

(Visit http://netgear.com/support , put in your (actual) model number,
and look for Documentation.  Get the User Manual.  Read.  Look for
"UPnP".)

   If you had some good reason to keep UPnP enabled, then I'd configure
an explicit port-forwarding rule for (external) port 22, and specify
some fictional server IP address in that rule (and any-old internal
port), so that no real system ever gets bothered.  (You could shrink
your DHCP pool from the usual default range of ".2" - ".254" to, say,
".2" - ".253", and use the ".254" address for your fictional/dead-end
server.  ADVANCED > Setup > LAN Setup : Use Router as DHCP Server :
<addresses>.  Alternatively, you could reserve some address like, say,
".254", and specify some unlikely MAC address ("00:00:00:00:00:01"?) in
that reservation, to ensure that no real system ever gets it.  <Same
page> : Address Reservation.)

   If you ever do want to enable SSH access from the outside world, this
shows why using external port 22 is a bad idea.  Specifying almost any
other (unpopular) external port stops almost all of those probes.

[irish-rbr50]

Thanks for the prompt reply.

The cable modem is supplied by my ISP, virgin media Ireland and, in modem mode has, 1 option, modem mode or router mode.

Correct, there was no port forwarding configured (I even disabled port triggering even though there was no rule added).

And correct again, UPnP was enabled, by default. I have promptly disabled it and have not seen a login attempt on my RPIs since.

Thanks again.

[irish-rbr50]

... and the messages are back.

It appeared to work for an hour or so and I went off doing other things. However the error messages came back, but initially the ssh attempts appeared to be coming from the Orbi itself. Then after a while the IP addresses switched back to external ones.

I have no port forwarding rules, port triggering is disabled, UPnP is disabled.

I did find a mention of similar symptom on a "unraid" box in a different thread and their conclusion was that it was Armor. I logged into https://armor.netgear.com/... and looked atm my router but there is no configuration detail to say what it is doing, but the error messages continue on my RPIs

pi@pi2:/var/log $ tail -f auth.log

Dec 28 15:25:15 pi2 sshd[22684]: Failed password for invalid user duser from 91.121.30.186 port 58788 ssh2

Dec 28 15:25:15 pi2 sshd[22684]: Received disconnect from 91.121.30.186 port 58788:11: Bye Bye [preauth]

Dec 28 15:25:15 pi2 sshd[22684]: Disconnected from 91.121.30.186 port 58788 [preauth]

Dec 28 15:25:15 pi2 sshd[22686]: Invalid user ubuntu from 49.234.101.196 port 54414

Dec 28 15:25:15 pi2 sshd[22686]: input_userauth_request: invalid user ubuntu [preauth]

Dec 28 15:25:15 pi2 sshd[22686]: pam_unix(sshd:auth): check pass; user unknown

Dec 28 15:25:15 pi2 sshd[22686]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=49.234.101.196

Dec 28 15:25:18 pi2 sshd[22686]: Failed password for invalid user ubuntu from 49.234.101.196 port 54414 ssh2

Dec 28 15:25:18 pi2 sshd[22686]: Received disconnect from 49.234.101.196 port 54414:11: Bye Bye [preauth]

Dec 28 15:25:18 pi2 sshd[22686]: Disconnected from 49.234.101.196 port 54414 [preauth]

Dec 28 15:25:58 pi2 sshd[22702]: Invalid user teamspeak3 from 51.105.5.16 port 58178

Dec 28 15:25:58 pi2 sshd[22702]: input_userauth_request: invalid user teamspeak3 [preauth]

Dec 28 15:25:58 pi2 sshd[22702]: pam_unix(sshd:auth): check pass; user unknown

Dec 28 15:25:58 pi2 sshd[22702]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=51.105.5.16

Dec 28 15:26:00 pi2 sshd[22702]: Failed password for invalid user teamspeak3 from 51.105.5.16 port 58178 ssh2

Dec 28 15:26:00 pi2 sshd[22702]: Received disconnect from 51.105.5.16 port 58178:11: Bye Bye [preauth]

Dec 28 15:26:00 pi2 sshd[22702]: Disconnected from 51.105.5.16 port 58178 [preauth]

Dec 28 15:26:07 pi2 sshd[22714]: Invalid user ftpuser from 51.254.102.19 port 47660

Dec 28 15:26:07 pi2 sshd[22714]: input_userauth_request: invalid user ftpuser [preauth]

Dec 28 15:26:07 pi2 sshd[22714]: pam_unix(sshd:auth): check pass; user unknown

Dec 28 15:26:07 pi2 sshd[22714]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=51.254.102.19

Dec 28 15:26:09 pi2 sshd[22714]: Failed password for invalid user ftpuser from 51.254.102.19 port 47660 ssh2

Dec 28 15:26:09 pi2 sshd[22714]: Received disconnect from 51.254.102.19 port 47660:11: Bye Bye [preauth]

Dec 28 15:26:09 pi2 sshd[22714]: Disconnected from 51.254.102.19 port 47660 [preauth]

[antinode · Accepted solution]

> The cable modem is supplied by my ISP, virgin media Ireland and, in
> modem mode has, 1 option, modem mode or router mode.

   Still not as useful a description as, say, a maker and model number
might be.  But, if it really is in modem-only mode, it shouldn't matter.
Is the IP address of the WAN/Internet interface on the RBR50v2 a public
address?

> I have no port forwarding rules, port triggering is disabled, UPnP is
> disabled.

   Did you verify that the ADVANCED > Advanced Setup > UPnp : UPnP
Portmap Table is empty?

   I'm out of possible causes.  If you're really getting outside-world
connections to multiple port-22 destinations, then I don't know what,
other than UPnP, could do it.  Of course, with Netgear router firmware,
almost any bug is possible, including leaving UPnP enabled/active when
the indicator says that it's not.

   My next step would be to configure an explicit dead-end
port-forwarding rule for (external) port 22, as suggested above.
Presumably, that would supercede any residual/misguided UPnP activity
for that port.  If UPnP actually is active, then attempting to add that
rule might fail with a complaint like:

      The specified port(s) are being used by other configurations.
      Please check your configurations of USB Readyshare, Remote
      Management, Port forwarding, Port Triggering, UPnP Port Mapping
      table, RIP, and Internet connection type.

   If that were to happen, then I'd disconnect everything except one
computer from the router's LAN (wired and wireless), restart the router,
and try it again.  (Then restore the normal LAN connections.)

[irish-rbr50]

Looks like the attempts stopped a some hours after I sent the previous email but before I made any changes....

The cable modem really is in modem-only mode, and provides an ISP supplied IP public address. It is relatively static, but has occasionally changed after resets.

For some reason, the ssh attempts stopped at 16:01 local time on the 29th. Up to that, there had been 10-15 a minute since I noticed. Is there a cron job in the router that 'delayed' the application of the config settings?

Either way, the login attempts have stopped but to be sure, per your suggestion, I shrunk the DHCP range and added an SSH forwarding rule to one of the unused IP addresses.

Thanks for the help and suggestions.

FWIW, Of the 2,404 usernames in the short log, the top 25 attempted logins make for a curious list:

$ egrep Invalid /var/log/auth.log | awk -F" " '{print $8}' | sort | uniq -c | sort -n | tail -25

     50 netman

     53 osmc

     67 ftpuser

     80 git

     80 nagios

     84 oracle

     87 guest

    102 postgres

    156 from

    160 test

    192 ubuntu

    235 tech

    248 telecomadmin

    256 admin1

    258 administrator

    263 profile1

    272 MikroTik

    272 web

    273 default

    282 demo

    284 ubnt

    301 user1

    323 support

    402 user

    785 admin

[antinode]

> Looks like the attempts stopped a some hours after I sent the previous
> email but before I made any changes....

   Sounds like a mystery.

> [...] Is there a cron job in the router that 'delayed' the application
> of the config settings?

   I doubt it.  But what do I know?

> [...] the login attempts have stopped but to be sure, [...]

   What could go wrong?

> FWIW, Of the 2,404 usernames in the short log, the top 25 attempted
> logins make for a curious list: [...]

   I assume that the malware writers did some research on popular user
names and passwords.  Especially cases where some package/account is
installed with a (constant) default password.

   Around here, SSH is not at port 22, so about all I see (with
credentials) are FTP attacks.  My outward facing server runs VMS, so
most of the popular Unix and Windows user names don't apply.  On rare
occasions someone/thing tries "SYSTEM", but my password seems to be
good enough.  (And, after N failures, break-in avoidance takes over, and
stops even good credentials from working for a while from that source.

   Thirty or forty years ago (pre-Internet), a VMS installation assigned
a password of "MANAGER" to the "SYSTEM" account (similar for a few
others: FIELD+SERVICE, ...), and left it up to the system manager to add
some security, but in recent decades the installation procedure demands
non-trivial passwords for the automatically-created accounts.