¿Qué revisar en un equipo antes de su puesta en servicio?

Una vez instalados los sistemas sobre los que se va a correr algún tipo de servicio (servidor de archivos, FTP, impresoras, WEB, aplicaciones…) comienza, o al menos debería, una fase de, podríamos decir, puesta a punto. Creo que es indiferente que vaya a ser un sistema expuesto a internet o bien uno interno, debería ser un paso obligado cuando se va a instalar un servidor. La típica excusa de “es un entorno de test, pruebas o desarrollo…” Eso no debe valer, ya que se prueba lo que sea sin las medidas de seguridad oportunas y cuando sube a producción de repente no funciona nada y, claro, hay prisa y no se puede esperar a realizar un buen bastionado del equipo. Seguro que sabéis de lo que hablo.

Voy a tratar de ser muy genérico, en el sentido que estos puntos sean válidos sea cual sea el servicio expuesto o la plataforma sobre la que esté instalado (Windows, Linux, *nix…). Comencemos por acciones que se pueden llevar directamente al equipo, con configuraciones propias de la tecnología  elegida, sin necesidad de ninguna aplicación de terceros:

  • Que el software que se use esté actualizado, tanto el SSOO como las aplicaciones que soporten el servicio. En la actualidad, y salvo casos concretos, no debería ser demasiado complicado llevarlo a cabo.
  • Verificar permisos con que se ejecutan los servicios, que la regla del mínimo privilegio prevalezca. Si en algún momento una aplicación se ve comprometida, que quien la explote tenga el menor privilegio posible a la hora de ejecutar comandos.
  • Asegurar una política de contraseñas fuerte. Ya comenté aquí algunas ideas a tener en cuenta a este respecto.
  • Ocultar la información que pueda exponer información no deseada. Cambiar el banner por defecto de bienvenida, personalizar páginas de error… Para que no muestren rutas internas, fabricante, versiones de software…
  • Eliminar todos los servicios y aplicaciones que no sean útiles. Mejor reducir la superficie de ataque al mínimo indispensable.
  • Habilitar logs específicos de auditoría. En caso de problemas, darán información útil para poder diagnosticar los motivos.
  • Aplicar permisos concretos a ficheros específicos, por ejemplo de configuración, logs… que restringa lo máximo su manipulación (lectura, modificación, borrado…)

Otras actividades que se pueden llevar a cabo, añadiendo algún software pueden ser:

  • Instalar un HIDS (Host Intrusion Detection System) que se alerte de la modificación de ficheros importantes del sistema.
  • Una solución SIEM siempre es de gran ayuda la hora de no perdernos por las miles de líneas de logs, en este caso no sería sólo de un equipo concreto, sino de todo el entorno en el que se encuentra.

 Si creéis que se puede completar, sois libres de dejar vuestros comentarios.

Hasta la próxima 🙂

Anuncios

La seguridad debe ser transparente al usuario

Hace un tiempo leí el siguiente artículo en que el autor se pregunta donde está el Steve Jobs del mundo de la seguridad, desde entonces tengo pendiente escribir sobre esto. Cada vez se avanza más en las soluciones de seguridad en general, haciéndolas amigables y, a veces, transparentes para el usuario, pero habrá que seguir trabajando en ello, porque creo que la clave está ahí, en que él no sepa que es lo que se hace por debajo. Queda bien eso de implementar productos simples, fáciles de usar, con unas características que lo hacen muy seguro, pero la clave está en la transparencia. Hay que hacer que para el usuario la palabra cifrado, actualizaciones de seguridad (especifico seguridad porque para añadir nuevas pantallas a un juego y cosas de ese tipo no tienen problema en aprenderlo), bastionado de equipos, firewall, apertura de puertos… Sigan siendo conceptos que no entiendan, pero sí que sean tecnologías que usan a diario sin saberlo.

