広告ブロック機能を使っている閲覧者には読めない記事を送信するアンチ広告ブロック

チラシおことわり
©いらすとや.

この記事は、嫌儲の方(自身の行為によりアカの他人が1円でも利益を得ることが許せない方)には到底納得できないであろう内容となっています。別のページまたは他所のサイトに移動されることをオススメします。

ウェブの広告は、「がとらぼ」の中の人が閲覧者であれば「まぁ見たくないけどどうでもいい。」程度。しつこく同じのが表示されたりセクシャルな画像だったり健康関係の広告の不快な画像、全ページ広告とかは「できれば見たくはない」そんな感じ。広告内容云々以前にハラの立つ行儀の悪い表示の広告もある。
でも、ウェブサイトを作って提供し続けるとなると、サーバのイニシャルコスト+月々の維持費さらにコンテンツを作るコストも。これが1ヶ月に1000円,2000円程度であれば全部自腹でも良いけど、維持費だけでも毎月万単位だといくら趣味でも全額自腹はツラい。たとえ微々たる額でも広告収入があれば助かるというか広告収入がないとやっていけないというもの。
そうなると、コンテンツを提供する側としては広告を見ることすら拒否してタダ読みをされるというのは困る。(コンテンツの有益性を棚上げしてスミマセン)
そこで広告ブロックアプリや広告をブロックするブラウザ拡張機能を使用している閲覧者にはコンテンツを表示しない、或いはもう少しソフトに「警告」を表示するという手段を講じることが必要になる(かもしれない)。

まぁ本来なら、「もしもこの糞下僕の拙い駄文でお目汚ししましたら誠に申し訳ございません。こんなコンテンツでも僅かでもお役に立てましたら恐悦至極に存じます。」という気持ちは持ち続けたいところではあるけど、現実にはそれどころじゃない。

閲覧者には「広告を見ない権利」はあるけどコンテンツ提供側にも「タダ読みを防ぐ権利」があると。

アンチ広告ブロックの記事とサンプル

↑のリストの最後の2つが新しく作ってみたもの。その内の上側「文字コードシフト式アンチ広告ブロック」はウェブサイト側は特に何かすることはなくて簡単なJavascriptを出力するだけ。閲覧者のブラウザでJavascriptが実行され、広告ブロックを判定して(広告ブロックしているなら)コンテンツの文字(漢字)を正常なものではなくす(読めなくする)というもの。「がとらぼ」でも7月末〜8月頭まで1週間ほど実際に試してみた。特に問題はなかったようだが、サーバからブラウザに正しいコンテンツを送信してブラウザ上で読めなくするというものなのでHTMLソースを読むなりJavascriptを無効にするなりコンテンツを異常にする処理を壊すなりすれば全く問題なく読めてしまうという問題がある。つまり「毒にも薬にもならない」程度の効果しかない。

「逆・文字コードシフト式アンチ広告ブロック」がこの記事の本題。これは、ウェブサイト側で「文字をずらす」という処理を施して送信し、閲覧者のブラウザ側で「広告ブロックが無効」ならJavascriptで(逆に文字をずらして)正しいコンテンツを表示するというもの。これはJavascriptを正常に実行しなければ正しく読めないので「広告すら表示しないでタダ読みする閲覧者の為すがままを許さない」というウェブサイト提供者側には一定の満足感が出るもの。
ただし、これを採用したからといって、閲覧者が「広告ブロック機能を無効にして正常にコンテンツを読もうとする」とか「広告をクリックしてくれるようになる」かというとそれは不明。むしろ最近は理不尽な人が増えてるので反感を買うことがあるかも

ここで言う「文字をずらす」(シフトする)というのは文字コード表で文字○個(指定分)プラス或いはマイナスした文字を表示するというもの。例えばアルファベットで「マイナス1シフト」するとB→Aのようにアルファベットの1つ前の文字になるのでIBMはHALになる。「プラス1シフト」するとB→CのようになるのでIBMはJCNになる。ひらがなだと「マイナス1シフト」すると「い」→「あ」のようになるし「プラス1シフト」すると「い」→「う」になる。漢字なども同様にシフトさせると別の文字になる。
なお、このページのサンプルではUTF-8で漢字の最初の「亜」という文字以降のコードポイントをシフトさせるようにしているので半角英数字や「かな」「カナ」などは文字が変わらない。漢字のコードポイントを1つだけシフトさせると異体字などの似た字になることが多いので頑張ればなんとか読めるか読めないか程度に書き換わる。あと、半角英数字をシフトさせるとHTMLタグなどが壊れてしまうので文章の体裁が崩れたり画像が表示されなかったりという点で困る。

ウェブページを1つずつHTMLコード手書きで作るならそこに記載するコンテンツ本文自体を文字シフトしてやらなくてはならないのでこれは後の修正が面倒だしシフトさせるのも何か用意してやる必要がある。でも、最近は1ページずつHTMLコード書いてなんてやってる人はほぼ居ないだろうと思うのでこの記事では対象外。
殆どは何らかのCMSを使ってるだろうし、中でもWordPress使ってる人が結構多いと思う。そこでWordPress用に文字シフト出力用のコードを書いた。WordPressの管理画面では正常な内容で記事の作成・編集が出来て正常な内容でデータを保存する。ページを出力するときに文字シフトして読めなくして閲覧者のブラウザに送る。

/WORDPRESSのPATH/wp-content/themes/使用しているテーマ/functions.php (次のコードをファイル最後に追記)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
add_filter('the_content', 'shift_content');
function shift_content($content) {
    $arrCont = mb_str_split($content);
    $arrCont = array_map('utf8_zenkaku_codePointShift', $arrCont);
    return implode($arrCont);
}

