ある研究者の手記

セキュリティとかゲームとかプログラミングとかそのへん

Amazon S3上のログのスキーマを管理していい感じに使うGo言語用ツールを作った

あまりにニッチすぎるから全く需要ないかなと思ったんですが、世の中に3人くらいは同じ悩みを抱えた人がいるかなー？と思ったので一応ブログをしたためておきます。

github.com

これはなに

タイトルでちょっと雑に書きましたが、もう少し正確言いうとAmazon S3上に保存したログのフォーマットやスキーマの一部をコード上で定義し、管理するためのフレームワーク in Go言語です。以下のように定義を書いた後、S3のバケット名、キーを指定するとパース済みの構造体を返してくれます。ここでは1行ずつのJSON形式で保存されたログが your-bucket バケットの http_log/ 以下に入っており、さらに ts というフィールドに時刻情報が入っていることを定義しています。

   pipeline := rlogs.Pipeline{
        Ldr: &rlogs.S3LineLoader{},
        Psr: &parser.JSON{
            Tag:             "ts",
            TimestampField:  rlogs.String("ts"),
            TimestampFormat: rlogs.String("2006-01-02T15:04:05"),
        },
    }

    reader := rlogs.NewReader([]*rlogs.LogEntry{
        {
            Pipe: pipeline,
            Src: &rlogs.AwsS3LogSource{
                Region: "ap-northeast-1",
                Bucket: "your-bucket",
                Key:    "http_log/",
            },
        },
    })

実際の読み取りはこんな感じ。

   ch := reader.Read(&rlogs.AwsS3LogSource{
        Region: "ap-northeast-1",
        Bucket: "your-bucket",
        Key:    "http_log/log.json",
    })

    for q := range ch {
        if q.Error != nil {
            log.Fatal(q.Error)
        }
        values := q.Log.Values.(map[string]interface{})
        fmt.Printf("[log] tag=%s time=%s src=%v\n", q.Log.Tag, q.Log.Timestamp, values["src"])
    }

rlogsの中には自分自身の需要によりJSON、VPC FlowLogs、CloudTrailのそれぞれのログに対応するパーサーを用意していますが、自分で実装することもできます。

なんで必要なのか

S3はオブジェクトストレージという性質上、当然ながら保存するときのログの中身・構造は一切問われません。そのためフォーマットやスキーマという概念を（ほぼ）無視してログの保存ができますが、一方でログを利用する際には別途中身をパースする必要があります。

保存しているログが2、3種類だけしかない、あるいは保存する際にちゃんと共通のスキーマに落とし込んでいる、というような場合はこれ以上お話することはないのですが、だいたいの場合現実はそうはいかないかなと思っています。特にS3にログを保存するときのメリットは「高可用でログの一次保存ができる」という点が大きいです。そのため、ログを保存する前にあれこれやってエラーなどがおきて可用性が下がってしまうというのは、アーキテクチャの旨味が少なくなってしまうかなと思います。

ということからログを利用する際にはどのバケット、どのプレフィクスにどんなログが入っているかを知っている必要があります。ログを利用するツール・システムが1つだけならそこに定義などを書いておけばいいのですが、実際には様々なことにログを利用したくなるため、自分は共通化したいと考えました。そこで共通利用できるようにして、ついでにログの取得＋パースの機能もつけようと思ったのがこのフレームワークです。

どう使うのか

組織内などで1つレポジトリを作り、そこにフォーマットやスキーマの定義を書いて、それをGoのパッケージとして呼び出す、というような使い方を想定しています。例えば your-git-server.example.com のようなサーバがあって your-git-server.example.com/someone/logparser のようなレポジトリを用意した場合、以下のような感じで定義を書いておきます。

package logparser

func NewReader() *rlogs.Reader {
        logEntries := []*rlogs.LogEntry{
                // ログの取り込み方＋パースの仕方＋場所の定義を
                {
                        Pipe: rlogs.Pipeline{
                                Ldr: &rlogs.S3LineLoader{},
                                Psr: &parser.JSON{
                                        Tag:             "your.log",
                                        TimestampField:  rlogs.String("time"),
                                        TimestampFormat: rlogs.String("2006-01-02T15:04:05Z"),
                                },
                        },
                        Src: &rlogs.AwsS3LogSource{
                                Region: "ap-northeast-1",
                                Bucket: "your-backet",
                                Key:    "logs/",
                        },
                },
               // いろいろ書く
        }
        return rlogs.NewReader(logEntries)
}

そのあと、実際にログを利用するコード内で以下のように呼び出します。

package main

import (
        "your-git-server.example.com/someone/logparser"
)

func main() {
    reader := logparser.NewReader()
    ch := reader.Read(&rlogs.AwsS3LogSource{
        Region: "some-region",
        Bucket: "your-bucket",
        Key:    "http/log.json",
    })

    for q := range ch {
        if q.Error != nil {
            log.Fatal(q.Error)
        }
        values := q.Log.Values.(map[string]interface{})
        fmt.Printf("[log] tag=%s time=%s src=%v\n", q.Log.Tag, q.Log.Timestamp, values["src"])
    }

}

どう使っているか

以前、会社のブログにも書いたですが、今の仕事ではおよそ20種類ぐらいのログをこのフレームワークを利用して取り込み、いろいろなことに利用しています。このあたりの話はまたいずれ改めて会社のブログなどに書くかもしれません。

クラウドネイティブなハニーポットをAWS上に作ってみた話

セキュリティ ネットワーク 分析 技術

TL;DR

  • AWSのマネージドサービスを活用して低インタラクション型のハニーポット環境を作った
  • コストも月々約$15で運用可能
  • コマンド3回ぐらいで誰でもデプロイできるようになっているので興味があれば使ってみてくれよな

f:id:mztnex:20190210154448p:plain

背景

という感じで昔クラウド上で運用していたハニーポットのことをふと思い出したのですが、仕事で多少AWSのサービスを理解した今だったらもうちょっとまともに実装できそうだよなぁ、実装するならインスタンスで完結するんじゃなくてクラウドのマネージドサービスちゃんと使って消耗しない作りにしたいよなぁ、と考えているうちに気持ちが高まってきたのでやりました。

また真面目な話としては、自分も情報セキュリティを生業としているので自分自身で脅威情報を収集する手段を持っていたかった、というのがあります。警視庁による定点観測やNICTによる監視報告などから、どのようなポートにどういう攻撃が来ているか、ということを知ることができますが、どのような環境で観測されているかという情報は非公開です。肌感覚ですが、こういったアクセスは対象となるネットワークによって異なる傾向があるように思えるため、自分で把握できる環境の情報をえる手段があると良いなと思っていました。

ちなみに「クラウドネイティブ」という言葉の意味は誰が言っていることが正しいのかはよくわかりませんが、「極力マネージドサービスを使って構築する」ぐらいの気持ちで使っています。あしからず。

今回扱うハニーポットの仕組み

ハニーポットと一口に言っても、特定のWebサービスの振りをしたりするものや、仮想環境をまるっと用意して侵入した攻撃者がどういう行動をするか観測するものなど様々なのですが、今回は低インタラクション型なハニーポットを実装しました。やっていることは至極単純で、TCPのsynパケットが来た場合に偽装syn+ackパケットのみを打ち返し、攻撃者側のプログラムにTCPがEstablishしたと誤認させます。そして、その後に続くパケットを収集することで攻撃者がどんな通信を投げてくるのか観測します。

f:id:mztnex:20190210171416p:plain

