Fail2Banの再インストールと設定の見直し

コンピューターに不正にアクセス
©いらすとや.

メールサーバやウェブサーバをインターネットに公開していると、どうしても迷惑さん達がたくさんやってくる。
メールサーバやウェブサーバでログを録って、Fail2Banでそのログをリアルタイムで監視する。
ログインに失敗したとか何か悪さしようとしているログが記録されしだい、FailBanはただちにそのログを検知して指定された動作をする。多くの場合はそのログに記録されたIPアドレスをパケットフィルタに登録して、その後しばらく(指定した期間)はそのIPアドレスからの通信を受け付けないようにする。なお、Fail2Banという名前だからといってかならず「ログイン失敗」→「Banする(ハブる)」という用途にしか使ってはいけないということはない。

「がとらぼ」の中の人はずいぶん長くFail2Banを利用している(でも詳しくはない)が、突然1台のホストのFail2Banが調子が悪くなった。ログにどんどん認証失敗のログが溜まっているのに殆ど反応しない。完全に反応しないというのではなく中途半端が一番困る。で、自分でFail2Banのフィルタールールを作って登録して動作テストを行ったのだが、やはり全く反応しないわけではないが「問題発生のログ」に殆ど反応しない。Fail2Banのログに何か異常が出ていれば対応のしようもあるのだが問題なし。Fail2Banを再起動しても変わらず。

Fail2Ban関係で変わったといえば、Fail2Banの最新版の0.11.2が出たのが昨年2020年11月。これは半年以上前なので関係なさそう。
FreeBSDのPortsでFail2Banの最新版が出たのが2021年6月15日、問題の発生しているホストでPorts/PKGを最新版に更新したのが7月前半。これっぽい。
FreeBSDのPortsのFail2Banの最新版0.11.2_1の変更点の注意書きは、「PKG/PortsでイントールしたFail2Banを稼働させるためにディレクトリが足りなくてもユーザーの責任でなんとかしろ云々」(意味不明)
まぁ、ports/PKGで何か足りなくてもユーザーでどうにかしてねっていうのはFail2Banに限らずports/PKG全般そうじゃないかとは思うけど、何か問題が発生してるのかな?
とりあえず、FreeBSDのports/PKGでインストールしたFail2Banは多くのファイルがports/PKGの削除時に自動的に削除される。更新時も殆どのファイルが一時的に削除されて新しい版のファイルが置き直される。ユーザーが作成した設定ファイル・フィルタファイル・アクションファイルはFail2Banのディレクトリに残る。
ただし、/var/db/fail2Banに作成されるsqlite3のデータベースファイルはports/PKGを削除・更新しても消されずに残る。Fail2Banで大きな変更があってデータの構成が変わった際は注意。「がとらぼ」の人は大きな変更があったらFail2Banを停止してsqlite3ファイルを削除してfail2Banを改めて立ち上げるようにしている。

今回の動作異常は

  1. Fail2Banを停止
  2. Fail2Banを削除
  3. Pythonを再ビルド&再インストール
  4. Fail2Banの設定ディレクトリ/usr/local/etc/fail2banを退避
  5. /var/db/fail2ban ディレクトリを削除
  6. Fail2Banをビルド&インストール
  7. Fail2Banの再設定
  8. Fail2Banの起動
以上で結果的に直ってしまった。(Fail2Banの再インストールだけではダメだった)
ただ、Fail2Banはバージョン更新で意外と多くが変わるようなので設定ファイルも1から見直すべき。

FreeBSDのPorts/PKGではFreeBSD用にパッチの当たった状態でFail2Banがインストールされるため/usr/local/etc/fail2banのfail2ban.confはFreeBSD向けのPath設定になっている。メインの初期設定のjail.confもFreeBSDでよく使われるアプリのログのPathが記載されたpaths-freebsd.confを読み込む設定が最初から入っている。

[INCLUDES]

#before = paths-distro.conf
before = paths-freebsd.conf

fail2ban.confとjail.confを含め/usr/local/etc/fail2banにある設定ファイルはports/PKGを更新すると一旦削除されて新しいファイルに置き換えられるためユーザーが編集してはいけない。
jail.confの設定を変更したいなら同じディレクトリにjail.localというファイルを新規で作成して、その中に変更したい(または追加したい)内容だけを書くとその設定が優先で使用される。(オーバーライド)
そして、jail.confには初期値があるだけでなく設定の書き方の参考にもなるのでしっかり見る。

たとえは、Postfixであればjail.confの[Postfix]セクション(Jail)に設定が書かれているがこの設定は有効化されていない状態。 なので /usr/local/etc/fail2ban/jail.local (無ければ作成)には
[postfix]
enabled  = true

と書いてやればjail.confの[postfix]セクションに書かれた設定でそのルールが有効化される。(ただし、アクションなど他の設定が未指定だと機能するか不明)

