カテゴリー: ITめいたこと (25ページ目 (31ページ中))

アンチウィルスソフトにKasperskyを使ってる人から、Adsenseを貼ってるサイトで「Trojan.JS.Redirector.ar」ってのを検出したんだけど…と申告があって、慌ててGoogle先生に聞いてみたら、「Trojan.JS.Redirector.arはカスペルスキーの誤検知のようです。」とのエントリーを発見。おー、なるほど。こういうエントリーはありがたい。まぁ、誤検出ということなら、とりあえず、様子見ということで。パターンファイルの更新を待とうかと。

…ってことは、KasperskyをインストールしてるPCを使ってる人は、違うWebを見る度にアラートが上がってるんだろうなぁ…と遠い目。

追記　その1：

GoogleAdsenseのフォーラムにも、この件の書き込みがあった。

Google Groups

一連の書き込みの中に

I recieved an email from kaspersky that it is an false detection and will be fixed in the next update..

ってことが書いてあったけど、…どうなんでしょうなぁ。

追記　その2：

さっき、このエントリーを眺めてたら、サイドバーに貼ってあるAdsenseにウィルスバスターの広告が出てた。偶然だろうけど、トレンドマイクロにとっては絶妙な感じだなぁ…と(汗)

追記　その3：

カスペルスキーの国内代理店(…?)のジャストシステムが、この件に関してWebページを公開してた。

JustSystems | Kaspersky製品についてによると、

本日2010年1月25日 15:00頃より、Kasperskyをご利用いただいているお客様がニュースサイトなどの記事を参照した際、トロイの木馬「Trojan.JS.Redirector.ar」を検知する場合があることを確認しております。

お客様にはご迷惑をおかけいたしまして誠に申し訳ございませんが、Kasperskyが誤って検知しているものです。

…とのこと。

追記　その4：

上記のジャストシステムのWebページに以下のような内容が追記されているのを発見。

2010年01月25日（月） 23時以降、修正された定義データベースを順次配信予定です。

…というわけで、カスペルスキーをお使いの皆様は手動でパターンファイルを更新すると、Adsenseを見かけて「Trojan.JS.Redirector.ar」を検出するということがなくなるんじゃないでしょうか…と。

あと、kaspersky.comに(ようやく?)この件が出てた。あちらでも、false detection(誤検出)であることを認めているようですな。

False positive detections by Kaspersky Lab products on some Google web pagesより

Such detections of the virus Trojan.JS.Redirector.ar on some Google web pages are false positives.

でも、日本の代理店(?)のジャストシステムのサイトでは改修版のパターンファイルを配信する時間までアナウンスしている一方で、本家では「Kaspersky Lab specialists are working on the issue.」ってざっくりしたアナウンスのままってのも、ちょっとなんだか不思議な感じがしないでもないなぁ。こういうのって本家の方が早いんじゃないのかな、だってパターンファイルとかって本家でつくってるんだろうし(…あ、本家ってもしかしてロシアか…)

追記　その5：

kaspersky.comのフォーラムを眺めてたら、なんとなく妙な感じになってた。

この辺で、Kasperskyの中の人っぽい人が

It’ s already fixed.

Update your databases.

って、書き込んでて、この指示に従って更新したとおぼしき人が返信で

I’ve just updated and I’m still getting the error, this is ruddy stupid.

と返信。そしたら、再び中の人が

K-Lab will fix this problem soon ….

…って、書き込んだってことは、一発目のfixは失敗したんだろうか…。あー。って、「It’ s already fixed.」って書き込んだ人、「Kaspersky fan」って書いてるから、Kasperskyの中の人じゃないじゃん。orz

最近、さくらインターネットでレンタルサーバを契約したユーザはMySQL5.1が使えるようになっているのだが、さくらインターネットのMySQLサーバ群にMySQL5.1が導入される前にMySQLのDBを持っていたユーザはMySQL4を使っている…と。

