(cache) セキュリティスキャンサービス「Walti」使ってみた

2014-11-24

■[セキュリティ] セキュリティスキャンサービス「Walti」使ってみた

Twitterで流れてきた、「サーバサイドのセキュリティスキャンサービスWalti」がムラムラ気になっていたのだが、初回スキャン無料のキャンペーンをしているようなのでさっそく試してみた。

Waltiとは何か

最近、地味に流行の兆しを見せつつある(?)、Webサービス向けのクラウド型セキュリティスキャンサービス。提供は、インフラやってる人には有名な(株)ハートビーツの子会社(株式会社ウォルティ設立のお知らせ)。対抗馬としては、BitforestのVAddyになるのかな。

と言ってもこういうのは意外に結構昔からあるので、今風を名乗るならやはりAPIを用意して、cronやJenkinsと連携して自動的にセキュリティスキャンする……というCI的使い方をしたくなる（すなわちDevOpsならぬ、DevOps+Sec）。Waltiでもそういう使い方を意識しているようだが、APIはまだ準備中なのでWeb操作しかできない。

気になるスキャン価格は以下。

	Web料金	API料金
portscan	10円	8円
sslyze	5円	4円
nikto	10円	8円
skipfish	100円	80円

portscanは、nmapをかけてくれる。sslyzeとはSSLのCipherSuite列挙や、HeartbleedなどSSL関連のチェックをしてくれるもの。

niktoは結構昔からあるWebセキュリティスキャナで、Perlで書かれている。手元のMacBookで実行すると、こんな感じ↓。

