Code Day's Night

ichikawayのブログ

VAddyを運営するビットフォレストという会社

VAddy Adventカレンダー4日目の記事です。

私が最初にクラフトビールに出会ったのはたぶん2008年ごろ、アメリカにあるセーフウェイというスーパーに行った時でした。ビールの陳列棚の大きさもさることながら、多種多様なビールが置いてあり、ほとんどは小さなクラフトビール工場が作った6packと呼ばれる6本セットの瓶ビールでした。よく分からないながらもペールエールを中心に何度か飲みましたが、短期滞在で毎回6本セットを買うのは消費する側には厳しいもので。。この話を書いているうちに今日が終わりそうなのでこのへんにしておきますね。

 今日はVAddyを開発運営している株式会社ビットフォレストについて書いてみます。

株式会社ビットフォレスト

VAddyを開発運営しているのは、株式会社ビットフォレストです。

www.bitforest.jp

創業は2002年ですので、インターネット関係の会社としては古いほうですね。

創業当初はWebシステムの受託開発が中心でしたが、平行して運営していたセキュリティ事業が軌道に乗り、最近ではほとんどがセキュリティ事業となりました。受託開発から自社サービスの会社へと変わっていきました。

CTOの佐藤(金床)は開発もセキュリティも詳しいエンジニアで、オープンソースでWeb Application Firewall(WAF)やDoormanというProxyソフトなどを公開していました。書籍はこれが有名です。

ウェブアプリケーションセキュリティ

ウェブアプリケーションセキュリティ

 

Scutum

 彼が作っていたWAFをベースにクラウド型Web Application Firewallをサービスとして展開させたのが Scutum です。

WAF スキュータム(Scutum) - クラウド型Webアプリケーションファイアウォール

 

開発運営はビットフォレスト、契約、販売、サポートは株式会社セキュアスカイテクノロジーが行っています。 

2009年にScutumがリリースされた当時は、まだアプライアンスのWAFが主流で製品も保守費も高いものがほとんどでした。そこに手軽に導入できるクラウド型WAFを低価格で提供し、顧客に受け入れられ、2016年現在は1800サイトに導入されています。

選ばれてシェアNo.1!| クラウド型WAFサービス Scutum【スキュータム】

2010年からの国内SaaS型WAFシェアNo.1をキープしています。

VAddy

Scutumは通信をリアルタイムに解析して攻撃を遮断するサービスです。それとは別に、根本的な脆弱性(バグ)を発見して解決してもらうのがVAddyで、2014年にベータ版をリリースして、2015年に正式版をリリースしました。

Scutumで日々攻撃を監視し、防いでいるノウハウを使って、VAddyでもCTO金床が脆弱性検査するエンジンを自前で開発しています。

Scutumはサービスの特性上、国内展開が中心となっています。
VAddyは広く海外にも売れるものであると考え、VAddyは海外展開も積極的に行っています。

さいごに

特に何が言いたいか、書いててわからなくなってきましたw
最近、ビットフォレストのオフィスが新宿から大手町に移転しました。大手町にクラフトビアマーケットという良い感じのビールが飲める店があるので、興味がある方は一緒にいきましょう!

www.craftbeermarket.jp

サービス名を決めた時の5つの基準! VAddyの名前が決まるまで

VAddy Adventカレンダー3日目の記事です。

今日もVAddyプロダクトマネージャ兼フロント側の開発を担当している市川が書いてます。週末はポエムっぽい内容にしようと思うのでQiitaではなく、自分のブログに書きます。

2日目の記事で私の好きなビールはペールエールやIPAと書きました。

qiita.com

逆に好きではない苦手なビールは、ウィートビール、白ビールと言われている華やかな香りで多くはバナナっぽい匂いがするものです。ヴァイツェンやヒューガルデンなんかそうですね。女性には人気の白ビールですが、IPA好きな私の周りの人を見るとこれが苦手という人が多く、おっと白ビール派の人たちに正座させられそうなのでこのへんにしておきますね。

 

VAddyの名前

VAddyは私が考えた造語で、Vulnerability Assessment is your Buddy(脆弱性診断はあなたの相棒)という言葉を短くしたものです。かなり気に入っています。