で、私は、さくらインターネットのレンタルサーバにWordPressをインストールして使っているわけだけど、今度のバージョン(Ver.2.9)から、要求されるMySQL4のバージョンが少し上がってしまったらしく、私が使っていたMySQLサーバではWordPressの要求を満たせなくなった…つまり、バージョンアップできなくなってしまった。

…というわけで、勢いに任せてMySQLのバージョンをアップすることに決定。基本的にさくらインターネットのレンタルサーバでは、使えるMySQLのDBの数が決まっているので、MySQL4のDBを返却(ま、結局は削除)して、MySQL5.1のサーバを借りることになる。基本的には、MyPHPAdminを使って、MySQL4のダンプをとって、MySQL4のDBを削除、でもって、改めて、MySQL5.1のDBを作成して、ダンプしたデータを戻すという作業が必要。まぁ、さくらインターネットのレンタルサーバのコントロールパネルとMyPHPAdminがあれば、片付く作業ではあるけれど、面倒くさい。

で、とりあえずやってみたところ、MySQL4のダンプデータが一部、おかしくなっていたのを、DBを削除した後に発見(UTF-8のデータなんだけど、ダンプして取得したファイルをテキストエディタで見てみたら文字化けが発生みたいな…)したので、この作業をやる人は、ダンプデータに文字化けが発生してないことを確認してから、DBを消すのがいいんじゃないかと(とはいえ、壊れていたのは、古いMovabileTypeで使っていて、放置していたテーブルなので実害はなかったんだけども…)

一応、コントロールパネルからMySQL4のDBを消して、再度、コントロールパネルからのDBの管理画面に行くとパスワードを入力するだけで、MySQL5.1のDBが確保できる。しかし、MySQLのサーバ名が変更されるので、あとは、WordPressの設定ファイル(wp-config.php)に書いてあるMySQLサーバの名前を変更すれば、元通り、WordPressが動くようになったし、WordPress2.9.1へのアップグレードも簡単に終了した。

最近、仕事でさくらインターネットのレンタルサーバのビジネスプロを使っている。

で、このサービスを検討している時には、このサービスはビジネス仕様をウリにしてるので、属性型JPドメイン(ま、co.jpドメインですな)をさくらインターネットに管理してもらって、さくらインターネットのビジネスプロを使おうと思っていたが、ちょっとイヤな予感がして問い合わせてみて、どうもそういう使い方ができないことがわかった(汗)

というのも、さくらインターネットで属性型JPドメインを預かってくれるのは確かなんだけど、ゾーンファイルの編集が不可という残念な仕様。結局は、さくらインターネットが決めている、いくつかのAレコード(wwwとかftpとかmailとか)とMXレコードがゾーンファイルに書かれて、それでなんとか使えというサービス仕様だった。例えば、社外向けにblogサーバでも立てようとして、blog.xxxxxxxxx.co.jpとか使おうとすると、それはできませんということだ。で、どうにかならないかとサポートに聞いてみたら、他社のDNSサーバを使って、そこのゾーンファイルにさくらインターネットのサーバのIPアドレスを書く使い方を提案されてしまう始末。あぁ、無理なのね(涙)

まぁ、さくらインターネットのDNSサービスでは、ゾーンファイルの編集とか一切できませんというのなら、納得もできるし、そもそも期待もしないんだけど、属性型JPドメインはゾーン編集不可で、gTLDドメインとか(汎用JPドメインは可だったかも)はゾーンファイル編集し放題だから、なんとなく、なんとかならないものかなぁと思ってしまう。

加えて、さくらインターネットは、ユーザにSSHを解放しちゃうくらいの自由度がウリだったりする側面もあるわけだし、ビジネス仕様なレンタルサーバなわけだし、属性型JPドメインのDNSはなんとかならないもんだろうか。

追記：

ふと思ったのは、今回、さくらインターネットのドメイン管理サービスで預かってもらおうとしたドメインは、他社で取得したモノで、それをさくらインターネットに移管しようとしたので、もし、最初から新規でさくらインターネットで取得した属性型JPドメインだったら、ゾーンファイルを編集することができるのかもしれない…が、未確認。