このトピックでは、Berkeley Packet Filtersを使用して、Decoderによって処理するパケットおよびログをフィルタリングする方法について説明します。
Decoderによって処理するパケットおよびログをフィルタするためにBerkeley Packet Filtersを使用できます。Decoderは、tcpdump/libpcap構文を使用して定義されたシステム レベルのパケット フィルタリングをサポートします。libpcapフィルタを指定する場合、レイヤー2～レイヤー4の属性に基づいて、キャプチャするパケット量を効率的に削減できます。解析のためパケットがDecoderアダプタにコピーされる前に、パケット ストリームに対してBPF（Berkeley Packet Filters）が適用されます。これによって、不要なトラフィックを効率的に破棄できます。ただし、破棄されたパケットに関する情報は、{{nd}}のどの統計情報（収集レート、ドロップされたパケット、フィルタされたパケット、合計パケット）にも反映されません。
libpcapフィルタは、Decoderの物理リソースに多大な負荷を与えるようなトラフィック量の場合に適しています。このシナリオが必要な状況では、Decoderでパケットのドロップが頻繁に発生し、またcapture.pageが高い数値を示している可能性があります。（/decoder/stats/capture.pages.freeが高い値です）。
システム レベル パケット フィルタの追加
システム レベルのBerkeley Packet Filterを追加するには、次の手順を実行します。
- Security Analyticsメニューで、［Administration］＞［サービス］を選択します。
- ［Administration］の［サービス］ビューで、Decoderサービスを選択し、
＞［表示］＞［構成］を選択します。
［サービス］の［構成］ビューが表示され、［全般］タブが開きます。
- ［Decoder構成］セクションの［Adapter］セクションで、［Berkeley Packet Filter］の横にあるフィールドをクリックします。
- このフィールドに単一のフィルタを入力します。複数のアイテムをフィルタする場合は、andを使用して複数の式を結合します。
SAユーザー インタフェースで、フィルタ文字列を入力した時点で構文が確認されます。 - ［適用］をクリックして、フィルタを保存します。
構文が適切な場合、確認メッセージが表示されます。
構文が不適切な場合、「Packet filter is not valid」というメッセージが表示され、Decoderのログに対応するログ メッセージが出力されます。
164474800 2015-May-01 19:03:08 warning Decoder Failed to parse filter ‘example_badrule': syntax error - このフィルターをアクティブ化するには、Decoder上でキャプチャを停止および開始する必要があります。
- ［構成］ビューを［システム］ビューに変更します。
- ［収集の停止］をクリックします。
- ［収集の開始］をクリックします。
Decoderのログにアクティブなフィルタが表示されます。
例
次に、いくつかのフィルタの例を示します。
- ソース アドレスと宛先アドレスのいずれかが10.21.0.0/16サブネット内であるすべてのパケットをドロップする。
not (net 10.21.0.0/16) - ソース アドレスと宛先アドレスの両方が10.21.0.0/16サブネットであるパケットをドロップする。
not (src net 10.21.0.0/16 and dst net 10.21.0.0/16) - 10.21.1.2からのパケット、または10.21.1.3へのパケットをドロップする。
not (src host 10.21.1.2 or dst host 10.21.1.3) - IPとHOSTの両方を組み合わせる。
not (host 192.168.1.10) and not (host api.wxbug.net) - すべてのポート53トラフィック（TCPおよびUDPの両方）をドロップする。
not (port 53) - UDPポート53トラフィックのみをドロップする。
not (udp port 53) - すべての IPプロトコル番号50（IPSEC）トラフィックをドロップする。
not (ip proto 50) - TCPポート133～135のすべてのトラフィックをドロップする。
not (tcp portrange 133-135
次のフィルタでは、前記のいくつかのフィルタを組み合わせ、1つのフィルタに複数の条件を格納する方法を説明します。
- Drop any port 53(DNS) traffic sourced from 10.21.1.2 or destined to 10.21.1.3.
not (port 53) and not (src host 10.21.1.2 or dst host 10.21.1.3) - IPプロトコル番号50またはポート53を使用するトラフィック、あるいは10.21.0.0/16サブネット内から10.21.0.0/16サブネット内へのトラフィックをドロップする。
not (ip proto 50 or port 53) or not (src net 10.21.0.0/16 and dst net 10.21.0.0/16)
注意：構文で括弧を誤って使用すると、場合によってはパケット フィルタが使用できなくなってしまうほどの影響が生じる可能性があります。そのため、ベスト プラクティスとしては、常に括弧の外側に「not」演算子を置き、フィルタ ルールを導入する前には必ずテストを実行します。入力時の構文確認に問題がなかったとしても、ルールの形式が適切でない場合、パケット フィルタによってすべてのトラフィックがドロップされてしまったり、その他の予期しない影響が発生したりする可能性があります。こうした事態は、Libpcapフィルタによって引き起こされ、NetWitnessソフトウェアでは制御ができません。
テスト
BPFフィルタを使用する場合、予期したとおりに動作することを確認するために、実装前にtcpdumpまたはwindumpのいずれかを使用してテストする必要があります。この例では、windumpを使用したフィルタのテストを示しています。
windump -nni 2 not (port 53 or port 443) or not (ip proto 50)
変換
パフォーマンス向上のために、既存のネットワーク ルールの代わりにシステム レベルのパケット フィルタの方が適切と判断される場合は、フィルタ構文に変換して利用することができます。変換を行う場合、次のような注意点があります。
- &&またはandの違いに注意します。
- ip.addrは、単一のホストの場合はhost、ネットワークの場合はnetになります。
- ip.srcは、単一のホストの場合はsrc host、ネットワークの場合はsrc netになります。
- ip.dstは、単一のホストの場合はdst host、ネットワークの場合はdst netになります。
- ネットワークをリストする際にはCIDR表記を使用します（たとえば10.10.10.0/24）。
- ||はorになります。
- !はnotになります。
- 複数のルールは、andにより結合する必要があります。
TCPDumpの次のマニュアルには、使用可能なフィルタおよび文字列の例が掲載されています。
http://www.tcpdump.org/tcpdump_man.html
また、次のサイトでは、BPFスタイルのパケット フィルタに関するリファレンスが提供されています。
http://biot.com/capstats/bpf.html
注意：vlanタグ付きパケットを収集している場合、前述の標準的なBPFフィルタが機能しないことがあります。たとえば、udpポート123のvlanタグ付きNTPトラフィックをフィルターするためにnot (udp port 123)を指定しても、機能しません。これは、BPFフィルタの仕組みがシンプルで、ルール内で指定されている以外のプロトコルを考慮できないためです。BPFフィルタを実行するOSは、標準のEthernet/udpパケットのバイト オフセットでudpポート値を検索しますが、Ethernetヘッダ内のオプションのvlanタグ フィールドがこれらの値を4バイトずつずらしてしまうため、BPFフィルタのルールが失敗します。これを解決するためには、BPFフィルタのルールを次のように変更する必要があります。not (vlan and udp port 123)。