ssh access which should have been blocked (better)

Issues related to configuring your network
Post Reply
mathog
Posts: 258
Joined: 2008/07/09 23:52:06

ssh access which should have been blocked (better)

Post by mathog » 2019/08/27 18:19:54

Code: Select all

CentOS Linux release 7.6.1810 (Core)
kernel 3.10.0-957.27.2.el7.x86_64
These RPMs are possibly involved
openssh-clients-7.4p1-16.el7.x86_64
openssh-7.4p1-16.el7.x86_64
libssh2-1.4.3-12.el7_6.3.x86_64
openssh-server-7.4p1-16.el7.x86_64
A bunch of failed login attempts on CentOS 7 machines were seen, these were supposedly fire walled off from the outside world. Here
are 4 attempts. The first one (nothing) was a positive control from my son's W7 machine using putty from home to the default ssh port. It was completely blocked as it should have been. The second one was a second positive control test from him to a "back door" port which I use for fixing things remotely when necessary. Control access for that is by this in sshd.config

Code: Select all

AllowUsers HideRealUserName *@131.215.0.0/16 *@192.168.1.0/24 
That one only allows entry from a single account name, and "Testing" is not it. sshd correctly shut down that request without checking the password. The others were intrusion attempts and at least one was to an account which existed where it seems to have actually checked the password. The destination port number wasn't logged, so I could not say which one was being attacked from that alone.

Code: Select all

(nothing)

Aug 27 10:31:45 aserver sshd[18492]: Invalid user Testing from 64.52.136.198 port 55666
Aug 27 10:31:45 aserver sshd[18492]: input_userauth_request: invalid user Testing [preauth]
Aug 27 10:31:56 aserver sshd[18492]: Connection closed by 64.52.136.198 port 55666 [preauth]

Aug 27 10:06:16 aserver sshd[17376]: Invalid user guest from 170.239.255.14 port 51942
Aug 27 10:06:16 aserver sshd[17376]: input_userauth_request: invalid user guest [preauth]
Aug 27 10:06:16 aserver sshd[17376]: pam_unix(sshd:auth): check pass; user unknown
Aug 27 10:06:16 aserver sshd[17376]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=170.239.255.14

Aug 27 10:36:45 aserver sshd[18558]: User postgres from 170.239.255.14 not allowed because not listed in AllowUsers
Aug 27 10:36:45 aserver sshd[18558]: input_userauth_request: invalid user postgres [preauth]
Aug 27 10:36:45 aserver sshd[18558]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=170.239.255.14  user=postgres
Aug 27 10:36:45 aserver sshd[18558]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "postgres"
Aug 27 10:36:47 aserver sshd[18558]: Failed password for invalid user postgres from 170.239.255.14 port 46672 ssh2
Aug 27 10:36:47 aserver sshd[18558]: Connection closed by 170.239.255.14 port 46672 [preauth]

After a bit of head scratching it finally dawned on me that /etc/sshd.config has this as default:

Code: Select all

#AddressFamily any
And the ipv4 specific iptables settings would be completely bypassed by ipv6 connections. Why those would show up as "170.239.255.14" instead of some ipv6 address I could not say. In any case, changed sshd.config to

Code: Select all

AddressFamily inet
which made it ipv4 only and restarted. Thought that had fixed it, but no, another shot at postgres was just logged a little while ago. Perhaps the intrusion attempts are on the high ssh port and differences in the ssh client account for the different types of log records?
Set LogLevel to DEBUG and that confirmed it.

Code: Select all

