インターネットに接続し、ＷｅｂやＦＴＰやメールサーバーなどのＴＣＰを使った ネットワークシステムはその攻撃にさらされる。 攻撃の影響はシステムによるが、その攻撃はＴＣＰプロトコルにとって根元的なものである。

　もしあなたがＩＳＰ（インターネット・サービス・プロバイダー）ならSection III と Appendix A に注意してほしい。そこでその攻撃の影響を学ぶ。もしあなたがＩＳＰの顧客なら 彼らにそうするように勧めてほしい。

　この報告書は問題の概説と部分的解決法を提供する。我々が新しい報告を受け取ったときは この報告書を更新する。その時は更新したものをcomp.security.announceに投稿し cert-advisory mailing listで配布する。最新情報はこの報告書の末尾のＵＲＬで 入手できる。

-------------------------------------------------------------

I. Description

　システム（クライアント）がサービスを供給しているシステム（サーバー）に ＴＣＰコネクションを確立しようとするとき、クライアントとサーバーは一連のメッセージを交換する。 この接続方式は全てのＴＣＰコネクション（telnet, Web, email, etc）に当てはまる。

　クライアントはＳＹＮメッセージをサーバーに送り、サーバーがそれを認識しＳＹＮーＡＣＫメッセージを クライアントに送る、クライアントがＡＣＫメッセージで応答することによって コネクションが確立する。そしてクライアントとサーバー間の接続が開かれ、互いにデータを交換することができる。 これはそのメッセージフローである。

　　　　　　　　Client　 　　　　　　　　　Server
　　　　　 　　------　　　　　　　　　　------
　　　　　　SYN-------------------->

　　　　　　　 <--------------------SYN-ACK

　　　　　　ACK-------------------->

　　　　　　　　Client and server can now
　　　　　　　　send service-specific data

　サーバーがまだＡＣＫメッセージを受け取っておらず、認識（ＳＹＮ−ＡＣＫ）をクライアントに返すときに 悪用の可能性が生じる。 これが"half-open" connectionsである。サーバーはシステムメモリーに、 扱っている全ての接続を記述するデータ構造を持つ。それは有限であり、意図的に作り出されたあまりにも多すぎる partially-open connectionsによって溢れさせることができる。

　"half-open" connectionsを作り出すことはIP spoofingによって簡単にできる。 攻撃する側のシステムが攻撃対象のサーバーに対してＳＹＮメッセージを送りつける。 それは正当なものに思えるが、実際はＳＹＮ−ＡＣＫメッセージに返答することはできない システムを照会する。 これは最終的にＡＣＫメッセージが攻撃対象のサーバー送られることがないことを意味する。

　攻撃対象のサーバー上では"half-open" connectionsデータ構造が結局は溢れる。 システムはテーブルが空になるまで入ってくる新しい接続を受け取ることができない。 ふつうは接続がタイムアウトになり"half-open" connectionsが終了し、攻撃対象のシステムは 回復するが、攻撃側のシステムは攻撃対象のシステムが接続を終了させるより早く 新しい接続を要求するIP-spoofed packetsを送り続ける。

　多くの場合、そのような攻撃の犠牲者は新しく入ってくる接続を受け入れることが困難になる。 そのような場合、攻撃は存在している内側への接続に影響することはなく、 外側へのネットワーク接続を生じさせる能力もない。

　しかし、ある場合では、システムはメモリーを使い果たしクラッシュするか、そうでなければ無効になる。 ＳＹＮパケットに含まれるソースアドレスは信用できないので攻撃側のシステムの位置は不明である。 パケットが攻撃対象のシステムに到達しても、それが正しいソースか確かめる方法はない。 ネットワークは目的地のアドレスにもとづきパケットを転送するので、パケットのソースを確認する 唯一の方法はソースをフィルタリングする事である。（Appendix A を見よ）

II. Impact

　インターネットに向けてＴＣＰベースのサービスを行っているシステムは、 攻撃中や攻撃後しばらくはサービスを提供することができなくなるだろう。 サービス自体は攻撃によって害されないが、通常はその能力が弱められる。 ある場合は、システムはメモリーを使い果たしクラッシュしするかあるいは無効になる。

III. Solution

　現在のＩＰプロトコル技術が持つこの問題の解決は今のところ無い。 しかし適切なルーターの構成で、あなたのサイトがこのような攻撃の源泉になる可能性を 減らすことはできる。

　Appendix Aはあなたのネットワークに存在したり入ってきたりするIP-spoofed packets を減らすために、どのようにパケットフィルターを行うかが記されている。 またこのようなフィルターを援助する売り手のリストを含む。

　ＩＳＰへ：我々はこの種の攻撃から顧客を守るために、それらのフィルターを ルーターにインストールすることを強く勧める。 これらのフィルターはあなたの顧客を攻撃から直接守ってはくれないが、 攻撃があなたの顧客のサイトで発生するのを防ぐ。 我々はいくつかのMobile IP体系上でのそれらのフィルターの結果について気づき、 適切な組織からの声明を求めている。

　ＩＳＰの顧客へ：我々はあなたのネットワークを守るために必要なフィルターを 設けているかをあなたのＩＳＰに確認することを勧める。

　多くの技術者がＩＰを改良してこの種の攻撃に耐えうるようにするために働いている。 改良が行われたら、できるだけ早くそれらをあなたのシステムに使うことを勧める。 この報告書は売り手の動向を反映して更新する。

IV. Detecting an Attack

