home.social

#experimentos — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #experimentos, 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. 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
  6. 🐾 ■ Estupefacción por la prueba cognitiva que han superado los cuervos y creían reservada únicamente a humanos ■ Las aves han logrado diferenciar formas geométricas muy parecidas sin ser preparadas para ello.
    huffingtonpost.es/life/animale

    #ciencia #aves #experimentos #animales

  7. Una de las características de los blogs mas conocidas son los sistemas de comentarios, que le da el aspecto social para poder distinguirse de las paginas web comunes. Aunque en la actualidad es muy común que los blogs ya no tengan ni caja de comentarios ni forma de contacto, aun veo gente probando alternativas. Vamos analizando las alternativas disponibles y sumemos una propuesta.

    Introducción

    Iniciar un blog es una decisión que tiene muchos preparativos detrás. Y uno de los mayores disuasorios es el hecho de que requiere una inversión monetaria en diferentes escalas, que muchas veces no nos podemos permitir. Hay soluciones que dependiendo de lo que quieras y creas, pueden ser o no buena idea. WordPress ofrece el servicio gratuito de hosting de blogs, pero no es divertido lidiar con una versión castrada de WordPress. Blogger también ofrece servicios gratuitos en una plataforma súper limitada. Puedes apostarle a plataformas sociales como Facebook, Instagram, Tumbrl que si bien son limitadas, ofrecen un gran alcance, pero la magia del blogging es que puedes elegir la casa que quieras según tus necesidades o limitaciones.

    Para este articulo, vamos a centrarnos en los generadores de sitios estáticos. Si ninguna de las alternativas anteriores te ha gustado, tal vez quieras probar crear tu blog c0mo un sitio estático y publicarlo en GitHub Pages puesto que no necesitas un servidor como en el caso de WordPress para servir paginas que ya has procesado localmente. Esto tiene la ventaja de que la carga es muy rápida y el alojamiento es gratuito, con el extra de que puede servirte de proyecto para tu hoja de vida. Por supuesto, tu página tendrá que usar un subdominio de GitHub, pero es un nombre con buena reputación que puedes utilizar de forma gratuita. Supongo que te darás cuenta del problema de utilizar un servidor de paginas estáticas; sin procesamiento del lado del servidor, no cuentas con el aspecto social del blogging.

    A medida que escribía este articulo, me fui dando cuenta de que no necesitas tomarte tantas molestias. Elije wordpress y ya. Blogger también te sirve. Son gratis y no es como que vayas a meter algo mas que texto e imágenes. Pero me di cuenta de que hay muchas decisiones envueltas a la hora de elegir servir un sitio estático en github pages. No las voy a repasar, pero si fuera por mi, diría que es por experimentar. Justo la razón por la que mantengo este blog y la razón por la que me molesta la falta de soporte de resaltado de código en wordpress. Es divertido y aprendo mucho.

    Justo por lo anterior, una de las ventajas de elegir un sitio estático estaría relacionado a la soberanía digital y a mantener un minimalismo en lo que publicas. Probablemente no necesites un servidor escuchando peticiones en el login todo el tiempo, o actualizando dinámicamente paginas que ya por tu elección, son estáticas. De hecho es lo que hay. En este blog, muchas paginas no vuelven a ser tocadas, por lo que no tiene sentido andar procesandolas una y otra vez. Se desperdicia recursos en algo que se puede hacer de forma mas eficiente.

    Mencione antes también, la soberanía digital. Podrías estar preocupado por cuanta información sobre tus lectores sale de tu sitio a servidores externos. Esto implica que esos datos obedecen a reglas fuera de tu control, lo que también puede significar que esos mismos datos serán monetizados de alguna forma. Alguien podría hablar de estos detalles. No creo ser el adecuado para ello.

    Sea cual sea tu razón para elegir sitios estáticos, hoy vamos a analizar algunas alternativas y luego propondre una por mi cuenta.

    Las alternativas

    Puedes utilizar muchas alternativas con diferentes enfoques según lo que prefieras. de hecho, Hugo mismo recomienda una lista que analizaremos un poco mas adelante. Pero debes tener en cuenta que todo lo gratis tiene un costo oculto que tal vez quieras o no asumir. El mas común en la perdida de soberanía digital. Las opciones de terceros, como Disqus monetizan con los datos de tus usuarios e insertan rastreadores, mientras que las opciones selfhosted como Commento o Isso te obligan a asumir la carga de procesamiento que evitabas al ingresar al mundo de los sitios estáticos. Ten en cuenta que esto ultimo también tiene un costo técnico en forma de parches de seguridad, actualizaciones y otras cosas que arruinan el concepto de simplicidad total que se espera de un sitio estático.

    Vamos analizando las características de algunos ejemplos que he seleccionado. Por supuesto, hay mas que puedes consultar por tu cuenta.

    Dependencia Externa¿Requiere Self-Hosting?Tipo de AlmacenamientoDisqus / FacebookAlta (Propietario)NoServidores de la empresa (Nube)Cactus CommentsMedia (Protocolo Matrix)OpcionalRed federada MatrixCommento / IssoBajaSiTu propia base de datos (SQL/Docker)Utterances / GiscusMedia (GitHub)NoGitHub Issues / DiscussionsStaticmanBaja (Transforma a Git)Si (Node.js)Tu propio repositorio (Archivos)
    • Disqus (La vieja escuela): Es el más fácil de instalar, pero el más invasivo. Dependes totalmente de su servidor y su política de privacidad.
    • Giscus/Utterances: Son muy populares actualmente. No requieren que tú gestiones un servidor, pero dependen de que GitHub esté activo y de que el usuario tenga una cuenta allí. Es «semi-estático» porque usa la API de GitHub.
    • Isso / Remark42: Son excelentes para la privacidad, pero te obligan a pagar un VPS o gestionar un contenedor Docker, lo cual anula la ventaja de tener un sitio estático «sin mantenimiento».
    • Staticman: Es lo más cercano a tu ideal, ya que convierte los comentarios en archivos de datos (JSON/YAML) dentro de tu repo, pero requiere un «servidor puente» (instancia de Node.js) para procesar el envío del formulario.

    Mi propuesta

    ¿Por qué no? Vamos aprovechando los recursos existentes, que asumo ya tienes, ya que quieres y puedes montarte un blog.

    Adelanto que esto solo es una prueba de concepto. En lo personal, las alternativas que analizamos son más completas y funcionales; aquí solo busco añadir una opción a la lista de alternativas existentes.

    Mail-Comment es una prueba de concepto de comentarios en páginas estáticas basado en correo electrónico. De la misma forma en la que buscaba otros usos para IMAP, se me ocurrió esta idea, notándole algunas ventajas interesantes.

    • Soberanía digital: tus datos son tuyos. Los datos de tus seguidores son únicamente los que comparten entre ustedes en una comunicación normal de correo electrónico.
    • Panel de moderación improvisado: antes de hacer públicos los comentarios que recibes, puedes aprovechar los filtros de spam existentes y decidir qué publicar.
    • Control adicional de SPAM: agrega filtros y palabras clave para controlar el spam.
    • Múltiples salidas: elige la que más te convenga según la plataforma que tengas.
    • Filtro de dominio: añade reglas que permitan participar específicamente en el post elegido.
    • Widgets y botones: configúralos en tu sitio para facilitar el proceso.
    • Compatibilidad con Hugo: añade los comentarios directamente en tus posts de Hugo.
    • Minimalismo total: sin JavaScript añadido, sin iframes y sin necesidad de otros servidores, propios o ajenos.

    Características

    • No necesita registro: cualquiera puede escribir un comentario, siempre y cuando tenga un correo electrónico.
    • Identidad (esto hay que revisarlo): identifícate con tu nombre de usuario de correo electrónico.
    • Compatibilidad con diferentes estrategias:
      • Comentarios por archivos RSS. Puedes añadir un widget que lea archivos XML a modo de comentarios.
      • Comentarios estáticos HTML. Exporta los comentarios como fragmentos HTML que puedes integrar en tu página.
      • Comentarios estáticos MarkDown. Exporta los comentarios como fragmentos MarkDown que puedes integrar en tu pagina.
      • Integración con Hugo. En tu instancia local, añade los comentarios al final de tus archivos MarkDown de hugo, según la url comentada.
      • Integración con WordPress. Añade un webhook en tu servidor de WordPress para recibir los comentarios sobre una URL para una instancia Headless.

    Dado que es un prototipo, estaré analizando mas cosas y mejoras que hacer.

    Instalación y ejecución

    En Linux necesitas crear un entorno virtual (venv). Te adjunto los comandos para crearlo y ejecutarlo, pero recuerda que tienes que editar el archivo .env:

    git clone https://git.interlan.ec/Drk0027/mail-comment.git
    cd mail-comment
    pip install -r requirements.txt
    cp .env.example .env
    python -m venv
    source venv/bin/activate
    python email-processor.py
    

    He dejado un archivo .env.example para que lo copies a .env y lo configures según tus necesidades. Recuerda que necesitas un servidor IMAP, que puede ser el de tu correo electrónico.

    Advertencia

    Recuerda que publicar tu dirección de correo puede ser algo sensible. Puede exponerte a spam y a vulnerabilidades que podrían causarte daño. Te recomiendo que, si quieres utilizar este enfoque, crees una cuenta nueva dedicada a esta tarea.

    Nota

    En el estado actual, el script revisa todos los correos de la carpeta INBOX, pero solo borra los que cumplan los requisitos de los que hablaremos mas adelante. Esto es por seguridad: así, si quieres hacer pruebas, no terminaras con toda tu bandeja aniquilada.

    El script analiza uno por uno los correos dentro de la bandeja que has especificado. Si está muy llena o si tu servidor es lento, esta tarea puede tardar bastante.

    Si bien, es posible utilizar el correo de gmail, es algo de lo que tengo dudas y no he tenido la oportunidad de probar todavía. Parece que se puede utilizar una clave de aplicación, si alguien lo intenta, puede decirme para actualizar este post. Aun así, en teoría puedes usar los mismos servidores que usarías en delta chat.

    👉 https://providers.delta.chat/

    Flujo de trabajo

    • Publica normalmente como siempre haces. Añade un texto o un botón para indicar a los usuarios como realizar los comentarios, mediante correo electrónico. Para que funcione esta herramienta, el asunto debe contener la URL de la pagina que se desee comentar. Esto sirve de validación para separar el spam de los comentarios legítimos.

    Por supuesto, si no quieres agregar el botón o crees que el enlace mailto no funciona, puedes pedir que te escriban directo desde sus bandejas de entrada, indicando en el asunto la url del post que deseas que comenten.

    Comentar esta entrada por correo electrónico

    • En el archivo .env deberás configurar el DOMAIN_TO_SEARCH con tu dominio para poder localizar el destino de los comentarios. Esto también te evitará algo de SPAM puesto que los procesos automatizados no saben que estarás utilizando este sistema de comentarios (a menos que se haga popular y los crawlers terminen aprendiendo como funciona y empiecen a joder simulando ser usuarios legítimos)

    En el archivo .env también puedes configurar palabras clave que puedes usar a modo de filtro mediante IGNORE_KEYWORDS=publicidad,notificacion,spamintroduce todas las palabras que quieras usar. Pero esto es mas útil si eliges ejecutar este script de forma regular, con poca o ninguna supervisión.

    • Al ser un correo normal, puedes revisar la bandeja de entrada para leer lo que ha llegado y decidir si lo borras o lo dejas antes de ejecutar el programa. Usa tu bandeja de entrada a modo de panel de moderación y de esta manera, puedes incluso aprovechar los filtros de tu proveedor de correos, como gmail, que usualmente es muy efectivo.
    • Elije una o todas las opciones de exportación o integración.

    SAVE_HTML=True
    SAVE_MARKDOWN=True
    SAVE_XML=True
    SEND_WEBHOOK=True
    • Si estas usando una instancia Headless de wordpress, puedes utilizar un snippet o editar un plugin o tema para integrar y crear un nuevo webhook para recibir los comentarios.

    https://git.interlan.ec/Drk0027/mail-comment/src/branch/main/functions.php

    WP_WEBHOOK_URL=https://tusitio.com/wp-json/tudominio/v1/recibir-comentario
    WEBHOOK_SECRET_TOKEN=mi_clave_secreta_123
    
    • Si estas usando Hugo, agrega el directorio donde estas editando tu sitio.

    HUGO_DIR = /home/user/quickstart/
    APPEND_HUGO = True

    Esta función prepara todos los comentarios recibidos y los agrega al final de tus entradas en Hugo que correspondan a la URL equivalente.

    Solo lo he probado con un despliegue básico de Hugo. Por eso se llama QuickStart XD

    • Ejecuta el script.

    Recuerda usar un venv en linux. Hay formas de usarlo sin tener que andar activando el venv, pero me da pereza explicarlo ahora.

    python email-processor.py
    

    El Script hará las siguientes cosas:

    • Se conectará al servidor de correo
    • De la bandeja seleccionada (INBOX por defecto) revisará uno por uno los mensajes
      • Obtiene el asunto (corresponde al titulo de la página y también al directorio local de Hugo)
      • Filtra que el dominio de la URL corresponda al del sitio, registrado en el .env (evita spam)
      • Obtiene remitente (se usará para identificar al comentarista)
      • Obtiene el mensaje y depura el HTML con el fin de obtener una versión mas simple y libre de posibles scripts indeseados.
      • Valida si el mensaje contiene alguna de las palabras de IGNORE_KEYWORDSy si no es el caso, continua el flujo
        • Si esta activo SAVE_MARKDOWN guardara un fragmento por mensaje
        • Si esta activo SAVE_XML guardará fragmentos para RSS en XML
        • Si esta activo SEND_WEBHOOK enviará el comentario al webhook de wordpress. Recuerda que tienes que haber configurado el secreto entre ambos.
        • Si esta activo SAVE_HTML guardara fragmentos HTML por mensajes
        • Si esta activo APPEND_HUGO convertirá el contenido HTML a Markdown y buscará en los directorios especificados en busca del post deducido de la URL. en caso de encontrarlo, agregara el comentario al final del post.
      • Borra los mensajes procesados
    • Cierra la sesión IMAP

    El resultado es que se integraran los comentarios en las entradas y estos se cargaran la próxima vez que actualices tu sitio.

    Resultado de mail-comment y hugo

    Conclusiones

    He escrito esta herramienta como prueba de concepto para añadir más alternativas a sitios estáticos que no desean tener servicios externos ni depender de servidores propios o ajenos. La idea resultó más extensa de lo que creí para un simple script en Python que automatiza tareas, pero me inspiré en los bots de Telegram para su flujo de trabajo.

    Dejo los recursos que he creado para que quien desee lo pruebe y, si así lo desea, me deje una opinión.

    Actualización

    Me quedan pendientes de hacer algunas cosas. como por ejemplo, una pagina de demo para mostrar funcionando el proyecto, pero me encontré con la particularidad de que no he contemplado el alojamiento en rutas de un dominio/subdominio y eso que funciona hasta para localhost jajaja

    Tambien encontré otro servicio similar a mi idea. ¡Hasta por las mismas razones! jajaja.

    Cito traducido de su pagina:

    Cada vez menos sitios web independientes admiten comentarios enviados por los lectores. Una barrera es que los diseños existentes están fundamentalmente en desacuerdo con lo que el usuario quiere y lo que necesita el moderador del sitio. Las principales compensaciones son entre brindar una experiencia conveniente y respetuosa para el visitante del sitio, manteniendo al mismo tiempo la capacidad de moderar los comentarios en busca de spam y contenido ofensivo.

    Históricamente, exigir a los usuarios que se registren para obtener cuentas antes de enviar comentarios ha sido el principal enfoque de moderación; sin embargo, un flujo de registro está en conflicto con el objetivo de conveniencia del visitante. Una alternativa a esto ha sido asociarse con grandes empresas comerciales de redes sociales para aprovechar su mayor conjunto de cuentas que muchos visitantes del sitio probablemente ya tendrán en estas otras plataformas. Este enfoque ayuda a aliviar el problema de conveniencia mencionado anteriormente (asumir que los visitantes utilizan las redes sociales), pero lo hace a expensas de su privacidad. Podría decirse que este compromiso es peor, porque los problemas de privacidad a menudo ocurren sin el conocimiento del lector.

    https://spenc.es/writing/email-as-a-commenting-system/

    Observo con curiosidad con que aunque la idea es la misma y las razones de su origen también, el desarrollo es totalmente diferente. Uh, súper diferente la verdad.

    Mientras r3ply se orienta a un despliegue permanente en la nube, Mail-Comment se puede ejecutar bajo demanda en tu propio equipo, sin infraestructura adicional

    • r3ply está diseñado para desplegarse como un servicio permanente en la nube (ej. AWS), siempre activo y disponible para procesar comentarios en tiempo real.
    • Mail-Comment en cambio, funciona como un script autónomo que puedes ejecutar bajo demanda en tu propio equipo, sin necesidad de infraestructura adicional ni de mantener un servidor 24/7.

    Pero ya que estamos, analicemos este ecosistema un momento

    • r3ply Proyecto open‑source que convierte correos electrónicos en comentarios para sitios web estáticos. Similar a Mail-Comment, aprovecha IMAP/SMTP y añade anonimización de direcciones. (parece que ha dado de baja su repo de git porque esta haciendo cambios y mejoras. al menos eso deduzco de sus comentarios)
    • Staticman Permite añadir comentarios a sitios estáticos mediante *pull requests* en GitHub/GitLab. https://staticman.net/
    • Cusdis Sistema ligero y open‑source de comentarios, centrado en privacidad. Aunque no está basado en correo, permite moderar comentarios vía notificaciones por email. https://cusdis.com/
    https://interlan.ec/blog/2026/01/16/comentarios-en-sitios-estaticos/ #Código #DIY #email #experimentos #programacion #python #selfhosting
  8. Los preuniversitarios en el campo en #Cuba fueron uno de los #experimentos sociales más traumáticos del sistema educativo #cubano. La idea surgió a finales de los años 60 y se consolidó en los 70, inspirada directamente por el modelo #socialista #soviético y por la visión del #Estado cubano de “formar al hombre nuevo”. El proyecto combinaba estudios académicos con trabajo agrícola.

  9. 🔥 ■ Milán, profesor que se disfraza de Batman en el metro para comprobar los efectos: "Con la ciencia también hay que ensuciarse las manos" ■ Su objetivo era medir qué ocurre cuando un elemento inesperado y disruptivo irrumpe en una rutina.
    huffingtonpost.es/virales/mila

    #virales #italia #batman #sociologia #estudios #antropologia #experimentos

  10. 🧘 ■ Los Ig Nobel vuelven a premiar a la ciencia más loca: lagartos yonquis de pizza, una vaca cebra y bebés enganchados al ajo ■ Los galardones que premian lo “improbable pero real” celebran 35 años de ciencia delirante con hallazgos como la receta definitiva de la pasta cacio e p[…]
    huffingtonpost.es/life/los-ig-

    #life #ciencia #premiosnobel #experimentos

  11. 💪 ■ Cierra el puño y extiende solo este dedo: descubrirás que es totalmente imposible y un experto sabe el motivo ■ Si puedes tal vez tengas una mano única.
    huffingtonpost.es/life/salud/c

    #experimentos #humano #anatomia #salud

  12. 💪 ■ La ciencia confirma que estos baños no ayudan a la recuperación muscular después del ejercicio ■ Se comprobó con un grupo de 30 mujeres jóvenes y activas.
    huffingtonpost.es/life/salud/l

    #salud #calor #ejerciciofisico #experimentos #frio

  13. 💪 ■ La OMS advierte que el mineral que muchos españoles tenemos guardado en casa es cancerígeno ■ Un estudio afirma que el talco ha presentado características clave de carcinógenos en "células primarias humanas y sistemas experimentales".
    huffingtonpost.es/life/salud/l

    #ratas #cancerigenos #salud #investigacion #oms #experimentos

  14. 💪 ■ La OMS advierte que el mineral que muchos españoles tenemos guardado en casa es cancerígeno ■ Un estudio afirma que el talco ha presentado características clave de carcinógenos en "células primarias humanas y sistemas experimentales".
    huffingtonpost.es/life/salud/l

    #ratas #cancerigenos #salud #investigacion #oms #experimentos

  15. 🌱 ■ Desmontan al "hombre más sano del mundo" que pide que te acuestes pronto, comas sano y te unas a su nueva religión ■ "En definitiva, no es un proyecto de medicina".
    huffingtonpost.es/life/desmont

    #experimentos #life

  16. Comentários (ou conversas) por e-mail

    Vamos fazer um novo experimento em novembro? Ao longo do mês, os comentários de novos posts no Manual ficarão fechados e, em seu lugar, haverá um convite para conversarmos por e-mail.

    manualdousuario.net/comentario

  17. agora é aguardar pra ver se a mente científica do infante vê alguma diferença entre pré-enfumaçado e pós enfumaçado.

    #experimentos

  18. Salgo junto a Guadalupe Sabio hacia el CEIP Guadiana de Badajoz a hablar de ciencia y extraer el #ADN de los alumnos con ingredientes que todos tenemos en casa.

    Para quien no pueda ir, aquí están las instrucciones:

    🔗cuantaciencia.com/llevate-tu-a

    #divulgacióncientífica #experimentos

  19. Ha llegado el momento de tener esa conversación sobre mecánica cuántica... El penúltimo «cuaderno experimental» ha llegado

    Cuadernos experimentales: efecto Zeeman | El Pingüino Tolkiano

    elpinguinotolkiano.wordpress.c

    #Ciencia
    #Educación, #Experimentos, #Física

  20. Estoy preparando un programa de radio para la emisora de mi localidad. Pondré comentario #rb o similar a las noticias que me gustaría "cubrir". A ver cómo funciona.... #experimentos