はじめに

この記事は,SLP_KBIT Advent Calendar 2016,25日目の記事です.
恐ろしい話で,クリスマスですね.
鳥さんとか,ケーキは食べましたか?
サンタさんから,贈り物はきましたか?
食べてない?来てない?大学に居た?なるほど.

この記事は何

この記事では,隣国のC国などのサンタさんが,非常に素敵な贈り物をしてくれるので,
それに対策する話をしようと思います.
というか,対策をしようとしている話をしようと思います.

んで,何の話よ

素敵な贈り物とは,ズバリ,サーバへの攻撃です.
最近,VPSを借りてみたのですが,攻撃って怖いなあと,
身をもって知る羽目になったので,この記事を書くことにしました.
この記事は,SSHサーバの設定と,不正ログインの足跡を見つけることを主眼に置きます.

ほそぼそしたサーバでも

例えば,SSHの認証リクエストとかが,
毎日何百件と,飛んでくるわけです.
それも,知らない人から.恐ろしい.
最悪の場合,パスワードを抜かれる…なんて事態もあり得るわけです.

…インターネッツ,オソロシイコ

あの手この手で攻めてくる

一般に,サーバは,稼働している限り,あの手この手で攻め込まれます.
以下は,攻撃の一例です.なんとなく知っている人は,読み飛ばし推奨.

ブルートフォース・アタック

総当り攻撃と訳されます.
文字通り,パスワードを,あらゆる組み合わせで試して,認証を試みます.

ディクショナリ・アタック

辞書攻撃と訳されます.
ブルートフォース・アタックでは,総当りでパスワードを試行するので,
例え,パスワードが,一般的には既知の文字列でも,認証までに時間がかかります.
その対策として,既知である文字列を辞書として構成し,
その辞書にある,フレーズで認証を試みます.

DoSアタック/DDoSアタック

DoSアタックとは,サーバに対して,意図的に,過剰な負荷を掛けることで,
サーバをダウンさせることを目的とします.
例えば,F5アタックなんかも,DoSアタックの一つだと言えます.

DDoSアタックは,これが分散型になり,複数のホストから
負荷を掛ける攻撃です.

SQLインジェクション

脆弱なWebサイトに対して,悪意のあるSQL文を,Webブラウザ経由で送信し,
データベースの中身を盗み見たり,改ざんしたりしようとする攻撃です.


と,ここでは,4つだけ取り上げましたが,これはほんの一例です.
クロスサイトスクリプティングや,セションハイジャック,
ディレクトリトラバーサルなどなど,攻撃の手法は多岐に渡ると言われています.
ただし,サーバを運用する以上,このような攻撃に屈するわけにはいきません.
自分や,自分の組織の情報を失う・流出させることはおろか,
最悪の場合,先述の,DDoS攻撃の踏み台にされるなど,
他人の迷惑にもなりかねない危険があるからです.

実際に,どのような攻撃が?

いまから示すのは,実際に,私が受けた攻撃です.
IPアドレス等は非開示とします.

まず,SSHへのログイン試行を調べてみます.
試行されたログは,Linux系のOSであると,
/var/logに記録されます.Debianだと,この中の,auth.logとして,記録されます.
実際に覗いてみましょう.

Dec 16 07:07:53 ${hostname} sshd[XXXX]: Failed password for root from ${攻撃者IPアドレス} port ${PORT} ssh2
Dec 16 07:07:55 ${hostname} sshd[XXXX]: Failed password for root from ${攻撃者IPアドレス} port ${PORT} ssh2
Dec 16 07:07:57 ${hostname} sshd[XXXX]: Failed password for root from ${攻撃者IPアドレス} port ${PORT} ssh2
Dec 16 07:07:57 ${hostname} sshd[XXXX]: fatal: Read from socket failed: Connection reset by peer [preauth]
Dec 16 07:07:57 ${hostname} sshd[XXXX]: PAM 4 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=${攻撃者IPアドレス}  user=root
Dec 16 07:07:57 ${hostname} sshd[XXXX]: PAM service(sshd) ignoring max retries; 5 > 3
Dec 16 07:07:58 ${hostname} sshd[XXXX]: error: Could not load host key: /etc/ssh/ssh_host_edXXXXX_key
Dec 16 07:07:59 ${hostname} sshd[XXXX]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=${攻撃者IPアドレス}  user=root
Dec 16 07:08:01 ${hostname} sshd[XXXX]: Failed password for root from ${攻撃者IPアドレス} port ${PORT} ssh2
Dec 16 07:08:03 ${hostname} sshd[XXXX]: Failed password for root from ${攻撃者IPアドレス} port ${PORT} ssh2
Dec 16 07:08:05 ${hostname} sshd[XXXX]: Failed password for root from ${攻撃者IPアドレス} port ${PORT} ssh2
Dec 16 07:08:08 ${hostname} sshd[XXXX]: Failed password for root from ${攻撃者IPアドレス} port ${PORT} ssh2
Dec 16 07:08:10 ${hostname} sshd[XXXX]: Failed password for root from ${攻撃者IPアドレス} port ${PORT} ssh2