また、Fail2Banの0.10まではではPostfix用の設定は分かれていなかったような記憶があるが、少なくともFail2Ban 0.11系ではPostfixの設定は複数存在する。 Postfix用のフィルターファイルは /usr/local/etc/fail2ban/filter.d/postfix.conf の1つなのでそこにいろいろ書かれている。また、セクションが複数あるだけでなく 0.10からはmodeもあるのでさらに細分化されている。 jail.localには使用するセクションをenabled = trueにするだけでなく使用するモードも書く。例: mode = more
たとえばPostfixでSMTP認証を実装するのにSASLを使っているとすると、fail2Banには[postfix-sasl]というセクションが用意されているので有効化する。fail2ban 0.9系まではPostfixのSASL関係のログを検知するフィルタは存在せず、0.10で[postfix]の中にSASL関係のログを検知するフィルタが入り、0.11で[postfix]からSASL関係のログを検知するフィルタが外れて[postfix-sasl]に入った。バージョン毎に違うため要確認。

jail.localの例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 192.168.0.0/24 fd00::/16
bantime  = 6h
findtime  = 12h
maxretry = 3
destemail = foobar@example.com
action = pf[name=%(__name__)s, bantime="%(bantime)s", actiontype=<allports>]    #←パケットフィルタpfでBanする
         %(mta)s-whois[name=%(__name__)s, sender="%(sender)s", dest="%(destemail)s"] #←IPアドレスの素性をwhoisで引いてメールする
         webhook[]    #←この行はpfのフィルタリングを実行すると共にwebhookで通知する (新規にwebhookアクションを作った場合)
         #アクションは必要に応じて複数設定可、それぞれ1行で書く


[postfix]
enabled  = true

[postfix-sasl] #(SASLの認証等を使っているなら)jail.confに書かれているpostfixフィルタのオプションモードの有効化 jail.confは変更せずにjail.localで指定
enabled  = true
bantime = 12h
maxretry = 1

本来はセクション別にでも監視対象のログファイルを指定してやるところだが、メジャーなアプリケーションは必要無い場合がある。
postfixのログの場合、jail.confで before = paths-freebsd.conf が指定されていて、そのpaths-freebsd.confの中でさらに before = paths-common.conf が指定されていて paths-common.conf の中で postfix_log = %(syslog_mail_warn)s と指定されている。戻って、 paths-freebsd.conf の中で postfix_log = %(syslog_mail_warn)s と指定されているため、jail.confの[postfix]セクションで指定されている logpath = %(postfix_log)s は logpath = /var/log/maillog ということになる。これが初期値なので jail.local でログファイルを指定する必要はないということになる。
postfixのログの出力先を変更しているということであれば、logpath = hoge という設定をjail.localの[postfix]セクションに追加する。

Webhook用のアクションを作る

/usr/local/etc/fail2ban/action.d/webhook.conf (新規)
1
2
3
4
5
[Definition]

actionban = /usr/local/bin/curl -X POST \
            -d '{"name":"fail2ban-<name>", "server":"<fq-hostname>", "address":"<ip>"}' \
            https://example.com/webhook/listener.php

この例では https://example.com/webhook/listener.php がwebhookの受け手。(この記事では省略)
<name>, <fq-hostname>, <ip> はfail2banで使われる変数。

# service fail2ban start    #Fail2Banの起動  

動作確認

