Programming SHOT BARへようこそ。

先日、私の名前を騙って発言する人がいたのですが、いたずらにしてもやってはいけない部類ですね。 そういう悪質な通信に対する画期的な対策が RFC3514 (日本語訳) に規定されています。ここで紹介してみましょう。

RFC3514

RFC(Request For Comment)とはIETF(Internet Engineering Task Force)という組織から出される技術標準のドキュメントです。
HTTPやFTPなど、よく知られたプロトコルはだいたいここから標準がだされています。 つまり、プロトコルの一次資料となるわけです。

普段は簡素に噛み砕いた書籍なり、ホームページなりを参照して作業すれば事足りますが、 何か調べ物をするときに１次資料に当たるという場合はこのRFCを読むことになります。

さて、このRFCですが、プロトコルによって番号が違います。HTTPは2616、FTPは959といった具合。 発行順に連番で付いているので、若い番号のプロトコルはそれだけ年季の入ったプロトコルになります。

さて、3514の内容について解説しましょう。まずは、要約から。

ファイアウォール、パケットフィルタ、IDSのようなものにとって、悪意ある 試みのパケットと、ほとんど異常でないパケットを区別するのは難しい。我々 は、この2つの場合を区別する意味を持つIPv4ヘッダのセキュリティフラグを 定義する。

この部分でRFC3514が何をするのかがわかりますね。 IPv4の通信パケットのうち悪意のあるパケットを省きたいわけです。 これは期待が持てます。
ではどうやってフィルタリングするのかと…

ファイアウォール、パケットフィルタ、IDSのようなものにとって、悪意のあ る試みのパケットと、ほとんど異常でないパケットの区別をするのは困難であ る。この問題は、その決定をすることが困難なことに起因する。この問題を解 決するため、IPv4 [RFC 791] ヘッダに「evil bit」として知られるセキュリ ティフラグを定義する。悪意から出たわけではないパケットはこのビットを0 にセットする； 攻撃に使われるものでは1にセットされるだろう。

えー。つまり、攻撃に使われる悪意のあるパケットはあらかじめフラグを立てて送ってきなさいよ、と。
攻撃者の自己申告によるフラグを立てることで効率よくフィルタリングができるだろう、というお話。

実はこのRFC、発効日が2003年4月1日なんです。そう、エイプリルフール。
こういったRFCはジョークRFCと呼ばれ、インターネットのお祭りであるエイプリルフールに華を添えます。
geekにはgeekの楽しみがあるというわけですね。それではまた。