電子メール爆撃と SPAM 図 3 check-relay ルールセット列 F{DeniedIP} /etc/DeniedIP F{DeniedNames} /etc/DeniedNames Scheck—reIay R$ + 引 $={DeniedIP}$* → R$*$={DeniedNames} 引 $ * → $#error $ 5 . 7.1 $ : $#error $@ 5 . 7.1 $ : と、そのホストは自ホスト宛のメールだけを受信するよう こで、、、自ホスト宛 " とは何かを知る簡便 になります。 Enter く ruleset> く address> invoked) ADDRESS TEST MODE (ruleset 3 NOT automatically csh% sendmail —bt テストモードで起動します。 な力法を紹介します。 sendmail に -bt オプションを付け、 56 パイルした sendmail を使う必要があります。 ョンとして、、—DTCPWRAPPERS=I" を指定してコン このルールセットを利用するには、コンパイル・オプシ いことがあります。 している場合は、 check-relay ルールセットと併用できな Ⅵ第Ⅱ Tool Kit) の smap などの SMTP proxy を使用 用されているときだけです。したがって、 FWTK (Fire- されるため、有効なのは sendmail がデーモンモードて漣 す。 check-relay は SMTP コネクションの接続中に適用 て得たホスト名の情報をもとにメール受信の可否を決めま 続を要求した相手の IP アドレス、およびそれを逆引きし check-relay ルールセットでは、 SMTP ポートへの接 checka•elay e d0 not support relaying ・ xx ・ (p) reJection: 571 sirasaki@xxx ・ xx ・ JP ・ check—compat (sirasaki@xxx.xx ・ JP , sirasaki@xxx Jun 18 15 : 41 : 55 mailer sendmail [ 4719 ] : Ru1eset メッセージを syslog に出力します。 ないメールが送られると、 sendmail は次のようなエラー 図 2 のルールセットを設定したホストに自ホスト宛で を指します。 してこれらのアドレスのうちのいすれかカ甘旨定されたもの が表示されます。、、自ホスト宛 " のメールとは、送信先と イン名をイ寸加したもの、ホストの IP アドレスなどの情報 こで、 $=w と入力すると、ホスト名やホスト名にドメ ーⅡ 0 access from your IP address" Ⅱ 0 access from your hOSt" 通常、このルールセットを利用する場合は、攻撃元の IP アドレス、ホスト名やドメイン名を列挙した、、プラッ クリスト " を用意します。このリストを設定すると、そこ に列挙されたホストからの SMTP 接続を拒否するように なります。 ルールセットは、 SMTP の MAIL FROM コマンド を実行する前に適用されます。接続を拒否した場合はそれ 以後のセッションが中断されるため、言算機資源をそれ はど浪費することはありません。したがって、攻撃元の ホストやドメインがあらかしめ分かっているような場合に は、 check•elay によって攻撃を効果的に防ぐことができ ます。とくに、 SPAM は特定のサイトから発信される場 合が多いので、このルールセットを用いたガ去は効果があ ると考えられます。 ところが、このルールセットによるカ 1 去には次の 2 つ の欠点があります。 1. 接続を拒否するプラックリストを必要に応じて史新しな ければならない。 2. プラックリストにあるサイトやホストの管理者からのメ ールい色してしまうため、管理者間の連係か保てなく なる。 check-relay ルールセットを用いた例を示し 図 3 に、 ます。メール受信を拒否したいホストの IP アドレスのリ ストを /etc/DeniedIP ファイルに、ホスト名やドメイ ン名のリストを /etc/DeniedNames ファイルに記述 したうえで、このリストを sendmail.cf の一番最後に追 加します。 どちらかのファイルがない場合は、 sendmail は次のよ うなエラーを syslog に出力して起動に失敗します。 Jun 18 16 : 36 : 24 mailer sendmail [ 4761 ] : NOQUEUE SYSERR(root) : /etc/sendmail . cf : line 1133 : f ileclass : cannot open /etc/DeniedIP: NO such f i1e 0 て directory UNIX MAGAZINE 1997.9

