アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
実体験 (スコア:5, 参考になる)
DCに設置してもらってネットにつながってから色々作業しようと思ってました。
で、rootのパスワードに「123456」を設定してました。
メールで「ネットにつなぎましたよー」と連絡もらって、
さあ作業しようと思ったらログインできません。ぎゃふん。
東京から横浜まで行ってもらい、パスワードを再設定してもらいましたが、
同じく「123456」だったので、その方がDCを出る頃にはまたワームに犯されてました。
ワームに犯された上、ルートキットを孕ませられてしまったので、
passwdでパスワードを変更してもshadowファイルを書き換えられてしまいます。
のでしょうがないので、cronで1分おきにshadowファイルを上書きするようにして、
泣きべそ書きながらrsyncでルートキットを駆除しました。
Re: (スコア:4, 参考になる)
sshを公開鍵認証のみ受け付けるよう設定しないと、間違いなく食い破られます。
新規にIPをもらってサーバを建てても、半日~1日でログインに失敗したログが現れます。
日本人らしき人名とか、よくあるシステムIDとか、ゾロゾロ、ゾロゾロと。
# 怖いのは、相手側のIPアドレスがことごとく異なること。 この攻撃者は、一体、何台のPCを手下にしているのだろう?
notice : I ignore an anonymous contribution.
Re: (スコア:0, フレームのもと)
それは人それぞれの運用です。それをバカ呼ばわりするのはどうでしょうか?
Re: (スコア:4, 参考になる)
rootkit仕掛けられても再インストールしない人に言われても説得力が無いなあ[笑]。
侵入されてるでしょ? 十分じゃなかったって事でしょ?
まず、その手のフィルタは補助でしかない。本気で狙われたら突破される。
現在の分散攻撃に対しては8~10桁のパスワードなど無力です。(半月保たないかもしれない)
この状況で、データセンタに設置したマシンがパスワード認証だぁ?
馬鹿以外に何と呼べと?
※パスワードだけで運用可能なのは、ファイアウォールの内側だけです。(しかも、内部でのウィルス対策が行われているという前提が必要)
1) 認証は公開鍵
notice : I ignore an anonymous contribution.
Re:実体験 (スコア:0)
>rootkit仕掛けられても再インストールしない人に言われても説得力が無いなあ[笑]。
>侵入されてるでしょ? 十分じゃなかったって事でしょ?
sayuぽるのもとい、sayupornではないACですが、rootkit仕掛けられた時の話と、
その後の対策の話が前後していませんか?
sayupornの話では、tcp_wrapperも使わず、パスワードも安易すぎるもので
グローバルなネットに繋げていたから侵入されたんですよね。
tcp_wrapperをかけていて侵入されてrootkitを仕掛けられたのではないと思うよ。
>まず、その手のフィルタは補助でしかない。本気で狙われたら突破される。
まぁ、そうですが、
> 現在の分散攻撃に対しては8~10桁のパスワードなど無力です。(半月保たないかもしれない)
これの説明には不十分でしょう。
tcp_wrapperをかけずに10桁程度のパスワードが分散攻撃に無力というのは
わかりますが、tcp_wrapperをかけた状態で無力というのはどういう理論?
マジ、わからないので説明よろしく。
sshd : ALL : allow
とかいう設定をしていたとかいうオチではないですよね。
完璧とは言えないけど、無力とは言いすぎかなと思いました。
>パスワードだけで運用可能なのは、ファイアウォールの内側だけです。
>(しかも、内部でのウィルス対策が行われているという前提が必要)
それは、本当ですか?
ウィルス対策が行われていれば、完璧ですか?
あまり変わらないと思うのは私だけですか?
内部でも公開鍵にしたほうがよくないですか?
またはファイアーウォール内のネットワークのセキュリティをもっと高くしないと
行けないのではありませぬか?
> 1) 認証は公開鍵認証に限定する。鍵の長さはシステムが許す限り長くする。
> これが基本。最後の砦。他の対策が全て転けても、最後はココで手間取る筈。
「tcp_wrapper+sshパスワード認証」の不正侵入被害と、
「ssh公開鍵認証」だけで運用しているサーバがsshdの脆弱性で不正侵入を食らうのと、
あまり被害数は変わらないような気がします。
なので、これを「最後の砦」とか基本とか言いきってしまうのはうましかでは?
TrojanでPC内のファイルを中国のサーバに送るのが存在しているよね。
しかも、毎日自分自身を更新するので、市販のアンチウイルスは検知しなかったり。
PC内にある秘密鍵を中国のサーバに送られたりなんかしたら、公開鍵認証だけでは
とてもじゃないですが安心とは言えませんな。
tcp_wrapperもかけたら?
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)
あぁそういえば昔は意味がありましたね、シーケンス番号予測して応答来たものとして
投げ続けるとか
もう対策済みでほぼ不可能だけど