Por que minha configuração do iptables permite tráfego não TOR?

Question

Que diabos está acontecendo aqui? Eu tenho as seguintes regras definidas:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             127.0.0.0/8         
ACCEPT     all  --  anywhere             anywhere             owner UID match debian-tor
ACCEPT     all  --  anywhere             anywhere             state ESTABLISHED
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

E estes em nat:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere             owner UID match debian-tor
REDIRECT   udp  --  anywhere             anywhere             udp dpt:domain redir ports 53
RETURN     all  --  anywhere             127.0.0.0/9         
REDIRECT   tcp  --  anywhere             anywhere             redir ports 9051
REDIRECT   udp  --  anywhere             anywhere             redir ports 9051

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Como você pode ver, todo o tráfego de saída é bloqueado, exceto para tráfego e tráfego já estabelecidos (?) com o tor. Por que eu ainda tenho conexões Tcp ativas para, por ex. Stack Exchange?

ESTAB      0      0      192.168.1.107:53532                151.101.193.69:https                
ESTAB      0      0      192.168.1.107:56648                151.101.1.69:https                
ESTAB      0      0      192.168.1.107:59170                198.252.206.25:https                
ESTAB      0      0      192.168.1.107:36078                151.101.12.133:https                
ESTAB      0      0      192.168.1.107:45418                172.217.19.238:https                
ESTAB      0      0      192.168.1.107:35364                172.217.21.106:https                
ESTAB      0      0      192.168.1.107:56650                151.101.1.69:https   

whois 198.252.206.25

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#


#
# The following results may also be obtained via:
# https://whois.arin.net/rest/nets;q=198.252.206.25?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#

NetRange:       198.252.206.0 - 198.252.206.255
CIDR:           198.252.206.0/24
NetName:        SE-NET01
NetHandle:      NET-198-252-206-0-1
Parent:         NET198 (NET-198-0-0-0-0)
NetType:        Direct Assignment
OriginAS:       AS25791
Organization:   Stack Exchange, Inc. (SE-111)
RegDate:        2012-10-17
Updated:        2012-10-17
Comment:        http://stackexchange.com
Ref:            https://whois.arin.net/rest/net/NET-198-252-206-0-1


OrgName:        Stack Exchange, Inc.
OrgId:          SE-111
Address:        110 William St.
Address:        Floor 28
City:           New York
StateProv:      NY
PostalCode:     10038
Country:        US
RegDate:        2012-09-14
Updated:        2014-09-16
Ref:            https://whois.arin.net/rest/org/SE-111


OrgAbuseHandle: SYSAD101-ARIN
OrgAbuseName:   Sysadmin Team
OrgAbusePhone:  [phone] 
OrgAbuseEmail:  [email protected]
OrgAbuseRef:    https://whois.arin.net/rest/poc/SYSAD101-ARIN

OrgTechHandle: SYSAD101-ARIN
OrgTechName:   Sysadmin Team
OrgTechPhone:  [phone] 
OrgTechEmail:  [email protected]
OrgTechRef:    https://whois.arin.net/rest/poc/SYSAD101-ARIN


#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#

O que está acontecendo aqui? Tenho a impressão, dia a dia, que o iptables está terrivelmente quebrado.

    

Answer 1

adicione uma regra -J LOG no final de OUTPUT para saber quais pacotes estão seguindo o restante das regras. Também adicionar -v a iptables -L ajuda, pois você pode ver mais detalhes, incluindo o número de pacotes que atingem cada regra.

Por exemplo:

iptables -A OUTPUT -j LOG --log-prefix "firewall:ACCEPT:" --log-level 6

Além disso, eu faria isso se a privacidade fosse uma prioridade alta ... Eu não confiaria em ninguém para escrever regras perfeitas para esse propósito. Em vez disso, eu faria uma máquina separada que é o cliente, que não tem como usar nenhuma conexão com a Internet, exceto através do tor. Dessa forma, mesmo que a sua máquina tenha um malware que envie pacotes pelo clearnet para fornecer sua identidade, ele simplesmente não conseguirá se conectar. Se você fizer do seu jeito, então o fracasso simplesmente vai além do clearnet ao invés de ser bloqueado, como você já viu.