====== Proxy invers i WAF ======

<WRAP info>
Un **proxy invers** o **//reverse proxy//** és un servidor de //frontend// (el primer que veiem quan realitzem una petició d'una URL) que enlloc de respodre a la petició desviarà aquesta cap a un altre servidor de //backend// que conté l'aplicació web real.
</WRAP>

Aquest article segueix a [[WAF]] o Web Application Firewall.

{{tag> #FpInfor #Ciber #Ceti #CiberMp03 #CetiMp03 #Asix #AsixMp17 web server mod_security waf firewall }}


El cas més habitual és disposar de diversos servidors on allotgem un domini diferent a cadascun d'ells, però pels que tenim un sol punt d'entrada. Si només disposem d'una IP ens veiem obligats a posar un proxy invers que reenvii les peticions al servidor del domini requerit.

{{ reverse_proxy_flow.png?500 }}

Aquest, però, no és l'únic motiu per a tenir proxy invers. Aquests son alguns dels beneficis que proporciona:
  - **Balanceig de càrrega**: podem repartir un mateix domini en diverses instàncies de la nostra aplicació, per exemple, en màquines físiques diferents, el que ens facilitaria una **escalabilitat horitzontal** (augment de capacitat de processament) basada en l'arquitectura. Aquest plantejament té un sostre molt més alt que les solucions basades en **escalabilitat vertical** que es tradueixen en millorar les prestacions de la màquina principal (RAM, CPUs i //threads// de processament de l'aplicació web).
  - **Bloqueig d'identitat**: els servidors d'aplicacions son l'autèntic objectiu de possibles atacants. Posant un servidor de //frontend// s'amaga la IP del servidor real, i s'evita l'exposició d'altres serveis que pot tenir la màquina server de producció, com per exemple l'accés remot SSH.
  - **Caché**: a l'igual que un //proxy// normal, és a dir, un //forward proxy//, el proxy invers pot enregistrar arxius estàtics o d'URLs que no necessiten processament, fet que alliberarà la càrrega dels servidors d'aplicacions.
  - **Encriptació HTTPS centralitzada** el què facilita la seva gestió. El trànsit fins el //frontend// o //proxy// invers es faria via HTTPS, i d'aquest als servidors d'aplicacions es faria per HTTP en una xarxa interna, pel què facilitaria el manteniment dels certificats (una part crítica del sistema) en un sol punt.
  - **WAF o //Web Application Firewall//** (veure :figure:Imatge323:) és un programari que escaneja les peticions i pot detectar i bloquejar les peticions malicioses (com cadenes amb intents de //SQL injection//, requests enverinades o amb errors introduïts per generar més temps de còmput de les CPUs i saturar-los en un atac de denegació de servei o DoS, etc.). El servidor de //frontend// és el millor lloc on col·locar aquest programari.

{{ waf.png?400 }}

<WRAP info>
Els proveidors de //cloud// solen tenir els seus propis serveis de WAF adaptats a la seva arquitectura i serveis.
</WRAP>

El **[[https://github.com/owasp-modsecurity/ModSecurity|programari de codi lliure ModSecurity]] és el WAF més conegut** i emprat. El gener de 2024, l'empresa Trustwave va trasnferir el seu manteniment a OWASP, organització sense ànim de lucre que ja portava anys configurant el **//Core Rule Set//** o **CRS de ModSecuriy**. Aquest conjunt de regles s'elaboren per la pròpia OWASP mercès als informes de vulnerabilitats com OWASP Top Ten. ModSecurity s'inclou com a mòdul addicional d'aplicacions com Apache Web Server o Nginx, i en distribucions GNU/Linux orientades a //web hosting// com Plesk o cPanel, facilitant la seva instal·lació i configuració.

Un interessant producte son els **serveis de protecció mitjançant proxy invers que ofereixen companyies com Cloudflare o Akamai**. Si transferim el control dels //nameservers// del servei DNS al seu entorn, els seus servidors faran de //frontend//, realitzant la funció de WAF i també ocultant la IP del nostre servidor, juntament amb un ventall d'opcions de gestió dels certificats SSL. Disposen d'algunes capes de servei gratuites, facilitant l'aproximació al servei. Cal tenir en compte, però, que el trànsit que circula pels seus servidors serà visible per a aquestes companyies, així com les peticions de DNS que es facin al domini. Aquests serveis gratuïts, doncs, es paguen (com tants d'altres) amb la recopilació de dades dels usuaris que, encara que sigui de forma legal (acceptant uns termes d'ús), cal no oblidar que ens resta sobirania tecnològica.

La **sobirania tecnològica** es pot definir com la **capacitat de prendre decisions segons els propis interessos** sense estar a mercè dels d'altri. Si una organització (empresa, estat, corporació, institució, etc.) coneix els //internals// de les tecnologies i disposa del //know-how// per a implementar solucions tecnològiques, podrà triar allò que li convé per als seus objectius. Si no té aquest coneixement, haurà de conformar-se amb el què li ofereixin entitats externes. En l'exemple comentat, si una empresa intermediària (sigui el WAF, el proveïdor de correu electrònic, etc.) pot llegir les nostres dades, serà capaç de crear perfils d'utilitzacions que poden fer-se servir per millorar el servei (és el que sempre al·legaran). Però també és coneguda la utilització de les dades (com en les xarxes socials en el paradigmàtic cas de Cambridge Analytica) per a manipular la opinió pública en favor, per exemple, de campanyes polítiques, el preu de les quals queda només a l'abast d'una gran inversió dels ens amb més poder econòmic, vulnerant la qualitat democràtica.


\\