アカウント名:
パスワード:
tcpwrapperに登録されたマシンが踏み台にされた場合とか、ssh以外のセキュリティホールを突かれた場合に、sshdへのtcpwrapper設定が意味を持たないのは自明。
侵入可能か?って話でしょ。
パスワードログインでもtcp_wrapperをかければ十分だと思います。
$ base64 /dev/urandom | head
しかしそれとsshを公開鍵認証でログインするように運用しなければならないことは別問題ですよね?
泣きべそ書きながらrsyncでルートキットを駆除しました
なぜまずいんですか?
それに普通って誰の普通ですか?
私もどこまでが「普通」かには自信がありませんが、企業のサーバ管理の専門家に聞いた限りでは、 rootkit 置かれちゃうレベルまで行ってたら再インストールか、最低でも HDD を取り出して他のクリーンであることがわかっているシステムに接続し復旧を試みる、という手順を踏みますね。間違っても、汚染された OS の内側から復旧しようなんて思わない。
たしかに、ただの踏み台やボットがわりに乗っ取られてたりする場合にはそこまで凝った仕掛けは施されていないことは多いでしょうが (無理して攻防戦をするよりも他のもっと弱いサーバーを乗っ取りに行った方が手間がかからない)、 それでも最近は出来合いのキットでもかなり出来のいい(というか恐しい)とも聞きますので、まぁ再インストールするか、管理者を他のもっとわかっている方に交代してもうらのがよいかと思います。
お前は駄目だ、他のものに代われ。って無責任に言うのは簡単ですね。それで世の中が完璧になればいいのに。
イントラネットならともかく、グローバルIPアドレス振られたサーバがほとんどのDCで、私のサーバ1台だけを早急にネットワークから切り離さなければいけない理由がわかりません。
ワーム経由で仕組まれるルートキットなんてたかがしれてるし、それらの検出は十分可能です。
検出できないとしてもrsyncでファイルをすべて上書きすれば十分だと思います。
ウィルスにかかったPCもそのたびにWindowsを再インストールしなければなりません。
より多くのコメントがこの議論にあるかもしれませんが、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) 認証は公開鍵認証に限定する。鍵の長さはシステムが許す限り長くする。
これが基本。最後の砦。他の対策が全て転けても、最後はココで手間取る筈。
2) リモートログイン可能なユーザからrootは必ず除外すること。
・破られた時の嫌がらせ程度の効力しかないけど、一応やっとく。
3) 一般ユーザは各自のhomeに閉じ込めること。
ファイル転送用途だけの場合はscponlyなどの転送用途に限定されたシェルを使用する。
4) 不要なポートは全て閉じる。 無いと本当に困るものだけを残す。
5) まともなルータが使える場合、sshのログインをルータのVPN経由の接続に限定する(IPsec推奨)。
・イーサネットの口が2口ある場合、物理的にセグメントを分離して接続すると設定が楽
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)
>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:実体験 (スコア:1)
パスワードと認証キーでどう異なるのか
私も興味ぶかかったので一連の発言おってみたけど、結果は提示されなかったんですね
送信元IP偽造って話もあったけど、その場合応答パケットが送信元に届かないので
クラックという面では意味が無い
DDOSアタックに使うならそれでいいんだけど
認証って面では公開キー暗号方式の場合、どうやって秘密キーを管理するか
と言うのが最大の問題点になりますから、リモートでインターネットを使って
メンテナンスするという話であれば私はそれは使いませんねぇ~
PC側に秘密キーを入れておくとかだと、それはそれで端末側をやられた場合危険でしょうから
今ならトークン持って、特定ユーザーにワンタイムパスワードが最低条件でしょう
個人で使うならそもそもリモートから管理するというのは考慮外
だって家に帰ればおいてあるのにリモートでメンテナンスやる必要がないですから
サーバーのサービスを使うことはあっても使わないサービス以外はルータで遮断でしょう
sshなんて遮断の筆頭候補ですよね
Re:実体験 (スコア:1)
あぁそういえば昔は意味がありましたね、シーケンス番号予測して応答来たものとして
投げ続けるとか
もう対策済みでほぼ不可能だけど
Re:実体験 (スコア:2, すばらしい洞察)
ほんとに冗談じゃなく。絶対にやめてください。
二度とするな。
Re:実体験 (スコア:1, すばらしい洞察)
他のサーバにアタックかける手下にされてしまうような状況が発生したら
被害者で済まなくなってしまいますよね。
例え不正アクセスの被害を受けたサーバの管理者であるとしても
対策の甘さと不正アクセスのアクセス元という状況が揃えば
賠償請求の対象になりかねません。
セキュリティ管理の甘い人にサーバ管理者に
なってもらいたくないのもわかります。
ただ、文章の書き方に関しては
もう少し配慮した方が良いのではないでしょうか。
こんなのにマジレス返すのが悔しいのでAC
Re:実体験 (スコア:1)
私だったら、最低でも、
インターネットからのリモートログインを許可するなら、(アドレス制限するとしても)パスワードログインは許可しませんね。SSHの公開鍵認証の方がパスワード(パスフレーズ)の管理が楽ですから。
Re:実体験 (スコア:1, おもしろおかしい)
パスワードを「123456」ではなく「12aho45aho」にしておけばまだましだったでしょう。
しかしそれとsshを公開鍵認証でログインするように運用しなければならないことは別問題ですよね?
Re:実体験 (スコア:1)
が、その程度もやってないのか、と批判されても仕方ないかな、とも思います。別に管理・運用が難しくなるわけでもないのですから。
Re: (スコア:0)
頭悪い。
何のためにそのサーバを運用するのかを見失ってしまうから別問題に見えるのだろう。
ちなみにこのストーリー、別にパスワードの話しかしちゃいけないわけじゃないよ?
Re:実体験 (スコア:1)
フォレンジック (スコア:0)
>普通、即ネットワークから切り離し、再インストールでしょう?
も完璧とは言えませんな。
「普通」のレベルにもよるかもしれませんけど、フォレンジックをやらないで
再インストールしちゃうのは原因特定や再発防止、犯人特定を不可能にしちゃうので
「インドで野良犬に噛まれても、唾付けときゃ治る」程度の療法でしょう。
今回の場合、安易なパスワードが攻略された可能性が高いではありますが、
その結果、何が仕掛けられ、どのような攻撃をどの範囲に行うのかくらいは
調べるべきでしょう。
徹底的に調べたうえで再インストールしなきゃ。
Windowsの場合、原因となった脆弱性の修正(WindowsUpdate)がされて再発が
防止されることもありますが、へっぽこLinux管理者の場合、原因も特定せずに
気づいた怪しいファイルだけ削除して復旧としたり、同じ状態で再インストール
して、またやられることを繰り返すパターンが結構あります。
Re:フォレンジック (スコア:2)
「汚染HDDのディスクイメージを取ってから初期化すれば,新品HDDは無くてもいいだろ?」
とも思いましたが,もしかすると汚染HDDのファームウェアから復元してくる奴もいるかもしれないので,新品HDDを安心料として用意するほうがいいのかな。
リモート作業をとったsayuporn氏の手順は全く感心できない,ということで。そのsayuporn氏は日記に逃げ込んじゃって,まだ吠えているみたいですけど。
> 「普通」のレベルにもよるかもしれませんけど、フォレンジックをやらないで
> 再インストールしちゃうのは原因特定や再発防止、犯人特定を不可能にしちゃうので
> 「インドで野良犬に噛まれても、唾付けときゃ治る」程度の療法でしょう。
Re: (スコア:0)
本体側のマザーボードのBIOS用のフラッシュメモリや、NICのネットワークブート用のフラッシュメモリも汚染されてるかもよ。
Re: (スコア:0)
主張はごもっともだが、この件は再インストールでいいんでは。
原因ははっきりしているのだし。
Re: (スコア:0)
ごめんなさい
Re:実体験 (スコア:5, 参考になる)
DC内でワーム大繁殖、何てことになったら目も当てられません。未必の故意で損害賠償を請求されても仕方の無いケースだと思います。
第二に、rootkitを完全に排除しなければまずいです。Rootkitが組み込まれた疑いがあるのなら、そのOS上での調査結果は完全には信用できません。Rootkitは、システムコールを巧妙に書き換えて、ユーザから身を隠したままOS内に潜伏することが可能です。OSに組み込まれたrootkitを完全に排除する最も簡単で信頼性の高い方法は、OSを再インストールすることです。
リモートから作業したのであれば、Rootkitが組み込まれたOSを使って作業したのですよね?だったら、まだrootkitが残ったままの可能性があります。かなりまずいと思いますよ。 Rootkitが何なのかを知っている人にとっての普通です。異論はあるでしょうが、それ程特殊な考え方では無いと思いますよ。
参考 [wikipedia.org]。
Re:実体験 (スコア:5, 参考になる)
私もどこまでが「普通」かには自信がありませんが、企業のサーバ管理の専門家に聞いた限りでは、 rootkit 置かれちゃうレベルまで行ってたら再インストールか、最低でも HDD を取り出して他のクリーンであることがわかっているシステムに接続し復旧を試みる、という手順を踏みますね。間違っても、汚染された OS の内側から復旧しようなんて思わない。
たしかに、ただの踏み台やボットがわりに乗っ取られてたりする場合にはそこまで凝った仕掛けは施されていないことは多いでしょうが (無理して攻防戦をするよりも他のもっと弱いサーバーを乗っ取りに行った方が手間がかからない)、 それでも最近は出来合いのキットでもかなり出来のいい(というか恐しい)とも聞きますので、まぁ再インストールするか、管理者を他のもっとわかっている方に交代してもうらのがよいかと思います。
Re: (スコア:0, フレームのもと)
ってもちろん疑えばきりがありません。
私だって手元にサーバがあれば再インストールしますし、
再インストールしなければいけないことなら地球の裏側のDCにだって行きます。
今回は全部の手間を考えた上で、妥当だろうという判断をしました。
それが駄目だと言われれば、はいそうですかというしかありません。
お前は駄目だ、他のものに代われ。って無責任に言うのは簡単ですね。
それで世の中が完璧になればいいのに。
Re:実体験 (スコア:1)
無知やそれによる失敗は仕方がありません。完璧な人間はいないのですから。大切なのは、その後の対応です。
Re: (スコア:0, フレームのもと)
Re:実体験 (スコア:2, すばらしい洞察)
Re:実体験 (スコア:2, すばらしい洞察)
件のサーバをまだ管理されているのであれば、他の方が書かれているように再インストール等の対策を今からでも取られた方がよろしいでしょう。
また、バックエンドにDBや管理LANなどはないでしょうか。
あった場合はそれらにつながっているサーバも攻撃を受けた可能性があります。
すでに下記のように書かれていますが、気になったので念のため。
> イントラネットならともかく、グローバルIPアドレス振られたサーバがほとんどのDCで、
> 私のサーバ1台だけを早急にネットワークから切り離さなければいけない理由がわかりません。
誰も現在のサーバの状態に言及してないので、よけいなおせっかいと思いつつもACで初投稿。
Re:実体験 (スコア:1)
そんな態度を続けてると、誰も何も教えてくれなくなりますよ。
Re: (スコア:0)
少なくとも一般的なフィーリングとはズレていると思いますよ。
あなたのやっていることは事故米を食用販売していた会社の社長と同じです。
確かに、実際に健康被害は無いのかもしれませんが、一般的に受け入れられない事です。
そのことが理解できない、する気が無いのであれば仕方が有りません。
私はあなたと仕事で関係することが無いことを祈るだけです。
Re: (スコア:0)
Re: (スコア:0)
みんながrootkitにやられた場合再インストールしなければならない言ってるのは、
rootkitが自分を隠して何をしてるかわからないからだろうけど、
彼女はそれを把握し、自分の責任で駆除したって言ってるんだから、
私はそれを信頼してます。なんかあったら彼女が責任取ればいいんだしw
と現場から援護射撃。
ヒソカに恋心があるのでAC
Re: (スコア:0)
この場合の「ヒソカに」は「表面的に」の意味でしょうか?
一度くらい食事してあわよくば一晩一緒に過ごせればいいってレベルの恋心なのでしょうか?
そうでないなら、もっと違う付き合い方があると思うのですが。
# とあることで警察や消費者センターに相談したらそういうツッコミを食らった
Re:実体験 (スコア:2)
> 私はそれを信頼してます。なんかあったら彼女が責任取ればいいんだしw
「その程度の対応では,sayuporn氏の責任・懲戒・退職だけでは済まず,会社の消滅までいくかもしれないぞ。それで十分と判断するのは止めたほうが,会社の仲間にも迷惑がかからない」
という意味の集中砲火なので,中途半端な援護はsayuporn氏のためには決してならないと思う。
> なんかあったら彼女が責任取ればいいんだしw
恋心を抱いている当の相手も見ている場で,突き放されたようにsayuporn氏に受け止められて氏を傷つけかねない,その台詞はうかつすぎるような・・・。
この書き込みがばれたら,一生,秘めた恋で終わるな。・・・あ,sayuporn氏がWebアクセスログも見れる立場だったら,もう誰が書いたのかバレバレなのか。
Re:実体験 (スコア:1, すばらしい洞察)
うちの会社の場合、お客様と結ぶ契約書/同意書/誓約書の類に個人が何か責任を負う条項が入っていた場合、法務が通しません。今回のように業務上のミスはもちろん、たとえば業務時間外にお客様の入館証を紛失し悪用された場合でも、損害賠償責任は会社が持ちます。
これは社員を尊敬していないわけではなく、逆に、「尻はぬぐってやるから思い切って仕事してこい」という意味だと思っています。
(もちろん後で社内規定に従って始末書なり懲戒なりがあります)
このあたりはうちが特殊なわけではなく、まあ多くの会社がそうやっていると思います。
もう1点は同僚を尊敬するということについて。
技術屋の場合、レビューなんてのはコードから提案書まで様々なものがありますが、それは決して同僚を信頼・尊敬していないわけではなく、チームとしてよりよいものを作り上げる共同作業というだけのはずです。
個人が「作業完了した」だけではダメで、最低限、チーム内で報告書を検討してチームとしてそれが最善であったかを検討する「レビュー」がないというのがなんとも不思議です。
で、この2点を合わせて考えると、あなたの会社は個人事業主の集まりのようなところで、お互い尊敬しあい、干渉も助言もせず、責任も個人で持つということなのでしょうかね? 社風とか文化はそうそう変わるものではないので、それで今までうまく行ってるってことですよねぇ・・・??
どうでもいいツッコミですけど (スコア:1)
バレたなら「秘めた」恋では終わらない気が。
署名スパムがウザい?アカウント作って非表示に設定すればスッキリさ。
Re:実体験 (スコア:4, すばらしい洞察)
今回の場合は、まだ納入したばかりでサービスインしていなかったんですよね?であれば、すぐに切り離しても問題無いはずですから、逆に切り離さない理由が解りません。 その根拠は? 例えばカーネル内のシステムコールが書き換えられていれば、全然十分ではありません。
到底rootkitとは何かを知っている人の意見とは思えません。 sayupornさん個人が管理するPCで、インターネットにも接続せず、何が起こってもsayupornさん自身がすべての責任を取る、と言うのなら、その必要はありません。
しかし、インターネットへ公開するマシンで、そのマシンの不具合で例えば会社の信用に傷がつく、という場合には、単にウィルスに感染しただけでも、OSから再インストールか、安全と確認されているバックアップをリストア、という判断もあろうかと思います。
Re:実体験 (スコア:1)
rootkitに犯されたシステムのrsyncを信用しちゃうわけですね。
Re: (スコア:0)
Re: (スコア:0)
今時のワームなら経路暗号化の上LKM引き込むのが常套手段だと思うけど?
受信したパケット全て解析の上、侵入したワームも全て確認済ならまあありか。
でも、再インストールの方が簡単確実のような。
> それらの検出は十分可能です。検出できないとしてもrsyncでファイルをすべて上書きすれば十分だと思います。
LKMでファイル読み書きフックされたら検出も書き換えも事実上不可能な気がする。
Re: (スコア:0)
である以上、再インストールすることで全て無かったことにしないと問題を取り除いたと証明できないからでしょ。
駆除という以上、駆除したことを証明できる方法が普通だと思うぞ。
証明出来ないんじゃ意味がない。
Re: (スコア:0)
HDDを物理的に新品と交換したほうがいいです。