蓄は資産保第。 妄れたに突やってくるティスククラッシ テータをしてかその復旧に募大なコストをかけるかを そとも万一を定したクステムに先行規第をするか。 第大な信新をるつのソリ 0 ーシンかを あなた々第の大切なテータ資産をしつかり保第し第す。 テジタルテクノロジーから発信 RA 旧ディスクアレイ C しシリース 規模の大を問わす、し AN のデータストレージ に最適。システムダウンを回避し、 万一の時にも修復するので安心、、 6 ・障害時にもデータアクセスが可能。 ・ディスク障害時にはグレーバルスペア機能によ データを自動再構築。 ・ミラー化キャッシュと内蔵バッテリによりキャッシュ上の データも保護。 ・電源 ON 状態で構成バーツのホットスワップが可能。 [ 仕様 ] ホストインターフェース : Fast Wide SCSl-2 (differential) / ディスク数 : 7 ドライブ、 1 0 ドライブ、 20 ドライブ、 30 ドライブの 4 シリーズ / ディスクドライブ : 4GB 、 9GB [ 対応 OS]Solaris 、 Sun OS 、 WindowsNT 、 AIX 、 Digital UNIX adiC ロ T バックアップシステム 大容で高速、し AN 全体のバックアップを 完全化します。 ・新 T (Digital Linear Tape) を使用。 従の 7 / 8mm システムに比べ、容量 5 倍、 度音のバックアップ環境を実現。 ・専用のバックアップソフト NetWorker との併 用より、手間のかかるバックアップ作業を効率 よく自動化。 [ 仕様 ] ホストインターフェース : Fast Wide SCSl-2/ 記録容量 : 490GB ( 2 倍圧縮想定時 ) [ 対応 OS]SoIaris 、 Sun OS 、 HP-UX 、 WindowsNT 、 AIX 、 NetWare 物・物第を第′ ※記載の社名・商品名は各社の商標または登録商標です。 国内代理店 「資料請求」は当社 www サーバーまで デジタルテワノロジー株式会社 DIGITAL TECHNOLOGIES CORPORATION 本社 : 〒 116 東京都荒川区東日暮里 5-7-18 コスモバークビル TEL. 03 ( 5604 ) 7801 ( 代表 ) FAX. 03 ( 3802 ) 3400 大阪支店 : 〒 532 大阪市淀川区宮原 3-5-24 新大阪第一生命ビル 4 階 TEL. 06 ( 398 ) 1201 FAX. 06 ( 393 ) 1800 資料請求 No. 041 http://www.dtc.co.jp/ ・中途採用募集中。 詳しくはホームページをご覧ください。

図 1 ハイバーテキストによるⅥ ' Ⅵ广念図 文書 A あっぷるの秘密 出身地 : 秘密 生息地 : 三森 : ・・ 好物 : 三バナナ : ・ だんな : : monkey : ・ 文書 B ・ >monkey の生活 出身地 : サル山 生息地 : 三森ト・ 好物 : : バナナ : ・・ 奥さん : : あっぷるト ホスト A ホスト D ホスト C ネットワーク 森を守ろう 適した気候ン・・ 生えてる木 - りんご - : バナナい - 幸福の木 気候テータベース・・ 降水量 年平均気温 日照時間 バナナの秘密 甘い・黄色い 長い・中は白 踏むとすべる 冷凍もうまい ホスト B タで、 W 、 VW サーパーといいます。 WWW サーバー すが、コンピュータ上にある辞書なら簡単にできてしまい は世界中に存在しており、それぞれがインターネットに接 ます。実際のハイバーテキストの例としては、 Windows 続されて情報を提供しています。これが広域分昔比いう のヘルフや Macintosh のハイバーカードなどか挙げられ 方式です。この方式の利点は、ディスク容量などの資源的 るでしよう。 Windows のヘルプの場合、ある事柄の説 制約がある場合でも、情報をあちこちのサーバーにう靖攵さ 明文中に色か変わっている部分があり、そこをマウスでク せて互いに参照することによって、ひとつの大規模な↑帯長 リックすると、その説明や画面ダンフ。か表示されたりしま を提供できるようになることです。また、ある事柄に関す す。これぞまさしくハイバーテキストです。 るすべての情報を個人で提信けるのカ吠変な場合でも、関 ハイバーテキストについてごちやごちゃと説明しまし 連した情報を公開している WWW サーバーを参照するよ たが、一度でも WWW を覗いたことのある方であれば、 うにすれは、より有益囹青報とすることかできます。 「ああ、リンクのことね」とうなすいてもらえると思いま す。リンクについてはすこしあとで詳しく説明します。リ たとえば、図 1 のホスト A の文書 B では、「 monkey ンクがハイバーテキストのすべてではありませんが、もっ の舌」という情幸甘是供されています。そのなかの「森」 とも大きな特徴であることはたしかです。 は、ホスト D にある「森を守ろう」という情報を参照し WWW は、世界中にあるハイバーテキストによる情報 ています。図では、この参照関係を点線て表しています。 を自由に閲覧できるシステムですが、そのイ督はみは、、サー 同様に、ホスト D の「適した気候」はホスト C にある " と、、クライアント " から構成されています。図 1 は、 「気候データベース」を参照するようにしてあります。 WWW を利用したハイバーテキスト情報の提信彬態の概 のように、ネットワークにつながれていれば、物理的に異 なる WWW サーバー上刎青報を参照しあうことかできま 念図です。現実のインターネット上の WWW も、これ す。また、ホスト A のように、同一のコンピュータ上の を拡張していったものです。 情報を柤こ参照することもできます。 図中のホスト A ~ D が清報を提供しているコンピュー 14 UNIX MAGAZINE 1997.9