以前はC++でこれを実装していたのですが、近代的な機能を使おうとするといろいろ面倒というのもあったのでこれを機にGoで書き直しました。lurkerという名前で実装しており、gopacket というライブラリでパケットキャプチャ、および偽装パケットの生成と送信をしています。前述したとおり低インタラクション型なので、攻撃者の挙動を深追いすることはできないのですが、以下のようなメリットがあります。

  • スケーラビリティが高い: 主な動作が 1) SYNパケットの応答を打ち返す、 2) パケットをキャプチャして保存する、という2つのみなので非常に軽快に動作します。今回はAWSの構成の制約上やっていませんが、大昔に大学の研究室で数百単位のIPアドレスを監視していた際も同じようなアーキテクチャで問題なく可動していました。
  • 侵入後の攻撃者の活動を心配する必要がない: 心配する必要がないというより、心配すらできない、が正しいかもしれません。実際に侵入させる系の高インタラクション型のハニーポットだと、侵入された後に外部に対して攻撃などの影響を及ぼさないようにするにはどうしたらいいか、ということを真剣に考える必要があります。場合によっては不正アクセスの片棒をかつぐ事になり厳しい怒られが発生する場合もありつつ、さりとてあまり行動（特に外部との通信）を制限しすぎると何も情報がえられない、という難しい問題があります。ですが、この仕組ではsyn+ackを打ち返すだけしかできないので、そのあたりの心配をする必要はありません。
  • 全ポートを監視できる: 通常ハニーポットを運用する場合、Webサービスを偽装する場合はport 80や443、sshを偽装する場合はport 22など、対象となるサービスによって監視するポートが自ずと狭まるものです。しかしこの仕組ではとりあえずどのTCPポートでも受信したパケットに対してはすべからく打ち返すので、全ポートに対するデータが収集できます。これの利点は、攻撃者がそもそもどこのポートに対してスキャンしようとしているかが分かることです。例えばsshはTCPセッション確立後にProtocol version exchangeのパケット（SSH-2.0-OpenSSH_5.3 みたいなやつ）が送信されます。これを見ることでsshは標準ポートの22だけでなく、1022、2222、8022といったポートもスキャンされているという情報を知ることができます。

設計方針

なるべくマネージドサービスを使う

近年においては常識ですよ、と言われてしまうかもしれませんが、すぐに対象のサービスが使えるという以外にも一応以下の効果を期待したということを記しておきます。

  • 持続的な運用を丸投げできる: 完全なメンテナンスフリーというわけにはいきませんが、やはり日々の運用の部分を肩代わりしてもらえるというのは大きいです。特に今回作るものは毎日ガッツリ使うというよりは、日々データをためておいて必要なときに確認する、というユースケースを想定しています。そうなると自分で動かしていたサービスがいつの間にか落ちていて、気づいたら全くデータ取れていなかった…という悲しいことも起きがちです。もちろんちゃんと監視の仕組みを入れてアラート飛ばすなどすればいいのでしょうが、その対応の手間も安くはありません。あと、雑に自前でサービスを立ち上げるためにインスタンスを上げっぱなしにしていると中のパッケージが古くなって脆弱性を放置して…などということも起こりがちです。雑多な用途で作るサービスだからこそ、そのあたりの負荷をなるべく減らしたいという気持ちです。
  • 監視の仕組みが最初から組み込まれている: こちらも同様に自前で頑張れなくないですが、既存のマネージドサービスだと最初から豊富な監視の機能が提供されています。メッセージ配信サービス（例 Amazon Simple Notification Service）であれば流量など、サーバレス実行環境（例 AWS Lambda）であれば実行回数や実行にかかった時間などをCloudWatch metricsで確認したり、CloudWatch alarmを設定し特定の条件で通知を飛ばしたり、といったことが容易に実現できます（今回そこまでやってないけど）こういったものがデフォルトで提供されているのであまり自分で頑張らなくて良い、というのもマネージドサービスの利点です。

データ取得と分析の処理を分離する

以前に似たようなアーキテクチャを考えていたときは、基本的にデータの収集と分析を密結合させて、最終的な結果だけをfluentdに流す、という方法をとっていました。言わずもがなですが、その構成だと分析方法の追加や変更、削除をするたびにデータ収集の部分をいじる必要がでてきてしまい、うかつに触れなくなってしまいます。また、データ収集と分析の処理を同じ環境で実施しようとすることで、負荷の重い方がリソース（CPUやメモリ）の制約を受けやすくなってしまう、ということもあります。具体的には後述しますが、そういった理由からマネージドサービスなストレージであるSimple Storage Service (S3) にまずデータ（今回は通信を記録したpcapファイル）を投げ込み、その通信に何が含まれていたか？という処理は後ろ側に任せる、というような構成をとりました。

実装

というわけで実際の実装に関する解説をしたいと思います。実装は3パートに分かれていて、それぞれ sensor、backend、output と呼んでいます。それぞれCloudFormationをベースとして実装しており、実際のデプロイ方法についてはデプロイの節をご覧ください。

sensorパート

f:id:mztnex:20190211103017p:plain

ハニーポット本体が設置してあるパートです。さすがに「TCPのSYNパケットを受けて偽装したSYN+ACKを返す」という処理をマネージドサービスで実現するのは困難だったので、そこはEC2インスタンスを使いました。ハニーポットには管理用と監視用、2つのネットワークインターフェースを接続しています。EC2は自前で2つ以上のネットワークインターフェースを接続すると標準で割り当てられるパブリックIPアドレスが使えなくなってしまうため、Elastic IP Address を2つ確保し、それぞれのネットワークインターフェースに割り当てて*1います。これらは全てCloudFormationを使ってデプロイ可能なようにしています。（ CloudFormationのテンプレート）

テンプレートを見るとわかるかと思いますが、（かなり雑なのでちょっと恥ずかしいですが）ハニーポットのソフトウェア本体であるlurkerのバイナリをダウンロードして /etc/rc.local に起動スクリプトを仕込み、実行するところまでを記述してあります。なのでこのテンプレートをデプロイするだけで、AWSに対し外部からどのような攻撃やスキャンがされているのか、というデータを収集し始めることができます。

このホスト上で動作するlurkerの仕事は非常に単純です。

  • TCPのSYNパケットを観測したらSYN+ACKパケットを打ち返す
  • TCPやUDPのフロー（IPアドレス＋ポート番号の組み合わせ）ごとに観測したパケットを保持しておく
  • あるフローに対して1分以上通信が発生しなかったらそのフローのパケットデータをS3バケットにpcap形式で保存する

先述したとおり、gopacket というライブラリがかなりいろいろやってくれて、偽装パケットを作ったり、パケットをキャプチャしたり、pcapファイル形式にデータを変換してくれたりと、だいたいこれに乗っかってやりたいことができました。データ出力先は思い切って（というか面倒だったので）S3バケットに出力するようにしか作っていません。出力されたpcapファイルは以下のような感じで蓄積されています。現在運用している感触だと、だいたい1日あたり10000個弱、合計10MB弱のpcapファイルが生成されています。

f:id:mztnex:20190211150811p:plain

backendパート

f:id:mztnex:20190211103618p:plain

ここは単純に2つのマネージドサービスを展開しているのみで、あまり説明することはありません。sensorがデータをアップロードする先のS3、およびイベントを通知するための Simple Notification Service (SNS) が、このbackendパートになります。S3にファイルがアップロード（生成）されると、そのイベント通知がSNSに飛び、さらにそこからoutputパートにあるLambdaが呼び出されます。

強いていうとS3にはイベントが発生した際に直接Lambdaを起動する機能もあるので、SNSを使わないでもこの構成は実現可能です。それでもSNSを利用している理由としては、S3からのLambdaの直接呼び出しは1つの宛先しか設定できないために分析したい処理が増えたときに困る、そしてbackendパートとoutputパートをより疎結合にできる、などが挙げられます。

