/etc/ssh/sshd_config では、公開鍵認証のみ可能にしてあります。
私の認識では、ファイアウォールの設定をしていないため、ポートスキャンはされ放題ですが、SSHのパスワードによるログインができないため、例えばブルートフォースアタック等でサーバが乗っ取られる可能性はかなり低いと考えています。
この状態で不正アクセスによるroot権限の乗っ取り、クラッキングによる破壊活動をされる手法はどれだけあるでしょうか？私はサーバ管理者としての経験が浅いため、どのような対策をすべきか熟知できておりません。可能性の列挙と、なぜ安全ではないか、という2つをできるだけたくさん教えていただきたいです。
なお、私が作るWebアプリケーションにバグ(例えばXSSやSQLインジェクション)はないものとして考えてください。主にサーバ設定における脆弱性を学びたいです。
よろしくお願いいたします。
No.4
966
247
50pt
/etc/ssh/sshd_config では、公開鍵認証のみ可能にしてあります。
公開鍵暗号認証のみ有効になっている状況であれば、ssh 経由で破られる事は無いと考えて良いです。
但し、条件はあります。
一つ目は、インストールしたまま放置しないで、ディストリビューションから提供されるアップデート（ソースからビルドしたなら、プロジェクトで公開される最新ソース）の適用をきちんと行うことです。これは、別に Linux に限った話では無いですが、これが基本です。
二つ目は、パスフレーズをきちんと使うことです。このパスフレーズの入力を回避する方法が紹介されていたりしますが、パスフレーズの入力が回避された状態というのは、秘密鍵の内容そのものが鍵ファイルに書かれていることになります。きちんとパスフレーズを使っていれば、万が一、秘密鍵のファイルが流出しても、秘密鍵自体がすぐに流出する事はありません。
また、パス「フレーズ」と言うように、十分に長い文字列を使う事が重要です。秘密鍵のパスフレーズを検証する、というのは、検証対象のデータが手元にあることになるので、ネットワーク越しで試すよりも、遥かに大量のパスフレーズを試す事が出来ることになります。最低でも８文字、10 文字以上であれば、ひとまず安全と言えます。８文字程度であれば、英数記号を織りまぜた、ランダムな文字列である事が求められますが、「フレーズ」（つまり「文」）と言えるような、長い文字列であれば、ランダムな文字列でなくても、例えば歌詞のワンフレーズで、どこかの文字を置換したり、余計な記号や文字を加える程度で大丈夫です。
意外に気がつかない人が多いのですが、パスフレーズ、パスワードを１文字増やすだけで、100 倍近く強度が上がります。その辺の話は、手前味噌ですが、下記のページが参考になると思います。
もし、１秒間に 1000 万回のパスワード照合が出来るとしたら - JULYの日記
...と、ここまでは、ssh の話だけです。
ファイアウォールの設定をしていないため、ポートスキャンはされ放題ですが、
ポートスキャンを受けること事態は日朝茶飯事なので、それ自体が問題では無いですが、問題は、外から接続可能になっているポートで待ち受けしているサービスが、きちんと管理されているか、という事になります。
例えば、外から SMTP でメールを受け取る必要が無いのに、アクセス可能な状態で放置されていたら、
といった事を気にする必要があります。でも、もともと外から接続を受けるつもりがないなら、はじめから繋がらない方が安全でしょ、ということで、FireWall の設定をしておく事に意味があります。
もし、外から接続される可能性のあるプログラムに関して、きちんと対策が出来る自信があれば、FireWall は必須では無いですが、FireWall で絞っておけば、気をつけなければいけない点を絞る事ができます。
この状態で不正アクセスによるroot権限の乗っ取り、クラッキングによる破壊活動をされる手法はどれだけあるでしょうか？
もし、アップデートを怠っていれば、数えられなくらいの手法はあります。
一般に、完全に root 権限を乗っ取るには、
の２つの脆弱性が利用されます。
いきなりリモートから root が取れる脆弱性、というのは、最近は見ませんが、ローカルユーザの権限上昇を引き起こす脆弱性は、今でも見つかる事があります。
上記ページは、今年の４月４日に出た、Redhat Enterprise Linux の glibc に関するアップデートですが、文中に権限上昇の脆弱性があった事が書かれています
A local attacker could use this flaw to escalate their privileges via a setuid or setgid program using such a library. (CVE-2011-0536)
ざっくり訳すと「このようなライブラリを使った setuid または setgid プログラムを使って、権限を上昇させる為に、この欠陥を使う事が出来た」といった事が書かれています。
もっとも、その権限上昇を引き起こすための条件が複雑で、デフォルトの状態だと大丈夫というケースも多いですが、全く出来ない訳ではありません。
もちろん、こういった脆弱性が見つかればアップデートが出るので、そのアップデートをきちんと適用していくことが肝心です。
No.1
85697
30pt
ポートスキャンはされ放題ですが
かなり危険な状態です。
telnetが動いていれば簡単に乗っ取られるでしょうし、ftpdやhttpdが動いていればそこから侵入される可能性もあります。
また、DoS攻撃されるかもしれません。
さらに、内側（ローカル端末）から攻撃される可能性はありませんか？
実践的で役に立つ参考書をご紹介しておきます。
No.3
1099132
15pt
＞不正アクセスによるroot権限の乗っ取り、クラッキングによる破壊活動をされる手法はどれだけあるでしょうか
Linuxカーネルの脆弱性などを狙われたら終わりです。
＞ファイアウォールの設定をしていないため、ポートスキャンはされ放題ですが
最低限、どこもがやってることはしてないとかなり危険としかいえない。
何の対策もしてないと、外部から情報を取得できるわけですから、狙われやすいでしょう。
No.4
966247
ここでベストアンサー
50pt
/etc/ssh/sshd_config では、公開鍵認証のみ可能にしてあります。
公開鍵暗号認証のみ有効になっている状況であれば、ssh 経由で破られる事は無いと考えて良いです。
但し、条件はあります。
一つ目は、インストールしたまま放置しないで、ディストリビューションから提供されるアップデート（ソースからビルドしたなら、プロジェクトで公開される最新ソース）の適用をきちんと行うことです。これは、別に Linux に限った話では無いですが、これが基本です。
二つ目は、パスフレーズをきちんと使うことです。このパスフレーズの入力を回避する方法が紹介されていたりしますが、パスフレーズの入力が回避された状態というのは、秘密鍵の内容そのものが鍵ファイルに書かれていることになります。きちんとパスフレーズを使っていれば、万が一、秘密鍵のファイルが流出しても、秘密鍵自体がすぐに流出する事はありません。
また、パス「フレーズ」と言うように、十分に長い文字列を使う事が重要です。秘密鍵のパスフレーズを検証する、というのは、検証対象のデータが手元にあることになるので、ネットワーク越しで試すよりも、遥かに大量のパスフレーズを試す事が出来ることになります。最低でも８文字、10 文字以上であれば、ひとまず安全と言えます。８文字程度であれば、英数記号を織りまぜた、ランダムな文字列である事が求められますが、「フレーズ」（つまり「文」）と言えるような、長い文字列であれば、ランダムな文字列でなくても、例えば歌詞のワンフレーズで、どこかの文字を置換したり、余計な記号や文字を加える程度で大丈夫です。
意外に気がつかない人が多いのですが、パスフレーズ、パスワードを１文字増やすだけで、100 倍近く強度が上がります。その辺の話は、手前味噌ですが、下記のページが参考になると思います。
もし、１秒間に 1000 万回のパスワード照合が出来るとしたら - JULYの日記
...と、ここまでは、ssh の話だけです。
ファイアウォールの設定をしていないため、ポートスキャンはされ放題ですが、
ポートスキャンを受けること事態は日朝茶飯事なので、それ自体が問題では無いですが、問題は、外から接続可能になっているポートで待ち受けしているサービスが、きちんと管理されているか、という事になります。
例えば、外から SMTP でメールを受け取る必要が無いのに、アクセス可能な状態で放置されていたら、
といった事を気にする必要があります。でも、もともと外から接続を受けるつもりがないなら、はじめから繋がらない方が安全でしょ、ということで、FireWall の設定をしておく事に意味があります。
もし、外から接続される可能性のあるプログラムに関して、きちんと対策が出来る自信があれば、FireWall は必須では無いですが、FireWall で絞っておけば、気をつけなければいけない点を絞る事ができます。
この状態で不正アクセスによるroot権限の乗っ取り、クラッキングによる破壊活動をされる手法はどれだけあるでしょうか？
もし、アップデートを怠っていれば、数えられなくらいの手法はあります。
一般に、完全に root 権限を乗っ取るには、
の２つの脆弱性が利用されます。
いきなりリモートから root が取れる脆弱性、というのは、最近は見ませんが、ローカルユーザの権限上昇を引き起こす脆弱性は、今でも見つかる事があります。
上記ページは、今年の４月４日に出た、Redhat Enterprise Linux の glibc に関するアップデートですが、文中に権限上昇の脆弱性があった事が書かれています
A local attacker could use this flaw to escalate their privileges via a setuid or setgid program using such a library. (CVE-2011-0536)
ざっくり訳すと「このようなライブラリを使った setuid または setgid プログラムを使って、権限を上昇させる為に、この欠陥を使う事が出来た」といった事が書かれています。
もっとも、その権限上昇を引き起こすための条件が複雑で、デフォルトの状態だと大丈夫というケースも多いですが、全く出来ない訳ではありません。
もちろん、こういった脆弱性が見つかればアップデートが出るので、そのアップデートをきちんと適用していくことが肝心です。
No.5
17314
30pt
FWの設定をしない場合ですが、
SSHやSSLのバージョンは大丈夫でしょうか。
旧バージョンでは大きな脆弱性などが発見されているため、アタックされてSSHが使えるようになる場合もあります。
SMTPポートが不正アクセスされると
迷惑メールの踏み台とかにされると、他の方にも迷惑がかかりる可能性があります。
FTPでもある程度コマンドが実行できるので、大切なファイルやセキュリティ設定のファイルが
書き換えられたり、壊されたりする場合もあります。
考え方として、サーバー製品、OpenSSLやOpenSSH,sendmailやapache等の製品自体がそもそも完璧では
ないので、セキュリティ上問題が発生する危険は常に残っています。
そのため使わないポートは閉じるか制限をかけておく。と言う考え方が良いと思います。
あと、ポートスキャンやDOS攻撃によって乗っ取られないまでも、サーバーやネットワークの負荷が高くなりすぎて
サーバーにアクセスできない。という状態にもなります。
それにより、ある日出社したらサーバーがダウンしてたり、NICが壊れてたりという事もありました。
実際どれが、どれくらい危険性があるか。という点については、
http://jvndb.jvn.jp/search/index.php?mode=_vulnerability_search_...
ここでお使いのOSやサーバーソフトウエアを検索して、
攻撃区分がネットワークとなっているものがそれにあたります。
沢山ありすぎて、全部洗い出すのは大変かと思いますし、
また、日々未知の脅威の数は増え続けています。
散々DOSでネットワーク過負荷をかけられたあげく、サーバーダウンして、再起動したら
バックドア仕込まれて、root権限とられて。。。
となった場合に、これらのワームやウィルスを除去したり、奪取されたrootパスワードを復旧するだけでも
大変な作業になります。
私はソフトウエア開発の傍らで片手間でサーバー管理をしてきた半端管理者ですが、
当初は安易に考えすぎていて非常に余計な時間を浪費してきたと思っていますので、
セキュリティは金額をかければ際限ないので
ベストはなかなかありませんが、今予算と労力の範囲で出来ることを実施されることをオススメいたします。
せめて、iptablesなどを使ってFWを設定されることを強くオススメします。
SSHもアクセスできるIPアドレスを絞り込んでおいた方がよいです。
No.6
11310
15pt
> SSHのパスワードによるログインができないため、例えばブルートフォースアタック等でサーバが乗っ取られる可能性はかなり低いと考えています。
>この状態で不正アクセスによるroot権限の乗っ取り、クラッキングによる破壊活動をされる手法はどれだけあるでしょうか？私はサーバ管理者としての経験が浅いため、どのような対策をすべきか熟知できておりません。可能性の列挙と、なぜ安全ではないか、という2つをできるだけたくさん教えていただきたいです。
前提にする条件って必ずしも成立するとは限らないのですよね。その事を考えないと前提が崩れていた場合には………。攻撃する者はそんな事を前提にしてはくれません。
他の手段でsshで使っているサーバの暗号キーコピーされちゃうとパケット覗き見で復号した通信内容見れますしね。
ソフトの更新はどの様に行っているでしょう。
典型的な公開迄の流れは、
1. 脆弱性かもって現象に遭遇した者がどこかのコミュニティで相談。
2. 脆弱性の可能性が高いという事でオフィシャルサイトに報告。(例えばopensshの開発チーム)
3. 内容を検討
4. 必要なら対策(実装の議論なども含めて)
5. オフィシャルサイトでの公開
6. 使用ソフトでの対策(Linuxディストリビュータ・各種OS開発グループ・ソフト作者・……)
7. 使用ソフトでの公開(Linuxディストリビュータ・各種OS開発グループ・ソフト作者・……)
という感じだと思いますが、1の段階から公開情報を見ての攻撃可能性はあります。(独自に解析を含めると………)
しっかり対応する人だとオフィシャルサイトでの検討の段階から内容次第である程度の対策を施すと思います。
※たまたま、1で知るという事もあったりする方も少しはいらっしゃる。
ディストリビュータから更新パッケージが配布される前にオフィシャルサイトで更新内容を取得して自身で反映できる様になればより早く安全な状態に更新できるかも。
例えば、あるソフトでセキュリティ上の問題を修正する更新ソフトが公開された時にそれを反映しますか。
無条件で反映する方もいらっしゃりますが、十分検討して反映を見送る場合もある様ですよ。
※『サーバ設定における脆弱性を学びたい』なら、議論が理解でき適した方法を選べる様に様々な知識を得ておく必要がありそうですよ。
まぁ、範囲を制限しなければ色々なソフトやハードが問題になります。
例えばssh以外のTCP/IPサービスも含めるのか、使っているハード(BIOSの更新やNetCardファームウェアの更新、ルータの制御ソフトの更新など)も含めるのか。そんなところでもセキュリティ上の問題があり更新される場合はありますし。
※例えば暗号化方式xxxは安全でないとされる様になったのでyyyを使える様にネットワーク機器aaaのファームウェアを公開しますとあれば色々変える必要がでてきたりしますしね。(基本使っている機器全ての情報を見ておく必要がある)
9
7
2
1
1
コメント（0件)