SEGURIDAD EN SERVIDOR LINUX

HARDENING

SENA
2017
 TENER EN CUENTA LAS SIGUIENTES RECOMENDACIONES

1. Parche del Sistema Operativo

Es importante en el sistema operativo y paquetes instalados se mantengan actualizados, ya

que es el núcleo del entorno. Para realizar una actualización de todos los paquetes
instalados, puede utilizar estos comandos que enumerará todas las actualizaciones
disponibles para la instalación y hace la solicitud de la continuidad:

Sistema operativo basado en RHEL:

yum update

Sistema operativo basado en Debían:

apt-get upgrade

Estos comandos instalarán todas las actualizaciones de paquetes disponibles desde el

repositorio, que pueden incluir el kernel de Linux. Verifique la lista de actualizaciones que se
instalarán para ver si hay una actualización del kernel ya que esto requerirá un reinicio para
aplicar.

En Linux, el kernel es el componente central del sistema operativo, administra componentes

como la memoria, la CPU, la programación de procesos y más. Debido a este rol central, el
kernel no puede reiniciarse sin reiniciar todo el sistema operativo, por lo que para completar
una actualización del kernel, será necesario reiniciar el sistema.

Es recomendable que las actualizaciones de seguridad se instalen tan pronto como sea
posible, esto puede hacerse manualmente o automáticamente a través de crontab. También
se sugiere que se suscriba a la lista de correo de su sistema operativo ya que estos lo
mantendrán actualizado en cualquier actualización de seguridad para el kernel y otros
paquetes comunes a medida que estén disponibles.

2. Patch Aplicaciones de terceros

Cualquier otra aplicación personalizada que haya instalado y que no sea mantenida por un
administrador de paquetes también debe parcharse con frecuencia para que se puedan
aplicar las últimas actualizaciones de seguridad.

Algunas aplicaciones pueden actualizarse automáticamente como WordPress, mientras que

otras requieren un proceso manual para actualizar, como los complementos de WordPress.
El proceso de actualización para la aplicación particular será diferente caso por caso, por lo
que si no está seguro, verifique la documentación oficial del proveedor y programe
actualizaciones periódicas. Se recomienda que se suscriba a las listas de correo o alertas
proporcionadas por el proveedor de la aplicación para mantenerse al día con las
vulnerabilidades que se den a conocer para que pueda actualizar de manera oportuna.

3. Deshabilitar el acceso remoto a la raíz

En Linux, el usuario raíz tiene acceso completo sin restricciones al sistema, deshabilitando
el registro directamente como el usuario raíz, podemos mejorar la seguridad ya que los
atacantes típicamente intentan comprometer la cuenta raíz. Esto se puede hacer editando el
archivo / etc / passwd y cambiando el shell de la raíz de / bin / bash a / sbin / nologin.

Predeterminado / etc / passwd para la raíz

raíz: x: 0: 0: raíz: / root: / bin / bash

Después de deshabilitar el inicio de sesión root

raíz: x: 0: 0: raíz: / raíz: / sbin / nologin

Esto evitará el acceso a la raíz a través de la GUI, SSH, SCP, SFTP y con su. Sin embargo,
no deshabilitará el acceso a sudo ni a la consola.

Los privilegios de root se pueden delegar a otras cuentas de usuario según sea necesario.
Como práctica recomendada, no desea proporcionar la contraseña de root a múltiples
usuarios, ya que hace más difícil la auditoría y el seguimiento de quién está haciendo lo que
con la cuenta. Para proporcionar acceso de root a otros usuarios, la cuenta de usuario se
puede agregar al archivo sudoers que les otorgará privilegios de root. Este archivo se puede
modificar con el comando 'visudo'.

[root @ centos ~] # visudo

...
raíz ALL = (ALL) ALL
nati ALL = (ALL) ALL
...

4. Deshabilitar el acceso a la consola raíz

El pasó anterior deshabilita el acceso remoto para la cuenta raíz, sin embargo, todavía será
posible que la raíz inicie sesión a través de cualquier dispositivo de la consola. Dependiendo
de la seguridad del acceso a la consola, es posible que desee dejar el acceso a la raíz en
su lugar, de lo contrario, se puede eliminar borrando el archivo / etc / securetty como se
muestra a continuación.

