IT業界は現在まで発展して、安全問題はすでに重要になって、最近の“プリズムゲート”事件の中から、多くの安全問題を屈折して、情報の安全問題はすでに一刻も猶予できないようになって、運営者として、いくつかの安全運営の準則を理解しなければならなくて、同時に、自分の責任を負う業務を保護して、まず攻撃者の角度に立って問題を考えなければなりません。潜在的な脅威と脆弱性を修正します。

次の例では、1つのサーバがrootkitに侵入された後の処理構想と処理過程を紹介し、rootkit攻撃はLinuxシステムの下で最も一般的な攻撃手段と攻撃方式である。

これは1台の取引先のポータルのウェブサイトのサーバーで、電信機の部屋で管理して、取引先は電信の通知を受け取ります:このサーバーが対外的にパケットを送信し続けるため、100 Mの帯域幅が尽きて、そこで電信はこのサーバーのネットワークを切断しました。このサーバはCentos 5です。5バージョンでは、80、22ポートが公開されています。

お客様によると、Webサイトへのアクセスはそれほど多くないため、帯域幅の占有量もそれほど高くなく、100 Mの帯域幅を消費することは絶対に不可能であり、サーバがトラフィック攻撃を受けた可能性が高いため、サーバにログインして詳細な検出を行います。

通信者の協力のもとでスイッチを通じてサーバーのネットの流量に対して検査を行って、このホストが確かに対外80ポートのスキャンの流量が存在することを発見して、そこで登録システムは“netstat–an”の命令を通じてシステムの開いたポートに対して検査を行って、不思議なことに、80ポートと関係があるネットの接続を発見していません。次に「ps–ef」、「top」などのコマンドを使用しても、不審なプロセスは見つかりません。そこでシステムがrootkitに移植されたかどうか疑問に思った。

システムにrootkitがインプラントされているかどうかを証明するために、ウェブサイトサーバのps、topなどのコマンドを、以前バックアップした同バージョンの信頼できるオペレーティングシステムコマンドとmd 5 sumチェックした結果、ウェブサイトサーバの下の2つのコマンドが確かに修正されていることがわかり、このサーバーが侵入し、rootkitレベルのバックドアプログラムがインストールされていると判断しました。

サーバは絶えず外部に発注されるため、まずこのサーバをネットワークから切断し、システムログを分析し、攻撃源を探すことです。しかし、システムコマンドは既に置き換えられており、このシステムで操作を継続すると信頼できなくなります。ここでは、このサーバのハードディスクを取り外して別の安全なホストにマウントして分析する2つの方法で回避できます。もう1つの方法は、同じバージョンの信頼性のあるオペレーティングシステムからすべてのコマンドをこの侵入サーバの下にあるパスにコピーし、コマンドを実行するときにこのコマンドの完全なパスを指定することです。ここでは2つ目の方法を採用します。

まず、システムのログインログを確認し、不審なログイン情報があるかどうかを確認し、次のコマンドを実行します。

more /var/log/secure |grep Accepted

コマンド出力の表示により、次のような疑問が生じるログがあります。

Oct 3 03:10:25 webserver sshd[20701]: Accepted password for mail from 62.17.163.186 port 53349 ssh2

このログは10月3日の午前3時10分に表示され、62.17.163.186というIPからメールアカウントがシステムにログインしました。mailはシステムの内蔵アカウントで、デフォルトではログイン操作ができませんが、62.17.163.186というIPは、アイルランドからのアドレスです。mailアカウントのログイン時間から見ると、このサイトのサーバが攻撃を受けた時間より早い。

次に、システムパスワードファイル/etc/shadowを確認します。また、不審な情報が見つかりました。

mail:$1$kCEd3yD6$W1evaY5BMPQIqfTwTVJiX1:15400:0:99999:7:::

明らかに、mailアカウントにはパスワードが設定されており、リモートログイン可能に変更されています。mailアカウントを使用するのは、侵入者が隠れたアカウントを残して、後でシステムに再ログインしやすいようにしたいからかもしれません。

次に、/var/log/messages、/var/log/wtmpなどの他のシステムログを表示し続けます。侵入者はシステムログファイルをクリーンアップしましたが、なぜ/var/log/secureファイルが空になっていないのかは分かりません。

