piu lentoの日々 (piu lento days)

Cloudflare(以下、CF)のプロキシを使い始めてから1か月以上経ち、無料版の制限があるながらも(試行錯誤して)「簡易WAF」が出来て効果が見えて来たので、現在の まとめ的なものを簡単に※書く。

※例によって、実際には長くなった。

効果

CFのプロキシと簡易WAFにより、サーバへの不正アクセス率が1/7以下(不正アクセス件数は1/20以下)に減少し、セキュリティが向上出来たように思う。以下に、簡易WAF導入前後での不正アクセス数などの変化を示す。

なお、「不正アクセス」とはサーバへのアクセスから、成功したアクセス(例: HTTP 200)と存在しないけど不正ではないもの(例: 期限切れのブログページなど)による失敗を除いたものとする。

• 導入前
  • 2023/3, 4月: 不正アクセス数・率(以下同): 14625 (2.2%), 11659 (1.7%): 約1.3万件/月 (約2%)
    • 成功アクセス数: 約68万
    • 以前の対策(IPアドレスやURLでのフィルタ)の状態。
  • 5月: 22053 (7.1%): 約2.2万件/月 (約7%)
    • 成功アクセス数: 約28万
    • CFや簡易WAFの導入前にサーバ側での対策を強化した。 (→ 悪質なボットのブロック)
• 導入後
  • 6月: 13246 (7.7%): 約1.3万件 (約8%)
    • 成功アクセス数: 約15万
    • 6/20頃にCFのプロキシを導入した程度なので、効果は まだ少ない。
  • 7月: 980 (0.99%): 約千件/月 (約1%)
    • 成功アクセス数: 約10万
    • 簡易WAFを実装・調整しつつ(中頃までに概ね出来た)使っている。

参考のため、過去1年間のサーバへのアクセス数のグラフを示す。

グラフの設定が悪くて分かりにくいものの、拡大図を見ると、右端の7月頃から それまでの1/2くらいに減っていることが分かる。※ それは、上記の簡易WAFなどで不正アクセスが減ったためではないかと考える。

※これは、上の集計の7月の成功アクセスが6月の1/1.5になっているのに対応するだろう。なお、5月頃に大きく減っているのは、別件の効果(サーバの状態取得用データの転送を改良した)と思われる(そのアクセス数は本節の集計には含まれていない)。

考察

• 5月の対策強化で不正アクセス率が3倍以上に増えたのは、それまで見逃していたものを拒否またはエラー(→ 失敗)にしたためと考えられる。なので、それまでは なかなか危なかったようだ・・・
  • また、成功アクセス数が1/2以下に減ったのは、悪質なボットや不正なクライアントの「成功してしまった不正アクセス」が減ったためと考えられる。
• 6月末から7月のCFプロキシと簡易WAFの導入で、不正アクセス率は導入前(5月)の約1/7に、不正アクセス数は導入前(同)の約1/20に激減した。
  • 成功アクセス数は3, 4月の約1/7、5月の1/2以下となり、成功した不正アクセスは更に減ったと考えられる。

副次的な効果として、不正アクセス数(≒ ログ中のエラー数)が激減したためにログのチェックが容易になった。※ これは結構重要なことだ。まあ、ログのチェックを目視でするのはアナログ・アナクロだが、そういうチェックが必要な・役立つこともあるのではないか。

※例えば、3月のログサイズは約180MBだったが、7月は約30MBと かなり小さくなった。

これに類似することだが、郵便受けに勝手に突っ込まれる大量のチラシはクソボットや不正アクセスと同じように迷惑で、大嫌いだ。「要らなければ捨てればいい。大した手間じゃない」じゃない! 郵便受けのSNR(≒ 中身が正当な率)を低下させる。: 重要なもの(手紙)がチラシに紛れて なくなる可能性があるので、こちらに被害を与えるのだ。

チラシ問題は今は まだ大きな問題になって居ないが、あと数年経ったら世の中の流れ(常識)が変わる気がする(そうなって欲しい)。

少なくとも、「チラシ投函禁止」と明示してある建物で投函するのは、法的には不法侵入だ。

簡易WAFの構成と機能・動作概要

以下のように多段階のチェック・フィルタリングを行っている。

1. CF
   1. CF自体のフィルタ
      • 詳細は公開されていないので不明だが、以下があるようだ。
        • 悪質なクライアント・ボットなどの排除
          • AS番号, IPアドレス, UAなどのチェックをしているのではないか。
        • 異常なアクセスの排除
          • HTTP要求のチェック をしているのではないか。
            • HTTP 400になるものは ここで排除されるようだ。
   2. 自作簡易WAF
      1. 極悪クライアント/ボットへの反撃
         • 対象: 脆弱性スキャナ(スキャンしてもフィードバックなし= 攻撃), 不正アクセスを繰り返す/行儀の悪いボットなど, 偽のセキュリティ団体
         • 動作: 巨大なファイル(あるISOイメージ)にリダイレクトする。
           • 以前の挙動から、悪質なボットはリダイレクト先に行かないようなので※(スキャンの高速化のため?)、実際に反撃効果があるかは不明。
             • ※あるいは、悪質なボットは上のCF自体のフィルタで既に排除されているのかも知れない。
      2. ポートスキャンの排除
         • 対象: 公開していないポート番号でのアクセス
         • 動作: ログ(後述、以下同)に記録して拒否する。
      3. 悪質クライアント, プロバイダ(AS, アドレス範囲), 団体の排除1
         • 対象: 不正アクセスを繰り返す/行儀の悪いボットなど, 不正の温床になっている企業・プロバイダ
         • 動作: 鬱陶しいので、ログに記録せずにブロックする。
      4. ログインのハニーポット
         • 対象: 不正ログインの試行
         • 動作: ハニーポットにリダイレクトし、ログに記録してブロックする。
      5. URLのブラック(拒否)リスト
         • 対象: 明らかに不正なURL(例: "sign-up")へのアクセス
         • 動作: ログに記録してブロックする。
      6. 悪質クライアント, プロバイダ(AS, アドレス範囲), 団体の排除2
         • 対象: 不正アクセスを繰り返す/行儀の悪いボットなど, 大嫌いな企業
         • 動作: 証拠の記録と参考のため、ログに記録してブロックする。
      7. クエリー文字列でのチェック
         • 対象: 不正そうなクエリー文字列(例: "register")の送信
         • 動作: CFのチャレンジ対象にする。
           • 正当なアクセスでも対象のクエリー文字列が送信される可能性があるので、ブロックにはしない。
           • チャレンジについては良く理解していないが、人間(ブラウザ)に対してはキャプチャが出る(出ない場合もある)が、それ以外は自動で拒否されるようだ。
      8. URLのホワイト(許可)リストでのチェック
         • 対象: ホワイトリスト※にないURL(パスなど)へのアクセス
           • ※自動処理(アプリなど)からアクセスされるURLなどをホワイトリストに入れておく。
         • 動作: CFのチャレンジ対象にする。
      9. レート制限
         • 対象: 通常の正常なアクセス頻度を超えたもの(悪質・出来の悪いボットと思われる)
         • 動作: しばらくブロックする。
           • 無料版の制限のため、ブロックするのは10秒間固定である。
         • ※機能・効果は今一つである。 → 少し改善できた。 (8/4 16:59) (実装メモを参照)
