iptables regras no servidor quebra dinâmico ssh port forwarding (proxy SOCKS) na máquina local

Question

Eu uso o debian 9 em um VPS alugado. No meu laptop, uso o encaminhamento dinâmico de portas ssh (usando o protocolo SOCKS) para encapsular o tráfego de alguns aplicativos. Tudo funciona bem, mas quando eu carrego as regras do iptables no servidor (o VPS) qualquer aplicativo no meu laptop que estava usando o encaminhamento de porta local pára de funcionar.

Este é o comando que eu uso para encaminhar a porta local 8080 do meu laptop (debian 8) para o meu VPS:

ssh -D 8080 -N [email protected]

O comando acima começa a retornar erros como os seguintes:

channel 7: open failed: connect failed: Connection timed out
channel 8: open failed: connect failed: Connection timed out
channel 9: open failed: connect failed: Connection timed out
channel 3: open failed: connect failed: Connection timed out
etc...

Aqui está a saída do iptables -L no VPS. Alguém pode ver por que essas regras causariam esse problema? Qualquer ideia muito apreciada.

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  google-public-dns-a.google.com  anywhere            
ACCEPT     all  --  resolver3.opendns.com  anywhere            
ACCEPT     all  --  resolver1.opendns.com  anywhere            
SYN_FLOOD_LOG_DROP  tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN
UDP_FLOOD_LOG_DROP  udp  --  anywhere             anywhere            
ICMP_FLOOD_LOG_DROP  icmp --  anywhere             anywhere            
       tcp  --  anywhere             anywhere             tcp dpt:ssh     state NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
SSH_LOG_DROP  tcp  --  anywhere             anywhere             tcp dpt:ssh state NEW recent: UPDATE seconds: 60 hit_count: 4 name: DEFAULT side: source mask: 255.255.255.255
       tcp  --  anywhere             anywhere             tcp dpt:xmpp-client state NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
XMPP_LOG_DROP  tcp  --  anywhere             anywhere             tcp dpt:xmpp-client state NEW recent: UPDATE seconds: 60 hit_count: 8 name: DEFAULT side: source mask: 255.255.255.255
       tcp  --  anywhere             anywhere             tcp dpt:http state NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
HTTP_LOG_DROP  tcp  --  anywhere             anywhere             tcp dpt:http state NEW recent: UPDATE seconds: 60 hit_count: 8 name: DEFAULT side: source mask: 255.255.255.255
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:xmpp-client
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  localhost            anywhere             tcp dpt:5582

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain HTTP_LOG_DROP (1 references)
target     prot opt source               destination         
LOG        all  --  anywhere             anywhere             LOG level warning prefix "IPTables DROP:HTTPATTACK  "
DROP       all  --  anywhere             anywhere            

Chain ICMP_FLOOD_LOG_DROP (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere             limit: avg 1/sec burst 3
LOG        all  --  anywhere             anywhere             LOG level warning prefix "IPTables DROP:ICMPFLOOD  "
DROP       all  --  anywhere             anywhere            

Chain SSH_LOG_DROP (1 references)
target     prot opt source               destination         
LOG        all  --  anywhere             anywhere             LOG level warning prefix "IPTables DROP:SSHATTACK  "
DROP       all  --  anywhere             anywhere            

Chain SYN_FLOOD_LOG_DROP (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere             limit: avg 1/sec burst 3
LOG        all  --  anywhere             anywhere             LOG level warning prefix "IPTables DROP:SYNFLOOD  "
DROP       all  --  anywhere             anywhere            

Chain UDP_FLOOD_LOG_DROP (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere             state NEW recent: UPDATE seconds: 1 hit_count: 20 name: DEFAULT side: source mask: 255.255.255.255
LOG        all  --  anywhere             anywhere             LOG level warning prefix "IPTables DROP:UDPFLOOD  "
DROP       all  --  anywhere             anywhere            

Chain XMPP_LOG_DROP (1 references)
target     prot opt source               destination         
LOG        all  --  anywhere             anywhere             LOG level warning prefix "IPTables DROP:XMPPATTACK  "
DROP       all  --  anywhere             anywhere           

Obrigado.

    

Answer 1

Eu peguei a sugestão do eckes e tentei registrar o que é DROPPUTO pela política INPUT. Então, adicionei a seguinte regra como última na cadeia INPUT:

iptables -A INPUT -j LOG --log-prefix "IPTables DROP: wrong drop " --log-level 4

Isso mostrou que muitas coisas estavam sendo descartadas, o que provavelmente não deveria acontecer. Um exemplo é esta linha do log:

Dec 12 22:45:13 myservername kernel: [41817.875804] IPTables DROP: drop errado IN = ens18 OUT = MAC = aa: 43: 9d: 07: 06: a7: 00: 1b: 21: ad: d0: 5d: 08: 00 SRC = 149.56.134.238 DST = 30.123.234.6 LEN = 113 TOS = 0x00 PREC = 0x00 TTL = 49 ID = 471 DF PROTO = TCP SPT = 6667 DPT = 47054 WINDOW = 227 RES = 0x00 ACK PSH URGP = 0

Eu estava conectado ao servidor de IRC 149.56.134.238 (cherryh.freenode.net) no momento do teste do meu laptop usando o encaminhamento dinâmico de porta ssh, conforme descrito. Perdi a conexão depois que as regras do iptables foram carregadas no servidor (VPS).

Então, eu tomei o conselho de eckes novamente e tentei aceitar pacotes ESTABLISHED, RELACIONADOS adicionando esta linha como a última regra da cadeia (mas antes da regra de LOG de depuração mencionada acima).

iptables -A INPUT -m conntrack --cstate ESTABLISHED,RELATED -j ACCEPT

Problema resolvido. Eu acho que a lição aprendida é que o primeiro passo com os problemas do iptables é checar o que está realmente sendo descartado!