outputパート

f:id:mztnex:20190211103629p:plain

最後が収集したデータをもとに、なんらかの出力をするoutputパートになります。backendパートにおいてS3に生成されたファイルがSNSに通知され、それをトリガーにしてLambdaが起動します。Lambdaには生成されたファイルそのもののデータではなく、どのバケット、どのキーに対してファイルが生成されたかという情報が伝わるだけなので、LambdaがS3バケットにアクセスして対象ファイルをダウンロードしてpcapファイルの中身を分析する、という一般的なS3 + Lambdaの構成になっています。SNSで複数のLambdaに通知を飛ばせるため複数の分析用Lambdaを配置することもできますが、今回はサンプルとして1つだけ「pcapファイルの中身を荒くまとめてCloudWatch Logsに投げ込む」という例をご紹介します。

今回、分析用に使うLambdaは python + dpkt で実装しました。ハニーポットのソフトウェアであるlurkerと同じくGoで実装しても良かったのですが、gopacketがlibpcapに依存しておりLambda上でC libraryを使うのは骨が折れそうだったので、今回はネイティブにpcap読み取り機能をもつ（libpcapに依存しない）dpktを利用しました。Lambdaでやっている処理は以下のとおりです。

  1. S3からpcapファイルをダウンロードして読み取る
  2. 送信元IPアドレスや宛先ポート番号を取得しTCPのデータセグメントを再構築する
  3. CloudWatch Logsにデータを送信する

TCPはデータを再送などできる都合上、重複したデータをキャプチャしている可能性があるためそれを排除する必要があります。今回は特にsyn+ackだけ返してその後の通信を全くしない、というツールの特性上、通常のTCP/IPスタックであれば必ずデータの再送が発生します。今回は各pcapファイルに1つのフローしか入っていない、という条件なのでわりと雑多にストリームの再構成のコードを書いてみました（何か間違っていたらこっそり教えてください）これらの情報を取得した後、以下のようなJSONを生成してCloudWatch Logsに投げ込みます。

{
  "init_ts": 1549870119.960277,
  "last_ts": 1549870151.089438,
  "src_addr": "193.201.224.***",
  "dst_port": 22,
  "payload": "U1NILTIuMC1XaW5TQ1BfcmVsZWFzZV81LjcuNQ0K",
  "readable": "SSH-2.0-WinSCP_release_5.7.5\r",
  "s3path": "s3://***/pcap/2019/02/11/07/1549870119_193.201.224.***_172.30.2.***_23300_22.pcap"
}

CloudWatch Logsに投入したJSON形式のログは自動的にパースされ、CloudWatch insightを使って実用的な検索などができるようになっています。

デプロイ

先述したとおり、ご紹介した sensor、backend、outputのパートは全てCloudFormationで記述されていますので、awsコマンドだけでバーンと展開できるようになっています。

Prerequisite

以下のツールが必要になります。pythonは3系、awscliはここ最近のものなら動くんじゃないかなと思いますが、検証済みなのは以下の条件です。また、言わずもがなですがawscliはAPIキーなどのcredentialをセットアップする必要があります（詳しくはこちら）

  • python >= 3.7
  • awscli >= 1.14.40

0) テンプレート等の取得

普通にgitでtemplateなどのセットを取ってきます。

$ git clone https://github.com/m-mizutani/aws-honeypot-templates.git
$ cd aws-honeypot-templates

1) backendパートのデプロイ

まず最初にbackendパートを設定します。これはsensorパートが送り先のS3バケットの名前を知っておく必要があること、そしてoutputパートがsubscribeするSNSのtopic名を知らないといけない、という依存関係によります。必要なパラメータを用意しコマンドを実行することで、S3バケットやSNSのリソースが生成され必要な設定が変更されます。

必要なパラメータ

  • backend_stack_name: backendパートのスタック名です。任意の名前で問題ありません。
$ aws cloudformation deploy \
    --template-file backend.yml \
    --stack-name <backend_stack_name> \
    --capabilities CAPABILITY_IAM

デプロイが完了したら、以下のコマンドでS3バケットの名前を知ることができます。AWSのWebコンソールなどから参照しても問題ありません。

$ aws cloudformation describe-stack-resources --stack-name <backend_stack_name> | jq '.StackResources[] | select(.LogicalResourceId == "DataStore") | .PhysicalResourceId ' -r

2) sensorパートのデプロイ

次にsensorパートを同様にCloudFormationのテンプレートを使ってデプロイします。こちらは必要なパラメータが少々多くなります。

必要なパラメータ

  • sensor_stack_name: sensorパートのスタック名です。任意の名前で問題ありません（ただし他のスタック名とかぶらないように）
  • VpcId: センサーがデプロイされるVPCのIDです。 (例 vpc-1234xxxx) VPCおよびsubnetは事前に準備しておく必要があります
  • SubnetId: センサーが接続するsubnetのIDです (例 subnet-1234xxxx)
  • KeyName: センサーにセットするSSHキーの名前です。基本的にトラブルシュート用です (例 default)
  • S3Bucket: backendパートで作成したS3のバケット名を指定してください
$ aws cloudformation deploy \
    --template-file sensor.yml \
    --stack-name <sensor_stack_name> \
    --capabilities CAPABILITY_IAM \
    --parameter-overrides \
    VpcId=<VpcId> \
    SubnetId=<SubnetId> \
    KeyName=<KeyName> \
    S3Bucket=<S3Bucket>

3) outputパートのデプロイ

outputパートのテンプレート、およびLambdaで使うコードは output/cwlogs 以下に入っています。（他にも何種類か用意したかった気持ちのあるディレクトリ構成だ、というところだけお察しください）こちらはいくつかの処理が必要なので deploy.sh というスクリプトを実行しています。やっていることは中身を見ればわかりますが、1) pythonのパッケージインストール、2) pythonのコードをzipで固める、3) backendパートのリソース名を取得する、4) 実際にデプロイ、という流れになっています。

必要なパラメータ

  • region: AWS のリージョンを指定してください（backend、sensorと同じリージョンにしてください）もしbackend、sensorデプロイ時に特にリージョン指定していなければ aws configure get region で確認できます (例 ap-northeast-1)
  • backend_stack_name: backend パートをデプロイしたスタック名を指定してください
  • output_stack_name: outputパートのスタック名です。任意の名前で問題ありません（ただし他のスタック名とかぶらないように）
  • code_s3_bucket: Lambdaのコードを置くためのS3バケット名になります。backendパートで用意したS3バケットとは別のものが良いと思います（同じでだめなことはないけど）
  • code_s3_prefix: Lambdaのコードを置くためのS3キーのprefixになります。自動的に "/" が末尾に追加されるので、例えば functions とだけ指定してください。（自分で末尾に / をつけると空のディレクトリ名が作成さてしまいます）
$ cd output/cwlogs/
$ ./deploy.sh <region> <backend_stack_name> <output_stack_name> <code_s3_bucket> <code_s3_prefix>

CloudWatch Insightでキャプチャしたログを見てみる

ここまできたらデータ収集、データの蓄積、そして分析結果が一気通貫で動いている状態になっているはずです。CloudWatch insightで結果を確認してみましょう。東京リージョン（ap-northeast-1）を利用しているなら以下のリンクでコンソールが開くと思います。

https://ap-northeast-1.console.aws.amazon.com/cloudwatch/home?region=ap-northeast-1#logs-insights:

コンソールを開くと以下のような画面になっているかと思います。 /honeypot/lurker-cwlogs-output となっているところがLogGroupの選択になります。/honeypot/<outputパートstack名> というLogGroupが作成されているはずなので、自分の環境にあった名前を選んでください。

