Fail2ban nunha pasarela VPN: que arranxa e que non
Fail2ban prohibe as fontes que fallan nos teus rexistros, e iso é todo. Que axude a unha pasarela VPN depende da superficie de inicio de sesión e de quen comparte un enderezo.
Todo servizo exposto recibe o mesmo consello: pónlle fail2ban. Para unha pasarela VPN ese consello nin é erróneo nin é suficiente, e tratalo como unha casilla de endurecemento é xusto como a xente acaba cunha cadea (jail) que non bloquea nada útil. Fail2ban le os rexistros de fallos aos que o dirixas e pide a un backend de aplicación que prohiba as fontes coincidentes. Todo o seu valor depende de que superficie de autenticación produciu o rexistro, de se o enderezo que contén é o cliente real e de que ocorre con todos os demais detrás dese enderezo.
Que é fail2ban, mecanicamente
Un filtro fai coincidir liñas dun rexistro, unha cadea conta coincidencias por fonte e unha acción aplica unha prohibición mediante un backend de cortalumes. Tres pezas móbiles, e cada unha pode estar equivocada de forma independente.
Ningunha das tres toca a ruta de autenticación: fail2ban reacciona á evidencia despois do feito e nunca valida por si mesmo unha credencial. Por iso unha cadea pode funcionar limpiamente mentres a superficie que nomea segue exactamente igual de exposta que antes.
O oínte do túnel non é un formulario de inicio de sesión
Un oínte OpenVPN protexido con tls-auth ou tls-crypt descarta os paquetes sen a protección da canle de control antes de que comece o procesamento normal de TLS. Un escáner que nunca ten a chave non xera nada que o teu filtro poida contar. A autenticación por certificado engade outra porta, porque non hai contrasinal que adiviñar. O proxecto Fail2ban documenta un modelo xeral baseado en rexistros, e un filtro VPN xenérico non converte un paquete non autenticado nun evento de fallo significativo.
Se a pasarela só acepta certificados, pode que a historia de forza bruta contra a que te defendes non exista nese porto.
Entón, que superficie protexes?
O mesmo host adoita expor tres cousas distintas: o oínte do túnel, un portal de perfís de cliente ou de autoservizo e unha páxina de administración. O portal e a páxina de administración teñen formularios de contrasinal e producen liñas de rexistro que un filtro pode contar. O túnel pode producir só erros de aperta de mans que significan algo completamente distinto. Fai coincidir a cadea coa superficie, non co nome do produto.
Unha cadea que vixía o rexistro equivocado é peor que ningunha, porque crea confianza sen cobertura. Apunta un filtro de inicio de sesión aos erros de aperta de mans do túnel e o contador dispararase con escáneres que nunca tiveron unha chave, mentres que un ataque de contrasinal contra o portal quedaría sen contar. Le a liña de rexistro que fai coincidir o filtro antes de confiar no número da cadea.
A atribución da fonte é o elo débil
Unha prohibición vale o que vale o enderezo ao que apunta. Cando o servizo está detrás dun proxy inverso local, o enderezo do cliente no rexistro pode ser o do proxy, e prohibilo elimina a todos. Confiar nunha cabeceira reenviada dunha fonte non fiable dálle a un atacante a capacidade de prohibir enderezos arbitrarios. En UDP os enderezos de orixe pódense falsificar, así que contalos merece máis coidado que contar un inicio de sesión TCP completado.
Anota o método de atribución da fonte no README da cadea, porque unha cabeceira reenviada desde un salto non fiable converte unha prohibición nunha arma.
O custo colateral son os demais
Varios empregados detrás dun NAT de oficina comparten un enderezo, así que unha soa contrasinal gardada e obsoleta pode bloquear toda a oficina en canto se cruza o limiar. O rexistro mostra unha fonte e unha conta que fallaron, non unha caída de toda a oficina.
As prohibicións curtas e os limiares moderados reducen iso, e unha ruta documentada para levantar a prohibición reduce a carga de soporte cando ocorre igualmente. O enderezo é un sinal groso en lugar dunha identidade, e quen abra o tícket describirá a caída, non o limiar.
Cando adoptalo e cando arranxar outra cousa
Adóptao cando haxa un fallo de inicio de sesión en liña real, atribuíble e repetido nunha superficie que controles, e cando o backend de aplicación cubra de verdade esa superficie. Arranxa outra cousa cando o problema sexa unha política de credenciais feble, unha páxina de xestión exposta a internet ou unha conta que inicia sesión con éxito porque foi comprometida. Unha prohibición non pode reparar nada diso e non pode absorber o tráfico que xa saturou a túa ligazón ascendente. Ese último problema pertence augas arriba, a alguén que poida filtrar antes de que os paquetes che cheguen.
Mantén cada cadea ligada a unha superficie, revisa os falsos positivos e mide o traballo de autenticación evitado en lugar do número de enderezos prohibidos.