工ンタープライズネットワーク環境に必要な TCP ハ P スタックを超える信頼の PC ネットワークソリューション WRQ の RefIection が答えです。 乗り換えキャンへ ーン 実施中 8 月 1 日 1 2 月 31 日 Ref 厄 ction こそが必要とされている PC ネットワークソリューションです。 複雑なエンタープライズ環境では、ネットワーク 上の問題に対処するための信頼の高いソリュー ションが必要です。 WRQ RefIection Suite for TCP がすべてを解決します。 △卓越した相互運用性 既存のシステムおよびオープンスタンダードを包括的に サポートし、主要プロトコル間での完全な コネクティビティを実現します。 △簡単なコネクティビティ ローカル、リモート、イントラネット / インターネットを介して各種工ンタープライ ズネットワーク上のホストアプリケーションや サービスに PC から簡単にアクセスできます。 △多彩なカスタマイズ・プログラミングッールと クライアント / サーバ機能 ホストへのログイン作業の自動化や、 クライアント / サーバ環境の構築等のための 豊富なツールが装備されています。 △優れたネットワークデスクトップ管理ツール ネットワーク統計と診断ユーティリティが システム管理者の問題解決をサポートします。 Reflection and E 即 55 50 wa 爬 WRQ,Inc./ Dexter Avenue North, Seattle, Washington 9 別 , USA Tel : + ト 206-2 ロ -71( 用 Fax : + ト 206-217-0 円 6 lNTERNET:info@wrq.com WEB:http://www.wrq.com 01997WRQ3nC. AII Rights reserved. WRQ,WRQ ロゴおよび RefIection はアメリカ国内および他の国における WRQ,lnc. の登録商標です。 その他のブランド名および製品名は各社の商標または登録商標です。 ロロ 今なら無料で最高のコネクティビテイソフトウェアを お試しいただけます。 期間限定でこ試用いただける W 日 Q Reflection 製の 無料評価版のお申し込みまたはお問い合わせは、 下記販売代理店まで今すぐどうぞ。 ホームページからもダウンロードできます。 を : WRQ's Reflection somtare iS it. 、 VRQ には、ターミナルエミュレーション および TCP / IP のデザインとテストの 分野で 16 年に渡る実績があります。 サ ( ネ当トステム貳各社 販売元 WRQ 本社 / 1 1 2 東京都文京区大塚 2 丁目 1 5 番 6 号ニッセイ音羽ビル 電話 03-5978-5453 FAX03-5978-5441 大阪支社 / 542 大阪市中央区南船場 4 丁目 2 番 4 号日本生命御堂筋ビル 電話 06-241-5241 FAX06-241-1 255 lNTERNET:rinfo@cybernet.co.jp WEB:http://www cybernet. co.jp ※記載された製品名は、すべて各社の商標または登録商標です。 RefIection Suite for TCP fo 「 Windows95 / NT 日本語版 マルチプロトコルスタック (TCP/IP 、 LAT 、 IPX/SPX 、 PPP 、 S 凵 P/CS 凵 P) ・デスクトップ管理 ( イベントログ、イベントビューワー、トレースルート、 ホスト接続 (VT382/VT420 、 SCO-ANSISBBS-ANSI ターミナルエミュレータ ) SNMP M 旧Ⅱ ) インターネットツール ( MS lnte 「 net Exp 「 e 「 : Web クライアント ,lnte 「 net ・インストール ( サーバインストール、サーバマネーシャ ) MaiI 、 Netmeeting 含む ) ・リモート & モバイル通信 ( Re 利 ection Smart Stack 、ダイナミックリンクリカ イントラネットアフリケーション ( NFS クライアント / アドミニストレータ、 FTP クライアント / サーバ、 LPR/LPD 、 Finger クライアント / サーバ、他 ) 資料請求 No. 053

連載 /UNIX Communication Notes 通常、初期化処理は、 socket() システムコールによる ソケットの生成と、 bind() システムコールによるロー カルなアドレス情報の付加によって終了する。 しかし、 UNIX MAGAZINE 1997.9 い川、この処理は省略する。 いれは ( つまり、 PCB にアドレスの情報がイ求されて によって、ソケット単位でアドレス情報が与・えられて PCB に登録する。事前に connect() システムコール て指定された受信ホストの IP アドレスとポート番号を 1. 最初に in-pcbconnect() を使って、システムコール こなわれる。具ー勺には、次の手順て実行される。 である。つまり、実際の送信処理は udp-output ( ) でお return (udp—output ( case PRU_SEND : れは分かるように、これに対応した処理は、 をともなって呼び出される。 udp-usrreq() の実装をみ イ勺な処理としては、 udp_usrreq() か引数 PRU_SEND ステムコールに対応しておこなわれる。カーネル内での具 UDP の送信処理は、 sendto() または sendmsg() シ 送信里 手ホストのアドレス情報をえる。 とに in-pcbconnect ( ) を呼び出し、 PCB に対して相 コールに対応した処理をおこなうときにシステムコールご 場合、カーネル内で udp_output ( ) がこれらのシステム スト ) のアドレス情報をえて送信処理をおこなう。この われる。これらのシステムコールは、相手ホスト ( 受信ホ 信には sendto() または sendmsg() システムコールが使 UDP を用いたソケットでは、通常のメッセージの送 スを指定する手間を省くことができる。 する。こうすれは、 UDP において送信処理ごとにアドレ PCB に相手ホストのアドレスとポート番号の情報を↑内 in-pcbconnect ( ) か呼はれ、そのソケットに関連する PRU-CONNECT をともなって呼び出される。これによって、 システムコールが呼ばれると、 udp-usrreq() が引数 相手を指定しておくことができる。この場合、 connect() 合は、 connect() システムコールによって、事前に通信 ば、通信相手のホストとポートがすでに分かっている場 使って受信ホストの情報を与・えることができる。たとえ UDP のソケットの場合も connect() システムコールを 2. UDP 擬似ヘッダを用意する。これは、さきほど説明し たようにチェックサムの計算だけに使われる。この処 理では、 M-PREPEND を用いて UDP 擬似ヘッダを表す 構造体 struct udpiphdr の大きさをもつ領域を確保 し、さらに、それを UDP メッセージの前に追加する。 その後必要なアドレス↑帯になどを設定する。 3. チェックサムの計算をする。これには、 IP のチェック サム算と同し関数 in-cksum() が使われる。チェッ クサムの結果が 0 になった場合は、 ui—>ui_sum = Oxffff ; というように a ル 1 の表現に書き換える。 カーネルの生成において、オプションとして COMPAT-42 意 ない。 る。 報か事前にケえられている場合は、この処理はおこなわ コールによって相手ホストのアドレスとポート番号の情 する。もし、ソケットに対して、 connect() システム の IP アドレスとポート番号の情報を PCB から解放 nect ( ) を呼び出し、送信処理前に登録した相手ホスト 5 ・ ip-output() の処理か終了すると、 ip-pcbdiscon- ip-output ( ) を呼び出して IP 層の送信処理を実行す 4. こまでで必要な UDP メッセージが用意できたので、 がおこなわれると考えてよい。 んどないので、 UDP?ÄO ケットではかならすチェックサム言 t 算 去も丘は COMPAT ー 42 を指定してカーネルを生成することははと す、どの UDP メッセージに対しても 0 を設定する。ただ、 カ甘旨定されていた場合、 UDP チェックサムの言算はおこなわ れた udp-input ( ) か起動される。 udp-input ( ) では、 起動される。この場合は、プロトコル・スイッチに指定さ 受信処理は、 IP 層からのソフトウェア割込みによって 受信里 次の手順で処理がおこなわれる。 1. ます、 IP 層から渡されたデータをチェックする。 は、次のようなポイントを調べる。 ・ IP と UDP のヘッダは適正な長さか。 ・ UDP メッセージ長は正しいか。 ・ UDP チェックサムは正しいか。 これ 51

電子メール爆撃と SPAM あるサイトでの例 こで、現実に中継攻撃を受けた国内のサイトでの対応 か読行されましたが、相変わらすサイト外からサイト外へ その後、効果を石忍するため sendmail ログのチェック よって、悪用が防げるのではないかと思われました。 ルヘッダから発信元のトレースが可能になります。これに 元の IP アドレスがヘッダに付加されるようになり、メー これらの対策を講したため、メールを中継する際に送信 ダに残すように設定されます ) 。 この種のメールを中継した際に相手の IP アドレスもヘッ ファイルから m4 を用いて生成した sendmail.cf では、 した (sendmail 8.8.5 の /cf/cf にある generic のマクロ した。これを記載するように sendmail.cf カイ多正されま の IP アドレスがヘッダに表示されない設定になっていま のホストでは、メールの中和こメールを受け取った相手 報カ甘是供されました。中継攻撃を受けた点で、サイト A ダの管理者と、攻撃を受けた米対の大学の管理者に調査情 ログを調査したあと、発信元のシンガポールのプロバイ いることも分かりました。 者情報は偽造されており、イ為のメールアドレスか書かれて に送信されていたことカ喇明しました。そのメールの送信 トで中継さ米対の大学のメーリングリスト・サーバー から発信されたものであり、それがサイト A のあるホス 間題のメールはシンガホールのあるプロバイダのユーサー ローズし、 sendmail のログを調査しました。その結果、 サイト A では、該当するホストの SMTP ポートをク かに調査し、適切なる対処をお願いします」 に貴サイトのホストより発信されたものかどうかをすみや メール爆撃のログを送付しますので、そのメールがたしか 高くなり、当方はたいへんに困っております。間題となる んですが、メーリングリスト・サーバーの負荷がきわめて す。攻撃を受けた人のメールポックスカヾ益れたのはもちろ いるメーリングリスト宛にメール爆撃がおこなわれていま 「数日前より、貴サイトのホストから、本学で運用して トワーク管理者宛に次のようなイ嶽頁が送られてきました。 国のある大学の管理者から、日本国内のサイト A のネッ 1997 年 2 月 8 日、メーリングリストを運営している米 の様子を紹介します。 60 のメール中継が多数 ( 1 日に数百通以わおこなわれてい ました。 1997 年 2 月 21 日、 sendmail 8.8.5 の config. c に ある check-compat ルーチンのソースコードか書き換え られ、サイト外からサイト外へのメールの中継を拒否する ようになりました。ところが、 check-compat はメールの 全文をいったん受け取ってから処理をおこないます。した がって、同しホストから同時に 100 以のメールを受け取 るような場合は、システムの負荷が E がり、スフ。ールディ スクも消費するため、 check-compat ルーチンを書き換え るだけでは言 - 巐機資源 &f 矍できす、完全な防徊策とはな りませんでした。 その後、前述の URL で公開されている check-rcpt と check-relay の設定例か試されましたが、残念ながら check-rcpt は期待どおりの重川乍をしてくれませんでした ( 後日、 check-rcpt カ鍾川しなかったのは、 sendmail.cf の単純な言当ミスによるものと分かりました ) 。 やむなく、従来の check-compat によるフィルタリン グに加え、頻繁にメール中継のあるサイトからの SMTP 接続を check•elay を用いて色する設定を追加し、シス テムの負荷やスプールディスクの使用量などを減らす工夫 カ功日えられました。 後日、 check-rcpt を再度試したところ、今度は正常に 動胙し、それ以降の不正なメール中継は check-rcpt で拒 絶するようになりました。 まとめ 残念ながら、現在の電子メールシステムではメール爆撃 や SPAM を完全に防止する方法はありません。しかし、 冒頭でも述べたとおり、多くのメール爆撃や SPAM は発 信青報を隠すためにいくつかのホストを中継しながら送 られます。したがって、インターネット上の各サイトの 1 っ 1 つのホストか不正中継を防ぐことで、多少なりとも メール爆撃や SPAM を減らせるのではないでしようか。 インターネットは特定の企業や 1 つの国によって運営 されているものではなく、すべての利用者の協調を前提と してなりたっています。皆で、よりよいインターネット環 境を育てていきましよう。 ( いちはら・たかし、しらさき・ひろお ) UNIX MAGAZINE 1997.9

連載 UNIX Communication Notes がある。 48 を用いて実装されている。 ターネット上でのビデオや音声の放送サービスは UDP でいえは放送のモデルにもっとも近い。このため、イン ある。同輌凾信やグルーフ通信は、従来の通信サービス ケーションによっては、これらの機能が必要なものが ・ TCP では同幸凾信、グルーフ通信ができない。アプリ いる。 求があったため、 UDP をベースに実装がおこなわれて オーバーヘッドをできるかぎり小さく抑えたいという要 ーと通信する必要がある。さらに、それにともなう ホスト名から IP アドレスを得るために多くのネームサ 使われている DNS (Domain Name System) では、 なることがある。たとえば、インターネットでひろく 設定と、その管理にともなうオーバーヘッドが問題に る必要のあるアフリケーションでは、コネクションの れはならない。このため、同時に多くのホストと通信す ・ TCP では、通信するたびにコネクションを設定しなけ る実時間像伝送アプリケーションが多い。 から、現在のインターネット竟では、 UDP を利用す められる信頼の度合いが・一ヨ殳に低い。このような事情 ル転送などの通常のアプリケーションとくらべて、求 落があっても人間の目カ黼完してくれるため、ファイ はよい。さらに、愈像の伝送では、データに多少の欠 は、実時間での動画像伝送アプリケーションとの相性 バケットが送出されるので、通信の挙動だけを考えれ 方、 UDP ではアプリケーションの送信処理に同期して 提としているが、 TCP はそのような挙動をしない。 は、受信側に一定間隔でバケットが到着することを前 するのが普通である。このようなアプリケーションで バケット化して、一定時間ごとに送り出すように実装 をそのまま表小する場合、送信側では各画像フレームを ルである。重加回像の伝送において、送られてきたデータ TCP はきわめて使いにくいトランスポート層プロトコ 間隔でデータを送る必要のあるアプリケーションでは、 ている。したがって、実時間での動回像伝送など、一定 (slow start) 機構が使われているためにつねに変化し スルーブットを引・測すると、 TCP ではスロースタート ワークの状況に応して変化する。さらに、より精密に ・ TCP でのスルーブットは、送受信ホスト間のネット 図 1 UDP メッセージ・フォーマット UDP Source Port UDP Message Length 0 UDP Destination Po UDP Checksum このような TCP の欠点ゆえに TCP との相性カく、 UDP のはうかイ吏いやすいアプリケーションもある。だか らこそ、 UDP にも十分な存在価値がある。 UDP を用い た代表的なアプリケーションとしては、 NFS (Network File System) 、 DNS 、マルチメデイ里の各種アプリ ケーションがある。 UDP メッセージ・フォーマット さきはど述べたように、 UDP ではデータグラムを単位 として通信がおこなわれる。 UDP は、 IP 層の上位にある トランスホート層プロトコルである。このため、 UDP で 用いられるデータグラム ( またはメッセージ ) は、 IP デー タグラムのデータ領域に褓内されて送受信される。 図 1 は、 UDP で用いられるデータグラム ( メッセー ジ ) のフォーマットである。この図では、横が 32 ヒ、ツト ( 4 オクテット ) を表す。一見して分かるように、きわめ て単純な構造である。 最初に、送信ホスト側でのポート (UDP Source port) と、受信ホスト側でのポート (UDP Destination port) か設定されている。 UDP Source port は、 「受信フ。ロセスに対して、応答を送り返してはしい送信ホ スト側のポート番号」 を指定する意味をもっている。通常は、送信側プロセス のもつ自分自身のポート番号を指定する。ただし、 に 0 ( ゼロ ) を指定してもかまわない。 UDP メッセージ長 (UDP Message Length) は、 UDP ヘッダとデータを合わせたメッセージは何バイトか という情報かオ褓内されるフィールドである。このフィール ドは 16 ビットしかないので、 UDP のメッセージの最大 長は 64KB に制限されてしまう。 次のフィールド (UDP Checksum) は、メッセージ のチェックサムを内するフィールドである。 UDP は、 DATA UNIX MAGAZINE 1997.9

連載 /UNIX Communication Notes— 図 2 UDP Pseudo Header 0 8 zero 1 6 Source 旧 address Destination 旧 address 31 P r010C6 UDP Length チェックサム言 fr 算ではすこし変わった処理をおこなって いる。 UDP では、チェックサムを付けるカ咐けないかは オプションである。すなわち、 UDP のレベルでチェック サムを計算して付け加えてもよいし、付けなくてもかまわ ない。このため、 UDP レベルでメッセージのチェックサ ムを言 t 算しない場合には、このフィールドのピットをすべ て 0 に設定する。これによって、受信倶レ。ロセスでは、そ の UDP メッセージについてはチェックサムを計算して いないことが分かる。一方、チェックサムを言算する場合 には、 IP のときと同じ計算力法を用いて、 16 ビットの 1 の補数でチェックサムを表現する。間題は、チェックサ ムの言 t. 算結果が 0 になった場合である。この場合、 1 の補 数表現を使っているので、 0 の表現にはすべてのビットを 0 に設定したものと、すべてのビットを 1 に設定したもの の 2 不鶤頁が使える。そこで、チェックサムの計算結果が 0 になった場合は、すべてのビットを 1 に設定する、いわ ゆる、、 a ル 1 " の表現を使う。これによって、チェックサム を計算していない場合との混同を回避する。 チェックサムの計算方法 UDP メッセージでのチェックサムの算ガ去は単純で はない。図 1 に示したように、 UDP メッセージへッダに は、送信側と受信側のポート番号しか書かれていない。 方、 UDP メッセージへッダのチェックサムに求められて いるのは、送信側カ甘旨定したホストとポートに対して、正 しくデータカられているかを検査することである。そこ で、 UDP のチェックサムの計算では、図 2 に示すよう な UDP 擬似ヘッダ (UDP Pseudo Header) を用いて 送受信ホストの IP アドレス情報を補完する。 チェックサムの言 1 算は、次の手順でおこなわれる。 1. UDP 擬似ヘッダを用意する。各フィールドには、送信 ホスト IP アドレス (Source IP address) 、受信ホス ト IP アドレス (Destination IP address) をそれぞ れ指定し、プロトコル・フィールド (Protocol) には、 UDP のプロトコル番号である、、 17 " を指定する。 zero UNIX MAGAZINE 1997.9 と書かれている部分は、すべてのビットが 0 に設定 される。メッセージ長 (UDP Length) には、送られ る UDP メッセージの長さ (UDP 擬似ヘッダの長さ は含まない ) か書かれる。 2. UDP メッセージのう頁に UDP 孑鬮以ヘッダを付ける。 3. UDP メッセージの最後に、 16 ビット境界に合うよう に 0 をパディング (padding) する。 4. UDP メッセージへッダのチェックサム・フィールド は 0 に初期化する。 5. チェックサムの計算を実行する。これには、 IP 層での チェックサム言 t 算に用いた関数洫ー cks Ⅷ ( ) を使う。 6. UDP メッセージへッダのチェックサム・フィールド に言算結果を各内する。 ここで注意しなけれはならないのは、 UDP 孑鬮以ヘッダ、 およびメッセージの最後にイ寸加されるパディングはチェッ クサムの計算でイ吏われるだけで、実際の送信データには含 まれないことである。したがって、受信ホストでのチェッ クサムの検査でも受信ホスト側で UDP 擬似ヘッダを用 意し、パディングをおこなってチェックサムを検査する が、これらのデータは当然のことながら上位層には渡され UDP の実装 UDP の実装は、同しトランスポート層に属する TCP とくらべてきわめてシンプルである。 UDP に関連した実 装としては、プロトコル・スイッチの設定が in_proto ・ c に、その他の処理関委蠕羊はすべて udp-usrreq ・ c に言当 されている。 プロトコル・スイッチの設定 インターネット・プロトコルにおけるプロトコル・ス イッチ struct protosw inetsw ロ ( ま、 in_proto. c で衫琪月化される。 UDP に対応するのは、ソケットタイプ (pr-type) に SOCK-DGRAM カ甘旨定されているエントリで ある。このエントリには、以下に示す情幸師ゞ書かれている。 ・ SOCK_DGRAM ソケット層からはデータグラム型通信として扱われる。 ・ IPPROTO_UDP プロトコル番号としては、 TCP/IP のプロトコル群の 49

電子メール爆撃と SPAM に対抗する方法 市原卓、白崎博生 電子メール爆撃、 SPAM とは ある朝、いつものように引・機にログインして電子メー ルをチェックすると、見覚えのない差出人から数百通も のメールか届いていたり、あるいはメールポックスか溢れ ていたり、そこまでいかなくても、大切なメールかイな メールの山に埋もれてしまったりしていては大変です。さ らに、このような事態が毎日続くと実質的にメールカ硬え なくなってしまいます。これは、けして架空の話ではあり ません。現実に起きていることです。 電子メール爆撃 (EmaiI Bomb) とは、特定の電子メー ルアドレスに大量のメールを送りつける行為、あるいは、 そのようなイ性トけを受信者に無斯で設定しで司様なことを 実現する行為を指します。ネ皮害に遭うと、連日多数 ( 通常 は数百通以わの不要な電子メールを受け取ることになり ます。その結果、電子メールの利用がきわめて困難にな り、日常の業務に重大な支障をきたします。 典型的な電子メール爆撃は、送信者アドレスを偽造し、 さらにいくっかのホストを中継して送り手の特定を困難に するように細工されています。しかし、メールヘッダの内 容を入念に角〒し、メールを中継したサイトに残った転送 ログなどを順次角 i していけは、通常は送信者を特定する ことができます。 54 SPAM には、同しメッセージを多数 ( 多くの場合は 20 の SPAM は商業広告です。 か望むと望まないとにかかわらす送られてきます。大部分 て送る行為を指します。これらのメッセージは、ユーサー ジの大阯のコピーを電子メールやネットニュースを使用し 一方、 SPAM とは、インターネット上で同一メッセー 以わ ) のニュースグループに投稿するものと、電子メー ルを用いて個々のユーサーにダイレクトに送信するもの の 2 種類があります。とくにメーリングリストに送られ る SPAM はたちが悪いので、メーリングリストの運営 者は SPAM 攻撃を受けないように注意架く管理しなけれ はなりません。米対では、偽造した送信アドレスを用いて SPAM を大量に送付した企業か訴えられ、裁判戸励ゞ偽造 メール送付の停止命令を出したケースもあります。 ーイ殳に、インターネットにおいては各サイトでメールサ ーを運用していますが、そのサーバーが電子メール爆 撃や SPAM の中継に不正に使用されることがあります。 さらに、 SMTP のポートを開いている WWW サーバー ホストや FTP サーバーホスト、ネームサーバー・ホスト なども不正な中継に悪用される場合があります。 このような中父撃を受けた際の不都合と、その物旦方 法を簡単に解説します。 中継攻撃の被害に遭うと あるサイトのメールサーバーが SPAM や電子メール爆 撃の中継を意図する攻撃 ( 中継攻撃 ) を受けた場合、その ような電子メールの中継を拒絶する設定をしていないと、 次のような間題か、発生します。 1. メモリ、 CPU 、スプールディスク、ネットワーク帯域 などの資源が大量に浪費されます。 ( 同し相手から ) 同 時に数ー - トから百を超える SMTP ポートへの接続要求 がある場合も多く、そのようなケースではメモリカ坏足 し、システムの爿は匀負荷値 (load average) が念敷に上 がります。その結果、サービスを停止せざるをえないア プリケーションが出てきたり、システムの施か翆対に UNIX MAGAZINE 1997.9

連載 UNIX Communication Notes—O これらの検査で異常があったときは、受信したデータグ ラムを破棄する。 2. 次に、同轤凾信とグルーフ。通信の処理をおこなう。これ は、受信した IP データグラムの受信ホスト IP アドレ ス (Destination IP address) を検査し、同報凾信また はグルーフ。通信のデータグラムかどうかを判別して処理 する。 UDP における処理では、これらのバケットをた んに単一のプロセスに渡すだけでは不十分である。とく にグループ通信では、同一ホストで複数のプロセスが同 しポートを使っている可能がある。この場合、ワイル ドカード (IN-ADDRANY) によって相手ホストを指定し ているソケットで複数のプロセスを受信する可能性があ るので、対応するすべてのソケットにデータを渡さなけ れはならない。そこで、 f 。 r 文を用いて PCB をすべて 検索し、受信すべきすべてのソケットにデータをコピー して渡し、最後に sorwakeup() を使って上位層であ るソケット層の処理を起測ける。対応するソケットがな ければ、単純にデータグラムを破棄する。 3.1 対 1 通信の場合は、上交的単純な処理をおこなう。ま す、受信アドレスとポートに対応する PCB を検索す る。対応する PCB が発見できた場合は、 UDP メッ セージの mbuf をそのまま対応する PCB のバッフアに ; 叫吉し、 sorwakeup() によってソケット層の処理を起 測ける。一方、対応する PCB が発見できなかった場合 は、 ICMP メッセージを生成して送信ホストに送付す る。このときの ICMP メッセージは、 ICMP-UNREACH (ICMP-UNREACH-PORT) のメッセージが生成される。 この送信には、関数 icmp-error() が使われる。受 信した UDP メッセージは、 ICMP メッセージの送信 処理後に破棄される。 そ也の里 UDP には、 pr-ctloutput と pr_ctlinput に対応 する処理がある。 pr-ctloutput については、 getsockoput() と set- sockoput() システムコールに対応した処理をおこなうが、 UDP 層ではとくに処理する必要はない。そのため、プロ トコル・スイッチの定義で直接 ip-ctloutput ( ) を呼ぶ ように設定されている。 一方、 pr-ctlinput については udp-ctlinput ( ) が 52 用意されている。この関数は、 ICMP メッセージを受信し たときに呼び出される。 ICMP メッセージを受信した場合 も、 UDP 層ではとくに処理の必要はないので、たんに上 位層に受信を通告するだけでよい。 in-pcbnotify() を 用いて、 ICMP メッセージの通告が必要なソケットに対 して通知するだけである。 終了里 UDP を使ったソケットをクローズする場合は、 close( システムコールを呼び出す。このとき、 udp-usrreq() が引数 PRU-DETACH 付きで呼び出さオ L 、ただちに udp- detach() か呼はれる。このなかでは、 in-pcbdetach() を呼んで里する PCB を消去しているだけである。これ によって、 UDP 層の PCB とソケット層における関連情 鬮切ゞすべて消去される。 ☆ 今回は、 UDP の機能とその実装について解説した。 UDP は、 IP 層の機能にトランスポート層のインターフェ イスをかぶせただけのトランスポート層プロトコルといっ てもよい。そのため、 UDP の実装はごく単純であり、ト ランスポート層の構造を把握するには恰好の材科である。 とくに、 UNIX でのトランスポート層の実装に最低限必 要なことはすべて分かる。その意味でも、実装の参考とし て読むにはうってつけの題材である。 ( やまぐち・すぐる奈良躡十支術大完大学 ) UNIX MAGAZINE 1997.9