---
title: 2020年度版Mastodon鯖管セキュリティチェックリスト
slug: /~h12o/mastodon-security-checklist-2020
tags: Mastodon
---
# 2020年度版Mastodon鯖管セキュリティチェックリスト

## まえがき

分散SNSは、プロトコルさえ守ればどこでも運用できます。そのため、必然的に多くのオープンソース実装が登場します。そして、オープンソース実装が多数存在するということは、ある程度の心得があれば、誰でもSNSサービスを運営できるという特徴につながります。しかし、心得がある人でも、鯖管（運営者）として、自サーバのセキュリティに自信を持てる人はそれほど多くないのではないでしょうか。

分散SNSのひとつMastodonは、比較的堅牢なウェブアプリケーションで、特に脆弱（ぜいじゃく）というわけではありません。また、Mastodonのセキュリティに関して優れた記述の文書もあります。しかし、利用者としての注意点と鯖管（運営者）としての注意点がごっちゃになっていたり、視点が偏っていたりするものも多く見受けられます。

一方、セキュリティは、一箇所でも欠陥があると、そこから破られてしまうという性格があります。言い換えると、網羅的に考えることがセキュリティではとても大切だということです。

筆者がMastodonのセキュリティに関して様々な記事を調べた結果、不満に感じたことは、以下の2点です。

1. 相手が明確ではないものが多いこと
2. 網羅性に欠けるものが多いこと

そこで今回、以下の2点を意識したセキュリティチェックリストを書いてみることにしました。

1. Mastodonの鯖管向けであること（Mastodonにアカウントを持っている人向けではありません）
2. 網羅性をなるべく高めること

なお、筆者はMastodon以外の運用経験がないため、本記事はMastodonを前提に執筆しています。しかし、MisskeyやPleroma、PixelFedなど、その他の分散SNSでも、セキュリティの原理原則が大きく変わることはありませんので、分散SNSの管理者にとって参考になる箇所も多数あるかと思います。本記事を少々修正すればこれらのセキュリティチェックリストを作成することも簡単でしょう。

また、本記事では、具体的な手順は省略しました。セキュリティを高めるには、「何をしたか」ではなく「どんな状態に到達したか」、すなわちベースラインが重要であるためです。ベースラインさえ明確になれば、鯖管をやろうとするみなさんのことですから、きっと正解に到達できるでしょう。

## このチェックリストの使い方

各項目は、「必須」「推奨」「任意」の3段階に分類しています。

- 必須: 実施しないと高確率でサーバに侵入され、被害を受ける結果につながるもの
- 推奨: 特別な事情がない限りは実施した方がよいもの
- 任意: 実施することでより安心できるもの

個人〜有志運営によるサーバを想定しています。

企業で運用するサーバは想定外です。企業で運用する場合は、自社の情報システム部門や情報セキュリティ部門、CSIRTといった組織と相談することをお勧めします。

## 準備

### 目的

- （必須）Mastodonホスティングは検討しましたか?
- 技術力に自信がない人は、Mastodonホスティングを使うことをお勧めします。いまは、攻撃者はどんなサーバでも狙ってきます。
- （推奨）ユーザは誰を想定しますか?
- おひとりさまか、友だちだけを受け入れるか、不特定多数を想定するかで、守るべきものやことが変わります。
- いきなり不特定多数を想定してMastodonサーバを立てることはおすすめしません。不特定多数を受け入れる場合、おひとりさまや友だちだけを受け入れるのに比べて、管理者（すなわち、あなた）にかかる負荷が非常に大きくなります。

### ドメイン

- （推奨）契約しようとしているドメイン業者では、DNS CAAは設定できますか?
- SSLサーバ証明書を第三者が勝手に発行することを防げるため、偽サーバへの誘導を防ぐことができます。後述のHSTSヘッダの設定と合わせて、偽サーバへの誘導を防ぐための重要な手段です。
- （推奨）契約しようとしているドメイン業者では、DNSSECは設定できますか?
- DNS情報の改ざんによる偽サーバへの誘導を防ぐことができます。単に利用者が偽サーバへ接続することを防ぐだけではなく、Let's Encryptに対してDNS情報を改ざんすることで偽の「正規の証明書」を発行されてしまうことを、防ぐ意味合いがあります。
- （任意）ドメイン業者はwhois情報公開代行に対応していますか?（サブドメイン形のMastodonホスティングサービスを除く）
- 対応している業者・対応しているTLDを選びましょう。
- （任意）スパムメールが届いても問題ないメールアドレスは持っていますか?
- whois情報に掲載しても問題ないメールアドレスがあると安心です。

