Tremaで試すFirewall

5,129 views
4,918 views

Published on

Tremaで試すFirewall - FW運用の理想と現実およびテストツール試作について -, 2013-11-16, Trema Day #4

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,129
On SlideShare
0
From Embeds
0
Number of Embeds
1,721
Actions
Shares
0
Downloads
12
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

Tremaで試すFirewall

  1. 1. Tremaで試すFirewall FW運用の理想と現実 およびテストツール試作について 1
  2. 2. @stereocat SIerでネットワークエンジニア …的な何か。 IHAnet ASN#64594 2
  3. 3. (注) • いわゆる”SDN”の話ではありません。 – “OpenFlowの応用” とかそういう方向。 • NWエンジニアよりの話です。 3
  4. 4. Q • 私はNWエンジニアである。 • 私はNWおよびFirewallの運用を 行っている/行ったことがある。 • ファイアウォール運用は正直も うやめたい/やりたくない。 4
  5. 5. “ACL” ? 5
  6. 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. 7. FirewallとAccess Control List • パケットフィルタ型FWについて扱う場合、 ACL = パケットフィルタのルール – 複数のエントリ(ACE: Access Control Entry)の集合 – 特定のトラフィック(フロー)を識別する情報 + 識別した情報に対するアクションの定義。 • アクセス制御  セキュリティ対策 – 余計な物は見せない触らせない。 7
  8. 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
  9. 9. ここがしんどいFW(ACL)運用 9
  10. 10. ACLしんどい • 増え続けるエントリ – 「謎エントリ化」問題 – 浪費される計算機資源 • ポリシと運用の破綻 – 「これ消したらどういう影響あるかわからないから、 消せないんだよね…」 – 「これ、何のために入れてあるんだっけ?」 – 「わかんねーからとりあえず突っ込んどけば?」 • 謎エントリの拡大再生産という悪循環 10
  11. 11. こうなる(実話) • 数百行オーダーのACLの乱立 – どこで何やってるのかわからないから、フィ ルタ要件追加にすごく時間がかかる。 – デバイスのメモリあふれ • フィルタ処理がTCAMで回らなくなる → CPUでまわるのでCPU利用率が異常上昇 → サービスレスポンスの急激な悪化 • 監視に応答しなくなってアラート • リモートログインすらまともにできない 11
  12. 12. どうしてこうなった? • FW(ACL)運用の複雑さ – メタ情報の管理の問題 • “Why” をどうやって管理するか – エントリ削除運用の徹底が難しい • 「やれてることがやれなくなる」リスク • どうしてもACLが肥大化する傾向にある – ルールと用途の重複 • ネットワークトポロジの考慮も必要 12
  13. 13. FW(ACL)運用の複雑さ やりたいこと (フィルタリング要件) やりたいことA やりたいことB やりたいことC フィルタルール “ACL” (実装されたコード) ルール1 ルール2 ルール3 ルール4 ルール5 ■要件とルールが必ずしも1対1 で対応しない。 ■対応させるとエントリ数が多 くなりすぎる。(メモリ食う) ■ルールから要件へのマッチン グ(逆方向の変換)が難しい。 「追加のみ」運用の発生 ACL誤削除によるサービス影響 ACLの肥大化 13
  14. 14. FW(ACL)運用の複雑さ • そもそも「要件」相当の情報がない – 直接実機上で変更して終わり、という運用。 – どのエントリが何のためにあるのか、わからなく なっていく。 • (初期)要件の情報はあれども、実機利用され てるACLと整合性がとれていない – 何もないよりマシ、程度。 • 結局、実機情報ベースで力業…orz – ACL自体にコメント書けるけど(remark)、1エン トリに複数要件が被るものをコメントで管理する のは非現実的。 14
  15. 15. FW(ACL)運用の複雑さ ネットワークトポロジの加味 → ネットワーク構造による 要件とACLの多重化 (本気でやるとルーティングとか 実装し始めかねない) リストの順序依存性 → 要件でブロック化しにくい → エントリの包含関係・競合 利用位置・利用者・アプリケー ションなどによる制御(5W1H) → 業務要件との密接な連携 フィルタ位置とポリシルールの 整合性 → 入口/中間/出口 → 単一の要件・複数の表現 15
  16. 16. 何が面倒か、を しゃべりはじめると きりがないので この辺にしておきます。 16
  17. 17. ここがしんどいFW(ACL)運用 • どんどん増える/消せない • 要件が多重化しすぎてわけわからん • 暗号解読状態(歴史とか推理とか…) • ミスって誤フィルタはいると大変 • 放置して穴だらけになってもいけない _人人人人人人人人_ > ACL塩漬け運用 <  ̄Y^Y^Y^Y^Y^Y^Y^Y^ ̄ 17
  18. 18. ここがしんどいFW(ACL)運用 • 機器の更新とか…どうする…… – ACLがもう機器の限界まで入っているから、 上位グレード機器でスケールアップさせると いう力業 • 有効なエントリって、そのうち何割だろう? • 消極的投資 – ACLが移行(変換)できなくて他ベンダ機器が 選択できないとか… 18
  19. 19. 理想的なACL運用のイメージ 19
  20. 20. FWポリシ設計論 これは本当に難しい。 …ので、システム的な ところにフォーカス。 20
  21. 21. FW運用のキモ • いかに「やりたいこと」と実際のACLとの 乖離を防ぐか。 • 「やりたいこと」の管理 – いる・いらないの定期的な見直し – 不要エントリ削除の運用 • 削除運用がないと管理対象が減らない。 • 定期的なポリシ見直しのないセキュリティ運用は、 強度が落ちる一方。 21
  22. 22. 負けパターン いきなり機器設定 → 論外 ACL 個別に書いていて連動していない → 不整合 メタ情報 ACL 22
  23. 23. こうだろ Human Readableで ベンダ非依存の ACL定義情報 メタ情報 記述 コード (ACL)の 生成と 最適化 ツール デプロイ まで自動 化できる とgood ACL • メタ情報を残す(冗長・重複で良いので情報を ちゃんと記録する) • ツールを使ってコード(ACL)を生成する。 • 生成時に最適化が行われて、冗長なエントリは 束ねられる。 • 生成されたコードを機器に投入する。 23
  24. 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. 25. ツール例 • Filter Language Compiler http://coombs.anu.edu.au/~avalon/flc.html – Cisco/ipfw など。開発とまってる気配 25
  26. 26. 理想 End-to-Endのやりたいことを書いた ら、その環境内の各機器で設定が必要 なポリシ(ACL)を生成して、 全部一気にデプロイできると完璧!! ACL メタ情報 記述 ツール ACL ACL サービス, トポロジ 情報 26
  27. 27. 壁 • ゼロから作るなら、ある程度はやれる。 – FW単体については。トポロジ情報の考慮まではまだ難しい。 • 今の環境をどうするか… メタ情報 記述 ? • 既存のACLを解析・最適化・メタ情報化したい • メタ情報との不整合を解消・照合したい • 既存のACLを別な機器用に変換・移行・更新したい 27
  28. 28. いちめんのACL いちめんのACL • 人力でがんばる – 量的に無理。品質と精神が崩壊する。 • ツール – ACLを解析するツール? – ACL Parser? – ACL生成はあるけどその逆はあまりない 作ってみた① 28
  29. 29. …ない? • それっぽいのはあるけど – aclcheck - Cisco ACL checker https://code.google.com/p/aclcheck/ – でも、やりたいのは syntax check だけじゃ ないんだ… 29
  30. 30. ACL Parse • ACL読める → 応用 – Syntax check – 最適化 – 変換 (Compile) • メタ情報記述への変換 • 他ベンダACLへの変換 – FWシミュレーション • トポロジ構成まで シミュレートしようとすると ソフトウェア的なものが欲しい。 これ消したら、 どういう影響あ るかわからない から、消せない んだよね… シミュレータで テストしろよ! (ってやれるよう にしたい) 30
  31. 31. ACL Simulator • 多分みんな考える OpenFlowが12Tuple使って フロー制御できるなら、FW とかこれで作れるよなー 作ってみた② 31
  32. 32. オーディオマニアの友人に、「セレク タを作っている」と話したところ、「そ れは、相当のめり込んだマニアが 手を出す物だ」と指摘されてしまった。 最初に観測方法を確立してから次 のステップへ進むという手順は、確 かに工学的あるいは研究的なスタ ンスかもしれない。 森博嗣 2007年1月28日(日) MORI LOG ACADEMY, vol.6, 森博嗣, メディアファクトリー, 2007. 32
  33. 33. シミュレーションとテスト • シミュレーションしたら、シミュレートでき ているかどうかを確認しなければいけない。 – 確認する方が難しい && 重要 • 変更したときに、やりたいことがすべて満た せているかどうかを確認しながら運用したい。 – 再現性・網羅性のある自動テストで品質担保を。 – テスト駆動開発(TDD)的な考え方でFirewallを運 用できるようになったらいいなあ。 33
  34. 34. NW系テスト一般形 テスタ input テスト対象 (DUT) 制御 入出力の照合 テストレポート テスタ output 34
  35. 35. …こう書いてみると? OpenFlow Switch Packet Out Message Packet Out テスト対象 (DUT) OpenFlow Controller Packet In OpenFlow Switch Packet In Message 35
  36. 36. こうか! ACL OpenFlow Parser Controller ACL (FW Simulator) OpenFlow Switch Packet Out Message Packet Out OpenFlow Switch OpenFlow Controller (Tester) Packet In OpenFlow Switch Packet In Message 36
  37. 37. ACL Tester • パケット生成してPacket-out/Packet-in • パケット生成 – Trema/PIO https://github.com/trema/pio • テストルール元にパケットを生成して、 投げて、受信できた/できなかった…を確 認してやれば、ACLのチェックができそう。 作ってみた③ 37
  38. 38. 全部まとめると? シミュレータ 手動 +ツールで 生成支援 各FW テストコード テ ス タ ACL メタ情報 記述 ツール ACL ACL サービス, トポロジ 情報 テスタで 全要件 自動テスト 38
  39. 39. ① ACL PARSER IMPLEMENTATION 39
  40. 40. Implementation • 個人的な都合でCisco IOS ACLを対象に。 • Ruby/RaccによるParserの実装 • 目標はIOS ACL全機能の網羅 – 前にSyntaxだけは実装してみたことがあった • とりあえずよく使う機能の実装 – Named/Numbered, Extended/Standard – 基本的なL3/L4, ポートマッチング 40
  41. 41. ACL Class Structure • よく使う機能に絞ったつもりだけど… • 実装がわりとad-hocなので構造がコレで いいのかは微妙な気がする。 41
  42. 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
  43. 43. ここがしんどいCisco ACL きりがないので (以下略) 43
  44. 44. 実行例(syntax check) Typo (“tcp” → “tco”) Number (not masked) 44
  45. 45. ② ACL SIMULATOR IMPLEMENTATION 45
  46. 46. 実装 • Simple Routerを改造 – 転送する前にACLとの照合 – マッチしたACLのアクション(Permit/Deny) に応じて、そのままOutPortかDropかを指定 してやれば良い。 – 片方向(inbound)だけフィルタするモデル 46
  47. 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. 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. 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. 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
  51. 51. ③ ACL TESTER IMPLEMENTATION 51
  52. 52. 構成 Firewall Tester (controller) br1 [0x01] Simple Firewall (controller) br3 [0x03] br2 [0x02] Open vSwitch Sender/ Generator Receiver/ Parser Linux/KVM Host 52
  53. 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. 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
  55. 55. 実行例 FW FW Tester 55
  56. 56. まとめ 56
  57. 57. まとめ • ACLめんどい • Trema/OVSで単純なL3/L4ヘッダ情報を 元にしたパケットフィルタとそのテスト のための仕掛けを作ってみた。 • 真面目に拡張するとFW周りのテストとか いろいろやれそうな気がする。 57
  58. 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. これから? 59
  60. 60. ACL Parser • http://rubular.com/ みたいなフロントエンドつ けらんないかなー • ACL Compiler – Cisco→Capirca • 対応ACL機能拡張 – object-class等のACL feature網羅率の向上 – ASA系対応? • Optimization – 不要エントリの排除やSuggest – フィルタの可視化ってなにかいい方法ないのか? – フィルタテストパターンの提示 60
  61. 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. 62. ACL Tester • TCP Stateのテスト – 今のところStatelessにしてしまってる (Simple Firewallの方も) • テストシナリオ/テストパターン生成 – 手書きするのめんどい。 62
  63. 63. ACL Tester • テストプローブとしての応用? Tester (OFC) packet OFS Packet Generate Traffic Dispatch 63
  64. 64. おわり 64

×