IDCF Tech-Blog

読者です 読者をやめる 読者になる 読者になる

IDCF テックブログ

クラウド・ビッグデータ・データセンターを提供するIDCフロンティアの公式エンジニアブログ

MastodonをIDCFクラウド上に構築してみた

Mastodonとは

MastodonはTwitterライクなSNSです。誰でも独自のMastodonインスタンスを作ることができて、すでに多数のインスタンスが立ち上がっています。登録されたインスタンスは、Mastodon instancesで参照することができます。

好きなインスタンスに参加するもよし、自分ひとり用のインスタンスを立ち上げるもよしです!本日はMastodonをIDCFクラウド上で構築する手順を紹介します。

f:id:ykanasugi:20170424140134j:plain

利用環境

  • IDCFクラウド light.S2 (1 CPU, 2GB メモリ)
  • Let’s EncryptでSSL証明書を発行
  • CentOS 7.3 64-bit テンプレート

仮想マシンの作成に関してはめちゃ楽ガイドを参照してください。

SSH用のポートにポートフォワードとファイアウォールの設定をしてSSHで接続します。

作業ディレクトリ作成

今回の作業用ディレクトリとして、/home/mastodonを作成します。

# mkdir -p /home/mastodon

dockerインストール

Mastodonはdockerコンテナを利用して構成されているため、dockerをインストール・設定していきます。

# yum -y install docker

docker保存先を変更

CentOS 7のテンプレートを利用する場合、ルートディスクが15GBで構成されます。ルートディスクのサイズは変更できないため、ボリュームを追加・アタッチし、dockerの保存先を変更しておきます。(mastodonのDBが肥大化する恐れもありますので)

仮想マシンへのデータボリュームの追加・パーティション作成・マウントについては、IDCFクラウドFAQを参照するかティアラちゃんに質問してみてください。

ディスクの追加完了後、下記ファイルを編集し保存先を変更します。 今回は/data/dockerというディレクトリを作成し、そちらを保存先にしました。

# vi /etc/sysconfig/docker

下記行がありますので、

OPTIONS='--selinux-enabled --log-driver=journald --signature-verification=false'

末尾に下記を追記します。

OPTIONS='--selinux-enabled --log-driver=journald --signature-verification=false -g /data/docker'

docker-composer準備

MastodonはPostgreSQLやRedisも利用しますので、docker-compose.xmlファイルを利用してコマンド一発で起動できるように準備します。

# curl -L https://github.com/docker/compose/releases/download/1.12.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
# chmod +x /usr/local/bin/docker-compose

インストールが正常にされたかを確認します。

# docker-compose --version
docker-compose version 1.12.0, build b31ff33

バージョンが表示されればOKです。

dockerの起動

dockerを起動します。

# systemctl start docker

Mastodonのインストール

GitHubからcloneする

MastodonをGitHubからcloneします。

# git clone https://github.com/tootsuite/mastodon

データの永続化設定

標準状態のままですと、データの永続化設定となっていないためコンテナを停止してしまうとデータが削除されます。 ユーザの登録情報等を永続的に維持するためにdocker-compose.xmlファイルを編集します。

# cd /home/mastodon/
# vi docker-compose.yml

