Seguridad

Cuando la tecnología Docker apareció, la adoraron por el lema: «Build once, run anywhere» (Construye una vez, ejecuta en cualquier lugar). Los desarrolladores dejaron de escuchar la frase «en mi máquina funciona, pero en el servidor no». Pero junto con la comodidad llegó una nueva amenaza.

Un contenedor no es solo tu aplicación. Es todo un mini-sistema operativo (SO) con sus propias bibliotecas, utilidades y llamadas al sistema. Y si no vigilas ese SO, dejas a los atacantes una puerta enorme completamente abierta.

Imagina que estás construyendo una casa. Tú mismo diseñaste las paredes, revisaste cada ladrillo y te aseguraste de no haber olvidado las llaves en la cerradura. Pero ¿y si el hormigón que compraste a un proveedor externo con el tiempo empieza a desmoronarse? ¿O si en los marcos de las ventanas que instalaste hay defectos ocultos?

En el desarrollo moderno la situación es exactamente así. Una aplicación promedio hoy en día está formada en un 80–90% por bibliotecas de código abierto. Solo escribes una pequeña parte del código (la punta del iceberg), que gestiona un enorme volumen de código ajeno oculto «bajo la superficie».

¿Alguna vez te has preguntado cómo los programadores experimentados encuentran errores en el código ajeno con solo mirarlo? Buscan patrones. Saben que si los datos del usuario entran directamente en una consulta SQL —eso es malo. Si la contraseña se compara con un == en lugar de una función segura —es un riesgo.

Pero una persona no puede revisar 100 000 líneas de código sin pasar algo por alto. Aquí entra en escena SAST (Static Application Security Testing).

Imagine la situación: trabajas en un proyecto genial toda la noche. A las 4 de la mañana todo está listo, haces un git push final y te vas a dormir tranquilo. Y por la mañana descubres que tu balance en AWS está a cero y que hay un minero corriendo en tus servidores. ¿Qué pasó? Resulta que en uno de los archivos dejaste la línea: AWS_ACCESS_KEY_ID = "AKIA...".

Es un error clásico por el que han pasado miles de desarrolladores. En este artículo veremos por qué «simplemente borrar la contraseña» no ayuda y cómo configurar una protección automática que físicamente te impedirá cometer el error.

Escribir un Dockerfile simple: FROM node, COPY ., CMD run. Esto funciona, y para pruebas locales a menudo es suficiente. Pero cuando tal imagen llega al CI/CD o, Dios no lo quiera, a producción, empiezan los problemas: la construcción dura una eternidad, la imagen pesa gigabytes y los de seguridad se llevan las manos a la cabeza.

La diferencia entre “funciona” y “funciona correctamente” es colosal. Vamos a analizar cuatro niveles de optimización que separan una chapuza aficionada de una solución de ingeniería fiable.

OpenVPN — es un protocolo VPN fiable y probado, que permite organizar acceso remoto protegido a la red local. MikroTik RouterOS soporta OpenVPN en modo servidor desde la versión 6.x (TCP), y desde la versión 7+ — también UDP, pero con una serie de limitaciones arquitectónicas:

• autenticación obligatoria por usuario/contraseña incluso al usar certificados;
• lista limitada de cifrados y algoritmos;
• ausencia de algunas funcionalidades del OpenVPN “clásico”.

A pesar de ello, OpenVPN en MikroTik sigue siendo una solución demandada — especialmente en escenarios donde los clientes no soportan WireGuard o se requiere compatibilidad con sistemas antiguos.

Si me enviaran a una isla digital desierta y solo me permitieran llevar una utilidad de red, sin dudarlo elegiría Netcat.

La documentación oficial (man nc) dice secamente: «utilidad para leer y escribir a través de conexiones de red usando TCP o UDP».
En la práctica es la navaja suiza del ingeniero de red, que reemplaza a decenas de programas especializados.

En el artículo se usan ejemplos para OpenBSD netcat — es el que viene por defecto en Ubuntu 20.04+, Debian 10+, Fedora, Arch, Alpine y en la mayoría de las distribuciones modernas.

Read more

Si su negocio trabaja con usuarios de Rusia, la cuestión de dónde se almacenan los datos personales le concierne directamente. Teléfonos, nombres, direcciones de correo electrónico, solicitudes de formularios, datos de empleados: todo esto está sujeto a estrictos requisitos de localización.

Durante años muchas empresas vivieron en una “zona gris”: los datos aparentemente se almacenaban tanto en Rusia como en el extranjero y la responsabilidad estaba diluida. Pero a partir del 1 de julio de 2025 las reglas cambiaron tanto que muchos esquemas técnicos habituales ahora se consideran una violación directa de la ley.

Si usas n8n para automatizar con modelos de lenguaje de gran tamaño (LLM), seguro conoces no solo sus enormes capacidades, sino también los riesgos. Los LLM siguen siendo una «caja negra»: pueden revelar datos personales por accidente, generar contenido tóxico o ser víctimas de inyección de prompts.

Hasta hace poco había que «colocar» en el flujo de trabajo de IA numerosos nodos IF y complejas comprobaciones Regex. Era engorroso e poco fiable.

En un mundo donde la privacidad de los datos y el acceso a recursos a menudo están restringidos por geobloqueos o políticas corporativas, herramientas como ProxyChains se vuelven asistentes indispensables. ProxyChains —o más precisamente su fork moderno ProxyChains-NG— es una herramienta utilitaria de código abierto para sistemas tipo Unix (Linux, macOS, etc.) que permite redirigir el tráfico de red de cualquier aplicación a través de una cadena de servidores proxy. Es especialmente popular entre desarrolladores, pentesters y entusiastas de la seguridad. En este artículo analizaremos qué puede hacer ProxyChains, por qué es útil para desarrolladores, daremos ejemplos de uso y discutiremos sus limitaciones.