fail2ban

最近、sl/ANY/IN のDNS queryが多発しているのでどうにかできないかと思ったのでfail2banの設定を。

しかし、そもそもUDPだしip偽装簡単だしfail2ban結構重いしであんまり意味なさげという記事が多いんではあるが、ここまで多いととりあえずのbanでも意味はありそうなので一応入れる。

元々fail2banにnamed-refusedというのがあったのでそれを使う。
が、全くHitしないのでfail2ban-regexであれこれ調べる。

予想通り、用意されたfilterとログが一致していない。

named[10854]: client @0xf1fa4cd0 104.190.220.183#3074 (sl): query (cache) ‘sl/ANY/IN’ denied

なんかログに@0xhogehogeというのが増えてたのでprefregexに追加した。

[Init]
journalmatch = _SYSTEMD_UNIT=bind9.service

[Definition]
prefregex = %(__line_prefix)s( error:)?\s*client \S+ #\S+( \([\S.]+\))?: .+$

色々調べてたらわかったこと。

journalを使うときはDate template hitsが0のままになる。多分日付をparseせずに直接journalから読んでいる。

fail2ban-regex systemd-journal を使うと量が多いのですごく時間がかかる。しかしjournalctl > hoge; fail2ban-regex hoge では日付が普通にhitしない。

jounalctl -oshort-iso -n 500 > hoge と –output に short-isoを付けるとちゃんとhitするのでこれでテストすると良い。

ここが詳しい > fail2banをうまく動かすためのTips。正規表現はシンプルに見やすく – のめうブログ (nomeu.net)

まずdatepatternでmatchして、残りがprefregexでmatch、そして最後にfailregexがmatchする。
のだが、fail2ban-regexだとその辺がわからん。ので理解に非常に時間がかかった。それ以前にpythonのregex知らなかったというのもあるけど・・・

かつ、systemd-journalからだとdatepatternがそもそも使われない（っぽい）

色々試したのだが最終的には結構シンプルに修正できた。

まあ、ログの形式が変わったりfail2banの設定が古かったりで整合性合わないのが問題なのだが・・・
fail2banの更新で修正されたりするとそれはそれで面倒だなぁ。

ついでにrecidiveも/var/log/fail2ban.logからじゃなくてjournalから読むようにしようと思ったのだが、これもよくわからない理由で断念。

まずfail2banの出力を/var/log/fail2ban.logからSYSLOGに変える。そしてrecidiveをbackend=systemdに変える。

logtarget = SYSLOG

[recidive]
enabled = true
backend = systemd

基本的にはこれで良いのだが（完全に動いたホストもある）、なぜかERROR NOK: (“can’t start new thread”,) でthreadが動かなくてダメになる。もしくはWARNING [recidive] Simulate NOW in operation since found time has too large deviationで時間がおかしいと出て動かなくなる。

多分fail2banのバグだろうと思うのだがこれ以上追っても仕方ないので諦めた。

fail2banがsystemd-jounalにまだうまく対応できていないのかなぁ

とりあえず最初の５回でBanしてその後700packetぐらいrejectしてたので今回のアタックには意味があったようだ。

しかし受け取って捨てるしかなくて単純にip banでは弾けないのがアレである。

spammer滅ぶべし。