はじめまして。私は最近RedHat Linux8でiptablesをいじりはじめた
初心者のものです。
実用的なフィルタを作る前にiptablesを色々いじっていたのですが、
どうもおかしな状況に遭遇しました。テスト的に簡単なフィルタを
作ってみて、それをテストするべく、LANのWindowsマシンから
nmap -sT 192.168.0.2
と打ってみたのです。すると、
-----------------------------------------------------------
Interesting ports on 192.168.0.2:
(The 1658 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
25/tcp open smtp
80/tcp open http
81/tcp open hosts2-ns
82/tcp open xfer
83/tcp open mit-ml-dev
110/tcp open pop3
119/tcp open nntp
1080/tcp open socks
5190/tcp open aol
8080/tcp open http-proxy
MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
Nmap finished: 1 IP address (1 host up) scanned in 141.600 seconds
-----------------------------------------------------------
のように表示されたのです。これは全く予想外のことでした。
というのも、ここに列挙されたポートは全て塞いであるつもり
だったからです。
そこで、さらに追求すべく、極端な例として、INPUT、FORWARD、
OUTPUT全てをDROPしてみた(ポリシーは全てDROPで、各チェインには
何も追加はせず)のです。それでも結果は同じでした。
それで頭を抱えています。一体、これはどういうことなのでしょうか？
誰かおわかりになる方、御教授下さい。
これだけの情報があるなら、ひとつずつつぶしていけばいいので何でしょうか？
> 実用的なフィルタを作る前にiptablesを色々いじっていたのですが、
> どうもおかしな状況に遭遇しました。テスト的に簡単なフィルタを
> 作ってみて、それをテストするべく、LANのWindowsマシンから
>
> nmap -sT 192.168.0.2
>
> と打ってみたのです。すると、
> -----------------------------------------------------------
> Interesting ports on 192.168.0.2:
> (The 1658 ports scanned but not shown below are in state: filtered)
> PORT STATE SERVICE
> 25/tcp open smtp
> 80/tcp open http
> 81/tcp open hosts2-ns
> 82/tcp open xfer
> 83/tcp open mit-ml-dev
> 110/tcp open pop3
> 119/tcp open nntp
> 1080/tcp open socks
> 5190/tcp open aol
> 8080/tcp open http-proxy
> MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
>
> Nmap finished: 1 IP address (1 host up) scanned in 141.600 seconds
> -----------------------------------------------------------
> のように表示されたのです。これは全く予想外のことでした。
> というのも、ここに列挙されたポートは全て塞いであるつもり
> だったからです。
これだけで、いろいろチェックできるのではないでしょうか？
3項だったらnmapしちゃまずいと思いますが・・。
1. 上記に表示されたポートは、本当にサーバで動作しているポートか？
LISTENされていないポートが出るのはおかしい。
デフォルトで動いているはずの22や631等がなく、普通は見られないポートが多いので。
2. 最後のMACは本当にサーバのMACか？
間違って他の端末をスキャンしなかったか？
3. 何かproxyサーバっぽいんですが？ Windowsに入ったままになってません？ローカルは串を通さない設定にするのが普通なので大丈夫と思いますが・・。
こういうネットワーク問題は、パケットキャプチャが一番早いです。Windows用もあるのでEtherealでパケット見れば、いろいろなケースでほぼ一発で原因がわかります。
> そこで、さらに追求すべく、極端な例として、INPUT、FORWARD、
> OUTPUT全てをDROPしてみた(ポリシーは全てDROPで、各チェインには
> 何も追加はせず)のです。それでも結果は同じでした。
設定されていること自体をiptables --list で確認されたかと思いますが・・。
おやじさん、さっそくのフォロー、ありがとうございました。
> > どうもおかしな状況に遭遇しました。テスト的に簡単なフィルタを
> > 作ってみて、それをテストするべく、LANのWindowsマシンから
> >
> > nmap -sT 192.168.0.2
> >
> > と打ってみたのです。すると、
> > -----------------------------------------------------------
> > Interesting ports on 192.168.0.2:
> > (The 1658 ports scanned but not shown below are in state: filtered)
> > PORT STATE SERVICE
> > 25/tcp open smtp
> > 80/tcp open http
> > 81/tcp open hosts2-ns
> > 82/tcp open xfer
> > 83/tcp open mit-ml-dev
> > 110/tcp open pop3
> > 119/tcp open nntp
> > 1080/tcp open socks
> > 5190/tcp open aol
> > 8080/tcp open http-proxy
> > MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
> >
> > Nmap finished: 1 IP address (1 host up) scanned in 141.600 seconds
> > -----------------------------------------------------------
> > のように表示されたのです。これは全く予想外のことでした。
> > というのも、ここに列挙されたポートは全て塞いであるつもり
> > だったからです。
>
> これだけで、いろいろチェックできるのではないでしょうか？
> 3項だったらnmapしちゃまずいと思いますが・・。
>
> 1. 上記に表示されたポートは、本当にサーバで動作しているポートか？
> LISTENされていないポートが出るのはおかしい。
> デフォルトで動いているはずの22や631等がなく、普通は見られないポートが多いので。
> 2. 最後のMACは本当にサーバのMACか？
> 間違って他の端末をスキャンしなかったか？
> 3. 何かproxyサーバっぽいんですが？ Windowsに入ったままになってません？ローカルは串を通さない設定にするのが普通なので大丈夫と思いますが・・。
1.については、サーバ上で netstat -a を打ってみました。すると、
-------------------------------------------------------------
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:sunrpc *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 Arab:smtp *:* LISTEN
udp 0 0 *:sunrpc *:*
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 1530 /dev/gpmctl
unix 7 [ ] DGRAM 983 /dev/log
unix 2 [ ACC ] STREAM LISTENING 1534 /tmp/.iroha_unix...
unix 2 [ ] DGRAM 1552
unix 2 [ ] DGRAM 1504
unix 2 [ ] DGRAM 1486
unix 2 [ ] DGRAM 1205
unix 2 [ ] DGRAM 991
-------------------------------------------------------------
となっていました(11行目は行の折り返しの都合で一部省略しました。
/tmp/.iroha_unix/IROHAとなっています。また、5行目の"Arab"と
いうのはサーバの名前です)。私は本当に初心者で、調べる方法は
ポートに関してはこれしか知りません。
これを見る限りではおやじさんの仰るように「LISTENされていない
ポートが出るのはおかしい」のだと思います。これで訳がわからず
頭を抱えている次第です。また、「デフォルトで動いているはず」と
仰られているsshのサービスはnetstatを見る限りは動いているよう
です。
ちなみに、サーバ上でiptables -Lを打ってみると、
-------------------------------------------------------------
Chain INPUT (policy DROP)
target prot opt source destination
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy DROP)
target prot opt source destination
-------------------------------------------------------------
と表示されます。これは前の投稿で述べた「全てDROPした」という
状況です。
2.については、確かに対象のサーバのMACアドレスです。デュアルブート
で入っているWin2000に切り替えて念のために確認してみました。
3.については、特にプロキシサーバとしての設定は行っていません。
実はLinux自体もテスト的にインストールしたもので、「最小構成」、
「ファイアウォールなし」の条件でインストーラに指示しました
(ちなみにLinux自体のインストールは何度も経験しています)。
その後で、iptablesの設定を加えた状況です。
ですから、「完全にDROPした」状況で前述のような「開いたポート」
が見えるのが不思議でなりません。
> こういうネットワーク問題は、パケットキャプチャが一番早いです。Windows用もあるのでEtherealでパケット見れば、いろいろなケースでほぼ一発で原因がわかります。
うう…パケットキャプチャですか…。私はやったこともないし、何か
敷居が高そうで抵抗がありますね…。
また、そもそもの疑問として、nmapで検出された情報はサーバのどこ
にあるのか検討もつきません。私はポートスキャナも今回初めて使い
ましたので、nmapに疑いを抱き、SuperScanという別のスキャナも
使ってみましたが、結果は同じでした。
以上、どこをとっかかりに問題に対処したらよいかわからないので、
現状の情報をより詳しく述べさせて頂きました。
この状況でどう対応したらよいのかご教示頂けたらあり難いです。
> > これだけで、いろいろチェックできるのではないでしょうか？
> > 3項だったらnmapしちゃまずいと思いますが・・。
> >
> > 1. 上記に表示されたポートは、本当にサーバで動作しているポートか？
> > LISTENされていないポートが出るのはおかしい。
> > デフォルトで動いているはずの22や631等がなく、普通は見られないポートが多いので。
> > 2. 最後のMACは本当にサーバのMACか？
> > 間違って他の端末をスキャンしなかったか？
> > 3. 何かproxyサーバっぽいんですが？ Windowsに入ったままになってません？ローカルは串を通さない設定にするのが普通なので大丈夫と思いますが・・。
>
> 1.については、サーバ上で netstat -a を打ってみました。すると、
> -------------------------------------------------------------
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp 0 0 *:sunrpc *:* LISTEN
> tcp 0 0 *:ssh *:* LISTEN
> tcp 0 0 Arab:smtp *:* LISTEN
> udp 0 0 *:sunrpc *:*
> Active UNIX domain sockets (servers and established)
> Proto RefCnt Flags Type State I-Node Path
> unix 2 [ ACC ] STREAM LISTENING 1530 /dev/gpmctl
> unix 7 [ ] DGRAM 983 /dev/log
> unix 2 [ ACC ] STREAM LISTENING 1534 /tmp/.iroha_unix...
> unix 2 [ ] DGRAM 1552
> unix 2 [ ] DGRAM 1504
> unix 2 [ ] DGRAM 1486
> unix 2 [ ] DGRAM 1205
> unix 2 [ ] DGRAM 991
> -------------------------------------------------------------
> となっていました(11行目は行の折り返しの都合で一部省略しました。
> /tmp/.iroha_unix/IROHAとなっています。また、5行目の"Arab"と
> いうのはサーバの名前です)。私は本当に初心者で、調べる方法は
> ポートに関してはこれしか知りません。
>
> これを見る限りではおやじさんの仰るように「LISTENされていない
> ポートが出るのはおかしい」のだと思います。これで訳がわからず
> 頭を抱えている次第です。また、「デフォルトで動いているはず」と
> 仰られているsshのサービスはnetstatを見る限りは動いているよう
> です。
>
> ちなみに、サーバ上でiptables -Lを打ってみると、
> -------------------------------------------------------------
> Chain INPUT (policy DROP)
> target prot opt source destination
>
> Chain FORWARD (policy DROP)
> target prot opt source destination
>
> Chain OUTPUT (policy DROP)
> target prot opt source destination
> -------------------------------------------------------------
> と表示されます。これは前の投稿で述べた「全てDROPした」という
> 状況です。
>
> 2.については、確かに対象のサーバのMACアドレスです。デュアルブート
> で入っているWin2000に切り替えて念のために確認してみました。
ifconfigでわかります。
> 3.については、特にプロキシサーバとしての設定は行っていません。
> 実はLinux自体もテスト的にインストールしたもので、「最小構成」、
> 「ファイアウォールなし」の条件でインストーラに指示しました
> (ちなみにLinux自体のインストールは何度も経験しています)。
> その後で、iptablesの設定を加えた状況です。
>
> ですから、「完全にDROPした」状況で前述のような「開いたポート」
> が見えるのが不思議でなりません。
>
> > こういうネットワーク問題は、パケットキャプチャが一番早いです。Windows用もあるのでEtherealでパケット見れば、いろいろなケースでほぼ一発で原因がわかります。
>
> うう…パケットキャプチャですか…。私はやったこともないし、何か
> 敷居が高そうで抵抗がありますね…。
Linuxはデフォルトで入っています。生データが見えるので一発で核心に迫れますから、ググレば使いかたはいくらでも載っているので今のうちに習得しておくといいですよ。
> また、そもそもの疑問として、nmapで検出された情報はサーバのどこ
> にあるのか検討もつきません。私はポートスキャナも今回初めて使い
> ましたので、nmapに疑いを抱き、SuperScanという別のスキャナも
> 使ってみましたが、結果は同じでした。
完全にクライアントの問題と思います。テスト中はファイヤウォール等を止めてやるといいと思います。
・サーバのiptablesを開けて、かつコンソールで
# tcpdumpとやってから、windowsからpingを打ってみてください。応答がないのでは？
同時にサーバのコンソール上にパケットキャプチャされるはずですがこれも出ないのでは？
・ルータのLAN側(ゲートウェイアドレス)にもpingを打ってどうなるか？これも応答がないと思われ？
・下記を参考にhostsファイルにlocalhost以外ないことを確認する。
http://www.aconus.com/~oyaji/faq/apache_html3.htm
おやじさん、レスありがとうございます。
> > ですから、「完全にDROPした」状況で前述のような「開いたポート」
> > が見えるのが不思議でなりません。
> >
> > > こういうネットワーク問題は、パケットキャプチャが一番早いです。Windows用もあるのでEtherealでパケット見れば、いろいろなケースでほぼ一発で原因がわかります。
> >
> > うう…パケットキャプチャですか…。私はやったこともないし、何か
> > 敷居が高そうで抵抗がありますね…。
>
> Linuxはデフォルトで入っています。生データが見えるので一発で核心に迫れますから、ググレば使いかたはいくらでも載っているので今のうちに習得しておくといいですよ。
>
> > また、そもそもの疑問として、nmapで検出された情報はサーバのどこ
> > にあるのか検討もつきません。私はポートスキャナも今回初めて使い
> > ましたので、nmapに疑いを抱き、SuperScanという別のスキャナも
> > 使ってみましたが、結果は同じでした。
>
> 完全にクライアントの問題と思います。テスト中はファイヤウォール等を止めてやるといいと思います。
>
> ・サーバのiptablesを開けて、かつコンソールで
> # tcpdumpとやってから、windowsからpingを打ってみてください。応答がないのでは？
> 同時にサーバのコンソール上にパケットキャプチャされるはずですがこれも出ないのでは？
>
> ・ルータのLAN側(ゲートウェイアドレス)にもpingを打ってどうなるか？これも応答がないと思われ？
>
> ・下記を参考にhostsファイルにlocalhost以外ないことを確認する。
>
> http://www.aconus.com/~oyaji/faq/apache_html3.htm
おやじさんからのアドバイスを参考に、まず、クライアントWin98マシン
のNorton Internet Securityを無効にして nmapを実行してみまし
たが、結果は変わりませんでした。
また、おやじさんの言われる「サーバのiptablesを開けて」の意味が
わかりませんでしたが、サーバをこれまでの「全てDROP」の状態の
ままにし、
#tcpdump host 192.168.0.2
とした上で、クライアントのDOSプロンプトでpingとnmapを実行しま
した(サーバへのping、nmapで"open"と報告された25番ポートへの
狙い撃ちnmap、nmapで"open"と報告されなかった22番ポートへの
狙い撃ちnmap)。その様子が次のようになっています。
--------------------------------------------------------------
C:\nmap-3.93>ping 192.168.0.2
Pinging 192.168.0.2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.0.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\nmap-3.93>nmap -p 25 -sT 192.168.0.2
Starting nmap 3.93 ( http://www.insecure.org/nmap ) at 2005-09-23 23:43 東京 (標
準時)
Interesting ports on 192.168.0.2:
PORT STATE SERVICE
25/tcp open smtp
MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
Nmap finished: 1 IP address (1 host up) scanned in 12.460 seconds
C:\nmap-3.93>nmap -p 22 -sT 192.168.0.2
Starting nmap 3.93 ( http://www.insecure.org/nmap ) at 2005-09-23 23:44 東京 (標
準時)
Interesting ports on 192.168.0.2:
PORT STATE SERVICE
22/tcp filtered ssh
MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
Nmap finished: 1 IP address (1 host up) scanned in 33.180 seconds
--------------------------------------------------------------
一方、これに対応するサーバ側の出力は次のようになっていました。
--------------------------------------------------------------
23:43:31.846999 192.168.0.1 > 192.168.0.2: icmp: echo request
23:43:36.103040 192.168.0.1 > 192.168.0.2: icmp: echo request
23:43:40.109144 192.168.0.1 > 192.168.0.2: icmp: echo request
23:43:44.113772 192.168.0.1 > 192.168.0.2: icmp: echo request
23:44:01.821300 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
23:44:01.821335 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
23:44:01.910884 192.168.0.1.netbios-ns > 192.168.0.2.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST [tos 0x8]
23:44:03.415462 192.168.0.1.netbios-ns > 192.168.0.2.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST [tos 0x8]
23:44:04.915616 192.168.0.1.netbios-ns > 192.168.0.2.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST [tos 0x8]
23:44:07.141548 192.168.0.1.4318 > 192.168.0.2.smtp: S 19936065:19936065(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) [tos 0x8]
23:44:10.096092 192.168.0.1.4318 > 192.168.0.2.smtp: S 19936065:19936065(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) [tos 0x8]
23:44:16.146692 192.168.0.1.4318 > 192.168.0.2.smtp: S 19936065:19936065(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) [tos 0x8]
23:44:28.237957 192.168.0.1.4318 > 192.168.0.2.smtp: S 19936065:19936065(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) [tos 0x8]
23:45:49.922505 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
23:45:49.922538 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
23:45:50.019435 192.168.0.1.netbios-ns > 192.168.0.2.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST [tos 0x8]
23:45:51.521646 192.168.0.1.netbios-ns > 192.168.0.2.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST [tos 0x8]
23:45:53.021822 192.168.0.1.netbios-ns > 192.168.0.2.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST [tos 0x8]
23:45:54.575959 192.168.0.1.4320 > 192.168.0.2.ssh: S 20043399:20043399(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) [tos 0x8]
23:45:54.628158 192.168.0.1.rwhois > 192.168.0.2.ssh: S 20043451:20043451(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) [tos 0x8]
--------------------------------------------------------------
ちなみにサーバが192.168.0.2、クライアントが192.168.0.1です。
これらの結果を見てわかるように、サーバへのpingの応答はありません
でした。また、nmapでのパケットキャプチャで見ると、
192.168.0.1 -> 192.168.0.2へのパケットの流れはあっても、
192.168.0.2 -> 192.168.0.1へのパケットの流れはありません。
一方向のパケットの流れしかないのに、nmapでどうやって"open"と
判定しているのか不思議でなりません。
TCP/IPについての精密な知識のない私にはこの程度しか読み取れませ
んでしたが、このような結果から何かわかることがあればご教授頂け
たらあり難いと思っています。
> おやじさんからのアドバイスを参考に、まず、クライアントWin98マシン
> のNorton Internet Securityを無効にして nmapを実行してみまし
> たが、結果は変わりませんでした。
AntiVirusのメールスキャンを明示的に止めないと、これがSMTPとPOP3サーバとして反応してしまいます。つまり、完全に遮断しているサーバを狙っても25と110はopenになるということ。
> また、おやじさんの言われる「サーバのiptablesを開けて」の意味が
> わかりませんでしたが、サーバをこれまでの「全てDROP」の状態の
> ままにし、
これは、フィルタで全遮断だとnmapがおかしな振る舞いをするかも知れないと思ったので、フィルタを開けてという意味でした。
> #tcpdump host 192.168.0.2
>
> とした上で、クライアントのDOSプロンプトでpingとnmapを実行しま
> した(サーバへのping、nmapで"open"と報告された25番ポートへの
> 狙い撃ちnmap、nmapで"open"と報告されなかった22番ポートへの
> 狙い撃ちnmap)。その様子が次のようになっています。
> --------------------------------------------------------------
> C:\nmap-3.93>ping 192.168.0.2
>
> Pinging 192.168.0.2 with 32 bytes of data:
>
> Request timed out.
> Request timed out.
> Request timed out.
> Request timed out.
>
> Ping statistics for 192.168.0.2:
> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
> Approximate round trip times in milli-seconds:
> Minimum = 0ms, Maximum = 0ms, Average = 0ms
>
> C:\nmap-3.93>nmap -p 25 -sT 192.168.0.2
>
> Starting nmap 3.93 ( http://www.insecure.org/nmap ) at 2005-09-23 23:43 東京 (標
> 準時)
> Interesting ports on 192.168.0.2:
> PORT STATE SERVICE
> 25/tcp open smtp
> MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
>
> Nmap finished: 1 IP address (1 host up) scanned in 12.460 seconds
>
> C:\nmap-3.93>nmap -p 22 -sT 192.168.0.2
>
> Starting nmap 3.93 ( http://www.insecure.org/nmap ) at 2005-09-23 23:44 東京 (標
> 準時)
> Interesting ports on 192.168.0.2:
> PORT STATE SERVICE
> 22/tcp filtered ssh
> MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
>
> Nmap finished: 1 IP address (1 host up) scanned in 33.180 seconds
> --------------------------------------------------------------
>
> 一方、これに対応するサーバ側の出力は次のようになっていました。
> --------------------------------------------------------------
> 23:43:31.846999 192.168.0.1 > 192.168.0.2: icmp: echo request
> 23:43:36.103040 192.168.0.1 > 192.168.0.2: icmp: echo request
> 23:43:40.109144 192.168.0.1 > 192.168.0.2: icmp: echo request
> 23:43:44.113772 192.168.0.1 > 192.168.0.2: icmp: echo request
> 23:44:01.821300 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
> 23:44:01.821335 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
> 23:44:01.910884 192.168.0.1.netbios-ns > 192.168.0.2.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST [tos 0x8]
> 23:44:03.415462 192.168.0.1.netbios-ns > 192.168.0.2.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST [tos 0x8]
> 23:44:04.915616 192.168.0.1.netbios-ns > 192.168.0.2.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST [tos 0x8]
> 23:44:07.141548 192.168.0.1.4318 > 192.168.0.2.smtp: S 19936065:19936065(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) [tos 0x8]
> 23:44:10.096092 192.168.0.1.4318 > 192.168.0.2.smtp: S 19936065:19936065(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) [tos 0x8]
> 23:44:16.146692 192.168.0.1.4318 > 192.168.0.2.smtp: S 19936065:19936065(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) [tos 0x8]
> 23:44:28.237957 192.168.0.1.4318 > 192.168.0.2.smtp: S 19936065:19936065(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) [tos 0x8]
> 23:45:49.922505 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
> 23:45:49.922538 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
> 23:45:50.019435 192.168.0.1.netbios-ns > 192.168.0.2.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST [tos 0x8]
> 23:45:51.521646 192.168.0.1.netbios-ns > 192.168.0.2.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST [tos 0x8]
> 23:45:53.021822 192.168.0.1.netbios-ns > 192.168.0.2.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST [tos 0x8]
> 23:45:54.575959 192.168.0.1.4320 > 192.168.0.2.ssh: S 20043399:20043399(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) [tos 0x8]
> 23:45:54.628158 192.168.0.1.rwhois > 192.168.0.2.ssh: S 20043451:20043451(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) [tos 0x8]
> --------------------------------------------------------------
>
> ちなみにサーバが192.168.0.2、クライアントが192.168.0.1です。
>
> これらの結果を見てわかるように、サーバへのpingの応答はありません
> でした。また、nmapでのパケットキャプチャで見ると、
> 192.168.0.1 -> 192.168.0.2へのパケットの流れはあっても、
> 192.168.0.2 -> 192.168.0.1へのパケットの流れはありません。
>
> 一方向のパケットの流れしかないのに、nmapでどうやって"open"と
> 判定しているのか不思議でなりません。
hostsの件が書かれてませんが、これはもういいです。ウイルスに感染したりしていていないかが気になったのですが、tcpdumpでパケットが来ているので問題ないですね。最初のカキコにあるopenになっているポートの種類が気になったので、確認したしだいです。
25番は恐らくAntivirusです。22番はfilteredですからOKですよね。この状態で全ポートスキャンしたらどうですか？ 本来ならひとつもでないはず。
これで出ないなら、カキコ時点からいままでに何かしたはずです。
もしかしたら、nmap側でWin98固有問題があるかもしれませんが、おやじの環境ではXP sp2は特に問題なく、フィルタすれば止まりますし想定どおり動いています。
お世話になります。
> > おやじさんからのアドバイスを参考に、まず、クライアントWin98マシン
> > のNorton Internet Securityを無効にして nmapを実行してみまし
> > たが、結果は変わりませんでした。
>
> AntiVirusのメールスキャンを明示的に止めないと、これがSMTPとPOP3サーバとして反応してしまいます。つまり、完全に遮断しているサーバを狙っても25と110はopenになるということ。
へーぇ！ そんなことがあるんですか！ 考えもしませんでした。
> …(中略)…
> hostsの件が書かれてませんが、これはもういいです。ウイルスに感染したりしていていないかが気になったのですが、tcpdumpでパケットが来ているので問題ないですね。最初のカキコにあるopenになっているポートの種類が気になったので、確認したしだいです。
> 25番は恐らくAntivirusです。22番はfilteredですからOKですよね。この状態で全ポートスキャンしたらどうですか？ 本来ならひとつもでないはず。
> これで出ないなら、カキコ時点からいままでに何かしたはずです。
> もしかしたら、nmap側でWin98固有問題があるかもしれませんが、おやじの環境ではXP sp2は特に問題なく、フィルタすれば止まりますし想定どおり動いています。
言われる通り、クライアント側のNortonの電子メールスキャンをオフに
して、Nortonを「無効」にした上、「全てDROP」のサーバに対して
nmapを実行してみました。
--------------------------------------------------------------
C:\nmap-3.93>nmap -sT 192.168.0.2
Starting nmap 3.93 ( http://www.insecure.org/nmap ) at 2005-09-24 10:29 東京 (標
準時)
Interesting ports on 192.168.0.2:
(The 1658 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
81/tcp open hosts2-ns
82/tcp open xfer
83/tcp open mit-ml-dev
111/tcp open rpcbind
119/tcp open nntp
1080/tcp open socks
5190/tcp open aol
8080/tcp open http-proxy
MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
Nmap finished: 1 IP address (1 host up) scanned in 516.080 seconds
--------------------------------------------------------------
結果はこのようになっており、確かにおやじさんの仰られるように、
25番と110番ポートは報告されなくなりました。…が、それと入れ替わる
ようにして、22番と111番が新たに現われ、報告された総数は同じに
なってしまいました。うーん…
そこで、今度は、サーバ側を「全てREJECT」にし、クライアントは
同じ条件でnmapしてみました。すると、
--------------------------------------------------------------
C:\nmap-3.93>nmap -sT 192.168.0.2
Starting nmap 3.93 ( http://www.insecure.org/nmap ) at 2005-09-24 11:13 東京 (標
準時)
Interesting ports on 192.168.0.2:
(The 1660 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
80/tcp open http
81/tcp open hosts2-ns
82/tcp open xfer
83/tcp open mit-ml-dev
119/tcp open nntp
1080/tcp open socks
5190/tcp open aol
8080/tcp open http-proxy
MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
Nmap finished: 1 IP address (1 host up) scanned in 116.500 seconds
--------------------------------------------------------------
となり、さきほど新たに現われたポートは報告されなくなりました。
しかし、依然として訳のわからないポートが報告されているのには
変わりなく…(T_T)
以上のようにやってみましたが、何か考えられることがあれば教えて
頂ければありがたいです。
P.S. 私が前のカキコで忘れていたhostsファイルの件ですが、存在
しませんでした。hosts.samならあったんですが。
> > AntiVirusのメールスキャンを明示的に止めないと、これがSMTPとPOP3サーバとして反応してしまいます。つまり、完全に遮断しているサーバを狙っても25と110はopenになるということ。
>
> へーぇ！ そんなことがあるんですか！ 考えもしませんでした。
ウイルススキャナーはメールクライアント(Outlook express等）とメールサーバの間に入るメールproxyのようなもので、クライアントにとってはメールサーバを擬似して中身をチェックしているのです。
> 言われる通り、クライアント側のNortonの電子メールスキャンをオフに
> して、Nortonを「無効」にした上、「全てDROP」のサーバに対して
> nmapを実行してみました。
> --------------------------------------------------------------
> C:\nmap-3.93>nmap -sT 192.168.0.2
>
> Starting nmap 3.93 ( http://www.insecure.org/nmap ) at 2005-09-24 10:29 東京 (標
> 準時)
> Interesting ports on 192.168.0.2:
> (The 1658 ports scanned but not shown below are in state: closed)
> PORT STATE SERVICE
> 22/tcp open ssh
> 80/tcp open http
> 81/tcp open hosts2-ns
> 82/tcp open xfer
> 83/tcp open mit-ml-dev
> 111/tcp open rpcbind
> 119/tcp open nntp
> 1080/tcp open socks
> 5190/tcp open aol
> 8080/tcp open http-proxy
> MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
>
> Nmap finished: 1 IP address (1 host up) scanned in 516.080 seconds
> --------------------------------------------------------------
> 結果はこのようになっており、確かにおやじさんの仰られるように、
> 25番と110番ポートは報告されなくなりました。…が、それと入れ替わる
> ようにして、22番と111番が新たに現われ、報告された総数は同じに
> なってしまいました。うーん…
やはり、クライアントの問題かと思います。
これはプロキシーのようなものをスキャンしているとしか考えられないですね。但し、全てではないようです。
クライアントにいろいろ入れてませんか？ 5190のaolはAOLメッセンジャーのポートなのでAOLに行っているとしか思えないのですが？
あと、気になったのがクライアントのIPアドレスが192.168.0.1ということ。このアドレスはルータにもよりますがデフォルトのLAN側のアドレス、即ちクライアントのゲートウェイアドレスとなるアドレスですが、お使いのルータのLAN側アドレスは192.168.0.100とかですか？
> P.S. 私が前のカキコで忘れていたhostsファイルの件ですが、存在
> しませんでした。hosts.samならあったんですが。
98ならそれでOKです。
毎度お世話になります。
> > > AntiVirusのメールスキャンを明示的に止めないと、これがSMTPとPOP3サーバとして反応してしまいます。つまり、完全に遮断しているサーバを狙っても25と110はopenになるということ。
> >
> > へーぇ！ そんなことがあるんですか！ 考えもしませんでした。
>
> ウイルススキャナーはメールクライアント(Outlook express等）とメールサーバの間に入るメールproxyのようなもので、クライアントにとってはメールサーバを擬似して中身をチェックしているのです。
そうなのですか。勉強になりました。
> やはり、クライアントの問題かと思います。
> これはプロキシーのようなものをスキャンしているとしか考えられないですね。但し、全てではないようです。
> クライアントにいろいろ入れてませんか？ 5190のaolはAOLメッセンジャーのポートなのでAOLに行っているとしか思えないのですが？
> あと、気になったのがクライアントのIPアドレスが192.168.0.1ということ。このアドレスはルータにもよりますがデフォルトのLAN側のアドレス、即ちクライアントのゲートウェイアドレスとなるアドレスですが、お使いのルータのLAN側アドレスは192.168.0.100とかですか？
うーん。AOLメッセンジャーとかはWin98で使ったことないのですが、
"aol*.*"というワイルドカードでシステムを調べてみたら、AOLがらみ
のファイルは一応、あります。でも、これは私が入れたのではなくて、
PCベンダーが予め仕込んでおいたものだと思います。また、少なくと
もスタートアップに入れるようなことはしてません。[Ctrl]+[Alt]+
{Del]で「プログラムの強制終了」ダイアログを出して、裏で何か
それらしきものが走っていないか調べたのですが、ありませんでした。
ルータの件ですが、アドレスを192.168.0.254に変更してあります。
ネットワーク機器とLANのPCのアドレス空間を分離するためです。
また、あれから色々試してみました。クライアントPCは実はマルチ
ブートマシンになってまして、WinXPも入っています(マシンが非力で
実用で使う気にならないので放置してありますが)。一応、WinXP SP1
です。おやじさんの環境はWinXP SP2ということなので近づけてみる
意味で、このWinXPにnmapをインストールして試して見ました。
まず、WinXPクライアント側のNortonの電子メールスキャンをオフに
して、Nortonを「無効」にした上、「全てDROP」のサーバに対して
nmapを実行してみました。すると、結果は
-------------------------------------------------------------
C:\nmap-3.93>nmap -sT 192.168.0.2
Starting nmap 3.93 ( http://www.insecure.org/nmap ) at 2005-09-24 11:59 東京 (標
準時)
Interesting ports on 192.168.0.2:
(The 1660 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
80/tcp open http
81/tcp open hosts2-ns
82/tcp open xfer
83/tcp open mit-ml-dev
119/tcp open nntp
1080/tcp open socks
5190/tcp open aol
8080/tcp open http-proxy
MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
Nmap finished: 1 IP address (1 host up) scanned in 103.376 seconds
-------------------------------------------------------------
となりました。これは、サーバ側を「全てREJECT」にし、Win98クライ
アントは同じ条件でnmapしたのと同じです。さらに、念のために、
WinXPクライアントの条件は同じにしてサーバ側を「全てREJECT」と
してnmapしてみたのですが、結果は同じでした。
さらに、WinXPクライアントの条件は同じで、サーバのフィルターを
インストーラのファイアウォール設定で「セキュリティレベル：中」
という指定で生成したものでnmapしてみると、
-------------------------------------------------------------
C:\nmap-3.93>nmap -sT 192.168.0.2
Starting nmap 3.93 ( http://www.insecure.org/nmap ) at 2005-09-24 16:35 東京 (標
準時)
Interesting ports on 192.168.0.2:
(The 1659 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
81/tcp open hosts2-ns
82/tcp open xfer
83/tcp open mit-ml-dev
119/tcp open nntp
1080/tcp open socks
5190/tcp open aol
8080/tcp open http-proxy
MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
Nmap finished: 1 IP address (1 host up) scanned in 91.610 seconds
-------------------------------------------------------------
となります。これまでの結果と少し違っているだけです。インストーラ
が生成するフィルターでもこうなってしまうのです。
さらに、色々とググってみましたが、
・http://lists.freebsd.org/pipermail/freebsd-stable/2003-September/003743.html
・http://www.linuxarkivet.se/mlists/netfilter/0302/msg00187.html
・http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2003-09/0565.html
・http://spinics.net/lists/netfilter/msg14262.html
・http://hack2.dot.thebbs.jp/r.exe/1052631737.601-700 の発言[665]
というような情報はみつかりました。他にも類似の問題が出ている
ようです。しかし、これらには解決に至る情報はありませんでした。
FreeBSDでも起きているようですね。
以上ですが、これらを見て何かアドバイス頂けるならお願い致します。
でした。
> > クライアントにいろいろ入れてませんか？ 5190のaolはAOLメッセンジャーのポートなのでAOLに行っているとしか思えないのですが？
> > あと、気になったのがクライアントのIPアドレスが192.168.0.1ということ。このアドレスはルータにもよりますがデフォルトのLAN側のアドレス、即ちクライアントのゲートウェイアドレスとなるアドレスですが、お使いのルータのLAN側アドレスは192.168.0.100とかですか？
>
> うーん。AOLメッセンジャーとかはWin98で使ったことないのですが、
> "aol*.*"というワイルドカードでシステムを調べてみたら、AOLがらみ
> のファイルは一応、あります。でも、これは私が入れたのではなくて、
> PCベンダーが予め仕込んでおいたものだと思います。また、少なくと
> もスタートアップに入れるようなことはしてません。[Ctrl]+[Alt]+
> {Del]で「プログラムの強制終了」ダイアログを出して、裏で何か
> それらしきものが走っていないか調べたのですが、ありませんでした。
> ルータの件ですが、アドレスを192.168.0.254に変更してあります。
> ネットワーク機器とLANのPCのアドレス空間を分離するためです。
了解しました。
> また、あれから色々試してみました。クライアントPCは実はマルチ
> ブートマシンになってまして、WinXPも入っています(マシンが非力で
> 実用で使う気にならないので放置してありますが)。一応、WinXP SP1
> です。おやじさんの環境はWinXP SP2ということなので近づけてみる
> 意味で、このWinXPにnmapをインストールして試して見ました。
>
> まず、WinXPクライアント側のNortonの電子メールスキャンをオフに
> して、Nortonを「無効」にした上、「全てDROP」のサーバに対して
> nmapを実行してみました。すると、結果は
> -------------------------------------------------------------
> C:\nmap-3.93>nmap -sT 192.168.0.2
>
> Starting nmap 3.93 ( http://www.insecure.org/nmap ) at 2005-09-24 11:59 東京 (標
> 準時)
> Interesting ports on 192.168.0.2:
> (The 1660 ports scanned but not shown below are in state: filtered)
> PORT STATE SERVICE
> 80/tcp open http
> 81/tcp open hosts2-ns
> 82/tcp open xfer
> 83/tcp open mit-ml-dev
> 119/tcp open nntp
> 1080/tcp open socks
> 5190/tcp open aol
> 8080/tcp open http-proxy
> MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
>
> Nmap finished: 1 IP address (1 host up) scanned in 103.376 seconds
> -------------------------------------------------------------
> となりました。これは、サーバ側を「全てREJECT」にし、Win98クライ
> アントは同じ条件でnmapしたのと同じです。さらに、念のために、
> WinXPクライアントの条件は同じにしてサーバ側を「全てREJECT」と
> してnmapしてみたのですが、結果は同じでした。
>
> さらに、WinXPクライアントの条件は同じで、サーバのフィルターを
> インストーラのファイアウォール設定で「セキュリティレベル：中」
> という指定で生成したものでnmapしてみると、
> -------------------------------------------------------------
> C:\nmap-3.93>nmap -sT 192.168.0.2
>
> Starting nmap 3.93 ( http://www.insecure.org/nmap ) at 2005-09-24 16:35 東京 (標
> 準時)
> Interesting ports on 192.168.0.2:
> (The 1659 ports scanned but not shown below are in state: filtered)
> PORT STATE SERVICE
> 22/tcp open ssh
> 80/tcp open http
> 81/tcp open hosts2-ns
> 82/tcp open xfer
> 83/tcp open mit-ml-dev
> 119/tcp open nntp
> 1080/tcp open socks
> 5190/tcp open aol
> 8080/tcp open http-proxy
> MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
>
> Nmap finished: 1 IP address (1 host up) scanned in 91.610 seconds
> -------------------------------------------------------------
> となります。これまでの結果と少し違っているだけです。インストーラ
> が生成するフィルターでもこうなってしまうのです。
現象的にはクライアントと思いましたが、状況証拠的にはサーバくさくなってきましたね。このテストときtcpdumpしたらこれらのポート、特に5190とか8080はどうなっているんですかね？ ものすごいログになるから無理ですかね。
> さらに、色々とググってみましたが、
>
> ・http://lists.freebsd.org/pipermail/freebsd-stable/2003-September/003743.html
> ・http://www.linuxarkivet.se/mlists/netfilter/0302/msg00187.html
> ・http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2003-09/0565.html
> ・http://spinics.net/lists/netfilter/msg14262.html
> ・http://hack2.dot.thebbs.jp/r.exe/1052631737.601-700 の発言[665]
>
> というような情報はみつかりました。他にも類似の問題が出ている
> ようです。しかし、これらには解決に至る情報はありませんでした。
> FreeBSDでも起きているようですね。
情報が古すぎるのと、どれも尻切れトンボですね。
ところで、一番最初に言ったiptabelsを止めてスルーさせた場合も同じなのですかね？
このテストも意味があるのかわからないのですが、iptablesがおかしな振る舞いをしていないかの切り分けとして・・。
原点に戻ってですが、もしLinux側の問題だとしたらサポートが切れているRedHat8をいまさら追求しても意味がない(何で新規でRedHat8なのか？)と思うので、切り分けもかねて最新のデストリ(FC4とか)にしてみるという手はありませんか？
お世話になります。
> 現象的にはクライアントと思いましたが、状況証拠的にはサーバくさくなってきましたね。このテストときtcpdumpしたらこれらのポート、特に5190とか8080はどうなっているんですかね？ ものすごいログになるから無理ですかね。
WinXPクライアント側を前と同じ条件にして、サーバ側を「全てDROP」
で5190番と8080番に対してピンポイントでnmapしてみました。
・nmap -p 5190 -sT 192.168.0.2
・nmap -p 8080 -sT 192.168.0.2
の二つを。結果はもちろん"open"でしたが、このとき
#tcpdump -n host 192.168.0.2
とやってみた結果が以下です。
--------------------------------------------------------------
23:25:16.009819 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
23:25:16.009863 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
23:25:16.101950 192.168.0.1.1044 > 192.168.0.2.5190: S 209920792:209920792(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
23:25:19.084730 192.168.0.1.1044 > 192.168.0.2.5190: S 209920792:209920792(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
23:25:25.094938 192.168.0.1.1044 > 192.168.0.2.5190: S 209920792:209920792(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
23:25:27.399141 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
23:25:27.399157 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
23:25:27.534453 192.168.0.1.1046 > 192.168.0.2.webcache: S 212892696:212892696(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
23:25:30.504127 192.168.0.1.1046 > 192.168.0.2.webcache: S 212892696:212892696(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
23:25:36.514302 192.168.0.1.1046 > 192.168.0.2.webcache: S 212892696:212892696(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
--------------------------------------------------------------
やはり、192.168.0.1->192.168.0.1への一方向で、完全にDROPされて
います。恐らく、他のポートも同じ状況だろうと思います。
> ところで、一番最初に言ったiptabelsを止めてスルーさせた場合も同じなのですかね？
> このテストも意味があるのかわからないのですが、iptablesがおかしな振る舞いをしていないかの切り分けとして・・。
これもやってみました。WinXPクライアントは同じ条件で、サーバの
方は/etc/sysconfig/iptablesを削除して。「完全ACCEPT」です。
--------------------------------------------------------------
C:\nmap-3.93>nmap -sT 192.168.0.2
Starting nmap 3.93 ( http://www.insecure.org/nmap ) at 2005-09-24 23:34 東京 (標
準時)
Interesting ports on 192.168.0.2:
(The 1658 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
81/tcp open hosts2-ns
82/tcp open xfer
83/tcp open mit-ml-dev
111/tcp open rpcbind
119/tcp open nntp
1080/tcp open socks
5190/tcp open aol
8080/tcp open http-proxy
MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
Nmap finished: 1 IP address (1 host up) scanned in 340.660 seconds
--------------------------------------------------------------
これは「完全DROP」に比べて22番(ssh)と111番(rpcbind = sunrpc)
が増えているだけですね。ちなみに、この増えた二つは、netstat -a
を打った出力で"LISTEN"と出たものです(「Re: Windowsにproxyが
入ったままになってません？」参照)。ただ、smtpも"LISTEN"して
いたのにそれがnmapで検出されていないのが不思議です。
さらに、この「完全ACCEPT」に対して、上のピンポイントnmap(5190
番と8080番)をやってみました。結果は当然"open"でしたが、この時
のtcpdumpを同様にとってみました。すると、
--------------------------------------------------------------
23:43:37.394097 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
23:43:37.394141 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
23:43:37.487739 arp who-has 192.168.0.2 tell 192.168.0.1
23:43:37.487749 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
23:43:37.487859 192.168.0.1.2729 > 192.168.0.2.5190: S 568038727:568038727(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
23:43:37.487909 192.168.0.2.5190 > 192.168.0.1.2729: R 0:0(0) ack 568038728 win 0 (DF)
23:43:37.904570 192.168.0.1.2729 > 192.168.0.2.5190: S 568038727:568038727(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
23:43:37.904586 192.168.0.2.5190 > 192.168.0.1.2729: R 0:0(0) ack 1 win 0 (DF)
23:43:38.405387 192.168.0.1.2729 > 192.168.0.2.5190: S 568038727:568038727(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
23:43:38.405407 192.168.0.2.5190 > 192.168.0.1.2729: R 0:0(0) ack 1 win 0 (DF)
23:43:42.486006 arp who-has 192.168.0.1 tell 192.168.0.2
23:43:42.486173 arp reply 192.168.0.1 is-at 0:90:cc:51:5a:ec
23:43:48.683117 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
23:43:48.683131 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
23:43:48.775265 192.168.0.1.2731 > 192.168.0.2.webcache: S 570999792:570999792(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
23:43:48.775288 192.168.0.2.webcache > 192.168.0.1.2731: R 0:0(0) ack 570999793 win 0 (DF)
23:43:49.223736 192.168.0.1.2731 > 192.168.0.2.webcache: S 570999792:570999792(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
23:43:49.223749 192.168.0.2.webcache > 192.168.0.1.2731: R 0:0(0) ack 1 win 0 (DF)
23:43:49.724566 192.168.0.1.2731 > 192.168.0.2.webcache: S 570999792:570999792(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
23:43:49.724578 192.168.0.2.webcache > 192.168.0.1.2731: R 0:0(0) ack 1 win 0 (DF)
--------------------------------------------------------------
となっていました。この場合、「完全DROP」と違い、192.168.0.1と
192.168.0.2との間に双方向のやりとりがみられます。
> 原点に戻ってですが、もしLinux側の問題だとしたらサポートが切れているRedHat8をいまさら追求しても意味がない(何で新規でRedHat8なのか？)と思うので、切り分けもかねて最新のデストリ(FC4とか)にしてみるという手はありませんか？
実は私は理論化学・計算化学を専攻する学者でして、自宅に「計算
サーバ」を立てようと計画しているのです。現在の取り組みはその
下準備の一環なのです。また、その計算に使うプログラムがFORTRANで
書かれていまして、しかも、そのコードが特定のコンパイラのバー
ジョンやライブラリのバージョンに依存しているのです。その結果、
このプログラムの動作はRed Hat Linux 8でしか動作保証はされて
おりません。そういう事情があるため、Red Hat Linux 8にこだわら
ざるを得ないのです。いずれはこういう環境依存の部分を移植して
新しいデストリビューションでも走らせるようにはしたいのですが、
まず、動作が保証されている環境で確認をとる必要があるのです。
長々と書き連ねてしまいましたが、以上から何かわかることがありまし
たら宜しくお願い致します。
RedHat8の件は了解しました。何とかしたいですね。
環境を併せるべく、バックアップにRedHat8を入れてみました。懐かしい画面をひさびさにみました。
とはいっても同じ問題は当然発生せず、想定どおりの正常動作でした。
で、いくつかわかったわかったことは、今回の件と直接関係はないはずですが、とんとんさんのサーバ機はDNSが設定されていませんね。
/etc/resolv.confに、下記（1個でもよい）を追記してください。サーバ機はDNSがいらないと思っている方が多いですが、ないといろいろ問題がでます。メールでは必須です。
nameserver xxx.xxx.xxx.xxx (ISPのプライマリDNSのIPアドレス)
nameserver yyy.yyy.yyy.yyy (ISPのセカンダリDNSのIPアドレス)
と書いて気がついたのですが、このサーバ機は一回もインターネットアクセスしていないということでいいですよね。つまりアップデートもしていない。
以下、情報は理解しましたので、疑問点のみインラインで書きます。tcpdumpに存在しないのにopenになる件は問題点なので除外。
> > ところで、一番最初に言ったiptabelsを止めてスルーさせた場合も同じなのですかね？
> > このテストも意味があるのかわからないのですが、iptablesがおかしな振る舞いをしていないかの切り分けとして・・。
>
> これもやってみました。WinXPクライアントは同じ条件で、サーバの
> 方は/etc/sysconfig/iptablesを削除して。「完全ACCEPT」です。
> --------------------------------------------------------------
> C:\nmap-3.93>nmap -sT 192.168.0.2
>
> Starting nmap 3.93 ( http://www.insecure.org/nmap ) at 2005-09-24 23:34 東京 (標
> 準時)
> Interesting ports on 192.168.0.2:
> (The 1658 ports scanned but not shown below are in state: closed)
> PORT STATE SERVICE
> 22/tcp open ssh
> 80/tcp open http
> 81/tcp open hosts2-ns
> 82/tcp open xfer
> 83/tcp open mit-ml-dev
> 111/tcp open rpcbind
> 119/tcp open nntp
> 1080/tcp open socks
> 5190/tcp open aol
> 8080/tcp open http-proxy
> MAC Address: 00:90:CC:51:B2:BE (Planet Communications)
>
> Nmap finished: 1 IP address (1 host up) scanned in 340.660 seconds
> --------------------------------------------------------------
> これは「完全DROP」に比べて22番(ssh)と111番(rpcbind = sunrpc)
> が増えているだけですね。ちなみに、この増えた二つは、netstat -a
> を打った出力で"LISTEN"と出たものです(「Re: Windowsにproxyが
> 入ったままになってません？」参照)。ただ、smtpも"LISTEN"して
> いたのにそれがnmapで検出されていないのが不思議です。
これは、完全におかしいですね。後述しますがやはりnmapかwinpcapがくさいと思うのですが？
> さらに、この「完全ACCEPT」に対して、上のピンポイントnmap(5190
> 番と8080番)をやってみました。結果は当然"open"でしたが、この時
> のtcpdumpを同様にとってみました。すると、
> --------------------------------------------------------------
> 23:43:37.394097 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
> 23:43:37.394141 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
> 23:43:37.487739 arp who-has 192.168.0.2 tell 192.168.0.1
> 23:43:37.487749 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
> 23:43:37.487859 192.168.0.1.2729 > 192.168.0.2.5190: S 568038727:568038727(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
> 23:43:37.487909 192.168.0.2.5190 > 192.168.0.1.2729: R 0:0(0) ack 568038728 win 0 (DF)
> 23:43:37.904570 192.168.0.1.2729 > 192.168.0.2.5190: S 568038727:568038727(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
> 23:43:37.904586 192.168.0.2.5190 > 192.168.0.1.2729: R 0:0(0) ack 1 win 0 (DF)
> 23:43:38.405387 192.168.0.1.2729 > 192.168.0.2.5190: S 568038727:568038727(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
> 23:43:38.405407 192.168.0.2.5190 > 192.168.0.1.2729: R 0:0(0) ack 1 win 0 (DF)
> 23:43:42.486006 arp who-has 192.168.0.1 tell 192.168.0.2
> 23:43:42.486173 arp reply 192.168.0.1 is-at 0:90:cc:51:5a:ec
> 23:43:48.683117 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
> 23:43:48.683131 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
> 23:43:48.775265 192.168.0.1.2731 > 192.168.0.2.webcache: S 570999792:570999792(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
> 23:43:48.775288 192.168.0.2.webcache > 192.168.0.1.2731: R 0:0(0) ack 570999793 win 0 (DF)
> 23:43:49.223736 192.168.0.1.2731 > 192.168.0.2.webcache: S 570999792:570999792(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
> 23:43:49.223749 192.168.0.2.webcache > 192.168.0.1.2731: R 0:0(0) ack 1 win 0 (DF)
> 23:43:49.724566 192.168.0.1.2731 > 192.168.0.2.webcache: S 570999792:570999792(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
> 23:43:49.724578 192.168.0.2.webcache > 192.168.0.1.2731: R 0:0(0) ack 1 win 0 (DF)
> --------------------------------------------------------------
> となっていました。この場合、「完全DROP」と違い、192.168.0.1と
> 192.168.0.2との間に双方向のやりとりがみられます。
実は、これが非常におかしくて、これがopen表示になるということは、クライアントのnmapかwinpcapがおかしいのではないかと思えます。
nmap ----- http://download.insecure.org/nmap/dist/nmap-3.93-win32.zip
winpcap -- http://www.winpcap.org/install/bin/WinPcap_3_1.exe
から落としたと思うのですが、もう一度落としなおしてインストールしなおしてみませんか？
何がおかしいかと言うと、上記の最後の2行だけみると(その上も繰り返しているだけ),
上の行は、192.168.0.1から192.168.0.2に対してセッションを張るためのSYNパケットを示してます。これがポートスキャンのこと。
それに対して、下の行は192.168.0.2から192.168.0.1に対してセッションを拒否するRST ACKパケットが帰ってきていることを示してます。
この動作は、存在しないソケットに対する処理としてサーバ側はきわめて正常な動作をしています。もし本当に存在するなら、以下のようになるはず。111番をおやじの環境でキャプチャしたものです。
07:07:23.500611 192.168.0.1.1428 > 192.168.0.2.sunrpc: S 688625629:688625629(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
07:07:23.500692 192.168.0.2.sunrpc > 192.168.0.1.1428: S 168136840:168136840(0) ack 688625630 win 5840 <mss 1460,nop,nop,sackOK> (DF)
07:07:23.501079 192.168.0.1.1428 > 192.168.0.2.sunrpc: . ack 1 win 65535 (DF)
07:07:23.514237 192.168.0.1.1428 > 192.168.0.2.sunrpc: R 1:1(0) ack 1 win 0 (DF)
1行目：192.168.0.1から192.168.0.2に対してセッションを張るためのSYNパケットを示してます。
2行目：それを受けて192.168.0.2から192.168.0.1に対して返送されるセッション受付のSYN ACKパケットです。
3行目：SYN ACKを受けたと言う192.168.0.1から192.168.0.2への ACKパケットです。通常ならこの後通信が行われます。
4行目：セッションを開放するため192.168.0.1から192.168.0.2への RST ACKパケットです。これでセッションが開放されます。
お世話になります。
> RedHat8の件は了解しました。何とかしたいですね。
> 環境を併せるべく、バックアップにRedHat8を入れてみました。懐かしい画面をひさびさにみました。
> とはいっても同じ問題は当然発生せず、想定どおりの正常動作でした。
わーっ！ わざわざすみません。ありがとうございます。m(_ _)m
> で、いくつかわかったわかったことは、今回の件と直接関係はないはずですが、とんとんさんのサーバ機はDNSが設定されていませんね。
> /etc/resolv.confに、下記（1個でもよい）を追記してください。サーバ機はDNSがいらないと思っている方が多いですが、ないといろいろ問題がでます。メールでは必須です。
>
> nameserver xxx.xxx.xxx.xxx (ISPのプライマリDNSのIPアドレス)
> nameserver yyy.yyy.yyy.yyy (ISPのセカンダリDNSのIPアドレス)
>
> と書いて気がついたのですが、このサーバ機は一回もインターネットアクセスしていないということでいいですよね。つまりアップデートもしていない。
一応、resolv.confには記述してあります。
nameserver 192.168.0.254 (ブロードバンドルータです)
と。
> 実は、これが非常におかしくて、これがopen表示になるということは、クライアントのnmapかwinpcapがおかしいのではないかと思えます。
>
> nmap ----- http://download.insecure.org/nmap/dist/nmap-3.93-win32.zip
> winpcap -- http://www.winpcap.org/install/bin/WinPcap_3_1.exe
>
> から落としたと思うのですが、もう一度落としなおしてインストールしなおしてみませんか？
記載して頂いたURLからダウンロードして、再インストールしました。
でも、結果には変化はみられませんでした。
> 何がおかしいかと言うと、上記の最後の2行だけみると(その上も繰り返しているだけ),
> 上の行は、192.168.0.1から192.168.0.2に対してセッションを張るためのSYNパケットを示してます。これがポートスキャンのこと。
> それに対して、下の行は192.168.0.2から192.168.0.1に対してセッションを拒否するRST ACKパケットが帰ってきていることを示してます。
> この動作は、存在しないソケットに対する処理としてサーバ側はきわめて正常な動作をしています。もし本当に存在するなら、以下のようになるはず。111番をおやじの環境でキャプチャしたものです。
>
> 07:07:23.500611 192.168.0.1.1428 > 192.168.0.2.sunrpc: S 688625629:688625629(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
> 07:07:23.500692 192.168.0.2.sunrpc > 192.168.0.1.1428: S 168136840:168136840(0) ack 688625630 win 5840 <mss 1460,nop,nop,sackOK> (DF)
> 07:07:23.501079 192.168.0.1.1428 > 192.168.0.2.sunrpc: . ack 1 win 65535 (DF)
> 07:07:23.514237 192.168.0.1.1428 > 192.168.0.2.sunrpc: R 1:1(0) ack 1 win 0 (DF)
>
> 1行目：192.168.0.1から192.168.0.2に対してセッションを張るためのSYNパケットを示してます。
> 2行目：それを受けて192.168.0.2から192.168.0.1に対して返送されるセッション受付のSYN ACKパケットです。
> 3行目：SYN ACKを受けたと言う192.168.0.1から192.168.0.2への ACKパケットです。通常ならこの後通信が行われます。
> 4行目：セッションを開放するため192.168.0.1から192.168.0.2への RST ACKパケットです。これでセッションが開放されます。
一応私の方でもWinXPクライアントから"LISTEN"しているポートへ
ピンポイントでnmapしてみることにしました。サーバ側は前のカキコで
書いた、インストーラが生成したフィルタです。これは22番へのアク
セスを許可していますので。これをやってみると、
--------------------------------------------------------------
11:25:03.926115 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
11:25:03.926160 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
11:25:04.018303 192.168.0.1.1047 > 192.168.0.2.ssh: S 2891283584:2891283584(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
11:25:04.018377 192.168.0.2.ssh > 192.168.0.1.1047: S 3597010783:3597010783(0) ack 2891283585 win 5840 <mss 1460,nop,nop,sackOK> (DF)
11:25:04.018595 192.168.0.1.1047 > 192.168.0.2.ssh: . ack 1 win 64240 (DF)
11:25:04.019095 192.168.0.1.1047 > 192.168.0.2.ssh: R 2891283585:2891283585(0) win 0 (DF)
--------------------------------------------------------------
これを見ると概ねおやじさんのものと同様なのですが、ただ、最後の
行に"ack"がありません。これは問題ないのですかね？
私としてはRed Hatがおかしいと思っていたのでおやじさんの環境で
正常動作するというのは以外な感じでした。
また、これは私の感覚なのですが、どうも、iptablesによるフィルタは
ちゃんと動いているように見えるのです。tcpdumpをとった結果もそう
でしたし。だから、iptablesとtcpdumpの二つを使う作業で完結して
いる間は何ら問題はないように見えます。ただ、自分の設定に問題が
ないのかを確認するためにもnmapは是非とも使えるようにしたいところ
ですね。
以上です。ご意見をお待ちしております。
> 一応、resolv.confには記述してあります。
>
> nameserver 192.168.0.254 (ブロードバンドルータです)
>
> と。
おかしいですね。 もしそうなら、下記のようにtcpdumpでDNSを牽くシーケンスがarp解決のあとに入るはずなのですが？これは、サーバ側の話で直接本件にかかわる話ではないですが・・。
tcpdump: listening on eth0
12:39:24.278262 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
12:39:24.278293 arp reply 192.168.0.2 is-at 0:90:27:be:83:ad
12:39:24.279284 arp who-has 192.168.0.254 tell 192.168.0.2
12:39:24.279765 arp reply 192.168.0.254 is-at 0:b:a2:c:c2:b2
12:39:24.279779 192.168.0.2.32769 > 192.168.0.254.domain: 24494+ PTR? 2.0.168.192.in-addr.arpa. (43) (DF)
サーバからブラウザでyahooでも何でもいいので見れますか？ xが使えないなら下記で名前解決後データ（index.html）を取れますか？
# wget http://www.yahoo.co.jp/
>
> > 実は、これが非常におかしくて、これがopen表示になるということは、クライアントのnmapかwinpcapがおかしいのではないかと思えます。
> >
> > nmap ----- http://download.insecure.org/nmap/dist/nmap-3.93-win32.zip
> > winpcap -- http://www.winpcap.org/install/bin/WinPcap_3_1.exe
> >
> > から落としたと思うのですが、もう一度落としなおしてインストールしなおしてみませんか？
>
> 記載して頂いたURLからダウンロードして、再インストールしました。
後述のようにやはりnmapの動きがおかしいのですが、この再インストールはどうやりましたか？
特にnmapは単なるzipでなので、今あるフォルダを完全に削除してから新規にダウンロードしたファイルを解凍しないとほとんどのケースでは上書きしてくれないので、何も変わっていない可能性があります。
解凍しなおしてみてください。
> でも、結果には変化はみられませんでした。
>
> > 何がおかしいかと言うと、上記の最後の2行だけみると(その上も繰り返しているだけ),
> > 上の行は、192.168.0.1から192.168.0.2に対してセッションを張るためのSYNパケットを示してます。これがポートスキャンのこと。
> > それに対して、下の行は192.168.0.2から192.168.0.1に対してセッションを拒否するRST ACKパケットが帰ってきていることを示してます。
> > この動作は、存在しないソケットに対する処理としてサーバ側はきわめて正常な動作をしています。もし本当に存在するなら、以下のようになるはず。111番をおやじの環境でキャプチャしたものです。
> >
> > 07:07:23.500611 192.168.0.1.1428 > 192.168.0.2.sunrpc: S 688625629:688625629(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
> > 07:07:23.500692 192.168.0.2.sunrpc > 192.168.0.1.1428: S 168136840:168136840(0) ack 688625630 win 5840 <mss 1460,nop,nop,sackOK> (DF)
> > 07:07:23.501079 192.168.0.1.1428 > 192.168.0.2.sunrpc: . ack 1 win 65535 (DF)
> > 07:07:23.514237 192.168.0.1.1428 > 192.168.0.2.sunrpc: R 1:1(0) ack 1 win 0 (DF)
> >
> > 1行目：192.168.0.1から192.168.0.2に対してセッションを張るためのSYNパケットを示してます。
> > 2行目：それを受けて192.168.0.2から192.168.0.1に対して返送されるセッション受付のSYN ACKパケットです。
> > 3行目：SYN ACKを受けたと言う192.168.0.1から192.168.0.2への ACKパケットです。通常ならこの後通信が行われます。
> > 4行目：セッションを開放するため192.168.0.1から192.168.0.2への RST ACKパケットです。これでセッションが開放されます。
>
> 一応私の方でもWinXPクライアントから"LISTEN"しているポートへ
> ピンポイントでnmapしてみることにしました。サーバ側は前のカキコで
> 書いた、インストーラが生成したフィルタです。これは22番へのアク
> セスを許可していますので。これをやってみると、
> --------------------------------------------------------------
> 11:25:03.926115 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
> 11:25:03.926160 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
> 11:25:04.018303 192.168.0.1.1047 > 192.168.0.2.ssh: S 2891283584:2891283584(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
> 11:25:04.018377 192.168.0.2.ssh > 192.168.0.1.1047: S 3597010783:3597010783(0) ack 2891283585 win 5840 <mss 1460,nop,nop,sackOK> (DF)
> 11:25:04.018595 192.168.0.1.1047 > 192.168.0.2.ssh: . ack 1 win 64240 (DF)
> 11:25:04.019095 192.168.0.1.1047 > 192.168.0.2.ssh: R 2891283585:2891283585(0) win 0 (DF)
> --------------------------------------------------------------
> これを見ると概ねおやじさんのものと同様なのですが、ただ、最後の
> 行に"ack"がありません。これは問題ないのですかね？
これはおかしいですね。一番最後は、その前のSEQ 1 ACK1 で切るものなのでおやじのとおりでないとおかしいです。SuSEでもRedHatでも同じです。
ということで、nmapをもう一度入れなおしてみてください。
お世話になります。
> > 一応、resolv.confには記述してあります。
> >
> > nameserver 192.168.0.254 (ブロードバンドルータです)
> >
> > と。
>
> おかしいですね。 もしそうなら、下記のようにtcpdumpでDNSを牽くシーケンスがarp解決のあとに入るはずなのですが？これは、サーバ側の話で直接本件にかかわる話ではないですが・・。
>
> tcpdump: listening on eth0
> 12:39:24.278262 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
> 12:39:24.278293 arp reply 192.168.0.2 is-at 0:90:27:be:83:ad
> 12:39:24.279284 arp who-has 192.168.0.254 tell 192.168.0.2
> 12:39:24.279765 arp reply 192.168.0.254 is-at 0:b:a2:c:c2:b2
> 12:39:24.279779 192.168.0.2.32769 > 192.168.0.254.domain: 24494+ PTR? 2.0.168.192.in-addr.arpa. (43) (DF)
前のカキコを確認して頂くといいのですが、tcpdumpをとるときに、
-nオプションを立てて実行しています。本質的でないパケットが入り
込まないように気を使ったつもりでした。-nを外すとルータに問い合
わせにいきます。
> サーバからブラウザでyahooでも何でもいいので見れますか？ xが使えないなら下記で名前解決後データ（index.html）を取れますか？
>
> # wget http://www.yahoo.co.jp/
wgetで何やらデータが表示されました。
> 後述のようにやはりnmapの動きがおかしいのですが、この再インストールはどうやりましたか？
再インストールは、次のようにしました。まずコントロールパネルの「アプリケーションの追加と削除」でWincapを指定してアンインスト
ールしました。次にC:\NMAP-3.93フォルダごと削除した上で、nmap-
3.93-win32.zipを解凍してできたNMAP-3.93をC:\に移動しました。
> 特にnmapは単なるzipでなので、今あるフォルダを完全に削除してから新規にダウンロードしたファイルを解凍しないとほとんどのケースでは上書きしてくれないので、何も変わっていない可能性があります。
> 解凍しなおしてみてください。
仰ることは心得ておりましたので上記のように作業しました。
> > 一応私の方でもWinXPクライアントから"LISTEN"しているポートへ
> > ピンポイントでnmapしてみることにしました。サーバ側は前のカキコで
> > 書いた、インストーラが生成したフィルタです。これは22番へのアク
> > セスを許可していますので。これをやってみると、
> > --------------------------------------------------------------
> > 11:25:03.926115 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
> > 11:25:03.926160 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
> > 11:25:04.018303 192.168.0.1.1047 > 192.168.0.2.ssh: S 2891283584:2891283584(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
> > 11:25:04.018377 192.168.0.2.ssh > 192.168.0.1.1047: S 3597010783:3597010783(0) ack 2891283585 win 5840 <mss 1460,nop,nop,sackOK> (DF)
> > 11:25:04.018595 192.168.0.1.1047 > 192.168.0.2.ssh: . ack 1 win 64240 (DF)
> > 11:25:04.019095 192.168.0.1.1047 > 192.168.0.2.ssh: R 2891283585:2891283585(0) win 0 (DF)
> > --------------------------------------------------------------
> > これを見ると概ねおやじさんのものと同様なのですが、ただ、最後の
> > 行に"ack"がありません。これは問題ないのですかね？
>
> これはおかしいですね。一番最後は、その前のSEQ 1 ACK1 で切るものなのでおやじのとおりでないとおかしいです。SuSEでもRedHatでも同じです。
> ということで、nmapをもう一度入れなおしてみてください。
これについては私に知識がありませんのでよくわかりません。
何度同じことをやっても同じだと思ったものの、仰るようにもう一度
再インストールしてはみましたが、結果には変化はありませんでした。
以上です。よろしくお願い致します。
> > おかしいですね。 もしそうなら、下記のようにtcpdumpでDNSを牽くシーケンスがarp解決のあとに入るはずなのですが？これは、サーバ側の話で直接本件にかかわる話ではないですが・・。
> >
> > tcpdump: listening on eth0
> > 12:39:24.278262 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
> > 12:39:24.278293 arp reply 192.168.0.2 is-at 0:90:27:be:83:ad
> > 12:39:24.279284 arp who-has 192.168.0.254 tell 192.168.0.2
> > 12:39:24.279765 arp reply 192.168.0.254 is-at 0:b:a2:c:c2:b2
> > 12:39:24.279779 192.168.0.2.32769 > 192.168.0.254.domain: 24494+ PTR? 2.0.168.192.in-addr.arpa. (43) (DF)
>
> 前のカキコを確認して頂くといいのですが、tcpdumpをとるときに、
> -nオプションを立てて実行しています。本質的でないパケットが入り
> 込まないように気を使ったつもりでした。-nを外すとルータに問い合
> わせにいきます。
全てが見えているわけではないのと、視点が違うのと、自分でやっているわけではない限界ですね。No.5220以外のtcpdumpの説明には-nオプションはないですが、全て入っていたということですね。
> > サーバからブラウザでyahooでも何でもいいので見れますか？ xが使えないなら下記で名前解決後データ（index.html）を取れますか？
> >
> > # wget http://www.yahoo.co.jp/
>
> wgetで何やらデータが表示されました。
名前解決できて(www.yahoo.co.jpはx.xx.xxx.xxとでる)、index.htmlがダウンロードできたんですよね。wgetはこれから何度も使うことになるので、使い方を知らないとつらいですよ。
> > 後述のようにやはりnmapの動きがおかしいのですが、この再インストールはどうやりましたか？
>
> 再インストールは、次のようにしました。まずコントロールパネルの「アプリケーションの追加と削除」でWincapを指定してアンインスト
> ールしました。次にC:\NMAP-3.93フォルダごと削除した上で、nmap-
> 3.93-win32.zipを解凍してできたNMAP-3.93をC:\に移動しました。
>
> > 特にnmapは単なるzipでなので、今あるフォルダを完全に削除してから新規にダウンロードしたファイルを解凍しないとほとんどのケースでは上書きしてくれないので、何も変わっていない可能性があります。
> > 解凍しなおしてみてください。
>
> 仰ることは心得ておりましたので上記のように作業しました。
>
> > > 一応私の方でもWinXPクライアントから"LISTEN"しているポートへ
> > > ピンポイントでnmapしてみることにしました。サーバ側は前のカキコで
> > > 書いた、インストーラが生成したフィルタです。これは22番へのアク
> > > セスを許可していますので。これをやってみると、
> > > --------------------------------------------------------------
> > > 11:25:03.926115 arp who-has 192.168.0.2 (Broadcast) tell 192.168.0.1
> > > 11:25:03.926160 arp reply 192.168.0.2 is-at 0:90:cc:51:b2:be
> > > 11:25:04.018303 192.168.0.1.1047 > 192.168.0.2.ssh: S 2891283584:2891283584(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
> > > 11:25:04.018377 192.168.0.2.ssh > 192.168.0.1.1047: S 3597010783:3597010783(0) ack 2891283585 win 5840 <mss 1460,nop,nop,sackOK> (DF)
> > > 11:25:04.018595 192.168.0.1.1047 > 192.168.0.2.ssh: . ack 1 win 64240 (DF)
> > > 11:25:04.019095 192.168.0.1.1047 > 192.168.0.2.ssh: R 2891283585:2891283585(0) win 0 (DF)
> > > --------------------------------------------------------------
> > > これを見ると概ねおやじさんのものと同様なのですが、ただ、最後の
> > > 行に"ack"がありません。これは問題ないのですかね？
> >
> > これはおかしいですね。一番最後は、その前のSEQ 1 ACK1 で切るものなのでおやじのとおりでないとおかしいです。SuSEでもRedHatでも同じです。
> > ということで、nmapをもう一度入れなおしてみてください。
>
> これについては私に知識がありませんのでよくわかりません。
相変わらずこうであるなら、最後の一行はWindows側の挙動のためWindows側の問題に間違いない(etherealならもっとはっきりする）と思っており、表面上はこの違い以外は見えないので、これがnmapを入れ替えても駄目となるとこれ以上はおやじの知識では無理ですね。
おやじのほうは、サーバはSuSE9.3の64ビット/32ビット、RedHat8/9、FedoraCore4、CentOS4.1、クライアントはWinXP sp2 Pro/homeの2台を組み合わせてテストしてみましたが、全て同じ結果(想定どおりで内容も同じ)しかないので、これ以上はおやじにはアイデアがありません。
後、違いといえばWindowsサイズ。おやじの環境では毎回最大の65535であるがとん・とんさん は64240となっている。これは、とん・とんさんがクライアントでMTU調整(MSS=1460)をしているのかな？と。
もうひとつは、上記動作からクライアント側と思っているが、実はパケットの中身がおかしくてサーバ側に問題があるというケースがあります。まだサーバの再インストールはしてないですよね。最新版にアップデートをされているのでしょうか？
つい最近、会社の若い人が経験したトラブルで、一見動いていてエラーも何もでないのになぜかftpがうまく動作しないというトラブルがありました。正攻法でいろいろトラブル対策したが駄目で、結果的にそのデーモンを再度強制インストールしたら動作したというもので、ファイルが一部壊れていたとしか思えないトラブルがありました。
可能性がないわけではないので、触っていなければサーバ側の見直しもありかなと思います。
ただ、見えている現象は、「サーバ側は応答していない固有のポートがopen表示される」なので、やはりクライアントか？ とおやじの頭の中は堂々巡りですね。