ITSS ネットワーク 第五回 「その他のネットワーク技術」 2003/08/25-30 2003/09/01-06
コースの流れ 一日目:通信媒体とデータリンク 二日目:IP ルーティング 三日目:ネットワーク基盤サービス シングルホップの通信 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 socket protocol wait? User program arguments ftp stream tcp nowait root /usr/sbin/ftpd ftpd telnet stream tcp nowait root /usr/sbin/telnetd telnetd shell stream tcp nowait root /usr/sbin/rshd rshd login stream tcp nowait root /usr/sbin/logind logind After; ftp stream tcp nowait root /usr/sbin/tcps ftpd telnet stream tcp nowait root /usr/sbin/tcpd telnetd shell stream tcp nowait root /usr/sbin/tcpd rshd login stream tcp nowait root /usr/sbin/tcpdd logind (2) inetd のreread # kill -HUP pid-of-inetd-process
アクセス制御 3. ホスト・サービスのアクセス制御 (1) /etc/hosts.allow (2) /etc/host.deny 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
SOCKS 外部DNS mail.A.com : A1.1.1.3 Internet SOCKS Router Intranet 内部DNS www.B.com : A2.1.1.3 www.B.com 外部DNS mail.A.com : A1.1.1.3 www.A.com : A1.1.1.4 ftp.A.com : A1.1.1.5 Internet SOCKS Router A1.1.1.1 Application Gateway socks.A.com A1.1.1.2 Mail.A.com A1.1.1.3 www.A.com A1.1.1.4 ftp.A.com A1.1.1.5 Intranet 内部DNS socks.A.com : A1.1.1.2
Firewall System Configuration Internet 外とのProxy External Router 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マスカレード 家でブロードバンドルータを使っている人 プライベートIPアドレスはグローバルに変換される 家の中はプライベート ルータはグローバル、プライベート両方 Internet プライベート ネットワーク ブロードバンド ルータ グローバル IPアドレス 10.0.0.1 133.27.x.x プライベート 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 EGP The Internet (Exterior Gateway Protocol) IGP (Interior Gateway Protocol) IX (Internet eXchange) AS (Autonomous System) Private Peering
AS Autonomous System 自律システム インターネットをAS単位に分割 AS番号の割り当て 「単一のポリシで運用される経路制御ドメイン」 経路制御のための定義 インターネットを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 3 B 1 Loop? 2 4 C D と には自分 が既に A C AS C D A B 1 2 3 4 C D A C Loop? A C B A C B A C と 短いパス を採用
Internal BGP peer AS R Internal BGP Peer eBGP iBGP External BGP Peer IGP eBGP iBGP Internal BGP Peer External BGP Peer BGPの経路制御情報を 伝播できない
ルーティングポリシ ポリシーに基づく経路選択 他のISP(AS)とどのようにトラフィックをやりとりしたいか 単に近さやコストをもとにした選択ではない 他のISPとの間でどのように経路情報をやり取りするか 個々の目的地ごとに経路を選択する BGPのパス属性を用いる 経路情報のやり取りの制御だけでは実現できないポリシーもある ネットワークトポロジの再考などが必要
ルーティングポリシの実現 Multi Exit Discriminator Local Preference AS Path Prepend
ケーススタディ:MCC
ポリシールーティング
ポリシールーティング 宛先のみでなく、他の情報を使ってルーティングすること 送信元アドレス 受信インターフェイス ポリシ表 送信元S: ↑ 受信I/F IFa:↓ 経路表 D: → 宛先: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スイッチ
VRRP
VRRP Increasing Reliability and Failover with Virtual Router Redundancy Protocol simitaka
VRRP概要 目的 2個以上のゲートウエイルータ ホストは仮想的なIPアドレスをゲートウエイに single point of failureを無くす 2個以上のゲートウエイルータ バックアップルータを建てる ホストは仮想的なIPアドレスをゲートウエイに ディフォルトゲートウエイアドレスを変えずバックアップ
X VRRPの例 by RFC gateway1 gateway2 host1 host2 host3 host4 gatewayの変更 IP address A IP address B gatewayの変更 hostからaddressAに見えたまま VRID1:マスター VRID1:スレーブ X 仮想的にaddressAに見せる グループで一つの仮想 MACアドレスを持っている GW=A VRID = 1
VRRPまとめ ルータの冗長化 ユーザへの透過性 三つの状態 マルチキャストによるメッセージの交換 Initialize, Master, Backup マルチキャストによるメッセージの交換
トンネル・VPN
IP tunneling IP-in-IP encapsulationによりIP層での仮想ネットワークを実現可能にする技術 IPv6 over IPv4 Virtual Private Network(VPN) IPv4でのroutingしか行われていないnetworkでIPv6の通信を可能にする技術 IPv6のpacketにIPv4のヘッダを付加 IPv6 Hdr payload encapsulation IPv4 Hdr
IPv6 over IPv4 tunneling IPv6 packetにIPv4 headerを付加 IPv4 headerの宛先にてdecapsulateされた時、次のheaderがIPv6なので、そのままIPv6 packetとして配送 Internet IPv4 IPv4 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ミーティング 年3回(2回は北米、1回はその他) だれでも参加可能 組織の代表ではなく個人として参加 IETFというのはワーキンググループという小さなグループ単位で実際の活動を行っています。また議論はメーリングリストを基本に行われています。しかし、年に3回、ミーティングが開かれ、ここではface-to-faceでの議論がされます。
IETFの構成 IETF IESG Internet routing security IPv6 dhc ospf isis sasl エリア Internet routing security IETFの上にあるIESGと「エリア」、「WG」の大まかな位置づけを知ってもらう。 Working Group IPv6 dhc ospf isis sasl ipsec
エリア 構成 役割 エリアディレクタ WG(複数) WGの方向性ガイド WGの設立承認 WGの「区分」 例えば・・・ Internet(IPv6,DHC,MIP) Routing(ospf,isis) Security(IPsec,TLS)
WG(Working Group) テーマごとに分かれたグループ 役割 例 関連RFCに関する議論(メーリングリスト) 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の分類 Historic Standard Track Informational Experimental 標準化に関するもの その他 RFC
RFCの分類-Standard Trackー 標準化には3つの段階がある Proposed Standard 仕様が明確で多くの人に支持される見込みがある Draft Standard 複数の実装や運用がされている Standard 運用実績が十分 標準化する十分な有用性がある
RFCの分類-その他ー Informational Experimental Historic 有益な情報 標準化にはもっと実験・改良が必要 Historic 標準化されていたが今は使われないもの 新しいプロトコルの出現等 Ex.POP2,RIP、BGP3
RFCの草案 誰でも投稿することができる 投稿されたものは「Internet Draft」と呼ばれる 基本的に該当するWGのメンバ 投稿されたものは「Internet Draft」と呼ばれる この段階では「RFC」ではない 有用性を問う段階 標準化する価値があるか RFCとして保存しておく価値があるか WGでの議論を経てRFCにする申請がされる 再検討と言われたら再び議論 6ヶ月以内にいずれかの形にならないと破棄
承認 次の場面では承認が必要 IESGの承認を得る Internet DraftをRFCにする時 Proposed Std.⇒Draft Std.になる時 Draft Std.⇒Standardになるとき IESGの承認を得る 通らなければWGで再検討
RFCの流れ 破棄1 研究が求められる 6ヶ月経過 Internet Draft Experimental Standard Track 標準化提唱 Proposed Standard 4ヶ月経過後承認 しっかりした運営や実装がある Draft Standard 6ヶ月経過後承認 有効性が高く運用実績なども多い 有益情報 Standard 古い技術情報 Informational 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)