ここで何が起こっているのでしょうか？私は次のルールを設定しました。
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を介して他のどのインターネット接続も利用できないクライアントとして機能する別のコンピュータを作成します。これにより、コンピュータがパブリックネットワークを介してパケットを送信してユーザーの身元を明らかにするマルウェアに感染しても接続できなくなります。あなたのやり方では、すでに見たように失敗がブロックされるのではなく、クリアネットを通過します。