function utf8_zenkaku_codePointShift($str){
    $cP = mb_ord($str, "utf8");
    if ($cP > 0x4e9b) {
        $cP = $cP - 1;
        $str = mb_chr($cP, "utf8");
    }
    return $str;
}

PHP77.?以降で且つmbstringモジュールが有効でないと機能しない関数を使っています。

WordPressのテーマでthe_content()関数が使われている部分が書き換わります。つまりWordPressのコンテンツ(本文)部分を書き換えるフィルタです。記事のタイトルやページのヘッダ・フッタ・ウィジェットなどは書き換わりません。
shift_content()関数はWordPressのコンテンツ本文に書かれている全ての文字を1文字ずつ配列にしてarray_map関数で配列の要素それぞれ(つまり1文字ずつ)にutf8_zenkaku_codePointShift()関数の処理を実行しimplodeで配列内の全要素を再接続。つまり個々の文字をつないで文字列に戻す。それを出力として返す。
utf8_zenkaku_codePointShift()関数は受けた1文字のコードポイントが0x4e9c(UTF-8で「亜」という漢字)以降であればコードポイントを1つマイナス方向にシフトさせて返すだけの単純な内容。
結構面倒そうなことだけどPHPだとド素人でも超簡単にできる。

投稿記事だけ(WordPressでは普通の記事1つだけを表示する)に適用したい場合は、 shift_content() 関数内で is_singular() を使って分岐させる。このような分岐は何かしらした方が良さげ。

functions.phpはWordPressのテーマの核心部分で、これの変更をとんでもなく間違えるとウェブサイト全体が正常に表示されなくなるなど重大な問題が発生するかもしれません。十分にご注意ください。

シフトした文字を戻すJavascriptをページのフッタに挿入する。
/WORDPRESSのPATH/wp-content/themes/使用しているテーマ/footer.php (以下を最後の方の</body>の直前に挿入する)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
<script>
  const adspace = document.querySelector('#adwidget');
  const mCont = document.getElementById('mainContent').innerHTML;
  var mAfter = [];
  var afCont = '';
  if( adspace.clientHeight === 0 ){
    arrCont = mCont.split('');
    for(var i = 0; i < arrCont.length; i++){
      if (arrCont[i].charCodeAt(0) >= 0x4e9c) {
        mAfter[i] = String.fromCharCode(arrCont[i].charCodeAt() + 1);
      } else {
       mAfter[i] = arrCont[i];
      }
    }
    afCont = mAfter.join('');
    document.getElementById('mainContent').innerHTML = afCont;
  }
</script>

このJavascriptの中で、#adwidgetというのが広告のあるブロックを想定。必要に応じて変更。

このJavascriptの中で、mainContent(2箇所)というのがコンテンツ本文のブロックを想定。必要に応じて変更。

このJavascriptをどのように出力するかという処理を入れるのは当然考慮すべきこと。WordPressの「投稿記事」(ようするに普通の記事を1つだけ表示)のときだけこのJavascriptを出力するというような処理はあった方が良いが、好みで。もちろん、コンテンツ書き換え側もセットで。(読めないように書き換えたにも関わらずJavascriptが無かったら読めないままだし、本文を書き換えていないのにこのJavascriptを出力すると正常なコンテンツを異常にしてしまうので)

広告コードの部分 (Adsenseなら自動広告ではなくレクタングルのユニットなど)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<div id="adwidget">
<!--ここから広告コード -->
<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<ins class="adsbygoogle"
	style="display:block; text-align:center;"
	data-ad-layout="in-article"
	data-ad-format="fluid"
	data-ad-client="ca-pub-0000000000000000"
	data-ad-slot="0000000000"></ins>
<script>
	(adsbygoogle = window.adsbygoogle || []).push({});
</script>
<!--ここまで広告コード -->
</div>

広告コードを1行目の<div id="adwidget">と14行目の</div>で囲んでやることが重要。その id="adwidget" というのがJavascript内の#adwidgetのこと。この#adwidgetブロックの高さが0になったら広告が表示されていないという判断にする(Javascriptの方に書いてる)

コンテンツ本文は上のサンプルでは#mainContentであるということになっている。つまり書き換えられるブロックは<div id="mainContent">書き換えられる記事本文部分</div>という風になることを想定している。投稿記事(ようするに普通の記事を1つだけ)を表示するのであればテーマのファイルは /WORDPRESSのPATH/wp-content/themes/使用しているテーマ/template-parts/content/content-single.php (このPathは最近のWordpress標準添付のテーマの流儀と同じ場合) の中のthe_content();の周囲でid指定できそうなdivタグを見つけてid="mainContent"を指定する。(例: <div class="entry-content" id="mainContent">)

最近のGoogleさんはとても賢いのでこのようなコンテンツの書き換えが行われても表示完了時に正常な表示になるのであれば正常にクロールしてくれる筈だけど絶対とはいえないので自己責任で。

2022年5月12日追記:
Googleにインデックスされた記事本文が文字シフト(文字化け)した状態であることが判明。Chromeブラウザでページをレンダリングした状態でコンテンツとして認識した内容をインデックスするという話だったと認識していたがそうではないみたい。

2022年3月2日追記:
このページの広告ブロック機能は結構過激なので実ウェブサイトでの採用は見送っていましたが、微修正してこの「がとらぼ」に実装して運用をはじめました。「がとらぼ」の中でブログ記事だけに適用されます。WordPressでいう「固定記事」とスマホなどのモバイル系記事には適用されません。
2022年5月12日にこの文字コードシフト式アンチ広告ブロックの運用は中止。(他の方式のアンチ広告ブロックを採用することがあります)

関連記事:

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 を付けて実行すると使い方が表示される。

Up