セッションテーブルと疑似セッションはほぼ keep-state で実現しているとは思います。ただ、ipfw しか知りませんが、割と皆さんやっている established な通信は ALL ALL で許可は開けすぎなので、keep-state するルールとセットで establlished な通信は通過させるルールが必要になり全部 2 行ずつ書くことになり面倒。しかも性能的に established を許可する行は上の方に持って行く必要がある
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 関連のルールが煩雑になるし、スプーフィング対策でインタフェースレベルまでフィルタを記述するとテストが大変だったりします。
だから、以下のような機能を実装して
Re: 商用ファイアウォールとの比較 (スコア:1)
IP Filterの場合ですが、
UDP疑似セッション:
udpに対するkeep state指定のこと?
セッションテーブルに基づくTCPの確立した通信のチェック:
セッションテーブルってTCPのレベルのこと? keep state指定のこと?
許可と拒否のログ
ログ自体が記録だと思うんですが、それはさておき可能です。
非passiveなFTPの許可:
NATのftp proxyを用意すればOKかな。
スプーフィングの検出:
機能の意味がよ
Re: 商用ファイアウォールとの比較 (スコア:2, 参考になる)
セッションテーブルと疑似セッションはほぼ keep-state で実現しているとは思います。ただ、ipfw しか知りませんが、割と皆さんやっている established な通信は ALL ALL で許可は開けすぎなので、keep-state するルールとセットで establlished な通信は通過させるルールが必要になり全部 2 行ずつ書くことになり面倒。しかも性能的に established を許可する行は上の方に持って行く必要がある
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
にしろってことかな。