山本ゆうごブログ

山本ゆうごの仕事メモ

接続元のドメイン名×メソッドでアクセス制限するのが楽で効果的

攻撃者が捕まるケース

相変わらずセキュリティの問題は出てきていますが、その犯人ってあっけなく捕まったり捕まらなかったり。一方で携帯で匿名掲示板に殺害予告を書くとあっけなく逮捕されてる。これは、接続元のIPアドレスが分かれば、携帯電話会社に警察が問い合わせて契約者を特定できてしまうため。

携帯電話って比較的本人確認が厳格なので、すぐに足がつく。なので、本当に攻撃をしている人達って、日本の通信会社を使わない。IPアドレスで言えば中国が多い。

じゃぁ接続元を日本に絞ればいいじゃない

日本のIPアドレスはだいたいわかる。そして、.htaccessみたいなところに書いておけばいい。 日本[jp]に割り当てられたIPアドレスの一覧 : ipv4.fetus.jp

ただしこの制限をそのまま入れちゃうと、たまに不便。AndoridのChromeとかは、Googleのプロキシを通してアクセスすることで、通信量を節約している。そうなると接続ができない。ちなみにこの制限で私個人も、GyaOとかスカパーのサービスに接続できなくて苦労した。ただし、それくらい乱暴だけどよく使われている手法ではある。

さらにGoogleクローラーは許可したかったりする。

じゃぁ中国と北朝鮮のみを制限すればいいじゃない

そういうフィルタもある。 krfilter : ipv4.fetus.jp

ただし、.htaccessレベルでドーンと制限しちゃうと、「中国からは拒否してるよ!」ってことが攻撃者にバレちゃう。対策練られやすい。

Location × メソッド × ドメインで絞る

例えば、WordPressではadminのディレクトリは、自分しかアクセスしないのなら、自分が契約しているプロバイダのみに絞る。自分が接続しているプロバイダのドメインは、確認くんとかで見れる。

確認くん

私は今、Biglobeでアクセスしているので、mesh.ad.jp のみを許可すればいい。ドメイン別に許可を与えるのは昔ながらのApacheの機能でもできる。

ミケネコの htaccess リファレンス

固定IPアドレスがあるといいのだけれど、そこまで厳密でなくても、プロバイダ外からのアクセスを防止するだけでも1000倍リスクは減る。

また、ドメインでの制限を加えると、IPアドレスからドメイン逆引きするので、パフォーマンスが落ちる。だからログインにつかうようなPOSTメソッドだけに絞るといいでしょう。ログインが高速である必要はない。あと、攻撃者のIPアドレスって、ドメイン名を持ってないことが多いので、逆引きに時間がかかる。攻撃者のみに嫌がらせもできて一石二鳥。

アプリレイヤーでカバーする方法

Webサーバ自体にドメインの逆引きをやらせるのってインフラ面ではハードルが高かったりする。ログイン周りが一番狙われやすいので、ログインの直前に接続元のチェックを入れるという方法もある。IPアドレスPHPでは、$_SERVER['REMOTE_ADDR']で取得可能。

<?php
echo gethostbyaddr("60.237.175.89"); // => flh1aef089.tky.mesh.ad.jp
require 'resolv'
r =  Resolv::DNS.new(:nameserver => ['8.8.8.8'])
p r.getname("202.225.233.218").to_s # "FLH1Amj218.tky.mesh.ad.jp

これで、ドメインが絞れる。docomoからのアクセスがいいなら、「spmode.ne.jp」で絞ったりする。

大半の日本のプロバイダは、.jpで終わるから、それで判断してもいいけど、ソフトバンクはbbtech.netだったりするので面倒。

アプリレイヤーで、接続元ドメインを把握できれば、ユーザが別プロバイダからログインした時に強く警告を出すというようなことも可能。

まとめ

セキュリティに絶対はないので「何桁リスクを減らせるか」を考える。鍵をガチガチにかけると一般ユーザも不便になる。一方で監視カメラは一発目の犯罪の防止はできないが、「足が付きやすい」ことから、抑止にはなる。ピッキングは防げないけど、ドアにカメラがあるとかなりハードルが高い。

Gmailで水平線<hr>を挿入する方法

そう言えば、gmailで水平線ってどうやって入れるんだろうと思って検索すると、こうなる。

