神楽坂一丁目通信局 サーバー引き継ぎ後に行ったセキュリティ強化やその他の変更

また 東京理科大学 Advent Calendar 2016 の25日目の記事であり, 煽り記事である. もう26日だが, 世界のどこかではまだ25日だろうし, まあいいだろう.

東京理科大学 Advent Calendar 2016 - Qiita

なお, 私は東京理科大学の学生 ではない のだが, 縁があって『神楽坂一丁目通信局』というサークルに邪魔している. 『神楽坂一丁目通信局』には, ここで紹介するような技術を取り扱っている人間がいる (はずだ) .

さて, 『神楽坂一丁目通信局』では, Webサーバーを運用している. 今年, このサーバーの運用権限を私はだわちん氏から 奪い取り 引き継いだ. その後行ったセキュリティ強化やその他の変更の一部を記す.

パスワード総入れ替え

まず行ったのがパスワードの総入れ替えである. パスワードが全て同じだったため, パスワード管理のツールを使ってそれぞれに異なるパスワードを割り当てた. 基本的なことだ.

SSHのポート変更

SSHのポートをwell-knownポートに変更した. これには2つの利点がある. まず1つは, 特別な操作をしなくても使用できるユーザーがrootに限られる点, もう1つは, その一部が東京理科大学からアクセスできる点である. これにより, 神楽坂一丁目通信局局員はいつでも安全なSSH通信が東京理科大学からできるようになったのだ.

人権がある.

SSHの認証をパスワードのみから証明書を使った認証に変更

3日目の記事にはわざわざパスワードでアクセスできるようにする変更が行われている. 馬鹿なんじゃないか? サーバー構築の勉強するのにわざわざセキュリティを弱めてどうする? 証明書を使っても使いやすくするのが本当のあり方というものだろう.

証明書を使うことによるセキュリティの改善は2つある. 1つは, 仮に通信を復号, 傍受されたとしても恒久的な認証情報は盗めない点, もう1つは, 証明書 (が保存されたクライアント) とパスワード (を入力する人間, あるいは入力時のクライアント) を攻略する必要がある点である. つまり, パスワードの場合だと, サーバー, クライアント, 人間のいずれか1つを攻略するだけで攻撃が成立してしまうが, 証明書の場合だとクライアントと人間の両方を攻略しなければ攻撃は成立しないのだ.

ということでパスワードのみから証明書を使った認証に変更し, パスワードによる認証は無効にした.

なお, どうしてもパスワードで認証したいという場合はチャレンジレスポンスを用いると良い. そうすれば, サーバーがやられてしまったとしても恒久的な認証情報は盗めないという利点は享受できる. これを用いている例として, 東京理科大学の無線LANがある. もっとも, あれは脆弱な暗号を利用しているのでその利点は失われているが.

私はgnome-keyringを使って認証をより容易にしている.

ユーザーの作成とrootによるSSHログインの無効化

ユーザーを作成し, rootによるSSHログインを無効化した. そもそも, Unix系OSの利点はユーザーにより権限を分散できることにある. また, 局員にユーザー権限のみを許可する, といった利用も可能になる. これはそもそもミニコンピュータに端末を使ってアクセスしていたというUnixの利用方法と同じだ.

管理者はwheelグループに登録し, sudoersを弄ってwheelグループのユーザーはrootになれるようにする. これにより, 今後管理者が変わった場合にも後継者をwheelグループに追加し, その後に私を除外すれば容易に移行できる.

SELinuxの有効化

しかし, Unix系OSではrootに権限が集中してしまっている. 例えば, インターネットに繋がっていて, なおかつrootで動作しているSSHに対して攻撃が成立してしまったら, その時点で全ての権限が掌握されてしまう. これはまずい.

そこで, LinuxではSELinuxが用意されている. どうやらさくらがプリインストールしているCentOSではSELinuxが無効にされているようなので, 有効にする. CentOSが提供しているtargeted policyを利用した.

有効にする前に, permissiveモードにしてpolicyに違反している動作を確認しよう. 当方では, SSHのポートを既定から変えているために違反が発生したりした. それらに応じて, policyの追記, 修正を行う.

CentOSの6から7へのアップグレード

TLS証明書の自動発行サービス, Let’s EncryptではCertbotというソフトウェアを使用している. これはCentOS 7から標準リポジトリで提供されるようになった. これを利用するため, CentOSを6から7へアップグレードした.

systemdやfirewalldが導入されるため, 高確率で死亡する. また, 当方では様々なライブラリの更新が失敗し, ほとんど身動きが取れないという状態に見舞われた. SSHさえも動作しなくなる可能性を覚悟したほうが良い.

SysVinitからsystemdへの移行

そんなこんなで見事爆死したサーバー. 外部リポジトリや手動でインストールされたアプリケーションなどが軒並み死んだので, これらを更新, あるいは排除していく. 一応SysVinitと互換があるので動くことには動くが, 移行したほうが無難だ.

Let’s Encryptの導入

Let’s Encryptの導入により, TLS対応ができる. これはそんなに難しくない. 先ほど紹介したCertbotというアプリケーションを定期的に実行すれば良い. 繰り返すが, CentOS 7ではsystemdを利用できる. 3日目の記事ではcrontabを使っていたが, ここはsystemdのtimerを用いよう.

IPv6対応

神楽坂一丁目通信局には物好きな人がいて, IPv6を使いたいというかいうツイートが昨日飛んできた.

DNSにAAAレコードを追加した. するとIPアドレス直打ちでも繋がるようになった. ドメイン名の方は, 事前にTTLを変更したりしていないので変更が反映されるまでしばらく時間がかかる.

これから

残念なことに, Webサービスを提供している, 局内で開発したTsuboneSystemというソフトウェアにいくつか問題が見つかり, 大幅な修正, あるいは破棄せざるをえないことが判明した. そして現在, その後継となるソフトウェアが開発されている.

現在のシステムはJavaで書かれているが, 新システムはGoで完全に新しく書き直されたため, クソ重いJavaVMとおさらばでき, より安価なサーバーでホストすることも可能になるだろう.

また, 局員向けサービスはSPAによって実装されるなど, 極めて挑戦的なものである. 現在のシステムが抱えている問題を解決するため, 一刻も早いデプロイが望まれる. 本当は次期システム開発中にも現在のシステムをメンテナンスできるように人手が欲しいのだが…

3日目の記事を書いた人は世界のどこがかクリスマスのうちに悔改めよ. まあ昔の話のようだからもう十分反省してるかもしれんけどね. 勉強の助けになったら嬉しいな☆(・ω<)

[top]