恐ろしい話ですが,たった,数十秒の出来事です.
最強の権限を持つアカウントである,rootにアクセスしようとしています.
これだけ,アタックされます.ちなみに,攻撃者のIPアドレスをwhoisで調べたところ,
隣国のC国からのアクセスでした.

更に,
sudo cat /var/log/auth.log | grep Failed | cut -d " " -f 11 | sort | uniq
として,SSHのログインに失敗したIPアドレスだけを抽出します.
調べてみるとわかることですが,やっぱり隣国nげふんげふん.

では,どうするのか

流石に対策をせねばなりません.
この記事では,主に,不正なログインの足跡を見つけること,
SSHを安全に運用するために,最低限やっておきたいことに主眼を置きたいと思います.

不正なログインはされていないか

まず,自サーバが,SSHで,不正ログインされていないかを確認します.
lastコマンドを利用します.これを用いると,
どのホストから,どのアカウントに対してログインが行われ,
誰がログイン中か,確かめることができます.
なお,不正ログインが確認されたら,即座にpasswdを行い,
パスワードを変更するなど,対策を取ってください.

SSHでrootにログイン出来ないようにしておく

root権限は,Linux系OSで,サーバを運用する以上,
最も奪われたくない,アカウントです.
そのため,rootに関しては,SSHでログインを出来ないようにしておきます.

Debianでは,sshサーバの設定ファイルは,
/etc/ssh/sshd-configとなっています.
この中の,
PermitRootLogin yesを,PermitRootLogin noに変更しておきます.
これにより,rootでのログインは無効になります.
sudo /etc/init.d/ssh restartでsshサーバを再起動して,変更を適用します.

SSHのパスワード認証を無効にしておく

パスワードを認証の方法にしている以上,ブルートフォース・アタックや,
ディクショナリ・アタックの脅威からは逃れられません.
そのため,原則として,公開鍵暗号方式を用いた,公開鍵認証を利用して,ログインするようにします.
例えば,ConoHaVPSでは,コンソールは,Webブラウザから利用できるものが用意されているので,
SSHでパスワード認証できなくなったとしても,パスワード認証を有効にして脅威に晒されるのに比べたら,
マシなわけです.

というわけで,設定をしてみましょう.

ホスト側の設定

まず,ホスト側で,ssh-keygenを実行します.
これは一回だけです.~/.sshが存在する場合,やってはいけません.
ssh-keygenを実行すると,~/.ssh直下に,RSA暗号方式に基づいた,
公開鍵(id_rsa.pub)と秘密鍵(id_rsa)が生成されます.
今回は,id_rsa.pubを利用します.

サーバ側の設定

ホスト同様に,ssh-keygenを実行します.
~/.sshができるので,直下に,autholized_keysファイルを作成します.
この中に,ホスト側で生成した,id_rsa.pubの内容をコピーしてください.

更に,sshd-configを書換えます.
PasswordAuthentication yesとなっているところを,PasswordAuthentication no
に書換えます.このことで,パスワード認証が無効になりました.
しかし,PubkeyAuthentication yesとなっていれば,公開鍵認証は行うことができるので,
ひとまず,ブルートフォース・アタックなどの脅威からは,身を遠ざけることができました.

SSHのポートを変更する

SSHのポートは,標準では22番を利用することになっています.
つまり,22番を狙えば,攻撃しやすい,ということになってしまいます.
このような事態を避けるために,SSHが利用するポートを変更します.
先程に続いて,sshd-configを編集します.

# What ports, IPs and protocols we listen for
Port 22

# What ports, IPs and protocols we listen for
Port ${任意の空きポート}

とします.ログインするときは,
ssh hoge@hoge.com -p ${任意の空きポート}
のようにすれば大丈夫です.

おわりに

今回は,最低限,攻撃からサーバを守る方法を紹介しました.
ここに紹介したのは,ほんの一例です.ちゃんと対策は講じましょう(自分への戒め)

それでは,残り時間少ないですが,楽しいクリスマスを!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です