echo> / etc / securetty

Este archivo enumera todos los dispositivos a los que la raíz puede iniciar sesión, el archivo
debe existir, de lo contrario, se permitirá el acceso a la raíz a través de cualquier dispositivo
de comunicación disponible, ya sea consola u otro. Sin dispositivos enumerados en este
archivo, el acceso a la raíz se ha deshabilitado. Es importante tener en cuenta que esto.

5. Restringir los privilegios de raíz

Los usuarios que requieren privilegios de root pueden agregarse al archivo sudoers, sin
embargo, podemos restringir aún más lo que los usuarios pueden ejecutar como root en
lugar de simplemente proporcionar acceso total al especificar explícitamente los comandos
en el archivo sudoers.

[nati @ centos ~] $ sudo reinicio

[sudo] contraseña para nati:
nati no está en el archivo sudoers. Este incidente será reportado.
Sin embargo, después de ejecutar 'visudo' y editar el archivo sudoers como se muestra a
continuación, esto es posible.

nati ALL = / usr / sbin / reiniciar

Después de este cambio, nati ahora puede realizar el reinicio como root pero nada más.

6. Habilite y configure Firewall

Es ideal para restringir el tráfico entrante y saliente, es más común que un servidor permita
el tráfico saliente y solo restrinja el tráfico entrante. Esto se debe generalmente a que los
ataques se inician externamente, especialmente desde Internet, por lo que estas redes
externas son menos confiables que el servidor en sí. Si un servicio en el servidor está
comprometido y el servidor es capaz de conectarse a Internet sin restricciones, podría
causar un mayor compromiso del sistema.

El firewall se debe usar para especificar direcciones IP y puertos de origen y de destino, si

es posible. La restricción basada en las direcciones IP de origen y destino con los puertos
es mucho mejor que simplemente cambiar el puerto en el que se está escuchando un
servicio.

7. Cifrar las transmisiones de red

Esto implica usar herramientas que admitan el cifrado, como SSL / TLS. Esto evitará que
otra persona vea la transferencia de datos a través del cable, suponiendo que la clave
privada en el servidor web esté segura, por supuesto.

Para lograr esto, básicamente debe elegir activamente utilizar herramientas y protocolos
que admitan el cifrado cuando se comuniquen a través de la red, se pueden usar otras
herramientas como VPN para establecer túneles seguros y encriptados entre dos hosts.
8. Autenticación de dos factores

Pueden implementarse para el acceso SSH u otro inicio de sesión de la aplicación, mejorará
la seguridad de inicio de sesión al agregar un segundo factor de autenticación, es decir, la
contraseña se conoce como algo que usted conoce, mientras que el segundo factor puede
ser un token de seguridad física o Dispositivo móvil que actúa como algo que tienes. La
combinación de algo que sabes y algo que tienes te asegura que eres más probable que
digas que eres.

Hay aplicaciones personalizadas disponibles para esto, como Duo Security y Google
Authenticator, así como muchas otras. Estos normalmente implican instalar una aplicación
en un teléfono inteligente y luego ingresar el código generado junto con su nombre de
usuario y contraseña cuando se autentica.

Google Authenticator se puede utilizar para muchas otras aplicaciones que no sean SSH,
como para iniciar sesión en WordPress con compatibilidad de complementos de terceros.

9. Seguridad mejorada de Linux (SELinux)

SELinux fue desarrollado originalmente por la NSA como un conjunto de parches para el
kernel de Linux. SELinux reduce la vulnerabilidad a la escalada de privilegios, proporciona
control de acceso de grano fino y separa los procesos entre sí. Los procesos se ejecutan en
su propio dominio lo que les impide acceder a los archivos utilizados por otros procesos.

Los eventos de seguridad y otros mensajes se almacenan en los archivos de registro por
alguna razón y deben revisarse. Puede ser difícil y lleva mucho tiempo revisar manualmente
los archivos de registro en cada servidor, por lo que podría ver implementar un sistema
como logstash o un servidor syslog para recopilar de manera centralizada todos los
registros.

