Windows → MacでVNC接続不能

オフィスのWindows7から自宅のiMacにVNC接続しようとVPNセッションを張って"UltraVNC Viewer"を起動したところ「選択されたユーザアカウントは利用できません。」のメッセージが出てデスクトップに接続できない。

どうやらユーザー名を指定しない"VNCタイプ"の接続をはねている（ユーザー名＆パスワードを利用するiTeleportのようなiPhoneアプリからは問題なく接続できる）ようで、なんとなく先週インストールした「セキュリティアップデート 2016-002」が影響したような雰囲気。

WindowsのVNCクライアントアプリは全滅っぽいし、Appleが修正してくれるの待つしかないのか...？
ちょっとだけ不便。

【2016/5/6追記】
GW明けて仕事始め。
連休中に自宅で作業したデータにアクセスしてみたらさっくり繋がった。
┐(´д｀)┌
連休前は接続できなかったような気がするんだが...。

特に何もしていないし、OS X向けの新たな"セキュリティーアップデート"も来ていないようだし、何が原因だったのかますますわからない状態。

セキュリティアップデートじゃなく、5月4日に"Remote Desktop クライアントアップデート"が来てました。
あまり詳細な説明はないけれど多分このアップデートで問題が解消した様子。

めでたしめでたし。
(^_^;

持病の「どこでもMy Mac」接続障害

先週、月に1〜2度発生する自宅のiMac(10.8.5）からのリモート作業（画面共有）で、事務所の"Mac mini"(10.9.5)が応答しなくなっていることに気がついた。orz

利用頻度は少ないものの、いざという時にかなり不便なので"Mac mini"の「どこでもMy Mac」をメンテナンス。

とりあえず

• 「ファイアーウォール」をOFFにしてみる。
• 「iCloud」コンパネから「どこでもMy Mac」をON OFFしてみる。
• "iCloud"からログオフ、再度ログオンしてみる。

を実行してみたものの、状況は変わらず...。

iCloudは「どこでもMy Mac」以外のサービスが利用できているのに「サーバに接続できません。」の一点張り。w
システムログを確認してみるとサービスをONにした直後から"mDNSResponder"(Bonjour)のエラーが大量に出ている。

mDNSResponder[40]: Adding registration domain 9*****4.members.btmm.icloud.com.
mDNSResponder[40]: ERROR: recvSetupResponse _telnet._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _ssh._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _uscan._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _printer._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _ptp._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _scanner._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _autotunnel6.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _ftp._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _ipp._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server

"btmm.icloud.com"ドメインからのサービスに接続できていないみたいなので、なんとなくこれが原因っぽい。（「どこでもMy Mac」の英語版は"Back to My Mac"なので、"btmm"は「どこでもMy Mac」のサーバーなんだろうね...）

ひと通りルーターやファイアーウォールを確認しても、これといって接続障害を招く要因が見当たらないため、困ったときの「アクセス権の修復」のおまじないをかけてみます。

幾つか修復されたアクセス権の中で気になるものが一つ。

“Library/Preferences/com.apple.alf.plist”上のグループが一致しません。80 であるはずですが、グループは 0 になっています。
“Library/Preferences/com.apple.alf.plist”を修復しました

ファイアーウォールの初期設定ファイルのグループ属性が修復されています。
本来"80"（admin）であるはずのグループ属性が"0"（wheel）になっていると...。

アクセス権の修復後、無事に「どこでもMy Mac」のサービスは起動するようになりました。（多分初期設定ファイルを削除して作りなおさせても良かったのかもしれません。）

ただ、後から"com.apple.alf.plist"ファイルのグループ属性を確認してみても"wheel"のままなのですが、いったい「アクセス権の修復」コマンドって何をやってるんでしょうね？

そもそも、なぜこんなに頻繁にファイルのアクセス権が変更されてしまうのかも疑問なのですが...。


P.S
ファイアーウォールの設定を確認していて、リモートシェル（ssh）のサービスも使えないようになっていることに気がついた。

「どこでもMy Mac」の接続障害を直すついでに"sshd-keygen-wrapper"への外部からの接続を許可しておきました。

ネットワーク障害

今朝（といっても10時過ぎだが...）出社そうそう上司が「Facebookの表示がおかしい」とMacBook Proを持って近づいてきた。

見てみるとFacebookのページがスタイルシートや画像を読み込めず、おかしなテキストだけの配列になっていたので、ブラウザーの「要素の検証」で見てみると、スタイルシート関連を格納しているサーバーへ接続出来ないエラーが出ていた。（接続出来ないというより、「サーバーが見つかりません」状態）

そういえば先週末に社内ネットワークがなんとなく遅いって事で、ルーターのDNSにGoogleのOpenDNS（8.8.8.8）を指定して様子見ていた事を思い出し、コンソール画面からlookupコマンドで確認を取ってみたところ、情報が取得出来たり出来なかったりと非常に不安定な状態。

Webサイトの「要素の検証」から確認してみるとアカマイのネットワークでホストされているものがほとんど全滅しているような状態で、"apple.com"のドメインまで閲覧出来ない状態に陥ってしまっていた。（そもそもOpenDNSはアカマイとの接続がいまいちらしいが...）

取りあえずGoogleのOpenDNSを全ての機器から削除＆ルーター再起動して午後からはどうにかアクセス出来る状態になっていた。

ところが17:00少し前ぐらいから別のスタッフが「またFacebook繋がらないです」との報告があり、見てみると今度は完全にシステムがダウンしている様子。

ブログなどに埋め込んである「いいね」ボタンもエラーを吐いてるし、かなり大規模なシステム障害の模様。ただ、自社ネットワークの障害じゃないので気分は楽。ww

結局17:30過ぎくらいまで復旧しなかったのだけれど、ネットの情報見てもかなり大規模な障害だったみたい。

APIサーバーにも繋がらなかったし、全世界で繋がらなかったとなると"Facebook"のシステムというよりもっとネットワークの根幹で障害を起こしていたような予感...。
ま、個人的にどうにかなるレベルのものじゃないけどね。

サイバー攻撃によるシステム障害でない事を祈ります。
（"人的ミス"ってのも企業にとっては大問題なんだろうけど、個人的には許せてしまうのです。w）

Mavericksと「画面共有」接続障害、その後。

先日書いた「OS X Mavericks(10.9)と"どこでもMy Mac"」はMavericksの不具合ではなく、たまたまっぽい気がしてきた。
なんとなく今回の諸悪の根源はLion側（うちの場合）の「画面共有」が原因のようだ。

本日会社の"Mac mini"から自宅のiMacへ接続する必要があり、いつものようにFinderのサイドバーに出現しているiMacを選択し「画面を共有」をクリックしてみた物の"iMacに接続出来ません"状態。
アラートで「画面共有が有効になっているか確認しろ」と表示されるが自宅内でも多用する"画面共有"を無効にした覚えなど無い。

先日の事もあったしクライアントがMavericksだし、またiCloud絡みのトラブルかと思い、自宅のLANへVPN接続してから"画面共有"を試みるも同じように繋がらない。orz
ローカルネットワーク内から繋がらないとなるとMac OS Xに実装しているVNCクライアント機能に不具合があるのかと、念のためフリーのVNCクライアントソフト"Chicken of the VNC"で接続を試みてもやはり繋がらない。

もうどう考えてもLionの画面共有が接続拒否しているとしか考えられない状態のため諦めて自宅へ移動。
コンソールからログを確認してみるとやはり"screensharingd"が接続を拒否している。

そういえば先日のMavericksへの接続時に確認したファイアーウォール設定でなぜか"screensharingd"が「外部からの接続をブロック」する設定になっていた事を思い出し、「接続を許可」に切り換えて見るも状況は変わらず...。orz

こんな時はMacメンテナンスでは定石その１"プリファレンスファイルの削除"。ファイアーウォール関連のファイルをゴミ箱に入れてファイアーウォールをリセットしてみる。

ファイアーウォールの設定画面はデフォルトのシンプルな構成になっていかにも接続出来そうな雰囲気になったのにやはり画面共有は繋がらない。（ログを参照する限りまだファイアーウォールで弾かれてる）

「画面共有」が許可されてるのに"screensharingd"が拒否するってどういう事？
こうなればファイアーウォールで"screensharind"を直接許可するしかないのでちょいと特殊な場所にある"screensharind"をファイアーウォールに登録。

余談ですがこのデーモンはパッケージ(.bundle)の中に収まってしまっているため、通常のファイルセレクターからだと階層までたどり着けません。(/System/Library/CoreServices/RemoteManagement/screensharingd.bundle/screensharind)

自分の環境では古くから愛用している"DefaultFolder X"というユーティリティが入れてあるのでファインダーで予め所在場所を開いておくとどんな場所にでも簡単にアクセス出来るんですが、皆さんはどうやってファイル選択してるんでしょう？
ちと高いユーティリティですがMacで仕事する人にはちょーお勧めなツールです。

で話を戻しますが、せっかく"DefaultFolder X"の力を借りて"screensharingd"をファイアーウォールに登録して接続を許可したのにやはり「画面共有」は繋がりません。orz
ログにも相変わらず"Firewall: Deny screensharingd connecting from xxx.xxx.xxx.xxx:50266 to port 5900 proto=6"のメッセージが羅列されるだけ...。

ファイアーウォール切って運用すればそれで済む所だけど、それではネットワーク管理者も生業としている身としては納得がいかないので、ここでMac OSメンテナンスの定石その２の"アクセス権の修復"を試みる。（他に思いつかない時の最後の手ともいう）

ずらずらとパーミッション関連の不具合が羅列され、終了間際にファイアーウォール関連の初期設定ファイルも修復されている...。
「これはもしかすると？！」

なんと、「画面共有」の接続が復旧いたしました。＼(^o^)／
なんとなくスッキリしませんが、経緯から見ると初期設定ファイルのグループ属性が正しくセットされる事によって接続出来るようになったと言う事でしょうか？

ただ、このあとファイアーウォール設定から"screensharingd"を外すとやはり接続出来なくなってしまうため、ファイアーウォールで"screensharingd"の接続を許可する必要もあるようです。

"アクセス権の修復"を実行してみてもう一つ気になったのは"Apple Remote Desktop"絡みの修復メッセージ。
Mavericksのリリースに合わせてARDも3.7にバージョンアップしてましたが、ひっそりとこの辺りも仕様が変更になっているのかもしれません。

「画面共有」はARDとは関係なく、たんなるVNC接続なんでしょうけどね。

Mavericks(10.9)のMail.appで接続エラー

先週Mavericksにアップグレードして特に不具合にも遭遇せず利用していたのだが、今朝になって社内のスタッフから

「Mavericksにアップグレードしたら自社のメールサーバーから送れなくなってしまいました〜。(T_T)」

との事。
自分の"Mac mini"ではそんな不具合を確認していなかったので、自分の環境と照らし合わせてみたところ、どうやらMavericksのMail.app（Ver7.0）ではSSL接続が半強制的にセットされる仕様に変更されている様子。

大手のメールサービスであれば、サーバー証明書もちゃんと用意してあるので接続に関してSSLを有効にしても問題は無いのだが、社内用に用意したドメインのメールサーバーにわざわざ高価な証明書は入れていないのでSSLを有効にするとどうしても初回接続時に証明書の警告が出てしまう。

ほとんど再起動しなくなったOS Xだけど、やはり警告が起動の度に出るのは煩わしい事もあってSSLを無効にしてしまうのだ。
で、問題なのがMavericksのMail.appで以前のように「デフォルトポートを使用」を選択するのだが、こちらを選ぶとSSL接続が強制的にセットされるようでその下にある「SSL を使用」の✓マークが外せない。
一時的には外せるのだが、数秒経つと自動的に✓マークが自動的に付けられてしまう。

何かの拍子に外した状態で保存出来ちゃったりすると、今度は「サーバーにSMTP接続が出来ない」とのエラーが発生しだす...。（冒頭のスタッフがこの状態）

多分「デフォルトポート」で設定し465番ポートで接続が出来たサーバーは問答無用でSSL接続がセットされるのではないかと思う。
そこで無理矢理SSLを切ると今度はSMTPポートに接続出来ないという現象に陥るのではないかと想像している。

結局SSL接続を使いたくない場合には「カスタムポートを使用」を選択し、ポート番号に587番ポートを指定。これでSSLの警告無しでメールサーバに接続出来るようになった。

そもそもSSL証明書が入っていないのにSSL接続を許可しているサーバーが悪いって事もあるけれど、「デフォルトポートを使用(25, 465, 587)」ってなってるのにSSLを外して587番ポートで接続出来ない仕様変更はどう考えてもおかしい。

そういえば、先日サポートスタッフがお客さんの新しいiPadのメール設定をしていた時に「SSLを"入"にしないとサーバーに接続出来ない〜」と悩んでいたけれど、もしかしてiOS7のメールも同じような仕様になっているんだろうか？！

見た目はあまり変わらないけど、新しいOSだしね。まだまだいろんな不具合は出てきそう...。

OS X Mavericks(10.9)と"どこでもMy Mac"

昨日のMarvericsアップグレード作業後、特にこれといった不具合も見当たらず残りの業務を終業までこなしました。

結構期待していたFinderの"タブ"実装だったけど、慣れの問題か相変わらずウィンドウ開き散らかしてます。ww
結局一度にフォルダの中身を確認するためには一杯ウインドウ開いていないとダメなんですよね...。Webブラウザーなどと違って思ったより使い方が限定される感じ。w


それはさておき、今朝は朝っぱらから経理担当者の苦言の電話。
Mavericksの"インストール＆試し弄り"で浮かれてて、頼まれていた顧客リストのプリントをすっかり忘れていた。orz

「すぐ事務所のプリンターに出力します。」と返事をして電話を切り、"どこでもMy Mac"で"Mac mini"へ接続しようと試みるもしばらくすると「接続出来ません」のエラー表示。

「え？　マジ？！」

毎日のように接続しているリモートデスクトップ。唯一の原因は昨日入れたMavericks以外考えられない。
iCloudの"どこでもMy Mac"が有効になっていないのかとも思ったが、自宅iMacのFinderサイドバーにはちゃんと"Mac mini"が現れてる...。

「画面共有」がだめならボリュームへの接続は出来るのか試してみたところ同じように「Serverが見つかりません、IPアドレスを確認....」云々とのたまってマウントが出来ない。
これはMavericksレベルの問題じゃないかもしれない...。と思い、取りあえず社内で稼働している"OSX Server(Mountain Lion)"へリモートデスクトップで接続。

"OSX Server"のFinderからローカル内の"Mavericks@Mac mini"に「画面共有」で接続。

「あれ？　普通に繋がるじゃん...。」

やっぱりiCloudの中継がおかしくなっている雰囲気なので、"Mac mini"の"システム環境設定"から"iCloud"を開き、一旦サービスからサインアウトして再度サインインしてみる。
Mavericksの初回起動時にも何かやった覚えがあるのだけれど、"iCloudキーチェーン"や"携帯番号との紐付け"等、いくつかの設定項目も再びiCloudを有効化してみた。

するとほぼリアルタイムに自宅のiMac側にも自動的に共有ボリュームがマウントされる。
多分iCloud内に記録していた"Mac mini"の端末情報がMavericksのインストール以降整合性がとれなくなっていたのかもしれない。

以前自宅でG5 → iMac変更時に「移行アシスタント」で遭遇した"どこでもMy Mac"認証エラーのような複雑なトラブルでなくて助かりました。
取りあえず初歩的なサインアウト＆サインインで復旧しました。（′Д`）

【2013/10/29追記】
"Apple サポートコミュニティ"でディスカッションされている内容を見ると、どうやらOSのバージョンの組み合わせで、発生する不具合に相違があるみたいです。
"Mountain Lion"と"Mavericks"の組み合わせだとファイアーウォールを"切"にしないと全く繋がらないとか、うちのように"Lion"と"Mavericks"だとファイアーウォールで"screensharingd"が「接続をブロック」になっていても双方から「画面共有」が出来ています。(Mavericks側は登録無し)

本日遭遇したMail.appのセキュア接続の方法も含めシステムのセキュリティ関連が大幅に変更になっているのかもしれません。
過去のディスカッションでもやり取りされている通り、「画面共有」はファイアーウォールとの絡みでトラブることもあるようで、Mac OSメンテナンスの基本に立ち返れば「取りあえず初期設定ファイルを捨ててみる」ってのが一番なのかもしれませんね。

特にクリーンインストールしていないOSは各種「初期設定ファイル」をそのまま引きずっている可能性が高いと思います。

【ファイアーウォール関連 初期設定ファイル】

/Library/Preferences/com.apple.alf.plist

/Library/Preferences/com.apple.alf.plist.lockfile

【画面共有関連 初期設定ファイル】

~/Library/Preferences/com.apple.ScreenSharing.LSSharedFileList.plist

~/Library/Preferences/com.apple.ScreenSharing.LSSharedFileList.plist.lockfile
~/Library/Preferences/com.apple.ScreenSharing.plist
~/Library/Preferences/com.apple.ScreenSharing.plist.lockfile

Apple サポートコミュニティ：Mavericksにアップデート後、画面共有できず。

【2013/11/05追記】

接続が可能だったのは"Lion(10.7)" ⇒ "Mavericks(10.9)"への接続だけでした。
逆向きの接続は世間で問題になっているとおり接続不可能でした。

トラブルシューティングはあらためて検証中

Bloggerのアクセス統計システムに変化？

色んな迷惑行為がはびこる昨今のインターネット。

Bloggerのアクセス統計システムにも大量のリファラースパムが押し寄せて迷惑この上ない。（トラフィックの上位はほとんどスパムドメイン...orz）

以前「"Google Analytics"のフィルターで迷惑ドメインを登録することによってカウントできるみたい」な記事を書いたことがあるのだが、全く効果の現れないドメインもあったりしてほぼあきらめていた。

何気に今日"Blogger"のアクセス統計を覗いてみると昨日（10月22日）からかなりカウント数が少なくなっているのに気が付いた。（「落ち着いている」という表現の方が適切かも...）

というか、そもそも"Blogger"の統計カウント数は"Google Analytics"でのカウント数と比べると8割ほど多く、あきらかに信憑性のない数字が多かったのだが、ここ2日ほどはかなり控えめなカウント数になっている。（それでもけっこう多いけど...w）

もしかするとたまたま2日続けてスパム行為がなかっただけかもしれないのだけれど、願わくば"Blogger"の方でもあきらかに"リファラースパム"と思われるドメインはフィルタリングで排除してくれるようになった事を期待したい。

そもそも"Google"はウェブアクセス時にも"マルウェア"等の検知をしてユーザーが被害に遭わないように注意喚起してくれるとても親切なプロバイダなのに、リファラ—スパム如き検知できないわけはないですよね？

そもそも"Google Analytics"っていう高機能アクセス統計システムがあるのになぜ"Adsence"のように組み込んでしまわないのだろう？（リンクでも良いので）

あと一応"Blogger"には「自分のページビューを追跡しない」という項目もあるのだが、これもどこまで（どの端末まで）除外できているのか微妙なところだ。

【2013/10/24追記】
かなり期待したけれど、今まで見かけなかった新たなドメインからのスパムアクセスがカウントされていました...。orz
ただ、以前からひっきりなしに来ていたドメインはなりを潜めたようだし、もうしばらく期待を込めて様子見ましょう。w

ついでなので、リファラースパムかどうかの判断方法ですが、自分は"aguse.jp"という調査サイトを良く利用させてもらってます。

http://www.aguse.jp

マルウェアの有無や、サイトのプレビューなども表示してくれるので安心してURLの確認が出来ます。有用な調査サイトを運営していただいて感謝。

MS純正 "Remote Desktop connection" がリニューアル

2008年の夏以降ずっと放置プレイだった Microsoft RDC クライアントのMac版と、ずっと待ちわびてたiOS版が"Windows Server 2012 R2"といっしょにリリースされたので早速インストールしてみた。

Microsoft Remote Desktop カテゴリ: [ビジネス] 価格: 無料

Desktop用のクライアントソフトは放置されていたからといっても接続出来ない状態ではないのだが、5年ぶりのアップデート。
今回から"Mac App Store"扱いなのでインストールも楽ちん。

ちなみに旧バージョンの設定ファイルは再利用不可能なようなので、また1から作り直しすることになります。
日本語にローカライズされていないけれど、特に難しい設定することもないので問題なし。

"サーバー名（or IPアドレス）"、"ユーザー名"、"パスワード"をセット。
後は画面サイズやサウンドの再生、ローカルドライブ＆プリンターの共有など、シンプルな画面構成になったけど出来ることはほぼRDC2の時といっしょ。

ただ、RDC2であった「セキュリティ」タブは廃止され、認証のセキュリティチェックは初回の接続時にアラートが表示され、"Connect Always"を選べばそれ以降はうるさいことを言わなくなる。

接続してみた雰囲気は...特に変わらず。ww　「若干旧バージョンよりレスポンス良いかな？」ってな程度です。（そもそも未だに"2003 Server"とかで運用してるのでそれ以前の問題です。）

それより今回の目玉はiPhone/iPad版がリリースされたこと。

Microsoft Remote Desktop カテゴリ: [ビジネス] 価格: 無料

リモートでサーバーメンテナンスするのはやっぱりモバイル端末から出来て"なんぼのもん"じゃないでしょうか？
iPhone利用し始めた当初から無料、有料問わず色々なクライアントソフトをインストールしては捨ててきましたけど、本家から無料の公式アプリがリリースされたのは非常に喜ばしい事です。

この手のソフトの優越判断はなんといってもUI次第。
今のところ自分の中では"iTeleport"以上の操作性を提供してくれるリモートデスクトップアプリは存在していませんが、後発Microsoftは果たしてどんなUIで操作させてくれるのか検証してみます。

で、ポチッとApp Storeからインストールして起動。
デスクトップ版と同じように接続先のサーバープロファイルを作成してコネクト。

こちらもデスクトップ版と同じように初回の接続時にセキュリティアラートがでますが、やはり"Connect always"で以降黙らせます。
接続した画面での操作はWindows版RDCのように画面中央上部のタブから機能へアクセス。

左側の"十字カーソルアイコン"をタップすると描写が等倍になって画面中程に十字コントロールパッドが出現（ダブルタップで配置場所は移動可能）、左の"キーボードアイコン"をタップすると下からキーボードが出現します。キーボードは更に左右の◀▶ボタンを押すことでファンクションキーなどの機能ボタンへ変化します。（これは使いやすいです）

また中央の"サーバー名"部分をクリックすると上部よりもう一段コントロール部が現れて、右側にはコネクションの"切断"ボタン、左側にはマウスポインターとタブレットモードの切り替えボタンが配置されます。

マウスカーソルモードは"iTeleport"などでも定番の操作方法なので、特筆すべきものは無いのですが、タブレットモード（手書きモード？）にすると、"ペイント"など自由描写の出来るアプリではそのままタブレット端末の画面をなぞって指先で描写することが可能です。

果たしてそんな操作をするシチュエーションがどれほどあるか微妙なところですが、「なぞる」操作ができるコントロールはこのAppが初めてのような気がします。

ただ、画面の拡大・縮小にタブレット端末特有の"ピンチ"操作やスクロールができないため、全画面表示か等倍表示かの二択しか出来ないみたいです。
そのため「もう少し広い範囲で見たい」とか「もう少し拡大して見たい」といった作業が出来ません。

まぁ、後発なだけにそれなりに扱いやすいUIに仕上げて来たのは悪くないと思います。
多分個人的には画面操作が秀逸な"iTeleport"を利用すると思いますけどね。ww

iTeleport: VNC & RDP カテゴリ: [ユーティリティ] 価格: ￥2,500

メールサーバースパム被害

マジ散々な一週間だった...。

それは一件のユーザーからの問い合わせで発覚。
「送ったメールがなかなか先方に届かない」との問い合わせだった。

メールサーバー（ゲートウェイ）のモニターグラフを見て愕然。毎分700通ほどのメールが着信している。
しかも外部からスパムが大量に送りつけられているかと思いきや、内側から配信しようとしている状況だ。

すぐさまLAN内のサーバーで大量のメールを発信しているサーバーを特定しメールのログを確認。ログも膨大なサイズに肥大していて閲覧するのも辛いほど。

サーバーはSMTP-AUTHのみ接続を許可され、不正中継をしていないことは確認できたのでSMTPユーザーのセッションを洗い出してみる事に。
以下のコマンドで"smtp-auth"で接続したユーザーアカウントだけ抽出して回数順にソートして並べてみる。

# cat /var/log/maillog |grep -I smtp_auth |grep -I user |awk '{print $11}' |sort |uniq -c |sort -n

ログのローテーションから10時間ほど経っていたのだが、普通多くても数回程度のSMTP接続が、1つのユーザーアカウントだけ数分おきのインターバルで500回近く接続している。
そのアカウントに的を絞ってIPを調べてみると、市内のフレッツ光ユーザーなのに接続しているIPアドレスは全て"ロシア"、"ウクライナ"や"ベラルーシ"など旧ソ連諸国や東ヨーロッパからの接続。

緊急的に該当ユーザーアカウントのパスワードを変更しログを注視して見ているとそれ以降"smtp-auth"接続エラーで配信されることはなくなった。
問題なのはユーザーアカウントがどこで盗まれたのかなのだが、調査してもサーバーから漏れた痕跡はないし、それ以外のユーザーアカウントが利用されていないので、ユーザーのPCがフィッシング等にあった可能性が高いと判断している。

その後ゲートウェイ（スパム、ウイルスフィルタ）に詰まった4万数千のキューと、該当ユーザーが利用していたメールサーバー内に拒否されて配送待ちになっていた45万ほどのキューの処理...。

正直そんな大量なキューを分類し削除処理していては時間がかかりすぎるため、一旦詰まったキューのディレクトリ丸ごと切り離し、空のキューフォルダと差し替えて送信サーバーの復旧を計る。

問題なのはそこからで、分離したキューを掃除して正常なメールだけを再送しなければならないのだが、Postfixで運用しているメールゲートウェイはどうにかなりそうなものの、アカウントを盗られた該当サーバーはQmailは運用されていたためキューの管理が煩雑な上45万件という膨大なキュー...。

Postfixのキューは"incoming"ディレクトリで一元管理されているため意外と処理が楽なのだが、Qmailの場合queue以下に"info","local","mess","remote"（他にもいくつか）などのディレクトリに別れ、それぞれに情報が格納されているためディレクトリ間の情報がおかしくなるとqmailのログにこれまた大量のエラーが吐き出されるようになる。

壊れたqueueを修復してくれる"queue-fix"( http://www.netmeridian.com/e-huss/queue-fix.tar.gz )なるツールも存在したので試してみたのだけれど、逆にqmailのシステムがエラーコード65を吐いて出て全くメールの送信が出来なくなってしまったため、やむなくqueue以下のフォルダを全て削除＆新規作成して復旧させた。

#  cd /var/qmail/
#  mv queue queue.orig
#  mkdir queue
#  chown qmailq:qmail queue ; chmod 750 queue
#  cd queue
#  mkdir mess
#  for i in `seq 0 22`; do mkdir mess/$i ; done
#  for d in info intd local remote todo ; do cp -r mess $d ; done
#  chmod -R 750 mess todo
#  chown -R qmailq:qmail mess todo
#  chmod -R 700 info intd local remote
#  chown -R qmailq:qmail intd
#  chown -R qmails:qmail info local remote
#  mkdir bounce pid lock
#  cp -a ../queue.orig/lock/* lock/
#  /etc/init.d/xinetd start
#  /etc/init.d/qmail start
#  chown qmailq:qmail pid lock
#  chown qmails:qmail bounce
#  chmod 700 bounce/ pid/
#  chmod 750 lock

今回のスパム送信者は数通の配信で接続先（IP）を変え、本文もランダムに変えるし送信者もでたらめなアドレスを生成させるといった手の込みようで、一定のキーワード検索では抽出が困難になるようなメールを生成していた。

Qmailはキュー管理用の様々なツール（"qmail" "キュー" "削除"等でググってみた）を使ってみたけどあまりの時間のかかりように途中であきらめました。

色んな国から大量の接続を経由して配信しているって事はかなりのPCが踏み台にされてるんだろうなぁ...。一つのIPからだとたいした数のスパムを配信してないのでまったく気付かない人も多いと思う。orz

結局今回は丸3日ほど処理作業に振り回されました。なんだか段々手強くなっていくなぁ...。(T_T)

ホントいい加減にして欲しい。

Windowsの資格情報

年に1度ほどのペースで依頼の来る歯科クリニックのクライアントマシンのLANへの追加作業。
毎回同じ事で失敗するのでちょっと備忘録。

データベースで管理されている口腔写真が大量に保存されている共有フォルダーへPC起動時に自動再接続しなければならないので、ネットワークドライブとして登録しておくのだが、これがまた起動する度にログイン情報を忘れる...。orz

「Windows XPのHomeエディションじゃあるまいし、Windows 7 Proで毎回ログイン情報忘れるってどういう事よ？」

と毎回現場の作業で繰り返す情けない状態。
しばらく「なんで記憶しないんだったっけなぁ...」と以前の対処法を思い出すまでに時間を要する。

如何せん、普段Macしか使ってないのに年に1度有るか無いかのセットアップ作業の内容なんか覚えていられない。
年に一回しか使わない宛名書きソフトの使い方を毎年うろ覚えで操作してるのと一緒です。orz

通常操作でネットワーク端末へのログイン情報を記憶させて「資格情報マネージャ」（Vista以降）で見てみると、"ログオン セッション"となっていて、この状態では再起動するとパスワードを忘れてしまうモード。
パスワードを"エンタープライズ"で記憶させないと再帰的には利用出来ない。

Microsoftのサポートページにある以下の内容が解説。

「Windows で特定の宛先に対して使用する資格情報を資格情報マネージャーに記憶しているにもかかわらず、再度、資格情報の入力を要求される」

基本的に、パスワードを記憶させるって事はかなりセキュリティ的にはリスクが高まるので容易に保存させないようにする行為は正しい。
そういった説明をクライアントにして、毎回ネットワークへのログインパスワードを入力してもらうのが正しい運用なんだろうけどね。

ただ現実の現場の作業者にとってはセキュリティなんて日常作業の邪魔だけで、マウスクリックのみで入力が完了するように設計された業務アプリではいちいちキーボードになんか触っていられないってのが実情。

今時インターネットから遮断するわけにもいかないしね、便利なんだか不便なんだか...。
┐(´д｀)┌

リファラースパム

なんかやたらと多いですね..。リファラースパム。orz

リファラーに限らずスパム行為を行うヤツの気が知れない。
日々どれほどの無駄なトラフィックが消費されてるか...。(T_T)

BloggerはGoogleファミリーの一員なので、簡易的ではあるけれど意外としっかりしたアナライザーが装備されている。
便利なツールである反面、アナライザー閲覧者をターゲットにする"リファラースパム"なる輩に横行されてしまうデメリットもある。

もともとGoogleにはウェブ管理者向けに高度なアナライズツールである"Google Analytics"というサービスがあるので、Bloggerにはこのツールの簡易版を組み込んであるのかと思っていた。

というのも、Bloggerの「統計」にリファラースパムが現れる毎に"Analytics"の「フィルタ」にスパムドメインを登録するとBloggerからも排除されていたため、同じシステムを使っているのかと思っていたのだ。

現に、過去10個ほどの迷惑ドメインをフィルター登録する事で、Bloggerの統計からも閉め出す事が出来ていたのだが、ここ1ヶ月ほどやたらとアクセスしてくる"blogsrating . pw"というドメインとTwitterの短縮URLを使った"t.co/xxxx"からのトラフィックをなぜか排除できていない...。

こうなると今までのスパムが消えたのはたまたまで、BloggerではAnalyticsとは全く関係の無い統計システムが構築されているのかとも思うのだが、フィルター登録した他の迷惑ドメインは一つもトラフィックに入ってこないので、もしかするとAnalyticsのフィルターをくぐり抜けるすべでも持っているのかもしれない...。
（もしくは気まぐれでBlogger運営スタッフが排除してくれてる？）

Bloggerの「統計」に対しても効果が有るのか怪しい雰囲気になっていますが、"Analytics"上では出来るだけ正しい統計を集計するためにも「フィルター」機能は活用するべきだと思います。

ちなみに"Google Analytics"にログインした画面の右上にある「アナリティクス設定」からプロファイルを選択する事によって「フィルター」タブにアクセスする事が出来ます。

基本的にECサイトを構築させて頂いていたお客様のWebサイトには必ずAnalyticsを組み込んでマネージメントしてもらっているのですが、意外と個人のサイトでも有用なツールとして活用できます。
ついでに"ウェブマスターツール"と合わせて使えばもっと詳細なサイト運営が行えますね..。

ま、個人のブログでそこまでやるガッツがあるかどうかは別ですけどね。:-P

新しいGoogle Maps

ツーリングルートを検討する際に何かとお世話になっている"Googleマップ"。

登録申請をかけ、5月の終わり頃「ようこそ新しいGoogle マップへ。」というメールを受信してからここ一ヶ月ほどリニューアルしたGoogleマップを使ってみたんだけど、まだまだツールとしては使えない感じ。

致命的なのは"マイプレイス"が利用出来ない事。
経路を調べたり作ったりする事は問題ないのだが、如何せん保存することが出来ないので共有する事も出来ず、後日活用のためのルートとしても利用出来ない。
（Google曰く、機能を準次追加中との事）

下部に名所などの写真が羅列されていたり、かなりストリートビュー系が強化されてバーチャル観光的な要素がかなり強くなってる。
地元（田舎）の路地裏のような道路まで"ストリートビュー"が撮影されていてちょっと驚いたりもする。

マップ自体はちょっとコントラストが強くなったけど、情報量と軽快な描写は他の地図サービスに比べると一日の長があってやっぱり安心感がある。
ただ、最近流行の簡素化されたUIに習ったのか、画面上から機能へアクセスするアイコンなどがことごとく排除されシンプルなデザインになってしまったのは、ユーザビリティ的にはちょっと微妙...。

あと、Appleなんかもそうなんだけど、各社とも地図の3Dビュー化にこだわるのはなぜなんでしょうね。
名所や歴史的建造物を見られるのは良いんだけど、今回のGoogleマップみたいに一般住宅を3D映像化（しかも変なアルゴリズム使って3D化してる）する必要はあるのでしょうかね？
これってあまりクオリティ上げると防犯的には悪用されそうで怖いと思うんですけどね。

あと、今日から利用出来るようになったらしい"高解像度衛星画像"(8000億画素!!)は結構見応え有ります。（マップ、Earth共に利用出来るようになってます）
海面の波までハッキリ見えます。人まではいかないまでも、車の車種ぐらいだったら判別できそう。

 【Engadget Japanese】
GoogleマップとEarthが8000億画素の新衛星画像で刷新、クラウドと決別

いずれにしても個人的にはツーリング用のルート案が保存できるようになるまでは、既存のGoogleマップに依存するしかないようです。

Google Reader終了間近でFeedlyのクラウドサービスが開始。

Google Reader終了まであと10日切った今日この頃、Google Reader愛用者のみなさんいかがお過ごしでしょうか。

個人的にはUIの美しさにほぼ"Feedly"で決まりかと思っていた矢先に先日"ITmedia"の配信で「FacebookがRSSリーダーを発表か？」などというニュースを目撃してしまったためにここ数日Facebookの発表会（現地20日）を少し気にして待っていたのだけれど、結局発表されたのは"ビデオ対応Instagram"だけだったみたい。
（おっくうだったFacebookへの動画投稿には有用なツールになりそうなのでそれはそれで良いんだけどね...。）

そんなタイミングでFeedlyから「全てのユーザーにCloud環境提供開始」の案内。

Feedly Cloud is Now Available to All Users

取りあえず案内されるまま"http://cloud.feedly.com/"へアクセスしてみると、"Import Your Google Reader"のリンクがある。

どうやらこれで単なるGoogle Readerをトンネリングして閲覧している状態からFeedlyのCloudサーバーへデータを移行するって事みたいだ。
さっそくリンクをクリックして見るも"504 Gateway Time-Out"のエラーが表示されなかなかインポートができなかった。

さすがの「2500万人のフィードを読んで日々数十億のニュースを処理している」サーバーでもアナウンス直後とあって、たて込んでいたのかもしれない。
時間をおいて何度か試しているうちになんとかインポート処理が完了し、いつもの閲覧画面になった。（今までの既読がリセットされるので、全て未読記事になったしまうようだ。全部既読にしてからインポートしないと、どこまで読んだかわからなくなりそう...）

今まではGoogle Readerのブラウザーみたいな立ち位置だったのでプラグイン（機能拡張）が組み込んでないと閲覧出来なかったのだけれど、クラウドサーバーにデータをインポートしたおかげで、"http://cloud.feedly.com/"でもRSSリーダーとして機能するようになった。

ただクラウド対応のためか、各種ブラウザー向けプラグイン（機能拡張）も最新版(16.0.512以降)にバージョンアップしないといけないみたいだ。
なぜかiPhone用のアプリはまだ6月11日リリースの16.0.1というバージョンなのだけれど、これはクラウドサーバーの中のデータを見ているんだろうか？

一応iPhoneのSafariでも"http://cloud.feedly.com/"を閲覧は可能なんだけれど、タッチパネルのインターフェースに適応できていないようで、うまく反応しなかったりする。

ところでFeedlyオリジナルのクラウドサーバーに移行したのだけれど、認証は相変わらずGoogle認証なんですね。これはこれで良い物なんだろうか？

【追記】
今後"TwitterやFacebook、TumblrのやLinkedInのためのサポートを追加する予定"とのコメントが記載されていました。

いずれにしてもGoogle Reader終了までの10日弱、しっかり検証させて頂きましょう。

【6月22日追記】
Feedlyのwebサイトには、Google Reader8年間の活動への労をねぎらうコメントが掲載されていました。なかなか洒落てるね。