201105GT117201105GT117https://colaboraeducacion30.juntadeandalucia.es/educacion/colabora/web/201105gt117/inicio/-/blogs/rss2024-03-28T16:25:10Z2024-03-28T16:25:10ZAnálisis de cortafuegosJosé Miguel Sánchez Aléshttps://colaboraeducacion30.juntadeandalucia.es/educacion/colabora/web/201105gt117/inicio/-/blogs/analisis-de-c2020-02-11T10:18:27Z2020-02-11T10:08:00Z<p>Como me propuse, ya que he acabado de estudiar el estado actual del cortafuegos en <em>Linux</em>, y el estudio nos puede servir de base para implementar la seguridad en <em>Cerbero</em> y <em>Tormenta</em>. El estudio lo he documentado en <a href="https://sio2sio2.github.io/doc-linux/08.redes/07.cortafuegos/index.html">el epígrafe correspondiente del manual sobre Linux</a>.</p> <p>Aprovecho la entrada en el <em>blog</em> para hacer un resumen de nuestras necesidades y las conclusiones del estudio.</p> <h3>Necesidades</h3> <dl> <dt><strong>Cerbero</strong></dt> <dd>Fiscalizar la red y servir de pasarela de acceso al servidor de contenidos de la red TIC. Lo primero exige reglas de filtrado de paquetes más o menos triviales y lo segundo algunas técnicas no tan trivales de traducción de direcciones de red (NAT). El <em>firmware</em> de Cerbero incluye una versión modificada de <em>Debian</em> con el clásico <strong>xtables</strong>.</dd> <dt><strong>Tormenta</strong></dt> <dd>Asegurar el acceso y, sobre todo, inutilizar los ataques de fuerza bruta sobre el servicio SSH. En esta máquina instalaremos la última versión de <em>Debian</em> que, en principio, usa el nuevo <strong>nftables</strong>.</dd> </dl> <h3>Estudio y conclusiones</h3> En <em>Linux</em> conviven ahora mismo dos aplicaciones de cortafuegos: el ya casi jubilado <strong>xtables</strong> y su sustituto <strong>nftables</strong>. Tenemos necesidad de usar ambos, porque <em>Cerbero</em> requiere el primero; y <em>Tormenta</em>, el segundo. <dl> <dt><strong>Cerbero</strong></dt> <dd>Requerirá hacer las mismas funciones que hacía <strong>zipi</strong>. Como ambos utilizan el mismo cortafuegos (<strong>xtables</strong>), no debería haber problemas más allá de que para algunas operaciones haya que recurrir directamente a <strong>xtables</strong>, porque la interfaz CLI del <em>firmware</em> del router, no permita definir algunas de las reglas más extravagantes de NAT.</dd> <dt><strong>Tormenta</strong></dt> <dd>Las reglas para controlar su acceso son bastante triviales, excepto aquellas que se usen para impedir los ataques de fuerza bruta. Con <strong>iptables</strong> la defensa contra estos ataques es <a href="http://ipset.netfilter.org/iptables-extensions.man.html#lbBW">el módulo recent</a>, pero en <strong>nftables</strong> no existe tal módulo. Sin embargo, se puede implementar una solución que funciona de manera muy parecida con <a href="https://sio2sio2.github.io/doc-linux/08.redes/99.ataques/02.tecnicas/03.brute.html#nftables-bruta">limit y meters</a>. Eso evita tener que recurrir a <a href="https://sio2sio2.github.io/doc-linux/08.redes/99.ataques/02.tecnicas/03.brute.html#fail2ban">fail2ban</a>.</dd> </dl>José Miguel Sánchez Alés2020-02-11T10:08:00ZPuesta en marcha del SERVIDOR de CLONACIONES.José Pazos Reyeshttps://colaboraeducacion30.juntadeandalucia.es/educacion/colabora/web/201105gt117/inicio/-/blogs/puesta-en-marcha-del-servidor-de-clonaciones-2020-02-17T21:22:03Z2020-02-10T20:53:00Z<p>Durante el proceso de pruebas del Sistema de clonaciones de las imágenes se desarrollan las siguientes actividades:</p> <ol> <li>Se monta una red en el taller con un <strong>router </strong>con el servicio <strong>DHCP</strong> configurado que posibilitará la asignación de IPs a los equipos conectados.</li> <li>Se prepara una máquina para emular al <strong>Servidor de Clonaciones</strong> donde se instala una distribución Debian Linux con los servicios TFTP, HTTP, SSH y NFS.</li> <li>Se instala la <strong>aplicación 'clonaton'</strong> en dicho equipo y</li> <li>Se conectan a la red varios equipos clientes para: <ul> <li>Crear una imagen del disco duro almacenándola en el Servidor en pruebas.</li> <li>Restaurar dicha imagen en una (UNICAST) o en varias máquinas simultaneamente (MULTICAST).</li> <li>Por último se realizan más pruebas sobre el funcionamiento del sistema en equipos con BIOS UEFI, detectándose los siguientes problemas: <ul> <li>No funciona la detención del menú del servicio PXE al pulsar la tecla de fijación de mayúsculas.</li> <li>Incompatibilidad de funcionamiento con BIOS UEFI en equipos más antiguos.</li> </ul> </li> </ul> </li> </ol> <h4> WOL - WAKE ON LAN.</h4> <p style="text-align: justify;">Como el servidor de clonaciones se va a usar muy puntualmente (a finales o principios de curso principalmente) va a permanecer apagado en su ubicación, aún por determinar. Dado que las clonaciones van a ser lanzadas desde cualquiera de las aulas técnicas con equipamiento informático, se contempla la conveniencia de encender el equipo en remoto desde cualquier lugar del Centro. Esto implica la activación de Wake On Lan (WOL) en nuestro servidor.</p> <p style="text-align: justify;">Para probar su correcto funcionamiento, se conecta un equipo a la troncal de la Red actual del Instituto y se lanza el magic packet tras instalar el <strong>paquete wakeonlan</strong> de Debian. La prueba es exitosa y la BIOS enciende la máquina en todos los intentos realizados.</p> <h4 style="text-align: justify;">Tareas Pendientes.</h4> <ul> <li>Comprar el hardware necesario para la implantación definitiva del sistema: un equipo por piezas de prestaciones simples pero con dos discos reflejados en espejo.</li> <li>Determinar la ubicación final de este equipo dentro de la red. En principio las propuestas son el propio departamento de Informática o el pequeño Centro de Proceso de Datos donde se encuentra instalado el Servidor TIC.</li> </ul> <p style="text-align: justify;"> </p>José Pazos Reyes2020-02-10T20:53:00ZReunión del 31 de eneroJosé Miguel Sánchez Aléshttps://colaboraeducacion30.juntadeandalucia.es/educacion/colabora/web/201105gt117/inicio/-/blogs/eunion-del-31-de-enero2020-02-03T06:28:39Z2020-02-03T06:10:00Z<p>Saludos a todos:</p> <p>En la reunión del viernes 31 de enero de 2020, debatimos y acordamos los siguientes puntos:</p> <ol> <li>Bautizar a las tres máquina de red como <strong>Cerbero</strong> (router ubiquiti), <strong>Tormenta</strong> ()servidor VPS( y <strong>Dolly</strong> (servidor de clonaciones).</li> <li><strong>Jesús Fernández</strong> expuso cómo habían ido suspesquisas de <em>plugins</em> de <strong>Worpress</strong> para simular un explorador de archivos; y que uno parecía apropiado puesto que habilitaba permisos de usuario. El <em>plugin,</em> no obstante, cuesta 15 euros con un soporte de seis meses, de modo que se dejará para más adelante su compra..</li> <li><strong>José Pazos</strong> informó de que del estudio sobre el servidor de clonación (<strong>Dolly</strong>) sólo resta comprobar el <em>Wake on LAN</em>.</li> <li><strong>José Miguel</strong> informa de que el estudio del nuevo cortafuegos de Linux (<strong>nftables</strong>) , necesario en <strong>Tormenta</strong>, está casi ya listo.</li> <li><strong>Francisco Navas</strong> comenzará en breve a estudiar la red actual a fin de tener más elementos de juicio cuando se decida donde ubicar <strong>Cerbero</strong>.</li> <li><strong>El coordinador</strong> pide que las conclusiones sobre los asuntos que se estudien se viertan como entradas en el blog.</li> </ol> <p>Y sin más asunto de interés, se levantó la sesión.</p>José Miguel Sánchez Alés2020-02-03T06:10:00Z