下記のコメントアウトされているコンフィグを有効化します。(冒頭の#を外す)

#    volumes:
#      - ./postgres:/var/lib/postgresql/data

#    volumes:
#      - ./redis:/data

環境ファイルをコピーし設定する

# cp .env.production.sample .env.production

シークレットキーの発行

下記コマンドを実行してシークレットキーを発行します。(少し時間がかかります。)

# docker-compose build
# docker-compose run --rm web rake secret

キーは3つ必要なため、上記の'docker-compose run –rm web rake secret'コマンドを合計3回実行する必要があります。最後に表示された長い文字列をコピーして次のステップで貼り付けます。

環境ファイルを編集してシークレットキー・ドメイン名・HTTPSを有効化するかの設定をします。example.comとあるところはご自身のMastodonで利用するFQDNを設定してください。

# vi .env.production
PAPERCLIP_SECRET=(発行されたキー①を貼り付け)
SECRET_KEY_BASE=(発行されたキー②を貼り付け)
OTP_SECRET=(発行されたキー③を貼り付け)
LOCAL_DOMAIN=example.com
LOCAL_HTTPS=true

データベースのマイグレーションとフロントエンドコンパイル

下記コマンドを実行します。

# docker-compose run --rm web rails db:migrate
# docker-compose run --rm web rails assets:precompile

Mastodonコンテナを起動

# docker-compose up -d

docker psコマンドを実行すると起動しているコンテナ一覧を表示することができます。

# docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                              NAMES
ae2dc853c315        gargron/mastodon    "bundle exec sidekiq "   4 seconds ago       Up 3 seconds        3000/tcp, 4000/tcp                 mastodon_sidekiq_1
922437f3ff8b        gargron/mastodon    "bundle exec rails s "   4 seconds ago       Up 3 seconds        0.0.0.0:3000->3000/tcp, 4000/tcp   mastodon_web_1
f72ac86fa74e        gargron/mastodon    "npm run start"          4 seconds ago       Up 3 seconds        3000/tcp, 0.0.0.0:4000->4000/tcp   mastodon_streaming_1
147bec4a1086        redis:alpine        "docker-entrypoint.sh"   5 minutes ago       Up 5 minutes        6379/tcp                           mastodon_redis_1
75e3c4008fb8        postgres:alpine     "docker-entrypoint.sh"   5 minutes ago       Up 5 minutes        5432/tcp                           mastodon_db_1

Nginxのインストール

epelリポジトリを追加して、NginxとCertbotをインストールします。

# yum -y install epel-release
# yum -y install nginx certbot python-certbot-apache

Certbotを利用してSSL証明書を発行する

Certbotを利用し、Let’s Encryptから証明書を発行してもらうためには、443番ポートへのアクセスが許可されている必要があるので、管理コンソールからファイアウォールとポートフォワードの設定を追加します。443番のファイアウォールは、ソースIPをANYで開けてください。 具体的な設定方法については、めちゃ楽ガイドを参照してください。

下記コマンドを実行して証明書を取得します。

# certbot certonly --standalone -d <mastodonで利用するFQDN>

Nginx設定ファイルを準備する

MastodonのGitHubページ内にあるconfファイルの内容をコピーします。 下記ディレクトリに、mstdn.confとして保存します。

# cd /etc/nginx/conf.d
# vi mstdn.conf
コピーした内容を貼り付け

server_name、SSL証明書へのフルパスとrootを変更します。 また、今回はRSA鍵を使用するため、ssl_dhparamの行はコメントアウトもしくは削除します。

server_name example.com;

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# ssl_dhparam         /etc/ssl/certs/dhparam.pem;

root /home/mastodon/public/;

Nginxを起動する

# systemctl start nginx.service

Mastodonへアクセスする

設定したFQDNに対してブラウザでhttpsアクセスします。ユーザ登録画面が表示されれば完了です。

f:id:hikita:20170421175221p:plain

ユーザ認証をコマンドラインで実行する

登録をしてもメールサーバの設定をしていないため、登録後の認証用メールを受信することができません。 そのため、コマンドラインからユーザの認証を実施します。

# docker-compose exec web bundle exec rails mastodon:confirm_email USER_EMAIL=<認証するメールアドレス>

認証が完了するとログインできるようになりますので、ログインしてトゥートしてみましょう!

f:id:hikita:20170421175730p:plain

最後に

実は、IDCFクラウドでMastodonを運営するには結構メリットが多いのです。

もしアクセスが伸びてきて仮想マシンのスペックが足りなくなった場合、IDCFクラウドには無停止でスケールアップする機能(ダイナミックスケール)もあるのでご活用ください。

また、IDCFクラウドのメリットとして、アウトバウンドの転送量は3,240GBまで無償範囲内でご利用いただけます。超えてしまった分は10円/GBの従量課金となります。転送量の急増が心配な方は、予算アラート機能を使ってみてください。

コミュニティテンプレートVulsのアップデートについて

こんにちは。株式会社アールワークスの井上です。

前回に引き続き、コミュニティテンプレートVulsについて説明していこうと思います。
f:id:kkamiyakenshiroh:20170412192907p:plain

過去の記事はこちら↓
最近話題のセキュリティスキャナ Vulsと、Vulsのmeetup Vuls祭り Vol.1のご紹介
コミュニティテンプレート Vuls の利用とTips

今回は、先日更新されたコミュニティテンプレートVulsについて、下記内容を共有したいと思います。

  • コミュニティテンプレート更新内容の確認
  • Vulsミートアップ「Vuls祭り #2」

コミュニティテンプレート更新内容の確認

2017/04/01、IDCFクラウドの中の人にテンプレートのアップデートをしていただきました。ありがとうございます! 主な更新点は以下の通りです。

  • テンプレートのアップデート
    • Vuls および Vulsrepo を、2017/04/01時点の最新のものとしました
  • Vulsのアップデートサポートスクリプトを用意
    • 本家の機能ではないのですが、アップデートをスクリプト一つで実行できるようにしました
  • sudoersの厳格化
    • sudoersでのvulsユーザ権限を、より厳しい形にしました
  • デフォルトconfig.tomlの変更
    • VulsのREADMEの記載が、自身をローカルスキャンする設定になったため、デフォルトのconfig.tomlを変更しました
  • 上記に合わせたREADMEの更新
    • vuls scanおよびvuls report付近の記載を一部変更しました

これらについて細かく見てみます。

アップデート

Vulsのバージョンは2017/04/01時点の最新版にしていますが、日々バージョンアップされているため、必要に応じて更新が必要です。

  • 前回のコミュニティテンプレートリリース後、Vulsに大幅なバージョンアップがあったため、テンプレートも更新しています
  • 後述のアップデートスクリプトを用意しました。ある程度動作確認が取れているバージョンで更新しています

アップデートサポートスクリプトを用意

Vulsミートアップ「Vuls祭り#2」で、1コマンドでアップデートしたい、という話もあったため、取り急ぎ用意しました(公式の手順をシェルスクリプト化しているだけです)。

Vulsのアップデート

/home/vuls/scripts/update_vuls.sh として、vulsのアップデートスクリプトを用意しました。 vulsユーザで実行してください。

[root@HOSTNAME ~]# su - vuls
[vuls@HOSTNAME ~]$ /home/vuls/scripts/update_vuls.sh
Update vuls
remote: Counting objects: 70, done.
remote: Total 70 (delta 42), reused 42 (delta 42), pack-reused 28
Unpacking objects: 100% (70/70), done.
From https://github.com/future-architect/vuls
 * [new branch]      add-testcase -> origin/add-testcase
 * [new branch]      hostkey    -> origin/hostkey
   d4bec0d..f878e22  master     -> origin/master
 * [new branch]      nvd-url    -> origin/nvd-url
 * [new branch]      stty-localexec -> origin/stty-localexec
 * [new branch]      update-deps -> origin/update-deps
...Update start.
...Update finished.
Update go-cve-dictionary
remote: Counting objects: 28, done.
remote: Compressing objects: 100% (28/28), done.
remote: Total 28 (delta 8), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (28/28), done.
From https://github.com/kotakanbe/go-cve-dictionary
 * [new branch]      dep        -> origin/dep
   683256b..103ddbd  makefile   -> origin/makefile
   bbfdd41..4d5c2be  master     -> origin/master
   82087b2..bb95122  redhat-cvedates -> origin/redhat-cvedates
 * [new branch]      refactoring -> origin/refactoring
...Update start.
...Update finished.
[vuls@HOSTNAME ~]$
  • 状況によりますが、数分かかる場合があります。スクリプト実行後、そのままでお待ちください
  • 利用中のVulsバイナリを保存したい場合は、/home/vuls/go/bin/vuls をリネームして保存してください

sudoersの厳格化

セキュリティを考える場合、必要なもの(人やファイル)に必要な権限の実をつけるという"need to knowの原則"に従う必要があります。 Vuls実行ユーザ"vuls"にも同様な制限を実施しました。

[root@HOSTNAME ~]# cat /etc/sudoers.d/vuls
vuls ALL=(ALL) NOPASSWD:/usr/bin/yum --changelog --assumeno update *
vuls ALL=(ALL) NOPASSWD:/usr/bin/yum --version
vuls ALL=(ALL) NOPASSWD:/usr/bin/yum --color=never check-update
Defaults:vuls env_keep="http_proxy https_proxy HTTP_PROXY HTTPS_PROXY"
[root@HOSTNAME ~]#

Vulsに限りませんが、アプリケーション専用ユーザ等を用意する場合でセキュリティを考慮するときは、以下の点を検討してください。

  • ファイルのOwnerになる必要があるのか
    • 読み込みと実行だけでよければ、グループとしてアクセス権を付与することをお勧めします
  • 無制限の権限を付与しない
    • sudo -s をさせない、必要なコマンドのみ権限を付与する
    • vulsユーザへは、yumのオプション付きで権限を与えています

デフォルトconfig.tomlの変更

最初にコミュニティテンプレートVulsがリリースされた後、Vulsでローカルスキャンが実装されました。それに伴い、自分自身へのスキャンは「ローカルスキャンモード」を利用するようにREADMEの記載が変わりました。

ローカルスキャンは、SSH接続不要なモードです。

コンフィグの記載方法の違いは、以下の通りです。

  • リモートスキャン(今までの方法)
    • host, port, user, keyPath を指定
      • SSH接続をする為に必要な情報
  • ローカルスキャン
    • host および port を指定
      • hostは、localhost 若しくは 127.0.0.1
      • portは、local
      • 上記の2つの指定がされていた場合、ローカルスキャンとなる

Vulsサーバ自分自身はローカルスキャン、自分以外のサーバはリモートスキャン、とするのが良いと思われます。

上記に合わせたREADMEの更新

Vulsのレポートオプション等について、簡単に記載しました。

おおよそ以下のようなフローで利用することになります。

  • スキャン
    • vuls scanコマンドで、スキャンをします
    • 必要に応じて、コンフィグファイルの指定-configや、デバッグ-debugなどのオプションを指定してください
  • レポート
    • まずはレポートの前処理として、以下を実行します
      • vuls report -to-localfile -format-json -lang ja
        • vulsのスキャン結果は resultsディレクトリにjsonファイルとして保存されます。この段階ではCVEの詳細等は含まれていません
        • まずは上記コマンドを実行することで、go-cve-dictionaryを使ってjsonの情報を更新します
    • 次に、必要な通知処理を実施します
      • どこに出力するかを、-to-xxxオプションで指定します
        • -to-email, -to-slack, -to-localfileなどです
        • -to-localfileの出力先は、reportディレクトリ以下になります
      • 出力形式を、-format-xxxオプションで指定します
        • -format-json, -format-xml, format-short-textなどです

以上で、コミュニティテンプレートの更新内容と、簡単なVulsのスキャンについて説明しました。 次は、Vuls祭り#2 についてレポートします。

Vulsミートアップ「Vuls祭り #2」

2017/03/27に Vuls祭り#2 が行われました。

  • コミュニティテンプレートVulsを作成頂いた、IDCFクラウドの中の人にもお話しいただきました

Vulsを利用した脆弱性対応や、サーバレスでVulsを使う、mackerelとの連携、などの話がありました。 セッションの資料について、一部アップロードされているので、興味のある方はご覧ください。

次回は夏ぐらいに実施されると思うので、セキュリティや運用に興味のある方はご参加ください。

最後に

今回は、テンプレート更新部分について記載しました。次回からは、コミュニティテンプレートを利用した監視の構築について書いていければと思います。

Vulsを使って、セキュリティ対応や運用の負荷を下げられれるといいですね。

尚、弊社 株式会社アールワークスでは、マネージド運用サービスを行っています。Vulsを使った運用も可能ですので、運用にお困りの場合はご相談ください。

IDCFクラウドで採用されたVXLAN over CLOS

みなさまはじめまして、UX開発部の橋口です。

今回の記事は、IDCFクラウドの東日本リージョン2に採用された、新ネットワークアーキテクチャである「VXLAN over CLOS」についてです。
「VXLAN over CLOS」の設計思想や、今までのアーキテクチャと比べ何が違うのかなどを書いていきます!

VXLAN over CLOSとは

続きを読む

コミュニティテンプレート Vuls の利用とTips

こんにちは。株式会社アールワークスの井上と申します。

VulsユーザーズグループであるVulsのSlackに参加している関係で、記事を書く機会をいただきました。 IDCFクラウド アンバサダープログラムのMORIO Dojoにも参加しています(白帯のままです...)。

前回は、Vulsのミートアップである Vuls祭りVol.1の記事を書きました。引き続き、Vulsの記事を寄稿させていただきます。

さて先日、IDCFエバンジェリストグループの方から、Vulsのコミュニティテンプレートが公開されました。 今回は、このコミュニティテンプレートについて内容を確認し、追加の情報を提供させていただきます。

  • 始まりのVuls/VulsRepo (Vulsを使ってみよう)
  • Vulsコミュニティテンプレート利用時に役立つTips
  • Vulsコミュニティテンプレートの構成について
  • Vulsミートアップ「Vuls祭り #2」のご紹介 & 有用なリンク集
  • 最後に

まずは、Vulsアップデートはせず、テンプレートのまま使ってみましょう。

始まりのVuls/VulsRepo

そもそも、Vuls/VulsRepoとは

f:id:kkamiyakenshiroh:20170412192907p:plain
Vulsは、OSSの脆弱性検知ツールです。Githubで公開されています。

  • コミュニティはSlackにあります。自由に参加可能です
  • 英語圏での反響もあるため、GithubのPullRequestやIssueは英語のことが多いです
    • ですが、Slack内のvulsjpでは日本語でやり取りされているので、英語が苦手でも大丈夫です

VulsRepoは、Vulsのスキャン結果をインタラクティブに見ることができる、OSSのWEBアプリケーションです。 こちらもGithubで公開されています。

  • 使い方は、Github上にgif動画で公開されています
  • 基本的には、見たいスキャン日時やサーバーを選択し、任意の条件でドリルダウンしていくように使います

Vulsでスキャンして、VulsRepoで見る、というのが一連の流れになります。

使ってみよう

Vulsコミュニティテンプレートを利用することで、Vuls/VulsRepoをすぐに利用できます。 初期設定では、自分自身の脆弱性をスキャンするように設定されています。

  1. Vulsコミュニティテンプレートから、サーバーを作成
  2. 構築したサーバーへのアクセス経路を調整
  3. SSH接続し、脆弱性のスキャン
  4. HTTPアクセスで、脆弱性の状況を確認

簡単ですね。
もう少し詳しく、設定を見てみましょう。

1.Vulsコミュニティテンプレートから、サーバーを作成
サーバーの作成方法は、他のコミュニティテンプレートの作成方法と同じですので、割愛します。
IDCFが「コミュニティテンプレートから仮想マシンを作成する」というTIPSページを公開しています。
https://www.idcf.jp/help/cloud/guide/vm_community_temp.htmlwww.idcf.jp

2.構築したサーバーへのアクセス経路を調整
サーバー作成後、Vuls設定のためにSSHアクセス、VulsRepoを見るためにHTTPアクセスの設定が必要になります。

  • IDCFクラウド上のサーバーで同じセグメントから利用する分には、特に設定は不要です
  • インターネット側から見る場合には、ポートフォワードとファイアウォールの設定が必要になります
    • インターネット経由でアクセスをさせる場合は、アクセス制限等を 別途しっかり行う必要があります。 必要に応じて、ソースIP制限や認証の追加をしましょう
    • 今回は特に制限を行わず、作成したサーバーをインターネット経由で公開してテストしました
ポート番号 用途
22 Vulsの設定時に必要
80 VulsRepoの閲覧時に必要

3.SSH接続し、脆弱性のスキャン
設定が出来たら、SSHで作成したサーバーにログインし、脆弱性スキャンをしてみましょう。

  • サーバー作成直後であれば、rootでのみログインできます
  • su で vulsユーザになり、スキャンコマンドを実行します
    • go-cve-dictionaryというCVEデータベースのアップデートを行ったあと、vulsでスキャンを行います

f:id:kkamiyakenshiroh:20170313103356p:plain

今回は、CVE番号が割り当てられている脆弱性はなく、12個分の更新がある事が分かります。

  • 12 updateable packageとありますが、1つにパッケージに複数の更新がある場合もあるので、yum upadteで出てくる アップデート可能パッケージ数とは異なる場合があります
    • この記事のタイミングで上記確認できたので、最新版では修正されます。 Vulsのupdatableの数は、check-updateの数と同じになります

次に、Vulsスキャン結果を CVEデータベースと突き合わせる report コマンドを発行します。

  • reportコマンドにより、パッケージのChangelogにある CVE番号から、共通脆弱性評価システムCVSSの情報と連携します
    • CVSSについては、IPAの資料が詳しいです
    • ざっくりと、どの程度危険なのかを判別するための情報、と考えてよいです
    • 見方がよく分からない場合は、Base値 ( 基本値 ) を見て、大きいほうが影響が大きい、と考えてください
  • レポート形式は複数選択可能です
    • 出力先は -to オプションで選択します。ファイルの場合は -to-localfile、Slackの場合は -to-slackなどです
    • 出力フォーマットは -format オプションで選択します。XMLの場合は -format-xml、短いテキストの場合は -format-short-textなどです
  • VulsRepoはjson形式が必要となるため、-to-localfile -format-json で出力する必要があります
[vuls@vuls vuls]$ vuls report -to-localfile -format-json
[Mar  6 20:38:50]  INFO [localhost] Validating Config...
[Mar  6 20:38:50]  INFO [localhost] cve-dictionary: /opt/vuls/cve.sqlite3
[vuls@vuls vuls]$ vuls report -format-full-text
[Mar  6 20:39:00]  INFO [localhost] Validating Config...
[Mar  6 20:39:00]  INFO [localhost] cve-dictionary: /opt/vuls/cve.sqlite3

vuls-server (centos6.8)
=======================
Total: 0 (High:0 Medium:0 Low:0 ?:0)    12 updatable packages

No CVE-IDs are found in updatable packages.
12 updatable packages

[vuls@vuls vuls]$

4.HTTPアクセスで、脆弱性の状況を確認
スキャンとレポーティングが無事に完了したので、VulsRepoで見てみましょう。 今回はCVE番号が割り当てられた脆弱性はないため、healthy、という表示になっています。

  • http://割り当てたIP/vulsrepo/ へアクセスすると表示されます
  • 最初に、左側から「確認したい日付」を選びます
    • 複数選択可能です。チェックを入れて「submit」を押してください
  • 左側の項目を ScanTime の列に移動させることで、項目ごとでのドリルダウンが可能です

f:id:kkamiyakenshiroh:20170313103555p:plain
これで、一連の スキャン/閲覧(と対応)の流れが終わりました。

次のステップ

まずは使ってみる、という観点からそのまま動かしてみました。しかしながら、これだけでは今回構築した Vulsサーバーしか脆弱性検査ができません。
次回以降、ほかのサーバーをスキャンする方法などを記載していきます。

Vulsコミュニティテンプレート利用時に役立つTips

Vulsは開発速度が速く、日によっては毎日PullRequestやMargeがされています。これは、脆弱性検知精度向上や 新たな対応OSの追加などのためです。( 先日、RaspberryPi用のRasbianがサポートOSに加わりました! )

自分でVuls/VulsRepoを更新することで、追加された機能/バグ修正/検知精度向上の効果を得ることができます。 アップデート手順等は次回以降で記載します。
今回は、コミュニティテンプレート版でも使える、最近実装した機能を紹介します。

ローカルスキャンを使う

同梱されている設定は、自分自身へ SSH経由でのスキャン を実施する設定です。 しかしながら、なるべくSSHでのスキャンをしたくない環境もあります。

その際に有用なのが、Vulsのローカルスキャンモードです。

  • ローカルスキャンの詳細については、次回以降で説明します
  • SSH接続をしてスキャンをするのではなく、ローカルのコマンドを利用してスキャンを行います
    • スキャンユーザには、SSH接続でのスキャン ( リモートスキャン ) と同様の権限が必要です

ローカルスキャンの設定

設定は、config.tomlを以下のように書き換えるだけです。

  • portをlocalに変更し、SSHユーザ/鍵の記載を削除する
    • hostが"localhost"若しくは"127.0.0.1" かつ portが"local"、の場合にローカルスキャンモードとなります
[servers]

[servers.vuls-server]
host         = "127.0.0.1"
port        = "local"

設定後、通常通りに vuls scan を行ってください。

cronでの実行

定期的な脆弱性スキャンのためには、cron等での実行が必要です。 その際には、どのような通知が必要なのか(メールやSlack通知が必要か、 VulsRepoのWEB-UIで見えればいいのか、等)を検討する必要があります。

出力方法に合わせて reportオプション(およびconfig.toml)を調整します。

以下に、メール通知想定でまとめてみます。

config.toml
SMTPサーバー接続情報等を追加で記載します。

[servers]

[servers.vuls-server]
host        = "127.0.0.1"
port        = "local"
smtpAddr    = "your-smtp-server-IP/FQDN"
smtpPort    = "25"
from        = "from-mail@domain"
to          = ["to-addr@domain"]
cc          = ["cc-addr@domain"]
subjectPrefix = "[vuls]"

cron化用のスクリプト
Vulsでのスキャン前に、CVEデータベースの更新が必要です。 そのため、CVEデータベースのアップデートをしてからVulsでスキャンをする、というスクリプトを作ります。 対話的に実行している場合はあまり気にならないのですが、いくつかの設定が必要です。

  • Vulsは、bashで実行する必要がある
  • いくつかのコマンド(rmなど)が必要なので、vulsユーザのパスを流用するのが簡単です。
  • スキャンデータの出力はカレントディレクトリとなるので、明示的に出力先を定義します。
  • 同様にconfig.tomlファイルも、明示的に指定します。

reportは メール かつ 短文形式 としています。ここは好みで変えてください。

#!/bin/bash
PATH=/bin:/usr/bin:/usr/sbin
CONFIG=/opt/vuls/config.toml
RESULTS=/opt/vuls/results
CVEDB=/opt/vuls/cve.sqlite3
LOGDIR=/var/log/vuls
go-cve-dictionary fetchnvd -last2y -dbpath=$CVEDB -log-dir=$LOGDIR
go-cve-dictionary fetchjvn -last2y -dbpath=$CVEDB -log-dir=$LOGDIR
vuls scan -config=$CONFIG -results-dir=$RESULTS -log-dir=$LOGDIR
vuls report -config=$CONFIG -results-dir=$RESULTS -cvedb-path=$CVEDB -log-dir=$LOGDIR -to-localfile -format-json
vuls report -config=$CONFIG -results-dir=$RESULTS -cvedb-path=$CVEDB -log-dir=$LOGDIR -to-email -format-short-text

Vulsコミュニティテンプレートの構成について

Vulsを動作させる環境は、人によって様々です。今回提供されている コミュニティテンプレートはどのように構成されているかを確認したので、 ある程度Vuls利用経験がある方は参考にしてください。

OS等について

OS CentOS6.8
OS Update 2017/02/24時点の最新
DISK (/dev/sda1)として 15GB
Vuls build 2017/02/06 v0.2.0 1730caf
sudo /etc/sudoers.d/vuls にエントリがある

ディレクトリ等について

ディレクトリ構成は以下の通りです。

  • /home/vuls以下に、バイナリ等が配置されている
  • /opt/vuls以下に、configとデータ類が置かれている
  • vuls/go-cve-dictionaryは、/var/log/vuls 以下にログを出す
/
├─....
├── opt
│   └── vuls
│       ├── config.toml
│       ├── cve.sqlite3
│       ├── cve.sqlite3-shm
│       ├── cve.sqlite3-wal
│       └── results
│           ├── 2017-02-24T11:54:18+09:00
│           └── current -> /opt/vuls/results/2017-02-24T11:54:18+09:00
├── home
│   └── vuls
│       ├── README
│       └── go
│           ├── bin
│           ├── go1.7.5.linux-amd64.tar.gz
│           ├── pkg
│           └── src
.....

Vulsミートアップ「Vuls祭り #2」のご紹介 & 有用なリンク集

Vuls祭り、またやります!

2017/03/24 (金) に、二回目のUser MeetUpである「Vuls祭り #2」が開催されます。 コアな方も、そうでない方も有意義に過ごせると思いますので、ぜひ参加いただければと思います。
https://vuls-jp.connpass.com/event/51343/
私も、ローカルスキャンと脆弱性対応の考え方について、少しお話をする予定です。

有用な情報源(リンク集)

また、Vulsに関する有用なリンクをまとめておきます。

最後に

コミュニティテンプレートを利用して、まずはVulsを使ってみる、という目的で書いてみました。

Vulsは複数のサーバーをスキャンすることで、システム全体の脆弱性残存状況が分かります。 次回以降で、他のサーバーの脆弱性をスキャンする方法や、監視サーバー等の連携、ローカルスキャンモードについて 書いていけたらと思います。

そして、弊社 株式会社アールワークスでは、マネージド運用サービスにVulsを取り入れたプランを準備中です。 Vulsによる残存脆弱性情報の可視化をしながら運用ができます。

よろしくお願いいたします。

IDCFクラウドでセカンダリIPを取得する方法

こんにちは!ソリューションアーキテクト部の金杉です。よくお客様からご質問をいただくので、本日はIDCFクラウドでセカンダリIPを取得する方法について紹介しようと思います。

はじめに

1つのネットワークインターフェイスに複数IPを割り当てたいというケースは多々ありますよね。例えばバーチャルホストを使って同じサーバーで複数ドメインを運営する時や、Virtual IP (VIP)を用いて冗長構成を実現したい時など、様々なシーンでセカンダリIPが必要になってきます。このような技術を一般的に"IPエイリアス"と呼び、元から割り当てられているIPと追加で取得したIPをそれぞれ"プライマリIP"、"セカンダリIP"と呼んだりします。

IDCFクラウドではセカンダリIPの取得が可能です。このブログではIDCFクラウドのサーバーでセカンダリIPの取得およびセカンダリIPアドレスをグローバルIPアドレスと紐づける方法を紹介します。

セカンダリIP取得の2つのパターンと手順

セカンダリIPの取得には以下2通りのパターンがあります。パターンによって、手順が異なりますのでご注意ください。区別がつかない場合は、図1を参考にしてみてください。

パターン1 (手順1) セカンダリIP経由でインターネットと通信する場合
パターン2 (手順2) セカンダリIP経由でインターネットと通信しない場合

f:id:ykanasugi:20170223115939p:plain
   ▲図1 セカンダリIP取得の際の2つのパターン

パターンによって手順が異なる理由は、IDCFクラウドのネットワーク仕様です。IDCFクラウドでは、コンピューティング環境とインターネットの間に仮想ルーターが存在します。対象のセカンダリIPがインターネットと通信をする場合、仮想ルーターを経由するので、セカンダリIPとグローバルIPを紐づける必要があります。一方、セカンダリIPがインターネットと通信をする必要がない場合、これらの操作が不要になります。なので、パターンによってセカンダリIPを取得する手順を両方紹介します。

仮想マシンのデプロイに関してはこちらを参考にしてください。

方法① インターネットと通信する場合

今回は、Light.S1(1コア, 1GBメモリ)の仮想マシンを使ってセカンダリIPを取得していきます。ホスト名はsecondary-ip-test、OSはCentOS 6.8を使用します。プライマリIPは10.32.0.122がDHCPで設定されています。

使用できるIPアドレスの確認

セカンダリIPとして使用できるIPアドレスは限られているので確認をします。IDCFクラウドコンソールより、左メニューバー「ネットワーク」、ターゲットのネットワーク名、「IPアドレス一覧」をクリックします。

f:id:ykanasugi:20170228101049p:plain

DHCP範囲内(CIDRの前半)のIPアドレスが選択できます。つまり、このテーブルに表示されている割当済みのIPアドレスと、「割当範囲外」のIPアドレスを除いたすべてのIPアドレスがVIPとして割当可能です。セカンダリIPはDHCPもしくはスタティックで取得することが可能です。今回は10.32.0.100を指定して使います。

TIPS: DHCP範囲内のIPを選択する理由は?
今回、対象のセカンダリIPアドレスとグローバルIPアドレスを紐づける必要があります。紐づけるにはAPI経由でポートフォワードもしくはスタティックNATの2つの方法があるのですが、いずれも仮想ルーターに対しての操作になります。仮想ルーターに対してIPアドレス関連の操作を行う場合、その対象となるIPアドレスは仮想ルーターが認識できる必要があります。DHCP範囲外のIPアドレスは仮想ルーターでは認識できないので、ここではDHCP範囲内のIPアドレスを選択する必要があります。(でないと、グローバルIPアドレスと紐づけることができません。)

セカンダリIPアドレスの取得

手順①ではセカンダリIPアドレスの取得はCloudStack API経由で行います。IPアドレスの値は、先ほど確認した10.32.0.100をスタティックで付与します。APIに関しては、API Referencesをご参照ください。

IPアドレスを付与するに必要なコマンドはaddIpToNicです。必要なパラメーターおよび取得方法は以下になります。

パラメーター 取得方法 取得の際の注意点
nicid listNics 取得にあたってvirtualmachineidが必要です。virtualmachineidはlistVirtualMachinesで取得できます
ipaddress 指定 今回は10.32.0.100を入れます。指定しない場合はDHCPで付与されます

IPアドレスの取得が完了した後、グローバルIPとセカンダリIPをenableStaticNatコマンドでスタティックNATします。必要なパラメーターおよび取得方法は以下になります。
※通常のスタティックNATの設定はIDCFクラウドコンソールからもできますが、今回はセカンダリIPを紐づけるため、操作はAPI経由で行う必要があります。

パラメーター 取得方法 取得の際の注意点
ipaddressid listPublicIpAddresses 特になし
virtualmachineid listVirtualMachines 特になし
vmguestip 指定 先ほど指定した10.32.0.100を入れます。DHCPで割り当てた場合もIPアドレスを入力する必要があります

それでは、これらのコマンドを使って実際に操作をしてみましょう。

コマンドラインツールのインストール
APIを利用するにあたって、コマンドラインツールのインストールが必要になります。インストールするサーバーは、Pythonが動けばどのサーバーでもかまいません。APIのGetting Started ガイドに沿って「簡単な使い方:Step4」までを実行してください。

APIでセカンダリIPアドレスを取得

# 仮想マシンのid一覧を表示
[root@API-Server ~]# cloudstack-api listVirtualMachines -t displayname,id
+---------------------+--------------------------------------+
|    displayname      |                  id                  |
+---------------------+--------------------------------------+
|  secondary-ip-test  | dd41b1a8-1c4a-48fd-b062-2ccab4c0ffc6 |
+---------------------+--------------------------------------+
 
# secondary-ip-testのNIC idを表示
[root@API-Server ~]# cloudstack-api listNics --virtualmachineid dd41b1a8-1c4a-48fd-b062-2ccab4c0ffc6 -t ipaddress,id
+-------------+--------------------------------------+
|  ipaddress  |                  id                  |
+-------------+--------------------------------------+
| 10.32.0.122 | 0f25accf-06f8-4722-beda-508cc832c4ef |
+-------------+--------------------------------------+
 
# secondary-ip-testのNICにセカンダリIPアドレスを指定して割り当てる
[root@API-Server ~]# cloudstack-api addIpToNic --nicid 0f25accf-06f8-4722-beda-508cc832c4ef --ipaddress 10.32.0.100

# もう一度secondary-ip-testのNICの情報を表示
[root@API-Server ~]# cloudstack-api listNics --virtualmachineid dd41b1a8-1c4a-48fd-b062-2ccab4c0ffc6
 (略)
 "secondaryip": [
  {
    "id": "fadd1502-3aaa-4576-a05a-0d4eb1762265",
    "ipaddress": "10.32.0.100"
  }
]
(略)

IDCFクラウドコンソールでグローバルIPを取得する
まずは、スタティックNATで使用するグローバルIPをIDCFクラウドコンソールより取得します。標準で1個付与されているグローバルIPはスタティックNAT用に使用できませんのでご注意ください。

IDCFクラウドコンソールにログインしたら、対象のリージョン→コンピューティングを選択し、左の「IPアドレス」タブをクリックします。画面の右上にある「IPアドレス取得」をクリックします。 f:id:ykanasugi:20170221105603p:plain

続いて、ポップアップが出てきたらIPアドレスの表示名と対象のネットワークを選択します。入力が終わったら右下の「取得する」をクリックします。 f:id:ykanasugi:20170221105948p:plain

先ほどのIPアドレスの画面に戻ったら、新たにグローバルIPが追加されているのが確認できます。現在「NAT」の欄は"なし"となっていますが、後ほど対象の仮想マシン名(secondary-ip-test)が表示されます。

f:id:ykanasugi:20170221112948p:plain

APIでセカンダリIPをグローバルIPとスタティックNATをする
それでは、先ほど取得したグローバルIPを10.32.0.100とスタティックNATします。

# 現在あるグローバルIPとそのidを表示
# 先ほど取得した210.140.43.145を使う
[root@API-Server ~]# cloudstack-api listPublicIpAddresses -t ipaddress,id
+----------------+--------------------------------------+
|   ipaddress    |                  id                  |
+----------------+--------------------------------------+
| 203.137.176.8  | eaa68c54-29a9-4ad1-bd93-32740e8bc15d |
| 210.140.42.154 | 7b469138-8504-4133-9c73-2d28ebde7aba |
| 210.140.43.145 | 17efd86a-9e2e-452a-ade9-d8b11610a091 |
+----------------+--------------------------------------+

# スタティックNATを有効化
[root@API-Server ~]# cloudstack-api enableStaticNat --ipaddressid 17efd86a-9e2e-452a-ade9-d8b11610a091 --virtualmachineid dd41b1a8-1c4a-48fd-b062-2ccab4c0ffc6 --vmguestip 10.32.0.100
{
  "enablestaticnatresponse": {
    "success": "true"
  }
}

スタティックNATのを確認
スタティックNATの設定が完了したら、ポータルから確認してみましょう。「NAT」の欄にsecondary-ip-testと表示されていますね。これで設定は完了です。 f:id:ykanasugi:20170221161116p:plain

手順② インターネットと通信しない場合

手順②ではセカンダリIPアドレスの取得は直接OS内で指定して行います。手順①より簡単です。このブログではCentOS6系とCentOS7系両方のやり方を紹介します。

使用できるIPアドレスの確認
セカンダリIPとして使用できるIPアドレスは限られているので確認をします。IDCFクラウドコンソールより、左メニューバー「ネットワーク」、ターゲットのネットワーク名、「IPアドレス一覧」をクリックします。

f:id:ykanasugi:20170227091449p:plain

ここで表示されている「割当範囲外」のIPアドレスがすべてセカンダリIPとして指定できます。(「利用不可」と書かれている最後の10個のIPアドレスだけはIDCFクラウド側で使用するため割当はできません)なので、この例では10.32.4.1を使います。

セカンダリIPアドレスの取得

CentOS 6系とCentOS 7系を例に手順を紹介します。

CentOS 6系の場合
今回は、Light.S1(1コア, 1GBメモリ)の仮想マシンを使ってセカンダリIPを取得していきます。ホスト名はsecondary-ip-test-cent6、OSはCentOS 6.8を使用します。プライマリIPは10.32.0.122がDHCPで設定されています。

#ifcfg-eth0:1の設定ファイルを作成
[root@secondary-ip-test-cent6 ~]# cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0:1

#IPアドレスをDHCP取得ではなく、スタティックに書き込む
[root@secondary-ip-test-cent6 ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0:1
DEVICE=eth0
ONBOOT=yes
IPADDR=10.32.4.1
NETMASK=255.255.248.0

#ネットワークの再起動
[root@secondary-ip-test-cent6 ~]# service network restart

#eth0の情報確認
[root@secondary-ip-test-cent6 ~]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:03:01:be:00:05 brd ff:ff:ff:ff:ff:ff
    inet 10.32.0.122/21 brd 10.32.7.255 scope global eth0
    inet 10.32.4.1/21 brd 10.32.7.255 scope global secondary eth0
    inet6 fe80::3:1ff:febe:5/64 scope link 
       valid_lft forever preferred_lft forever

10.32.4.1がちゃんと設定されていました。

CentOS 7系の場合
今回は、Light.S1(1コア, 1GBメモリ)の仮想マシンを使ってセカンダリIPを取得していきます。ホスト名はsecondary-ip-test-cent7、OSはCentOS 6.8を使用します。プライマリIPは10.32.0.209がDHCPで設定されています。

#まずは現在の状態を見てみます
[root@secondary-ip-test-cent7 ~]# ip addr show
(略) 
2: eno16777984: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:03:01:be:00:06 brd ff:ff:ff:ff:ff:ff
    inet 10.32.0.209/21 brd 10.32.7.255 scope global eno16777984
       valid_lft forever preferred_lft forever
    inet6 fe80::3:1ff:febe:6/64 scope link 
       valid_lft forever preferred_lft forever

#nmcliコマンドでセカンダリIPを追加
[root@secondary-ip-test-cent7 ~]# nmcli connection modify eno16777984 +ipv4.addresses  "10.32.4.1/21"

#ネットワークを再起動する
[root@secondary-ip-test-cent7 ~]# systemctl restart network

#再度NICの状態を確認
[root@secondary-ip-test-cent7 ~]# ip addr show
(略)
2: eno16777984: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:03:01:be:00:06 brd ff:ff:ff:ff:ff:ff
    inet 10.32.0.209/21 brd 10.32.7.255 scope global eno16777984
       valid_lft forever preferred_lft forever
    inet 10.32.4.1/21 brd 10.32.7.255 scope global secondary eno16777984
       valid_lft forever preferred_lft forever
    inet6 fe80::3:1ff:febe:6/64 scope link 
       valid_lft forever preferred_lft forever

こちらでも10.32.4.1がちゃんと設定されていますね。

まとめと注意点

セカンダリIPを使いたい時は、まずはどのような利用をするかに沿って方法を選択しましょう。ちなみに以前セカンダリIPを使ってLVSを冗長化する記事も書いたのでご参考ください。

手順①のAPI経由で取得したセカンダリIPの扱いには、2つ注意点がありますのでご参考ください。

  1. セカンダリIPはIDCFクラウドコンソールからの管理ができないので、ご自身での管理となります。
  2. セカンダリIPをグローバルIPとスタティックNATした場合、APIでスタティックNATを解除してから仮想マシンを削除するようにしてください。スタティックNATの設定解除せず、そのまま仮想マシンを削除してしまうとシステム側からスタティックNATが削除できなくなってしまいます。

方法2については特に注意点はないのですが、紹介したCentOS6と7の方法は両方ともネットワークの再起動が伴うため、動的にIPを追加したい場合はip addr addコマンドなどで追加することも可能です。

ぜひ、試してみてください。

IDCFクラウドでのマルチキューネットワーク

f:id:tafujish:20170127205753p:plain

仮想環境や古いサーバーだと上記画像のように、CPU使用率が特定のコアに偏ることがあると思います。特に2番のCPUのsi(ソフトウェア割り込み)の値のみ大きいです。このような場合、マルチキューネットワークに対応することで複数のCPUコアを利用することができるためネットワーク性能をスケールすることができます。

この話はしばしば質問いただきますが、IDCFクラウドの仮想マシンのNICはRSS(Receive Side Scaling)に標準で対応しているので、マルチキューネットワークのためにこれといった操作や設定は不要です。

「以上です。」
で終わってしまいそうな話ですが、以下ではもう少し踏み込んでみるので、CPUの各コアの利用が偏っている場合は次を参照ください。だいたい多い話として、irqbalanceが入っていなかったり、ダイナミックスケール後の話だったり、ISOから作った仮想マシンだったりします。

1) RSSに対応しているか確認するには

RSSはNIC側で複数のキューを持ち、複数のCPUコアを活用できます。

IDCFから提供しているテンプレートから仮想マシンを作成すると、標準でRSSに対応したNICである「vmxnet3」が搭載されています。vmxnet3であることの確認は、

# ethtool -i ens160
driver: vmxnet3
version: 1.4.7.0-k-NAPI
~略~

※ens160はネットワークインターフェース名(eth0等適宜置き換えてください)

driverがvmxnet3であれば、このNICはRSS対応となります。

では、具体的にマルチキューになっているか確認しましょう。

# ls /sys/class/net/ens160/queues/
rx-0  rx-1  rx-2  rx-3  tx-0  tx-1  tx-2  tx-3

※ens160はネットワークインターフェース名(eth0等適宜置き換えてください)

rx-0からrx-3の4つが受信キュー、tx-0からtx-3の4つが送信キューです。
仮想マシンのCPUのコア数と同じ数のキューが有効になっています。(この仮想マシンはHighcpu.L8の4コアマシン)

この4つのキューが、どこのCPUコアに割り当てられてるかは次のように確認できます。

# cat /proc/interrupts | grep ens160
  56:         39          0          0      44516   PCI-MSI-edge      ens160-rxtx-0
  57:          7      44132          0          0   PCI-MSI-edge      ens160-rxtx-1
  58:         16          0      44175          0   PCI-MSI-edge      ens160-rxtx-2
  59:         28          0          0      44739   PCI-MSI-edge      ens160-rxtx-3
~略~

※ens160はネットワークインターフェース名(eth0等適宜置き換えてください)

割り込みのカウントが上がっているところを見ると、0番のキューはCPUの3番、1番のキューはCPUの1番、2番のキューはCPUの2番、3番のキューはCPUの3番に割り当てられてます。
この環境はCentOS7.3ですが、0番のCPUが使われておらず、3番のCPUに2つのキューが割り当てられています。このあたり、気になる方は、次の 2) を参照ください。