oshiete.goo.ne.jp

  • 教えてgooの検索結果とそのコピーサイトで占められる
  • 回答は「何が仰りたいのかよくわかりませんでした。」
  • それがベストアンサー

上からクリックしていくと、このゴミみたいなベストアンサーが続くのでイライラする。

これが正解。

  • gmailの編集画面はhtmlの直接編集はできない
  • しかし、ブラウザでレンダリング済みの画面からのコピー&ペーストは可能
  • どこかしらのサイトから、水平線をコピー&ペーストで可能
  • 手元のPC上でHTMLファイル作って、ブラウザで開いた結果をコピ&ペーストで実現可能
  • 他にも、テーブルでもコピペすれば表現可能

ユーグレナのコアバリューを考えてみる

この記事 http://www.recomtank.com/entry/euglena をみて、いろいろ思うところあり。

起業から上場までのストーリーはR&Dからのスタートアップということで、注目は浴びておりました。

ただ、ビジネスとしては、健康食品というところで落ち着いている。

元は、食糧問題を解決するためのソリューションだったはず。しかしながら、ガチの貧困地域は金がないので売れない。そもそも貧困地域に直接食い物を渡すのではなく、本当なら貧困地域が貧困でなくするようなソリューションが必要。

一方で、貧困が解消するにつれ国民が金を持ち始めると、完全栄養食品よりも不健康な食事の方がニーズが高く、最終的にはダイエット食品に金が集まる。

本当に貧困地域の課題解決が金になるのなら、今頃アース製薬は超巨大起業になっててもいい(今でも大企業だけど「蚊を退治する」という社会的価値からすればマイクロソフトなみの会社でもいいくらい)。

そんで、ユーグレナです。食糧問題解決は金にならない。もう一つのイノベーションとしては、「燃料が作れる」ということ。石油王になれるとなるとこれは急に見る目変わりますよね。すごいすごいと。

1平方kmの培養プールで生産できるミドリムシは油脂換算で日間約11.4t

とある。一見すごい気がするが、1平方kmってでかすぎる。100万平方メートルなので。現実的には千分の1の1,000平方メートル換算にしましょう。20×50メートルのプールならそのスペースで何できるかが分かる。 改めて計算すると、

1000平方mの培養プールで生産できるミドリムシは油脂換算で日間約11.4キロ

ミドリムシの油脂の密度は知らないが、ざっくり10リットルとする。

ちなみに10リットルの原油がどれくらいかの価格かというと、今は1バレル(160リットル)40ドルだから、1リットルあたり約25円。原油と同じ価格で売るなら(売れるのか?)、一日250円の売上。プール1個の面積から燃料を得ようとすると年間では約8万円の売上。これちょっと厳しい。同じ面積つかうなら別の商売したほうが良さそう。

まとめると、ユーグレナ自体の技術的ブレイクスルーはすごいのだけど、商売を考えると、以下の点が課題。

  • 食料問題の解決はビジネスにはならず、必要とされているのは痩せ薬
  • 今あるエネルギー問題は、エネルギー不足ではなく、エネルギー価格が安すぎて投資が回収できないという問題

元を正せば、食べ物も燃料も原価までたどるとめちゃくちゃ安い。商売しようとすると、ある程度の「期待価値」みたいなのが必要で、結局将来的にも健康食品としてのポジションが一番ビジネスになるとは思う。「完全食品ミドリムシだけで絶食合宿!」みたいな「コト消費」にすれば、客単価15万もありえる。

あとは、日本の自治体が学校給食の地産地消をうたっているわりには地元の農産物の生産能力がないので、学校給食を独占するという手もある。

Google Cloud Strage の東京リージョンができたので、巨大なパラパラ漫画を実装してみた

やっとGoogle Cloud Strageの東京リージョンがオープンしました。 S3+CloudFrontの組み合わせのように使えるので、配信にも便利かも知れません。

手順は以下の通り。

  • バケットを作ります
    • バケット単位でリージョンは選べますが、東京リージョンが選べるのは、Regionalというストレージクラスだけのようです。
  • ファイルのアップロードはコンソールからできる
    • S3でもそうですが、ブラウザからアップロードできます。
    • フォルダのドラッグ&ドロップでもアップロードできます。
  • 一般公開はファイル単位
    • フォルダ単位での公開ができません
    • 「デフォルトのオブジェクトの権限の編集」はできますが、アップロードする前に設定する必要があります

