SSL/TLS: Self-signed Certificate Authority for NGINX on FreeBSD
https://rtfm.co.ua/en/ssl-tls-self-signed-certificate-authority-for-nginx-on-freebsd/
I run a bunch of web services
#FreeBSD #Linux #NGINX
SSL/TLS: Self-signed Certificate Authority for NGINX on FreeBSD

Setting up your own Certificate Authority on FreeBSD, signing a wildcard SSL/TLS certificate for NGINX, and adding the CA to the trust store on FreeBSD and Linux clients

RTFM: Linux, DevOps, and system administration | DevOps-engineering, and system administration. Cases from practice.
Jetzt patchen nginx-ui! Angreifer übernehmen Kontrolle über Nginx-Server

Derzeit nutzen Angreifer eine kritische Sicherheitslücke im Web-Managementtool nginx-ui aus. Davon sind auch Instanzen in Deutschland bedroht.

heise online
🚀 Install and Run Self-hosted #Mattermost Instance on Linux #VPS This article provides a comprehensive guide to install and run self-hosted Mattermost instance on Linux VPS (Ubuntu/Debian). This guide will set up Mattermost with #PostgreSQL and #NGINX as a reverse proxy with HTTPS.
What is Mattermost?
Mattermost is a self-hosted, open-source collaboration platform ...
Continued 👉 https://blog.radwebhosting.com/self-hosted-mattermost-instance/?utm_source=mastodon&utm_medium=social&utm_campaign=mastodon.raddemo.host #opensource #letsencrypt #selfhosted #reverseproxy #unifiedcommunications #selfhosting

🚀 Deploy #Odoo on Rocky Linux #VPS

This guide walks through the steps to deploy Odoo on Rocky Linux VPS using PostgreSQL, #Python virtual environment, #Nginx reverse proxy, and systemd. This setup is production-ready and appropriate for business deployments.
What Is Odoo?
Odoo is an open-source business management platform that integrates many core business functions into one ...
Continued 👉 https://blog.radwebhosting.com/deploy-odoo-on-rocky-linux-vps/?utm_source=mastodon&utm_medium=social&utm_campaign=mastodon.raddemo.host #opensource #letsencrypt #rockylinux #selfhosted #postgresql #selfhosting

nginx + ssl production config — on 4grab.com security headers, rate limiting, reverse proxy, HTTPS setup. copy-paste configs that actually work in production. https://4grab.com/pay.php?id=ptag_69c4361231092 #prompt #nginx #ssl #devops
Nginx in Production: SSL, Reverse Proxy, Rate Limiting, Security Headers — Purchase

After fixing two AUR `PKGBUILD` files and a bit of patching, the initial rough Arch repo is online. Even made the package list look good with some fancy indexing. The compile takes a long time, but since it's in a VM I'm not too bothered about it. I will probably make an actual build system, but for now the crontab will suffice.

#archlinux #nginx #svtav1 #handbrake #vapoursynth

Critical Nginx UI auth bypass flaw now actively exploited in the wild

A critical vulnerability in Nginx UI with Model Context Protocol (MCP) support is now being exploited in the wild for full server takeover without authentication.

BleepingComputer
Dado que aprovechar la inteligencia artificial para tareas sencillas es imposible sin una supercomputadora (o muchas supercomputadoras), volvemos a los orígenes con un nuevo plan de mejora para las VPS. Contamos con WireGuard, lo hemos pulido hasta que funciona con el ancho de banda completo. Vamos a confiar un poco más en el para administrar los servicios que tenemos expuestos por internet… ¡En privado!

Introducción

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 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 ←Estamos aquí
  • 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
Todo esto se me ocurre en el contexto de que tengo un servidor NextCloud que trabaja en público y a diario tengo crawlers intentando entrar. La solución simple es fácil. Ya que ahora trabaja mediante WireGuard, puedo agregar la IP de la VPN y usarla de forma privada. No es gran problema excepto porque me interesa que se mantengan las funciones públicas, como los enlaces compartidos, las agendas de calendarios y alguna cosa que se me antoje por ahí. En ese sentido, la complejidad aumenta bastante porque no es solo desconectar de la interfaz pública, sino también elegir las rutas que dejarán de ser accesibles por Internet y que estas sean accesibles por la red WireGuard. Si la teoría es posible, me gustaría poder aplicar esto a más servicios en los que soy el único que se autentica, como por ejemplo este blog. Por esa razón, vamos a necesitar la ayuda de un DNS local exclusivo para WireGuard.