では、この環境に負荷をかけて、CPUの使用率を確認します。

f:id:tafujish:20170127205755p:plain

上記のキューの割り当ての通り、0番のCPUの負荷は低く、3番のCPUの負荷が高くなっています。
ここまで確認したように動いていれば、RSSが正常に機能しています。
NICがvmxnet3で、キューの数もCPUコア数に応じた数があるのに、CPUの使用率が異なる場合、キューが各CPUに割り当てられていない可能性があります。そのようなときはirqbalanceをyumやaptでインストールして動かしてみてください。

執筆時点のIDCFクラウドの標準テンプレートだと、CentOS6.xと7.xでははじめからirqbalacneがインストールされていますが、Ubuntu16.04ではインストールされていません。

2) CPU0番コアが使われていないとき

先述のとおり、RSSが機能しており、irqbalanceが各CPUコアにキューを割り当てているのに、0番のCPUが使われないのは、irqbalanceが0番のCPUに割り当てないためです。
CnetOS6.xでは0番にも割り当てますが、CentOS7.xやUbuntu16.04では0番に割り当てられません。

偏りが問題ないレベルであれば、そのまま利用いただいて問題ないですが、カツカツにCPUリソースを消費していて偏りが困る場合は、キューの割り当て先CPUを手動で変更することもできます。