macbook:nikto-2.1.5 ozuma$ perl nikto.pl -host localhost
- Nikto v2.1.5
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    localhost
+ Target Port:        80
+ Start Time:         2014-11-23 21:58:38 (GMT9)
---------------------------------------------------------------------------
+ Server: Apache/2.2.26 (Unix) DAV/2 mod_ssl/2.2.26 OpenSSL/0.9.8za
+ Server leaks inodes via ETags, header found with file /, inode: 260474, size: 44, mtime: 0x3e9564c23b600
+ The anti-clickjacking X-Frame-Options header is not present.
+ Uncommon header 'tcn' found, with contents: choice
+ OSVDB-637: Enumeration of users is possible by requesting ~username (responds with 'Forbidden' for users, 'not found' for non-existent users).
+ mod_ssl/2.2.26 appears to be outdated (current is at least 2.8.31) (may depend on server version)
+ OpenSSL/0.9.8za appears to be outdated (current is at least 1.0.1c). OpenSSL 0.9.8r is also current.
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS
+ mod_ssl/2.2.26 OpenSSL/0.9.8za - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell (difficult to exploit). CVE-2002-0082, OSVDB-756.
+ OSVDB-3092: /manual/: Web server manual found.
+ OSVDB-3233: /index.html.en: Apache default foreign language file found. All default files should be removed from the web server as they may give an attacker additional system information.
+ OSVDB-3268: /icons/: Directory indexing found.
+ OSVDB-3268: /manual/images/: Directory indexing found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ 6544 items checked: 0 error(s) and 13 item(s) reported on remote host
+ End Time:           2014-11-23 21:58:49 (GMT9) (11 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

skipfishは私知らなかったのだけど、アグレッシブにWebアプリをチェックしてくれるツールらしい。これだけお高いのであんまり気軽にかけられないね。

というわけで手持ちのサーバにスキャンしてみた。

スキャン手順

アカウントを作ると、まずログイン直後に「組織」を入力するように言われる。これはスキャン結果のグルーピングのものなので会社名というよりはチームとかシステム名的な扱いらしい。が、とりあえず個人利用としてみた。FAQにも、個人利用で構わないとはっきり書いてあるし（個人でも利用できますか？）。

スキャン自体は、基本的にIPアドレスを指定して「開始」を押すだけなのでそんなに難しいことは無い。ただし他人のサーバに勝手にかけられないように、Waltiはスキャン前に認証ファイルを確認するようになっている。ちょうどGoogle Webmasterとかで置くのと同様のもの。

このチェック用の認証ファイルはhttpで取りに来るので、httpを上げていないサーバ（メールサーバなど）や、80/tcp以外でhttpをサービスしているちょっと特殊なサーバはスキャンできない。まぁあんまり無いと思うけど注意。

また、初回スキャンでは、この認証ファイル確認後に問答無用でスキャンが始まるため注意しないとけない。

この確認画面が出た後、メニュー画面に戻るともうスキャンが始まっていた。ちょっとビックリした(^^;)。

とりあえず認証ファイルだけ置いてセッティングして後でスキャンしよう、と思っている人は注意。

スキャン元IPアドレス

FAQに記載されている通り、Waltiではスキャン元のIPアドレスを指定することはできない(Walti.ioからのスキャン元のIPについて)。

実際にスキャンして試してみたところ、スキャン元のIPアドレスはいくつかあるのだが、それらをWhoisで引いてみるとすべてDigital Oceanとなっていた。

macmini:~ ozuma$ whois -h whois.arin.net 162.243.139.152
....(省略)....
NetRange:       162.243.0.0 - 162.243.255.255
CIDR:           162.243.0.0/16
NetName:        DIGITALOCEAN-7
NetHandle:      NET-162-243-0-0-1
Parent:         NET162 (NET-162-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       AS14061, AS62567, AS46652
Organization:   Digital Ocean, Inc. (DO-13)
....(省略)....

というわけで、スキャン用サーバはDigital Oceanにあるようだ。おそらく動的に確保するから、スキャン元のIPアドレスを指定できないのだろう。

スキャン結果

ではスキャンしてみた感想……の前に、スキャン対象のサーバ構成をざっくり紹介。

対象サーバの構成

CentOS 6.5(64bit)で、以下サービスを用意した。

FTP: vsftpd(21/tcp)
SSH: OpenSSH(19022/tcp)
HTTP: Apache httpd (80/tcpと、10080/tcpから10099/tcpまで20コ)
HTTPS: Apache httpd (443/tcp, 20443/tcp)
MySQL: mysqld (3306/tcp)
Tomcat: ajp (8009/tcp), Coyote (8080/tcp)

Apacheは、ちょっと意地悪をして大量にListenディレクティブを書いて20個ほどのポートで同時に待ち受けてみた。

ポートスキャン

ポートスキャンはnmapで行われるので、その結果も見慣れたポートスキャンの出力である。次のように、「結果」のところに今風のWebデザインでのポート列挙と、nmapの出力のテキストを見ることができる。

なおスキャンはTCP SYNスキャンを全ポートで行い、UDPスキャンは実施されないので注意が必要(portscanについて)。

ところで、普通にnmapを走らせると以下のように最初にバージョン情報が表示されるのだが、これは意図的に(?)削られているようだ。うーん、検査データとして残すなら、バージョン情報も出しておいて欲しいな。

macbook:~ ozuma$ nmap -A localhost

Starting Nmap 6.47 ( http://nmap.org ) at 2014-11-23 21:35 JST
Nmap scan report for localhost (127.0.0.1)
....(省略)....

また見ると分かるのだが、このスキャンは「11月24日 19時26分13秒」に実施しているが、nmapの出力は、

Nmap done at Mon Nov 24 05:26:10 2014; 1 IP address (1 host up) scanned in 403.30 seconds

とJSTになっていない。まぁご愛敬か。

こういうポートスキャンをJenkinsでかけるというのは、アプリ屋さんはあまりピンと来ないだろうけど、インフラ屋さんやネットワーク屋なら結構良いかもと思う人もいるのでは。インストールしただけで勝手にハイポートを開くミドルウェアとか、いつの間にか開けてないはずのポートが開いていたファイアウォールとか、そういうのはやはり自動化の一環で見つけたいものです。