2011年12月30日金曜日

VMware Fusion のホストオンリーネットワークはハブのように振る舞う(スイッチではないみたい)

VMware Fusionで複数のVMをホストオンリーネットワークに接続し、VMのひとつで tcpdump を動かしてみる。そうすると、ブロードキャスト以外のパケットまで見えることに気づく。まるでリピータハブに接続したときのように。


環境

  • MacOS 10.6.8
  • VMware Fusion 4.1.1

VMを3つ作って(OSは、tcpdump や ping が使えるなら何でもよい)、それらのNICをホストオンリーネットワークにつなぐ。


ホスト(MacOS)で認識されているNICのうち、"vmnet1"がVMwareのホストオンリーネットワーク用の仮想ネットワークアダプタ。以下のように、ネットワークアドレスは"192.168.105.0"になっている。


$ ifconfig vmnet1
vmnet1: flags=8863 mtu 1500
 ether 00:50:56:c0:00:01 
 inet 192.168.105.1 netmask 0xffffff00 broadcast 192.168.105.255

なので、VMを起動するとVMのNICには"192.168.105.128/24" や "192.168.105.129/24" などが設定される。


$ ip addr show eth0
2: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:0a:48:1b brd ff:ff:ff:ff:ff:ff
    inet 192.168.105.128/24 brd 192.168.105.255 scope global eth0

準備ができたら、まず 1つのVMで "tcpdump -i eth0" を実行し、残り2つの VM間で ping をしてみる。すると tcpdump の出力に ping による通信が出てくる。

次に、プロミスキャスモードOFFの'-p'オプションをつけて tcpdump を実行して、同様に ping を実行すると、今度は出てこない。プロミスキャスモードが効く、つまり switched network には接続されていないときの動作になっている。


物理的な環境だとスイッチ(ングハブ)を常に使うから、VMware Fusionの世界もスイッチだと思い込んでいたが、違うらしい。また、VMwareのエディション等によっても挙動が変わってくる模様。


2011年12月26日月曜日

OpenSSHサーバーの鍵生成

一般的なLinuxディストリビューションでは、OpenSSHサーバーがインストールされていて、起動すればすぐに使える状態になる(はず)。

しかし、いったいサーバーの鍵はいつどこで誰が準備したのだろうか? たぶんこんなこと気にする必要は無い。でも気になった。

CentOS-6.0 について言えば、sshdの起動スクリプトの中で自動的に3種類の鍵、つまり RSA1 と RSA(SSH2対応RSA),DSAの鍵が作られるのだった。

/etc/init.d/sshd から抜粋

(略)
KEYGEN=/usr/bin/ssh-keygen
SSHD=/usr/sbin/sshd
RSA1_KEY=/etc/ssh/ssh_host_key
RSA_KEY=/etc/ssh/ssh_host_rsa_key
DSA_KEY=/etc/ssh/ssh_host_dsa_key
(略)
        if test ! -f $RSA1_KEY && $KEYGEN -q -t rsa1 -f $RSA1_KEY -C '' -N '' >&/dev/null; then
(略)
        if test ! -f $RSA_KEY && $KEYGEN -q -t rsa -f $RSA_KEY -C '' -N '' >&/dev/null; then
(略)
        if test ! -f $DSA_KEY && $KEYGEN -q -t dsa -f $DSA_KEY -C '' -N '' >&/dev/null; then
(略)

'ssh-keygen'コマンドを素直に3回実行するという流れ。

OpenSSHのStrictHostKeyChecking=xxx

OpenSSH の'StrictHostKeyChecking'オプションの振る舞いを確認してみた。

環境

ローカルホスト(SSHクライアント)
MacOS 10.6.8, OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011
リモートホスト(SSHサーバ)
CentOS-6.0 OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010

ちなみに OpenSSH のバージョンを調べるオプションは '-V' だった。

やったこと

OpenSSHの'StrictHostKeyChecking'オプションの値を yes, ask, no と変えながら、リモートホスト(ここでは 192.168.111.103)にユーザー user01 でログインを試みる。ただし、毎回以下のコマンドを実行してローカルホストのknown_hostsファイルがリモートホストの情報を含まない状態にしておく。

$ ssh-keygen -R 192.168.111.103

結果

