zapimir 17 minutos atrás Como Criamos um Proxy Reverso em Go e Abandonamos a VPN para Acessar Painéis Administrativos Médio 10 min 855 Segurança da Informação * Administração de Servidores * Serviços em Nuvem * DevOps * Tecnologias de Rede * Caso de Uso
Em resumo: Após o deface do site de um conhecido devido ao vazamento da senha do painel administrativo, percebemos que gerenciar acessos de equipes não técnicas (editores, SEO, fornecedores) via VPN ou IPs estáticos era um problema. Os proxies existentes exigiam reinicializações e eram controlados por configurações. No final, criamos nosso próprio forward-proxy em Go, onde o acesso é concedido por token através de uma extensão de navegador, e as regras (TTL, limites de tráfego, domínios acessíveis) são aplicadas em tempo real, sem interrupção das conexões.
Assim o Google Gemini vê nossa solução
Por que abandonamos as soluções clássicas A tarefa parecia trivial: dar acesso seguro aos painéis administrativos a um grupo limitado de pessoas. Mas, na prática, os padrões são quebrados pelos processos reais:
VPN: Excessiva. Redireciona todo o tráfego (olá, torrents e abusos no servidor), difícil de configurar para não técnicos, e a segmentação de acesso (ACL) rapidamente se transforma em caos.
IPs estáticos: Na era do 4G/5G, coworking e trabalho remoto - quase não funcionam. Whitelist no servidor não permite segmentação por usuários e flexibilidade de revogação.
Forward-proxies prontos (por exemplo, 3X-UI ): Configuração via arquivos. Conceder acesso a um fornecedor "por uma hora" - é editar a configuração, implantar e reiniciar. A UI em cima dessas soluções é apenas uma interface, cada alteração requer reload, descartando as sessões atuais. Além disso, muitas vezes configurar um proxy HTTPS com um certificado de uma CA normal - é uma tarefa e tanto.
Pomerium e outros Reverse Proxy / Gateways SSO: Excelentes ferramentas, mas com suas desvantagens fatais para nossa tarefa.
Primeiro, o reverse-proxy altera o domínio do site (ou requer configurações complexas) e termina o TLS, organizando um MITM (Man-in-the-Middle).
Segundo, a integração é difícil. Para permitir que auditores externos ou fornecedores temporários entrem, você precisa primeiro solicitar o e-mail deles, criar contas no IdP, configurar direitos, dar acesso aos recursos necessários e, após a conclusão do trabalho, não se esqueça de excluir.
A lacuna entre "a ferramenta funciona" e "é conveniente de usar" acabou sendo grande. Precisávamos de uma ferramenta para gerenciar acessos , e não infraestrutura, sem integração complexa.
A ideia principal: acesso à configuração, não ao usuário Mudamos a abordagem: o administrador cria uma configuração (domínios permitidos, TTL, limites de tráfego). Um token base58 curto é gerado para ela.
Este token é passado para o usuário. Sem senhas, clientes VPN, coleta de e-mails ou endereços IP. Enviou o token para o auditor no Telegram - através do TTL especificado, o acesso se "transformou em abóbora" sozinho.
A arquitetura consiste em três partes:
Forward-proxy em Go. API de gerenciamento (Control Plane). Extensão para navegador. Um pouco mais abaixo, mostrarei 3 casos de uso não óbvios (por exemplo, como matamos para sempre a necessidade de editar /etc/hosts ao migrar sites), mas para que a mágica seja compreendida, vamos dar uma olhada rápida sob o capô do motor.
A migração do site agora é sem editar /etc/hosts Como funciona sob o capô Nossa ferramenta não é um proxy universal, mas um gateway de internet altamente especializado.
Implantação e autonomia (Zero Config): O próprio gateway é um único binário de 8 MB com zero dependências, que é colocado em um Debian 13 "nu" (x86/ARM). Ele não tem nenhum arquivo de configuração . Ele recebe todas as configurações do Control Plane. Ao mesmo tempo, o gateway pode funcionar de forma autônoma: se não houver comunicação com o CP após a reinicialização do servidor, o proxy será iniciado a partir do estado local e continuará a permitir que os usuários entrem de acordo com as regras (até a expiração do certificado TLS).
Segurança de transporte (TLS): A conexão com o proxy funciona via TLS. Automatizamos esse processo: mesmo para nós auto-hospedados, o sistema emite e renova os certificados (Google Trust Services, Let's Encrypt, ZeroSSL).
Velocidade e TTFB: por que o proxy funciona mais rápido que uma conexão direta: Aparentemente, qualquer gateway é um hop extra que deve retardar o carregamento. Na prática, obtivemos o efeito oposto. Devido ao fato de que o gateway tem seu próprio resolvedor de DNS em cache (que funciona com 1.1.1.1/8.8.8.8), e os próprios nós estão em canais de backbone de data centers, o Time To First Byte (TTFB) através de nosso proxy é frequentemente menor , do que com uma conexão direta através de um provedor doméstico comum com seu DNS lento.
Proteção contra scanners e controle de compartilhamento (TLS SNI): Para roteamento para o proxy, um DNS curinga é usado (por exemplo, *.de.l7ag.run ), e cada usuário recebe um endereço exclusivo do tipo DevID-user-v4.de.l7ag.run através da extensão. Isso dá duas superpotências. Primeiro, pré-autorização rígida no nível TLS SNI: se um bot ou scanner estiver batendo no IP ou sem o SNI correto, a conexão é interrompida instantaneamente e o IP vai para a lista de banidos. Em segundo lugar, é assim que identificamos dispositivos específicos em um token (você pode definir um limite: por exemplo, não mais que 3 pessoas por token).
Modelo de conexão: HTTP CONNECT. O gateway funciona como um túnel: o TLS do site de destino não é terminado, o payload não é analisado (zero-copy). O resultado é zero MITM, baixa carga na CPU e atraso mínimo.
Autorização: Basic Auth, onde o login/senha estão vinculados à configuração , e não a uma pessoa específica. Isso permite que você use um link para deixar uma equipe de fornecedores entrar e, em seguida, com um clique, matar o token para todos.
Armazenamento: Passamos do Redis para o banco de dados embutido BuntDB . No início, tudo é armazenado em cache no mapa na memória. Sem idas ao banco de dados em cada CONNECT - o atraso é mínimo.
Extensão do acesso em tempo real. Em alguns cliques e sem interrupção das conexões.
Killer-feature: Atualização dinâmica sem interrupção das conexões O principal problema dos proxies clássicos: alterou a configuração -> fez reload -> as conexões ativas caíram. Se, nesse momento, o editor estivesse carregando um vídeo grande no painel administrativo, ele o odiaria.
Implementamos a aplicação de regras em tempo de execução. O gateway rastreia túneis ativos:
O acesso é concedido por uma hora. A pessoa está carregando um dump do banco de dados. O tempo está acabando - o administrador na UI pressiona "Estender por 30 minutos". A conexão não é interrompida. O mecanismo do gateway atualiza os parâmetros do túnel ativo em tempo real. E vice-versa: se o limite de tráfego for excedido ou o administrador revogar o token, o gateway mata instantaneamente o túnel ativo, sem esperar que a sessão seja fechada pelo cliente.
Parte do cliente: Extensão e arquivos PAC Em vez de um proxy do sistema, escrevemos uma extensão de navegador que aceita um token e gera um arquivo PAC (Proxy Auto-Configuration) em tempo real.
Sem "caixas pretas": peso 38 KB e aprovação nas lojas Nossa extensão pesa apenas 38 KB (junto com os ícones) - menos que a imagem de visualização deste artigo. Não usamos minimização, ofuscação ou rastreadores analíticos por princípio. Os comentários originais são até deixados no código.
É por causa dessa transparência que a extensão já passou com sucesso pela moderação e está disponível nas lojas oficiais Chrome e Firefox . Não temos nada a esconder: qualquer desenvolvedor pode descompactar o código-fonte e verificar pessoalmente a segurança do plugin em apenas alguns minutos.
Por que isso é conveniente: Facilidade de configuração: Você só precisa inserir um token de 5 caracteres, e o roteamento funciona. Sem configurações com um monte de opções ou encaminhamento de arquivos json com configurações.
"Configurado e esquecido" + teste rápido: Graças ao roteamento seletivo, você não precisa ligar ou desligar constantemente a extensão (como acontece com a VPN) - o navegador sabe quando ir através do gateway e quando ir diretamente. E o botão liga/desliga na extensão permite que você verifique com um clique como o site se comporta através do gateway e como ele se parece "por fora" para visitantes regulares.
Isolamento de tráfego: O painel administrativo da loja vai através do proxy, e o YouTube na guia ao lado - diretamente.
Multirregionalidade: A extensão pode espalhar solicitações por diferentes instâncias de proxy (painel administrativo para a UE - através de um gateway, para os EUA - através de outro).
Exemplo de roteamento seletivo. Um site através da Áustria, outro através da Alemanha, o painel administrativo está disponível através do gateway (sem ele mostra 404), e o YouTube vai diretamente. A demonstração é feita no Vivaldi
3 casos de uso não óbvios que nossa abordagem fechou Além da proteção banal dos painéis administrativos, esse roteamento no nível do navegador resolveu vários outros problemas para nós:
-
Testando ao mudar para um novo servidor (Matador de /etc/hosts ) Quando você move um site para um novo servidor, é necessário que QA, SEO e o cliente verifiquem tudo antes de atualizar o DNS público. Antes, era preciso escrever instruções para pessoas não técnicas: "abra o bloco de notas como administrador, encontre o arquivo hosts...". Agora, simplesmente criamos um token "Novo servidor", onde especificamos uma resolução de domínio personalizada para o novo IP. A pessoa liga a extensão - vê o site no novo servidor. Desliga - vê o antigo (produção).
-
Acesso seguro a localhost e IP privado Você pode facilmente conceder acesso a serviços internos que não estão fisicamente expostos. Por exemplo, você precisa dar ao DevOps acesso à API Caddy, que ouve apenas localhost:2019 em um servidor específico, ou deixar um desenvolvedor entrar no painel administrativo do banco de dados na sub-rede cinza interna. Usando domínios, como caddy.internal .
-
Nomes DNS internos sem registros DNS reais Acesso a ferramentas de infraestrutura para as quais você não deseja revelar registros DNS por princípio. Você pode mapear um grafana.site.com condicional na configuração para localhost:3000 (na máquina onde o gateway está executando). O usuário com o token simplesmente insere grafana.site.com na barra de endereço do navegador (ou clica no link na extensão) e chega aos painéis. De fora, esse domínio e porta não existem.
Interface Uma dor separada de muitas soluções empresariais (o mesmo Pomerium) é a interface. Configurar cada usuário novamente, clicar em dezenas de caixas de seleção para alterar os direitos de um grupo de domínios - isso leva muito tempo.
Portanto, projetamos a UI da conta pessoal com foco na UX da área de trabalho. Precisa selecionar uma dúzia de objetos? Não é necessário clicar em uma dúzia de caixas de seleção - basta selecioná-los com uma moldura, como no Windows Explorer, ou via Shift/Ctrl. As ações necessárias são chamadas pelo menu de contexto usual com o botão direito do mouse. Qualquer objeto pode ser duplicado com um clique para não repetir a rotina. Sem uma interface web sobrecarregada - apenas um SPA (Single-Page Application) rápido em JS vanilla, onde os dados voam via WebSocket.
Seleção por moldura, menus de contexto - UX da área de trabalho
Modelos de isolamento: de Shared a Self-hosted Como estávamos fazendo SaaS, tivemos que colocar imediatamente a arquitetura em diferentes níveis de paranoia e requisitos de infraestrutura:
-
Gateways compartilhados (Gerenciados) Completamente nossa infraestrutura. Ideal para um início rápido e pequenas equipes. Criou um token - e trabalhou imediatamente. A única nuance é que aplicamos a moderação "preguiçosa" de domínios para que nossos IPs não entrem em listas negras devido a amantes de torrents e spam.
-
Gateways dedicados (Gerenciados) Também nossa infraestrutura, mas uma instância dedicada para um cliente. Isso resolve o problema dos "vizinhos" e fornece um endereço IP estático limpo do gateway, que pode ser codificado no whitelist no servidor de destino.
-
Self-hosted (Sua própria infraestrutura) O mais alto nível de controle. Nesse caso, todo o tráfego passa pelo seu servidor, você não tem limites de tráfego e domínios sem moderação, e o pagamento pelo servidor vai diretamente para seu provedor de hospedagem
Tornando o self-hosted mais acessível Simplificamos ao máximo a implantação de gateways self-hosted. Nosso objetivo era que um gerente de projeto ou chefe de agência, que nunca viu o console Linux e SSH, pudesse levantar seu próprio nó.
Tudo é feito a partir da interface: você insere a chave API do seu provedor de nuvem (Hetzner, Vultr, DigitalOcean, Upcloud, Akamai (Linode)), seleciona um local e clica no botão. Nosso back-end criará o servidor, baixará o binário do gateway e, ao mesmo tempo, emitirá um certificado do Google Trust Services (Let's Encrypt ou ZeroSSL). Em menos de 25 segundos, você obtém um proxy seguro e pronto para uso sem uma única linha de código no terminal.
Ou você pode instalá-lo manualmente em absolutamente qualquer servidor Linux (mesmo em um Raspberry Pi no depósito do escritório). A instalação se resume ao one-liner clássico:
curl -fsS
https://l7.run
| sh -s -- -t
Para aqueles que justificadamente consideram curl | sh uma má prática Você pode simplesmente baixar este script e estudá-lo. Não há mágica ou ofuscação. Ele determina a arquitetura, baixa o binário, registra o serviço systemd e joga a configuração em /etc/sysctl.d/ para ajustar a pilha de rede para altas cargas: ativamos o algoritmo BBR, reutilizamos TIME_WAIT sockets, desativamos o início lento após o tempo ocioso e ajustamos os buffers.
Nós nos preocupamos com o conceito de Zero Dependency. Para não depender da presença de unzip ou zstd no servidor durante a instalação, usamos a compressão HTTP zstd ao baixar via curl . Economizamos tráfego, descompactamos o fluxo em tempo real, criamos um usuário com direitos mínimos e registramos o binário no autostart.
Além disso, o gateway assume a rotina: ele mesmo solicita certificados e configurações atuais do Control Plane. E, seguindo as melhores práticas modernas, o binário pode se atualizar com segurança e "suavidade" sem interromper as conexões ativas (graceful update) . Sem sessões interrompidas ou downloads falhados para os usuários! Por padrão, o gateway é pendurado na porta 443, mas você pode alterá-lo em alguns cliques diretamente na interface web. Novamente, sem configurações de texto e confusão no terminal.
A evolução do remendo, ou como chegamos ao SaaS É engraçado, mas este projeto não foi planejado como SaaS. Tudo começou com uma pequena extensão para o Chrome que escrevemos para nós mesmos.
De onde tudo começou Inicialmente, não havia back-end em princípio. Um 3X-UI normal estava rodando sob o capô, e você só precisava copiar a configuração JSON para a extensão. Mas rapidamente ficou claro que enviar arquivos JSON para usuários não técnicos é um problema. A pessoa precisava salvá-lo em algum lugar, então entrar nas configurações da extensão, encontrar onde ela salvou o arquivo... Decidimos simplificar: deixe o usuário inserir apenas um token curto, e a extensão baixará a configuração via API. A ideia funcionou perfeitamente.
Mas então o próprio 3X-UI começou a incomodar. O processo de adição de acesso foi o seguinte: vá para o painel administrativo, crie um usuário manualmente, depois especifique as regras separadamente (quais sites ele pode visitar). Então, não se esqueça de salvar a configuração e a coisa mais irritante - reiniciar o servidor . Durante uma dessas escavações manuais, bloqueei acidentalmente o canal de serviço do próprio 3X-UI. Eu nem pensei que a ferramenta pudesse se bloquear tão facilmente diretamente de sua própria UI e, em seguida, simplesmente travar a cada reinicialização :)
Para não gerar erros, criei uma página web simples: você insere domínios e credenciais, e ela gera um JSON pronto. Mas os dados ainda precisavam ser inseridos em dois lugares. Isso foi extremamente irritante.
Gerador de configuração JSON Então veio o pensamento blasfemo: E se você jogar fora o 3X-UI e escrever seu próprio proxy o mais estúpido e simples possível, que será controlado pela API e aplicará as regras sem reinicializações? Assim começou uma série de experimentos:
Primeira iteração: Pegamos a biblioteca elazarl/goproxy e conectamos o Redis para armazenar o estado. Mais tarde, percebemos que isso era uma superengenharia selvagem: não precisávamos de MITM e análise aprofundada do tráfego, precisávamos apenas transferir bytes do soquete para o soquete o mais rápido possível. Como resultado, cortamos ambas as ferramentas, mudando para um mecanismo zero-copy caseiro e in-memory/BuntDB.
Batalha de protocolos e Wi-Fi público: Tentamos SOCKS5, mas esbarramos nas restrições dos navegadores - eles simplesmente não sabem como transmitir a autorização SOCKS5, além disso, o TLS falhou. Tivemos que voltar para HTTP CONNECT. Ao mesmo tempo, tínhamos um requisito de segurança fundamental: não queríamos que uma pessoa, sentada em um Wi-Fi público, exibisse as credenciais do gateway em aberto. Portanto, tudo precisava ser necessariamente envolvido em TLS.
Problemas do navegador com cache: Um problema extremamente não óbvio surgiu. Se a pessoa mudasse o token na extensão (entrasse com outro usuário), o navegador continuaria a enviar teimosamente os antigos cabeçalhos de autorização ( Proxy-Authorization ). Os navegadores armazenam em cache as credenciais do proxy até a reinicialização completa! A solução foi elegante: começamos a gerar SNIs dinâmicos para cada usuário, para que parecesse um servidor proxy completamente novo para o navegador. O cache foi redefinido, a mágica funcionou.
Resolvendo um pequeno problema após o outro, passo a passo, nos livramos dos remendos de outras pessoas, até que em algum momento olhamos para o resultado e percebemos: "Ops, parece que escrevemos um SaaS completo" P.S. No processo de desenvolvimento, reunimos um bom número de armadilhas e encontramos muitas soluções não óbvias para contorná-las (especialmente em termos de trabalho com navegadores e extensões). Se você estiver interessado na parte técnica do projeto, informe nos comentários e escreverei um segundo artigo com uma análise detalhada das "pedras no caminho"! P.P.S. O serviço ainda está em fase de teste beta fechado. Aqueles que desejam experimentá-lo podem ir para a página de destino temporária L7 Admin Guard e experimentar como as demonstrações ao vivo funcionam, a extensão já está nas lojas.
Somente usuários registrados podem participar da pesquisa. Por favor, entre. Como você concede acesso a painéis administrativos para funcionários e fornecedores não técnicos agora? 0% VPN clássico (WireGuard, OpenVPN, etc.) 0 0% Reverse Proxy / Gateways SSO (Pomerium, Cloudflare Access, IdPs terceirizados) 0 0% Redes Mesh / Zero Trust (Tailscale, Nebula) 0 0% Basic Auth / Senhas compartilhadas (.htpasswd) 0 0% Restrição por IP (Whitelist) 0 0% De forma alguma, os painéis administrativos estão expostos (esperamos senhas complexas e 2FA) 0 0% Nós temos nossa própria bicicleta personalizada (escreverei nos comentários) 0 Ninguém ainda votou. Não há abstenções.
Tags: Zero Trust gerenciamento de acesso vpn proxy tls extensões de navegador zero trust network access
Hubs: Segurança da Informação Administração de Servidores Serviços em Nuvem DevOps Tecnologias de Rede 0 1 0 98 Karma @zapimir Usuário Inscrever-se Fluxo Segurança da Informação disponível 24 horas por dia, 7 dias por semana, graças ao apoio dos amigos do Habr Cursos Habr para todos PUBLICIDADE Prática, Hexlet, SkyPro, cursos do autor - reunimos todos e pedimos descontos. Resta escolher! Ir Ir para o fluxo Segurança da Informação Comentar Melhor do dia Semelhante Mostrar o melhor de todos os tempos
