httpの部分をフォーカスを当てました。tcpdump
①yahooさんからデータを受け取るまで。フラグにFがあります。通信を終了したいことを表しています。クライアント側から通信終了を伝えています。
20:33:18.489822 IP f1.top.vip.kks.yahoo.co.jp.http > 192.168.3.150.53223: Flags [P.], seq 1:557, ack 168, win 31, options [nop,nop,TS val 279445444 ecr 10715205], length 556
20:33:18.490051 IP 192.168.3.150.53223 > f1.top.vip.kks.yahoo.co.jp.http: Flags [F.], seq 168, ack 557, win 123, options [nop,nop,TS val 10715251 ecr 279445444], length 0
20:33:18.490128 IP f1.top.vip.kks.yahoo.co.jp.http > 192.168.3.150.53223: Flags [F.], seq 557, ack 168, win 31, options [nop,nop,TS val 279445444 ecr 10715205], length 0
※順番を並び変えております。
20:33:18.529480 IP f1.top.vip.kks.yahoo.co.jp.http > 192.168.3.150.53223: Flags [.], ack 169, win 31, options [nop,nop,TS val 279445487 ecr 10715251], length 0
20:33:18.489837 IP 192.168.3.150.53223 > f1.top.vip.kks.yahoo.co.jp.http: Flags [.], ack 557, win 123, options [nop,nop,TS val 10715251 ecr 279445444], length 0
20:33:18.490134 IP 192.168.3.150.53223 > f1.top.vip.kks.yahoo.co.jp.http: Flags [.], ack 558, win 123, options [nop,nop,TS val 10715251 ecr 279445444], length 0
データを終了したいフラグを立てています。
httpにアクセスする場合をパケットキャプチャーしてみよう。（DNSとHTTP）
Linuxサーバからwww.yahoo.co.jpにアクセスする
実行コマンド：curl --head http://yahoo.co.jp
パケット取得コマンド：tcpdump port 53 or port 80
それではパケットを見ていきましょう
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
①まず初めに、Linuxサーバがwww.yahoo.co.jpをDNSサーバへ問い合わせをおこなっています。
そもそもですが、DNSはUDP通信のため、フラグ等がありません。
20:33:18.374781 IP 192.168.3.150.33342 > google-public-dns-a.google.com.domain: 35479+ A? yahoo.co.jp. (29)
②次はDNSサーバの逆引きドメインをもらっている。。なぜ？？？
そもそもですが、DNSはUDP通信のため、フラグ等がありません。
20:33:18.375520 IP 192.168.3.150.34257 > google-public-dns-a.google.com.domain: 7657+ PTR? 8.8.8.8.in-addr.arpa. (38)
③IPV6用も聞いています。なぜ？？？？IPv6のモジュールをONにしているからかな。。
そもそもですが、DNSはUDP通信のため、フラグ等がありません。
20:33:18.375568 IP 192.168.3.150.33342 > google-public-dns-a.google.com.domain: 30346+ AAAA? yahoo.co.jp. (29)
④GoogleのDNSさんから回答。Aレコードは2tあるよと
20:33:18.401404 IP google-public-dns-a.google.com.domain > 192.168.3.150.33342: 35479 2/0/0 A 183.79.135.206, A 182.22.59.229 (61)
⑤1回のやりとりでは返せなかったのかな？？再度GoogleのDNSとやりとり
20:33:18.404026 IP google-public-dns-a.google.com.domain > 192.168.3.150.33342: 30346 0/1/0 (76)
⑥CDNか何か使っているんですかね？？直接yahoo.co.jpにはいけないようですね。ここからTCPの通信が始まります。
SYNパッケージをこちらからyahoo.co.jpらしき人に送っています。
20:33:18.404391 IP 192.168.3.150.53223 > f1.top.vip.kks.yahoo.co.jp.http: Flags [S], seq 592186689, win 14600, options [mss 1460,sackOK,TS val 10715166 ecr 0,nop,wscale 7], length 0
⑦yahoo.co.jpの代打の人から+1したackが返ってきました。ありがとうございます。
20:33:18.443536 IP f1.top.vip.kks.yahoo.co.jp.http > 192.168.3.150.53223: Flags [S.], seq 3051888169, ack 592186690, win 14480, options [mss 1460,sackOK,TS val 279445400 ecr 10715166,nop,wscale 9], length 0
⑧ではackを見やすいようtcpdumpさんが「1」にしました。ここから通信開始です。
20:33:18.443575 IP 192.168.3.150.53223 > f1.top.vip.kks.yahoo.co.jp.http: Flags [.], ack 1, win 115, options [nop,nop,TS val 10715205 ecr 279445400], length 0
⑨私からデータを送ります。
20:33:18.443689 IP 192.168.3.150.53223 > f1.top.vip.kks.yahoo.co.jp.http: Flags [P.], seq 1:168, ack 1, win 115, options [nop,nop,TS val 10715205 ecr 279445400], length 167
⑩ここでグーグルDNSさんから逆引き情報が届きました。。UDPで。
20:33:18.448094 IP google-public-dns-a.google.com.domain > 192.168.3.150.34257: 7657 1/0/0 PTR google-public-dns-a.google.com. (82)
⑪了解ですとGoogleさんのDNSに返事。
20:33:18.448371 IP 192.168.3.150.33395 > google-public-dns-a.google.com.domain: 41759+ PTR? 150.3.168.192.in-addr.arpa. (44)
⑫またGoogleさんとやりとり。次はNXdomain情報。？？
20:33:18.475236 IP google-public-dns-a.google.com.domain > 192.168.3.150.33395: 41759 NXDomain 0/0/0 (44)
⑬
20:33:18.475554 IP 192.168.3.150.37687 > google-public-dns-a.google.com.domain: 60830+ PTR? 206.135.79.183.in-addr.arpa. (45)
⑭以下のように続いていきます。。。
DNS通信が終わってhttpに通信に行くタイミングでもDNSとはちょくちょく会話するんですね。。。。
20:33:18.486560 IP f1.top.vip.kks.yahoo.co.jp.http > 192.168.3.150.53223: Flags [.], ack 168, win 31, options [nop,nop,TS val 279445443 ecr 10715205], length 0
20:33:18.489822 IP f1.top.vip.kks.yahoo.co.jp.http > 192.168.3.150.53223: Flags [P.], seq 1:557, ack 168, win 31, options [nop,nop,TS val 279445444 ecr 10715205], length 556
20:33:18.489837 IP 192.168.3.150.53223 > f1.top.vip.kks.yahoo.co.jp.http: Flags [.], ack 557, win 123, options [nop,nop,TS val 10715251 ecr 279445444], length 0
20:33:18.490051 IP 192.168.3.150.53223 > f1.top.vip.kks.yahoo.co.jp.http: Flags [F.], seq 168, ack 557, win 123, options [nop,nop,TS val 10715251 ecr 279445444], length 0
20:33:18.490128 IP f1.top.vip.kks.yahoo.co.jp.http > 192.168.3.150.53223: Flags [F.], seq 557, ack 168, win 31, options [nop,nop,TS val 279445444 ecr 10715205], length 0
20:33:18.490134 IP 192.168.3.150.53223 > f1.top.vip.kks.yahoo.co.jp.http: Flags [.], ack 558, win 123, options [nop,nop,TS val 10715251 ecr 279445444], length 0
20:33:18.529480 IP f1.top.vip.kks.yahoo.co.jp.http > 192.168.3.150.53223: Flags [.], ack 169, win 31, options [nop,nop,TS val 279445487 ecr 10715251], length 0
20:33:18.533594 IP google-public-dns-a.google.com.domain > 192.168.3.150.37687: 60830 1/0/0 PTR f1.top.vip.kks.yahoo.co.jp. (85)
FTPの通信をパケットキャプチャーしてみよう。
FTPの通信をパケットキャプチャーしてみよう。
参考URL
サーバ：Linuxサーバ
サーバ側でキャプチャーしてみました。
■FTP編
FTP基本：21番ポートが制御用
20番ポートがデータ用
コマンド：tcpdump port 20 or port 21
①まずクライアント側から サーバ側の21番ポートに対して、Flagが [S] SYN（コネクション確立要求）です。
シーケンス番号は「2155816753」windowサイズが8kb
17:36:16.965909 IP 192.168.3.2.49624 > 192.168.3.150.ftp: Flags [S], seq 2155816753, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
②次に、サーバ側の21番ポートから同様にFlags [S.]（コネクション確立要求）です。なんで[S.]があるんだろう？？
ACKがあることは、SYNに対する確認応答です。ACKは「2155816754」で+1されています。
17:36:16.965984 IP 192.168.3.150.ftp > 192.168.3.2.49624: Flags [S.], seq 2742584544, ack 2155816754, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7],
③フラグがなくなりました。ただしクライアント側からもきちんとACKしていますね。
ackの「1」は見やすくしているためで、本当は、+1しているので「2155816755」です。（余計にわかりにくいな。。。）
※ちなみにtcpdump に -S オプションをつけるとそのままのシーケンス番号を表示してくれる。
17:36:16.966903 IP 192.168.3.2.49624 > 192.168.3.150.ftp: Flags [.], ack 1, win 256, length 0
④21番ポートから20バイトのデータが送信されている。開始シーケンスと終了シーケンスが記載されている。
seq 1:21は"開始シーケンス番号:終了シーケンス番号" という意味らしい。納得。
1+20は21という感じかな
ちなみに、PはPUSH（バッファリングせず、即時にデータを送るようTCPに要求）
マスタリングTCP/IPには、Pがある場合は、バッファリングしてはならない。即座にデータを送信する必要あり。
17:36:16.970634 IP 192.168.3.150.ftp > 192.168.3.2.49624: Flags [P.], seq 1:21, ack 1, win 115, length 20
⑤次はクライアント側から13バイト送信している。
そのためシーケンス番号はseq 1:14で納得。ackもしており、21までokって。双方向通信だな。
17:36:16.975339 IP 192.168.3.2.49624 > 192.168.3.150.ftp: Flags [P.], seq 1:14, ack 21, win 256, length 13
⑥サーバ側から14番ack。今更だけど「.」（ドット）はフラグなしみたい。
17:36:16.975362 IP 192.168.3.150.ftp > 192.168.3.2.49624: Flags [.], ack 14, win 115, length 0
途中省略
⑦次にftp-dataからのコネクションのSYNパケットが開始される。
クライアント側から21番ポートにSYNを送って通信は開始されるが
20番ポートの場合は、サーバ側からSYNパケットが始まるんだ。今回はクライアント側からのPUTにも関わらず、、
17:36:17.035540 IP 192.168.3.150.ftp-data > 192.168.3.2.49625: Flags [S], seq 1545207833, win 14600, options [mss 1460,sackOK,TS val 93797 ecr 0,nop,wscale 7],
⑧これはseqが+1されているので問題なし。
17:36:17.036495 IP 192.168.3.2.49625 > 192.168.3.150.ftp-data: Flags [S.], seq 1 482706172, ack 1545207834, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS va l 122508 ecr 93797], length 0 length 0
⑨それでデータ転送が開始されていきます
17:36:17.036514 IP 192.168.3.150.ftp-data > 192.168.3.2.49625: Flags [.], ack 1, win 115, options [nop,nop,TS val 93798 ecr 122508], length 0
NATをする目的
よくお客様環境は100%NATされている。
その理由は？
一般的に言われる目的
IPv4のアドレス枯渇問題 ⇒ それは違う！！
大きく2つのパターンがある
①社内LANからサーバにアクセスする場合のNAT（インフラ、アプリ問わず）
やはり、1番の問題は、プライベートのLANの情報を公開したくない。
（※けどなんかあんまりいつも本当に意味あんのかなって思う。結局必要なポートを解放するわけで。。。。。）
最近は、VPN装置を介してアクセスさせるところが多い。私もこちらのほうが使いやすく好きです。
さらにVPN接続時にはワンパス発行にしている会社も多いので、これが私は一番好きです。セキュリティ的にも高い。
コストは無視して。。
②WEBサーバがFWでNATしている理由
FWで不要ポート等の攻撃を遮断したい。
サーバに直接侵入させたくない。あたりだろうか。
DMZからは、必要ポートのみを開けてAPLサーバへ ⇒ APLサーバから⇒ 必要なポートのみを許可してDBサーバへ
これが一番セキュリティが高そう。
DMZにWEBサーバが仮に侵入され、そこからDBサーバまでsshとかで接続でき、またはWEBサーバからSQL発行できたりしたら
それってどういう構成？？
その構成ならはっきり言ってインフラエンジニアいらねーだろってことだと思うんですよね。
よっぽどWEBサーバのセキュリティ構成に自信がある会社がやることだと思いますね。
JAVAでFTP接続してみよう。
以下のサイトを参照
自分で追加した作業
WindowsOSの環境変数に以下の追加
C:\Program Files\Java\jdk1.8.0_51\lib\commons-net-3.5.jar
以下のプログラムをコンパイル
※今回はPUTしかしていません。
import java.io.FileInputStream;
import java.io.FileOutputStream;
import org.apache.commons.net.ftp.FTPClient; //味噌
import org.apache.commons.net.ftp.FTPReply;
public class TestFtp {
public static void main(String[] arg) throws Exception {
FileOutputStream os = null;
FTPClient fp = new FTPClient();
FileInputStream is = null;
try {
fp.connect("192.168.3.150");
if (!FTPReply.isPositiveCompletion(fp.getReplyCode())) { // コネクトできたか？
System.out.println("connection failed");
System.exit(1); // 異常終了
}
if (fp.login("kenken", "kenken") == false) { // ログインできたか？
System.out.println("login failed");
System.exit(1); // 異常終了
}
// ファイル受信
//os = new FileOutputStream("c:/tmp/aaa.txt");// クライアント側
//fp.retrieveFile("/home/searchman/bbb.txt", os);// サーバー側
//os.close();
//System.out.println("FTP GET COMPLETED");
// ファイル送信
is = new FileInputStream("c:/tmp/aaa.txt");// クライアント側
fp.storeFile("/home/kenken/kenken.txt", is);// サーバー側
is.close();
System.out.println("FTP PUT COMPLETED");
} catch (Exception e) {
e.printStackTrace();
} finally {
fp.disconnect();
is.close();
//os.close();
}
}
}
