内容
Vyatta_Firewall_Best_Practices.pdf を参考にして、個人的に知っておいたほうがよいと思った点について抜粋してみます。
ステートレスとステートフル ファイアウォール
Vyattaは、ステートレスとステートフルの両方のファイアウォール設定をサポートしています。
ステートレス ファイアウォール
- 注：Vyattaルーターは、デフォルトでステートレス
- ステートレスのほうがパフォーマンスがよい
- 接続情報（セッションテーブル）を保存せず、メモリとCPU時間の消費を抑えるので、転送パフォーマンスは、ステートレスなシステムで最適。
- ステートフル性に特有の機能を必要としない場合、最高のパフォーマンスを得るためにルータをステートレスに保つことが推奨。
- ユースケースには、ステートフルなフィルタリングや変換よりもパケットの高速配信が重要なコアルータや中継プロバイダなどパフォーマンスが優先される場合に利用
- フローで使用される複数のインターフェイスにファイアウォールルールが適用される場合、トラフィックは両方向で明示的に受け入れられる必要がある。
ステートフル ファイアウォール
- アプリケーショントラフィックが一般的である場合には最適
- ステートフルのほうが使い勝手がよい（アプリケーション通信での行きと帰りの許可に利用。両方向で明示的に書く必要がない。）
- Vyattaのファイアウォールは、次のいずれかの条件を満たすまでステートレスになります。
- ファイアウォールが構成され、ルールに「状態」パラメータが設定されている
- 「ファイアウォールの状態ポリシー」が構成されている
- NATが構成されている
- 透過的なWebプロキシサービスが有効になっている
- 負荷分散構成が有効である
ファイアウォールグループ
ファイアウォールグループを使用すると、多数の要素に対して共通の操作を実行する必要がある場合に、パフォーマンスを向上させることができる。
（ファイアウォールのログ収集と統計収集はルールごとに実行されるため、グループを一致条件として参照するファイアウォールルールは、ログもグループごとになる）
インターフェースベースとゾーンベース ファイアウォール
インターフェースベース ファイアウォール
- 中継ルータやコアルータなどパフォーマンスが優先される場合に利用
- インターフェースが2つのときで、内側と外側を構成するシンプルな場合に推奨される。
ゾーンベース
- ゾーンベースのファイアウォールは構成の簡素化のために、インターフェースが2つより多いときに推奨される。
- 全てのインターフェースに対してゾーンを作る必要がある
- リモートアクセスインターフェース（pptpやl2tp）にもゾーンベース ファイアウォールを適用できる
- 同一ゾーン内通信をフィルタリングすることはできない（フィルタリングしたい場合は、ゾーンを分ける必要がある）
ファイアウォール グローバルオプション
all-ping（デフォルト有効）(SoftLayerデフォルト有効)
通常のpingに応答するか、しないかをすべてのインターフェースで設定可能
（インターフェースごとに変えたい場合は、個別にルールを設定する必要がある）
broad-cast ping（デフォルト無効）(SoftLayerデフォルト無効)
ブロードキャストpingに対する応答。
Smurf攻撃を引き起こす原因となるので、無効が推奨。
ip-src-route and ipv6-src-route（デフォルト無効）(SoftLayerデフォルト無効)
IPヘッダーに送信元ルート情報を含むIPv4およびIPv6パケットがドロップされる。
IPスプーフィング攻撃に対して脆弱となる可能性があるため、無効が推奨
log-martians（デフォルト有効）(SoftLayerデフォルト有効)
無効な送信元または送信先アドレスが含まれているとみなされるパケットを受信したときにシステムがログメッセージを生成。
潜在的な攻撃やネットワーク設定の問題が発生した場合に記録して識別できるように、有効が推奨。
Receive-redirects and ipv6-receive-redirects（デフォルト無効）(SoftLayerデフォルト無効)
ホストがICMPリダイレクトメッセージを受信すると、ICMPリダイレクトメッセージで受信した情報に基づいて、独自のルーティングテーブルを更新する。
DoS攻撃にも簡単に使用可能なため、必要な場合以外は、無効が推奨。
send-redirects（デフォルトで有効）(SoftLayerデフォルト無効)
ほとんどの場合、発生する可能性のある攻撃またはネットワーク構成の問題が発生したときに特定できるように、有効が推奨。
Vyattaは、同じレイヤ2セグメント上の直接接続されたホストにのみICMPリダイレクトメッセージを送信する。
source-validation（デフォルトで無効）(SoftLayerデフォルト無効)
受信したパケットの送信元アドレスが、受信したインターフェイス上で予想されるかどうかを検証するプロセスで利用される。
送信元検証はIPソースアドレスのなりすまし攻撃から保護するために使用できますが、動的ルーティング環境で有効にすると、システムが有効なトラフィックを削除する可能性があるので、「有効」にするときは注意。
syn-cookies（デフォルトで有効）(SoftLayerデフォルト有効)
システムがTCP SYNクッキー機能を使用してローカルTCP接続キューの過負荷の可能性を減らすことによってSYNフラッド攻撃を緩和するように、有効が推奨。
（宛先アドレスがVyattaシステム自体のアドレスであるTCPパケットに対してのみ、この機能が有効）
CONNECTION TRACKING について
セッションテーブルを「show conntrack table」でみることができます
TCP接続に関連するconntrackテーブルエントリでは、エントリの最初の値は「接続ID」になる。この値はVyattaが操作モードコマンドを使用してconntrackエントリを識別して操作するために使用される。たとえば、conntrackテーブルのエントリは、その接続IDに基づいて識別および削除できる。
以下、チューニング項目について。
1.接続追跡テーブルのサイズ、
system conntrack expect-table-size
デフォルト値は2048で、予想される接続または関連する接続を格納するために使用される。
大部分のトラフィックがSIPセッションに関連付けられたRTP音声ストリームなどの「予想される」接続で構成される場合にのみ、期待値テーブルのサイズを大きくすることを推奨（基本はデフォルト推奨）
conntrackのテーブルサイズの変更を検討するときは、大きすぎる値を割り当てるとシステムが使用可能なメモリを使い果たす可能性があるため、控えめな方がよい
system conntrack table-size
デフォルト値は262144。この値は、システムが格納するconntrackテーブルエントリの数。
システムがメモリが制約された環境（たとえば、1GB以下のRAMしか搭載していないVM）で実行されている場合を除いて、ほとんどのシステムのconntrackテーブルサイズを2から20倍の値（1048567）に増やすことを推奨。システムの推奨メモリが最小または最小以下である場合、メモリが枯渇するのを防ぐためにconntrackテーブルサイズをデフォルト値のままにしてください
system conntrack hash-size
デフォルト値は4096。conntrackテーブルで実行されるルックアップなどのアクションを管理するために使用されるハッシュテーブルのサイズを定義。
効率のために、conntrackハッシュサイズは、conntrackテーブルサイズの1/8の値に設定する必要があります。上記の推奨されているconntrackテーブルサイズの値（2〜20倍値）については、関連するハッシュサイズの値は131070である必要があります
DDOS攻撃に関する注意
標準接続または関連接続の数がメインconntrackまたはconntrack expectテーブルを超えると、システムは新しい接続のドロップを開始します。先に述べたように、conntrackのテーブルサイズが大きすぎると、利用可能なすべてのメモリを消費して、重要なシステムが終了することがあります。
これは、システム自体またはトラフィックを転送しているデバイスがDDoS攻撃の対象である場合に発生します。 conntrackテーブルサイズの値を選択するときは、システムが処理するトラフィックの量に応じた適切な値を選択することが非常に重要です。
2.接続追跡TCP固有の調整
system conntrack tcp half-open-connections
デフォルト値は512。この値は、「半分開いた」状態にあるIPv4 TCP接続のキューサイズを定義し、firewall syn-cookies機能と連携して動作するもの。
TCPハーフオープンコネクションは、TCP 3ウェイハンドシェイクでまだ3番目のパケットを受信していないコネクションです。この接続確立フェーズでは、接続はSYN-RCVD状態になります。 TCP SYNフラッド攻撃は無効なハーフオープン接続の数が過剰になり、受信システムの接続キューをすぐにいっぱいにして、新しい（有効または無効な）接続を受け入れないままにします。
ファイアウォールsyn-cookies機能と同様に、Vyattaシステムで終端しているTCP接続にのみ影響します。ほぼすべての場合、Vyattaは主にTCPパケットを転送し、長期間半開状態に留まることのない少量のサービスに対してのみTCP接続を終了します。このため、何らかの理由でシステムが大量のTCP接続を終了しない限り、デフォルト値の512のままが推奨。
system conntrack tcp loose
このオプションはブール値で、デフォルトで有効。
既存の接続に含まれているように見えるが、conntrackテーブルにはまだ存在していないIPv4 TCPパケットが、確立された接続の一部である有効なパケットであると仮定するもの。
接続がセキュリティよりも優先される環境では、有効のままが推奨。これにより、システムクラッシュや予期しない電源の再投入などの障害から復旧しても、システムがまだ存在する接続を受け入れることができる
system conntrack tcp max-retrans
デフォルト値は3
この値は、古くなったIPv4 TCP接続のタイムアウトを設定するために使用されます
有効なTCPセッションで大幅な遅延が予想される理由がない限り、この設定をデフォルト値の3のままが推奨
3.接続追跡イベントのロギング
デフォルトでは、conntrackテーブルからのエントリの作成、変更、削除などの接続追跡イベントは記録されません。デバッグおよびトラブルシューティングの目的で、conntrack関連のログメッセージをシステムログファイルに送信するようにシステムを設定できます。 Conntrack関連のログオプションは、Vyatta CLIとGUIの 'system conntrack log'サブツリーの下にあります。たとえば、conntrackテーブルに新しいTCP接続を作成するためのログを有効にするには、次のように設定します
set system conntrack log tcp new
上記をコミットすると、次のようなメッセージがシステムログファイルに表示されます。
log-conntrack: [NEW] tcp 6 120 SYN_SENT src=192.168.50.10 dst=74.125.224.97 sport=60587 dport=80 [UNREPLIED] src=74.125.224.97 dst=76.74.103.41 sport=80 dport=60587 id=3718230264
アカウンティング、フォレンジックス、または一時的なトラブルシューティングの目的でビジネス要件が強い場合にのみ、conntrackイベントログを有効にします。通常の動作状態では、パフォーマンスやディスク容量の消費に影響を与えるため、推奨されません。conntrackロギングが有効になっている場合、ほとんどのプロダクションシステムでは、1秒あたり数百〜数千のconntrack関連のログメッセージが表示されます。 conntrackに関連するイベントを記録すると、ログに記録されている各接続に処理オーバーヘッドが追加され、潜在的に転送パフォーマンスに重大な影響を与えます。本稼働環境では、この機能を慎重に使用してください
4. Disabling System ALGs (Conntrack Helper Modules)
絶対必要な場合を除いて、システムALGのすべてのconntrackヘルパーモジュールを無効にすることをお勧めします。これにより、ヘルパーモジュールをトラバースするために必要なコードパスが削減され、パフォーマンスが向上します。
system conntrack modules ftp disable
system conntrack modules gre disable
system conntrack modules h323 disable
system conntrack modules nfs disable
system conntrack modules pptp disable
system conntrack modules sip disable
system conntrack modules sqlnet disable
system conntrack modules tftp disable
# SIP ALG Tuning Options:
system conntrack modules sip enable-indirect-media
system conntrack modules sip enable-indirect-signalling
system conntrack modules sip port