その1:DNS

p1-01

 

パケットキャプチャしている最中にレンタルサーバ(Lolipop)へのssh接続を行った。パケットキャプチャを停止すると下図のようなパケットが採取された。

p1-02

No20から始まる通信がSSHの通信。その前にSSHとは関係ないパケットが取得されているが、無視せず確認してみる。No1のパケットはDNSの要求、No2のパケットはDNSの応答。だが問い合わせの対象がlolipopではなく、eset.comになっている。No1のパケットの詳細を確認する。

p1-03

 

解析の欄は5つのブロックに分かれている。Frame 1:のブロックは、WireSharkがこのパケットについて解説してくれているもので、実際のパケットにはこのようなデータは無い。

Ethernetのブロックを確認する。

p1-04

Ethernetのブロックは3つに分かれている。1つ目はDestination、2つ目はSource、3つ目はTypeとなっている。
DestinationとSourceに記載されているアドレスはMACアドレス。MACアドレスは6Byteだが、表示されている文字は6Byte以上ある。Destinationアドレスはa0d37a4f6492。1Byte=8bitであり、2の8乗=256個の情報を表現できる。MACアドレスは16進数で表現されているので、最初の2桁を表現するのに必要な情報量は16*16bit=256bit。それが6セットあるので6Byteとなる。つまり、HonHaiPrなどの情報はWireSharkがMacアドレスに含まれるベンダーコードから、ベンダー名を割り出して表示している。Sourceも同様に6Byte。Typeはネットワーク層のプロトコルを識別するためのフィールドで、IPだと0800となる。表示は0x0800だが、0xも16進数であることを示すためにWiresharkが表示しているだけであって、実際にデータが流れているわけではない。データ部を見る通り、流れているデータは0800。つまりTypeは2Byteとなる。
合計するとEthernetヘッダは14Byteとなるが、Wiresharkの表示にはFCSは表示されていないし、容量としてカウントもされていない。FCSはOSがアプリに渡さないのでWiresharkは仕様的に取り込めないという理由らしいが、トレーラとして4ByteのFCSが存在している。Ethernetはヘッダ+トレーラで18Byteとなる。また、このパケットとは関係ないが、802.1qのタグが付与されたパケットはもっと大きくなる。Ethernetのパケットは、タグがつくとEthernetの最大サイズであるはずの1518Byteを超え、1522Byteになる。LANインターフェースはこの程度の超過には対応できる。だが、VXLANを用いる場合には更に50Byte増える。こうなってくると、ジャンボフレームとして扱わなければならない。因みにVMware の VXLAN の実装ではDF bit が 1 にセットされているので、MTUを超えるとDROPする。

次にIPヘッダ。IPヘッダは20Byte。

p1-05

日常的に確認する項目はSourceIPアドレスとDestinationIPアドレス。IPアドレスは4Byte。192.168.3.8が、クライアント端末のIPアドレス。パケットキャプチャを採取した端末でもある。宛先は192.168.3.1。端末のプレフィックスは24なので、この宛先IPアドレスは端末と同じサブネットに存在する。TTLが128になっている。128回ルーティングされると破棄される。この端末のOSはWindows10。

UDP。Destination Portが53ということで、DNSパケットとしてWiresharkに解釈されている。UDPのヘッダはとてもシンプルで8Byteしかない。TCPヘッダは20Byte。

DNS。i1.c.eset.comのAレコードを参照している。

p1-6

 

Flagsを確認する。
最初のQRフィールドは0なので照会であることを示す。1の場合は応答になる。
次のOpcodeフィールドは0なのでStandard queryであることを示す。Standard以外が指定されることは殆どない。
次のTCフィールドは0なので512Byte未満のデータであることを示す。
次のRDフィールドは1なので再帰問い合わせを要求している。
その下を見るとこのDNSパケットは1つのQuestionで構成されている。

ここまでがNo1のパケットだが、要するに192.168.3.1というDNSサーバに対してi1.c.eset.comのAレコードを参照している。
そしてその回答はNo2のパケットで帰ってくる。UDPレイヤまでは省略して、DNSの応答を確認する。

フラグ部分。

p1-7

 

QRフィールドは1なので応答であることを示す。
要求パケットには無かったRAフィールドがある。RDフィールドは再起問い合わせの要求で、RAフィールドはそれが可能かどうかを応答する。ここでは1がセットされているので、DNSサーバが再帰問い合わせの要求に応じている。
そしてこのDNSパケットの内容は、Question 1 Answer 3 Authority 3 Additional 3。まずAnswerセクションの詳細を確認する。

 

p1-8

