Fedora、rootユーザーによるsshパスワードログインのデフォルト無効化を検討開始 48
ストーリー by hylom
結局手動でいつも変えるんだよね 部門より
結局手動でいつも変えるんだよね 部門より
headless曰く、
Fedoraは今秋リリースのFedora 31に向け、rootユーザーによるsshパスワードログインをデフォルトで無効化すべく検討を開始したようだ(Phoronix、Fedora Wiki、develメーリングリストのスレッド)。
OpenSSHでは2015年からrootユーザーのパスワードログインをデフォルトで無効化しているが、Fedoraはデフォルト設定を変更してパスワードログインを許可し続けていた。しかし、Linuxのrootログインは攻撃者に狙われやすい部分であり、パスワードはその弱点となっている。Fedoraがパスワードログインを許可し続けてきたのにはさまざまな実用的な理由があるものの、OpenSSHのデフォルトとの違いが許容できない段階に達しており、ユーザーの期待するデフォルト設定にも反するため変更が必要になったとのこと。変更後も公開鍵認証やGSS-API認証は影響を受けない。
一方、この設定に依存するものも多く存在するため、対策の検討も必要となる。最終的にはFedora Engineering Steering Committee(FESCo)での採決が必要になるが、develメーリングリストで強い反対意見は出ておらず、Fedora 31ではrootユーザーのsshパスワードログインがデフォルト無効になる可能性が高いとみられている。
もうこれを機に (スコア:0)
root自体とかrootのパスワードをなくすとか…他はやってるんだし。
それ逆に危険だよね (スコア:1)
sudoは操作ミスで致命的な事態になるのを防ぐにはいいんだけどセキュリティ的には問題ありすぎる
sudoできるアカウント(非root)が乗っ取られたらsudoコマンド自体が不正なものに書き換えて、入力されたパスワードをクラッカーに送信するように改変できる
あとはクラッカーがその乗っ取ったアカウントにログインして入手したパスワードでsudoすればroot権限で任意のコマンドが実行可能
sudoできるアカウントを乗っ取ったら事実上rootを奪えるので、rootになれるアカウント(sudoできるアカウント)が増える分だけリスクが高まるといえる
Re:それ逆に危険だよね (スコア:2, 参考になる)
ほんとそれ、そのへんの権限周りで他の良い方法が出来ないかなぁ
sudoコマンド自体が不正なものに書き換えて、入力されたパスワードをクラッカーに送信するように改変できる
ただこの表現だとわかってない人は「どうやってrootの所有のファイル/usr/bin/sudoを書き換えるんだよw」みたいな勘違いした反応がありそう
要は本物のsudoの実行ファイル自体はそのまんまでも各ユーザーが陥落した時点でそのユーザーのホームに偽sudoバイナリ置いてPATHいじるなりシェルのaliasなりで偽のsudo使うようにできちゃうのよね
んでそれに気づかずに偽のsudoにパスワード入力しちゃってrootの権限がウンタラカンタラって
Re: (スコア:0)
sudo できるアカウントって、 Windows で言うところの Administrators グループのユーザみたいなものだから、
乗っ取られるような運用している時点でだめなんじゃないですかね?
Administrators グループの権限で cmd.exe 置き換えられる!って騒いでるような感じ?
Re: (スコア:0)
そんな感じだけど、Windowsの場合UACが有るからねぇ……
UACの確認画面はすり替える意味すら無いのだけど、
それと同等の安全確保がsudoには無いってのがキモかな。
# あとコマンドすり替えはsuでも怖い。
ログイン等にCTRL+ALT+DEL使うようなプロテクトがCUIでは困難、てのがな……
まぁUACにしても予め特権を得た際に実行する処理を決めておいて、
確認画面が出るような操作の際に正規の操作の代わりにそっちの処理でUAC承認取れば攻撃は出来るんだが。
Re: (スコア:0)
UACはさまざまな手段でバイパス可能で、MSはそもそもセキュリティ機能ではないから仕様って言ってるじゃん。すり替えだったらカレントディレクトリが勝手に検索されて無効にできないし実行可能パーミッションに存在するものがあるにはあるけどまったく運用されていないも同然のWindowsのほうが圧倒的に簡単だ。
Re: (スコア:0)
特権の利用可否を問うダイアログを表示するに当たり通常外のコンソールに切り替える機能があるか否かってだけの話なんで。
最終的な安全の話に持っていってまで反論してもそこに意味はないですよ。
単方向でテキストのストリームでコンソール出せる以上、致し方の無い仕様なんだから素直に諦めときなさい。
Re: (スコア:0)
例えば、攻撃者が runas.exe 置き換えて外部にパスワード流すようにしていたら
sudo 置き換えられたのと何も変わらんわ
UAC が表示されたってそれが正規の操作中に起きた内容ならなんも気づかないでしょ
sudoers や Administrators グループのユーザ取られた時点でアウトだよ
Re: (スコア:0)
元コメの最後二行がその手のリスクの話なんだが。
特権の利用に専用のコンソールが入る事で攻撃に制限が生じるって話であって完全な防御って話では無い。
Re: (スコア:0)
2段階認証sudoとか?
携帯電話やスマホにセキュリティコードのメールが飛んでくるみたいな。
Re: (スコア:0)
それLinuxのディストリに実装するの?いやFedoraならやってくれるはず!
Re: (スコア:0)
PAM の sudo に google authenticator とか設定すれば良いんじゃないの?
ubuntu では出来ていたような記憶があるけど、Fedora でも似たような感じじゃないかな・・・
Re: (スコア:0)
通常使用するアカウントはsudoできないようにして、sudo専用アカウント作ればいいんじゃない。
そもそもsudoできるアカウントをばらまくから問題なのでは。
Re: (スコア:0)
sudo専用アカウントがばらまかれるだけかと。
Re:それ逆に危険だよね (スコア:1)
その必要があるなら、もし sudo 使ってなかったら、 かわりに root のパスワードがばらまかれるだけでは?
Re: (スコア:0)
sudoじゃないユーザで通常作業
sudoできるアカウントで管理作業
・・・って普通じゃないの?
rootのパスワードなんて必要ないよね?
Re: (スコア:0)
sudoめんどくさー
sudoは悪い文化 (スコア:0)
すべからく滅ぶべし
Re: (スコア:0)
すべからく警察だ
今さらか (スコア:0)
今さらというか、ようやく対応ですね。
遅くてもやらないよりはマシ。
日本の運用だとかえって危険になる気がする (スコア:0)
sshパスワードログインって、エンジニアでも、パスワードが平文で流れるとか、中間経路でのなりすまし攻撃に弱いといった勘違いをしている人がいるけど、そんなことはないです。
パスワード認証だろうと通信自体は暗号化されるし、なりすまし攻撃はサーバの公開鍵のフィンガープリントの確認で防げます(普通のSSHクライアントは信頼済みでないフィンガープリントなら確認画面がでます)。
つまり、ブルートフォースアタックに弱いだけですので、「j9FJ:45F4:mMFa」ぐらいの強度のパスワードなら何の問題もなかったわけです。
多くの組織の場合、パスワードの前半部分をメモして担当者の手帳と会社の金庫に入れておき、後半部分は他の記憶させる(他のパスワードなどとも使いまわしだったりするが)などの安全対策をしているはずです。
パスワード漏洩=危険 は分かりやすいですから、多くの組織ではそれなりの管理になるわけですね。
一方、これが公開鍵認証になると、秘密鍵をUSBメモリに入れておく、終業時には金庫に入れるといった運用になり、物理的に泥棒が入ったらアウトです。下手したら面倒になってデスクに放置されたり、担当者が出先で落としたりするリスクもあります。更に酷いと操作用のノートPCにコピーされるかもしれません。
秘密鍵自体を暗号化してパスフレーズで保護するといったこともSSHクライアントによっては可能ですが、OpenSSH標準ではないですし、しない人も多いでしょう。
秘密鍵をパスフレーズで保護しない限り、パスワード認証よりかえって脆弱になるといえます。
Re:日本の運用だとかえって危険になる気がする (スコア:2)
sshパスワードログインって、エンジニアでも、パスワードが平文で流れるとか、中間経路でのなりすまし攻撃に弱いといった勘違いをしている人がいるけど、そんなことはないです。
中間経路でのなりすまし攻撃に対して公開鍵認証と比べたらパスワード認証の方が弱いというのは事実でしょう。
なりすまし攻撃はサーバの公開鍵のフィンガープリントの確認で防げます(普通のSSHクライアントは信頼済みでないフィンガープリントなら確認画面がでます)。
まともな運用が出来ていればいいのですが、『日本の運用』を考えた場合、「取り合えずyesと入力しろ」とか「訊かれたくなければStrictHostKeyChecking=noに設定しろ」等の情報が氾濫している現状から、あまり考えもせずにyesを入力するケースも有りそうです。
実際、Tera Termにも「警告を抑制できるようにして欲しい」という要望が多く来たのに負けて /nosecuritywarning [ttssh2.osdn.jp] を追加してしまいましたし。
# 実際には海外からも要望が来ていたので日本に限ったものではないかもしれませんが
そしてホスト鍵の確認が不十分な時はパスワード認証は脆弱で、中間者攻撃が行われている場合は接続先が本物のホストだった(ように見えた)時でも安全ではありません。
一方、公開鍵認証は(認証に関しては)安全ですし、本物のホストのホスト鍵が変わったのか、それとも中間者攻撃が行われているかの判別も可能です。(中間者攻撃の場合は認証が失敗する)
「j9FJ:45F4:mMFa」ぐらいの強度のパスワードなら何の問題もなかったわけです。
14文字ありますが
など、かなり使われている文字に偏りが有りますね。
それらをおまけして"英大文字"/"小文字"/"数字"/"記号"の四種類、計95文字の中から14文字と考えると92bit程度の強度ですね。
これはRSA 1024bit鍵の80bit相当よりは安全ですが、現在主流のRSA 2048bit鍵の112bit相当やED25519鍵の128bit相当よりはかなり落ちます。
# 最新のOpenSSHではRSA鍵はデフォルトで3072bit(128bit相当)を生成するように変わりました
また、このパスワードは「英大文字/小文字/数字4桁を3つ作り、それを : で繋げる」というルールで作られているようにも見えます。
この場合は72bit程度の強度になるので、今はもう使うなと言われているRSA 1024bit鍵よりも弱い事になります。
# まあそれでもオンラインでのブルートフォース攻撃だけを想定するならば十分ではありますが
秘密鍵自体を暗号化してパスフレーズで保護するといったこともSSHクライアントによっては可能ですが、OpenSSH標準ではないですし、しない人も多いでしょう。
秘密鍵をパスフレーズで保護しない限り、パスワード認証よりかえって脆弱になるといえます。
他のコメントでも指摘されていますが、OpenSSH標準で秘密鍵は暗号化されますし、パスフレーズを付けて保護されるのが一般的です。
一般的には行われていない運用を仮定してそれをもって公開鍵認証の方が脆弱だとするのは不公平な比較でしょう。前述したパスワード認証の問題も評価出来ていませんし。
Re: (スコア:0)
多くの組織の場合、パスワードの前半部分をメモして担当者の手帳と会社の金庫に入れておき、後半部分は他の記憶させる(他のパスワードなどとも使いまわしだったりするが)などの安全対策をしているはずです。
それはあなたの想像ではないでしょうか
Re: (スコア:0)
2人揃わないと開けられない的な? 核ミサイルスイッチかよ。
Re: (スコア:0)
インド辺りの核スイッチの方が緩かったりしてね。
Re: (スコア:0)
パスフレーズ無しの鍵認証なんて何らかの自動化目的以外で使われること
あんまりないと思うけどなあ。
Re: (スコア:0)
だよねえ。
それはそれとして、秘密鍵がパスフレーズで保護されているとしても、
もし鍵ファイルが盗まれたら盗んだ奴のローカルな環境でブルートフォースアタックが可能なのに対して、
パスワード認証は(まともな)サーバーならブルートフォースアタック対策が出来てるはずだから、
そういう意味じゃ公開鍵認証のほうが柔いって言えるかな?
パスフレーズ知っている人が退職しちゃったので解析した経験あり (スコア:1)
ssh 鍵のパスフレーズを忘れたら [improve-future.com] の方法でブルートフォース解析できます。
オフラインで解析できるので早いですよ。
Re: (スコア:0)
John the Ripper使ってる時点でかなり古くないか?この情報。それにブルートフォースで破れるパスフレーズって、どんだけ弱いんだ?解析はできます、でも結果は出るかわかりませんってことか?
Re: (スコア:0)
その記事にも
> (実際のところ Minlen = 3, MaxLen = 10, CharCount = 62 だとまず終わらないです。)
と書いてあるんですが…
ブルートフォース解析できたのは、パスフレーズが短かったからです
あなたの職場はsshを正しく運用できてないし、正しいsshの使い方も知らないのでしょう
Re: (スコア:0)
>パスワード認証は(まともな)サーバーならブルートフォースアタック対策が出来てるはずだから、
え。どんな?鍵認証使うより簡単に?
使ってるなぁパスフレーズ無しの鍵認証。パスフレーズ付けるぐらいなら鍵認証使わない。
Re: (スコア:0)
秘密鍵が絶対に盗まれないと自信を持って言えるなら、
パスフレーズなしでも良いのかもしれないけど、
普通はパスフレーズつけますわな。
秘密鍵を盗むことができれば、秘密鍵に対してローカルでブルートフォースアタックが可能。
# ただ、パスフレーズが十分な長さを持っていれば、攻撃は実質不可能。
パスワードはブルートフォースアタックが来ても、
サーバでアカウントがロックされるなどするので攻撃は不可能。
Re: (スコア:0)
sshでroot loginできること自体の是非は別にあるとして、
sshの「公開鍵認証はパスワード認証よりも安全」みたいな誤解はどうにかして欲しいですねマジで。
Re:日本の運用だとかえって危険になる気がする (スコア:1)
素直な利用の運用なら(空パスフレーズとか、秘密鍵をやたら運搬したりとかしない)なら、高強度パスワードを用意するよりかは、人間のさまざまを考えて安全かなとは思うが
ただ、無条件ではないですよね
M-FalconSky (暑いか寒い)
Re: (スコア:0)
> 多くの組織の場合、パスワードの前半部分をメモして担当者の手帳と会社の金庫に入れておき、後半部分は他の記憶させる
そんな組織見たことねぇな
忘れたら再発行・再登録なのはよく見るけど
> 秘密鍵自体を暗号化してパスフレーズで保護するといったこともSSHクライアントによっては可能ですが、OpenSSH標準ではない
えぇ!OpenSSHのパスフレーズ対応は標準じゃない???
# あれ、俺の生きてる世界が変わったのか?
Re: (スコア:0)
異世界転生ですか、おめ。
おそらく元コメは公開鍵暗号というものを理解していないだけかと。
きっと秘密鍵を共有しちゃうんでしょうね。
何故にsshの秘密鍵を金庫で保存せにゃならんのだ。
Re: (スコア:0)
ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/whoami/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
標準で聞いてくるよなあ…emptyにするのが標準なんだろうか?あと、秘密鍵暗号化に対応してないSSHクライアントってなんだろ?これってネタとか釣りなのかな?
パスワード認証許可だと、パスワードを使いまわされた結果別のところから漏洩することになるから、やっぱり公開鍵+暗号化だよなあ?パスワード変更不可ならまだしも…
Re: (スコア:0)
パスワード認証許可だと、パスワードを使いまわされた結果別のところから漏洩することになるから、やっぱり公開鍵+暗号化だよなあ?パスワード変更不可ならまだしも…
使いまわすのは秘密鍵も同じでは?
PuTTYgenとかで作って同じのサーバにアップして使いません?
VPS50台管理していたら50セットもキーペア作るんですか?
Re:日本の運用だとかえって危険になる気がする (スコア:1)
自分の周りの場合基本的に接続元端末毎に接続先台数分作る
~/.ssh/config に書いとけばいいし
Re: (スコア:0)
使いまわしても、自分の端末から漏洩することはあっても
別のところから漏洩はしないでしょw
Re: (スコア:0)
ちゃうちゃう、秘密鍵自体をみんなで共有しやがるの。
だから同じ秘密鍵がいろんな端末に入っているという。
その時点で漏れたとみなすべきだろうけど、彼女らはそういう認識を持たない。
何言っているんだって思おうかもしんないけど、そういう運用する馬鹿多い。
というか、運用に携わるITエンジニアってそんなばっか。
Re: (スコア:0)
秘密鍵の使いまわしって、基本SSHでしかやらないでしょう?パスワードはWindowsのサインインに始まり、GmailだFaceBookだYahooだOffice365だAppleIDだ、全部同じにしている人が結構いるわけです。haveibeenpwned.comで検索するとまあ出るわ出るわ。この理由だけでパスワードはだめなんです。使いまわしの抵抗感がほぼゼロなんです。
Re: (スコア:0)
パスワード使い回すのって、パスワードをpasswordにしたり、
秘密鍵の入ったモバイルPCやUSBメモリにパスフレーズ書いた付箋貼っとくのと同じぐらいアホなことなので、
そんなアホのやることまで考えてたら、どっちもどっちじゃろ
Re:日本の運用だとかえって危険になる気がする (スコア:1)
はははは…。
https://it.srad.jp/story/19/03/13/0457206/ [it.srad.jp]
IT従事者でもこのざまなのに、ガチ素人相手にシステム運用してる社内SEとしては、そんな正論空しいだけだな。
Re: (スコア:0)
初期パスワード渡して変えてもらうようなシステムならよいのだが、そうもいかないシステムでユーザに希望するパスワードを提出してもらうと、
それ他のサービスでも使いまわしてるだろ…みたいなパスワードを無邪気に提出してくるので知るのが怖い。
Re: (スコア:0)
銀行口座の乱数表カードっていろいろ考えられてるなと気づかされるな。
口座ごとに固有のものだから使いまわしできないし、書留で郵送することで二段階認証にもなっている。
ただしログインのたびに乱数表見るのはめんどくさすぎるので、振り込みなどの一部のオペレーションのみに要求されるsudo的な位置づけか。
Re: (スコア:0)
>安全対策をしているはずです。
思い込むのは自由ですが、実際は直接リモートログイン可能だけならまだマシで、rshダイレクトに叩けるようにしてたとこがありました。
rootです。
絶句しましたね。
SSHでrootに直接ログインできなくなったので (スコア:0)
元に戻す方法を教えてください。
という質問がRHEL9のサポート窓口に来るようになると、今から予測。