Antes de nada, debo pedir disculpas a todos los lectores, llevo varios meses muy centrado en otros temas y lo cierto es que no he encontrado momento ni temas suficientes como para escribir con la frecuencia y el tiempo que me gustaría. Suelo aprovechar alguna noticia importante del mundo de la VoIP y/o del software libre para hacer algún comentario y hablar sobre algún tema que considero de interés, no obstante llevo varios meses con bastante lío encima de la cabeza y salvo los productos interesantes que me hacen llegar la gente de Snom y la gente de InstantByte (menos mal), apenas encuentro un momento tranquilo para sentarme a pensar sobre qué me gustaría escribir.
Entre otros temas que me trae de cabeza, es algo sobre lo que llevamos (mis compañeros y yo) algunos meses tramando… y es sobre cómo conseguir ser una «empresa segura«. Algo que daría para muchos, muchos artículos y sobre lo que está todo escrito y no se escriben otras muchas cosas para no dar pistas a los «malvados», pero sí que es cierto que llevamos muchos meses preparando el terreno para asegurar técnicamente, todo lo posible, la información con la que trabajamos todos los días.
No es que tengamos los códigos nucleares, ni los códigos de acceso a los búnkeres de seguridad nacional, pero sí que al tratar y manejar datos privados de clientes y visto lo visto en cuanto a ataques, vulnerabilidades y demás… hemos considerado interesante buscar la forma de ponérselo un poco más difícil a los malvados juankers y hacer todo lo posible para que los datos de los clientes estén a buen recaudo.
Está claro que si los hackers han entrado en Telefónica, en Iberdrola, en Endesa, en la DGT, en varios ministerios y en un sinfín de empresas muy preparadas, nada me asegura que haga lo que haga no vayan a conseguir lo mismo. Es extremadamente difícil asegurar una empresa y los datos que maneja, pero sobre todo, quizá lo más difícil es llegar a cruzar la línea de la paranoia sin que realmente uno se vuelva paranoico.
Para conseguir dar el paso para ser una «empresa segura», hemos optado por realizar varias fases:
- Fase 1: Sentido común
Esto es… si yo conociera los puntos flacos de la empresa ¿Cómo lo haría para atacarla? ¿Qué necesitaría? En esta fase eliminamos los puntos de seguridad por ocultación y nos centramos en asegurar de verdad. - Fase 2: Seguridad exterior
Preparamos todo lo necesario para evitar ataques provenientes del exterior: bots, personas externas, vulnerabilidades en servicios expuestos, etc…. aquí nuestro amigo el firewall, junto con nuestros amigos «direcciones IP estáticas» van a ser nuestros mejores aliados. - Fase 3: Seguridad interior
Ahora le toca la parte de ¿y si el enemigo está en casa? Paranoia máxima… un cable no controlado, una red wireless vulnerable, un acceso remoto no configurado y el enemigo ya está dentro… ¿qué hacer entonces?
Una vez planificado estos puntos, toca la parte más difícil… plantearse un reto, un reto de verdad, uno que cueste dinero y así asegurarnos que no se quede en agua de borrajas:
- Obtener un certificado de Calidad y Seguridad a nivel internacional, debería ser una forma como otra cualquiera que nos garantice que los cambios que hacemos son suficientes como para prevenir y curar con garantías cualquier problema de seguridad que pueda plantearse en un hipotético caso. Por suerte (y veremos que también por desgracia), la empresa nunca ha tenido un problema de seguridad más allá de algún ssh expuesto accidentalmente y varios intentos de ataque, y eso es, sin duda, gracias a mis compañeros presentes y pasados, que de una forma u otra «blindaron» la infraestructura para evitar sustos que pudieran considerarse serios.
Claro que desde entonces hasta ahora ha llovido bastante y la tecnología y la seguridad ha evolucionado tanto que hoy día, un chaval de 17 años puede hacer estragos con unas pocas ganas de tocar las narices, así que buscamos un certificado internacional de seguridad y nos hemos tirado a por él. Contratada una consultora que nos guíe en los distintos pasos que hay que seguir y ponernos en sus manos en cuanto al asesoramiento sobre qué debemos mirar.
Somos conscientes que el 70% de los certificados son documentación y protocolos más que temas técnicos que nos puedan ayudar a proteger la información que almacenamos. No obstante, los requisitos para que, asegurar la información de una empresa no se quede simplemente en buenas intenciones, implica ponerse en serio y sacar las certificaciones, a ser posible en un tiempo record.
Hay muchas certificaciones:
- ISO27001 (el certificado de seguridad por excelencia, entre 97 y 114 puntos de control que hay que asegurar) Documentación por un tubo y cada uno de ellos con sus «necesito una evidencia de lo que dices» que te volverá loco. Hay que renovar cada 3 años.
- ENS (el certificado de seguridad nacional) un certificado que nació para que lo cumplieran los ayuntamientos, universidades y administraciones públicas y al final han terminado obligando a cumplirlo a todos aquellos que quieren trabajar con las AAPP. Reune más requisitos técnicos que la ISO27001 (porque sólo permiten cierto hardware y software homologado para AAPP, pero que ya sea de paso, también para todo aquella empresa que quiera sacarse el certificado). Hay tres tipos de ENS: simple, medio y alto. (lo bueno es que toda la información es pública: https://www.ccn-cert.cni.es/es/guias.html). Hay que renovar cada 2 años.
- NIS2 (el certificado de seguridad europea) un certificado de ciberseguridad a nivel europeo similar a los puntos de la ISO27001, pero con una organización algo más laxa.
¿Qué hay que proteger?
Para empezar a ser una empresa segura, lo primero es preguntarse, ¿qué tenemos que haya que proteger? ¿qué tienes?, ¿de dónde sale?, ¿quién es el responsable?, ¿cómo se genera?, ¿quién lo utiliza?, ¿quién lo borra?, y un largo etcétera.
En nuestras empresas hay mucha información relevante e importante: grabaciones, listados de llamadas, números de clientes, agendas, usuarios/contraseñas, etc. Si tienes CRM o ERP, la cosa se vuelve más peliaguda, ya que tienes información más confidencial de la empresa del cliente y si almacenas datos de identificaciones como CIF, nombres y direcciones, se considera que tienes datos confidenciales de nivel 2 y toca proteger la información sí o sí, bien cifrándola, bien poniéndole todas las barreras posibles para evitar que nos lo roben, la vendan, etc.
Sabiendo la información, material o cosas que hay que proteger, el siguiente paso no es más que algo evidente: ¿qué podría pasar si no se protege?
¿Qué podría pasar si no se protege?
Imagina que borran estos datos, o que un día entras en la oficina y desaparecen los servidores, o que hay una manifestación y nadie puede entrar en la oficina o que han desaparecido todos los servidores principales por un fallo en el datacenter, o que… 1000 situaciones catastróficas que se te puedan ocurrir, desde las más elementales (que entre alguien a un sistema) como las más insospechadas (que alguien con información confidencial se vaya de mal rollo de la empresa).
No es agradable ponerse en esta situación, pero es otro paso necesario. Controlar qué cosas pueden ocurrir, la probabilidad de que ocurra, y qué habría que hacer en este caso.
Backup y protocolos anti-desastres
No hay duda que tener una copia de seguridad siguiendo la regla del 3-2-1 (La norma establece que debes tener al menos tres copias de tus datos; dos de las copias de seguridad deben estar almacenadas en diferentes tipos de medios, y al menos una copia de seguridad debe estar almacenada fuera del sitio o en la nube) es algo fundamental. No siempre es posible, pero hay que buscarlo siempre que se pueda. Siempre puede, por muchas garantías que te digan, fallar algún sistema crítico y haya que recuperar cuanto antes.
O ponerse en lo peor y pensar que todo se puede ir al traste en una mañana… en ese caso, toca preparar un protocolo anti-desastres que ayude a mantener la calma y recomponerse tan rápido como sea posible. Las posibilidades son casi infinitas, pero las probabilidades no son tan bajas como nos gustarían y estar preparado ante lo insospechado es un plus.
Con esto, explicado de una forma rápida y sutil como una conversación de cafetería, tendríamos la parte vital de recomponernos si algo va mal. Ahora empezamos con la parte «divertida».
Evitar el ataque
En este caso, hay que activar algo que siempre he odiado: el modo paranoico. De hecho en Sinologic no escribía sobre seguridad porque no quería despertar al «paranoico» que llevamos en nuestro interior. Se vive mejor y mucho más feliz siendo «hormiguitas» en la que nadie se fija ni siquiera para atacarnos, pero es verdad que hoy día los bots ya no miran sólo a empresas grandes, miran a cualquier empresa o cualquier ordenador que haya conectado y sea vulnerable y la mejor forma de evitar quedarte sin empresa o sin servicio, es evitando el ataque.
Para evitar el ataque, lo primero es ver qué infraestructura tenemos, cómo está expuesta y por qué está expuesta. Evitar la «seguridad por ocultación» es algo vital…
Ejemplo: Proteger el acceso remoto:
El hecho de mover un puerto SSH estándar a uno aleatorio fue útil hace unos años, pero desde que un bot puede escanear la red entera buscando servidores SSH en todo internet buscando puerto a puerto y en cuestión de minutos, hace que tener un puerto SSH expuesto a Internet sea ya un riesgo. No es necesario ni tener una cuenta, basta con que la versión del servidor SSH no sea la última que soluciona una vulnerabilidad, para que haya un exploit que de acceso remoto al bot y avise al «nodo supremo» que tiene una nueva máquina a la que inyectar el software de minado, para que te encuentres minando bitcoin en menos de 10 minutos.
Puedes usar un fail2ban, pero nuevamente, el script detecta la versión al primer intento, por lo que el exploit funcionará en el segundo intento. Fail2ban puede servir, pero no es la panacea (esto último lo he visto con mis ojos). Así que ante la falta de soluciones sólo nos queda una posible solución:
- Tener la distribución completamente actualizada SIEMPRE.
- Cortar todo acceso SSH utilizando el firewall bloqueándolo a la IP desde la que vayamos a conectarnos.
- Usar fail2ban
- Evitar acceso mediante contraseña (siempre utilizar Autentificación mediante Clave Pública)
- Cambiar el puerto estándar (nunca usar el puerto estándar para accesos remotos)
- Jamás permitir acceso directo con el usuario ‘root’. Siempre acceso a usuario local con permisos limitados.
- Monitorizar periódicamente los accesos por ssh.
Sé lo que puedes estar pensando: Desde el momento en que bloqueemos el puerto SSH a una IP ¿por qué hay que hacer todo lo demás? Nadie va a poder acceder al puerto excepto nosotros…
Ahí es donde te equivocas… recuerdo un caso hace algunos años en el que el firewall siempre estaba activo,… hasta que un día alguien tuvo que bajarlo y se olvidó subirlo… en ese caso un fallo manual provocó que el puerto SSH estuviera expuesto. El resto de acciones protegen ante el fallo del anterior.
Acuérdate del IPv6
Y es que muchos sistemas tienen IPv6 aunque se nos olvide, y configuramos el firewall para IPv4, pero para IPv6 el firewall sigue estando accesible. Es más difícil de acceder, porque los escaneos de la red son más limitados, pero aún así, sigue estando accesible si no hemos bloqueado el puerto en ambos sistemas.
El ataque no siempre viene desde fuera
Ahora viene la parte más complicada, y es que una gran parte de los ataques no vienen desde el exterior, si no del interior. Acuérdate de cuando en Mr.Robot, el protagonista metió un USB en la empresa con un virus y un empleado de la empresa lo metió en su ordenador para ver qué contenía e infectándose. Ya no es únicamente una serie de televisión, hay cientos de miles de pendrive con virus sueltos por las calles a la espera de que alguien se lo lleve y vea qué contiene.
Linux no siempre es invulnerable
Donde trabajo, prácticamente todos usamos Linux (el 95%) tanto en servidores como en puestos de trabajo, por lo que la parte de virus, troyanos, malware y demás… digamos que estábamos bastante tranquilos. Hasta que un compañero estuvo investigando acerca de OSSEC, una herramienta software libre que analiza el software instalado en cada sistema, revisa versiones y compara con una base de datos de vulnerabilidades. En ese momento empezamos a recibir una cantidad curiosa de alertas sobre versiones de paquetes vulnerables por no estar convenientemente actualizados. Es curioso como puedes pasar de la tranquilidad de saber que todos trabajamos con Linux, a ver un montón de números rojos sobre versiones vulnerables y que toca revisar, actualizar y teñir de verde como sea. (Recordad que estamos haciendo esto para obtener una certificación, y la única manera de hacerlo es que todo sea seguro).
Volviendo a «el ataque no siempre viene desde fuera» viene otra parte cruda, sospechar de cualquier compañero. Esta parte es muy fea, desagradable pero obligatoria, y es que cuando eres una empresa pequeña, hasta la chica que viene a limpiar tiene acceso root a cualquier servidor (vale, si… es una exageración,… xD) pero para obtener el certificado, lo primero que te dicen es: Sólo pueden tener acceso el mínimo número de personas. Eso implica que desarrolladores, personal de soporte, administración y demás que tenían acceso a un servidor «por si las moscas pasaba algo», ahora ya no tenían acceso. Los permisos del CRM y del ERP son revisados y ahora ya no todo el mundo tiene vista de lo que antes sí tenían visibilidad, y eso fastidia, es algo normal… quitar accesos que antes tenías suena a que no se fían de tí, pero lo cierto es que en seguridad, por cada persona que tenga acceso a un sistema, se convierte en un posible agujero de seguridad. Algo que exigen eliminarlo a toda costa salvo que haya un motivo de peso para tenerlo.
Por si fuera poco, dos cosas más que hay que añadir a «obligaciones para tener una red corporativa segura«: vigilancia de la red interna y un control de DLP, aunque sea mínimo.
Vigilancia de la red interna pueden ser muchas cosas, lo importante es que si hay un software haciendo de las suyas en la red interna un martes a las 04:00 a.m. deberías recibir algún tipo de alerta y hacerte las preguntas básicas. ¿porqué el ordenador XXX tiene 2Mb/sec de ancho de banda ocupado a las 4 a.m.? ¿Cómo se detecta este comportamiento extraño? Herramientas hay muchas, libres no tantas.,
DLP (Data Loss Prevention o en español: prevención de pérdida de datos) es el control para evitar una fuga de información por canales estándar, lo que implica disponer de un software de «detección de fuga de información», un aspecto que el Incibe ya nos habla y nos pone en sobreaviso. Ya sea por parte de un compañero, jefe o cargo-intermedio, nadie escapa a una posible «fuga de información» que hay que evitar. Ya no únicamente saber que tendrá consecuencias si ocurre, es que directamente hay que evitar que ocurran, ya que en muchos casos ésta puede ser algo sin querer. Ahí prácticamente no hay ningún sistema libre que permita controlar el DLP tal y como lo piden las empresas certificadoras, así que toca buscar alternativas comerciales. 🙁
Finalizando de forma segura…
Tener una empresa «segura» no es algo fácil, ni barato, ni siquiera cómodo. Siempre he dicho que la seguridad es incómoda, pero necesaria. Puede provocar malentendidos y alguna que otra discusión, pero es mejor discutir que perder los datos de la empresa de la que dependen muchas familias.
Si algo he aprendido estos meses que hemos estado trabajando para aumentar la seguridad de la empresa, es que la sociedad de la información nos ha obligado a los administradores de sistema a volvernos paranoicos. Es un estado necesario para la supervivencia hoy día en la que los datos, las redes de alta velocidad y accesibilidad desde cualquier lugar, se han convertido en la materia prima más importante de esta sociedad. La privacidad vs. la seguridad. ¿Cómo vigilar que es seguro algo que no podemos ver por la defensa de la privacidad? Esto es un debate muy interesante y me encantaría conocer vuestra opinión al respecto.
En fin, espero que este tema llegue a su fin (spoiler: no mucho, porque la seguridad es un estado que requiere revisiones periódicas para comprobar que todo sigue en su sitio) y pueda tener un poco más tiempo para poder escribir más sobre VoIP y Software Libre.
Lo que sí os puedo garantizar es que voy a empezar a escribir sobre esta temática que he evitado tantos años, y es que, otra de las cosas que tengo que hacer es estar al día sobre riesgos, alertas y vulnerabilidades de sistemas que usamos a diario, lo que implica estar vigilante sobre cualquier fallo de seguridad que afecte a nuestras herramientas Asterisk, Kamailio, FreeSwitch, OpenSIPs, etc. o bien a hardware VoIP (teléfonos, gateways, etc.)