Los registros de acceso deben supervisarse para que los intentos de acceso no autorizados
se conozcan y se traten según sea necesario. Logwatch también puede instalarse y
configurarse para enviar correos electrónicos a resúmenes periódicos de eventos que se
registran, como paquetes instalados o usuarios que han iniciado sesión. Tener conocimiento
de lo que ocurre en sus sistemas lo ayudará a detectar posibles ataques.
12. Limitar el acceso SSH

Cualquier usuario que cree en un servidor Linux con el shell / bash / bash predeterminado
puede iniciar sesión remotamente mediante SSH una vez que haya establecido una
contraseña. El acceso SSH puede restringirse a un conjunto definido de usuarios o grupos
mediante el uso de AllowUsers o AllowGroups en / etc / ssh / sshd_config, respectivamente.
No todos los usuarios de un servidor normalmente necesitarán acceso SSH, por lo que esto
se puede restringir solo a aquellos que necesitan acceso para administrar el servidor.

AllowUsers root nati

Los usuarios que comparten un atributo común se pueden agrupar y permitir en su lugar
con AllowGroups, que es más escalable con un mayor número de usuarios. Asegúrese de
reiniciar el servicio sshd para aplicar los cambios realizados aquí.

13. Seguridad física

Si su servidor está alojado dentro de un entorno de centro de datos, es probable que ya

restrinja el acceso físico y tenga varias medidas de seguridad implementadas, se
recomienda que analice las medidas de protección implementadas para su servidor y
asegúrese de que cumplan con sus requisitos.

Si hospeda su servidor en un local o en una oficina, debe estar bloqueado de forma segura
en una sala de servidores dedicada, si es posible, en una ubicación central del edificio, con
acceso solo otorgado a aquellos que necesiten mantener físicamente el servidor. También
se recomienda mantener todos los bastidores de servidores o cajas bloqueadas.

14. Asegurando el BIOS

La contraseña que protege el BIOS puede ayudar a reducir la velocidad de un atacante con
acceso físico al cambiar la configuración del BIOS o al arrancar el sistema desde el CD o la
unidad USB. Como la BIOS diferirá entre los fabricantes, debe consultar su documentación
específica sobre cómo configurarla.

Es importante tener en cuenta que esto no protege el sistema muy bien si es posible el
acceso físico completo, ya que la contraseña del BIOS generalmente puede restablecerse
fácilmente con puentes en la placa base o mediante la eliminación de la batería CMOS.

Si bien existen mejores métodos para asegurar un sistema Linux como se sugirió, las
contraseñas de BIOS pueden ser útiles para computadoras públicas, como en una
biblioteca pública, probablemente sean menos propensos a comience a hacer esto en un
lugar público, ya que es más difícil de hacer sin detectar en comparación con simplemente
insertar un CD o una unidad USB.
15. Asegurar el cargador de arranque

Al asegurar el gestor de arranque podemos evitar el acceso al modo de usuario único que
inicia sesión automáticamente como root. Esto se hace con GRUB 2 configurando una
contraseña que se almacena en texto sin formato de forma predeterminada, se recomienda
configurar una contraseña cifrada para que la contraseña de grub no pueda recuperarse
fácilmente del disco.

16. Cifrar datos

Los datos confidenciales almacenados en el servidor Linux deben estar encriptados. Si de

alguna manera se obtiene acceso físico al servidor y se roban los discos duros no
encriptados, todos los datos serán leídos por un atacante. Aunque la seguridad física puede
ayudar a proteger contra este escenario, debe planificar lo peor y encriptar los datos. La
seguridad física puede ser más difícil de implementar para dispositivos portátiles, como
computadoras portátiles y tabletas, el cifrado fuerte puede ayudar a proteger los datos de
los dispositivos robados.

Este problema también existe con las máquinas virtuales, aunque posiblemente en menor
medida, si se copia el archivo del disco duro virtual, es posible acceder a los datos
contenidos en él. Para evitar esto y proteger los datos, debe cifrarse en reposo y no
almacenarse en el disco en texto sin cifrar. Existen muchas maneras de manejar el cifrado,
el formato de disco de configuración unificado de Linux (LUKS) es uno de ellos y funciona
bastante bien. Una vez que los datos han sido encriptados si pierde la contraseña o la clave
para acceder a esos datos, ya no podrá acceder a los datos.

17. Autenticación centralizada

