◆仕様（目標）概要

既知の不正リクエスト、ワームからのリクエスト等の不正なパケットを検知し、
WEBサーバーまで到達させずにフィルタリングで破棄する。

破棄するとともに、サービス停止、メール通知、ポート遮断等、
固有のアクションを起こさせる設定が容易に行える。

パケットは破棄せずに解析だけすることもできる(analysis モード)。

WEBサーバー運用目的以外のパケットは全遮断、ping コマンドも指定したホストからしか
受け付けない。

安易なポートスキャンは回避できる。

パケットを検査するオーバーヘッドのため、結果的にクライアントから見た場合、
多少のパフォーマンス低下は免れない。


◆テスト運用使用機材

PC            : PC/AT compatible Pentium120MHz 32MB RAM
Network概要   : Internet
                ---> ADSL 1.5M
                ---> Firewall
                ---> PC (10Base-T)
                セキュリティ上、あまり詳しくは書けません :)


◆テスト運用ソフトウェア構成

ベースOS      : Laser5 Linux 7.2 exp
カーネル      : (2.4.18 + iptables-1.2.6a(2002.04.06時点))
Web Server    : Apache (1.3.24(2002.04.06時点))

このシステム（仮称 S_K_wwwfilterシステム)について

スクリプト・設定 : 
              [ ソース等 ]
              正しく設定しないとセキュアでないのでそのまま使用しないでください。


              ◆ wwwfilter.sh

	      パフォーマンスを維持するためにルールを最小限にする必要がある。
              せっかくsnort2iptables があるのでそれをぜんぶ使えば、というのはあまりに安易な発想で、
              snortのシグネチャがどんなに膨大か見てみてください。web 関連だけでこんなにあります。泣きます。

              もうひとつの考え方として、string マッチルールを一切使用せず、たとえばポート80番向け
              パケットはすべて QUEUE し、ユーザー空間で判断して処理を振り分ける、という方法も
              考えられます。string マッチのオーバーヘッドがどんなもんかわからないので、
              速いのか遅いのかよいのか悪いのかわかりませんが、楽な方法ではありますので、
              問題がないならいいかもしれません。検討は今後の実験結果によります。

              なので、とにかく、たとえば php が動かないなら .php なんてのはひっかけちゃっても
              いいだろうし（うまく調整しないと掲示板の記事内に .php とか書けなくなるが...
              それもツライかな）、そんなカンジでスリムにする努力が必要です。

              現在最も気になっている課題はDoS対処です。iptables のlimit マッチングは man に
              よれば LOG と組み合わせろ、とあるのですけど、他とは不具合出ると言う意味なのか？
              深い意味が無いのなら、これとあわせるのが手っ取り早いんですけど。これも
              基本システムが落ち着いたら実験します。

              あとホントは string モジュール関係もまだソースを詳しく見てないんで、
              脆弱性のチェックとかしなきゃなんないんだろうけどねえ.....。


              ◆ nf-hook.pl (フック処理中枢)

              パケットをとりあえず ACCEPT してしまって、フック処理は子プロセスに渡して思う存分
　            やらせる "analysis" モードと、
              フック処理を終了してから DROP する strict モードを用意しましたが、この２種の
              コーディングを転用すれば違った動きも簡単に作れるでしょう。
              それぞれの注意点は 子プロセスの数をあまり多くさせないようにすること
             （最大数を設定する変数があります）、キューをためてしまわないように素早く処理すること、
              といったところです。


              ◆ S_K_nf.pl (フック処理等実装)

              なんにせよ処理は簡潔に、最小限にする必要があるでしょう。
              どちらかというとこのスクリプトファイルは設定ファイル的なものです。


              ◆ nf-hook-compact.pl (フック処理中枢)

              公開用のコンパクト版です。以前でいうanalysisモードのみとしました。
              パケット改ざんも可能になりました。


              ◆ S_K_nf-compact.pl (フック処理等実装)

              公開用のコンパクト版専用のモジュールです。


              ◆ wwwfilter-hook.sh (フック処理実装追加用)

              重たそうなことをしたいなら、C とかの実行バイナリとかを呼ぶようにするとか。
	      サンプルはこれまたありがちですが、メールで通知するやつです。私は持ってませんが、
              i-mode とかがいいんでしょうかね。攻撃が連発するとメールボムになってしまうので、
              簡単ですが安全装置をつけてみました。どんなのが来たかを通知してもいいのですが、
              それを通知させるにはこれまたフィルタリングが関わってくるので、逆に穴が増える恐れが
              あります。ということで、通知だけです。ログをどっかに転送しておいて、通知が来たら
              そこに見に行く、というのがよろしいんじゃないでしょうか。
              共通で使用するアプリケーションディレクトリのパスなどのシェル変数は
              環境変数にしたりサブシェルを使わずに export したりした方が使い勝手がよいですね。


              ◆ build-wwwfilter.sh (システム構築コマンド)

              WWW 鯖も含めてまとめて面倒見ます。
              これを使用する場合は特に、共通で使用するアプリケーションディレクトリのパス
              などのシェル変数は環境変数にしたりサブシェルを使わずに export したりした方が楽チンです。


nf-hook-compact.pl S_K_nf-compact.pl はメールサーバー用などでも共通で使用しています。

以上は基本的に皆様に使用していただくことを目的にしているわけではなく、着想の例として
公開してるものです。よって、詳しい使用法などは割愛しています。
万が一これらを使ってみようという場合、使用法等説明することはできますが、一切の責任を負いません。
運用にいたるまでにはいくつもの段階を踏む必要があり、最新の注意が必要です。
基本的な Linux およびカーネルの知識があり、ここまでの iptables の記事の内容を
理解していることが必須となります。
また、上記システムが既にいくつかの脆弱性、問題点を抱えていることを作者自身は把握していますし、
今後新たに発覚するものがあっても、その通知の義務は負わないものとします。


■ 補足

wwwfilter.sh についてはいろいろなポリシーがあると思いますが、
実際に一般公開し、運用している場合はオーバーヘッドを最小限にせねばならないでしょう。
また計算機の速度とあわせて考える必要もあるでしょう。
どういった選択がいいかは今後実験を経て考えていきたい所です。
なお、wwwfilter.shのマッチング文字列は主に snort2iptables の結果を参考にしていく予定ですが、
今後出現する不正リクエストに対してはこのページは特に迅速な対応をするわけではありません。