El punto de partida fue algo invisible para el usuario pero bastante crítico por dentro. La forma en que EasyPodcast resolvía las URLs de los episodios era secuencial, con un coste que crece conforme crece la biblioteca. Se añadió un índice en la base de datos y se pasó a una búsqueda logarítmica. En podcasts con muchos episodios, la diferencia se nota de inmediato. De paso, se corrigió un bug con las URLs absolutas que generaba inconsistencias al resolver enlaces.

A mediados de mes llegó la versión 1.5.0 con algo que llevaba tiempo pendiente: el panel de administración ahora habla varios idiomas. Español, inglés, alemán, catalán, gallego, francés, portugués e italiano. El selector está accesible desde el propio panel y desde configuración, y el sistema envuelve todos los textos de la interfaz. Nada de parches a medias.

Pero si hay una versión del mes, esa es la 1.6.0. El editor Markdown desaparece y lo sustituye Jodit, un editor WYSIWYG completo que funciona tanto en episodios como en páginas. Edición visual real, sin necesidad de aprender ninguna sintaxis. Además, el contenido pasa a un campo específico y el feed RSS ahora incluye HTML completo en el campo content:encoded, que es como debe ser. También se introduce un campo de descripción corta pensado para SEO y para listados, separando por fin el resumen del contenido largo.

En esa misma versión, y en la 1.6.1 que vino justo después, llegaron varias cosas más. EasyPodcast ahora tiene una API REST completa que expone episodios, páginas, configuración, redes sociales, estadísticas y caché, con autenticación por Bearer token y documentación integrada en el propio panel. También se añadió un grabador de audio directo desde el navegador, con un detalle importante: si hay errores de validación al guardar, la grabación no se pierde. El 2FA gana la opción de recordar el dispositivo durante siete días, que reduce la fricción sin comprometer la seguridad. Y se añade una herramienta para detectar y eliminar audios e imágenes huérfanos que llevan tiempo ocupando espacio sin que nadie los use. Por último, cuando un episodio no existe, el servidor devuelve un 404 real en lugar de fallar en silencio. Pequeño detalle, gran diferencia para el SEO.

Las versiones 1.6.3 y 1.6.4, ya a finales de mes, se centraron en estabilidad. La grabación de audio ya no se pierde si hay errores de validación, el actualizador en Docker deja de sobrescribir el .htaccess, lo que causaba bucles de redirección HTTPS en setups con reverse proxy, y tras actualizar se muestra el changelog de la versión que acaba de instalarse. Cambios pequeños, pero el tipo de cosas que en producción real marca la diferencia entre un dolor de cabeza y que todo funcione.

Para cerrar el mes, el 28 llegó la 1.7.0 con un sistema de temas visuales. Seis opciones: Default, Agua, Fuego, Invierno, Hacker y Monocromo. Se aplican en servidor, sin JavaScript de por medio, lo que significa que no hay ningún destello al cargar la página. El antiguo modo oscuro basado en localStorage desaparece y lo sustituye este sistema, bastante más sólido y coherente.

En resumen, marzo ha sido menos de funcionalidades aisladas y más de evolución real del producto. Mejor base técnica, mejor experiencia de edición, más control vía API y más personalización visual. EasyPodcast está empezando a comportarse más como una plataforma completa que como una herramienta de publicación simple, y este mes lo deja bastante claro.

De todos modos os paso el contenido:

en robots.txt (para pedirlo educadamente)

# ── Crawlers de IA / LLM ─────────────────────────────────

# OpenAI
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

# Anthropic
User-agent: anthropic-ai
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

# Google IA (Gemini / Bard training)
User-agent: Google-Extended
Disallow: /

# Meta
User-agent: FacebookBot
Disallow: /

# Perplexity
User-agent: PerplexityBot
Disallow: /

# You.com
User-agent: YouBot
Disallow: /

# Common Crawl (usado para entrenar LLMs)
User-agent: CCBot
Disallow: /

# Cohere
User-agent: cohere-ai
Disallow: /

# Diffbot
User-agent: Diffbot
Disallow: /

# ByteDance / TikTok
User-agent: Bytespider
Disallow: /

# Apple
User-agent: Applebot-Extended
Disallow: /

# Otros scrapers conocidos
User-agent: ImagesiftBot
Disallow: /

User-agent: magpie-crawler
Disallow: /

User-agent: DataForSeoBot
Disallow: /

User-agent: AI2Bot
Disallow: /

User-agent: Omgilibot
Disallow: /

User-agent: Timpibot
Disallow: /

User-agent: FriendlyCrawler
Disallow: /

En el .htaccess (para bloquear esos .user-agents)

<IfModule mod_rewrite.c>
RewriteCond %{HTTP_USER_AGENT} (GPTBot|ChatGPT-User|OAI-SearchBot|anthropic-ai|ClaudeBot|Claude-Web|Google-Extended|FacebookBot|PerplexityBot|YouBot|CCBot|cohere-ai|Diffbot|Bytespider|Applebot-Extended|ImagesiftBot|magpie-crawler|DataForSeoBot|AI2Bot|Omgilibot|Timpibot|FriendlyCrawler) [NC]
RewriteRule .* - [F,L]
</IfModule>

Foto de Markus Spiske: https://www.pexels.com/es-es/foto/hombre-policia-uniforme-de-espaldas-4682719/

Aunque mucha gente da por hecho que con HTTPS ya va todo cifrado desde el principio, la realidad es que no era exactamente así. Durante años, en el arranque de la conexión TLS seguían viajando en claro algunos datos bastante sensibles, como por ejemplo el nombre del servidor al que te querías conectar. Es decir, que la conversación luego iba protegida, sí, pero al principio todavía ibas dejando pistas de más.

Ahí es donde entra ECH, que significa Encrypted Client Hello. La idea es cifrar precisamente esa parte sensible del saludo inicial para que no vaya expuesta por la red. Dicho de forma sencilla, es una manera de evitar que en ese primer “hola” entre cliente y servidor se revele información que no debería estar a la vista. Es una mejora importante de privacidad, porque tapa una fuga que llevaba años ahí y que quedaba un poco fea en algo que, en teoría, ya considerábamos seguro.

El mecanismo, además, está bastante bien pensado. ECH separa el saludo en una parte visible y otra cifrada: una especie de sobre por fuera y contenido real por dentro. A eso se suman detalles como el uso de HPKE, que significa Hybrid Public Key Encryption, el padding para que el tamaño de los mensajes no delate información, y técnicas como GREASE, que ayudan a que el tráfico con ECH no destaque demasiado frente al resto. Vamos, que no se limita solo a cifrar, sino que intenta hacerlo bien.

Ahora bien, también conviene decir lo que ECH no hace. No convierte tu conexión en invisible ni arregla toda la privacidad de Internet de golpe. Por ejemplo, si el DNS no va cifrado, sigues dejando pistas importantes por el camino. Y la IP también puede seguir dando bastante contexto. O sea, ECH resuelve una parte muy concreta y muy relevante del problema, pero no borra todo lo demás.

En resumen: ECH no reinventa Internet ni pone todo patas arriba, pero sí corrige una fuga bastante evidente en el arranque de las conexiones TLS. Y solo por eso ya merece la pena prestarle atención, porque era una de esas piezas que faltaban para que la privacidad en HTTPS estuviera un poco más a la altura de lo que la mayoría damos por hecho.

Foto de cottonbro studio: https://www.pexels.com/es-es/foto/oscuro-internet-tecnologia-efecto-desenfocado-5473951/

El problema es que yo uso Linux. Más concretamente KDE Plasma, que es mi escritorio de toda la vida. Y claro, NotchPrompter es solo para Mac.

Solución obvia: portarlo a Linux.

Qué hace

Una ventana sin marcos que se queda siempre encima de todo y va pasando el texto que tú le metas. Sin más. Lo que hace cualquier teleprompter, pero sin que te instale media internet en el proceso.

Cuando acercas el ratón aparece una barrilla con los controles. Cuando lo alejas, desaparece. Puedes cambiar la velocidad, el tamaño del texto, editar el guion al vuelo o cargar un .txt desde disco.

Los colores son del esquema Catppuccin Mocha porque soy así de friki con estas cosas.

Qué no hace

Pues a diferencia de la original para Mac, esta no escucha por donde vas, así que tendrás que estar un poco más atento para regular la velocidad o pausar el texto.

Por qué PyQt6 y no otra cosa

Porque soy usuario de KDE Plasma y quería algo que funcionara bien de verdad, no una app web disfrazada ni dependencias de GNOME. PyQt6 te da acceso directo a Qt, que es lo que usa KDE por debajo. El resultado es una ventana nativa, ligera y que se comporta como debe.

El script instalado pesa 25 KB. Veinticinco kilobytes. Que conste.

Cómo instalarlo

Si tienes Debian o Ubuntu, descarga el .deb de la página de releases y:

sudo apt install ./kdeteleprompter_1.0.1_all.deb

Listo. Las dependencias las gestiona apt solo, no tienes que hacer nada más. Aparece en el lanzador de aplicaciones de KDE y todo.

Si prefieres tirarlo desde el código fuente:

pip install PyQt6
python3 kdeteleprompter.py

Los atajos que molan tener memorizados

┌─────────┬───────────────────────┐
│ Tecla   │     Para qué          │
├─────────┼───────────────────────┤
│ Espacio │     Play / Pausa      │
├─────────┼───────────────────────┤
│ R       │  Volver al principio  │
├─────────┼───────────────────────┤
│ + / -   │ Más o menos velocidad │
├─────────┼───────────────────────┤
│ Ctrl+E  │ Editar el guion       │
├─────────┼───────────────────────┤
│ Escape  │ Cerrar                │
└─────────┴───────────────────────┘

El código está en GitHub, la licencia es MIT porque el código original era MIT y hay que respetar las licencias, es libre, abierto, lo que quieras:

github.com/educollado/KDETeleprompter

Si le ves algo mejorable o te peta en tu máquina, abre un issue y lo miramos.

La idea nació de una pregunta incómoda: ¿quién es el dueño real de tu podcast cuando lo tienes en Anchor, iVoox o Buzzsprout? La respuesta, en la mayoría de los casos, es que ellos tienen tus datos, tu feed y tu contenido. Y pueden cambiar las reglas cuando les dé la gana.

EasyPodcast resuelve eso. Se instala en cualquier hosting básico, genera tu feed RSS automáticamente, te da una web pública con modo oscuro incluido, panel de administración limpio, SEO automático, copias de seguridad con un clic y hasta importación desde otras plataformas. Todo gratis, sin límite de episodios, sin sorpresas.

También os explico lo que EasyPodcast no hace, y por qué. No tiene estadísticas de descargas por capítulo ni datos por usuario. No es una carencia: es una decisión. Creo que la privacidad de quien escucha importa, y no voy a montar un sistema de rastreo para saber quién descarga qué. Punto.

Si buscas independencia, control total sobre tu contenido y respeto hacia tus oyentes, EasyPodcast está hecho para ti. Si necesitas un dashboard con métricas detalladas, hay otras opciones y en el episodio también hablo de ellas con honestidad.

Todo el código está en https://github.com/educollado/EasyPodcast y la web del proyecto en https://www.easypodcast.eu.

Puedes leer la documentación oficial de EasyPodcast en https://www.easypodcast.eu/.

Llevo tiempo dándole vueltas a una cosa: ¿cómo algo tan sencillo como publicar un podcast se ha convertido en una especie de gymkana tecnológica?

La opción fácil es darse de alta en una plataforma, pagar una cuota, aceptar quince pantallas de configuración, conectar servicios que no sabes muy bien para qué sirven… y al final tú solo querías subir un audio y que el RSS funcionase. La otra opción es montarte un WordPress, instalar un plugin enorme, instalar 10.000 dependencias y al final del todo tienes un podcast, pero creo que a veces no es lo que queremos.

Así que un día quería montar un podcast nuevo y no me apetecía ninguna de las dos opciones, y de ahí salió EasyPodcast.

EasyPodcast es un gestor sencillo para publicar podcasts usando PHP y SQLite. Nada de infraestructuras ni de ingeniería aeroespacial, nada de depender de terceros, nada de cosas que no se pueden controlar. Lo mejor: hacérselo uno mismo. Lo subes a tu servidor, lo configuras y te pones a publicar en 5 minutos. Como debería ser. Vamos, que no hace falta pedir audiencia en el Vaticano para sacar un episodio.

Yo quería algo que hiciera estrictamente lo necesario y ni una línea más. Al publicar un episodio, se guarda en SQLite, se actualiza el feed RSS y se muestra en la web pública. Punto.

Uso SQLite porque me parece una maravilla infravalorada. Un archivo y listo. No necesitas montar un servidor de base de datos aparte ni complicarte la vida. Al final son muy pocos datos y realmente no lo necesitas, sobre todo si es un proyecto personal. Pero incluso para algo más serio, SQLite es suficiente.

Si ya tienes un VPS pequeño o tu propio servidor, lo puedes tener funcionando antes de que termine el café.

No pretende competir con plataformas gigantes ni con soluciones empresariales. No es su guerra. EasyPodcast es para quien quiere control, simplicidad y autonomía. Para quien prefiere tener su feed RSS en casa, bajo su dominio, sin que mañana alguien cambie las condiciones y te deje mirando a Cuenca. Que ya nos conocemos.

El panel de administración es limpio y directo. Subes el audio, rellenas los datos del episodio y a correr. No hay tutorial de 40 minutos en YouTube para entenderlo. Si sabes usar un formulario web, sabes usar EasyPodcast. Y si sabes algo de PHP, además puedes abrir el código y entender qué está pasando. Sin magia negra.

Con el tiempo le he ido añadiendo las cosas que de verdad hacen falta. Las descripciones de los episodios se escriben en Markdown con vista previa en tiempo real, porque escribir en un textarea pelado en 2025 no tiene ningún sentido. Al subir un MP3, escribe automáticamente los metadatos ID3, incluida la portada, para que el episodio llegue bien presentado a cualquier app de podcast. Hay sitemap, Open Graph y datos estructurados JSON-LD, porque si publicas algo, que al menos Google se entere. Y hay un sistema de copias de seguridad integrado para exportar e importar la base de datos y los ficheros, que uno no quiere depender solo de que el servidor no se muera. Por si acaso.

A partir de la versión 0.7 también tiene modo oscuro, que ya sé que parece una tontería, pero cuando son las once de la noche y estás preparando el episodio de la semana, lo agradeces.

¿Es perfecto? No. Ni lo pretende. Es pequeño a propósito. Es mantenible a propósito. Es sencillo a propósito. Porque a veces lo mejor no es añadir más cosas, sino quitar las que sobran. Que eso parece que cuesta más.

En el fondo, EasyPodcast nace de una idea muy básica: si el estándar del podcasting es abierto y el RSS es abierto, ¿por qué necesitamos intermediarios para publicar un mp3?

Cómo instalarlo

La instalación es de las más sencillas que he podido hacer. Sin SSH, sin consola, sin complicaciones. Solo necesitas un servidor con PHP.

1. Descarga el instalador: ve al repositorio EasyPodcast-Installer en GitHub y descarga el archivo instalar.php. También puedes descargarlo directamente desde este enlace: descargar instalar.php (clic derecho → Guardar como).
2. Súbelo a tu servidor: copia instalar.php en el directorio raíz donde quieres instalar EasyPodcast. Ese directorio debería estar vacío (o ser el único archivo que haya en él).
3. Abre el instalador en el navegador: accede a https://tu-dominio.com/instalar.php y sigue los tres pasos del asistente: comprobación de compatibilidad, verificación del directorio e instalación.
4. Listo: el instalador descarga la última versión de EasyPodcast desde GitHub, extrae los archivos, crea la base de datos SQLite y te redirige al panel de administración en /admin.php. El propio instalador intenta borrarse solo al terminar; si no puede, bórralo tú manualmente antes de empezar a usar la aplicación.

Requisitos mínimos: PHP 8.0+ con las extensiones pdo_sqlite, sqlite3, zip, gd, fileinfo y xmlwriter. La mayoría de hostings compartidos modernos los tienen activados por defecto.

Si eres de los que tiene servidor propio, te gusta trastear y prefieres depender de ti mismo antes que de una plataforma con suscripción mensual, igual te encaja. Puedes ver el código completo en github.com/educollado/EasyPodcast y ver un ejemplo real funcionando en aratospodcast.com.

La verdad es que me haría mucha ilusión si lo probarais, porque nunca se sabe y a lo mejor es lo que estabais buscando.

Y ahora sí, como dice Felipe, vamos al lío.

Este episodio es la primera parte de un análisis bastante serio —pero contado como lo contaría alguien que lleva más de veinte años en telecomunicaciones— sobre algo que casi todos hemos sufrido alguna vez: tienes un servidor Linux con buena CPU, buena RAM, tarjetas modernas… y de repente empieza a perder paquetes. O aparece jitter. O la latencia hace cosas raras. Y miras la CPU global y está al 20 %. Y piensas: “¿Pero qué está pasando aquí?”

La clave no está en la potencia bruta. Está en el modelo de procesamiento.

El stack de red del kernel Linux está pensado para ser generalista. Tiene que servir para servidores web, bases de datos, firewalls, virtualización, mil aplicaciones a la vez. Cada paquete que entra genera interrupciones, estructuras dinámicas, validaciones, decisiones del scheduler… Todo eso funciona muy bien cuando la carga es razonable.

Pero cuando empiezas a hablar en serio de paquetes por segundo, la historia cambia. No tanto por los gigabits, sino por los pps. Empiezan las invalidaciones de caché, la carga se concentra en una o dos colas, aparecen microbursts que no se absorben bien y el sistema empieza a comportarse de forma poco predecible. No es que Linux “no pueda”. Es que no está optimizado exclusivamente para forwarding masivo.

Aquí es donde entra el enfoque vectorial.

En vez de tratar cada paquete como si fuera un evento único que requiere atención inmediata, el modelo vectorial los agrupa en lotes y los procesa en bloque. Se reducen transiciones, se mantiene la caché caliente y la CPU hace lo que mejor sabe hacer: ejecutar el mismo código repetidamente sobre datos similares.

En lugar de vivir a base de interrupciones, los cores dedicados al plano de datos hacen polling continuo. Sí, están preguntando todo el rato si hay trabajo. A primera vista parece poco eficiente, pero cuando te mueves en millones de paquetes por segundo, el coste del polling es mucho menor que el de gestionar millones de interrupciones.

Sobre esta idea se construye VPP, el Vector Packet Processor. Es un plano de datos en espacio de usuario que, apoyándose en DPDK, toma control directo de las interfaces de red. Organiza el procesamiento como un grafo de nodos: uno clasifica capa 2, otro analiza IP, otro hace el lookup en la FIB, otro reescribe cabeceras, otro aplica ACLs… y todo eso lo hace sobre vectores de buffers ya reservados en hugepages. No hay malloc por paquete. No hay estructuras que se creen y destruyan constantemente.

Y aquí ya nos metemos en terreno físico de verdad: cachés L1, L2, L3, predicción de saltos, TLB, hugepages… Esto no va solo de “configurar BGP”. Va de entender cómo funciona la CPU por dentro. Si ejecutas el mismo código sobre datos contiguos, la caché trabaja a tu favor. Si accedes a memoria del otro socket NUMA, el coste sube. Si no alineas bien colas RSS con workers, puedes saturar un core mientras el de al lado está mirando.

Todo cuenta: CPU, memoria, NIC y cómo lo configuras.

Otro punto importante es que esto no elimina el kernel. Lo separa. El forwarding masivo lo hace el motor vectorial en el plano de datos, pero el plano de control sigue en Linux. Bird o FRR gestionan BGP, OSPF, lo que toque. La sincronización entre ambos mundos se hace por Netlink: el kernel mantiene el RIB y VPP ejecuta la FIB real.

Eso funciona muy bien… siempre que lo entiendas. En una reconvergencia gorda, con miles de rutas BGP entrando o saliendo, puedes generar una tormenta de mensajes Netlink. Si no dimensionas bien los buffers o no separas cores correctamente, puedes tener problemas de sincronización. No es magia. Es ingeniería.

También se habla de cosas muy de campo: caída de enlaces físicos, BFD reaccionando en milisegundos, microbursts, tráfico de paquetes mínimos que te revientan el pps aunque el Gbps no sea alto, y RSS repartiendo mal la carga.

Aquí aparece una métrica que me parece brutal: el “vector size”. Si ves que el promedio se acerca a 256 buffers por llamada, sabes que ese worker está cerca del límite. Mucho más útil que mirar la CPU global y quedarte tranquilo. Es una manera mucho más honesta de saber dónde estás.