まずは、割当先を変更したい0番のキューのIRQ番号確認します。ここでは56番です。

# cat /proc/interrupts|grep ens160
  56:         39          0          0     268151   PCI-MSI-edge      ens160-rxtx-0
~略~

※ens160はネットワークインターフェース名(eth0等適宜置き換えてください)

次に現在の割当先を念のため確認します。ここで先ほど調べたIRQ番号を入れます。ここでは、「8」となってますがビットで記載されているので、3番のCPUに割り当てとなっています。
(ちなみに、0番のCPUは「1」、1番のCPUは「2」、2番のCPUは「4」となります)

# cat /proc/irq/56/smp_affinity
00000000,00000000,00000000,00000008

0番のCPU(値としては「1」)に割り当て、確認します。

# echo 1 > /proc/irq/56/smp_affinity
# cat /proc/irq/56/smp_affinity
00000000,00000000,00000000,00000001

この状態で負荷をかけるときれいに分散されました。

f:id:tafujish:20170127205757p:plain

この設定はOS再起動で消えてしまうので、必要だったらOS起動時のスクリプトに記載ください。
また、irqbalanceがデーモンとして動いていると変更した設定を戻されてしまうので、irqbalanceのサービスを止めるかONESHOTの設定にする必要があります。

3) ダイナミックスケール後の対応

