Tremaで試すFirewall
•
7 j'aime•7,345 vues
Tremaで試すFirewall - FW運用の理想と現実およびテストツール試作について -, 2013-11-16, Trema Day #4
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à Tremaで試すFirewall
Similaire à Tremaで試すFirewall (20)
Dernier
Dernier (9)
Tremaで試すFirewall
- 3. (注) • いわゆる”SDN”の話ではありません。 – “OpenFlowの応用” とかそういう方向。 • NWエンジニアよりの話です。 3
- 4. Q • 私はNWエンジニアである。 • 私はNWおよびFirewallの運用を 行っている/行ったことがある。 • ファイアウォール運用は正直も うやめたい/やりたくない。 4
- 5. “ACL” ? 5
- 6. FirewallとAccess Control List • Firewall (FW) ある特定のコンピュータネットワークとその外部との通信を 制御し、内部のコンピュータネットワークの安全を維持する ことを目的としたソフトウェア（あるいはそのソフトウェア を搭載したハードウェア）の技術概念 ファイアーウォール - Wikipedia http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%82%A2%E3%83%BC%E3%82 %A6%E3%82%A9%E3%83%BC%E3%83%AB • Access Control List (ACL) アクセス制御リスト（アクセスせいぎょリスト、Access Control List、ACL）とは、オブジェクト（受動体）に付属す る許可属性のリスト。コンピュータセキュリティにおけるア クセス制御を実現するために、誰にどのリソース（受動体） に対するどの操作を許可するかを列挙したもの。 アクセス制御リスト - Wikipedia http://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E5%88%B6%E5%BE %A1%E3%83%AA%E3%82%B9%E3%83%88 6
- 7. FirewallとAccess Control List • パケットフィルタ型FWについて扱う場合、 ACL = パケットフィルタのルール – 複数のエントリ(ACE: Access Control Entry)の集合 – 特定のトラフィック(フロー)を識別する情報 + 識別した情報に対するアクションの定義。 • アクセス制御 セキュリティ対策 – 余計な物は見せない触らせない。 7
- 8. ACL実例 (Cisco IOS) ip access-list extended GI0-OUT エントリ deny ip any 10.0.0.0 0.255.255.255 log (ACE) deny ip any 172.16.0.0 0.15.255.255 log deny ip any 0.0.0.0 0.255.255.255 log deny ip any 127.0.0.0 0.255.255.255 log deny ip any 192.0.2.0 0.0.0.255 log deny ip any 169.254.0.0 0.0.255.255 log deny ip any 224.0.0.0 31.255.255.255 log アクション フローの remark vpn 識別 permit udp any eq isakmp any remark permit to 6to4 permit ip any 192.88.99.0 0.0.0.255 permit 41 any 192.88.99.0 0.0.0.255 remark permit any from inside to outside permit icmp any any permit ip any any reflect iptraffic timeout 300 deny ip any any log ! 8
- 10. ACLしんどい • 増え続けるエントリ – 「謎エントリ化」問題 – 浪費される計算機資源 • ポリシと運用の破綻 – 「これ消したらどういう影響あるかわからないから、 消せないんだよね…」 – 「これ、何のために入れてあるんだっけ?」 – 「わかんねーからとりあえず突っ込んどけば?」 • 謎エントリの拡大再生産という悪循環 10
- 11. こうなる(実話) • 数百行オーダーのACLの乱立 – どこで何やってるのかわからないから、フィ ルタ要件追加にすごく時間がかかる。 – デバイスのメモリあふれ • フィルタ処理がTCAMで回らなくなる → CPUでまわるのでCPU利用率が異常上昇 → サービスレスポンスの急激な悪化 • 監視に応答しなくなってアラート • リモートログインすらまともにできない 11
- 12. どうしてこうなった? • FW(ACL)運用の複雑さ – メタ情報の管理の問題 • “Why” をどうやって管理するか – エントリ削除運用の徹底が難しい • 「やれてることがやれなくなる」リスク • どうしてもACLが肥大化する傾向にある – ルールと用途の重複 • ネットワークトポロジの考慮も必要 12
- 14. FW(ACL)運用の複雑さ • そもそも「要件」相当の情報がない – 直接実機上で変更して終わり、という運用。 – どのエントリが何のためにあるのか、わからなく なっていく。 • (初期)要件の情報はあれども、実機利用され てるACLと整合性がとれていない – 何もないよりマシ、程度。 • 結局、実機情報ベースで力業…orz – ACL自体にコメント書けるけど(remark)、1エン トリに複数要件が被るものをコメントで管理する のは非現実的。 14
- 15. FW(ACL)運用の複雑さ ネットワークトポロジの加味 → ネットワーク構造による 要件とACLの多重化 (本気でやるとルーティングとか 実装し始めかねない) リストの順序依存性 → 要件でブロック化しにくい → エントリの包含関係・競合 利用位置・利用者・アプリケー ションなどによる制御(5W1H) → 業務要件との密接な連携 フィルタ位置とポリシルールの 整合性 → 入口/中間/出口 → 単一の要件・複数の表現 15
- 17. ここがしんどいFW(ACL)運用 • どんどん増える/消せない • 要件が多重化しすぎてわけわからん • 暗号解読状態(歴史とか推理とか…) • ミスって誤フィルタはいると大変 • 放置して穴だらけになってもいけない ＿人人人人人人人人＿ ＞ ACL塩漬け運用 ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^￣ 17
- 18. ここがしんどいFW(ACL)運用 • 機器の更新とか…どうする…… – ACLがもう機器の限界まで入っているから、 上位グレード機器でスケールアップさせると いう力業 • 有効なエントリって、そのうち何割だろう? • 消極的投資 – ACLが移行(変換)できなくて他ベンダ機器が 選択できないとか… 18
- 21. FW運用のキモ • いかに「やりたいこと」と実際のACLとの 乖離を防ぐか。 • 「やりたいこと」の管理 – いる・いらないの定期的な見直し – 不要エントリ削除の運用 • 削除運用がないと管理対象が減らない。 • 定期的なポリシ見直しのないセキュリティ運用は、 強度が落ちる一方。 21
- 23. こうだろ Human Readableで ベンダ非依存の ACL定義情報 メタ情報 記述 コード (ACL)の 生成と 最適化 ツール デプロイ まで自動 化できる とgood ACL • メタ情報を残す(冗長・重複で良いので情報を ちゃんと記録する) • ツールを使ってコード(ACL)を生成する。 • 生成時に最適化が行われて、冗長なエントリは 束ねられる。 • 生成されたコードを機器に投入する。 23
- 24. ツール例 • capirca - Multi-platform ACL generation system https://code.google.com/p/capirca/ – Cisco/Juniper/iptablesのACL生成 Enterprise QoS, Tim Chung, Google Corporate Netops Architecture, Nanog 49, June 15th, 2010. http://www.nanog.org/me etings/nanog49/presentati ons/Tuesday/ChungEnterpriseQoS-final.pdf 24
- 25. ツール例 • Filter Language Compiler http://coombs.anu.edu.au/~avalon/flc.html – Cisco/ipfw など。開発とまってる気配 25
- 27. 壁 • ゼロから作るなら、ある程度はやれる。 – FW単体については。トポロジ情報の考慮まではまだ難しい。 • 今の環境をどうするか… メタ情報 記述 ? • 既存のACLを解析・最適化・メタ情報化したい • メタ情報との不整合を解消・照合したい • 既存のACLを別な機器用に変換・移行・更新したい 27
- 28. いちめんのACL いちめんのACL • 人力でがんばる – 量的に無理。品質と精神が崩壊する。 • ツール – ACLを解析するツール? – ACL Parser? – ACL生成はあるけどその逆はあまりない 作ってみた① 28
- 29. …ない? • それっぽいのはあるけど – aclcheck - Cisco ACL checker https://code.google.com/p/aclcheck/ – でも、やりたいのは syntax check だけじゃ ないんだ… 29
- 30. ACL Parse • ACL読める → 応用 – Syntax check – 最適化 – 変換 (Compile) • メタ情報記述への変換 • 他ベンダACLへの変換 – FWシミュレーション • トポロジ構成まで シミュレートしようとすると ソフトウェア的なものが欲しい。 これ消したら、 どういう影響あ るかわからない から、消せない んだよね… シミュレータで テストしろよ! (ってやれるよう にしたい) 30
- 32. オーディオマニアの友人に、「セレク タを作っている」と話したところ、「そ れは、相当のめり込んだマニアが 手を出す物だ」と指摘されてしまった。 最初に観測方法を確立してから次 のステップへ進むという手順は、確 かに工学的あるいは研究的なスタ ンスかもしれない。 森博嗣 2007年1月28日(日) MORI LOG ACADEMY, vol.6, 森博嗣, メディアファクトリー, 2007. 32
- 33. シミュレーションとテスト • シミュレーションしたら、シミュレートでき ているかどうかを確認しなければいけない。 – 確認する方が難しい && 重要 • 変更したときに、やりたいことがすべて満た せているかどうかを確認しながら運用したい。 – 再現性・網羅性のある自動テストで品質担保を。 – テスト駆動開発(TDD)的な考え方でFirewallを運 用できるようになったらいいなあ。 33
- 37. ACL Tester • パケット生成してPacket-out/Packet-in • パケット生成 – Trema/PIO https://github.com/trema/pio • テストルール元にパケットを生成して、 投げて、受信できた/できなかった…を確 認してやれば、ACLのチェックができそう。 作ってみた③ 37
- 40. Implementation • 個人的な都合でCisco IOS ACLを対象に。 • Ruby/RaccによるParserの実装 • 目標はIOS ACL全機能の網羅 – 前にSyntaxだけは実装してみたことがあった • とりあえずよく使う機能の実装 – Named/Numbered, Extended/Standard – 基本的なL3/L4, ポートマッチング 40
- 41. ACL Class Structure • よく使う機能に絞ったつもりだけど… • 実装がわりとad-hocなので構造がコレで いいのかは微妙な気がする。 41
- 42. Cisco IOS ACL Syntax Tree • とても機械処理しにくいフォーマット – だから正規表現じゃなくてparserにしたんだけど • かつて挑戦して途中で挫折しました… – というか無駄が多い気がするが… Road to Cisco ACL Parser(3) - # cat /var/log/stereocat | tail -n3 http://d.hatena.ne.jp/stereocat/20110911/1315716668 42
- 44. 実行例(syntax check) Typo (“tcp” → “tco”) Number (not masked) 44
- 46. 実装 • Simple Routerを改造 – 転送する前にACLとの照合 – マッチしたACLのアクション(Permit/Deny) に応じて、そのままOutPortかDropかを指定 してやれば良い。 – 片方向(inbound)だけフィルタするモデル 46
- 47. FW Config $interface = [ { :port => 1, :hwaddr => "00:00:00:01:00:01", :ipaddr => "192.168.1.1", :masklen => 24, :filter_file => "filters.acl", :infilter => 1 }, { :port => 2, :hwaddr => "00:00:00:01:00:02", :ipaddr => "192.168.2.1", :masklen => access-list 1 permit 24 access-list 1 deny } access-list 1 permit ] access-list 1 deny ACLファイルと ACL名(ACL番号) を指定してやる 192.168.1.0 192.168.1.64 192.168.1.128 192.168.1.192 0.0.0.63 0.0.0.63 0.0.0.63 0.0.0.63 47
- 48. Packet-in 処理(1) def handle_ipv4( dpid, message ) if filtered?( dpid, message ) send_drop_flow_mod dpid, message return end true (denied) ならdrop actionの フローを追加する if should_forward?( message ) forward dpid, message elsif message.icmpv4_echo_request? handle_icmpv4_echo_request dpid, message else # noop. 転送処理は end Simple Routerの処理 end そのままでOK 48
- 49. Packet-in 処理(2) def srcdst_match packet_in opts = { :dl_type => packet_in.eth_type, :nw_src => packet_in.ipv4_saddr.to_s, :nw_dst => packet_in.ipv4_daddr.to_s, } if packet_in.tcp? opts[ :nw_proto ] = 6 opts[ :tp_src ] = packet_in.tcp_src_port opts[ :tp_dst ] = packet_in.tcp_dst_port elsif packet_in.udp? opts[ :nw_proto ] = 17 opts[ :tp_src ] = packet_in.udp_src_port opts[ :tp_dst ] = packet_in.udp_dst_port elsif packet_in.icmpv4? Dropするフローは opts[ :nw_proto ] = 1 L3/L4マッチで指定 end (拡張ACLレベル) Match.new opts end 49
- 50. def filtered?( dpid, message ) port = message.in_port interface = @interfaces.find_by_port( port ) infilter = interface.infilter filtered = false # not filtered if infilter opts = { :src_ip => message.ipv4_saddr.to_s, :dst_ip => message.ipv4_daddr.to_s } ACL マッチング Config File (略: Packet-in object からACL検索オプション情報生成) ACLマッチ検索 ace = infilter.search_ace( opts ) if ace # when found matched ace ACL Actionに応じて case ace.action ログ出力して when "permit" フラグ決めて終わり。 info "packet permitted # #{ _pph(opts) }" when "deny" info "packet denied (explicitly) # #{ _pph(opts) }" filtered = true end else # not found matched entry info "packet denied (implicitly) # #{ _pph(opts) }" filtered = true end 暗黙のdeny end return filtered 50 end
- 53. 宛先解決問題 • Sender – パケットを生成→どこに投げるか – L2 next hop (dst MAC) • Sender は全部 default gateway に投げるのでL2では投げ先固 定。今回は Static に指定してarp 解決はしていない • Receiver – FW(DUT)は生成されたパケットをどこかに投げようとす る • テストケースに応じて変動するIP/MACを解決して受信しなけ ればいけない。 • 任意の ARP Request をControllerが吸い込む – Simple Router(FW)は1回目のパケット送信はARP解決の ためできないので、2回(以上)繰り返してやる必要がある。 • いきなりパケット送ってる → Unknown Unicast処理させてる 53
- 54. 宛先解決問題 def echo_arp_request dpid, message info "[handle_arp_request] #{dpid.to_hex}" arp_reply = Pio::Arp::Reply.new( :source_mac => @bridge[ @receiver_dpid ][ :src_mac ], :destination_mac => message.arp_sha.to_s, :sender_protocol_address => message.arp_tpa.to_s, :target_protocol_address => message.arp_spa.to_s ) action = SendOutPort.new( message.in_port ) packet_out dpid, arp_reply.to_binary, action end ARP Requestについて 全部オウム返しにした上で Controller(Receiver)に吸い込む 54
- 56. まとめ 56
- 57. まとめ • ACLめんどい • Trema/OVSで単純なL3/L4ヘッダ情報を 元にしたパケットフィルタとそのテスト のための仕掛けを作ってみた。 • 真面目に拡張するとFW周りのテストとか いろいろやれそうな気がする。 57
- 58. See also. • ACL Parser – stereocat/cisco_acl_intp https://github.com/stereocat/cisco_acl_intp – ACLをどうにかしたい話 - # cat /var/log/stereocat | tail -n3 http://d.hatena.ne.jp/stereocat/20130929/1380457458 • Simple Firewall – training/simple-firewall at master · stereocat/training https://github.com/stereocat/training/tree/master/simple -firewall • TCP/UDPパケット生成 – simple-router + udp echo server function using Pio https://gist.github.com/stereocat/6839659 – Trema/Pioでパケットを作ろう(1)~(3) - # cat /var/log/stereocat | tail -n3 http://d.hatena.ne.jp/stereocat/20131005/1380977633 58
- 59. これから? 59
- 60. ACL Parser • http://rubular.com/ みたいなフロントエンドつ けらんないかなー • ACL Compiler – Cisco→Capirca • 対応ACL機能拡張 – object-class等のACL feature網羅率の向上 – ASA系対応? • Optimization – 不要エントリの排除やSuggest – フィルタの可視化ってなにかいい方法ないのか? – フィルタテストパターンの提示 60
- 61. ACL/FW Simulator • トポロジ込みのEnd-to-End filtering simulation/test – Simple-routerの拡張(multiple-router?) – DSLによるネットワークトポロジ定義(trema 自体はもうやってる) – 対話的処理(ACL変更、テスト実行) • TCP Stateのチェック – 全部packet-inさせるならstate-fullな動作も DPI的な動作もやろうと思えばやれるはず。 61
- 62. ACL Tester • TCP Stateのテスト – 今のところStatelessにしてしまってる (Simple Firewallの方も) • テストシナリオ/テストパターン生成 – 手書きするのめんどい。 62
- 63. ACL Tester • テストプローブとしての応用? Tester (OFC) packet OFS Packet Generate Traffic Dispatch 63
- 64. おわり 64