2. サーバ: CFでのフィルタリングと重複しているが、単体動作時の最低限のセキュリティ確保のために行っている。
   1. IPアドレス範囲でのブロック
   2. User Agentでのブロック
   3. URLでのブロック

実装などのメモ

• CF自体のフィルタの機能について
  • CFからダウンロードした設定(自作の設定ダウンロードプログラム(後述)で取得した)の中に、CFのフィルタらしきものもある。まだ ちゃんと見ていないので詳細は不明だが、そこから機能・動作が分かるかも知れない。
• ログについて
  • CFの無料版ではログ(アクセス, 拒否)が見られない※。それだと不正アクセスの内容・状況や効果が分からず、簡易WAFの作成や調整が難しい。そこで、不正アクセスを別サーバ(「ログ用サーバ」, 概要は後述)に転送することで、ログを記録できるようにした。
    • ※限定的にイベントログは見られるが、全部ではなさそうだし見られる期間が限定されている。また、APIで取得することはできない。
  • 将来、簡易WAFが完成したらログ用サーバは不要になるが、ログが見られるほうが便利ではある。
• レート制限について
  • 無料版で機能が少なくて設定が難しい。: この稿を書いている時にメディア一覧で制限されてしまったため、かなり緩くした。ちゃんとやるならサーバでやったほうが良さそうだ(が、設定が煩雑な気がする)。
  • (8/4 16:59) その後 更に調べたら、WAFの別モジュール(Custom rules)でレート制限をスキップできる※ことが分かり、メディア一覧が制限される問題を どうにか回避できた(実際には今一つ いい加減である)。
    • ※スキップ対象の条件を設定し、動作("Then take action…")を"Skip"にし、レート制限をスキップするようにする("WAF components to skip"で"All rate limiting rules"にチェック)。
  • それで上限を下げて試しているが、画像の多いページを速くスクロールすると引っ掛かるかも知れないので、様子を見ている。
• CFの設定の保存について
  • 上を見ると分かるように、CFの設定の種類と量が かなり多い＊ため、ダウンロードして手元で保存したくなった※が、管理ページには そういう機能はなく、そういうプログラムも提供されていない＠ので、設定のダウンロードプログラムを作り(概要は後述)、定期的に自動保存するようにしている。
    • ＊例えば、リダイレクトのルールの最大サイズは4096バイトだが、そのギリギリになっているものがある。
    • ※設定のバックアップ以外に、変更点のチェックにも使える。
    • ＠外部のサービス?(Terraforming)を使うものはあるが、分かりにくく面倒そうだったので止めた。

感想など

• 簡易WAFの設定(特にブラック/ホワイトリスト)は なかなか難しい。
  • サイト固有の要素(例: 許可・不許可URL)が多い。
    • 結果を見ながら丹念な調整(チューニング)が必要。
  • 判定に使える条件が限られるため、完璧にはできない。
    • 例えば、WPのログインを判定条件にしたいが できない。
  • CFの無料版の機能制限のために実装が難しくなることが多い。
    • 正規表現が使えないのが かなり痛い・・・
    • でも、絶妙な切り方だと思う。無料では全然使えない訳ではないから納得できる。
• ログ用サーバ(別名「ゴミ箱」、「ネズミ捕り」、ハニーポット)へのリダイレクトは便利
  • ひどい不正アクセスボット(本物の悪者)は この時点で止める(リダイレクト先には行かない)ようだ。
    • あるいは、CFやログ用サーバのFWで拒否されるのかも知れない。
  • ボットをテキトーに扱える。
    • クソボットのアクセスは無駄に多いが、それらのログを分離できるため、他の重要なイベントを見逃しにくくなる。
  • ちょっと間抜けな奴が引っ掛かるようだ。
    • ログを見れば、どういう不正アクセスが来たかが分かるようにしている。
    • 始めた頃、偶然、某押し売り放送のアクセスがログに記録できた。その後は不明だが、二度と来ないで欲しい。
    • ハニーポットの偽ログインページには「本当の馬鹿以外は以下に進まないこと。」と書いてあるのに入力する馬鹿ばかりだ(実際には全部ボットだろう)。