IDCFクラウドでダイナミックスケールした後、増えたCPUのコアがちゃんと使われていないというような質問をしばしばいただきます。

実はダイナミックスケールによりCPUのコアが増えたとしても、RSSのキューの数が増えないため、増えたCPUコアをNICが使うことはありません。
増えたCPUコア分のキューを増やすには、vmxnet3のモジュールをいったん削除し、再度追加することで認識できます。

# modprobe -r vmxnet3; modprobe vmxnet3

ただ、この方法だとモジュールを削除するので瞬断が発生します。
それが難しい場合は、以下の4)のようにRPS/RFSでマルチキュー化でしのぎ、次回OS再起動時にRSSに戻るという方法もあると思います。

4) RSS対応してないときはRPS/RFSで

RSSはNICの方が対応しているマルチキューネットワークであり、NIC(今回だとvmxnet3)が対応している必要があります。IDCFクラウドでは、vmxnet3以外のNICも利用可能です。

  • テンプレートインポート時にe1000かpcnet32を選択することもできます
  • ISOインストールでの仮想マシンはデフォルトでe1000となります

このように、vmxnet3以外のときは、OS側でマルチキューネットワークに対応させます。具体的には、 RPS(Receive Packet Steering)、RFS(Receive Flow Steering)です。

では具体的な設定を紹介します。
例えば、以下のようなe1000のNICでキューが1つしかない、4コア仮想マシンの環境があったとします。デバイス名はens35とします(eth0等適宜置き換えてください)。