f:id:mztnex:20190211165509p:plain

とりあえず「クエリの実行」をクリックしてもなんらかの出力は出てくると思いますが、例えば以下のようなクエリがわかりやすいかと思います。

fields @timestamp, src_addr, dst_port, readable, strlen(readable) as len
| filter len > 0
| sort @timestamp desc
| limit 20

クエリの意味としては、fields で項目を選択しつつ readable フィールドの文字列を取得して、 filter で文字列が0より大きいものを抽出しています。観測してみると、synパケットだけ飛んできていてペイロードデータが送られてきていないトラフィック（いわゆる普通のSYNポートスキャン）もそれなりにあるので、それを避けるためのクエリです。例として私の環境では以下のような出力がでてきました。

f:id:mztnex:20190211170026p:plain

どういうものが見えるのか？

この仕組を動かし始めてまだ2〜3日といったところですが、いくつか面白い物が見えていたので軽くご紹介します。画像は左から送信元IPアドレス、宛先ポート番号、そして送信されたペイロードとなります。

Hadoop YARN ResourceManager への攻撃

f:id:mztnex:20190211180853p:plain

現在観測している範囲だと、データが送信されている通信の半分以上がこの通信です。S-Owlさんのブログ記事によるとHadoop YARN ResourceManagerに任意のコードを実行できる脆弱性があり、これを探し回っている通信と見られます。

SSHへのアクセス

f:id:mztnex:20190211181300p:plain

これ上側は全部同じIPアドレスからきているのですが、protocol version exchangeで全部違ったクライアントを騙ってアクセスしてきていました。クライアントの種類によってアクセスを許可・遮断するようなツールやサーバがあったりすんですかね…。

バックドアらしきものへのアクセス

f:id:mztnex:20190211181535p:plain

ちょっと見づらいのですが、 /xw1.php というパスに対して h=die(@md5(F3bru4ry)); というデータをPOSTで送信してきています。他にも /xw.php や /xx.php といったパスに対して同様の形式っぽいデータが送られているのを確認しました。具体的になんのツールなのかなどはわかっていませんが、パス名のパターンから考えるに攻撃者が設置したバックドアなどではないかと推察されます。

コスト

さて、冒頭にも書いていますが実際にこれを運用するとどのくらいのコストがかかるか、というのを計算してみました。前提条件は以下の通りで実測値をもとにしています。環境ごとに変化する可能性はありますが、大幅にずれることはないんじゃないかなと思います。（2019年2月現在の東京リージョンの価格情報をもとに計算しています）

  • 1日あたりに生成されるpcapファイルの数：10000個
  • 1日あたりの生成されるpcapファイルのサイズ合計：10MB
  • 1時間あたりのSNSに流れるデータサイズ：300KB
  • Lambda の1時間あたりの実行時間合計：350秒
  • S3のデータ保持期間：1年

f:id:mztnex:20190211153113p:plain

なにか抜けてる要素があるかもしれませんが、支配的なのはEC2インスタンスの使用料＋EIPの使用料なのでまあそんなにズレはないかなと思います。ということで、月額約$15ほどでこの仕組を運用できることがわかりました。これは無料枠を使っていない前提なので、普段AWS上のリソースを使っていないアカウントならさらにお安くなります。価格帯的に高いか安いかは人によるでしょうが、趣味で動かすのであれば高すぎるということはないんじゃないかな、と思う次第です。

今後の課題

  • Elastic IP addressを自動更新するようにする : このような定点観測型のハニーポットの弱点はIPアドレスが固定だと攻撃者に気づかれて、そもそもアクセスを敬遠される、という恐れがあります。ただ、これはAWSを利用することで解決可能で、定期的にEIPをつけかえれば（同じ観測点ではないものの）攻撃者に観測点を常に特定されている、という状況を回避できます。一方でこの仕組を作ろうとするとCloudFormationと相性があまり良くない、という問題があります。スタックを削除する際に付け替えるために新たに取得したアドレスをちゃんと片付けられるようにしないとならず、それについてはちょっと頭を悩ませるところです
  • 使用するElastic IP addressの数を減らす：AWS ではデフォルトでEIPの利用がアカウントごとに5個までと制限されています。この仕組は1つのセンサーをデプロイするだけで2つも消費してしまうため、最大で2つまでしか利用することができなくなっています。このことからEIPを1つだけで運用する、もしくはEC2 インスタンスに標準で付与されるIPアドレスを利用してうまくできないか、というのは検討の余地があるかなという状況です。
  • 自分のパケットがデータに含まれない問題をどうにかする : gopacket非常に便利ではあるのですが、どうも自分自身が射出したパケットはキャプチャできない、という構造になっているようです。なので現在収集されているpcapにはsyn+ackパケットが含まれておらず、pcapを読み込むツールによっては期待された動作をしない懸念があります。これはTCPの応答プロセスとキャプチャのプロセスを分けるなどしてうまくできないかなとは考えています。

*1:本当は1つのElastic IP Addressのみで運用したいのですが、詳しくは今後の課題に後述

テキスト出力されたログファイルから元のログフォーマットを分析するツールを作った

タイトルの通りなのですが、昔ちょっとやっていたテーマに関連したツールをGo言語の練習がてら作ってみました*1。

ログファイルから元のログフォーマットを分析するとは

ここで言うログのフォーマットというのは所謂フォーマット文のことを指します。

log.Printf("Requested from %s", ipAddr)

このコードから以下のようなログが出力されます。

2018/05/23 23:25:00 Requested from 10.0.2.1
2018/05/23 23:25:10 Requested from 192.168.1.5
2018/05/23 23:25:24 Requested from 10.0.1.5

元になったフォーマットは %s の部分にIPアドレスらしきものが埋め込まれて下図のようなテキストとして出力されます。この例は非常に簡単なので下から上を推測するのは容易ですが、内容が複雑になってくると「これ値なのか固定文なのかどっちだ？」ということがまれによくあります。この下の出力から上のフォーマット文（に近いもの）を推測するのが今回作成したツールになります。このツールは 1) すでに出力されたログファイルからフォーマットを推定する、そして 2) 推定したフォーマットを利用し、そのフォーマットに該当するログがログファイルのどのあたりに出現したのかを示す という2つの機能を実装しています。

なんでこんなツールが必要なのか

実際には、正規化・構造化されたログデータのみを扱う環境であればこのツールは不要ですが、以下のような状況で役立ちます。

  • ログの全体像を把握したい場合 : セキュリティ分析の文脈で特に多いと思いますが、今まで見たことのない大量のログをみてそこから知見を導き出さないと行けない場合があります。そういったときにひたすら less コマンドで眺めようとしても人間には厳しいので、全体としてどういうログがあるのか？ そしてどういう分布をしているのか？ ということがわかると分析のとっかかりが非常に楽になります。特にセキュリティ分析で必要なのは多くの場合全体の99%を占める通常のサービスに関するログではなく、何か異常が起こったポイントになります。異常が起こった際のログというのは通常見られないエラーや処理が発生しやすいため、異常なログ＝珍しいフォーマットのログがどこに出現するのかを把握できると、そこにまず注目して分析するという足がかりを作ることができます。
  • テキスト形式で出力されるログを再利用しないとならない場合 : すでにサービスなどが稼働しておりテキストではログを出力するという場合、そのログを正規表現にかけるなどして中に含まれている値を抽出する必要があります。仕様書がある場合はいいですが、そうでない場合はソースコードを見るか、もしくは正規表現を書く→網羅でいているか確認する→正規表現を直す、みたいなことを繰り返さないとならずかなり面倒です*2。このツールだと抜くべき値の正規表現の推定まではしてくれませんが、既存のログから分かる範囲ではどこまでやればいいかを網羅できるので作業的に楽になります。

