De vez en cuando recibo la extraña solicitud de proporcionar asistencia remota, resolución de problemas y / o ajuste de rendimiento en sistemas Linux.
Las compañías más grandes a menudo ya tienen procedimientos bien establecidos para proporcionar acceso remoto a vendedores / proveedores y solo necesito cumplir con ellos. (Para bien o para mal.)
Por otro lado, las pequeñas empresas y los individuos siempre recurren a mí para instruirlos sobre lo que deben hacer para prepararme. Por lo general, sus servidores están conectados directamente a Internet y las medidas de seguridad existentes consisten en los valores predeterminados para cualquier distribución de Linux.
Casi siempre necesitaré acceso de nivel raíz y quien sea que configure el acceso para mí no es un administrador de sistemas experto. No quiero su contraseña de root y también estoy bastante seguro de que mis acciones no serán maliciosas, pero qué instrucciones razonablemente simples debo dar a:
- configurar una cuenta e intercambiar credenciales de forma segura
- configurar el acceso root (sudo)
- restringir el acceso a mi cuenta
- proporcionar seguimiento de auditoría
(Y sí, soy consciente y siempre advierto a esos clientes que una vez que tenga acceso de administrador, ocultar cualquier acción maliciosa es trivial, pero supongamos que no tengo nada que ocultar y participar activamente en la creación de un seguimiento de auditoría).
¿Qué se puede mejorar en los pasos a continuación?
Mi conjunto de instrucciones actual:
configurar una cuenta e intercambiar credenciales de forma segura
Proporciono un hash de contraseña y solicito que mi cuenta esté configurada con esa contraseña cifrada, por lo que no necesitaremos transmitir una contraseña de texto claro, seré el único que conoce la contraseña y no comenzamos con Una contraseña débil predecible.
sudo useradd -p '$1$********' hbruijn
Proporciono una clave pública SSH (par de claves específico por cliente) y les pido que configuren mi cuenta con esa clave:
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 el acceso root (sudo)
Le pido al cliente que configure sudo para mí con sudo sudoedit
o usando su editor favorito y agregue a /etc/sudoers
:
hbruijn ALL=(ALL) ALL
restringir el acceso a mi cuenta
Por lo general, el cliente todavía permite inicios de sesión basados en contraseña y les pido que agreguen las siguientes dos líneas para /etc/ssh/sshd_config
al menos restringir mi cuenta solo a claves SSH:
Match user hbruijn
PasswordAuthentication no
Dependiendo del cliente, enrutaré todo mi acceso SSH a través de un solo host de bastión para proporcionar siempre una única dirección IP estática (por ejemplo 192.168.1.2) y / o proporcionar el rango de direcciones IP que utiliza mi ISP (por ejemplo, 10.80). 0.0 / 14). El cliente puede necesitar agregarlos a una lista blanca de firewall si el acceso SSH está restringido (sin embargo, la mayoría de las veces, ssh no está filtrado).
Ya viste esas direcciones IP como la from=
restricción en el ~.ssh/authorized_keys
archivo que limita los hosts desde los cuales se puede usar mi clave para acceder a sus sistemas.
proporcionar seguimiento de auditoría
Hasta ahora, ningún cliente me lo había pedido, y no he hecho nada específico más allá de lo siguiente para cubrir mi trasero:
Intento usarlo constantemente sudo
con comandos individuales e intento evitar usar sudo -i
o sudo su -
. Trato de no usar, sudo vim /path/to/file
pero uso sudoedit
en su lugar.
Por defecto, todas las acciones privilegiadas se registrarán en syslog (y /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
La mayoría de las veces me doy por vencido en la personalización de mis entornos de trabajo, lo único que realmente hago es configurar lo siguiente en mi ~/.bash_profile
creciente historial de bash e incluir marcas de tiempo:
export HISTSIZE=99999999999
export HISTFILESIZE=99999999999
export HISTIGNORE="w:ls:ls -lart:dmesg:history:fg"
export HISTTIMEFORMAT='%F %H:%M:%S '
shopt -s histappend
screen
, por lo que, en casos extremos, su cliente puede ver en vivo lo que está haciendo.Respuestas:
Lo único que viene a la mente sería agregar
--expiredate
a laadduser
llamada.Con eso, el cliente sabe que su acceso caducará automáticamente en una fecha fija.
Todavía necesita confiar en ti, ya que tienes acceso de root y aún podría eliminar el indicador de caducidad.
fuente
Puede grabar sus sesiones con la utilidad script (1) .
entonces todo está en session.log.
fuente
Dado que ya está iniciando sesión con una clave pública SSH, se reforzaría un poco si no proporcionara un hash de contraseña; en su lugar, dígales que usen
adduser --disabled-password
(de manera equivalente,useradd -p '!'
creo), que es efectivamente equivalente aPasswordAuthentication no
esa cuenta, además, no hay posibilidad de que alguien que espíe su correo electrónico pueda forzar el hash de contraseña e iniciar sesión como usted.fuente
Match user hbruijn \n PasswordAuthentication no
a sshd_config debería evitar que cualquier persona inicie sesión de forma remota con mi contraseña descifrada (los usuarios potencialmente locales podrían usarlasu - hbruijn
) pero, hasta donde sé, todavía necesito tener una contraseña válida para estossudo
propósitos. ¿Quizás debería simplemente restablecer mi contraseña después de iniciar sesión?--disabled-password
estado puede recibir una contraseña ejecutándosepasswd
desde esa cuenta.hbruijn ALL=(ALL) NOPASSWD: /usr/bin/passwd hbruijn
?¿Por qué proporcionar una contraseña cuando va a utilizar claves públicas / privadas?
Las claves públicas están destinadas a ser compartidas, así que esto es lo que debe usar para intercambiar credenciales de forma segura, no contraseñas hash.
sudo useradd --disabled-password hbruijn
Cuando envíe su clave pública, verifique la huella digital a través de un segundo canal, como una llamada telefónica, para que sepa que nadie la alteró en el camino.
Como no tendrá una contraseña ahora para usar sudo, también debe modificar su línea en el archivo sudoers para
hbruijn ALL=(ALL) NOPASSWD:ALL
Si no se siente cómodo con no tener una contraseña para sudo y realmente desea una contraseña, todavía no es necesario que envíe su contraseña cifrada, permita que la cuenta se cree sin contraseña, configure su clave pública y una vez que su cuenta esté configurar puede iniciar sesión a través de ssh y ejecutar
passwd
para establecer su propia contraseña.fuente