home.social

#servidores — Public Fediverse posts

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

  1. Pues verás, uno de los problemas más fastidiosos que he tenido son los numerosos líos relacionados con la falta de memoria RAM. Por supuesto, esto es gracias a que tengo contratado el paquete mínimo; aun así, dado mi escasísimo tráfico, no debería tener estos problemas. Por eso, zram viene en un contexto donde swap pudo haber ayudado, pero no es recomendado porque DigitalOcean mismo advierte que no se debería usar swap en un droplet con SSD.

    Introducción

    Como ya me he quejado antes en otros artículos, al usar un droplet de espacio tan limitado como el modelo básico de 1GB de RAM y 25GB de disco SSD, frecuentemente encuentro problemas de escasez de memoria RAM, por lo que mis servicios se caen o dejan de funcionar. Esto podría haber sido lidiado con swap, pero digitalOcean prefiere que no lo active, y de hecho se encuentra desactivado por defecto, para evitar la degradación de los discos SSD pues, tienen un tiempo limitado de vida. Aún así, y teniendo en cuenta que hace poco escribí una entrada hablando de zram me di cuenta de que esa era la solución. ZRAM no escribe en el disco, sino que trabaja reservando un espacio de la memoria RAM y comprimiendo allí mismo los datos, de tal manera que puede con las configuraciones apropiadas, duplicar la RAM. Por supuesto, esto no es mágico y depende de ciertas circunstancias, pero para el propósito que se contrata un droplet tan básico, es suficiente.

    Como activar zram en debian

    En Debian es sumamente sencillo gracias al paquete oficial zram-tools. Abre tu terminal y ejecuta los siguientes comandos como usuario root o usando sudo:

    sudo apt update && sudo apt install zram-tools -y

    Luego, basta con configurar los parámetros optimizados

    sudo nano /etc/default/zramswap

    Dentro del archivo, busca las siguientes líneas, descoméntalas (elimina el símbolo # si lo tienen) y edítalas para dejarlas con estos valores ideales para un VPS de 1 GB:

    • ALGO=zstd (Utiliza el algoritmo de compresión zstd, balance perfecto entre ahorro de espacio y velocidad de CPU).
    • PERCENT=60 (Asigna hasta un 60% de tu RAM física para ser usada como bloque comprimido, lo que equivale a unos 600 MB en tu máquina de 1 GB). [1, 2]

    Guarda los cambios presionando Ctrl + O, confirma con Enter y sal con Ctrl + X.

    Y finalmente acepta los cambios reiniciando el demonio de zram:

    sudo systemctl restart zramswap

    Por supuesto, puedes confirmar que el servicio esta funcionando con el siguiente comando:

    sudo swapon –show

    deberia salirte algo similar a esto:

    NAME       TYPE      SIZE USED PRIO

    /dev/zram0 partition 600M 0B   100

    Por supuesto, puedes echarle un ojo tambien a la salida del comando htop. en mi caso deje solo 256M para zram puesto que he optimizado el droplet y ya no necesito tanta RAM como antes.

    htop con zram activo

    Conclusiones

    Zram es una utilidad muy necesaria para poder optimizar y sacarle hasta lo último al hardware limitado, pero te advierto que no es raro que hayan novedades. Tendrás más holgura sí, pero como mencioné en el artículo anterior, la razón por la que algo tan bueno no viene activo por defecto es porque puede haber inestabilidad en el sistema. Aún así, está muy optimizado y la probabilidad de que ocurra algo malo es bajísima. Ya lo tengo activo en mi droplet, por lo que si ocurre algo, terminaré reportándolo por aquí jajaja

    https://interlan.ec/blog/2026/07/17/tutorial-zram-en-droplet-de-digital-ocean/ #devops #linux #selfhosting #servidores #Swap #tutorial #vps #zram
  2. Proposta: Servidores de jogos ativos pra sempre?

    Já pensou obrigar estúdios a manter servidores de games "para sempre"? 😳

    - O que está rolando:
    • Projeto de lei propõe que empresas que desenvolvem games mantenham os servidores ativos indefinidamente.
    - Por que isso é polêmico:
    • Você compra um jogo e, hoje, o servidor pode parar de funcionar um dia.
    • Empresas lançam coisas novas; se não inovarem, o ecossistema...

    #games #servidores #política #gaming #jogos #debate #MorningCrypto

  3. Água: Uma ameaça ronda São Carlos

    Para pressionar a cidade paulista, programa estadual de privatização do saneamento tem um ardil: estudos questionáveis de falhas no serviço. Dados refutam a narrativa. Busca obsessiva de lucros destrói o setor. Caso Sabesp é emblemático

    outraspalavras.net/alemdamerca

  4. ¿Buscas hosting potente y flexible? Descubre las ventajas del VPS hosting con recursos dedicados y control total. IDEI Web te ofrece servidores virtuales privados de alto rendimiento. Conoce más sobre sus soluciones de VPS hosting y elige el plan perfecto para tu proyecto. #VPS #Hosting #Servidores #IDEIWeb

    ideihosting.com/vps-hosting/

  5. ¿Quieres el verdadero superpoder de los servidores Dell? ⚡ Se llama iDRAC (Integrated Dell Remote Access Controller).

    Es un chip en la placa base que te permite encender, apagar, actualizar y diagnosticar tu servidor desde cualquier parte del mundo, incluso si el sistema operativo se ha colapsado por completo. Es como tener las manos dentro del servidor sin moverte de tu silla. Infaltable en IT.

    #iDRAC #Dell #Servidores #SysAdmin #DataCenter #Hardware #Tech

  6. ¿Un servidor como PC cliente? 🖥️🛠️

    Su desempeño es un contraste total. Destaca de forma masiva en multitarea pesada, virtualización, renderizado y bases de datos locales gracias a sus procesadores multihilo y gigabytes de RAM ECC.

    ¿Su punto débil? El gaming y tareas cotidianas. Al carecer de potencia mononúcleo alta y GPUs comerciales, los juegos van fatal. Además, hacen mucho ruido y tardan minutos en arrancar.

    #Sistemas #Servidores #Hardware #HardwareTech #SysAdmin #Mastodon

  7. ¿Un servidor como PC cliente? 🖥️🛠️

    Su desempeño es un contraste total. Destaca de forma masiva en multitarea pesada, virtualización, renderizado y bases de datos locales gracias a sus procesadores multihilo y gigabytes de RAM ECC.

    ¿Su punto débil? El gaming y tareas cotidianas. Al carecer de potencia mononúcleo alta y GPUs comerciales, los juegos van fatal. Además, hacen mucho ruido y tardan minutos en arrancar.

    #Sistemas #Servidores #Hardware #HardwareTech #SysAdmin #Mastodon

  8. ¿Un servidor como PC cliente? 🖥️🛠️

    Su desempeño es un contraste total. Destaca de forma masiva en multitarea pesada, virtualización, renderizado y bases de datos locales gracias a sus procesadores multihilo y gigabytes de RAM ECC.

    ¿Su punto débil? El gaming y tareas cotidianas. Al carecer de potencia mononúcleo alta y GPUs comerciales, los juegos van fatal. Además, hacen mucho ruido y tardan minutos en arrancar.

    #Sistemas #Servidores #Hardware #HardwareTech #SysAdmin #Mastodon

  9. ¿Un servidor como PC cliente? 🖥️🛠️

    Su desempeño es un contraste total. Destaca de forma masiva en multitarea pesada, virtualización, renderizado y bases de datos locales gracias a sus procesadores multihilo y gigabytes de RAM ECC.

    ¿Su punto débil? El gaming y tareas cotidianas. Al carecer de potencia mononúcleo alta y GPUs comerciales, los juegos van fatal. Además, hacen mucho ruido y tardan minutos en arrancar.

    #Sistemas #Servidores #Hardware #HardwareTech #SysAdmin #Mastodon

  10. ¿Un servidor como PC cliente? 🖥️🛠️

    Su desempeño es un contraste total. Destaca de forma masiva en multitarea pesada, virtualización, renderizado y bases de datos locales gracias a sus procesadores multihilo y gigabytes de RAM ECC.

    ¿Su punto débil? El gaming y tareas cotidianas. Al carecer de potencia mononúcleo alta y GPUs comerciales, los juegos van fatal. Además, hacen mucho ruido y tardan minutos en arrancar.

    #Sistemas #Servidores #Hardware #HardwareTech #SysAdmin #Mastodon

  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. ¡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

  19. ¡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

  20. ¡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

  21. ¡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

  22. ¡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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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
  29. 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? -

  30. 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? -