El uso de un directorio central para mantener cuentas de usuario suele ser más seguro y
mucho más escalable a medida que aumenta la cantidad de clientes / servidores a los que
necesita acceder.

Un directorio central ofrece varias ventajas de seguridad. Al almacenar todas las cuentas de
usuario en el directorio, en caso de que una cuenta de usuario se bloquee, se bloqueará
independientemente de la computadora del cliente que intente iniciar sesión. Sin un servidor
de directorio, las cuentas locales se definirían por servidor, por lo que un atacante que
realiza un ataque de fuerza bruta podría simplemente bloquear la cuenta en una
computadora y luego volver a iniciar el ataque en otra.

También puede ser mucho más difícil comprometer los hashes de contraseña de una
cuenta, ya que se almacenan en el servidor de directorio central, en lugar de en cada
servidor individual. Aunque el acceso al archivo / etc / shadow requiere acceso de root para
leer, es posible que un atacante haya comprometido uno de sus servidores y, de hecho,
tenga acceso de root al servidor local. El atacante podría ver los hashes de contraseña para
todos los usuarios en el servidor y realizar un ataque de fuerza bruta fuera de línea, lo que
podría resultar en obtener más credenciales de usuario que pueden ser necesarias para
acceder a sistemas adicionales.

18. Reforzar las contraseñas fuertes

Podemos mejorar la seguridad de una cuenta, ya que el ataque con fuerza bruta se vuelve
más difícil, las contraseñas más fuertes requieren más tiempo y potencia informática para
descubrir. Esto generalmente se hace a través de la política en el servidor de directorio
donde existen las cuentas, pero también se puede configurar localmente por servidor. En
CentOS 7, el módulo PAM de pwquality impone fuertes contraseñas en lugar del módulo
cracklib, pero ambos utilizan el mismo back end.

pwquality comprueba la fuerza de una contraseña contra un conjunto de reglas, primero

comprueba si la contraseña es una palabra de diccionario y luego, si no, comprueba el
conjunto personalizado de reglas definidas dentro de /etc/security/pwquality.conf.

Para habilitar el módulo de calidad agregue la siguiente línea en el archivo

/etc/pam.d/passwd.

contraseña requerida pam_pwquality.so retry = 3

El archivo /etc/security/pwquality.conf se utiliza para configurar las comprobaciones, como la
longitud mínima, este documento documenta bien todas las variables disponibles.

También es importante tener en cuenta que un usuario root puede establecer cualquier
contraseña para ellos mismos o cualquier otra cuenta de usuario independientemente de
esto, se les advertirá si están usando una contraseña débil, sin embargo, pueden evitar la
aplicación de la contraseña.

19. Envejecimiento de contraseñas

El envejecimiento de la contraseña se defiende de la detección y reutilización de

contraseñas incorrectas por parte de un atacante, incluso si una contraseña está
comprometida, solo será utilizable durante un período de tiempo establecido. Las cuentas
que ya no son necesarias pero que no se han bloqueado se volverán inaccesibles cuando
caduque la contraseña. Esto debe configurarse como por defecto, no se requerirá un
cambio de contraseña para 99999 días.

El envejecimiento de la contraseña puede gestionarse localmente por servidor, o como se

menciona anteriormente en un directorio central, como Active Directory o Identity
Management. Es posible administrar el envejecimiento de las contraseñas por servidor a
nivel local, solo requerirá más tiempo de administración y aumentará la probabilidad.
20. Bloqueo de cuenta

Si bien contar con contraseñas sólidas para las cuentas de los usuarios puede ayudar a
frustrar los ataques de fuerza bruta, una buena indicación de ataque de fuerza bruta es una
cuenta de usuario que no pudo iniciar sesión exitosamente varias veces en un corto período
de tiempo, este tipo de acciones deben ser bloqueadas e informadas. Podemos bloquear
estos ataques bloqueando automáticamente la cuenta, ya sea en el directorio si está en uso
o localmente.

El módulo PAM pam_tally2.so se puede usar para bloquear cuentas locales después de un
número determinado de fallas. Para que esto funcione, agregué la siguiente línea al archivo
/etc/pam.d/password-auth.
auth requerido pam_tally2.so file = / var / log / tallylog deny = 3 even_deny_root unlock_time
= 1200