queryは、要求パケットのオウム返しになっている。Answerは3つある。CNAMEが1つとAレコードが2つ。
CNAMEで、もともとAレコードを要求していたi1.c.eset.comがi1.cwip.eset.comに置き換えられている。
置き換えられたi1.cwip.eset.comのAレコードが2つ帰ってきている。端末は複数のAレコードが返却された場合には最初のレコードを優先する。次にAuthority nameserversセクションを確認する。
p1-9

Authority nameserversには、answersにあったAレコードの権威サーバが記載される。ここには3つNSレコードがあるが、実際に端末がこれらのNSにアクセスするわけではなく、再起問い合わせを行った結果。

最後にAdditional recordsセクションを確認する。

 

p1-10

Additional recordsは追加情報であり、ここでは権威サーバのAレコードが記載されている。

ここまでで、パケットNo1とNo2のDNSのやりとりが完了した。No3では解決したAレコードに対してHTTP通信を行ってる。
画面に表示されているパケットNo3-15までがひととおりのHTTP通信のやり取りになっている。

・192.168.3.8が91.228.167.86に対してTCPコネクションを作成。
・リクエストの内容はHTTP POSTメソッド
・リクエストの結果は正常終了
・TCPのコネクションも正常終了

 

no3のSynパケットのフラグ

p1-11

SP:50860
DP:80
Sequence number:0
Acknowledgment number:0

Header Lengthが32Byteになっている。TCPのヘッダサイズは20Byteだが、Optionで12Byteが上乗せされている。Flagsを見るとSynのみセットされている。

 

p1-12

MSSが1460Byteになっている。MTUは1500Byteである。そこからTCPヘッダ(20Byte)とIPヘッダ(20Byte)を引いた値になるため、標準的な値になっている。その他にWindowスケールShift Count8とSACKオプションLength2がセットされている。No4のパケットはSynに対するSynAck。

 

p1-13

サーバからのSequence Numberも0。Acknowledgment Numberは1。セッションを確立する時はシーケンス番号に1を足すので、No3に対するAckだとわかる。データを送受信する時は送信側のシーケンス番号に受信バイト数を加えた値になる。FlagはSynとAckのビットが立っている。Syn/Ackも20Byte+12Byteで32Byte。やはりオプションがついている。

 

p1-14

クライアントが送ったMSSは1460Byteだったのに対してサーバからのMSSサイズが1420Byteになっている。このパケットキャプチャを取得した環境はFTTH。回線側でL2フレームをカプセル化するため、MTUを超えないようにキャリア側ルータが書き換えていると考えられる。クライアントが送ったMSSの1460Byteも、レンタルされているブロードバンドルータが1420Byteに書き換えていると思われる。確かなことは仕様を確認しないとわからない。MSSを小さい値にするのは、フラグメントによるオーバーヘッドを避けるため。値をいくつにするかは、カプセル化の仕様によって変わる。

WindowスケールがShift Count7とSACKオプションLength2がセットされている。端末からのShift Countは8。次は3ハンドシェイク最後の、端末が送信するAckパケット。

p1-15

 

この時点でTCPオプションは無く、20ByteのTCPヘッダのみとなっている。Sequence numberは1。これはNo2で受け取ったAckに対して、続きのデータ送信であることを示す。Acknowledgment numberは1。これはNo2のパケットのシーケンス番号に1が足されたもの。

No6から端末からサーバへのデータ転送。1420Byteのデータを送信している。この数字はTCPのデータサイズ。L2のフレーム長で言うなら、1420+20(TCP header)+20(IP header)+14(Ethernet Header)+4(Ethernet FCS)=1478となる。WireSharkは1474と表示しているが、Wiresharkの表示にはFCSの4Byteがカウントされていない。

ヘッダの表示にハンドシェイクまではなかったTCP Segment Len:1420や、Next sequence number:1421が増えているが、[]内の表示は、WireSharkがつけた補足説明なので参考程度に確認する。
Sequence numberは1。Acknowledgment numberは1。まだ何も送受信していないのでいずれもNo5と同じ。
FlagはAckにビットが立っている。TCPは、Synパケット以外の全てのパケットはAckにビットが立っている。ここには関係ないが、この仕様を利用してCisco(だけでは無いと思うが)のEstablished ACLが成立する。Established ACLはAckフラグがついていないパケットをDROPする。

実際のデータの内容はNo6だけ見てもよくわからないが、No7を見ると1644ByteのデータをPOSTメソッドで送っているということがわかる。パケットは分割されているが、No6とNo7はもとは1つのデータである。アプリケーションが作成したひとまとまりのデータを、TCPパケットにする際にMSS値によって分割されてネットワークに伝送される。
この端末にはESETがインストールされている。何を送っているのかはわからないが、ESETが何か送っているようだ。ESETのやりとりはよくわからないので、ここでいったん解析を終了する。TCPとしては、あとはFINを交換するだけである。
長くなってしまったのでSSHの解析は次回にする。