【システム】

DeleGate＋robots.txt で大ハマリしたので、メモ。

会社の公開サーバは、複数のサーバをひとつの固定IPアドレスで公開しているため、内向きの、いわゆるリーバース・プロキシを通すことで、インターネットから入ってくる接続を各サーバに振り分けている。
使用しているプロキシ・サーバは DeleGate。

DeleGateは、/robots.txt にアクセスがあった場合、自動的にプロキシ経由のURLを検索エンジンにヒットさせないように、robots.txt の内容を自動的に書き換えて返す。

たとえば、以下のような内容で /robots.txt が置かれていた場合…・

DeleGateは、以下の様に自動的に出力を追加する。

この動作は、/robots.txt が存在しているか否かに関わらず自動的に出力され、/robots.txt が存在しなくても、常に以下の様に出力される。

昨今は、WEBサイトがどんどんSSL化されつつあるが、httpsでアクセスした場合、/robots.txt にどのように記載してあったとしても、すべて捨てられてしまっている事に気付いた。
常に /robots.txt が存在しないものとして、DeleGateの自動出力だけが出力されている。
すなわち、/robots.txt を置いても置かなくても、/robots.txt にどのように記述してあっても、常にこのように出力される。

マヂすか。(涙)
まぁ、DeleGateと言えども、SSLで通信されている内容を傍受／復元して「内容を改ざんする」事はできないだろうから、SSLで通信をしている場合は、出力のすべてを置き換えるしか方法がないのだろうな。
もし、傍受／復元が可能だとすると、SSLでて暗号化している意味がない。
確かに、そりゃそうだと思う。

DeleGateが開発された当時は、まだSSLは一般的ではなく、特殊な環境であったと思うので、この動作でも大きな問題ではなかったのだろうけれど、ほとんどのWEBサイトがSSL化されている現在の状況では、この動作はちょっと厳しい。

困ったぞ。
サーバ上のコンテンツはインターネットから見える様にはしているが、検索エンジンにはヒットさせたくない。
そして逆に、このブログを含め、検索エンジンにヒットさせたいコンテンツもある。

DeleGateのマニュアルと読むと、MOUNT のオプションに「robots={no|ok}」という設定は存在しているが、どう設定しても出力は変化しない。
過去に仕事で X-Window のソースと格闘し、死ぬほど苦労した ずんべ としては、正直、こういったソフトウェアのソースコードは覗きたくない。はっきり言うと、ソースコードが「すごく汚い」のだ。たいていの場合、読めたもんじゃない。
さりとて、robots.txt が制御できないのも困る。

仕方がない、ソースコードを開いてみることにする。
がい、しかし、やっぱり、読むには辛いソースコードだ。
同じ構造体を、異なるソースファイルだと、異なる型で定義されていたり...、
関数の情報はヘッダファイルなどにまとめられておらず、各ソースファイルで必要に応じてという形で記述されていたり...。
マクロだらけで、結局、どういうソースに展開されるのか、ぜんぜんわからない...。
各ソースは、それが「クラス」であるかの如く振る舞うような作りになっているように思えるけれど、一貫性がない。

それでも頑張って、追ってみる、追ってみる、追ってみる。
「robots={no|ok}」を参照しているコードはあった。
しかし、その設定が、robots.txt の出力のコードの部分で使われているようには見えない。
やはりこの設定、ぜんぜん機能してないんじゃないか？

さて、どうするか。
設定では対処できそうにないので、ぶっちゃけ、やりたくないけど、プログラムを修正し、この問題を何とかしてみることにする。

修正の方向性はふたつ考えられる。

【方向性1】の方が汎用性があるような気がするのだけれど、ざっとソースコードを追う限り、ちょっと面倒な修正になりそうだし、すべてのコンテンツの /robots.txt を書き換え、かつ、過去のコンテンツを復活させる場合も、新しいコンテンツを作る場合も、もれなく /robots.txt を置いていくのはちょっと面倒だ。
と、いう事で、汎用性は狭められてしまうけれど、【方向性2】で行くことにする。

以下の様に修正を行う事にする。

MOUNTのオプションに「sitepub={no|ok}」を追加する。
記述はこんな感じ。

「ok」の場合は「Disallow: /」を出力しない。
「no」の場合は「Disallow: /」を出力する。
設定が無い場合、上記以外の場合は「Disallow: /」を出力する。つまり、デフォルトは非公開。

