havp を我が家の Web アクセスの経路に組み込んでみた

ということで、前エントリーからの続き。

我が家のネットワーク環境については、さらにちょっと前のエントリーで既出なわけですが

我が家のネットワーク構成概要 2017/12/16版

概略としては上の図の通りで、 Web アクセスの流れだけを抜き出してみたのが、下の図。

Webアクセス時の経路

まぁ、まんまこの図の通り、家中の PC やスマホからの Web アクセスを内部サーバ上で動いている Squid に集約して、更にそれを VyOS で有効にした webproxy (これも Squid なわけだが)を上位プロキシにしている、というわけ。
で、内部サーバで動いてる Squid 周りの設定を変更して、インストール済みの havp を更に挟み込む、というのが今回の内容。

HAVP (HTTP Anti Virus Proxy) を利用してWebアクセスにもアンチウィルス

多分、自分が見落としていただけなのだと思うのだけど、 Web アクセス時のアンチウィルスを実現するためのものとして、 HAVP というのがあるのに気がついた。

Short Description

HAVP (HTTP Antivirus Proxy) is a HTTP proxy with an antivirus scanner. It supports the free ClamAV , but also commercial solutions e.g. Kaspersky, Sophos and F-Prot.

[From HAVP – HTTP Anti Virus Proxy – The Free HTTP Anti Virus Proxy]

プロキシとして機能して、ウィルスチェックについては ClamAV などを呼び出して実行するというもの、だそうで。

「子供たちにネット使わせるには、Web アクセスのタイミングでもウィルスチェックしたほうがいいんだろうなぁ…。」と漠然と考えていたんですが、どう実現させるかというとこまでは至っていなかったので、コレは渡りに船とばかりに試してみた次第。

インストールは、コマンド一発!

インストールはそんなに難しいものではなくて、 Debian の場合( jessie 以降)であればコマンドラインから "aptitude install havp" 一発で関連パッケージまで含めてインストール完了。

