自サーバーに置いたWebフォントを読み込めない時の対処法

Google Fontsなどのサービスとして公開されているのではなく、独自にサーバーに置いたWebフォントをCSSで指定しても反映されない場合の対処方法です。独自ドメインで使っているサーバーとは別にFC2やSeesaaブログなどをやっていて、そちらで自サーバーのWebフォントが読み込めないという場合、クロスドメイン制約でアクセス制限がかかっている事があります。

Google Fontsなどのサービスとして公開されているのではなく、独自にサーバーに置いたWebフォントをCSSで指定しても反映されない場合の対処方法です。

独自ドメインで使っているサーバーとは別にFC2やSeesaaブログなどをやっていて、そちらで自サーバーのWebフォントが読み込めないという場合、クロスドメイン制約でアクセス制限がかかっている事があります。

ていうか、私自身が今使っているバリューサーバーに置いたフォントを、別のサイトで読み込ませて使っていたんですが、気がついたら使えなくなっていました。以前は使えていたんですけど、どこかの段階でバリューサーバーの設定が変わったようです。

その時にやった事のまとめです。

Webフォントが読み込めないドメインのアクセス制限を解除する

先に公開したページ「Google Feed APIを使わずXMLHttpRequestでクロスドメインのRSSを取得する方法まとめ」に書いたんですが、.htaccess に Access-Control-Allow-Origin の設定をするとアクセス制限を解除できます。

.htaccess に次のように書くと全てのドメインからのアクセスが許可されます。

Header append Access-Control-Allow-Origin: *

* はワイルドカードで、この場合は全てのドメインを指します。

全てのドメインにではなく、自分の使っているドメインだけ許可したい時は、そのドメインを指定します。許可したいドメインが http://example.com なら下の通りです。

Header append Access-Control-Allow-Origin: http://example.com

ただし、ドメインを複数指定するには工夫が必要なようです。
参考「Access-Control-Allow-Originヘッダで複数のオリジンドメインを許可する方法 – ぷれすとぶろぐ」

Internet ExplorerだけWebフォントが反映されない時の対処法

上の設定で、Webフォントは読み込まれるようになったんですが、IEだけ反映されませんでした。

そこで調べたら、次のページを発見。Truetype embedding-enabler

このページにあるembed.exeをダウンロードしてコマンドプロンプトで以下のように実行。そのフォントを再アップロードしただけでIEにも反映させることが出来ました。

embed font_name.ttf

私の場合は上のツールで解決したんですが、下のページで他の使いやすいツールとかを詳しく説明してくれています。

IEにも対応したWebフォントの使い方について｜ memocarilog

このページによると、IE以外のブラウザでは拡張子が .ttf のTrueTypeフォントや .otf のOpenTypeフォントが使えるんですが、IEだけは拡張子が .eot のEmbedded Open Typeしか使えないというのが原因のようです。

.htaccess の Allow と Deny 〜アクセスの許可と制限〜

ロリポップのサーバーには不正なログインを試みるアクセスと判断された場合に、自動で制限をかける仕組みがあるそうです。自分自身ではロリポップは借りていないんですが、不正アクセスのためにログインしようとしているとみなされたIPアドレスは自動でアクセス拒否にされる模様。どうやってアクセス拒否にするかというと .htaccess を書き換えて行うようです。それが自動で行われるのですが、なんらかの理由でその .htaccess が正しく書き換えられないとアクセスできなくなります。

ロリポップのサーバーには不正なログインを試みるアクセスと判断された場合に、自動で制限をかける仕組みがあるそうです。

自分自身ではロリポップは借りていないんですが、不正アクセスのためにログインしようとしているとみなされたIPアドレスは自動でアクセス拒否にされる模様。

どうやってアクセス拒否にするかというと .htaccess を書き換えて行うようです。

それが自動で行われるのですが、なんらかの理由でその .htaccess が正しく書き換えられないとアクセスできなくなります。

ただし、一般公開ページを閲覧しようとして403エラー（アクセス拒否）となる場合は、必ずしも.htaccessが原因とは限らないようです。