これまで、mailアカウントがシステムにログインしたことがあることを知っていましたが、なぜこのサイトのサーバがパケットを対外的に送信し続けるのでしょうか。対応する攻撃源を見つける必要があります。このサーバのpsコマンドに置き換えて、システムが現在実行しているプロセスを確認し、新しい不審なものを発見します。

nobody   22765     1  6 Sep29 ?        4-00:11:58 .t

これtプログラムは何ですか。topコマンドを実行し続けた結果、次のようになりました。

PID USER    PR  NI  VIRT  RES  SHR  S  %CPU %MEM    TIME+  COMMAND

22765 nobody  15  0   1740m 1362m 1228  S  98.3    91.5      2892:19   .t

出力から分かるように、このtプログラムはすでに4日ほど実行されており、このプログラムを実行しているのはnobodyユーザーであり、このtプログラムは大量のメモリとcpuを消費している。これも以前の顧客が反映したウェブサイトサーバーが異常に遅い原因であり、この出力から、tプログラムのプロセスPIDは22765であり、次にPIDに基づいてプログラムを実行する経路がどこにあるかを検索した。

メモリディレクトリに入り、対応するPIDディレクトリの下にあるexeファイルの情報を表示します。

[root@webserver ~]# /mnt/bin/ls -al /proc/22765/exe 

lrwxrwxrwx 1 root root 0 Sep 29 22:09 /proc/22765/exe -> /var/tmp/…/apa/t

これにより、/var/tmpディレクトリのデフォルトのユーザー可読性のため、侵入者はこの脆弱性を利用して/var/tmpディレクトリの下に「...」ディレクトリを作成し、このディレクトリの下に攻撃のプログラムソースを隠して/var/tmp/.../ディレクトリに入ります。侵入者が配置したrootkitファイルがいくつか見つかりました。リストは次のとおりです。

[root@webserver ...]#/mnt/bin/ls -al

drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 apa

-rw-r--r-- 1 nobody nobody     0 Sep 29 22:09 apa.tgz

drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 caca

drwxr-xr-x 2 nobody nobody 4096  Sep 29 22:09 haha

-rw-r--r-- 1 nobody nobody      0Sep 29 22:10 kk.tar.gz-

rwxr-xr-x 1 nobody nobody      0 Sep 29 22:10 login

-rw-r--r-- 1 nobody nobody      0 Sep 29 22:10 login.tgz

-rwxr-xr-x 1 nobody nobody      0 Sep 29 22:10 z

これらのファイルの分析を通じて、これが私たちが探しているプログラム攻撃源であると基本的に判断します。

1)、zプログラムは、システムログなどの関連情報を消去するために使用され、例えば実行される。

./z 62.17.163.186

このコマンドが実行されると、62.17.163.186に関連するすべてのログが消去されます。

2)、apaディレクトリの下にバックドアプログラムtがあります。これは前にシステムで見たものです。このプログラムを実行すると、このプログラムは自動的にapaディレクトリの下のipというファイルを読みます。ipというファイルには各種のipアドレス情報が記録されています。このtプログラムはipファイルに記録されているすべてのip情報をスキャンし、リモートホストの権限を取得するべきだと思います。このサイトのサーバーはすでに侵入者の肉鶏であることがわかります。

3)、hahaディレクトリには、システムに関するコマンドを置き換えるためのプログラムが配置されています。つまり、このディレクトリの下のプログラムでは、オペレーティングシステムの異常を見ることができません。

4)、loginプログラムは、システムログインプログラムを置き換えるための木馬プログラムであり、ログインアカウントとパスワードを記録することもできる。

ここまで、サーバーで受けた攻撃はほぼ明らかになっていますが、侵入者はどのようにこのサーバーに侵入したのでしょうか。この問題は重要で、侵入の根源を見つけてこそ、根本的に抜け穴を封じることができる。

侵入者がどのようにサーバーに入ったのかを明らかにするには、このサーバーのソフトウェア環境を知る必要があります。このサーバーはjavaベースのwebサーバーで、インストールされているソフトウェアはapache 2があります。0.63、tomcat5.5,apacheとtomcatの間はmod_を通りますjkモジュールは統合され、apacheは80ポートを外部に開放し、tomcatは外部に開放されていないため、問題をapacheに集中します。

