VNC認証失敗エラーが多すぎる - Fail2ban

VNC認証失敗エラーが多すぎる - Fail2ban

Xtightvnc がインストールされている Debian 11 サーバーでは、「認証失敗が多すぎます」というメッセージがたくさん表示されます。私はVNCを介して私のサーバーにログインしたい不正なユーザーをブロックするためにFail2banを使用したいと思います。しかし、有効なルールが見つかりません。私が見つけたルールは非常に古く、ログには適用されません。

14/10/21 20:37:43 Got connection from client 209.141.49.123
14/10/21 20:37:43 Using protocol version 3.3
14/10/21 20:37:43 Too many authentication failures - client rejected
14/10/21 20:37:43 Client 209.141.49.123 gone
14/10/21 20:37:43 Statistics:
14/10/21 20:37:43   framebuffer updates 0, rectangles 0, bytes 0

私は私のアクセスIPを無効にするためだけにiptablesを使用しますが、このソリューションは望ましくありません。

答え1

残念ながら、このVNCロギングのログ形式はfall2banには適していません。失敗したメッセージにはIPアドレスは含まれておらず、IPを持つエントリと失敗した試行には、このIDにグループ化できる識別子は含まれていません。

デフォルトでは、FAIL2BANはこの種の複数行ログ(IPを含む1行とエラーを含む別の行)を2つの方法で処理できます。

  • 刑務所/フィルタmaxlines> = 2ローリングログ、メッセージウィンドウには1つ以上のメッセージが含まれています。
  • 新しい複数行処理では、<F-MLFID>...</F-MLFID>同じクライアントからの2つのメッセージを考慮するために、タグを使用して各行のセッション関連IDを取得します。

ここでは、両方のアプローチが適切ではありません。

まもなく次のように合法的な試みと失敗した試みが同時に発生すると、これを区別できなくなります。

Got connection from client 192.0.2.111
Got connection from client 192.0.2.222
Too many authentication failures - client rejected
Client successfully connected ~artificial log-entry (I don't know ~

ここでは2つのクライアントが接続されていますが、1つは失敗し、もう1つは成功しました。どちらが成功し、どちらが失敗しましたか?

拒否されたメッセージの後にはまだ暗黙的にログエントリ(IPおよび)があるため、接続が成功したgone後にクライアントが消える可能性がほとんどないと思われる場合は、近くのメッセージを次のメッセージclient rejectedとして扱うと言えます。gone同じクライアント(これは少し「危険」です。特に、ある瞬間に成功し、後で消える間に追加のメッセージがない場合はさらにそうですが…)。

その後、次の構成を使用できます。

# increasing the value of `maxlines` would make that the filter works more precise (can consider failures also in case of some flood in log between `client rejected` and `gone`),
# but it would make it more unsafe at the same time (because it can cause false positives on `gone` messages from legitimate clients occurring after `client rejected` logged from evildoers):

maxlines = 2

failregex = ^\s*Too many authentication failures - client rejected<SKIPLINES>\s*Client <ADDR> gone

(fail2banバージョンが0.10より古い場合は、次のもの<ADDR>と交換してください)<HOST>

しかし、とにかくVNCサイトで修正する方が良いでしょう。たとえば、client rejectedIP アドレスをメッセージに直接追加したり、セッション関連 ID を導入してクライアントを明確に識別したりします。

関連情報