# ethtool -i ens35
driver: e1000
version: 7.3.21-k8-NAPI
~略~

# ls /sys/class/net/ens35/queues/
rx-0  tx-0

まずはRPSの設定です。入力している「f」は4コアすべて利用するときでビット計算となってます。例えば、2コアのときは「3」、8コアのときは「ff」となります。

# echo f > /sys/class/net/ens35/queues/rx-0/rps_cpus

次にRFSです。rps_sock_flow_entriesの値は、一般的に「32768」が推奨されています。
一方で、rps_flow_cntは、rps_sock_flow_entries÷受信キューの数となります。e1000のこの環境ではキューは1つのため、rps_sock_flow_entriesと同じ値となります。

# echo 32768 > /proc/sys/net/core/rps_sock_flow_entries
# echo 32768 > /sys/class/net/ens35/queues/rx-0/rps_flow_cnt

以上ですが、上記設定はネットワークインターフェース毎に設定が必要なので、複数NICがある場合はその分実行ください。また、これらの設定はOS再起動で消えてしまうので、必要だったらOS起動時のスクリプトに記載ください。

5) e1000のテンプレートをvmxnet3に変える

先述のとおり、e1000でもRPS/RFSでマルチキューネットワークは利用できますが、設定が面倒だとか何らかの理由でvmxnet3に置き換えたいときもあると思います。

