porque o nome de usuário não possui um UID?

Question

Meu servidor está comprometido, e tento obter os arquivos abertos do usuário mal-intencionado, ele diz que o usuário não tem um UID, por isso não consegue encontrar nada. Eu vejo que existem processos que estão sendo executados por esse usuário, mas não consigo obter os arquivos abertos por ele.

    

Answer 1

it says that the user does not have a UID

Eu certamente posso concordar com isso. Um usuário como definido por "usuário malicioso executando coisas em um servidor" não tem um UID, mas isso é porque esse usuário é uma pessoa que pode (talvez) executar coisas como UIDs diferentes em sua máquina (a partir de agora eu vou ficar para o termo "atacante").

Portanto, o caminho correto é tentar descobrir qual caminho o invasor tomou para controlar um processo em sua máquina que poderia executar fork() e exec() . Esse é um bom ponto de partida porque, no final do dia, um ataque bem-sucedido começa por ganhar controle (possivelmente de uma maneira muito complicada) de um processo que pode fazer isso. Como o invasor consegue chegar a esse ponto é o que varia no ataque.

Dito isto, a resposta do sobre o que fazer com um servidor comprometido é eliminá-lo da órbita . Não é mais seu computador, e você não pode ter certeza de quanto acesso o invasor conseguiu. O invasor conseguiu privilégios de root, assim como você pode se conectar a uma VM em execução no que já foi seu servidor. Ou você pode até estar lidando com um rootkit.

(Nota: "nuke de órbita" significa uma "nova instalação" pela maioria das pessoas)

Voltar para a pergunta real:

why the username does not have a UID?

Ou melhor, o implícito pelo texto da pergunta:

(how a process is running without an UID?)

A ideia de que um processo está sendo executado sem um UID é um absurdo. A estrutura do kernel que mantém a existência de um processo (na verdade, o KSE) contém um campo UID que deve ser preenchido (mesmo se for preenchido com lixo no caso de, digamos, um bug do kernel). Portanto, todo processo sempre tem um UID.

O mais provável é que o UID não esteja listado em /etc/passwd , o que, apesar de estranho para um processo, não é diferente de fazer touch leet; chown 1337 leet (supondo que você não tenha um usuário leet com esse UID, isso é). Praticamente todas as ferramentas * nix padrão funcionam em UIDs como em nomes de usuários. ou seja,

lsof -u username

é equivalente a

lsof -u 'id -u username'

e

find . -user username

também é equivalente a

find . -user 'id -u username'

Portanto, de volta para a primeira citação (ênfase minha):

it says that the user does not have a UID

Qualquer que seja o it , não é uma ferramenta padrão * nix. Ou você está realmente mais ferrado do que acredita, e está rodando dentro de um ambiente estranho criado pelo atacante.

    

Answer 2

Para encontrar arquivos sem dono no seu sistema, você pode executar find / -nouser

Você também pode executar find /sbin -mtime 1 para encontrar quaisquer arquivos que foram modificados em um dia no diretório / sbin.

    

Answer 3

Simplesmente, o usuário e o binário podem ter sido excluídos do sistema ou o root poderia ter iniciado um processo e alterado o uid; esteja preparado para que você não encontre os binários também.

Neste momento, eu não iria inicializar com o sistema comprometido, e iria iniciar com uma distribuição ao vivo para analisar o sistema de arquivos. Como o grochmal diz, o tou poderia ter ferramentas / binários comprometidos instalados se houvesse um comprometimento de raiz. O fato de você ter um binário do qual você não conhece o usuário aponta strongmente para isso.

Dito isso, vi alguns comprometimentos de sistema, com escalonamento de raiz e um simples comprometimento de senha de usuário, se fosse uma tendência comum deixar binários em execução e excluí-los para complicar as operações forenses.

    

Answer 4

Se você tem processos em execução e conhece seu PID, é possível localizar quais descritores de arquivos estão abertos com "ls -l / proc / PID / fd", onde o PID é o processo do processo de dis.

O problema é que o processo pode abrir um arquivo, lê-lo ou escrevê-lo e depois fechar o fd. Nesse caso, nada lhe dirá, mas a ideia do @damansk de usar o find ajudará.

Você também pode rastrear o processo e ver quais chamadas do open () ele faz.