내 iptables 구성이 TOR가 아닌 트래픽을 허용하는 이유는 무엇입니까?

내 iptables 구성이 TOR가 아닌 트래픽을 허용하는 이유는 무엇입니까?

여기서 무슨 일이 일어나고 있는 걸까요? 나는 다음과 같은 규칙을 설정했습니다.

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

그리고 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

보시다시피 Tor 트래픽과 Tor(?)로 이미 설정된 트래픽을 제외한 모든 나가는 트래픽이 차단됩니다. 예를 들어 왜 여전히 활성 Tcp 연결이 있습니까? 스택 교환?

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   

세계보건기구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:  +1-212-232-8280 
OrgAbuseEmail:  [email protected]
OrgAbuseRef:    https://whois.arin.net/rest/poc/SYSAD101-ARIN

OrgTechHandle: SYSAD101-ARIN
OrgTechName:   Sysadmin Team
OrgTechPhone:  +1-212-232-8280 
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
#

여기서 무슨 일이 일어나고 있는 걸까요? 날마다 iptables가 심각하게 손상되었다는 인상을 받습니다.

답변1

OUTPUT 끝에 -J LOG 규칙을 추가하면 어떤 패킷이 나머지 규칙을 따르는지 알 수 있습니다. 또한 iptables -L에 -v를 추가하면 각 규칙에 맞는 패킷 수를 포함하여 자세한 내용을 볼 수 있으므로 도움이 됩니다.

예를 들어:

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

또한, 프라이버시가 최우선이었다면 저는 이렇게 할 것입니다. 저는 누구도 이 목적을 위해 완벽한 규칙을 작성할 것이라고 믿지 않습니다. 대신 Tor를 통하는 것 외에는 어떤 인터넷 연결도 사용할 수 없는 클라이언트 역할을 하는 별도의 컴퓨터를 만들겠습니다. 이렇게 하면 컴퓨터가 공개 네트워크를 통해 패킷을 보내 사용자의 신원을 드러내는 악성 코드에 감염되더라도 연결할 수 없습니다. 여러분의 방식대로 하면 이미 본 것처럼 실패가 차단되는 대신 클리어넷을 통과하게 됩니다.

관련 정보