プロジェクトが始まって、継続的にセキュリティテストをする仕組みやビジネスをどうするか数ヶ月議論していましたが、その中でサービス名が決まっていませんでした。プロジェクトメンバーかはら早く名前をと言われるのですが、プログラミングと一緒で名前は大事で、一度決めるとサービス名の変更は難しいので、しっくりくる名前が思いつくまで2ヶ月ほどかかりました。

名前が決まらない間は、適当に仮の名前にしておくかってことで、私が当時住んでいた福岡市の千早(ちはや)という名前になりましたが、仮の名前が正式名称になるってことは多々あるので、本気で考えないといけないなとビールを飲みながら真剣に悩んでました。

 

名前を決める基準

名前を決めた基準は次の通りです。

  • 造語でGoogleなど検索にヒットしやすいこと
  • サービスの思いが込められていて、意味があること
  • ドメインが空いてること
  • 読みやすく、書きやすいこと
  • 声に出した時に変な意味に間違われないこと

最後のVAddyが英語圏の人達からすると違和感のある音や、卑猥な言葉に近くて間違われやすいなどを心配したので、アメリカとイギリスとオーストラリアの友人に聞いてみたところ、特に違和感はないと言われたのでホッとしたのでした。

 

ドメイン

.comドメインは空いておらず、変なドメイン業者が売り出してたので交渉してみたところ100万円以上の値段を提示してきました。いまどきcomドメインにそこまでこだわる必要もないかと思い、.netドメインを取得しました。

エンジニア向けサービスでは、.ioドメインが人気でしたが、より一般的な.netにしました。というのも、リビアドメイン.lyがリビアの国自体がどうなるか分からない時に極力利用は避けるという話があったからです。 .ioに同じような問題が起こるかはわかりませんが、重要なサービスのドメインなのでより安全な方にしました。

 

名前が決まってからは

名前が決まってからは、プロジェクト内の議論が活発になり、より具体的な話やロゴを作成する話など、多くのことが進み始めました。
一番良かったのは、名前ができたことでチームメンバーの意識がより高くなり、リリースに向けて、自分たちの目指す世界を作るために集中しやすくなったことでしょう。

私の好きな漫画パトレイバーの後藤隊長も、グリフォンという敵機の名前が正式に決まった時に、対象物が正体不明のものから名前がついた現実にいる物体に変わった、みたいなことを言ってましたね(すみません、その該当ページがすぐに見つからず覚えている範囲で。。)

 

たかが名前、されど名前。名前は大事ですね。

 

自前のページング処理でもLaravelのページング用htmlを出力する方法

Laravel5.1を使ってます。

LaravelのEloquentやクエリビルダーを使わない場合でも、View側で下図のようにLaravelのページングのhtmlを出力したい場合の話。

f:id:ichikaway:20161007161051p:plain

 Illuminate\Pagination\LengthAwarePaginatorクラスを使います。

$paginator = new LengthAwarePaginator($items, $total, $limit, $page);
$paginator->setPath($request->url());

というように第1引数に配列やコレクションオブジェクトをセットし、第2引数に総レコード数、第3引数に1ページに表示する件数、第4引数に現在表示しているページ数をセットするだけ。
ページング用のURLはsetPath()でセットします。

<?php echo $paginator->render(); ?>

あとはView側でrender()メソッドを呼ぶとhtmlが出力されます。
ですので、DB以外から取得した配列データなどでも簡単にページングのhtmlが作成できます。

LengthAwarePaginatorクラスのコンストラクタはこのようになってます。