• 今までに分かった、不正アクセスの温床のプロバイダ(AS)やセキュリティ調査の名目で不正アクセスを行っている団体など (いずれも僕の経験からの印象)
  • DigitalOcean, ColoCrossing, ColocationX, Tencent, MS, internet-measurement.com, Expanse, Censysなどは不正アクセスの数が多くてログを見るのも鬱陶しいので、記録せずに(「静かに」)破棄することにした。
    • プロバイダの数社はハッカー支援してそうな勢いだが、一般ユーザも居るのだろうか?
      • 不正アクセスをしてもペナルティがないために悪者が多いのかも知れない。
    • MSは全く いいことがない。 → 全部ブロックにした。
      • 不正アクセスが多い。
      • Bingボットはアクセス回数が多い割に馬鹿なアクセスが多いし、ヒット数が少ない(Yahoo!の1/8くらい)ので無意味。
  • ただ、上より怖いのは、別々のアドレス(AS)・国から同じ時間帯に同じような不正アクセスをしてくる連中だ。そういうのは どこかに黒幕が居て、全世界に数多くの支店(ハックしたクライアント?)を持っているのだろう。
• クソボット(robots.txtを読まない・読んでも無視する, マナーがない, 馬鹿・無駄なアクセスをする)は本当に迷惑!
  • 一応、ネズミ捕り(上記のログ用サーバ)で、robots.txt兼用の「二度と来るな!」ページを出しているが、読んでも すぐにまた来る馬鹿がほとんど。
  • AIのボット(Spawning-AI)は、robots.txtはスルーし、AI関係だけ(/ai.txt, /.well-known/tdmrep.json)チェックするが、そういうものが充分に浸透しているとは思えず、自分勝手だと思う。そういうことするから反感を買うのではないか?
    • それでも、それらのファイルがなければクロールしないようなので、良心的だ。 → 近頃、下のようなクソが居ることが分かり、それよりはずっと マトモなことが分かった。
  • 近頃出て来たanthropic-aiは かなりひどい。: Spawning-AIと違ってルールなしで、高頻度に無駄なアクセス(例: 同じファイルのクエリー文字列を変えて何度もアクセスする)をする。人工無能?
    • 次に来たら「反撃」にしようと思っている。せいぜい、人間の そういう対応も学習してくれ。
• 簡易WAFに引っ掛かった悪質なボット・クライアントなどを自動でブロックできるようにすると便利だが、上に書いたように設定が難しいので、簡単ではなさそうだ。

ログ用サーバについて

ログ記録用に使う無料ホスティングサービスを いろいろ比較したところ、x10hostingが なかなか良いが、調べたり使うと欠点も見付かった。

• アクセスログが見られる。
• メール, FTP, PHP, MySQLが使える(ただし、セキュリティのため使っていない)。
  • 無料メールにも使えそうだが、継続性が不安。
• 設定が結構いろいろできる。
  • 自分のドメインも使えたはず。
  • DNSレコード
  • Let's EncryptのSSL証明書が使える(取得してくれる)。
  • (2FA対応: 近頃見ないので、別のサービスだったかも。)
• ディスク: 512MB
  • Webのファイルマネージャは まあまあ使いやすい。
• ただし・・・
  • いろいろ制限がある感じ。
  • 1か月くらいログインしないとアカウントが削除される。
    • ログイン間隔が短いので面倒。
    • メールで通知が来る。
    • 他も同様だが、ログイン情報が2種類(大本とサイト用?)あって煩雑。
      • 1か月ログイン制限は大本なので誤解していた。
  • アクセスログが毎日更新のようで、古いものがなくなる。 → 自分でログ機能を作った。
  • サイト(ページ)作成直後にFB(facebookexternalhit)からアクセスがあったのは不審。
    • 新しいユーザーをFBに投稿している??
    • 他のボットなどからもあった。 → DNSをスキャンしている?
  • サーバのタイムゾーンがカナダ(UTC -0400)で変えられない。
  • たまにHTTP 503になったりして慌てるが、待てば回復するようだ。
  • サポートはフォーラムだけ。
  • 検索すると悪い評判も多い。 (→ 参照1, 参照2)

x10hostingの他にはPHPの制限が緩い(例: system()も可能)ところ(AwardSpace)もあったが、ちょっと怖いので止めた。

なお、この用途はホスティング本来の用途では なさそうなので、いつかアカウントが削除される可能性がある。その場合はPHPが使える別のところに移れば良い。

Cloudflareの設定ダウンロードプログラム(cf-get-config.php)について

CF APIを使って以下の設定を取得し、JSONで出力する。僕がCFの管理ページ(web)で設定して居る すべてと追加情報が取得できる。APIに対応する管理ページは"Web:"の行に書く。

• ゾーンのルールセット一覧 (List zone rulesets)
  • ゾーンのルールセット(下記)を取得するために必要なルールセットIDなどが取得できる。
• ゾーンのルールセット (Get a zone ruleset)
  • Web: Security: WAF: Custom rules, Rate limiting rules
  • Web: Rules: Configuration Rules, Transform Rules(Managed Transformsを除く), Redirect Rules, Origin Rules, Settings
• ゾーンのIPアクセスルール (List IP Access rules)
  • Web: Security: WAF: Tools: IP Access rules
• ゾーンのUAブロックルール (List User Agent Blocking rules)
  • Web: Security: WAF: Tools: User Agent Blocking
• ゾーンの設定 (Get all Zone settings)
  • Web: (他に記載のないゾーンの設定全般)
• ゾーンの その他の設定
  • CFからサーバ(オリジンサーバ)への最大HTTPバージョン (Get Origin Max HTTP Version setting)
    • Web: Speed: Optimization: Protocol Optimization: HTTP/2 to Origin
  • DNSSECの設定 (DNSSEC Details)
    • Web: DNS: Settings: DNSSEC
  • Bot Fight Mode
    • Web: Security: Bots: Bot Fight Mode
  • HTTPヘッダ: "X-Powered-By"の削除, セキュリティヘッダの追加 (List Managed Transforms)
    • Web: Rules: Transform Rules: Managed Transforms: HTTP response headers: Remove "X-Powered-By" headers
  • URLの正規化設定 (Get URL normalization settings)
    • Web: Rules: Settings: Normalize URLs to origin
  • Crawler Hints (Zone flags)
    • Web: Caching: Configuration: Crawler Hints

実装などのメモ

