sunhux
asked on
Can't ssh into RHEL after hardening: still pingable
While hardening, I got logged out & can't ssh into the RHEL7 VM anymore:
I'm not sure at which step of CIS hardening this took place but it appears
that when I delete a user account by issuing: userdel johndo
I gain access from vCenter console & reversed back the "sshd_config"
file & did "pkill -HUP sshd" but no joy.
From another RHEL VM in the same subnet (ie no firewalls in between)
& no iptable rules have been set up yet, I attempted verbose ssh:
[root@mesobootsp01.jp.com.
$ ssh -vvv root@10.121.0.51
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug2: resolving "10.121.0.51" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.121.0.51 [10.121.0.51] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
I'll attach a log of the changes done shortly
I'm not sure at which step of CIS hardening this took place but it appears
that when I delete a user account by issuing: userdel johndo
I gain access from vCenter console & reversed back the "sshd_config"
file & did "pkill -HUP sshd" but no joy.
From another RHEL VM in the same subnet (ie no firewalls in between)
& no iptable rules have been set up yet, I attempted verbose ssh:
[root@mesobootsp01.jp.com.
$ ssh -vvv root@10.121.0.51
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug2: resolving "10.121.0.51" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.121.0.51 [10.121.0.51] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
I'll attach a log of the changes done shortly
ASKER
Noci, note that ssh into that RHEL 7 VM does not even prompt
for the login id. I've tried using any other non-root id.
I've not restricted root login to CONSOLE yet
for the login id. I've tried using any other non-root id.
I've not restricted root login to CONSOLE yet
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
From the same PC, I used 'portqry' & telnet to that
RHEL VM on Tcp22 : it's still responding/listening
on tcp22.
Attached is the change log:
use the password below to open:
On1y_chg (first letter is capital Oh)
I've recreated back the deleted account using
back the same uid & gid : still no joy
ChangeLog-12Nov.docx
RHEL VM on Tcp22 : it's still responding/listening
on tcp22.
Attached is the change log:
use the password below to open:
On1y_chg (first letter is capital Oh)
I've recreated back the deleted account using
back the same uid & gid : still no joy
ChangeLog-12Nov.docx
ASKER
Reckon the client ssh command David gave
"ssh -vvv root@10.121.0.51" was supposed to be
"ssh -vvv root@10.121.0.51 -p 55555"
On the 10.121.0.51 end, I started the given sshd that listens on port 55555:
Saw on the RHEL ssh server end:
" inetd sockets after dupping: 3, 3
Connection refused by tcp wrapper"
Hmm, I don't recall I've made any tcp wrapper change (refer to my change log)
"ssh -vvv root@10.121.0.51" was supposed to be
"ssh -vvv root@10.121.0.51 -p 55555"
On the 10.121.0.51 end, I started the given sshd that listens on port 55555:
Saw on the RHEL ssh server end:
" inetd sockets after dupping: 3, 3
Connection refused by tcp wrapper"
Hmm, I don't recall I've made any tcp wrapper change (refer to my change log)
ASKER
Ahh, found the cause:
echo "ALL: ALL" >> /etc/hosts.deny
by removing above line from /etc/hosts.deny, I'm back to normal.
So I guess CIS item "3.4.3 Ensure /etc/hosts.deny is configured "
should only be done after carefully creating entries in hosts.allow
first.
Rationale:
========
The /etc/hosts.deny file serves as a failsafe so that any host not specified in
/etc/hosts.allow is denied access to the system.
echo "ALL: ALL" >> /etc/hosts.deny
by removing above line from /etc/hosts.deny, I'm back to normal.
So I guess CIS item "3.4.3 Ensure /etc/hosts.deny is configured "
should only be done after carefully creating entries in hosts.allow
first.
Rationale:
========
The /etc/hosts.deny file serves as a failsafe so that any host not specified in
/etc/hosts.allow is denied access to the system.
So I guess CIS item "3.4.3 Ensure /etc/hosts.deny is configured "
should only be done after carefully creating entries in hosts.allow
first.
Eh yes...
The main thin in Hardening is FIRST ensure legitimate access is still possible, then block the general/unspecific access.
The /etc/hosts.deny sets a total restriction that can be enabled through addition of rules in /etc/hosts.allow
add into hosts.allow
SSHD:10.121.0.51
add into hosts.allow
SSHD:10.121.0.51
ASKER
Ok, suppose I don't want to implement iptables & these hosts.*,
can I justify that we already have network firewall in place with
network segmentation (DMZ, internal zones), we don't need to
harden by iptables' rules & hosts.* anymore?
Quite a harrowing experience as this fragile system is supposed
to go live in a couple days' time.
can I justify that we already have network firewall in place with
network segmentation (DMZ, internal zones), we don't need to
harden by iptables' rules & hosts.* anymore?
Quite a harrowing experience as this fragile system is supposed
to go live in a couple days' time.
No, the point of hardening systems is to shild the system from a mishap including controlling source from which access can be made whether internally or externally.
Usually, when hardening it would tell you what is involved and what changes it is making.
the use of restriction through tcp_wrappers was the old way pre software firewalls on the system.
once you saw the source, why not simply add the rules in /etc/hosts.allow and go from there?
You've already spent time troubleshooting the issue.
Usually, when hardening it would tell you what is involved and what changes it is making.
the use of restriction through tcp_wrappers was the old way pre software firewalls on the system.
once you saw the source, why not simply add the rules in /etc/hosts.allow and go from there?
You've already spent time troubleshooting the issue.
iptables is a measure on kernel level (when packets enter, leave or pass through the system), and finely grained in options & posibilities.
hosts/allow (aka tcp_wrapper) is something implemented (or not) in server processes, only actine on source IP address.
Originaly there were no network daemons, there was one super daemon (inetd, nowadays xinetd the extended version).
Within that server a program was run, later that program was prefixed with tcp_wrapper command, meaning that the tcp_wrapper program was run by inetd, that would verify if the host address was allowed/denied, if allowed it would run the server program next.
xinetd, and later "persistent" service daemons adopted this tcp_wrapper notion of allowed / disallowed. (this was done in unices from before the firewalls.. 1980's stuff. ) Firewall start somewhere early in the 1990's with tools like the Gauntlet & gatekeeper (https://en.wikipedia.org/wiki/Trusted_Information_Systems) .
Hardening is about make the best security you can do. So tough passwords, no-one can become root by just logging in, processes are separated by distingct group, users. Also specifying what user may operate what system call on what object (selinux). all layers work together, it isn't one thing to rule them all.
hosts/allow (aka tcp_wrapper) is something implemented (or not) in server processes, only actine on source IP address.
Originaly there were no network daemons, there was one super daemon (inetd, nowadays xinetd the extended version).
Within that server a program was run, later that program was prefixed with tcp_wrapper command, meaning that the tcp_wrapper program was run by inetd, that would verify if the host address was allowed/denied, if allowed it would run the server program next.
xinetd, and later "persistent" service daemons adopted this tcp_wrapper notion of allowed / disallowed. (this was done in unices from before the firewalls.. 1980's stuff. ) Firewall start somewhere early in the 1990's with tools like the Gauntlet & gatekeeper (https://en.wikipedia.org/wiki/Trusted_Information_Systems) .
Hardening is about make the best security you can do. So tough passwords, no-one can become root by just logging in, processes are separated by distingct group, users. Also specifying what user may operate what system call on what object (selinux). all layers work together, it isn't one thing to rule them all.
Correct, the ssh should have contained the -p 55555 option also.
So logging on as root won't work. Another thing would have been to enable an account as sudo user. So someone can logon and is then authorized to use sudo to enable stuff again.
Reverting sshd would mean you need to ensure that root is enabled in that file.