先日から「ちょっと試す」程度のつもりだったCloudflare(以下、CF)のプロキシなど(正式な名前は 調べたが忘れた)。噛めば噛むほど味が出て食べ応えがあるため^^、ちょっとのつもりが本腰を入れてしまい、近頃では珍しく 楽しく使って居る。(とは言え、分からないことが多いので苦労はある。)
昔のGogleも似たような感じだった印象があるが、飽きっぽくて(作っては捨て)信用できないうえに、いつからか悪魔になってしまった・・・
そして、無料版で制限はあるものの充分使えるので、このまま(「駄目」になるまで)使い続けようと思っており、今までに試した概要や感想を書く。
ネットワークの接続構成
以下のように、CFがプロキシとしてブラウザとサーバの間に入る。
そのため、ホスト名(blog.piulento.netなど)でアクセスすると、実際のサーバでなくCFに繋がる(IPアドレスを検索してwhoisすると分かる)。
参考までに実行例(適宜省略。OrganizationがCloudflare):
$ host blog.piulento.net
blog.piulento.net has address 104.21.50.89
blog.piulento.net has IPv6 address 2606:4700:3035::ac43:9fa1
$ whois 104.21.50.89
# Copyright 1997-2023, American Registry for Internet Numbers, Ltd.
NetRange: 104.16.0.0 - 104.31.255.255
NetName: CLOUDFLARENET
OriginAS: AS13335
Organization: Cloudflare, Inc. (CLOUD14)
なお、「プロキシ」とは書いているが、中継サーバ的なもので、SSL証明書も入れ換えている(ブラウザで見ると分かる。: 「本物」はLet's Encryptだが、違うもの(Google)になっている)。
使って居る機能・用例
最初はそんなに凝るつもりはなかったが、管理ページを見て試しているうちに、以下のように結構多くなった。他にも使いたいが、興味とか趣味の領域だ(まあ、そもそも趣味だがw)。
- ドメイン管理(DNS)
- 権威サーバ
- プロキシ
- リダイレクト
- ポートスキャンの拒否
- 不正ログインの拒否
- 悪質なボットの拒否
- サービスの転送
- サーバの保護※ (どれも詳細は不明)
- セキュリティレベル: 高
- 何らかの条件で悪質なアクセスを拒否するようだ。
- ただ、それほど厳しくない。悪いアクセスが通過することは多い。
- 何らかの条件で悪質なアクセスを拒否するようだ。
- ボットからの保護?: Bot Fight Mode
- 「悪いボット」を拒否しているようだが、条件は不明。
- 上と同様に、もっと悪いボットが通過することは多い。
- 「悪いボット」を拒否しているようだが、条件は不明。
- DDoSからの保護
- ブラウザの整合性チェック
- セキュリティレベル: 高
- WAF (Web application firewall): 無料版なので機能は少ない。
- チャレンジ(いわゆる「キャプチャ」(CAPTCHA))
- どうやって人間か判断しているかは不明。
- ボットからのアクセス(非インタラクティブ(自動)アクセス)を ほぼ遮断できる。
- 人間からのアクセス(挑戦)を防ぐのは無理だが、ブルートフォース攻撃は難しいだろう。
- おそらく、人間が挑戦すべき対象をボットで見付けているのではないか。
- キャプチャの例
- チャレンジ(いわゆる「キャプチャ」(CAPTCHA))
- 通常の場合: 待てば本来のページが出る。
- 「人間です」を押す場合
-
-
- ブログのログインページやコメント投稿時などに出すようにしたら、かなり安心できる感じだ。
- (今のところ)スパムコメントを根絶できて居る。
- 当初はCFのAPIを使って、自分でログインページなどにキャプチャを出そうと思って居たが、WAFの設定だけでできた。
- また、非インタラクティブアクセス(例: アプリ, ボット)を許可するURLのホワイトリストを作り、許可しないものにはチャレンジを出すようにした。
- Managedというチャレンジは、基本的には人がアクセスした場合は待つだけで良いので利便性は損なわれない。
- どうやって判断しているかは不明
- 無料版のWAFが弱いので、自分でルールを作って強化した。
- Managedというチャレンジは、基本的には人がアクセスした場合は待つだけで良いので利便性は損なわれない。
- ブログのログインページやコメント投稿時などに出すようにしたら、かなり安心できる感じだ。
- 「引っ掛かった馬鹿」はイベントログで確認できる。
- ただ、多いと確認が大変なので、明らかな不正アクセスはリダイレクトでブロックすることにして、チャレンジは減らした。
-
- スピードの最適化
- クライアントへのHTTP/2, HTTP/3
- HTTP/3はHTTP/2よりは良さそうなので、サーバも対応させたい。
- なお、サーバへのHTTP/2は、以前試したときに効果がなかったのでoffにしている。
- Brotli圧縮: 詳細不明
- Early Hints: 詳細不明
- Rocket Loader: JSの高速化。詳細不明
- Nextcloudの管理ページでは無効にしないと正しく表示できなかったので、そういうルールを設定した。
- Auto Minify: HTML, CSS, JSのサイズの縮小。本当に効いているか不明。
- 常時HTTPS (勝手にHTTP→HTTPS)
- WPのHTTPSにリダイレクトするプラグインが不要になる(が、CFを使わない場合に備えて入れておく必要がある)。
- クライアントへのHTTP/2, HTTP/3
- キャッシュ
- ヒット率を向上させるためにルールを設定してみたが、余り意味がなさそう(CFのデフォルト設定で充分良さそう)。
- キャッシュできない情報は そういう指定がHTTPヘッダに書かれており、無理にキャッシュしてはいけない(意味がない)。
- キャッシュ可能なものは、上と同様に、CFがヘッダで判断して自動的にキャッシュするはず。
- ヒット率を向上させるためにルールを設定してみたが、余り意味がなさそう(CFのデフォルト設定で充分良さそう)。
- IP Geolocation
- サーバへの要求HTTPヘッダにクライアントの位置情報(国、県、市など)が入れられるので便利
- サーバや自分で検索すると重いし面倒なので、手軽で良い。
- 同様に、CFのイベントログにIPアドレスから検索された主なwhois情報が載っているのも、自分で検索しなくて済むので助かる。
- 参考までに、国と県をログに記録している。
- 例(一部伏せた。先頭のアドレスはCFのもので実際の位置とは関係なく、最後のほうの2409::xxxxがクライアントのアドレス):
- サーバや自分で検索すると重いし面倒なので、手軽で良い。
- サーバへの要求HTTPヘッダにクライアントの位置情報(国、県、市など)が入れられるので便利
162.158.118.114 - - [28/Jun/2023:21:02:02 +0900] "GET / HTTP/1.1" 200 44340 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36" "JP/Tochigi" "2409::xxxx" https:blog.piulento.net:443
- Scrape Shield
- Email Address Obfuscation: 効いているのか不明
- Server-side Excludes: 自分でページを対応させないと無意味
- アクセス解析
- 出すページによって集計条件が違うようだが、それなりに分かる(傾向が分かれば良いので、それで良い)。
- アクセス(訪問者)数は(以前調べた時と同様に)100件/日程度。
- 地域やページごとも分かるのが便利
- ページアクセス速度(所要時間)が分かるのが便利
- 描画完了までの時間のせいか、結構遅い。: 約1.5秒前後
- 時間は分かっても、なかなか高速化できない。
- たまに、すごく遅い場合がある(以前からあった)のが謎。
- 描画完了までの時間のせいか、結構遅い。: 約1.5秒前後
- アクセス(訪問者)数は(以前調べた時と同様に)100件/日程度。
- 「有料」と書かれているものと同等な(と思われる)機能が別のページにあって無料で使えている??
- 違うにしても、僕にはそれで充分
- WPの(無料)プラグインには まともなものがなかったので、随分有用だ。
- アクセス解析の例
- 出すページによって集計条件が違うようだが、それなりに分かる(傾向が分かれば良いので、それで良い)。
- 本サーバ(以下同)の訪問者数の変化(1週間)
- 地域, ページなどごとの訪問者数(1週間)
- アクセス数, キャッシュ率などの変化(1日): “Unique visitors”とあるが、左とは集計方法が違うようだ。
- ページ表示時間の変化(1週間)
※サーバの保護について
安全性を向上させるため、上記の他に、HTTPとHTTPSはCFからの接続だけを許可するようにした。*: DNSの設定でサーバの公式な名前(例: blog.piulento.net)に対応するIPアドレスをCFのプロキシのものにし、サーバのHTTP/HTTPSのポートへの接続をCFからだけ許可した。
*当初はCFとのトンネリング("Zero Trust": 大変難解)を使う必要があると思って居たが、とりあえず不要になった。
なお、SSHは(CFの無料版ではサポートされていないため、)サーバに直接接続する必要があるが、そのためのDNSレコードを用意した。そのため、SSHについては、従来どおり、サーバのパケットフィルタの機能(iptables)で防御している。
良い点
- サーバと自分の負荷軽減・手間の削減にすごく良い。
- クソなアクセス(不正アクセスや攻撃の試行やクソなボット)にサーバで対応しなくて良い。
- 自分の設定漏れ・ミスを心配しなくて良い。あるいは、自分のセキュリティ設定が補強される。
- セキュリティ関連の設定を変更する場合、CFだけで済む(サーバを変更しなくて良い)ため、手間と間違う可能性が減るのが助かる。
- ただ、CFを止めた時のため、同様の設定をサーバにもすべきである。
- クソなアクセス(不正アクセスや攻撃の試行やクソなボット)にサーバで対応しなくて良い。
- CFがフィルタリングするのかCFを敬遠するのか、ひどい不正アクセスが減った(なくなった訳ではない)。
- おかしな(例: 中身の不明なバイナリデータでHTTP 400になるもの)HTTP要求がCFのプロキシで破棄されて全く来なくなるのも良い。
- キャッシュの効きは まあまあ?
- ヒット率は10%程度
- WPは動的にページを生成しているためにキャッシュできず、表示時間は短縮できなさそうだ。
- 古いページを固定するような機能があると良さそう。でも、古いページの内容が表示時の条件によって変わる可能性があるので、難しそうだ。
- CSSは良いとして、例えばWPのショートコードは問題だ。
- 古いページを固定するような機能があると良さそう。でも、古いページの内容が表示時の条件によって変わる可能性があるので、難しそうだ。
- ただ、何となく表示が軽くなった気はする。
- ドキュメントを丹念に調べると、いろいろな機能が使える。
- Backblaze B2(クラウドストレージ)と接続した場合、B2の通信料(egress)が掛からないので、何かに使えそう。
欠点
- 機能・設定箇所が分散していて分かりにくい。場所ごとに、同様のことでも出来ることと出来ないことが違う場合がある。
- 設定方法がドキュメントにも書いてないことがある。 ← 更に検索(Google)したりAPIなどのドキュメントを見ると分かることがある。
- 参照先を書き切れていない感じ。
- 資料に書いてないことが出来る場合と出来ない場合がある。
- 書いてないことは出来なくて良いのだが、他の機能で出来ていることが出来なくて惜しいので試してみる。
- 設定方法がドキュメントにも書いてないことがある。 ← 更に検索(Google)したりAPIなどのドキュメントを見ると分かることがある。
- 結構 未完成な管理ページ(例: 表示が残念)がある。
- でも、ちゃんと使えるので許せる。
- 有料でしか使えない機能がある。
- WAFなどの条件に正規表現が使えないのが痛い・・・
- WAFなどで使えるルール数も少ない。: 3個とか10個とか。
- ただ、それぞれのルールに多くの条件が書けるので、今は問題ない。
- 自分の使って居るサービスのすべての設定をまとめてダウンロードして保存(バックアップ)する機能がない。(フォーラムにも文句が書かれている)
- 同様に、「自分が使って居る機能は何か」が一目で分からない。
- 他社の"Overview"に相当するものがない。Overviewのページはあるが、違う。
- 同様に、「自分が使って居る機能は何か」が一目で分からない。
- (プロキシなので仕方ないが、)サーバのアクセスログのアクセス元アドレス(通常は行の先頭)にはCFのアドレスが書かれるので、誤解しやすい。また、集計処理するプログラムの対応が要る。
- クライアントの本当のアドレスはヘッダのX-Forwarded-Forの値(通常は行の最後のほう)として書かれるので、忘れずにそこを見れば良いのだが、習慣のために良く誤解する。
その他
- CFの動作など
- 動作確認でポートスキャンをしたら、HTTP/HTTPSの待ち受けポートは80, 443だけでなく他に いくつか使えることが分かり、ブログ以外の機能に使って居る。
- CFのプロキシのIPアドレスの位置はUSと出るが、拠点は国内にあるようで、pingの応答は速い。: 僕のPCからだとサーバに直接するのの1/2くらい(30ms→15ms)になる。
- ただし、サーバ(北海道)からCFの拠点は遠いようで、サーバからCFまでは約20msとなり、キャッシュされていない場合には速くならなそうだ。
- CFのイベントログで分かったが、ブログ検索(サイドバーの下の方)への攻撃の手始めらしきもの※もある。以前から気になって居たが、なかなか確認出来ずに居た。これからはチャレンジ(キャプチャ)で保護できそうだ。
- ※ボット(しかも海外)が検索することは余り考えられない。
- 上述の、ページ表示時間がものすごく長い場合(10秒前後)は、キャプチャが出て(タイムアウトして)いる時かも知れない。
- CFへの懸念など
- そのうち無料プランの機能が制限されたりすると、困る。年間3000円くらいなら出してもいいが、今の有料プランはUSD 20/月くらいからと、なかなか高い。
- サーバの機能もあるのだが、今のVPSのようには使えなさそうなので、完全に移行するのは無理だ。
- CFに関する心配としては、サーバへのアクセスを全部CF経由にしているため、もしCFが落ちたら何もできなくなってしまうことだ。
- それを想定して、いつでも容易にCFなしに戻せるようにしている(つもり: やってみないと分からない)。
- それに、GoogleやAWSなどと違い、今までCFが落ちてトラブルになったという話を聞いたことがないので、信頼性は高そうだ。
- 単に僕が知らないだけとか大口ユーザの影に隠れている可能性はある。
- 気になるけど気にしないことは、CFで中継する時にSSL/TLSの暗号化が解除されるので、そこから情報が漏洩・改ざん される可能性があることだ。
- まあ、そういうことがあれば、まず僕より大口のユーザで問題になって大騒ぎになる(なって居た)だろうが、そういう話は聞いたことがないので、とりあえずは気にしない。
- でも、たまにショップサイトなどである「他人の会員情報が見えてしまう」トラブルはCDN(キャッシュ)が原因という話もあるので、全く安全という訳ではなさそうだ。
- そういうことも想定して、Nextcloudのデータはend-to-endで暗号化している。
- でも、いろいろ抜けはあるんだろう・・・
- そのうち無料プランの機能が制限されたりすると、困る。年間3000円くらいなら出してもいいが、今の有料プランはUSD 20/月くらいからと、なかなか高い。
- CFに(余り)関係なさそうなこと
- なぜか、CFのプロキシを使うようになってから、デスクトップのNextclouldアプリが1日に1回程度落ちるようになった。
PCのIPv6の一時アドレスが更新される時かと想像しているが、(← ログを調べたら、起こるタイミングがズレていたので違う) 以前は起こらなかったので不思議だ。- ログにエラーは出ず原因が分からないので、落ちたら再起動するスクリプトを作った。
- (6/30 7:55) PCのログ(syslog)を調べたら、落ちるのは1日1回より多く、落ちる時にlibglibがtrap int3というエラーを出していることが分かった。
- 調べたら、他のプログラムでも起こるようだが、解決策は なかった。ちょっと気になる。
- (7/2 15:09) 原因は確定していないが、解決方法は分かった。: Nextclould(以下、NC)アプリの接続先のIPアドレスを固定すれば良い。
- 推測した原因
- CFのプロキシを使う場合、DNSに現れるサーバのアドレスは、IPv4, v6それぞれ2個ずつの計4個となる。
- NCアプリが同期する時に前回とアドレス(特にv4/v6?)が変わると、想定外に なって落ちるのではないか。
- trap int 3は異常な場合にプログラムが自分を落とす場合に多いとのこと。
- また、サーバへの接続にプロキシ(下記)を使うと接続数が1/2くらいに減るので、NCアプリはサーバに同時接続していて、それらのアドレスやタイプが異なると落ちるのかも知れない。
- 検証と結果: sshで仮のSOCKS5プロキシを作り、NCアプリの接続先のアドレスが変わらないようにしたところ、約6時間経過しても落ちなかった。
- sshをプロキシにするコマンド例(PCのIPアドレスが192.168.0.123の場合)
- 推測した原因
- なぜか、CFのプロキシを使うようになってから、デスクトップのNextclouldアプリが1日に1回程度落ちるようになった。
ssh -N -D 192.168.0.123:8940 localhost
-
-
-
-
- NCアプリのプロキシ設定: SOCKS5, 192.168.0.123:8940
- 接続概要: NCアプリ → 192.168.0.123:8940 [ssh] → [CF] → [サーバ]
- ただ、実際には、NCアプリだけのためにプロキシを動かすのは煩雑(もったいない)だし、他の方法(例: プライベートなDNSサーバ, NW namespace, LD_PRELOAD, firejail)も同様に手軽でないので、現状のまま 落ちたら再起動することにした。
-
- なお、NCのフォーラムで聞こうと思って探したが それらしいものは見付からず、NCアプリからドキュメントを開いたら「ファイルなし」になったため、サポートは期待できないと考えて止めた。
- (7/2 15:52) その後、もしやと思ってNCのサイトで最新版アプリを探したらV3.9と、今まで使っていた2.6(
Ubuntuのリポジトリにないので、どこからインストールしたか不明・・・※)より随分違うので、それを試している。- ※今までのアプリは
NCのサイトからダウンロードしたのだろうが、更新チェック機能がなかったので、ずっと古いままだったようだ。 ← 良く調べたらUbuntuのリポジトリからインストールしたものだった。 (7/3 4:40)
- ※今までのアプリは
- (7/3 4:40) 最新版アプリを使って居る時は、通常時の(PC全体での)接続数が かなり少ないことが分かった(10個前後 → 4個)。ということは、古いアプリは使い終わった接続を切断せずに残すなどするため、時間が経つとテーブルがフルになって(想定外で)落ちるのかも知れない。
- (CFを使う前には起こらず)CF経由にして発現したのは、CFが接続を切断せずに残すからだろうか。
-
- 同様に、Seamonkeyもスケジュールのアカウント作成が できなくなってしまったが、最新版(同じ頃に更新した)に問題があるようで、以前の版に戻したら直った。
- まだ直っていないのを見ると、使う人が少ないのか。あと、新しくアカウントを登録するのが失敗するようなので発覚していないのかも知れない。
- Thunderbirdなら大丈夫だったが、以前気に入らなかった点がまだ直っていないので、使わないことにした。
- もう一つ、ログを見て居て気付いたのは、1日に1回、サーバ内から自分に変なアクセス(HTTP 400: 要求文字列などが空)があることだ。
- 一見ウイルスのように思えるが、調べたらサーバのSSL証明書の自動更新に使って居るプログラムgetsslが、更新チェックする時にopenssl s_clientコマンドでサーバの証明書を取得しており、それが異常なアクセスをしていることが分かった。
- 綺麗でないが、opensslコマンドをHTTPに対応させるのは本質的でないので、それでいいのだろうと理解した。
- opensslにもgetsslにも そこらに関する設定がないので、放置することにした。
- 一見ウイルスのように思えるが、調べたらサーバのSSL証明書の自動更新に使って居るプログラムgetsslが、更新チェックする時にopenssl s_clientコマンドでサーバの証明書を取得しており、それが異常なアクセスをしていることが分かった。
-
現在の結論
なかなか良いし、いじるのが おもしろいが、以前も書いたようにCF(CFだけでなく、特定企業・団体に固有のサービス)に依存するのは良くないので、ほどほどにする必要がありそうだ。例えば、ここが使えなくなっても容易に他に移れるように、一般的な概念で進めて「どういう機能を どう使ったか」を記録しておけば良さそうだ。そして、CF特有の機能は余り追うべきではない(おもしろいけど)。
(-6/29 15:09 修正、加筆; 6/30 7:55 Nextcloudアプリが落ちる件に追記, 8:04 「その他」の構成を改良)