そのときは、テンプレートを一度エクスポートしていただき、再度インポートしていただければ、インポート時の設定で下図のようにNICの種類を指定することが可能ですので、こちらもご検討ください。

f:id:tafujish:20170127205758p:plain

まとめ

長くなりましたが、基本的にはRSS標準対応なので、手間なくそのままご利用いただけます。もしCPUのコアが偏っているようであれば、上記ご参照ください。

コーポレートサイトのセキュリティ対策は万全ですか?

はじめましてみなさん、コンテンツマーケティング部の河田です。
おもにIDCフロンティアのコーポレートサイトの運営を担当しています。

f:id:dkawata:20161226185447p:plain

当社のことをみなさんに知っていただく看板サイトとして、日々、新サービスの紹介やイベント、キャンペーン情報などを発信し続けています。
本日は、IDCFクラウド上で稼働しているコーポレートサイトを運用し続けるための仕組みを次のポイントに分けてわかりやすくご紹介していきたいと思います。

はじめに

今回お伝えしたい内容がこちらです。

  • 24時間365日運営できるサイト作り
  • サイトを守るために必要な3つの対策
    • GSLBによる広域負荷分散
    • DDoS対策サービスの導入
    • WAFの活用
  • 実際に障害が起こってしまったら
  • 最後に