### コンプライアンス

- （必須）サーバ所在地がどの国・地域に属しているか把握していますか?
- サーバ所在地が属する国・地域によって法的な影響が変わります。

## 構築

### OS

- （推奨）SELinuxまたはAppArmorを有効にしていますか?
- 開発者向けに書かれた文書では、煩雑さを嫌ってでしょうか、SELinuxを無効にすることが多いようです。しかし、これはおすすめできません。
- SELinuxやAppArmorを無効にしていると、管理者権限を奪われた場合に壊滅的な被害を受けます。万が一の場合でも被害を限定的なものにするために、きめ細かいアクセス制御が可能なSELinuxやAppArmorを有効にすることを強くお勧めします。
- 「推奨」にしていますが、限りなく「必須」に近い推奨です。

### メールサーバ

- （必須）SPFやDKIMの設定はされていますか?
- 設定がされていないと、メールが迷惑メール扱いされる確率が非常に高くなります。
- （必須）MailgunやSendgridの契約は把握していますか?
- 普通は無料契約にするものと考えられますが、無料契約であることと、無料契約の場合はクレジットカード番号の入力が不要なことを確認しておきましょう。
- 攻撃者は、ドメインを発見してMXを調べ、MXがMailgunやSendgridだった場合、管理者に対してフィッシングメールを送りつけることがあります。MailgunやSendgridを装ったフィッシングメールは、「クレジットカードの決済が通らなかった」と言って、クレジットカード番号の入力を促すサイトに誘導するメールです。
- 落ち着いて考えましょう。無料契約なのに、契約途中で「クレジットカードの決済が通らなかった」となることはありません。
- おひとりさまMastodonなどで、自分宛てのメールしか飛ばないと分かっている場合は、MailgunやSendgridを使う代わりに、GmailのメールサーバをSmartHostに設定する方法もあります。ただし、Postfixの知識がないとうまくいかないうえ、Gmailの設定が若干面倒くさいこと、将来にわたって有効に使える手段とは限らないことから、お勧めはできません。

### HTTPS（HTTP over TLS）設定

- （推奨）TLS 1.2以上を使う設定になっていますか? また、脆弱な暗号スイートが除外されていますか?
- HTTPSであれば安全、ではありません。SSL2.0や3.0、TLS1.0や1.1はいまでは「古い」「安全性が低い」と言われてしまいます。
- 最適な暗号スイートの組み合わせは一言では言い表せないうえ、時とともに危殆化（きたいか - いままでは安全と考えられてきた暗号方式などが、セキュリティ研究者の研究成果などによって危険とみなされるようになること）しますので、定期的に信頼できるテストにかけて、不備を修正していくのが現実的な対策です。
- 定番としては「Qualys SSL LABS SSL Server Test」（ https://www.ssllabs.com/ssltest/ ）が挙げられます。レーティングA以上が安全性の目安です。
- （推奨）HSTSヘッダは設定されていますか?
- サーバからHSTSヘッダを受け取ったウェブブラウザは、それ以降HSTSヘッダで設定された一定期間内、`http://`で始まるURLが指定されていても、HTTPSアクセスに「勝手に」切り替えてアクセスするようになります。これは、前述の偽サーバへの誘導に対して一定の効果があります。
- 限界もあります。偽サーバが偽の「正規の証明書」を持っている場合には、HSTSには意味がありません。HSTSを設定すると同時に、DNS CAAおよびDNSSECも合わせて設定しましょう。

### ミドルウェア