A partir de ahí, el dimensionamiento cambia completamente. Dejas de hablar de “este servidor es más potente” y empiezas a hablar de ciclos por paquete. Si el forwarding básico consume X ciclos y añadir NAT o VXLAN suma Y más, puedes estimar cuántos millones de paquetes por segundo puede manejar cada core. Eso ya no es intuición, es matemática.

También se compara de forma honesta con ASIC. Los ASIC siguen siendo impresionantes. Para ciertas escalas y latencias mínimas, son imbatibles. No desaparecen ni mucho menos. Pero el espacio intermedio ha cambiado mucho. Hoy un servidor bien diseñado puede hacer cosas que hace diez o quince años solo estaban al alcance de hardware muy especializado.

La diferencia es que aquí tienes flexibilidad software. Puedes evolucionar, automatizar, versionar configuración, integrar métricas con Prometheus, tratar el router como infraestructura como código.

Y eso cambia la mentalidad.

El plano de datos deja de ser una caja negra. Empiezas a medir ciclos por nodo, vectores procesados, presión de buffers. Dejas de sobredimensionar “por si acaso” y empiezas a dimensionar con números reales.

No es una solución mágica ni sirve para todo el mundo. Requiere entender CPU, hugepages, NUMA, afinidad de cores y cómo se comporta el sistema bajo carga real. Pero si te dedicas a esto desde hace años y te gusta entender lo que pasa de verdad debajo del capó, es difícil no interesarse.

En el fondo, este episodio no va solo de reenviar más tráfico. Va de entender cómo se mueven los paquetes dentro de una máquina moderna, por qué a veces todo parece ir bien hasta que deja de irlo, y cómo rediseñar el plano de datos para que, cuando aprietes de verdad, el sistema responda de forma estable y predecible.

Artículos de VPP en IPngNetworks: https://ipng.ch/s/articles/

Foto de Alex wolf mx: https://www.pexels.com/es-es/foto/carretera-coche-deportivo-deportes-de-motor-carrera-14401648/

Todo esto explicado de forma sencilla lo que nos dice es que el modelo OSI estaba diseñado para entregar la información entre un punto A y un punto B, y eso lo hace perfecto, pero hemos llegado a un punto donde además de entregar la información de A a B, y eso es cierto que lo hace muy muy bien, pero hay un pequeño detalle que nos falta.

El modelo OSI es muy bueno en entregar la información, pero al modelo OSI le da igual si el destino ha entendido el mensaje, si lo ha comprendido bien, como un cartero, entrega las cartas, pero no entra en si el receptor ha entendido bien el mensaje y si la información que ha obtenido es la que el emisor quería que el receptor entendiese.

Hoy estaba en el gimnasio escuchando un podcast llamado Network Break y mientras estaba haciendo ejercicio han comentado este tema y me he quedado con la copla, porque quiero mentir a nadie, me ha impactado muchísimo que el modelo OSI que fue publicado en 1984, imagino que muchos de los que estáis aquí ni siquiera habíais nacido, yo tenía 7 años entonces.

Para mi el modelo OSI estaba básicamente escrito en piedra, era inmutable y una verdad absoluta. El escuchar que el modelo OSI podría cambiar me ha dejado en shock, es verdad que todo cambia, pero el modelo OSI … a veces uno no está preparado para escuchar ciertas cosas, pero mentalidad abierta, ¿por qué no? así que me he puesto a investigar sobre el tema.

Hasta hace relativamente poco las comunicaciones se hacían por humanos, esos que tenemos carne, huesos y experiencia vital, no modelos que necesitan que todo esté perfectamente descrito.

Pero ahora es diferente, además de interactuar las personas interactúan esos entes generalmente conocidos por IAs. Hasta hace poco los agentes de IA actuaban de forma independiente, aislada, no se comunicaban con otros, pero ahora la cosa cambia, los agentes interactúan entre sí, agentes de diversos tipos, ya no son agentes iguales y tienen que ser capaces de comunicarse.

Cuando los agentes quieren comunicarse entre si surgen problemas y no porque los agentes no sean «listos» sino por otro tema más abajo, el problema es que las reglas de comunicación que disponen no dan la talla.

Antes de empezar con esto hay que definir dos conceptos, la sintaxis y la semántica, seguro que lo conoces, pero siempre va bien recordarlo.

Sintaxis

La sintaxis es la forma en la que se transmite la información. Son las reglas del formato: cómo se estructura un mensaje para que pueda ser leído.

La sintaxis dice cómo se escribe algo, no qué significa.

Ejemplo:
Un paquete bien formado, un JSON válido, una cabecera HTTP correcta. Todo eso tiene buena sintaxis, aunque no sepamos qué quiere decir.

Semántica

La semántica es el significado de esa información. Es lo que realmente quiere decir el mensaje, más allá de que esté bien escrito.

La semántica dice qué significa algo y qué se espera que pase.

Ejemplo:
Dos mensajes pueden tener la misma sintaxis, pero provocar acciones distintas según su significado, el contexto o la intención.

Hasta ahora en las comunicaciones no necesitaban trabajar con la semántica porque eso lo hacen los humanos de serie, pero claro, con las máquinas es diferente, ahora necesitamos también controlar la semántica.

Vamos a suponer que un agente envía un mensaje sintácticamente perfecto, pero el agente receptor no entiende bien el significado, la semántica, así que entran en bucles de aclaración que no terminan nunca:

- ¿qué quieres decir?

- no no, ¿qué quieres decir tú?

- dime que quieres que te aclare

Estos bucles de aclaración son muy caros en tiempo y recursos, además esto hace que al final el sistema se vuelva impredecible y que si algo sucede varias veces no siempre va a dar el mismo resultado, esto es terrible, depende del contexto de cada uno al final.

A esto le llamamos «brecha semántica«, y esto es la clave de todo. En el artículo se cita una frase que me parece fantástica sobre la Internet que tenemos diseñada a día de hoy ya que fue

«diseñada para mover bytes, no para mover intención, significado y estado compartido entre agentes«

El tema es que los humanos trabajamos con información en crudo y los agentes de IA trabajan con intención y significado y esa es la brecha que hay que cerrar y que se propone cerrar con esta modificación del modelo OSI.

Esta modificación es añadir las capas 8 y 9 al modelo. Es interesante añadir que aquí la solución no ha pasado por tirarlo todo y volver a empezar de cero, sino algo mucho más fácil que es aprovechar lo anterior y añadir lo que falta, de forma que lo anterior sigue siendo funcional.

La idea es añadir dos capas:

Capa 8: Comunicación de Agente (el cómo se comunican los agentes)

Capa 9: Semántica del Agente (el qué es lo que quieren decir)

La capa 8 (El cómo) estandariza la estructura de las conversaciones: sobres, intención y patrones. Esta es la gramática de los agentes, define la estructura de las frases, si es una pregunta, una orden, una afirmación, es decir, el esqueleto del mensaje

La capa 9 (El qué) estandariza el significado para establecer una verdad compartida antes de actuar. Esta es el diccionario compartido, su función es la de que antes de hacer nada, todo el mundo esté de acuerdo en qué significa cada palabra.

Dentro de la capa 9 tenemos el punto central que es el Contexto Compartido que es algo parecido a las reglas del juego, aquí se define todo, los conceptos, las acciones o los parámetros para cada cosa. Antes de empezar a hablar los agentes harán un Semantic Handshake, para confirmar que están de acuerdo en el Contexto Compartido que se va a utilizar.

Si no aplicáramos esto algo como «Reiniciar el servicio» tendría sus problemas: ¿qué es reiniciar? ¿qué servicio? ¿de qué manera quieres esto?. Con la capa 9 todo esto queda definido.

Lo más importante de todo esto del Contexto Compartido es que se negocia antes de hacer nada, esto es fundamental.

Ejemplo del Mundo Real

Se cae el sistema, se despliega un equipo de agentes, uno de métricas, uno de sistemas, otro de red, otro de … sin las capas 8 y 9 puede ser que un agente piense que el 30% de la utilidad (según sus metricas) está caído, otro el 50%, no saben qué tienen que hacer y hay mucha confusión.

Con las capas 8 y 9 tenemos orden y las cosas funcionan

Beneficios:

1. Agentes de distintas empresas trabajando juntos
2. Sistemas predecibles
3. Ahorros de costes evitando los bucles de aclaración
4. Sistemas más seguros

Hasta ahora estábamos enfocados en mover datos, ahora en mover el entendimiento y esto para empezar tenemos que empezar con las capas 8 y 9.

Referencias:

https://outshift.cisco.com/blog/mind-the-semantic-gap-osi-model

https://www.linkedin.com/posts/sujit-chandrapati-73905b5_outshift-mind-the-semantic-gap-a-case-activity-7424996635505750016-aN1W/

Foto de cabecera de Suzy Hazelwood: https://www.pexels.com/es-es/foto/foto-en-primer-plano-de-libros-con-titulos-variados-1122865/

En la era digital actual, la seguridad de las redes se ha convertido en una preocupación primordial para organizaciones de todos los tamaños. Con la creciente sofisticación de los ataques cibernéticos, es imperativo que las infraestructuras de TI no solo estén protegidas por medidas de seguridad perimetral tradicionales, como firewalls y antivirus, sino también por sistemas avanzados de detección y prevención de intrusiones. Estos sistemas son esenciales para identificar, alertar y, en algunos casos, responder automáticamente a actividades maliciosas antes de que puedan causar daño significativo.

Los Sistemas de Detección de Intrusiones (IDS) juegan un papel crucial en la defensa en profundidad, monitoreando el tráfico de red y/o la actividad en los sistemas para detectar patrones de comportamiento sospechosos o conocidos de ataques. Al operar como los centinelas de la red, los IDS proporcionan una capa adicional de seguridad que ayuda a identificar y mitigar las amenazas en tiempo real o de manera retrospectiva, permitiendo a los equipos de seguridad investigar y responder a los incidentes de manera informada.

Dentro del ámbito de los IDS, existen varias herramientas poderosas y ampliamente adoptadas, cada una con sus propias fortalezas, capacidades y enfoques únicos para la detección de intrusiones. En este artículo, nos centraremos en tres de las herramientas más prominentes y sofisticadas disponibles para sistemas Linux: Snort, Suricata y Zeek.

Snort es uno de los IDS más antiguos y ampliamente utilizados en el mundo. Desarrollado por Sourcefire y ahora bajo el amparo de Cisco, Snort es una herramienta de detección basada en firmas que inspecciona el tráfico de red en busca de patrones específicos que indican posibles intrusiones. Su amplia base de usuarios y su conjunto de reglas actualizadas continuamente lo convierten en una solución de confianza para muchas organizaciones.

Suricata, por otro lado, es un sistema de detección, prevención e inspección de intrusiones de próxima generación. Desarrollado por la Open Information Security Foundation (OISF), Suricata es conocido por su capacidad para realizar análisis de tráfico en tiempo real, utilizando técnicas de detección basadas en firmas, anomalías y protocolos. Es altamente escalable y puede procesar grandes volúmenes de tráfico, aprovechando las capacidades de procesamiento multihilo.

Zeek (anteriormente conocido como Bro) se distingue por su enfoque en el análisis de eventos de red de alta fidelidad y la generación de registros detallados de actividad. A diferencia de Snort y Suricata, que se centran en la detección basada en firmas, Zeek proporciona un marco flexible para el análisis de tráfico que permite a los usuarios escribir sus propios scripts de detección. Esto lo hace excepcionalmente poderoso para identificar comportamientos anómalos y complejos en la red que pueden no ajustarse a las firmas de ataque conocidas.

La selección entre Snort, Suricata y Zeek depende de varios factores, incluidas las necesidades específicas de seguridad de la red, la infraestructura existente, los recursos disponibles y la experiencia técnica del equipo de seguridad. Al entender las capacidades y limitaciones de cada herramienta, las organizaciones pueden implementar una solución de detección de intrusiones robusta y efectiva, fortaleciendo significativamente su postura de seguridad en red.

¿Qué es un Sistema de Detección de Intrusiones (IDS)?

Un Sistema de Detección de Intrusiones (IDS) es una herramienta esencial dentro de la ciberseguridad, diseñada para identificar y alertar sobre intentos de intrusión o actividades maliciosas en una red o sistema. Su principal objetivo es monitorear y analizar tanto el tráfico de red como el comportamiento de los sistemas para detectar acciones sospechosas que podrían indicar una amenaza de seguridad. Esto incluye desde intentos de acceso no autorizado hasta ataques más sofisticados, como el malware, el phishing, y otros tipos de ciberataques.

Definición y Objetivo de un IDS

La definición formal de un IDS se centra en su capacidad para identificar patrones de comportamiento anormal o firmas de ataques conocidos, basándose en un conjunto predefinido de reglas o criterios. Estos sistemas se diseñaron con el objetivo de proporcionar una capa adicional de seguridad, complementando las defensas perimetrales tradicionales como firewalls y soluciones antivirus. Al hacerlo, los IDS desempeñan un papel crucial en la detección temprana de posibles incidentes de seguridad, permitiendo a los administradores de red tomar medidas proactivas para mitigar los riesgos antes de que se produzcan daños significativos.

Tipos de IDS

Los sistemas de detección de intrusiones se clasifican generalmente en dos categorías principales, basados en su enfoque de monitoreo:

• IDS Basados en Red (NIDS): Estos sistemas se centran en el análisis del tráfico de red que pasa por puntos estratégicos de la red, buscando patrones de tráfico sospechosos o anomalías. Los NIDS son especialmente efectivos para identificar ataques dirigidos a múltiples sistemas dentro de la red, ya que tienen una visión global del tráfico de red.
• IDS Basados en Host (HIDS): A diferencia de los NIDS, los HIDS se instalan en dispositivos individuales y monitorean las actividades internas de ese sistema, incluyendo el sistema de archivos, los registros de eventos del sistema y las operaciones de los usuarios. Estos sistemas son capaces de detectar cambios maliciosos en los archivos del sistema, intentos de escalada de privilegios y otras amenazas específicas del host.

Además de estos dos tipos principales, existen variantes híbridas y especializadas de IDS que combinan características de ambos enfoques, ofreciendo una detección de amenazas más comprensiva y adaptativa.

Integración en una Estrategia de Seguridad en Profundidad

La integración de IDS en una estrategia de seguridad en profundidad es fundamental para establecer una defensa robusta contra las amenazas cibernéticas. La seguridad en profundidad se basa en la aplicación de múltiples capas de defensa distribuidas a lo largo de la infraestructura de TI, con el fin de proteger los datos en todos los niveles. Los IDS complementan otras medidas de seguridad al proporcionar detección de amenazas en tiempo real y análisis detallado del comportamiento de la red y de los sistemas.

La implementación efectiva de un IDS dentro de esta estrategia implica no solo su configuración y mantenimiento continuo sino también la integración con otros componentes de seguridad, como sistemas de prevención de intrusiones (IPS), firewalls, sistemas de gestión de eventos e información de seguridad (SIEM) y soluciones de respuesta ante incidentes. Esto permite a las organizaciones no solo detectar amenazas de manera proactiva sino también responder de manera rápida y efectiva, minimizando así el impacto de los ataques.

En conclusión, los sistemas de detección de intrusiones son componentes críticos dentro de la arquitectura de seguridad de cualquier organización. Su capacidad para detectar actividades sospechosas o maliciosas en tiempo real, junto con su integración en una estrategia de seguridad en profundidad, los convierte en herramientas indispensables para la protección contra una amplia gama de ciberamenazas. Al elegir e implementar el tipo adecuado de IDS, las organizaciones pueden fortalecer significativamente su postura de seguridad y su capacidad para responder a incidentes de seguridad.

Snort

Snort es un sistema de prevención y detección de intrusiones de red (NIDS/NIPS) ampliamente reconocido y utilizado en el mundo de la seguridad informática. Desde su creación en 1998 por Martin Roesch, Snort ha evolucionado de ser una simple herramienta de detección de intrusiones a convertirse en un sofisticado sistema de prevención de intrusiones, gracias a su capacidad para analizar el tráfico de red en tiempo real, identificar patrones de ataques y realizar acciones correctivas automáticas.

Historia y Desarrollo de Snort

Snort fue lanzado inicialmente como un proyecto de código abierto, lo que permitió que una comunidad global de desarrolladores y profesionales de seguridad contribuyera a su desarrollo y mejora continua. A lo largo de los años, Snort ha recibido varias actualizaciones significativas que han ampliado sus capacidades de detección y prevención de intrusiones, así como su eficiencia y facilidad de uso. En 2013, Snort fue adquirido por Cisco Systems, lo que marcó el comienzo de una nueva era de desarrollo y soporte profesional, garantizando que Snort siguiera siendo relevante y efectivo frente a las amenazas cibernéticas en constante evolución.

Características Principales

• Detección Basada en Firmas: Snort utiliza un extenso conjunto de firmas de ataques, que son patrones de datos que corresponden a comportamientos conocidos de amenazas. Esto permite a Snort identificar y bloquear una amplia gama de ataques, desde intentos de intrusión hasta malware y actividad de exfiltración de datos.
• Análisis de Protocolos: Snort es capaz de inspeccionar y analizar varios protocolos de red, incluidos HTTP, FTP, SMTP, y muchos otros. Esta capacidad permite a Snort detectar anomalías y ataques que se llevan a cabo a través de protocolos específicos, mejorando la precisión de la detección.
• Prevención de Intrusiones: Además de detectar ataques, Snort puede actuar como un sistema de prevención de intrusiones, bloqueando el tráfico malicioso antes de que alcance los sistemas objetivo. Esto se logra mediante la integración de Snort con dispositivos de control de tráfico de red, como firewalls y switches.

Arquitectura y Componentes Principales

• Preprocesadores: Los preprocesadores son módulos en Snort que preparan el tráfico de red para el análisis, realizando tareas como la normalización de protocolos, la decodificación de flujos y la detección de anomalías. Esto permite a Snort analizar el tráfico de manera más eficiente y efectiva.
• Motor de Detección: El corazón de Snort es su motor de detección, que utiliza algoritmos y patrones de firmas para analizar el tráfico de red en busca de indicadores de ataques. El motor de detección es altamente configurable, permitiendo a los usuarios ajustar la sensibilidad y las especificaciones de detección según las necesidades de su entorno.
• Salidas de Alerta: Cuando Snort detecta una actividad sospechosa, genera alertas que pueden ser enviadas a varios destinos, como archivos de registro, consolas de administración de seguridad o sistemas de gestión de eventos e información de seguridad (SIEM). Esto facilita la monitorización y respuesta rápida a incidentes de seguridad.

Comunidad y Soporte

• Reglas de Snort: Una de las fortalezas de Snort es su sistema de reglas, que es mantenido tanto por la comunidad de usuarios como por equipos profesionales. Las reglas definen los patrones de tráfico que Snort debe buscar y pueden ser personalizadas para satisfacer las necesidades específicas de cualquier red. La comunidad de Snort juega un papel crucial en el desarrollo y actualización constante de estas reglas, asegurando que Snort pueda detectar las últimas amenazas.
• Snort3: La última versión importante de Snort, Snort3, introduce varias mejoras significativas sobre las versiones anteriores, incluyendo una arquitectura completamente reescrita para mejorar el rendimiento y la eficiencia, un sistema de configuración simplificado y capacidades avanzadas de inspección de tráfico. Snort3 representa el compromiso continuo de la comunidad y Cisco para mantener a Snort a la vanguardia de la detección y prevención de intrusiones.

En conclusión, Snort se mantiene como una herramienta indispensable en el arsenal de cualquier profesional de seguridad de redes, ofreciendo capacidades robustas de detección y prevención de intrusiones respaldadas por una comunidad activa y un soporte profesional sólido. Su arquitectura flexible y sistema de reglas potente permiten a Snort adaptarse a una amplia gama de entornos y desafíos de seguridad, haciendo de él una solución de confianza para proteger contra las amenazas cibernéticas modernas.

Suricata

Suricata es un sistema de detección, prevención e inspección de intrusiones de alto rendimiento, desarrollado por la Open Information Security Foundation (OISF). Es conocido por su capacidad para realizar un análisis en profundidad del tráfico de red, utilizando tanto la detección basada en firmas como la detección de anomalías para identificar amenazas. Suricata se distingue por su enfoque en el rendimiento, la escalabilidad y la capacidad de manejar grandes volúmenes de datos en tiempo real.

Historia y Desarrollo de Suricata

Suricata fue lanzado en 2009 por la OISF, con el objetivo de proporcionar una herramienta de detección de intrusiones de próxima generación que fuera de código abierto, altamente escalable y fácil de integrar con otros sistemas de seguridad. Desde su lanzamiento, Suricata ha recibido el apoyo de una comunidad activa de desarrolladores y usuarios que contribuyen a su desarrollo continuo, mejoras en las características y actualizaciones regulares para mantenerse al día con las nuevas amenazas de seguridad.