• CF APIの資料が分かりにくい(書いてないものもある)のと、CFの管理ページの構成とAPIの構成が異なる(管理ページは使いやすくなるように再構成している?)ため、対応させるのに苦労した。
  • 設定とAPIの対応は管理ページの"API"を押せば出るものもあるが、それが ないものが多い。
• CF APIにアクセスするためのAPIトークンはGnome Keyringに格納しておき、実行時に取得するようにした。
  • Gnome Keyringはデスクトップのログイン時にアンロックする。
• ゾーンの設定を取得するにはゾーンIDを指定する必要があるが、最初に自分のゾーン一覧を取得し、(複数ある場合は順に)その設定を取得するようにした。
• たまに(1日に1回程度)APIが失敗することがあるが、少し待ってからリトライすると成功する。
  • 待ち時間は1.5秒にした。
  • APIのレート制限(1200回/5分)があるが、それとは関係ないようだ。
    • 念のため、API実行後に0.5秒待つようにした。

※設定ダウンロードプログラムは要望があれば公開するが、今までの経験から なさそうだ。ニッチ過ぎるだろう。

PS. 作業中に気付いた、本題とは直接関係のない話

• WPのプラグインReally Simple SSLがクソになった。 → Really stupid SSL?
  • セキュリティチェックのため、/wp-content/uploads/code-execution.php を勝手に作って時々実行しようとする。
    • もうsimpleでない。別のを探すか止めたい。
• プライベートなサービスの簡易な保護
  • 不正アクセスのログを見ていると、"/private"や"/owa"(Outlook on the web?)のような、推測しやすい・広く知られた名前でアクセスして来る場合がある。
  • 例えば、サーバのプライベートな(非公開だが自分では使う)サービスのトップディレクトリを そういう名前にすると、そういう機能があることが分かり、挑戦(例: brute force attack)されてしまう可能性がある。
    • もちろん認証は あっても、サービスがあることが知られないのが一番良い。
  • そこで、トップディレクトリ名をパスワードジェネレータで作って類推されにくくし、そういう機能があることが発覚しにくくした。
    • 例: "/owa" → "/rsTZ8JKlUuhkjArA"
  • 逆に、(存在しない)分かりやすいディレクトリ名(上に挙げたようなもの)を簡易WAFのブラックリストに載せて、試行の時点で検出できるようにした(疑似餌?)。
• Oracleの無料サービス(OCI Cloud free tier)は撒き餌か詐欺?
  • 先日、ある記事で無料サービスがあるのを知って登録しようとしたが、住所、氏名、クレジットカード番号まで入れてクレジットは仮決済・返金できているにも関わらず、試用開始ボタンを押すと決済失敗になってしまった。
  • 氏名・住所の言語や使うカードなどを変えて何度か試したが駄目だった。
  • サポートに問い合わせると、数日後に やっと来た返事は決済失敗以外は何の情報も出せないとのことだった。
  • 結局、撒き餌だった気がする。優良顧客にだけ使わせるのではないか?
    • 僕だけでなく、多くの人が同じ目に遭って怒っている。
    • 何かの掲示板に それを連想させることが書いてあった。
  • 個人情報をどう使うのか気になるが、何の情報も出せないで終わりにされたらどうしようもない。
  • Java, MySQL, VirtualBoxに続くOracleへの不信感・蔑み・憎しみが追加された。

(18:40 細かい修正・加筆など; 8/4 9:25 cf-get-config.phpのAPIとWebの対応を加筆・修正, 16:59 レート制限の改良を追記, 22:11 わずかに補足)

うまく行かなかった話なので簡単に書きたい(でも長くなったｗ)。

前回などに書いた、嫌なボット、邪悪な企業、不正アクセスのブロックや、以前書いた(初歩的な)国際化の作業をしていて、再び、このブログのアクセス解析(例: どのページが人気あるか、どの地域からアクセスされるか)をしたくなった。

実際、何かをした効果を知るために測定することは重要だ。

ちなみに、プラグインの評価のために、WP Staticticsを短期間使って調べたところでは、以前試した時と同様にMusicBee関連ページへのアクセスが最も多かった。アクセス元は、当然ながら国内が最も多く、次は中国だった。また、アクセス頻度は少なく、訪問者(ユニークIPアドレス)数は1日100件前後、アクセスページ数は1日200件前後だった(どちらもボットを除く)。

数年前にSlimstat Analyticsなど試したが、機能や出来が今一つだったのと、解析することに大きな意味がない※と思って止めたため、今回も同じような結果になりそうだと思いつつも始めたが、やっぱり駄目だった。

※「エゴサーチ」に近いものがあると思っている。熱中したり一喜一憂すると、良いことはない。そして、アクセス数が多くなるような稿を書くのが目的でなく、書いたものが結果的にアクセスが多くなれば良しだ。

そもそも、良い(僕の用途・要望に合う)アクセス解析プラグインがなかった。(プラグインではないが)Google Analyticsも含めて いろいろ検討したが、どれも以下の問題があって今一つだった。

• アクセスを捕捉できない。
  • 正しく or 全く捕捉できない。
• 機能が不足している・貧弱。
• 問題・不具合が多い。
• 無料でない/有料サービスに誘導する。

それでも いろいろ探して以下を試してみたが、ボロボロだった。それらの重要な問題を書く。

• WP Statictics: アクセス捕捉のために訪問者のブラウザからREST APIにアクセスさせるのは、現在の一般的なセキュリティの認識からは不適切で常識に欠ける。
  • 近頃の更新でREST API(wp-json)にアクセスさせるようになったようだ。
    • 変更履歴にサラッと書いてあったが、もっとちゃんと説明すべきだと思う。このプラグインは そういう説明不足な点が多い。
  • WPのセキュリティ面での弱点になるため、ログインユーザ以外からのREST APIをブロックするセキュリティプラグインがある。それを有効にしている場合はアクセスを集計できない。
  • そもそも、後述のadmin-ajaxも含め、多くの弱点を作り出しているWPが悪いのだが、今は置いておく。
