Por que os wrappers TCP parariam de funcionar para o sshd?

Question

Em alguns servidores do CentOS 5, o sshd parece ter se tornado “desembrulhado” - antes eu estava usando TCP wrappers e hosts.allow / hosts.deny para controlar o acesso, mas agora eles não estão sendo usados. Se eu executar

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

não produz nada, enquanto nos servidores em que os TCP wrappers ainda estão funcionando, vejo

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

Alguém sabe o que pode causar isso ou como ele pode ser corrigido?

Atualizado Conforme solicitado:

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

A saída de ldd / usr / sbin / sshd é:

    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.

    

Answer 1

No momento, há evidências de que seu sshd foi recompilado. A soma de verificação MD5 e o tamanho do arquivo estão errados, de acordo com a saída rpm -qV .

sshd parece ser menos útil do que, digamos, openssh em dizer qual versão está sendo executada e quando foi compilada, mas a saída de rpm -qa|grep openssh-server e as dez principais linhas de /usr/sbin/sshd -p 22222 -d -d (você pode Se você substituir qualquer porta não usada por 22222, o comando exigirá privilégio, e você poderá eliminá-lo com ^C depois de iniciado - é apenas o número da versão que queremos) seria mais útil aqui.

Editar : parece ainda mais que o seu sshd não é a versão da distro. Acabei de fazer o mesmo teste ( sshd -p 22222 -d -d em uma caixa C5.10 com o estoque sshd e recebo uma linha que diz

debug1: sshd version OpenSSH_4.3p2

enquanto você tiver

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

No momento, não vejo motivo para pensar que você está executando o estoque sshd , o que explicaria por que ele não está honrando os wrappers TCP. Entre outras coisas, isso pode colocá-lo em risco de qualquer número de ataques que sejam bons contra a versão sshd que teria sido corrigida na versão da distribuição. Você pode obter uma resposta definitiva removendo e reinstalando o openssh-server RPM e verificando se a compatibilidade dos TCP wrappers foi restaurada. Você provavelmente precisará estar no console para fazer isso com segurança.

    

Answer 2

De acordo com a saída rpm -qV, seu binário sshd foi modificado, mas o registro de data e hora da modificação foi retornado ao seu valor original.

Normalmente, quando isso acontece, é porque seu computador foi invadido e o atacante tem acesso root. Isso explicaria o funcionamento anormal do seu binário sshd também.

Note que seu servidor ssh quase certamente está enviando suas senhas para o hacker quando você efetua login, então considere todas as senhas agora comprometidas.

    

Answer 3

Ele é compilado com cabeçalhos apropriados (configure --with-libwrap [= path]) - então ele é usado.

Se bem me lembro, é um comportamento intencional, como o link .