communication-g7396f4352_1280

▼更新履歴(クリック/タップで展開)

2023/07/07: 環境のアップデート方法も改めて書いておいたほうがいいと思ったので、当該項目を追加。 また、一部のまどろっこしい部分やあやふやな部分、わかりにくい部分を多少修正。

2023/06/26: WebArena Indigo以外のVPSを使っている場合に必要と思われる「(Web ARENA Indigo以外のVPS向け)rootのログインと、パスワード認証を禁止する」という項目の追加。 及び、本記事の内容の実施を促す「そもそも狙われる・攻撃されることってあるんですか?」の追加。

Misskeyの鯖建ての記事の内容では少々セキュリティ面において不安が残る部分があったため、私でも(WEB上の記事を見ながらなら)できそうな範囲で「ちょっとでもいいのでセキュリティを向上する」感じのものをピックアップしました。

基本的には先の記事を補う立ち位置の記事なので、MisskeyなりFirefish(旧Calckey)なりを使っている想定ではいますが、多分内容的には普遍的なものだと思います。 高度なことは書いてないと思うので(“ど素人”なので!)、あまり期待せずにお読みください。

Ubuntu環境を想定しています。

そもそも狙われる・攻撃されることってあるんですか?

はい、日常的に知らずのうちに狙われ、攻撃されている……なんてことは珍しくありません。 無事でいられたのはたまたま、というくらいの認識のほうがいいかもしれませんね。

いわゆる標的型攻撃(特定個人を狙った攻撃)ではなく、セキュリティの甘いところがあれば攻撃を試す……のようなタイプの攻撃の被害は、文字通り明日は我が身のような状態なのです。 攻撃ツールでサーバーを網羅的・無作為に探して回り、脆弱な点を調査し、該当すれば攻撃する……というような。

よって、「別にあなたではなくてもいいが、セキュリティが甘ければあなたが対象になる」というような感じの攻撃が行われています。 そうした無作為な攻撃から身を守るためにも、いくらかでも被害を避けたり抑え込んだりするためにも、以下の項目は最低限チェックした方がいいでしょう。

(WebARENA Indigo)ユーザーのパスワードを設定・変更しておく

私が書いた記事ではWebARENA IndigoというVPSを使っているんですが、ちょっと特殊で……SSH接続の際のデフォルトユーザー名がubuntuで、なおかつ、パスワードが設定されていません。

なので、使っているのが他のVPSであったりする場合はこの項目は読まなくていいと思います。 が、パスワード変更のコマンド自体は、他のVPSでも使えるので初期パスワードが気になるとか言う場合には変更してもいいかもしれません。

その場合、パスワード認証をしない設定にした上で、公開鍵認証設定をするのがより安全です。 次の項目を参考にしてみてください。

まぁ、初期状態でパスワード認証は拒否されており、SSH鍵の認証をするようになっているので問題はない……のかもしれませんがちょっと気持ち悪いですし、「パスワード入力を求められるのに、パスワードを設定していないので操作の続行が不可能になる」みたいな状況もよくあるので、設定したほうがいいでしょう。

ただ、パスワード変更時に少し問題があったため、「Authentication token manipulation errorでパスワードが変更できなかった」を参考にしました。

上記の記事にもあるように、いきなりパスワード変更しようとしてもなぜかエラーで弾かれてしまったので、まずは、

sudo pwconv

を入力します。 よくわかりませんが、パスワードを保存するファイルに発生した問題を解決するものだとか……?

続いて、パスワード変更のコマンドを入力。

sudo passwd ubuntu

すると以下に、

New password:

という表示が出てくるので、パスワードを設定します。 入力中、文字が表示されないのでご注意を。

Retype new password:

すると確認のために再入力を求められるので、間違えずに再入力します。 やっぱり文字は表示されないので、焦らず慎重に。

ともあれ、これでパスワード変更可能です。 もっとも、前述の通りあまりパスワードを使う機会がないかもしれませんが……設定しておいても損はないでしょう。

(WebARENA Indigo以外のVPS向け)rootのログインと、パスワード認証を禁止する

WebARENA Indigo以外のVPSの場合、もしかしたらrootでのログインや、パスワード認証でのログインが可能な状態になっている場合があります。 SSHクライアントのログインユーザー名がrootだったり、その際にパスワードを入力している場合は該当するでしょう。