一応、パッチも公開しておく。

delegate 9.9.13用パッチ

ただし、「自分が使えればいいや」レベルでの修正なので、いろいろきちんと作っていない。
使用は自己責任で。

DBD::mysqlで大ハマリしたので、メモ。

問題が発生した環境。

① CentOS 7.6
② Apache 2.4.37（自力でビルド）
③ MySQL 5.6.44（自力でビルド）
④ perl 5.16.3
⑤ DBD::mysql 4.050（自力でビルド）

各ソフトウェアは、ひとつのOS上で複数のバージョンを稼働させる必要から、yum や rpm を使わず、基本的に自力でコンパイルして動作環境を構築している。

この環境で、Apache経由でアクセスし、perl から MySQLに 接続したところ、500エラーが発生した。
エラーログを見てみると、以下の様に記録されていた。

このような組み合わせの環境構築は、これまでに何度も行っているが、はじめて見るエラーだ。
自力でビルドした DBD::mysql の共有ライブラリ（mysql.so）から、自力でビルドした MySQL の共有ライブラリ（libmysqlclient.so.18）にアクセスして、なぜかエラーになっている。どういうことだ？

とりあえず、実行環境を模擬した上で、読み込まれるライブラリを確認してみる。
問題なく読み込まれている。

LD_LIBRARY_PATH を指定しなければ、当然「共有ライブラリが見つからない」エラーになるはずだよな、と、念のため LD_LIBRARY_PATH を外して確認してみる。

が... あれ？ エラーにならない。
「/usr/lib/mysql/libmysqlclient.so.18」を読み込んでる。何これ？

確認してみると、このファイルは確かに存在している。
このディレクトリに、MySQLのライブラリをインストールした覚えはないのだが...。
これは、CentOSが標準でインストールするものだろうか。

自力でビルドしたMySQLのライブラリを確認してみる。

DBD::mysql は「libmysqlclient.so.18」をロードしようとするのだが、コンパイル時に指定した、自力でビルドした MySQL の「libmysqlclient.so.18」に接続できず、標準の「libmysqlclient.so.18」に接続しようとして、エラーになっているようだ。

しかし、「/lib」とか「/usr/lib」とか「/usr/local/lib」とかなら、自動で読み込まれるのはわかるが、「/usr/lib/mysql」が自動で読み込まれるというのは、どういうことなのだろう？
もしかして、/etc/ld.so.conf か？

ビンゴ！
このサーバには mariadb も入れてはいるが、インストールの時に、このファイルを入れた覚えはない。CentOS が勝手に入れているのだろうか。余計な事をしてくれる。

少し古い CentOS の場合、どうなっているのだろう？

mariadb ではなく、mysql として、同じ設定が入っていた。
では、この「/usr/lib/mysql」には何が入っているのだろうか。

「libmysqlclient.so.16」が入っている。
なるほどね、これまでは、バージョンが違っているから、たまたま競合しなかったのかと言う事なのか。

これは困ったぞ、どうするか...。
Apache は、DBD::mysql が共有ライブラリを読み込もうとするとき、/etc/ld.so.conf の設定に従ってしまうので、狙っていない共有ライブラリを読んでしまう。
それならば、Apacheを起動するときに、自力でビルドした MySQL のライブラリを読みに行かせるようにするしかないか。
と、言う事で、Apache の起動時の環境設定を変更する事にする。

以下の1行を追加。

Apacheを再起動。

無事、MySQL に接続できた。
ふぅ...。

最近は「監視社会」と言われるように、いたるところに監視カメラが設置され、交差点や商店街といった屋外だけでなく、店舗内や事務所内にも監視カメラが設置されている。

多くの監視カメラがネットワークに接続できる機能を持ち、ネットワーク経由で監視カメラをコントロールしたり、動画や画像を参照できるようになっている。
ネットワークに接続できるという機能は有用ではあるのだが、「監視カメラがサーバとして動作している」事を理解していない業者が設置したり、素人が設置すると、セキュリティ設定が甘くなり、誰もが動画や画像を見る事ができて、更にセキュリティの設定が甘い監視カメラでは、監視カメラを外部からコントロール可能な状態のカメラ・サーバがインターネット上に登場してしまう。
残念な事に、そのような監視カメラは多数存在し、当然の事ながら、その監視カメラの運用者は、その事に気付いていない。
世の中には、こういったセキュリティの設定が甘い監視カメラを集めたまとめサイトが存在し（たいていはアングラなサイトなのだが…）、動画や画像が公開されてしまっている状態の監視カメラを一覧している。

