
Estou enfrentando um problema em um servidor recém-configurado no Hetzner-Cloud executando o Ubuntu 18.04 LTS.
Depois de instalar o Iptables(-persistent) e configurar o seguinte conjunto de regras:
root@inetsec:/home/linus# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- anywhere 1.2.3.4 tcp dpt:272
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Ainda consigo obter um handshake TCP bem-sucedido usando Telnet, usando várias outras portas (110, 143, 25, 993).
Mesmo assim, os aplicativos responsáveis por essas portas (Dovecot & Postfix) nem estão rodando, e netstat -tulpen
mostra:
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 112 20485 1198/mysqld
tcp 0 0 1.2.3.4:272 0.0.0.0:* LISTEN 0 18773 1047/sshd
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 101 19746 1113/systemd-resolv
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 111 19076 1004/named
udp 0 0 127.0.0.53:53 0.0.0.0:* 101 19745 1113/systemd-resolv
udp 0 0 127.0.0.1:53 0.0.0.0:* 111 19075 1004/named
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 18955 1173/dhclient
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 15042 816/dhclient
, ainda recebo um TCP-Handshake nas portas mencionadas usando telnet, em vez do tempo limite esperado (devido à política INPUT DROP) ou pelo menos uma ICMP-Destination Unreachable (3)
mensagem para as portas fechadas.
Um problema que descobri é que, se eu estiver reinicializando o servidor com o conjunto de regras iptable salvo ( iptables-save > /etc/iptables/rules.v4
), o servidor trava cerca de 5 minutos no estado
....
iscsi: registered transport (tcp)
iscsi: registered transport (user)
antes de ativar o login.
Além disso, leva cerca de 15 segundos para executar o comandoiptables -L