Restringe el acceso a un servidor y pon un WAF delante de tu aplicación
Desde el primer despliegue,
erpc worker permite SSH solo desde tu dirección y descarta todas las demás conexiones entrantes. Una tabla [waf] pone un proxy de filtrado delante de tu API.Esta página describe ERPC CLI
v0.1.0-rc.4, una versión preliminar.El firewall
Un despliegue configura el firewall del servidor antes de que la aplicación arranque por primera vez:
- SSH solo desde
firewall.ssh_allowy desde la dirección de la que procede el despliegue; - todas las demás conexiones entrantes descartadas, excepto
run.portdesdefirewall.app_allow; para una aplicación detrás de un WAF, el puerto del WAF en su lugar, y solo donde el WAF del servidor ya aplica las reglas que[waf]define ahora (más abajo).
Cada cambio se ejecuta con un temporizador de rollback de 120 segundos y solo se conserva una vez que una conexión nueva consigue entrar, así que un cambio erróneo no puede dejarte fuera.
Sin embargo, la lista blanca sobrevive a la dirección desde la que se creó: si cambia la dirección de tu casa, la forma de volver a entrar es el soporte de ERPC para un servidor de ERPC, o la consola del proveedor para un servidor propio. Mantén en
firewall.ssh_allow una segunda dirección desde la que puedas llegar al servidor (una oficina, una salida de VPN) antes de confiar en la de tu casa.Si tu dirección cambia, añade todas las direcciones fijas que usan tus administradores:
bash
Poner un WAF delante de tu aplicación
Añade una tabla a
erpc.toml:toml
Después,
erpc worker deploy ejecuta un proxy inverso HTTP en el servidor, en una unidad systemd propia (erpc-waf-<app>-<env>): un usuario dinámico sin privilegios, sin clave, sin secreto y sin nada del worker, limitado a 1 GiB de memoria. Escucha en waf.port, lee cada solicitud antes que la aplicación, rechaza lo que nombran sus reglas y reenvía el resto a la aplicación en 127.0.0.1:<run.port>.-
La aplicación se queda en el loopback. Su propio puerto nunca se abre desde fuera.
erpc worker apiy la comprobación de salud llegan a la aplicación por el loopback, sin pasar por el WAF. -
Quién puede conectarse sigue siendo la lista del firewall, y el puerto del WAF es el único sitio donde esa lista puede decir «todos»:shSi no hay nadie en la lista, el WAF escucha y no se deja entrar a nadie, y el despliegue lo indica.
-
El puerto se abre una vez que el WAF escucha en él, nunca antes. Un despliegue cuyo WAF no arranca falla y dice por qué, con la aplicación todavía en ejecución.
-
Cuando cambias
[waf], el puerto no se abre a nadie nuevo hasta que un despliegue haya dejado aplicadas las reglas nuevas. -
Quitar
[waf]deerpc.tomly desplegar elimina el WAF del servidor.
Ajustes del WAF
Solo
port es obligatorio. Todas las claves, con su valor predeterminado:toml
rate, max_connections_per_address, ban y new_connections se desactivan con false (ban = false), y una clave omitida toma su valor predeterminado. erpc worker check indica qué hará la tabla [waf], y qué tiene de incorrecto, antes de cualquier despliegue.Lo que el WAF hace sin necesidad de ajustes
- Una solicitud que no se lee como una única solicitud HTTP/1 inequívoca recibe 400, y lo mismo una ruta que no está en forma normal.
- Una solicitud para cambiar de protocolo (
Upgrade) recibe 501. - Cada rechazo cuenta para el veto, y cada rechazo cierra su conexión.
- Una dirección es una dirección IPv4, o un
/64de IPv6. - El WAF no reenvía las cabeceras de la conexión del cliente con el proxy (
Connectiony las cabeceras que nombra,Keep-Alive,Proxy-Authenticate,Proxy-Authorization,Proxy-Connection,TE,Trailer),Expect, las cabeceras cuyo nombre lleva un guion bajo, ni las cabecerasForwarded,X-Real-IPyX-Forwarded-Protoque envía el propio cliente. EstableceX-Real-IPen la dirección de la que vino la conexión y añade esa dirección al final deX-Forwarded-For; solo la última entrada deX-Forwarded-Forprocede del proxy.
Ver lo que hace el WAF
Una solicitud reenviada no deja ninguna línea en el log, y nunca se registra ninguna cabecera ni ningún cuerpo; la consulta de una solicitud bloqueada sí, hasta donde alcanzan los 200 bytes. Lo que envía un cliente no puede escribir en tu terminal: el WAF escribe su journal como ASCII imprimible.
Lo que el WAF no hace
- Sin TLS. Habla HTTP/1.1 sin cifrar en su puerto.
- Sin HTTP/2: le responde con 400.
- Sin WebSocket, ni ningún otro
Upgrade: 501. - No mira dentro de los cuerpos. Un cuerpo se mide, nunca se lee. La lista de sondeos es corta y es un filtro de ruido, no una garantía: la aplicación sigue encargándose de comprobar su entrada.
- Sin autenticación. Quién puede llamar a la aplicación lo decide la aplicación, y la lista del firewall.
- Una dirección es un cliente. Los clientes detrás de un mismo NAT, proxy o CDN comparten una tasa y un veto; un cliente con muchas direcciones tiene tantas tasas como direcciones.
- Los vetos y los recuentos se olvidan cuando el WAF se reinicia.
- Recuerda como máximo 8192 direcciones y mantiene como máximo 1024 conexiones a la vez.
- Solo escucha en IPv4, así que una entrada IPv6 en
app_allowtodavía no llega a nada. - Una ruta se compara como los bytes a los que se decodifica. A una aplicación que lee las rutas de forma más laxa (sin distinguir mayúsculas y minúsculas, con parámetros
;, decodificando dos veces) se puede llegar con un nombre quedeny_pathsno cubre.allow_pathsno tiene ese hueco: lo que no está en la lista no se reenvía. - A un lector lento se le sirve hasta el final. A un cliente que sigue recibiendo una respuesta, por lento que sea, se le sirve hasta el final.
- Una avalancha puede cortar una subida grande. El WAF se ejecuta en un solo hilo, así que una avalancha puede cortar una subida grande con 408. Una aplicación que acepta cuerpos grandes sube
body_timeout_secsjunto conmax_body_bytes.
La guía del worker tiene todas las reglas, incluido cuándo un cambio en
app_allow se retiene hasta el siguiente despliegue.





