« cocologのメンテが終わったらしい | トップページ | エンジニア都市伝説 »

2007.04.05

SSHのセキュリティを高めるためのハウツー

SSHのセキュリティを高めるためのハウツー

SSH経由のログインを特定のユーザーにだけ許可するという所に

SSH経由でのrootログインは不必要であり、大きなセキュリティリスクにもなるため許可するべきではない。
とある。
これはある種常識として言われている事だけど、本当だろうか?
というか、金科玉条のように「rootログインはイケナイ」と言われているだけで、rootログインを許した場合のリスク(メリット)/rootログインを許さなかった場合のリスク(メリット)に付いてはあまり語られていないような気がする。

それではまず必要性の方から考えてみると、たとえばデータのバックアップを取る時、「各ユーザの責任で各自取りなさい」という事であれば問題無いけど、サーバ丸ごとバックアップを取る場合にはroot権限が必要になる。
各サーバにそれぞれローカルにバックアップ用HDD等を付けて、そこにそれぞれバックアップを取るのならSSH接続は必要無いだろうが、サーバ台数が数十台とか100台規模以上になるとそれも現実的ではない。
一台、あるいは数台のバックアップ用機を用意して、そこから各サーバのバックアップを取るという運用が行われている場合も多いのではないだろうか。
そういう場合、やはり各サーバへバックアップ機からrootログインできる必要がある。

これはあくまでも一例だけど、他にも他機と連携して何かしなくてはいけないような場合にrootログインできる必要もあるだろう。

次にリスクの方を考えてみる。

まずパスワードでのログインを許す場合、rootでのログインを許さないようにしておけば、一般ユーザのパスワードをクラックした上でrootパスワードもクラックしなくてはいけないから、コストは2倍になる(リスクは半分になる)。
ただし、これはパスワードをブルートフォースなど強引な方法で解析する場合の話で、頻繁にsuするようなユーザを乗っ取って、キーロガーなどを仕掛けてしまえばrootパスワードのクラックに必要なコストは非常に小さくなる。
システムワイドなキーロガーであればroot権限が必要だが、クラックしたユーザのキーだけを盗めば良いのであれば、そのユーザの権限があれば十分。

他にも色々やりようはあるだろうが、パスワードでのログインを許しながらrootでのログインができないようにする一番大きなメリットは、固定IDの"root"ではなく、任意文字列のユーザIDを推定して(あるいは探して)パスワードのブルートフォースアタックをかけなくてはいけないという事で、パスワードが二重になるというのはメリットとしては小さいだろう。

次にパスワードでのログインを許さない場合だけど、とりあえず現時点ではRSA/DSAキーはブルートフォースアタックに対しては十分に強いとされている。
今後何らかの脆弱性がみつかったり、CPUパワーなどが上がってブルートフォース可能になるという事はあり得るけど、現時点ではブルートフォースというのは可能性が十分に低いと仮定する。
すると、一般ユーザであれrootであれ、乗っ取られる可能性というのは、秘密鍵が流出した場合という事になる。

それが一般ユーザの秘密鍵であっても、それがsuする事の多いユーザであれば上述したようにブルートフォースより低コストでrootパスワードを取得できる可能性がある。
一旦一般ユーザで入れさえすればrootパスワードの入手が低コストでできるのであれば、rootログインできてもできなくても「大きなセキュリティリスク」という程の差は出ない。
(もちろんrootになれてしまうというのは大きなセキュリティリスクだけど、直接rootでログインするのと一旦一般ユーザでログインしてからsuするのに有意なコスト差が無いのであればセキュリティリスクとしてはたいした違いは無い)

「パスワードが二重にかかってるから安全性が高い」というのはキーロガーなどが無く、root kitのような仕込みを見せなくする仕組みが十分に発展していなかった牧歌的な時代の常識であって、現在では一つ破られればシマイと思っておくべきだろう。

また、suしないユーザであってもブルートフォースでrootパスワードをクラックする事もできるから、パスワードでのログインができないようにしていても、セキュリティレベルはパスワードでログインできる場合と同等となってしまう。

