アカウント名:
パスワード:
tcpwrapperに登録されたマシンが踏み台にされた場合とか、ssh以外のセキュリティホールを突かれた場合に、sshdへのtcpwrapper設定が意味を持たないのは自明。
侵入可能か？って話でしょ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
実体験 (スコア:5, 参考になる)
DCに設置してもらってネットにつながってから色々作業しようと思ってました。
で、rootのパスワードに「123456」を設定してました。
メールで「ネットにつなぎましたよー」と連絡もらって、
さあ作業しようと思ったらログインできません。ぎゃふん。
東京から横浜まで行ってもらい、パスワードを再設定してもらいましたが、
同じく「123456」だったので、その方がDCを出る頃にはまたワームに犯されてました。
ワームに犯された上、ルートキットを孕ませられてしまったので、
passwdでパスワードを変更してもshadowファイルを書き換えられてしまいます。
のでしょうがないので、cronで1分おきにshadowファイルを上書きするようにして、
泣きべそ書きながらrsyncでルートキットを駆除しました。
Re: (スコア:4, 参考になる)
sshを公開鍵認証のみ受け付けるよう設定しないと、間違いなく食い破られます。
新規にIPをもらってサーバを建てても、半日～１日でログインに失敗したログが現れます。
日本人らしき人名とか、よくあるシステムIDとか、ゾロゾロ、ゾロゾロと。
# 怖いのは、相手側のIPアドレスがことごとく異なること。 この攻撃者は、一体、何台のPCを手下にしているのだろう？
notice : I ignore an anonymous contribution.
Re: (スコア:0, フレームのもと)
それは人それぞれの運用です。それをバカ呼ばわりするのはどうでしょうか？
Re:実体験 (スコア:4, 参考になる)
rootkit仕掛けられても再インストールしない人に言われても説得力が無いなあ[笑]。
侵入されてるでしょ？ 十分じゃなかったって事でしょ？
まず、その手のフィルタは補助でしかない。本気で狙われたら突破される。
現在の分散攻撃に対しては8～10桁のパスワードなど無力です。（半月保たないかもしれない）
この状況で、データセンタに設置したマシンがパスワード認証だぁ？
馬鹿以外に何と呼べと？
※パスワードだけで運用可能なのは、ファイアウォールの内側だけです。（しかも、内部でのウィルス対策が行われているという前提が必要）
1) 認証は公開鍵認証に限定する。鍵の長さはシステムが許す限り長くする。
これが基本。最後の砦。他の対策が全て転けても、最後はココで手間取る筈。
2) リモートログイン可能なユーザからrootは必ず除外すること。
・破られた時の嫌がらせ程度の効力しかないけど、一応やっとく。
3) 一般ユーザは各自のhomeに閉じ込めること。
ファイル転送用途だけの場合はscponlyなどの転送用途に限定されたシェルを使用する。
4) 不要なポートは全て閉じる。 無いと本当に困るものだけを残す。
5) まともなルータが使える場合、sshのログインをルータのVPN経由の接続に限定する（IPsec推奨）。
・イーサネットの口が２口ある場合、物理的にセグメントを分離して接続すると設定が楽
6) 可能ならばルータでNATをかける。
7) iptablesなどのフィルタが利用できる場合は設定する。
これで最低限だと思う。（細かい対策を始めたら際限ないけど）
｜東京から横浜まで行ってもらい
「先方」というのが顧客だったら、うちでは間違いなく始末書ですね。
んで、顛末書を作成し、客に提出して平謝りです。 正直、そんな事態だけは避けたい。
notice : I ignore an anonymous contribution.
クライアント証明書での認証普及しないかな (スコア:1)
＞（しかも、内部でのウィルス対策が行われているという前提が必要）
そうなんですよ，できればサーバにログインするためのアカウントだけでなく
ウェブサービス全般へのログインについても本当は証明書で運用したいんだよなぁ．
パスワードの長さとか文字種とかであからさまに弱すぎるパスワードは
設定できないようにしたり，一定期間たったら変更してくれるように
促すメッセージは表示しているものの，基本的にユーザ任せですからね・・
屍体メモ [windy.cx]
Re: (スコア:0)
その本気の狙い方を教えて下さい
Re: (スコア:0)
この場合、すでに1台がやられている訳なので、同じように運用している端末 / サーバー がやられる可能性は、他の人が運用している端末 / サーバーよりも高いでしょう。
そもそもこの方がリモートでアクセスしている端末が既にやられている可能性もあるわけで・・・
# セキュリティは想定しうる“可能性”を潰すことと心得る
Re: (スコア:0)
僕はIPアドレス制限をちゃんとかけてあるサーバにクラックする方法を知りません。
その方法が知りたいのです。
Re: (スコア:0)
えーと、そんなことを言い出したら、公開鍵認証を使っていたとしても、
サーバの公開鍵と対をなす秘密鍵が入った端末・サーバが踏み台にされたと
考えてみるとどうでしょうか？
ついでに言えば、踏み台にしなくても、その秘密鍵を別環境にコピーして
使えば踏み台も何もいらないですね。
そこまで想像できませんか？
Re: (スコア:0)
あるいは、許可しているIPアドレス範囲のネットワークに悪意あるコンピューターが接続してくれば、安易なパスワードを平文で扱っていたりすれば突破されるよ・・・。こういうソーシャルハッキング的行為が組み合わさるとIPフィルタでは防げませんよね。
もちろんこの場合、前者なら他人が入れない場所にPCを
Re:実体験 (スコア:1)
tcpwrapperに登録されたマシンが踏み台にされた場合とか、ssh以外のセキュリティホールを突かれた場合に、sshdへのtcpwrapper設定が意味を持たないのは自明。
Re:実体験 (スコア:2, 参考になる)
TELNETじゃなく、SSHを使う理由は、一つには通信経路が信用できないから、暗号化したい、ということですよね。
信用できない通信経路には、途中に何を仕掛けられるか判りませんよね。IPアドレスを偽って侵入しようとするクラッカーもいるかもしれません。
以前、『データセンタ内のARP spoofing攻撃で通信改ざんが発生、対策の定石は? [srad.jp]』って話もありましたので、可能性が低い、と言い切れる話でも無いと思います。
Re:実体験 (スコア:1)
そもそもIPパケットは送信元が何であれ届くので、TCPの(以下検閲)を推測して(以下検閲)ばできる。乱数の出来が悪い事がセキュリティホールになる理由の一つだけど、別に乱数の出来が悪くなくても数撃ちゃ当たるのでそういうプログラムを回しておけばクラックできる。その時に推測しなきゃならない空間がよくある暗号に比べてもものすごーく小さいのでIP制限だけというのはかなり脆弱といえる。
※あー、上の内容はそのままでは別の攻撃と同義なので実際にやるとすぐバレるよ。
Re: (スコア:0)
Re: (スコア:0)
ssh公開鍵認証が安全だという論拠が賢明ではないということ。
他人をバカ呼ばわりするほど、書いている本人は優れていないよということ。
何が安全で何がダメ、という話とはまた別。
Re: (スコア:0)
>rootkit仕掛けられても再インストールしない人に言われても説得力が無いなあ[笑]。
>侵入されてるでしょ？ 十分じゃなかったって事でしょ？
sayuぽるのもとい、sayupornではないACですが、rootkit仕掛けられた時の話と、
その後の対策の話が前後していませんか？
sayupornの話では、tcp_wrapperも使わず、パスワードも安易すぎるもので
グローバルなネットに繋げていたから侵入されたんですよね。
tcp_wrapperをかけていて侵入されてrootkitを仕掛けられたのではないと思うよ。
>まず、その手のフィルタは補助でしかない。本気で狙われたら突破される。
Re:実体験 (スコア:1)
iptablesが何か調べてから書き込んでください。
# いまどき、tcp_wrapper は使われません。使うとしたらipfwやiptablesが使えない様な特殊な場合のみ。
notice : I ignore an anonymous contribution.
Re: (スコア:0)
逃げですか。
たかが知れますね。
ちゃんと反論できる知識は提供できませんか、そうですか。
>iptablesが何か調べてから書き込んでください。
> # いまどき、tcp_wrapper は使われません。使うとしたらipfwやiptablesが使えない様な特殊な場合のみ。
だから、ipfwやiptablesでも問題は変わりませんって。
分散攻撃でtcp_wrapper+sshパスワード認証が無力になる理由を示して欲しい
ということなんですが、たぶん知っているキーワードを並べただけだったんですね？
それに、秘密鍵が保存されている端末がやられたら、公開鍵
Re:実体験 (スコア:1)
パスワードと認証キーでどう異なるのか
私も興味ぶかかったので一連の発言おってみたけど、結果は提示されなかったんですね
送信元IP偽造って話もあったけど、その場合応答パケットが送信元に届かないので
クラックという面では意味が無い
DDOSアタックに使うならそれでいいんだけど
認証って面では公開キー暗号方式の場合、どうやって秘密キーを管理するか
と言うのが最大の問題点になりますから、リモートでインターネットを使って
メンテナンスするという話であれば私はそれは使いませんねぇ～
PC側に秘密キーを入れておくとかだと、それはそれで端末側をやられた場合危険でしょうから
今ならトークン持って、特定ユーザーにワンタイムパスワードが最低条件でしょう
個人で使うならそもそもリモートから管理するというのは考慮外
だって家に帰ればおいてあるのにリモートでメンテナンスやる必要がないですから
サーバーのサービスを使うことはあっても使わないサービス以外はルータで遮断でしょう
sshなんて遮断の筆頭候補ですよね
Re:実体験 (スコア:1)
あぁそういえば昔は意味がありましたね、シーケンス番号予測して応答来たものとして
投げ続けるとか
もう対策済みでほぼ不可能だけど