- （必須）RedisやPostgresQLのパスワードは設定されていますか?
- RedisやPostgresQLが**Mastodonと同じホストにあったとしても**、パスワードは設定してください。SSRF攻撃のようなシェルアクセスを要さない攻撃によって、メモリストアやデータベースをリモートから読み書きされるのを防ぐことができます。
- いまのところMastodonやミドルウェアにSSRF攻撃可能な脆弱性は発見されていません。しかし、万が一脆弱性があった場合、パスワードが設定されていることで、被害を最小限にすることができます。
- Mastodonサーバへのシェルアクセスを許してしまった場合は、ミドルウェアにパスワードがかかっていても意味はありません。しかし、パスワードが設定されていることによるデメリットはありません。
- （必須）データベースのバックアップは定期的にとっていますか?
- データベースのバックアップがあれば、仮に侵入された場合であっても、バックアップまでは巻き戻すことができます。最低でも1日1回をお勧めします。

### ファイアウォール

- （必須）ポートはHTTP（80番）・HTTPS（443番）・SSH（TCP 22番または変更後のポート）以外ふさがっていますか?
- nmapやNessus（無料ライセンスあり）などで確認できます。
- （任意）WAF - Web Application Firewallを導入していますか?
- WAFは、通常のファイアウォールが対象とはしていない、ウェブアプリケーションの脆弱性を突く攻撃を検知して食い止めるファイアウォールです。
さくらのVPSなどではSiteGuardが無料で提供されています（ https://help.sakura.ad.jp/115000021862/#02 ）。
無料のWAFが使える場合や、WAFのライセンスが余っている（ようなお金持ちの人の）場合は、WAFを導入するとよいでしょう。

### SSH

- （必須）SSHはパスワードログインできないようになっていますか?
- 必ず公開鍵認証を使うようにしましょう。
- （任意）SSHのポートはTCP 22番から変更されていますか?
- 攻撃者はTCP 22番ポートがSSHであるという前提で侵入を試みます。
ポート番号を変えておくと、攻撃者が前提としていることを覆すことができます。
- （任意）SSHログインできるコンピュータをIPアドレスベースで制限していますか?
- VPNやVPCネットワークを使って、インターネットから直接SSHログインできないようにすることもセキュリティ上有効です。
- （任意）SSHでログインしたとき、メールやSlackなどで通知が届くようになっていますか?
- 身に覚えのないSSHログインがあった場合、それを検知できます。

### 証明書

- （必須）証明書の有効期限が近いときに通知が届くようになっていますか?
- 証明書の有効期限が切れると利用者がアクセスできないだけでなく、管理がずさんなのではないかと攻撃者に思われる危険性があります。
- Let's Encryptの場合はメールで通知する機能があります。その他の認証局でも、たいていはメールやサイトのダッシュボードなどで通知されます。

## 運用

### 脆弱性対応

- （必須）Mastodonに関係するソフトウェアをキーワードとして把握していますか?
- 簡単でよいので、Mastodonに関係するソフトウェアをキーワードとして理解しておく
- （OS）CentOS・Ubuntu・Debian: お使いのOS・ディストリビューションの名前とバージョンを記憶しておきましょう。
- （コンテナ）Docker: サーバによってDocker使用の有無は異なります。自身のサーバがDockerを使っているか・使っていないかは記憶しておきましょう。
- （キャッシュ）Redis: お使いのバージョンも記憶しておきましょう。
- （データベース）PostgresQL: お使いのバージョンも記憶しておきましょう。
- （アプリケーション）Node.js
- （アプリケーション）Ruby on Rails
- （HTTPSサーバ）Nginx・Apache: どちらを使っているか記憶しておきましょう（これらのウェブサーバ以外を使っている方もいますが、そのような方には言うまでもありません）。
- （必須）脆弱性情報を入手できるサイトは知っていますか?
- 最低でも「JPCERT/CC Weekly Report」（ https://www.jpcert.or.jp/wr/ ）・「JVN」（ https://jvn.jp/ ）・ 「JVNiPedia」（ https://jvndb.jvn.jp/ ）の存在は知っておきましょう。
#JVNiPedia のRSSフィードは https://blessedgeeks.social/@JVNiPedia でフィードしています（2020年5月31日現在）。
- セキュリティ専門のニュースサイトは「ScanNetSecurity」（ https://scan.netsecurity.ne.jp/ ）などがあります。
- 一般のニュースサイトは、セキュリティに関しては不正確だったり誤解を招いたりする情報を流すこともあります。
- （必須）Mastodonのバージョンアップ情報は把握していますか?
- https://mastodon.social/@mastodon
- https://github.com/tootsuite/mastodon/releases
- Githubのreleasesは、「`.atom`」を付加するとATOMフィードを得ることができます。
例: https://github.com/tootsuite/mastodon/releases.atom
- （必須）Mastodonを計画的にバージョンアップしていますか?
- Mastodonは比較的堅牢なウェブアプリケーションですが、過去には脆弱性が発見されたこともあります（たとえば、Mastodon 2.5.1およびそれ以前にはXSSの脆弱性があります（注1）。また、Mastodon 2.6.3およびそれ以前にはセッション期限に関する脆弱性があります）。
- バージョンアップしていないことが見えると、攻撃者のモチベーションを上げることにつながります。