root@vhost01:~# aptitude install havp
以下の新規パッケージがインストールされます:
clamav{a} clamav-base{a} clamav-freshclam{a} havp libclamav7{a}
更新: 0 個、新規インストール: 5 個、削除: 0 個、保留: 0 個。
アーカイブの 2,100 kB を取得する必要があります。展開後に 4,666 kB のディスク領域が新たに消費されます。
先に進みますか? [Y/n/?]
取得: 1 http://debian-mirror.sakura.ne.jp/debian sid/main amd64 libclamav7 amd64 0.99.3~beta1+dfsg-4 [936 kB]
取得: 2 http://debian-mirror.sakura.ne.jp/debian stable/main amd64 havp amd64 0.92a-4+b2 [135 kB]
取得: 3 http://debian-mirror.sakura.ne.jp/debian sid/main amd64 clamav-base all 0.99.3~beta1+dfsg-4 [303 kB]
取得: 4 http://debian-mirror.sakura.ne.jp/debian sid/main amd64 clamav-freshclam amd64 0.99.3~beta1+dfsg-4 [362 kB]
取得: 5 http://debian-mirror.sakura.ne.jp/debian sid/main amd64 clamav amd64 0.99.3~beta1+dfsg-4 [364 kB]
2,100 kB を 0秒 秒で取得しました (3,778 kB/s)
パッケージを事前設定しています ...
以前に未選択のパッケージ libclamav7:amd64 を選択しています。
(データベースを読み込んでいます ... 現在 381379 個のファイルとディレクトリがインストールされています。)
.../libclamav7_0.99.3~beta1+dfsg-4_amd64.deb を展開する準備をしています ...
libclamav7:amd64 (0.99.3~beta1+dfsg-4) を展開しています...
.../havp_0.92a-4+b2_amd64.deb を展開する準備をしています ...
havp (0.92a-4+b2) を展開しています...
以前に未選択のパッケージ clamav-base を選択しています。
.../clamav-base_0.99.3~beta1+dfsg-4_all.deb を展開する準備をしています ...
clamav-base (0.99.3~beta1+dfsg-4) を展開しています...
以前に未選択のパッケージ clamav-freshclam を選択しています。
.../clamav-freshclam_0.99.3~beta1+dfsg-4_amd64.deb を展開する準備をしています ...
clamav-freshclam (0.99.3~beta1+dfsg-4) を展開しています...
以前に未選択のパッケージ clamav を選択しています。
.../clamav_0.99.3~beta1+dfsg-4_amd64.deb を展開する準備をしています ...
clamav (0.99.3~beta1+dfsg-4) を展開しています...
clamav-base (0.99.3~beta1+dfsg-4) を設定しています ...
libclamav7:amd64 (0.99.3~beta1+dfsg-4) を設定しています ...
libc-bin (2.25-6) のトリガを処理しています ...
havp (0.92a-4+b2) を設定しています ...
グループ `havp' (グループ ID 138) を追加しています...
完了。
There is already /var/lib/havp/havp.loop, maybe from an earlier or custom installation, not building loopback-device
Job for havp.service failed because the control process exited with error code.
See "systemctl status havp.service" and "journalctl -xe" for details.
invoke-rc.d: initscript havp, action "start" failed.
● havp.service - LSB: HAVP virus-scanning HTTP proxy
Loaded: loaded (/etc/init.d/havp; generated; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2018-01-03 15:49:19 JST; 14ms ago
Docs: man:systemd-sysv-generator(8)
Process: 26029 ExecStart=/etc/init.d/havp start (code=exited, status=1/FAILURE)

1月 03 15:49:19 vhost01 systemd[1]: Starting LSB: HAVP virus-scanning HTTP proxy...
1月 03 15:49:19 vhost01 havp[26029]: Cleaning up /var/spool/havp... done
1月 03 15:49:19 vhost01 havp[26029]: Starting havp: Starting HAVP Version: 0.92
1月 03 15:49:19 vhost01 havp[26029]: LibClamAV Error: cli_loaddbdir(): No supported database files found in /var/lib/clamav
1月 03 15:49:19 vhost01 havp[26029]: One or more scanners failed to initialize!
1月 03 15:49:19 vhost01 havp[26029]: Check errorlog for errors.
1月 03 15:49:19 vhost01 havp[26029]: Exiting..
1月 03 15:49:19 vhost01 systemd[1]: havp.service: Control process exited, code=exited status=1
1月 03 15:49:19 vhost01 systemd[1]: havp.service: Failed with result 'exit-code'.
1月 03 15:49:19 vhost01 systemd[1]: Failed to start LSB: HAVP virus-scanning HTTP proxy.
E: Error starting service (could be due to port 8080 already in use), ignoring...
systemd (236-2) のトリガを処理しています ...
man-db (2.7.6.1-4) のトリガを処理しています ...
clamav-freshclam (0.99.3~beta1+dfsg-4) を設定しています ...
Created symlink /etc/systemd/system/multi-user.target.wants/clamav-freshclam.service → /lib/systemd/system/clamav-freshclam.service.
clamav (0.99.3~beta1+dfsg-4) を設定しています ...
systemd (236-2) のトリガを処理しています ...

と、インストール時に表示されるメッセージ、 havp のインストール後の起動のところで、エラーが出ている。

AppArmor に蹴躓く

11 月末ぐらいから、 bind9 のログが出力できないとか統計情報のファイルが作れないという状況になっていたのですが…。
ログに関しては syslog 経由で出すように設定変えて凌いだんですが、統計情報( rndc stats で出力されるやつ)が出力できないのが正常にならなくて、「 bind の設定いじってないのに、なんででなくなった?」と悩んでいたわけです。

で、今日。ふと思い立って出力ファイル名である named.stats をキーにして、/varlog/syslog に grep を実行してみたところ…。

Dec  6 10:20:14 nexus01 kernel: [927197.495080] audit: type=1400 audit(1512523214.458:3455): apparmor="DENIED" operation="open" profile="/usr/sbin/named" name="/var/log/bind9/named.stats" pid=13306 comm="named" requested_mask="ac" denied_mask="ac" fsuid=109 ouid=109
Dec 6 10:25:01 nexus01 kernel: [927484.822757] audit: type=1400 audit(1512523501.782:3456): apparmor="DENIED" operation="open" profile="/usr/sbin/named" name="/var/log/bind9/named.stats" pid=13306 comm="named" requested_mask="ac" denied_mask="ac" fsuid=109 ouid=109

apparmor って、コレかよ、原因は…。 orz

「何かの依存関係で、インストールされてたなぁ…」というのは、微かに記憶の片隅にあったのだけど、これが原因になっていたとは、予想だにせず。
パッケージのインストールログ( /var/log/aptitude )を漁ってみたら、確かにインストールしてるし、bind のログ出力周りがおかしくなったタイミングとインストールした日時が、ほぼ合致しているので、間違いなく AppArmor をインストールしたことの影響だったようです。

Aptitude 0.8.10: log report
Fri, Nov 24 2017 14:42:09 +0900

IMPORTANT: this log only lists intended actions; actions which fail
due to dpkg problems may not be completed.

Will install 8 packages, and remove 0 packages.
252 MB of disk space will be used
========================================
[HOLD, DEPENDENCIES] openssl:amd64 1.1.0f-5
[HOLD] libssl1.1:amd64 1.1.0f-3
[INSTALL] apparmor:amd64 2.11.1-3
[INSTALL] linux-compiler-gcc-7-x86:amd64 4.14-1~exp1
[INSTALL] linux-headers-4.14.0-trunk-amd64:amd64 4.14-1~exp1
[INSTALL] linux-headers-4.14.0-trunk-common:amd64 4.14-1~exp1
[INSTALL] linux-image-4.14.0-trunk-amd64:amd64 4.14-1~exp1
[INSTALL] linux-kbuild-4.14:amd64 4.14-1~exp1
[UPGRADE] libmariadbclient18:amd64 1:10.1.29-5 -> 1:10.1.29-6
[UPGRADE] mariadb-common:amd64 1:10.1.29-5 -> 1:10.1.29-6
========================================

Log complete.

===============================================================================

# bind9 側に何か変更があった?と思って調べてたんだけど、そちらは全部ハズレだったよ。

Rspamd の設定を細かくやってみる - 力技で正規表現フィルタリング

正規表現でのフィルタリング、「一応」出来るようになったので、メモとして残しておく。

modules.d ディレクトリの中を見ると、 SpamAssassin と連携するための spammassassin.conf や メールヘッダや本文中の文字列を正規表現で引っ掛けるための regexp.conf といったものがあるので、このあたりを使いこなせれば更に検知精度が上げられそうです。正規表現での検知は、実際には Rspamd デフォルトのものが有効化されているので、使われていないわけではないんですけど。

[From Rspamd の設定を細かくやってみる - Soukaku's HENA-CHOKO Blog]

但し、「正しい」方法ではないので、参考にしたいという方は、その点自己責任でお願いします。

本来の「正しい」設定方法

/etc/rspamd/local.d/regexp.conf というファイルを作って、そこにブロックしたいメールのヘッダ情報から、フィルタしたい条件を正規表現で記述します。

nexus01:/etc/rspamd# more local.d/regexp.conf
--
config['regexp']['RECEIVED_worldstream'] = {
re = 'Received=/ customer\\.worldstream\\.nl/i',
score = 2.5,
group = 'header'
}

--
config['regexp']['RECEIVED_93034net'] = {
re = 'Reveived=/\\.93034\\.net/i',
score = 2.5,
group ='header'
}

それが終わったら、rspamadm コマンド使って、フィルタしたい内容が認識されているところ確認して〜、と書きたいところなんですが、これが上手くいかない。
ドキュメント通りに設定書いてるのに、local.d/regexp.conf の記述内容が反映されない…。反映されなので、正しく記述できているのかもわからないという困った状況に陥ってしまいました。

サイバーセキュリティ財団の ZERO DAY を読んでみた

「大手書店、コンビニで発売中」と謳っているにも関わらず、東京だと Amazon 以外での入手経路のないサイバーセキュリティ財団の ZERO DAY 。遅ればせながら入手したんで、読んでみて感じたことなど。

自分的に気になったのは、Capter03 で取り上げられている WordPress の脆弱性について。
WordPress のインストールから、実際にページの不正な書き換え手法についてまでが書かれているわけですが、そのパートの最後のほうに


また、このグループ名で検索するとまだ書き換えられたことに気づかず放置されているサイトが見受けられます。被害サイトは日本のサイトもまだ多く含まれます。

とか、対応策として

WordPressのバージョンを最新のバージョンへアップデートを行ってください。

という記述があるんですがね…。
財団メンバーのサイトが、記事に記載されている手法でと思われる改竄被害を受けていた上に、

未対策なままサイトが再公開されて、再び改竄されるという被害を受けていたのを見つけてしまった自分としては、「ZERO DAY に書いたことすら、財団メンバーのサイトで実践出来てないのかよ…。」と微妙な気持ちになるわけですが…。(ちなみに、 Capter03 を書いたのは、財団理事の一人である田口氏…。)

Apple だけじゃなく Microsoft を騙るフィッシングメールも来ましたよ

相も変わらず、アカウントやクレジットカード情報狙いと思われるフィッシングメールが、流れてくるんですけど、最近多いのは Apple を騙ったもののようですね。

トレンドマイクロ株式会社は25日、Appleをかたるフィッシングメールが6月ごろから継続して確認されているとして注意喚起を行った。

[From 継続して出回るAppleの偽メール・6つの件名バリエーション、偽サイトへ誘導し、個人情報を根こそぎ窃取 -INTERNET Watch]

実際に、ボクも何通か受け取りましたけど、

  • あなたのApple IDはロックされます
  • AppIelD 情報が更新されました。
  • リマインダー: 最近アカウントが不明なデバイスからサインインされました!
  • iCloudの異常なサインインアクティビティ
  • アラート:АppleIDは、認識されていないデバイスからiCloudにサインインされました。

こんな感じの Subject のやつでした。
中には、宛先に 100 個ぐらいメールアドレスが羅列されてたのがあったりして、「そりゃ流石に怪しいだろ」ってわかると思うんですけど、タイトルだけで騙されちゃう人が一定数いるから、一向にこの手もメールも減らないんだろうなぁ、と思うわけです。利用者が賢くなれば、それに合わせて更に裏を掻こうとしてくるんで、イタチごっこも続くんですけどね…。

んで、本題は Apple ではなくて、 Microsoft を騙ったフィッシングメールのこと。

"Rspamd 1.6.0 has been released" ということなので

あまり周りで使っているという話を聞かない、 Rspamd ですが、1.6 のリリースがアナウンスされておりました。

Today, we release the new major version 1.6.0 of Rspamd. The most significant change in this version is the addition of Milter protocol support in Rspamd.

[From Rspamd 1.6.0 has been released]

実際は、アナウンスよりも先に、パッケージがアップデートされたので気がついたんですけど。

で、 1.6 から、rmilter の利用が非推奨(使えないわけではないが)となり、その代わりに Rspamd Proxy を利用して、 MTA との milter 接続を行うように変更されています。

The introduction of this feature also finally obsoletes the Rmilter project in honor of the new integration method.

[From Rspamd 1.6.0 has been released]

ということで、設定を一部変更してみた。

Rspamd 側は、 /etc/rspamd/local.d/worker-proxy.inc を、次のように。

milter = yes;	# enable milter mode
timeout = 120s;

#upstream "local" {
# default = yes;
# self_scan = yes;
#}

upstream "scan" {
default = yes;
hosts = "round-robin:127.0.0.1:11333:10";
# compression = yes;
}

この場合だと、ローカルで稼働する Rspamd でスキャンするようになってます。 "hosts" に Rspamd の稼働するサーバを複数羅列すると負荷分散が出来るようですが、自分のとこはそこまでは必要ないので、その設定はしてないです。
で、 Rspamd 自身を再起動して、正しく起動できれば、OK。

チャイルドフィルターを少し試してみたけど、やっぱりお薦めできなかった…

さて、ここしばらく(表立ってアナウンスされてはいなかったけど)メンテナンスを理由に新規申込みが停止していた、サイバーセキュリティ財団が提供するチャイルドフィルター。どうやら、サービスを提供するためのインフラ部分を作り直していた模様。

それならそれで、ちゃんとアナウンスすればいいのに、と思いつつ、利用申し込みフォームも再び有効になったので、改めて使ってみようということで、申込みをしてみた。

チャイルドフィルター利用申込みフォーム

申し込みの一時停止前は、メールアドレスだけで登録出来たのですけど、メンテナンスのタイミングで変更されていました。
メールアドレス以外に、チャイルドフィルターを利用させたい子供の学年と性別、使わせている iOS デバイスを選択した上での申込みとなります。

rspamd の Web UIの URLを 書き換える

さて、前回の落穂拾いです。

ところが、実際 Apache に対して設定してみたのだけど 500 Internel Server Error が出て上手く行かなかったので、結局 rspamd 側の設定でポート開放して、 iptables でアクセス元を絞る形に。

[From rspamd の Web GUI にアクセスしてみる - Soukaku's HENA-CHOKO Blog]

rspamd の Web UI の書き換え、 FAQ 通りに設定したのに上手く行かなかったといういうのは、前回書いた通り。

/var/log/apache2/error.log を眺めると、

[Thu Apr 27 16:18:59.762601 2017] [proxy:warn] [pid 14798] [client xxx.xxx.xxx.xxx:55948] AH01144: No protocol handler was valid for the URL /rspamd/. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

と出力されているので、改めてその内容でクグってみたところ、

こんなエラーが出た.Pを指定したのにapacheにproxyに関するモジュールが入っていなかったのが原因の様だった.proxy,proxy_httpをロードするようにしたら解決した.

[From mod_rewriteによるURLの書きかえ - yuu_nkjm blog(2014-04-13)]

と書かれているサイトがあったので、早速 mod_proxy 関連のモジュールを有効にしてみることに。

続・ボクがチャイルドフィルターをオススメしない理由

質問しても、利用解除申し込んでも、梨の礫だったわけですが、ちょっと動きが出てきたので、その辺をまとめておきます。

とにかく、利用する上で機能面でも運営面でも規約面でも不明な点、不安な点が多すぎる、ということで、オススメできないと思った次第。

[From ボクがチャイルドフィルターをオススメしない理由 - Soukaku's HENA-CHOKO Blog]

まず、既にエントリーに書いていた、解除申込みのその後ですが、

解除申込みすると「通常3営業日以内にご連絡いたします。」と表示され、「入力された内容を確認しだい、削除用のプロファイルをこのメールアドレス宛てにお送りします。」という内容の確認メールも届くのですが、それ以降は音沙汰がありません。とりあえず、このまま督促しないでいたらどうなるか試してみますけど、自力でプロファイル削除できないユーザだと、解除申込みからプロファイル削除までの間、アクセスログ抜かれ放題になるんですけど、それで善しと思ってるんですかね…。

[From サイバーセキュリティ財団って、実際どうなのよ?というお話 - Soukaku's HENA-CHOKO Blog]

結局、10 営業日(実際に解除申し込みしたのが 3 月 11 日の夜なので、 2 週間も)放置されたままだったんですが、痺れを切らしてしまいまして、 26 日のお昼過ぎに再度解除申し込みをしてみたところ、27 日の朝に解除プロファイルが添付されたメールが送られてまいりました。
#おまけに、そのメール、SPAMに分類されてたという…。

メール本文には「ご連絡が遅くなり申し訳ありません。」とありました、一応…。
多分、再度解除申し込みしていなかったら、そのまま放置状態が続いていたんじゃないかと思うと、ちょっとねぇ…。