JAWS-FESTA2018_「細かくて伝わらないかもしれないネットワーク移行を見据えた事前調査」

JAWS-FESTA 2018 Osaka
細かくて伝わらない(かもしれない)
ネットワーク移行を見据えた事前調査
JAWS-FESTA 2018
Osaka
Nov. 3rd. 2018

自己紹介
1
今枝正志
（いまえだまさし）
■やっていること
ネットワーク系インフラ＆Linux OS の技術支援
＆マネージャー
■興味をもっていること
クラウドの技術とソリューション活用に関すること

本日の流れ
2
1. 背景
2. 困ったこと
3. 基本技術のおさらい
4. クラウド環境でやってみたこと
5. 結果
6. まとめ

本日のゴール
3
1. キラキラした今どきのサービスとか、すごい事例じゃな
くてもJAWS-UGで登壇できることを知ってもらうこと
2. 特殊ケースでのＮＷ移行を検討する時、低レイヤーも気
にしなきゃいけないことがあると知ってもらう

背景｜オンプレ間移行
4
拠点ビル
データセンター
組み込み系デバイス
組み込み系デバイス

困ったこと｜トラブル
5
・時々通信が切断されているようでデータが集まっていないように見えている
・移行前はなかった事象
問題：
・各ノードで確認すると収集サーバに到達していないパケットがある
・経路中でロストしている
状態：

困ったこと｜原因
6
・デバイスから送信されるＴＣＰに希少なフラグパターンを持つケースがある
・NW機器で不正なパターンとしてドロップしている
原因：

JAWS-FESTA 2018 Osaka 7
基本技術のおさらい
と
前提の知識

おさらい｜TCP
8
ＴＣＰは
Ｌ４のコネクション型プロトコル

おさらい｜TCP
9
three way handshake

おさらい｜TCP
10
three way handshake

おさらい｜TCP FLAGS （RFC793）
11
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP Header Format

前提知識｜NW機器が持つ機能
12
・ＴＣＰフラグに希少なパターンを持つケースがある
原因：
Firewall Switching Module (FWSM)
＋
Adaptive Security Appliance (ASA)

前提知識｜TCP正規化
13
TCP Normalization（TCP正規化）
不良TCPヘッダーのチェック・破棄
疑わしいTCPフラグのチェック・破棄
（不正なTCP FLAGの組み合わせ）

話題、戻ります

困ったこと｜原因
15
・デバイスから送信されるＴＣＰに希少なフラグパターンを持つケースがある
原因：
SYN を送る時に PSH フラグもつけていた
PSHフラグ：受信側で受け取ったデータをバッファリングせずにすぐにアプリケーションへ送信するために利用する。
TCPとアプリケーション間でバッファリングする必然性はなく、あまり意味のあるものとしては考えられていない。

環境だけ考えると、クラウドに持っていけそう。
でも、パブリッククラウドで提供されるネットワーク周りで
同じようなこと発生したりしない？？

ということで、
AWS VPCではどうなのか？
余計なFLAGがついたSYNを送信してみた。

確認した構成
18
TCP:8000に対して
FLAG付パケット送信
SGはTCPの8000番オープン
tcpdump で確認
受信プロセスで待受するわけでな
く、到達を確認する
hping3を利用してFLAG
をつける
送信ノード：受信ノード：

接続のパターン
19
i. AWS VPC から AWS VPC へインターネット経由
（同／別リージョン間でグローバルIPアドレス利用）
ii. AWS とは関係のない場所から送信
iii. AWS VPC Peering

結果｜From いろいろなところ
20
送信元 SYN ACK PSH FIN S+A S+P S+F S+P+F S+A+P+F
○ ○ ○ ○ ○ ○ ○ ○ ○
○ ○ ○ ○ ○ ○ ☓ ☓ ☓
○ ☓ ☓ ☓ ☓ ○ ☓ ☓ ☓
受信ノード：AWS VPC 内のEC2
送信ノード：インターネット経由になるノード
G社
M社

結果｜From VPC Peer
21
送信元 SYN ACK PSH FIN S+A S+P S+F S+P+F S+A+P+F
東京リー
ジョン内
VPC
○ ○ ○ ○ ○ ○ ○ ○ ○
バージニア
リージョン
VPC
○ ○ ○ ○ ○ ○ ○ ○ ○
受信ノード：AWS VPC 内のEC2
送信ノード：VPC Peering先にあるノード

参考でついでにやってみた｜To いろいろなところ
22
送信先 SYN ACK PSH FIN S+A S+P S+F S+P+F S+A+P+F
○ ○ ○ ○ ○ ○ ○ ○ ○
○ ○ ○ ○ ○ ○ ○ ○ ○
○ ☓ ☓ ☓ ☓ ○ ☓ ☓ ☓
受信ノード：インターネット経由になるノード
送信ノード：AWS VPC 内のEC2
G社
M社

結果と課題
23
結果：
｜現在、AWSでは、きっかけのSYN+PSHは問題なさそう
｜ AWSでは流れるデータは「共有責任モデル」のユーザ側として考慮してるっぽい
｜利用するクラウドサービスに依って状態が違う
｜送／受信で状況が違う場合がある

＋ＯＮＥ
24
なぜ、送信元にクラウドサービスを利用したか
｜オンプレ環境(オフィス環境)には、通常、Firewallがある
｜家から試すにしても、ホームルータがある
セキュリティが考慮され、illegal packet として扱われることもある。
検証するには邪魔になるので、素で動いてくれる環境を見つけることも
結構大切。

まとめ
25
 トラフィック特性には、トラフィック量、ピーク時間、利用するアプリケーションプ
ロトコルの特性だけでなく、低レイヤーなプロトコルも含まれる場合がある。
 クラウドサービスの機能変更は目に見えるサービスだけでないかもしれない。
 WEB系でないものをリフトする場合は特に注意して事前調査を。
 異常なトラフィックを検証するときは送信側もチェックする。

JAWS FESTA 2018
Osaka
Nov. 3rd. 2018

JAWS-FESTA2018_「細かくて伝わらないかもしれないネットワーク移行を見据えた事前調査」

More Related Content

Similar to JAWS-FESTA2018_「細かくて伝わらないかもしれないネットワーク移行を見据えた事前調査」

JAWS-FESTA2018_「細かくて伝わらないかもしれないネットワーク移行を見据えた事前調査」