Aug 27 11:07:20 aserver sshd[18853]: debug1: Set /proc/self/oom_score_adj to 0
Aug 27 11:07:20 aserver sshd[18853]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Aug 27 11:07:20 aserver sshd[18853]: debug1: inetd sockets after dupping: 3, 3
Aug 27 11:07:20 aserver sshd[18853]: Connection from 170.239.255.14 port 41416 on 131.215.xxx.xxx port 60022
Aug 27 11:07:20 aserver sshd[18853]: debug1: Client protocol version 2.0; client software version libssh2_1.7.0
Aug 27 11:07:20 aserver sshd[18853]: debug1: no match: libssh2_1.7.0
Aug 27 11:07:20 aserver sshd[18853]: debug1: Local version string SSH-2.0-OpenSSH_7.4
Aug 27 11:07:20 aserver sshd[18853]: debug1: Enabling compatibility mode for protocol 2.0
Aug 27 11:07:20 aserver sshd[18853]: debug1: SELinux support enabled [preauth]
Aug 27 11:07:20 aserver sshd[18853]: debug1: permanently_set_uid: 74/74 [preauth]
Aug 27 11:07:20 aserver sshd[18853]: debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
Aug 27 11:07:20 aserver sshd[18853]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Aug 27 11:07:20 aserver sshd[18853]: debug1: SSH2_MSG_KEXINIT received [preauth]
Aug 27 11:07:20 aserver sshd[18853]: debug1: kex: algorithm: diffie-hellman-group-exchange-sha256 [preauth]
Aug 27 11:07:20 aserver sshd[18853]: debug1: kex: host key algorithm: ssh-rsa [preauth]
Aug 27 11:07:20 aserver sshd[18853]: debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none [preauth]
Aug 27 11:07:20 aserver sshd[18853]: debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none [preauth]
Aug 27 11:07:20 aserver sshd[18853]: debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth]
Aug 27 11:07:20 aserver sshd[18853]: debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth]
Aug 27 11:07:20 aserver sshd[18853]: debug1: expecting SSH2_MSG_KEX_DH_GEX_REQUEST [preauth]
Aug 27 11:07:20 aserver sshd[18853]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
Aug 27 11:07:20 aserver sshd[18853]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
Aug 27 11:07:20 aserver sshd[18853]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]
Aug 27 11:07:21 aserver sshd[18853]: debug1: rekey after 4294967296 blocks [preauth]
Aug 27 11:07:21 aserver sshd[18853]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
Aug 27 11:07:21 aserver sshd[18853]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Aug 27 11:07:21 aserver sshd[18853]: debug1: SSH2_MSG_NEWKEYS received [preauth]
Aug 27 11:07:21 aserver sshd[18853]: debug1: rekey after 4294967296 blocks [preauth]
Aug 27 11:07:21 aserver sshd[18853]: debug1: KEX done [preauth]
Aug 27 11:07:21 aserver sshd[18853]: debug1: userauth-request for user user service ssh-connection method password [preauth]
Aug 27 11:07:21 aserver sshd[18853]: debug1: attempt 0 failures 0 [preauth]
Aug 27 11:07:21 aserver sshd[18853]: Invalid user user from 170.239.255.14 port 41416
Aug 27 11:07:21 aserver sshd[18853]: input_userauth_request: invalid user user [preauth]
Aug 27 11:07:21 aserver sshd[18853]: debug1: PAM: initializing for "user"
Aug 27 11:07:21 aserver sshd[18853]: debug1: PAM: setting PAM_RHOST to "170.239.255.14"
Aug 27 11:07:21 aserver sshd[18853]: debug1: PAM: setting PAM_TTY to "ssh"
Aug 27 11:07:21 aserver sshd[18853]: pam_unix(sshd:auth): check pass; user unknown
Aug 27 11:07:21 aserver sshd[18853]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=170.239.255.14
Aug 27 11:07:23 aserver sshd[18853]: debug1: PAM: password authentication failed for an illegal user: User not known to the underlying authentication module
Aug 27 11:07:23 aserver sshd[18853]: Failed password for invalid user user from 170.239.255.14 port 41416 ssh2
Aug 27 11:07:24 aserver sshd[18853]: Connection closed by 170.239.255.14 port 41416 [preauth]
Aug 27 11:07:24 aserver sshd[18853]: debug1: do_cleanup [preauth]
Aug 27 11:07:24 aserver sshd[18853]: debug1: monitor_read_log: child log fd closed
Aug 27 11:07:24 aserver sshd[18853]: debug1: do_cleanup
Aug 27 11:07:24 aserver sshd[18853]: debug1: PAM: cleanup
Aug 27 11:07:24 aserver sshd[18853]: debug1: Killing privsep child 18854
I'm not concerned about an intrusion guessing the random string for the one valid account name. However, I don't see why it is checking passwords when the account name didn't match in these attempts. It did not in the putty attempt. And that worries me.

Suggestions?

Thanks.

mathog
Posts: 258
Joined: 2008/07/09 23:52:06

Re: ssh access which should have been blocked (better)

Post by mathog » 2019/08/27 18:23:11

Other info:

Code: Select all

cat /etc/pam.d/sshd
#%PAM-1.0
auth       required     pam_sepermit.so
auth       substack     password-auth
auth       include      postlogin
# Used with polkit to reauthorize users in remote sessions
-auth      optional     pam_reauthorize.so prepare
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    required     pam_namespace.so
session    optional     pam_keyinit.so force revoke
session    include      password-auth
session    include      postlogin
# Used with polkit to reauthorize users in remote sessions
-session   optional     pam_reauthorize.so prepare

mathog
Posts: 258
Joined: 2008/07/09 23:52:06

Re: ssh access which should have been blocked (better)

Post by mathog » 2019/08/27 18:31:26

In the meantime, this rule was added to the firewall:

Code: Select all

DROP       all  --  170.239.255.14       anywhere            

Post Reply