← Volver ao blog

Auditamos a seguridade do noso propio servidor e atopamos cousas que non lle perdoariamos a un cliente

Daniel García·

Levabamos meses metendo cabeceiras de seguridade e CSP nas webs dos clientes e nunca fixeramos o mesmo coa nosa. Nótase cando por fin te sentas a miralo: atopamos cousas que a un cliente lle faríamos corrixir na primeira revisión.

A que máis me fixo remexer na cadeira foi o despregamento por SSH. O workflow de GitHub Actions usaba ssh-keyscan contra o IP do VPS cada vez que despregabamos, sen comprobar esa chave contra nada. Iso é aceptar cegamente a pegada do servidor que responda nese momento: se alguén intercepta a conexión cun ataque de intermediario xusto cando se executa o pipeline, tráguao sen rechistar. Arranxámolo metendo a man a chave pública ED25519 real do VPS no workflow e quitando o StrictHostKeyChecking=no que levaba aí desde que montei o despregamento, hai un par de semanas.

Tamén nos faltaban cabeceiras que levamos meses recomendando a outros: X-Frame-Options, Strict-Transport-Security, un Content-Security-Policy de verdade. Engadímolas nun nginx.conf de 65 liñas que agora se copia dentro da imaxe Docker no build. Montar o CSP foi o máis pesado, non porque sexa complicado senón porque hai que ir probando que rompe: Google Fonts precisa a súa propia orixe en style-src e font-src, Google Analytics precisa script-src e connect-src, e o formulario de contacto chama á API de Web3Forms, así que sen metela en connect-src o fetch fallaba en silencio e ninguén se decataba ata que un cliente potencial dicía que escribira e non lle contestaramos. Tivemos que deixar unsafe-inline en script-src polas animacións de scroll e o aviso de cookies, que van inline no layout. Non é a política máis estrita que existe, pero é moitísimo mellor que non ter ningunha.

Fixamos tamén as versións de Node e de nginx no Dockerfile. Antes tirabamos de alpine a secas, que un día che cambia de versión maior sen avisar e o build rómpese sen que teñas tocado nada.

Hai unha cousa que non se arranxa con código e que se me pasara por completo: a chave de acceso de Web3Forms estaba sen restrinxir ao noso dominio. Calquera que a sacase do bundle de JavaScript, que é público, podía usala para mandar formularios desde calquera outra web e queimarnos a cota. Iso só se cambia a man no panel de Web3Forms, e segue na miña lista de tarefas mentres escribo isto.

O que máis me incomoda non é ningún dos fallos en si, senón canto tempo levaban aí sen que ninguén os mirase. Auditamos a infraestrutura dun cliente cando entra un proxecto novo ou cando algo cheira mal. A nosa montámola unha vez, funcionou, e aí quedou. Sospeito que non somos a única axencia pequena á que lle pasa isto coa súa propia casa.

seguridadeservidordeployment