여기서 무슨 일이 일어나고 있는 걸까요? 나는 다음과 같은 규칙을 설정했습니다.
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를 통하는 것 외에는 어떤 인터넷 연결도 사용할 수 없는 클라이언트 역할을 하는 별도의 컴퓨터를 만들겠습니다. 이렇게 하면 컴퓨터가 공개 네트워크를 통해 패킷을 보내 사용자의 신원을 드러내는 악성 코드에 감염되더라도 연결할 수 없습니다. 여러분의 방식대로 하면 이미 본 것처럼 실패가 차단되는 대신 클리어넷을 통과하게 됩니다.