• Slimstat Analytics(以下、Slimstat): (まともに使えるようにするための)設定に手間が掛かり過ぎるうえに、問題・欠点・我慢すべきことが多過ぎて、使う気が失せる。
  • IPv6アドレス(範囲)での除外ができない。
    • 以前使った時はIPv4アドレスでの除外処理に不具合があって、修正案を連絡したものの随分長く放置された(どうも、作者が(メンタル面で)調子悪かったようだ)。
  • 余りにも問題が多い。最初は連絡して直してもらおうと思って居たが、多過ぎる!: 以下に例を挙げる。
    • リダイレクト(HTTP 301)を除外できないため、アクセス数が重複してカウントされてしまう。
      • このブログは、現在の一般的な規範?に従い、HTTPをHTTPSに自動リダイレクトしている。
    • ブラウザのad-blockerを解除しないと、管理画面が ちゃんと出ない。
      • 変なサイトから部品を取り込んでいるのだろうか?
    • トラッカーをクライアント(JavaScript(以下、JS)でアクセスを捕捉する)にすると、最近のブラウザ・サーバのプライバシー・セキュリティ強化(例: トラッキング拒否, CSP)のため、アクセスを捕捉できない場合が多い。
      • 特に、Edgeは ほとんど駄目だった。
    • グラフの日付の処理が まともにできていない(これで使う気がなくなった!)。: 過去1か月や1週間の表示の時に、表示期間全部のデータがない場合に期間の頭からグラフを描くので、日がズレる。
      • 以前使った時もそうだった気がする。

      • 

        WP Slimstatのグラフの処理がおかしい例: 5/24から過去1か月の表示が4/27からになっている。 (使用開始は5/23)

  • 機能は多いが、それらの詰めが甘い。
  • アクセスを捕捉するために、訪問者のブラウザからadmin-ajaxにアクセスさせる。
    • REST APIと同様にセキュリティ的に不安がある。
      • ただ、簡単に塞ぐことができないし、塞ぐことは一般的でないので、仕方ない。
• Koko Analytics: ちゃんと集計できない。機能が少な過ぎる。
  • ちゃんと集計できないのはWP Staticticsと同じ原因(REST API)だろうか?
  • IPアドレスでの除外設定ができない。
  • アクセス元の地域を調べられない。
• (プラグインではないが)Google Analytics (以下、GA)
  • プラグインが全滅だったので、手軽に ちゃんと動きそうなので試した。
  • ところが、最近のブラウザ・サーバのプライバシー・セキュリティ強化(上を参照)のために、アクセス捕捉用のJSが実行できず、アクセスを全く捕捉できなかった。
    • 上記のSlimstatよりひどく、僕が主に使っているVivaldiとFirefox(どちらもプライバシー設定を一番厳密にしている)ではJSが実行できないために、全く捕捉できなかった。
    • 他の訪問者からのアクセスも、全く捕捉しなかった。
    • 捕捉用JSをローカルに持って来て使っている方が居るようだが、見てみると、(どんな複雑なことをしているのか分からないが、)異常にサイズが大きく、難読化されていて論外なので、全くその気が起こらなかった。

使えるものが何もなくなったので、自分でサーバのアクセスログから集計するプログラムを作るほうが良さそうだと思った＊ものの、それも大変なので、ログを集計するソフト※を探して使うのが良さそうだという結論になった。

＊サーバのログにはアクセス履歴が全部あるのだから、それを使えばサイトやページを変更することなく解析できるし、嫌われている・問題になっているユーザのトラッキングを しなくて済む。

ただ、サーバのログを集計するのは問題でないのかは不明だ。: 例えば、GDPR的には どうなんだろうか?: まあ、自サイトだけの集計は「トラッキング」(追跡: 他サイトへのアクセスも含めて調査することを指すと思われる)とは言わなさそうではある。

※探したらいくつかあったが、まあ、やる気が継続していたら試すことにする。

おまけ: Internet Archiveの謎

アクセスログのチェックやアクセス解析をしていて不思議に思ったのは、Internet Archive (Wayback Machine)は一体どうやってページを収集しているのかということだ。

というのは、先月以降のログを検索しても、それらのUAが全く出て来なかったからだ。※ とすると、以前書いた邪悪な企業と同様に、「あらゆる手段」＊で収集しているとしか思えない。: 調べると、公式ページにはアクセス元を識別するための情報は見付からなかった(UAは あったかも知れない)し、他者の情報によれば、UAやドメインは複数あるし、IPアドレスは随時変化するらしいからだ。

※更に、Wayback Machineの このブログの最終収集日(5/6)に サーバにアクセスはなかった。

＊他の団体からの情報提供も受けているのかも知れない。

いかにもUS的な、「正しいことは何でも独断で やって良い」みたいな思想なのだろうか。それで嫌ってブロックする人も居るから、ちゃんとすればいいと思う。

全くの想像だが、これや以前書いた邪悪なセキュリティ企業は、密かにUSの情報面での戦力として位置づけられているので、「やり放題」なのかも知れない。

なんて書くと、「おや、誰か来―」になってしまうかも? 危ないな。

おまけ2: WPとプラグインの危うさ

良く「＊プラグインの脆弱性が見付かった」という記事が出るが、危ないものを「無効」にしているだけでは危険を防げないことを、(本文に書いた)アクセス解析や不正アクセスの検出のためにログを見ている時に気付いた。というのは、「無効」にしてもプラグインのファイルはそのままなので、外部からURLを推測されてアクセスされれば、脆弱性を突かれてしまうのだ。。。※ だから、プラグインのディレクトリごと削除しないと駄目なのだ。

※ログには、そういう脆弱と思われるプラグインのファイル(PHP)をアクセスしようとしているものがあった。PHPの前に、プラグインの有無を調べるためか、テキストファイルにアクセスしているものもあった。

以前、「無効にしているだけでは不充分」と読んだのは このことだったのだ。

