Thirdware Inc. | 日常化するアタック

日常化するアタック

●imapdへのアタック

2月11日の夕刻頃、imapdを狙ったアタックが観測されたというメールがlinux-security-jpメーリングリストに流れました。報告された方は、対処済みのバージョンのimapdを使っておられたので、わざとアクセスを認める設定にしてみたそうです。すると、数時間後に再度アタックがあり、今度は実際にimapdサーバにログインを試みた記録がログに残されました。

【注】ホスト名、相手側のIPアドレスは書き換えてあります

Feb 11 21:23:38 hostname imapd[32508]: Login failure user=^P^P^P^P^P^(略)P^^

P^P^P^P host=[12.34.56.78]
Feb 11 21:23:39 hostname imapd[32508]: Missing command before authentication

host=[12.34.56.78]
Feb 11 21:23:41 hostname imapd[32508]: Connection reset by peer, while

reading line user=^P^P^P^P^P^(略)^P^P^P^P^P host=[12.34.56.78]

ユーザ名としてきわめて長い文字列を送り込み、サーバ側のバッファオーバフローを狙ったアタックだということが読み取れます。そして、アタッカーはidコマンドで成功したかどうか確認しようとしたそうです。この報告に対して、数人の方から「うちにも来たよ」というフォローがありました。

さらに、アタッカー側のホストに関する情報もいくつか集まりました。このアタックの特徴は、

* ドメイン名からメキシコの大学内のホストと想像でき、telnetへのアクセス制限は行っていないようだ。プロンプトからLinuxマシンと判明。 * 3回アタックを受けた方のログによると、アタック間隔は約2時間半。スクリプトを使った自動運転になっている可能性も考えられる。 * 他の状況も考慮すると、アタッカーは実際には別のところにいて、このホストを踏み台にしている可能性も考えられそう。

などとなりそうです。whoisで調べた管理者に確認メールを送ったそうですが、その結末はまだわかっていません。

●phfの悪用

imapdへのアタックの数日後、私の会社で管理を受託しているサーバに対して、phfスクリプトを悪用したアタックがありました。そのときのログを示します。

dialup107-5-8.foo.com - - [14/Feb/1998:03:33:12 +0900] "GET /cgi-bin/phf?

Qalias=x%0a/bin/cat%20/etc/passwd HTTP/1.1" 404 -

phf の悪用については、以前にも書きました。報告されてから時間が経過しているにもかかわらず、相変わらず繰り返されているようです。最近の各種バイナリパッケージにはphfスクリプトは入っていないようですが、1、2年前にWWWサーバを立ち上げた方は、/cgi-bin/に相当するディレクトリを確認しましょう。

このアタックがなかなか減らない理由は、特別なプログラムを用意しなくてもアタックできること、パスワードファイルをシャドウ化していないサイトだと、ただちに「役立つ」情報が入手できること、などなのでしょう。

●telnetdへのアタック

この原稿を書く数日前、私の会社が管理しているサーバ数台に同一サイトからtelnetdへのアタックがありました。アクセス元はやはり海外、最初のアタックと最後のアタックの間に約2時間のずれがありました。

これらのサーバではtelnetによるインターネット側からのアクセスを禁止、または厳しく制限していましたので、tcp wrapperがアクセスを検出してメールで知らせてくれたのです。

このアタックの対象となったサーバの1台は、2週間ほど前にインターネットに接続したばかり。メールサーバになっていますが、WWWサーバなど世間に知られるようなサーバ機能は持たせていません。それにもかかわらずアタックを受けるということは、「敵」の情報収集力が高いことを示しているような気がします。

●possible SYN flood

私の会社のサーバがpossible SYN floodというメッセージを数日前に出しました。実はこれが2回目だったので、JPCERT/CCの方を交えてアクセス元のサイト管理者とメールで検討を行いました。結論から先に書きますが、この件は意図的なアタックではなく、偶発的な要因が重なった「誤報」だろうという結論に落ち着きました。

Mar 16 12:28:54 myserv kernel: Warning: possible SYN flood from 123.45.67.89

on 98.76.54.32:22926. Sending cookies.

なぜこう判断したか、順を追って説明しましょう。SYN floodは、標的サーバをサービス不能に陥れるアタックのひとつです。TCPでの通信は、クライアントが「サービスを受けたい」というパケットをサーバに送ることから始まります。このパケットはSYNフラグを1にした特別なパケット(SYNパケット)です。

SYNパケットを受け取ったサーバは、接続に応じる場合はSYNフラグと同時にACKフラグを立てたパケット(SYN-ACKパケット)を返します。そして同時に接続を待ち受ける体制に入ります。

正常なクライアントは、ここでACKフラグを立てたパケットを再度送ります。ここでTCPでの通信路(コネクション)が確立するわけです。この過程を3ウェイコミュニケーションと呼びます。

SYN floodアタックは、最初のSYNパケットを送った後で、返ってきたSYN-ACKパケットを無視します。単に無視するだけでなく、アタッカ─はSYNフラグを立てたパケットをサーバに無数に送り付けます。

