O problema da exposição de rede na inferência local
A inferência local de IA consiste em executar um modelo treinado em infraestrutura própria, seja num servidor dedicado ou num computador de secretária. Num cenário de inferência distribuída, um servidor central executa o modelo e os clientes remotos enviam pedidos ao respetivo endpoint pela rede. Esta arquitetura concentra no servidor a gestão da capacidade de computação, do armazenamento dos modelos e do acesso à rede para vários clientes.
O risco surge quando precisamos de aceder ao servidor a partir de outros dispositivos da rede local ou através de uma rede privada virtual (VPN), sem o expor à Internet. Esta situação fica entre dois extremos: manter o serviço acessível apenas por localhost e publicá-lo para acesso externo sem controlo. O objetivo é permitir que um portátil na mesma rede utilize o servidor com segurança, adotando uma configuração defensiva por predefinição e verificando os limites de acesso.
Configurar a interface de escuta: bind address
O endereço de bind determina em que interfaces de rede o servidor aceita ligações. Por predefinição, o Ollama escuta em 127.0.0.1:11434. Assim, só os processos executados no próprio computador conseguem aceder-lhe. Esta predefinição é adequada quando não é necessário acesso remoto e deve ser mantida nesse caso.
Para permitir ligações de outros dispositivos, é preciso alterar o endereço de escuta. Definir OLLAMA_HOST=0.0.0.0 ou usar -p 11434:11434 no Docker faz com que o serviço escute em todas as interfaces. Se uma delas estiver acessível publicamente e a firewall não bloquear o tráfego, o serviço poderá ficar exposto à Internet. No caso do Ollama, isto é particularmente arriscado: a API não inclui autenticação integrada. Quem conseguir chegar à porta poderá enviar pedidos ao serviço e consumir os recursos disponíveis. Para uma rede privada, prefira vincular o serviço ao endereço específico da interface local ou da VPN, em vez de usar 0.0.0.0.
Comparação de opções de bind address
Use esta comparação para escolher a interface de escuta adequada ao cenário de acesso.
| Opção | Alcance | Risco | Utilização recomendada |
|---|---|---|---|
| 127.0.0.1 | Apenas localhost | Baixo | Acesso por processos no próprio computador |
| 0.0.0.0 | Todas as interfaces | Muito alto | Evitar, salvo se houver controlos adequados à frente do serviço |
| IP específica, por exemplo, 192.168.1.10 | Apenas essa interface | Moderado | Acesso numa rede local controlada |
| IP do túnel VPN, por exemplo, 10.8.0.1 | Clientes da VPN | Baixo | Acesso remoto por uma rede privada |
Controlos de acesso: autenticação e CORS
A ausência de autenticação nativa é um fator importante a considerar nos servidores de inferência local. O Ollama, por exemplo, não inclui uma chave de API, início de sessão ou limite de pedidos. A variável OLLAMA_ORIGINS limita as origens de navegador autorizadas por CORS; não impede que um programa ou um comando curl de outro computador tente aceder à API. Por isso, é necessário controlar o acesso através da rede ou acrescentar uma camada de autenticação.
O LM Studio permite configurar o serviço para funcionar em modo headless e aceitar ligações pela rede. A porta predefinida indicada no guia consultado é a 1234; confirme a configuração e o estado da escuta no sistema em que o executa. Se o serviço não disponibilizar a autenticação necessária, coloque um proxy inverso, como nginx, Traefik ou Caddy, à sua frente. O proxy pode terminar TLS e exigir uma palavra-passe ou um token antes de encaminhar os pedidos para o serviço local. Mantenha o serviço de inferência vinculado a localhost sempre que possível, e evite deixar exposta uma porta direta em paralelo.
Proteção do perímetro: firewall e filtragem de portas
A firewall do computador anfitrião é uma camada importante para limitar o acesso a portas e endereços autorizados. Em Linux, ferramentas como ufw ou iptables podem ser usadas para restringir as portas do serviço, por exemplo, 11434 para Ollama ou 1234 para LM Studio, a uma rede local ou a endereços da VPN. No Windows, a Firewall do Windows com Segurança Avançada permite criar regras de entrada limitadas a intervalos de endereços IP. No macOS, use os controlos de firewall disponíveis e confirme se as regras aplicadas cobrem efetivamente a aplicação e as interfaces relevantes.
Antes de alterar as regras, confirme a configuração do serviço e o comportamento da firewall. Uma regra permissiva pode anular a proteção pretendida, e as instruções exatas variam consoante o sistema operativo, a distribuição e a forma como o serviço foi instalado. Não abra uma porta para a Internet apenas para resolver um problema de ligação. Se o serviço não precisar de acesso de rede, mantenha-o em localhost e deixe a porta fechada. Se precisar de acesso, restrinja-o a clientes autorizados e verifique o resultado a partir de outra máquina.
Exemplo de restrição com ufw em Linux
Este exemplo ilustra uma regra que permite ligações ao porto 11434 apenas a partir de uma rede local. Confirme a sintaxe e a ordem das regras na sua distribuição antes de as aplicar; uma regra de negação mais abrangente pode interferir com a regra de permissão.
- 01Verifique as regras atuais: sudo ufw status verbose.
- 02Permita o acesso ao porto 11434 a partir do intervalo autorizado, substituindo a sub-rede pelo valor correto: sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp.
- 03Confirme a ordem e o efeito das regras. Não acrescente uma regra geral de negação sem verificar como a sua configuração de ufw resolve regras sobrepostas.
- 04Se necessário, recarregue a configuração conforme a documentação da sua distribuição: sudo ufw reload.
- 05Verifique novamente as regras ativas: sudo ufw status verbose e teste a ligação a partir de um cliente autorizado e de outro não autorizado.
Verificação empírica e cenários avançados
Não presuma que a configuração está segura apenas porque foi definida uma regra de firewall ou um endereço de bind. Verifique a interface em que o serviço está a escutar com ferramentas como ss ou netstat e teste o acesso a partir de dispositivos autorizados e não autorizados. Por exemplo, um cliente da rede local pode tentar uma chamada ao endpoint configurado; uma ligação recusada, por si só, não identifica a causa, pelo que deve ser comparada com o estado do serviço, do firewall e do endereço de escuta.
Para confirmar que o serviço não está acessível pela Internet, faça testes a partir de uma rede externa, como uma ligação móvel, sem desativar as proteções do computador anfitrião. Verifique também as regras do router e de qualquer firewall do fornecedor de alojamento. Um teste feito apenas a partir da mesma rede local não demonstra que o serviço está inacessível externamente. Em ambientes empresariais, registe as decisões sobre o limite de dados, os clientes autorizados e os responsáveis pelo serviço; reveja ainda a gestão de credenciais e os registos de acesso.
Protocolo de teste de acesso
Execute os testes sem expor temporariamente o serviço nem remover controlos de segurança. Registe os resultados e repita-os depois de alterações relevantes à rede, à firewall ou ao servidor.
- 01No servidor, verifique o endereço e a porta de escuta com ss -lntp ou netstat. Confirme que correspondem à configuração pretendida e não estão vinculados a uma interface inesperada.
- 02A partir de um dispositivo autorizado, teste o endpoint pela rede local ou VPN usando o método e as credenciais configurados.
- 03A partir de um dispositivo não autorizado na mesma rede, teste se a ligação é bloqueada. Confirme se o resultado é compatível com as regras de firewall e de autenticação.
- 04A partir de uma rede externa, tente aceder ao endereço público e à porta relevante, sem abrir regras temporárias. Se não houver um endpoint público previsto, a ligação não deve ser possível.
- 05Reveja os registos da firewall e do proxy para confirmar que as tentativas são registadas e que as credenciais não são expostas nos registos.
- 06Se existirem regras no router ou na infraestrutura do fornecedor, verifique-as separadamente. Não considere um teste local como prova de que a porta está inacessível a partir da Internet.
Acesso remoto por VPN e utilização em equipa
Uma VPN permite dar acesso remoto por uma rede privada, sem tornar a porta do servidor de inferência publicamente acessível. Se usar WireGuard ou outra VPN, configure o servidor para escutar no endereço de túnel adequado e permita o acesso apenas aos pares autorizados. A configuração e as regras de encaminhamento variam de acordo com a topologia; teste a conectividade e confirme que o serviço não ficou também vinculado a uma interface pública.
Em organizações com vários utilizadores, a segurança não se resume a fazer o serviço chegar à rede. Defina quais clientes e pessoas podem utilizá-lo, como são emitidas e revogadas as credenciais, e que dados podem atravessar o endpoint. Um proxy inverso pode ser integrado com um sistema de identidade, se a implementação o suportar e estiver configurada para isso. Guarde as credenciais num sistema aprovado, não em ficheiros de código ou configurações acessíveis a utilizadores não autorizados. Proteja o tráfego com TLS e verifique quais funcionalidades de API, autenticação e streaming são compatíveis com os clientes que pretende usar.
Para escolher entre acesso local, VPN e um endpoint partilhado, tenha em conta o número de clientes, os requisitos de disponibilidade e a capacidade do servidor. Um endpoint compatível com uma API conhecida não garante que todas as funcionalidades sejam suportadas: confirme as rotas, o identificador do modelo, o comportamento de streaming e o método de autenticação esperado pelo cliente.
Escolher uma forma de acesso
A opção adequada depende de quem precisa de usar o serviço e de onde se encontram os clientes.
| Cenário | Abordagem a considerar | Verificações principais |
|---|---|---|
| Um programa no mesmo computador | Manter o serviço em localhost | Confirmar que não existe uma publicação adicional da porta pelo Docker ou por outro proxy |
| Vários dispositivos na rede local | Vincular a uma interface privada e limitar o acesso na firewall | Testar a partir de clientes autorizados e não autorizados |
| Acesso remoto | Usar uma VPN e restringir o serviço ao endereço do túnel, se a configuração o permitir | Verificar os pares autorizados e testar também a partir de uma rede externa |
| Acesso partilhado por uma equipa | Usar autenticação e autorização num proxy ou endpoint concebido para esse fim | Confirmar a gestão de credenciais, TLS, registos e funcionalidades compatíveis |
Questões em aberto
- As opções de bind address, autenticação e CORS dependem do produto, da versão e do método de instalação; confirme a documentação aplicável à configuração que está a usar.
- As fontes verificadas não estabelecem um conjunto completo de instruções atuais para configurar firewalls em Linux, macOS e Windows. Adapte as regras ao sistema operativo e teste o resultado antes de disponibilizar o serviço.
- A disponibilidade de autenticação nativa e de integrações com sistemas de identidade varia entre runtimes e proxies; não assuma que uma opção existe sem a verificar.
- Um teste feito a partir da rede local não prova que o serviço esteja inacessível pela Internet. A avaliação deve incluir a configuração do router, do fornecedor de alojamento e das interfaces de rede ativas.
Continue a explorar
Fontes consultadas
Correções e transparência
Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.
Propor uma correção