サーバーにリモートログインできる通信規格「SSH」。そのSSHを司るサーバーがsshd。
リモートログインとは、外部からコンピュータを操作できる仕組みのこと。
これができると言うことは、もし、悪意ある人物がxianに侵入できた場合、
ネットワークを介してxianを破壊することも、また可能になります。
だからこそ、接続した相手が信頼に足る人物かどうかを決める
「ユーザー認証」が重要になってくるわけです。
ユーザー認証で最も基本となるのが、「パスワード認証」。
要するにユーザー名とパスワードを入力するやつです。It's basic.
しかし、パスワード認証には、こんな落とし穴が。。
`` xianに不正アクセスをかけてくる不届き者の図。
ここに挙げたログは全て不正アクセスを示すものです。
詳しい読み方は割愛しますが、赤色で囲まれた部分に注目してください。
このユーザー名でxianに不正アクセスを仕掛けてきた、という意味です。
見ての通り、適当な2文字を組み合わせたものを連続して送ってきています。
これが落とし穴。
つまりパスワード認証の場合、ユーザー名とパスワードを適当な文字を組み合わせて送り続ければ、
これが「パスワード・クラック」又は「ブルートフォース・アタック(総当たり攻撃)」と呼ばれる不正アクセスです。
(その他、辞書に載っている単語を片っ端からぶつけてくる、辞書攻撃、なんてのもあります。
ちなみに、この日やってきたアタックは辞書攻撃と呼ばれるものでした。)
でも、使える文字が、アルファベット24文字+数字10文字+記号=40文字強、
つまり、1文字のユーザー名であっても40以上のパターンがあるのに、
その中からランダムで選んでも当たりっこない、と思う方もいるでしょう。
そこがコンピューターとネットワークの恐ろしいところです。
確かに、xianがスタンドアローン(ネットワークに繋がっていない自立型)のシステムで、
shigenの家に来て直接操作しないといけない場合、
ランダムに組み合わせて手入力でアタックしてもラチがあきませんし、
きっと解除する前にshigenに見つかってしまいます。
ところが、疲れを知らないコンピュータなら何時間でも、何日でもその作業を続けることができます。
さらに、ネットワーク越しとなるとshigenは不正アクセスをしてきてる相手の所に行くこともできません。
ひょっとしたら、ネットワークの毎回変えて、こちらからは追えないようにしているかもしれません。
では、どのような対策を取るべきか。
そこで出てくるのが「公開鍵認証」という方式です。
詳しい話はこちらを読まれるか、調べられることをお勧めしますが、
あらかじめ、自分と認証したい相手に鍵を渡しておき、
その鍵を使うことでユーザー認証を行う仕組みのことです。
この方式ならば、パスワードクラックのような適当な組み合わせによる攻撃は事実上不可能となります。
(確かに、全く不可能というわけではありません。セキュリティに「絶対安全」は存在しないのです。)
と、いうわけで、ssh導入時からずっと行ってきた、鍵認証方式への移行が先ほど完了しました。
マニュアルに書いてあるとおりにしても、全く上手くいかず、ハマりまくっていました;;
最大の原因はPAM認証。PAM認証の詳しい仕組みは分かりませんが、こいつが有効になっていた為、
どんなにパスワード認証を禁止しても、PAM認証が適用され、事実上認証が可能になっていたようです。
sshdで鍵認証方式のみを使用する場合は、sshd_confに以下の設定を適用します。
PasswordAuthentication no ←パスワード認証をしない。
ChallengeResponseAuthentication no ←プレーンテキストによる認証をしない。
これで、SSHを堂々とネットに公開できる・・・はず。
リモートログインとは、外部からコンピュータを操作できる仕組みのこと。
これができると言うことは、もし、悪意ある人物がxianに侵入できた場合、
ネットワークを介してxianを破壊することも、また可能になります。
だからこそ、接続した相手が信頼に足る人物かどうかを決める
「ユーザー認証」が重要になってくるわけです。
ユーザー認証で最も基本となるのが、「パスワード認証」。
要するにユーザー名とパスワードを入力するやつです。It's basic.
しかし、パスワード認証には、こんな落とし穴が。。
`` xianに不正アクセスをかけてくる不届き者の図。
ここに挙げたログは全て不正アクセスを示すものです。
詳しい読み方は割愛しますが、赤色で囲まれた部分に注目してください。
このユーザー名でxianに不正アクセスを仕掛けてきた、という意味です。
見ての通り、適当な2文字を組み合わせたものを連続して送ってきています。
これが落とし穴。
つまりパスワード認証の場合、ユーザー名とパスワードを適当な文字を組み合わせて送り続ければ、
理論上、いつか解除できてしまうのです。
これが「パスワード・クラック」又は「ブルートフォース・アタック(総当たり攻撃)」と呼ばれる不正アクセスです。
(その他、辞書に載っている単語を片っ端からぶつけてくる、辞書攻撃、なんてのもあります。
ちなみに、この日やってきたアタックは辞書攻撃と呼ばれるものでした。)
でも、使える文字が、アルファベット24文字+数字10文字+記号=40文字強、
つまり、1文字のユーザー名であっても40以上のパターンがあるのに、
その中からランダムで選んでも当たりっこない、と思う方もいるでしょう。
そこがコンピューターとネットワークの恐ろしいところです。
確かに、xianがスタンドアローン(ネットワークに繋がっていない自立型)のシステムで、
shigenの家に来て直接操作しないといけない場合、
ランダムに組み合わせて手入力でアタックしてもラチがあきませんし、
きっと解除する前にshigenに見つかってしまいます。
ところが、疲れを知らないコンピュータなら何時間でも、何日でもその作業を続けることができます。
さらに、ネットワーク越しとなるとshigenは不正アクセスをしてきてる相手の所に行くこともできません。
ひょっとしたら、ネットワークの毎回変えて、こちらからは追えないようにしているかもしれません。
では、どのような対策を取るべきか。
そこで出てくるのが「公開鍵認証」という方式です。
詳しい話はこちらを読まれるか、調べられることをお勧めしますが、
あらかじめ、自分と認証したい相手に鍵を渡しておき、
その鍵を使うことでユーザー認証を行う仕組みのことです。
この方式ならば、パスワードクラックのような適当な組み合わせによる攻撃は事実上不可能となります。
(確かに、全く不可能というわけではありません。セキュリティに「絶対安全」は存在しないのです。)
と、いうわけで、ssh導入時からずっと行ってきた、鍵認証方式への移行が先ほど完了しました。
マニュアルに書いてあるとおりにしても、全く上手くいかず、ハマりまくっていました;;
最大の原因はPAM認証。PAM認証の詳しい仕組みは分かりませんが、こいつが有効になっていた為、
どんなにパスワード認証を禁止しても、PAM認証が適用され、事実上認証が可能になっていたようです。
sshdで鍵認証方式のみを使用する場合は、sshd_confに以下の設定を適用します。
PasswordAuthentication no ←パスワード認証をしない。
ChallengeResponseAuthentication no ←プレーンテキストによる認証をしない。
これで、SSHを堂々とネットに公開できる・・・はず。
習わない方がおかしいと言えばおかしいのか。
xianは総当たり攻撃と辞書攻撃の2大パスワード・クラックに遭遇したのが自慢です。(まぢか!)
習ったね。(自慢)
覚えてないけど。(自慢)