2

On a couple of CentOS 5 servers sshd seems to have become 'unwrapped' - previously I was using TCP wrappers and hosts.allow/hosts.deny to control access, but these are now not being used. If I execute

$ldd /usr/sbin/sshd | grep libwrap 
$

it outputs nothing, whereas on servers where TCP wrappers are still working I see

libwrap.so.0 => /lib64/libwrap.so.0 (0x00002b2fbcb81000)

Does anyone know what might cause this, or how it could be rectified?

Updated As requested:

$ rpm -qV openssh-server
S.5....T  c /etc/pam.d/sshd
S.?....T  c /etc/ssh/sshd_config
S.5.....    /usr/sbin/sshd

Output of ldd /usr/sbin/sshd is:

    libpam.so.0 => /lib64/libpam.so.0 (0x00002af906b89000)
    libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002af906d94000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00002af9070e5000)
    libutil.so.1 => /lib64/libutil.so.1 (0x00002af9072ea000)
    libz.so.1 => /lib64/libz.so.1 (0x00002af9074ed000)
    libnsl.so.1 => /lib64/libnsl.so.1 (0x00002af907701000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002af90791a000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00002af907b52000)
    libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002af907d67000)
    libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002af907f96000)
    libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002af90822b000)
    libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002af908450000)
    libc.so.6 => /lib64/libc.so.6 (0x00002af908653000)
    libaudit.so.0 => /lib64/libaudit.so.0 (0x00002af9089ac000)
    /lib64/ld-linux-x86-64.so.2 (0x00002af90696b000)
    libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002af908bc4000)
    libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002af908dcd000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00002af908fcf000)
    libsepol.so.1 => /lib64/libsepol.so.1 (0x00002af9091e8000)

$ rpm -qa|grep openssh-server

openssh-server-4.3p2-82.el5

$ sudo /usr/sbin/sshd -p 22222 -d -d

debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 655
debug2: parse_server_config: config /etc/ssh/sshd_config len 655
debug1: sshd version OpenSSH_4.3, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]='22222'
debug1: rexec_argv[3]='-d'
debug1: rexec_argv[4]='-d'
Set /proc/self/oom_adj from 0 to -17
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 22222 on ::.
Server listening on :: port 22222.
4
  • At first glance, that does seem odd; I hope I've correctly fixed your formatting above. Could you add into your question the entire output of ldd /usr/sbin/sshd, just in case it's a privilege issue, and possibly the output of rpm -qV openssh-server as well?
    – MadHatter
    May 27, 2014 at 8:51
  • Sure thing, now done May 27, 2014 at 9:05
  • Not so - could we get the entire output of ldd /usr/sbin/sshd, as I'd asked? In any case, it looks as if someone's modified the sshd binary - the filesize and MD5 checksum are wrong.
    – MadHatter
    May 27, 2014 at 9:07
  • apologies, adding now May 27, 2014 at 10:07

3 Answers 3

2

At the moment, there's evidence that your sshd has been recompiled. The MD5 checksum and the file size are wrong, according to the rpm -qV output.

sshd seems to be less helpful than, say, openssh in telling you what version it's running and when it was compiled, but the output of rpm -qa|grep openssh-server and the top ten or so lines from /usr/sbin/sshd -p 22222 -d -d (you can substitute any unused port for 22222, the command will require privilege, and you can kill it with ^C once it's started - it's just the version number we want) would be most helpful here.

Edit: it looks even more like your sshd is not the distro version. I've just done the same test (sshd -p 22222 -d -d on a C5.10 box with the stock sshd, and I get a line that says

debug1: sshd version OpenSSH_4.3p2

while you have

debug1: sshd version OpenSSH_4.3, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

At the moment, I can see no reason to think that you're running the stock sshd, which would explain why it's not honouring TCP wrappers. Amongst other things, that may put you at risk of any number of attacks that are good against that sshd version which would have been patched in the distro version. You could get a definitive answer by removing and reinstalling the openssh-server RPM, and checking that TCP wrappers compatibility had been restored. You will probably need to be on the console to do that safely.

1
  • I think you're right - I don't know how it's happened, I've asked the hosting company who seem to have confirmed that the binary had been replaced. Thanks for your help! May 27, 2014 at 13:28
2

According to the rpm -qV output, your sshd binary had been modified, but the modification timestamp was set back to it's original value.

Typically when this happens it's because your computer has been hacked and the attacker has root access. This would explain abnormal functioning of your sshd binary as well.

Note that your ssh server is almost certainly sending your passwords to the hacker as you log in, so consider all passwords now compromised.

3
  • Yes, this is something that is concerning me, although the hosting company (who have replaced the binaries now) reckon they can't see evidence of compromise. I'm trying to find any other evidence of malicious activity, I'm not sure what I'm looking for though May 30, 2014 at 8:10
  • ...root ssh access has never been permitted (PermitRootLogin no in sshd_config) and prior to the problem with the binaries any ssh access was limited to a handful of IPs, using TCP wrappers)? May 30, 2014 at 8:24
  • I once took over the administration of a CentOS server that had no security measures applied to it, no iptables rules, etc. (it was also my first encounter with how Plesk messed up the OS). Anyhow, finding out that sshd didn't have TCP wrappers support was the first clue that the system had been rooted. Sep 9, 2016 at 15:45
-1

It is compiled with proper headers (configure --with-libwrap[=path]) - so it use it.

As I remember it is intentional behavior - like described http://www.akadia.com/services/ssh_tcp_wrapper.html.

1
  • Sorry? Firstly, how do you know it's compiled with that flag? Secondly, as I read it the page you link to specifically recommends doing the ldd test the OP is doing to establish whether or not the sshd binary supports TCP wrappers.
    – MadHatter
    May 27, 2014 at 9:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .