一つのbanaction、二つのトランスポート：fail2ban VPN jailの修正

fail2ban自体はパケットを一つも落としません。行動を呼び出し、その行動がプロトコルとポートを指定します。jailがbanを報告しているのにデーモンがログインを受け付け続ける場合、そのbanは通常は本物で、ログが示すより狭い範囲です。もう一方のトランスポートで再接続するクライアントは、インストールされたルールに決して当たりません。何かを変える前に、行動が何をインストールしたかとデーモンが何を待ち受けているかを比べてください。証拠は行動が書き込んだファイアウォールチェーンにあり、jailの一覧にはないからです。

jailの要約ではなく、チェーンを読む

fail2banはサービス用チェーンの前に独自のチェーンを挿入するので、カウンターの一覧は存在するものを正確に示します。jailの名前を冠したチェーンが、プロトコル列がudpと読めるルールを一本だけ持っているなら、それが届き続けるTCPログインの完全な説明です。拒否されているのは禁止された送信元からのUDPパケットだけです。サービスにはTCPの待ち受けがあり、そのチェーンの中の何もそれに触れていません。

隣のjailの効果にも注意してください。欠けている半分を別のjailが供給しているだけで、あるホストは完璧に設定されているように見えます。そして同じビルドは、そのjailが入っていない場所では何もしません。

行動は一つのプロトコルだけを指定し、そこで壊れる

各banactionはファイアウォールコマンドのテンプレートであり、プロトコルはそのプレースホルダーの一つに入っています。狭さは意図的で、Web用のjailとDNS用のjailが同じポートを塞ぐ理由はありません。これが罠になるのは、サービスが複数のトランスポートで待ち受けるときで、VPNデーモンは日常的にそうしています。フィルターが両方のトランスポートの失敗ログインを見ていても、行動は片方しか覆いません。

SoftEtherとOpenVPNの配備は通常UDPとTCPを同時に待ち受けており、どちらの場合もログ行が同じに見えるため、フィルターは両方を見ています。非対称性はjail自身のレポートには決して現れません。fail2banは失敗を正しく数えたうえで、その失敗が届いたトラフィックの半分にしか適用されないルールを入れました。

banに両方のトランスポートを覆わせる

代わりにjailの定義で直してください；手書きのルールは次の再読み込みでかき混ぜられます。プロトコルごとに一つずつ、二つの行動を明記します：

action = %(banaction)s[name=%(__name__)s-tcp, actionname=%(__name__)s-tcp, protocol="tcp", port="%(port)s", chain="%(chain)s"]
         %(banaction)s[name=%(__name__)s-udp, actionname=%(__name__)s-udp, protocol="udp", port="%(port)s", chain="%(chain)s"]

protocol = allで短くしようとしないでください。既定のbanactionはmultiport行動で、-p <protocol> -m multiport --dports <port>に展開されます。L4プロトコルがなければポート一致が試すものが何もないため、jailが成功したbanを報告し続ける一方でiptablesはルールを拒否します。iptables-allportsやnftables-allportsのような全ポート行動は一つのエントリを受け付けますが、その送信元の全ポートを禁止してしまい、これは別の判断であり独自の正当化が必要です。protocolはtcpかudpのままにして、二つのエントリを受け入れてください。

設定を信じるのではなく、ルールが存在することを証明してください（設定はチェーンが保持するまでの意図にすぎません）：

iptables -S f2b-vpn-tcp
iptables -S f2b-vpn-udp

各チェーンはルールを一本だけ載せるべきで、一本目に-p tcp、二本目に-p udpが入り、どちらも禁止されたアドレスを指定します。次に、同じアドレスが両方のトランスポートで拒否されることを確認します。チェーンで見ていないbanは希望にすぎず、同じ症状の次の報告はまた同じ一時間を費やすことになります。

banがまだ取りこぼすもの、そして次の事例

行動が行うのは単一の送信元を拒否することだけで、しかもその中に列挙されたポートに限られます。アドレスを回転させる攻撃者には何の効果もなく、何百人もの利用者が共有するキャリアグレードNATの出口から敵対的なマシンを切り離すこともできません。そこでは一つのbanが何もしていない人々を締め出します。フィルターがクライアントが実際に持つアドレスを読むようにしてください。転送されたヘッダーやプロキシのアドレスではありません。誤りが自然に失効するよう、期間は十分短く保ってください。

これらのどれもプロトコルの修正を飛ばす理由にはなりません；二つの考えを同時に持つ理由になるだけです。banはjailの要約が示すより狭く、完全なbanでさえ脅威より狭いのです。ファイアウォールチェーンをデーモンの待ち受け一覧の隣に置いてプロトコルごとに比べてください、banがそもそもサービスに届くかどうかを決めるのはその二つの一覧だからです。

再読み込みのコマンドとチェーンの一覧を、jailの隣のランブックに残してください。次の人はどちらも必要とし、jailの要約はどちらも教えてくれません。