Características Distintivas

• Multihilo: Suricata está diseñado para ser multihilo, lo que le permite procesar grandes cantidades de tráfico de red de manera eficiente al distribuir la carga de trabajo a través de varios núcleos de procesador. Esta característica hace que Suricata sea especialmente adecuado para entornos de alta demanda, donde el rendimiento y la capacidad de respuesta son críticos.
• Detección Basada en Firmas y en Anomalías: Suricata utiliza un sistema híbrido de detección que combina la detección basada en firmas, para identificar patrones de ataque conocidos, con la detección de anomalías, para identificar comportamientos sospechosos o desconocidos. Esto le permite detectar una amplia gama de amenazas, desde ataques conocidos hasta actividades maliciosas novedosas o sofisticadas.
• Soporte para IPv6 y TLS: En reconocimiento a la evolución de las redes modernas, Suricata ofrece soporte completo para IPv6, permitiendo a las organizaciones proteger sus redes mientras adoptan la última generación de protocolos de Internet. Además, Suricata puede inspeccionar el tráfico cifrado TLS, lo que es esencial para detectar amenazas en conexiones seguras que de otro modo estarían ocultas.

Arquitectura y Flujo de Trabajo

La arquitectura de Suricata está diseñada para maximizar el uso eficiente de los recursos y la escalabilidad. Al utilizar un enfoque multihilo, Suricata puede distribuir el análisis de tráfico a través de varios núcleos de CPU, lo que permite un procesamiento más rápido y la capacidad de manejar volúmenes de tráfico elevados sin degradar el rendimiento. Suricata también implementa una arquitectura de flujo de trabajo que procesa el tráfico de red en etapas, desde la captura de paquetes hasta el análisis de protocolos, la detección de amenazas y la generación de alertas, optimizando el flujo de trabajo para una detección eficaz y precisa.

Integración y Soporte

• Open Information Security Foundation (OISF): Suricata es un proyecto de la OISF, una fundación dedicada al desarrollo de herramientas de seguridad de red de código abierto. La OISF proporciona soporte y recursos para la comunidad de Suricata, facilitando el desarrollo continuo y la adopción de la herramienta en la industria.
• Actualizaciones de Reglas: Suricata se beneficia de un sistema de actualización de reglas dinámico, con contribuciones tanto de la comunidad como de proveedores comerciales. Esto asegura que Suricata esté siempre equipado con las últimas definiciones de amenazas, permitiendo a los usuarios detectar y responder a las amenazas emergentes de manera oportuna. Además, Suricata es compatible con las reglas de Snort, lo que permite a los usuarios aprovechar una amplia base de datos de firmas de ataques conocidos.

Suricata representa una solución robusta y de vanguardia en el ámbito de la detección y prevención de intrusiones, destacándose por su rendimiento, escalabilidad y flexibilidad. La combinación de características avanzadas, como el procesamiento multihilo, la detección híbrida y el soporte para tecnologías emergentes, junto con el fuerte soporte de la OISF y una comunidad activa, hacen de Suricata una elección preferente para organizaciones que buscan proteger sus redes contra una amplia gama de amenazas de seguridad.

Zeek (anteriormente Bro)

Zeek es un potente marco de análisis de seguridad de red que se distingue por su enfoque en la inspección de tráfico en profundidad y el análisis de eventos de red. Originalmente conocido como Bro, el proyecto fue renombrado a Zeek en 2018 para reflejar mejor su evolución y capacidades más allá de una herramienta de detección de intrusiones tradicional. Zeek se ha establecido como una solución de seguridad de red flexible y poderosa, apreciada por su capacidad para analizar el tráfico de red en detalle y proporcionar un contexto rico para la actividad de red, lo que facilita la detección de comportamientos maliciosos y anomalías.

Historia y Cambio de Nombre de Bro a Zeek

El sistema fue desarrollado inicialmente en 1994 por Vern Paxson en Lawrence Berkeley National Laboratory como una herramienta de monitoreo de red. Bro fue diseñado para interpretar lo que sucede en la red desde un punto de vista semántico, llenando el vacío entre el análisis de paquetes tradicional y el alto nivel de abstracción de las intrusiones. Con el tiempo, Bro evolucionó para incluir capacidades de análisis de tráfico más sofisticadas, convirtiéndose en una plataforma completa para la seguridad de la red. En 2018, para reflejar su amplio espectro de capacidades y alejarse de las connotaciones negativas asociadas al término «bro», el proyecto fue renombrado a Zeek.

Enfoque y Características

• Análisis de Eventos de Red: Zeek se centra en convertir el tráfico de red en eventos de alto nivel, permitiendo una comprensión detallada de la actividad de la red. A diferencia de las herramientas de detección de intrusiones basadas en firmas, Zeek analiza los patrones de comportamiento y las conexiones entre eventos, lo que lo hace efectivo en identificar amenazas sofisticadas y ataques sin firmas conocidas.
• Scripting Flexible: Una de las características más potentes de Zeek es su lenguaje de scripting, que permite a los usuarios escribir sus propios scripts para extender la funcionalidad de Zeek, personalizar el análisis de tráfico y adaptar la herramienta a las necesidades específicas de su entorno de red. Esto hace de Zeek una herramienta extremadamente versátil y adaptable.
• Menos Dependiente de Firmas: A diferencia de otros sistemas de detección de intrusiones, Zeek no depende principalmente de las firmas de ataques conocidos para detectar anomalías. En su lugar, analiza el contexto y el comportamiento del tráfico de red, lo que le permite detectar actividades sospechosas basadas en patrones de comportamiento y anomalías, incluso si el ataque es nuevo o desconocido.

Arquitectura y Uso

La arquitectura de Zeek se basa en su motor de eventos, que procesa el tráfico de red y genera eventos de alto nivel para análisis. Los scripts de Zeek definen cómo se analizan y responden a estos eventos, permitiendo una gran personalización. Los usuarios pueden escribir scripts para realizar una amplia gama de tareas, desde la detección de ataques específicos hasta la recolección de estadísticas de red y la generación de registros detallados. Esta capacidad de personalización hace que Zeek sea adecuado para una variedad de entornos de red, desde pequeñas empresas hasta grandes infraestructuras corporativas.

Comunidad y Recursos Disponibles

• Paquetes de Scripts: La comunidad de Zeek ofrece una amplia gama de paquetes de scripts para diferentes propósitos, desde la detección de malware y exfiltración de datos hasta el análisis de protocolos específicos. Estos paquetes permiten a los usuarios ampliar rápidamente las capacidades de Zeek para satisfacer sus necesidades específicas.
• Formación y Documentación: Zeek cuenta con un extenso conjunto de recursos de formación y documentación para ayudar a los nuevos usuarios a familiarizarse con la herramienta y para asistir a los usuarios experimentados en la personalización y extensión de Zeek. La comunidad de Zeek organiza regularmente talleres, webinars y conferencias para proporcionar formación y compartir conocimientos.
• Comunidad Activa: La comunidad de Zeek es una de sus mayores fortalezas, con un amplio soporte disponible a través de listas de correo, canales de Slack y foros de discusión. Los usuarios pueden colaborar, compartir conocimientos y obtener ayuda de otros profesionales de seguridad.

En resumen, Zeek ofrece una plataforma potente y flexible para el análisis de seguridad de red, destacándose por su enfoque en el análisis de eventos, la flexibilidad de scripting y la capacidad de adaptarse a una amplia gama de entornos de red. Con el apoyo de una comunidad activa y recursos extensos, Zeek continúa siendo una herramienta valiosa para profesionales de la seguridad que buscan una comprensión profunda y detallada de la actividad de su red.

Comparación y Casos de Uso

Al elegir entre Snort, Suricata y Zeek para la seguridad de la red, los profesionales deben considerar varios factores críticos, incluidos el rendimiento, la facilidad de uso, la flexibilidad y el soporte comunitario. Cada uno de estos sistemas de detección de intrusiones ofrece ventajas únicas y puede ser más adecuado para ciertos entornos y necesidades de seguridad.

Comparación Directa

• Rendimiento:
  • Snort es ampliamente reconocido por su robustez y ha sido el estándar de oro en la detección basada en firmas durante muchos años. Sin embargo, puede no ser tan eficiente en el procesamiento de grandes volúmenes de tráfico de red como Suricata, debido a su arquitectura monohilo en versiones anteriores (antes de Snort 3).
  • Suricata se destaca por su capacidad de procesamiento multihilo, lo que le permite manejar grandes volúmenes de datos con mayor eficacia, haciendo de Suricata una opción preferida para redes de alto rendimiento.
  • Zeek no se centra primariamente en la detección basada en firmas sino en el análisis de eventos de red, lo que requiere un enfoque diferente en términos de rendimiento. Su capacidad para generar análisis detallados y registros de eventos lo hace valioso para investigaciones de seguridad y monitoreo de red en tiempo real, aunque esto puede requerir recursos computacionales significativos para el procesamiento.
• Facilidad de Uso:
  • Snort tiene una curva de aprendizaje moderada, especialmente para configurar y personalizar reglas. Sin embargo, su amplia adopción y vasta documentación facilitan encontrar guías y soporte.
  • Suricata ofrece configuraciones y opciones avanzadas que pueden ser intimidantes para los nuevos usuarios, pero su soporte para reglas de Snort y la adición de capacidades de procesamiento multihilo lo hacen atractivo para usuarios con necesidades de rendimiento específicas.
  • Zeek requiere una comprensión más profunda de los scripts y el análisis de eventos de red, lo que puede presentar una curva de aprendizaje más pronunciada. Sin embargo, ofrece flexibilidad sin precedentes para aquellos dispuestos a adentrarse en su lenguaje de scripting.
• Flexibilidad:
  • Snort y Suricata ofrecen flexibilidad en términos de detección de intrusiones y prevención, con Suricata proporcionando capacidades avanzadas de procesamiento de tráfico gracias a su arquitectura multihilo.
  • Zeek sobresale en términos de flexibilidad debido a su poderoso lenguaje de scripting, que permite a los usuarios adaptar la herramienta a una amplia gama de escenarios de seguridad específicos.
• Soporte Comunitario:
  • Snort disfruta de un vasto soporte comunitario, con una gran base de usuarios y desarrolladores contribuyendo a su conjunto de reglas y documentación.
  • Suricata también cuenta con una comunidad activa, respaldada por la OISF, y beneficia de actualizaciones regulares y un flujo constante de nuevas características.
  • Zeek tiene una comunidad única orientada a investigadores y profesionales de seguridad que comparten scripts, herramientas y mejores prácticas, proporcionando un recurso valioso para usuarios avanzados.

Elección Dependiendo del Contexto Específico

• Tamaño de la Red:
  • Para redes de gran tamaño y alto volumen de tráfico, Suricata puede ser la mejor opción debido a su capacidad de procesamiento multihilo y eficiencia en el manejo de grandes volúmenes de datos.
  • En redes más pequeñas o en entornos donde el análisis detallado es más crítico que el volumen de tráfico, Snort y Zeek pueden ser más adecuados.
• Recursos Disponibles:
  • Organizaciones con recursos limitados pueden preferir Snort por su amplia base de usuarios y soporte comunitario.
  • Aquellas con la capacidad de invertir en hardware más potente para el análisis de tráfico podrían inclinarse por Suricata o Zeek.
• Nivel de Experiencia Técnica:
  • Snort puede ser una buena entrada para aquellos nuevos en la detección de intrusiones, mientras que Suricata ofrece una opción robusta para aquellos con algo más de experiencia.
  • Zeek es particularmente adecuado para usuarios con un alto nivel de experiencia técnica que desean una personalización profunda y análisis detallado.

La elección entre Snort, Suricata y Zeek debe basarse en una evaluación cuidadosa de las necesidades específicas de seguridad, recursos disponibles y experiencia técnica. Cada herramienta tiene sus fortalezas y puede ser la mejor opción en diferentes contextos. La consideración de estos factores ayudará a garantizar que se elija la solución más adecuada para proteger la infraestructura de red contra amenazas.

Implementación y Mejores Prácticas para Sistemas de Detección de Intrusiones (IDS)

La implementación de un Sistema de Detección de Intrusiones (IDS) es una parte crucial de la estrategia de seguridad en cualquier organización. Su correcta configuración y mantenimiento pueden significar la diferencia entre detectar a tiempo una intrusión potencialmente devastadora y dejar pasar inadvertida una amenaza. Aquí se detallan algunos consejos y mejores prácticas para la implementación efectiva de un IDS, así como para la gestión de alertas y la respuesta a incidentes.

Implementación Efectiva de un IDS

• Monitoreo del Tráfico de Red:
  • Cobertura Completa: Asegúrate de que el IDS tenga visibilidad sobre todo el tráfico de red relevante. Esto puede implicar la colocación estratégica de sensores IDS en puntos clave de la red donde el tráfico de datos es más significativo.
  • Análisis de Tráfico Cifrado: Considera la capacidad del IDS para manejar tráfico cifrado, dado que muchas amenazas ahora se ocultan dentro de conexiones seguras. La descifrado, cuando sea legal y éticamente apropiado, puede ser necesario para una inspección profunda del paquete.
• Ajuste de la Configuración:
  • Personalización: Ajusta las configuraciones y reglas del IDS según el entorno específico de tu red y las políticas de seguridad de tu organización. Lo que funciona para una red puede no ser adecuado para otra.
  • Minimización de Falsos Positivos y Negativos: Trabaja continuamente en el ajuste de las reglas para reducir los falsos positivos, que pueden sobrecargar al equipo de seguridad, sin incrementar los falsos negativos, que representan amenazas no detectadas.
• Actualización Regular de las Reglas:
  • Mantente Actualizado: Las amenazas evolucionan constantemente, por lo que es crucial mantener el sistema de detección de intrusiones actualizado con las últimas reglas y firmas de ataques.
  • Suscripciones a Fuentes de Inteligencia de Amenazas: Utiliza fuentes de inteligencia de amenazas para enriquecer las capacidades de detección del IDS, permitiendo que el sistema reconozca las últimas tácticas, técnicas y procedimientos utilizados por los atacantes.

Gestión de Alertas y Respuesta a Incidentes

• Priorización de Alertas:
  • Clasificación de Alertas: Desarrolla un sistema para clasificar alertas basado en su gravedad y potencial impacto, lo que permitirá a tu equipo centrarse primero en las más críticas.
  • Contextualización: Incorpora contexto a las alertas para ayudar en la rápida evaluación de su importancia. Esto incluye datos sobre los activos afectados, vulnerabilidades conocidas y correlación con otros eventos de seguridad.
• Procesos de Respuesta a Incidentes:
  • Planes de Respuesta Predefinidos: Establece procedimientos y planes de respuesta específicos para diferentes tipos de alertas. Esto debe incluir pasos claros para la contención, erradicación y recuperación de incidentes.
  • Automatización: Donde sea posible, automatiza las respuestas a incidentes comunes para acelerar la resolución y reducir la carga de trabajo manual del equipo de seguridad.
• Revisión y Aprendizaje Continuo:
  • Análisis Post-Incidente: Después de un incidente, realiza un análisis detallado para entender qué sucedió, cómo se detectó la amenaza, cómo se respondió y cómo se puede mejorar la detección y respuesta en el futuro.
  • Capacitación y Sensibilización: Asegúrate de que todos los miembros del equipo de seguridad estén continuamente capacitados en las últimas tendencias de ciberseguridad, técnicas de ataque y estrategias de defensa.

Implementar y mantener un IDS eficazmente es una tarea compleja que requiere un enfoque proactivo y un compromiso con la mejora continua. Al seguir estas mejores prácticas, las organizaciones pueden fortalecer significativamente su capacidad para detectar y responder a las amenazas de seguridad, protegiendo así sus activos críticos y manteniendo la integridad de sus sistemas y datos.

Conclusión

Los Sistemas de Detección de Intrusiones (IDS) representan una faceta crítica de la ciberseguridad, crucial para la protección integral de las infraestructuras de Tecnologías de la Información (TI). A medida que el panorama de amenazas evoluciona con ataques cada vez más sofisticados y diversificados, la necesidad de implementar y mantener IDS eficientes se hace más evidente. Estas herramientas no solo ofrecen la capacidad de detectar actividades maliciosas en tiempo real, sino que también proporcionan una visión profunda del tráfico de red, lo que permite a los equipos de seguridad identificar patrones sospechosos y responder adecuadamente antes de que se materialicen daños significativos.

La importancia de los IDS dentro de la infraestructura de TI trasciende la simple detección de ataques. Estos sistemas juegan un papel vital en la estrategia de defensa en profundidad, complementando otras medidas de seguridad como firewalls, sistemas de prevención de intrusiones (IPS), y soluciones antivirus. Al monitorear continuamente el tráfico de red y los sistemas host para detectar actividades anómalas o maliciosas, los IDS proporcionan una capa adicional de seguridad que fortalece la postura general de ciberseguridad de una organización.

La elección del IDS adecuado, sin embargo, no es una decisión que deba tomarse a la ligera. Cada herramienta de IDS, ya sea Snort, Suricata o Zeek, viene con sus propias fortalezas, debilidades y áreas de especialización. La decisión de implementar una solución específica debe basarse en una evaluación detallada de las necesidades específicas de seguridad de la organización, la infraestructura de red existente, los recursos disponibles, y el nivel de experiencia técnica del equipo de seguridad.

Para redes de alto rendimiento que manejan grandes volúmenes de datos, Suricata, con su capacidad de procesamiento multihilo, puede ofrecer la eficiencia necesaria. Para organizaciones que buscan una solución madura y ampliamente soportada con una gran base de reglas, Snort podría ser la opción preferida. Por otro lado, Zeek se destaca por su flexibilidad y capacidad de análisis detallado del tráfico, lo que lo hace ideal para entornos que requieren un alto grado de personalización y análisis forense.

En última instancia, la implementación exitosa de un IDS requiere no solo la selección de la herramienta adecuada, sino también un compromiso continuo con las mejores prácticas de configuración, mantenimiento y respuesta a incidentes. Esto incluye el ajuste regular de la configuración para minimizar los falsos positivos, la actualización constante de las reglas para detectar las últimas amenazas, y el desarrollo de un proceso efectivo de gestión de alertas y respuesta a incidentes.

Los IDS son, sin duda, componentes indispensables de una estrategia de seguridad robusta. Sin embargo, su eficacia está intrínsecamente ligada a la habilidad de la organización para integrarlos adecuadamente dentro de su ecosistema de seguridad, personalizarlos según las necesidades únicas del entorno, y responder de manera efectiva a las alertas generadas. En el contexto actual de amenazas cibernéticas en constante evolución, la capacidad de una organización para proteger sus activos de información depende en gran medida de su enfoque proactivo hacia la seguridad de la red, en el cual los IDS juegan un papel central.

Referencias

La implementación y gestión eficaces de los Sistemas de Detección de Intrusiones (IDS) como Snort, Suricata y Zeek requieren acceso a una amplia gama de recursos de aprendizaje y soporte. A continuación, se presenta una lista de referencias útiles, incluyendo documentación oficial, estudios de caso, tutoriales y recursos comunitarios para cada uno de estos sistemas.

Snort

• Documentación Oficial: La documentación oficial de Snort proporciona una guía exhaustiva sobre la instalación, configuración y operación de Snort. Disponible en: https://www.snort.org/documents
• Tutoriales: Los tutoriales de Snort, disponibles en su sitio web oficial y en plataformas como YouTube, ofrecen instrucciones paso a paso para usuarios de todos los niveles.
• Recursos Comunitarios: La comunidad de Snort en https://www.snort.org/community es un lugar excelente para encontrar soporte, compartir configuraciones y discutir las mejores prácticas.
• Estudios de Caso: Diversos estudios de caso sobre la implementación de Snort en entornos empresariales pueden ser encontrados a través de búsquedas en internet, proporcionando perspectivas reales sobre su aplicación y beneficios.

Suricata

• Documentación Oficial: La Open Information Security Foundation (OISF) mantiene una documentación detallada de Suricata, que es esencial para cualquier implementación. Disponible en: https://suricata.readthedocs.io/en/suricata-6.0.0/
• Tutoriales: Hay una amplia gama de tutoriales disponibles en línea para ayudar a los usuarios a comenzar con Suricata, desde la configuración inicial hasta el análisis avanzado de tráfico.
• Recursos Comunitarios: El foro de Suricata en https://forum.suricata.io/ y otros grupos en plataformas de redes sociales son excelentes recursos para obtener soporte y consejos de la comunidad.
• Estudios de Caso: Investigaciones y publicaciones específicas sobre el uso de Suricata en diferentes sectores industriales pueden proporcionar una visión valiosa sobre su adaptabilidad y eficacia.