前提となるWeb上の脅威のお話から、具体的な対策方法、障害発生時への備えまで一連の流れでご紹介したいと思います。では早速、本題に入りましょう。

24時間365日運営できるサイト作り

Webの世界にはリアル社会のように年末年始の休業期間などはありません。 基本的に24時間365日、サイトを運用し続けることが前提となります。
そしてWeb上でサービスを提供しているかぎり尽きないのがサイバー攻撃の脅威です。
中でもコーポレートサイトのような会社のブランディングに直結するサービスには DDoS攻撃などが猛威を振るってきます。 TCP・SYNフラッド、UDPフラッド、DNSアンプ、Low and Slow攻撃など、その種類は上げればきりがないくらい存在します。
また、それぞれの攻撃が狙うターゲットレイヤーも異なり、その規模もどんどん大きくなってきています。

こうした悪意のある攻撃からサイトを守るためには、単純にサーバーを強化するだけでは対策不足です。ネットワークインフラからサーバーまで一貫した対策が必要になります。

サイトを守るために必要な3つの対策

IDCFのコーポレートサイトは、これからご説明する3つのサービスを用いてセキュリティ対策を実現しています。
では、実際にどのような取り組みをしているのか簡単にご紹介していきます。

1)GSLBによる広域負荷分散

サイバー攻撃に関わらず、人為的なミスや大規模災害などが起きて、サーバーに何らかの障害が発生した場合、ただちにGSLBは登録されているディザスタリカバリ(DR)サイトへ自動でアクセスを切り替え、ダウンタイムを 最小限に抑えてくれます。
通常のロードバランサーと違い、東西の拠点でロードバランシングを行うため、より一層可用性が担保されます。アクセス数の多い都心部からのレイテンシを考慮し、プライマリサイトを東日本に構築していることもポイントです。
そして、拠点間でのコンテンツ同期やバックアップを行い、さらにプライベートコネクト接続で セキュアな通信網を利用すればベストです。

f:id:dkawata:20170106140952p:plain
▲GSLBによるDRサイトへの自動切り替わりイメージ

2)DDoS対策サービスの導入

このDDoS対策サービスというのは、トラフィックがサーバーに届くより前の段階のネットワーク領域でDDoS攻撃を緩和、防御してくれます。

もう少し詳しく説明すると、以下のフローを自動で行います。
1. ネットワーク上の振る舞いから悪意のあるトラフィックを検知する
2. そのトラフィックを遮断するためのシグネチャを自動生成(動的シグネチャ
3. フィルタリングを実行

既知の攻撃手法に対しての防御は不正侵入検知/防御サービス(IDS/IPS)で対応可能ですが(静的シグネチャ)、未知の攻撃や巧妙に細工された攻撃にはこのDDoS対策サービスが特に効果を発揮します。

※静的シグネチャとは、既知の攻撃パターンをデータベース化して管理した上で、該当する攻撃をフィルタリングする方式です。

3)WAFの活用

WAFとはWeb Application Firewallの略称で、一般的によく知られているFirewallがポート、IP制限などのネットワークレイヤーの不正アクセスを防ぐのに対して、WAFは「SQLインジェクション」「XSS」などのWebアプリケーションを狙った攻撃を防御してくれます。

例えば、お問い合わせなどのフォームからサーバーへ送られる入力データのチェックを行い、不正なデータが渡されないようにします。つまりサーバーとクライアントの間に立って通信を遮断し、Webアプリケーションを防御してくれます。

しかしながら、WAFを導入すればすべてのWebアプリケーションの脆弱性対策ができるかというと、答えはNOです。 あくまで暗号化された通信(SSL)上でのセキュアなプログラミングや適切なサーバー設定の漏れを補完することが目的です。

f:id:dkawata:20161226185515p:plain
▲各レイヤーによりサイバー攻撃を防御する対象が異なる

こうしたネットワークサービスを導入することで、一定のサイバー攻撃からサイトを守ることができます。 しかもその負荷を専用機器でまかなうことができるため、Webサーバーに無駄な負荷をかけずに済みます。
SSLの暗号化・復号処理をサーバーではなく、ロードバランサーで行っていることもポイントの一つです(SSLアクセラレーション)。 普段何気なくアクセスしているコーポレートサイトも、コンテンツへ到達するまでには 上図のような様々なサービスを通過して閲覧できているワケですね。

実際に障害が起こってしまったら

ここからは人や組織の対策です。
あまり考えたくないことですが、実際に問題や障害が発生してしまった時の行動を緊急時対応マニュアルとしてフローチャート形式でまとめることや、エスカレーション先を決めた表を作成する必要があります。
この時、自分ひとりですべての作業を差配している人は少ないと思います。複数の部署をまたいだ連携が必要になってくるハズです。そのため、物事の決定権が誰にあるのかを事前に決めておくことは非常に重要です。できれば担当部署だけでなく、担当者名まで決めておくことができれば安心です。
またその代理や、最悪、誰とも連絡がつかなかった場合などその条件は多岐に渡りますが、まずは自分の上司など身近なところから決めて行き、表を完成させていきましょう。

まとめ

今回は少し駆け足でコーポレートサイトの全体像をお伝えしました。
以上のことを踏まえてIDCFのコーポレートサイトはざっくりと下図のような構成になっています。

f:id:dkawata:20161227171522p:plain

普段は個々のサービスとして独立して説明する機会が多いと思いますが、このように一連の流れで説明することで、それぞれのサービスが担当する守備範囲がわかりやすくなったのではないでしょうか。

要点をまとめてみます。

  • GSLBによるDRサイト構築
  • DDoS対策サービスを含むネットワークサービス(FW、IDS/IPS、WAF、LB)の導入
  • SSLによる通信の暗号化
  • セキュアなプログラミングや適切なサーバー設定
  • コンテンツの同期とバックアップ
  • 障害時の対応マニュアルの作成

これらがすべて揃って初めて24時間365日運営できるサイト作りが実現することになります。

最後に、今回取り上げたこれらのサービスを実際使ってみたいという方へのお知らせです。
中でもIDCFクラウド上で導入可能なGSLB(DNS)プライベートコネクトILBならすぐにでも対策を始めることができます。 また、お申込みベースでDDoS対策サービスを含むIDCFネットワークサービスも利用可能です。

これを機にみなさんが運営されているサイトのリスクマネジメント対策を見直してみてはいかがでしょうか?

Copyright © IDC Frontier Inc.