アカウント名:
パスワード:
WordPressは初期インストール状態だと脆弱でインストール後に設定を変更する手順が必要ってこと？だとしたらそこを改善すべきような
・WordPressを設定するためには、公開URLを確定する必要がある(virtualHostなどで複数のURLからアクセス可能な状況でも、設定と違うURLからアクセスすると怒られる。httpとhttpsも区別される)ので、httpsで公開するサイトを作るためには、WordPressを設定する前に、証明書の設定が必要
・WordPressの初期状態でアクセスすると「DB設定やパスワード登録などを行う初期設定画面」が出るので、その段階でアクセスできれば誰にでも好き勝手できる(推測ですが、攻撃者は、パスワード登録して利用開始→不正ファイルアップロード→設定クリアして初期状態に戻す、という対応をしてるんじゃないでしょうか)
という鶏と卵状態ですね。設定の簡便さのために「インストール後の最初のアクセスでパスワードを登録する」のは、WordPressに限らずよく見かける初期状態ですが、従来は、そんな状態のURLが外部に漏れることもないし攻撃されることないだろう、と高をくくっていたのがCTにより、その段階のサイトを素早く見つけることができてしまう、と…
対策としては、案1・まずオレオレ証明書を入れ、WordPressの設定を済ませてから、Let's Encryptの証明書取得に切り替える案2・http設定でWordPressの設定を済ませてから、Let's Encryptの証明書取得し、https設定に切り替える(tweetにドメインの変更はトラブルの元とありますが、同名ドメインでのhttp→https移行は支援プラグインなどがあり、まず問題は起きません)とかですかね。
一番手っ取り早いのはApache/nginxへの登録時に一緒にBASIC認証を入れるとかじゃないかな
# WordPressユーザがそんなことできるのかは知らん
いや何らかのアクセス制限を行うとLet's EncryptのHTTP-01認証のアクセスも通らなくなるので、証明書を取れなくなってしまうというのっがミソ
/.well-known/acme-challenge/ だけオープンしとけば通るのでは
WordPressは何かと狙われやすいので割と初期から管理系があるwp-adminにはBASIC認証とIP制限かけてDBのID/Passとかが書かれているwp-config.phpは初期設定のディレクトリの親ディレクトリに入れるってのは、結構前からWordPressの入門系サイトにもよく書かれている内容ですので理解せずとも猿真似で出来るユーザーはいるかと・・・
※その程度を理解できないユーザーがサーバを公開することについては別な問題と言うことで
なにはともあれ、まずWebサーバーへアクセスできるマシンやIPアドレスを限定すべきでしょう。その後の設定とか準備したあとに公開していい状態になるわけで、初期状態で最初から全世界に公開しておくっておかしすぎて理解できない。ひょっとしてWeb界隈では手順として普通なのか？
Let's Encryptのドメイン所有者確認(HTTPチャレンジ)では、Let's Encrypt側から指示されたファイルをWebサーバに置く必要があるので、IPアドレス制限なりBASIC認証なりをかける場合は、そのファイル置き場所は誰でもアクセス可能にする、という一手間が発生します。
DNSチャレンジならWebサーバ非公開でも問題ありませんが、HTTPチャレンジよりもはるかに設定が面倒。
まあ、結局のところ、問題の起きない正しい方法はありますが、それなりに手間が入り組んでるので、初心者でも簡単に設定できるとサイト管理の心得がない人が手を出して穴を開けてる、ってことでしょうね。
オレオレ証明書ってクライアント側の判断用でクライアント側がＯＫならアクセスできるのでは？クライアント側を制限するときは、オレオレ個人証明書でないの？
オレオレ証明書ならCT公開ログに記録されることが無いので、CT公開ログを監視しているだけの攻撃者には気付かれることが無い、というだけのことでしょ
もちろん理想的には Wordpress の設定完了まではアクセス可能なクライアントを制限するべきだけど、CT公開ログから検知されるのを防ぐだけならこの方法でできる。
PHPが使えるVPSとかにうｐして直叩きするんです。ページが読み込まれると初期設定が始まります。事前にパスワードをファイルに書いて含めておくとかDBをいじって書き込むとか、VPSにVPNで繋ぐような気の利いたことは中々できません。
危なくないのかって? ……。
VPSでも認証ぐらいかけられるでしょ
初期パスワードでログインされちゃうとかかねぇ。だとすると、WordPress側での改善はしづらい部分かも。
初期パスワードをインストーラーでランダムに発生させてもダメ？
ランダムに生成したパスワードをサイト管理者のみに伝える汎用的な方法がない
WordPress インストール、で検索して最初にヒットしたページからたらい回されて辿り着いたWordPress のインストール [wordpress.org]を流し読みすると、パスワードの設定の前にブラウザからアクセスしてインストールスクリプトを実行、なる手順が出てくるね…。
初心者でも簡単にセットアップ出来るように作ったあまり、初心者には危険すぎる手順になっちゃったのかな。
1. ドメイン名を準備2. 外部からアクセス可能な空っぽのWebサーバを立ち上げてlet's encrypt3. Webサーバに証明書をきっちり設定する4. Webサーバの外部からのアクセスを禁止に5. WordPressのスクリプトを展開6. ローカルから繋げてブラウザでWordPressのインストールスクリプトを実行7. 十分に安全な設定にしてから、再び外部からのアクセスを許可
という手順が要る。最初のツイートとかを見ると、WordPressはURL設定に敏感なので、セットアップ後にURLを変えるのは面倒くさいらしいので。だとすると、6でsshのポートフォワードなりを使いたくなるけど、ちょっと面倒くさそうかな。プロクシをフォワードするのが楽かな。
あと、いずれにせよ潜在的に危険な手順だけど、WordPressを展開→let's encrypt→WordPressの初期セットアップよりは、let's encrypt→WordPressを展開→WordPressの初期セットアップの方が短時間とは言えバレるまでにラグがあるし危険な状態の時間が短い分だけかなりマシかな? と思ったけど、そんな事はないか。攻撃者側は、登録されたのを見かけた時点で、次はWordPressが展開されるかも知れない、と鬼のようにアクセスを繰り返し始めたら良いだけなので。
サーバー証明書を入手できた時点で、アクセス可能なIPアドレスを制限するとか。共用サーバーとかVPSとかだとIPアドレス制限ができなかったり知識が必要だったりするけど、AWSやAzureだったら、あんまり知識無くてもできるし。
> サーバー証明書を入手できた時点
がCTでほぼ即座に突き止められてしまうから間に合わないわけで
上の手順では、その時点ではまだ WordPress 入ってないでしょ
というか、 #4251956 の手順が前提なら #4252048 が言ってるのはまんま 手順4. のことでは
AWSならALBにACMの証明書入れればいいじゃない？# Azureは知らん
初期状態のまま公開するなよって話じゃないの？知らんけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
よくわからん (スコア:0)
WordPressは初期インストール状態だと脆弱でインストール後に設定を変更する手順が必要ってこと？
だとしたらそこを改善すべきような
Re:よくわからん (スコア:5, 参考になる)
・WordPressを設定するためには、公開URLを確定する必要がある(virtualHostなどで複数のURLからアクセス可能な状況でも、設定と違うURLからアクセスすると怒られる。httpとhttpsも区別される)ので、httpsで公開するサイトを作るためには、WordPressを設定する前に、証明書の設定が必要
・WordPressの初期状態でアクセスすると「DB設定やパスワード登録などを行う初期設定画面」が出るので、その段階でアクセスできれば誰にでも好き勝手できる(推測ですが、攻撃者は、パスワード登録して利用開始→不正ファイルアップロード→設定クリアして初期状態に戻す、という対応をしてるんじゃないでしょうか)
という鶏と卵状態ですね。
設定の簡便さのために「インストール後の最初のアクセスでパスワードを登録する」のは、WordPressに限らずよく見かける初期状態ですが、
従来は、そんな状態のURLが外部に漏れることもないし攻撃されることないだろう、と高をくくっていたのが
CTにより、その段階のサイトを素早く見つけることができてしまう、と…
対策としては、
案1・まずオレオレ証明書を入れ、WordPressの設定を済ませてから、Let's Encryptの証明書取得に切り替える
案2・http設定でWordPressの設定を済ませてから、Let's Encryptの証明書取得し、https設定に切り替える(tweetにドメインの変更はトラブルの元とありますが、同名ドメインでのhttp→https移行は支援プラグインなどがあり、まず問題は起きません)
とかですかね。
Re: (スコア:0)
一番手っ取り早いのはApache/nginxへの登録時に一緒にBASIC認証を入れるとかじゃないかな
# WordPressユーザがそんなことできるのかは知らん
Re:よくわからん (スコア:1)
いや何らかのアクセス制限を行うとLet's EncryptのHTTP-01認証のアクセスも通らなくなるので、証明書を取れなくなってしまうというのっがミソ
Re: (スコア:0)
/.well-known/acme-challenge/ だけオープンしとけば通るのでは
Re: (スコア:0)
WordPressは何かと狙われやすいので割と初期から管理系があるwp-adminにはBASIC認証とIP制限かけて
DBのID/Passとかが書かれているwp-config.phpは初期設定のディレクトリの親ディレクトリに入れるってのは、結構前からWordPressの入門系サイトにもよく書かれている内容ですので
理解せずとも猿真似で出来るユーザーはいるかと・・・
※その程度を理解できないユーザーがサーバを公開することについては別な問題と言うことで
Re: (スコア:0)
なにはともあれ、まずWebサーバーへアクセスできるマシンやIPアドレスを限定すべきでしょう。
その後の設定とか準備したあとに公開していい状態になるわけで、初期状態で最初から全世界に公開しておくっておかしすぎて理解できない。
ひょっとしてWeb界隈では手順として普通なのか？
Re:よくわからん (スコア:2)
Let's Encryptのドメイン所有者確認(HTTPチャレンジ)では、
Let's Encrypt側から指示されたファイルをWebサーバに置く必要があるので、
IPアドレス制限なりBASIC認証なりをかける場合は、
そのファイル置き場所は誰でもアクセス可能にする、という一手間が発生します。
DNSチャレンジならWebサーバ非公開でも問題ありませんが、HTTPチャレンジよりもはるかに設定が面倒。
まあ、結局のところ、問題の起きない正しい方法はありますが、それなりに手間が入り組んでるので、
初心者でも簡単に設定できるとサイト管理の心得がない人が手を出して
穴を開けてる、ってことでしょうね。
Re: (スコア:0)
オレオレ証明書ってクライアント側の判断用でクライアント側がＯＫならアクセスできるのでは？
クライアント側を制限するときは、オレオレ個人証明書でないの？
Re: (スコア:0)
オレオレ証明書ならCT公開ログに記録されることが無いので、CT公開ログを監視しているだけの攻撃者には気付かれることが無い、というだけのことでしょ
もちろん理想的には Wordpress の設定完了まではアクセス可能なクライアントを制限するべきだけど、CT公開ログから検知されるのを防ぐだけならこの方法でできる。
Re:よくわからん (スコア:2)
PHPが使えるVPSとかにうｐして直叩きするんです。ページが読み込まれると初期設定が始まります。事前にパスワードをファイルに書いて含めておくとかDBをいじって書き込むとか、VPSにVPNで繋ぐような気の利いたことは中々できません。
危なくないのかって? ……。
Re: (スコア:0)
VPSでも認証ぐらいかけられるでしょ
Re:よくわからん (スコア:2)
初期パスワードでログインされちゃうとかかねぇ。だとすると、WordPress側での改善はしづらい部分かも。
svn-init() {
svnadmin create .svnrepo
svn checkout file://$PWD/.svnrepo .
}
Re: (スコア:0)
初期パスワードをインストーラーでランダムに発生させてもダメ？
Re: (スコア:0)
ランダムに生成したパスワードをサイト管理者のみに伝える汎用的な方法がない
Re:よくわからん (スコア:1)
WordPress インストール、で検索して最初にヒットしたページからたらい回されて辿り着いたWordPress のインストール [wordpress.org]を流し読みすると、
パスワードの設定の前にブラウザからアクセスしてインストールスクリプトを実行、なる手順が出てくるね…。
初心者でも簡単にセットアップ出来るように作ったあまり、初心者には危険すぎる手順になっちゃったのかな。
1. ドメイン名を準備
2. 外部からアクセス可能な空っぽのWebサーバを立ち上げてlet's encrypt
3. Webサーバに証明書をきっちり設定する
4. Webサーバの外部からのアクセスを禁止に
5. WordPressのスクリプトを展開
6. ローカルから繋げてブラウザでWordPressのインストールスクリプトを実行
7. 十分に安全な設定にしてから、再び外部からのアクセスを許可
という手順が要る。
最初のツイートとかを見ると、WordPressはURL設定に敏感なので、セットアップ後にURLを変えるのは面倒くさいらしいので。
だとすると、6でsshのポートフォワードなりを使いたくなるけど、ちょっと面倒くさそうかな。
プロクシをフォワードするのが楽かな。
あと、いずれにせよ潜在的に危険な手順だけど、
WordPressを展開→let's encrypt→WordPressの初期セットアップ
よりは、
let's encrypt→WordPressを展開→WordPressの初期セットアップ
の方が短時間とは言えバレるまでにラグがあるし危険な状態の時間が短い分だけかなりマシかな? と思ったけど、そんな事はないか。
攻撃者側は、登録されたのを見かけた時点で、次はWordPressが展開されるかも知れない、と鬼のようにアクセスを繰り返し始めたら良いだけなので。
Re: (スコア:0)
サーバー証明書を入手できた時点で、アクセス可能なIPアドレスを制限するとか。
共用サーバーとかVPSとかだとIPアドレス制限ができなかったり知識が必要だったりするけど、
AWSやAzureだったら、あんまり知識無くてもできるし。
Re: (スコア:0)
> サーバー証明書を入手できた時点
がCTでほぼ即座に突き止められてしまうから間に合わないわけで
Re: (スコア:0)
上の手順では、その時点ではまだ WordPress 入ってないでしょ
Re: (スコア:0)
というか、 #4251956 の手順が前提なら #4252048 が言ってるのはまんま 手順4. のことでは
Re: (スコア:0)
AWSならALBにACMの証明書入れればいいじゃない？
# Azureは知らん
Re: (スコア:0)
初期状態のまま公開するなよって話じゃないの？
知らんけど。