Zeek

• Documentación Oficial: La documentación de Zeek es un recurso invaluable que ofrece una visión completa sobre cómo utilizar y personalizar Zeek. Disponible en: https://docs.zeek.org/en/current/
• Tutoriales: Los tutoriales específicos de Zeek, que van desde configuraciones básicas hasta el desarrollo de scripts avanzados, son accesibles a través de su sitio web oficial y plataformas de aprendizaje en línea.
• Recursos Comunitarios: La comunidad de Zeek, accesible en https://zeek.org/get-involved/, ofrece una amplia gama de recursos, incluyendo una lista de correo, Slack y eventos como ZeekWeek para fomentar el aprendizaje y la colaboración.
• Estudios de Caso: Los estudios de caso sobre Zeek ofrecen insights sobre cómo esta herramienta se ha implementado en entornos complejos para resolver problemas de seguridad específicos.

Estos recursos representan puntos de partida esenciales para aquellos interesados en profundizar en la teoría y práctica de los IDS. Ya sea que estés buscando implementar un nuevo sistema de detección de intrusiones, optimizar una configuración existente o simplemente expandir tu conocimiento en el área, la documentación oficial, tutoriales, recursos comunitarios y estudios de caso proporcionan una base sólida sobre la cual construir tu experiencia.

Desde hace años, Afrinic vive una situación crítica: sin junta directiva electa desde 2022, bajo administración judicial desde 2023 y atrapada en un torbellino de demandas, elecciones anuladas y sospechas de corrupción. El origen de todo está en su enfrentamiento con CIL, uno de los mayores receptores de IPv4 en África. Afrinic acusó a CIL de incumplimientos y uso indebido de direcciones, mientras que CIL respondió con una ofensiva legal que dejó a la organización prácticamente paralizada y sin fondos.

A partir de ahí, los problemas se multiplicaron: intentos fallidos de elecciones en 2025 por votos delegados falsificados, la presión de ICANN que amenaza con retirar el reconocimiento a Afrinic como RIR, y la intervención del gobierno de Mauricio, percibida por algunos como una intromisión política que pone en duda la independencia del organismo. A esto se suman contratos legales opacos, abogados sin capacidad para representar a Afrinic y un ambiente de desconfianza que no deja de crecer.

Hoy Afrinic se encuentra en un callejón con varias salidas posibles, todas delicadas: reestructuración con ayuda de otros RIRs, pérdida de reconocimiento por parte de ICANN o, incluso, la disolución forzosa que propone CIL. Lo que está en juego no es solo el futuro de una organización, sino la estabilidad de Internet en todo un continente.

Referencias:

• https://btw.media/afrinic/afrinic-collapse-and-internet-governance-under-icann-pressure/
• https://afrinic.net/20220827-communique
• https://btw.media/all/internet-governance/regulation/afrinic-vs-lu-heng-how-a-simple-commercial-dispute-became-the-biggest-story-in-internet-governance/
• https://btw.media/afrinic/afrinics-independence-why-rule-of-law-must-prevail-over-political-interference/
• https://btw.media/afrinic/controversy-as-afrinic-opens-nominations-for-2025-board-election/
• https://www.internetgovernance.org/2025/06/19/has-the-supreme-court-of-mauritius-resolved-afrinics-governance-turmoil/
• https://www.theregister.com/2025/06/26/icann_letter_afrinic_election_suspended/
• https://technomag.co.zw/internet-governance-ln-turmoil-as-afrinic-faces-possible-dissolution/
• https://btw.media/all/it-infrastructure/data-centres/lu-heng-larus-ceo-on-afrinic-elections-clique-control-must-end-decentralisation-will-ensure-democracy/

Principales vulnerabilidades del BGP

1. Suplantación de rutas (Route Hijacking): El paraguas que todo lo aglutina.
2. Secuestro de prefijos (Prefix Hijacking): Anuncio ilegítimo de prefijos, ya sea por error o con intención maliciosa, lo que puede causar interrupciones de servicio y robo de datos.
3. Inyección de rutas maliciosas: El atacante introduce rutas falsas, provocando pérdida de paquetes, degradación de rendimiento o bucles de encaminamiento.
4. Route leaks: Rutas que deberían ser privadas se propagan públicamente, exponiendo datos internos y generando inestabilidad en el encaminamiento.

Medidas de protección clave

• RPKI: Permite validar si un AS está autorizado para anunciar un prefijo, ayudando a evitar secuestros de rutas y errores de configuración.
• Filtrado de rutas: Impide que se acepten o anuncien rutas no autorizadas mediante listas de prefijos y políticas de validación.
• Monitorización de anomalías: Sistemas que detectan comportamientos extraños en las rutas BGP, como aumentos súbitos de prefijos o cambios inesperados de rutas.
• Sesiones seguras con TCP MD5 o TCP-AO: Protegen las sesiones BGP mediante autenticación criptográfica, evitando manipulaciones en las conexiones entre routers.

Buenas prácticas

• Aplicar políticas de seguridad estrictas.
• Configurar alertas y realizar auditorías periódicas.
• Ir al EsNOG y hacerse el MANRS.
• Leer mucho.

Casos reales destacados

• YouTube (2008): Pakistan Telecom secuestró por error el tráfico global de YouTube durante varias horas.
• Google (2018): Parte del tráfico se desvió a través de Rusia y China tras un anuncio incorrecto de prefijos por parte de un ISP en Nigeria.
• Bitcoin (2014): Mineros de Bitcoin fueron víctimas de un ataque BGP que desvió su tráfico, afectando su rendimiento y generando pérdidas.
• AWS Route 53 (2018): Un secuestro de rutas permitió redirigir tráfico DNS de Amazon a servidores maliciosos y lanzar ataques de phishing.
• Orange España (2024): El 3 de enero, el operador se quedó sin servicio tras un ataque que modificó los ROA del RPKI mediante el robo de credenciales del administrador en RIPE. RIPE obligó a partir de entonces a activar el segundo factor de autenticación en todas las cuentas.

El futuro

El camino hacia un BGP más seguro pasa por:

• La adopción global del RPKI, como herramienta base para validar anuncios de rutas, aún estamos lejos.
• El desarrollo de nuevos protocolos, como BGPsec y arquitecturas alternativas como SCION, que integran seguridad desde su diseño.
• La cooperación entre operadores, la estandarización de buenas prácticas y una mayor conciencia sobre la importancia de proteger la infraestructura de encaminamiento.

Vídeo del Canal de Tecnocrática

Por si preferís ver en vídeo, no es exactamente el mismo contenido, pero sí muy similar.

Foto de Lewis Kang’ethe Ngugi: https://www.pexels.com/es-es/foto/monitor-de-pantalla-plana-encendido-289927/

En un switch Nexus, los puertos pueden configurarse como puertos de acceso o como puertos trunk, según lo que se requiera en la red.

Puertos de Acceso

Los puertos de acceso se utilizan para conectar dispositivos finales, como ordenadores, impresoras y otros dispositivos de usuario final, a la red. Cada puerto de acceso está asociado con una sola VLAN.

Configuración de un puerto de acceso:

interface Ethernet1/1
  switchport mode access
  switchport access vlan 10

En este ejemplo, configuramos el puerto Ethernet1/1 como un puerto de acceso y lo asignamos a la VLAN 10.

Puertos Trunk

Los puertos trunk se usan para transportar tráfico de múltiples VLAN entre switches o entre un switch y un router. Los puertos trunk etiquetan las tramas Ethernet con un identificador de VLAN para asegurar que el tráfico se dirija a la VLAN correcta. Configuración de un puerto trunk:

interface Ethernet1/2
  switchport mode trunk
  switchport trunk allowed vlan 10,20,30
  switchport trunk native vlan 1

En este ejemplo, configuraremos el puerto Ethernet1/2 como un puerto trunk para permitir el tráfico de las VLAN 10, 20 y 30, con la VLAN nativa configurada en 1. La VLAN nativa se utiliza para el tráfico no etiquetado.

Lidiar con Spanning Tree

Para proteger la red de problemas relacionados con el Spanning Tree Protocol (STP), hay que mantener la estabilidad y evitar bucles de red. Aquí os dejo las mejores prácticas y configuraciones de STP para un switch Cisco Nexus:

Configurar BPDU Guard

BPDU Guard se utiliza para proteger los puertos configurados como puertos de acceso (edge ports) que no deberían recibir Bridge Protocol Data Units (BPDUs). Si un puerto con BPDU Guard habilitado recibe un BPDU, el puerto se deshabilitará automáticamente para prevenir bucles de STP.

switch# configure terminal
  switch(config)# interface range Ethernet1/1 - 24
    switch(config-if-range)# spanning-tree port type edge
    switch(config-if-range)# spanning-tree bpduguard enable

spanning-tree port type edge: Configura el puerto como un puerto de acceso, lo que significa que se transicionará inmediatamente al estado forwarding.
spanning-tree bpduguard enable: Habilita BPDU Guard para deshabilitar el puerto si se recibe un BPDU.

Configurar Root Guard

Root Guard previene que dispositivos no autorizados se conviertan en el root bridge, lo cual podría alterar la topología STP de la red.

switch# configure terminal
  switch(config)# interface Ethernet1/25
    switch(config-if)# spanning-tree guard root

spanning-tree guard root: Habilita Root Guard en el puerto para asegurarse de que no se pueda convertir en root port si se reciben BPDUs de un dispositivo no autorizado.

Configurar Loop Guard

Loop Guard ayuda a prevenir bucles causados por un fallo en recibir BPDUs en puertos no-designados. Es útil en topologías redundantes donde los puertos pueden quedarse en estado «stuck in blocking».

switch# configure terminal
  switch(config)# interface Ethernet1/26
    switch(config-if)# spanning-tree guard loop

spanning-tree guard loop: Habilita Loop Guard en el puerto para evitar que se transicione a forwarding si deja de recibir BPDUs.

Configurar UDLD (Unidirectional Link Detection)

UDLD detecta enlaces unidireccionales causados por fallos físicos y puede deshabilitar el puerto afectado.

switch# configure terminal
  switch(config)# interface Ethernet1/27
    switch(config-if)# udld port aggressive

udld port aggressive: Configura UDLD en modo agresivo para detectar y deshabilitar rápidamente enlaces unidireccionales.

Configurar PortFast

PortFast se utiliza en puertos de acceso para que transicionen inmediatamente al estado forwarding, lo que es útil en puertos conectados a hosts.

switch# configure terminal
  switch(config)# interface range Ethernet1/1 - 24
    switch(config-if-range)# spanning-tree port type edge

spanning-tree port type edge: Habilita PortFast en los puertos de acceso para minimizar el tiempo de convergencia.

Ejemplo Completo de Configuración

switch# configure terminal
  switch(config)# interface Ethernet1/1 - 24
    switch(config-if-range)# spanning-tree port type edge
    switch(config-if-range)# spanning-tree bpduguard enable
  switch(config)# interface Ethernet1/25
    switch(config-if)# spanning-tree guard root
  switch(config)# interface Ethernet1/26
    switch(config-if)# spanning-tree guard loop
  switch(config)# interface Ethernet1/27
    switch(config-if)# udld port aggressive
  switch(config)# exit

Configurar correctamente los puertos de un switch Cisco Nexus para protegernos de problemas con el Spanning Tree Protocol (STP) implica habilitar BPDU Guard, Root Guard, Loop Guard y PortFast en los puertos adecuados. Estas configuraciones previenen bucles de red, aseguran la estabilidad de la topología STP y mejoran la eficiencia de la red.

Port Security

Configurar Port Security de manera efectiva en una red corporativa es esencial para prevenir accesos no autorizados y proteger la integridad de la red. Aquí están las mejores prácticas para lograrlo en switches Cisco Nexus:

Lo primero será habilitar el feature de port-security:

switch# configure terminal 
  switch(config)# feature port-security

Definir Políticas de Seguridad Claras

Antes de configurar Port Security, es crucial definir políticas claras que establezcan qué dispositivos están permitidos en la red y cuáles no. Estas políticas deben ser comunicadas y aplicadas consistentemente.

Configurar Port Security Básico

Comienza con una configuración básica de Port Security para restringir el número de direcciones MAC permitidas en cada puerto:

switch# configure terminal
  switch(config)# interface Ethernet1/1
    switch(config-if)# switchport mode access
    switch(config-if)# switchport port-security
    switch(config-if)# switchport port-security maximum 2
    switch(config-if)# switchport port-security violation restrict

switchport port-security maximum 2: Permite un máximo de dos direcciones MAC en el puerto.
switchport port-security violation restrict: En caso de una violación, el puerto restringirá el acceso en lugar de deshabilitarse completamente, permitiendo al administrador investigar sin una interrupción total.

Usar Sticky MAC Addresses

Configura direcciones MAC «sticky» para que las direcciones aprendidas dinámicamente se guarden en la configuración de running, lo que facilita la administración:

switch(config-if)# switchport port-security mac-address sticky

Implementar Políticas de Violación

Define qué acción tomar en caso de una violación de seguridad. Las opciones incluyen protect, restrict, y shutdown. La opción restrict es generalmente recomendada para evitar interrupciones totales:

switch(config-if)# switchport port-security violation restrict

• Protect: Descarta paquetes no autorizados, sin alertas ni registros. (No funciona en todos los modelos)
• Restrict: Descarta paquetes no autorizados, con alertas y registros.
• Shutdown: Deshabilita el puerto completamente en caso de violación.

Control de Macs

Control Manual

switch(config-if)# switchport port-security mac-address 0AC3.4C16.BEF0 vlan 111
switch(config-if)# switchport port-security mac-address 12B7.364D.D307 vlan 111

Control con macs sticky

switch(config-if)# switchport port-security mac-address sticky

Para ver las macs sticky aprendidas:

switch#sh port-security address

Para borrar una mac sticky

switch(config-if)# no switchport port-security mac-address sticky 0011.2233.4455

Configura alertas para ser notificado en caso de violaciones de seguridad. Utiliza Syslog o SNMP traps para recibir notificaciones:

Monitorización y Alertas

Configura alertas para ser notificado en caso de violaciones de seguridad. Utiliza Syslog o SNMP traps para recibir notificaciones:

switch(config)# logging host <IP_del_servidor_syslog>
switch(config)# snmp-server enable traps port-security

Auditoría

Realiza auditorías de las configuraciones de Port Security y las direcciones MAC asociadas a cada puerto. Utiliza comandos como:

switch# show port-security interface Ethernet1/1
switch# show port-security address

Documentación y Formación

Documenta todas las configuraciones y asegúrate de que el equipo de IT esté formado en cómo configurar y monitorizar Port Security. Incluye procedimientos para resolver violaciones y restaurar la normalidad.

En el audio de hoy hablo de:

• Almacenamiento
• Red
• Firewall
• HA

Espero que os resulte interesante y recordad que si necesitáis algo con Proxmox en Tecnocrática es una de las cosas que hacemos.

La evolución hacia RDMA (Acceso Directo a Memoria Remota) es notable por su capacidad de eliminar copias de datos innecesarias, reduciendo la carga en la CPU y disminuyendo la latencia de la red. RDMA permite transferencias de memoria a memoria sin la intervención del sistema operativo, mejorando significativamente la eficiencia en la transferencia de datos entre sistemas remotos.

Una tecnología particularmente relevante mencionada en el documento es RoCE (RDMA over Converged Ethernet), que adapta RDMA para operar sobre redes Ethernet. RoCE mejora la eficiencia operativa al permitir transferencias de datos de alta velocidad sin sobrecargar el procesador central y es ideal para entornos como centros de datos y la nube, donde se requieren altas tasas de transferencia de datos y baja latencia.

RoCE viene en varias versiones, como RoCE v1, que opera en redes sin pérdidas utilizando Control de Flujo por Prioridad (PFC), y RoCE v2, que funciona sobre redes IP y utiliza UDP para encapsular paquetes RDMA, incluyendo mecanismos de control de congestión avanzados como ECN.

La culminación de estas tecnologías se presenta con UltraEthernet, que se describe como una evolución de RoCE diseñada específicamente para las necesidades de la IA y la HPC. Ofrece mejoras en escalabilidad, manejo de la congestión, rendimiento y seguridad, optimizando para operaciones rápidas necesarias en el procesamiento de grandes volúmenes de datos en tiempo real o tiempos de ejecución aceptables. También incorpora mecanismos de seguridad directamente en la capa de red para proteger datos críticos, como el cifrado de datos en tránsito y la autenticación de nodos.

En resumen, estas tecnologías no solo avanzan en la eficiencia y el rendimiento de las redes y los sistemas de procesamiento de datos, sino que también abordan desafíos críticos de seguridad y escalabilidad necesarios para el futuro de la computación en IA y HPC.

Descargar: ultraethernet_esnog_31.pdf

Para protegerse contra estos ataques, se recomienda emplear prácticas de seguridad como validación de entrada, cifrado de comunicaciones, educación en seguridad, actualizaciones regulares, copias de seguridad, y el uso de soluciones de seguridad avanzadas.

Un SOC es una unidad especializada dentro de una organización dedicada a la monitorización, análisis, detección y respuesta ante amenazas cibernéticas. Opera 24/7 para proteger los activos digitales mediante la monitorización continua, el análisis de eventos, la detección de amenazas, la respuesta a incidentes y la gestión de la seguridad. El equipo de un SOC incluye analistas de seguridad, ingenieros, expertos en respuesta a incidentes y gestores, todos trabajando con herramientas avanzadas como IDS, IPS, firewalls, y plataformas de inteligencia de amenazas.

SIEM (Security Information and Event Management)

Un SIEM centraliza la recopilación, almacenamiento, análisis y correlación de eventos de seguridad de diversas fuentes, ofreciendo una visión holística y en tiempo real del estado de seguridad. Esto facilita la detección temprana de amenazas y una respuesta eficaz ante incidentes. Los componentes clave incluyen la recopilación de datos, normalización, almacenamiento, análisis, generación de alertas y una consola de usuario para la interacción.

WAF (Web Application Firewall)

Un WAF protege las aplicaciones web filtrando y bloqueando el tráfico malicioso para prevenir ataques como inyección de SQL y XSS. Puede ser basado en la nube, on-premise o híbrido, ofreciendo protección contra ataques comunes, mejorando la seguridad web y reduciendo el tiempo de respuesta a incidentes.

IDS (Intrusion Detection System)

Un IDS es una herramienta que monitoriza la red o sistemas informáticos en busca de actividades maliciosas o no autorizadas, generando alertas para una posible acción. Los IDS pueden ser basados en la red (NIDS), en el host (HIDS) o en aplicaciones (AIDS), y utilizan métodos de detección basados en firmas, anomalías y comportamientos.

IPS (Intrusion Prevention System)

Un IPS, al igual que un IDS, detecta actividades sospechosas pero también interviene activamente para prevenir daños, bloqueando tráfico malicioso o aislando dispositivos afectados. Los IPS pueden ser basados en la red (NIPS), en el host (HIPS) o en aplicaciones (AIPS), ofreciendo una capa adicional de seguridad.

SOAR (Security Orchestration, Automation, and Response)

Un SOAR mejora la eficiencia y eficacia de los equipos de seguridad mediante la orquestación y automatización de procesos y respuestas a incidentes. Integra diversas herramientas de seguridad y automatiza tareas rutinarias, proporcionando un marco de trabajo para respuestas rápidas y eficientes a las amenazas detectadas.

Diferencias entre IPS e IDS

Mientras que ambos sistemas detectan actividades maliciosas, el IPS se diferencia por su capacidad para prevenir intrusiones activamente, siendo más complejo y costoso que un IDS, que se enfoca en la detección y generación de alertas.

Ofrece recursos gratuitos como guías, herramientas y proyectos para ayudar a los desarrolladores y organizaciones a proteger sus aplicaciones web.
Algunos de sus recursos más conocidos son:

• OWASP Top Ten: Lista de las 10 vulnerabilidades más críticas en aplicaciones web.
• OWASP ASVS: Marco de trabajo para la verificación de la seguridad de aplicaciones.
• OWASP ZAP: Herramienta para el análisis de vulnerabilidades en aplicaciones web.

OWASP también ofrece formación y eventos para la comunidad de seguridad.

La organización se actualiza constantemente para estar al día con las últimas amenazas y tecnologías.

OWASP es una comunidad global que trabaja por un futuro digital más seguro.

Puntos clave:

OWASP es un recurso invaluable para la seguridad de las aplicaciones web.
Es importante que los desarrolladores y organizaciones se familiaricen con los recursos de OWASP.
La participación en la comunidad de OWASP puede ayudar a mejorar la seguridad del software.

Enlaces útiles:

