home.social

#servidores — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #servidores, aggregated by home.social.

  1. Si, continuamos con la serie de tutoriales basadas en el hecho de que ya tenemos una red privada virtual (VPN) desde la que podremos acceder a la autenticación de servicios a los que solo nosotros accedemos.

    Introducción

    Hasta el momento hemos tenido éxito en dejar solo las rutas necesarias para NextCloud y dejando en secreto una instancia FreshRSS. La primera ruta es parcial y la segunda, oculta completa. Ahora, nos toca ocultar parcialmente una que puede resultar un poco más compleja debido a que hablamos de WordPress. El sistema de blogs utilizado para casi cualquier cosa y por eso puede tener puertas por todas partes.

    Ya no es necesario poner los requisitos puesto que ya los cumplimos todos, así que vamos directo a la teoría.

    Desarrollo

    La verdad pensé que sería tan sencillo como mandarle un location deny all, pero no. WordPress usa un sistema de rutas y embellecedores de URL que puede hacer que olvides que /wp-login no es lo mismo que /wp-login.php. Además, bloqueando el /wp-admin se te carga también el sistema AJAX, con lo que el contact form 7 dejaría de funcionar. Vamos repasando lo que hemos hecho para evitar todo esto.

    1
    2
    3
    4
    5
    6
    7
    8
    location = /wp-admin/admin-ajax.php {
            allow all; # Permitir que el público lo use para formularios/filtros
    
            # IMPORTANTE: Aquí debes incluir tu configuración de PHP
            # para que Nginx sepa cómo procesar el archivo.
            include snippets/fastcgi-php.conf;
            fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP
                    }

    Debes agregar este fragmento a tu archivo de configuración de nginx después de tu bloque de php. Esto es porque luego bloquearemos la ruta /wp-admin la cual terminará cargándose al admin-ajax.php el cual sirve para muchas funciones, especialmente para los plugins. pero si no tienes casi nada, es posible que solo afecte al funcionamiento de contact form 7

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    location /wp-admin{
         allow 10.0.0.0/24;
         deny all;
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP}
    
    location /wp-login{
         allow 10.0.0.0/24;
         deny all;
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP}location = /wp-login.php {
         allow 10.0.0.0/24;
         deny all;
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP}

    Estos bloques son de lo mas predecible. Al igual que en los casos anteriores, basta con definir la ruta que queremos bloquear y pues… bloquearla. Recuerda que la intención es que se pueda acceder por la red privada virtual, así que agrega tu rango de subred con el que tienes configurado WireGuard.

    Por ultimo, haremos unos cuantos ajustes de seguridad.

    1
    2
    3
    location ~* (readme.html|debug.log|license.txt) {
        deny all;
    }

    Esto es mas para protegerte de descuidos. El archivo readme.html y licence.txt está públicamente accesible. Bloquéalo para no delatar tu versión exacta de WordPress (es mas fácil atacar una versión especifica que atacar al azar hasta que aciertas a la vulnerabilidad que buscas).

    Debug.log es un archivo que queda visible si has habilitado la depuración. Hay mucha info sensible allí. Lo mejor es que lo escondas por si las dudas.

    Con estos cambios ya no tendrás que preocuparte tanto por ataques de fuerza bruta pues, no pueden forzar la cerradura si no hay cerradura XD.

    También te beneficia si tienes pocos recursos, porque tu servidor no tiene que estar atendiendo al ruido de Internet (bots, scrappers, etc) y puede centrarse en el trafico real.

    Conclusiones

    Pues verás, a diferencia de mi pobre lector de RSS que no tenia muchas visitas indeseadas, mi blog principal si que es atormentado todo el tiempo. Los que responden 200 son solo de tanteo. Confirman que la página existe. Pero los que devuelven otros errores son de ataques. Si no los bloqueara, estarían ahí todo el rato probando combinaciones de contraseñas hasta dar con la correcta y joderme la vida.

    Y verás, probablemente puedas comprobar por ti mismo si estos códigos funcionan. Basta con que entres a la url de /wp-admin o /wp-login y encontraras errores 403

    Pero el resto del sitio esta completamente funcional.

    El hecho de que pueda seguir escribiendo y puedas leer este post, es prueba de que las configuraciones aquí aplicadas han funcionado.

    ¿Sobre qué ganamos con esto? la verdad, algo mas de paz. Ya no tienes que preocuparte tanto por la calidad de tu contraseña, pero no te descuides, para todo, activa A2F (autenticacion en dos factores) porque aun puedes tener accidentes. Ya sabes, errores de capa 8 jajaja.

    En adelante, los logs ya no deberán dar respuestas 200, sino un error 403. Ya es cuestión de modificar las reglas de fail2ban para que bloquee a los que provocan esos errores, pero claro, recordando que no te bloquees a ti mismo porque si olvidas entrar con wireguard activo, puede dejarte pateado afuera.

    https://interlan.ec/blog/2026/05/01/tutorial-mejorando-la-seguridad-de-wordpress-mediante-regas-nginx/ #Blog #devops #experimentos #linux #nginx #seguridadInformática #selfhosting #servidores #spam #tutorial #vps #wordpress
  2. Si, continuamos con la serie de tutoriales basadas en el hecho de que ya tenemos una red privada virtual (VPN) desde la que podremos acceder a la autenticación de servicios a los que solo nosotros accedemos.

    Introducción

    Hasta el momento hemos tenido éxito en dejar solo las rutas necesarias para NextCloud y dejando en secreto una instancia FreshRSS. La primera ruta es parcial y la segunda, oculta completa. Ahora, nos toca ocultar parcialmente una que puede resultar un poco más compleja debido a que hablamos de WordPress. El sistema de blogs utilizado para casi cualquier cosa y por eso puede tener puertas por todas partes.

    Ya no es necesario poner los requisitos puesto que ya los cumplimos todos, así que vamos directo a la teoría.

    Desarrollo

    La verdad pensé que sería tan sencillo como mandarle un location deny all, pero no. WordPress usa un sistema de rutas y embellecedores de URL que puede hacer que olvides que /wp-login no es lo mismo que /wp-login.php. Además, bloqueando el /wp-admin se te carga también el sistema AJAX, con lo que el contact form 7 dejaría de funcionar. Vamos repasando lo que hemos hecho para evitar todo esto.

    1
    2
    3
    4
    5
    6
    7
    8
    location = /wp-admin/admin-ajax.php {
            allow all; # Permitir que el público lo use para formularios/filtros
    
            # IMPORTANTE: Aquí debes incluir tu configuración de PHP
            # para que Nginx sepa cómo procesar el archivo.
            include snippets/fastcgi-php.conf;
            fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP
                    }

    Debes agregar este fragmento a tu archivo de configuración de nginx después de tu bloque de php. Esto es porque luego bloquearemos la ruta /wp-admin la cual terminará cargándose al admin-ajax.php el cual sirve para muchas funciones, especialmente para los plugins. pero si no tienes casi nada, es posible que solo afecte al funcionamiento de contact form 7

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    location /wp-admin{
         allow 10.0.0.0/24;
         deny all;
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP}
    
    location /wp-login{
         allow 10.0.0.0/24;
         deny all;
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP}location = /wp-login.php {
         allow 10.0.0.0/24;
         deny all;
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP}

    Estos bloques son de lo mas predecible. Al igual que en los casos anteriores, basta con definir la ruta que queremos bloquear y pues… bloquearla. Recuerda que la intención es que se pueda acceder por la red privada virtual, así que agrega tu rango de subred con el que tienes configurado WireGuard.

    Por ultimo, haremos unos cuantos ajustes de seguridad.

    1
    2
    3
    location ~* (readme.html|debug.log|license.txt) {
        deny all;
    }

    Esto es mas para protegerte de descuidos. El archivo readme.html y licence.txt está públicamente accesible. Bloquéalo para no delatar tu versión exacta de WordPress (es mas fácil atacar una versión especifica que atacar al azar hasta que aciertas a la vulnerabilidad que buscas).

    Debug.log es un archivo que queda visible si has habilitado la depuración. Hay mucha info sensible allí. Lo mejor es que lo escondas por si las dudas.

    Con estos cambios ya no tendrás que preocuparte tanto por ataques de fuerza bruta pues, no pueden forzar la cerradura si no hay cerradura XD.

    También te beneficia si tienes pocos recursos, porque tu servidor no tiene que estar atendiendo al ruido de Internet (bots, scrappers, etc) y puede centrarse en el trafico real.

    Conclusiones

    Pues verás, a diferencia de mi pobre lector de RSS que no tenia muchas visitas indeseadas, mi blog principal si que es atormentado todo el tiempo. Los que responden 200 son solo de tanteo. Confirman que la página existe. Pero los que devuelven otros errores son de ataques. Si no los bloqueara, estarían ahí todo el rato probando combinaciones de contraseñas hasta dar con la correcta y joderme la vida.

    Y verás, probablemente puedas comprobar por ti mismo si estos códigos funcionan. Basta con que entres a la url de /wp-admin o /wp-login y encontraras errores 403

    Pero el resto del sitio esta completamente funcional.

    El hecho de que pueda seguir escribiendo y puedas leer este post, es prueba de que las configuraciones aquí aplicadas han funcionado.

    ¿Sobre qué ganamos con esto? la verdad, algo mas de paz. Ya no tienes que preocuparte tanto por la calidad de tu contraseña, pero no te descuides, para todo, activa A2F (autenticacion en dos factores) porque aun puedes tener accidentes. Ya sabes, errores de capa 8 jajaja.

    En adelante, los logs ya no deberán dar respuestas 200, sino un error 403. Ya es cuestión de modificar las reglas de fail2ban para que bloquee a los que provocan esos errores, pero claro, recordando que no te bloquees a ti mismo porque si olvidas entrar con wireguard activo, puede dejarte pateado afuera.

    https://interlan.ec/blog/2026/05/01/tutorial-mejorando-la-seguridad-de-wordpress-mediante-regas-nginx/ #Blog #devops #experimentos #linux #nginx #seguridadInformática #selfhosting #servidores #spam #tutorial #vps #wordpress
  3. Si, continuamos con la serie de tutoriales basadas en el hecho de que ya tenemos una red privada virtual (VPN) desde la que podremos acceder a la autenticación de servicios a los que solo nosotros accedemos.

    Introducción

    Hasta el momento hemos tenido éxito en dejar solo las rutas necesarias para NextCloud y dejando en secreto una instancia FreshRSS. La primera ruta es parcial y la segunda, oculta completa. Ahora, nos toca ocultar parcialmente una que puede resultar un poco más compleja debido a que hablamos de WordPress. El sistema de blogs utilizado para casi cualquier cosa y por eso puede tener puertas por todas partes.

    Ya no es necesario poner los requisitos puesto que ya los cumplimos todos, así que vamos directo a la teoría.

    Desarrollo

    La verdad pensé que sería tan sencillo como mandarle un location deny all, pero no. WordPress usa un sistema de rutas y embellecedores de URL que puede hacer que olvides que /wp-login no es lo mismo que /wp-login.php. Además, bloqueando el /wp-admin se te carga también el sistema AJAX, con lo que el contact form 7 dejaría de funcionar. Vamos repasando lo que hemos hecho para evitar todo esto.

    1
    2
    3
    4
    5
    6
    7
    8
    location = /wp-admin/admin-ajax.php {
            allow all; # Permitir que el público lo use para formularios/filtros
    
            # IMPORTANTE: Aquí debes incluir tu configuración de PHP
            # para que Nginx sepa cómo procesar el archivo.
            include snippets/fastcgi-php.conf;
            fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP
                    }

    Debes agregar este fragmento a tu archivo de configuración de nginx después de tu bloque de php. Esto es porque luego bloquearemos la ruta /wp-admin la cual terminará cargándose al admin-ajax.php el cual sirve para muchas funciones, especialmente para los plugins. pero si no tienes casi nada, es posible que solo afecte al funcionamiento de contact form 7

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    location /wp-admin{
         allow 10.0.0.0/24;
         deny all;
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP}
    
    location /wp-login{
         allow 10.0.0.0/24;
         deny all;
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP}location = /wp-login.php {
         allow 10.0.0.0/24;
         deny all;
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP}

    Estos bloques son de lo mas predecible. Al igual que en los casos anteriores, basta con definir la ruta que queremos bloquear y pues… bloquearla. Recuerda que la intención es que se pueda acceder por la red privada virtual, así que agrega tu rango de subred con el que tienes configurado WireGuard.

    Por ultimo, haremos unos cuantos ajustes de seguridad.

    1
    2
    3
    location ~* (readme.html|debug.log|license.txt) {
        deny all;
    }

    Esto es mas para protegerte de descuidos. El archivo readme.html y licence.txt está públicamente accesible. Bloquéalo para no delatar tu versión exacta de WordPress (es mas fácil atacar una versión especifica que atacar al azar hasta que aciertas a la vulnerabilidad que buscas).

    Debug.log es un archivo que queda visible si has habilitado la depuración. Hay mucha info sensible allí. Lo mejor es que lo escondas por si las dudas.

    Con estos cambios ya no tendrás que preocuparte tanto por ataques de fuerza bruta pues, no pueden forzar la cerradura si no hay cerradura XD.

    También te beneficia si tienes pocos recursos, porque tu servidor no tiene que estar atendiendo al ruido de Internet (bots, scrappers, etc) y puede centrarse en el trafico real.

    Conclusiones

    Pues verás, a diferencia de mi pobre lector de RSS que no tenia muchas visitas indeseadas, mi blog principal si que es atormentado todo el tiempo. Los que responden 200 son solo de tanteo. Confirman que la página existe. Pero los que devuelven otros errores son de ataques. Si no los bloqueara, estarían ahí todo el rato probando combinaciones de contraseñas hasta dar con la correcta y joderme la vida.

    Y verás, probablemente puedas comprobar por ti mismo si estos códigos funcionan. Basta con que entres a la url de /wp-admin o /wp-login y encontraras errores 403

    Pero el resto del sitio esta completamente funcional.

    El hecho de que pueda seguir escribiendo y puedas leer este post, es prueba de que las configuraciones aquí aplicadas han funcionado.

    ¿Sobre qué ganamos con esto? la verdad, algo mas de paz. Ya no tienes que preocuparte tanto por la calidad de tu contraseña, pero no te descuides, para todo, activa A2F (autenticacion en dos factores) porque aun puedes tener accidentes. Ya sabes, errores de capa 8 jajaja.

    En adelante, los logs ya no deberán dar respuestas 200, sino un error 403. Ya es cuestión de modificar las reglas de fail2ban para que bloquee a los que provocan esos errores, pero claro, recordando que no te bloquees a ti mismo porque si olvidas entrar con wireguard activo, puede dejarte pateado afuera.

    https://interlan.ec/blog/2026/05/01/tutorial-mejorando-la-seguridad-de-wordpress-mediante-regas-nginx/ #Blog #devops #experimentos #linux #nginx #seguridadInformática #selfhosting #servidores #spam #tutorial #vps #wordpress
  4. Si, continuamos con la serie de tutoriales basadas en el hecho de que ya tenemos una red privada virtual (VPN) desde la que podremos acceder a la autenticación de servicios a los que solo nosotros accedemos.

    Introducción

    Hasta el momento hemos tenido éxito en dejar solo las rutas necesarias para NextCloud y dejando en secreto una instancia FreshRSS. La primera ruta es parcial y la segunda, oculta completa. Ahora, nos toca ocultar parcialmente una que puede resultar un poco más compleja debido a que hablamos de WordPress. El sistema de blogs utilizado para casi cualquier cosa y por eso puede tener puertas por todas partes.

    Ya no es necesario poner los requisitos puesto que ya los cumplimos todos, así que vamos directo a la teoría.

    Desarrollo

    La verdad pensé que sería tan sencillo como mandarle un location deny all, pero no. WordPress usa un sistema de rutas y embellecedores de URL que puede hacer que olvides que /wp-login no es lo mismo que /wp-login.php. Además, bloqueando el /wp-admin se te carga también el sistema AJAX, con lo que el contact form 7 dejaría de funcionar. Vamos repasando lo que hemos hecho para evitar todo esto.

    1
    2
    3
    4
    5
    6
    7
    8
    location = /wp-admin/admin-ajax.php {
            allow all; # Permitir que el público lo use para formularios/filtros
    
            # IMPORTANTE: Aquí debes incluir tu configuración de PHP
            # para que Nginx sepa cómo procesar el archivo.
            include snippets/fastcgi-php.conf;
            fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP
                    }

    Debes agregar este fragmento a tu archivo de configuración de nginx después de tu bloque de php. Esto es porque luego bloquearemos la ruta /wp-admin la cual terminará cargándose al admin-ajax.php el cual sirve para muchas funciones, especialmente para los plugins. pero si no tienes casi nada, es posible que solo afecte al funcionamiento de contact form 7

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    location /wp-admin{
         allow 10.0.0.0/24;
         deny all;
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP}
    
    location /wp-login{
         allow 10.0.0.0/24;
         deny all;
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP}location = /wp-login.php {
         allow 10.0.0.0/24;
         deny all;
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP}

    Estos bloques son de lo mas predecible. Al igual que en los casos anteriores, basta con definir la ruta que queremos bloquear y pues… bloquearla. Recuerda que la intención es que se pueda acceder por la red privada virtual, así que agrega tu rango de subred con el que tienes configurado WireGuard.

    Por ultimo, haremos unos cuantos ajustes de seguridad.

    1
    2
    3
    location ~* (readme.html|debug.log|license.txt) {
        deny all;
    }

    Esto es mas para protegerte de descuidos. El archivo readme.html y licence.txt está públicamente accesible. Bloquéalo para no delatar tu versión exacta de WordPress (es mas fácil atacar una versión especifica que atacar al azar hasta que aciertas a la vulnerabilidad que buscas).

    Debug.log es un archivo que queda visible si has habilitado la depuración. Hay mucha info sensible allí. Lo mejor es que lo escondas por si las dudas.

    Con estos cambios ya no tendrás que preocuparte tanto por ataques de fuerza bruta pues, no pueden forzar la cerradura si no hay cerradura XD.

    También te beneficia si tienes pocos recursos, porque tu servidor no tiene que estar atendiendo al ruido de Internet (bots, scrappers, etc) y puede centrarse en el trafico real.

    Conclusiones

    Pues verás, a diferencia de mi pobre lector de RSS que no tenia muchas visitas indeseadas, mi blog principal si que es atormentado todo el tiempo. Los que responden 200 son solo de tanteo. Confirman que la página existe. Pero los que devuelven otros errores son de ataques. Si no los bloqueara, estarían ahí todo el rato probando combinaciones de contraseñas hasta dar con la correcta y joderme la vida.

    Y verás, probablemente puedas comprobar por ti mismo si estos códigos funcionan. Basta con que entres a la url de /wp-admin o /wp-login y encontraras errores 403

    Pero el resto del sitio esta completamente funcional.

    El hecho de que pueda seguir escribiendo y puedas leer este post, es prueba de que las configuraciones aquí aplicadas han funcionado.

    ¿Sobre qué ganamos con esto? la verdad, algo mas de paz. Ya no tienes que preocuparte tanto por la calidad de tu contraseña, pero no te descuides, para todo, activa A2F (autenticacion en dos factores) porque aun puedes tener accidentes. Ya sabes, errores de capa 8 jajaja.

    En adelante, los logs ya no deberán dar respuestas 200, sino un error 403. Ya es cuestión de modificar las reglas de fail2ban para que bloquee a los que provocan esos errores, pero claro, recordando que no te bloquees a ti mismo porque si olvidas entrar con wireguard activo, puede dejarte pateado afuera.

    https://interlan.ec/blog/2026/05/01/tutorial-mejorando-la-seguridad-de-wordpress-mediante-regas-nginx/ #Blog #devops #experimentos #linux #nginx #seguridadInformática #selfhosting #servidores #spam #tutorial #vps #wordpress
  5. Vulnerabilidad crítica en cPanel: Hackers explotan activamente un fallo que afecta a millones de sitios web

    Un grave fallo de seguridad en el software de gestión de servidores cPanel y WHM está siendo utilizado activamente por atacantes. La vulnerabilidad permite a los hackers eludir la autenticación y tomar el control total de los servidores afectados (Fuente y Más información: Cpanel.net).

    El sector del alojamiento web se encuentra en estado de emergencia tras la revelación de un fallo crítico en cPanel y WebHost Manager (WHM), registrado con la clave CVE-2026-41940. Según las investigaciones publicadas por TechCrunch y diversas firmas de seguridad, la vulnerabilidad reside en el flujo de inicio de sesión gestionado por el demonio del servicio (cpsrvd), el cual escribe un archivo de sesión en el disco antes de que ocurra la autenticación real. Esto es aprovechado por los atacantes como una vulnerabilidad de omisión de autenticación no autorizada (unauthenticated bypass).

    Debido a la enorme cuota de mercado de cPanel y WHM en la industria, este fallo pone en riesgo a decenas de miles de servidores y a los millones de sitios web que alojan. Según las agencias de ciberseguridad, es altamente probable que se sigan produciendo ataques. Además, empresas de alojamiento como Namecheap y KnownHost detectaron intentos de acceso no autorizados, lo que indica que el error ha estado siendo explotado «en la naturaleza» (in the wild) durante semanas antes de que se lanzara el parche de emergencia.

    La respuesta de la industria ha sido inmediata. Proveedores y administradores han estado aplicando de urgencia los parches proporcionados por cPanel a través de la secuencia de comandos de actualización del servidor. La recomendación de los expertos es verificar que la infraestructura de alojamiento web esté actualizada a las últimas versiones y comunicarse inmediatamente con los proveedores de hosting para asegurar la mitigación de esta brecha que amenaza la integridad de los datos en internet.

    Y lo más importante es NO descartar las actualizaciones de cualquier sistema!!!

    #actualización #arielmcorg #ciberseguridad #cPanel #CVE202641940 #hackers #infosertec #PORTADA #servidores #tecnología #Vulnerabilidad #WebHosting #WHM
  6. Vulnerabilidad crítica en cPanel: Hackers explotan activamente un fallo que afecta a millones de sitios web

    Un grave fallo de seguridad en el software de gestión de servidores cPanel y WHM está siendo utilizado activamente por atacantes. La vulnerabilidad permite a los hackers eludir la autenticación y tomar el control total de los servidores afectados (Fuente y Más información: Cpanel.net).

    El sector del alojamiento web se encuentra en estado de emergencia tras la revelación de un fallo crítico en cPanel y WebHost Manager (WHM), registrado con la clave CVE-2026-41940. Según las investigaciones publicadas por TechCrunch y diversas firmas de seguridad, la vulnerabilidad reside en el flujo de inicio de sesión gestionado por el demonio del servicio (cpsrvd), el cual escribe un archivo de sesión en el disco antes de que ocurra la autenticación real. Esto es aprovechado por los atacantes como una vulnerabilidad de omisión de autenticación no autorizada (unauthenticated bypass).

    Debido a la enorme cuota de mercado de cPanel y WHM en la industria, este fallo pone en riesgo a decenas de miles de servidores y a los millones de sitios web que alojan. Según las agencias de ciberseguridad, es altamente probable que se sigan produciendo ataques. Además, empresas de alojamiento como Namecheap y KnownHost detectaron intentos de acceso no autorizados, lo que indica que el error ha estado siendo explotado «en la naturaleza» (in the wild) durante semanas antes de que se lanzara el parche de emergencia.

    La respuesta de la industria ha sido inmediata. Proveedores y administradores han estado aplicando de urgencia los parches proporcionados por cPanel a través de la secuencia de comandos de actualización del servidor. La recomendación de los expertos es verificar que la infraestructura de alojamiento web esté actualizada a las últimas versiones y comunicarse inmediatamente con los proveedores de hosting para asegurar la mitigación de esta brecha que amenaza la integridad de los datos en internet.

    Y lo más importante es NO descartar las actualizaciones de cualquier sistema!!!

    #actualización #arielmcorg #ciberseguridad #cPanel #CVE202641940 #hackers #infosertec #PORTADA #servidores #tecnología #Vulnerabilidad #WebHosting #WHM
  7. Dado lo bien que salio el ejercicio anterior, vamos a probar aislar un servicio por completo para posteriormente, aislar parcialmente un servicio. En este caso, FreshRSS.

    Introducción

    En el caso anterior, lo que hicimos fue segmentar un servicio que ya era privado y del que solo queríamos un segmento específico atendiendo a Internet. Este proceso se llama «reducción de superficie de ataque». Este proceso permite cerrar las puertas que pueden intentar forzar para entrar y causarte daño, pero en mi caso es más como reemplazar la puerta por una pared. Te adelanto que tal vez esta técnica no aplique para todos los casos, así que numeraré unos cuantos para que veas si te conviene seguir el camino del ermitaño o continuar como ya estabas.

    • Eres el único usuario de tus servicios e infraestructura. Es decir, montaste un servicio público por alguna necesidad puntual como, un lector RSS que puedas alcanzar desde cualquier parte de Internet o algún servicio de notas o algún servicio de sincronización.
    • Quieres tener control de tu infraestructura por una «puerta trasera» Suena feo, pero es cuestión de seguridad. No necesitas que todo el mundo esté tocando a la puerta todo el tiempo si eres el único que tiene la llave y el único que puede (y debe) entrar.
    • Quieres tener un terreno seguro de juego mientras desarrollas tus cosas. No necesitas desplegar SSL en un entorno privado. Eso facilita muchas cosas.

    En ese sentido, reducir la superficie de ataque puede ayudarte a no tener que preocuparte tanto por vulnerabilidades, pero puede complicar un poco la administración. Además claro, tienes que confiar en servicios que pueden caer y dejarte aislado de todo.

    La idea es simple y se basa en la siguiente premisa: «¿Si soy el único que usa los logins y demás sistemas de autenticación, ¿para qué tengo que dejarlos al aire para que todos los días estén dale que dale tratando de hackearlos por fuerza bruta los crawlers de Internet?» Así que la idea es simplemente negar el acceso a los sistemas de autenticación a la red expuesta a Internet y dejarla solo para la red expuesta a la red local o la red de WireGuard. Así que en teoría, lo que se necesita es lo siguiente:

    • Crear una red WireGuard.
    • Crear un servidor DNS para la red WireGuard
    • Configurar el DNS para que solo funcione en la interfaz de WireGuard
    • Configurar un servicio para que trabaje en la interfaz de WireGuard
    • Limitar los accesos a áreas públicas por la interfaz de red
    • Limitar los accesos a áreas de autenticación solo a la red de WireGuard

    Mira tú, ya tenemos casi todo completo y ahora solo falta ir resolviendo los casos particulares.

    Cambiando puertas por paredes

    En este ejercicio vamos a bloquear por completo el acceso y uso publico de un servicio que no necesita mas visitas que las mías. En este caso, FreshRSS.

    Esta vez no comparto los logs porque realmente hay poco trafico basura que mostrar.  La cosa es muy distinta cuando intente bloquear parcialmente el wp-admin y ya verán por que.

    Como esta vez el dominio es distinto del equipo de origen, tendremos que hacer algunos ajustes. Recuerda que esto es parte de un tutorial anterior.

    Agregamos nuevas reglas a Nginx para que solo permita el acceso desde la interfaz de Wireguard

    Al principio del archivo de configuración de nginx:

    1
    2
    3
    4
    5
    map $remote_addr $es_vpn {
        default 0;
        "~^10\.0\.0\." 1;  # Esto usa una expresión regular para atrapar a cualquiera que empiece con 11.0.0.}

    Dentro de tu regla server

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
               # 1. REGLA ESPECIAL PARA AJAX (WordPress la necesita pública)
               location = /wp-admin/admin-ajax.php {
                   include fastcgi_params;
                   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                   fastcgi_pass unix:/run/php/php8.4-fpm.sock;
               }
           
               # 2. BLOQUE ÚNICO PARA TODO PHP (Incluye la seguridad VPN)
            location ~ \.php(?:$|/) {
                # 1. Definir una variable de control
                set $permitido 0;
            
                # 2. Si es la VPN, sumamos 1
                if ($es_vpn = 1) {
                    set $permitido 1;
                }
            
                # 3. Si NO es zona restringida (o sea, es el front del sitio), sumamos 1
                if ($uri !~* "(wp-admin|wp-login)") {
                    set $permitido 1;
                }
            
                # 4. Si después de ambas comprobaciones sigue en 0, es que es zona restringida Y NO es VPN
                if ($permitido = 0) {
                    return 403;
                }

    Esta acción genera un error 403 para todos los directorios del dominio. Es justo lo que buscamos. Ahora tenemos que editar en el archivo que creamos antes. el hosts.wireguard para cambiar las rutas y dominios.

    10.0.0.2 freshrss.misitio.com #la ip en la red wireguard de tu servicio

    Y ejecutas el systemctl restart dnsmasq y listo. Como puedes ver, esta vez tuvimos que hacer muchos menos pasos y recuperamos, esta vez de forma exclusiva, el acceso a nuestra pagina de lector de RSS.

    Debido a que el firmado SSL no se encuentra fuera del servidor, esta vez no tenemos que mover nada mas. Lo tendremos firmado apenas lo abrimos.

    Conclusiones

    Esta vez logramos hacer esta tarea mucho mas rápido y metiendo menos código. Para este ejercicio, la verdad pensaba que iba a ser mas sencillo y funcionar a la primera con un simple deny al directorio correspondiente, pero como puedes ver, es un monton de lineas de codigo. Esto es porque tras algunas pruebas descubrí que si bien bloqueaba efectivamente al Internet abierto, en la VPN dejaba libre como esperabamos, pero dejaba de procesar el archivo php, devolviendo un wp-login.php en texto plano. Es decir, cualquiera que estuviera en tu VPN iba a poder ver los archivos PHP de tu servidor. Pero solo los que bloqueamos, claro. Tras algunas practicas, finalmente llegue a esta conclusion y creo que es la mas funcional. Lo sigo revisando por si hay alguna sorpresa, pero parece muy funcional.

    ¿Sobre los resultados de esto? han pasado varias semanas desde que lo implementé. Parece que si el servidor responde con 403, los crawlers llegan a cansarse y dejar de insistir. En el caso del log de hoy, solo hay un intento de acceder. mientras que para el día de ayer, solo fueron 4. Parece funcionar, ¿no?

    Estoy cuestionándome un poco sobre la practicidad de esto, puesto que si desplegaste Freshrss en una VPS o hosting, es probable que haya sido por lo práctico que es tener el lector unificado y accesible desde cualquier parte de Internet. En ese sentido, podrías elegir tener un lector local en tu dispositivo, pero esto es una práctica y vamos a hacer estas locuras hasta encontrarle un uso práctico. En próximas entregas ya hablaremos de un uso más serio, segmentando un sitio con más tráfico para probar y ver resultados.

    https://interlan.ec/blog/2026/04/24/tutorial-reduccion-superficie-de-ataque-mediante-wireguard-nginx-dnsmasq/ #experimentos #freshrss #la #linux #nginx #rss #seguridad #seguridadInformática #selfhosting #servidores #tutorial #vps
  8. ¡Holii!

    Esta es mi #presentación 👋😛

    Soy un apasionado de la #informática y la #tecnología desde que tengo uso de razón.
    Me encanta aprender, experimentar y #geekear con todo lo nuevo (y lo viejo, si es interesante).
    Tengo incalculables horas en #videojuegos, pero donde más disfruto es en coop/multi (¡Half-Life para siempre!).

    Cacharreo con #IoT, #STM32, #ESP32, #LoRaWAN y código.
    Desarrollo con #PHP y #Phalcon, y monto #servidores como si fueran LEGOs.

    También me interesa el #patrimonio, la #meteorología y la #seguridadinformática.

    El #covid me alejó de lo que siempre fue mi pasión: el #gaming, la comunidad, los amigos, las largas noches de partidas y ese mundo que tanto me inspiró. La vida se llenó de otras prioridades y necesidades, pero hoy siento que es el momento de volver a conectar 🙂

    Si te gusta la #tech, el #gaming o simplemente charlar, ¡aquí estoy!
    #spain #galicia #opensource #comunidad

  9. ¡Holii!

    Esta es mi #presentación 👋😛

    Soy un apasionado de la #informática y la #tecnología desde que tengo uso de razón.
    Me encanta aprender, experimentar y #geekear con todo lo nuevo (y lo viejo, si es interesante).
    Tengo incalculables horas en #videojuegos, pero donde más disfruto es en coop/multi (¡Half-Life para siempre!).

    Cacharreo con #IoT, #STM32, #ESP32, #LoRaWAN y código.
    Desarrollo con #PHP y #Phalcon, y monto #servidores como si fueran LEGOs.

    También me interesa el #patrimonio, la #meteorología y la #seguridadinformática.

    El #covid me alejó de lo que siempre fue mi pasión: el #gaming, la comunidad, los amigos, las largas noches de partidas y ese mundo que tanto me inspiró. La vida se llenó de otras prioridades y necesidades, pero hoy siento que es el momento de volver a conectar 🙂

    Si te gusta la #tech, el #gaming o simplemente charlar, ¡aquí estoy!
    #spain #galicia #opensource #comunidad

  10. ¡Holii!

    Esta es mi #presentación 👋😛

    Soy un apasionado de la #informática y la #tecnología desde que tengo uso de razón.
    Me encanta aprender, experimentar y #geekear con todo lo nuevo (y lo viejo, si es interesante).
    Tengo incalculables horas en #videojuegos, pero donde más disfruto es en coop/multi (¡Half-Life para siempre!).

    Cacharreo con #IoT, #STM32, #ESP32, #LoRaWAN y código.
    Desarrollo con #PHP y #Phalcon, y monto #servidores como si fueran LEGOs.

    También me interesa el #patrimonio, la #meteorología y la #seguridadinformática.

    El #covid me alejó de lo que siempre fue mi pasión: el #gaming, la comunidad, los amigos, las largas noches de partidas y ese mundo que tanto me inspiró. La vida se llenó de otras prioridades y necesidades, pero hoy siento que es el momento de volver a conectar 🙂

    Si te gusta la #tech, el #gaming o simplemente charlar, ¡aquí estoy!
    #spain #galicia #opensource #comunidad

  11. ¡Holii!

    Esta es mi #presentación 👋😛

    Soy un apasionado de la #informática y la #tecnología desde que tengo uso de razón.
    Me encanta aprender, experimentar y #geekear con todo lo nuevo (y lo viejo, si es interesante).
    Tengo incalculables horas en #videojuegos, pero donde más disfruto es en coop/multi (¡Half-Life para siempre!).

    Cacharreo con #IoT, #STM32, #ESP32, #LoRaWAN y código.
    Desarrollo con #PHP y #Phalcon, y monto #servidores como si fueran LEGOs.

    También me interesa el #patrimonio, la #meteorología y la #seguridadinformática.

    El #covid me alejó de lo que siempre fue mi pasión: el #gaming, la comunidad, los amigos, las largas noches de partidas y ese mundo que tanto me inspiró. La vida se llenó de otras prioridades y necesidades, pero hoy siento que es el momento de volver a conectar 🙂

    Si te gusta la #tech, el #gaming o simplemente charlar, ¡aquí estoy!
    #spain #galicia #opensource #comunidad

  12. ¡Holii!

    Esta es mi #presentación 👋😛

    Soy un apasionado de la #informática y la #tecnología desde que tengo uso de razón.
    Me encanta aprender, experimentar y #geekear con todo lo nuevo (y lo viejo, si es interesante).
    Tengo incalculables horas en #videojuegos, pero donde más disfruto es en coop/multi (¡Half-Life para siempre!).

    Cacharreo con #IoT, #STM32, #ESP32, #LoRaWAN y código.
    Desarrollo con #PHP y #Phalcon, y monto #servidores como si fueran LEGOs.

    También me interesa el #patrimonio, la #meteorología y la #seguridadinformática.

    El #covid me alejó de lo que siempre fue mi pasión: el #gaming, la comunidad, los amigos, las largas noches de partidas y ese mundo que tanto me inspiró. La vida se llenó de otras prioridades y necesidades, pero hoy siento que es el momento de volver a conectar 🙂

    Si te gusta la #tech, el #gaming o simplemente charlar, ¡aquí estoy!
    #spain #galicia #opensource #comunidad

  13. Solo como follow up sobre el tema, a modo de reflexion, para que vean la cantidad de energia que se desperdicia lidiando con los ataques y eso. En la gráfica se ve como aumenta el consumo de los servidores, causado principalmente por el aumento de la carga en Centaurus, el server principal donde corre PeerTube. Paso de una media de 360-370W a unos 450-480W sobre el final del ataque. Cuanta energia se gasta al pedo. #energia #servidores #undernet #spam #malware #ataque #ddos

  14. Solo como follow up sobre el tema, a modo de reflexion, para que vean la cantidad de energia que se desperdicia lidiando con los ataques y eso. En la gráfica se ve como aumenta el consumo de los servidores, causado principalmente por el aumento de la carga en Centaurus, el server principal donde corre PeerTube. Paso de una media de 360-370W a unos 450-480W sobre el final del ataque. Cuanta energia se gasta al pedo. #energia #servidores #undernet #spam #malware #ataque #ddos

  15. Solo como follow up sobre el tema, a modo de reflexion, para que vean la cantidad de energia que se desperdicia lidiando con los ataques y eso. En la gráfica se ve como aumenta el consumo de los servidores, causado principalmente por el aumento de la carga en Centaurus, el server principal donde corre PeerTube. Paso de una media de 360-370W a unos 450-480W sobre el final del ataque. Cuanta energia se gasta al pedo. #energia #servidores #undernet #spam #malware #ataque #ddos

  16. Solo como follow up sobre el tema, a modo de reflexion, para que vean la cantidad de energia que se desperdicia lidiando con los ataques y eso. En la gráfica se ve como aumenta el consumo de los servidores, causado principalmente por el aumento de la carga en Centaurus, el server principal donde corre PeerTube. Paso de una media de 360-370W a unos 450-480W sobre el final del ataque. Cuanta energia se gasta al pedo. #energia #servidores #undernet #spam #malware #ataque #ddos

  17. Solo como follow up sobre el tema, a modo de reflexion, para que vean la cantidad de energia que se desperdicia lidiando con los ataques y eso. En la gráfica se ve como aumenta el consumo de los servidores, causado principalmente por el aumento de la carga en Centaurus, el server principal donde corre PeerTube. Paso de una media de 360-370W a unos 450-480W sobre el final del ataque. Cuanta energia se gasta al pedo. #energia #servidores #undernet #spam #malware #ataque #ddos

  18. La huella digital – El rastro imborrable que puede resolver un crimen

    Recientemente, fui invitado por el equipo de La Nación + para participar en su panel de análisis periodístico, en el programa de los domingos, conducido por Gustavo Carabajal, Caso Abierto. El objetivo fue aportar una perspectiva técnica sobre un caso que conmociona a la opinión pública: la actividad sospechosa en las redes sociales de una persona que fue hallada sin vida (Caso del enfermero hallado muerto en Palermo).

    Durante mi intervención, hice especial hincapié en un concepto fundamental para la justicia moderna: la huella digital es absoluta y siempre queda un registro.

    https://youtu.be/85BMUOd0V9M

    El misterio de los perfiles que «cobran vida»

    Uno de los puntos más inquietantes del caso analizado es que la cuenta de la red social X (anteriormente Twitter) de la víctima cambió su configuración de público a privado pocas horas después de que se encontrara el cuerpo. Ante la pregunta de si esto podría ser una acción programada, mi respuesta fue contundente: no es posible programar un cambio de privacidad de este tipo.

    Este acto requiere una intervención manual. Como expliqué en el programa, esto significa que alguien, utilizando uno de los dispositivos de la víctima o un acceso remoto, administró la cuenta después del fallecimiento.

    Por qué la tecnología es el testigo clave

    En la era digital, es prácticamente imposible desaparecer sin dejar rastro. Durante el panel, destaqué tres puntos clave que los peritos informáticos analizan en estos casos:

    1. Registros en servidores: Más allá de lo que se borre en un teléfono o computadora, las plataformas como X, Instagram o incluso OnlyFans mantienen registros detallados en sus servidores.
    2. Múltiples conexiones: Las redes sociales permiten ver cuántos y qué tipo de dispositivos estaban conectados simultáneamente a una cuenta.
    3. Geolocalización y registros de acceso: Cada inicio de sesión deja una marca que indica la provincia o zona general de conexión, además de la identificación del equipo utilizado.

    La importancia del peritaje judicial

    Aunque un usuario común no puede acceder a estos datos técnicos de terceros, la justicia tiene las herramientas para solicitar a los proveedores de servicios (como X o Instagram) el historial completo de accesos.

    En casos donde se debate si la causa de muerte fue un homicidio o una situación accidental, estos rastros digitales se vuelven pruebas irrefutables. Todo lo que hacemos en internet, sin importar la aplicación o el sistema operativo, guarda un registro.

    #ArielCorgatelli #arielmcorg #ciberseguridad #dispositivosMóviles #EvidenciaDigital #huellaDigital #investigaciónJudicial #Justicia #LaNaciónMás #periciaTécnica #peritajeInformático #PORTADA #rastroDigital #redesSociales #seguridadInformática #servidores #tecnología
  19. 04/01 - 1º de abril: Dia da Mentira -
    💧#Privatização que não garante tarifa menor
    🚧 #Pedágios mais caros e estradas que não melhoram
    🏥 #Servidores desvalorizados
    📚 #Educação sem investimentos prometidos

    instagram.com/p/DWl6F69DktZ/ -

    RI @lcmarcolino13 -
    .Temos mentirosos profissionais? -

  20. 04/01 - 1º de abril: Dia da Mentira -
    💧#Privatização que não garante tarifa menor
    🚧 #Pedágios mais caros e estradas que não melhoram
    🏥 #Servidores desvalorizados
    📚 #Educação sem investimentos prometidos

    instagram.com/p/DWl6F69DktZ/ -

    RI @lcmarcolino13 -
    .Temos mentirosos profissionais? -

  21. Guía para Servidores Mac Mini: Encendido Automático con Linux

    Como muchos ya saben, tengo en casa 2 Mac Mini 2012 con procesadores Intel que están haciendo la función de servidores, uno con Ubuntu Server y otro con Debian. Estos equipos son ideales para usarlos como servidores porque consumen muy poco, tienen buena refrigeración, son silenciosos, y se pueden actualizar en cuanto a memoria RAM y disco duro. Por diversos motivos he tenido interrupciones de electricidad, y estaba buscando como configurar ambos Mac Mini para que, cuando detectaran que […]

    systeminside.net/guia-para-ser

  22. Guía para Servidores Mac Mini: Encendido Automático con Linux

    Como muchos ya saben, tengo en casa 2 Mac Mini 2012 con procesadores Intel que están haciendo la función de servidores, uno con Ubuntu Server y otro con Debian. Estos equipos son ideales para usarlos como servidores porque consumen muy poco, tienen buena refrigeración, son silenciosos, y se pueden actualizar en cuanto a memoria RAM y disco duro. Por diversos motivos he tenido interrupciones de electricidad, y estaba buscando como configurar ambos Mac Mini para que, cuando detectaran que […]

    systeminside.net/guia-para-ser

  23. Guía para Servidores Mac Mini: Encendido Automático con Linux

    Como muchos ya saben, tengo en casa 2 Mac Mini 2012 con procesadores Intel que están haciendo la función de servidores, uno con Ubuntu Server y otro con Debian. Estos equipos son ideales para usarlos como servidores porque consumen muy poco, tienen buena refrigeración, son silenciosos, y se pueden actualizar en cuanto a memoria RAM y disco duro. Por diversos motivos he tenido interrupciones de electricidad, y estaba buscando como configurar ambos Mac Mini para que, cuando detectaran que […]

    systeminside.net/guia-para-ser

  24. Guía para Servidores Mac Mini: Encendido Automático con Linux

    Como muchos ya saben, tengo en casa 2 Mac Mini 2012 con procesadores Intel que están haciendo la función de servidores, uno con Ubuntu Server y otro con Debian. Estos equipos son ideales para usarlos como servidores porque consumen muy poco, tienen buena refrigeración, son silenciosos, y se pueden actualizar en cuanto a memoria RAM y disco duro. Por diversos motivos he tenido interrupciones de electricidad, y estaba buscando como configurar ambos Mac Mini para que, cuando detectaran que […]

    systeminside.net/guia-para-ser

  25. 2026 – El año en que la IA se vuelve operativa y la infraestructura se convierte en estratégica

    Por Octavian Tanase, Chief Product Officer (CPO)Hitachi Vantara

    Si 2025 fue el año en que las empresas aprendieron a experimentar con la IA, entonces 2026 será el año en que aprendan a depender de ella. 

    La era de los proyectos piloto y de las herramientas aisladas de IA Generativa está dando paso a algo mucho más transformador: sistemas de IA capaces de actuar, decidir y operar con creciente autonomía, redefiniendo no solo la forma en que funcionan los negocios, sino también la infraestructura subyacente que las naciones utilizan para asegurar su futuro. 

    El hilo conductor más poderoso que conecta las principales tendencias del próximo año es simple pero profundo: la IA está evolucionando de una capacidad a una capa fundacional de la competitividad económica. Todo lo demás —desde la estrategia de datos y la arquitectura Cloud hasta el diseño de hardware y los modelos de fuerza laboral— ahora orbita en torno a ese cambio.

    En el centro de esta transformación está el auge de la IA Agéntica, la tendencia tecnológica empresarial definitoria de 2026. A diferencia de los modelos generativos anteriores que simplemente producían contenido, los sistemas de IA Agéntica pueden ejecutar tareas, tomar decisiones y operar de manera autónoma dentro de los flujos de trabajo del negocio. 

    Las empresas los integrarán en sus cadenas de suministro, operaciones de atención al cliente, procesos de cumplimiento y rutinas de análisis financiero. Estos agentes no solo responderán preguntas: tomarán acciones, activando flujos de trabajo, ajustando parámetros en tiempo real y gestionando decisiones que antes estaban en manos de personas.

    Pero con la autonomía llega la complejidad. Las organizaciones necesitarán sólidos sistemas de gobernanza, marcos de confianza y canalizaciones de datos de alta calidad para garantizar que estos agentes se comporten de manera predecible y responsable. Aquí emerge la segunda gran tendencia de 2026: los datos se convierten en la principal fuente de diferenciación competitiva.

    A medida que el cómputo, los modelos e incluso los algoritmos avanzados continúan “comoditizándose”, el diferenciador pasa a ser el dato propietario, de alta calidad y bien gobernado. Cada empresa deberá enfrentar una realidad común: la sofisticación de su IA dependerá menos de la potencia de sus modelos y más de la precisión, limpieza y confiabilidad de los datos que los alimentan. 

    Las compañías con ecosistemas de datos maduros tomarán ventaja rápidamente. Aquellas que no lo estén, tendrán dificultades para adaptarse, ya que los sistemas agénticos requieren ciclos de decisión más rápidos, correlación en tiempo real y señales contextuales más granulares.

    El tercer hilo conductor se apoya en este cambio: los gobiernos de todo el mundo ahora consideran la infraestructura de IA como un activo estratégico, al nivel de la energía o la defensa. El crecimiento de las nubes soberanas no es un movimiento de nicho, sino una respuesta geopolítica a la era de la IA. 

    Las naciones quieren la capacidad de poseer y proteger los datos que impulsan sus economías y resguardan a sus poblaciones. Exigen garantías sobre dónde se almacena la información sensible, cómo se entrenan los modelos y si los sistemas de IA pueden respetar los límites regulatorios.

    En 2026, se espera una aceleración significativa de los ecosistemas de nube soberana. Los países invertirán en centros de datos preparados para cumplir con regulaciones y diseñados específicamente para cargas de trabajo de IA, con alta eficiencia energética. Estas instalaciones se convertirán en los santuarios de los datos ciudadanos, financieros y 

    vinculados a la defensa, construidos para soportar el cumplimiento normativo y la supervisión nacional. A medida que proliferen los agentes de IA, la necesidad de supervisión nacional y control de la infraestructura será imposible de ignorar.

    Esto conecta directamente con la cuarta tendencia: la IA está llevando al límite físico las arquitecturas actuales de los centros de datos, forzando un ciclo de modernización sin precedentes. Las cargas de trabajo de IA y de sistemas agénticos demandan una densidad de cómputo extraordinaria, aceleradores especializados y arquitecturas de almacenamiento diseñadas para baja latencia y alto rendimiento. Las limitaciones de energía y refrigeración, antes consideradas un tema operativo, ahora se convierten en un factor restrictivo para la innovación en IA.

    Esta modernización no se trata solo de rendimiento. Está impulsada por la necesidad de liberar capacidad eléctrica para las cargas de trabajo de IA. Si las empresas no pueden liberar capacidad energética, no expandirán sus capacidades de IA, quedando rezagadas competitivamente. Los requisitos de sostenibilidad y las regulaciones emergentes también acelerarán este cambio, convirtiendo la eficiencia energética no solo en una mejora operativa, sino en un imperativo de cumplimiento.

    A través de estas tendencias clave emerge una narrativa única: la IA ya no es una herramienta superpuesta a las operaciones del negocio. Es la columna vertebral sobre la que dependerán las operaciones, la infraestructura, la regulación y las estrategias de los países. 

    La IA agéntica impulsa la necesidad de mejores datos. Mejores datos impulsan la necesidad de entornos seguros, soberanos y conformes. Esos entornos requieren infraestructura modernizada y energéticamente eficiente, diseñada específicamente para la automatización inteligente. Este ecosistema se retroalimenta.

    Y entre todo ello persiste una verdad humana final. Aunque los sistemas se vuelvan más autónomos, las personas siguen siendo esenciales. En 2026 veremos un fuerte impulso en la recapacitación de la fuerza laboral, no para convertir a los empleados en programadores, 

    sino en orquestadores capaces de aprovechar estos sistemas autónomos para transformar sus industrias. 

    Los próximos grandes avances no vendrán únicamente de científicos de datos, sino que también de expertos potenciados por IA.

    En 2026, la IA se convierte en la nueva infraestructura, y las organizaciones que comprendan este cambio de manera temprana definirán el panorama competitivo durante los próximos años.

    #arielmcorg #datacenters #hitachiVantara #infraestructuraIa #PORTADA #servidores
  26. Bueno, habiendo finalizado proceso de mejoras de hardware e incorporaciones para 2026, paso en limpio los números finales de las mejoras. La meta inicial de $U7000 fue superada ampliamente. Llegamos a juntar unos $U12897 y el gasto final fue de unos $U14184. Con eso pudimos comprar partes y repuestos e incrementar los recursos de RAM, disco y CPU globales como sigue:

    CPUs (+23%)
    Antes 26-cores -> ahora 36-cores

    RAM (+51%)
    Antes 74GB -> ahora 112GB RAM

    Almacenamiento (+69%)
    Antes 13TB -> ahora 22TB

    Estas mejoras nos van a permitir dedicar un servidor entero a Mastodon (lo cual redundará en la velocidad de respuesta), migración que llevará tiempo y que haré en estos días, posiblemente el sábado.

    Muchas gracias a las generosas colaboraciones que recibí, Undernet está en buena forma y lo único que viene quedando pendiente es resolver el tema de la UPS o baterías nuevas y organizar todo en un rack.

    Si desean colaborar con el proyecto, pueden colaborar en cualquiera de los medios de mastodon.uy/about

    #undernet #uruguay #mastodon #mejoras #actualizaciones #selfhost #servidores #autogestión