2025年05月31日(土) - 21:29 | カテゴリ:
Linux
それは、唐突に起きた―――
実は、一昨日から自宅サーバのCPU負荷が高騰してアラートが定期的に発生していた。
筆者も平日は本職の方にかかりっきりで自鯖は弄れないのと、今週は佳境だったので放置してたが、
万が一クラッキングされていたら洒落にならないのでログを確認してみた。
結果、Google CloudのグローバルIPからScrapyを使ったWebスクレイピングが大量に行われ、
コレが原因で各システムのCPU負荷が上がった状態だった。
筆者が管理しているWebサーバの内1台でシステム負荷を見ると次の状況だった。
約2時間の周期でCPU負荷が飽和する位の処理が発生し、
ネットワーク観点だとTCPセッション数が瞬間的に1,500～2,000に高騰していた。
なお、スクリーンショットだとTIME-WAITのみセッション数がバーストしているが、
システム監視の周期都合なので実際はESTABLISHEDも同数が発生していた状況となる。
CPU負荷に周期性がある事からBOTで機械的に処理をされていると予測しつつ、
インターネット回線からWebサーバまで各種ログを確認したところ、
Google CloudのグローバルIPからScrapyのWebスクレイピング通信が大量に来ていた。
実際に来たHTTPクエリのログがこちら。
明確にScrapyのUser-Agentが記録されており、利用バージョンは2.11.2と少し低めの模様。
Webサイトのトップページから準繰りに全ページを辿っている状態で中々のクエリ数になっていた。
………
筆者が趣味で管理するサーバでは悪質で無ければWebスクレイピングを禁止していないが、
今回は結構なクエリが来ていた事もあり遮断しようか迷いつつ様子見していた。
本来なら、この記事を書く直前に遮断して記事にしようと思っていたものの、
夜中にWebスクレイピング自体が止まっていた。
Scrapy爆弾の報告がTwitterでも上がっていたので、
誰かがGoogleに通報したかWebスクレイピングを実行した管理者が止めたのでは無いかと思う。
通信が止まっているので筆者も様子見継続だが、
システム負荷が上がり切るレベルの高頻度Webスクレイピングはマナー違反だと思う (´・ω・`)
AIの時代だしWebスクレイピングをするなとは言わないが、やるとしても加減はして欲しいと感じた。
« 続きを隠す
2025年05月10日(土) - 19:42 | カテゴリ:
Linux
PCとサーバの通信制御用にSquidを使っており検証用にSSL復号化(SSL Bump)も利用している筆者。
約3年前にSSL Bumpを構築してから放置してたが、証明書が期限切れとなり通信出来なくなった。
通信出来ないとWebサイトを閲覧出来ない上、通信を追いかける調査にも支障が出るので更新してみた。
SSL Bumpの設定方法はSquid wikiを見て貰うとして、
証明書更新で問題になるのがSSL Bumpで必須となるSSL証明書の自動生成キャッシュだった。
SquidでSSL Bumpを実行するには、Squid本体が中間者攻撃の様にインターセプトする動作となるので、
PC ⇔ Squid・Squid ⇔ サーバで通信セッションを都度作り直す事となる。
SSL Bumpを動かすにはSSL復号化用のオレオレ証明書を作成し、
認証局の証明書をPC、サーバ証明書をSquidにインストールする必要があるのだが、
サーバ証明書を更新してもSquidが保持するSSL復号化用の証明書キャッシュを更新してくれないため、
Webブラウザでガチの中間者攻撃と検知されてしまい通信が出来なくなる。
………
Squidのcacheログには次のログが出力されるのみで内容を判断しにくい状態となっており、
フォーラムでもOpenSSLの出力するログなので、Squidでは無くOpenSSLを見る様に書かれている。
| Error negotiating SSL connection on FD 1: error:00000001:lib(0):func(0):reason(1) (1/-1) RSA |
一概にズバリと解消できる方法は無いのがコレだが、
筆者の環境ではSquidの保持するSSL復号化用の証明書キャッシュを完全初期化する事で直った。
SSL復号化用証明書のキャッシュ保存先ディレクトリが “/var/cache/squid/ssl_db” の場合、
フォルダを削除した後に次の初期化コマンドを打ち込めばエラーが直るはず。
コレでもエラーが直らなかった場合は、証明書の生成コマンド自体を見直せば不具合が解消出来るかも。
rm -rf /var/cache/squid/ssl_db
security_file_certgen -c -s /var/cache/squid/ssl_db -M 4MB
chown -R squid.squid /var/cache/squid/ssl_db |
コマンドを打ち込んでSSL Bumpのキャッシュディレクトリを初期化した後は、
今まで通りにWebサイトをSSL復号化しつつ閲覧できた。
今の時代、SquidでSSL復号化をするケースは少ないかもだがTIPSとしてメモしておく。
« 続きを隠す
2025年05月03日(土) - 00:04 | カテゴリ:
Linux
筆者の自鯖でもメールは運用しており、何処からでも利用できる様にWebメールも備えている。
従来はWebフロントエンドにRainLoopを利用していたのだが、
OSSの更新が滞ってしまったのと、かと言って自力で開発する熱意まで昇華できず乗り換えを探していた。
先日、別のドキュメントを探している中でRainLoopの後継アプリケーションとなるSnappyMailの存在を知り、
調べてみると色々とメリットも多かったためWebフロントエンドを載せ替える事となった。
という事で、RainLoopからフォークしたアプリケーションとなるSnappyMailへ移行してみた。
OSSのWebメールと言われると真っ先にRoundcubeが上がる位には有名で、
エンタープライズ向けなら昨今話題のActive! mailは採用実績が多いと思われる。
教育機関だとZimbraの採用も多いらしいが、Microsoft 365に切り替える所が多いと聞いた事あるので、
今後はSaaSに移るケースがより増えていくのかもしれない。
それらのメジャー所に比べて、RainLoopは無名に近くSnappyMailは情報皆無だが、
必要最低限の機能が卒なく実装されていて動作も軽いため筆者はRainLoopを採用していた。
今回、SnappyMailへ乗り換える決め手になったのはGUIがRainLoopに近くてシンプルかつ使いやすいのと、
プラグインも互換性のある物が多く改修すれば使える事が多いのが決定打となった。
SnappyMail全体の設定項目は結構増えてるものの、
ドキュメントを読まずに項目名を読むだけでも設定が出来る程度には纏まっている。
また、RainLoopでは開発中の機能だったり、オプション実装だったSieveにも正式対応してたりするので、
必要最低限の機能を短時間で利用するには良い選択肢になると言えそう。
OSSで大規模なWebメールならRoundcubeが候補になってくるが、
アカウント少な目な小規模環境で管理負荷を下げつつも最新機能を使いたいなら、
SnappyMailはハマる可能性が高いので是非とも使って見て欲しい。
………
最大の課題はSnappyMailの情報が全くなく、ググっても出てこない事。
公式ドキュメントか技術ブログを読めば設定はなんとかなる。
それでもダメな場合はソースコードを読む必要が出るので覚悟が必要になって来るかも。
切り替えてから丸一日が経過しているが、
メール送受信は勿論のことフィルタリング修正などオプション機能も普通に使えている。
また、やる気を出せばログイン画面をreCAPTCHA対応させたりワンタイムパスワード化も出来るので、
セキュリティ観点でもメリットが十分あると言えそう。
まだまだ使って見る必要はあるが、ひとまずは連休の自由研究その1が無事終了となった。
その2として無線AP載せ替えがあるのでコチラは引き続き着手する予定。
« 続きを隠す