Página principal de OWASP: https://owasp.org/
OWASP Top Ten: https://owasp.org/www-project-top-ten/
Recursos educativos y eventos: https://owasp.org/www-community/

Conclusión:

OWASP es una organización líder en la seguridad de aplicaciones web. Sus recursos gratuitos son una herramienta esencial para cualquier persona que desarrolle o gestione aplicaciones web. La participación en la comunidad de OWASP puede ayudar a mejorar la seguridad del software para todos.

“Tengo en un servidor Linux un directorio que se llama /bk_datos. Quiero que de otro directorio de mi host llamado /datos_2024 se haga una copia de seguridad total los sábados a las 18:30pm y una copia incremental de Lunes a Viernes a las 22:00pm en el directorio /bk_datos Quiero que uses el comando tar y que comprimas con xz”.

Respuesta 1:

#!/bin/bash
# Ruta del directorio de origen
source_directory="/datos_2024"
# Ruta del directorio de destino
backup_directory="/bk_datos"
# Nombre del archivo de copia de seguridad
backup_file="$backup_directory/backup_$(date +\%Y-\%m-\%d_%H-\%M).tar.xz"
# Verificar si es sábado
if [ "$(date +\%u)" -eq 6 ]; then
# Copia de seguridad total los sábados a las 18:30
tar --listed-incremental="$backup_directory/incremental.snar" -cJf "$backup_file" "$source_directory"
echo "Copia de seguridad total realizada el $(date +\%Y-\%m-\%d_%H-\%M)."
else
# Copia de seguridad incremental de Lunes a Viernes a las 22:00
tar --listed-incremental="$backup_directory/incremental.snar" -cJf "$backup_file" "$source_directory"
echo "Copia de seguridad incremental realizada el $(date +\%Y-\%m-\%d_%H-\%M)."
fi
………………………………………
chmod +x backup_script.sh
# Copia total los sábados a las 18:30
30 18 * * 6 /ruta/al/backup_script.sh
# Copia incremental de lunes a viernes a las 22:00
0 22 * * 1-5 /ruta/al/backup_script.sh

Referencia: https://juncotic.com/tar-backups-incrementales-gnu-linux/

Solo me queda añadir la lógica para que el sábado “expulse” el snapshot y haga un backup total puro y duro creando el fichero de snapshot incremental .snar nuevecito para los subsiguientes incrementales de lunes a viernes.

Conclusión: ChatGPT Me ha ayudado mucho no, ¡muchísimo! pero hay veces que el remate lo tiene que hacer el “ser humano”.

Prompt 2:

“Tengo un partición montada en un directorio que se llama /proyecto_seal y tengo tres usuarios user01, user02 y user03. Quiero que los tres usuarios tengan acceso a este directorio. También quiero una política de cuotas con un soft limit de 2G y periodo de gracia de 3 dias y una hard limit de 5G. Otorga al directorio el permiso apropiado para que ningún usuario de esto tres pueda borrar lo que han creado los otros”

Respuesta 2:

# Asegúrate de que el grupo exista, si no, créalo
sudo groupadd proyecto_seal
# Añade usuarios al grupo
sudo usermod -aG proyecto_seal user01
sudo usermod -aG proyecto_seal user02
sudo usermod -aG proyecto_seal user03
# Cambia el propietario y grupo del directorio
sudo chown :proyecto_seal /proyecto_seal
# Establece permisos para el propietario (dueño del directorio)
sudo chmod 1770 /proyecto_seal
# Permite que los miembros del grupo tengan acceso total
sudo chmod g+rwx /proyecto_seal
# Restringe el acceso a otros usuarios (no propietarios ni del grupo)
sudo chmod o-rwx /proyecto_seal
sudo apt-get install quota
vi /etc/fstab
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /proyecto_seal ext4 defaults,usrquota,grpquota 0 2
sudo mount -o remount /proyecto_seal
sudo quotacheck -cug /proyecto_seal
sudo edquota -u user01
sudo edquota -u user02
sudo edquota -u user03

Prompt 3:

Tengo un fichero de texto con paths completos de directorios, algunos caminos empiezan por /usr/bin/local/ y quiero en estos que empiezan por /usr/bin/local/ y solo en estos eliminar /usr/bin/local/ ¿Me creas un script para realizar esta tarea?

Respuesta 3:

#!/bin/bash
# Verificar si se proporcionó un archivo como argumento
if [ -z "$1" ]; then
echo "Uso: $0 archivo"
exit 1
fi
archivo="$1"
# Verificar si el archivo existe
if [ ! -f "$archivo" ]; then
echo "El archivo '$archivo' no existe."
exit 1
fi
# Crear un archivo temporal para almacenar los resultados
archivo_temporal=$(mktemp)
# Procesar el archivo línea por línea
while IFS= read -r linea; do
# Verificar si la línea comienza con /usr/bin/local/
if [[ "$linea" == "/usr/bin/local/"* ]]; then
# Eliminar /usr/bin/local/ de la línea
nueva_linea="${linea#/usr/bin/local/}"
echo "$nueva_linea" >> "$archivo_temporal"
else
# Conservar la línea tal cual si no comienza con /usr/bin/local/
echo "$linea" >> "$archivo_temporal"
fi
done < "$archivo"
# Sobrescribir el archivo original con los resultados
mv "$archivo_temporal" "$archivo"
echo "Proceso completado. Se ha modificado el archivo '$archivo'."

Y vamos con SAR…

sar es una herramienta de monitorización de recursos en sistemas basados en Unix, como Linux. El nombre «sar» proviene de «System Activity Reporter». Esta utilidad permite recopilar, informar y analizar datos sobre la actividad del sistema, incluyendo el uso de CPU, memoria, E/S (entrada/salida) y otros recursos.

El paquete sar generalmente viene incluido en el conjunto de herramientas de sysstat. Para utilizar sar en Linux, debes asegurarte de que sysstat esté instalado.

Con mucha seguridad el paquete systat estará instalado pero si no procedemos como siempre
Para Centos/Redhat sería algo como esto… yum o dnf

yum install sysstat -y
systemctl start sysstat.service
systemctl enable sysstat.service

Pero ya que estamos con ChatGPT usamos este PROMPT para que nos diga cómo ponerlo en marcha. No obstante la instalación y puesta en marcha de sar/sysstat está francamente bien documentado en montones de sitios web que se encuentran con la oportuna búsqueda en google.

“¿Me explicas detalladamente cómo poner en marcha sar en Linux Centos a partir de la instalación de sysstat?”

Respuesta de ChatGPT:

Paso 1: Instalar sysstat
sudo yum install sysstat

Paso 2: Habilitar y configurar sysstat
sudo nano /etc/sysconfig/sysstat
Dentro de este archivo, asegúrate de que la variable ENABLED esté establecida en "true". Si no está configurada, cámbiala a:
ENABLED="true"

Paso 3: Iniciar y activar el servicio sysstat
sudo systemctl start sysstat
sudo systemctl enable sysstat

Paso 4: Configurar la recopilación automática de datos
La recopilación automática de datos se realiza mediante el cron. 
El archivo /etc/cron.d/sysstat configura la programación de las actividades de recopilación.
Abre el archivo /etc/cron.d/sysstat en un editor de texto:
sudo nano /etc/cron.d/sysstat
Asegúrate de que la tarea cron esté descomentada y configurada según tus necesidades. 
Por defecto, la recopilación de datos se programa cada 10 minutos:
*/10 * * * * root /usr/lib64/sa/sa1 1 1
Puedes ajustar el intervalo según tus preferencias.

Genial respuesta una vez puesto en marcha empezamos ejecutar comandos sar para indagar la carga del sistema en diferentes aspectos…

Esta utilidad permite recopilar, informar y analizar datos sobre la actividad del sistema, incluyendo el uso de CPU, memoria, E/S (entrada/salida), swap, disco, paginación, red, etc.

Vamos a crear prompts para que me genere informes sobre cada uno de estos aspectos.

“ChatGPT voy a arrancar un aplicación en Linux y quiero saber el impacto a nivel de consumo de CPU que va a tener. Créame el comando sar para esta prueba y poder observar el consumo de CPU por la ejecuc.ión de esta aplicación”

Respuesta de ChatGPT: Eso es en el presente.

sar -u 1
Este comando recopilará estadísticas de CPU cada segundo (-u 1) y mostrará el uso de CPU, carga promedio y más.
Ejecuta tu aplicación:
Inicia la aplicación que deseas probar. Mientras se ejecuta, sar continuará recopilando y mostrando estadísticas de CPU cada segundo.
Detén la recopilación de datos de sar:
Puedes detener la recopilación de datos presionando Ctrl + C. Después de esto, sar mostrará un resumen del uso de la CPU durante el período de recopilación.
El comando y la salida se verán algo así: Esto en el presente:

En esta salida, %user representa el porcentaje de tiempo de CPU gastado en el espacio de usuario (aplicaciones), y %system representa el porcentaje de tiempo de CPU gastado en el kernel del sistema.

Observa los valores de %user y %system para evaluar el impacto en el consumo de CPU de tu aplicación durante la ejecución. También puedes ajustar el intervalo de recopilación (1 en el comando -u 1) según tus necesidades para obtener más o menos granularidad en los datos recopilados.

ChatGPT dime cómo evolucionó el consumo de CPU entre las 01:00am y 4:00am del 12 de enero de 2024. Dame por favor el comando sar que debo ejecutar.
Salida de ChatGPT: Esto es una pregunta “hacia el pasado”.

Evolución ficticia
Linux 5.4.0-74-generic (hostname) 12/01/2024 _x86_64_ (1 CPU)

01:00:00 AM CPU %user %nice %system %iowait %steal %idle
01:10:00 AM all 10.00 0.50 5.00 0.00 0.00 84.50
01:20:00 AM all 12.00 0.75 6.00 0.10 0.05 81.10
01:30:00 AM all 15.00 1.00 7.50 0.20 0.10 76.20
...
03:50:00 AM all 25.00 2.00 12.50 0.50 0.25 60.75
04:00:00 AM all 22.50 1.75 11.25 0.30 0.15 64.05

Una vez visto cómo se construye el comando sar para ver el consumo de CPU a través del prompt de ChatGPT, os toca a vosotros extrapolarlo los siguientes aspectos del rendimiento del sistema

Listado de comandos básicos de sar para monitorear diferentes aspectos del sistema, con ejemplos sencillos:
1. Uso de CPU:
Comando:
sar -u 1
Ejemplo:
sar -u 1
Descripción: Muestra estadísticas de uso de CPU cada segundo.
2. Uso de Memoria RAM:
Comando:
sar -r 1
Ejemplo:
sar -r 1
Descripción: Muestra estadísticas de uso de memoria RAM cada segundo.
3. Uso de Swap:
Comando:
sar -S 1
Ejemplo:
sar -S 1
Descripción: Muestra estadísticas de uso de swap cada segundo.
4. Uso de Disco:
Comando:
sar -b 1
Ejemplo:
sar -b 1
Descripción: Muestra estadísticas de E/S de bloque (disco) cada segundo.
5. Paginación:
Comando:
sar -B 1
Ejemplo:
sar -B 1
Descripción: Muestra estadísticas de paginación cada segundo.
6. Estadísticas de Red:
Comando:
sar -n DEV 1 nota DEV seria eth0, eth1, enp0s3, etc
Ejemplo:
sar -n DEV 1
Descripción: Muestra estadísticas de red para cada interfaz de red cada segundo.
Estos comandos te proporcionarán información útil sobre el rendimiento del sistema en tiempo real. Puedes ajustar el intervalo (1 en los ejemplos) según tus necesidades. Recuerda que la disponibilidad de ciertas métricas puede variar según tu sistema operativo y configuración específica.

Muy probablemente ya sar estará up & running en vuestro servidor. Yo personalmente tengo ya unos comandos sar preparados que los utilizo cuando hay una “crisis” las respuestas de ChartGPT complementan y refuerzan mi colección de comando sar para momentos en que el servidor esta impactado y quiero saber que pasó a nivel me memoria, cpu, swap, red, etc en el pasado.

Imagen generada con Bing:

https://www.bing.com/images/create/quiero-ver-al-pinguino-de-linux-tux-navegando-por-/1-65b55c0737984be4a5b094094ac4a36c?id=saGy0f4yGyOzg%2bEOWDH0cw%3d%3d&view=detailv2&idpp=genimg&FORM=GCRIDP&mode=overlay

Enlaces a las clases y los talleres:

Clase 1
https://growthhackingcourse.io/clases-chatgpt/
Clase 2
https://growthhackingcourse.io/clase-2-chatgpt-dominando-los-prompts/
Clase 3
https://growthhackingcourse.io/clase-3-chatgpt-automatizando-la-generacion-de-contenidos/
Taller1:
https://directo.growthhackingcourse.io/taller-chat-gpt-en-directo/
Taller2:
https://www.youtube.com/watch?v=-f2xdGwkO3k

1. Arquitectura Punto a Punto: Conmutadores conectan dispositivos como servidores y sistemas de almacenamiento, permitiendo comunicación directa y eficiente.
2. Alto Ancho de Banda y Baja Latencia: Ofrece velocidades desde 2.5 Gbps hasta 800 Gbps en las versiones más recientes, adecuadas para aplicaciones intensivas en datos.
3. Protocolo de Transporte Propio: Diferente a los protocolos de Ethernet o Fibre Channel, optimizado para transporte eficiente y confiable de datos.
4. Virtualización de Canales: Permite múltiples enlaces lógicos sobre un enlace físico, aumentando la flexibilidad y eficiencia en la gestión del tráfico.
5. Calidad de Servicio (QoS): Capacidades avanzadas para priorizar tráfico y garantizar rendimiento consistente.
6. Soporte de RDMA: Permite acceso directo a la memoria de otros dispositivos sin intervención del procesador, reduciendo latencia.
7. Uso en Clústeres y HPC: Popular en aplicaciones de procesamiento intensivo de datos como simulación científica y modelado financiero.
8. Compatibilidad y Convergencia: Desarrollos en la convergencia con tecnologías Ethernet, permitiendo coexistencia en algunos entornos.

La arquitectura de InfiniBand se caracteriza por componentes como Host Channel Adapters (HCA) y Target Channel Adapters (TCA), conmutadores para enrutamiento y conmutación eficiente, y soporte para virtualización de canal y protocolo de transporte propio. Su escalabilidad, gestión avanzada de QoS, y soporte para múltiples tipos de conexión, como enlaces de cobre y fibra óptica, la hacen ideal para aplicaciones que requieren un transporte rápido y eficiente de grandes cantidades de datos.

El ancho de banda y la latencia son aspectos cruciales de InfiniBand, con tasas de transferencia evolucionando de 2.5 Gbps (SDR) a 800 Gbps en las versiones futuras. La latencia extremadamente baja es fundamental para aplicaciones que requieren respuestas rápidas.

El protocolo de transporte de InfiniBand, orientado a mensajes y con soporte para RDMA, gestiona conexiones confiables y no confiables, y conexiones orientadas a datagramas. Incluye mecanismos sofisticados para la gestión de la congestión y QoS, y es escalable y de alto rendimiento.

La virtualización de canales mejora la flexibilidad y eficiencia de la red, permitiendo una mejor utilización del ancho de banda y una implementación eficiente de QoS. La Calidad de Servicio en InfiniBand gestiona el ancho de banda y prioriza el tráfico, crucial para mantener la eficiencia en redes de alto rendimiento.

El RDMA en InfiniBand permite accesos directos a la memoria de sistemas remotos, reduciendo la latencia y mejorando el rendimiento, especialmente útil en HPC y almacenamiento de datos.

InfiniBand es clave en clústeres y HPC por su bajo ancho de banda y latencia, soporte para RDMA, escalabilidad, y soporte para aplicaciones paralelas y de alto rendimiento. Su convergencia con Ethernet en centros de datos es una tendencia creciente, ofreciendo flexibilidad operativa y optimización de costos, aunque requiere gestión cuidadosa para garantizar rendimiento y priorización efectiva del tráfico.

Foto de Fernando González

La verdad es que el tweet me gustó mucho y me hizo pensar que no había hablado de control de congestión en el podcast todavía, así que le he robado vilmente la idea y hoy voy a hablar en el podcast un poco de control de control de congestión en TCP.

La verdad es que me tocó repasar porque, voy a ser sincero, no lo tenía nada fresco esto, hace mucho tiempo, hace unos 11 ó 12 porque en Tecnocrática tenemos los servidores web con un pequeño tuning para mejorar el rendimiento, pero eso es cosa para otro día.

Fundamentos del Control de Congestión de TCP

Definición y Objetivos del Control de Congestión

El control de congestión en TCP (Protocolo de Control de Transmisión) es un mecanismo diseñado para regular la cantidad de datos que pueden ser enviados a la red sin confirmación. Su principal objetivo es evitar la sobrecarga de la red, que puede ocurrir cuando demasiados paquetes son enviados en un período corto, superando la capacidad de la red para manejarlos eficientemente. Esta regulación es crucial para mantener un rendimiento óptimo y la estabilidad de la red.

La congestión se produce cuando los nodos de la red (como routers y switches) están sobrecargados de datos, lo que lleva a un aumento en el tiempo de retardo y la probabilidad de pérdida de paquetes. El control de congestión busca equilibrar la carga en la red, ajustando dinámicamente la tasa de transmisión de los datos en función de las condiciones actuales de la red. Esto se logra mediante una serie de algoritmos y mecanismos que detectan, previenen y reaccionan ante los signos de congestión.

Problemas Causados por la Congestión de Red

La congestión en una red de datos puede llevar a varios problemas serios, entre ellos:

• Pérdida de Paquetes: Cuando los buffers en los routers se llenan debido a la congestión, los paquetes en exceso son descartados, lo que requiere su retransmisión y, por ende, reduce la eficiencia general de la red.
• Latencia Alta: Un mayor volumen de tráfico en la red puede aumentar significativamente los tiempos de retardo, afectando negativamente la experiencia del usuario, especialmente en aplicaciones en tiempo real como las llamadas VoIP y juegos en línea.
• Fluctuaciones de Throughput: La variabilidad en el throughput (rendimiento) de la red puede ser un signo de congestión intermitente, lo que dificulta la planificación de la capacidad y la calidad del servicio.
• Injusticia en la Asignación de Recursos: Sin un control de congestión efectivo, ciertos flujos de datos pueden monopolizar los recursos de la red, mientras que otros pueden quedar con un ancho de banda insuficiente.

Diferencia entre Control de Congestión y Control de Flujo

Aunque a menudo se confunden, el control de congestión y el control de flujo en TCP son mecanismos distintos diseñados para resolver diferentes problemas:

• Control de Flujo: Se enfoca en la relación entre el emisor y el receptor. Su objetivo es evitar que el emisor sobrecargue al receptor con demasiados datos. Utiliza el mecanismo de ventana deslizante de TCP, donde el receptor anuncia dinámicamente el tamaño de la ventana de recepción (la cantidad de datos que está dispuesto a recibir antes de enviar un acuse de recibo) al emisor, regulando así la velocidad a la que el emisor puede enviar datos.
• Control de Congestión: Por otro lado, el control de congestión se ocupa de la relación entre el emisor y la red. Busca prevenir o mitigar la sobrecarga de datos en la red para mantener un alto rendimiento y evitar la pérdida de paquetes. A diferencia del control de flujo, que es una cuestión de capacidad del receptor, el control de congestión se relaciona con la capacidad de toda la red.

En resumen, mientras que el control de flujo se asegura de que el receptor no se vea abrumado, el control de congestión se asegura de que la red en su conjunto no se vea sobrecargada. Ambos mecanismos trabajan en conjunto para garantizar una transmisión de datos eficiente y fiable en TCP.

Mecanismos Básicos de Control de Congestión en TCP

El control de congestión en TCP emplea varios mecanismos fundamentales para gestionar y mitigar la congestión en las redes. Estos mecanismos trabajan juntos para ajustar la tasa de envío de datos, basándose en la percepción del estado actual de la red. Los más importantes son el Slow Start, Congestion Avoidance, Fast Retransmit y Fast Recovery.

Slow Start (Inicio Lento)

• Funcionamiento: El algoritmo de Slow Start es el primer paso en el control de congestión de TCP. Al iniciar una conexión, TCP no sabe cuánta capacidad está disponible en la red. Por lo tanto, comienza con una tasa de envío conservadora. Inicia con una ventana de congestión pequeña, típicamente de uno o dos segmentos de tamaño máximo de segmento (MSS). Por cada acuse de recibo (ACK) recibido, el tamaño de la ventana de congestión se incrementa en un MSS, lo que lleva a un aumento exponencial del tamaño de la ventana por cada RTT (Round-Trip Time).
• Objetivo: El objetivo es aumentar rápidamente la tasa de transmisión hasta encontrar la capacidad de la red, sin iniciar la transferencia con una carga pesada que podría provocar inmediatamente congestión.

