Sou muito novo em sistemas operacionais * nix, e estou tendo alguns problemas que acredito ser devido a uma configuração incorreta do firewall iptables.
Meu servidor tem SSH em execução na porta 22 e o software do servidor em execução na porta TCP 25565. O SSH e o software do servidor respondem apropriadamente às conexões feitas dentro da rede (ou seja, conexões feitas usando o endereço local do servidor, 10.0.0 .xx). No entanto, se eu tentar acessá-los de fora da rede ou usando o endereço IP externo do roteador, eles não responderão.
O roteador está configurado para encaminhar essas portas para o servidor; Eu duvido muito que haja um erro lá.
Depois de pesquisar o iptables, eu tentei alguns guias, mas não estou vendo nenhum resultado.
A saída do iptables -L é como tal:
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:25565
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:27015
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Uma varredura nmap de dentro da rede informa que as portas 22 e 25565 estão abertas e que as portas 80 e 2705 (outro software de servidor que não estou executando no momento) estão fechadas. A execução do nmap com o IP externo do roteador não retorna resultados úteis; Eu acredito que o roteador está detectando a tentativa de varredura e se recusando a responder.
O servidor está executando o Debian em modo somente texto.
Alguém vê qual é o problema ou tem etapas de solução de problemas para sugerir?
Em resposta aos comentários:
netstat -tpln fornece o seguinte (entre outras coisas); Eu suponho que isso é bom, embora a diferença entre tcp e tcp6 me escape.
tcp6 0 0 :::25565 :::* LISTEN 3092/java
Hosts.deny é desprovido de entradas.
No entanto, o /var/auth.log tem alguns conteúdos interessantes. É normal que as pessoas comecem a tentar usar o bruteforce na minha senha root no minuto em que o SSH é exposto?
Mas, sim, a leitura dos registros parece sugerir que sou a única pessoa que não pode acessar o SSH no meu servidor.
O iptables é um dos piores (melhores?) exemplos de "vamos apenas exportar as tabelas brutas do kernel e deixar que o administrador faça sentido" design.
OFirewall Descomplicado lidará com os casos comuns, como você descreve, e deixará você com a sua sanidade. É apenas um invólucro do iptables, mas que fala na estrutura de tarefas e não nas estruturas do kernel.
But yes, a perusal of the logs seems to suggest that I'm the only person who cannot SSH into my server.
Isso soa um pouco ... você está tentando se conectar ao seu IP público da rede interna ? Isso não é provável que funcione. Você deve testar seu acesso do lado da Internet do roteador, por exemplo de um VPS ou um celular 3G. Apenas um pensamento ...
Tente limpar seus iptables e defina a política padrão como ACCEPT , se você puder conectar, seu problema é com as regras do iptables, caso contrário o roteador estará com bugs.
Sobre as entradas em seu arquivo auth.log, há várias listas de bloqueio para redes de bots conhecidas que provavelmente tentam quebrar sua configuração (ou é só você com seus testes), instale openssh-blacklist-extra para fornecer proteção adicional ( ele deve ser instalado junto com o sshd, mas uma verificação rápida pode ajudar). Além disso, deve ser uma boa ideia fail2ban também.
Use tcpdump -i eth0 -nn para ver o que está acontecendo no fio. Deve haver tentativas de conexão e respostas como esta:
14:20:38.482053 IP 172.31.170.1.42111 > 172.31.170.102.22: Flags [S], seq ...
14:20:38.482095 IP 172.31.170.102.22 > 172.31.170.1.42111: Flags [S.], seq ...
se a resposta a [S] não for [S.] , mas algo como [R] ou um pacote ICMP, então há algo errado.
ip route show - existe uma rota padrão apontando para o roteador? Embora você possa configurar iptables manualmente, é muito mais confiável usar uma ferramenta para criar o firewall de acordo com suas necessidades. Acho que o Shorewall é uma ferramenta bem documentada e fácil de usar. Está disponível como um pacote. Se você precisar de IPv6, há também um pacote Shorewal6. Existem exemplos de configuração para várias configurações que fazem um bom ponto de partida.
O pacote ucf também pode ser usado para criar um conjunto de regras.
Ou configuraremos algumas regras padrão que você pode perder ao usar seu próprio firewall.
Seu conjunto de regras iptables está permitindo acesso à porta TCP 22 onde você tem seu daemon SSH em execução. Se você não pode alcançá-lo da Internet é por causa de 1) o roteador / firewall está bloqueando o acesso ou 2) a porta é incorretamente configurada ou 3) o daemon SSH não está escutando na interface correta ou 4) O SSH está configurado para rejeitar conexões de qualquer alcance. Uma lógica semelhante se aplica ao seu software de servidor.
Observação: sua regra relacionada / estabelecida normalmente fica no topo devido ao desempenho e para melhorar a legibilidade do conjunto de regras. Além disso, você pode querer dividir o conjunto de regras por interface, é muito menos propenso a erros dessa maneira. Você pode querer usar um wrapper de firewall, mas eu os acho tão complicados quanto gerenciar o iptables diretamente.