ロリポップの場合 .htaccess でアクセス制限をかけるのはログインページであって不正アクセス防止のためなので、一般公開ページに制限をかける理由はありません。

先日、ロリポップを借りている方が、管理ページからスタイルシートを編集しようとしたところ、管理画面も一般公開ページもすべて403エラーでアクセスできなくなったそうですが、その時はパーミッションの設定で直ったそうです。

その方はロリポップに問い合わせをしたところ、次の返事が来て設定を修正しました。なぜパーミッションが変更されたのかはわかりませんが、そういうケースもあるようです。

WordPressをインストールされているフォルダのパーミッション（属性）が「770」で設定されておりフォルダ内のデータを呼び出すことができない状態でございました。そのため、サイトが403エラーとなっております。

パーミッションの変更は次のページに説明があります。
サイト改ざんへの対策をお願いいたします – ロリポップ！レンタルサーバー

下の表は上記サイトより引用しました。

HTML・画像ファイル	604	rw—-r–
CGIの実行ファイル	700	rwx——
CGIのデータファイル	600	rw——-
.htaccessファイル	604	rw—-r–
ディレクトリ	705	rwx—r-x

.htaccess によるアクセス制限

.htaccess を見て次の通り書きこまれていたら、それがアクセス制限の記述部分です。

Order deny,allow
Deny  from all
Allow from IPADDRESS

赤字の IPADDRESS の部分は 123.456.789.100 のように４組の数字を .（ドット）で区切って書いてあります。ここに指定されたIPアドレスからのみアクセスが許可され、それ以外は全て拒否されます。

場合によっては Allow from IPADDRESS の行は複数あるかもしれません。その場合、許可されたIPアドレスが複数あるという事です。

Order deny,allow
Deny  from all
Allow from IPADDRESS
Allow from IPADDRESS
Allow from IPADDRESS

そのIPアドレスに自分のアドレスがない場合、アクセスは出来ません。解決するためには、これを自分のIPアドレスに書き換えなければいけません。

でも、自分のIPアドレスがわからない！

自分のIPアドレスがわからなければ、それを指定して書き換えることができません。それでもログインしたい時は、一時的にすべてのIPアドレスからのアクセスを許可する設定をします。

具体的には、次のようにします。

Allow from IPADDRESS の次に Allow from all という行を追記する

Allow from all というのは、全てのIPアドレスを許可するという意味です。Allow from IPADDRESS の行が複数ある場合は、その後に追記します。

修正前

Order deny,allow
Deny  from all
Allow from IPADDRESS

修正後

Order deny,allow
Deny  from all
Allow from IPADDRESS
Allow from all

これで、全てのIPアドレスからのアクセスが許可されます。

ただし、ログインページは誰でもアクセスできると危険なので、どうしても緊急にログインしたい場合を除き、許可したIPアドレス以外はアクセスできないように、自分のアドレスを調べて訂正しておきましょう。

コメントアウト

上の書き方ですべてのアクセスを許可しますが、この書き方は無駄があります。それは、Allow from IPADDRESS の次に Allow from all としているため、最初の IPADDRESS は2回許可されているという事になります。言い方を変えると Allow from all には、上の行の IPADDRESS も含むので、上の行は冗長だという事です。

ですから、上の行 Allow from IPADDRESS は消してしまって構いません。

ただ、消してしまって後から困らないか不安！という場合には、消さずに無効にする方法があります。それには次のように、行の最初に半角で # (シャープ)を書き加えます。これをコメントアウトと言います。

Order deny,allow
Deny  from all
#Allow from IPADDRESS
Allow from all

こうすると # の後は行末まで説明書きという意味になり、設定から無視されます。例えば次の場合、赤字の部分は説明で、消しても設定には影響しません。見た時にわかりやすくなるようにつけているだけです。

# BEGIN Lolipop
<Files ~ "wp-login.php">
Order deny,allow
Deny  from all
Allow from 123.456.789.101
</Files>
# END Lolipop

<Files ~ “wp-login.php”> と </Files> の行は後で説明します。

Order deny,allow と Order allow,deny