サーバの資源も有限ですから、きわめて多数のSYNパケットを送り付けられたら、新たなリクエストに応じる余裕がなくなってしまいます。つまり、サーバ機能が働かなくなってしまうのです。

SYN floodアタックを防ぐには、コネクションが確立していないサービス要求の総数を制限することになります。Linuxはセキュリティに敏感に対応しているOSですから、当然最近のカーネルはSYN floodアタックへの対策が可能になっています。

●JPCERT/CCおよびアクセス元への連絡

この件では、同一ホストからの疑わしいメッセージが2回発生したため、JPCERT/CCに連絡し、同時にアクセス元にも問い合わせました。

「疑わしい」と思われる場合でも、決して相手を加害者と決めつけるような表現は避けなければなりません。アドレスの間違いなど単純ミス、こっちの勘違いなどの可能性もあるからです。さらに、別のアタッカーに踏み台にされている可能性もあります。

究明を通じて互いのセキュリティレベルを高めたいという気持ちで、事実を正確に述べ、協力をお願いするのがいいでしょう。JPCERT/CCの方のメールはよく練り上げられていて、警戒心や反発を引き起こさないような配慮に満ちていました。

アクセス元の管理者の方は、該当日時前後のログを調べ、外部からの侵入の可能性も含めた検証を行ってくださいました。そして、踏み台に使われた可能性がないと思われること、メッセージが出たときにアクセスしていたユーザを個人レベルまで特定でき、意図的なアタックはなかったと思われることなどをお知らせいただきました。

それでは、どうしてこのpossible SYN floodというメッセージが出たのでしょうか。それを突き止めないと不安が残ります。

●サーバが接続を受け付けるしくみ

TCP を扱うサーバは、特定番号のポートを開いてクライアントからの接続要求を受け付けます。ポートを開くとき、listen(2)システムコールが使われます。manページを見るとわかりますが、listen(2)にはポート番号(正確にはソケットディスクリプタ)と「バックログ」を指定します。

「バックログ」は、このポートが受け付けられる接続要求の数の上限です。バージョン2.0.xのカーネルでは、SYN floodアタック対策にこの値を使っています。カーネル定数SOMAXCONN (デフォルト値は128)または「バックログ」値の小さい方、または最小値5をmax_ack_backlogとします。

接続待ちのバックログ(ack_backlog)の数は、SYN-ACKパケットを送った時点で1つ増え、コネクションが確立した時点でこれを1つ減ります。

ack_backlogの値がmax_ack_backlogを超えると、possible SYN flood警告メッセージが出るわけです。

●22926番ポートの謎

possible SYN flood警告メッセージが出るメカニズムはわかりました。でも、アタックではないのにメッセージが出るケースとは何なのでしょうか。

そこでログをもう一度調べました。アクセス元は私のサーバの22926番ポートにアクセスしています。これは先方のログでも確認されています。

インターネットで使われるサービスは、通常1023番以下のポートを使っています。22926番ポートというのは、ちょっとおかしいような気がします。

もう一度ログファイル全体を調べてみました。前後のログ行から、アクセス元のユーザはFTPでファイルをダウンロードしていたことが判明しました。これで22926番の謎がわかりました。

FTPではセッションの制御のためのコネクションとは別に、データ転送のためのもうひとつのコネクションが使われます。最初のコネクションには21番ポートが使われますが、データ転送のコネクションを作り出すのに2とおりの方法があります。ここで22926番ポートが登場するのは、パッシブモードと呼ばれる方法です。

パッシブモードでは、サーバが空いているポートを選んで開き、ポート番号をクライアントに通知します。空いているポートということで、このセッションでは 22926番が使われたわけです。クライアントはこのポートに体してコネクションを張り、データ転送が行われます。

私のサーバが使っているwu-ftpdのソースを調べてみると、パッシブモードでのlisten()では、バックログ値が1になっています。すでに確立しているセッションの相手にだけ提示する一時的なポートですので、1という値は自然です。

インターネットでは、混雑によってパケットが捨てられたり大幅に遅延して届くことがあります。サーバが送ったSYN-ACKをクライアントが受け取れず、クライアントが再度SYNパケットを送ってしまう可能性は否定できません。

今回はクライアントアプリケーションの検討はできませんでした。しかし、回線事情の悪化などなんらかの一時的な要因によって、ack_backlog値が大きくなってしまいpossible SYN flood警告メッセージが出たと解釈するのが妥当だと思います。

●教訓

不正アクセスを思わせるログメッセージが出た場合でも、その多くは相手の単純ミスであったり、偶発的な要因が重なり合った結果のメッセージであったりします。

possible SYN flood行だけでなく前後のログメッセージを慎重に検討し、さらに22926番というポート番号の意味に早く気付いていたら、アクセス元管理者などの手を煩わせずに上の結論に到達できたのではないでしょうか。まだまだ修行が必要です。

【Linux Japan Vol.8 掲載記事を加筆修正】

前へ戻る次へ

Search This Site