2016年07月14日

「コンボボックス上でマウスホイール操作抑止」正式公開延期について

現在β版として公開している「コンボボックス上でマウスホイール操作抑止」につきまして、昨日正式公開を予定しておりましたが、予定外の作業が入った都合で中止となりました。

Twitterの方では書いておりますが、さくらインターネットのレンタルサーバのご担当者殿から、ウイルスに感染したファイルがサーバに置かれていると連絡があり、サーバ上に置いてあるファイルの全件スキャンを指示されたため、その対応に追われておりました。

しかしながら、感染していると言われているファイルについては複数のウイルス対策ソフト(ウイルスバスターを含む)を使って調べても、ウイルス感染している様子はなく、誤検知であったことがわかっています。

現在、圧縮ファイル類以外についても全件ダウンロード中で、この後スキャンの予定ですが、それらがウイルス感染している可能性は非常に低く、完全な無駄骨になることは間違いありません。

以前から申し上げているとおり、ユーザーや仲介業者からのウイルス感染報告(誤検知報告)は固く禁じておりますが、さすがにサーバ運営業者自身からの報告は想定しておりませんでしたし、無碍にすることもできません。

しかしながら、サーバ運営業者の社員としても、外部業者からの指摘を無碍にすることはできないために私に連絡してきたのであり、サーバ運営業者の社員もまた、本件の冤罪被害者であると言えましょう。

誤検知としては、2012年から足かけ3年に渡って不具合(内部不整合)のにより高頻度連続誤検知を起こし続けたトレンドマイクロ社のウイルスバスターの件を思い出します。さらに、それにより生じた誤解を解くのに2年以上の月日を費やしていることを考えると、もう4年になります。誤検知がいかにつらい事柄か、誤検知業者は分かっているでしょうか。

指摘をしたという外部業者については、作業停滞犯罪者(社)として、後々実名公表するなどのペナルティを科すことも検討しています。
なお、さくらインターネットの社員については、同じく被害者として、情報共有をしたいと思っています。

こんな感じで誤検知冤罪被害が結構あるのかとか、それによる機会損失や作業停滞被害などがどれくらいあるのか、レンタルサーバー運営会社として冤罪被害対策をしているかとかの情報共有。同じ被害者同士という立ち位置で。

ともかく今回は、作業妨害による正式公開の中止(延期)という実害が出ましたので、「誤検知でしたテヘペロ♪」みたいなことでは済ませないつもりです。

posted by ayacy at 00:00 | Comment(0) | TrackBack(0) | サーバ運用

2016年06月12日

存在しないファイルへの大量のアクセスログの謎

サーバのエラーログを見ていて、結構な頻度で見つかる謎のアクセスがあります。ファイルが存在する1つ上のディレクトリで、同名のファイルにアクセスしようとしてエラーになっているというもの。あれってなんなんだろう。

anzo_logs.png

例えば、www/pic/a.jpgが存在するとしたら、www/a.jpgにアクセスしてみて404エラーになるというログが残されています。こんなようなエラーが、そのディレクトリで公開しているファイルの数分だけあります。しかも、そのアクセスは非常に短い間隔で行われています。

アクセス間隔からして、おそらく人間の仕業ではなく、botみたいな自動プログラムの仕業だろうと思います。なんらかの脆弱性検査をしていて、もしそれでなんらかの脆弱性が見つかろうものなら、そこから何かしらの攻撃が行われるのでしょう。

ところで、1つ上のディレクトリで同名のファイルが見つかると、それでどんな脆弱性が露見するのか、それについてはちょっと、気になるところではあります。
あるいは、どんな脆弱性があると、そんなことが起きうるのか。

でないと、ただの薄気味悪いアクセスってままになってしまいます。
どんな意図のある攻撃なのかくらいは知っておきたいですね。

誰か、この謎をご存知ではないでしょうか?

今度、1つ上のディレクトリにも全部同じ名前のファイルを置いておいて、その後にどんなアタックが来るのか、待ち構えて見てみようかな。


posted by ayacy at 08:27 | Comment(2) | TrackBack(0) | サーバ運用

2015年10月15日

サーバで使われているPHPのバージョンを思い切って最新まで上げてみた(5.4⇒5.6)

今夜は訳あって早々に帰宅できたため、思い切ってPHPのバージョンを最新まで上げてみました。
PHP 5.4からPHP 5.6.11へ。

なぜ今日の今日まで躊躇っていたのかというと、default_charsetがUTF-8になってしまうため、様々なPHPの関数の動きがUTF-8を前提としたものに変わってしまう他、レスポンスヘッダに

Content-Type: text/html; charset=UTF-8

が付いてしまいます。
これが付いていると、HTMLのヘッダに

<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">

が入っていても、ブラウザはUTF-8として解釈しようとして、文字化けが発生します。

当サイトでは、比較的最近作り始めたページについてはUTF-8で書かれていますが、歴史的な都合上、トップページを始めとしてShift-JISで書かれたページが数多く存在しており、そういったページが全て文字化けします。

さらに、さくらのレンタルサーバ上で、拡張子htmlのファイルをPHPに解釈させるためのテクニックが諸々入っている都合で、各ドメイン毎にPHP関係の設定があれこれされています。

最も良い、あるべき姿としては、全てのファイルをUTF-8に切り替えることですが、ファイル数が多く、難しいため、各ドメイン毎のPHP関係の設定をいじることにしました。

具体的には、php.inidefault_charset="" を書き込むことにより、PHP 5.6より既定となった default_charset="UTF-8" を忘れさせてやることなのですが、この設定を、各ドメイン毎のPHP関係の設定に、一斉に行わなければなりません。

ちょっと焦りながらだったので、何回か失敗してしまい、むしろ設定に時間がかかってしまいました。
そんなわけで、本日の20:30〜21:00頃、訪問されていた方がいたとしたら、ブログとミニブログといくつかのページ以外が、すべて文字化けしていたかと思います。ご迷惑をおかけしました。

いずれは、すべてのページをUTF-8化すべく、頑張りたいと思います。


…とはいえ、Web版ヘルプのページのような、他のプロジェクトと密接な関係があってShift-JISになっているページもあるので、なかなか難しい…。


posted by ayacy at 21:19 | Comment(0) | TrackBack(0) | サーバ運用