先程の .htaccess の設定は次の意味です。

Order deny,allow

Order deny,allow: 順序として、許可しないアドレスを先に指定して、次に許可するアドレスを指定するという断り（宣言）。
Deny from all: すべてのIPアドレスを許可しない。
Allow from 123.456.789.101: IPアドレスが123.456.789.101の場合だけ、アクセスを許可する。

不許可のアドレスを先に決め、その後に例外として許可するアドレスを1行ずつ列挙します。

例えば、この世にあるIPアドレスが次の10個だけだとします。

123.456.789.101
123.456.789.102
123.456.789.103
123.456.789.104
123.456.789.105
123.456.789.106
123.456.789.107
123.456.789.108
123.456.789.109
123.456.789.110

この中で、123.456.789.101だけを許可したい場合は、まず Order deny,allow で指定する順序を宣言します。これは、不許可が先、許可が後という意味です。

その後 Deny from all で全てのIPアドレスを不許可に指定します。この時点ですべてのIPアドレスからのアクセスが遮断されます。

そして Allow from 123.456.789.101 で、IPアドレスが123.456.789.101のものだけ、特別にアクセスを許可します。

では、この書き方でIPアドレスが123.456.789.110以外の9個のアドレスを許可するにはどう書けばいいでしょうか。次のようにすればOKです。

Order deny,allow
Deny  from all
Allow from 123.456.789.101
Allow from 123.456.789.102
Allow from 123.456.789.103
Allow from 123.456.789.104
Allow from 123.456.789.105
Allow from 123.456.789.106
Allow from 123.456.789.107
Allow from 123.456.789.108
Allow from 123.456.789.109

これで、指定していない123.456.789.110は許可されないので残りの9つのアドレスからはアクセスできます。

IPアドレスがこの世に10個しかない場合は簡単です。では1万個のIPアドレスから9999個を許可して1個だけ拒否するにはどうすればいいでしょう。Allow from IPADDRESS を9999行書けばいいだけなので簡単です。でも、ふざけるなです。

そんな場合は、指定する順序を逆にします。

Order allow,deny

Order allow,deny: 順序として、許可するアドレスを先に指定して、次に許可しないアドレスを指定するという断り（宣言）。
Allow from all: すべてのIPアドレスを許可する。
Deny from 123.456.789.101: IPアドレスが123.456.789.110の場合だけ、アクセスを許可しない。

許可するアドレスを先に決め、その後に例外として許可しないアドレスを1行ずつ列挙します。

123.456.789.110以外のアドレスを許可するには次のように書けます。

Order allow,deny
Allow from all
Deny  from 123.456.789.110

この世に存在するIPアドレスが10個しかないのなら、次のどちらでも同じ意味になります。

Order deny,allow
Deny  from all
Allow from 123.456.789.101
Allow from 123.456.789.102
Allow from 123.456.789.103
Allow from 123.456.789.104
Allow from 123.456.789.105
Allow from 123.456.789.106
Allow from 123.456.789.107
Allow from 123.456.789.108
Allow from 123.456.789.109

Order allow,deny
Allow from all
Deny  from 123.456.789.110

指定のページだけアクセス制限をかける方法

ここまでで、IPアドレスを制限する設定は出来ました。ただ、このままだとサイトの全てのページが同じように制限されてしまいます。

一般公開しているページは、誰でも見て構わない。ただ、ログインページだけには制限をかけたい。そういう場合は、次のようにアクセス制限の設定を <Files ~ “FILENAME”> と </Files> で囲みます。

WordPressのログインページ wp-login.php だけ、制限したい場合は、wp-login.php のあるディレクトリで .htaccess に次のように記述します。

<Files ~ "wp-login.php">
Order deny,allow
Deny  from all
Allow from 123.456.789.100
</Files>

こうすると <Files ~ “wp-login.php“> から </Files> までは、wp-login.php のみに適用されます。

参考までに .htaccess に誰もアクセスできないようにするには下のように書きます。これは . (ドット)で始まるファイルには全てのアクセスを拒否するという意味です。