# fail2ban-client status
Status
|- Number of jail:      5
`- Jail list:   dovecot, postfix, postfix-sasl, rainloop, recidive

fail2ban-clientコマンドに引数 status を付けると稼働中のセクション(Jail=牢獄)のリストが表示される。設定で有効にしたセクション名が全て表示されていて不足・過剰がないこと。
この例ではdovecot, postfix, postfix-sasl, rainloop, recidiveの5つのセクションが有効であることが判る。

# fail2ban-client status postfix-sasl
Status for the jail: postfix-sasl
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /var/log/maillog
`- Actions
   |- Currently banned: 2
   |- Total banned:     2
   `- Banned IP list:   192.168.59.101 192.168.59.142

statusの後にセクション名を追加するとそのセクションの状態が表示される。
この例ではpostfix-sasl (SMTP認証)では/var/log/maillogを監視していて、現在は2つのIPアドレスをBanした状態で、そのBan済みのIPアドレスは192.168.59.101, 192.168.59.142であることが判る。ここで表示されるIPアドレスはFail2Banで管理しているIPリストなので別途パケットフィルタの設定が正しく行われていなければこの通りに「弾く」ことはできない。パケットフィルタ側でも現在BanしているIPアドレスリストを表示してFail2Ban側と同じIPアドレスがBanされていることを確認する。

最近のfail2ban-clientコマンドではかなり多くのことができる。 --help を付けて実行すると使い方が表示される。

ADS-B用アンテナをさらに改修した話

レーダー
©いらすとや.

この記事の話は昨年末にADS-Bの受信機セットが壊れて以降の長期間にアンテナ関係で行ったことが時系列マゼマゼで書かれています。

謎の針金アンテナを作り直しと再設置
以前作った針金アンテナの記事の写真。
スタブの部分が少し広く、そしてそのスタブ部分を直接グラスファイバーのポールに留める方式にしていた。これでもまぁまぁ受信できていたのだが、なんか気に入らなかったのも確か。今回アンテナケーブルを変更するついでにアンテナ自体も作り直すことにした。ただし、基本的には「針金4箇所曲げるだけの高利得な謎アンテナを作る」のダブルツェップアンテナと同じもの。

謎の針金アンテナを作り直しと再設置 1
回収した針金アンテナのスタブの幅。アンテナの計算ではスタブの間隔は8mmということになっていたのでどうするか迷ったあげくこの時は間隔そのものを8mmで作った。この針金は直径3mmなので針金の中心からだと間隔が11mmということになる。

謎の針金アンテナを作り直しと再設置 2
前回も針金にアンテナケーブルを仮留めするのに使った圧着端子。給電点の位置を決めるのに圧着する側ではなく丸い穴(上の写真では中心より左下側に見えている穴)を針金に通して位置を探った。前回は最終的には圧着端子は使わずケーブルの端はハンダでアンテナ針金に直付けになった。
今回は圧着端子の圧着する側(上の写真では中心より右寄りの筒部分)を針金に通して位置を調整してからかしめることに。

謎の針金アンテナを作り直しと再設置 3
かしめる筒部分の穴の直径と針金の直径が近いものを選択したが案の定針金をスムーズに通ってくれないので切断した。また、アンテナケーブルと接続する部分は少し表面を削った。

謎の針金アンテナを作り直しと再設置 4
今回は針金の中心の長さでアンテナの設計どおりに作るということでスタブの間隔が変わる。つまり針金の直径が3mmなので針金と針金の間の幅は5mmになる。
針金を曲げる前に圧着端子を通しておいてスタブ部分にそれぞれ1つずつ圧着端子を配置した。圧着端子とアンテナケーブルを接続し、VNAでSWRの値を見ながら位置をずらして調整する。前も書いたが、最適位置を探すと位置はケーブルの芯線側と網線側でちょっとズレた状態になる。(1090MHzのSWRが1.0だとスミスチャートで1090MHzがちょうど中心の50Ωを通る曲線)

謎の針金アンテナを作り直しと再設置 5
写真では既に自己融着テープを巻いてしまっているが、芯線の先、網線の先をそれぞれ圧着端子にハンダ付けして自己融着テープを巻き、その上からビニールテープなどで養生する。自己融着テープもビニールテープも導電性はないということになっているが、芯線側と網線側を一緒には包まないようにした。

謎の針金アンテナを作り直しと再設置 6
この写真は今回修理を行った過程で撮影した再現用。
暫く前に、新しく作った針金アンテナを写真の赤い輪の部分にタイバンドを巻いて固定した状態で一度「完成」として屋根の上に設置したのだが、しばらくしてタイバンドが取られて壊されてしまった。聞いた話では、カラスが屋根に集まっていたらしいのでカラスにイタズラされたかな?

謎の針金アンテナを作り直しと再設置 7
壊れた状態を撮ったもの。光学望遠のないスマホで撮ったのでこれで等倍。アンテナを固定していた細めのタイバンドが無くなったのでアンテナが外れて立ってる筈のエレメントが倒れた状態に。これでも受信自体はできるけど無指向アンテナのハズが傘を横にしてさしているようなもので本来の性能は発揮できない。
金属製のマストとケーブルを留めていた細いタイバンドも取られていてアンテナケーブルがマストからだいぶ離れている。

謎の針金アンテナを作り直しと再設置 8
見た目は醜くてヤバいがエポキシパテでアンテナケーブルを固めた。パテとアンテナの針金は触れていない。マストとアンテナケーブルを留めるタイバンドは全て太いものに取り替えた。
ついでにグラスファイバーの2本の延長マストも長さを倍にしてアンテナの位置を少し高くした。

謎の針金アンテナを作り直しと再設置 9
細い単管のアンテナポールの先にグラスファイバー2本で継いで高さを稼いでいる。こうすれば上部が軽くなる。アンテナポールが金属製なのでグラスファイバーで遠くに離すことでアンテナへの影響を弱めようということもある。
アンテナマストの先端に取り付けられた針金アンテナは ┫ になっているが、上の写真だと背景に溶け込んでいて殆ど見えていない。(特にスマホ画面だと見えないかも)
一応、これで完成のつもり。

問題はカラスのイタズラが本当だとしたら、これで壊されないとは限らないのよね。昨年H2には全く問題無かったけど。

2021年8月7日追記:
カラスが数羽集まって針金アンテナを突きまくって騒いでいるらしい。曲がり始めているとも。アルミ棒が銀色で太陽光が当たってピカピカ光るからかしら?

昨年末まではアンテナからその直下60cm以内までRG58を使い、塩ビパイプに格納したBPF+LNA+RTL-SDRドングル+シングルボードコンピュータとそこから室内までLANケーブルと電源用としてのUSBケーブルを伸ばした。しかし、屋外の塩ビパイプに熱源を入れて稼働させるとどうしても結露と湯気が発生して基板類がサビてしまう。 そこで、「アンテナ直下に機器類を置いてアンテナケーブルによる信号ロスを避ける」というのは諦めてアンテナから室内まで4〜5m長のアンテナケーブルを伸ばすことにした。ただし、針金アンテナから50cmほどのところでNコネクタでケーブルをつないでいる。いつかアンテナが壊れたり新しいアンテナを作ったらそこから先だけを取り替えるというつもり。また、バイアスTのLNAを購入したらそこに挟むというのもアリかもしれない。
で、安価なRG58ケーブルを幾つかAliExpressで購入したのだが、結構ヒドくて内1本に至っては3mのケーブルで信号がほぼ届かないほど。端子を取り替えたら直るかなと思って端子を外したら網線がボロボロボロボロ崩れたのが次々出てきてこれはダメだと思った。というか、RG58はさすがに1m以上は良くないかなと思ったのでもう少しだけマシそうなのを購入。今回アンテナケーブルには5D-FBを使用した。5Dなので太さ7.5mmで50Ω、家庭の衛星放送のアンテナケーブルに使われる5C-FBが75Ωで似たようなやつ。
FlightAwareのFAQを見ると「アンテナから受信機までのケーブルは、高品質の50オーム同軸ケーブルが15 m以下である必要があります(Ecoflex 10、Ecoflex 15、Westflex W103、H100、LDF250、LDF450、またはLMR600を推奨)」と書かれている。LMR400でも高くて手が出ないのにそれが推奨にすらなってなくてLMR600とかいう個人的には見たこともない直径15mmの太くて硬い高価なケーブルが推奨とかちょっとヒドい。でも、裸銅のソリッドケーブルだとケーブル曲げるのが大変な代わりに形作られたケーブルを変形させるのも大変なので今回のようなカラスに留めバンド取られて壊されるというようなのは無くなるかな?

謎の針金アンテナを作り直しと再設置 10
dump1090-faの5.0あたりから入っているウェブUIの新版SkyAwareによる昨日午後の様子。日中は100NM(海里)=185km以内で認識されることが殆どだったが、新しく作ったアンテナでは日中でも100NMを超えて遠くの航空機も捉えることが増えた。また、「がとらぼ」の中の人の環境では北西の若狭湾方向に限られるが夜も含めて180NM(330km)程度まで見えることが増えた。高度4万フィートくらいで巡航している旅客機だと海抜0mで周りに障害物が無いとして地球が丸い関係で見えるのは理論上では230NM(420km)が限度。高度2万4千フィート(7400m)の航空機だと計算上の最大距離は170NM(320km)ということになる。ADS-Bの1090MHzは光に近い特性で曲がったり大気中で反射したりしないためこれを超えるとなんかオカシイということになる。(ただし、稀に320NM=600km超えとかいうアヤシイのを検知することがあるけど)

以下2021年7月29日追記:

謎の600km超え 1
この画像はdump1090-faの出力する値をPrometheus + Grafanaで監視しているもの。(dump1090 Prometheus ExporterでADS-B受信状況を監視する参照)
頻発するわけではないけど、ときどき600kmを超える何かを検知しているというのが画像中の赤丸のように記録されている。このグラフは48時間分を表示しているので1瞬だけ飛び出たようなのは表示されず、数十秒〜数分検知されていなければこのようには表示されない。でも地球の丸さと航空機の高度を考えると600kmというのはありえない。何かの誤りやADS-Bの誤情報、エラー訂正の失敗だとは思うけど謎だった。

謎の600km超え 2
自衛隊F-15?と思われる航空機が能登半島の西、若狭湾の北方をうろついていたので眺めていたら、九州の宮崎県の海岸近くに突然ワープした。しかも暫くが2回。受信した値を間違えてエラー訂正してプロットしてるんだろうとは思うけど、こんなに変な風になるのね。しかも600km超えの時は毎回測ったように600km少しの同じ値なので毎回この場所(能登半島の西)に現れた航空機が間違って宮崎県沖に瞬間移動してるように検知してるのかな?

Up