Document

ITSS ネットワーク
第五回
「その他のネットワーク技術」
2003/08/25-30
2003/09/01-06
コースの流れ
• 一日目:通信媒体とデータリンク
– シングルホップの通信
– LAN、無線LAN、IP、ARP (実習)
• 二日目:IP ルーティング
– マルチホップの通信
– 静的経路設定、OSPF (実習)
• 三日目:ネットワーク基盤サービス
– 通信に必要なサービス
– DNS、DHCP (実習)
• 四日目:ネットワークの監視とデバッグ
– ネットワーク管理
– SNMP、tcpdump (実習)
• 五日目:その他のネットワーク技術
– フィルタ、BGP、冗長性、負荷分散、(試験)
ファイアウォール
パケットフィルタリング
アクセス制御
1.必要なサービスのみにしてしまう。
= 不要なサービスはシャットダウンする。
=> /etc/inetd.conf の不要な行をコメントアウト
(1) 共通; conmsat, finger, ntalk,
(2) クライアント; pop, imap
(3)ssh導入時; login, exec, shell, ftp
アクセス制御
2. tcp_wrapper
http://csrc/nist.gov/tools/tools.htm
(1) /etc/inetd.conf
Before;
#service
ftp
telnet
shell
login
socket protocol wait?
stream tcp
nowait
stream tcp
nowait
stream tcp
nowait
stream tcp
nowait
User
root
root
root
root
program
/usr/sbin/ftpd
/usr/sbin/telnetd
/usr/sbin/rshd
/usr/sbin/logind
arguments
ftpd
telnetd
rshd
logind
After;
#service
ftp
telnet
shell
login
socket protocol wait?
stream tcp
nowait
stream tcp
nowait
stream tcp
nowait
stream tcp
nowait
User
root
root
root
root
program
/usr/sbin/tcps
/usr/sbin/tcpd
/usr/sbin/tcpd
/usr/sbin/tcpdd
arguments
ftpd
telnetd
rshd
logind
(2) inetd のreread
# kill -HUP pid-of-inetd-process
アクセス制御
3. ホスト・サービスのアクセス制御
(1) /etc/hosts.allow
fingerd
: ophelia hamlet laertes
rshd,rlogind: LOCAL EXCEPT hamlet
telnetd,ftpd: LOCAL, .expcons.com, 192.1.4
(2) /etc/host.deny
tftpd : ALL : (/usr/sbin/safe_finger -l @%h |
/usr/sbin/mail -s %d-%h root) &
ALL : ALL
アクセス制御
1. セキュリティーポリシーを決める
2. ユーザーの認証(パスワード管理)
3. ファイルの保護
4. Secureなホストへの アクセスの方法
5. アクセス制御(xinetd,TCP wrappers)
→ 6. 暗号化 (IPsec)
(1) 暗号メール
(2) トランスポート層での暗号化
(3) IPsec
7. Firewall
4 Levels of Firewall Configurations
Internet
Intranet
(1) Simple gateway
Choke
Internet
Intranet
Proxyサーバ
Proxyサーバ
(2) Belt and Suspender
4 Levels of Firewall Configurations
Internet
Intranet
Proxyサーバ
(3) TIPなどによる接続
Internet
Intranet
(4) Disconnect
ファイアウォール
1. 経路情報の交換を停止
→ FW内の経路情報は外部に広告されない。
(注) Source routingで進入可能
2. パケットフィルタリング
socket{src_IP, src_port, dsrt_IP, dst_port}の情報
でフィルタリングを行う。
(注) - ftpなど相性がよくないアプリケーションが存在
(a) 公開されるべきサービス
WWW, anonymous-ftp, IRC
(b) 公開されるべきではないサービス
NIS, NFS, PRC, TFTP, SNMP
(c) 内向きを禁止すべきサービス
SMTP, NNTP, HTTP, FTP
ファイアウォール
3. アプリケーション ゲートウェイ ; Proxyサーバ
→ 各アプリケーションでProxyサービスを提供する。
e.g., SOCKS
ftp://ftp.nec.com/pub/security/socks.cstc/socks.cstc.4.2.tar.gz
www.B.com
外部DNS
www.B.com : A2.1.1.3
SOCKS
外部DNS
Internet
SOCKS
Router
mail.A.com : A1.1.1.3
www.A.com : A1.1.1.4
ftp.A.com : A1.1.1.5
A1.1.1.1
Application
Gateway
socks.A.com
A1.1.1.2
Mail.A.com www.A.com
A1.1.1.4
A1.1.1.3
内部DNS
socks.A.com : A1.1.1.2
Intranet
ftp.A.com
A1.1.1.5
Firewall System Configuration
Internet
External
Router
外とのProxy
Proxyサーバ
内とのProxy
内→外(直接)
フィルタリング
Proxyサーバ
パケットフィルタリング
特定のホスト間のみ
パケット交換を許容
Intranet
DoSアターック!
• DoS (Denial of Service) アタック
– 処理しなければならないパケットが多すぎ
– パケットが落ちる確率は同じ
– 嫌がらせ
ファイアウォール
NAT
グローバルアドレス/プライベート
アドレス
• グローバルアドレス
– 世の中全てに対して有効なIPアドレス
– 世界中で一意でなくてはならない
• プライベートアドレス
– プライベートな利用が可能なアドレス
– 自分で勝手に利用して良いアドレス
– 閉じたネットワーク内での利用が可能
– どんなアドレスを使っても良いけど、一応
• 10.0.0.0~10.255.255.255
• 172.16.0.0~172.31.255.255
• 192.168.0.0~192.168.255.255
– これらのアドレスは,グローバルインターネットの世界では使わな
いことにしてある
NAT(Network Address Translation)、
IPマスカレード
• グローバルホストとプライベー
トホストは通信不能
• どこかでプライベートIPアドレス
をグローバルIPアドレス対応さ
せる必要
• NAT、IPマスカレード
Interne
t
グローバル
IPアドレス
133.27.x.x
• 家でブロードバンドルータを
使っている人
• プライベートIPアドレスはグ
ローバルに変換される
– 家の中はプライベート
– ルータはグローバル、プラ
イベート両方
ブロードバンド
ルータ
10.0.0.1
プライベート
ネットワーク
プライベート
IPアドレス
10.0.0.2
10.0.0.25 10.0.0.154
NATで、できること/できないこと
• できること
• 自分からコネクションを張りに
行くもの
– WWWの閲覧
– IRCクライアント
– SSH
– メールの送信
– メールの受信
• できないこと
• 外からコネクションを張られる
もの
– 各種サーバの構築
– FTP(PassiveではないFTP)
FTPはプロトコル上ダウン
ロードする側に対してサー
バがコネクションを張りに
行く
– IMなどでのファイル交換
片方の人がNATの内側に
居るとできない
BGP
AS Hierarchy
The Internet
EGP
(Exterior Gateway Protocol)
IGP
(Interior Gateway Protocol)
Private Peering
IX (Internet eXchange)
AS (Autonomous System)
AS
Autonomous System
• 自律システム
– 「単一のポリシで運用される経路制御ドメイン」
– 経路制御のための定義
• インターネットをAS単位に分割
• AS番号の割り当て
– http://www.nic.ad.jp/jpnic/ipaddress/as-numbers.txt
BGP
Border Gateway Protocol
• 現在のAS間経路制御プロトコル(EGP)
• パスベクタ型アルゴリズム
– Loop Free
• ASレベルでのルーティングポリシーを実現
Path Vector Algorithm
には自分 A が既に
現れているので、ループを検知
D A C
A C
AS
A
C
AS
1
A C 2
B
Loop?
D A C
C
AS
3
4 B A C
AS
D
B A C と
A C
短いパス A C を採用
Internal BGP peer
Internal BGP Peer
eBGP
eBGP
External BGP Peer
R
iBGP
R
IGP
AS
BGPの経路制御情報を
伝播できない
ルーティングポリシ
• ポリシーに基づく経路選択
– 他のISP(AS)とどのようにトラフィックをやりとりしたい
か
• 単に近さやコストをもとにした選択ではない
• 他のISPとの間でどのように経路情報をやり取りす
るか
• 個々の目的地ごとに経路を選択する
• BGPのパス属性を用いる
– 経路情報のやり取りの制御だけでは実現できないポ
リシーもある
• ネットワークトポロジの再考などが必要
ルーティングポリシの実現
• Multi Exit Discriminator
• Local Preference
• AS Path Prepend
ケーススタディ:MCC
ポリシールーティング
ポリシールーティング
• 宛先のみでなく、他の
情報を使ってルーティ
ングすること
– 送信元アドレス
– 受信インターフェイス
宛先:D
ポリシ表
送信元S: ↑
受信I/F IFa:↓
経路表
D: →
L4スイッチ
スイッチ種類
switch
【レベル】1、【発音】swi't∫、【@】スイッチ、スウィッチ、【変化】《動》switches | switching |
switched
【名-2】 交換{こうかん}、交代{こうたい}、転換{てんかん}
【自動-1】 切り換わる、交代{こうたい}する
【自動-2】 移る
【他動-2】 (話題{わだい}・スイッチ)を切り換える
【他動-3】 ~を交換{こうかん}する、交代{こうたい}させる、取り替える、差し替える、
乗り換える
【他動-4】 ~を転換{てんかん}する、変える
–
–
–
–
L2スイッチ:MAC アドレスで Ethernet frame をスイッチ
L3スイッチ:IP アドレスで IP packet をスイッチ
L4スイッチ:フローで IP packet をスイッチ
L7スイッチ:アプリケーション層を認識して IP packet を
スイッチ(URLなど)
L4スイッチ用途
• サーバ冗長化・負荷分散
– QoS (Quality of Service) 制御
Internet
サーバ
L4スイッチ
サーバ
Internet
VRRP
VRRP
Increasing Reliability and Failover with
Virtual Router Redundancy Protocol
simitaka
VRRP概要
• 目的
– single point of failureを無くす
• 2個以上のゲートウエイルータ
– バックアップルータを建てる
• ホストは仮想的なIPアドレスをゲートウエイ
に
• ディフォルトゲートウエイアドレスを変えず
バックアップ
VRRPの例 by RFC
VRID1:マスター
gateway1
X
IP address A
gatewayの変更
hostからaddressA
に見えたまま
VRID1:スレーブ
gateway2
IP address B
仮想的にaddressAに見せる
グループで一つの仮想
MACアドレスを持っている
GW=A
host1
GW=A
GW=A
host2
host3
VRID = 1
GW=A
host4
VRRPまとめ
• ルータの冗長化
• ユーザへの透過性
• 三つの状態
– Initialize, Master, Backup
• マルチキャストによるメッセージの交換
トンネル・VPN
IP tunneling
• IP-in-IP encapsulationによりIP層での仮想ネッ
トワークを実現可能にする技術
– IPv6 over IPv4
– Virtual Private Network(VPN)
• IPv6 over IPv4
– IPv4でのroutingしか行われていないnetworkで
IPv6の通信を可能にする技術
– IPv6のpacketにIPv4のヘッダを付加
encapsulation
payload
IPv6 Hdr
payload
IPv6 Hdr IPv4 Hdr
IPv6 over IPv4 tunneling
• IPv6 packetにIPv4 headerを付加
– 通常のIPv4 packetととして配送される
– IPv4 headerの宛先にてdecapsulateされた時、次のheaderが
IPv6なので、そのままIPv6 packetとして配送
IPv4
IPv4
Internet
sfc.wide.ad.jp
so-net.ne.jp
IPv6 over IPv4
IPv6
IPv6
v6 host
v6 host
IETF
IETFとは
• Internet Engineering Task Force
• 1986年に発足
• インターネット技術の標準化を推進する任
意団体
– 誰でも参加可能
• 標準化をRFCという技術文章で公開
IETFの活動
• 標準化文章の公開と作成
– メーリングリスト上での議論
• 標準化すべく草案を練る
• IETFミーティング
– 年3回(2回は北米、1回はその他)
– だれでも参加可能
– 組織の代表ではなく個人として参加
IETFの構成
IETF
エリア
Working
Group
IESG
Internet
IPv6
dhc
routing
ospf
isis
security
sasl
ipsec
エリア
• 構成
– エリアディレクタ
– WG(複数)
• 役割
– WGの方向性ガイド
– WGの設立承認
– WGの「区分」
• 例えば・・・
– Internet(IPv6,DHC,MIP)
– Routing(ospf,isis)
WG(Working Group)
• テーマごとに分かれたグループ
–例
• IPv6(Internet)、IPsec(Security)、OSPF(Routing)
• 役割
– 関連RFCに関する議論(メーリングリスト)
– IESGに標準化の検討要請
– 必要に応じ作られ目的を完了したら解散
IESG(Internet Engineering Stearing
Group)
• 構成
– 各エリアのエリアディレクタ
• 役割
– WGの設立承認
– 標準化の最終検討
RFC(Request For Comment)
• IETFの公開する文章
– 標準化に関するもの(Standard Track)
• POP,SMTP,FTP,etc…
• メールアドレスやURLのフォーマット
– 標準化ではないが公開しておく価値のあるも
の
• インターネットの歴史
• WGガイドライン
ある国や企業の提案する標準化ではない
• プロトコルの運用方法
RFCの背景
• 昔のインターネット技術
– 技術開発はARPA/DARPAから資金援助
– 一般に公開不可
– 他の技術者と共有されない
• 公開するための抜け道
– 「コメント求む」というメモ
• 「標準化した規格」として公開してるのではない
– よりよくするためのコメントを世界中からもらう
RFCの分類-Standard Trackー
• インターネット標準化のためのRFC
• 標準化には3つの段階がある
– Proposed Standard
• 仕様が明確で多くの人に支持される見込みがある
– Draft Standard
• 複数の実装や運用がされている
– Standard
• 運用実績が十分
• 標準化する十分な有用性がある
RFCの分類-その他ー
• Informational
– 有益な情報
– Ex.インターネットの歴史,サービス運用方法
• Experimental
– 標準化にはもっと実験・改良が必要
• Historic
– 標準化されていたが今は使われないもの
• 新しいプロトコルの出現等
– Ex.POP2,RIP、BGP3
RFCの草案
• 誰でも投稿することができる
– 基本的に該当するWGのメンバ
• 投稿されたものは「Internet Draft」と呼ばれ
る
– この段階では「RFC」ではない
– 有用性を問う段階
• 標準化する価値があるか
• RFCとして保存しておく価値があるか
• WGでの議論を経てRFCにする申請がさ
承認
• 次の場面では承認が必要
– Internet DraftをRFCにする時
– Proposed Std.⇒Draft Std.になる時
– Draft Std.⇒Standardになるとき
• IESGの承認を得る
– 通らなければWGで再検討
破棄1
6ヶ月経過
研究が求められる
RFCの流れ
Internet Draft
Experimental
Standard Track
標準化提唱
Proposed Standard
4ヶ月経過後承認
しっかりした
運営や実装
がある
Draft Standard
6ヶ月経過後承認
有益情報
有効性が高く
運用実績な
ども多い
Informational
Standard
古い技術情報
Historic
まとめ
• インターネットのプロトコルはRFCで仕様が
公開されている。
• IETFはRFCというインターネット標準の文
章を作成している。
• RFCの標準化はInternet Draftとして提案さ
れた後、3段階のステップを経て行われる。
まとめ
• RFCは「 rough consensus and running
code 」というボトムアップの標準化
“We reject kings, presidents, and voting.
We believe in
rough consensus and running code.”
-Dave Clark (1992)