yes の場合
$ ssh -o StrictHostKeyChecking=yes -l user01 192.168.111.103
No RSA host key is known for 192.168.111.103 and you have requested strict checking.
Host key verification failed.
$
認証まで進まずに、sshコマンドが終了してしまう。
ask の場合
ssh -o StrictHostKeyChecking=ask -l user01 192.168.111.103
The authenticity of host '192.168.111.103 (192.168.111.103)' can't be established.
RSA key fingerprint is 26:f9:16:77:cf:92:95:58:95:d1:55:ce:d2:9e:34:84.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.111.103' (RSA) to the list of known hosts.
user01@192.168.111.103's password:
手続きを進めるかどうか確認待ちになる。そこで yes を入力すると、パスワード入力待ちになる。
no の場合
$ ssh -o StrictHostKeyChecking=no -l user01 192.168.111.103
Warning: Permanently added '192.168.111.103' (RSA) to the list of known hosts.
user01@192.168.111.103's password:
確認無しに、パスワード入力待ちになる。

2011年12月23日金曜日

Nmap テスト用ホスト scanme.nmap.org

nmapコマンドを使ってみたい人のために、テスト用のホスト(scanme.nmap.org)が公開されている。このホストに対しては、一日あたり10数回程度という制限の範囲内で、自由にスキャンを実行してよい。

# nmap -A -T4 scanme.nmap.org

これも man や Examples に書いてあった。

Nmap の性能に関するオプション

詳しい説明が man や Timing and Performance に書いてあった。

お手軽なのは -T4 というオプション。

2011年12月19日月曜日

Tshark の Capture Filter と Read Filter のマニュアル

Tshark のフィルタは、"CAPTURE FILTER" と "READ FILTER" の二段構えになっており、それぞれが異なる文法にしたがう。

以下は、各文法を詳しく知りたいときに何を参照すればいいか、という話。


man tshark

とりあえず man tshark をする(CentOS-6.0 にて)。

CAPTURE FILTER SYNTAX
See the manual page of pcap-filter(4) or, if that doesn't exits, tcpdump(8).
READ FILTER SYNTAX
For a complte table or protocol and protocol fields that are filterable in TShark see the wireshark-filter(4) manual page.

…ということで、"pcap-filter(4)" と "wireshark-filter(4)" を参照すればいい。ちなみに CentOS-6.0 の場合 "pcap-filter(4)" は存在しなかった。代わりに "pcap-filter(7)"がみつかった。


例:SYNフラグがセットされているTCPパケットを抽出するフィルタ

キャプチャフィルタ('-f'オプション)の場合
# tshark -i eth0 -f 'tcp[tcpflags] & tcp-syn != 0'
リードフィルタ('-R'オプション)の場合
# tshark -i eth0 -R 'tcp.flags.syn == 1'

キャプチャフィルタのほうは、配列やビット演算風のローレベルな記述になっている。そして、Tshark 以外に tcpdump にも流用できる。


2011年12月18日日曜日

キャプチャデータを一定時間ごとにファイルへ保存(tshark, tcpdump)

キャプチャデータを、指定した時間間隔ごとに複数のファイルに出力するオプションを試してみた。

環境は、CentOS-6.0, libpcap-1.0.0, tshark-1.2.15, tcpdump-4.1-PRE-CVS。


tshark の場合

'-b <capture ring buffer option>' というオプションの値として 'duration:秒数' を指定する。

# tshark -i eth0 -b duration:3 -w tshark.pcap

上のコマンドを実行した場合、次のようにファイルが生成されていく。

# ls tshark*
tshark_00001_20111218215216.pcap
tshark_00001_20111218215219.pcap
tshark_00001_20111218215222.pcap

tcpdump の場合

'-G rotate_seconds' というオプションを使用する。それと同時に、

  • ファイル名('-w'オプション)に 'strftime' の書式文字列を含める必要がある
  • '-Z'オプションに 'root' を指定する必要がある(場合によってはセキュリティの問題につながるかもしれないので、一般ユーザーで sudo して '-Z user01' のようにしたほうがいいと思われる)
# tcpdump -i eth0 -G 3 -Z root -w tcpdump_%Y%m%d%H%M%S.pcap

上のコマンドを実行した場合、次のようにファイルが生成されていく。

# ls tcpdump*
tcpdump_20111218220740.pcap
tcpdump_20111218220743.pcap
tcpdump_20111218220746.pcap

sudoの設定をして、一般ユーザーで実行することもできる(たとえば user01 とする)。

$ sudo tcpdump -i eth0 -G 3 -Z user01 -w tcpdump_%Y%m%d%H%M%S.pcap
$ ls -l tcpdump*
-rw-r--r-- 1 user01 user01 480 Dec 18 23:01 tcpdump_20111218230115.pcap
-rw-r--r-- 1 user01 user01 480 Dec 18 23:01 tcpdump_20111218230118.pcap
-rw-r--r-- 1 user01 user01 480 Dec 18 23:01 tcpdump_20111218230121.pcap