- Un WAF eficaç combina models de llista de bloqueig, llista de permesos i regles basades en freqüència per decidir quan registrar, comptar o bloquejar.
- El control fi de falsos positius mitjançant llistes blanques, excepcions i modes de simulació és clau per no afectar el trànsit legítim.
- La segmentació de polítiques per aplicació o servei juntament amb la integració amb SIEM i automatització permet un equilibri realista entre seguretat i operativitat.
- L'evolució cap a plataformes WAAP amplia la protecció a API, millora el context dels registres i facilita decisions de bloqueig més precises.
Trobar l' equilibri entre registrar i bloquejar en un WAF s'ha convertit en un dels maldecaps més habituals per a equips de seguretat i operacions. Un tallafocs d'aplicacions web és capaç de parar atacs molt seriosos, però si es configura de forma massa agressiva pot tombar compres, accessos o trucades API legítimes. Si es configura massa “tou”, acaba sent gairebé decoratiu. La clau és ajustar amb cap quan registrar, quan comptar, quan permetre i quan bloquejar.
En aquest article aprofundirem en com aconseguir aquest equilibri usant les capacitats modernes dels WAF (llistes de permesos, regles basades en freqüència, modes d'aprenentatge, integració amb SIEM, machine learning, etc.), recolzant-nos en exemples concrets d' AWS WAF, ModSecurity, WAF al núvol i solucions on . Veureu com limitar falsos positius sense baixar el nivell de protecció, com organitzar polítiques per aplicacions i com utilitzar el registre com a aliat, i no com un soroll constant impossible de gestionar.
Què és un WAF i per què el registre és tan important
Un firewall d'aplicacions web actua com una capa intel·ligent entre l'usuari i el servidor i analitza el trànsit HTTP/HTTPS en temps real. A diferència d'un tallafoc tradicional de xarxa, que mira ports i IPs, el WAF es fica fins a la cuina: URL, paràmetres, cos de la petició, capçaleres, galetes, mètodes HTTP, etc.
La seva missió és detectar i frenar atacs típics de la capa 7 : injeccions SQL, XSS, LFI/RFI, atacs contra el control d'accés, abús d'APIs, scraping agressiu, força bruta o fins i tot certs patrons de DDoS a nivell d'aplicació. Per això es basa en conjunts de regles, firmes i polítiques de seguretat que s'actualitzen constantment.
El registre (logging) és l'altra banda de la moneda. Cada decisió del WAF —permetre, bloquejar o només comptar— pot anar acompanyada d'un esdeveniment detallat als logs . Aquests registres permeten:
- Investigar incidents: reconstruir què va passar i com es va intentar explotar una vulnerabilitat.
- Ajustar regles: detectar falsos positius veient quines peticions legítimes està aturant el WAF.
- Complir normatives: demostrar que hi ha controls actius (PCI DSS, GDPR, auditories internes, etc.).
- Alimentar un SIEM: correlacionar atacs d'aplicació amb esdeveniments de xarxa, sistema, identitat, etc.
El problema és que un WAF mal afinat pot omplir els logs de milers d'esdeveniments irrellevants , fer impossible trobar allò important i, a sobre, provocar rebutjos injustificats al trànsit legítim. Aquí entra l'art de jugar amb les maneres de registre, comptatge i bloqueig.
Models de seguretat en WAF: llistes de bloqueig, llistes de permesos i enfocament híbrid
La majoria de WAF moderns combinen diversos enfocaments de filtratge, la qual cosa té un impacte directe en com es registren i bloquegen les peticions . A grans trets, podem parlar de dues filosofies clàssiques, més un model mixt molt habitual.
Un WAF basat en llista de bloqueig segueix un model de seguretat negatiu. La seva idea és: “permeto tot tret del que sé que és dolent”. Funciona a partir de signatures d'atacs coneguts (injecció SQL, XSS, patrons de bots, etc.) i regles que defineixen què es considera sospitós. És més fàcil de desplegar al principi, però si només et quedes amb aquest model corres el risc que nous vectors o variants d'atacs es colin sense ser detectats.
Un WAF de llista de permesos va just al revés: “bloquejo tot excepte allò explícitament permès”. Es basa en un model de seguretat positiu. Només s'accepta el trànsit que encaixa en el comportament legítim definit: rutes, mètodes, paràmetres, formats, mides, etc. És molt més segur, però requereix una feina d'afinat molt seriosa i pot generar falsos positius al principi si no es prepara bé.
A causa dels avantatges i inconvenients de cada enfocament, cada cop és més habitual un model híbrid de llista de permesos + llista de bloqueig . En aquest escenari, es defineixen perfils de trànsit esperat (per exemple, què es considera una petició normal de login o de pagament) i, alhora, s'apliquen firmes i heurístiques per caçar patrons maliciosos típics. A efectes de registre, l'híbrid permet:
- Marcar com esdeveniment de risc alt allò que incompleix la llista de permesos.
- Tractar com alertes de prioritat mitjana/baixa els patrons generals de llista de bloqueig.
- Usar el mode “comptar” per veure què trencaria una regla abans d'activar el bloqueig.
WAF en xarxa, en host i al núvol: impacte en registre i bloqueig
El model de desplegament del WAF condiciona molt com es gestiona el logging i el bloqueig de trànsit. No és el mateix registrar peticions en un dispositiu de xarxa que en un agent dins del servidor o en un servei gestionat al núvol.
Un WAF basat en xarxa sol desplegar-se com a appliance físic o virtual a la infraestructura, entre Internet i les aplicacions. És lenfocament clàssic de fabricants com F5. Té l'avantatge d'oferir alt rendiment i control granular , però la configuració i la gestió poden ser complexes. El registre sol enviar-se a syslog oa un SIEM central, i convé filtrar bé què es guarda per no saturar emmagatzematge ni eines danàlisi i per diagnosticar problemes en xarxes IP i DNS.
El WAF basat en host s'executa als propis servidors (o contenidors) on resideix l'aplicació, normalment com a mòdul o agent (per exemple, ModSecurity integrat en un Nginx o Apache; combinar-ho amb hardening Linux amb SELinux millora la postura de seguretat). Aquest model permet tenir més context de laplicació i regles molt específiques per servei, a costa de consumir recursos locals i de requerir una gestió més distribuïda dels logs. Poden desar-se en fitxers locals i després reenviar-se, o integrar-se amb serveis de logging centralitzat.
El WAF al núvol (Cloudflare, Akamai, Imperva Cloud, AWS WAF, etc.) s'integra amb balancejadors, CDN o xarxes virtuals. Aquí el proveïdor sol oferir panells, dashboards i exportació de logs cap a S3, BigQuery, syslog remots o SIEM. Sol ser més senzill d'activar, però has d'adaptar les polítiques de registre al model del proveïdor: tipus d'esdeveniments, retenció, filtres per gravetat, etc.
Escollir un model o un altre no és només decisió tècnica, també de com vols treballar l'equilibri entre registre i bloqueig: un servei gestionat al núvol simplifica molts aspectes, però potser vulguis control absolut sobre on s'emmagatzemen els logs per polítiques de compliment o confidencialitat, cosa que empeny cap a models on premis o híbrids.
Condicions, regles i ACL web: com decideix el WAF si bloquejar, permetre o només registrar
Independentment del fabricant, tots els WAF moderns es basen en la idea de condicions, regles i polítiques daccés . Entendre això és clau per jugar amb els modes de comptatge (count), registre i bloqueig sense embolicar-la en producció.
Les condicions descriuen quina part de la petició s'inspecciona: IP d'origen, capçaleres HTTP concretes (Host, User-Agent, Accept, Content-Type…), paràmetres de consulta, cos de la petició, galetes, mètode HTTP, país d'origen, etc. Per exemple, a AWS WAF Classic podeu definir una condició d'IP fins a 10.000 adreces o rangs, o una condició de coincidència de cadena sobre una porció de la URL.
Les regles combinen una o diverses condicions i assignen una intenció: permetre, bloquejar o comptar. Quan una regla té diverses condicions, normalment s'avaluen amb un AND lògic : totes s'han de complir perquè la regla s'activi. Una regla normal sense condicions, a la pràctica, no coincideix amb res i la seva acció mai no es dispara.
En molts WAF, incloent AWS WAF, existeixen també regles basades en freqüència (rate-based) . Aquestes regles compten les peticions que arriben des d'una IP (o conjunt d'IP que compleixen certes condicions) durant una finestra de temps, per exemple cinc minuts. Si se supera un llindar —diguem 1.000 sol·licituds en cinc minuts— la regla passa a actuar: bloquejar o només comptar. Això és molt útil per a:
- controlar força bruta en formularis de login.
- Limitar scraping agressiu o bots maleducats.
- Mitigar cert tipus datacs DDoS a nivell daplicació.
El següent nivell és la Web ACL (Access Control List) . Aquí s'hi agrupen les regles i es defineix un ordre d'avaluació i una acció per defecte (ALLOW o BLOCK). Una petició va passant per les regles en ordre; si coincideix amb alguna, se n'aplica l'acció i es deixa d'avaluar-ne la resta. Si no coincidiu amb cap, s'aplica l'acció per defecte definida a l'ACL.
A nivell d'equilibri entre registre i bloqueig, l'ACL és el lloc on decideixes si vols que, per defecte, el sistema sigui permissiu (ALLOW i bloquejos només per regles específiques) o molt restrictiu (BLOCK excepte excepcions). A més, moltes solucions permeten marcar regles en mode "comptar" dins de l'ACL, de manera que registren coincidències però no aturen el trànsit, ideal per a la fase d'ajustament.
Llistes de permesos (whitelists) i reducció de soroll als logs
Les llistes de permesos són una eina fonamental per reduir falsos positius i soroll al registre . La idea és senzilla: en determinats contextos, indiques al WAF que no apliqui una directiva o conjunt de regles a cert trànsit concret que ja has catalogat com de confiança o que saps que surt de la norma però és legítim.
Per exemple, a AWS WAF podeu crear regles de llista de permesos perquè, si la petició ve d'una IP o rang concret , o si coincideix amb un patró d'URL i mètode HTTP conegut, no s'apliquin certes inspeccions de signatura. Això ajuda a:
- Evitar que APIs internes que usen patrons “rars” generin falsos positius constants.
- Reduir la latència que introdueix la inspecció profunda en trànsit que ja consideres de confiança.
- Disminuir el volum de registres innecessaris als logs del WAF.
En plataformes com ModSecurity, l'enfocament recomanat no és tocar les regles estàndard (per exemple, OWASP Core Rule Set), sinó crear exclusions específiques per ID de regla per a certs paràmetres, rutes o usuaris. Això permet mantenir la protecció global sense deixar forats enormes per desactivar regles senceres a tot el lloc.
La clau és que les llistes de permesos siguin quirúrgiques , no una destralada. És molt millor excloure una combinació concreta (regla X + paràmetre Y a URL Z) que apagar la regla X a nivell global. D'aquesta manera, el registre continua sent útil i no generes punts cecs innecessaris.
Regles de protocol i límits: quan bloquejar, quan avisar
Molts WAF incorporen un conjunt de regles de sanejament de protocol HTTP que funcionen com a primer filtre de trànsit mal format o sospitós . Aquestes regles revisen capçaleres obligatòries, mètodes, mides d'arguments, etc. i són una font freqüent tant de bona protecció com de falsos positius si no s'entenen bé.
Alguns exemples molt habituals:
- Missing Accept Header (capçalera Accept absent): no és estrictament una violació del RFC, però moltes peticions sense aquesta capçalera procedeixen d'eines automàtiques o scripts poc “educats”. Podeu afectar API o clients personalitzats que no l'envien. En molts entorns es prefereix registrar i comptar abans de bloquejar de manera contundent.
- Missing Host Header: segons els estàndards HTTP/1.1, la capçalera Host és obligatòria. Els WAF la necessiten, a més, per decidir quina política aplicar. Bloquejar aquí sol ser raonable, però pot generar falsos positius en proves o trànsit intern mal configurat; convé monitoritzar els logs abans d'activar bloqueig estricte.
- Missing User-Agent Header: aquesta regla intenta frenar bots rudimentaris i trànsit no identificat. El problema és que moltes APIs legítimes poden no enviar User-Agent. El més assenyat sol ser registrar i, si es detecta una API constant i legítima, afegir el vostre IP o patró a una llista de permesos.
- Validació de GET/HEAD amb cos: encara que el RFC no prohibeix estrictament enviar cos amb GET o HEAD, no és una pràctica habitual i pot indicar intents d'evasió. En molts casos, un primer pas és enregistrar totes aquestes peticions i, si es verifica que són anomalies sospitoses, passar a bloquejar.
- Manca de Content-Type amb cos: si hi ha cos i no hi ha Content-Type, és un indici clar d'ús incorrecte del protocol o d'intent d'evasió d'anàlisi. Aquí acostuma a tenir sentit ser més agressiu amb el bloqueig, sobretot en entorns exposats a Internet.
A més d'aquestes regles de protocol, és freqüent trobar límits d'arguments per protegir davant de desbordaments i atacs de tipus DoS a nivell d'aplicació. Per exemple:
- Número màxim d'arguments per petició (per defecte, 255 en alguns WAF).
- Longitud màxima d'un argument individual (per exemple, 400 caràcters).
- Grandària total combinada de tots els arguments (per exemple, 64.000 bytes).
Aquests valors són raonables per a moltes aplicacions, però hi ha casos —pujades de formularis complexos, filtres avançats, càrregues JSON voluminoses— en què es disparen falsos positius. En aquests escenaris, l'enfocament més prudent és començar registrant i comptant , revisar quins endpoints trenquen els límits i ajustar només per a aquestes rutes, en lloc d'aixecar tots els límits per a tot el lloc.
Falsos positius: com detectar-los i no morir en l'intent
Un fals positiu és una petició legítima que el WAF identifica com a maliciosa i bloqueja o marca com a atac. Són inevitables, especialment quan actives conjunts de regles amplis com OWASP CRS, però es poden gestionar de manera professional perquè no es converteixin en un dolor diari.
La detecció de falsos positius passa, primer, per una observació acurada dels logs . Revisar quines peticions estan sent bloquejades, quina regla les dispara i en quin context passa (URL, paràmetres, usuari, origen, etc.). Eines visuals i dashboards ajuden a veure pics derrors 403 o patrons inusuals.
Un enfocament molt recomanat, tant per proveïdors cloud com per la comunitat de ModSecurity, és utilitzar un mode simulació o count mode . En aquest mode, les regles que voleu provar registren cada coincidència, però no bloquegen. Així podeu veure, per exemple, quantes peticions legítimes hauria tallat una nova regla de SQLi abans d'atrevir-se a activar-la en producció.
També és bona idea provar les regles en un entorn de staging o preproducció que rebi trànsit real o simulat. Eines com OWASP ZAP o scripts de replay de trànsit poden ajudar-te a simular patrons legítims i atacs coneguts per comprovar el comportament del WAF.
A més, és crucial mirar l'impacte operatiu i reputacional dels falsos positius: interrupció de pagaments, errades al registre d'usuaris, anomenades API crítiques que fallen sense explicació… Tot això pot tenir un cost directe en ingressos i en imatge de marca. Un excés de falsos positius també satura l'equip de seguretat amb alertes que no aporten valor i dificulten veure els incidents de debò.
Estratègies d'ajust de regles i ús intel·ligent del registre
La gestió de falsos positius no consisteix a apagar regles fins que “tot funcioni”, sinó a afinar el WAF amb bisturí . Aquí entren en joc bones pràctiques com les següents:
Primer, evitar desactivar regles de manera global. És preferible crear excepcions molt concretes : excloure l'ID de regla només per a una ruta determinada, per a certs paràmetres o per a trànsit intern. D'aquesta manera, segueixes protegit a la resta de l'aplicació i mantens registres útils.
Segon, aprofitar el mode de comptatge abans de bloquejar. Activar noves regles inicialment només en mode registre et permet mesurar quantes peticions legítimes es veurien afectades. Pots acompanyar-lo d'alertes al SIEM per detectar ràpidament si una regla genera un volum anormal de coincidències.
Tercer, integrar el WAF amb un SIEM o plataforma de logging centralitzat . Això facilita correlacionar esdeveniments de WAF amb altres indicadors: activitat inusual en sistemes, errors d'autenticació massius, canvis de configuració sospitosos, etc. També ajuda a prioritzar quines regles ajustar primer segons la gravetat i la freqüència dels esdeveniments.
Quart, documentar cada canvi: quina regla s'ha afinat, per a quin endpoint, sota quina justificació i amb quines evidències. Per això, consultar la guia de manuals de servidors pot ser útil. Aquesta documentació no només ajuda a mantenir el control intern, també és or pur en auditories i revisions de seguretat, on vols demostrar que no es desactiven controls a la lleugera.
Automatització, machine learning i regles adaptatives a WAF
A mesura que les aplicacions creixen i el trànsit es torna més complex, gestionar el WAF només a mà es torna poc realista. Aquí entren en joc l' automatització, l'anàlisi avançada de logs i, en alguns casos, l'ús de machine learning.
En primer lloc, la integració amb SIEM permet construir regles de correlació i respostes automatitzades : per exemple, si un conjunt d'IPs dispara repetidament regles d'injecció o XSS, es pot generar una acció automàtica per afegir aquestes IPs a una llista de bloqueig temporal o reforçar el nivell d'inspecció.
En segon lloc, alguns WAF incorporen modes d'aprenentatge automàtic (learning mode) que observen el trànsit legítim durant un període definit. A partir d'aquestes dades, proposen o ajusten llindars, padrões i perfils de comportament normal. Això ajuda a reduir falsos positius quan es passen regles com a bloqueig, ia detectar desviacions posteriors al trànsit.
En treballs de recerca i entorns de laboratori s'han fet servir tècniques d'aprenentatge supervisat per entrenar models que distingeixin entre trànsit legítim i maliciós, afinant polítiques que després s'utilitzen en producció. Tot i que no és una vareta màgica, aquest enfocament pot ajudar a descobrir patrons subtils que les regles clàssiques basades en firmes no detecten amb facilitat.
Finalment, el testing automatitzat continu (amb eines com OWASP ZAP, scripts personalitzats o pipelins de CI/CD) permet validar que els canvis al WAF no trenquen funcionalitats crítiques ni deixen escletxes obvies. Integrar aquestes proves al cicle de desplegament fa que la seguretat sigui part natural del flux de desenvolupament, en lloc d'un pegat d'última hora.
Disseny de polítiques per aplicació i llistes negres per servei
En entorns complexos —per exemple, un proveïdor de hosting o un ISP— no n'hi ha prou amb una política WAF “única” per a tot, especialment quan hi ha TI a l'ombra . És freqüent tenir múltiples dominis o aplicacions darrere d'un mateix balancejador, cadascuna amb necessitats de seguretat i perfils de trànsit diferents . Aquí és on cobra sentit dissenyar polítiques i llistes específiques per servei.
Un cas il·lustratiu és el d'un balancejador HTTP/S que actua com a servidor intermediari invers per a diversos llocs (per exemple, www.empresa1.com i www.empresa2.com) darrere d'una sola IP virtual. En aquest escenari, és possible configurar el WAF perquè, només arribar la petició, s'avaluï la capçalera Host i la IP d'origen abans fins i tot d'entrar al mòdul de balanceig.
La lògica seria una cosa així: el WAF comprova si la combinació de SERVER_NAME (Host) i IP de client coincideix amb una llista negra específica del lloc. Si la IP figura com a prohibida per a www.empresa2.com però no per a www.empresa1.com, es respon amb un 403 Forbidden només en el primer cas. El trànsit “net” passa al mòdul de balanceig, que decideix quin backend serveix la petició.
Això permet mantenir, per exemple, llistes negres per domini , en comptes d'una llista global per a tot el punt d'accés. A nivell de registre, cada rebuig s'anota a syslog amb detalls com l'ID de regla, la condició que ha coincidit, la URL, el host i la IP del client, facilitant l'anàlisi posterior i l'ampliació o depuració d'aquestes llistes.
La moralitat és que, com més segmentades estiguin les teves polítiques (per aplicació, per entorn, per tipus d'usuari), més fi pots filar l'equilibri entre registre i bloqueig: pots ser molt estricte a portals administratius i una mica més flexible a webs informatius, per exemple, sempre amb evidència en els logs de per què s'ha pres cada decisió.
Més enllà del WAF clàssic: WAAP i protecció d'APIs
El panorama d?amenaces no s?ha quedat quiet. Avui dia, moltes aplicacions són natives del núvol, usen arquitectures de microserveis i exposen APIs públiques i privades que es converteixen en l'objectiu principal dels atacants. El WAF tradicional ha anat evolucionant cap a plataformes més àmplies conegudes com a WAAP (Web Application and API Protection) o WAAS (Web Application & API Security).
Aquestes solucions no només descobreixen automàticament aplicacions web, també identifiquen endpoints d'API , accepten especificacions com OpenAPI o Swagger i usen aquesta definició per comprovar la conformitat de les peticions: tipus de dades esperades, paràmetres permesos, límits de mida, etc. Segons l'endpoint (per exemple, un que maneja dades molt sensibles), es pot aplicar un nivell d'escrutini i de bloqueig molt més alt.
A nivell de registre, WAAP tendeix a generar esdeveniments més rics en context : quin endpoint exacte de l'API s'ha atacat, quina operació (GET, POST, PUT…), quin usuari o token hi estava implicat, quina part de l'especificació s'ha violat, etc. Això permet ajustar millor les decisions de bloqueig, en comptes de basar-se només en patrons genèrics de payload.
A més, moltes eines WAAP inclouen protecció DoS específica per a aplicacions i APIs, filtratge per geolocalització, reputació d'IPs, detecció de bots i scraping, i opcions de personalitzar nivells d'alerta per servei. De nou, es tracta de tenir la flexibilitat de decidir on vols mà dura i on prioritzar fluïdesa , sense renunciar a una bona base de registres per investigar qualsevol incident.
En conjunt, un WAF ben ajustat -ja sigui clàssic, basat en WAAP o integrat en un ecosistema al núvol- es converteix en un component essencial de la defensa moderna d'aplicacions i APIs, capaç de combinar registre detallat, bloqueig intel·ligent i adaptació contínua al canviant panorama d'amenaces.