<Files ~ "^\.">
deny from all
</Files>

クラッキング（ハッキング）被害を受けたサイト管理者がとるべき２つの重要な対策

生まれて初めてクラック（ハッキング）された。今回クラックされたのは自分が借りているバリューサーバー。今のところやられたのはその中の１台のみらしく、幸いにして閲覧者に被害を及ぼす心配はなかった。今現在は大丈夫でも、今後危険になる可能性が「ある」。その可能性が、侵入されたサーバーにファイルとして「残っている」という事実だ。では、どうしたらよいのか。今後同じような被害を受けた人のために、今回の対処方法を書き残しておきます。

お詫び：
2014年1月19日17時頃から23時すぎまで、当サイトはクラッキング（ハッキング）被害を受けました。閲覧画面に下のような表示がなされましたが、閲覧された方に被害が及ぶ心配はありません。ご迷惑をおかけして申し訳ございません。詳細は以下の記事をご覧ください。

追記 2014年1月20日21:01
本日夕方17時過ぎから先ほど20時すぎまで、またクラックされましたが、今回は明確に原因を特定できているようです。

VALUE-DOMAIN.comのユーザーフォーラム s1.valueserver.jpへのクラッキングについてより

特定の管理ユーザー以外昇格できないようにする設定ファイルに、とあるユーザー様が追加され、そのユーザー様領域内での不正なプログラムがおかれておりました。

当サイトを閲覧いただいた皆様には重ねがさね失礼いたしました。以下、本文です。

生まれて初めてクラック（ハッキング）された。まあ、共有サーバーである以上誰かがミスれば全体に影響するというのはある。今回クラックされたのは自分が借りているバリューサーバー（VALUE SERVER – valueserver.jp）。

今のところやられたのはその中の１台、s1.valueserver.jpのみらしく、幸いにして閲覧者に被害を及ぼす心配はなかった模様。今回、この記事を書いているテーマはここで、閲覧者に被害を及ぼす心配は「なかった」のであって、今現在は大丈夫でも、今後危険になる可能性が「ある」ということ。その可能性が、侵入されたサーバーにファイルとして「残っている」という事実だ。

詳しく説明するために、まず起こった状況から。

実際に受けたクラッキングの詳細

自分が気づいたのは23時過ぎだったんだけど、実際には17時頃に最初のクラッキングがあったらしい。最初というのは、その後再びファイルが書き換えられるアタックがあったから。最低でも２回侵入されている。

VALUE-DOMAIN.comのユーザーフォーラム s1.valueserver.jpへのクラッキングについてより

2014/01/19(Sun) 18:58
今日の17時ごろs1サーバー内のファイル(ファイル名に”index”が含まれるもの)が別の内容に書き換えられたようです（添付画像参照）。

2014/01/19(Sun) 22:42
先ほど修正したはずなのですが、22:26 にまた index.html が
別のファイルに書き換えられました。(一部のディレクトリのみ)
もうどうにでもなれって感じです。

1回目の攻撃で黒地の画面に”Hacked by Jacko Nexus”と表示されるようになり、２回目の攻撃で画像が兵士のものに変更され、音も鳴るようになった。自分が実際に見ているのは音の出る方の画面。

クラッキング（ハッキング）の原因

正確な原因は攻撃した側と、被害を受けたサーバー管理者しかわからないので、バリューサーバーの発表を待つ必要がある。もちろん待っても本当の原因を発表するとは限らないけど。ただ、フォーラムの情報を見るとポートに穴が開いていたらしい。

VALUE-DOMAIN.comのユーザーフォーラム s1.valueserver.jpへのクラッキングについてより

