p0f は、 通信相手の OS を受動的に特定するツールで、 迷惑メール送信などの スパム行為を行なう「敵」を知る手段として有用である。 例えば、もし (あくまで仮定の話だが) 受信するメールのほとんどすべてが Linux や FreeBSD などの UNIX 系サーバから送信されるメールであって、 Windows マシンから送られてきたメールのほとんどすべてが迷惑メールであったなら、 Windows マシンからのメールを排除するという対策は合理的なものとなるだろう。
もちろん、Windows を使ってマトモなメールを送ってくるケースもあるだろうから、 Windows から送られたメールを全て排除するのは現実的ではないが、 p0f での判定結果と、 その他の手段 (例えば送信元 IP アドレス) での判定結果を組合わせて 迷惑メールであるか否かの判断を行なえば、 より精度の高い迷惑メール排除が可能になる。
ところが、 p0f は通信相手から送られてくる IP パケットを元に、 通信相手の OS を特定するツールであるから、 間にファイアウォールや NAT (IPアドレス・ポート変換) を行なう機器があると、 通信相手ではなくファイアウォールや NAT について調べてしまう。 だから、メールを受信するサーバがファイアウォールの内側にある場合は、 意味ある結果が得られないし、 外側にある場合だとメールを受信するサーバとは別の場所 (つまりファイアウォールの内側) で スパム判定を行ないたくなるものだろう。 例えばメールサーバは DMZ 上にあるが、 迷惑メール判定は LAN 内のマシンで行ないたい場合など。
私の個人サイト GCD は、 b フレッツに PPPoE 接続している。 p0f は調べる通信のインタフェース名を -i オプションで指定する必要があるが、 (1) PPPoE だからインタフェース名 (ppp0～) が変わることがある。 また、 PPPoE を行なうゲートウェイマシンは二台ある (冗長構成) ので、 (2) アクティブ側で p0f を実行しないと意味がない。 さらに、 メールサーバは (メールボックスを一ヶ所にまとめたかったので) 一台だけであり、 (3) 異なるサーバ上 (アクティブ側のゲートウェイ) で動いている p0f の結果を メールサーバから参照しなければならない。
以上 (1) ～ (3) の 3点を満たすための構成を考えてみた。
まず (1) と (2) は、pppd の ip-up スクリプトから p0f を実行すればよい。 例えば、ip-up で
command=$0
interface=$1
...
case $command in
*ip-up)
p0f -i $interface -Q /var/run/p0f-sock \
'port 25 and (not src net 192.168.0.0/16)' \
-u stone -d -t -o /var/log/p0f.log
;;
*ip-down)
killall p0f
;;
esac
などと p0f を起動し、ip-down で p0f を終了させる。 これでアクティブ側のゲートウェイ上でのみ p0f が動く。
p0f による判定結果は、 p0f の -Q オプションで指定した UNIX ドメイン・ソケット (上記の例では、 /var/run/p0f-sock) を介して 問合わせることができるが、 UNIX ドメイン・ソケットなので当然のことながら 別のマシンからは問合わせることができない。 そこで stone に転送させる:
stone /var/run/p0f-sock 12345 &
アクティブ側のゲートウェイは、 仮想ルータの IP アドレス 192.168.1.1 を持っているので、 「192.168.1.1:12345」へアクセスすれば、 それを stone が /var/run/p0f-sock へ中継してくれるので、 (3) p0f の結果を参照できる。
p0f の結果を参照するサンプルプログラムとして、 p0f には perl で書かれた p0fq.pl と、 C で書かれた p0fq.c が付属しているが、 あいにくどちらも UNIX ドメイン・ソケットにしか対応していない (当たり前)。 ちょっといじってリモート上の p0f へ (stone 経由で) アクセスできるようにしてみる。
p0fq.pl へのパッチ:
--- test/p0fq.pl.org 2006-08-21 23:11:10.000000000 +0900
+++ test/p0fq.pl 2008-01-31 08:00:14.652880068 +0900
@@ -30,8 +30,14 @@
$src->intip(), $dst->intip(), $ARGV[2], $ARGV[4]);
# Open the connection to p0f
-my $sock = new IO::Socket::UNIX (Peer => $ARGV[0],
+my $sock;
+if ($ARGV[0] =~ /^[\-\w]+:\d+$/) {
+ $sock = new IO::Socket::INET (PeerAddr => $ARGV[0],
Type => SOCK_STREAM);
+} else {
+ $sock = new IO::Socket::UNIX (Peer => $ARGV[0],
+ Type => SOCK_STREAM);
+}
die "Could not create socket: $!\n" unless $sock;
# Ask p0f
「IO::Socket::UNIX」を「IO::Socket::INET」に変更するだけで済む。
p0fq.c へのパッチ:
--- test/p0fq.c.org 2006-08-21 21:29:49.000000000 +0900
+++ test/p0fq.c 2008-01-31 08:05:55.499326450 +0900
@@ -16,6 +16,7 @@
#include <sys/types.h>
#include <sys/socket.h>
+#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
@@ -40,6 +41,7 @@
struct p0f_response r;
_u32 s,d,sp,dp;
_s32 sock;
+ char *str;
if (argc != 6) {
debug("Usage: %s p0f_socket src_ip src_port dst_ip dst_port\n",
@@ -55,12 +57,37 @@
if (!sp || !dp || s == INADDR_NONE || d == INADDR_NONE)
fatal("Bad IP/port values.\n");
+ if ((str=strchr(argv[1], ':'))) {
+ struct addrinfo *ai = NULL;
+ struct addrinfo hint;
+ int err;
+ *str++ = '\0';
+ hint.ai_flags = 0;
+ hint.ai_family = AF_INET;
+ hint.ai_socktype = SOCK_STREAM;
+ hint.ai_protocol = IPPROTO_TCP;
+ hint.ai_addrlen = 0;
+ hint.ai_addr = NULL;
+ hint.ai_canonname = NULL;
+ hint.ai_next = NULL;
+ err = getaddrinfo(argv[1], str, &hint, &ai);
+ if (err) {
+ if (err == EAI_SYSTEM) pfatal("getaddrinfo");
+ else fatal("getaddrinfo(%s,%s): %s\n",
+ argv[1], str, gai_strerror(err));
+ }
+ memcpy(&x, ai->ai_addr, ai->ai_addrlen);
+ sock = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
+ freeaddrinfo(ai);
+ if (sock < 0) pfatal("socket");
+ } else {
sock = socket(PF_UNIX,SOCK_STREAM,0);
if (sock < 0) pfatal("socket");
memset(&x,0,sizeof(x));
x.sun_family=AF_UNIX;
strncpy(x.sun_path,argv[1],63);
+ }
if (connect(sock,(struct sockaddr*)&x,sizeof(x))) pfatal(argv[1]);
getaddrinfo を呼び出すための準備に行数を費やしているので 複雑に見えるかも知れないが、 本質は プロトコル・ファミリ (protocol family) を AF_UNIX から AF_INET に変更しただけである。
(p0f を実行しているマシンとは異なるマシン上で) p0fq を実行してみる:
% p0fq 192.168.1.1:12345 81.36.137.136 2943 60.32.85.220 25 Genre : Windows Details : 2000 SP4, XP SP1+ Distance : 21 hops Link : pppoe (DSL)
上記は、 メール送信元 (81.36.137.136 のポート 2943番) が GCD の MX (60.32.85.220 のポート 25番) へメールを送ってきた通信の p0f による判定結果。 メールサーバで、 メールヘッダにメール送信元のポート番号も出力するようにしておけば、 メールを受信するユーザが自前のメール振り分けプログラム (procmail など) を使って p0f の判定結果を参照できる点がミソ。
81.36.137.136 はスペインのプロバイダの IP アドレスらしいが、 逆引きしてみると 136.Red-81-36-137.dynamicIP.rima-tde.net となるので 動的に割当てられているアドレスなのだろう。 これは p0f の結果に pppoe (DSL) と出ていることと符合する。 そして Windows 2000 SP4 か Windows XP SP1 以降を使って 送信していることが分かる。