WPのクソさに呆れている。

なぜ、WPは そういう問題があるのを知っているはずなのに直さないのだろうか?

先日も結構前にもあったのだが、何かの作業でサーバのアクセスログを見ると、不正アクセスや攻撃の試行が見付かって頭に来る。しばらくは対処するのだが、結局イタチごっこでキリがなくて諦めるのの繰り返しだ。

パケットフィルタでブロックした直後は不正アクセスは減るのだが、しばらくすると、敵は新しいアドレスで来て また増えるから、まるでゴキブリや鼠だ。。。

不正アクセスして来たアドレスを自動でブロックすることも考えるが、そのうちにフィルタ処理が重くなったり どこからもアクセスできなくなったりしそうなので、保留している。今は、毎月自動集計して回数が多いところをブロックするようにしている。

今回は、ブロックしても しつこくアクセスして来る企業(E𑀋panse (Palо Aｌtо Neｔwоrks)とІnｔernet-Mеaｓuremеnｔ.cоｍ ※)に、ストーカー的な気味悪さを感じた。それらは「スキャンを停めて欲しければ連絡しろ」などと書いているが＊、そんなことをしたらスパムが来るとか更に悪いことになるに決まっている＠。

※どちらの名前も いかにも公的とか研究機関風だが、そんなことはない。検索されて更に攻撃されたくないので、(今は効果がないかも知れないが)一部の文字を見た目が似ている別のものにした。以下も同じ。

＊そもそも無許可でスキャン・攻撃して居る癖に、なんでそんなに偉そうなのだ?

＠以前、別のプロバイダのabuseの連絡先に、そこのユーザからスパムメールが来るので対処して欲しいと連絡したら、返事すらなくて、逆にスパムが増えた気がする。

被害者から止めてくれるよう申請する建前のせいか、robots.txt(サーバのボットに対する許可・不許可設定)を無視する(そもそもアクセスしない)し、パケットフィルタでIPアドレス(範囲)をブロックしても、少しすると別のアドレスから来るからキリがない。更に、Іnｔernet-は高速「大量」スキャンツール(MASSCAN)を使っているし、一度の連続した攻撃(試行)の種類ごとにアドレスを変えて来る(それらにはUA(User Agent)は付いて居ない)※ので、とても悪質だと感じた。

※そのため、IPアドレスで集計すると数が少なく見えるし、UAで検索・集計・ブロックできない。

全世界の、客のものでないサーバまで、頼まれても居ないのにスキャンしてセキュリティホールを探して、一体どうするんだろうか? 日本の省庁か関連機関(名前は不明: デジタル庁? ICC-Crawlerではないようだ)のように、(内容が不充分にしても)教えてくれるなら分かるし納得行くが。

と訝しんで居たのだが、その後、とんでもないことが分かった。: 一部の企業(例: Shоｄаn※, Ⅽеnｓуs)はスキャンして見付けたサーバのポート公開状況やセキュリティホールを客(有料)や一般に公開している。犯罪の支援ではないか。

妙なのは、USの政府機関(CISA)が そういう企業のサービスを使ったセキュリティ向上を推奨していることだ。 (→ 参照＊) 矛と盾みたいなものか。武器も使いようだけど、これでは政府公認サービスみたいになってしまって、文句が言えなくなってしまう。

＊どうしても この資料がUS政府の本物と思えなかったので、機関の名前やドメイン名やSSL証明書を確認したが、本物のようだった・・・

※今まで見た中でShоｄаnは最悪だ。アクセスにUAは全く付いてないらしく(攻撃ツールで試行しているだけ?)、IPアドレス範囲が広いうえに変化が激しいようなので、特定できない。だから、僕のサーバに来たかどうかも不明で、出所が不明な攻撃として集計していた可能性が高い。

そういう企業にネットへのアクセスを提供するプロバイダ(例: Digіｔal 𑀞ｃeаn)も同罪だ。調べると、Digіｔal-社に文句を言っても禄に対処しないらしい。 (→ 参照)

まあ、上に書いたように、「政府のお墨付きがある、セキュリティ向上のためのチェックだから問題ない」というスタンスで逃げられたら、どうしようもない・・・

結局、根本的に対処しようがないのが頭に来る。全部消えて欲しい。

US系とC国系の そういう企業で戦って、両方とも消滅してくれると ありがたいが、戦争になってしまう?

補足 (5/19 21:20)

書き忘れて居た。: 連中(E𑀋panseとІnｔernet-Mеaｓuremеnｔ.cоｍ)や その他のボットを少しでも排除したくて、基本的なrobots.txt(サイト全体のもの)にブログのサイトマップの定義を追加してWPの仮想robots.txtにするようにした。※ が、結局、(本文に書いたように、)行儀の悪い奴らはrobots.txtを無視するので無駄だった。でも、あとで使えるかも知れない(少なくとも保守が楽になるし、方法が分かったので、別の定義の追加なども楽だ)。

※WPのフックrobots_txtにrobots.txtの内容を生成(置換)するフィルタ(関数)を設定した。

なお、今のrobots.txtはE𑀋panseとІnｔernet-への渾身の怒りを込めて書いた。それが他のボットや検索エンジンに読まれて誰かの目に留まれば、少しは溜飲が下がるか。

PS. なお、UAは容易に偽装・詐称できるので、別人が悪い企業を詐称したり、悪い企業がGoogleなどを詐称することが充分考えられるので、発信者はアクセスごとのIPアドレスで検索・判断するしかなく、手間が掛かる。

PS2. 当然ながら、近くのC国からも多くの不正アクセスが来るが、そもそも悪役だし上に比べれば まだ素朴なので、極悪のイメージは少ない。あと、本来のアクセスが期待できないので、どばっと広い範囲をブロックするのに躊躇する必要がないのも良い。

もしC国に真面目に読んで下さる方が居られたとしても、自国の悪い連中の行動は分かっているはずなので、上のように書かれても悪い気分にはならないだろうと、勝手に思っている。

