アカウント名:
パスワード:
パスワードログインでもtcp_wrapperをかければ十分だと思います。
$ base64 /dev/urandom | head
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
実体験 (スコア: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: (スコア:1)
私だったら、最低でも、
- rootのリモートパスワードログインを禁止して、
- suできる唯一の一般ユーザを推測され難いユーザ名で作成し、
- iptablesでリモートログインを許可するIPアドレスを制限する
くらいのことはしますね。もちろん、すべてのパスワードは推測し難いものにします。 の出力などから、適当な長さの文字列を切り出して使います。インターネットからのリモートログインを許可するなら、(アドレス制限するとしても)パスワードログインは許可しませんね。SSHの公開鍵認証の方がパスワード(パスフレーズ)の管理が楽ですから。
Re: (スコア:1, おもしろおかしい)
パスワードを「123456」ではなく「12aho45aho」にしておけばまだましだったでしょう。
しかしそれとsshを公開鍵認証でログインするように運用しなければならないことは別問題ですよね？
Re:実体験 (スコア:0)
頭悪い。
何のためにそのサーバを運用するのかを見失ってしまうから別問題に見えるのだろう。
ちなみにこのストーリー、別にパスワードの話しかしちゃいけないわけじゃないよ?