Agregando Reglas Nginx

Para empezar, tomaré como modelo mi servidor de Nextcloud, puesto que no necesito hacer mas maromas para lograr lo que quiero. Lo primordial será bloquear el acceso de las rutas de autenticación a través de Internet. Para eso vamos viendo como están los logs. logs de mi instancia de nextcloud mostrando algunos accesos por login y un monton de escaneos de directorios Como se puede ver en la imagen, hay varios intentos de acceso por la url login, pero un montón de escaneos de directorios (debo mejorar las reglas de fail2ban) Ya he descontado mis propios accesos y también del monitor uptime. Lo primero es agregar las reglas apropiadas para limitar el acceso a la ruta /login Hay que recordar que NextCloud tiene una regla que redirecciona el trafico no autenticado desde el directorio raíz al directorio /login, por lo que si tienes algo monitorizando esa ruta, disparará la alarma de inmediato. location /admin { allow 10.0.0.0/24; # Tu red de WireGuard deny all; # Bloquea al resto del mundo include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; # Ajusta a tu versión de PHP } Recuerda cambiar la ruta que quieres bloquear. en el caso de NextCloud, la ruta es /login Apenas aplicas los cambios con systemctl restart nginx ya notaras el cambio al acceder al login desde Internet. Login de Nextcloud antes de aplicar la regla de Nginx Login de Nextcloud luego de aplicar la regla de Nginx Por supuesto, esto nos deja pateados afuera. Pero puedes acceder a Nextcloud mediante la VPN normalmente. Aunque faltan hacer algunos ajustes todavía.

Un DNS personal

Si dejamos esto hasta aquí, nos encontraremos con que Nextcloud desconfía de nosotros. Nextcloud, error de acceso por dominio sin confianza Esto es normal y bastaría con agregar la ip de tu servidor como dominio de confianza, pero queremos tener más servicios con la autenticación escondida. Y eso que no estamos contando que los servicios que dependen de SSL pueden dar conflictos al acceder solo por IP. lo primero es instalar dnsmasq sudo apt install dnsmasqDnsmasq es un software ligero y de código abierto diseñado para redes pequeñas, que actúa como servidor DNS (sistema de nombres de dominio) caché y servidor DHCP (protocolo de configuración dinámica de host). Proporciona servicios esenciales como la resolución de nombres locales y la asignación de IPs, siendo muy común en routers domésticos y entornos Linux. Aunque puedes instalar esta herramienta en cualquiera de tus equipos de la red WireGuard, es recomendable instalarlo en la que hace de servidor. Lo que vamos a hacer, es crear un servidor DNS intermediario, que reemplace las direcciones de tu dominio para que apunte a las redes locales de forma prioritaria. De esta manera, tu configuración de red normal va a seguir apuntando al Internet de siempre, pero con esta configuración, al encender wireguard, las consultas DNS se harán mediante dnsmasq, permitiendo poder acceder normalmente con la dirección de dominio anterior sin cambiar nada mas. En la configuración de los clientes de wireguard debes poner ya la IP de tu servidor. Esto lo hace opcional pues cada cliente puede configurar sus cosas a gusto, asi que no estas forzando a nadie que no quiera. Ahora, vamos a /etc/dnsmasq.conf interface=wg0 # Escucha solo en la interfaz de la VPN listen-address=127.0.0.1, 10.0.0.1 bind-interfaces # Evita conflictos con otros servicios DNS domain-needed # No reenvía nombres sin punto (seguridad) bogus-priv # No reenvía IPs privadas a internet# DNS públicos para lo que no sea tu red localserver=8.8.8.8 server=1.1.1.1 # No busques en el archivo de hosts de internet no-hosts # Pero SÍ usa este archivo que crearemos para tus dominios locales addn-hosts=/etc/hosts.wireguard Recuerda revisar tu archivo dnsmasq.conf por si estas lineas no están comentadas ya. Dado que es una instalación nueva, basta con agregar todo esto al final del archivo pues todo esta comentado. Ahora tenemos que crear el archivo /etc/host.wireguard para agregar los dominios e ip que necesitamos 10.0.0.1 ://tu-dominio.com y ya con esto, basta con reiniciar el servicio dnsmasq systemctl restart dnsmasq A partir de este momento, cuando ingreses a tu dominio con wireguard apagado, veras el mismo error 403 como todos. pero cuando lo hagas con wireguard encendido, veras tu instancia de Nextcloud completamente funcional.

Últimos Pasos

He estado describiendo estos pasos asumiendo que ya te has encargado de los problemas relacionados con SSL. Después de todo, si tienes un sitio web, seguro sale por https. Sin embargo, aunque la redireccion permite aprovechar las mismas credenciales que los servicios que quieres ocultar, en este caso en particular teniamos el siguiente esquema: Internet → dominio publico/Nginx → WireGuard → servidor privado/Nginx Por lo que tenemos que lidiar con dos servidores Nginx, asi que el paso que buscabamos ahorrarnos, pues nos lo tenemos que cargar. Pero tampoco es para tanto. SI ves las configuraciones de tu sitio publico, encuentras las rutas donde deben estar los certificados y tambien como habilitar https. basta con que copies los archivos en el mismo lugar de tu servidor privado. Entonces ya todo vuelve a quedar funcional y bonito.

Conclusiones

Digamos que esta serie de tutoriales serán un caso de «Sobreingeniería de la pereza«. Me gusta cómo están funcionando las cosas ahora, pero empieza a cansarme teniendo los crawlers ahí tocando la puerta todo el tiempo. Al hacer estos ajustes, puedo seguir como siempre sin tener expuestas las puertas de mis servicios y claro, tengo menos exposición a vulnerabilidades de las que no estén pendientes. Además, tampoco es necesario tener tanta cosa expuesta. Siendo el único que usa los servicios que estoy desplegando, tampoco es que me haga falta que más gente conozca dónde está la cerradura para intentar forzarla. Aún estoy decidiendo cuál es el próximo servicio a ocultar, pero estoy entre WordPress y mi servidor de correo electrónico. Mi blog, aunque tiene códigos y funciones especiales, prácticamente es un sitio estático y en cuanto al correo, solo hace falta tener a postfix ahí escuchando los correos entrantes. Los salientes, ni siquiera necesitan un puerto abierto.

Actualización

Aunque aún no se ha publicado este post, he estado haciendo pruebas y viendo los resultados. Efectivamente el tráfico ha disminuido y a fail2ban solo le queda bloquear a toda IP que haga 404 o 302. El uso del VPS bajo muchísimo, así que se puede aprovechar el potencial extra en otras tareas. Pero ya sé cuál será el próximo servicio que oculte mediante este método.     https://interlan.ec/blog/2026/04/17/tutorial-desplegando-dns-privado-para-red-wireguard/ #experimentos #nextcloud #nginx #seguridadInformática #selfhosting #servidores #spam #tutorial #vps
Nginx網頁管理介面元件Nginx UI存在重大漏洞,有資安公司警告已遭積極利用
https://www.ithome.com.tw/news/175108
#nginx #security #infosec
Nginx網頁管理介面元件Nginx UI存在重大漏洞,有資安公司警告已遭積極利用

3月下旬Nginx UI揭露資安漏洞CVE-2026-33032,本週出現最新的進展而受到關注,通報漏洞的Pluto Security指出利用的門檻不高,但帶來的危害相當嚴重;另一家資安公司Recorded Future警告已出現攻擊活動

iThome

RE: https://social.heise.de/@heisec/116418694406990548

Uff. @heiseonline ist auch nur noch zusammengesponnener Unfug. "Kritische Sicherheitslücke in #nginx". Ja, ne. Nicht in nginx. In nginx-ui. Andere Software, anderer Hersteller. Vielleicht sollte der Verlag auf das generieren von fressenden Toiletten oder so umsteigen statt seinen Slop als Nachrichtenseite zu tarnen. :/