PS3. 今のところだけかも知れないが、日本(のプロバイダ)からは ここまで悪質なものは ほとんどないので感心している。それに、日本の企業だったら、連絡すれば ちゃんと対処してくれそうだ(面倒なので、しないでブロックするが)。

今まで知らなかったのだが、WordPress(以下、WP)の言語設定には2種類ある。: 1つは本体の基本的な言語設定、もう1つはUIの言語設定である。それらの設定は以下である。

• 基本的な言語設定: Settings(設定) → General(一般) → Site Language(サイトの言語)
• UIの言語設定: Users(ユーザー) → 各ユーザーのプロファイル  → Language(言語)

※英語版UIの表記を勘で日本語にしたものを()内に書いた。

WPに限らず、僕は日本語化されたソフトのUIの文言が分かりにくくて※イライラするので、可能なものは英語表記で使っている。WPも そうして居た(基本設定を英語にしていた)。それで大きな問題はなかったのだが、例えば以下の問題があった。

• 月ごとの投稿ウィジェットのプルダウンに年月が英語で出る。
  • ウィジェットの表記の設定は変更できない。
• 投稿編集画面の単語数がおかしい。
• 投稿のExcerpt(抜粋)が全文になってしまう。
  • 例えばRSSフィードに使われる。

※日本語表記が分かりにくい・嫌な理由は山ほどある。以下に例を示す。

• • 訳自体が不適切で本当の意味が分からない・誤解する・ぼやける。
    • → 元の英単語を想像する羽目になる。
  • 部分ごとに言葉が ばらつくことがあって紛らわしい。
  • 検索したい英単語(例: 本来のコンセプトや用語)の日本語に相当するものが分からないと、検索できない。
    • カタカナ語や英字の略語になっていても、それが正しい英語の用語でないこともあって ややこしい!
  • 日本語には さまざまな文字種があったり単語に切れ目がないために、検索が煩雑・うまく行かない。
    • 関連すること: 日本語の正規表現での検索も可能なのだろうが、したくない!
  • サポート依頼する時に、元の英単語を調べるか想像する必要がある。
    • 一方、英語で使うと、このブログのように日本国内に向ける場合に日本語の単語を想像する必要がある。

近頃 最後の問題に気付いて直したくなって調べたら、上述のように2種類あることが分かった。想像だが、基本的な言語設定を日本語にすると、WP Multibyte Patchというプラグインが働くようになって、日本語の抜粋(といっても、通常は先頭の決められた文字数を出すだけ)が正しくできるようになるのではないか。

それでも投稿編集画面の単語数は おかしい。難しいのは分かるが、行数を出すとかして欲しい。

それで、基本的な言語を日本語に、UIを英語に設定したら、万事うまく行った

ように思えたのだが、それでも日本語で出る箇所がある。ほとんどはプラグインで、例えば(いつも問題の多い)All in one securityである。UI設定を見ていないのだろうと思うが、英語で出る箇所もあるので、詰めが甘いようだ。他のものにもあって、それぞれサポート依頼したり自分で直すのは面倒なので、我慢する。

そして、良く考えると、そもそも 他の多くの多言語対応しているソフトのように、基本的設定を英語にしても「ちゃんと」動くべきで、プラグインが悪いのではなく、WPの作りが悪いのである。長年Multibyte Patchに頼っているのは手抜きの証拠だ。とは言え、それはプラグインよりも どうにもならないので、我慢するしかない。

以前も書いた気がするが、これ以外にも問題(特にセキュリティ)が多いのでWPから脱出したいが、なかなか面倒だし、同じように使えるものがあるかも分からない。

先日書いた、このブログの海外へのプロモーション用※に、各稿の下に英語で(新聞のような)見出しやキャッチ的なものを出すことにした(そういうのの適切な英語訳が分からないので、"Keys"とした＠)。最初は自分で付けていたのだが、結構面倒なので＊AIにやらせることを思い付いた。

※これは、以前大嫌いだと書いたSEOの一種になるのだろうが、無理に検索の上位にしようとしている訳でなく、外国の人の目に触れる機会を作ろうとしているだけだ。

＊自分で書いたにも関わらず内容を忘れて居る(このブログの主旨には合っている)のと、近頃は やたらに長く内容が多過ぎる稿が多いことが多い。そこは要改善点なのだろう(と、書いておく)。

＠ちょっと強引だが、KeysはWordPressのタグとして扱っている。

それで、いろいろなAIソフト(エンジンは主にOpenAIの無料版)で各稿のサマリーやキーワードを生成しようとしたが、巷の評判とは異なり、今一つ うまく行かなかった。

最初にChatGPTで試したら、外部URLは読み込めないから使えなかった。次にWritesonicのText Summary V2を試したら、結構良さそうだった。出力に英語を指定すると、日本語の文章も英語でサマリーを出してくれる。ただ、それからKeysを作るのは手作業で それほど楽ではないし、WordPress(以下、WP)に貼るのも面倒だった。

そこで、こういう用途に使えるWPのプラグインを探したが、ほとんどなかった。: 多くはChatGPTのプロンプトを出すだけだし、投稿の編集ページでなく独立のページでしか使えないものや、有料(最初だけ無料)でしか使えないものも多かった(それを明記していないものがあって ひどい)。

使えないからアンインストールしたら"We Need to Talk!"とかいうメールを送って来て、unsubscribeしたら それにもメールを送って来た、大変鬱陶しいGetGene AIというクソもあった。

唯一残ったのはFlusso AI※(OpenAIを利用)だった。投稿の編集ページでボタンを押すだけで、Key Pointsというサマリーを作ってくれ、それを投稿と一緒に表示することもできるから便利だ。この出力は上述のWritesonicと同様だったので、どちらもOpenAIの機能を使っているのだろう。