rootでのログインを禁止するのは、rootユーザーは権限が強大すぎる(が、名前が割れていて狙われやすく、乗っ取られた場合に被害は甚大すぎる)ためです。

また、パスワード認証も公開鍵認証よりはリスクがあるため、同じく禁止します。

これらの作業をする場合、「KAGOYA(カゴヤ)のVPSでUbuntuを初期設定しよう」が参考になるかもしれません(鍵の使い回しがいいのかは不明ですが、手間は少ないです……)。 念の為書いておきますが、hugahugaはこういうことなのでそのまま使わないように……。 user_nameやhugahugaの部分は適宜自身で追加するユーザー名に読み替えてください。

他の記事を参考にしてもいいですが、ともかく、やることは2つで、「新規ユーザーを作成、sudoできるようにし、公開鍵認証させるために鍵を移す(もしくは作成する)」と、「rootユーザーのログインを禁止する」です。

KAGOYA以外のVPSを利用する場合は、「サービス名 公開鍵認証」などで検索すれば、おそらく情報がヒットすると思う(例えばこのように)ので、やりやすい・わかりやすい記事を見つけるなどしてなんとか実施してみてください……!

後者だけやってしまうとログイン手段がなくなってしまうため、必ずセットで実行します。

パスワード認証禁止に関しても先の記事で行なえます。 ただ、ポート変更に関しては次の項で行うので、ひとまず手を付けずにおいてください。

SSH接続のポートを変更する

鯖建て記事をご覧になった方であれば特にそうだと思いますが、SSHクライアントを使用してサーバーに接続し、操作を行っていると思います。

その際に使われるポート(サーバーへの接続経路というか、入り口のようなものです)がデフォルトでは22番なんですが……これは他のVPSでも基本的にはそうらしいので、攻撃者はまぁ間違いなく最初にこのポートを攻撃対象にするのだと思います。 わかりやすい入り口ですからね。

なので、このポート……入り口を変えよう!(ついでに22番は封鎖してしまおう!)というのが本項目の目的です。

設定を間違えると接続できなくなる可能性があるため、必ず「すでに接続が確立できている状態」をキープしつつ作業しましょう! タブ式で接続を切り替えられるといいと思います(私はRLoginを使っています)。

まずは以下のコマンドを入力します。

sudo vim /etc/ssh/sshd_config

設定ファイルが開くので、

#Port 22

と書かれた部分を探します。 通常のマウスクリックではカーソルが動かないので、矢印キーでカーソルの操作をします。 見つけたらAキーかIキーを1回入力すれば文字入力できる(Insert Modeになり、左下に-- INSERT --と表示される)はずです。

先程の文字列のところで改行し、SSH接続に使うポート番号を書きます。

SSH接続に使うポートは10001~65535の範囲で決めるのがいいのだとか。 この範囲内でご自由にどうぞ!

今回の例では、12345番を使うと仮定すると、こうなります。

Port 12345

できたら一度Escキーを押してInsert Modeを抜け、続いて:wqと入力します。 元のコンソール画面に戻ると思いますので、続いて以下を入力。

sudo systemctl restart sshd

これにより、先程編集した設定ファイルの内容が反映されますので、忘れずに実行しましょう。

さてこれで、今回の例で言えば今後12345番のポートを使ってSSH接続するように設定できましたが、まだこのままでは実際に接続することはできません。

続いて、今設定したポートを開放しましょう。

sudo ufw allow 12345

鯖建ての記事の手順を踏んだのであればufwが有効になっているはずなので、これが通るはずです。 文字列のとおり、これにより今回で言えば12345番のポートへの接続を許可しています。

sudo ufw reload

念のため、ここでufwを再読込しておきます。 これによって設定が反映されるはずです。

そしてここで一度、今の接続はそのままにした上で、今設定したポートで接続できるか試してみましょう。 (RLoginの場合)「ファイル」→「サーバーに接続」と進み、Server Selectウィンドウが出てきたら「編集」をクリックし、TCPポートの番号を22番から自分で決めたポート番号へ変更し、OKします。

これで接続できれば、SSH接続のポート番号の変更が完了し、接続もできるようになったことになります!

最後に、今度は使わなくなった22番ポートを塞ぐ必要があります。 が、今回はそんなに面倒な作業はありません。

