He tenido algunos problemas de seguridad con un servidor mío, algunos usuarios de SSH han estado provocando incendios, también conocidos como problemas.

Me gustaría:

• Seguimiento de inicios de sesión y cierres
• Rastree la actividad de estos SSH para descubrir cualquier actividad maliciosa
• Evitar que los usuarios eliminen registros

No soy muy administrador de sistemas y soy bastante inexperto en este asunto, por lo que cualquier tipo de consejo sería muy bienvenido y muy útil. :)

Como estamos hablando de servidores SSH, le daré soluciones de línea de comandos.

• Rastree los inicios y cierres de sesión de los usuarios Eso es fácil, el archivo /var/log/auth.logdebe tener esta información.

• Rastree la actividad de esos usuarios: si son bastante inocentes, puede verificar el archivo .bash_historyen su directorio de inicio. Verá una lista de los comandos que ejecutaron. El problema es, por supuesto, que pueden eliminar o editar este archivo.

• Evitar que los usuarios eliminen registros: los usuarios no deberían poder tocar auth.log. Para evitar que jueguen, .bash_historydebes hacer un par de trucos .

• ¿Qué pasa si el usuario logra obtener acceso de root? : Estás jodido. A menos que cometan un error, podrán ocultar todos sus pasos.

[DESCARGO DE RESPONSABILIDAD] Me doy cuenta de que llego tarde a la fiesta, pero me gustaría pegar una respuesta que di a otra pregunta , porque siento que puede ofrecer una buena idea a los lectores, y esta pregunta parece ser la respuesta. lugar para información ssh básica.

Hubo un problema similar que me llamó la atención después de leer esta pregunta aquí en AskUbuntu y comprobar mi VPS, solo para ver una gran cantidad de intentos de fuerza bruta. Fue entonces cuando decidí tomar medidas.

Ahora, de acuerdo con la pregunta a la que me vinculé, si desea ver intentos fallidos de inicio de sesión en su máquina a través de ssh (podrían ser intentos de fuerza bruta o algo), intente escribir esto:

grep sshd.\*Failed /var/log/auth.log | less

Si la salida consta de varias líneas, es decir, muchos intentos de fuerza bruta, especialmente si se han producido entre intervalos cortos, es posible que desee realizar las siguientes acciones:

Cambiar el archivo de configuración ssh

Para hacer esto, abra el archivo ubicado en / etc / ssh / sshd_config con su editor favorito, así vim /etc/ssh/sshd_config.

1. Intente mover ssh desde el puerto 22 : Ahora ubique la línea que dice:

# What ports, IPs and protocols we listen for
Port 22

y comenta el Puerto 22, y usa a cualquiera que te guste. Ejemplo:

# What ports, IPs and protocols we listen for
# Port 22
Port 28934

Recuerde que los puertos por debajo de 1024 necesitan un permiso especial (root). No sé cómo esto podría interferir con eso, pero solo digo.

2. Desactive los inicios de sesión de raíz a través de ssh : dado que el nombre de usuario raíz es predecible y proporciona acceso completo a su sistema, no es aconsejable proporcionar acceso sin restricciones a esta cuenta a través de SSH. Localice la línea que lee PermitRootLogin y configúrelo en no .

PermitRootLogin no

3. Desactive la autenticación de contraseña : genere y use claves SSH para iniciar sesión en su sistema. Sin las contraseñas habilitadas, los atacantes deberán adivinar (o robar) su clave privada SSH para obtener acceso a su servidor. Algo que es muy muy difícil. Proceda a buscar la línea que lee Autenticación de contraseña y configúrela como no

PasswordAuthentication no

!¡ADVERTENCIA! Antes de hacerlo, consulte esta guía aquí sobre cómo configurar la autenticación de certificado.

NOTA: Después de haber realizado los cambios, use sudo /etc/init.d/ssh restart. Para conectarse a otro puerto a través del uso de ssh: ssh [email protected] -p <port_number>.

Configurar un firewall

Consulte esta guía sobre cómo configurar el firewall extremadamente potente y efectivo, que está integrado en Linux, IPTables .

Configura scripts para ayudarte con la seguridad

Uno que uso personalmente y que rápidamente viene a mi mente es Fail2Ban . Fail2ban supervisará sus archivos de registro en busca de intentos fallidos de inicio de sesión. Después de que una dirección IP haya excedido el número máximo de intentos de autenticación, se bloqueará a nivel de red y se iniciará sesión en el evento /var/log/fail2ban.log. Para instalarlo:sudo apt-get install fail2ban

Verifique el historial de comandos a través de ssh

Hay un comando de Linux, llamado history, que le permite ver qué comandos se han ingresado hasta ese punto. Intenta escribir historyen una terminal para ver todos los comandos hasta ese punto. Podría ayudar si fueras root .

Para buscar un comando en particular, intente:history | grep command-name

Para enumerar todos los comandos después de ssh :fc -l ssh

También puede editar comandos usando vi (no lo he probado vim, aunque supongo que también funciona):fc -e vi

También puedes eliminar el historial :history -c

NOTA: Si no eres fanático del comando, historytambién hay un archivo en tu directorio de inicio ( cd ~), llamado .bash_history (si estás usando bash) que puedes catver todo lo que se ha escrito en el shell bash.

Un poco exagerado, pero puede ver todo lo que se ejecuta en su sistema utilizando el "conector de eventos de proceso":

http://www.outflux.net/blog/archives/2010/07/01/reporting-all-execs/

1. Javier ya respondió a esta: /var/log/auth.log
2. He encontrado un gran artículo sobre esto aquí .
3. Si sus usuarios no tienen acceso a la raíz, sus archivos de registro deberían estar seguros. Puede intentar crear algunas reglas personalizadas en el archivo sudoers para restringir a qué pueden acceder sus usuarios y cómo. También puede aumentar el nivel de registro para el demonio sshd.

Además del inicio de sesión en sí, no hay una forma segura de rastrear / registrar las acciones de los usuarios después de que inician sesión, suponiendo que tengan conocimientos básicos de Linux, podrán desactivar el registro de shell o simplemente ejecutar comandos desde otros shells (por ejemplo, python).

En su lugar, debe ser conservador al proporcionar acceso ssh, ¿realmente lo necesitan? No es muy común otorgar acceso ssh a menos que esté en el shell que proporciona negocios.