（注1: https://github.com/tootsuite/mastodon/releases/tag/v2.5.2 に「Fix XSS vulnerability ([#8959](https://github.com/tootsuite/mastodon/pull/8959))」とあります）

### Mastodon

- （必須）Mastodonの管理者はパスワードを使いまわしていませんか?
- 漏えいしたパスワードのリストを用いて、他のサイトにログインを試みる攻撃を「パスワードリスト攻撃」と呼びますが、長年にわたって使われている（つまり、効果のある）攻撃手法として用いられていて、非常に多くの被害をもたらしています。
（参考: 「SSTエンジニアブログ - 2019-08-19 絵で分かる! パスワードリスト攻撃」（ https://techblog.securesky-tech.com/entry/2019/08/19/ ））
- 「パスワードは覚えるものであって、絶対にメモしてはいけない」という人もいまだにいますが、現実的には困難です。
筆者としては、自分でも覚えられないような完全にランダムな文字列を生成したうえで、パスワード管理ソフトを使って保存し、定期的にバックアップを取得することをお勧めします。
- （推奨）Mastodonの管理者は二段階認証を有効にしていますか?
- 2010年代後半ごろからは、多くのサイトで二段階認証が導入されています。
- （推奨）新規登録受付を閉じていますか?
- スパムアカウントを作られるおそれがあるので、招待制またはおひとりさまMastodonにすることをおすすめします。
- （推奨）「メールブラックリスト」への追加方法は把握していますか?
- 新規登録受付を開ける場合、スパムアカウントを作成されることを100%防ぐことは不可能です。また、対処ができればいいだけなので、目指す必要もありません。
- Mastodonのメールブラックリストには、MXホストを追加することができます。スパムに使われるMXホストはある程度限られてくるので、過去スパムアカウントの作成に使われたメールアドレスのMXホストをメールブラックリストに追加することは有効なスパム対策です。しかし、この機能を正しく使うためには、メールアドレスとMXの概念を把握しておく必要があります。
- （推奨）「スパム対策を有効にする」をオンにしていますか?
- Mastodonの「スパム対策を有効にする」は、迷惑なメッセージを繰り返し送信するアカウントを自動通報する機能です。 「誤検知を含む可能性があります。」との但し書きもありますが、有効にすることをお勧めします。

### コンプライアンス

