パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

FreeBSD に pf が組み込まれる」記事へのコメント

  • 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つ持っていってもらって流してもらったら
            設定が終わってしまうので好きなんですけどね。。。

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

処理中...