Lea o seu rexistro VPN antes de envialo: campo por campo

Abre un ticket de asistencia, achega a exportación de diagnóstico que produciu o cliente e espera. O ficheiro probablemente non contén ningún historial de navegación, e iso é o que o fai parecer seguro. Aínda así contén quen é vostede, que máquina usou, que enderezos internos alcanzou e cando, e de cando en vez unha clave privada copiada por un cliente que rexistra a súa configuración. Percorrer o ficheiro antes de envialo leva uns cinco minutos e evita unha divulgación permanente.

Ábrao e lea as primeiras corenta liñas

Empece por arriba, onde os clientes adoitan verter versión, plataforma e configuración. As primeiras liñas dinlle canto detalle ten o ficheiro, o que determina canto do resto debe importarlle. Un rexistro predeterminado e un rexistro de depuración son artefactos distintos con exposición distinta.

head -n 40 vpn-support.log
sed -n '1,40p' vpn-support.log | grep -nE 'version|platform|config|option'

Comprobe tamén o tamaño e a forma do ficheiro antes de ler nada del. Un ficheiro de texto de dous megabytes cun acontecemento repetido é fácil de recortar. Unha captura binaria no mesmo cartafol é un problema completamente distinto e require outra conversa con quen pediu a exportación.

En Windows os equivalentes son un cmdlet cada un, e paga a pena executar o primeiro sobre calquera ficheiro que non crease vostede mesmo:

Get-Content .\vpn-support.txt -TotalCount 40
Get-Item .\vpn-support.txt | Select-Object Length,LastWriteTime

Os campos que identifican unha persoa

Os nomes de usuario aparecen en lugares que a xente non espera: a conta usada para autenticarse, o asunto do certificado, a ruta do perfil baixo un directorio de inicio e o nome da máquina que a miúdo codifica un nome real. Un rexistro que redacta o campo da conta e deixa intacta a ruta de inicio non redactou nada.

A consistencia importa máis que a exhaustividade cando un enxeñeiro de asistencia ten que seguir unha sesión polo ficheiro. Substitúa os valores por etiquetas estables en lugar de eliminalos, para que cada aparición do mesmo usuario siga lendo como o mesmo usuario. Eliminar o campo por completo rompe o fío que o enxeñeiro necesita e non fai o ficheiro máis seguro.

Unha marca de tempo tamén é dato persoal no conxunto. As horas en que se conectou unha conta, tomadas ao longo dun mes, describen horarios laborais e viaxes. Se a pregunta non necesita todo o rango, recorte o ficheiro á xanela arredor do acontecemento.

Os campos que identifican unha rede

Os enderezos de extremo, as rutas internas e as opcións empurradas describen a forma dunha rede privada. Esa é exactamente a información que un atacante querería ter, e adoita estar presente con moito máis detalle do que necesita o ticket.

Busque a familia de enderezos en uso, non só a que esperaba. Un cliente de dobre pila pode rexistrar un extremo IPv6 e un conxunto de rutas IPv6 que ninguén pensou en redactar porque a revisión só buscaba cuádruplos con puntos.

grep -nEo '([0-9]{1,3}\.){3}[0-9]{1,3}' vpn-support.log | sort -u | head -n 40
grep -nEo '([0-9a-fA-F]{0,4}:){2,7}[0-9a-fA-F]{0,4}' vpn-support.log | sort -u | head -n 20

A lista única é o punto. Dille cantos enderezos distintos menciona o ficheiro, que adoitan ser moitos menos do que parece ao desprazarse. Tamén lle dá unha lista de verificación para redactar e unha forma de demostrar que os cubriu todos. Dez enderezos son unha tarefa de cinco minutos, e cen dinnos que a exportación é máis ampla que a pregunta.

Conserve a topoloxía se o enxeñeiro a necesita. Substituír o segundo e o terceiro octeto mantendo as relacións de subrede responde a pregunta sen publicar o rango. O mesmo truco funciona para os prefixos IPv6. O que o enxeñeiro necesita é a forma do fallo, e a forma sobrevive a unha substitución consistente.

Os segredos agóchanse en formas, non en etiquetas

Unha clave privada non necesita a palabra “password” preto. Aparece como un bloque entre liñas marcadoras, como unha cadea base64 longa ou como un volcado de configuración en liña. Os tokens aparecen como parámetros de consulta, e as credenciais aparecen dentro de URL que un cliente rexistrou literalmente.

grep -nE 'BEGIN [A-Z ]*PRIVATE KEY|password|passwd|token|secret|psk|auth-user-pass' vpn-support.log
grep -nE 'https?://[^ ]*:[^ ]*@' vpn-support.log

O segundo patrón é o que a xente esquece. Unha URL da forma esquema, usuario, contrasinal, host é unha credencial completa, e os clientes rexistran tales URL sempre que un proxy ou un fluxo se configura con autenticación en liña.

Nunca envíe o ficheiro orixinal como forma de demostrar que non o editou. Se un operador insiste nunha exportación sen modificar, pregunte para que a necesita, envíea polo seu canle de asistencia verificado e despois borre a súa copia local. Ese pedido é lexítimo; unha pega pública non o é.

Constrúa a copia redactada e envíe o extracto

Traballa sobre unha copia, garda o orixinal nun lugar protexido e redacta cunha orde repetible en lugar de facelo a man. Unha soa pasada polos patróns de enderezos captura a maior parte:

cp vpn-support.log vpn-support.original.log
sed -E 's/([0-9]{1,3}\.){3}[0-9]{1,3}/ADDR/g; s/[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+/USER@DOMAIN/g' \
  vpn-support.original.log > vpn-support.redacted.log
grep -cE 'PRIVATE KEY|password|token' vpn-support.redacted.log

A conta final debería ser cero. Se non o é, a pasada de redacción perdeu unha forma e debería mirar esas liñas antes de enviar nada. Lea tamén o ficheiro redactado unha vez cos seus propios ollos; un script captura patróns, non contexto.

Envíe o extracto máis pequeno que aínda mostre o fallo. Dez liñas arredor do erro adoitan abondar, e son moito máis fáciles de revisar que un ficheiro de dous megabytes. Despois garde a correspondencia entre as súas etiquetas e os valores reais nun lugar que controle, porque a pregunta de seguimento a necesitará.

A documentación de rexistro de OpenVPN describe como os niveis de verbosidade cambian o que se rexistra, o que é un contexto útil para decidir canto do ficheiro require realmente o problema.