在本文中，我將在驗證節點的安全性和可用性方面討論兩個主題。我知道，這里介紹的技巧僅僅涵蓋了POS驗證節點的“安全性和可用性”冰山一角。不過，我發現它們對于您的測試實例提供最小的安全性和可用性是有用的。

保護驗證節點

在互聯網上公開區塊鏈或加密服務會吸引攻擊者試圖攻擊您的系統。所以最好準備好采取任何措施來降低被危害的風險。

在運行我的polkadot驗證節點時，我觀察到大量的攻擊者試圖強行使用我的ssh密碼。

我做的第一件事就是安裝SSHGuard。那么什么是SSHGuard？正如Andrew Schartzmeyer在他的博客中所描述的那樣：

sshguard監控服務器的日志記錄活動。當日志顯示有人在攻擊時，sshguard會作出相應防護措施阻止攻擊。

在我們的例子中，我們使用它來保護我們的SSH端口，安裝過程非常簡單，默認情況下，它將開始檢查Ubuntu服務器上的/var/log/auth.log（其中記錄了SSH攻擊等） ）。

在Ubuntu服務器上運行以下命令以安裝SSHGuard，它將使用iptables作為系統防火墻。 iptables是一個用于配置和管理內核netfilter模塊的程序。

apt-get update apt-get install -y sshguard

當sshguard阻止任何惡意用戶（通過阻止其IP地址）時，它將使用sshguard鏈。準備好sshguard鏈并確保在檢測到新的傳入連接時也會觸發鏈，最后重新啟動sshguard。

iptables -N sshguard

ip6tables -N sshguard

iptables -A INPUT -j sshguard

ip6tables -A INPUT -j

sshguard service sshguard restart

在下面的示例中，sshguard在4次登錄嘗試失敗后開始阻止一次嘗試，如果攻擊者繼續攻擊，則會逐漸增加阻止時間。

要查看被阻止的IP地址，請運行以下命令：

iptables -nvL sshguard

通過這個簡單的設置，您可以確保您的明智的sshd端口受到保護，以防愚蠢的攻擊者試圖侵入您的系統。

polkadot驗證節點的進入端口

哪個端口，是polkadot驗證器所需要的。驗證節點需要三個入站端口：

30333用于Peer2Peer協議的端口；

9933用于RPC；

9944用于WebSocket（WS）通信；

理想情況下，驗證節點將只公開這三個端口以及允許您登錄系統的sshd端口。

polkadot驗證節點的出端口

關于保護以及驗證程序的出站端口的一些想法。如security.stackexchange線程中所述

https://security.stackexchange.com/questions/24310/why-block-outgoing-network-traffic-with-a-firewall

進入流量阻塞只能阻止未經請求的流量到達您的內部網絡。但是，如果您在內部計算機上收到惡意軟件（通過運行不受信任的可執行文件或利用漏洞），您仍然會受到攻擊。

通過阻止惡意軟件連接到命令和控制服務器或清除數據，阻止傳出流量有助于限制損壞。

因此，在生產驗證程序節點中，這可能被認為是至關重要的，但要注意：

在高度安全環境中，出站過濾的想法似乎是一個自然的過程。然而，這是一項非常龐大和復雜的事情。

為了說明這一點，我通過分析驗證節點的通信模式運行了一個快速練習。

為此，我使用了優秀的工具Wire Shark。

“Wireshark是世界上最重要、應用最廣泛的網絡協議分析儀。它可以讓您在微觀層面上了解您的網絡上發生了什么，并且是許多商業和非盈利企業、政府機構和教育機構的事實（通常是法律上的）標準。”

為了獲得WireShark的輸入文件，我必須在我的驗證器節點上運行tcpdump命令…

［email protected］：~# tcpdump -w dump.out -i venet0 -c 1000 -vvv

tcpdump： listening on venet0， link-type LINUX_SLL （Linux cooked），

capture size 262144 bytes 1000 packets captured 1125 packets

received by filter 0 packets dropped by kernel

并將其加載到Wire Shark中。 正如下面的截圖所示。 驗證節點使用了大量的出站端口。

預計這將考慮到Validator將使用Peer2Peer通信方案，以便與其他網絡中的45個驗證節點進行通信。

為了保護出站端口，詳細了解底層P2P庫是如何工作的，這超出了本文的范圍（考慮保護測試節點）。

不過，值得一提的是，支付卡行業數據安全標準只是要求提供信用卡的組織（也是某種驗證器）這樣做。

PCI DSS要求1.2.1的重點是組織制定政策和程序，將流量限制為業務目的的入站和出站絕對必要的流量。PCI要求1.2.1規定，“將入站和出站流量限制為持卡人數據環境所必需的流量，并明確拒絕所有其他流量。”PCI要求1.2.1的目標是將流量限制為僅必要的、所需的協議、端口或服務，并為所需的ELE提供商業理由。

那么在生產環境中運行Polkadot Validator節點的最低要求是什么。

那么，讓我們切換到本文的第二個主題。

提高驗證節點的可用性

我正在以7x24方式運行Validator POC-2節點，并試圖將削減（由于我的節點不可用）減少到最小。

盡管如此，該進程不時會收到一個終止信號，導致必須啟動該進程。

為了自動執行此任務并將削減概率降至最低，我編寫了一個小的cron作業腳本，每分鐘執行一次。

要觸發的腳本（monitorValidator.sh）將檢查是否沒有運行polkadot進程

#！/bin/bash

timestamp（）

{

date +“%Y-%m-%d %T”

}

a=$（/bin/netstat -tulpn | awk ‘{print $7}’ | grep polkadot | wc -l ）

if test $a = “0” then

echo “$（timestamp）： Polkadot Validator Down” 》》 /var/log/run.log

/root/.cargo/bin/polkadot --name $POLKADOT_NAME_POC2 --validator

--key $POLKADOT_KEY_POC2 &》》 /var/log/run.log

fi

要安裝crontab，請執行以下命令

（/usr/bin/crontab -l ; echo “ * * * * * bash -l -c

‘/root/monitorValidator.sh 》 /dev/null 2》&1’”） | /usr/bin/crontab

如果驗證程序進程仍在運行，這將導致每60秒檢查一次，否則將重新啟動。

在公開報告中，為了協調在Web3空間中工作的團隊的協作，一個問題是“為polkadot創建和運行節點集群服務”（https://github.com/w3f/web3 collaboration/issues/43），這將解決可用性問題。

Cosmos比Polkadot更為成熟，它涉及一些主題，其中包括：

· 提供哨兵節點體系結構，這是一個基礎設施示例，用于緩解GAIA/COSMOS集線器網絡驗證程序節點上的DDOS。

“為了緩解這個問題，在云環境中部署了多個分布式節點（哨兵節點）。由于易于擴展，很難對驗證程序節點產生影響。新的哨兵節點可以在DDOS攻擊期間出現，并且可以使用八卦網絡將它們集成到事務流中。”

· Tendermint HSM密鑰管理系統（KMS）

“一種輕量級服務，旨在與GAIAD服務（理想情況下在單獨的物理主機上）一起部署，它提供以下功能：

· 對驗證程序簽名密鑰的高可用性訪問；

· 即使在驗證程序進程受到影響的情況下，也要防止雙重簽名；

· 硬件安全模塊存儲驗證程序密鑰，可在主機損壞后繼續使用”

今天就是這樣，至少在驗證程序冰山一角的表面上，您已經完成了第一步來確保和提高可用性。

在安全性和可用性的背景下，觀察polkadot如何隨著時間的推移而發展將是很有趣的。