Understanding sshd logs
Clash Royale CLAN TAG#URR8PPP
I understand where to find the logs, but I am not always sure what they mean. And I can't exactly find a comprehensive guide on sshd logs explaining what they mean.
I am particularly concerned with this set of log attempts:
Feb 03 01:08:47 malan-server sshd[8110]: Invalid user centos from 193.106.58.90 port 34574
Feb 03 01:08:47 malan-server sshd[8110]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:08:48 malan-server sshd[8110]: Failed password for invalid user centos from 193.106.58.90 port 34574 ssh2
Feb 03 01:08:49 malan-server sshd[8110]: Connection closed by invalid user centos 193.106.58.90 port 34574 [preauth]
Feb 03 01:14:30 malan-server sshd[8114]: Invalid user centos from 193.106.58.90 port 39249
Feb 03 01:14:30 malan-server sshd[8114]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:14:32 malan-server sshd[8114]: Failed password for invalid user centos from 193.106.58.90 port 39249 ssh2
Feb 03 01:14:34 malan-server sshd[8114]: Connection closed by invalid user centos 193.106.58.90 port 39249 [preauth]
Feb 03 01:20:18 malan-server sshd[8118]: Invalid user centos from 193.106.58.90 port 43934
Feb 03 01:20:18 malan-server sshd[8118]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:20:20 malan-server sshd[8118]: Failed password for invalid user centos from 193.106.58.90 port 43934 ssh2
Feb 03 01:20:22 malan-server sshd[8118]: Connection closed by invalid user centos 193.106.58.90 port 43934 [preauth]
Feb 03 01:26:06 malan-server sshd[8121]: Invalid user centos from 193.106.58.90 port 48611
Feb 03 01:26:06 malan-server sshd[8121]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:26:08 malan-server sshd[8121]: Failed password for invalid user centos from 193.106.58.90 port 48611 ssh2
Feb 03 01:26:08 malan-server sshd[8121]: Connection closed by invalid user centos 193.106.58.90 port 48611 [preauth]
There are plenty that day from that same IP address, 193.106.58.90
in Kiev, Ukraine.
Another set of scary looking logs are these:
Feb 04 19:58:29 malan-server sshd[9725]: Bad protocol version identification 'RFB 003.003' from 142.44.253.51 port 36772
Feb 04 23:47:52 malan-server sshd[9762]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248
Feb 05 06:40:36 malan-server sshd[9836]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 186.4.174.94 port 34515
Feb 05 07:59:13 malan-server sshd[9850]: Bad protocol version identification 'GET / HTTP/1.1' from 209.17.97.34 port 43944
Feb 05 09:09:48 malan-server sshd[9863]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 98.150.93.187 port 60182
Feb 05 14:09:45 malan-server sshd[9911]: Did not receive identification string from 191.232.54.97 port 63982
Feb 05 14:09:45 malan-server sshd[9912]: Bad protocol version identification '03' from 191.232.54.97 port 64044
Feb 05 14:09:45 malan-server sshd[9913]: Bad protocol version identification '03' from 191.232.54.97 port 64136
Feb 05 14:33:37 malan-server sshd[9919]: Bad protocol version identification '' from 198.108.67.48 port 56086
What do these mean?
I understand that the Internet is a big bad mean scary place where public-facing IP addresses constantly get bombarded with bot-attacks. But I have my router configured to forward connections on port 9000 to my server's port 22, so I am not entirely sure how there are still bot-attacks. It seemed unlikely to me that they would be port scanning all 65,535 possible ports.
I'll write a list of questions:
- Did I just choose a port that's too easy to guess? What would be a better port number?
- What do the port numbers in these sshd logs even mean? How can they have access to port 44493 if my router is only configured to forward port 9000 to port 22? It seems obvious to me that the port number listed is not the same thing as the outward-facing computer port, because I only access through port 9000, yet the port number listed for my own external logins is not 9000.
- What does
[preauth]
mean? - What does
Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248
mean?
ssh logs
|
show 3 more comments
I understand where to find the logs, but I am not always sure what they mean. And I can't exactly find a comprehensive guide on sshd logs explaining what they mean.
I am particularly concerned with this set of log attempts:
Feb 03 01:08:47 malan-server sshd[8110]: Invalid user centos from 193.106.58.90 port 34574
Feb 03 01:08:47 malan-server sshd[8110]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:08:48 malan-server sshd[8110]: Failed password for invalid user centos from 193.106.58.90 port 34574 ssh2
Feb 03 01:08:49 malan-server sshd[8110]: Connection closed by invalid user centos 193.106.58.90 port 34574 [preauth]
Feb 03 01:14:30 malan-server sshd[8114]: Invalid user centos from 193.106.58.90 port 39249
Feb 03 01:14:30 malan-server sshd[8114]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:14:32 malan-server sshd[8114]: Failed password for invalid user centos from 193.106.58.90 port 39249 ssh2
Feb 03 01:14:34 malan-server sshd[8114]: Connection closed by invalid user centos 193.106.58.90 port 39249 [preauth]
Feb 03 01:20:18 malan-server sshd[8118]: Invalid user centos from 193.106.58.90 port 43934
Feb 03 01:20:18 malan-server sshd[8118]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:20:20 malan-server sshd[8118]: Failed password for invalid user centos from 193.106.58.90 port 43934 ssh2
Feb 03 01:20:22 malan-server sshd[8118]: Connection closed by invalid user centos 193.106.58.90 port 43934 [preauth]
Feb 03 01:26:06 malan-server sshd[8121]: Invalid user centos from 193.106.58.90 port 48611
Feb 03 01:26:06 malan-server sshd[8121]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:26:08 malan-server sshd[8121]: Failed password for invalid user centos from 193.106.58.90 port 48611 ssh2
Feb 03 01:26:08 malan-server sshd[8121]: Connection closed by invalid user centos 193.106.58.90 port 48611 [preauth]
There are plenty that day from that same IP address, 193.106.58.90
in Kiev, Ukraine.
Another set of scary looking logs are these:
Feb 04 19:58:29 malan-server sshd[9725]: Bad protocol version identification 'RFB 003.003' from 142.44.253.51 port 36772
Feb 04 23:47:52 malan-server sshd[9762]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248
Feb 05 06:40:36 malan-server sshd[9836]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 186.4.174.94 port 34515
Feb 05 07:59:13 malan-server sshd[9850]: Bad protocol version identification 'GET / HTTP/1.1' from 209.17.97.34 port 43944
Feb 05 09:09:48 malan-server sshd[9863]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 98.150.93.187 port 60182
Feb 05 14:09:45 malan-server sshd[9911]: Did not receive identification string from 191.232.54.97 port 63982
Feb 05 14:09:45 malan-server sshd[9912]: Bad protocol version identification '03' from 191.232.54.97 port 64044
Feb 05 14:09:45 malan-server sshd[9913]: Bad protocol version identification '03' from 191.232.54.97 port 64136
Feb 05 14:33:37 malan-server sshd[9919]: Bad protocol version identification '' from 198.108.67.48 port 56086
What do these mean?
I understand that the Internet is a big bad mean scary place where public-facing IP addresses constantly get bombarded with bot-attacks. But I have my router configured to forward connections on port 9000 to my server's port 22, so I am not entirely sure how there are still bot-attacks. It seemed unlikely to me that they would be port scanning all 65,535 possible ports.
I'll write a list of questions:
- Did I just choose a port that's too easy to guess? What would be a better port number?
- What do the port numbers in these sshd logs even mean? How can they have access to port 44493 if my router is only configured to forward port 9000 to port 22? It seems obvious to me that the port number listed is not the same thing as the outward-facing computer port, because I only access through port 9000, yet the port number listed for my own external logins is not 9000.
- What does
[preauth]
mean? - What does
Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248
mean?
ssh logs
One of these questions (concerning port numbers) has been answered here. I found the answer after I posted the question.
– malan
Feb 11 at 16:36
1
By using a non-standard port, you additionally attract probes that are not necessarily meant for an SSH server, so all sorts of funky HTTP-type requests are obviously coming in.
– Kusalananda
Feb 11 at 16:43
1
and I wouldn't put it past people to scan all 65,535 ports and look for things that answer, and then to match those answering strings with typical protocols.
– Jeff Schaller
Feb 11 at 16:44
1
note also the very regular timing between the logs in the first example: 348 seconds, 348 seconds, 343 seconds. A human wouldn't wait so long, nor be so regular.
– Jeff Schaller
Feb 11 at 17:07
1
@Jeff well spotted; and that corresponds to a scan rate of 200 attempts per second, if the source is attempting connections on all ports (assuming 9000 is the only open port and is therefore the only port which adds significant delay to the scan).
– Stephen Kitt
Feb 11 at 17:22
|
show 3 more comments
I understand where to find the logs, but I am not always sure what they mean. And I can't exactly find a comprehensive guide on sshd logs explaining what they mean.
I am particularly concerned with this set of log attempts:
Feb 03 01:08:47 malan-server sshd[8110]: Invalid user centos from 193.106.58.90 port 34574
Feb 03 01:08:47 malan-server sshd[8110]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:08:48 malan-server sshd[8110]: Failed password for invalid user centos from 193.106.58.90 port 34574 ssh2
Feb 03 01:08:49 malan-server sshd[8110]: Connection closed by invalid user centos 193.106.58.90 port 34574 [preauth]
Feb 03 01:14:30 malan-server sshd[8114]: Invalid user centos from 193.106.58.90 port 39249
Feb 03 01:14:30 malan-server sshd[8114]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:14:32 malan-server sshd[8114]: Failed password for invalid user centos from 193.106.58.90 port 39249 ssh2
Feb 03 01:14:34 malan-server sshd[8114]: Connection closed by invalid user centos 193.106.58.90 port 39249 [preauth]
Feb 03 01:20:18 malan-server sshd[8118]: Invalid user centos from 193.106.58.90 port 43934
Feb 03 01:20:18 malan-server sshd[8118]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:20:20 malan-server sshd[8118]: Failed password for invalid user centos from 193.106.58.90 port 43934 ssh2
Feb 03 01:20:22 malan-server sshd[8118]: Connection closed by invalid user centos 193.106.58.90 port 43934 [preauth]
Feb 03 01:26:06 malan-server sshd[8121]: Invalid user centos from 193.106.58.90 port 48611
Feb 03 01:26:06 malan-server sshd[8121]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:26:08 malan-server sshd[8121]: Failed password for invalid user centos from 193.106.58.90 port 48611 ssh2
Feb 03 01:26:08 malan-server sshd[8121]: Connection closed by invalid user centos 193.106.58.90 port 48611 [preauth]
There are plenty that day from that same IP address, 193.106.58.90
in Kiev, Ukraine.
Another set of scary looking logs are these:
Feb 04 19:58:29 malan-server sshd[9725]: Bad protocol version identification 'RFB 003.003' from 142.44.253.51 port 36772
Feb 04 23:47:52 malan-server sshd[9762]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248
Feb 05 06:40:36 malan-server sshd[9836]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 186.4.174.94 port 34515
Feb 05 07:59:13 malan-server sshd[9850]: Bad protocol version identification 'GET / HTTP/1.1' from 209.17.97.34 port 43944
Feb 05 09:09:48 malan-server sshd[9863]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 98.150.93.187 port 60182
Feb 05 14:09:45 malan-server sshd[9911]: Did not receive identification string from 191.232.54.97 port 63982
Feb 05 14:09:45 malan-server sshd[9912]: Bad protocol version identification '03' from 191.232.54.97 port 64044
Feb 05 14:09:45 malan-server sshd[9913]: Bad protocol version identification '03' from 191.232.54.97 port 64136
Feb 05 14:33:37 malan-server sshd[9919]: Bad protocol version identification '' from 198.108.67.48 port 56086
What do these mean?
I understand that the Internet is a big bad mean scary place where public-facing IP addresses constantly get bombarded with bot-attacks. But I have my router configured to forward connections on port 9000 to my server's port 22, so I am not entirely sure how there are still bot-attacks. It seemed unlikely to me that they would be port scanning all 65,535 possible ports.
I'll write a list of questions:
- Did I just choose a port that's too easy to guess? What would be a better port number?
- What do the port numbers in these sshd logs even mean? How can they have access to port 44493 if my router is only configured to forward port 9000 to port 22? It seems obvious to me that the port number listed is not the same thing as the outward-facing computer port, because I only access through port 9000, yet the port number listed for my own external logins is not 9000.
- What does
[preauth]
mean? - What does
Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248
mean?
ssh logs
I understand where to find the logs, but I am not always sure what they mean. And I can't exactly find a comprehensive guide on sshd logs explaining what they mean.
I am particularly concerned with this set of log attempts:
Feb 03 01:08:47 malan-server sshd[8110]: Invalid user centos from 193.106.58.90 port 34574
Feb 03 01:08:47 malan-server sshd[8110]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:08:47 malan-server sshd[8110]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:08:48 malan-server sshd[8110]: Failed password for invalid user centos from 193.106.58.90 port 34574 ssh2
Feb 03 01:08:49 malan-server sshd[8110]: Connection closed by invalid user centos 193.106.58.90 port 34574 [preauth]
Feb 03 01:14:30 malan-server sshd[8114]: Invalid user centos from 193.106.58.90 port 39249
Feb 03 01:14:30 malan-server sshd[8114]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:14:30 malan-server sshd[8114]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:14:32 malan-server sshd[8114]: Failed password for invalid user centos from 193.106.58.90 port 39249 ssh2
Feb 03 01:14:34 malan-server sshd[8114]: Connection closed by invalid user centos 193.106.58.90 port 39249 [preauth]
Feb 03 01:20:18 malan-server sshd[8118]: Invalid user centos from 193.106.58.90 port 43934
Feb 03 01:20:18 malan-server sshd[8118]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:20:18 malan-server sshd[8118]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:20:20 malan-server sshd[8118]: Failed password for invalid user centos from 193.106.58.90 port 43934 ssh2
Feb 03 01:20:22 malan-server sshd[8118]: Connection closed by invalid user centos 193.106.58.90 port 43934 [preauth]
Feb 03 01:26:06 malan-server sshd[8121]: Invalid user centos from 193.106.58.90 port 48611
Feb 03 01:26:06 malan-server sshd[8121]: pam_tally(sshd:auth): pam_get_uid; no such user
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): check pass; user unknown
Feb 03 01:26:06 malan-server sshd[8121]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=193.106.58.90
Feb 03 01:26:08 malan-server sshd[8121]: Failed password for invalid user centos from 193.106.58.90 port 48611 ssh2
Feb 03 01:26:08 malan-server sshd[8121]: Connection closed by invalid user centos 193.106.58.90 port 48611 [preauth]
There are plenty that day from that same IP address, 193.106.58.90
in Kiev, Ukraine.
Another set of scary looking logs are these:
Feb 04 19:58:29 malan-server sshd[9725]: Bad protocol version identification 'RFB 003.003' from 142.44.253.51 port 36772
Feb 04 23:47:52 malan-server sshd[9762]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248
Feb 05 06:40:36 malan-server sshd[9836]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 186.4.174.94 port 34515
Feb 05 07:59:13 malan-server sshd[9850]: Bad protocol version identification 'GET / HTTP/1.1' from 209.17.97.34 port 43944
Feb 05 09:09:48 malan-server sshd[9863]: Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 98.150.93.187 port 60182
Feb 05 14:09:45 malan-server sshd[9911]: Did not receive identification string from 191.232.54.97 port 63982
Feb 05 14:09:45 malan-server sshd[9912]: Bad protocol version identification '03' from 191.232.54.97 port 64044
Feb 05 14:09:45 malan-server sshd[9913]: Bad protocol version identification '03' from 191.232.54.97 port 64136
Feb 05 14:33:37 malan-server sshd[9919]: Bad protocol version identification '' from 198.108.67.48 port 56086
What do these mean?
I understand that the Internet is a big bad mean scary place where public-facing IP addresses constantly get bombarded with bot-attacks. But I have my router configured to forward connections on port 9000 to my server's port 22, so I am not entirely sure how there are still bot-attacks. It seemed unlikely to me that they would be port scanning all 65,535 possible ports.
I'll write a list of questions:
- Did I just choose a port that's too easy to guess? What would be a better port number?
- What do the port numbers in these sshd logs even mean? How can they have access to port 44493 if my router is only configured to forward port 9000 to port 22? It seems obvious to me that the port number listed is not the same thing as the outward-facing computer port, because I only access through port 9000, yet the port number listed for my own external logins is not 9000.
- What does
[preauth]
mean? - What does
Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248
mean?
ssh logs
ssh logs
edited Feb 11 at 16:32
malan
asked Feb 11 at 16:25
malanmalan
667521
667521
One of these questions (concerning port numbers) has been answered here. I found the answer after I posted the question.
– malan
Feb 11 at 16:36
1
By using a non-standard port, you additionally attract probes that are not necessarily meant for an SSH server, so all sorts of funky HTTP-type requests are obviously coming in.
– Kusalananda
Feb 11 at 16:43
1
and I wouldn't put it past people to scan all 65,535 ports and look for things that answer, and then to match those answering strings with typical protocols.
– Jeff Schaller
Feb 11 at 16:44
1
note also the very regular timing between the logs in the first example: 348 seconds, 348 seconds, 343 seconds. A human wouldn't wait so long, nor be so regular.
– Jeff Schaller
Feb 11 at 17:07
1
@Jeff well spotted; and that corresponds to a scan rate of 200 attempts per second, if the source is attempting connections on all ports (assuming 9000 is the only open port and is therefore the only port which adds significant delay to the scan).
– Stephen Kitt
Feb 11 at 17:22
|
show 3 more comments
One of these questions (concerning port numbers) has been answered here. I found the answer after I posted the question.
– malan
Feb 11 at 16:36
1
By using a non-standard port, you additionally attract probes that are not necessarily meant for an SSH server, so all sorts of funky HTTP-type requests are obviously coming in.
– Kusalananda
Feb 11 at 16:43
1
and I wouldn't put it past people to scan all 65,535 ports and look for things that answer, and then to match those answering strings with typical protocols.
– Jeff Schaller
Feb 11 at 16:44
1
note also the very regular timing between the logs in the first example: 348 seconds, 348 seconds, 343 seconds. A human wouldn't wait so long, nor be so regular.
– Jeff Schaller
Feb 11 at 17:07
1
@Jeff well spotted; and that corresponds to a scan rate of 200 attempts per second, if the source is attempting connections on all ports (assuming 9000 is the only open port and is therefore the only port which adds significant delay to the scan).
– Stephen Kitt
Feb 11 at 17:22
One of these questions (concerning port numbers) has been answered here. I found the answer after I posted the question.
– malan
Feb 11 at 16:36
One of these questions (concerning port numbers) has been answered here. I found the answer after I posted the question.
– malan
Feb 11 at 16:36
1
1
By using a non-standard port, you additionally attract probes that are not necessarily meant for an SSH server, so all sorts of funky HTTP-type requests are obviously coming in.
– Kusalananda
Feb 11 at 16:43
By using a non-standard port, you additionally attract probes that are not necessarily meant for an SSH server, so all sorts of funky HTTP-type requests are obviously coming in.
– Kusalananda
Feb 11 at 16:43
1
1
and I wouldn't put it past people to scan all 65,535 ports and look for things that answer, and then to match those answering strings with typical protocols.
– Jeff Schaller
Feb 11 at 16:44
and I wouldn't put it past people to scan all 65,535 ports and look for things that answer, and then to match those answering strings with typical protocols.
– Jeff Schaller
Feb 11 at 16:44
1
1
note also the very regular timing between the logs in the first example: 348 seconds, 348 seconds, 343 seconds. A human wouldn't wait so long, nor be so regular.
– Jeff Schaller
Feb 11 at 17:07
note also the very regular timing between the logs in the first example: 348 seconds, 348 seconds, 343 seconds. A human wouldn't wait so long, nor be so regular.
– Jeff Schaller
Feb 11 at 17:07
1
1
@Jeff well spotted; and that corresponds to a scan rate of 200 attempts per second, if the source is attempting connections on all ports (assuming 9000 is the only open port and is therefore the only port which adds significant delay to the scan).
– Stephen Kitt
Feb 11 at 17:22
@Jeff well spotted; and that corresponds to a scan rate of 200 attempts per second, if the source is attempting connections on all ports (assuming 9000 is the only open port and is therefore the only port which adds significant delay to the scan).
– Stephen Kitt
Feb 11 at 17:22
|
show 3 more comments
3 Answers
3
active
oldest
votes
There is no good port to use, only good SSH configurations. If you disable password-based logins and only allow key-based authentication, you won’t risk much from such brute-forcing attempts. You could add port-knocking, but that’s security by obscurity.
The port numbers listed on the right of the logs are the source ports; these are dynamically allocated and are on the source system, not the target system.
[preauth]
means that the logged event happened before the connection was authenticated — i.e. in this case that the connection is closed before being authenticated.All the logs from your second set of logs correspond to non-SSH traffic sent to your dæmon. You’ll see this happen quite a lot, especially since you’re listening on a non-standard port — various scanners will send requests without knowing what is listening on the other end.
Scanning large portions of the Internet, on a variety of ports, doesn’t take very long if you have well-connected systems to scan from, or a large number of compromised hosts in a botnet. See massscan
for an example of a mass-scanning tool. There are also lists of known-open IP addresses and ports which are circulated; so all it takes is for one scan to find your open port 9000.
I have been learning how to use ssh keys very recently. I only learned how to use gpg keys a month or two ago in the process of trying to set up pass. Thank you for the suggestion. (I ordered a yubikey this weekend, so I'll have another reason to play around with these sorts of things now).
– malan
Feb 11 at 17:17
As far as point 1 goes, it can be useful to layer obscurity over other forms of security in the same way that it can be useful to camouflage a tank.
– Gerald Combs
Feb 11 at 21:36
@Gerald granted, as long (IMO) as it doesn’t lull people into a false sense of security — as has happened with tanks ;-). Something likefwknop
can be useful. I tend to favour other approaches which don’t involve too much setup on the client...
– Stephen Kitt
Feb 11 at 21:50
add a comment |
Short of a comprehensive guide to sshd logs, but addressing your points:
Did I just choose a port that's too easy to guess? What would be a better port number?
There's "only" 65,535 ports, and scanners are good at finding them, so once you've moved beyond port 22 to avoid the simplest scans, there's not a whole lot of benefit to picking one arbitrary port over another.
What do the port numbers in these sshd logs even mean? How can they have access to port (43944) if my router is only configured to forward port 9000 to port 22? I
The port numbers after the IP's, such as 209.17.97.34 port 43944
indicate the source-side's port that was likely arbitrarily chosen by the kernel on that side. It means next to nothing to you.
What does [preauth] mean?
It's short for "pre (before) authentication"; ssh performs in stages, and this is one. There are other, similar questions here at U&L.
What does Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248 mean?
A quick Google search turned up this
strange query in server logs REMOTE HI_SRDK_DEV_GetHddInfo
in Stack Overflow -- reinforcing the idea that this is a scanner looking for "opportunities".
add a comment |
Well your bad protocol stuff is scanning for Kguard Digital Video Recorders vulnerable to CVE-2015-4464. They just happen to default to port 9000..
https://dl.packetstormsecurity.net/1506-exploits/kdvr-authorization.txt
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499982%2funderstanding-sshd-logs%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
There is no good port to use, only good SSH configurations. If you disable password-based logins and only allow key-based authentication, you won’t risk much from such brute-forcing attempts. You could add port-knocking, but that’s security by obscurity.
The port numbers listed on the right of the logs are the source ports; these are dynamically allocated and are on the source system, not the target system.
[preauth]
means that the logged event happened before the connection was authenticated — i.e. in this case that the connection is closed before being authenticated.All the logs from your second set of logs correspond to non-SSH traffic sent to your dæmon. You’ll see this happen quite a lot, especially since you’re listening on a non-standard port — various scanners will send requests without knowing what is listening on the other end.
Scanning large portions of the Internet, on a variety of ports, doesn’t take very long if you have well-connected systems to scan from, or a large number of compromised hosts in a botnet. See massscan
for an example of a mass-scanning tool. There are also lists of known-open IP addresses and ports which are circulated; so all it takes is for one scan to find your open port 9000.
I have been learning how to use ssh keys very recently. I only learned how to use gpg keys a month or two ago in the process of trying to set up pass. Thank you for the suggestion. (I ordered a yubikey this weekend, so I'll have another reason to play around with these sorts of things now).
– malan
Feb 11 at 17:17
As far as point 1 goes, it can be useful to layer obscurity over other forms of security in the same way that it can be useful to camouflage a tank.
– Gerald Combs
Feb 11 at 21:36
@Gerald granted, as long (IMO) as it doesn’t lull people into a false sense of security — as has happened with tanks ;-). Something likefwknop
can be useful. I tend to favour other approaches which don’t involve too much setup on the client...
– Stephen Kitt
Feb 11 at 21:50
add a comment |
There is no good port to use, only good SSH configurations. If you disable password-based logins and only allow key-based authentication, you won’t risk much from such brute-forcing attempts. You could add port-knocking, but that’s security by obscurity.
The port numbers listed on the right of the logs are the source ports; these are dynamically allocated and are on the source system, not the target system.
[preauth]
means that the logged event happened before the connection was authenticated — i.e. in this case that the connection is closed before being authenticated.All the logs from your second set of logs correspond to non-SSH traffic sent to your dæmon. You’ll see this happen quite a lot, especially since you’re listening on a non-standard port — various scanners will send requests without knowing what is listening on the other end.
Scanning large portions of the Internet, on a variety of ports, doesn’t take very long if you have well-connected systems to scan from, or a large number of compromised hosts in a botnet. See massscan
for an example of a mass-scanning tool. There are also lists of known-open IP addresses and ports which are circulated; so all it takes is for one scan to find your open port 9000.
I have been learning how to use ssh keys very recently. I only learned how to use gpg keys a month or two ago in the process of trying to set up pass. Thank you for the suggestion. (I ordered a yubikey this weekend, so I'll have another reason to play around with these sorts of things now).
– malan
Feb 11 at 17:17
As far as point 1 goes, it can be useful to layer obscurity over other forms of security in the same way that it can be useful to camouflage a tank.
– Gerald Combs
Feb 11 at 21:36
@Gerald granted, as long (IMO) as it doesn’t lull people into a false sense of security — as has happened with tanks ;-). Something likefwknop
can be useful. I tend to favour other approaches which don’t involve too much setup on the client...
– Stephen Kitt
Feb 11 at 21:50
add a comment |
There is no good port to use, only good SSH configurations. If you disable password-based logins and only allow key-based authentication, you won’t risk much from such brute-forcing attempts. You could add port-knocking, but that’s security by obscurity.
The port numbers listed on the right of the logs are the source ports; these are dynamically allocated and are on the source system, not the target system.
[preauth]
means that the logged event happened before the connection was authenticated — i.e. in this case that the connection is closed before being authenticated.All the logs from your second set of logs correspond to non-SSH traffic sent to your dæmon. You’ll see this happen quite a lot, especially since you’re listening on a non-standard port — various scanners will send requests without knowing what is listening on the other end.
Scanning large portions of the Internet, on a variety of ports, doesn’t take very long if you have well-connected systems to scan from, or a large number of compromised hosts in a botnet. See massscan
for an example of a mass-scanning tool. There are also lists of known-open IP addresses and ports which are circulated; so all it takes is for one scan to find your open port 9000.
There is no good port to use, only good SSH configurations. If you disable password-based logins and only allow key-based authentication, you won’t risk much from such brute-forcing attempts. You could add port-knocking, but that’s security by obscurity.
The port numbers listed on the right of the logs are the source ports; these are dynamically allocated and are on the source system, not the target system.
[preauth]
means that the logged event happened before the connection was authenticated — i.e. in this case that the connection is closed before being authenticated.All the logs from your second set of logs correspond to non-SSH traffic sent to your dæmon. You’ll see this happen quite a lot, especially since you’re listening on a non-standard port — various scanners will send requests without knowing what is listening on the other end.
Scanning large portions of the Internet, on a variety of ports, doesn’t take very long if you have well-connected systems to scan from, or a large number of compromised hosts in a botnet. See massscan
for an example of a mass-scanning tool. There are also lists of known-open IP addresses and ports which are circulated; so all it takes is for one scan to find your open port 9000.
answered Feb 11 at 17:00
Stephen KittStephen Kitt
174k24399476
174k24399476
I have been learning how to use ssh keys very recently. I only learned how to use gpg keys a month or two ago in the process of trying to set up pass. Thank you for the suggestion. (I ordered a yubikey this weekend, so I'll have another reason to play around with these sorts of things now).
– malan
Feb 11 at 17:17
As far as point 1 goes, it can be useful to layer obscurity over other forms of security in the same way that it can be useful to camouflage a tank.
– Gerald Combs
Feb 11 at 21:36
@Gerald granted, as long (IMO) as it doesn’t lull people into a false sense of security — as has happened with tanks ;-). Something likefwknop
can be useful. I tend to favour other approaches which don’t involve too much setup on the client...
– Stephen Kitt
Feb 11 at 21:50
add a comment |
I have been learning how to use ssh keys very recently. I only learned how to use gpg keys a month or two ago in the process of trying to set up pass. Thank you for the suggestion. (I ordered a yubikey this weekend, so I'll have another reason to play around with these sorts of things now).
– malan
Feb 11 at 17:17
As far as point 1 goes, it can be useful to layer obscurity over other forms of security in the same way that it can be useful to camouflage a tank.
– Gerald Combs
Feb 11 at 21:36
@Gerald granted, as long (IMO) as it doesn’t lull people into a false sense of security — as has happened with tanks ;-). Something likefwknop
can be useful. I tend to favour other approaches which don’t involve too much setup on the client...
– Stephen Kitt
Feb 11 at 21:50
I have been learning how to use ssh keys very recently. I only learned how to use gpg keys a month or two ago in the process of trying to set up pass. Thank you for the suggestion. (I ordered a yubikey this weekend, so I'll have another reason to play around with these sorts of things now).
– malan
Feb 11 at 17:17
I have been learning how to use ssh keys very recently. I only learned how to use gpg keys a month or two ago in the process of trying to set up pass. Thank you for the suggestion. (I ordered a yubikey this weekend, so I'll have another reason to play around with these sorts of things now).
– malan
Feb 11 at 17:17
As far as point 1 goes, it can be useful to layer obscurity over other forms of security in the same way that it can be useful to camouflage a tank.
– Gerald Combs
Feb 11 at 21:36
As far as point 1 goes, it can be useful to layer obscurity over other forms of security in the same way that it can be useful to camouflage a tank.
– Gerald Combs
Feb 11 at 21:36
@Gerald granted, as long (IMO) as it doesn’t lull people into a false sense of security — as has happened with tanks ;-). Something like
fwknop
can be useful. I tend to favour other approaches which don’t involve too much setup on the client...– Stephen Kitt
Feb 11 at 21:50
@Gerald granted, as long (IMO) as it doesn’t lull people into a false sense of security — as has happened with tanks ;-). Something like
fwknop
can be useful. I tend to favour other approaches which don’t involve too much setup on the client...– Stephen Kitt
Feb 11 at 21:50
add a comment |
Short of a comprehensive guide to sshd logs, but addressing your points:
Did I just choose a port that's too easy to guess? What would be a better port number?
There's "only" 65,535 ports, and scanners are good at finding them, so once you've moved beyond port 22 to avoid the simplest scans, there's not a whole lot of benefit to picking one arbitrary port over another.
What do the port numbers in these sshd logs even mean? How can they have access to port (43944) if my router is only configured to forward port 9000 to port 22? I
The port numbers after the IP's, such as 209.17.97.34 port 43944
indicate the source-side's port that was likely arbitrarily chosen by the kernel on that side. It means next to nothing to you.
What does [preauth] mean?
It's short for "pre (before) authentication"; ssh performs in stages, and this is one. There are other, similar questions here at U&L.
What does Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248 mean?
A quick Google search turned up this
strange query in server logs REMOTE HI_SRDK_DEV_GetHddInfo
in Stack Overflow -- reinforcing the idea that this is a scanner looking for "opportunities".
add a comment |
Short of a comprehensive guide to sshd logs, but addressing your points:
Did I just choose a port that's too easy to guess? What would be a better port number?
There's "only" 65,535 ports, and scanners are good at finding them, so once you've moved beyond port 22 to avoid the simplest scans, there's not a whole lot of benefit to picking one arbitrary port over another.
What do the port numbers in these sshd logs even mean? How can they have access to port (43944) if my router is only configured to forward port 9000 to port 22? I
The port numbers after the IP's, such as 209.17.97.34 port 43944
indicate the source-side's port that was likely arbitrarily chosen by the kernel on that side. It means next to nothing to you.
What does [preauth] mean?
It's short for "pre (before) authentication"; ssh performs in stages, and this is one. There are other, similar questions here at U&L.
What does Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248 mean?
A quick Google search turned up this
strange query in server logs REMOTE HI_SRDK_DEV_GetHddInfo
in Stack Overflow -- reinforcing the idea that this is a scanner looking for "opportunities".
add a comment |
Short of a comprehensive guide to sshd logs, but addressing your points:
Did I just choose a port that's too easy to guess? What would be a better port number?
There's "only" 65,535 ports, and scanners are good at finding them, so once you've moved beyond port 22 to avoid the simplest scans, there's not a whole lot of benefit to picking one arbitrary port over another.
What do the port numbers in these sshd logs even mean? How can they have access to port (43944) if my router is only configured to forward port 9000 to port 22? I
The port numbers after the IP's, such as 209.17.97.34 port 43944
indicate the source-side's port that was likely arbitrarily chosen by the kernel on that side. It means next to nothing to you.
What does [preauth] mean?
It's short for "pre (before) authentication"; ssh performs in stages, and this is one. There are other, similar questions here at U&L.
What does Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248 mean?
A quick Google search turned up this
strange query in server logs REMOTE HI_SRDK_DEV_GetHddInfo
in Stack Overflow -- reinforcing the idea that this is a scanner looking for "opportunities".
Short of a comprehensive guide to sshd logs, but addressing your points:
Did I just choose a port that's too easy to guess? What would be a better port number?
There's "only" 65,535 ports, and scanners are good at finding them, so once you've moved beyond port 22 to avoid the simplest scans, there's not a whole lot of benefit to picking one arbitrary port over another.
What do the port numbers in these sshd logs even mean? How can they have access to port (43944) if my router is only configured to forward port 9000 to port 22? I
The port numbers after the IP's, such as 209.17.97.34 port 43944
indicate the source-side's port that was likely arbitrarily chosen by the kernel on that side. It means next to nothing to you.
What does [preauth] mean?
It's short for "pre (before) authentication"; ssh performs in stages, and this is one. There are other, similar questions here at U&L.
What does Bad protocol version identification 'REMOTE HI_SRDK_DEV_GetHddInfo MCTP/1.0' from 162.207.145.58 port 48248 mean?
A quick Google search turned up this
strange query in server logs REMOTE HI_SRDK_DEV_GetHddInfo
in Stack Overflow -- reinforcing the idea that this is a scanner looking for "opportunities".
answered Feb 11 at 17:06
Jeff SchallerJeff Schaller
42.9k1159137
42.9k1159137
add a comment |
add a comment |
Well your bad protocol stuff is scanning for Kguard Digital Video Recorders vulnerable to CVE-2015-4464. They just happen to default to port 9000..
https://dl.packetstormsecurity.net/1506-exploits/kdvr-authorization.txt
add a comment |
Well your bad protocol stuff is scanning for Kguard Digital Video Recorders vulnerable to CVE-2015-4464. They just happen to default to port 9000..
https://dl.packetstormsecurity.net/1506-exploits/kdvr-authorization.txt
add a comment |
Well your bad protocol stuff is scanning for Kguard Digital Video Recorders vulnerable to CVE-2015-4464. They just happen to default to port 9000..
https://dl.packetstormsecurity.net/1506-exploits/kdvr-authorization.txt
Well your bad protocol stuff is scanning for Kguard Digital Video Recorders vulnerable to CVE-2015-4464. They just happen to default to port 9000..
https://dl.packetstormsecurity.net/1506-exploits/kdvr-authorization.txt
answered Feb 11 at 23:09
RichUKRichUK
211
211
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499982%2funderstanding-sshd-logs%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
One of these questions (concerning port numbers) has been answered here. I found the answer after I posted the question.
– malan
Feb 11 at 16:36
1
By using a non-standard port, you additionally attract probes that are not necessarily meant for an SSH server, so all sorts of funky HTTP-type requests are obviously coming in.
– Kusalananda
Feb 11 at 16:43
1
and I wouldn't put it past people to scan all 65,535 ports and look for things that answer, and then to match those answering strings with typical protocols.
– Jeff Schaller
Feb 11 at 16:44
1
note also the very regular timing between the logs in the first example: 348 seconds, 348 seconds, 343 seconds. A human wouldn't wait so long, nor be so regular.
– Jeff Schaller
Feb 11 at 17:07
1
@Jeff well spotted; and that corresponds to a scan rate of 200 attempts per second, if the source is attempting connections on all ports (assuming 9000 is the only open port and is therefore the only port which adds significant delay to the scan).
– Stephen Kitt
Feb 11 at 17:22