Las actualizaciones automáticas de los SSOO fueron un primer paso, los AV, casi todos los navegadores dan la opción de hacerlo en la actualidad, sus plugins también empiezan a hacerlo, y así nuevos programas se van uniendo, todo sin que el usuario tenga que hacer nada. Cuando hay un parche o nueva funcionalidad, la aplicación lo baja y en el siguiente reinicio lo aplica y listo. La activación por defecto del firewall de Windows XP SP2 fue un gran acierto. El que quería abrir puertos para juegos u otras aplicaciones se molestaba en averiguar como, pero la mayoría de la gente estaba más protegida sin saberlo, y ni falta que hizo.

Está la opción se seguir con la concienciación del usuario, pero no parece que los resultados sean los esperados. Ya lo comentó hace poco David Barroso en su blog y los comentarios de Juan Garrido o José Selvi, entre otros, son de obligada lectura. Como es lógico, no se puede eliminar al usuario de la ecuación, pero sí delegar lo menos posible en él, siempre que pueda haber una solución técnica que lo proteja, aunque no lo sepa.

Saludos

RootedCON

Comienza el congreso de seguridad madrileño por excelencia, la RootedCON… Este será el tercer año que podremos disfrutar de esta reunión de profesionales de seguridad en Madrid. He asistido a los dos anteriores, y la experiencia siempre ha sido muy buena, tanto en nivel técnico (mejorando cada año) como por la oportunidad de conocer gente que trabaja en el sector de la seguridad en este país, cuyo nivel es realmente bueno, nada que envidiar a nadie.

Yo ya me he registrado ¿Y tú? Si ya has asistido a alguno de los dos anteriores, seguro que ya habrás hecho hueco en la agenda para esta tercera edición, si no, deberías probar.

Toda la información aqui.

Nos vemos allí. 🙂

Lista de verificación de seguridad.

Estaba preparando una lista para valorar de forma relativamente rápida la seguridad de un sistema y, en función del problema, explicar cómo solucionarlo. Pues bien, cómo no, no he sido el primero en pensar en ello, y navegando por ahí o a través de twitter (no me acuerdo), he encontrado alguien que ya lo había hecho previamente, así que, os dejo el enlace.

Está bastante completa, y, aunque principalmente se refiere a SSOO Windows, es perfectamente válida para cualquier otro sistema.

Hasta la próxima 🙂

Securizar MacOS X II

En el anterior artículo, comenté la utilidad Filevault, para cifrar el contenido que cada uno crea conveniente y que yo no lo usaba… ¿Por qué? Sencillo, porque suelo trabajar en diferentes entornos y plataformas, Windows, Linux (diferentes “sabores”) y MAC. Filevault sólo trabaja sobre MacOS X. Uso Truecrypt porque puedo tener acceso a mis contenedores cifrados en todo momento desde mi unidad externa.

Os dejo un enlace de la wikipedia en el que se ven diferentes soluciones de cifrado para varios SSOO, cada uno puede elegir la que mejor que convenga o se adapte a sus necesidades.

Tenemos también la opción de borrar de forma segura, por defecto, todo lo que tiremos a la papelera. Pero hay que tener en cuenta que el proceso de borrado toma bastante más tiempo.

Un enlace muy interesante es este de la comunidad de DragonJar. No voy a repetir aquí todo lo que en ese artículo se dice, ya que está muy bien explicado. Habla de diversas herramientas como Prey, iAlertU, DynDNSUpdater, LogMeIn que son de mucha utilidad. Algunas cosas de las que comenta, contradicen un poco lo que anteriormente había escrito, en la primera parte, no he querido modificar nada ya que el documento lo descubrí después y así yo mismo me doy cuenta de que me podría haber pasado lo mismo. Siempre es bueno leer algo que te hace ver otro punto de vista 🙂

Por último, quería comentar la herramienta WaterRoof, pero debido a mi limitada capacidad para expresar lo que quiero, o la poca experiencia que tengo escribiendo artículos, soy incapaz de explicarlo como mandan los cánones, así que he decidido dejar waterroof para un artículo para él solito y hablar brevemente de su hermano noobroof. Las diferencias entre ellos las podéis ver aqui, pero básicamente el segundo es mucho más fácil de usar para gente menos relacionada con las comunicaciones, sockets, puertos y demás.

