Hola Habr!
No hemos publicado ningún libro nuevo en Linux para principiantes durante mucho tiempo, y ahora estamos emprendiendo la traducción de nuevos productos de tal plan. El libro de Clinton,
Linux in Action , publicado por Manning, habla no solo de la
estructura interna de Linux , sino también de los problemas más comunes y cómo solucionarlos.
El autor ha publicado un extracto del capítulo 9 en el sitio web de Hackernoon, que sugerimos que evalúe.
Ensamblar un servidor LAMP, cómo configurarlo, garantizar un procesamiento de datos confiable, configurar el área temática y cuidar un certificado TLS es solo la mitad del camino hacia la victoria. También debe asegurarse de que su infraestructura esté protegida de las muchas amenazas terribles de Internet.
En este artículo, examinamos la seguridad de un sitio web al aprender a trabajar correctamente con grupos de sistemas, garantizar el aislamiento del proceso y auditar regularmente los recursos del sistema. Por supuesto, esta historia no está completa (el libro de Linux en acción también cubrió otros temas, por ejemplo, instalar certificados TLS y trabajar con SELinux), pero esto será suficiente para empezar.
Grupos de sistemas y el principio de privilegios mínimos
Los desarrolladores que está apoyando (finalmente) están comenzando a darse cuenta de que es necesario limitar el acceso general a los datos y archivos de configuración ubicados en el servidor de aplicaciones, pero al mismo tiempo, dejar dicho acceso abierto a varios programadores y otros equipos de TI.
La primera parte de la solución son los
grupos . Un grupo es un objeto en el sistema (al igual que un usuario) con la advertencia de que ningún usuario iniciará sesión en el sistema como grupo. La fortaleza de los grupos radica en el hecho de que ellos, como los usuarios, pueden ser "asignados" a archivos o directorios, lo que permite a cada miembro del grupo utilizar los privilegios que se le otorgan. Esto se ilustra a continuación.
Los desarrolladores del grupo de desarrolladores pueden acceder a un directorio específico, y para los usuarios que no son miembros de este grupo, el directorio se cerrará
Pruébelo usted mismo: cree un nuevo archivo en un editor de texto. Escriba texto simple en él, por ejemplo, "Hola mundo", para que pueda ver de inmediato cuándo se accedió con éxito al archivo. Luego edite los permisos usando
chmod 770 para que el propietario del archivo y los miembros del grupo al que pertenece tengan todos los derechos para trabajar con el archivo, mientras que otros no puedan leerlo.
$ nano datafile.txt $ chmod 770 datafile.txt
Si su sistema aún no tiene otras cuentas de usuario además de la suya, cree dicha cuenta utilizando
adduser , esto se hace en Debian / Ubuntu, o use
useradd , como es habitual en CentOS. El comando
useradd también funcionará en Ubuntu.
El comando
useradd , a diferencia del
adduser Debian
adduser requiere que la contraseña del usuario se genere por separado:
# useradd otheruser # passwd otheruser Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully
Usando el comando
su , cambiamos al nuevo usuario. Después de ingresar su contraseña, todos los siguientes comandos se ejecutarán en nombre de este usuario. Trabajará en nombre de este usuario en particular; ni más ni menos. Si intentas leer el archivo de datos
datafile.txt (usando
cat ), ya nada funcionará para ti; Como recordará, solo los miembros del grupo tienen derechos de lectura. Cuando termine, escriba
exit para salir del nuevo shell de usuario y volver al shell original.
$ su otheruser Password: $ cat /home/ubuntu/datafile.txt cat: /home/ubuntu/datafile.txt: Permission denied $ exit
Todo esto es esperado y bastante comprensible. Como puede ver, cuando no puede leer un archivo que pertenece a otro usuario, esto a veces es un problema. Veamos qué puede hacer asociando el archivo con el grupo y luego configurando correctamente los permisos del archivo.
Crearemos un nuevo grupo con el que podremos administrar los datos de nuestra aplicación, y luego editaremos las propiedades de nuestro archivo de datos usando el
chown . El argumento de ubuntu: app-data-group deja la propiedad del archivo al usuario de Ubuntu, pero su grupo cambia a uno nuevo: app-data-group.
# groupadd app-data-group # chown ubuntu:app-data-group datafile.txt
Ejecute ls para obtener la salida "expandida" de este archivo y ver sus nuevos permisos y estado. Tenga en cuenta: como se esperaba, el archivo es propiedad del usuario de
ubuntu que pertenece al grupo
app-data-group la
app-data-group .
$ ls -l | grep datafile.txt -rwxrwx — — 1 ubuntu app-data-group 6 Aug 9 22:43 datafile.txt
Puede usar
usermod para agregar su usuario al
app-data-group y luego usar el comando
su para cambiar al shell en el que se implementa la cuenta de otro usuario. Ahora, a pesar de que los derechos de acceso al archivo lo bloquean de todos los "otros", y usted es definitivamente un usuario "diferente" en este momento, debe leer este archivo libremente, porque pertenece al grupo necesario.
# usermod -aG app-data-group otheruser $ su otheruser $ cat datafile.txt Hello World
Usando el comando
su , cambiamos entre cuentas de usuario. Se registran en mi archivo
datafile.txt . Dicha organización es la forma correcta y efectiva de eliminar una variedad de problemas complejos con los derechos de acceso que pueden surgir en un sistema multiusuario.
De hecho, se utiliza no solo para proporcionar los derechos de acceso necesarios a usuarios individuales, sino que muchos procesos del sistema tampoco serían capaces de llevar a cabo sus tareas si no se les prescribe la membresía en los grupos necesarios. Puede ver el archivo / etc / group en diagonal: observe cuántos procesos del sistema pertenecen a sus propios grupos ...
Listado abreviado de los contenidos del archivo / etc / group:
$ cat /etc/group root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4:syslog tty:x:5: disk:x:6: lp:x:7: mail:x:8: news:x:9: uucp:x:10: man:x:12: proxy:x:13: […]
Aislamiento del proceso de contenedor
¿Quizás le preocupa que muchos servicios que se ejecutan en su mismo servidor estén en riesgo si al menos uno de estos servicios se ve comprometido? Una opción para suavizar el daño que pueden causar usuarios descuidados o malintencionados es aislar los recursos y procesos del sistema. Por lo tanto, incluso si alguien desea expandir su autoridad más allá de los límites establecidos, no obtendrá acceso físico a los datos.
Anteriormente, se decidió resolver este problema de la siguiente manera: a cada servicio se le asignaba su propia máquina física. Sin embargo, la virtualización hace que sea mucho más fácil y económico construir una arquitectura de "malla". Hoy en día, esta arquitectura se conoce como
microservicio y le permite ejecutar muchos contenedores a la vez, en uno de los cuales, por ejemplo, una base de datos puede funcionar, en el otro, Apache y en el tercero, archivos multimedia que se pueden insertar en sus páginas web. La arquitectura de microservicios permite no solo aumentar significativamente la productividad y la eficiencia, sino también reducir significativamente el riesgo de pirateo de cada componente individual.
Los "contenedores" de los que estoy hablando no tienen que ser convincentes con LXC. Otras tecnologías de contenedores como Docker se están volviendo mucho más populares hoy en día.
Comprobación de valores de ID de usuario peligrosos
Por supuesto, cualquier usuario con derechos de administrador puede proporcionar temporalmente acceso de root con el
sudo , pero solo el administrador es el administrador real. Como ya sabe, no es seguro realizar funciones regulares en el acceso raíz. Sin embargo, esto puede suceder, ya sea por accidente o por fraude de datos malicioso, que un usuario común tendrá derechos administrativos sin interrupciones.
En este caso, es bueno que no sea difícil identificar a esos impostores: su ID de usuario y / o grupo, como la del administrador, será "0". Eche un vistazo al archivo passwd en el directorio / etc /. Este archivo contiene un registro para cada cuenta de usuario regular y del sistema que ya existe en el sistema. El primer campo contiene el nombre de la cuenta (en este caso, root y ubuntu), y en el segundo campo se puede usar x en lugar de la contraseña (si la contraseña existe, se cifrará en el archivo / etc / shadow). Pero los siguientes dos campos contienen el ID de usuario y grupo. En el caso de
ubuntu en este ejemplo, ambas ID son 1000. Y el administrador, como puede ver, tiene ceros aquí.
$ cat /etc/passwd root:x:0:0:root:/root:/bin/bash […] ubuntu:x:1000:1000::/home/ubuntu:/bin/bash
Si alguna vez conoce a un usuario normal con un ID de usuario o grupo = 0, puede estar seguro de que el asunto no está limpio y que la situación debe repararse. Una forma rápida y fácil de identificar dicho problema es verificar el
passwd con el comando
awk , que mostrará todas las líneas en el tercer campo de las cuales no hay nada más que 0. En mi caso (puede exhalar) solo había una de esas líneas: la raíz. Puede ejecutarlo nuevamente reemplazando $ 4 por $ 3; esto verificará el campo ID de grupo.
$ awk -F: '($3 == “0”) {print}' /etc/passwd root:x:0:0:root:/root:/bin/bash
Auditoría de recursos del sistema
Mientras más cosas haya en su sistema, mayor será la probabilidad de que algo se rompa. Por lo tanto, es aconsejable rastrear qué funciona y cómo. En este caso, estamos hablando de puertos de red (si el puerto está "abierto", entonces, por definición, debería ser una entrada), servicios (si el servicio está activo, entonces debería ser posible usarlo) y programas instalados (si el programa está instalado, debería ser la capacidad de realizarlo).
Para que una auditoría sea beneficiosa, debe ser más o menos regular. Como todos somos olvidadizos, es mucho mejor escribir herramientas de auditoría en un script especial que no solo se ejecutará regularmente, sino que idealmente analizará los resultados para que sean más legibles.
Aquí, sin embargo, le presento tres herramientas clave de auditoría que lo ayudarán a ver puertos abiertos, servicios activos y paquetes de software innecesarios. Su tarea es automatizar todo esto.
Escaneo de puertos
Un puerto se considera "abierto" si un host está ejecutando un proceso que escucha las solicitudes en este puerto. Vigilando sus puertos abiertos, comprenderá mejor qué está sucediendo exactamente en su servidor.
Ya sabes que los puertos HTTP (80) y SSH (22) probablemente deberían estar abiertos en un servidor web normal, por lo que no te sorprenderán. Pero es mucho más importante prestar atención a otros resultados inesperados. El comando netstat muestra todos los puertos abiertos, así como una tonelada de información sobre cómo se usan.
En este ejemplo, estamos probando un servidor multipropósito muy típico, y el comando
-n le dice a
netstat que habilite todos los puertos y direcciones numéricos.
-l solo incluye tomas de escucha y
-p agrega la ID del proceso del programa de escucha. Naturalmente, si ves algo, actúa.
# netstat -npl Active Internet connections (only servers) Proto Local Address Foreign Address State PID/Program name tcp 127.0.0.1:3306 0.0.0.0:* LISTEN 403/mysqld tcp 0.0.0.0:139 0.0.0.0:* LISTEN 270/smbd tcp 0.0.0.0:22 0.0.0.0:* LISTEN 333/sshd tcp 0.0.0.0:445 0.0.0.0:* LISTEN 270/smbd tcp6 :::80 :::* LISTEN 417/apache2 […]
En los últimos años,
ss utilizado cada vez más en lugar de
netstat . Por las dudas: si una noche te encuentras en una empresa y alguien te pregunta sobre ss, entonces este ejemplo (que enumera todas las conexiones SSH instaladas) debería ser lo suficientemente informativo como para que no puedas enfrentar la suciedad:
$ ss -o state established '( dport = :ssh or sport = :ssh )' Netid Recv-Q Send-Q Local Address:Port Peer Address:Port tcp 0 0 10.0.3.1:39874 10.0.3.96:ssh timer:(keepalive,18min,0)
Comprobación de servicios activos
Si toma una instantánea rápida de los servicios administrados por el
system y actualmente activos en su computadora, la máquina ayudará a identificar cualquier actividad no deseada. El comando
systemctl puede enumerar todos los servicios existentes, y luego su lista puede reducirse a aquellos cuya descripción contiene
enabled . Por lo tanto, solo se devolverán los servicios activos.
# systemctl list-unit-files — type=service — state=enabled autovt@.service enabled bind9.service enabled cron.service enabled dbus-org.freedesktop.thermald.service enabled docker.service enabled getty@.service enabled haveged.service enabled mysql.service enabled networking.service enabled resolvconf.service enabled rsyslog.service enabled ssh.service enabled sshd.service enabled syslog.service enabled systemd-timesyncd.service enabled thermald.service enabled unattended-upgrades.service enabled ureadahead.service enabled
Si encuentra algo que obviamente no
systemctl , puede usar el comando
systemctl para detener el servicio y asegurarse de que no se reinicie en el próximo arranque.
# systemctl stop haveged # systemctl disable haveged
En realidad, no hay nada oscuro y sombrío en el servicio
haveged que detengo en este ejemplo: es una herramienta que a menudo ejecuto para crear una actividad aleatoria del sistema de fondo cuando creo claves de cifrado.
Buscar programas instalados
¿Alguien podría instalar programas en el sistema sin su conocimiento? Bueno, para descubrirlo, debes mirar. El comando
yum list installed o, en el caso de Debian / Ubuntu,
dpkg — list le dará un resumen detallado, y el comando remove debería eliminar todos los paquetes que no necesitamos.
# yum list installed # yum remove packageName
Así es como se hace lo mismo en Ubuntu:
# dpkg --list # apt-get remove packageName
También es útil realizar un seguimiento de los cambios que se están realizando en los archivos de configuración de su sistema; hablaremos de esto en el Capítulo 11.