アカウント名:
パスワード:
tcpwrapperに登録されたマシンが踏み台にされた場合とか、ssh以外のセキュリティホールを突かれた場合に、sshdへのtcpwrapper設定が意味を持たないのは自明。
侵入可能か？って話でしょ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
実体験 (スコア: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) 認証は公開鍵
notice : I ignore an anonymous contribution.
Re: (スコア:0)
その本気の狙い方を教えて下さい
Re: (スコア:0)
この場合、すでに1台がやられている訳なので、同じように運用している端末 / サーバー がやられる可能性は、他の人が運用している端末 / サーバーよりも高いでしょう。
そもそもこの方がリモートでアクセスしている端末が既にやられている可能性もあるわけで・・・
# セキュリティは想定しうる“可能性”を潰すことと心得る
Re: (スコア:0)
僕はIPアドレス制限をちゃんとかけてあるサーバにクラックする方法を知りません。
その方法が知りたいのです。
Re: (スコア:0)
あるいは、許可しているIPアドレス範囲のネットワークに悪意あるコンピューターが接続してくれば、安易なパスワードを平文で扱っていたりすれば突破されるよ・・・。こういうソーシャルハッキング的行為が組み合わさるとIPフィルタでは防げませんよね。
もちろんこの場合、前者なら他人が入れない場所にPCを
Re: (スコア:1)
tcpwrapperに登録されたマシンが踏み台にされた場合とか、ssh以外のセキュリティホールを突かれた場合に、sshdへのtcpwrapper設定が意味を持たないのは自明。
Re:実体験 (スコア:2, 参考になる)
TELNETじゃなく、SSHを使う理由は、一つには通信経路が信用できないから、暗号化したい、ということですよね。
信用できない通信経路には、途中に何を仕掛けられるか判りませんよね。IPアドレスを偽って侵入しようとするクラッカーもいるかもしれません。
以前、『データセンタ内のARP spoofing攻撃で通信改ざんが発生、対策の定石は? [srad.jp]』って話もありましたので、可能性が低い、と言い切れる話でも無いと思います。