Congestion Avoidance (Evitación de la Congestión)

• Funcionamiento: Una vez que la ventana de congestión alcanza un umbral específico (el umbral de congestión), el algoritmo de Congestion Avoidance toma el control. A partir de este punto, el aumento del tamaño de la ventana de congestión es más conservador. En lugar de duplicar la ventana cada RTT, se incrementa en un MSS por cada RTT, resultando en un crecimiento lineal. Este crecimiento más lento ayuda a evitar la saturación de la red.
• Objetivo: El principal objetivo es mantener el flujo de datos en un nivel sostenible para evitar la congestión, aumentando gradualmente el tamaño de la ventana de congestión mientras se monitoriza el rendimiento de la red.

Fast Retransmit (Retransmisión Rápida)

• Funcionamiento: Fast Retransmit es un mecanismo que mejora la eficiencia de la red al reducir el tiempo necesario para recuperarse de la pérdida de paquetes. Cuando un emisor recibe tres acuses de recibo duplicados (tres ACKs para el mismo segmento de datos), asume que un segmento se ha perdido y lo retransmite inmediatamente sin esperar a que expire el temporizador de retransmisión.
• Objetivo: Este mecanismo está diseñado para responder rápidamente a la pérdida de paquetes, una señal común de congestión en la red, minimizando así el impacto negativo en el rendimiento.

Fast Recovery (Recuperación Rápida)

• Funcionamiento: Fast Recovery trabaja en conjunto con Fast Retransmit. Una vez que se retransmite el paquete perdido, en lugar de reducir drásticamente la ventana de congestión y comenzar desde Slow Start, TCP entra en un estado de recuperación rápida. En este estado, la ventana de congestión se reduce a la mitad del tamaño que tenía cuando se detectó la pérdida. Luego, por cada ACK duplicado recibido, el tamaño de la ventana de congestión se incrementa en un MSS, hasta que todos los datos pendientes son reconocidos.
• Objetivo: El objetivo de Fast Recovery es reanudar rápidamente una tasa de transferencia efectiva después de una pérdida de paquetes, evitando el proceso más lento de Slow Start y aprovechando la información obtenida de los ACKs duplicados para ajustar el tamaño de la ventana.

En resumen, estos cuatro mecanismos son fundamentales para el eficiente control de congestión en TCP. El Slow Start permite a TCP iniciar la transmisión de datos de manera conservadora, aumentando exponencialmente el tamaño de la ventana hasta encontrar un límite sostenible. La Evitación de Congestión mantiene el crecimiento de la ventana en un ritmo lineal para evitar la saturación de la red. Fast Retransmit y Fast Recovery trabajan juntos para responder rápidamente a la pérdida de paquetes, permitiendo a TCP recuperar su tasa de transmisión de manera eficiente y minimizar la interrupción en la transferencia de datos.

Algoritmos Avanzados de Control de Congestión

Los algoritmos avanzados de control de congestión en TCP representan una evolución en la forma en que TCP gestiona la congestión y la pérdida de paquetes. Estos algoritmos incluyen Tahoe, Reno, NewReno, CUBIC y BBR, cada uno con características únicas adaptadas a diferentes escenarios de red.

Tahoe, Reno, y NewReno: Evolución y Diferencias en la Respuesta a la Pérdida de Paquetes

• Tahoe: Este fue uno de los primeros algoritmos en implementar los mecanismos de Fast Retransmit y Fast Recovery. En Tahoe, cuando se detecta una pérdida de paquetes (a través de tres ACKs duplicados o un timeout), la ventana de congestión se reduce a 1 MSS, y el algoritmo entra en Slow Start. Aunque eficaz en su época, Tahoe puede ser demasiado conservador, ya que reinicia el proceso de Slow Start tras cada pérdida detectada.
• Reno: Representa una mejora sobre Tahoe. Al igual que Tahoe, utiliza Fast Retransmit, pero difiere en su manejo de Fast Recovery. En Reno, cuando se detecta una pérdida de paquetes por ACKs duplicados, la ventana de congestión se reduce a la mitad, y no se reinicia completamente como en Tahoe. Esto permite una recuperación más rápida, ya que el algoritmo entra en Congestion Avoidance en lugar de Slow Start.
• NewReno: Mejora aún más el proceso de Fast Recovery. A diferencia de Reno, que solo puede recuperarse de una única pérdida de paquetes durante Fast Recovery, NewReno puede manejar múltiples pérdidas de paquetes. Si se detectan más pérdidas después de entrar en Fast Recovery, NewReno puede retransmitir los paquetes perdidos sin necesidad de salir de este modo, lo que mejora la eficiencia en situaciones con múltiples pérdidas de paquetes.

CUBIC: Algoritmo Utilizado por Linux, Adaptación en Función de la Latencia de la Red

CUBIC:Es el algoritmo de control de congestión predeterminado en muchas variantes de Linux.

CUBIC es diferente de los algoritmos basados en AIMD (Additive Increase/Multiplicative Decrease) como Tahoe, Reno y NewReno. Utiliza una función cúbica para aumentar la ventana de congestión, lo que permite un escalado más rápido de la ventana en redes con grandes capacidades de ancho de banda y alta latencia (redes de larga distancia). CUBIC es menos sensible a la pérdida de paquetes y más a los cambios en el retardo, lo que lo hace adecuado para redes modernas de alta capacidad.

BBR (Bottleneck Bandwidth and Round-trip Propagation Time): Enfoque en el Ancho de Banda y el Tiempo de Ida y Vuelta

BBR (Bottleneck Bandwidth and RTT): Desarrollado por Google, BBR es un algoritmo de control de congestión que se centra en maximizar la utilización del ancho de banda disponible y minimizar la latencia. BBR no se basa en la detección de pérdidas para ajustar la ventana de congestión. En su lugar, estima el ancho de banda del cuello de botella y el RTT mínimo para determinar el ritmo óptimo de envío de paquetes. Este enfoque permite que BBR gestione eficazmente la congestión, incluso en redes con altas tasas de pérdida de paquetes, ofreciendo mejoras significativas en el rendimiento en comparación con los algoritmos basados en pérdidas.

En resumen, estos algoritmos avanzados de control de congestión representan diferentes enfoques y estrategias para optimizar el rendimiento de la transmisión de datos en TCP. Tahoe, Reno, y NewReno se centran en mejorar la respuesta a la pérdida de paquetes, mientras que CUBIC y BBR se adaptan mejor a las redes modernas de alta capacidad, ofreciendo soluciones más eficientes para el control de la congestión en diversos entornos de red.

Impacto del Control de Congestión en Diferentes Tipos de Red

El control de congestión en TCP desempeña un papel vital en la gestión del tráfico de datos en diferentes tipos de redes. La eficacia y necesidad de los mecanismos de control de congestión pueden variar significativamente dependiendo de las características específicas de cada red, como la latencia, el ancho de banda disponible, y la probabilidad de pérdida de paquetes. Esto es particularmente evidente al comparar Redes de Área Local (LAN) con Redes de Área Amplia (WAN) y Redes Móviles.

Redes LAN vs. WAN: Cómo Varía el Control de Congestión

• Redes LAN:
  • Características: Las LAN generalmente tienen baja latencia y alta capacidad de ancho de banda. La congestión es menos frecuente en las LAN debido a su corta distancia y a su infraestructura de red, que a menudo es de alta calidad y bien mantenida.
  • Impacto del Control de Congestión: En las LAN, los algoritmos de control de congestión de TCP pueden no ser tan críticos o necesarios como en otros entornos. La baja latencia y el alto ancho de banda hacen que la red sea menos susceptible a la congestión, por lo que los mecanismos como Slow Start y Congestion Avoidance pueden no tener un impacto significativo en el rendimiento general.
• Redes WAN:
  • Características: Las WAN, en contraste, se caracterizan por tener mayor latencia y un ancho de banda más variable. Estas redes abarcan distancias más largas y pueden incluir enlaces con capacidades de ancho de banda muy diferentes.
  • Impacto del Control de Congestión: En las WAN, los algoritmos de control de congestión son fundamentales para mantener la estabilidad y eficiencia de la red. La variabilidad en la latencia y el ancho de banda hace que sea esencial un ajuste cuidadoso de la tasa de envío de datos para evitar la sobrecarga de los enlaces. Los mecanismos de control de congestión de TCP, como Fast Retransmit y Fast Recovery, son clave para responder rápidamente a la congestión y mantener un flujo de datos constante.

Redes Móviles: Desafíos Únicos y Adaptaciones en TCP

• Desafíos en Redes Móviles:
  • Variabilidad en la Conexión: Las redes móviles enfrentan desafíos únicos debido a su naturaleza inalámbrica, como variabilidad en la calidad de la señal, cambios frecuentes en las condiciones de la red y tasas de error más altas.
  • Cambios de Red y Movilidad: Los usuarios en redes móviles pueden cambiar entre diferentes tipos de redes (como pasar de 4G a Wi-Fi), lo que puede resultar en fluctuaciones significativas en el rendimiento y la disponibilidad de la red.
  • Latencia y Pérdida de Paquetes: La latencia puede variar significativamente, y la pérdida de paquetes es más común, lo que puede ser malinterpretado por los algoritmos de control de congestión como señales de congestión de red.
• Adaptaciones en TCP para Redes Móviles:
  • Algoritmos de Control de Congestión Adaptativos: Para abordar estos desafíos, se han desarrollado variantes de TCP específicas para entornos móviles, como TCP Vegas, que utiliza medidas de retardo para detectar y controlar la congestión, y TCP Westwood, que ajusta el tamaño de la ventana de congestión basándose en la estimación del ancho de banda disponible.
  • Mejoras en la Detección de Congestión: Estas variantes mejoran la forma en que TCP interpreta la pérdida de paquetes y los cambios en la latencia, diferenciando mejor entre la congestión real y las características inherentes de las redes móviles.
  • Optimizaciones para Movilidad: Además, se han realizado esfuerzos para mejorar la capacidad de TCP para manejar cambios en la conectividad y movilidad, como en MPTCP (Multipath TCP), que permite a TCP usar múltiples rutas para enviar y recibir datos, aumentando la robustez y eficiencia en entornos móviles.

En conclusión, el control de congestión en TCP varía considerablemente

Diseño de red modular

Consideraciones de ancho de banda y latencia

Redundancia y alta disponibilidad

Tecnologías de encaminamiento y conmutación

Comprende protocolos como OSPF, ISIS, BGP, y STP.

Diseños de Data Center

Incluye arquitecturas como la espina dorsal-hoja (Spine-Leaf) y consideraciones para virtualización y almacenamiento.

Introducción a BGP y Confederaciones

• BGP (Border Gateway Protocol): Es el protocolo de routing estándar utilizado para intercambiar información de routing entre sistemas autónomos (AS) en Internet.
• Confederaciones en BGP: Son una técnica utilizada para gestionar sistemas autónomos grandes y complejos. Permiten dividir un único AS en varios ASes más pequeños, mejorando la administración y la escalabilidad.

Usos de Confederaciones en BGP

1. Escalabilidad: Al dividir un AS grande en varios ASes más pequeños, las confederaciones reducen la complejidad y el tamaño de las tablas de routing.
2. Gestión de Políticas: Facilitan la gestión de políticas de routing, ya que cada AS en la confederación puede tener su propia política.
3. Control de Tráfico: Permiten un mayor control sobre el flujo de tráfico, ya que los cambios de política pueden aplicarse a pequeñas secciones del AS.
4. Reducción de la Convergencia: Ayudan a reducir los tiempos de convergencia en caso de cambios de routing.

Aplicación de Confederaciones en BGP

• Redes Grandes: Son especialmente útiles en redes muy grandes que requieren una gestión compleja y detallada del routing.
• Proveedores de Servicios: Los ISP suelen utilizar confederaciones para gestionar de manera eficiente sus grandes redes.
• Organizaciones con Múltiples Divisiones: Organizaciones que operan múltiples redes pueden utilizar confederaciones para gestionar estas redes como si fueran ASes independientes.
• Modificación del nexthop: No, las sesiones de eBGP entre subAS de confederación no modifican el atributo de next hop.  Los valores MED y de local preference  también permanecen inalterados entre los pares eBGP de la confederación.

Configuración de Confederaciones en BGP

1. Definición de la Confederación: Se debe definir la confederación y sus miembros en la configuración del router.
   • Ejemplo: router bgp 65000 (donde 65000 es el número del AS de la confederación).
   • bgp confederation identifier 12345.
   • bgp confederation peers 65001 65002 (donde 65001 y 65002 son los ASes miembros).
2. Configuración de Vecinos BGP: Configurar los vecinos BGP dentro de los ASes miembros de la confederación.
   • Ejemplo: neighbor 192.168.1.1 remote-as 65001.
3. Políticas de routing: Definir políticas de routing específicas para cada AS miembro.
   • Utilización de listas de acceso, mapas de ruta y listas de prefijos.
4. Optimización y Pruebas: Tras la configuración inicial, se deben realizar pruebas para asegurar que la red opera como se espera.
   • Monitorización del intercambio de rutas.
   • Ajustes de políticas según sea necesario.

Consideraciones Adicionales

• Diseño de la Red: La decisión de utilizar confederaciones debe basarse en una comprensión profunda del diseño y las necesidades de la red.
• Compatibilidad con Dispositivos: Asegurarse de que todos los dispositivos en la red son compatibles con BGP y las confederaciones.
• Seguridad en BGP: Implementar medidas de seguridad como BGPsec para proteger contra anuncios de rutas malintencionados.

Configuración de Router Cisco para Confederaciones BGP

Configuración del Router A (AS miembro 65001)

router bgp 65001
bgp confederation identifier 12345
bgp confederation peers 65002
neighbor 192.168.12.2 remote-as 65002
neighbor 192.168.10.1 remote-as 12345
network 10.1.1.0 mask 255.255.255.0

Explicación:

• router bgp 65001: Inicia la configuración BGP para el AS miembro 65001.
• bgp confederation identifier 12345: Define el identificador de la confederación como 12345.
• bgp confederation peers 65002: Establece el AS 65002 como un par en la confederación.
• neighbor 192.168.12.2 remote-as 65002: Establece un enlace BGP con el Router B, que está en el AS 65002.
• neighbor 192.168.10.1 remote-as 12345: Configura un enlace con el AS principal de la confederación.
• network 10.1.1.0 mask 255.255.255.0: Anuncia la red 10.1.1.0/24 en BGP.

Configuración del Router B (AS miembro 65002)

router bgp 65002
bgp confederation identifier 12345
bgp confederation peers 65001
neighbor 192.168.12.1 remote-as 65001
neighbor 192.168.20.1 remote-as 12345
network 10.2.2.0 mask 255.255.255.0

Explicación:

• router bgp 65002: Inicia la configuración BGP para el AS miembro 65002.
• bgp confederation identifier 12345: Define el identificador de la confederación como 12345.
• bgp confederation peers 65001: Establece el AS 65001 como un par en la confederación.
• neighbor 192.168.12.1 remote-as 65001: Establece un enlace BGP con el Router A, que está en el AS 65001.
• neighbor 192.168.20.1 remote-as 12345: Configura un enlace con el AS principal de la confederación.
• network 10.2.2.0 mask 255.255.255.0: Anuncia la red 10.2.2.0/24 en BGP.

Ejemplo de Configuración para Conectar una Confederación BGP con un AS Externo

Supongamos que tienes dos routers en tu confederación (Router A en el AS 65001 y Router B en el AS 65002), y deseas conectar tu confederación con un router en el AS externo 6800.

Configuración en el Router de la Confederación (Router A o Router B)

Elije uno de los routers en tu confederación para establecer la conexión con el AS externo. Supongamos que usamos el Router A para esta conexión.

router bgp 65001
bgp confederation identifier 12345
bgp confederation peers 65002
neighbor 192.168.12.2 remote-as 65002
neighbor 192.168.30.1 remote-as 6800 ! Vecino en AS externo

Explicación:

• neighbor 192.168.30.1 remote-as 6800: Esta línea añade un nuevo vecino BGP que está en el AS externo 6800. La IP 192.168.30.1 deberá ser la dirección del interfaz del router en el AS 6800 con el que estás estableciendo la conexión.

Configuración en el Router del AS Externo

En el router del AS externo (AS 6800), debes configurar un vecino BGP que apunte al router de tu confederación.

router bgp 6800
neighbor 192.168.30.2 remote-as 12345

1. Fibra Monomodo: Los cables de fibra monomodo a menudo tienen una cubierta amarilla. Esto facilita su identificación rápida en entornos donde se utilizan tanto fibras monomodo como multimodo.
2. Fibra Multimodo: OM1, OM2, OM3, OM4, OM5

1. Contratar la sala en un Tier IV.
2. Controles de acceso.
3. Esperar que se ponga el suelo falso y se termine la obra para adecuar la sala.
4. Poner los racks.
5. Montar los rejiband y los fiberrunner.
6. Pedir al menos un patch con posiciones contra la MMR.
7. Pedir tránsitos y fibra oscura.
8. Pedir parcheos contra las posiciones de la MMR.
9. Llevar equipos de comunicaciones.
10. Tener planificado el direccionamiento.
11. Preparar un nivel 2 para conectar clientes.
12. Preparar el parcheo entre los racks del cubo para dar conectividad (con patch idealmente).
13. Una vez tienes conectividad ya puedes empezar a traerte cliente.

El audio de hoy es un resumen de la RFC 9099 que hace referencia a las consideraciones de seguridad en la implementación y despliegue del protocolo IPv6, particularmente en comparación con su predecesor IPv4. Se señalan preocupaciones y recomendaciones específicas en relación a la seguridad en IPv6:

1. Direcciones IPv6: Se habla de los retos que presenta la amplia gama de direcciones IPv6, su autoconfiguración, y la importancia de tener un plan de direccionamiento adecuado.
2. Encabezados de Extensión: IPv6 introduce estos encabezados, que son una diferencia clave respecto a IPv4. Es necesario entender cómo se manejan y las implicaciones de seguridad que tienen.
3. Seguridad en capa de enlace: Se menciona la dependencia del Protocolo de Descubrimiento de Vecinos (NDP) y sus vulnerabilidades, la necesidad de limitar la tasa de solicitudes de vecinos, la importancia de asegurar DHCPv6 y las consideraciones específicas de seguridad para enlaces 3GPP, entre otros.
4. Seguridad en el plano de control: Se habla sobre cómo proteger el plano de control de posibles ataques y cómo configurar listas de control de acceso (ACL) para filtrar paquetes no deseados.
5. Seguridad en el encaminamiento de IPv6: Se aborda la seguridad de enrutamiento en IPv6, especialmente en relación con el protocolo BGP y OSPFv3, y las consideraciones específicas para la autenticación de vecinos en OSPFv3.

En esencia, en la RFC 9099 trata de la importancia de ser proactivo en la gestión de la seguridad al desplegar o trabajar con IPv6, considerando las particularidades y desafíos que este protocolo introduce en comparación con IPv4.

También se abordan las tecnologías de transición y coexistencia para las redes IPv4 e IPv6, particularmente los mecanismos «Dual Stack», mecanismos de encapsulación y técnicas de túnel.

1. Dual Stack: Permite que IPv4 e IPv6 coexistan en una red.
   • Ventajas: Minimiza el impacto en operaciones IPv4 y proporciona una transición fluida a IPv6.
   • Contras: Aumenta la complejidad y duplica los riesgos de seguridad.
2. Mecanismos de Encapsulación y Túneles: Se presentan diversos tipos de túneles, cada uno con sus propios beneficios y desafíos de seguridad. Es esencial tomar precauciones, como usar IPsec y aplicar filtros.
3. Mecanismos de Traducción: Estas estrategias permiten la coexistencia de IPv4 e IPv6 y tienen sus propias consideraciones de seguridad. Uno de los ejemplos es el «Carrier-Grade NAT».
4. Endurecimiento de Dispositivos: Con la prevalencia de IPv6 en dispositivos, es esencial aplicar medidas de seguridad como restringir accesos, monitorizar, desactivar servicios no utilizados y aplicar protocolos criptográficamente protegidos.
5. Consideraciones de Seguridad para Empresas: Las empresas deben tener políticas de seguridad comparables para IPv4 e IPv6. Se abordan tanto las medidas de seguridad externas como internas.
6. Consideraciones para Proveedores de Servicios y Usuarios Residenciales: Se discuten las amenazas y las técnicas de mitigación adecuadas para estos grupos, subrayando la importancia de una política de seguridad de doble pila para los usuarios residenciales.
7. Lecturas Adicionales y Consideraciones de Seguridad: Se ofrecen recomendaciones y una visión general de la seguridad en redes IPv6, abarcando tanto redes puras IPv6 como combinadas con IPv4.