使い方

Go言語を使う環境が整っていれば go get github.com/m-mizutani/logptn でインストールされます。

GitHub - m-mizutani/logptn: Generate Log Format from real log data

例として（短いものですが）以下のようなログをツールに入力してみます。

$ cat test.log
Feb  1 07:56:49 pylon sshd[5153]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.3  user=root
Feb  1 07:56:51 pylon sshd[5153]: Failed password for root from 192.168.0.3 port 7176 ssh2
Feb  1 07:56:51 pylon sshd[5153]: Connection closed by 192.168.0.3 [preauth]
Feb  1 08:01:26 pylon sshd[5156]: Invalid user upload from 192.168.0.3
Feb  1 08:01:26 pylon sshd[5156]: input_userauth_request: invalid user upload [preauth]
Feb  1 08:01:26 pylon sshd[5156]: pam_unix(sshd:auth): check pass; user unknown
Feb  1 08:01:26 pylon sshd[5156]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.3
Feb  1 08:01:28 pylon sshd[5156]: Failed password for invalid user upload from 192.168.0.3 port 51058 ssh2
Feb  1 08:01:28 pylon sshd[5156]: Connection closed by 192.168.0.3 [preauth]
Feb  1 08:05:01 pylon CRON[5159]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb  1 08:05:01 pylon CRON[5159]: pam_unix(cron:session): session closed for user root
Feb  1 08:05:54 pylon sshd[5162]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.3  user=root
Feb  1 08:05:56 pylon sshd[5162]: Failed password for root from 192.168.0.3 port 33005 ssh2
Feb  1 08:05:56 pylon sshd[5162]: Connection closed by 192.168.0.3 [preauth]
Feb  1 08:10:28 pylon sshd[5165]: Invalid user mythtv from 192.168.0.3
Feb  1 08:10:28 pylon sshd[5165]: input_userauth_request: invalid user mythtv [preauth]
Feb  1 08:10:28 pylon sshd[5165]: pam_unix(sshd:auth): check pass; user unknown
Feb  1 08:10:28 pylon sshd[5165]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.3
Feb  1 08:10:30 pylon sshd[5165]: Failed password for invalid user mythtv from 192.168.0.3 port 59978 ssh2
Feb  1 08:10:30 pylon sshd[5165]: Connection closed by 192.168.0.3 [preauth]
Feb  1 08:15:01 pylon CRON[5168]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb  1 08:15:01 pylon CRON[5168]: pam_unix(cron:session): session closed for user root
Feb  1 08:15:26 pylon sshd[5171]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.2.3.4  user=root
Feb  1 08:15:28 pylon sshd[5171]: Failed password for root from 10.2.3.4 port 60733 ssh2
Feb  1 08:15:28 pylon sshd[5171]: Connection closed by 10.2.3.4 [preauth]
Feb  1 08:17:01 pylon CRON[5173]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb  1 08:17:01 pylon CRON[5173]: pam_unix(cron:session): session closed for user root
Feb  1 08:20:35 pylon sshd[5177]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.2.3.4  user=root
Feb  1 08:20:37 pylon sshd[5177]: Failed password for root from 10.2.3.4 port 44877 ssh2
Feb  1 08:20:37 pylon sshd[5177]: Connection closed by 10.2.3.4 [preauth]
Feb  1 08:25:01 pylon CRON[5180]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb  1 08:25:01 pylon CRON[5180]: pam_unix(cron:session): session closed for user root
Feb  1 08:25:16 pylon sshd[5183]: Invalid user user from 10.2.3.4

このデータを入力させると以下のような出力をします。

./logptn test.log
2018/05/20 13:30:55 arg:test.log
     4 [4ffb267b] Feb  1 *:*:* pylon sshd[*]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=*  user=root
     4 [845f4659] Feb  1 *:*:* pylon sshd[*]: Failed password for root from * port * ssh2
     6 [847ccf35] Feb  1 *:*:* pylon sshd[*]: Connection closed by * [preauth]
     3 [de051cd9] Feb  1 08:*:* pylon sshd[*]: Invalid user * from *
     2 [8e9e2a13] Feb  1 08:*:* pylon sshd[*]: input_userauth_request: invalid user * [preauth]
     2 [22190c74] Feb  1 08:*:* pylon sshd[*]: pam_unix(sshd:auth): check pass; user unknown
     2 [83fba2bf] Feb  1 08:*:* pylon sshd[*]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.3
     2 [f1ba83ea] Feb  1 08:*:* pylon sshd[*]: Failed password for invalid user * from 192.168.0.3 port * ssh2
     4 [e4a6f815] Feb  1 08:*:01 pylon CRON[*]: pam_unix(cron:session): session opened for user root by (uid=0)
     4 [5256845b] Feb  1 08:*:01 pylon CRON[*]: pam_unix(cron:session): session closed for user root

この出力では、左から「そのフォーマットが出現した回数」「フォーマットID」「推定されたフォーマット」になっています。また、推定されたフォーマットにおいて、値として埋め込まれると思われる部分を * という記号に置き換えています。この例ではサンプルが少ないため、IPアドレスの部分が * になっていないものもありますが、サンプル数が増えるとこれも * に置き換わります。上記は人間が読みやすいテキスト形式での出力になっていますが、別のプログラムで扱えるようにjson形式でも出力できます。

./logptn test.log -d sjson | jq . 
{
  "formats": [
    {
      "segments": [
        "Feb  1 ",
        null,
        ":",
        null,
        ":",
        null,
        " pylon sshd[",
        null,
        "]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=",
        null,
        "  user=root"
      ],
      "count": 4
    },
(snip)

さらに、そのフォーマットがログ全体のどの行数あたりに現れたのかをHTML形式で一覧にして表示することもできます。

$ ./logptn  ./var/log/secure -d heatmap -o secure.html

上記のコマンドでログのフォーマット、およびそれが何行目あたりに出現したのかを示すヒートマップを作成できます。ヒートマップは左が推定されたフォーマット、上のヘッダが行数（何行目〜何行目）、右が合計ログ数になっています。下の画像がちょっと小さくて見づらいですが、HTMLファイル自体はここからもダウンロード可能です。

f:id:mztnex:20180520141045p:plain 大きい画像

性能

計算量としては O(NM) になり、N がログファイルに含まれるログの総数、 M が推定されたフォーマットの数になります。いろいろなログファイルで試してみましたが M は10〜100ぐらいに収束するのでだいたいは N 、つまりログの総数が影響します。雑にしか計測していませんが、M=40 ほどになるデータに対して MacBookPro Early 2015 (2.7 GHz Intel Core i5) で動かして、おおよそ30,000 logs/sec 程度で動作しました。多分コード的にはもっと最適化できるんですが、まだそこまでは手を付けてません。

動作の仕組み

このあとはどうやってフォーマットを作成しているかという話なので、興味のある方だけどうぞ。

f:id:mztnex:20180524021502p:plain

すでに出力されているテキストログから元になったログフォーマットを推定する話は昔から研究としてありますが*3、今回 logptn で実装したのは非常に簡易なアルゴリズムになっています。昔は自分もいろいろとこねくり回した方法を考えたのですが、どれだけ複雑なアルゴリズムを使ったところで「まあ所詮は推測にすぎないよね」という割り切りを得たので、極力シンプルに実装しました。

手順

このフォーマット推定のアルゴリズムは4段階に別れており、それぞれ順番に解説します。

Phase1) Import logs

このアルゴリズムはバッチ型（ある程度の固まった量のログデータをまとめてから処理するタイプ）になります。一方で次々到着するログを逐次的に処理するオンライン型やストリーム型と呼ばれる手法もありますが、今回はもとになるデータセットは事前に決まっている（あとから増えない）ものとします。

取り込みに関しては全く難しいことはしておらず、現在は完全に1行1ログとして分割して切り分けています。全体の流れとしては複数行のログでも対応できないことはないアルゴリズムになっていますが、複数行で切り分ける基準がログごとに様々すぎるので、現状では対応していません。

Phase2) Chunking

