Debian

查看 VPS 上的 iptables(執行 Tor 非退出中繼)

  • July 27, 2021

誰能幫我檢查一下我的iptables規則(執行一個新的 Tor 中繼伺服器),好嗎?

我正在執行完全更新的 Debian GNU/Linux 11 (bullseye)。

預設情況下,我刪除了 INPUT 鏈中的所有內容,SSH 埠被審查,所以如果你看到XXYYZ……我將其更改為自定義埠,以便機器人有更多的工作,而不僅僅是點擊 22。

我現在將複製粘貼rules.v4文件:

# Latest revision on 2021-Jul-25

*filter

:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

--append INPUT --match conntrack --ctstate NEW --protocol tcp ! --syn --match comment --comment "protection: non-syn packets" --jump DROP
--append INPUT --match conntrack --ctstate INVALID --match comment --comment "protection: malformed packets" --jump DROP
--append INPUT --in-interface lo --match comment --comment "loopback: compulsory" --jump ACCEPT
--append INPUT --protocol icmp --icmp-type echo-request --match limit --limit 2/second --limit-burst 5 --match comment --comment "ICMP: ping only" --jump ACCEPT
--append INPUT --match conntrack --ctstate RELATED,ESTABLISHED --match comment --comment "Tor: traffic" --jump ACCEPT
--append INPUT --match conntrack --ctstate NEW,ESTABLISHED --protocol tcp --match tcp --destination-port XXYYZ --match comment --comment "SSH: global obfuscated" --jump ACCEPT
--append INPUT --protocol tcp --match tcp --destination-port 9001 --match comment --comment "Tor: OR" --jump ACCEPT
--append INPUT --protocol tcp --match tcp --destination-port 9030 --match comment --comment "Tor: Dir" --jump ACCEPT

COMMIT

大約一天正常執行時間的目前輸出為:

# iptables -L INPUT -v --line-numbers

Chain INPUT (policy DROP 29718 packets, 3008K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1      234  131K DROP       tcp  --  any    any     anywhere             anywhere             ctstate NEW tcp flags:!FIN,SYN,RST,ACK/SYN /* protection: non-syn packets */
2      374 45284 DROP       all  --  any    any     anywhere             anywhere             ctstate INVALID /* protection: malformed packets */
3       96  4800 ACCEPT     all  --  lo     any     anywhere             anywhere             /* loopback: compulsory */
4       24   902 ACCEPT     icmp --  any    any     anywhere             anywhere             icmp echo-request limit: avg 2/sec burst 5 /* ICMP: ping only */
5    3736K 2726M ACCEPT     all  --  any    any     anywhere             anywhere             ctstate RELATED,ESTABLISHED /* Tor: traffic */
6       30  1800 ACCEPT     tcp  --  any    any     anywhere             anywhere             ctstate NEW,ESTABLISHED tcp dpt:XXYYZ /* SSH: global obfuscated */
7    12493  743K ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:9001 /* Tor: OR */
8     7948  423K ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:9030 /* Tor: Dir */

伺服器似乎工作起來像一個魅力,但我可能只是過於自信,因為沒有更好的詞。

供你參考:

*filter
-N RNNS
-A RNNS -p tcp ! --syn -j REJECT --reject-with tcp-reset
# accept (new) syn
-A RNNS -j ACCEPT

-N ALLOW
# tcp (r)eset (n)ew but (n)ot (s)yn
# -j RNNS is fine too since the chain has a "fallback" verdict at the end
-A ALLOW -p tcp --dport 9001 -g RNNS
-A ALLOW -p tcp --dport 9030 -g RNNS
-A ALLOW -p tcp --dport 12345 -g RNNS
# for (new) udp, just accept
-A ALLOW -p udp --dport 54321 -j ACCEPT
# others' fate will be determined by the chain policy of INPUT
# because we came to this chain by -g
# but well, -g ALLOW was the last rule anyway, so -j would have worked too
# and you can -j DROP here anyway

-P INPUT DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
# -A INPUT -m conntrack --ctstate INVALID ! -p tcp -j DROP
# could only be of conntrack state NEW; oh well, also see UNTRACKED
-A INPUT -i lo -j ACCEPT
# -A INPUT -i lo -g RNNS
-A INPUT -p icmp --icmp-type echo-request -m limit --limit 2/second --limit-burst 5 -j ACCEPT
# chain policy; optimization / optional
-A INPUT -p icmp -j RETURN
# won't be ICMP
-A INPUT -g ALLOW

-P FORWARD DROP
-P OUTPUT ACCEPT
COMMIT

請注意,同一條鏈中規則的順序可能很重要,但沒有邏輯關係的規則之間的順序肯定不重要(參見鏈ALLOW),儘管作為“優化”,我們優先考慮更“重要的匹配” " / 可能是正確的(參見鏈--ctstate中的前兩條規則)。INPUT

引用自:https://unix.stackexchange.com/questions/660027