パスワードを忘れた? アカウント作成
7701 story

FreeBSD に pf が組み込まれる 26

ストーリー by Oliver
選べる自由と選ぶ悩み 部門より

BSD 曰く、 "Max Laierが 関係者にあてたメールによると、OpenBSD によって開発されているpf(Packet Filter)が、FreeBSD のベースシステムに移植されたとのことだ。-CURRENT を再構築すると、カーネルに必要なコードが埋め込まれ、ツール類がインストールされる。また、mergemaster を起動すれば、/etc/master.passwd と /etc/group の追加修正を求められ、必要なアカウント情報が組み込まれる。これで、FreeBSDには IPFW2、ipfilter、pf と3つのパケットフィルタが利用できるようになった。さて、どれが一番使いやすいだろうか。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by fil (17752) on 2004年03月09日 20時26分 (#510947)
    若干ストーリーにそぐわないかも知れませんが、商用ファイアウォールではアプリケーションレベルまで見る FireWall-1 と ASIC の NetScreen が戦っていますが、とかく高価な商用ファイアウォールに匹敵するオープンソースのパケットフィルタってありますか?

    昔は ipfw のルールをガリガリ書いたりしましたが、UDP 関連のルールが煩雑になるし、スプーフィング対策でインタフェースレベルまでフィルタを記述するとテストが大変だったりします。

    だから、以下のような機能を実装していたら費用が限られる場合に、一つの候補になるかなと思います。

    ・UDP 疑似セッションを実装している ※これは ipfw でできますね
    ・セッションテーブルに基づく TCP の確立した通信のチェックができる
    ・許可と拒否のログが記録できる
    ・非パッシブのFTPを簡単に許可できる
    ・ネットワーク構成の設定か、ルーティングに基づくスプーフィングの検出ができる
    • IP Filterの場合ですが、

      • UDP疑似セッション:
        udpに対するkeep state指定のこと?

      • セッションテーブルに基づくTCPの確立した通信のチェック:
        セッションテーブルってTCPのレベルのこと? keep state指定のこと?

      • 許可と拒否のログ
        ログ自体が記録だと思うんですが、それはさておき可能です。

      • 非passiveなFTPの許可:
        NATのftp proxyを用意すればOKかな。

      • スプーフィングの検出:
        機能の意味がようわかりません、文章として。

      IP Filterの良いところは幅広いプラットフォームで動くところ、その一方でルールや設定ファイルが良くも悪くもprimitive的なところでしょうか。

      IP Filter 4.Xもそろそろのようです。

      親コメント
      • by fil (17752) on 2004年03月09日 23時22分 (#511051)
        短くいえば FTP と UDP を含むステートフルインスペクションが可能で、スプーフィング対策のルールが自動的に生成されるパケットフィルタがあったら嬉しいという意味です。

        セッションテーブルと疑似セッションはほぼ keep-state で実現しているとは思います。ただ、ipfw しか知りませんが、割と皆さんやっている established な通信は ALL ALL で許可は開けすぎなので、keep-state するルールとセットで establlished な通信は通過させるルールが必要になり全部 2 行ずつ書くことになり面倒。しかも性能的に established を許可する行は上の方に持って行く必要がある。商用ファイアウォールならセッションテーブルに基づく処理は最上位に自動的に配置される。

        ipfw だと内部にあるセグメントをソースとする通信が、外部のインタフェースから到達した場合に drop することでスプーフィングを防止すると思います。

        商用ファイアウォールの場合は、どのインタフェース側にどのネットワークが存在するかという設定を登録してスプーフィングを判定したり、ルーティングテーブルから想定されるネットワーク(通信するホストは当然ルーティングテーブルに乗っているので必然的に配置がわかる)に基づいて自動的にスプーフィングを判定します。これは製品によって違います。
        親コメント
        • ipfilterのkeep stateでは、
          コネクション確立パケットを通せば、あとはセッションテーブル
          に基づいてよきにはからってくれますよ。また、こちらは聞いた
          だけなので不確かですが、シーケンスナンバーとかもしっかり
          見ているみたいです。ただ、単体ではアプリケーション層まで
          はカバーしてくれないので、適宜Proxyと組み合わせる必要が
          ありますね(FTP等)。
          親コメント
        • すいません, 私の理解不足なのですが

          > established な通信は ALL ALL で許可は開けすぎ

          なのは何故でしょうか? establishedパケットはTCPのみですし, TCPなら前段階でSYN/ACKによる接続の確保が必須なので, この前段階だけフィルタリングしてやればTCP通信ができることに対する制限はかけられると思うのですが.

          親コメント
          • by Anonymous Coward on 2004年03月10日 15時46分 (#511481)
            元記事だとipfwということだから、establishedフラグはTCP
            としてコネクションが確立されているかではなく、単にRSTか
            ACKが付いているかでしか判断してないので
            ipfw add allow tcp from any to any established
            :
            ipfw add allow tcp from any to me 80 in setup

            みたいなのは開けすぎで、TCPでも
            ipfw add check-state
            ipfw add deny tcp from any to any established
            :
            ipfw add allow tcp from any to me 80 in setup keep-state

            にしろってことかな。
            親コメント
    • 仕事で使うなら、大人しく売り物にすべきと思う。
      導入時の検証の手間や、いざトラブルの際の対応など、
      さらに運用を考えれば自分で構築する意味は薄い。

      FW-1 は分からないが、NetScreen ならそれほど高価でないし。
      • by Anonymous Coward on 2004年03月09日 21時44分 (#510984)
        FireWall-1でそれなりに満足しているので、あえてフリーで構築しようと思ったことはありませんね。
        Solarisだと、SunScreenなんてモノで簡単にでっちあげることもありますし、
        ハコ物だとPIXも使いますね。
        PIXやNetScreenってフェイルオーバー環境が簡単に構築できてメリットが非常にあると感じています。

        #FreeBSDを仕事で使っているんですけどね・・・
        親コメント
        • さらに運用を考えれば自分で構築する意味は薄い。

          もちろん、ソフトウェア費を下げる代わりに、運用支援費はいただきます。

          PIXやNetScreenってフェイルオーバー環境が簡単に構築できてメリットが非常にあると感じています。

          それはありますね。まして、セッションの引き継ぎとかになると…。実際、ディスクレスで MTBF が抜群に良いファイアウォールほど二重化が容易なんですよね。
          親コメント
        • by Anonymous Coward on 2004年03月10日 1時52分 (#511129)
          PIXでの構築をみてて、「IOSからいろんなモノが欠落した感じで、凄い設定しにくいね」とコメントをしたら、周囲の設定経験者からも同意が帰って来ました。
          NetScreenはともかくPIXはちょっと問題ありすぎです。
          # SonicWallみたいに不安定なのは論外ですけど。
          親コメント
          • >「IOSからいろんなモノが欠落した感じで、凄い設定しにくいね」
            CLIの話ですよね。
            私はそーゆーものだと思ってなれてしまった人間なので特には感じないのですけど、
            ポリシをしょっちゅうメンテする様な場所に導入するのは、人間の教育時間が間に合わないかもしれませんね。

            導入時にかっちりとポリシが決まってしまうような処に導入するので
            あれば、社内の適当な人間にテキストファイル1つ持っていってもらって流してもらったら
            設定が終わってしまうので好きなんですけどね。。。
  • FYI (スコア:3, 参考になる)

    by Anonymous Coward on 2004年03月09日 22時10分 (#510998)
    pfは、OpenBSDのサイトで解説文書の日本語訳 [openbsd.org]が公開されています。

    実装されている機能の詳細は上掲の文書を見ればわかるのですが、パケットフィルタリングの一般的な機能に加えて、
    • NAT、RDR
    • パケットの優先制御・帯域制御(ALTQをマージ)
    • アドレスプールを利用した負荷分散
    • nmapのようなOS識別機能
    などの機能も含まれています。まぁ、結構キッチンシンク的アプローチなのですが。

    あと、ロギング専用のネットワークインタフェース(pflog)があり、ロギングルールにマッチしたパケットはこのインタフェースを通じて記録したり、tcpdumpを用いて調査したりできます。
    • by kamiyan (10895) on 2004年03月10日 0時08分 (#511077) ホームページ
      最近 ipfilter から pf への移行作業をしてみましたが、気分的には OpenBSDの日本語訳の存在が大きいです。
      ipfilterの時はIPF.KANJIがほぼ唯一のまとまった日本語ドキュメントだったのを 考えると、雲泥の差というか。
      今から始める人だったら pf を勧めますね。

      # ALTQ までベースシステムに取り込まれたらすごく嬉しい。
      # 実運用環境でのカーネルパッチは負担が重いです
      親コメント
    • by Anonymous Coward
      おいらが思うに、pfの他に対するアドバンテージって、outgoingパケットの ロードバランシング機能かなって感じなのだが、そのあたりはどうかな? http://www.openbsd.org/faq/pf/ja/pools.html#outgoing [openbsd.org]
  • ipfilterは (スコア:2, 興味深い)

    by oddmake (1445) on 2004年03月09日 18時02分 (#510848) 日記
    ライセンス上のごたごたが以前あった [allbsd.org](今どうなったかはわかんない(ぉ)りして、それでPFの開発がはじまった経緯があって。
    ipfilterはBSD的にステなのかな・・・・・・と思っていたのですが。

    # 教えてBSDのえらいひと
    --
    /.configure;oddmake;oddmake install
  • by Anonymous Coward on 2004年03月09日 19時19分 (#510917)
    ipchains、iptables、ipfwadmと3つのパケットフィルタが使えるな。
    どこからのパクリなのか知らないが。
    • by Anonymous Coward
      IPFW2、ipfilter、pfは並列だけど、
      Linuxはipfwadm→ipchains→iptablesだろ。
      一緒にするのはどうかと。
      • by Anonymous Coward
        たしか元(ipfwadmかな)はipfを参考にというのを
        見たことがあるような無いような・・・
        今のiptablesはipfとは全く別物ですが。
        一時期パケットフィルタを色々調べてて頭の片隅に

        誰かその辺詳しい方いらっしゃいません?
        # もしかしたら勘違いかも
  • by Anonymous Coward on 2004年03月09日 23時01分 (#511033)
    BSD の美しい点として、こういうツール群に Linux 的な redundancy がなかったと思うのですが、最近は違うのですね・・一番使いやすいのを一つ入れて、あとは ports collection にまわしてほしかったりするけれど、パケットフィルタなんかはカーネル上で動くからそれは無理なのかしら・・・

    っていうかどれが一番使いやすいの?教えて偉い人。
    #「パケットフィルタなんて飾りです・・」は無しで。マジで聞いてます。
    • Re:僕の思う BSD (スコア:3, 参考になる)

      by Anonymous Coward on 2004年03月10日 13時56分 (#511406)

      ま、車輪の再発明ってのは別に目新しい話でもない罠。portsを詳細に見ていくと、機能的にかぶっているモノなんていくらでもあるし、今のFreeBSDはスケジューラーとかスレッドライブラリなど複数の実装が混在しているのが現状。ゆくゆくは1つに収斂していくのかもしれないけど、今はそういう時期なんだとあきらめてる。

      個人的なイメージとしては

      • ipfw2:NATするにはnatdと組み合わせる必要がある
      • IPFilter:FreeBSD標準だと帯域制限機能が使えない
        (つーか、FreeBSDのdummynet(4)がほぼipfw決め打ちなだけ)
      • pf:なんでもあり(帯域制限はALTQを使うらしい)。ただし、世に出てまだ日が浅い
      という感じ。

      パフォーマンスはルール設定にもよるだろうから、自分の欲しい環境で比較しないと無理。とりあえず、市販の安いルータレベルの機能はどれだって持ってるから、あとは設定するのに必要な事前情報の量じゃないの?pfの日本語訳の存在は大きいよね。

      #「素直に格安ルータ買っとけ」という突っ込みはあると思うが(w

      親コメント
typodupeerror

ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家

読み込み中...