このように考えた場合、パスワードでのログインができない(RSA/DSA鍵によるログインのみ許す)場合、rootでログインできてもできなくても、セキュリティリスクはそれ程大きな差はない。
むしろ、rootログインを許してsuしないようにしておけば、該当サーバ上でパスワードを打つ必要が無いから、キーロガーなどへの耐性が高まるし、多数のサーバを擁している場合、全部のrootパスワードが一緒というのは論外にしても、何らかの法則性がある場合にパスワードを推定される手がかり(何文字程度とかどういう文字種を使っているかというのも大きな手がかりとなる)を与えずに済むというメリットもある。

上で「現在では一つ破られればシマイ」と書いたが、suしないような運用にしておけば、影響範囲を局所化できる場合もある。
たとえば一般ユーザアカウントはどこからでもアクセスできるけど、rootユーザはauthorized_keysのfromで社内LANからしか(localhostやDMZも含めて)アクセスできないように制限しておけば、秘密鍵が流出してもrootまでは取られないという運用が可能な場合もあるだろう。

あくまでも「パスワードでのログインができない」という条件下に限れば、rootでログインできる/できないというのは一長一短で、どちらかが格段にリスクが大きい/小さいという事は無いのではないだろうか。
盲目的に「rootログインはイケナイ」と考えるのではなく、許した場合のリスク(メリット)と許さない場合のリスク(メリット)を考える必要があると思う。

あと、記事の2ページ目公開鍵認証を使用するというのがあるが、ここに書かれている事に加えてUsePAMも確認しておく必要がある。
UsePAM yes
となっていると、パスワード認証しないようにしたつもりでもPAM経由でパスワード認証されてしまう。

|

« cocologのメンテが終わったらしい | トップページ | エンジニア都市伝説 »

パソコン・インターネット」カテゴリの記事

コメント

ほほー。
自分の知る限りじゃ一般ユーザでログイン→suとさせる企業が多いですね。
まあ私が繋ぐのはあくまで開発用サーバで、本番システムとは独立してると
思いますけど…。

投稿: yoh-yoh | 2007.04.06 08:31

>yoh-yohさん
上でも書いたように、パスワードでログインできる環境であれば、既知のIDである"root"でのブルートフォースを防ぐという意味で有効だと思いますよ。

ただ、そういう「rootでログインしてはいけない理由」を考えずに、ただ「rootでログインはダメ」というだけではダメでしょという話で・・・
「rootでログインしてはダメだから、rootでのログインは止めてsudoersにALL=(root) NOPASSWORD:ALLと書け」
とか書いてあるページを見てズッコケたという話もありますが(^^;何のために、何を守ろうとしてそういう設定をしているのかを理解しないと、全然安全になんかならないんじゃないかなと・・・

投稿: <セルダン> | 2007.04.06 20:09

ちゃんと頭使って、ケースバイケースで適切な方法を考えろってことですね、
たしかに。 (^^;

投稿: yoh-yoh | 2007.04.08 00:51

>yoh-yohさん
ま、まとめてしまうとそういう事ですかね(^^;

そもそも、この「rootでログインできるのはダメ」が言われ始めたのって、接続にtelnet使って、ネットワークも10BASEで同軸接続orダムHUB接続という時代なんですよね。
今からして思えば、「そんなのパケットキャプチャすればパスワードなんかダダ漏れじゃん」という事になるんですが、そういう事は一般的には考えられていなかった時代です。
そういう時代にできた「常識」が、現在の環境でどこまで通用するのか、どこが単なる都市伝説(^^;なのかという再評価をちゃんとすべきじゃないかなぁと・・・

投稿: <セルダン> | 2007.04.08 02:22

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/4003/14570595

この記事へのトラックバック一覧です: SSHのセキュリティを高めるためのハウツー:

« cocologのメンテが終わったらしい | トップページ | エンジニア都市伝説 »