En general, la RFC 9099 destaca la necesidad de adoptar medidas de seguridad robustas en la transición y coexistencia de IPv4 e IPv6, dada la creciente prevalencia y relevancia de IPv6 en el mundo de las redes.

Entre las tecnologías que facilitan esto están QinQ (apila VLANs para su transporte), VXLAN (extiende redes de capa 2 usando redes de capa 3), OTV (solución de Cisco para data centers) y MPLS (aunque no específicamente para VLAN, servicios como VPLS pueden extender VLANs usando MPLS).

Al adoptar estas soluciones, es crucial considerar la topología de la red, evaluar el rendimiento, implementar medidas de seguridad y, si se busca movilidad de máquinas virtuales, considerar aspectos como latencia y consistencia de políticas.

En resumen, la extensión tunelizada de VLANs es una herramienta valiosa para conectar recursos, pero requiere planificación y gestión adecuadas.

ACTUALIZACIÓN:

Aitor me manda este mensaje por telegram

Por añadir un detalle interesante en ese VXLAN enrutado sin EVPN ni nada, también corre usando multicast, tienes varias de las ventajas y sin muchas de las complejidades de EVPN, como tener que usar BGP

Foto de Burak The Weekender: https://www.pexels.com/es-es/foto/foto-de-lapso-de-tiempo-del-tunel-730134/

Esta solución es vital en lugares como los Centros de Proceso de Datos (CPD), que generan mucho calor.

El método puede ser directo, introduciendo aire frío al espacio; indirecto, usando un intercambiador de calor; o mediante agua de fuentes frías naturales.

Sus ventajas incluyen ahorro energético, menor impacto ambiental, reducción en el mantenimiento y prolongación de la vida útil de equipos.

No obstante, su eficacia depende de factores como la ubicación geográfica y calidad del aire.

Es una opción sostenible y económicamente inteligente, pero requiere evaluación y adaptación según las circunstancias específicas de cada instalación.

Foto de Galvão Menacho: https://www.pexels.com/es-es/foto/foto-de-persona-sosteniendo-un-ventilador-electrico-2877256/

Control Total

Una de las razones principales para optar por tener tus propios servidores en un centro de datos es el control total que obtienes sobre tus recursos informáticos, o como a los marketinianos les gusta llamarlos los «activos digitales». Cuando alojas tus servidores en una nube pública, estás confiando en un proveedor externo para gestionar y mantener esos servidores. Si bien esto puede ser conveniente en algunos casos, también significa que tienes limitaciones en cuanto a cómo puedes configurar y personalizar tus servidores.

En contraste, cuando tienes tus propios servidores en un centro de datos, tienes el control total sobre la infraestructura. Puedes personalizar cada aspecto de tus servidores para satisfacer tus necesidades específicas. Esto es especialmente importante para empresas que tienen requisitos particulares en cuanto a rendimiento, seguridad y compatibilidad.

Seguridad y Privacidad

La seguridad y la privacidad son preocupaciones fundamentales en el mundo digital de hoy en día. Cuando utilizas una nube pública, estás confiando en el proveedor de la nube para proteger tus datos y servidores. Aunque muchos proveedores de nube tienen altos estándares de seguridad, aún existe el riesgo de que tus datos puedan ser comprometidos debido a un fallo en el proveedor o un ataque dirigido.

Tener tus propios servidores en un centro de datos te brinda un mayor control sobre la seguridad y la privacidad de tus datos. Puedes implementar tus propias políticas de seguridad, configurar cortafuegos personalizados y tomar medidas adicionales para proteger tu infraestructura. Esto es especialmente importante si manejas datos sensibles o confidenciales, como información financiera o de clientes.

Rendimiento Personalizado

El rendimiento es otro aspecto crucial en la elección entre una nube pública y tus propios servidores. Cuando utilizas una nube pública, al final estás compartiendo recursos con otros usuarios. Esto significa que el rendimiento de tus servidores puede verse afectado por las cargas de trabajo de otros clientes en la misma nube. Si necesitas un rendimiento consistente y personalizado, tener tus propios servidores te da la ventaja de poder configurarlos de acuerdo a tus necesidades específicas.

Además, tener servidores dedicados en un centro de datos te permite escalar tu infraestructura de manera más eficiente. Puedes agregar más capacidad de procesamiento, almacenamiento o memoria según lo requieras, sin depender de las limitaciones de una nube pública.

Cumplimiento Regulatorio

Para muchas empresas, el cumplimiento regulatorio es un factor crítico a considerar. Dependiendo de tu industria y ubicación geográfica, es posible que debas cumplir con ciertos requisitos legales y normativas relacionados con la seguridad y la privacidad de los datos. Tener tus propios servidores en un centro de datos te permite un mayor control sobre el cumplimiento de estas regulaciones.

Puedes implementar medidas específicas para cumplir con los estándares de tu industria y mantener un registro detallado de cómo se gestionan tus datos. Esto puede ser mucho más complicado de lograr en una nube pública, donde el proveedor puede estar sujeto a regulaciones diferentes a las tuyas.

Costes a Largo Plazo

Si bien puede parecer que alojar tus servidores en una nube pública es más económico a corto plazo debido a la falta de gastos iniciales de infraestructura, es importante considerar los costes a largo plazo. Los servicios de nube suelen tener modelos de precios basados en suscripción que pueden aumentar con el tiempo a medida que tu infraestructura crece.

Por otro lado, cuando tienes tus propios servidores, tienes un coste inicial más alto para adquirir y configurar la infraestructura, pero los costes operativos a largo plazo pueden ser más predecibles y, en muchos casos, más bajos. Esto es especialmente cierto si planeas mantener tus servidores durante varios años.

Realmente al final tus costes son el coste del armario o rack y el coste del tránsito o conectividad.

Flexibilidad y Personalización

La flexibilidad y la personalización son aspectos clave que pueden influir en tu decisión. Cuando alojas tus servidores en una nube pública, estás limitado por las opciones y configuraciones que ofrece el proveedor de la nube. Si deseas una solución altamente personalizada o necesitas ejecutar software específico, es posible que te encuentres con restricciones.

Tener tus propios servidores te brinda la libertad de personalizar tu infraestructura según tus necesidades. Puedes seleccionar los componentes de hardware y software que mejor se adapten a tu carga de trabajo y objetivos comerciales.

Confiabilidad y Disponibilidad

La confiabilidad y la disponibilidad son esenciales para cualquier empresa. Si tus servidores están fuera de servicio, tu negocio puede sufrir graves interrupciones. Cuando dependes de una nube pública, estás en manos del proveedor de la nube para garantizar la disponibilidad.

Tener tus propios servidores en un centro de datos te permite implementar medidas de alta disponibilidad y recuperación ante desastres a medida de tus necesidades. Puedes configurar sistemas redundantes y realizar copias de seguridad de tus datos de manera más específica para garantizar que tu negocio pueda seguir funcionando incluso en caso de problemas.

Conclusiones

En resumen, la elección entre tener tus propios servidores en un centro de datos y utilizar una nube pública depende de tus necesidades comerciales específicas y tus prioridades. Si valoras el control total, la seguridad, el rendimiento personalizado, el cumplimiento regulatorio, los costes a largo plazo, la flexibilidad, la confiabilidad y la disponibilidad, tener tus propios servidores en un centro de datos puede ser la mejor opción.

Sin embargo, es importante destacar que no existe una respuesta única para todas las situaciones. Algunas empresas pueden encontrar que una combinación de ambas opciones, conocida como «nube híbrida», es la más adecuada para ellas. En última instancia, la elección dependerá de tus objetivos comerciales y recursos disponibles, pero es esencial considerar todas las implicaciones antes de tomar una decisión informada sobre dónde alojar tus servidores y datos.

En agosto, decidí probar la opción de desplazarme en bicicleta hacia la oficina siempre que me fue posible. La experiencia fue muy satisfactoria, y de hecho, logré acumular un total de 600 kilómetros según mi GPS. Es importante mencionar que no registré todos mis trayectos con el GPS, pero considero que completar 600 km en bicicleta en un solo mes es una cifra bastante respetable y justifica tener una bicicleta para ir al trabajo.

Para el regreso a casa, normalmente opté por utilizar el tren, a excepción de un par de días en los que me animé y también regresé en bicicleta.

El trayecto diario hasta la oficina abarca una distancia de 41 km, y logro completarlo en menos de 2 horas y media. Creo que es un tiempo bastante aceptable, especialmente teniendo en cuenta que las ruedas de mi bicicleta tienen un diámetro ligeramente superior a las 16 pulgadas, y no estoy compitiendo en una carrera.

En resumen, la experiencia ha sido extremadamente positiva, y tengo la intención de intentar repetirla en septiembre. Continuaré compartiendo mis experiencias en este espacio.

El tema social es muy interesante, pero a mi me ha llamado la atención el tema de los bots, porque se hablaba de un bot llamado CCBot que debe de ser un bot con un gusto excelente porque por esta web ya ha pasado, de hecho este año lleva ya 688 visitas, que no son muchas, pero sí las suficientes para haber visto lo que le interesaba y haberlo procesado.

Además tenemos el bot GPTBot que ha visitado este humilde blog ya 1495 veces.

No se qué hará ese bot en concreto, pero parece ser que alimenta a Common Crawl, uno de los mayores conjuntos de datos de IA. El bot BGPBot supongo que como su nombre indica es el bot de ChatGPT y GPT-4.

El tema aquí está en que si esos bots revisan tu web y luego sirven el contenido desde sus aplicaciones, por supuesto sin mencionar desde donde lo han obtenido, al final la gente va a dejar de revisar las webs.

Ante esto hay quien prefiere bloquear estos bots, realmente los user-agent que usan, ¿pero como se hace?, simplemente modificando en el .htaccess de tu web y añadiendo un par de líneas como estas:

#BLOQUEAR CRAWLERS INDESEADOS
RewriteCond %{HTTP_USER_AGENT} (CCBot|GPTBot) [NC]
RewriteRule .* - [R=403,L]

Obviamente a la lista podéis añadir todos aquellos bots que consideréis indeseables para vuestra web.

Ahora, ¿esto sirve para algo? Pues sí, si una visita se identifica con un bot de ese tipo le dará un 403 y no podrá cargar la web.

Todo tiene su user-agent, por ejemplo, si usáis Firefox el user-agent será Mozilla/5.0, pero esto es cambiable, para hacerlo podéis seguir los siguientes pasos:

1. Abrir about:config
2. Aceptar el aviso
3. Buscar general.useragent.override, que no va a estar.
4. Pinchar en cadena y en el botón +
5. Ahora te saldrá un recuadro para rellenar, ahí puedes poner el user-agent que quieras

Una vez cambiado el user-agent cuando visites una web saldrá el user-agent que le hayas puesto ahí.

Foto de cabecera de Mat Kedzia: https://www.pexels.com/es-es/foto/foto-de-primer-plano-de-la-arana-2091017/

Realmente lo básico que podemos hacer para protegernos son 4 cosas:

• Portfast
• BPUGuard
• BPDUFilter
• RootGuard

Portfast

En Spanning Tree tenemos varios estados por los que tiene que pasar un puerto antes de ponerse en fordward o envío, ya sabéis: desactivado, bloqueo, escucha, aprendizaje y envío.

Si habilitamos el portfast el puerto va a pasar automáticamente de bloqueo a envío, ni va a aprender macs antes ni nada, directamente se pone en forwarding.

Este es muy útil en puertos que tengan un host en el que estén conectado en un puerto de acceso y que necesite DHCP. Poniendo ejemplos de centros de datos podríamos configurar así un puerto de una iDRAC, IPMI o como vuestro fabricante favorito llame al puerto de consola remota y que por algún motivo, que no llevo a comprender, en vez de configurar la IP fija se le pone DHCP. En ese caso necesitaríamos que el puerto pase directamente a forwarding.

Es decir, usaremos portfast en un puerto de los denominados edge.

La configuración en un nexus será:

switch(config)# int ethernet 1/45
switch(config-if)# spanning-tree port type edge

Y en un catalyst, si alguien aún tiene podría ser

switch(config)# int ethernet 1/45
switch(config-if)# spanning-tree portfast

También podríamos hacer que los puertos por defecto estén en portfast, esto lo haremos:

switch(config)# spanning-tree portfast default

Pero a mi eso no me gusta demasiado y por eso prefiero ir puerto por puerto.

Aquí estamos haciendo trampa pues también existe el comando

switch(config)# int ethernet 1/45
switch(config-if)# spanning-tree port type edge trunk

¿Cómo que port type edge trunk? ¿Qué brujería es esta?

Mente abierta, porque es posible que tengamos un servidor con varias vlans, varios subinterfaces, ese es el motivo, pero eso sí, siempre son puertos de edge, nunca un switch.

BPUGuard

Si portfast lo que hace es saltarse los estados de Spanning Tree ¿cómo hacemos para que el puerto caiga si recibe alguna BPDU?, para eso tenemos el BPDUGuard.

Cuando habilitamos el BPDUGuard si se recibe una BPDU por ese puerto el puerto se queda en el estado errdisable.

¿Es recomendable usar esto? Pues depende qué tengamos conectado al otro lado, si lo que hay es un servidor pues el portfast es suficiente, pero si es un switch y queremos que el puerto caiga si recibimos por ahí BPDUs es muy reoocmendalbe poner el bpduguard.

switch(config)# int ethernet 1/45
switch(config-if)# spanning-tree port type edge trunk
switch(config-if)# spanning-tree bpduguard enable

Por supuesto también se puede habilitar globalmente, pero como antes, no os lo recomiendo.

No lo he dicho, pero para quitar el errdisable primero se soluciona el problema y luego se tira el puerto y se vuelve a levantar.

BPDU Filter

Esta funcionalidad es algo parecido a desactivar el Spanning Tree en un puerto. El BPDUFilter lo que hace es dejar de eviar BPDUs por ese puerto y obviamente no espera recibir BPDUs por ahí.

Esto para configurarlo es:

switch(config)# int ethernet 1/45
switch(config-if)# spanning-tree port type edge trunk
switch(config-if)# spanning-tree bpdufilter enable

Si configuramos BPDUfilter en dos switches enfrentados y configuramos los puertos como portfast el puerto levantará.

Esta característica yo no la uso demasiado, pero oye, ahí está por si la necesitáis para lo que sea.

Por supuesto también se puede habilitar globalmente.

RootGuard

Esta característica sí que me resulta muy interesante en redes en las que tenéis nodos centrales, algo muy común.

Imaginad que tenéis una red en la que tenéis un par de switches más grandes donde concentráis todo y queréis que esos switches sean el root del spanning tree.

Por supuesto le definís que sean el root del spanning tree, pero tenemos que prevenir que un switch por debajo se llegue a convertir en el root de spanning tree de la red, es decir, estamos indicando donde debe de estar el root en la red.

Aquí hay un tema que quizás parezca un poco confuso y es la diferencia entre BPDUGuard y RootGuard. En BPDUGuard lo que hacemos es desabilitar un puerto si recibe una BPDU y ponerlo en errdisable, mientras que en RootGuard si recibe BPDU que indique ese es un root port, es decir, que por ahí se va al root lo que hace es poner el puerto en inconsistente y bloquear el puerto.

La configuración sería:

switch(config)# int ethernet 1/45
switch(config-if)# spanning-tree guard root

Empecé a utilizar Twitter en Marzo de 2007, toda una vida dirían algunos, pero a veces la vida toma caminos extraños que no podemos controlar, eso es lo que está pasando con Twitter.

Cada poco tiempo parece que se viene abajo todo, quizás se esté tensando demasiado la cuerda y algunos ya estamos empezando a coquetear con otras opciones, en mi caso desde abril de 2017, que empecé a utilizar Mastodon.

Parece que Mastodon podría ser un sustituto de Twitter, pero no lo es, son cosas totalmente diferentes, mientras el nivel de troleo que existe en Twitter es absurdamente elevado en Mastodon aún se mantiene la cosa con una cierta nobleza.

Por otro lado hay algo que me ha sorprendido muchísimo de Twitter y es el escoramiento a la extrema derecha de gran parte de su contenido, o al menos, el que a mi me muestra. Un contenido racista, xenófogo, clasista y en definitiva un contenido que no me acaba de gustar.

Está claro que cada uno puede poner lo que quiera, sólo faltaba, pero ¿de verdad hay tanto contenido de ese tipo?, da la impresión que se promociona ese tipo de contenido, algo así como algunos programas de la televisión que viven de tener a la gente cabreada, preocupada y con miedo de cosas que realmente o no existen o no son tal problema.

La última muestra es lo que está pasando en Francia ahora. ¿De verdad está el país entero en llamas? o quizás hay 10 ó 12 exaltados en algunas ciudades, personalmente me inclino a pensar que son 10 ó 12 exaltados y Twitter y algunos programas de televisión lo que quieren es contrarestar eso con 50 o 60.000 exaltados más.

Con este panorama seguiré publicando en Twitter porque a la gente le gusta, pero os invito a que empecéis a usar más Mastodón, a mi me podéis encontrar en https://mastodon.social/@ecollado https://social.collado.eu/@edu.

Por supuesto también puede ser que la sociedad se esté yendo al pedo y yo sea un optimista que no sabe ver la realidad, pero creo que no va por ahí

La presentación versó en una introducción a Vyos en el Centro de Datos, porque al fin y al cabo es lo que usamos en Tecnocrática para la red.

La presentación fue muy amena, al menos a mi me resultó muy amena gracias a aquellas personas que asistieron y que quiero darles las gracias de nuevo.

La presentación se grabó, pero en la grabación no se ve muy bien lo que se estaba proyectando así que he vuelto a grabarla para que podáis tener las diapos.

