セッションテーブルと疑似セッションはほぼ keep-state で実現しているとは思います。ただ、ipfw しか知りませんが、割と皆さんやっている established な通信は ALL ALL で許可は開けすぎなので、keep-state するルールとセットで establlished な通信は通過させるルールが必要になり全部 2 行ずつ書くことになり面倒。しかも性能的に established を許可する行は上の方に持って行く必要がある。商用ファイアウォールならセッションテーブルに基づく処理は最上位に自動的に配置される。
ipfw だと内部にあるセグメントをソースとする通信が、外部のインタフェースから到達した場合に drop することでスプーフィングを防止すると思います。
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 にしろってことかな。
商用ファイアウォールとの比較 (スコア:3, 興味深い)
昔は ipfw のルールをガリガリ書いたりしましたが、UDP 関連のルールが煩雑になるし、スプーフィング対策でインタフェースレベルまでフィルタを記述するとテストが大変だったりします。
だから、以下のような機能を実装していたら費用が限られる場合に、一つの候補になるかなと思います。
・UDP 疑似セッションを実装している ※これは ipfw でできますね
・セッションテーブルに基づく TCP の確立した通信のチェックができる
・許可と拒否のログが記録できる
・非パッシブのFTPを簡単に許可できる
・ネットワーク構成の設定か、ルーティングに基づくスプーフィングの検出ができる
Re: 商用ファイアウォールとの比較 (スコア:1)
IP Filterの場合ですが、
UDP疑似セッション:
udpに対するkeep state指定のこと?
セッションテーブルに基づくTCPの確立した通信のチェック:
セッションテーブルってTCPのレベルのこと? keep state指定のこと?
許可と拒否のログ
ログ自体が記録だと思うんですが、それはさておき可能です。
非passiveなFTPの許可:
NATのftp proxyを用意すればOKかな。
スプーフィングの検出:
機能の意味がようわかりません、文章として。
IP Filterの良いところは幅広いプラットフォームで動くところ、その一方でルールや設定ファイルが良くも悪くもprimitive的なところでしょうか。
IP Filter 4.Xもそろそろのようです。
Re: 商用ファイアウォールとの比較 (スコア:2, 参考になる)
セッションテーブルと疑似セッションはほぼ keep-state で実現しているとは思います。ただ、ipfw しか知りませんが、割と皆さんやっている established な通信は ALL ALL で許可は開けすぎなので、keep-state するルールとセットで establlished な通信は通過させるルールが必要になり全部 2 行ずつ書くことになり面倒。しかも性能的に established を許可する行は上の方に持って行く必要がある。商用ファイアウォールならセッションテーブルに基づく処理は最上位に自動的に配置される。
ipfw だと内部にあるセグメントをソースとする通信が、外部のインタフェースから到達した場合に drop することでスプーフィングを防止すると思います。
商用ファイアウォールの場合は、どのインタフェース側にどのネットワークが存在するかという設定を登録してスプーフィングを判定したり、ルーティングテーブルから想定されるネットワーク(通信するホストは当然ルーティングテーブルに乗っているので必然的に配置がわかる)に基づいて自動的にスプーフィングを判定します。これは製品によって違います。
Re: 商用ファイアウォールとの比較 (スコア:2)
コネクション確立パケットを通せば、あとはセッションテーブル
に基づいてよきにはからってくれますよ。また、こちらは聞いた
だけなので不確かですが、シーケンスナンバーとかもしっかり
見ているみたいです。ただ、単体ではアプリケーション層まで
はカバーしてくれないので、適宜Proxyと組み合わせる必要が
ありますね(FTP等)。
Re: 商用ファイアウォールとの比較 (スコア:1)
すいません, 私の理解不足なのですが
> established な通信は ALL ALL で許可は開けすぎ
なのは何故でしょうか? establishedパケットはTCPのみですし, TCPなら前段階でSYN/ACKによる接続の確保が必須なので, この前段階だけフィルタリングしてやればTCP通信ができることに対する制限はかけられると思うのですが.
Re: 商用ファイアウォールとの比較 (スコア:1, 参考になる)
としてコネクションが確立されているかではなく、単に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
にしろってことかな。
Re:商用ファイアウォールとの比較 (スコア:0)
導入時の検証の手間や、いざトラブルの際の対応など、
さらに運用を考えれば自分で構築する意味は薄い。
FW-1 は分からないが、NetScreen ならそれほど高価でないし。
Re:商用ファイアウォールとの比較 (スコア:1, 参考になる)
Solarisだと、SunScreenなんてモノで簡単にでっちあげることもありますし、
ハコ物だとPIXも使いますね。
PIXやNetScreenってフェイルオーバー環境が簡単に構築できてメリットが非常にあると感じています。
#FreeBSDを仕事で使っているんですけどね・・・
Re:商用ファイアウォールとの比較 (スコア:1)
もちろん、ソフトウェア費を下げる代わりに、運用支援費はいただきます。
それはありますね。まして、セッションの引き継ぎとかになると…。実際、ディスクレスで MTBF が抜群に良いファイアウォールほど二重化が容易なんですよね。
Re:商用ファイアウォールとの比較 (スコア:1, 参考になる)
NetScreenはともかくPIXはちょっと問題ありすぎです。
# SonicWallみたいに不安定なのは論外ですけど。
Re:商用ファイアウォールとの比較 (スコア:0)
CLIの話ですよね。
私はそーゆーものだと思ってなれてしまった人間なので特には感じないのですけど、
ポリシをしょっちゅうメンテする様な場所に導入するのは、人間の教育時間が間に合わないかもしれませんね。
導入時にかっちりとポリシが決まってしまうような処に導入するので
あれば、社内の適当な人間にテキストファイル1つ持っていってもらって流してもらったら
設定が終わってしまうので好きなんですけどね。。。