※Flussoは 問い合わせに ちゃんと対応してくれて良い。出たばかりでユーザが少ないからだろうか。ただ、作者が自分でレビューの評価を★5にしているのは逆に損だ(ただ、一般ユーザを詐称している訳ではないので、悪意はなさそうだ)。

ただ、使ってみると、実はKey Pointsも今一つなことが分かった。箇条書きだけど なまじ文章(しかも短くない)になっているため、パッと見てもポイントがすぐには分からない。僕がネイティブでないせいはあるだろうが、文章の単語数が多い気がする。要するに、長ったらしい。(要約なのに"TL;DR"になりそうだｗ): 以下に、Key Pointsの出力の(良い)例(前回の稿「ちゃんと多言語対応するのは大変だ。」)を示す。

∙ The blog is primarily aimed at a Japanese audience, but some topics, such as technology, are relevant internationally, leading the blogger to consider creating an English version.

∙ The blogger initially used machine translation to create an English version of the site, using Google and Yandex, which had comparable translation quality.

∙ Google Translate was ultimately chosen because it successfully translated the name "Hamelin," and a link to the English version was added to the site.

∙ The blogger considered various options for improving the English version but decided to stick with the current setup due to the difficulty and cost involved in creating high-quality translations.

論文などなら良いが、僕がKeysとして欲しいのはツイッターのタグ※的なもの(一つの単語でなくても良く、完全な文章でなくて良い、パッと見て中身が想像できる・興味をもたせる短いフレーズ)だ。 参考までに、僕が考えたKeysは以下である。

AI translation, build multilingual website, Google and Yandex translate comparison, Google Translate, i18n, machine translation, Yandex Translate

※そういう機能のものも いくつかあったが、原文が日本語のせいか結果が全く駄目だった。

AIの出力は大筋では合っているのだが、前書きやアムランの件は余計だし(しかも、後者は読み切れていない)、Googleが すごく良いから選んだ訳ではないし、題にも書いた重要な意図(build multilingual website: 単なる英語版を作ろうと思っているのではない)は読めていない感じだ。

それ以前に、稿によっては、結果に重要な内容が書いてないことがあったので、結局、自動処理はできず、出力を確認して修正する必要がある。※ それから、OpenAIの無料版だと元の文章の長さ(単語数?)制限があって、結構多くの稿で使えなくて不便だ。

※以前も書いたが、今のAIの最大の欠点は、人間が結果を確認する必要があることだと思う。まあ、人間に依頼した(or 自分でした)作業でも同じだけど、自動化・効率向上の妨げになっている。そして、しばらくはAIに作らせたままの ひどいソフト・システムや文章が出て来そうだ。。。＊

＊でも、今だって、れっきとした人間に作らせたままの粗悪品が某ショッピングサイトAに蔓延しているので、AIだけが悪い訳ではではない。出す人間が悪い。

それに、ソフトやシステムだって、大企業が多額の費用を掛けて作ったものでもマトモに動かないことがあるではないか。(例: 近頃問題が発覚している、マイナンバーでの住民票発行システム)

それに比べれば、AIが作ったまま出すほうが費用対効果は良さそうだ。だから人間は不要だ。: などというのは、政治家とか有名人がTVとか配信で言いそうだが、単なるレトリックで技術的・論理的には正しくない。

原因は いろいろあり、人間とAIでは問題が起こる確率が異なるが、全部人間が悪いのは確かだ。AIが作ったまま出すのも、同じく人間が悪いために問題が起こる(現時点ではAIでなく人間が出すため)。

結局、どちらにしても、人間が真面目にやれば いいってことだ。少なくとも今は。

そういうことなら、最初にやったように、「自分で稿を読んで英語のキーワードを考えたほうが楽」という結論になって、(暇潰し?を兼ねて)順次やっている。

まあ、有料版のOpenAI(GPT4)なら強力で長さ制限もないのだろうから もう少し良くなるだろうが、料金が かなり高いので趣味には使えない。それでも、今後は手軽に使えるものが出て来ることを期待したい。

(19:18) その後、Flussoの方に勧められて、GPT-4 APIの待ちリストに登録した。GPT-4は全部有料だと誤解していたが、それが通れば無料でAPI(Flussoが使う)が使えるようだ。

そうすれば、長さの問題はクリアできる。キーワードを抽出する(Keysを作る)のは、どういうAPIがあるか調べてFlussoに要望するか、自分で作ってみたい。

なお、今、英語関係で一番役に立っているのはDeepL(翻訳, write(改善))だ。これもAI技術を使っているようで、普通の辞書サイトと違って生きた・「こなれた」英語にしてくれる。※ APIもあるようだが、やっぱり料金がすごく高いので使えず、もっぱらwebページで処理して結果をコピペしている。

※僕の印象なので正しいかは不明だが、日本の辞書サイトで出た、「なんか うーん」な英語をDeepL Writeに入れると、いかにも「おお これだ!」という自然なネイティブが使うような(に感じる)結果になることが多い。

なお、DeepLのは和訳は少し弱い感じ(ちょっと砕けた英語(それでも、和訳はできるしwriteは通る)は破綻する)だが、僕には英訳や英語の修正のほうが重要なので、大きな問題ではない。

PS. ニュースで良くなったと見て、Edge+Bingも試したが、なぜか散々だった。: 本文に書いたのと同じ稿に対する出力が全く誤っていて、なぜか全く別(別人)の文章に対するものだった。全然違う、どうして?と指摘したら、一方的にチャットを「終了」に されてしまった。ChatGPTなら続けて「どうして欲しい」と打ち込めるのに・・・

同じOpenAIを使っているはずなのに、随分作り込みが違うようだ。

使い物にならないようなので、Edgeは すぐにアンインストールした。いつものように、一瞬でもMSに期待したのが間違って居た。

PS2. 試しに この稿のGoogle翻訳での英語版を読んでみたが、やっぱり結構良い。破綻している箇所があってDeepLほどではないが、OpenAIのサマリーよりは ずっと読みやすい。

それから、どういう訳か、今回は「ｗ」を"lol"と訳していたので感心した。