Esto registrará todas las fallas en el archivo / var / log / tallylog y bloqueará una cuenta
después de 3 fallas consecutivas.

El recuento de fallas se puede restablecer manualmente agregando -reset en este

comando.
pam_tally2 --user = nati --reset

Si un inicio de sesión tiene éxito antes de que se haya alcanzado el límite, el recuento de
fallas se restablecerá a 0. También puede bloquear y desbloquear manualmente cuentas de
usuarios locales en lugar de esperar a que se alcance el límite de falla.

Bloquee la cuenta de usuario 'nati'.

[root @ centos ~] # passwd -l nati
Bloqueo de contraseña para usuario nati.
passwd: el éxito

Desbloquee la cuenta de usuario 'nati'.

[root @ centos ~] # passwd -u nati
Desbloqueo de contraseña para usuario nati.
passwd: el éxito

Tenga cuidado al habilitar el bloqueo de la cuenta, ya que los bloqueos automáticos en las
cuentas utilizadas por diversos servicios podrían provocar interrupciones. Esto tiene la
ventaja de bloquear el ataque sin bloquear la cuenta e impedir el acceso legítimo de los
usuarios.
21. Uso de llaves SSH

Las claves SSH se pueden usar para aumentar el nivel de seguridad para un usuario que se
autentica de forma remota en un servidor Linux a través de SSH. Las claves SSH son
generalmente preferibles en términos de seguridad en comparación con una contraseña, ya
que son mucho menos vulnerables a los ataques de fuerza bruta, simplemente hay mucha
más entropía en una clave que en la contraseña.

Las claves SSH se basan en criptografía de clave pública, por lo que generará un par de
claves que incluye una clave pública y una clave privada. La clave pública se almacena en
el servidor de destino a la que desea acceder y solo permitirá el acceso de clave privada
correspondiente. Por lo tanto, es extremadamente importante que proteja su clave privada,
si un atacante puede acceder a esta clave, podrán iniciar sesión como usuario.

Las mejores prácticas dictan que su clave privada se cifre con una contraseña que se puede
configurar cuando se crea el par de claves.

22. Sistema de detección de intrusión basado en host (HIDS)

Incluso después de implementar medidas de seguridad adicionales, aún es posible que su

servidor se vea comprometido, ningún servidor debería considerarse 100% seguro. Si esto
sucediera, querrías recibir una alerta para que puedas investigar más. Esto se puede hacer
mediante el uso de un sistema de detección de intrusiones basado en host que
normalmente se instala en el servidor como un agente que supervisa los elementos internos
del sistema y puede alertar si se detecta una intrusión intentada o exitosa. Si bien esto
definitivamente no detecta ni alerta a cada posible intrusión, es una buena medida de
protección que debe implementarse.

OSSEC es un HIDS de código abierto multiplataforma que es capaz de realizar análisis de

registro, verificación de integridad de archivos, supervisión de políticas, detección de rootkits
y alertas y respuestas en tiempo real.

23. Escaneo de virus / malware

Además de detectar intrusiones, también es importante explorar con frecuencia el sistema

de archivos, la memoria y los procesos en ejecución para conocer los virus conocidos o las
amenazas de malware que pueden haberlo hecho en su servidor Linux. El escaneo debería
ser capaz de poner en cuarentena de manera activa los archivos dañados conocidos que se
detectan y enviar una alerta de notificación para una mayor investigación.

Es una buena idea ejecutar estos escaneos durante períodos de bajo uso de recursos para
que el escaneo no entre en conflicto con el servicio normal. Otras opciones como Config
eXploit Scanner (CXS) también utilizan ClamAV y exploran activamente los archivos a
medida que se cargan o modifican, por ejemplo, si un atacante puede modificar un archivo
con un código malicioso conocido, se detectará y pondrá en cuarentena en cuestión de
segundos .
 CONCLUSIÓN

Si bien es imposible garantizar completamente un sistema Linux, podemos reducir

significativamente la cantidad de vulnerabilidades dentro de un sistema y, por extensión, la
posibilidad de un compromiso al ser conscientes de la seguridad e implementar estos
consejos de endurecimiento. Siempre habrá un intercambio entre seguridad y usabilidad,
donde esa línea se dibuja en su entorno depende de usted.