/**
* Create a new paginator instance.
*
* @param mixed $items
* @param int $total
* @param int $perPage
* @param int|null $currentPage
* @param array $options (path, query, fragment, pageName)
* @return void
*/
public function __construct($items, $total, $perPage, $currentPage = null, array $options = [])
{

参考

Pagination - Laravel - The PHP Framework For Web Artisans

https://readouble.com/laravel/5.1/ja/pagination.html

Go言語のクロスコンパイルで生成したバイナリが動作しない

VAddyのコマンドラインツールをgolangを使って書いているのですが、MacからLinuxやWindowsのバイナリを生成して、例えばLinux環境で動作させようとすると、

   line 1: syntax error near unexpected token `newline'
   line 1: `!<arch>'

というエラーが出て動作しない状況に遭遇しました。

 

解決策は簡単で、main()が書いてあるファイルのpackage宣言がpackage mainではなくpackage vaddyという名前になっていたのが原因でした。これをクロスコンパイルすると外部ライブラリとしてコンパイルするだけで、実行可能ファイルにはなりません。

Mac上で開発していて、package vaddyの状態でも go run xxx.goとすると実行できてしまうので、クロスコンパイルするまでは気付かない問題でした。

 

ちなみに、クロスコンパイルするときは、例えばlinux 64bitの場合は下記のようにしています。
   GOOS=linux GOARCH=amd64 go build  -o bin/vaddy-linux-64bit

 このようなシェルスクリプトを作成して、複数環境のバイナリを生成しています。

 

参考文献

qiita.com

qiita.com

 

WEB+DB PRESS Vol.82

WEB+DB PRESS Vol.82

  • 作者: 山口徹,Jxck,佐々木大輔,横路隆,加来純一,山本伶,大平武志,米川健一,坂本登史文,若原祥正,和久田龍,平栗遵宜,伊藤直也,佐藤太一,高橋俊幸,海野弘成,五嶋壮晃,佐藤歩,吉村総一郎,橋本翔,舘野祐一,中島聡,渡邊恵太,はまちや2,竹原,河合宜文,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2014/08/23
  • メディア: 大型本
  • この商品を含むブログ (1件) を見る
 

 

 

スターティングGo言語

スターティングGo言語

 

 

 

みんなのGo言語[現場で使える実践テクニック]

みんなのGo言語[現場で使える実践テクニック]

  • 作者: 松木雅幸,mattn,藤原俊一郎,中島大一,牧大輔,鈴木健太
  • 出版社/メーカー: 技術評論社
  • 発売日: 2016/09/09
  • メディア: Kindle版
  • この商品を含むブログを見る
 

 

ZOHO APIからデータを更新する方法

ZOHO APIからデータを更新する方法の紹介です。
今回は、PotentialsというZOHO CRMの種類のレコードを更新します。

まずはじめに、APIを使うためのチケットを発行します。
下記のURLに必要なEmail IDとPasswordを入れてブラウザでアクセスすればチケットとよばれる認証キーが発行されます。

    https://accounts.zoho.com/apiauthtoken/nb/create?SCOPE=ZohoCRM/crmapi&EMAIL_ID=hoge@example.com&PASSWORD=xxxxxx&DISPLAY_NAME="testmode1"
    

レコード情報の取得

認証キーが発行されたら、更新の前にまずはレコードが取得できるか試してみましょう。

https://crm.zoho.com/crm/private/xml/Potentials/getRecords?authtoken=aaaaaaaaaaaaaaaaaaaaaaaaaaaaa&scope=crmapi

このauthtokenに先ほど発行されたキーをセットすると、Potentialsのレコードが取得できます。Potentialsを使ってない場合は、使っているLeadsやContacts、Productsなどに変更してください。


レコードの更新

最後に、レコードを更新します。更新するキーと値をxml形式で送ります。(なぜかGETリクエストで送って更新・・)

https://crm.zoho.com/crm/private/xml/Potentials/updateRecords?newFormat=1&authtoken=aaaaaaaaaaaaaaaaa&scope=crmapi&id=123456789&xmlData=<Potentials><row no="1"><FL val="キー">更新したい値</FL></row></Potentials>

updateRecordsというAPIを使って更新します。セットするパラメータは、

  • authtoken: 認証キー
  • id: レコードのID
  • xmlData: 更新用のXML

xmlDataにセットしているのは、

<Potentials>
  <row no="1">
    <FL val="キー">更新したい値</FL>
  </row>
</Potentials>

というようなXMLです。Potentialsの情報でval="キー"というカラムの値を更新します。

更新は差分で更新されるので、該当レコードの他のカラムには影響しません。

重要なのは、idで該当レコードIDを指定して、更新XMLを送ることです。

ZOHO APIマニュアルに詳しいことは書いてありますが、サンプルURLの幾つかにidパラメータが入っていない記述ミスがありますのでご注意ください。

www.zoho.com

 

PHPに関するHTTPOXY脆弱性の問題と対応方法

外部から簡単にHTTP_PROXYという環境変数がセットでき、サーバ間通信や外部サイトと連携している場合に影響があるかもしれない脆弱性です。(HTTPoxy. CVE-2016-5385)

PHPの場合はphp-fpm, mod_php, Guzzle4以上やいくつかのライブラリで影響あります。

対応方法は簡単です。


Apache側で対応する場合は、mod_headerを使える状況であれば、confファイルに下記の1行を追加。

RequestHeader unset Proxy


FastCGIの場合は下記の1行を追加。

fastcgi_param HTTP_PROXY "";


Guzzleは6.2.1で対応されたようです。
Release 6.2.1 release · guzzle/guzzle · GitHub
コミットログを見ると、CLIの時のみ、getenv('HTTP_PROXY')を利用するように変更されてますね。
Addressing HTTP_PROXY security vulnerability, CVE-2016-5385 · guzzle/guzzle@9d521b2 · GitHub



問題の原因や、対応方法、再現方法などは下記のサイトが詳しいのでご覧ください。 

httpoxy.org

www.nginx.com

例えば、Guzzle4以上を使っていて外部サイトに裏で通信して何かしようとするときに、HTTP_PROXY環境変数が上書きされてしまうと、そのProxy経由で通信が行われるため、任意のサイトにアクセスさせられたり、中間者攻撃が可能になります。(PHPからの接続先がhttpsで証明書を検証していれば問題ないですが)
この攻撃は簡単にできてしまうため、影響がありそうならすぐに対応しておいたほうが良いです。

 残念ながら、unset($_SERVER['HTTP_PROXY']) putenv('HTTP_PROXY=');としてもgetenv()に影響しないため回避できません。

 

追記1

httpoxyのサイトで示されたように

RequestHeader unset Proxy early

としていましたが、earlyがなくても手元のapacheでは問題なくHTTP_PROXY環境変数がセットされませんでした。earlyは開発者向けのテスト・デバッグ用の設計のようなので、無くしたほうがよいかもしれません。

mod_headers - Apache HTTP サーバ バージョン 2.2

検証方法は、curlコマンドで

curl -H 'Proxy: 127.0.0.1:12345' "http://localhost"

のようにして、Proxyヘッダをセットしてlocalhostのwebサーバに送信。PHP側は、

var_dump($_SERVER['HTTP_PROXY']);
putenv('HTTP_PROXY=');
var_dump(getenv('HTTP_PROXY'));
exit;


のようにして、ヘッダにセットしたProxyが環境変数にセットされているか表示して確認。

MacでPHPをコンパイルする時にzlibがnot foundエラーとなる問題

MacOSX El CapitanでPHPをコンパイルしようとすると、zlib not found(libz not found)のエラーが出てしまいました。

検索すると、xcodeのCommand line toolsをインストールする必要があって、

xcode-select --install

とすればダイアログが立ち上がってインストールできるとありました。

しかし、何度やってもダウンロードしてインストールが進行したところで、ダウンロードエラーが出て止まってしまいます。

そこで

sudo xcode-select --install

としたところインストールが無事完了しました。めでたし。

sudoを付けたのが影響したのか、何度かインストールにトライして偶然いけたのかは不明です。

Unix考古学を読んで遠い昔に思いを馳せる

3年ほど前に「Unixという考え方」という本を読んで感銘を受けたので、最近話題になってたUnix考古学も読んでみました。これは非常に面白く、早く先を読みたいと思う本でした。

1960年から1990年ぐらいまでのUnixの歴史が、数多くの参考文献やメモを掘り起こし、整理して、たまに著者の推測も入りながら書かれている本です。 当時の政治などの時代背景も書いてあるのが良いです。

Unixの初期はAT&Tが独占禁止法で通信分野以外の商売をしてはいけない状態で、AT&Tのベル研究所から研究成果としてUnixが出てきて、開発者の草の根活動なども手伝って普及していく過程、その後BSDなどに派生したり、AT&Tが解体されてUnixを商売として力を入れられるようになっていく過程、ARPAやDARPAによるインターネットの後押しなどなど、今の私たちを支えるUnixやインターネットがたどった道が詳細に書かれていて興奮します。

中に出てくる開発者達が、研究成果を元にどんどん起業していくのは、この当時からアメリカという国はこうなんだなと感じました。


印象に残った箇所

面白かった箇所は多いのですが、印象に残ったものは

「AT&Tで使われているアプリケーションの複雑さを考えれば、アプリケーションを新しいOSに移植するよりも、OSを新しいマシンに移植するほうがより簡単だろう」P.86

当時はマシンベンダーごとに異なるCPUであったり互換性がなかったのでUnixが普及する過程ではポーティング作業が多かったようですが、その結果、様々な環境でUnixが動くようになり、このポータビリティがUnix普及を後押ししました。

アプリケーションを移植するよりもOSを移植するほうが簡単というのはすごいですね。

 

それ以外にも、リントストラップというコマンド名にしたかったが当時は4文字しかコマンド名につかえず、lintというコマンド名になったとか、シェルの中で他のコマンドを呼び出してプロセスフォークすると、当時の非力なマシンを複数人で共有している環境ではフォーク処理時間が問題になり、testコマンドなどはシェルのビルトインコマンドにしたとか。

testコマンドは今でも which test すると、「test: shell built-in command」となっていてビルトインコマンドになってますよね。

 

Unixのソースコード

この本を読んでると、当時のUnixのソースコードはどんなものだったか気になります。下記のサイトでは、過去のUnixのソースコードが可能な限り公開されています。

http://minnie.tuhs.org/cgi-bin/utree.pl

たとえば、4.3BSDのTCPに関するコードはここ。

http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD/usr/src/sys/netinet

 

読みたくなった参考文献

この本は参考文献が非常に多いのも特徴的で、後で読んでみようと思うものありました。

一つが、デニスリッチーとケントンプソンが書いたUnixに関する初めての論文
The UNIX time-sharing system」 です。

もう一つが、ヴィントサーフとロバートカーンが書いたインターネットの構想を書いた論文「A Protocol for Packet Network Communication (May 5, 1974) 」です。

あと、当時の人たちの生態を描いたスティーブンレヴィの小説、ハッカーズも読んでみたいと思います。

 

余談

私が初めて自分のPCにUnixを入れたのは1999年ごろ、FreeBSD 2系を486のPCに入れてネットワークカードもない状態でいじってました。たしかFreeBSDのムック本がCD-ROM付きで出てて、興奮しながら買ってインストールしたのを覚えてます。
ちなみに、私が生まれた年に出たUnixは、「Seventh Edition Unix」でした。どうでもいいですけど。。

そういえば、2009年ぐらいにアメリカのComputer History Museumに行ったのですが、偶然にもPDP-1の実機デモを見せてもらいました。当時のエンジニアがボランティアでPDP-1のメンテナンスをしてて、楽しそうにコンピューターのことを語ってたのが印象的でした。ちなみにPDP-1は動く状態で存在しているのはここにしかないとか。 

 

Unix考古学 Truth of the Legend

Unix考古学 Truth of the Legend

 
UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

 

 

ハッカーズ

ハッカーズ

 

 

 

Gitコマンドで行単位ではなく文字単位の差分表示を手に入れる

f:id:ichikaway:20160614182511p:plain

Githubを使っていると、diff表示が行単位ではなく文字単位になってて便利かと思います。手元の端末でも同じようにdiffを文字単位に表示したい時は、diff-highlightというスクリプトを使えばできます。表示は上の画像のようになります。

diff-highlightは、gitの公式リポジトリのcontribディレクトリの中にあって、perlのスクリプトファイルです。

https://github.com/git/git/tree/master/contrib/diff-highlight


一番簡単な設置は、/usr/local/binなどの場所にダウンロードして実行権限を与えればOK。

wget https://raw.githubusercontent.com/git/git/master/contrib/diff-highlight/diff-highlight

chmod 755 diff-highlight

 

軽く試したい時は、

git log -p --color | diff-highlight


すると文字単位のdiff表示になります。

 

diff-highlightにパイプで渡すのが面倒なので、.gitconfigに

    [pager]
	log = diff-highlight | less
	show = diff-highlight | less
	diff = diff-highlight | less

と書いておくと、git log, show ,diffの差分表示でdiff-highlightが適用された形になります。

 

もしgitのバージョンが古くて上記のgitconfigの記載でエラーになる場合は、

[core]
    pager = diff-highlight | less -r

と書いておくと良いかもしれません。