そして、大量のjpegをアップロードして、パラパラ漫画にしてみた

画像を高速に切り替えてアニメーションにするというのは、CSSスプライトでよくやる手法ですが、今回は大きな画像でコマ数も多いので、そのままロードします。アニメーションが始まるちょっと前に、JavaScriptの中で、Image オブジェクトをnewして、srcにセットしておきます。あとは、setTimeoutで、ちょっとずつずらしながら、1個のimgタグのsrcを書き換えていくだけ。

デモ

https://storage.googleapis.com/yugoyamamoto/parapara/dance.html

1280pxの巨大な画像を24fpsで動かしてみましたよというデモです。この実装では、3割ほど画像がロードされたらアニメーションが動き始めるロジックにしています。あとは、ロードしながら追いかけてアニメーションします。一応スマホでも動きました。流石にこのサイズのimageオブジェクトが大量になると動きは怪しいですが、画像が一度キャッシュされるとスムーズにアニメーションします。(手元のGALAXY Note3での検証)

影響力の武器をベースにした転職活動

「影響力の武器」というまぁまぁ有名な本がありまして、それを転職活動につかうとどうなるかという話。実際に採用する側もこういうことで左右される。

理由付け

志望動機そのものだが、大した理由でなくてもいい。理由があることそのものが大事。過去の自慢話した後に「なので御社にも貢献できると思ったんです」でいい。

返報性(reciprocation)

何かお土産を持ってく。交渉の現場では、「いい情報」。競合他社の採用現場の状況がわかるといい。やりすぎると秘密の漏洩になるのでほどほどに。

希少性(scarcity)

他社での採用活動が進んでいるように見せると、早く決めなくちゃいけないと思う。

権威(authority)

いわゆるアレオレ詐欺。前職ですごい仕事をしていると思わせる。実際にやっていれば素直に「分かりやすいラベル」でアピールする。

コミットメントと一貫性(consistency and commitment)

一般的な交渉事では、小さな合意を相手から引き出して、「やっぱりヤメ」ということができなくなるようにする。採用の現場では、面接とは別に面談をお願いして、「次の約束」を細かく取りつける。何度も会ってるということ自体が「正式採用間近」に見える。逆に急にアポが取りづらくなったら、「一貫性」を保つために、最終結論もNGの見通しが高い(これは、普通の営業現場でも同じ)。

好意(liking)

そもそも、御社のことが好きですということは最低限言う。

社会的証明(social proof)

本出してたりすると分かりやすい。原稿料が安くてもいいので、共著で何か執筆しているとAmazonに著者として名前が載る。

SQLとO/Rマッパーのポエム

SQLとO/Rマッパーのポエム

http://qiita.com/kantomi/items/f527bc717b10e86335af に関して、最初にO/Rマッパーを見た時の感想としては、同じ印象をもちました。

O/R マッパはSQL知らなくてもいい説には反対

なので新人研修の際には、ActiveRecordを触らせる前には必ず、素のSQLも手書きで一通り書かせている。phpmyadmin やsequel proを使う場合にも素のSQLを書かざるを得ない。そんなのエンジニアじゃなくて今どきのWebディレクターならやってる。

したがって、ORマッパを使ったところで、二重に勉強しないといけないというのが正解かなと。

わたしが作ってる研修メニューでは、 ・素のSQLを一通り覚える ・Railsを通すのではなく、素のRubyにActiveRecordeだけをrequireして、コードの中で接続し、 ActiveRecord::Base.logger = Logger.new(STDOUT) で、どんなSQLが流れているかを一通り眺めながら、ActiveRecordの各メソッドが発行しているSQLを見せる。 ということをしている。

そこまでして二重に学習しなくてはならないの?って質問には、はいすみません、今どきの子大変ですね。でもソースはちょっとだけ見やすいですね。

逆にSQLをとことん高度にしてアプリまで書いちゃうというアプローチ

実はそういうプロダクトがあった。OracleSQLPL/SQLと言って、普通のプログラミングもできる。ストアドプロシジャとか呼んでる奴。プロダクトとしては、KeyWeb Creator という名前だった。しかしながら、そもそもストアドプロシジャの外でPL/SQLをつかう人もいなく、制約も多かったので、陽の目を見ることはなかった。ということで、市場原理の中ではSQLでは最強ではなくなった。

