2025年02月14日(金) - 23:26 | カテゴリ:
Linux
権威DNSにはGSLB(広域負荷分散)と呼ばれる動的なDNSレコードを返す物があり、
“ns-lab BB”でもWebサーバの負荷分散とサーバ切替で用いており数年の運用実績がある。
そんな自鯖のGSLBも機能強化しつつ運用しているが、
フロントエンドがdnsdistを採用してバックエンドにgdnsdを用いた多段構成のため、
GeoIPを用いたロケーション判定と動的応答が出来ない課題があった。
………
そんな折に発生した権威DNSの脆弱性対応でサーバをアップグレードをする必要があり、
ついでにEDNS0の対応もする事となった。
(｀・ω・´)「dnsdistがEDNS0に対応出来るなら、gdnsdも対応すればGeoIPを使えるのでは？」
そう思い立ち調査をしたところgdnsdもEDNS0に対応している事が判明。
ソースコードも読んだらEDNS Client Subnetで接続元のIPアドレスを引き渡せそうだったため、
筆者の運用するgdnsdでもEDNS0への対応とGeoIP動的応答への対応をしてみた。
今回はdnsdistとgdsndの両方をEDNS0に対応させる事で、
EDNS Client Subnetを使ったIPアドレス連携とGeoIPを使ってみた。
構築手順はwikiへ追記したので、ビルド方法やパラメータの詳細はwikiを読むべし。
- nowsky system-lab memo > gdnsd
今回の構成は以下の通り。
EDNS Client Subnetの付与はdnsdistで行い、
パラメータをgdnsdで読み取りGeoIPとの連携と動的なDNS応答をしている。
稼働させて2週間ほど経過するがGeoIPでの動的制御も正常に動いている。
懸念していたCPU負荷やメモリ使用率も正常稼働の範囲となっておりバーストも無かった。
GSLBは使い方によっては特定のネットワークからの接続を禁止する用途にも使えるため、
他のシステムと組み合わせれば攻撃検知と自動防御にも使えると思われる。
この場合、接続元キャッシュDNSサーバのグローバルIPを元に制御すれば行けそうなので、
自鯖で開発出来ないか考えてみようと思う。
………
本職でもDNSを弄っておりスキル習得が重要なため先進的な事は自鯖で実装する様にしてる。
権威DNSの自前運用は出来る限り避ける事が望まれる昨今なので時代に逆行しているものの、
自宅サーバなど自由な環境でないと出来ない事も大量にあるので、
敢えて自前で運用する事をポリシーにしていたりする。
安定が求められるシステムだからこそ深い所まで把握し自由に操作するのが重要なのと、
自由に弄れる環境だからこそ実現出来る事があるのも事実。
だからこそ、自前で運用する権威DNSを使って検証をしていく所存。
« 続きを隠す
2025年02月08日(土) - 21:33 | カテゴリ:
雑談
自宅サーバの権威DNSをテコ入れする機会があり、
サーバ内部の構成変更と配置を最適化する事にした。
今回は普通の権威DNSはBIND 9.20とNSD 4.11へのアップグレードと、
GSLBとフロントエンドでGeoIPに対応させてみた。
また、GSLBでは接続元IPアドレスを元に応答を切り替える機能も使える様にした。
BINDのviewに近い動きをするがGSLBの機能を使っているので、
より自由度の高い動きが出来るようになった。
稼働テストとドキュメントは粗方まとめたが記事にまとめるには時間がかかるので、
少しずつ内容を書き溜めておき、何処かで公開できればと思う。
2025年01月30日(木) - 22:45 | カテゴリ:
雑談
この記事を書いているDigiLoogは勿論、ns-lab BBでもreCAPTCHAを利用している。
そんな中、ちょっち前に話題となったreCAPTCHAのAPI実行制限の本丸と思われる、
Google reCAPTCHAへのサービス移行通知連絡が筆者の元にも届いた。
流石にreCAPTCHAが利用出来なくなるのは避ける必要があり、
WordPressとreCAPTCHAの組み合わせは多用もしているためサービス移行が必須になった
という事で、このままreCAPTCHAを利用しつつ新サービスに移行するか、
別のCAPTCHAサービスへ移行を行うか比較してみた。
reCAPTCHAもAIで突破出来ると言われたりしているが、
普通のスパムやスクリプトキディなどは防げるのも事実だったりする。
実際に筆者が運用する色々なサービスでスパムなどを防いでいる実績もあり役立っている
とは言っても、クエリ試行されたらお財布が破産しちゃうため同等の代替サービスを探してみた。
有名どころだとCloudflare Turnstileが良さそうで、
Google reCAPTCHA同等のセキュリティ対策が簡単に実装出来る模様。
Contact Form 7にも対応しているので妥当な移行先として真っ先に上がると思う。
他には、Google Authenticatorを用いた多要素認証も考えられるが、
仕組み的に登録ユーザが前提となりメール送信フォームやコメント欄などパブリックでの実装が難しく、
reCAPTCHAの代替にはなり切れないのが事実。
管理画面のログインフォームなどアカウントを前提にするなら現時点で考えられるベター案ではあるので、
使い処によっては十分検討の余地は残っている。
また、Google Authenticatorに限らずWordPressの多要素認証プラグインが豊富なため、
簡単に導入出来るメリットもあったりする。
変わり種だと少し前のオンラインバンクで見かけたパズル認証もあったが、
2023年にCVE-2023-44997のCSRF脆弱性が見つかり危険と判断されプラグイン非公開になっていた。
そもそも、パズル認証は多要素認証として脆弱という研究報告も上がっていたり、
画像認識処理のプログラミング登竜門的な所もあるらしく今さらコレを新規実装する事も無いと言える。
………
今回どれを選択するか先行き不透明だが、第一候補はCloudflare Turnstileになりそうだった。
使用感がreCAPTCHA同等なのと実装も他より簡単総なのが候補に挙がった理由の一つとなる。
Google reCAPTCHA完全移行まで時間もありそうなので情報収集を進めながら、
実装難易度の確認と選定を行いセキュリティ強化を図りたいと思う。
« 続きを隠す