データを1つずつのログ（現在は1行のテキスト、と同じ）に分割したあとは、そのログに含まれる単語などに分解する Chunking を実施します。これはログ内に埋め込まれる値は単語などの短い単位として出力される、という前提をおくことで、値として出力される単語の長さが違うことでフォーマットがばらつくのを防ぐのが目的です。例えば 0.0.0.0 と 255.255.255.255 という2つが別のログに現れたとしても同じ「IPアドレス」として認識してほしいですが、これを一文字ずつ比較しようとすると2つはかなり異なる文字列長になります（0.0.0.0 が7文字、255.255.255.255 が15文字）もちろんこういう文字列長の違いをうまく吸収してくれるアルゴリズムなら気にしなくていいのですが、だいたいは問題を単純化するために事前にログを単語（ここではchunkとよんでいます）に分割しています。

分割については、これが自然言語的な英語であれば単純に空白で区切ればいいのですが、ログファイルというのは様々な記号が含まれてそれによって区切られている場合もあるので、なかなか空白だけというわけにはいきません。実際にはある特定の記号が出てきた場合に区切るという実装にしており、現状 logptn だと \t!,:;[]{}()<>=|\\*\"' がデフォルトの区切り文字となっています。これらのうちどれかがでてきたらchunkとして切り分けてきます。（詳しくはこちら を参照）この記号の選び方は完全に自分の経験に基づくヒューリスティックなものなので明確な根拠はないですが、まあだいたいうまくいっている感じです。一方、これらの記号にもとづいてこのフェーズである程度正しく文を分割できることが前提となっているため、日本語のようなマルチバイト文字のログについてはおそらくうまくいきません。

また、ヒューリスティックを入れていいと考えるなら正規表現などによって日付やURL、Eメールアドレスなど値として埋め込まれると考えられるような形式の値をを特定して切り出してしまえばより精度があげられます。実際、それを見越して正規表現でそういった機能も実装したのですが、Goの正規表現モジュールが想像以上に遅くて厳しかったので、現状デフォルトの機能としては外しています。（一応、 --enable-regex オプションを使うと有効化はされます）

実際にこの方法で文を分割すると、以下のようになります。

  • Before: pam_unix(cron:session): session closed for user root
  • After: pam_unix, (, cron, :, session, ), :, , session, , closed, , for, , user, , root

Phase3) Clustering

Chukingされたログが出揃ったら次は類似しているログをクラスタリングします。クラスタリングも非常にシンプルなアルゴリズムを使っています（名前知らないだけで既存のクラスタリング手法かもですが）。以下の手順をログ1つずつ順番に試します。

  1. Chunk長（1つのログから生成されたChunkの数）が同じクラスタがなかったら手順終了
  2. 同じChunk長のクラスタ全部に対して距離を計算する
  3. クラスタとログの距離は、クラスタの中心になっているログとどれくらい近いかで計算する。ログ間の距離は全体でChunkが一致する割合を見て、割合が高いほど近いと判断する。
  4. クラスとの距離がthreshold（デフォルトでは0.7）を超えていたら、もっとも近いクラスタに組み込まれて手順終了
  5. もしthresholdを下回るクラスタのみだったらそのまま終了

クラスタに組み込まれずに終了した場合は、そのログを元に新しいクラスタを生成します。これをすべてのログに対して実施します。

Phase4) Estimate Format

クラスタが生成されたらあとはフォーマットを推定するのみです。これも非常にシンプルなアプローチで、クラスタ内のすべてのログに対して積をとっているイメージです。クラスタ内のログを L1, L2, ... , Ln としたとき、まず L1 と L2 で積をとって、L' を生成し、そのあとは Li と L' で積をとる、という処理を繰り返します。

  • L1: Requested from 10.0.2.3
  • L2: Requested from 192.168.0.1
  • L': Requested from null

同じクラスタだとChunkの長さがすべて同じになるので、互いのログのChunkを先頭から比較します。同じ内容であればそのまま、もし異なる内容であれば null とします。この null がフォーマットの中で値が入ると考えられる部分となります。このあと L3 と比較する際は null の部分はどのChunkと比較しても必ず null になります。

この操作をクラスタ内のすべてのログに対して実施すると、最終的にそのクラスタのすべてのログに適合できるフォーマットが生成（推定）できるということになります。

この手法の弱点

前述したとおり、このアルゴリズムはChunkingがある程度正しくできていて、かつ1 Chunk＝埋め込まれる値になることが強い前提となっています。そのため、たとえばChunkに分割されやすい任意長の文字列が登場するようなログ（極端に言えば、例えばユーザによる入力をそのままログに書き出すようなログ）に対しては非常に低い精度になると見込まれます。また任意長でないとしても同様にChunk分割によって1つの値が複数に分割されてしまうようなログには耐性がないと言えます。

また、現状のアルゴリズムだと複数のクラスタから同じフォーマットが生成される可能性があります。クラスタを生成する時のアルゴリズムがわりと雑なのでたまたま距離の計算でしきい値を超えてしまったなどの場合に、本来同じクラスタであるべきログが2つ以上のクラスタに分離してしまいます。これについてはまだすっきりした方法を思いついてないですが、生成後のフォーマット同士を比較してマージするというような処理が必要かなと考えています。

参考文献

*1:言い訳がましいのですがまだGo言語まともに書き始めて1ヶ月ぐらいという有様なので実装物について、流儀的にこういうの違うよ、とかGoならこういうふうにも書けるよ、みたいなコメントは大歓迎です

*2:そんな環境のほうがおかしいだろというツッコミはあると思いますが、稀によくあるシチュエーションでした。特に前職

*3:参考文献として幾つか論文へのリンクを貼っておきました

2018年春アニメはネット配信だけで視聴できるのか

背景

先日、会社でアニメの雑談していたときに「そういえば今時のネット配信はテレビ放映中のアニメのカバレッジってどれくらいなんだろう？」と気になりました。だいぶ配信が整備されてきたようなそうでもないような…。

個人的には四半期に一度せっせと録画の準備をしたり、HDDの残り容量を気にしていろいろケアしたり、録画に失敗したりというので消耗するのはそろそろやめたかったのでなるべくならネット配信で見てしまいたい派です。ということで、現実的にどれくらいの視聴ができるのかというのを知るべく、2018年春アニメのネット配信状況をまとめて見ました。

結果

2018年春アニメ ネット配信一覧 - Google スプレッドシート

※ 雑に作った＆後から情報が更新されることもあるようなので、間違いなどあればtwitterなどで指摘してもらえればと思います

結論から言うと「完全にネット配信だけで生きていくことはできないが、頑張ればわりといける」です。

まとめはある程度配信数を揃えていそうなサイトで、かつ月額定額制で（少なくともその期にやってるアニメは）定額のうちに入っているものを対象にしたつもりです。（ニコニコ、DMMなどは1週間で無料期間が終わってPay per viewになるので除外しました）

以下、まとめていた時の気づき。

  • 配信数はバンダイチャンネルとdアニメストアの二大勢力。しかしそれでも30本ちょいで今季から新しく始まった72作品の半分に届いていない
  • 日中や夕方にやるような本来子供向けのアニメはあまり配信されていない傾向にある。そのためみたいコンテンツが深夜アニメ枠ならかなりがカバーされている
  • AmazonビデオやNetflixは二大勢力には数で劣るものの、独占配信のコンテンツがいくつかある