一覧されている監視カメラの中には、監視カメラの管理機能もしくはプログラムにまで侵入され、「I'm Hacked, bye2」などと、文字を埋め込まれてしまっている（ハッキングされてしまっている）ヤバい状態の監視カメラも存在している。

ちなみに、公開されている状態になっている監視カメラにアクセスする事は、おそらく違法ではない。
なぜなら、アクセスする先が監視カメラというだけの話であって、公開されているWEBサーバにアクセスする事と何ら変わりはないからだ。クライアント側から見たら、アクセスしている先がどんなサーバであるかは関係が無く、WEBサーバと同じく、アクセス可能だからアクセスしているに過ぎないので、アクセスする先が監視カメラ（と思われる）からといって、アクセスすること自体には問題が無いと考えられる。
もちろん、きちんとセキュリティ設定がなされているある監視カメラに対して、パスワードなどを破ってアクセスした場合は犯罪になるのだろうが。

このような、運用者が意図せずに公開されてしまっている監視カメラを運用している人は、どのようなセキュリティ意識を持っているのか気になった。
そこで、以下の様なリアル調査を実施してみる事にした。

いくつかの監視カメラを選び、その動画や画像から施設を特定する。
その施設に実際に電話をする。
その施設が、店内などのライブ中継を行っていない事を確認する。
そして、「今から話す事は重要な事です」と前置きをする。
その上で、監視カメラの映像がインターネットで公開されている事、対処が必要な事を伝える。
電話で対応した人がITオンチと思われる場合は、上役に伝える様に言う。

それを聞いた運用者が、どのように対処をするか見てみた。
サンプルは12件。
結果は以下の通り。
ただし、以下は、あくまでもサンプル数がわずか12件というごく少ない数での調査であるので、偏りがあるであろうことは前置きしておく。

(1).すぐに対処し、監視カメラを停止するなどの措置を取った。

3件。
なんと、わずか3件。すぐに対処をしたのは、たった25%。

(2).「ご指摘ありがとうございます」と対応しながらも、監視カメラを停止するなどの措置をしない。

5件。
42%が、動画や画像がインターネットに流れていても放置。
施設は、宿泊施設、飲食店、パチンコ店、ヘアサロンと様々だが、対処しようとしない。
店舗の監視カメラであれば、「お客様の顔も見えてますよ」と伝えたのだけれど、措置がなされない。
事務所の中が見えてしまっている監視カメラであれば、「事務所の中が見えてますよ。書類も見えてますよ。」と伝えたのだけれど、措置がなされない。
監視カメラを設置した業者に依頼し、監視カメラの設定作業に業者が来るのを待っているのかもしれないが、とりあえず「監視カメラの電源を抜いたらどうか」と思うのだが...。
恐ろしいぞ。

(3).まったく関心を示さない。

3件。
25%が、まったく関心を示さない。
あんた、ネット越しに監視カメラでこっちから見られてるんだよ。こっちは、あんたを見ながら話をしてるんだよ。そんな無関心でいいの？
セキュリティも何もない。大丈夫か？
超恐ろしいぞ。

(4).公開されていて、操作する事もできるようになっている監視カメラだった。

1件。
たいへん失礼致しました。m(__)m

もちろん、多くの監視カメラはきちんとセキュリティの設定がなされていて、不用意にインターネットに情報を流さない様になっていると思うので、上記(1)の25%というのは、あくまでも「きちんとセキュリティの設定がされていない監視カメラのうちの」という事であるから、全体から見たらほんのわずかなのであろうが、「セキュリティに関心が無い人だとこんなもんか」という事がはっきり見て取れた。

ちなみに、こう言う人もいるだろう。

自分が行った先で写真を撮ってSNSにアップしてるじゃないか。
店内で撮影される事がそんな問題なのか？

しかしこれは、そもそも論点が違う。
自分が、自分の意思でアップするのと、他人が、自分の意思と関係なくアップするのとでは、そもそも話の次元が違う。
また、SNSに顔出しをしていない人もいる。個人情報保護法でも、個人の顔写真は本人を特定できる情報とされており、個人情報の第三者提供を行う場合は削除しなければならない情報とされているものであるから、基本的には、本人の承諾なく、勝手に撮影／公開していいものではない。
そもそもSNSに参加していない人も多いだろう。

