De vez em quando, recebo uma solicitação estranha para fornecer suporte remoto, solução de problemas e/ou ajuste de desempenho em sistemas Linux.
Muitas vezes, empresas maiores já possuem procedimentos bem estabelecidos para fornecer acesso remoto a vendedores/fornecedores e eu só preciso cumpri-los. (Por bem ou por mal.)
Por outro lado, pequenas empresas e indivíduos invariavelmente recorrem a mim para instruí-los sobre o que precisam fazer para me estabelecer. Normalmente, seus servidores estão conectados diretamente à Internet e as medidas de segurança existentes consistem nos padrões de qualquer distribuição Linux.
Quase sempre vou precisar de acesso de nível raiz e quem irá configurar o acesso para mim não é um administrador de sistema especialista. Não quero a senha de root e também tenho certeza de que minhas ações não serão maliciosas, mas que instruções razoavelmente simples devo dar para:
- configurar uma conta e trocar credenciais com segurança
- configurar acesso root (sudo)
- restringir o acesso à minha conta
- fornecer trilha de auditoria
(E sim, estou ciente e sempre aviso os clientes que, assim que tiver acesso de administrador, ocultar qualquer ação maliciosa é trivial, mas vamos supor que não tenho nada a esconder e participo ativamente da criação de uma trilha de auditoria.)
O que pode ser melhorado nas etapas abaixo?
Meu conjunto de instruções atual:
configurar uma conta e trocar credenciais com segurança
Forneço um hash de senha e peço que minha conta seja configurada com essa senha criptografada, para que não precisemos transmitir uma senha de texto não criptografado, serei o único que sabe a senha e não começaremos com uma senha fraca previsível.
sudo useradd -p '$1$********' hbruijn
Forneço uma chave pública SSH (par de chaves específico por cliente) e peço que configurem minha conta com essa chave:
sudo su - hbruijn
mkdir -p ~/.ssh
chmod 0700 ~/.ssh
echo 'from="10.80.0.0/14,192.168.1.2" ssh-rsa AAAAB3NzaC1y***...***== hbruijn@serverfault' >> ~/.ssh/authorized_keys
chmod 0600 ~/.ssh/authorized_keys
configurar acesso root (sudo)
Peço ao cliente para configurar o sudo para mim com sudo sudoedit
ou usando seu editor favorito e anexar a /etc/sudoers
:
hbruijn ALL=(ALL) ALL
restringir o acesso à minha conta
Normalmente, o cliente ainda permite logins baseados em senha e peço que adicionem as duas linhas a seguir /etc/ssh/sshd_config
para, pelo menos, restringir minha conta apenas a chaves SSH:
Match user hbruijn
PasswordAuthentication no
Dependendo do cliente, rotearei todo o meu acesso SSH por meio de um único bastion host para sempre fornecer um único endereço IP estático (por exemplo, 192.168.1.2) e/ou fornecer o intervalo de endereços IP que meu ISP usa (por exemplo, 10.80.1.2). 0,0/14). O cliente pode precisar adicioná-los a uma lista de permissões de firewall se o acesso SSH for restrito (na maioria das vezes, o ssh não é filtrado).
Você já viu esses endereços IP como a from=
restrição no ~.ssh/authorized_keys
arquivo que limita os hosts dos quais minha chave pode ser usada para acessar seus sistemas.
fornecer trilha de auditoria
Até agora nenhum cliente me pediu isso, e eu não fiz nada específico além do seguinte para cobrir minha bunda:
Eu tento usar consistentemente sudo
com comandos individuais e tento evitar o uso de sudo -i
ou sudo su -
. Eu tento não usar, sudo vim /path/to/file
mas usar sudoedit
em vez disso.
Por padrão, todas as ações privilegiadas serão registradas no syslog (e /var/log/secure
):
Sep 26 11:00:03 hostname sudo: hbruijn : TTY=pts/0 ; PWD=/home/hbruijn ; USER=jboss ; COMMAND=sudoedit /usr/share/jbossas/domain/configuration/domain.xml
Sep 26 11:00:34 hostname sudo: hbruijn : TTY=pts/0 ; PWD=/home/hbruijn ; USER=root ; COMMAND=/usr/bin/tail -n 5 /var/log/messages
Quase desisti de personalizar meus ambientes de trabalho, a única coisa que realmente faço é definir o seguinte em meu ~/.bash_profile
histórico bash crescente e incluir carimbos de data/hora:
export HISTSIZE=99999999999
export HISTFILESIZE=99999999999
export HISTIGNORE="w:ls:ls -lart:dmesg:history:fg"
export HISTTIMEFORMAT='%F %H:%M:%S '
shopt -s histappend
A única coisa que vem à mente seria adicionar
--expiredate
àadduser
chamada.Com isso o cliente fica sabendo que seu acesso expirará automaticamente em uma data fixa.
Ele ainda precisa confiar em você, pois você tem acesso root e ainda pode remover o sinalizador de expiração.
Você pode gravar suas sessões com o utilitário script(1) .
então tudo está em session.log.
Como você já está efetuando login com uma chave pública SSH, seria um pouco complicado se você não fornecesse um hash de senha; em vez disso, diga a eles para usar
adduser --disabled-password
(equivalentemente,useradd -p '!'
, eu acho), o que é efetivamente equivalente aPasswordAuthentication no
essa conta, além de não haver chance de alguém bisbilhotar seu e-mail forçar o hash da senha e fazer login como você.Por que fornecer uma senha, quando você vai usar chaves públicas/privadas.
As chaves públicas devem ser compartilhadas, então é isso que você deve usar para trocar credenciais com segurança, não senhas com hash.
sudo useradd --disabled-password hbruijn
Ao enviar sua chave pública, verifique a impressão digital em um segundo canal, como um telefonema, para que você saiba que ninguém a alterou no caminho.
Como você não terá uma senha agora para usar o sudo, também precisará alterar sua linha no arquivo sudoers para
hbruijn ALL=(ALL) NOPASSWD:ALL
Se você não se sente confortável em não ter senha para o sudo e realmente deseja uma senha, ainda não há necessidade de enviar sua senha com hash, deixe a conta ser criada sem senha, defina sua chave pública e, assim que sua conta for configurado, você pode fazer login por ssh e executar
passwd
para definir sua própria senha.