Hasta la próxima 🙂

Securizar MacOS X (Parte 1)

Como reciente poseedor de un flamante Macbook Pro, explico los pasos que he seguido para que sea un poco más seguro, todo a nivel de SSOO, con opciones o aplicaciones que vienen con nuestro equipo nada más adquirirlo.

  • Usar siempre una cuenta de usuario sin privilegios, usemos la de administración sólo cuando sea necesario. Será bueno también deshabilitar las cuentas por defecto (invitado).
Cuenta de usuario
  •  En las opciones de arranque, deshabilitamos el inicio de sesión automático, y para la autenticación, introducimos nombre de usuario y contraseña.
Opciones de arranque
  • Configurar la búsqueda de actualizaciones del sistema diariamente. Para sistemas no conectados a internet, se pueden descargar desde aquí. Se puede comprobar que lo que se descarga es realmente lo que dice, comprobando el hash asociado al fichero con el comando /usr/bin/openssl sha1 <fichero descargado>
Buscar actualizaciones
  • En la opción de seguridad en las preferencias del sistema, tenemos varias opciones. En la pestaña General son muy claras, no necesitan explicación. Filevault es una utilidad de MacOS para el cifrado del directorio /home del usuario y sus ficheros. Yo personalmente no lo uso, ya os explicaré el porqué, en la segunda parte de este artículo. Por último tenemos el Firewall, IMPRESCINDIBLE tenerlo habilitado. En las opciones avanzadas se puede dar permiso a aplicaciones para que admitan conexiones externas. Para gestionar de una manera mucho más profunda el firewall, una magnífica interfaz la proporciona WaterRoof, hablaremos de él en otro artículo, ya que en verdad no usa el firewall de aplicación, que es el que se muestra ahora, sino el ipfw 😉
Seguridad – General
Seguridad – Filevault
Seguridad – Firewall
Seguridad – Firewall 1
  • Deshabilitar todos los servicios no vitales o necesarios para el uso del equipo. Se pueden encontrar en el directorio /System/Library/LaunchDaemons. Para hacerlo se ejecutará el comando sudo launchctl unload -w <ruta completa al servicio y su nombre>. En la siguiente tabla se puede ver el nombre del servicio y a qué función corresponde. La segunda tabla se corresponde con los agentes de algunas aplicaciones, lo único que cambia es la ruta /System/Library/LaunchAgents
Servicios 1
Servicios 2
  • Deshabilitar SetUID y SetGID. El bit SetUID es necesario para que algunos programas del sistema puedan realizar la tarea que les corresponde. Bugs en este tipo de aplicaciones pueden originar una escalada de privilegios en el sistema, por lo que donde no es estrictamente necesario, mejor tenerlo deshabilitado. En mi caso concreto, no lo tengo activo en el ping (primera captura). Se puede comprobar tecleando en el terminal ls -l /sbin/ping. La diferencia es la s en el campo de permisos (segunda captura), que indica que está efectivamente activo. Hay aproximadamente unos 75 programas en Snow Leopard con ese bit activo. Por lo general es necesario para su correcto funcionamiento, pero en ocasiones, no es necesario para nuestro uso particular del equipo, por lo que mejor deshabilitarlo. Para encontrar los programas se puede teclear en un terminal find / -perm -04000 -ls (SetUID) y find / -perm -02000 -ls (SetGID). Para deshabilitar el bit se debe usar lo siguiente chmod ug-s <nombre del programa>. Como en el anterior punto, tenéis una tabla con los programas y su función, para que decidáis si es necesario o no tenerlo.