ぶっちゃけ、店舗内が見えていようと、事務所内が見えていようと、その施設の中の情報だけで完結できるなら、誰にも迷惑をかけるものではないので何らの問題もないと思うが、店舗にはお客様が来ており、事務所には様々な書類が置かれ、ホワイトボードには情報が書き込まれている。
自分がどれだけセキュリティを意識していたとしても、出かけた先で勝手に自分の情報が洩れる事は問題であるし、客先に送った書類から勝手に情報が自分や自社の情報が洩れる事も問題だ。

警察としても、公開されてしまっている監視カメラそのものを取り締まる事はできないのだろうが、映像を公開している者ではない、他の者が迷惑を被る可能性があるのだから、そのような監視カメラを取り締まるべきだと思うのだが、そういう事はできないのだろうか。

このエピソードの続き。

Windows Thin PC

超低スペックなPCに Windows Thin PC をインストールして、シンクライアント端末として使用していたのだが、その超低スペックなPCが故障してしまった。
新しいノートPCを購入してもいいのだけれど、せっかく準備したVM環境も無駄にしたくない。
かと言って、適当なノートPCもない。

そこで、手元で余っている Raspberry pi をシンクライアントとして使えないかと考えた。
シンクライアントとして使用するには、とりあえず、VNC系のクライアントか、リモートデスクトップのクライアントが必要だが、どちらも存在しているようだ。
VM環境側にVNCサーバを新たにインストールするのは避けたいので、リモートデスクトップのクライアントで試してみる事にする。

手元にある Rasbperry pi は、最新の B+ ではなく、ひとつ前の B。
実用に耐えるパフォーマンスが出るかわからないが、とりあえず、やってみる。

OSである rasbian は、2014/09/09 版が出ている。
最新版は容量2GBのSDカードにはインストールできないらしいが、手元に適当な容量のSDカードが無いので、ひとつ前の 2013/02/09 版をインストール。

ネットワークやssh許可などの初期設定を行い、続けて、rdesktop をインストール。

リモートデスクトップに接続。

リモートデスクトップで接続できた。

さすがに開発用としてはストレスが溜まるであろうレベルではあるが、ちょっとネットを見てみるといったくらいには、思ったほどストレスは感じない。
スクロールさせるとパラパラ感はあるが、イラっとするほどではない。
とりあえず、これで行く事にする。

現在広く使われている Microsoft Windows XP は、来年4月にサポート終了の予定になっている。
どこの企業でも、Windows Vista、Windows 7、Windows 8への移行を始めていると思う。
多くは Windows 7 に移行でしょう。

そんな中で、2013/04/30付 中日新聞の1面の記事。

むむむ、「Windows XP を使い続ける」という選択肢があるのか。
もちろん、現在においても、環境によっては Windows 95 や MS-DOS を使い続けているところもあるとは思うけれど、官公庁が事務で使っているPCを更新しないとは…。

ネットワークに接続されないよう、「LANポートにテープを貼るなどの対策をする」とは書かれているけれど、ウィルスの進入経路は、必ずしもネット経由とは限らない。
USB、フロッピーディスク、CD、DVDなどからも感染の可能性がある。

また、「ウィルス対策ソフトは引き続き機能する」とも書かれているが、本当だろうか。
トレンドマイクロにしろ、ノートンにしろ、Windows XP はサポート対象から外すはず。
Windows XP を引き続きサポートするウィルス対策ソフトはあるとは思うけれど、大丈夫なんだろうか。

アサヒ飲料株式会社から発売されている「ワンダ モーニングショット」。

最近流れているこのCMなんだけど…。

シリーズ第3弾「ＩＣカード」編

このCMのストーリーは…
主人公の島崎（AKB48）が、ゲートを通ろうとICカードをかざすけど、なかなか反応しない。
そこへ、後ろから来た先輩サラリーマンがカードをかざしてゲートを開ける。
島崎はゲートを通過する。
というもの。

ありそうな話ではあるのだけれど…セキュリティ的に見たら、これはマズい。
個人を特定するためにカードを配布しているのに、他人のカードで入れてしまうのは問題があると思うのだが…。