Web系企業に転職して最高だったという話をしたい

11月にSI企業からCookpadにセキュリティエンジニアとして転職して1ヶ月たったのですが、いろいろ感銘をうけたのでその気持を忘れぬうちに文章に残しておきたいと思います。

disclaimer

  • 個人の主観であり、客観的にSI企業が悪いとかWeb系が良いとか言っているわけではありません。
  • かなり前職disな話っぽくなってしまっていますが、そこは企業としての性質の違いだとご理解いただければ幸いです。
  • 当該企業からはお金を頂いています。予めあしからずご了承ください。

しがらみが少ない

CookpadはWeb系の中でもかなり規模が大きい方だとは思うのですが、それでも前職のグローバル含めた規模のおそらく1/1000ぐらいであり、自分にとってはとても風通しの良い体質に思えます。

新しく何かを始めようとするときも、関係する人と立ち話で「こんな感じにしようと思うんだけどどうですかね」みたいなところをざっと決めて作りながら物事を進めていく…というやり方だと感じています。Rough Consensus and Running Codeという世界ですね。もちろんこの1ヶ月の間に細かい手戻りも何度かあったりしたのですが、ちゃんと合意を取りながらすすめると言ったやりかたを超えるスピード感で仕事をするのが重要と感じています。（もちろんこれは対象の規模などにもよりますが）

また、サービスなどに直結するような内容でも素早く動いていくことを重視しているように感じています。前職では何かしようとするとだいたい2〜3つ以上の力学というか外圧のようなものがあり、それをまずどうにかしないといけませんでした。グループ内部ではわりと好きにやらせてもらっていたのですが、その外に出ようとした瞬間に壁を突破したり調整したりが必要でそこで疲弊してしまうことが少なくありませんでした。現職では担当者同士ですぐ話をして次のステップへ進めるというサイクルが短く回っているため、むしろ振り落とされないよう頑張ってついていかねばと思う場面も少なくありません。

強いエンジニアが多い

とりあえず、右を見ても左を見ても豪傑ばかりという印象です。

前職でも研究所に学術的研究に秀でた方は多くいらっしゃいましたが、正直なところエンジニアリングが得意という人は全体でもかなり少なかったです。本当はエンジニアリングも得意だけど、そういうのが仕事の内容的に見えてこないというだけだったかもしれませんが、全体としてエンジニアリングにあまり積極的でない空気感を感じていました。

当然ながら現職ではエンジニアリングは非常に重要な位置づけとなっており、これを蔑ろにすると（多分）人権を失います。象徴的なイベントとして、入社後にちょうど社内ISUCONが開催され私も参加させてもらったのですが、出張や休暇などでいない人を除いて全技術職が参加必須というのに驚きました。技術職と言っても様々な分野の方（インフラ、サーバサイド、フロントエンド、モバイルアプリ、研究職）がいらっしゃるわけですが、皆さんほぼ基本的な技術は一通りできるのは当たり前で、その上で自分の得意分野を活かして競技に参加していました。

また、CTOが「今日一日業務が止まるのはとても手痛いが、それでもやる価値がある」と言っていたのがとても印象的で、ちゃんとエンジニアの育成に力を入れているんだなと思いました。

セキュリティの分野についても入り組んだ攻撃や防御の話に通じている人はあまりいませんが、実践のサービス開発と運用の部分については長年の蓄積を持つ人が多く、学ばせてもらうところが多くあります。そういった環境に身を置けるというのはエンジニアとしてありがたいことだと思います。

当事者意識があり、サービス・環境の改善にとても前向き

自分たちが作っている・使っている環境を常に良くしていこうという文化を強く感じます。前職の場合、基本的には本社なり別部署が決めたものを（それがどんなに使いづらいものでも）言われるがままに使うというのが基本でした。規模の大きさを考えると仕組みや使うものを決める人と使う人を分けたほうが仕事が明確になって良いのでしょうが、使いづらさやだめなところがいつまでも改善されないというフラストレーションがありました。

現職場では自分達が使うものを自分たちで選び、時には作るといったことをするため、常に「どうすると良くなるか？」といった方向を見ているなと感じています。これは今あるものを良くするためにも重要なことだし、その良くなったものをベースにまた次の新しいことを始めるのにも活きてきます。また、そうするべきかという議論や検討はもちろん必要ですが、ソフトウェアであれば自分で作ってしまっても良いわけで、ものづくりが好きな自分としてはそれも魅力の一つになっています。

自由にオープンソースにコミットできる

正直、これが一番強烈だったかもしれせん。

入社する前から外部に対してアウトプットしていくことは評価にも含まれており望ましいという話は聞いていたのですが、実際にとても自由な状況でした。OSSに関するポリシーを見てみると "従業員は自分の良識に基づいて、業務時間中に開発したソフトウェアをOSSで公開できる" という説明を見つけ、あまりの神々しさに見た瞬間目が潰れるかと思いました。目がーっ！

前職では知財やそれに準じる成果物が非常に厳しく管理されており、私的時間に書いたコードですらOSSとして公開あるいはcontributeするのに内部レビューと承認が必要でした。おかげでOSS的活動が好きな自分としては少なからずストレスではあったのですが、それが完全に開放され翼を授かった気持ちです。というかむしろ、前職との違いに頭がクラクラしています。

おかげで、これまでgithub上でPRを送るというOSS活動に縁がなかったのですが、先日始めてPRを送りmergeされてました。実に大したことじゃないんですが、ささやかながら嬉しい気持ちになっています。今後は自分で書いているOSSだけでなく、他のOSSにも積極的に貢献していきたいと考えてます。

f:id:mztnex:20171203114238j:plain

その他

あまり本質ではないのですが、その他感動したことなどをいくつか。

いわゆる今時の仕組みを使った開発・運用

社内で動いているシステムやフレームワークを見て「おお、これが噂に聞いたgitでconfigのバージョン管理をして自動デプロイされるというあれか…！」と感動していました。github eterpriseまでは前職でも使っていたのですが、普通にコードのバージョン管理をするだけで（それでも社内ではかなり珍しい感じでしたが）そういった今時っぽい使い方はしていませんでした。まあがっつり運用というほどではなかったので、そこまでする必要がなかったと言えばそうなんですがね…。

開発マシンなど

マシン自体は前職もそこまで悪くなかったですが、現職ではさらにもう一回り上のスペックになっています（MacBookPro メモリ16GB）。基本、全員が4Kディスプレイを使っています。

キーボードやマウスについても、自分は最近 Realforce とLogicool G900 がベストな組み合わせなので「ちょいと値は張るけど新しく職場用に自分で買うかー」と思っていました。が、この話をしたら「いや、普通に発注してくださいよw」と言われするっと申請したらしゅっと支給されてとても感動しました。

無限のコーヒーやスナックがある

まったく本質ではないし、前職にいたときもコーヒー買うお金をケチったことなどないのですが、やはり無料で供給されると思うと気分が全く違いますね。ここしばらくカフェインをコードに変換する仕事をしていました。

おわりに

まだ転職してからたかだか1ヶ月なのでこれから見えてくる大変なことや苦労も色々あるとは思うのですが、今のところ職務内容も含めて、転職してよかったと思える生活をしています。

この記事は別にリクルート目的というわけではないので特にリンクなどは貼りませんが、現職ではセキュリティエンジニアだけでなくいろんな職種を募集しているので、興味のある方は気軽に声をかけてもらえればと思います。