- （必須）ソースを改変した場合、そのソースをGithub等で公開していますか?
- MastodonはAGPLでライセンスされています。AGPLでライセンスされているソフトウェアのソースコードを改変したときは、それを開示する必要があります。
- Githubで公開する場合、[tootsuite/mastodon](https://github.com/tootsuite/mastodon)をforkしてから、forkしたGithubレポジトリをgit cloneするのが簡単です。改変を加えたソースコードをgit pushするだけでライセンスを遵守できます。
- （推奨）電気通信事業者としての届出をしていますか?
- Mastodonのサーバも、電気通信事業法上の「電気通信設備」に該当します。そしてそれが「他人の通信の用に供する」「他人の需要に応ずるために提供する」「事業である」場合は、電気通信事業となります。
- Mastodonにはダイレクトメッセージ機能がありますが、これは他人の通信の仲介と解釈することもできます。そのため、Mastodonを運営することが「他人の通信の用に供する」「他人の需要に応ずるために提供する」「事業である」と考えることもできてしまいます。
- さらに、電気通信事業には届け出を要するものと要しないものとがあります。Mastodonを運営することで、サーバ運用にかかる費用をカンパするような場合を含め、サーバに関連して金銭の授受が発生する場合は、実際の利益の有無にかかわらず、営利目的とみなされるおそれがあります。おひとりさまMastodonのように届出不要と言い切れない場合は、届出をするのが無難です（この件は、意見が分かれるところですが）。
- （推奨）利用規約に禁止行為は明記されていますか?
- おひとりさまMastodonでもない限り、ユーザがトラブルを起こす前提は考えておくのがよいでしょう。

## 非常時

- （推奨）サーバに侵入された（インシデントが起こった）場合の復旧手順は把握していますか?
- 企業サーバでは説明責任を果たす関係からも、ある程度の原因追及ができることが望ましいといえますが、個人で運用しているサーバでは、最低でも復旧手順を事前に確認しておきましょう。

## 参考文献

- ashphy's commit logs - 2018-08-26 [マストドンセキュリティガイドライン](http://ashphy.hateblo.jp/entry/mastodon-securit-guidelines)
- 鯖缶工場Wiki - [Mastodonセキュリティチェックシート](https://wiki.sabakan.industries/mastodon/security-checksheet)

## あとがき

筆者は、セキュリティエンジニアと呼ばれる類のエンジニアです。

1990年代末から2000年代初頭、筆者はウェブエンジニアでした。
そのころは、ウェブアプリケーションといえばCGIが一般的で、Ajaxの概念もほぼ存在しませんでした。しかし、誰もが、技術的興味で、いい意味で気軽に、様々なウェブサービスを世に送り出していった時代でもありました。
古き佳きインターネットの絶頂期です。

しかし、インターネットが進歩を重ねるにつれ、いつしかウェブはプロフェッショナルの世界となりました。お金の匂いがするところには、残念ながら悪意も集まります。
悪意ある者が、様々なウェブサービスを、技術的興味と気軽さの裏返しでもある脆弱性を暴き、蹂躙していきました。
我々セキュリティエンジニアは、「素人はウェブサービスを出すな」というポジショントークをせざるを得なくなりました。
私には心のどこかで、あのころの古き佳きインターネットを、泣く泣く諦めたという負い目があったのかもしれません。

分散SNSの登場とMastodonの突然の流行は、私を含む。古き佳きインターネットの再来を待ち望んでいた人たちにとっては、福音だったとも言えるでしょう。
安全で、改変可能で、あの頃と同じくらいの手軽さでウェブサービスを世に出し、コミュニティを作ることができる、という意味で、Mastodonは奇跡的によくできていると言えるでしょう。

正直にいうと、セキュリティは「守ろうとするとつまらない」ものです。セキュリティは、（筆者のように脆弱性に対する技術的興味があれば別ですが）技術的興味と関係があるわけではないので、できれば考えずに済ませたい。

しかし、時代はもはやそれを許しません。であれば、Mastodonはじめ分散SNSを運用する人に、セキュリティエンジニアとして何ができるかを伝える必要があるのではないだろうか。

…といったことを思って書いたような気がします（「気がします」というのは、執筆していたときの思いを振り返りながらこの「あとがき」を書いているからです）。これから分散SNSを運用しようとする方が、セキュリティについて考える時間を少しでも減らすことができますように。本記事が、その助けとなれば幸いです。

最後になりましたが、本記事執筆の機会をご提供くださった国見小道さんに感謝を申しあげます。

## 自己紹介

- ほそのひでとも @h12o （エイチ・じゅうに・オー）
- <s>https://blessedgeeks.social/@h12o</s><br />https://blessedgeeks.com/@h12o<br />https://mastodon.tokyo/@h12o

1975年生まれ、本職は<s>大手ECサイト運営会社の情報セキュリティ担当</s>2023年1月よりクラウドサービスのセキュリティチェック支援SaaSを開発している会社に勤務。
Mastodon運用は2年弱（2020年現在）ほど経験。