apacheの構成を見ることにより、apacheは静的リソース要求のみを処理するが、ウェブページも静的ページが多いため、ウェブページ方式でシステムに侵入する可能性は低い。脆弱性がapacheから来ている可能性がある以上、apacheログを見てみると、不審なアクセス痕跡が発見され、accessを見ることができるかもしれない。logファイルでは、次の情報が見つかりました。

62.17.163.186 - - [29/Sep/2013:22:17:06 +0800] "GET http://www.xxx.com/cgi-bin/awstats.pl?configdir=|echo;echo;ps+-aux%00 HTTP/1.0" 200 12333 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1) Gecko/20121010 Firefox/2.0"

62.17.163.186 - - [29/Sep/213:22:17:35 +0800] "GET http://www.xxx.com/cgi-bin/awstats.pl?configdir=|echo;echo;cd+/var/tmp/.../haha;ls+-a%00 HTTP/1.0" 200 1626 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1) Gecko/20121010 Firefox/2.0"

これで、抜け穴の根源が見つかったのはawstatsだった。plスクリプトのconfigdirの脆弱性は、このサーバのアプリケーションを理解することによって、お客様は確かにAwstatsのオープンソースプラグインを通じてWebアクセス統計を行い、この脆弱性を通じて、攻撃者は直接ブラウザ上でサーバを操作することができます。例えば、プロセスの表示、エントリの作成などです。上記の2番目のログから、攻撃者が通常のブラウザで/var/tmp/.../に切り替えることがわかります。hahaディレクトリの操作。

このシナリオの脆弱性は恐ろしいですが、Awstatsの公式サイトでもすでに修正方法が提供されています。この脆弱性については、修復方法が簡単で、awstatsを開きます。plファイル、次の情報を見つけます。

if ($QueryString =~ /configdir=([^&]+)/i)

{

$DirConfig=&DecodeEncodedString("$1");

}

修改为如下即可：

if ($QueryString =~ /configdir=([^&]+)/i)

{

$DirConfig=&DecodeEncodedString("$1");

$DirConfig=~tr/a-z0-9_\-\/\./a-z0-9_\-\/\./cd;

}

上記の段階的な分析と紹介を通じて、このサービスが侵入された原因と過程はすでに明らかになっており、大まかな過程は以下の通りである。

(1)攻撃者はAwstatsスクリプトawstatsを通過する.plファイルの脆弱性はシステムに入り、/var/tmpディレクトリの下に隠しディレクトリを作成し、rootkitバックドアファイルをこのパスの下に転送します。

(2)攻撃者はバックドアプログラムを植え込むことで,システムスーパーユーザ権限を取得し,さらにこのサーバを制御し,このサーバを介して外部に発注する.

(3)攻撃者のIPアドレス62.17.163.186はエージェントによって来た可能性があり,攻撃者が制御する他の肉鶏サーバである可能性がある.

(4)攻撃者はこの機器を永続的に制御するために,システムのデフォルトアカウントmailの情報を修正し,mailアカウントをログイン可能にし,mailアカウントのパスワードを設定した.

(5)攻撃者は攻撃が完了した後,バックドアプログラムによりシステムアクセスログを自動的に整理し,証拠を破壊した.

この侵入過程の分析を通じて、侵入者の手段は依然として非常に簡単で普遍的であることを発見し、侵入者はシステムのいくつかのログを削除したが、多くの調査可能な跡を残し、実際にはユーザーの下を見ることができる。bash_historyファイル、このファイルはユーザー操作コマンドの履歴です。

システムはファイルが変更され、置き換えられたため、システムは完全に信頼できなくなったため、Webサイトのデータをバックアップし、システムを再インストールすることをお勧めします。基本的な手順は以下のとおりです。

(1)安定したバージョンのオペレーティングシステムをインストールし、システムのデフォルトで不要なユーザーを削除する。

(2)システム登録方式を公開鍵認証方式に変更し,暗号認証の欠陥を避ける.

(3)より高いバージョンのapacheと最新の安定バージョンのAwstatsプログラムをインストールする.

(4)LinuxでのTcp_の使用Wrappersファイアウォールは、sshログインのソースアドレスを制限します。