権限は 555 に設定されています。他のユーザーがファイルを変更するにはどうすればよいですか?

権限は 555 に設定されています。他のユーザーがファイルを変更するにはどうすればよいですか?

私は Vesta で Ubuntu 12.04 x64 VPS と PHP のサイトを運営しています。次のようなコードが挿入され、何度かハッキングされました。

<?php $KoDgalxVvsZfidVcEOTJDeMX='ba'.'se6'.'4_deco'.'de';eval($KoDgalxVvsZfidVcEOTJDeMX("cHJlZ19yZXBsYWNlKCIvN0xna0xnND1IR2JEOGs2WDht....

これを修正するために、すべてのファイルの権限と所有者を 555 と root に変更して、どのユーザーもファイルを変更できないようにすることにしました。FTP アクセスを削除し、SSH を保護して、VPS にあるキーだけが接続できるようにしました。

これらすべての変更にもかかわらず、別のユーザーは常にファイルを変更したり、フォルダーの名前を変更したり、ハッキングされた別のファイルをアップロードしたりできます。

私が見逃しているものは何だと思いますか? 何か提案はありますか? ありがとうございます! この問題についてさらに情報が必要な場合は、同じ苦しみに苦しむ他の人々を助けるために喜んで共有します!

答え1

攻撃者がシステムのルート権限を取得しました。システム上のあらゆるものをまったく信頼できません。ルートキットによって実行できることの範囲は広大です。

コンテンツのバックアップがどこかにある場合は、それを使用してください。そうでない場合は、攻撃者がデータを壊していないことを期待するしかありません。SQL テーブルをダンプし、それを他のもの (jpg、pdf、html、ただしスクリプト/php/その他実行されるものは除く) と一緒にコピーします。それを別のシステムにコピーするか、サイズが小さく、再度アップロードできる場合は自宅のコンピューターにダウンロードします。

コピーしたものがまだ問題ないことを確認するために、できることは何でもしてください。(念のため、jpg がすべて有効な jpg であることを確認します。ウイルス スキャナーを実行するのもいいかもしれません。)

侵害されたインストールを吹き飛ばします。サーバーが一般的なホスティング サービスでホストされている場合、ホストのルートでも混乱させられないコントロール パネルが設定されているはずです。したがって、攻撃者が侵害したマシンの外部に何も触れていないことを期待できます。(ただし、そのマシンに設定されている他のものにパスワードなしでアクセスできる場合は、それらを確認してください。)

新規インストールを行うために必要なことは何でも行ってください。いずれにせよ再インストールする必要があるので、Ubuntu 14.04 LTS に移行したほうがよいでしょう。

侵害されたシステムから新しいシステムにコードをコピーしないでください。侵害されたシステムから取得したすべてのデータは、潜在的な疫病の媒介物として扱う必要があります。

Unixファイルシステムのセマンティクスでは、ファイルを削除するにはディレクトリへの書き込み権限が必要です。(ファイル名は名前からinodeへのリンクです。ハードリンク(ファイルの別名)を作成するシステムコールはlink(2)、ファイルを削除する呼び出しはunlink(2)

ディレクトリ ( chmod +t) にスティッキー ビットが設定されている場合、unlink(2)リンク解除または名前変更するファイルの所有者が呼び出し元である必要があります (ファイルの書き込み権限に関係なく)。および が(スティッキー ビットが設定されていると誰でも書き込み可能)になるのがrename(2)標準です。/tmp/var/tmp1777

rmシェルコマンドは、POSIX読み取り専用ファイルのリンクを解除する前にプロンプ​​トを表示しますが、その場合をチェックする必要があります。unlink(2)他のファイルの場合とまったく同じ操作を実際に実行する必要はありません。したがって、これが敵に何らかの効果をもたらすと誤解しないでください。

これらはいずれも、攻撃に対する防御にはあまり関係がありません。なぜなら、最も起こり得るケースは、Web サーバー プロセス、または多くのものへの書き込みアクセス権を持つユーザー ID で実行されている他の何かの制御を取得することだからです。

インターネットからのデータを処理するプロセスによって書き込まれる内容を制限できるほど、攻撃者が httpd の制御からデータの変更、またはマシン全体の制御へとエスカレートする可能性が低くなります。

これが、Apache を root として実行すべきでない理由です。

答え2

回避できる場合は、Web サービスの脆弱性が侵害されるとサーバーが完全に侵害されることになるので、Web サーバーのプロセスを root ユーザーとして実行しないでください。

現状では、新しいサーバーで最初からやり直すことをお勧めします。攻撃者は、さまざまな方法で永続的なルートアクセスを取得している可能性があります。ここ詳細については。

答え3

これらすべての変更にもかかわらず、別のユーザーは常にファイルを変更したり、フォルダーの名前を変更したり、ハッキングされた別のファイルをアップロードしたりできます。

Web ルートの親ディレクトリが Web サーバーを実行しているユーザーと同じユーザーによって所有されている場合、その親ディレクトリの権限は子ファイルとディレクトリに設定されている権限よりも優先されます。

たとえば、所有する任意のディレクトリで「ターミナル」プロセスを開きます。次に、zzz_test.txt次のようなファイルを作成します。

touch zzz_foo.txt

次のようにファイルを確認します。

ls -la zzz_foo.txt

私の場合、権限は次のようになります。

-rw-r--r--  1 jake  staff  0 Feb 23 19:11 zzz_foo.txt

次に、chmod次のように実行します。

chmod 555 zzz_foo.txt 

もう一度実行するls -laと、結果は次のようになります。

-r-xr-xr-x  1 jake  staff  0 Feb 23 19:11 zzz_foo.txt

さて、権限が変更されました。では、削除を試みるなど、何か「クレイジーな」ことをしてみましょう。

rm zzz_foo.txt

応答は次のようになります。

override r-xr-xr-x  jack/staff for zzz_foo.txt?

そして、単に押してy押すreturnと、ファイルが消えます。

このため、ファイルの権限を変更するだけでは、Web サーバーを安全に保護する効果的な方法にはなりません。Web サーバーの動作は単純なため (特に PHP ベースの場合)、Web サーバーのユーザーは、アクセスする必要があるファイルに対して常に読み取りおよび書き込みアクセス権を持ちます。そのため、単に変更するだけでは、chmod 555 [some files]マルウェアやハッキングの試みから自分自身を「防御」する方法としては効果的ではありません。

では、今できることは何でしょうか? 権限と所有権を変更するだけでは、何の意味もありません。より大きな問題は、PHP コードベースが攻撃に対して脆弱であることです。したがって、この種のものをクリーンアップする唯一の効果的な方法は、PHP コードをクリーンアップすることです。このサイトが Joomla!、WordPress、CakePHP などの既成のフレームワークに基づいている場合、最善の策は、コアの Joomla!、WordPress、CakePHP フレームワークをアップグレードして、セキュリティ ホールを塞ぐことです。同様に、攻撃に対して脆弱な Joomla!、WordPress、CakePHP プラグインがある場合は、そのプラグインをアップグレード/パッチして、ホールを塞ぐ必要があります。

さらに、コア システム ソフトウェア (LAMP (Linux Apache MySQL PHP) スタックであると仮定) も最新の状態に保ち、パッチを適用する必要があります。

結局のところ、ウェブサイトのセキュリティは一度きりのことではありません。それは、遵守しなければならない全体的な考え方とメンテナンス プロセスです。そうしないと、サイトがハッキングされたときに、混乱を解消しようと必死に作業することになりますが、これは実際には最初のマルウェア侵入自体よりも大きな損害を引き起こす可能性があります。

答え4

サーバー オプションからやり直すことには同意しますが、セキュリティと制御をさらに強化したい場合は、専用サーバーを使用する方がよいでしょう。

あなたの状況に関して、私が最初に提案するのは、シェル アクセスを除くすべての実行中のサービスを無効にすることです。つまり、FTP サービス、Web サーバー (HTTP)、電子メールなどを停止します。次に、シェルに入り、ハッキングされていると主張するアイテムを含むフォルダーに移動します。次に、次のように入力します。

ls -al

結果には次のようなものが表示されます。

drwxrwxrwx  2 root root  4096 2014-10-10 00:31 ./

4 番目の項目 (特に 3 番目の項目) が実際には「root」である場合、深刻な問題が発生するため、フォルダに応じて異なるユーザーとして実行するように Web サーバーの構成をやり直す必要があります。Apache の mod_rewrite (または同様のもの) を調べ、それに応じて Apache 構成ファイル (httpd.conf) を調整して、フォルダへのリクエストが行われるたびにシステムがユーザー名を変更するようにします。次に、それに応じてフォルダのユーザー名とグループ名を変更します。

修正したら、ドキュメント ルート フォルダー (おそらく public_html) に移動し、エディター (pico が使用可能) を使用して次のように入力します。

<?php
echo shell_exec("whoami");
?>

これを who.php として保存します。次に、Web サーバーをオンにして任意のブラウザーで Web サイトのホームページに移動し、その末尾に who.php を追加すると、画面に 1 つの単語だけが表示されます。その単語が root である場合、深刻な問題が発生しているため、上記の手順を再度実行する必要があります。単語が nobody である場合、ハッカーはそのユーザー名をよく知っているため、多少問題があります。

関連情報