技術者ブログ

はじめに

2017/9/10(日)に「Security meets Machine Learning」に参加し、Scutumにおけるデータサイエンスの使い方について発表を行ってきました。今回は簡単な参加レポートをしたいと思います。

自分の発表

私はトップバッターでした。40分ほど時間を頂き、Scutumの防御機能の中核であるベイジアンネットワークや、最近導入を開始しているクラスタリングによる異常検知について紹介をさせていただきました。講演に使った資料は我々の主な敵であるスクリプトキディに見られたくない部分を含むため、非公開となっています。

現在、24時間休みなく、Scutum上を正常と異常が混ざった大量のデータが通過していきます。まさに「ビッグデータ」が手に入る状況ですが、それらすべてに「攻撃である・攻撃ではない」のようなラベルを付けることは現実的ではありません。そのためKaggleをウォッチして勉強した一般的な教師有り学習のテクニックは導入できておらず、クラスタリングによる教師無し学習によって正常（ありがち）とそれ以外を分けるところまでしかできていません。

教師有り学習にはできていないものの、やはりデータ量は正義であり、クラスタリングで得られた「ありがち」なデータをうまく使うことで、エキスパートの専門知識を量で上回り、それを使って誤検知を減らすことに繋げることができています。

40分も話ができる講演は久しぶりだったので最初はゆっくり喋っていたのですが、最後は結局時間が足りず、ちょっとあわただしい展開となってしまいすみませんでした。講演後、何人かの方から非常に参考になるフィードバックを頂くことができ、話をさせていただいて良かったと感じています。

はじめに

私は以前の「Struts2が危険である理由」というブログ記事において

例えばS2-045については止めることが出来ていました(ゼロデイでも防ぐことが出来ていました）が、S2-046についてはギリギリ、わずか数時間の差で先にScutum側の防御機能のアップデートが間に合いました。これを受けて今後、より力を入れてStruts2のOGNLインジェクションに特化したゼロデイ攻撃を想定した防御機能を開発する予定です

はじめに

2017年3月、Struts2にまたしても新たな脆弱性(S2-045、S2-046)が見つかり、複数のウェブサイトにおいて情報漏洩等の被害が発生しました。筆者は2014年4月（およそ3年前）に「例えば、Strutsを避ける」という記事を書きましたが、今読み返してみると「やや調査不足の状態で書いてしまったな」と感じる点もあります。今回、良いタイミングなのでもう一度Struts2のセキュリティについてざっとまとめてみたいと思います。

はじめに

ビッグデータ、データサイエンスという言葉の流行を大きく後押ししたのは大規模なスケールアウト、分散処理を可能としたHadoopの存在です。しかしデータサイエンティストは日々のデータ処理作業において必ずしも複数台のマシンを必要とするような大規模な処理ばかり行っているわけではありません。自身の開発用ワークステーション1台で完結するような処理も多数存在します。

2016年ではもはや当たり前ですが、多くのワークステーションはマルチコアのCPUを搭載しており、CPUがボトルネックになるようなデータ処理をマルチコアを活かして並列処理する重要性は高まっています。しかし、意外に多くのソフトウェアが、この当たり前に期待される「マルチコアを活かして単一ワークステーション上で高速並列処理すること」が出来ていません。

この悩みから、筆者は過去にテキストデータ処理を簡単にマルチコア対応にするJavaフレームワーク、MCPを開発してegrepより10倍速い行ベースの正規表現による検索を実装しました。また同様にWEKAのK-Meansクラスタリングをマルチスレッド対応させ、1台のワークステーション上でのクラスタリングを高速化しました。

続いて筆者の頭を悩ませたのは、RDBでのデータ解析です。データを対話的に解析するためにSQLを頻繁に利用しているのですが、メインで使っているPostgreSQLは基本的に1つのクエリは1つのCPUコア上で処理するため、マルチコアのパワーを全く活かせません（RDBではディスクアクセスがボトルネックになることが多いと思われていますが、CPUがボトルネックになるケースも結構あります）。

上記のMCPやWekaとは異なり、RDBのクエリを並列処理させるのはちょっとした開発で行えるような簡単なものではないので、どうしようかと悩んでいました。しかし最近になり、並列処理可能なRDB（MPPデータベースなどと呼ばれる）のうちの一つであるGreenplumがオープンソース化され、誰でも自由に使えるようになりました。

Greenplumを使うことで、マルチコアを全て活かした高速なデータ解析が行えるようになります。

はじめに

私は自ら「串職人」と名乗るほどウェブの(つまりHTTPの）Proxyサーバが好きで、もう10年以上もプロキシサーバを作り続けています。このブログの主題であるクラウド型WAF、Scutumもそのひとつです。そもそもプロトコルとしてのHTTPが好きです。ウェブの裏側に、とてもシンプルな、テキストベースのHTTPプロトコルが活躍しているということが私の串職人としての出発点です。

はじめに

先日、私たちが開発しているクラウド型WAFサービス、Scutum(スキュータム)において、予想していなかった箇所の修正によってサーバの負荷が大幅に減るということがありました。原因はこのエントリのタイトルにもあるように、Stringクラスのインスタンスを生成する際の方法にありました。

はじめに

以前のエントリに書いたように、Java7以前では、SSL通信の際にサーバソケット側で暗号スイートを決定することができず、どうしてもやりたい場合にはJSSEのソースコードを書き換える必要がありました。しかし昨今、SSLに関連する多くの脆弱性や問題が相次いで見つかるようになっており、サーバ側でも暗号スイートをコントロールしたいというニーズは高まっていると思います。Java8ではJSSEにおいてサーバ側暗号スイート選択の機能が実装され、またTomcatでも8.0.21においてこれが可能になりました。

はじめに

Scutumではベイジアンネットワークをはじめ、データサイエンスを積極的に導入して高性能のWAFを実現することを目指しています。データサイエンスやデータマイニングでは、解析対象のデータに対して対話的に解析を行うことが多くなります。今回は基本的には「対話的プログラミング環境でない」Javaで、データを対話的に解析する方法をご紹介します。

はじめに

この記事をお届けできることを非常にうれしく思います。タイトルは「ScutumはPOODLE攻撃を検知・防御する唯一のWAFです」となっていますが、実は末尾に「(ｷﾘｯ」が抜けているイメージです。

2015年1月26日より、クラウド型WAFのScutum(スキュータム)において、SSLv3を従来通り(AES/3DES/RC4)に使いつつ、POODLE攻撃を検知・防御できるようになりました。本エントリでは、その内容について説明をおこないます。

はじめに

数年前に発見されたHashDoSですが、実際に攻撃が行われているケースは殆ど目にしません。ソフトウェアのロジックを突くDoSとしては、他にApacheに対してRangeヘッダを使う攻撃手法(Apache Killer)なども発見されましたが、こちらも同様に、殆ど実際の攻撃としては検知していません。DoS攻撃にはもっと単純で、攻撃対象のアーキテクチャを調べる必要のない、シンプルな物量攻撃が好まれているような印象です。そのため筆者としてはHashDoSのセキュリティリスクは非常に低いものという認識です。

さて現在、国内ではあまりニュースになっていませんが、いくつかのミドルウェアにおいてHashDoS対策の漏れが発見されており、対策の実装が進められているフェーズのようです。これらのミドルウェアにおけるHashDoS攻撃の対策をScutumでは既に実施済みで、「ゼロデイ攻撃への対策」ができている状態です。情報がパブリックになった時点で、また続報をお届けします。