追記

コメントとか見てたら「給与や労働時間の話がないのは闇」って書かれていて、みんなよく訓練されてるなぁと感心してしまいました。気になる方も多いと思うので一応追記しておきます。

  • 給与は前職で「独身一人暮らしが雑に出費しても貯金できる程度」もらってると書きましたが、そこからちょい上乗せするくらいもらっています。転職時にあんまり給与交渉しなかったので場合によってはもっとあがっていたかもしれません。
  • 勤務時間は基本1日8時間となっていてフレックスタイム制です。残業時間は先月で確か20時間ちょいぐらいだったと記憶していますが、これは働きはじめでいろいろ慣れていなかったこともあり、効率的にやればもっと短縮できそうではあります。

情報セキュリティ関連の求人

セキュリティ 仕事

先日転職したわけですが、転職活動序盤に「そもそも情報セキュリティ関連の求人ってどういうのがあるんだろう？」と思ってばーっといろいろな職種を見渡していました。その結果、概ねこういうカテゴリの募集があるのか、という知見を得たのでまとめてみます。これから情報セキュリティ関連の職種への就職・転職を考えている人の参考になれば幸いです。

なお、筆者の個人的嗜好によってバイアスがかかっている可能性は多分にあり、まったくもって網羅性を保証するものではありません。

脆弱性診断

自社で開発するプロダクトやサービスを検査し、脆弱性を発見する仕事。また開発物のチェックだけでなく、セキュアな開発のガイドラインを作成するというような仕事が付け加えられている場合もある。プロダクトやサービスに直接関連する開発の知識・経験が求められる。

SOCオペレータ

サーバやネットワークを監視してセキュリティインシデントを発見・対応する仕事。非常に規模が大きい自社サービスを抱えているところでは自社内だけを対応するケース（プライベートSOC）もあるが、おおむね契約したお客さんの環境を監視するManaged Security Serivceの要員を募集している場合が多い。監視機器の環境構築・導入・保守も担当する。インシデントを発見した場合に報告するだけなのか、インシデント対応をサポートするのかなどは会社によって異なる。

社内全体のリスク管理

個別のプロダクトやサービスの脆弱性を検査するだけでなく、社内全体のリスク評価の実施して改善案をだしたり、インシデント発生時の演習のとりまとめをやったりする。CSIRT (Computer Security Incident Response Team) に近い業務を求められるものもある模様。かなり上級職で給与レンジも高いが、幅広く深い知識と経験が要求される感じがした。

ITシステム部門（セキュリティ担当）

大手日系企業などに多い。社内のIT利用を統括するIT部門においてセキュリティ関連の業務を担う。社内でIT機器を使う際のセキュリティ関連ガイドラインを作成したり、ISMSなどのレギュレーション対応、セキュリティベンダへの発注、監査対応など諸々を対応する模様。自分で手を動かしてテクニカルなことをやる場面は少なそう。

インフラエンジニア

IT部門とやや似ているが、どちらかというと自社サービスのアプリケーション、ミドルウェア以外の部分（OS、ネットワーク、サーバ管理など）を担当し、その中でセキュリティ業務も担当すると言った感じ。どちらかというとセキュリティはおまけ要素っぽさがある。

セキュリティプロダクトベンダのテクニカルセールスやサポート

外資系ベンダに多い。日本でプロダクトを売る時に導入や運用において起こる技術的な課題を解決する。またはプロダクトを導入後の問題に対して対応するようなポジション。外資系だとおそらく上司が海外にいるとか普通にあるっぽいので求人で英語力必須とある。

コンサルタント

お客さんのセキュリティ上の課題を洗い出し、ソリューションまでの道筋を示したりする。観測した範囲だとセキュリティ専門にやるというよりはITコンサルの中の一部の業務という感じっぽい。ここまでくるとあんまりエンジニアという枠ではないかも。

その他

  • リサーチャー：脅威分析などを専門にやるポジション。募集要項を見る限り学会などでの発表を目指すような研究者ではない（トーマツ等）
  • セキュリティプロダクトベンダの開発エンジニア：国内で募集している例はかなり少ない（トレンドマイクロぐらい？）
  • インシデントレスポンスチーム：まれに見かけた。自社内のインシデント対応を担当

退職します

2017年10月31日をもって，6年7ヶ月お世話になった日本IBMを退職します．

何やってたの？

最初に入社したときは研究部門（東京基礎研究所）につとめていてIBMクラウド上のログ管理のシステムやSIEM関連の開発をやっていました．2015年4月から1年半ほどIBM Tokyo SOC (Security Operation Center) で働かせていただいたのですが，いろいろな力学によって2016年9月ごろにはまた研究部門に戻っていました．

研究所では，自分はどちらかというと開発よりのプロジェクトをやることが多く，実験したり論文書いたりというようなアカデミックな活動はあまりできていません．ただ，やはりまわりは一流の研究者というか超人のような人たちが多く，色々刺激されたり勉強させてもらいました．特に学生時代の研究は我流で突き進んでいたところが少なからずあったので，改めて研究のやりかたについて学べたのはありがたかったです．

もともと学生時代にIDS（侵入検知システム）まわりをやっていたこともあり，SOCではその経験を活かしつつ， 実際の現場ではどのようになっているかということを肌感覚として大いに学ばせてもらいました． 最初の頃は純粋にアナリスト業務をやっていましたが、途中から業務効率化や分析の方が面白くなってしまい、後半はそういったツールの開発に取り組んでいました。Tokyo SOCレポート*1もほそぼそと執筆を続けさせてもらい楽しかったです．

現職どうだった？

素直に書いてみたいと思います．

  • 研究所は完全裁量労働で働く時間は相当な自由が効きましたが，一方で海外勢と一緒にやるプロジェクトだったりすると夜中の電話会議もそれなりの頻度でありました．
  • 個人的には給与に不満はありませんでした．独身一人暮らしが雑に出費しても貯金できる程度にもらっていました．
  • （少なくとも自分の周りは）仕事に対しては真摯で筋の通った方が多く，直接の人間関係で困ったことなどはほぼありませんでした．
  • 非常に古く大きい企業（創業から106年，全世界で社員数40万人弱*2 ）であるため，そういった組織特有のしがらみというか壁を感じる場面は少なくなかったです．

何で辞めるの？

新しい経験を積みたくなった，というのが最も大きな理由です．

開発に従事するのもSOCで監視をするのもそれぞれ楽しさはありますが，情報セキュリティという視点でみると それぞれ局所的になってしまっているなと感じていました．一口に情報セキュリティといっても， 現実にやならければいけないことは多岐にわたりそれぞれが密に連携している...と思っています． 今後，何か一つの技術や活動に注力するとしても，一度全体を見渡して情報セキュリティの設計・実装・運用に携わってみたいと思うようになりました．

そのためには現在の会社だとどうしても「BtoBのベンダ」という立ち位置になって局所的な話になりがちになってしまうため， もっと自分が全体に責任をもって取り組めるユーザ企業でセキュリティに取り組んでみたいと思って退職を決めました．

どこに行くの？

11月1日よりCookpad社にてセキュリティエンジニアとしてお世話になる予定です．セキュリティ界隈でまたしばらく活動させて頂くことになるかと思いますし，アカデミック方面にもできれば関わり続けたいと思っております．本職の開発の方々には及ぶべくもありませんが，開発自体は割りと好きな方なのでセキュリティ関連で面白いものを作っていくということもやりたいですね．

ということで，今後共何卒よろしくお願いいたします．

*1:https://www-935.ibm.com/services/jp/ja/it-services/soc-report/

*2:Wikipediaより https://ja.wikipedia.org/wiki/IBM