Cómo no proteger sus sistemas en la nube

¡A menudo, cuando le cuento a alguien sobre la vulnerabilidad, me miran como un loco con un letrero que dice "Arrepiéntanse, porque el fin del mundo está cerca"!

Ahora todos están entrando en pánico y tratando de organizar un "control remoto", cometiendo errores simples, recolectando todos los rastrillos posibles, así que decidí compartir algunas historias dramáticas con la participación de hackers gitanos, CVE abiertos y devops profesionales, pero un poco ingenuos. Por supuesto, tuve que omitir algunos detalles o incluso distorsionarlos intencionalmente, para no molestar a los clientes. En su mayor parte, esta no es una práctica del trabajo actual en Technoserv, pero deje que esta publicación sea una pequeña nota sobre cómo no hacerlo, incluso si realmente lo desea.

Cómo cercar el servidor


Había un servidor en el centro de datos. Tal hierro de la vieja escuela, sin ningún contenedor elegante y virtualización. Hace varias generaciones de empleados, uno de los desarrolladores lo configuró "temporalmente, de modo que solo se acepten unos pocos archivos grandes para el proyecto". Al mismo tiempo, la empresa realmente se preocupaba por la seguridad de la información, pero, como suele suceder, los colegas de IS fueron a satisfacer las necesidades de la empresa y acordaron una opción temporal con acceso total a Internet.

Afortunadamente, el servidor estaba ubicado en la zona gris de la DMZ y no podía conectarse directamente a los servicios críticos del circuito interno. El puerto 22 se estableció, y en el interior, solo agregaron algunos usuarios locales con contraseñas individuales para iniciar sesión a través de ssh / sftp. El acceso por certificados se consideró demasiado inconveniente. Luego, los desarrolladores de otro proyecto vinieron corriendo y pidieron ayudar a automatizar las cargas regulares desde el servidor de la contraparte, porque "usted tiene un servidor conveniente con un acceso coordinado a la red". Entonces otra vez.

El resultado fue una situación extremadamente alegre cuando el servidor, que parecía temporal, no recibió ninguna actualización, pero un montón de procesos comerciales ya estaban vinculados y se bombeaban varios terabytes de datos por mes.

Decidimos monitorearlo, ya que el servidor es muy importante, y los gráficos de la CPU tienen de inmediato un estante del 100%. Lo acertaron al resolverlo: y hubo un montón de procesos rand en nombre de la prueba de usuario sospechosa y un montón de memoria que habían comido, y los registros tenían una fuerza bruta continua de todo el mundo.

Antes de dejar el servidor en el olvido, pincharon los procesos: lsof enseguida mostró los archivos borrados pero no cerrados que aún estaban colgados en la RAM. Desafortunadamente, no fue posible entender exactamente lo que estaba haciendo el atacante, pero era más probable que el comportamiento fuera como una persona que elaborar un guión. Al examinar una secuencia de comandos en RAM, las inserciones como scanez clasa (escanear una clase) en rumano estaban muy contentas:

#!/bin/bash
while["1"];do
class="
#168
"
classb="`seq 1 255`"
classb2=($classb)
num_classb=${#classb2[*]}
b=${classb2[$((RANDOM%num_classb))]}
classc="`seq 1 255`"
classc2=($classc)
num_classc=${#classc2[*]}
c=${classc2[$((RANDOM%num_classc))]}
classes=($class)
num_class=${#classes[*]}
a=${classes[$((RANDOM%num_class))]}
echo "scanez clasa ${a}.${b}"
./a ${a}.${c}
done

Hasta donde sé, no se ha filtrado nada grave (o no me lo contaron) y el atacante no pudo entrar al perímetro, pero desde entonces la compañía ha estado hablando de hackers gitanos ladrones de caballos.

reglas


  1. No permita que soluciones temporales convenientes, pero inseguras se arreglen en la infraestructura. Sí, sé que son inconsistentes, pero solo soportan la cuarentena, pero solo acuerdan cuándo los eliminarán. Después de cuántos días u horas. Y limpiar sin demora. Bueno, al menos díselo a los demás, por favor. Después de todo, el servicio expuesto comienza a romperse en un promedio de 20 minutos.
  2. No muestre ssh y RDP puro al exterior, es mejor proporcionar acceso a través de VPN o servicios de túnel web. No sé por qué, pero para ellos, las personas son más responsables del conjunto de cuentas permitidas y sus contraseñas.
  3. ssh — . . ssh, .
  4. - — - fail2ban, , - . «» «». , . , , , — .
  5. , : « ?» .
  6. . . , , .

IP – , firewall !


Entiendo perfectamente que NAT era una muleta necesaria que arruinaba la vida de los desarrolladores y no permitía implementar opciones para conectar nodos rápidamente entre sí. Sin embargo, su efecto secundario de ocultar la estructura interna de la red es muy útil en términos de complicar un ataque automatizado regular. Y sí, entiendo muy bien que la opción más correcta es usar un firewall de la lista blanca para permitir explícitamente solo las conexiones necesarias. El problema es que en el mundo de aggail continuo para pequeños problemas como la configuración dura de un firewall o Dios no lo quiera, SELinux nunca tiene el tiempo y el presupuesto. En general, interfieren con la depuración, reducen el indicador crítico del tiempo de comercialización y no permiten que los desarrolladores y desarrolladores vivan en paz.

La situación se volvió aún más interesante cuando la infraestructura de la nube, implementada automáticamente bajo demanda, se convirtió en el estándar de la industria. El hecho es que la mayoría de las soluciones en la nube suponen que la protección de un montón de contenedores elevados y máquinas virtuales recae en el usuario final. Como regla, le brindan la infraestructura, le asignan direcciones IP blancas y eso es todo, en esencia, le brindan un conjunto de capacidades, no soluciones preparadas. De forma predeterminada, todo está cerrado, pero es inconveniente y, por lo tanto, impide el desarrollo. Por lo tanto, abramos todo y lo probaremos con calma, pero en producción lo haremos bien.

A menudo esto lleva a casos divertidos. Vi una copia ligeramente pirateada del famoso servidor MMORPG. Clanes, donat, discusiones continuas de las madres de los demás y otras alegrías. Todos se preguntaban por qué algunos personajes bombeaban tan rápido y, en general, eran omnipotentes. Ejecuté nmap a través del rango de direcciones más cercanas al servidor del juego.

Resultó que toda la infraestructura, incluida la interfaz, el servidor y la base de datos, simplemente bloquearon los puertos abiertos al mundo exterior. ¿Y cuál es la contraseña más probable para el usuario sa si la base de datos es accesible a través de Internet? Así es, sa también! Como resultado, lo más difícil es descubrir la estructura de la tabla.

Una historia similar fue con un cliente que abrió el acceso remoto al panel de administración para una máquina doméstica mientras trabajaba desde su casa por un tiempo. Naturalmente, el panel de administración no tenía autorización, ya que se consideraba un recurso interno seguro. Y el cliente no se molestó y simplemente abrió el puerto para todo Internet de inmediato.

Y los servidores ELK abiertos al mundo aparecen cada semana. Lo que simplemente no encuentra en sus contenidos. A partir de datos personales, terminando con números de tarjeta de crédito.

reglas


  1. El firewall debe estar en la lista blanca. En ningún caso el backend debe ser accesible desde el exterior. Y no dude en preguntar a los contratistas y empleados remotos desde qué IP se conectarán. Al final, una IP dedicada cuesta alrededor de 150 r / mes, lo cual es un desperdicio factible por la oportunidad de trabajar desde casa.
  2. Utilice siempre HTTPS y autenticación completa, incluso si son máquinas de prueba "solo".
  3. Pruebas estrictamente separadas y entornos productivos. Nunca, nunca, use las mismas cuentas en ambos entornos.

Samba


Especialmente a menudo estoy contento con el servidor Samba, que se usa tradicionalmente para organizar el acceso compartido a los recursos. ¿Por qué no configurar el acceso de invitados para colegas del departamento vecino para intercambiar archivos de manera conveniente?

En una empresa pequeña, todo salió bien hasta que no hubo más departamentos. Después de algún tiempo, fue necesario configurar el acceso a sucursales remotas. Y una solución completamente "razonable" era abrir el acceso a la samba desde el exterior. Bueno, todos tienen sus propias contraseñas, ¿qué podría salir mal? Nadie recordaba sobre el acceso de invitados hasta que resultó que una parte tangible del HDD estaba obstruida con los datos de otra persona. Los escáneres automáticos encontraron rápidamente un almacenamiento de archivos gratuito, y el HDD comenzó a obstruirse rápidamente con los archivos cifrados de otra persona. Y en uno de los directorios, encontramos durante la auditoría una colección de películas seleccionadas para adultos con la participación de actrices mayores de 60 años (y fue una suerte que no 18, de lo contrario habría volado de las agencias de aplicación de la ley).

recomendaciones


  1. Nunca comparta almacenamiento sin una VPN.
  2. samba ftp-. , .
  3. , , - .

,


Tenía un cliente que no entendía en absoluto por qué necesitaba gastar cantidades adicionales en copias de seguridad si todo funcionaba para él. Esto es costoso. Y está bien afinado. Como resultado, los empleados que abren y ejecutan todo en una fila que se envían por correo atrapan de forma segura un virus de cifrado. Perdieron la base 1C y pudieron restaurarla solo gracias al archivo en papel y a un contratista que una vez copió la base para sí mismo.

Hablé con el líder, le expliqué los puntos clave que deben cambiarse en la empresa para eliminar los riesgos de perder la base. Asintió durante toda la conversación y terminó con una frase maravillosa: “El proyectil no golpea el mismo agujero dos veces. Ahora no hay nada que temer ". Nuevamente rechazó las copias de seguridad y, naturalmente, perdió todos los datos en el mismo escenario seis meses después.

reglas


  1. , (- ). , .
  2. . - , .
  3. . . , helpdesk.

!


En mi experiencia, las pequeñas y medianas empresas suelen comenzar con una gestión de cuentas de usuario totalmente manual. Quiero decir, el nuevo gerente de ventas pisa fuerte en la guarida de administradores barbudos, donde solemnemente se le da un nombre de usuario, contraseña y acceso. Todo esto funciona bien hasta que la empresa comience a crecer.

Aquí están las personas que vendieron tanques compuestos. Recientemente cambiaron su liderazgo y se decidió realizar una auditoría de seguridad completa. Incluso nos llevaron a una excursión para mostrar la producción. El espectáculo es muy impresionante: en un gran taller, se rotaron grandes piezas de trabajo, en las que se enrollaba fibra de vidrio, mientras los trabajadores corrían con un cubo de resina epoxi, untando cuidadosamente sobre la pieza de trabajo.

En un edificio separado tenían un ala administrativa, donde nos enterramos directamente en la organización de la parte de información de producción. A primera vista, habían organizado un esquema bastante lógico, cuando el acceso a la base de datos del cliente se proporcionaba solo a través de una cuenta interna en AD con la aprobación del jefe. Cuando una persona dejó de fumar, revisó la lista de verificación, entregó el equipo, las tarjetas y la cuenta fue desactivada. Todo esto se hizo manualmente, ya que no se asignaron fondos para la gestión completa de la identidad.

En el proceso de auditoría, descubrimos que habían implementado un portal autoescrito hace muchos años para que los vendedores pudieran recibir de forma remota los datos que necesitan sobre los clientes. Incluso comenzaron a migrar su infraestructura a la nube, pero al final se detuvieron a la mitad debido a algunas dificultades internas. Además, AD no pudo integrarse allí y las cuentas se eliminaron exactamente de la misma manera en la lista de verificación al momento del despido. Todo parece ser normal, pero en los registros encontramos una cuenta activa de cierto Vasily, quien fue despedido hace varios años y ahora ha trabajado con éxito en una empresa competidora. Además, a juzgar por los registros, descargaba casi toda la base de clientes al menos una vez al mes.

La cuenta fue bloqueada de inmediato y comenzaron a observar cómo una persona podía eludir las regulaciones internas. Resultó que Vasily primero obtuvo acceso al portal como gerente de ventas, y luego se transfirió a un puesto directivo directamente en el taller, después de lo cual renunció. Pero la lista de verificación para el despido en el taller es completamente diferente y la desactivación de la cuenta del portal no figuraba allí. Aunque, parecería, hacer una lista de verificación general para el control de acceso en todos los sistemas y el problema podría evitarse.

reglas


  1. Si tiene más de 100 empleados, considere introducir un sistema IDM completo.
  2. Descarte los datos no de la hoja de derivación, sino directamente del departamento de personal. Los despidos son diferentes y una solución alternativa puede no traerlo.
  3. — . . , « , », , ( , , . .).
  4. « », - .
  5. . .
  6. . , — . .

?


Por alguna razón, la seguridad de la información se percibe tradicionalmente como personas hostiles que persiguen a todos con sus aburridas regulaciones e interfieren con su trabajo. De hecho, para todos los ejemplos grotescos anteriores, a menudo se encuentran en casos reales, y son los guardias de seguridad y los administradores paranoicos los que ayudan a evitarlos.

Solo trata de encontrar un idioma común. En primer lugar, los propios empleados de IS no deberían convertirse en vigilantes que solo se dedican a hacer del cerebro una política de contraseña regular sin explicación. El enfoque correcto es reunirse con desarrolladores y desarrolladores, sumergirse en sus problemas. Luego, desarrolle la opción de compromiso correcta, que no solo brillará con acceso sin contraseña al mundo exterior, sino que será conveniente de usar.

Y los devops quieren ser a veces al menos un poco paranoicos.
El texto fue preparado por Vladimir Chikin, Jefe de Tecnología de la Información en Technoserv Cloud .

All Articles