2016年の素数日一覧
一連のツイートが思ったよりバズったので…
「本学では2016年がもちろん素数ではないと落胆する学生が多いようですが、2016年は1984年以来32年ぶりに、2進法で表したときに連続する1と0で表現できる年です。」って東工大学長祝辞が浮かんでしまった…
1984=11111000000 2016=11111100000
— 上原 哲太郎 (@tetsutalow) 2016, 1月 6
「本学では2016年がもちろん素数ではないと落胆する学生が多いようですが、2016年は1953年以来63年ぶりに、n以下の自然数の総和で表される年です」の方が良いかな
n=62つまり1+2+…+62=1953、n=63つまり1+2+…+63=2016
— 上原 哲太郎 (@tetsutalow) 2016, 1月 6
おお素敵。ついでにn=62の1953年も昭和28年。 https://t.co/8WVRws7QEc
— 上原 哲太郎 (@tetsutalow) 2016, 1月 7
ついでに2016年の素数日(日付を8桁で表すと素数になる日)を貼ります。
20160319
20160401
20160403
20160529
20160601
20160607
20160611
20160709
20160727
20160809
20160817
20160821
20160923
20161007
20161013
20161019
20161021
20161027
20161103
1月と2月と12月には素数日がありません。4月1日は素数日なので東工大の学長も祝辞のネタには困らないと思います ;-)
ついでに書いたヘボいコード。久々にRuby書いたなぁ…
追記:
もっと美しく書いてる人がいました
ついでにWebで計算できるようにしてる人も。
2016年の素数日
便利だけど気をつけないと危ないChrome Remote Desktop
Windowsデスクトップに遠隔でアクセスしたくなる事がありますが、皆さんどうされてますか?
昔から定番はVNCを使うことでした。個人的にも昔はRealVNCやUltraVNCを使っていましたが、VNCは画質もイマイチですし音声も転送できないのでもう少しマシな方法が欲しいところです。
Windowsの場合、純正のプロトコルであるRDPを用いた「リモートデスクトップ接続」なら音声も転送できますし画質も綺麗です。ですが、これを利用しようとすると、遠隔操作される側が(Homeやwith Bingでなく)Professionalなど上位のエディションである必要がありました。ところが最近、HomeエディションのWindowsでもRDPによるリモートデスクトップ接続を可能にするRDPWrapなんてものが現れました。個人的にも最近は専らこれに頼っています。Windows 8.1 with BingやWindows 10 Homeあたりでも問題なく遠隔操作できるので大変便利です。さらに最近はMicrosoft純正のAndroidで動作するクライアントやiPad/iPhoneなどのiOSで動作するクライアントもあるので、時々iPadから接続したりして快適に利用してます。
そんなわけで個人的にはRDPWrapですっかり満足しているのですが、他の選択として、最近GoogleがChrome Remote Desktopなるものを出していることに気づいてはいました。
ChromeはChromecastに向かってタブだけじゃなくデスクトップを送信(キャスト)する機能があるので、Chrome Remote Desktopもこの技術の延長で実装されてるのかなと思っていたのですが、先日ちょっと調べる機会があって動作を見てみたらこれがとんでもない勘違いであることに気づきました。確かに便利ではあるのですが、なかなか怖いということもわかったのでまとめておきます。
Chrome Remote Desktopのインストールの方法&使い方
インストール手順や基本的使用法そのものはここに詳しいので譲ってしまいます。
この手順を見ればわかりますが、サーバPCには、chromeremotedesktophost.msiのインストールを通じて「Chromeリモートデスクトップサービス」なるサービスが登録されます。
この結果、対象となるサーバPCはChromeの起動の有無やログオン状態とは関係なく、電源onであればいつでも遠隔操作可能となります。Chrome Remote DesktopというからにはChrome起動中だけ遠隔操作可能なのかと思ってしまいそうになりますが(私だけ?)実はChromeとは無関係であるというのがミソ。ログオン前でも遠隔で接続してログオン操作から行うことが出来るので、確かに大変便利です(例えば再起動が必要になる状況になっても気軽に遠隔から再起動できます)が、一方で他人が利用中のPCのデスクトップも(許可さえされていれば)いつでも共有できてしまう=操作可能になってしまいます。なお遠隔操作時には、画面中央下に「デスクトップは現在<googleアカウント名>と共有されています」と表示されますので、遠隔操作されていることに気づくことはできます。この機能はどうも、PC操作の遠隔サポートなどを想定しているのでこのような動作になっているようです。
遠隔操作できる条件
調べた範囲では、サーバ側PCのデスクトップが共有可能になる=遠隔操作可能になる条件は以下の場合のようです(間違っていたらご指摘下さい)。
- サーバ側PCの管理者権限を持っており(=ローカル管理者権限のあるアカウントを持っている)あらかじめ対象PCを遠隔操作可能なGoogleアカウントを指定してあること。管理者権限はChromeリモートデスクトップサービスのインストール時と、遠隔操作可能なGoogleアカウントの指定時(PIN指定時)の2回必要になります。遠隔操作可能とするためには、対象となるPCのデスクトップでの直接操作が必要になります。また、1台のPCに対して遠隔操作可能なGoogleアカウントは1つしか指定できません。
- サーバ側PC、クライアント側PCともにGoogleの特定のサーバへの443/5222TCP接続と、UDPの対外接続が可能であること。NAT配下で構わないようですが、NATルータのUDP Hole punchingについてどんな制限があるかはまだ調べていません。重要なのは、サーバ側PCに外からTCP接続を必要としない、つまり、Port forwardingやUPnPを必要としないことです。UDPが必要なのでProxy配下の端末は操作できませんが、VNCやRDPと違ってTCP接続の穴を外から開ける必要がありません。
ネットワーク的な動作
実際のネットワークトラフィックがどのようになるかは、この辺を読むと推測できます。
(1) サーバ側
Chromeリモートデスクトップサービスを担っているremoting_host.exeから、chromoting-host.talkgadget.google.comのport 5222にTCP接続されています(プロトコルはXMPPの模様)。また、実際のリモートデスクトップ接続後はランダム(だいたいは60000番台)なポート番号のUDPトラフィックをクライアントとの間で直接やりとりしますが、ここに書いてある設定によってポート番号の範囲を12400~12409に制限できるようです。
(2) クライアント側
ドキュメント読む限りはchrome.exeからchromoting-oauth.talkgadget.google.comのport 443とchromoting-client.talkgadget.google.comのport 5222にTCP接続するようです。ただ、私が試した範囲ではChrome.exeから5222への接続は確認できませんでした。代わりにport 5228へのそれらしい接続は見つかりました(バージョン47.0.2526.28の場合)。一度接続するとUDPトラフィックをサーバ側PCとの間で直接投げ合います(ポート番号はやはり基本ランダムで、設定により制限可能)。
なお実際にはGoogleのサーバは(現在のところ)3種とも全てwildcard-talkgadget.l.google.comへのaliasになっているようです。
問題となりうる状況
すぐに思いつく問題では、「UDPが通ればFirewall配下でも遠隔操作可能になるので、組織内のPCがセキュリティポリシーなどに反して遠隔操作可能にされているかもしれない(その結果組織のセキュリティに影響する)」という話です。ただ、PCの管理者権限が必要ですし、NAT接続などUDPが通らないとダメという制限がありますので、小企業のように企業内PCの管理者権限がエンドユーザに渡されているようなところでない限りあまり問題にならないかも知れません。
一般利用者にとっては「いつのまにか画面が他の人に覗かれているかも知れない」という問題があります。これはChrome Remote Desktopが現在使用中の画面状態(セッション)のまま他者に共有させるからです。この挙動はVNCと同じですが、純正リモートデスクトップ接続であるRDPとは違います(RDPの場合使用中のセッションを遠隔で奪うには使用者のログオンパスワードが必要)。共有状態になっているかどうかは画面に「共有されています」という表示が出ているかどうかで解りますが、気づかない可能性はあります。例えばログオンした画面をロックせずに離席してたら、覗かれても気づきませんね。
あと細かいことですが、通信プロトコルが全体としてXMPPをベースとしたものだと思われるのですが詳細は分からないので、リモートデスクトップ接続利用に伴ってGoogleにどのような情報が渡っているのかよく判らないのも気になります。これについてはヘルプ中の「Chrome リモート デスクトップの安全とセキュリティ」という節に「ネットワークの待ち時間やセッションの継続時間に関して、データを完全に匿名で収集、保存」とあり、不要な情報は保存していないと宣言されているので、これを信じる限りはそれほど心配要らないと思うのですが。
Google Chrome Desktopの使用を禁止する方法
端末に管理者権限がない利用者が勝手にChrome Remote Desktopの利用を有効にすることはできないので、この点は安心なのですが、ネットワーク管理側で一網打尽にしようとすると少し面倒です。TCP Port 5222による対外接続を塞いでしまうとできますが、他のXMPP使用アプリケーションも(どれくらいあるかわかりませんが)塞がれてしまいます。きちんと管理する方法については、Google自身が下記のような情報を提供してくれています。
リモートでデスクトップを管理する - Chrome for Work ヘルプ
上記URLにはいくつかのGoogleのホストをDNSでブロックせよと書いてあるのですが、これは管理者にとってはちょっと面倒な上、ちゃんと考えておかないと抜け穴が残っちゃいますよね(例えばDNSサーバを管理外のものに変更されてしまうと抜けられてしまう)。まぁ結局ちゃんと端末管理したければNATなんかせずにProxy設置しなさいということなんでしょう。
ということで、何かのご参考になれば。
あけましておめでとうございます
あけましておめでとうございます。
旧年中は大変お世話になりました。今年もよろしくお願いします。
今年の抱負ですが、セキュリティ人材の育成にフォーカスしたいと思っています。もともと人材育成には力を入れてきたつもりではあるのですが、昨年の年金機構の事件以降、業界的な人不足がとんでもなくなっているのを見て、危機感が強まりました。社会人のリカレント教育も含め、セキュリティ人材を産み続ける力を大学が持つことが大切で、そのために私が何が出来るか、私が所属する立命館大学に何が出来るか、考えながら走るような一年にしたいと思います。といっても私一人で成し遂げられるわけがないので、是非とも同じ想いを持つ人たちと一緒にさせていただきたく。ご協力よろしくお願いいたします。
というか正月くらいblog書こうかと…
Google Chrome for Windowsを32bit版から64bit版に移行する
Windows版のChromeが32bit版だったのに気づかず使ってて64bit版にしたら軽くなったという話がFBのTLに流れてきて、そういえば自分も出た直後に試験的にサブマシンに64bit版を入れて使ってみたもののメインマシンは放置してたなと思い出し、移行しようとしてちょっとだけハマったのでメモっておきます。
まず自分でお使いのChromeが32bitか64bitかの確認方法は以下の通り。まずメニューから「Google Chromeについて」を選択。
(以下の画像は潰れて見にくい人は画像をクリックしてオリジナルサイズを表示して下さい)
概要のバージョン番号を見て、64bitとあれば64bit版ですが、何もなければ32bit版です。
64bit版のダウンロード方法がまた面倒で、普通にダウンロードしに行くと32bit版になってしまいます。そこで、「別のプラットフォーム向けのChromeをダウンロード」します。
Windows 8/7 64bitを選択。
利用規約の承諾などを求められますので承諾するとChromeSetup.exeが落ちてきます。
で、これを実行すれば64bit版をインストールできるのですが、私の環境では「実行中のGoogle Chromeと同じバージョンをインストールすることはできません。Google Chromeを閉じてからもう一度お試しください。」と出てインストールできませんでした。
Chromeのウィンドウを閉じても同じ。で、タスクマネージャーで調べるとChromeのプロセスが残ってます。ここで手でプロセスを殺したり、再起動したりしてからインストールしてもいいのですが、そもそもなんでChromeは閉じたあともバックグラウンドで動き続けるかは、そういうの機能があるからなので、そちらの機能を切ることで対処しましょう。
まず、再びメニューから今度は設定を選びます。
詳細設定を表示します。
下の方に「システム」という項があって「Google Chromeを閉じた際にバックグラウンドアプリの処理を続行する」って言われますが、これがプロセスが生き残る原因です。なので、64bit版のインストールに失敗した人は、まずChromeのこのチェックを外します。
あとはChromeを閉じて、再度ChromeSetup.exeを実行すれば良いはずです。もしバックグラウンド実行機能(メッセージの通知とか)を使いたいのであれば、インストール終了後に再度設定して「バックグラウンドアプリの処理を続行する」を有効にするのをお忘れなく。
なお、Chrome 64bit版はセキュリティ的にはより安全になるはずなのでお勧めできますが、性能が向上するかは環境依存ではないかと思います。基本性能は上がっているようですが、どうしても32bit版より少しメモリ食いになると思いますので、メモリが厳しい環境では期待外れかも。あと、さすがにもう絶滅寸前じゃないかとは思いますがNPAPIが必要なプラグインを使っている人はトラブります。でもこの1月でNPAPIはデフォルトで一部を除きブロックされるようになったようですし、9月には完全にサポートがされなくなる予定です。
関連:
Chromium Blog: The Final Countdown for NPAPI
ALS Ice Bucket Challenge by Tetsu=TaLow : Behind the Scene
昨日投稿したALS Ice Bucket Challengeビデオ、アップロードまでの経緯のメモ。もし今後こういうのを受ける人がいればご参考に。
- 21日朝、仙石さんからFBでメッセージ。「どうもアイスバケツチャレンジが今夜あたり回ってきそうなんだけど、次受けてくれないか」という旨。いつか回ってくるだろうと思っていたけど早かったので驚きつつ、受けるよと即答。ただ22日は終日出張中なので余り早く回ってきても24時間制限守れないよ?と答えると、まぁ遅く回すよという返事。なら土曜の午後ゆっくりやればいいかと考える。
- まず考えたのは、どうするか。「寄付せず3人に回す」「寄付して止める」「寄付しつつ回す」「寄付しつつ、ルールを勝手に変更して回す」。よくある「チェーンメール批判」に関しては個人的には結論が出てる。寄付することで止めることができる以上無限連鎖が止まる仕組みは元々あるのでチェーンメールではないし、その辺がよく解ってる人はルールを変更して次の指名を1人にしたりし始めているからこれはいつか止まるタイプだ。だから私も最初は誰か1人だけに回して「今後は1人です」って宣言する「寄付しつつルール変更して回す」案にしようかなと考えていた。
- しかし寄付先を調べているうち、日本ALS協会がアイスバケツチャレンジに参加して3日しか経ってないことに気づいた。さらに見ているとちょうど寄付額が出てきた。3日で250万円の寄付。まぁ初動としてはいい成果ではあるけど、絶対額がちょっと足りない。ALSAが数十億集めていることに比べたらあまりに心許ない。まぁALSAが研究ファンドであるのに対し日本ALS協会は患者団体的な性格が強いようなのでその差はあるだろうが、日本ALS協会も研究基金を用意している。これは個人的には研究基金指定して寄付したい。よし日本ALS協会の名前を広める活動と捉えよう。ということで3人版のままで決行を決意。日本ALS協会の名前が目にとまるように、ちょっと工夫したいな…ということでビデオの出だしのネタを思いつく。少しパワポで試作するとすぐそれっぽいアニメが作れるとわかった。写真使用の許諾を先に仙石さんにとっておく。彼曰く「よくわかんないけどOK、ただ私LINE使ってませんよ」。
- しかし3人集めるとなると大変。ボランティアは強制されてやるべきものではないので、事前ネゴは必須。ボランティアに理解がありそうで、かつ「寄付」「氷水」どちらか選択のために余計な障害がない人じゃないといけない。つまり、1万円or$100の寄付くらいでは動じないくらいには収入ある人で、かつ「顔出しビデオをYouTubeにさらすことができる人」、さらにできれば分野がそれぞれ違う3人を次に指名してくれそうな人から選ぶことが必要。ということでだいぶ悩んだ。それで該当しそうな人にいろいろ声をかけてみたが、案の定かなり断られた。人それぞれの考え方はあろうから、説得はせずすぐ引き下がった。しかし困った、これ想像以上に大変だぞ。
- まぁ何にせよ寄付はするつもりなのでそちらを先に。最初ALSAに$50、日本ALS協会に5000円と思っていたが、ALSAは$50という選択肢がなく、$60があったのでそちらに。日本ALS協会には振り込んだ後、メールを送って研究基金に使途を指定しようかと思ったが、きっと急に寄付が殺到して事務負担も増えてるだろうしと直前で考えを改めて使途不問である旨をメール。
- 最初は1人にしか回さないつもりで声かけをはじめていて、途中で3人にしようと考えを変えてしまったので1人しか集まらないうちに22日になってしまった。出張中は声かけも十分できないだろう。どうするかなぁと思いながら東京。新幹線内では仕事を片付けつつ、東京では会議をハシゴする状態でネットも十分見られない。で、会議と会議の間の移動中にFB見るともう仙石さん決行済み。うわ!早いよ!土曜の夕方くらいまででいいと構えていたのに昼過ぎがリミットということで焦る。だいたい土曜日は実家に帰る用事があるのでさらに時間が限られるではないか。まあ幸い仙石さんは次に回すにあたって何のルールも言わなかった。じゃあ24時間ルールも緩く考えてもいいか?
- 会議中にもう一人から返事があり、これで2人確保できたけどまだ1人決まってない。きょうの会議はそのまま夜の懇親会があるのでその場で誰かに声かけしようかしらん?それともFBでフォロアーに広く声がけしようかな。いやまぁ2人に減らすというのも手か?考えているうちに夜になってしまう。懇親会終わっても決まってなかったらFBで募集だなぁと思ってたら、ダメ元でメール投げてた最後の一人から懇親会中に受諾のお返事。ありがたや。これで土曜の決行決定。
- 朝起きてみたらもう、同時にバケツまわっていたおごちゃんが決行済み。私もやらなきゃなぁとか覚悟を新たにしつつ、家族を連れて実家に帰る必要があったので、実家で撮影することに。着替えだけ用意していって、実家でバケツと氷かりて昼食後、実家マンション内の広場でデジカメで撮影。撮影したのは妹(Canon PowerShot S110)、一発撮りなので失敗したときのために妻が隣でiPod touchで撮ってくれた。音声テスト以外はリハもしなかったので思いつきでしゃべっており、結構細部がボロボロ、テロップ入れて修正するか…という気になる。
- とはいえ時間が無いのでUpしないと。実家でそのまま作業。まずOPを作る。PowerPointでざっくりアニメ作ってビデオとしてエクスポートして、ビデオ編集ソフトでつなぎテロップをいれる作戦。OPアニメ、最初背景色を黄緑で作ってたら横から覗いてきた妻が、LINEは背景が空色っぽくて吹き出しが黄緑っぽいとかツッコミを入れ出す。そこかよ。大人しく修正。
- ビデオ編集は最初、Lifebook SH90/M附属のCorel DigitalStudioと思ったが、はじめて使うだけあってよくわからん!しばらく格闘して断念。Windows8系はMSのムービーメーカーがないので、ダウンロードから始める。泥縄。でもこれは何度か使ったので慣れてる。とりあえずテロップなし版を作ったところで24時間リミット越えてしまったので、あわててUpload。Blogもざっくり大急ぎで書く。
- 夜、家に帰ってから再度ムービーメーカーを使い、字幕を入れた版を作って再投稿、blogも入れ替え。特に会社名間違えた丸山さんには申し訳ない。
ALSアイスバケツチャレンジがまわってきたので受けました
SNSの拡散力を考えたら遠からず私のところにも来るかなぁと思っていたら、思ったより早く来てしまいました。仙石さんからALSアイス・バケツ・チャレンジの挑戦を受けたので、受けて立とうと思います。
この活動、ALSという病気に対する認知を広げる上で大変うまく行っていると思うのですが、最近は批判もあるようです。もちろん難病はALSだけじゃないとか、今は日本にも支援を求めている人が広島や福知山、そして東日本大震災の被災地にもいるというのは確かですが、一人の人がどうせ全部は出来ないのだし、それぞれの人が出来ることをやればいいのではないのでしょうか。ALSは、ホーキング博士が戦っておられる病気として有名ですが、彼のように進行が遅いのは幸運な例であって、実はALSが多くの人にとっては進行の早く5年以内に半数の方が亡くなられる病気であること、そして残念なことに治療法もなく、対処療法しかないということは意外と知られていないのではないでしょうか。私にとっては縁の深い土地である和歌山では比較的多い病気であることも、この病気に対する個人的な関心を高めているので、このバケツが回ってきたら是非協力したいとは思っていました。
ということで、次は是非つぎの3人の方に私の挑戦を受けて頂きたいと思います。
宜しくお願いします。
注:21:00 動画を字幕入りに入れ替えました
Mt.Gox社に対するDDoS攻撃という読売新聞報道に寄せたコメントの補足
本日3月9日付の読売新聞朝刊トップはこの記事でしたが
マウント社に「DDoS攻撃」毎秒15万回(読売新聞)
この紙面版には私のコメントが載ってます。ただ、記事全体と合わせると私のコメントの意図がうまく伝わっているかわからないので少しだけ補足します。
- DDoSそのものと、Mt.Gox社からBitcoinが盗まれた?件は無関係なのではないかと思います。最初は関係があるかもしれないと思っていました。BitCoinのプロトコルの実装の穴=取引展性問題(参考)を突いたとするとその攻撃がそもそもDDoSになったり、あるいは単純DDoSかけることで裁定を遅らせようとした可能性もあるからです。ですが、もしこの記事にあるハッカーの言い分が正しいとすると、ここまでできているなら直接不正アクセスで侵入して堂々とBitcoinを盗んでいる可能性が高いと思います。
- DDoSに技術が要らないよ、とコメントしたのは、アングラにあるbotnetレンタルサービスとか使ってるかもしれないね、という意味です。
- 技術誇示の愉快犯じゃないかなとコメントしたのは、すでに上述のように犯行声明的なものが出てしまっていることを根拠にしています。経済的利益を得ようというのが主目的ならそんなことはしないでしょう。Bitcoinを大量に保持していても現状は使い道が限られ、かといって一気に大量に現金化すると足がつくのでやりにくいため、現実的な経済的な利益はあまり大きくないだろうと思います。
なおBlockchainを追っかけるともっといろんな情報が得られるはずですが、私は主にサイバー攻撃という観点からしか見ていませんので、外している部分もあるかもしれません。チラチラ聞いている話ではどうもこの話、単純な不正アクセスによる窃盗では説明できない点もあるみたいなのですが、その辺はより深く追いかけている人から詳報が出てくるのを待つことにしたいと思います。