O/Rマッパーをつかうってことは、RDBをNoSQL的に使ってない?

これはYES。複雑なSQL使えないし、基本的な動きは、主キーでダイレクトに取ってくるだけの動きが多い。

心配な点としは、RDBはKVSにくらべて機能が大きいために主キーダイレクトで引っ張ってくるにしても、オーバーヘッドも大きいのではないかという懸念。これはエンジンごとにすごく違う。mysqlはスレッドタイプのコネクションなので、コネクションの接続からしてめちゃくちゃ軽い。

この辺の経験値というのが、業務アプリとユーザーサービスと結構違っている。 業務アプリでは、DBエンジンはOracleバッチ処理性能が大事 ユーザーサービスは、 DBエンジンはMySQLで、ユーザーレスポンスが大事 ユーザレスポンスを大事にするときって、凝ったSQLを書かないというのが割りと大事。レコードの件数によって、プランが変わるようなのは避けたい。

例えば、画面には数十件しかでないのだから、JOINせずに、主キーダイレクトで20回くらいアクセスが発生しても一向にかまわないのだ。

ここでも、RDBをNoSQLみたいに使ってるという批判はアリそうだけれど、主キーで高速にデータを取ってくるってこと自体は、mysqlに関しては超高速。甘えていい。

NoSQLを使えばいい場面でも、マスタの管理とか、主キーそのものがintで管理されていたりとか、実装レベルで便利だったりする。

プログラミングをゼロから始める人のためのRubyプログラミング

目的

プログラミングの基礎を学ぶ

なぜRuby

Ruby意外のしんどさを書いてく。

言語 しんどさ
Java IDEなしに素のプログラミングをやらせるの辛い。IDE経由だと何しているかわかりにくい
PHP Apache経由の動きだけになりがち。一番最初はレイヤーが浅い方がいい
Perl もう情報が少ない(リファレンス/デリファレンス/UTF8フラグが無駄にしんどい)
Python 次点としてありだが、Python3が完全普及するまで待っていいのでは?
C 自分はここから入ったのでいいけど、業務では使ってないので遠回りがすぎる。core dumpは初心者には遠回りがすぎる。

ということで、ターミナル上で、標準入出力を使ったプログラミングの基礎を学ぶには、Rubyが「ちょうどいい」。

標準入出力にとことんこだわる

  • 業務でも十分使える
  • いきなりMVCフレームワークを使うと階層がわからず迷子になる
  • Webフレームワークの環境構築で悩まなくていい
  • 多言語言語でも通用する考えなので、OS/IOとプログラミング言語の階層構造が理解しやすい。

標準入出力をベースにしたプログラミングの試験はスタンダード

PaisaやAtCorderやCodeIQなどのサイトは標準入出力で答え合わせをしている。それくらい「スタンダード」

学習の順番

  • Hello World
  • 引数をもらって「こんにちは◯◯さん」と出力
  • 標準入力をもらって「こんにちは◯◯さん」と出力
  • 標準入力で入ってきた小文字アルファベットを大文字にして出力
  • 標準入力で入ってきた数字を倍にして出力
  • 標準入出力をつかって対話型じゃんけん

次に覚えるのはSQL

AcitveRecordをいきなり触らない。裏で流れているSQLを知らないで開発できるかっていうと、直接SQLつかう機会は多い。ゲームのディレクターはエンジニアでなくてもちょっとしたSQLは書ける。もはやエクセルみたいなもん。

次に覚えるのはHTML

  • フォームヘルパーは使わない。まずはformタグを全部かく。
  • GETとPOSTの違いをしる。
  • input、select 、radio、checkbox、texture、hiddenを一通り手で作ってみる
  • Webアプリケーションフレームワークとしてはシナトラでお勉強する。Railsは何してるか分からないので。

次に覚えるのはcurlコマンド

  • フォームでPOSTしている内容を、curlコマンドで再現してみる。
  • ここで、ブラウザのデベロッパーツールの使い方を覚える(copy as curl
  • curlのパラメーターを変えて、何をリクエストすると何が帰ってきているかを知る。

・・・・続く。そのうち書く。あとは、そもそものLinuxの使い方として、grepとかlessとかvimとかsshとかscpとかその辺は徐々に覚える。