2014/01/20(Mon) 01:00
はてなブックマーク ( http://b.hatena.ne.jp/entry/kumalog.com/2014/01/19201213.php ) で以下のような指摘がありました。
—————
s1.valueserver.jpの31337ポート（トロイの木馬に感染したときの
Back Officeポート。通称「エリート」ポート）が空いているね。
—————
確認したところ現在も開いたままなので、まだ色々まずいかも知れません。

2014/01/20(Mon) 05:27
こんばんは。
はてなブックマークで31337ポートが空いてるよって書いた者です。
HTTP復旧したようですね。もう31337ポートは空いていません。
おそらくセキュリティパッチを当ててサーバーを再起動したか、
新しい筐体にユーザーのデータを移して起動させたのかと思います。

私はここのサーバーを使っていないので、NULLさんが指摘された
PHPのバックドアのファイルが残っていないか気になるところですが、
これでしばらくは大丈夫かなと思います。

#しかし未だ開ける必要のないポートが沢山開いている…。
iptablesでファイアウォール設定とかやってないのでしょうね…。
OSやミドルウェアの更新とかも定期的にやらずに放置だったのでしょうね…。

クラッカーは、おそらく開いているポートから侵入したのでしょう。

追記：[2014/01/20 21:30] 原因が公式発表されました

あるユーザーにて、WordPressの脆弱性をつき、不正なプログラムが設置された
そのプログラムからシステムの脆弱性つかれ、インデックスページを書き換えるプログラムを実行された
インデックスページを設置されているサイトにおいて、id.htm、in.php、index.php、index.htm、index.html　の内容が変わり、動作しなくなった

被害を拡大しないためにするべきこと

バリューサーバーの対応が出来たので多分、今すぐ再侵入される可能性は低いと思う。しかしまだ問題が残っている。それはクラッカーによって書きこまれたPHPのバックドアファイルだ。これが残っている以上、いつでもクラッカーは攻撃を仕掛けられる。どういうことかというと、実はフォーラムにこのように書きこまれている。

VALUE-DOMAIN.comのユーザーフォーラム s1.valueserver.jpへのクラッキングについてより

2014/01/20(Mon) 01:27
Tomさんの
＞~/inphpの内容
＞http://dwm.me/download/in.txt
がかなり興味深いですね。

デコードすると分かるのですが、バックドアとして機能するようです。
これは早急に対策しないとマズイです。
いつ悪意のあるページに書き換えられてもおかしくありません。

追記：http://dwm.me/download/in.txt
このファイルですが削除されたみたいです。
アップしたのは私なんですが、消したのはおそらく管理サイドだと思うので再アップはしません。
ソースは公にしないほうがいいとも思うので。

そのバックドアとは何なのか。

IT用語辞典より

バックドア【 backdoor 】

クラッカーにより侵入を受けたサーバに設けられた、不正侵入を行うための「裏口」。

クラッカーはコンピュータへの侵入に成功すると、次回も侵入できるように、管理者に気づかれないようこっそりと侵入経路を確保する。これがバックドアである。

簡単に言えば、今は「ターミネーター２」でシュワちゃんが溶鉱炉に入ることになった時のような状況。ファイルがある以上、それを消し去らないとまた敵が攻撃してくる。

では、どうしたらいいのか。自分は対策には２種類あると思っている。それは具体的な対策と潜在的な対策だ。具体的な対策を書く前に、潜在的な対策を書いておきたい。

発信者の責任

もしも推測の通りポートの穴が原因なら、それはバリューサーバーの管理責任といえる。しかし、そのサーバーを使ってサイトを公開している以上、忘れてはいけないことがある。自分たちは、あくまで発信者なのだ。サイトを訪れた閲覧者に不利益をもたらすことをしたのなら自分にも責任が生じる。

これは今月本当にあった話だけど、テレビ番組でダンサーがFUCKと書かれた衣装を着て踊ったとする。しかも子供向けの番組で。これはダンサーだけの責任だろうか？放送局にも責任はあるのではないか？いや、むしろ局側の責任のほうが大きいのじゃないか。

そしてブログというのは例え小さかろうがメディアであるということ。メディアである以上、テレビと同じ立場だ。配信する側には責任がある。バックドアからウィルス的なものを仕込まれ閲覧者に感染したら、そのサイトにも責任が生じる。

参考：社員にTOEIC受験を義務づけるのは楽天やUNIQLOより放送局にお願いします | More Access! More Fun!

被害を受けるのはサーバーのユーザーだけとは限らない。自分のサイトを開いた人が何かを仕込まれるかもしれない。もしそうなった時、責任はそのサイトにもある。それが情報を発信する側の責任だ。

昨年あった「あし@」の詐欺広告

昨年、あし@のサーバーが乗っ取られ、パーツを貼っているブログに強制的に詐欺広告が表示されるという事件があった。

「あしあっと事務局」がユーザーに送ったメールより

この度、2013年9月20日に、あし＠の広告を配信しているアドサーバーの広告管理アカウントの一つに部外者からの侵入があり、広告の内容の一部に改変が加えられた事で、あし＠の広告が表示されると、予期せぬポップアップ広告が表示されいるという現象が発生しておりました。
ご迷惑をおかけ致しましたブロガー様、読者様には深くお詫び申し上げます。

この時、気になったことがある。「あし@」が設置された状態で放置された、更新していないブログの多くが管理者の気づくことなく「詐欺広告」を表示し続けていたという事実。そして、それに引っかかり詐欺ソフトを買ってしまった人物もひとり知っている。

もちろん一番悪いのはクラッカー（ハッカー）だ。そして、それを防げなかった「あし@」にも責任はあるだろう。それが原因かどうか知らないが「あし@」は今月いっぱいでサービスを停止する。

では、この広告を配信してしまった「ブログ」には責任がないのだろうか？自分は「ある」と思っている。ましてや、更新せず放置したまま気づかなかったブログ管理者の責任は大きいと思う。

クラッカーの攻撃を受けたサーバーにとって、侵入を許してしまうのはある意味やむを得ない部分もあって、防げなかったことを強くは攻めるつもりはない。同じように、ブログで使っていたパーツが知らないうちに詐欺広告を表示していたとしても、ある意味やむを得ない。というか貼っている以上防ぎようがない。

問題はいかに早く気がつくかだ。そして気がついたらいかに早く対処するかだ。２次攻撃を受けるまで気がつかなかった自分が言えることではないが、サイト管理者は責任を持って対処しないといけない。

共有サーバーには自分以外のサイトもある

そして、共有サーバーを使っている以上、自分がバックドアを仕込まれたら他の全員に迷惑をかけることになる。今回の責任がバリューサーバーだとしてもバックドアを削除せずに残したままにしておいたのなら、次の被害を受けた時の責任はそのサイトにもある。それが共有サーバーなら他の全員に被害が出る。

実際、昨年「ロリポップ」が乗っ取られた時の状況は、たったのひとりから発生した可能性もある。

【緊急警報!!】ロリポップとGMOのinterQのWordPressが軒並み乗っ取られてます | More Access! More Fun!

サーバクラックではないとすると、1人のアカウントに侵入し、同じサーバ上のWordPressをすべて乗っ取ったというのが一番考えられるのではないかと。共有サーバでWordPressを使う危険性がまざまざと浮き彫りになったわけです。

具体的な対策

では、どうしたらよいのか。バリューサーバーのユーザーは、おそらく自分で対処できるベテラン揃いだと思う。けど、今後同じような被害を受けた人のために、今回の対処方法を書き残しておきます。

トップディレクトリに５つのファイルが書きこまれているので全て削除。

id.htm
in.php
index.php
index.htm
index.html

このうちの少なくともどれかひとつは、元からあったファイルの名前ですが、改ざんされています。削除して作りなおしてください。特に重要なのが「in.php」で、これが問題のバックファイルです。

5つのファイルが書きこまれているのはトップディレクトリだけですが、その他のディレクトリにindex.* (index.で始まるファイル)がある場合、すべて確認、訂正します。

静的なHTMLだけなら、これで完了と思われます。

WordPressの場合

WordPressの場合も、トップディレクトリのindex.phpを書きなおすだけでサイトは表示されるようになります。しかし、トップディレクトリの修正だけでは管理画面にログインできません。wp-admin/index.phpも書き換えられています。

WordPress3.8の初期状態のindex.phpは以下のとおりですが、すべて改ざんされていました。

wordpress $ find . -name index.* -print
./wp-content/index.php
./wp-content/themes/twentyfourteen/index.php
./wp-content/themes/index.php
./wp-content/themes/twentytwelve/index.php
./wp-content/themes/twentythirteen/index.php
./wp-content/plugins/index.php
./wp-content/plugins/akismet/index.php
./wp-admin/user/index.php
./wp-admin/index.php
./wp-admin/network/index.php
./index.php

バックアップがない場合、英語版の wordpress.org または日本語版の ja.wordpress.org のどちらかから.zipファイルをダウンロードして解凍。中にあるindex.phpをそのまま再設置します。英語版も日本語版も index.php は同じなので日本語版でなくても大丈夫です。

インストールしているテーマやプラグインの中にもindex.*があるのですべて修正します。

WordPressを専用ディレクトリにインストールしている場合、トップディレクトリのindex.phpの中身は1行だけ違います。それについてはWordPress Codexの「WordPress を専用ディレクトリに配置する」を参照してください。

今回の攻撃ではDB（データベース）の改ざんは、確認されていません。

FC2ブログのコメント欄にメアドを入れると読めてしまいます

WordPressなどのコメント欄はメールアドレスを入れてもそのブログの管理者にしかわかりません。しかしFC2ブログの場合はメアドを入れるとリンクとして表示されてしまいます。

FC2ブログのヘルプにも書いてあるんですが、気がつきにくいので書いておきます。

FC2ヘルプ | FC2ブログ | コメント機能についてより

公開コメント場合、入力した内容はすべてブログ上に表示されますので、メールアドレスなどを記載する場合は十分にご配慮ください。

FC2ブログでコメントする時、下のようにメールアドレスを入力すると投稿後のコメントにある名前にメールアドレスがリンクされます。

FC2ブログのコメントフォーム

名前の上にマウスを合わせると、ブラウザの左下にmailto:・・・とメールアドレスが表示されてしまいますし、そのリンクをクリックすればメール送信ソフトが立ち上がり、宛先にはコメント欄に記入したメールアドレスが入力されています。

名前にメールアドレスがリンクされている

非公開の「秘密」コメントにすれば、管理者にしか読めないコメントになるので、メアドを伝えたい場合は、それを使うのが無難だと思います。

「Google Public DNS」でプロバイダーのDNS障害に対処

OCNで通信障害 – 22時49分から断続的に通信しづらい状態

2013年8月23日発生

マイナビニュース 8月24日(土)0時5分配信より

NTTコミュニケーションは8月23日、同社が提供するインターネット接続サービス「OCN」で設備故障により通信障害が発生していることを発表した。発生日時は8月23日22時49分頃で、現在も断続的に通信しづらい状態になっているという。設備の故障による障害で、詳細は発表していない。

Googleの無料DNSサーバー「Google Public DNS」

うちもプロバイダーにOCNを使っていますが、確かに昨夜23:00頃から突然インターネットにアクセス出来なくなりました。ワイヤレスLANのアクセスポイントへはつながっていているのにインターネットのサイトは開けません。

そこで、アクセスポイントのDNS設定を切り替え「Google Public DNS」を使うようにしたら、接続可能になりました。今も、その状態で記事を書いています。

DNS(ネームサーバー) プライマリの接続先を「8.8.8.8」へ
DNS(ネームサーバー) セカンダリの接続先を「8.8.4.4」へ

これでOCNのDNSが壊れていても、Googleの無料DNSを使ってインターネットが出来ます。

昨夜23時53分にOCNへ電話して留守番電話に問い合わせたら、01時48分にOCNから返事の電話がかかってきて、トラブルが発生していると言われました。さすがにもう直っているかと思ったらまだみたいです。（2013年8月24日 10:30am）

余談ですが、OCNの故障サポートは夜中にかけると留守電になっていますが、メッセージを残すと、しばらくして向こうから、かけてきます。実は、自分がOCNに入会してからのトラブルはこれが初めてではなく、前回、夜中に電話しても数時間で返事が来ることを知りました。ただし、その時はトラブルが起きていることを認めつつも、朝になるまで修理に取りかかれないとの回答でした。