Proxy IP próprio: inicialização SSH e reforço de segurança

Ao comprar um servidor em nuvem para usar como proxy, o problema raramente está na conectividade básica. Na maior parte das vezes, a dificuldade é a ordem de preparação do lado do servidor. Com a sequência correta, o cliente costuma conectar de primeira; com a sequência errada, você acaba voltando várias vezes ao terminal para ajustar a configuração.

Aqui o foco é somente o lado do servidor: do primeiro login e do fechamento do acesso até o serviço de proxy em execução, a liberação de portas, a conexão do cliente e o diagnóstico por camadas quando algo não conecta.

No primeiro login, confirme o acesso antes de tudo

Depois de criar a instância, entre primeiro pelo terminal web fornecido no console do provedor, sem depender logo de início de uma ferramenta local. Nesta etapa, o objetivo é apenas confirmar que a máquina está ativa e que a rede está acessível.

Depois de entrar, mude para root executando sudo -i e pressionando Enter. Quando o prompt mudar de $ para #, a elevação de privilégio foi concluída. Faça as etapas seguintes com essa identidade.

Anote quatro informações: IP público, usuário de login (root por padrão no Linux), senha e porta SSH (22 por padrão). São exatamente esses quatro dados que o cliente precisa; se faltar um deles, a conexão falha.

Troque a porta padrão e depois use login por chave

A porta 22 é escaneada incontáveis vezes todos os dias, e tentativas automatizadas de credenciais são comuns. Trocar a porta não torna o servidor intrinsecamente mais forte, mas elimina boa parte do ruído automatizado.

A alteração é feita em /etc/ssh/sshd_config. Abra o arquivo com vi, pressione i para entrar no modo de edição, altere as linhas PermitRootLogin e PasswordAuthentication para yes e, depois de pressionar Esc, digite :wq para salvar e sair. Se o provedor oferecer login por chave, uma abordagem mais sólida é adicionar sua chave pública local ao authorized_keys do servidor e depois mudar PasswordAuthentication para no, aceitando apenas chaves.

Não encerre a sessão atual imediatamente após alterar a configuração. Abra primeiro outra janela de terminal, entre uma vez usando a nova porta e o novo método, confirme que funciona e só então feche a janela antiga. Caso contrário, um erro de configuração pode deixá-lo do lado de fora, obrigando a recuperação pelo console do provedor.

A porta SSH é definida na linha Port. Após a mudança, reinicie o serviço SSH para aplicar a configuração. Em sistemas Debian e Ubuntu, você pode executar /etc/init.d/ssh restart.

Faça o reforço básico já no primeiro dia

Além da troca de porta e do uso de chaves, vale concluir duas pequenas tarefas no primeiro dia. Primeiro, defina para root uma senha aleatória e suficientemente longa com passwd root, evitando combinações previsíveis. Segundo, desative serviços e portas que não são usados. Quanto menos coisas estiverem expostas, menor será a superfície de ataque; o firewall do sistema deve liberar apenas as portas realmente necessárias.

Se o servidor será usado por muito tempo a partir de alguns poucos pontos fixos, limite no grupo de segurança os endereços de origem a esses locais. Isso é muito mais seguro do que deixar o acesso aberto para toda a internet.

Instale o serviço de proxy e configure a autenticação

Com a inicialização do servidor concluída, passe para o proxy em si.

Uma opção é usar diretamente um túnel SSH. Nada extra precisa ser instalado no servidor; o cliente usa o serviço SSH já existente no sistema para fazer o encaminhamento, com as mesmas credenciais do servidor. É prático, mas o desempenho é mediano e muita concorrência pesa, então funciona melhor para uso temporário ou poucos perfis.

A outra opção é instalar um serviço de proxy dedicado. Normalmente, um único comando de instalação resolve, e depois você configura o método de autenticação e a porta de escuta. Ative a inicialização automática; caso contrário, uma reinicialização do servidor derruba o proxy.

Há três níveis comuns de autenticação, em ordem crescente de segurança: usuário e senha são mais simples, mas um vazamento praticamente entrega o proxy; senha mais lista de permissões por IP de origem costuma ser suficiente para o uso diário; autenticação por chave ou certificado é a mais robusta, embora exija mais configuração e valha o esforço para contas de uso contínuo.

Libere a porta em dois lugares separados

Este é um dos pontos em que mais surgem problemas. A porta de escuta do serviço de proxy precisa ser liberada tanto no firewall do sistema quanto no grupo de segurança do provedor. Os dois controles são independentes, e liberar apenas um deles não basta.

Outro ajuste fácil de esquecer é o endereço de escuta do serviço. Alguns serviços, por padrão, vinculam somente a 127.0.0.1. Se o teste local no servidor funciona mas a conexão externa não, essa costuma ser a causa. Altere o endereço de escuta para o endereço privado do servidor ou para 0.0.0.0.

Conecte pelo cliente local

Crie um novo ambiente na ferramenta de gerenciamento e selecione o tipo de proxy realmente usado. Se estiver usando túnel SSH, o endereço é o IP público do servidor, a porta é a porta SSH e o usuário e a senha são as credenciais do servidor. Depois, execute o teste de conexão.

Um teste bem-sucedido só comprova que o caminho está funcionando. Abra o ambiente e confirme mais três pontos: o IP de saída deve ser o IP público do servidor; o DNS também deve passar pelo proxy, pois uma resolução local pode revelar uma região incompatível com o IP de saída; e o fuso horário e o idioma devem corresponder à região de saída. O ambiente só está pronto quando os três itens forem validados.

Quando o número de contas crescer, mantenha fixa a relação entre cada ambiente e sua saída para evitar que várias contas compartilhem o mesmo ambiente. Ferramentas como PurpleMark podem vincular uma saída separada a cada conta, o que é mais confiável do que manter manualmente uma tabela de correspondência.

Se não conectar, verifique de fora para dentro

Comece pela camada mais externa: o grupo de segurança está liberado? O firewall do sistema está liberado? Confirme os dois antes de avançar.

Depois, verifique o próprio serviço: o processo ainda está em execução, principalmente depois de reiniciar o servidor? O endereço de escuta está vinculado apenas ao host local?

Em seguida, verifique a autenticação: usuário ou senha estão errados? As permissões do arquivo de chave estão amplas demais? O SSHD rejeita diretamente a chave quando as permissões estão incorretas. Só então verifique o cliente: foi informado o IP público ou, por engano, o IP privado? Essa troca é bastante comum.

Seguindo essa ordem, normalmente duas ou três rodadas são suficientes para encontrar a camada com problema, em vez de reinstalar o serviço várias vezes.

Encerramento

Preparar o lado do servidor leva menos de meia hora, mas define quanto trabalho a máquina dará nos meses seguintes. Restrinja o acesso, libere as portas corretas e configure bem a autenticação; depois disso, sobra apenas a manutenção rotineira.