Académique Documents
Professionnel Documents
Culture Documents
HARDENING
SENA
2017
TENER EN CUENTA LAS SIGUIENTES RECOMENDACIONES
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.
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.
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.
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'.
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.
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.
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.
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.
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.
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.
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í.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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