　攻撃されたシステムのユーザーは、IP-spoofedコネクションの要求が著しくシステムを 圧迫しないので、ふつうは気づかないだろう。 システムはまだ外への接続を確立することができる。 この問題のほとんどは、攻撃されたシステムのサービスにアクセスを試みたクライアントによって 発見される。

　この攻撃が行われているか確かめるには、システムのネットワークトラフィックの状態を チェックすればよい。たとえばＳｕｎＯＳではこのコマンドを用いる。

　　　　　　　netstat -a -f inet

　多くのコネクションが"SYN_RECEIVED"という状態にあることはシステムが攻撃されていることを示している。

.......................................................................................................................................................................

Appendix A - Reducing IP Spoofed Packets

1. Filtering Information
- - -------------------------

　現在のＩＰプロトコル技術ではIP-spoofed packetsを排除することは不可能だが、 それがあなたのネットワークに存在したり入ってくるのを減らすことはできる。

　現在最も良い方法は、もしそれがあなたのネットワーク内のソースアドレスを持つなら、 通過を許さないことによってインターフェイスへの入力を制限する、 フィルタリングルーター（インプットフィルターと呼ばれる）をインストールすることである。 さらに、IP-spoofing攻撃があなたのサイトから発生することを防ぐために、 あなたのネットワーク内のものとは異なるソースアドレスを持って外部へ出てゆくパケットを フィルターすべきである。

　これら２つのフィルターによって、外部の攻撃者があなたにネットワーク内にいるふりをして パケットを送りつけるのを防ぎ、またあなたのネットワーク外にいるふりをしてあなたのネットワーク内 でパケットが発生するのを防ぐ。 これらのフィルターは全てのTCP SYN 攻撃をなくすことはできない。 なぜなら外部の攻撃者はどこかの外部のネットワークからパケットを偽ることが でき、内側の攻撃者はまだ内側のアドレスを偽った攻撃を送ることが可能であるからだ。

　我々はＩＳＰにこれらのフィルターをインストールすることを強く勧める。

　またＩＳＰの顧客には、あなたのネットワークを守るために必要なフィルターを 設けているかをあなたのＩＳＰに確認することを強く勧める。

2. Vendor Information
- - ----------------------

　下記の売り手はこの種のフィルターをサポートし、どのようなルーターの構成にすればよいのか 助言をしてくれる。もしあなたがファイアーウォールやルーターについての情報が必要なら 直接連絡を取ってほしい。

Cisco
-----
Refer to the section entitiled "ISP Security Advisory"
on http://www.cisco.com for an up-to-date explanation of
how to address TCP SYN flooding on a Cisco router.

　売り手へ：もしここに載っていないルーターの性能や構成についての情報があれば下記のContact Information section にあるCERT Coordination Centerに知らせてほしい。 あなたから聞いたことによってこの報告書を更新する。

3. Alternative for routers that do not support filtering on the inbound side
------------------------------------------------------------

　もしあなたの売り手のルーターがインターフェイスへのフィルタリングをサポートしていなかったり、 そうすることに遅延が生ずるならあなたはインターフェイスと外部のコネクションの間に第２のルーターを 置いて、IP-spoofed packetsをフィルターできる。 あなたの最初のルーターに接続されているインターフェイス上に、あなたの内部ネットワークのソースアドレス を持つ全てのパケットを遮断するルーターを置く。 この目的のためにあなたはフィルタリングルーターを使うか、パケットフィルタリングをおこなう ２つのインターフェイスを持つＵＮＩＸシステムを使うことができる。

　注意：ルーターでソースルーティングができないと攻撃から守ることができないが、 しかしまだ良いセキュリティー手段がある。

　インターネットからあなたのネットワークへ来る、あなたのインターフェイスへの入力を 以下のアドレスを使ってパケットを遮断すべきである。

* Broadcast Networks: The addresses to block here are network 0 (the all zeros broadcast address) and network 255.255.255.255 (the all ones broadcast network).

* Your local network(s): These are your network addresses

* Reserved private networks: The following networks are defined as reserved private networks and no traffic should ever be received from or transmitted to these networks through a router:
10.0.0.0
127.0.0.0
172.16.0.0
192.168.0.0

-------------------------------------------------------------

The CERT Coordination Center staff thanks the team members of NASIRC for contributing much of the text for this advisory and thanks the many experts who are devoting time to addressing the problem and who provided input to this advisory.
--------------------------------------------------------------

If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (see ftp://info.cert.org/pub/FIRST/first-contacts).

CERT/CC Contact Information
- - ----------------------------
Email cert@cert.org

Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) /EDT(GMT-4) and are on call for emergencies during other hours.

Fax +1 412-268-6989

Postal address
CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 USA

Using encryption
We strongly urge you to encrypt sensitive information sent by email. We can support a shared DES key or PGP. Contact the CERT/CC for more information.
Location of CERT PGP key
ftp://info.cert.org/pub/CERT_PGP.key

Getting security information
CERT publications and other security information are available from
http://www.cert.org/
ftp://info.cert.org/pub/

CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce

To be added to our mailing list for advisories and bulletins, send your email address to
cert-advisory-request@cert.org

---------------------------------------------------------------
Copyright 1996 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included.

CERT is a service mark of Carnegie Mellon University.
--------------------------------------------------------------

This file: ftp://info.cert.org/pub/cert_advisories/CA-96.21.tcp_syn_flooding
http://www.cert.org
click on "CERT Advisories"

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~