sudo ufw deny 22
sudo ufw deny 22/tcp
sudo ufw reload

これでおそらくOKのはずです。 一度ここで再び、今の接続はそのままにした上で、22番で接続ができないことを確認してみるのもいいでしょう。 先程と同じ手順で行うのがいいですが、確認が終わったらSSH接続用ポートに接続設定を戻しておくのをお忘れなく。

念のため、ちゃんとポートの設定ができているか、ここで確認してみます。

sudo ufw status verbose

これを入力すると、現在のポートの開放状況などが一覧で出てきます。 今回設定したポートや22番ポートも表示されているはず。

最終的に自分が設定したSSH接続用ポートが“Allow”になっていて、22番が“Deny”になっていればOKです。

80番と443番はそれぞれHTTP接続とHTTPS接続で通常使うものなので、見覚えがない!と塞いでしまったりはしないようにしましょう。

これでSSH接続用のポート変更作業は完了です!

fail2banを導入しておく

本項目の内容は主に「vpsセキュリティ設定で絶対にやるべき6つのこと【乗っ取り注意】」を参考にしました。

fail2banは、規定回数SSH接続に失敗した場合、該当するIPアドレスを一定時間BANするというもので、記事によれば不正アクセスやDDoSに効果があるのだとか。 こうした攻撃は日々あちこちで発生しているのを見聞きしますし、少しでも防御力を高めるためにもやっておきましょう!

とはいえ、導入までは非常に簡単。 まずは以下のコマンドでインストールします。

sudo apt-get install fail2ban

またしてもピンク色の目と心臓に悪い画面が出てきたりすると思いますが、OK(Enterキー)で許可してインストール作業を行わせます。 終わったら、次のコマンドで起動。

sudo /etc/init.d/fail2ban start

特に問題がなければStarting fail2ban云々と出て起動するので、これだけでOKです! 手軽な割にありがたいですよね。

ちなみに、ログイン試行回数の上限(デフォルトは5回)やBAN期間(デフォルトは10分)などを設定ファイルを弄ることで変更できます。 より厳しくすることもできますが、うっかりログインに失敗しまくって自分がBANされないようには注意です……。

以下のコマンドで設定ファイルを開けます。 

sudo vim /etc/fail2ban/jail.conf 

私もすべての設定項目に目を通したわけではないですし、今のところデフォルト設定のまま使っていますが、とりあえず触るとしたら以下の部分をまずいじってみるのがいいかもしれません。

bantime = 10m

のBAN期間とか、

maxretry = 5

の再試行回数あたりが主な変更の余地がある箇所ですかね。 他にも色々とあるようですが、結構高度そうなものとかもあるので、より強固にしたい場合は翻訳しつつ頑張ってみてください……!

環境をアップデートする

ログインしてコンソール画面を開くと、アップデートがある場合はそれらしい文章で通知してくれます。 バグ・脆弱性の修正である可能性も高いので、時折アップデートしていきましょう。

場合によっては正常に動かなくなる(バージョンの不適合とか)可能性もあるといえばあるため、念のためバックアップ・スナップショットをとってからのほうがベターでしょう。

アップデート自体は以下のコマンドでできます(再起動も含みます)。

sudo apt update; sudo apt full-upgrade -y; sudo reboot

なお、アップデートしていくとそのうち「古くなってもう使われないもの」が出てくる場合があります。

これは残しておいてもストレージを無駄に消費し続けるだけなので、削除するのも手です……が、稀に必要なものを間違って削除してしまうこともあるらしいので、やっぱりこれもバックアップ・スナップショットの類をとってからやるほうがいいと思います。 こちらは頻繁に実行する必要もないでしょう。

コマンドは以下です。

sudo apt-get --purge autoremove

これで完璧!というものでは決してない

本当になんもわからん状態の私でもできることですし、最初のユーザーのPW変更の項目などは気休めというか……安心を得るためにやったみたいなところもあるので、そんなにセキュリティが強固になったとは言えないでしょう。

とはいえ、なにもしないよりは絶対いいですよね。 家を出るときは鍵を閉めるとか、長く空けるならガスの元栓締めたりなんだりするのと同じ。

気のせいレベルで、ほんの僅かだとしても平均的に環境の安全性底上げになれば……と思います。