セキュリティ対策は技術と考え方の両輪で進めないといけない。一方だけではセキュリティインシデントが発生する確率が高まる。事故を未然に防ぐには具体的な方法と、それを裏で支える思想が必要だ。
目次
- Rootログインは禁止にする
- 秘密鍵の設定をする
- パスワードログインの禁止する
- SSHのIP制限をする
- アクセスできる人を制限する
- 社内の基本的なセキュリティ対策を徹底する
Rootログインは禁止に
サーバーのRootログインは当然禁止にしよう。まだ禁止にしていない人は、下記のコマンドを打ってみるといいだろう。セキュリティまわりのログを確認できる。
こんなログが3秒おきにあれば大至急対策をしたほうがいい。これはランダムなログイン情報をひたすら繰り返し、いつかサーバーに不正にログインされる可能性がある攻撃である。パスワードはパスワードは10桁もあれば破られる可能性は低いが、それでも一度破られると取り返しがつかない。
どうなるかはこちらの本当にあった怖い話「サーバーがクラッキングに遭って復旧できなかった件の末路とやるべきだった事」を参照されたし。
rootログイン禁止は簡単で/etc/ssh/sshd_configにあるPermitRootLogin noをコメント#を外して、sshdを再起動するだけである。もちろん、root以外のユーザーアカウントを事前に作っておく必要があるのは、言うまでもない。
ちなみに実際に破られた事例を知っていて、さくらVPSに不正ログインされると、以下のような措置が取られる。強制的にサーバーをクリーンインストールするしかなくなるのだ。バックアップがなければ終わりであるが、SSHのrootログインを禁止をするという基本的な設定をしていないサーバー管理者が、サーバー外にバックアップをとっているだろうか。
○○ 様
ご連絡いただきありがとうございます。
さくらインターネットabuse対策チームでございます。ご連絡いただきましたところ恐れ入りますが、現状のまま制限を
解除いたしますと前回同様の症状が発生する可能性がございますため
制限を解除することができかねます。ご了承ください。制限解除につきましては、本件のご回答及びその内容を確認、検討しました
うえで、弊社営業時間内での対応となります。あらかじめご了承ください。なお、ご利用サーバにつきましては、管理者権限をお客様にお渡し
しているサービスとなりますため、原因については弊社にて特定
することができません。恐れ入りますが、お客様にてご利用サーバ内に不審なファイルや
プロセス等が起動していませんか調査・ご対応を行っていただけますよう
お願いいたします。また、一例となりますが、考えられる原因等については以下をご参考ください。
○考えられる原因
・CMS(WordPress・joomla!・など)やウェブアプリケーション、その他の
ウェブに公開したプログラムの脆弱性を悪用されている。
・CMS・ウェブアプリケーション類のログイン権限をもつユーザのパスワードが
漏洩し、悪用されている。
・アプリケーションサーバ、データベース他、ミドルウェアの脆弱性を悪用されている。
・アクセス制限を設定していないサービスを悪用されている。
・管理用ユーザ、一般ユーザ、試験目的のユーザアカウント等のパスワードが漏洩し悪用されている。○必要な対策
・【重要】ご利用サーバ内の覚えのないファイル・フォルダを探し削除する
・【重要】不正なプログラムが動作していないか全てのプロセスを調査する。
・chkrootkit、rkhunter、maldetect等を活用し攻撃プログラムを捜索し削除する。
・悪用されたユーザアカウントがないか調べて対策する。・重要なデータを他の環境にバックアップする。
・調査困難な場合・原因不明の場合は、OS再インストールを検討する。○再発防止策
・不要なCMS・ミドルウェア・ソフトウェアを削除する。
・不要なサービスを停止する。
・不要なユーザアカウントを削除する。
・パスワードの管理ポリシーを検討する。・OSのアップデートを実施する。
・ミドルウェア・ウェブアプリケーション・CMS等を最新のバージョンへアップデートする。・iptables・firewalldなどファイアウォールを設定する。
・各ミドルウェアに固有のアクセス制限機能がある場合、設定する。■注意事項・考えられるリスク
・対策が不十分な場合、再発する危険があります。
・調査対策が困難な場合は、OS再インストールをご検討ください。▼OS再インストール(さくらのVPS)
https://help.sakura.ad.jp/hc/ja/articles/206207961
秘密鍵の設定をする
作成したユーザーで秘密鍵を作成しよう。設定はこの秘密鍵の設定方法を見るといいだろう。
初心者のために記事の補足をしよう。記事中のサーバーAをローカルマシン、サーバーBをリモートと考えるといい。公開鍵を設定するのはリモートで、秘密鍵を保持するのはローカルである。サーバーの公開鍵は/home/ユーザー名/.ssh/authorized_keys のようなpathとなり、これは/etc/ssh/sshd_configに設定を記述する箇所がある。
パスワードログインの禁止する
秘密鍵の設定をしてパスワードを入力しなくてもサーバーにssh接続できることを確認したら、パスワードログインを禁止しよう。これも/etc/ssh/sshd_configで設定できる。秘密鍵の設定前にパスワードログインを禁止すると、タイミング次第ではログインできなくなるので要注意。
さくらVPSのようなサーバーの場合はコンソールログインという奥の手があるが、こういう最後のカードはあまり使わないよう慎重にサーバーの設定をしたいところだ。
SSHのIP制限をする
さらにセキュリティを強化する場合はSSH可能なIPを制限することもできる。ただし、最近はゼロトラストネットワークという考え方もあるくらいで、IP制限さえすれば絶対安全というわけではないので、盲進しないように注意したい。以上で技術的な設定について説明を終わる。
アクセスできる人を制限する
ここからは運用面のお話をする。どんなに厳重なセキュリティ設定をしても、アクセス出来る人が増えるほど漏洩の可能性は高まる。したがってサーバーにSSH接続できる人を制限するのは言うまでもない。
これは社員を信用するとかしないという意味ではなく、事故は起こり得るという前提で考えないといけないのだ。故意に情報を漏洩させるなんてのは論外だが、そんなケースはあまりなく、むしろ偶発的にセキュリティインシデントは発生する。
例えば、酔って終電に乗った社員が鞄ごとPCを盗まれるとか、どこかに置き忘れるとかそういう事例である。ちなみにこれは例え話しではなく、私が実際に見た事例である。もしその盗まれたPCにパスワードがかけなかったら終わりである。
社内の基本的なセキュリティ対策を徹底する
情シスがいないようなゆるい中小零細企業の場合、支給されたパソコンに当然のごとくパスワードをかけない人とか、世の中にはいるんです。あるいは私物パソコンを業務に使うとかもある。
そういう人は面倒とかではなく、そもそもパスワードをかける発想がなかったりする。リテラシーが低いので仕方ないのだ。
情シスを雇うのが難しい会社の場合でも、最低限の社内のセキュリティポリシーを策定し、それを社員に守られるくらいのことは必要である。それだけでセキュリティインシデントが発生するかなり確率は減るだろう。