AWS Lightsail で動かしている僕のsymbolノード ls1.rellc.jp ですが、いわゆるインターネット上に晒されたlinuxホストであり、常に攻撃される危険性を孕んでいます。
この記事では、ls1.rellc.jp で行っているセキュリティ関連の設定に基づき、くどくどと解説しています。ノード運営をしている方はよろしければ参考にしてください。
開放するポートについて
基本は塞いで、必要なポートのみ開ける
Lightsailに限らず、基本的に今どきのVPSやクラウドサービスでは、全てのポートは閉じられており、必要なポートのみ開放する、というスタイルになっていると思います。もしそうでないような、牧歌的な時代のサービスを使っているのであれば、今すぐに乗り換えることをお勧めします。
ssh接続用のポートについて
22番 sshについては、基本的に塞ぐか、限定するべきです。
自宅や事務所で固定IPアドレスサービスを利用しているのであればそのIPアドレスに限定してしまいましょう。
aws Lightsailではブラウザの管理画面からSSH/RDPを利用して接続できますので、むやみに開放せず、ブラウザ経由でのみ利用するという方法もあります。
sshでアクセスしたいけど固定IPアドレスを利用していない場合、全て開放するのではなく、少し手間ですが、アクセスする前に現在のIPアドレスを許可して接続すればいいでしょう
もちろん管理に利用するawsアカウントについてはMFAで多要素認証しておきましょう。
sshについて、未だにパスワード認証をnoにしており公開鍵認証だけにしてるからといって公開しているサイトもあるようですが（僕も2015年ぐらいまではそういう設定で旧ryo.comやrhosoi.comを運用してました）、間違いなく攻撃を受け続けます。
攻撃されてもログインされなきゃ大丈夫、もちろんそれはそうなのですが、攻撃に成功されたときのダメージが大きすぎますし、ログに攻撃の跡が残りまくりますのて管理の手間は気が付かない間に増大しています。
ログイン失敗を攻撃とみなして自動BANするfail2banなどのツールもありますが、もはやおすすめできません。運用するとわかるのですが毎日何件も何件もBANしててバカバカしいことこの上ないですし、すぐにfail2banのログもチェックすることなくなります。開けっ放しは本質的には危険な状態です。
標準22番以外のポートでsshを待機するという手段もしばしば使われますが、それでも接続元の限定は行っておくべきです。また、このような対応はポートスキャンによりすぐにバレてしまいますので、22番ポートをさまざまなホストで狙い撃つbotによる攻撃を避けることはできても、ホストが標的にされた際には全く意味がありません。
symbolノードが使用するポート
ここまできてやっと本題ですが、 3000 と 7900 がhttpでsymbolのdualノードでのサービス提供ポートですので、この2つは開放しておく必要があります。
https-portalをつかってhttps化するためには、 80 443 3001 の3ポートも追加で開放する必要があります。
80と443はhttps-portalがLet’s Encryptに対して証明書を発行・更新する際にnginxをつかって仮のサイトを提示するために使用し、3001はsymbolのhttps通信に使用します。
適切な管理と監視
symbolノードで委託ハーベスト可能な設定にしたとしても、node上で管理する秘密鍵を含むアドレスについては残高ゼロのまま運営することが出来ますので、万が一ホストに侵入されたり乗っ取られたりした場合も資産を失う可能性はほぼありません。だからといってノードを動かすホストの管理をおろそかにすることはよくないですね。
同一ホスト上で別サービスを動かさない
VPSを使うといろんなサービスを動かしたくなるのが人情です。たとえばWordpressなどのCMSを動かしてwebサイトを運営したり、別のブロックチェーンのテストネットを動かしたり、プライベートチェーンを動かしたり、dockerでいろんなコンポーネントを試したくなります。
しかしながら、暗号資産のメインチェーンを取り扱うホストで、このように別のアプリケーションを動かすことは積極的に避けるべきです。
このようなサービスがごちゃまぜになったホストは攻撃者とって好都合です。メインネット経由で直接攻撃できなくても、別アプリケーション経由でシステムに侵入することができる可能性があり、格好の攻撃対象になってしまうからです。
ログイン通知を受け取る
ホストに対するsshログインの通知をメールで受け取ります。
接続元IPアドレスを限定してるし自分しか接続しないので不要だ！という考え方では不十分です。自分の使用しているPCやLAN、WiFiが攻撃され、乗っ取られる可能性は常にあります。
そしてそのような攻撃を実際に受けた際、いわゆるアンチウイルスソフトや保護ソフトはほとんど役に立ちません（実際に有効な攻撃を受けたとき「既存の防御方法では防げないから」攻撃されているのです）。
sshによるログイン通知は常に受け取り、ログインするたびに確認を行い、万が一の攻撃時にすぐに対処できるように備えましょう。
僕のホストでは場合はシステム全体のsshrcを利用して
ryo@ls1:~$ cat /etc/ssh/sshrc
echo ""$USER" has logged in from $SSH_CLIENT at `date +"%Y/%m/%d %p %I:%M:%S"`" | mail -s "ls1 sshd login alert" アールホソイのメールアドレス@gmail.com
このように「ユーザー名、接続元、日付時刻」をメールで送信しています。
emailをあまり利用していないのであれば、slackやtwitterなどで自分宛てに通知を行うのも良いでしょう。
ryo@ls1:~$ ls -l /etc/ssh/sshrc
-rwxr-xr-x 1 root root 131 Mar 20 03:18 /etc/ssh/sshrc
rcスクリプトを追加する際はchmod +x を忘れないようにしましょう。
参考：SSHでログインしたらメールで通知する ＝＞しかしながら、特定のホストからの場合通知しない、ということをやるべきではありません。理由は上述した通りです。
chkrootkitの繰り返し実施
rootkitの検知ツール chkrootkit をインストールし、定期的に実行するようにしておきます。
侵入されたかも？となってからchkrootkitで確認しても手遅れであることがほとんどで、継続的に実行しておくことによってのみ、万が一の攻撃時にすぐに対応できるようにしておくことができます。
chkrootkitはubuntuのリポジトリにもありますが、僕は最新版のtarballを公式サイトから取得して使用しています。
root@ls1:~# cat /etc/cron.hourly/chkrootkit
#! /bin/bash
echo "** exec chkrootkit" >> /var/log/chkrootkit.log
/bin/date >> /var/log/chkrootkit.log
/usr/bin/nice /root/chkrootkit-0.54/chkrootkit | /usr/bin/tee -a /var/log/chkrootkit.log | /bin/grep INFECTED
exit 0
定期的な実行についてはcron.hourlyフォルダにchkrootkitとして設定を行うことにより1時間毎に実行するようにしています。このファイルも+xを忘れないようにしましょう。
root@ls1:~# grep MAILTO /etc/crontab
MAILTO=アールホソイのメールアドレス@gmail.com
また、システムのcrontabでMAILTO環境変数を設定し、メール出力を受け取るようにしています。
https-portalでhttps化している場合、Let’s Encryptを使用するためのツールcertbot-autoが誤検知されてしまいます。chkrootkit の Linux.Xor.DDoS誤検知 などを参考に対処しましょう。
※ chkrootkitが “chkrootkit: can’t find `strings’.” と出して動かない場合、スクリプト中で定義されているcmdlist (awk cut echo egrep find head ld ls ps sed strings uname)のどれかがインストールされていない可能性があります
※2 ubuntu20.04LTSで”ld”がインストールされていない場合、binutilsをインストール(sudo apt install binutils)します。
rkhunterなど、chkrootkit以外のルートキット検知ツールについても同様にしてみるのが良いと思います。
まとめ
- 開放するポートは 3000 と 7900 のみ
- sshポートは必要に応じてのみ開ける
- https化するなら 80 443 3001 も開ける必要アリ
- symbol-bootstrap以外のサービスを同居させない
- ログイン通知を受け取る
- ルートキット検出ツールを定期的に動かす
これだけやっておけば完璧！というわけではありません。
これだけやっていても、インターネット上にホストを公開するということは攻撃を受ける可能性は常にありますし、未知の脆弱性を利用され乗っ取りに合うことも十分にありえます。
ただ、これだけやっておけば、攻撃・侵入された際におそらく直ぐに気がつくことが出来ますし、その際の対処をすばやく行うことができるのです。
1500台を超えた全てのSymbolノードが可能な限り安全に運用されることを願います。
追記
Symbolノード運営情報の宝庫であるタヌソンslackにていくつかフォローいただきました。
- スーパーノードとして運用する場合、モニタリングエージェントが待機するポート 7880 も開けておく必要があります（Enokiさんに教えていただきました）。
- ノード上のメインアカウントについて残高ゼロのまま秘密鍵を保持する前提となっていますが、カスタムプリセットを使ってホスト上にはメインアカウントの公開鍵のみ保持し、必要なとき秘密鍵の入力を行うという運用を行うことも可能です。詳細は https://github.com/nemtech/symbol-bootstrap/blob/main/docs/presetGuides.md#private-key-security-mode を参照してください（しおじいさんに教えていただきました）。
どちらもスーパーノードを運用する場合は知っておくべき知識ですね。個人的にはスーパーノードのメインアカウントはしおじいさんのオススメの通り公開鍵のみにして、さらにマルチシグアカウント化しておくのが良いと思います。