Captura 1
Captura 2
SetUID 1
SetUID 2
  • Si no se están usando, mejor deshabilitar los servicios de redes inalámbricas y bluetooth, para incrementar la duración de la batería por un lado, y evitar su uso no autorizado por otro. Si se quieren deshabilitar de forma definitiva, se pueden borrar (o renombrar) los siguientes ficheros del directorio /System/Library/Extensions/IOBluetoothFamily.kext y IOBluetoothHIDDriver.kext para el Bluetooth y IO80211Family.kext para la red inalámbrica.
  • Al igual que con los servicios anteriores se puede actuar con el iSight y el micrófono interno del equipo. Para el primero, la mejor forma de evitar que algunos programas hagan uso de la cámara es renombrar o borrar el fichero /System/Library/Quicktime/QuicktimeUSBVDCDigitalizer.component. Para el micrófono, siempre se puede bajar el volumen a cero en las propiedades del dispositivo, borraremos o renombraremos el fichero IOAudioFamily.kext en el directorio /System/Library/Extensions.
  • En lo que respecta al navegador por defecto de MacOS, Safari, evitaremos que se abran los ficheros nada más ser descargados, en la pestaña general, e indicaremos que no se guarde el historial más de un día, es lo mínimo que nos permite el navegador para hacerlo de forma automática (increíble que considere seguros todos esos tipos de ficheros :-|). En la de Seguridad, deshabilitaremos la ejecución de código Java, disminuyendo las posibilidades de ataque. Deshabilitar Javascript también es una buena opción, pero se debe ser consciente de que la gran mayoría de páginas WEB no funcionarán de forma correcta
Safari 1
Safari 2
  • Bonjour, es un protocolo para el descubrimiento de servicios en la red. Aunque útil en algunos casos, desde la perspectiva de la seguridad hace el equipo visible en la red, generando tráfico no necesario en la red. Para deshabilitar los mensajes multicast se ejecutará el siguiente comando: sudo defaults write /System/Library/DaemonsLaunch/com.apple.mDNSResponderProgramArguments -array-add “-NoMulticastAdvertisements”.
  • Continuemos deshabilitando servicios, como por ejemplo, el de compartir ficheros, impresoras, acceso remoto…
Servicios 3
  • Otra herramienta por defecto que viene con el sistema operativo es iTunes, como gestor de ficheros multimedia. Vamos a deshabilitar el servicio de compartir de la aplicación, que nos puede dar algún que otro disgusto.
iTunes

Esto es todo por ahora, en la siguiente parte hablaremos más, comentando alguna opción más dada por el propio SSOO y metiéndonos en algunas aplicaciones que nos ayudarán a que nuestro equipo sea algo más seguro.

Para la redacción de este artículo me he basado principalmente en la Guía de seguridad de Snow Leopard de Apple y unos consejos publicados por la NSA Hardering Tips for Mac OS X 10.6 Snow Leopard.

Hasta la próxima 🙂

Anécdota con proxy

Llego un buen día a la oficina de un cliente, contento, con una sonrisa, para empezar bien el día, como dice por ahí un anuncio de la tele, como si hubiera tomado mi dosis de fibra 🙂 Estoy desplazado allí por una implantación por un tiempo determinado.

Me siento en el sitio asignado, enciendo el equipo portátil. Mientras inicia, reviso las notas del día anterior, me autentico en el dominio, se carga el escritorio, todo normal, como siempre. Abro el correo, reviso tareas, contesto lo urgente que no necesito consultar información extra, una mañana cualquiera en el cliente, salvo por el momento en que voy a conectarme a internet.

Abro el navegador, Firefox en este caso, y el mensaje de autenticación del proxy es diferente, me dice la marca.

No es que sea el fin del mundo, pero me extraño, ya que no es el comportamiento habitual, y pruebo con otro navegador, toca Chrome

¡¡Vaya, lo mismo!! Pruebo otro, el IE y aquí es cuando viene la sorpresa soberana:

No sólo me dice la marca y el modelo del proxy, si no que además me advierte de que la comunicación (usuario y contraseña) no será segura.

No puede ser, tengo que probarlo, así que ni corto ni perezoso, tiro de wireshark y pruebo de nuevo esnifando un poco de tráfico… ¡Quién me mandaría!

No, no estaba en la empresa para hacer ninguna auditoría de seguridad. Pero es que vaya chapuzilla.

Abro una incidencia en el sistema, y lo mejor fue la respuesta. “No está permitido el uso de sniffers en la red corporativa” 😮