El vídeo lo tenéis en el canal de You Tube que hemos abierto en Tecnocrática (https://www.youtube.com/@TecnocraticaNet)

De todos modos aquí debajo os dejo las configuraciones usadas:

VyOS1
=====
configure
set system host-name vyos1
set interfaces ethernet eth1 address 198.51.100.1/24
set interfaces loopback lo address 192.0.2.1/32

set protocols ospf area 0 network '198.51.100.0/24'
set protocols ospf area 0 network '192.0.2.1/32'
set protocols ospf interface eth1
set protocols ospf redistribute connected


VyOS2
=====
configure
set system host-name vyos2
set interfaces ethernet eth1 address 198.51.100.2/24
set interfaces loopback lo address 192.0.2.2/32

set protocols ospf area 0 network '198.51.100.0/24'
set protocols ospf area 0 network '192.0.2.2/32'
set protocols ospf interface eth1
set protocols ospf redistribute connected


VyOS3
=====
configure
set system host-name vyos3
set interfaces ethernet eth1 address 198.51.100.3/24
set interfaces loopback lo address 192.0.2.3/32

set protocols ospf area 0 network '198.51.100.0/24'
set protocols ospf area 0 network '192.0.2.3/32'
set protocols ospf interface eth1
set protocols ospf redistribute connected


=============
LABORATORIO 2
=============

VyOS3
=====
set protocols ospf default-information originate


set interfaces ethernet eth2 address 203.0.113.1/24


set protocols ospf area 0 network '203.0.113.0/24' ?????????????


VyOS4
=====
configure
set system host-name vyos4
set interfaces ethernet eth0 address 203.0.113.2/24


VyOS3
=====
configure
set protocols bgp system-as '15954'
set protocols bgp neighbor 203.0.113.2 address-family ipv4-unicast
set protocols bgp neighbor 203.0.113.2 remote-as 100
set protocols bgp address-family ipv4-unicast import
set protocols bgp parameters router-id '203.0.113.1'


set protocols bgp address-family ipv4-unicast network 192.168.150.0/24


set policy route-map Todo rule 1 action 'permit'
set protocols bgp neighbor 203.0.113.2 address-family ipv4-unicast route-map export 'Todo'
set protocols bgp neighbor 203.0.113.2 address-family ipv4-unicast route-map import 'Todo'


VyOS4
=====
configure
set protocols bgp system-as 100

set protocols bgp neighbor 203.0.113.1 address-family ipv4-unicast
set protocols bgp neighbor 203.0.113.1 remote-as 15954
set protocols bgp address-family ipv4-unicast import
set protocols bgp parameters router-id 203.0.113.2




set policy route-map Todo rule 1 action 'permit'
set protocols bgp neighbor 203.0.113.1 address-family ipv4-unicast route-map export 'Todo'
set protocols bgp neighbor 203.0.113.1 address-family ipv4-unicast route-map import 'Todo'

Red Alert: ICANN and Verisign Proposal Would Allow Any Government In The World To Seize Domain Names

En esta noticia se hacen eco de unos posibles cambios en la política de nombres de dominio en la extensión .net. Según esa noticia se estaría preparando una modificación que permitiría a cualquier Gobierno / Autoridad Administrativa / Autoridad Gubernamental / Tribunal Competente…. denieguen, cancelen, redirijan o transfieran cualquier dominio registro de nombres, en otras palabras, se podrían confiscar dominio por cualquier entidad con «autoridad» y claro, esto pues podría supone un problema.

De momento este borrador sólo afecta a los dominios con extensión .net, pero podría afectar a los .com en un futuro no muy lejano.

El documento en cuestión está vivo en https://itp.cdn.icann.org/en/files/registry-agreement/redline-proposed-amendment-2017-net-registry-agreement-11-04-2023-en.pdf, pero os dejo una copia también por aquí por si queréis verla o si desapareciese.

Estos cambio son bastante preocupantes y en la web de freespeech.com ponen una serie de ejemplos que se podrían dar si esta nueva versión de la normativa entrase en juego.

1. El gobierno de China ordena que se suspendan (o simplemente se transfieran al gobierno chino) los nombres de dominio que operan sitios web que critican sus políticas.
2. El gobierno de Rusia, en guerra con Ucrania, ordena la transferencia de nombres de dominio pro-ucranianos al control del gobierno ruso.
3. El gobierno de Ucrania, en guerra con Rusia, ordena la transferencia de nombres de dominio prorrusos al control del gobierno ucraniano.
4. El gobierno de Texas ordena que los nombres de dominio a favor del aborto se transfieran al gobierno de Texas.
5.  El gobierno talibán en Afganistán ordena que los nombres de dominio a favor del aborto y aquellos que promueven la educación de las niñas sean transferidos al gobierno.
6.  El gobierno de Irán ordena que todos los nombres de dominio en todo el mundo con contenido «para adultos» (es decir, pornografía) se transfieran al gobierno iraní.
7. El gobierno de Tuvalu, (que ya licencia el registro .TV para recaudar fondos) que enfrenta una crisis económica debido al cambio climático, ordena que cada punto-net de 2 letras, 3 letras y una palabra sea transferido al gobierno de Tuvalu, con el fin de subastar los nombres de dominio para recaudar nuevos fondos para ellos mismos.
8. Un gobierno en Argentina lanza un nuevo programa cuyo nombre resulta ser idéntico al nombre de dominio propiedad de una empresa francesa durante los últimos 25 años. El gobierno de Argentina ordena que se les transfiera el nombre de dominio, sin compensación por la expropiación.
9. El gobierno de Italia está molesto por una empresa de redes sociales que opera desde China y ordena que el nombre de dominio de la empresa china se transfiera al gobierno italiano.
10. El gobierno del Reino Unido está molesto porque el software publicado por una empresa sueca tiene cifrado de extremo a extremo. Ordena transferir el nombre de dominio de la empresa sueca al gobierno del Reino Unido.

Si esto se permitira a todo el mundo imaginad el descontrol que esto podría ser. Por suerte de momento está todo en borrador y es probable que no salga adelante, pero hay que andar con cuidado, porque estas cosas pasan cada vez más a menudo

El otro día a un cliente le fallaba una aplicación en un servidor suyo y llamaba, no le fallaba el servidor, pero sí la aplicación, al final es porque le estaban haciendo peticiones no deseadas desde distintos proveedores de servicios y hacían que el número de hilos del php-fpm se agotara.

Esas IPs que estaban jorobando fueron descubiertas después de bucear por los logs un ratito por un compañero, no voy a decir quien, pero es el que bautizó a nuestra empresa. El tema es que al cliente, aunque es un encanto de persona (lo digo desde el corazón), le tenía yo al teléfono y claro, el cliente estaba nervioso y lo que hace es traspasarme su tensión y si esto te lo hacen 8 o 10 veces por semana durante 20 años pues algo se queda en el cuerpo. También puede ser que te de todo igual y que nada te afecte, pero la verdad es que yo eso no me lo he encontrado nunca.

Pues si estás muy jodido ve a un profesional, que oye, no muerden y si no estás tan jodido pues puedes al menos hacer ejercicio, o eso es lo que nos dicen.

Así que me he puesto a buscar información sobre cómo puede beneficiar al administrador de sistemas o de red el deporte.

Hoy el cuerpo me pedía grabar un audio sobre esto porque con los años he descubierto que es algo fundamental en nuestro trabajo y llevo trabajando casi 30 años en esto.

Después de investigar bastante he llegado a dos conclusiones.

• El deporte tiene mucho que ver con nuestra profesión.
• El deporte nos ayuda a lidiar con los intentos diarios de traspasarnos los problemas de otros.

• https://diagnoise.bandcamp.com/album/3435
• https://diagnoise.bandcamp.com/album/nuclear-winter

Las notas del programa de hoy las tenéis en

Motivos para cambiar tu centro de datos

Foto de Taylor Vick en Unsplash

Pero hoy no quiero hablar de proxmox, sino de proxmox backup server, que es el servicio de backup de proxmox.

La instalación es muy similar a la de proxmox VE, el hipervisor, y para entrar en vez de utilizar el puerto 8006 se utilizará el puerto 8007, lo cual, no se lo digáis a nadie, pero permite instalar el PBS en el mismo servidor que el Proxmox VE.

Instalar ambos softwares en el mismo hipervisor está bien si lo que queremos es un laboratorio o si tenemos dos servidores y hacemos copias cruzadas. De todos modos, que se pueda no significa que sea buena idea. Recordad que no todo lo que se puede hacer es buena idea, se puede beber lejía, pero yo no lo haría.

PBS tiene cuatro cosas muy graciosas que le hacen ser un software maravilloso:

1. La deduplicación en las copias de seguridad, es decir, el backup va a ocupar muy poquito espacio.En el caso de KVM que las copias son muy rápidas y ligeras. En LXC el backup no es tan eficiente, pues hace copia de la máquina completa.
2. Retención y rotación de backups. Puedes tener las copias de seguridad y retenerlas con la antigüedad que quieras, por ejemplo backups cada hora, día, semana, mes, año. Una maravilla vamos.
3. Por supuesto la integración con Proxmox VE es total y absoluta.
4. PBS hace replicación entre PBS, con lo cual puedes tener siempre un backup externo en otro lado porque siempre va a estar sincronizado con tu PBS principal

PBS es un componente integral de la plataforma de virtualización Proxmox VE, y se integra perfectamente con el hipervisor Proxmox VE para proporcionar una solución de copia de seguridad completa. PBS ofrece una amplia gama de características, como la capacidad de realizar copias de seguridad de forma incremental, comprimir y cifrar los datos de respaldo, y programar copias de seguridad de manera automática.

PBS utiliza la tecnología de copia de seguridad basada en Zstandard y deduplicación de datos, lo que permite reducir significativamente el tamaño de las copias de seguridad y, por lo tanto, el espacio de almacenamiento requerido. También es compatible con varios tipos de almacenamiento de respaldo, como discos duros, almacenamiento de red (NAS) y sistemas de almacenamiento en la nube.

• Por si no lo conocéis Zstandard es un algoritmo de compresión muy rápido que se distribuye de forma gratuita con licencia BSD. Es un algoritmo desarrollado en Facebook, un lugar donde se hacen cosas muy interesantes.
• Y la deduplicación lo que hace es ir buscando trozos de 4KB y le asigna un hash a cada uno. Al final si se ve un bloque duplicado no se guarda y sólo se almacenan bloques únicos, por eso el ahorro de espacio es tan salvaje. La deduplicación no es sólo no guardar dos veces el mismo fichero, sino que va mucho más allá, es algo mucho más sesudo y complicado de implementar, pero PBS nos lo ofrece gratis.

PBS es una solución maravillosa, pero como os contaba en el audio anterior si tenemos el PBS en nuestras oficinas tenemos que tener en cuenta que sólo en electricidad nos va a costar unos 70 euros al mes, además de la amortización de hardware, control de discos, el que la sala no sea lo más adecuado, etc…

Así que una opción estupenda es tener el PBS en un Centro de Datos externo o incluso si tenéis el Proxmox VE en un Centro de Datos tener las copias en otro Centro de Datos.

La opción tradicional consiste en levantar un servidor nuevo en otro Centro de Datos, o bien usar un servicio de PBS remoto como el que ofrecemos nosotros en Tecnocrática, es cuestión de echar números y mirar qué es lo que más nos interesa. También se puede usar nuestro PBS para replicar el PBS que tengas

Pensar que la cantidad de datos que necesitáis de PBS es muy baja gracias a la deduplicación, así que quizás os interese hacer los backups en un PBS externo como el nuestro. Nosotros en Tecnocrática, por cierto cobramos 50 euros al mes el Tera usado y neto en el PBS que es mucho menso de lo que realmente se hace backup por lo que os he contado antes. Además en ese servicio nosotros nos encargamos de todo y tú sólo tienes que preocuparte de que las copias de seguridad se lancen.

Atributos: Piezas de información que utiliza BGP para tomar su decisión de routing.

Communities: Agrupación de prefijos por algún motivo y que se utilizan para poder filtrar, anunciar o manipular.

Si queréis profundizar recordad que hay otro capítulo sobre BGP que cuenta todo esto, y si queréis profundizar más, pues hay muchos más:

• Secuestro de prefijos BGP o BGP hijacking
• BGP Anycast
• Tránsitos y filtros en BGP
• Gestión de filtros en BGP
• Montar dos routers frontera BGP
• Communities de BGP
• BGP con Mikrotik
• BGP Personal con Javi-h
• Qué es BGP FlowSpec

El punto neutro de Internet es un componente esencial de la arquitectura de Internet que permite el intercambio de tráfico entre los distintos proveedores de servicios de Internet (ISP, por sus siglas en inglés) de manera eficiente y equitativa. Es un lugar físico en el que los proveedores de servicios de Internet interconectan sus redes para intercambiar tráfico de Internet y proporcionar conectividad a sus clientes. En este texto, explicaremos en detalle qué es un punto neutro de Internet y cómo funciona.

Los puntos neutros de internet son cruciales para el funcionamiento de internet, ya que permiten a los diferentes ISP interconectar sus redes y ofrecer a sus clientes acceso a todo el contenido de internet. Sin los puntos neutros, los ISP tendrían que conectarse directamente entre sí para intercambiar tráfico de datos, lo que sería muy costoso y poco eficiente.

Los puntos neutros de internet no son propiedad de ningún ISP, empresa u organización en particular. En cambio, son operados por entidades sin fines de lucro, conocidas como «intercambios de Internet», que proporcionan el espacio físico y la infraestructura necesarios para que los ISP intercambien tráfico de datos de manera neutral y equitativa.

El funcionamiento de un punto neutro de internet se basa en el principio de la neutralidad de la red, que establece que todo el tráfico de internet debe ser tratado de manera equitativa, independientemente de su origen, destino o contenido. En un punto neutro, todos los ISP son iguales y no hay preferencia por parte del intercambio de Internet hacia ningún ISP en particular.

Cuando un ISP se conecta a un punto neutro de internet, puede intercambiar tráfico de datos con otros ISP que también estén conectados al punto neutro. El intercambio de datos se realiza a través de una serie de conexiones de red de alta velocidad, conocidas como «enlaces de peering», que conectan los routers de los diferentes ISP en el punto neutro.

Los enlaces de peering son bidireccionales, lo que significa que el tráfico puede fluir en ambas direcciones. Cuando un cliente de un ISP solicita acceso a un sitio web alojado en otro ISP, la solicitud se envía a través de la red del ISP del cliente hasta el punto neutro de internet, donde se enruta al ISP que aloja el sitio web. El ISP que aloja el sitio web luego envía la respuesta de vuelta a través del enlace de peering al ISP del cliente.

El tráfico que fluye a través de un punto neutro de internet puede ser de diferentes tipos y tamaños. Puede ser tráfico web, correo electrónico, mensajería instantánea, video en línea, juegos en línea, transferencias de archivos, etc. El punto neutro no tiene control sobre el contenido del tráfico, solo se encarga de enrutarlo de manera eficiente y equitativa.

Los puntos neutros de internet son especialmente importantes para el tráfico de datos de alta velocidad y gran volumen, como el streaming de video en línea y los juegos en línea. Cuando se utiliza un punto neutro de internet, el tráfico de datos no tiene que pasar por múltiples redes intermedias, lo que puede ralentizar la velocidad de conexión y aumentar la latencia. En cambio, el tráfico se enruta directamente entre los ISP conectados al punto neutro, lo que mejora enormemente las posibilidades existentes.

Si tenemos que acceder a una red remota podemos hacerlo con un wireguard, claro que sí, sin problema, pero muchas veces necesitamos una solución rápida y directa, algo más rápido que levantar una VPN, o incluso puede que levantar una VPN sea un poco complicado porque se pisen direccionamientos o cualuier otro motivo.

Para acceder a servicios remotos a veces lo más fácil es levantar un túnel SSH desde tu propio equipo y a funcionar.

La forma más común de levantar un túnel SSH quizás seá con e en Windows, porque sí, los usuarios de Windows también hacen cosas interesantes.

Los túneles SSH los podemos hacer de dos formas:

1. De nuestra máquina hacia afuera (ssh -L)
2. Del destino a nuestra máquina (ssh -R)

Elegiremos el túnel SSH normal o el túnel SSH inverso dependiendo de cómo tengamos la conexión.

Por ejemplo si nosotros queremos ver en un puerto de localhost algo que está en una máquina a la que se llega por nuestra máquina de salto será un SSH normal.

Si nosotros queremos abrir un puerto a una conexión externa entonces usaremos un SSH inverso.

Donde se ve -> nosotros -> Destino
nosotros -> máquina de salto -> destino

¿Cuando se usa esto? Cuando tienes acceso a una red mediante una única máquina de salto por ssh, cuando quieres abrir una aplicación interna a una máquina externa sin exponerla a internet.

La última vez que lo he usado ha sido por ejemplo hoy que he tenido que acceder a un entorno web de unos equipos de red tunelizando la web a través de una conexión ssh.

A mi me pasa muchas veces que tengo que acceder a una máquina a la que no tengo acceso directo, por ejemplo una máquina de salto

ssh -L 7001:10.10.10.10:80 user@pub001.host
ssh -R 8081:10.10.10.10:80 user@mipc

Actualizaciones y mejoras del artículo (se agradece muchísimo :D):

Por Dathpatatas:

Vengo a “quejarme” del podcast he echado en falta los otros 2 tuneles ssh

Proxy socks directo similar al -L, pero creando un proxy socks en local que sale por la maquina a la que nos conectamos, super util
ssh user@host -D 8000

Proxy socks reverso muy util para dar internet a la maquina remota a traves de un proxy socks remoto que sale por la maquina que ejecuta el comando
ssh user@host -R 8000

Para el -L iplocal:puertolocal:ipremota:puertoremoto

Si no pones iplocal por defecto es 127.0.0.1
La ipremota puede ser 127.0.0.1 (un puerto local de la maquina remota) o cualquier ip

En el mundo Cisco la mayoría de las empresas levantan VLANs, esas VLANs tienen asociada una instancia de Spanning Tree y hay mucha gente que no se pregunta mucho más sobre eso, simplemente si quieres ver los puertos bloqueados pues

show spanning tree vlan 55

Y poco más, como mucho se define el root de alguna instancia de spanning tree para que el root de la instancia de la vlan 55 esté en un switch determinado y poco más.

El protocolo que se utiliza por defecto en Cisco para el Spanning Tree es PVST+ y es el protocolo ideal para la gran mayoría de las redes empresariales, pero tiene un límite, el límite es que PVST+ sólo permite 128 instancias, que son muchas, pero claro, hay gente que necesita más de 128 VLANs en su red, en ese caso, la 129 no correrá spanning tree.

Al configurar la vlan 129ª saldrá un mensaje diciendo que se ha quedado sin instancias de PVST y que esa vlan nueva no va a tener spanning tree y claro, la primera vez que ves ese mensaje se entra en crisis, ¿cómo que no voy a tener spanning tree en las vlans nuevas.

Este es un tema que no he tratado anteriormente porque no creía que fuera una necesidad pero sin ir más lejos el otro día estaba mirando una red y saltó esta necesidad, en esa red había necesidad de bastantes más vlans que 128 y claro, por defecto hay PVST+ y no nos sirve para el Spanning Tree de esta red.

Como opciones tendríamos CST o MST y claro, CST no vamos ni a considerarla.

La elección del tipo de Spanning Tree depende de dos factores:

• Ubicación del root
• Utilización de los enlaces

Ubicación del root

Si tenemos una vlan de almacenamiento donde siempre va a ser necesario que todo el tráfico llegue a una cabina está claro que el root del STP tendría que estar en la cabina porque queremos que todos los enlaces de ese switch estén disponibles y no cortados.

Utilización de los enlaces

Con Spanning Tree podemos hacer que unas instancias vayan por un enlace y otras por otro, de forma que, si tenemos dos enlaces, tengamos utilizados ambos enlaces, obviamente la suma no debería ser mayor al ancho de banda de uno de los enlaces, teniendo en cuenta que son iguales.

El objetivo de este capítulo no es explicar como funciona spanning tree, de eso ya hablé en Enero de 2018 en este mismo podcast en el capítulo Spanning Tree, el objetivo es que sepáis qué hacer cuando os quedéis sin instancias disponibles en PVST+.

MST

La solución será MST, que sólo nos ofrece 64 instancias, pero con la gracia de que podemos agregar vlans a una instancia, dividiendo de forma idéntica podríamos tener, por ejemplo, 64 instancias con 64 vlans cada instancia.

Seguro que muchas vlans comparten la misma estructura, son vlans en las que tenemos servidores o PCs que tienen que comunicarse con un router, pues en este caso el root lo ponemos en el switch donde esté el router y todas esas vlans en una misma instancia, así que compartirán topología de nivel 2.

Por desgracia nadie empieza una red utilizando MST, sino utilizando PVST+, por comodidad o por no pensar en el futuro

Yo mismo nunca he iniciado una red desde 0 con MST, y siempre me arrepiento muchísimo, porque el cambio a MST es inevitable ya que el llegar a 128 instancias es sólo cuestión de tiempo.

¿Cómo levantaríamos el MST desde el principio?

switch# conf t 
Enter configuration commands, one per line. End with CNTL/Z. 
switch(config)# spanning-tree mode mst 
switch(config)# spanning-tree mst configuration 
switch(config-mst)# instance 1 vlan 1 
switch(config-mst)# instance 2 vlan 2-5 
switch(config-mst)# instance 3 vlan 6,7,8 
switch(config-mst)# exit 
switch(config)# spanning-tree mst 0-3 root primary

Como se ve la configuración es muy sencilla y se entiende perfectamente spanning tree tradicional, si asignáramos una vlan a una instancia al final tendríamos el mismo comportamiento que PVST+.

Migración de PVST+ a MST

En un Mundo ideal podríamos convertir la configuración de todos los switches a la vez y ya estaría, pero ya sabéis que eso no va a suceder nunca, así que vamos a tener que ir paso a paso para hacer la conversión en la red.

1. Identificar los puertos de acceso de la red y configurarlos como spanning-tree portfast, como spanning-tree port type edge o como sea en el switch donde estemos.
2. Asignar vlans a instancias de MST y decidir donde va a  estar el root primario y el secundario para cada instancia. Ojo, la instancia 0 no hay que usarla.
3. Aprovechando que MST puede interactuar con PVST+ a nivel de puerto se pueden mantener ambas topologías a la vez. Ojo aquí porque hay que asegurarse que los trunks lleven todas las vlans.
4. Asegurarse que los switches PVST+ tienen menor root bridge (numeración superior) que el CST, el root del MST instancia 0.
5. Y lo más importante, no es que puedas tener un corte en la red, es que seguro que lo vas a tener, así que no hagas esto en hora de máximo tráfico.

Una vez que se haya terminado hay que hacer dos cosas, tunear el MST con el port-priority

switch(config-if)#spanning-tree mst 2 port-priority 64

Y limpiando la configuración que quede de PVST+

switch(config)#no spanning-tree backbonefast
switch(config)#no spanning-tree backbonefast
switch(config)#interface FastEthernet1/0/24
switch(config-if)#no spanning-tree vlan 20,40,200 port-priority 64

Una vez limpia la configuración procederemos a configurar MST en el siguiente y así iremos bajando niveles.

Nos hemos juntado Adrián Almenar, DMNTR, Carlos Fraga, Andreu Adrover y un servidor alrededor de una sala de Zencastr y hemos grabado algo más de una hora de charla informal sobre el tema de moda en estos momentos ;-), el IPv6.

Espero que os guste.