Quantcast
Channel: さくらのナレッジ is_page
Viewing all 325 articles
Browse latest View live

統合監視ツール「Zabbix」によるサーバー監視

$
0
0

サーバーを監視するためのツールにはさまざまなものがあるが、その1つに「Zabbix」がある。Zabbixはオープンソースで開発されている多機能な監視ツールで、設定を容易に行えるテンプレート機能やWebブラウザ上で操作できるGUIが特徴だ。本記事ではZabbixの概要と、ZabbixによるLinuxサーバーの監視方法について紹介する。

テンプレート機能や豊富な監視設定が特徴のZabbix

サーバー運用において重要なのが、サーバーやそこで動作しているアプリケーションが正常に動作しているかを監視することだ。監視方法としてはさまざまなものがあるが、多くの場合専用の監視用ツールを利用するのが一般的である。監視用ツールとしては「Nagios」や「MRTG」などが有名であるが、今回は豊富な監視機能を持つ「Zabbix」という統合監視ツールを使ってLinuxサーバーを監視する方法について紹介しよう。

Zabbixは、ラトビアのZabbix SIAが開発するオープンソースの統合監視ツールである(ライセンスはGPL)。「Zabbixエージェント」と呼ばれるソフトウェアを監視対象にインストールすることで詳細な監視が行えるほか、SNMPを使った監視や監視対象サーバーの各種ポートにアクセスして監視を行うポーリング監視機能も備えている。

ZabbixではさまざまなOSや機器向けの設定項目がまとめられた「テンプレート」が多数用意されており、監視したいサーバーを登録してテンプレートを選択するだけですぐに一通りの監視が行える。監視や設定はWebブラウザを使ったGUIで行えるため、OSやデバイスを問わずに監視や設定作業が可能だ。

Zabbixの構成

Zabbixは「Zabbix Server(サーバー)」および「Zabbix Agent(エージェント)」、そしてWebフロントエンドというコンポーネントから構成されている。Zabbixサーバーは監視および監視データの収集、設定などの管理を行うコンポーネントだ。後述のZabbixエージェントからの情報収集などはこのZabbixサーバーが実行する。

Zabbixエージェントは監視対象とするサーバーにインストールするソフトウェアで、ZabbixサーバーはZabbixエージェントを通じて監視対象サーバーの状態を取得する。WebフロントエンドはPHPで実装されたWebアプリケーションで、Zabbixサーバーが収集したデータを表示したり、各種設定を行う機能を持つ。

今回は監視を行う構成として、図1のような環境を想定している。ここではZabbixサーバーとWebフロントエンドを同じサーバー上で動作させているが、これらを別のサーバーで動作させることも可能だ。

図1 Zabbixによるサーバー監視構成例
図1 Zabbixによるサーバー監視構成例

 なお、以下では監視対象サーバーおよびZabbixサーバーのOSにRed Hat Enterprise Linux(RHEL) 6.4互換のLinuxディストリビューション「CentOS 6.4」を使用して環境構築方法を紹介している。

>>次ページ:Zabbixのインストール

おしらせ

banner_writer


柔軟なログ収集を可能にする「fluentd」入門

$
0
0

複数台のサーバーやクラウド環境を組み合わせてのサービス運用においては、ログの収集方法に工夫が必要となる。こういった場合に有用なのが、さまざまなログの収集手段を提供するfluentdだ。今回はfluentdのアーキテクチャやそのインストール/設定方法、基礎的な設定例などを紹介する。

さまざまな方法でログを収集できるfluentd

今回紹介するfluentdは、Treasure Dataが開発するログ収集管理ツールだ(図1)。オープンソースで公開されており、Linuxや各種UNIXで動作する。

図1 fluentdのWebサイト
図1 fluentdのWebサイト

 ログ収集のためのソフトウェアとしてはsyslogdやsyslog-ngなどが有名だが、fluentdがこれらと異なる点としては、以下が挙げられる。

さまざまなソースからのイベントをさまざまな媒体に出力できる

fluentdの大きな特徴としては、ログの収集方法やログの記録先などを柔軟にカスタマイズできる点がある。

一般的にログ収集ソフトウェアは何らかの「イベント」を検知し、その内容を発生時刻などの情報とともにファイルやデータベースなどのストレージなどに出力する、という処理を行うが、fluentdではイベントの受け取り(input)およびストレージなどへの出力(output)がすべてプラグインとして実装されている(図2)。

図2 fluendのアーキテクチャ。ファイルやアプリケーションなどのイベントソースから受け取ったイベントが集約され、条件に応じてさまざまな出力先に出力される
図2 fluendのアーキテクチャ。ファイルやアプリケーションなどのイベントソースから受け取ったイベントが集約され、条件に応じてさまざまな出力先に出力される

 inputプラグインについてはsyslog互換プロトコルやMessagePackベースの独自プロトコル、HTTPのPOSTリクエスト、Unix Domain Socketなどを使うものや、任意のテキストファイルを監視してそこにテキストが書き込まれたらそれをイベントとして受け取る、といったものなどが用意されている。outputプラグインについては標準出力への出力やテキストファイルへの書き出し、MongoDBへの書き込み、任意のコマンドを実行してそこにログデータを渡す、といったものが用意されている。

また、サードパーティによって開発されたプラグインも多く公開されており、さらに自分でプラグインを作成することも可能だ。fluentdやそのプラグインはRubyで実装されており、Rubyの知識があれば比較的容易にfluentdの機能を拡張できる。

ログの種類はタグで管理される

fluentdでは、ログの管理を「タグ」と呼ばれる情報で管理する。タグはイベントを発生させる側やinputプラグイン側で任意の文字列を指定できるが、以下のように「.」を使った階層構造を取るのが一般的だ。

<親タグ名>.<子タグ名>

「foo.bar.hoge」のように3階層以上の構造を持つタグを指定することもできる。

ログの内容はJSON形式

fluentdではログの内容(レコード)がJSON形式になっている。そのため、アプリケーション側でのパースが容易であるというメリットがある。最近ではMongoDBなどのJSON形式をネイティブで扱えるデータベースも登場しており、これらと組み合わせることでデータの解析などがやりやすくなる。

さまざまな言語向けのモジュールが提供されている

fluentdでは、イベントを送信するためのモジュールがさまざまな言語で用意されている。公式のものとしてはRubyやJava、Python、PHP、Perl、Node.js、Scala向けのモジュールが提供されているほか、サードパーティによってこれ以外の言語向けのモジュールも開発されている。これらを利用することで、独自のアプリケーションのログをfluentd経由で簡単に記録させることができる。

fluentdが適している分野

fluentdはさまざまな環境で利用できるが、やはり多く使われているのはWeb関係の分野だろう。たとえば、一定以上の規模のWebサービスではロードバランサを使ってリクエストを複数台のWebサーバーに分散させる構成が一般的だ。このような構成の場合、fluentdを使ってWebサーバーのアクセスログを処理することで、ログを1つのデータベースに集約することが可能になる。

また、アクセスログに加えてWebアプリケーションから直接fluentdにログを記録させることで、より粒度の高いロギングが可能になる。

クラウド環境においてもfluentdは有用だ。クラウドサービスで提供される仮想マシンでは、ストレージの永続化がサポートされていない(サーバーを停止/再起動させた際にストレージがクリアされる)ことも多い。そのため、各種ログは仮想マシン外の永続的ストレージに記録する必要がある。fluentdを利用すれば、外部ストレージへのログ記録と複数サーバーのログ集約が容易に行える。

>>次ページ:fluentdの設定手順

おしらせ

banner_vps

あなたのサーバは大丈夫?Shellshock対策をしましょう

$
0
0

9月下旬に発覚したbashの脆弱性Shellshock。自分のサーバは関係ない、そのままでも大丈夫と思っていませんでしょうか。最近のサーバに対する攻撃はほぼ自動化されており、手当り次第に攻撃を仕掛けてきます。

もちろん大手のサービスは狙われやすいですが、そんなことのないごくごく小さなサービスを運営しているだけでも狙われる可能性は十分にあります。対策は難しくありませんので、以下の内容を参考に確認、対策をしてください。

対象

さくらインターネットの下記サービスを利用されているケースにおいて、対策が必要になる可能性があります。

  • さくらのVPS
  • さくらのクラウド
  • さくらの専用サーバ
  • 専用サーバ
  • 専用サーバPlatform Ad/St

bashがインストールされている場合は対象になりえるので、Windows Server以外はほぼほぼ全てのサーバが対象と言えます。

確認方法

全てのサーバが対策が必要という訳ではありません。その確認方法を紹介します。今回はさくらのVPSを使ってみます。

さくらのVPSトップページ
さくらのVPSトップページ

さくらのVPSトップページを表示します。左側にあるリモートコントロールをクリックします。

リモートコントロール
リモートコントロール

黒い部分をクリックして、エンターキーを押します。

ログイン
ログイン

ログインはそれぞれサーバインストール時に設定されていると思います。管理者権限(rootなど)があるユーザでログインします。ログインできると、

[root@www9999 ~]#

といったような文字が一番下に出るかと思います。

ログイン完了です
ログイン完了です

ログインしたら、次のコマンドを入力してエンターキーを押します。

env x='() { :;}; echo this bash is vulnerable' bash -c :

via Bash – shellshockのテストスクリプトがUnix的でないので改善してみた。 – Qiita

もし、

this bash is vulnerable

と出たら脆弱性があります。何も出なければ問題ありません。

もし脆弱性が確認されたら

そのまま放置しておくと危険ですので、OS(Linuxディストリビューション)ごとに対応を行います。

Redhat Linux/CentOSの場合

管理者権限(rootなど)において次のコマンドを実行します。

yum update bash

Debian/Ubuntuの場合

管理者権限(rootなど)において次のコマンドを実行します。

apt-get update
apt-get upgrade bash

その他のLinux/Unixの場合

パッケージ管理されていない場合は、bug-bash (thread) などを参考にbashにパッチを当ててください。

確認

対応が終わったら先ほどの

env x='() { :;}; echo this bash is vulnerable' bash -c :

を実行して何も文字が出ないことを確認してください。


サーバのセキュリティ問題は、自分たちのサーバが乗っ取られたり、データを削除される怖さもありますが、それ以上に乗っ取られることで他者のサーバを攻撃する踏み台にされる可能性があると言うことです。

万一データが消えても惜しくないから放っておくというのは危険で、加害者にならないためにも早めの対応を行わなければなりません。こちらの記事を参考にぜひ早めの対応をお願いします。

【重要】GNU bash の脆弱性に関する注意喚起 | さくらインターネット

サーバー監視、セキュリティのトレンドなど最新の話題がいっぱい! 「第23回さくらの夕べin大阪」レポート

$
0
0

2015年2月27日に、大阪で開催された「第23回 さくらの夕べin大阪」に参加してきました。
大阪では半年ぶりの開催で、100人近い方々が参加されました。
今回は、株式会社はてな(以下、はてな)のサーバー管理サービス「Mackerel(マカレル)」や、ウェブペイ株式会社の決済サービス「WebPay」についてご紹介します。

はてなCTO 田中慎司

「Mackerelによる簡単サーバー管理入門」

はてなのCTO、田中慎司さんに「Mackerel」を紹介していただきました。Mackerelは、はてなが2014年9月にリリースしたクラウド型(SaaS)のサーバー管理ツールです。

はてなCTO 田中慎司

サーバーを複数管理している個人や会社にとって、サーバーの管理や運用などの手間は面倒だし煩わしいものです。できれば、サーバーの保守にはあまり手間をかけたくないでしょう。
そんなニーズにマッチするサービスがMackerelです。
Mackerelはクラウド型のサービスなので、インストールの手間がパッケージソフトに比べて少なく、比較的簡単に始めることが可能です。サーバー群を一括で監視できるので、運用や保守にかかる人件費を削減できます。

いままでにも「Zabbix」や「Nagios」といったオープンソース型のサーバー監視ツールはありました。しかしインストールや設定が複雑で、それなりに運用の知識が必要であり、導入に時間がかかったり、あまりインターフェースが洗練されていなかったりという課題がありました。
また、「サーバー監視をするためのサーバー」が必要という問題点もあります。
クラウド型サービスのMackerelは監視サーバーを自前で用意する必要がなく、ユーザーが所有する、監視したい対象の各サーバーにAgentをインストールすることで、サーバーを監視できます。

現在のところ、Mackerelが対応している監視対象のサーバーOSは以下のとおりです。
・CentOS 5/6
・Debian 6/7
・Windows(アルファ版)
・Mac
・ARM版

監視できるリソースは、CPUメモリ使用率ロードアベレージなどです。それに加えてJVMAWS RDSELBの状況も監視できます。サーバーの資源だけではなく、例えばWebサーバーのアクセスごとのステータスコード(404 not foundの数)などもカウントしてグラフ化できます。
サーバー異常時にアラートを送る宛先は、メール、Slack、HipChat、Webhook、Chatworkを指定できます。
監視対象のサーバーが複数になる場合、それぞれのリソースは積み重ねグラフとして表示できます。
ある日、監視対象のサーバー群の1つを廃止しても、そのサーバーのリソースグラフが全部消えてしまうことはなく、履歴として残るので、サーバー全体としてどれだけのリソースが減ったかの差分を視覚的に確認することができます(オートスケール対応)。

おもしろいと思ったのは、埋め込みグラフ機能です。
Mackerelの管理画面では、もちろん監視対象のすべてのリソースグラフを見ることができますが、特に注意して見たいグラフを別のページに埋込表示させることができます。
例えば特定のサーバーのリソースだけをチェックしたいとか、あまりサーバーのことがわからない上司にロードアベレージだけを見せるといったプレゼンをするときに便利ですね!

Mackerel 埋め込みグラフ機能

Mackerelは毎週のように新しい機能をリリースしており、どんどん進化していますので、今後のパワーアップが楽しみです。

Mackerelについては去年のさくらの夕べでも、はてなの田中さんに登壇していただいています。こちらも合わせてご覧ください。
はてなの田中CTOがMackerelを語る!第18回さくらの夕べ 開催レポート

「クレジットカードのためのセキュリティ標準入門」

次はウェブ決済、アプリ決済サービスの「WebPay」を運営するウェブペイ株式会社(以下、ウェブペイ)CEOの久保渓さんのお話です。

ウェブペイ株式会社 久保渓

WebPayの最近のニュースと言えば、2014年2月に「LINE Pay」がウェブペイを100%子会社化したことが話題になりました。

[参考]LINE、決済サービスを提供するウェブペイを買収

巨大なユーザー数を抱えるLINE PayにWebPayの技術が使われることで、今後、WebPayプラットフォームが大きく飛躍することが予想されます。

最近では、サービスが稼働しているシステムが外部から攻撃されたり、セキュリティの不備を突かれたりすることによる個人情報の漏えい事件が世間でたびたび発生しています。
特にクレジットカード番号は、守られるべき情報として厳重に管理されなければなりませんが、カード番号の漏えいも実際に起こり、賠償問題に発展しています。しかしネットショップやアプリなどのサービスを提供する立場としては、顧客の個人情報を厳密に管理することは工数もコストもかかる問題です。セキュリティを高めることだけに腐心していれば競争力のあるサービスが作れなくなり、経営の体力がどんどん失われていきます。
そこで、セキュアでコストパフォーマンスの良い決済サービス事業者とうまく連携して、自社では顧客のクレジットカード番号を保管しないソリューションが登場しています。
WebPayは2013年にサービスを開始して以来、高度なセキュリティの確保とサービス開発者にとって実装しやすいAPIを提供することで、人気上昇中の決済サービスです。

今回初めて耳にしたのですが、クレジットカードを扱う業者に対して、PCI DSSというセキュリティ基準があります。
PCI DSSは300以上ものチェック項目があり、例えば「データセンターに監視カメラを設置すること」「ネットワークは適切にセグメント化されること」「通信を暗号化すること」など、項目の一つひとつはかなり具体的です。

本来ならば、決済事業者だけでなく、ネットショップなどのクレジットカードを取り扱う会社もこのPCI DSSに準拠していることが望ましいのですが、現実的にはこの膨大な数の基準項目に一般の企業が対応するのは困難です。
それならば、逆に「決済にクレジットカードを使うWebサービスやアプリは、生のクレジットカード番号を扱わずに決済すればよい」という発想で、生のカード番号はサービス提供者では取り扱わず、WebPayがカード番号を管理するという仕組みを構築しています。
ネットショップなどサービス提供者は、カード番号の代わりにランダムな文字列を並べたトークンで決済をやり取りします。

WebPayのトークン決済

実際にカード番号漏えい事件が発生しているのは、ほとんどのケースがPCI DSSに準拠していない通信経路上やサーバーからの漏えいであり、その危険な部分をトークンに置き換えられるというのは安全な取引をする上で大きな意味を持ちます。

余談ですが、久保さんが語ってくれたクイズは興味深いものでした。
ユーザーのクレジットカードを表示する場合は、マスクするべきなのは上位12桁で、実番号は下4桁を表示するのがクレジットカードのレギュレーションだそうです。
もし、あなたが開発にかかわっているサービス内で、顧客のカード番号を隠して表示していても、それが下4桁以外であれば、カード情報が漏えいしてしまう可能性があるのでご注意ください!
逆に、あなたのサービスがレギュレーションに準拠して、カードの下4桁のみ表示していても、上位12桁を明らかにしている別のサービスを同じユーザーが使っていれば、組み合わせで16桁すべての番号が漏えいしてしまいます。

クレジットカードの一部を隠す表示方法1クレジットカードの一部を隠す表示方法1

WebPayについては、ウェブペイCTOの曾川さんが、さくらのナレッジに寄稿されているので、興味がある方はそちらもご覧ください。
2014/7/24 決済にまつわるセキュリティの話 第1回 クレジットカードセキュリティ入門
2014/11/11 決済にまつわるセキュリティの話 第2回 PCIDSS取得のためのクラウド選定

「さくらのクラウドのサービス紹介」

さくらインターネット研究所 所長の鷲北 賢さんに、さくらのクラウドのサービス概要を紹介していただきました。

さくらインターネット研究所 所長 鷲北

さくらのクラウドは、さくらのVPSをさらに進化させたサービスで、2011年から運用が開始されており、さくらのVPSと同様に開発者志向でシンプルなものになっています。
さくらのクラウドではVPSと違って、たくさんのサーバーを追加したり削除したりすることが容易にでき、サーバーのCPU数、メモリ、ストレージのサイズをあとから変更することもできます。
将来的にスケールアウトするかもしれないサービスならば、VPSよりも、さくらのクラウドを選んでおけばサーバーの性能をあとから強化できるので安心です。
クラウドのサーバーは北海道・石狩のデータセンターで運用されており、「インスタンス」という言葉よりもサーバーという概念を大切にしたいという考えだそうです。実際に物理的なサーバーを操作するイメージのサービスにしたかったからとのことです。
さくらのクラウドでは、スペックに応じていろいろな料金プランがありますが、一番安い1コアでメモリ1GBのプランが月額1,954円です。さくらインターネットが主催するイベントでは、よく2万円分のクーポンがもらえるので、10カ月くらいは無料で使うことができ、おすすめです。

サーバー自体のサービスのほかに、別のサービスとの連携ができるのも興味深いところです。
さくらのクラウドのサービス内だけでなく、石狩データセンターに存在する専用サーバーやリモートハウジングのサーバーとレイヤー2レベルの接続ができるので、セキュアなネットワーク環境を構築できます。
サーバーの起動や停止、プラン変更などの基本的な操作は、さくらのクラウドコントロールパネルから行うことができます。APIも提供されているので、コマンドラインからサーバーを起動・停止したり、プランを変更したり、コントロールパネルでできることと同様の操作が可能です。
Sandbox機能があるので、試しにサーバーを作ったり消したりすることができます。また自作のスタートアップスクリプトをサーバー作成時に動かすことで、自分に必要なアプリケーションがインストールされたサーバーを作ることもできます。
VPCルータ機能では、VPN接続などのセキュアな方法で遠隔地からさくらのクラウドのサーバーに接続することができます。

ネットワークの構成は以下の写真のようにグラフ表示でき、マウスのドラッグ&ドロップで線をつないだり付けかえたりできるのは便利ですね。直感的でわかりやすいサーバー管理ができそうです。

さくらのクラウド 直感的で分かりやすいネットワークグラフ

最近では、さくらのクラウドの1つのアカウントについて、複数のユーザーを登録して運用できる仕組みを導入したそうです。

さらに、2015年3月1日から、オブジェクトストレージのサービスをリリースしています
AmazonのS3互換サービスになっており、さくら内のサービスから利用する限りは転送量課金が無料となっています。

サーバーのデータバックアップによさそうですね。

さくらのオブジェクトストレージ

懇親会

1時間半で3名の方にお話しいただいたあとは隣りの部屋で懇親会が開催されました。
懇親会は1時間ちょっとの短い時間でしたが、多くの参加者で賑わい、参加者のライトニングトークもあり盛況でした。
参加者の方に感想を聞いたところ、「本日登壇された、その道の有名な方と直接お話ができ、名刺交換させていただけたのでうれしかった」という声をいただきました。
私自身も多くの方と名刺交換や交流ができて、とても有意義でした。

さくらの夕べin大阪 懇親会

「さくらの夕べ」は大阪だけでなく、東京やその他の地域でも開催されています。今後のイベント予定はさくらインターネット広報のtwitterアカウント@sakura_prをフォローしてチェックしましょう!

決済プラットフォームでイノベーションを起こす!急成長中のサービス「WebPay」とは

$
0
0
当ページは「導入事例・構成例 サイト」に移行しました。
http://case.sakura.ad.jp/case/webpay
3秒後に自動で移動します。

2015年2月27日に行われた、「さくらの夕べin大阪」で登壇いただいた、ウェブペイ株式会社(以下、ウェブペイ)CEOの久保渓さんに別途時間を作っていただき、「WebPay」やさくらインターネットとのかかわりについてインタビューしました。
聞き手はさくらインターネット広報宣伝室の林さんです。

ウェブペイ株式会社の久保さんと曾川さん

ウェブペイ株式会社の久保さんと曾川さん

ウェブペイって、何をしている会社なのですか?事業をおこしたきっかけは?

ウェブペイは2013年に「WebPay」という決済サービスを始めたばかりの、比較的新しい会社です。その前は、米国のシリコンバレーでサーバーのホスティング会社を3年ほどやっていました。当時は日本向けのクレジットカードの課金ロジックを実装するときに、既存の決済サービスの難しい仕様やAPIを理解しなければならず、開発に多くの時間を要していました。決済サービスはもっと簡単に実装できるようになるはず、そのためのサービスを作って、開発者がもっと簡単に決済サービスを組み込めるようなプラットフォームを提供したいと思ったのがウェブペイという会社を作ったきっかけです。

ウェブペイ株式会社 久保渓さん

ウェブペイ株式会社 久保渓さん

WebPayは主にWebサービスの提供者モバイルアプリの開発者に向けて、簡単に決済サービスを実装できるようにシンプルなAPISDK(開発キット)を提供し、従来よりも高速かつ簡単に決済サービスを組み込めるようにしたものです。
すでにクラウド会計ソフトの「freee」や、スマホの写真を簡単に郵送できるサービス「レター」などのサービスの決済ツールとして利用されており、現在もWebPayを採用する企業やサービスがどんどん増えている状況です。

最近は個人情報などに対するセキュリティ意識が高まる一方、それらを扱う企業では外部からの攻撃や社内での運用ミスによる情報漏えいが少なからず発生しています。決済サービスを担う者は単に開発しやすいプラットフォームを提供するだけでなく、安全に取引・決済できるよう、重要なデータを適切にやりとりしたり保管したりしているという保証や安心をユーザーに与えなければなりません。クレジットカードで物を買うとき、生のクレジットカードのデータを通信経路上で何回も無駄にやりとりしないようにしたり、Webサービス提供者やアプリのサーバー上など必要のない場所にカード情報を残したりすることがないように、サービス提供者とWebPayサービスの間の橋渡しをするAPIをうまく設計しています。これにより従来の決済サービスより安全な取引ができるようになっています。

参考:2/27に大阪で開催されたさくらの夕べのレポートにも関連記事があります。
サーバー監視、セキュリティのトレンドなど最新の話題がいっぱい! 「第23回さくらの夕べin大阪」レポート

以前、私たちが取引をしている会社から、「自社の個人情報が漏えいした」と一報を受けたことがありました。調べてみたところ、住所や氏名などの情報は残念ながら漏れていましたが、クレジットカードの生データは漏れていませんでした。これはWebPayを通した決済において、直接クレジットカード情報をやりとりするのではなく、その代わりとなるトークンで決済のAPIを使う仕様になっているため、顧客のサーバーに生のカードデータが保管されていなかったからです。

先日、LINEによるウェブペイの完全子会社化が発表されましたが、そのことについて詳しく教えてください

参考: LINE、決済サービスを提供するウェブペイを買収

以前から、LINE社への個人的なつながりはあって、「一緒に何かやれたらいいね」という感じで話はしていました。
協業について具体的な話があったのは数ヵ月前からで、2015年2月10日に正式発表させてもらいました。
ウェブペイはまだ始めたばかりの会社で、人数もあまり多くないので、しっかりとした経営基盤を持つLINE社のバックアップを受けることはとても大きな意味を持ちます。
また、巨大なユーザーを持つLINEの決済プラットフォームにウェブペイの技術が組み込まれれば、私たちが設計した決済フローをより多くの人に使ってもらえることになるので、それが世間一般の標準仕様に発展できればうれしく思います。

パソコンでコミュニケーションしたり物を買ったりする時代が過ぎて、人はより多くのことをスマートフォンだけで済ませてしまう時代になってきています。しかしクレジットカードで物を買うとき、スマートフォンの小さい画面でカード番号を入力したり自分の名前を入力したりするのは面倒に感じる人も多いでしょう。そんな煩わしい手順ではなく、もっと簡単に決済できる仕組みをWebPayは追求していきたいし、LINEとの協業で、もっと決済が身近に感じられる仕組みを作っていけたらいいなと思っています。

WebPayはさくらのサーバーを使っているそうですが、どういったところにメリットを感じていますか?

ウェブペイを立ち上げる前から、さくらのサーバーを利用していたので、WebPay事業を始めるにあたって、引き続きさくらのサーバーを使うことは自然な流れでした。
現在は「さくらのVPS」、「さくらのクラウド」、「さくらの専用サーバ」を使っていますが、他社と比べてコストパフォーマンスの良いのが魅力です。
私たちが手がける決済サービスはもちろんコスト競争力がないといけません。経費としてかかるサーバーの費用を抑えることは、私たちのサービスを低価格で提供するためにも非常に重要なことです。

とはいえ、AWSなど他社のサーバーも併用しています。ストレージの暗号化やキーマネジメントシステムなど、AWSの方が便利に使える部分についてはAWSを使用していますが、それ以外の部分ではコストパフォーマンス的に有利なさくらのサーバーを使っています。用途によって最適なサーバーを使い分けているわけです。

さくらインターネット広報宣伝室 林

さくらインターネット広報宣伝室 林さん

逆に、さくらに関して「もっとこうなってほしい」と思う点はありますか?

PCI DSS(Payment Card Industry Data Security Standard)というクレジットカード業界のセキュリティ基準があります。これは、VISAやマスターカードなどクレジットカード会社5社が合同して作ったセキュリティ基準で、例えば以下のような300以上のチェック項目が記載されています。

・機密情報を扱う施設には監視カメラをつけること
・ネットワークをセグメントで分けるなど適切に区画すること
・オフィスへ出入りする人の入退室記録をつけること

この基準に準拠していれば、そのサービスはクレジットカード情報などを適切に保全できるサービスとして認められます。米国では、この基準に準拠することが州法で義務化されている地域もあります。
また、この基準はクレジットカードに限らず、一般的なセキュリティ基準として、さまざまな施設やサービスに対して適用できるので、サーバーホスティング会社などでも準拠の動きが広がっています。
さくらインターネットもこの基準に準拠していただければ、その上で展開している私達のサービスもよりセキュアで安全なものになりますので、ぜひ準拠することを検討していただきたいです。

参考:PCI DSSに関する、ウェブペイCTO曾川さんの記事を以前に掲載しているのでこちらもあわせて御覧ください。
決済にまつわるセキュリティの話 第1回 クレジットカードセキュリティ入門

日本特有の法規制とか、手続きについて煩わしいと思ったことはありませんか?

守るべき日本特有の法律や規制はあると思います。一般的には規制緩和が叫ばれている風潮ですが、私たちが親しくしている社外のエキスパートに助けられて、法基準や課題を1つひとつクリアしています。私たちの立場としては、サービスとして厳密な個人情報を扱うわけですから、なんでも規制緩和すればいいというわけではなく、法整備すべきところはちゃんと法整備して、安心に取引できる仕組みを作った方がメリットは大きいと考えています。規制が煩わしいというよりは、むしろもっと厳しくするべきところは厳しくするべきだと思います。

今後、WebPayはどうなっていきますか?どういう未来を描いていますか?

決済サービス事業は、金銭を渡したり受け取ったりするという意味では、まさに資本主義の根幹をなす事業です。そんな事業を手がけていることに責任ややりがいを感じていますし、社会に貢献できる部分も多く、今後できることの可能性が大きい領域だと思います。
小さく始めたWebPayですが、LINEとの協業を通じて、日本だけでなく世界も見すえた巨大な事業になると確信しています。
また、WebPayと同様なサービスもいくつも出てきていますが、単にライバル視するのではなく、そのような事業者の方とともに、この業界を大きく盛り上げていきたいと思っています。
ということで、人材も募集中です!私たちと一緒に未来ある事業を作っていきませんか?
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
1時間ほどお時間をいただき行ったインタビューでしたが、いかがでしたでしょうか。
若さに満ちあふれた久保さんを見ていると、今後のWebPayという決済サービスがどのようになっていくか、非常に楽しみです。
すぐ始められるそうなので、興味がある方はぜひ一度使ってみてはいかがでしょうか?

WebPay: 開発者向けクレジットカード決済サービス
https://webpay.jp/

SNIで1台のサーバ上に複数のSSLサイトを運用 – 後編

$
0
0

前回は、SNI(Server Name Indication)の技術的な概要と、その特徴について説明を行いました。

後編である今回は、新たにSNIに対応したさくらのレンタルサーバー スタンダードプランを利用して、実際にSNIを利用した独自ドメインのSSLの設定を行ってみたいと思います。

従来のさくらのレンタルサーバでは、独自SSL(IPアドレスベース)は、ビジネスプロプラン以上でのみ対応しており、1契約で1つのSSLサイトを運用できました。

それが、[今回のSNI SSL対応](http://www.sakura.ad.jp/function/security/original-ssl.html)により、スタンダードプラン1つで複数のSSLサイトを運用できるようになりました。

最安で月額515円から始められサーバプラン料金が抑えられることに加え、1サーバプランで複数のSSLサイトを運用できるので、サーバの運用コストを大幅に抑えられるようになりました。

この記事を通じて、「高コスト・面倒」だったSSLの設定・運用が、「低コスト・簡単」なものになってきたことを実感して頂ければと思います。

サイト構築の概要と前提

構築サイトの概要

ここでは、さくらのレンタルサーバスタンダードプラン1台で、2つのサイトを運用することを想定してみます。1つはブログ、もう1つはECサイトです。

以下はSNIの設定が完了したサイトのイメージです。SNIの設定が完了すると、このようにURLがhttpからhttpsと表示されます。

サンプルページ

サンプルページ

なお、複数のSSLサイトを設定するための全体フローは下図のようになりますが、本記事の解説範囲は、「SNIの設定」以降の範囲となります。

SNI設定のフロー

CSRの作成から始まるSSL証明書の発行、および、ドメインの取得から始まるマルチドメインの設定に関する作業は終わっていることを前提としています。
これらの作業について、参考になるページをそれぞれ挙げておきます。

作業内容

1. ドメイン設定画面を開く

レンタルサーバの管理画面にログインしたら、ドメイン設定メニューから「ドメイン設定」をクリックします。

ドメイン設定

2. example1.jp のSSL証明書を設定

このようなドメイン一覧画面が表示されるはずです。
まずはexample1.jpのSSL証明書を設定するために、「登録」をクリックします。

ドメイン一覧でSSL登録開始

続いて、「証明書のインストール」リンクをクリックします。

証明書のインストールを開始

3. example1.jp のSSL証明書を送信

事前に発行されたSSL証明書の内容を入力(①)し、送信ボタン(②)を押します。

中間証明書の送信

4. example1.jp のSSL中間証明書を登録

続いて中間証明書の設定を行うために、「中間証明書のインストール」をクリックします。

中間証明書のインストール開始

なお、発行されたSSL証明書の種類によっては、中間証明書の登録が不要なものもあります。
詳細は、SSL証明書発行元のドキュメントを参照して下さい。

5. example1.jp のSSL中間証明書を送信

SSL証明書の発行元から指定された中間証明書の内容を入力(①)し、送信ボタン(②)を押します。

中間証明書の送信

以上でSSL証明書の設定は完了です。

6. example1.jp のSNI SSLを設定

続けて、SNI SSLの設定を行うために、「ドメイン設定」をクリックします。

ドメインの設定

ドメイン設定の画面で、「SNI SSLを利用する」を選択(①)し、送信ボタン(②)を押します。

SNI SSLの設定
以上で、example1.jpドメインに対するSNI SSLの設定が完了しました。

ドメイン設定完了

7. example2.jpの設定も同様に行う

example2.jp の設定も、以上の流れと同様に行います。
最終的に、ドメイン一覧は以下のようになります。

SNI設定完了後のドメイン一覧

エンジニアとして感じたこと

筆者はエンジニアとして、数々のWEBサーバの設定を経験してきました。
エンジニアによって作業スタイルは異なると思いますが、私はコンソール、いわゆる「黒い画面」で設定ファイルを編集しながら設定作業を行うことが多いです。

一方で、本記事のようにWEBの管理画面から設定作業を行うのは久しぶりの経験で、コンソールを利用した設定作業には無いメリットも感じることが出来ました。

作業項目の比較に見る属人性の低さ

最も大きなメリットとして、運用作業に対する属人性が低くなる点が挙げられます。

SNIで複数サイトの構築を行うための作業項目を、コンソール経由での作業項目と比較する形で列挙してみました。

  管理画面経由での作業 コンソール経由での作業
サブドメインの追加
  • 管理画面からサブドメインを追加
  • 設定ファイルにVirtualHostの定義を追加
  • 各VirtualHostに対応するディレクトリのパーミッションを確認
SNIに対応させる
  • 自動で対応済み
  • 設定ファイルでSNIを有効化
SSL証明書の配置
  • 管理画面からSSL証明書をアップロード
  • 秘密鍵を適切なパーミッションで配置する
  • SSL証明書を適切なパーミッションで配置する
  • 設定ファイルのVirtualHostの定義に、秘密鍵とSSL証明書のパスを追記する
中間証明書の配置
  • 管理画面から中間証明書をアップロード
  • 中間証明書を適切なパーミッションで配置する
  • 設定ファイルのVirtualHostの定義に、中間証明書のパスを追記する

管理画面経由での作業に比べ、コンソール経由での作業項目が多いことが分かると思います。
特に、パーミッション設定やファイル設置などの作業は、運用ルールを決めておかないと人によって内容がまちまちで、担当者が変わると混乱、、という状況になりがちです。

近年は、DevOpsと呼ばれる領域で、サーバ設定をコード化(プログラミング)して、属人性の少ない自動化されたプロセスを構築することも可能にはなっていますが、仕組みの構築・維持にも、それなりに高いスキルと時間が求められるのが現状です。

管理画面から証明書をアップロードするだけで設定が終わるというのは、設定作業の属人性が低くなるという点で、レンタルサーバの大きなメリットであると思います。

最後に

前編・後編の2回にわたって、SNIの解説記事をお送りしてきました。
SNIによってマルチドメインのSSL運用が楽になること、また、SNIのメリット・デメリットがご理解頂ければ幸いです。

さくらのレンタルサーバ スタンダードプランのように、低コストでSNI SSLを導入できるサービスも登場してきました。サーバ運用担当の方は、積極的にSNI SSLの導入を検討してみてはいかがでしょうか。

最後までお読み頂き、ありがとうございました。

常時SSL化とは?Webサイトの常時SSL化の効果と注意点

$
0
0

SSL
Googleが常時SSL化をランキングシグナルに使用することを発表してから、一般サイトにおける常時SSL化が話題になっています。今回は、この常時SSL化について詳しくご説明します。ECサイトや金融機関などの重要な個人情報を管理するサイトだけではなく、一般的なコーポレートサイトや個人運用の情報サイトにおいても常時SSL化は必要あるのでしょうか。Webサイトの常時SSL化の効果と注意点を確認しましょう。

常時SSL化とは?

https

「常時SSL化」とは、金融機関などのWebサイトのように、自サイトのWebページをすべて暗号化することです。

常時SSL化を行うことにより、Webサイトのトップページから、暗号化されたプロトコルを使用した安全なコンテンツであることを示す「HTTPS」が表示されます。

さまざまな効果が見込める常時SSL化

盗聴、パケット改ざんの防止

Webサイト内でのユーザーの行動を保護し、Cookieを含めたすべての情報を暗号化します。暗号化されたデータは盗むことが困難になり、パケットの改ざんもされにくくなります。

Webサイトが本物であることを証明できる

アクセスしているWebサイトが本物であることを証明し、なりすましサイトへの誘導にユーザーが気付きやすくなります。

一時期、ユーザーを大手金融機関に酷似した偽サイトに誘導し、キャッシュカードの情報を入力させることで金融情報を盗む「フィッシング」が問題となりました。現在ではほぼすべての金融機関が全WebページをHTTPS化しています。常時SSL化したなりすましサイトを作成することは事実上不可能に近いため、HTTPSのサイトであることが本物の証明となり、ユーザーが安心して使用できる環境が整っています。

サイトの信頼性が上がる

今後、Google Chromeをはじめとする各社のブラウザは、よりわかりやすいセキュリティ情報を配信するために、HTTPSのWebサイトを「安全」、HTTPのサイトを「危険」と表示するシステムに変化していく見通しです。

現時点でもHTTPSサイトのアドレスはグリーンで表示され、安全であることが示されていますが、今後さらに明確にHTTPとHTTPSのサイトが区別されるようになったとき、少なくともコーポレートサイトが「危険」と表示されていることは望ましくありません。

検索エンジンからの評価が上がる

Webサイトを常時SSL化することにより、Googleなどの検索エンジンから「ユーザーが安心して利用できる優良なコンテンツである」と評価されます。

同時に、インターネットのヘビーユーズ層でもあるセキュリティ意識の高いユーザーからの評価が上がり、安心してアクセスしてもらうことで、ユニークなアクセスや有効な滞在実績を集めることができます。その実績によって、さらに検索エンジンからの評価を上げることが可能※です。一般サイトにおける常時SSL化が話題になったのは、このSEOの観点からでした。

ウェブマスター向け公式ブログ

覚えておきたい常時SSL化の注意点

常時SSL化のSEO効果は限定的

現時点で検索エンジンは、常時SSL化が「強力な」SEOになるような評価システムを採用していません。「競合サイトがあって、すべてが同レベルならHTTPSのほうが評価は上がる」という程度であることが、GoogleのGary Illyesによって公式に語られています。数百におよぶその他の要素と比べて、格段に重要視されてはいないとのことです。

信頼性の低い認証は逆効果

SSL認証の信頼性は3段階に分かれ、信頼性が高いほど導入価格も上がります。なるべく安価に導入したいところですが、安価でセキュリティ強度の低い証明書を使用したHTTPSサイトや、期限切れの証明書を使用したままになっているようなWebサイトは、コンテンツの安全性を確認できないと判断される恐れもあります。
なお、SSLの認証レベルについては、改めて知ろう、SSLサーバー証明書とは?(第二回)をご確認ください。

Webサイト内の取り込みコンテンツにも注意

Webサイト内で外部スクリプトの読み込みやコンテンツの取り込みを行う場合、それらもすべて安全であることが必要です。取り込みたい外部コンテンツの発信元が安全なサイトであるかは慎重に確認してください。

ソーシャルシェアのカウントがリセットされる

サイトアドレスが変わるため、TwitterやFacebook、Google+といったソーシャルシェアのカウントがすべてゼロになります。これは情報サイトにとっては手痛い点かもしれません。

タイトルに惹かれてクリック流入してきたユーザーは、その情報が有用であるかを、ソーシャルのシェア数、つまり過去の「バズり」実績で確認することがあります。そこでシェア数がゼロになっている記事は「誰も良いと思っていない」と判断され、読んでもらえないことも考えられます。サイトの滞在時間が縮み、直帰率が上がるため、苦しい運用をすることになるかもしれません。

アクセス解析ツールへの再登録が必要な場合も

上記同様、HTTPS化によってサイトアドレスが変わるため、アクセス解析ツールへの再登録が必要な場合があります。情報の引き継ぎができない場合は、常時SSL化によるアクセスの変化を解析することが困難になります。

おわりに

常時SSL化は、いずれセキュリティに繊細な企業サイトだけではなく、個人が運用する情報サイトにも求められていくと考えられます。しかし、SEOのためにとりあえず常時SSL化しよう、なるべく安い証明書で形だけセキュリティレベルを高く見せかけよう……という方法では、逆効果になる可能性が高いため、注意が必要です。

あくまでもメインはユーザーにとって有用なコンテンツを安全に、便利に届けること、常時SSL化はそのための一手段であり、検索結果への反映はその結果にすぎないことを心に留めておきましょう。

ファイアウォールiptablesを簡単解説~初心者でもよくわかる!VPSによるWebサーバー運用講座(4)

$
0
0
初心によるWebサーバー運用講座者でもよくわかる!VPS 公開日
【第1回】「サーバーってなに?」~初心者でもよくわかる!VPSによるWebサーバー構築講座(1) 2014年11月20日
【第2回】「よく分かる公開鍵認証」~初心者でもよくわかる!VPSによるWebサーバー運用講座(2) 2015年9月18日
【第3回】「Muninでかんたんサーバー監視」~初心者でもよくわかる!VPSによるWebサーバー運用講座(3) 2015年10月20日
【第4回】ファイアウォールiptablesを簡単解説~初心者でもよくわかる!VPSによるWebサーバー運用講座(4) 2016年1月15日

VPSによるWebサーバー運用講座の連載4回目です。
今回は、iptablesを使ってサーバーのファイアウォールの設定を行います。
サーバーOSはCentOS 6.7です。(CentOS 7系ではファイアウォールの仕組みが違うのでこの設定は使えませんので注意してください。)

まず、ファイアウォールの基本を学ぼう

VPSをセットアップしてWebサーバーを公開したら、Webコンテンツを全世界に発信できるようになりますが、同時に悪意ある第三者の攻撃にさらされる宿命を負います。
ファイアウォールは和訳すると「防火壁」です。サーバーが提供するサービス以外の不要な侵入口を塞ぐことで、最低限のセキュリティを確保します。
Webサーバーを公開するならばぜひともファイアウォールは設定しておきたいところです。

ファイアウォールを設定するにあたって、基本的な考え方は、
使っているサービスの口はオープンにして、使ってないサービスの口は閉じる」ということです。
あなたが管理しているサーバーでは、どんなサービスを使っているでしょうか? 使っているサービスの通信は許可して、使っていないサービスの通信は遮断するのがファイアウォールです。

HTTPサーバーなどのサービスはそれぞれ固有の「ポート番号」を使用しています。
また、使用する通信プロトコルとしてTCPUDPがあり、それぞれにポート番号の概念があります。「TCPのポート番号80」と「UDPのポート番号80」は別物ですので注意してください。
代表的なサービスのプロトコルとポート番号は以下のようになっています。

サービス名 プロトコルとポート番号
httpサーバー(HTTP) TCP 80
httpサーバー(SSL) TCP 443
メールサーバー(POP3) TCP 110
メールサーバー(IMAP) TCP 143
メールサーバー(SMTP) TCP 25
メールサーバー(submission port) TCP 587
FTP TCP 20, 21
SSH、SFTP TCP 22

Webサーバーだけの機能を持つサーバーの場合、以下のようにSSH(SFTP)、HTTP、HTTPSのポートを許可して、他の通信は拒否する設定にします。

ファイアウォール

よく使われるサービスのポート番号は、ウェルノウンポート番号(WELL KNOWN PORT NUMBERS)といって 0〜1023までのポート番号のどこかに割り当てられています。
詳しくは、以下のページをご覧ください。
TCPやUDPにおけるポート番号の一覧 – Wikipedia

あなたのサーバーについて、どのポートを許可すべきかをあらかじめ調べておきましょう。

ファイアウォールiptablesの設定を行う

それでは実際にiptablesの設定を行います。
はじめに、iptablesがインストールされていることを確認しましょう。

# which iptables
/sbin/iptables

whichコマンドで、iptablesがインストールされているパス /sbin/iptables が返ってくる場合は、すでにiptablesはインストールされています。

逆に、以下のようなメッセージが表示された場合はiptablesがインストールされていません。

/usr/bin/which: no iptables in (/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin)

この場合は、yumコマンドでインストールしてください。

# yum install iptables

iptablesの基本的な考え方

iptablesには、INPUTOUTPUTFORWORDという3つのポリシーがあります。それぞれの通信の基本ポリシーを”DROP”(拒否)、”ACCEPT”(許可)のどちらかに設定できます。
INPUTは、サーバーに入ってくる通信のポリシーです。ここでは基本ポリシーを”DROP”にして、あとで個別のポートに対して許可する設定にします。
OUTPUTは、サーバーから出て行く通信のポリシーです。基本ポリシーは”ACCEPT“にします。
FORWARDは、受信したデータを他のサーバーへ転送する際に適用される設定です。ここでは、特に転送するサーバーは無いので”DROP”にします。

iptablesのポリシー

実際の設定事例と解説

ポリシーを決めたあとに、個別のポートを許可する設定を行います。
事例を見てもらった方が早いと思いますので、実際のiptablesの設定ファイル内容を以下に紹介します。(2行以上に渡っている行は、実際には1行です)

# (1) ポリシーの設定 OUTPUTのみACCEPTにする
*filter
:INPUT   DROP   [0:0]
:FORWARD DROP   [0:0]
:OUTPUT  ACCEPT [0:0]

# (2) ループバック(自分自身からの通信)を許可する
-A INPUT -i lo -j ACCEPT

# (3) データを持たないパケットの接続を破棄する
-A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# (4) SYNflood攻撃と思われる接続を破棄する
-A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# (5) ステルススキャンと思われる接続を破棄する
-A INPUT -p tcp --tcp-flags ALL ALL -j DROP

# (6) icmp(ping)の設定
# hashlimitを使う
# -m hashlimit                   hashlimitモジュールを使用する
# —hashlimit-name t_icmp  記録するファイル名
# —hashlimit 1/m               リミット時には1分間に1パケットを上限とする
# —hashlimit-burst 10        規定時間内に10パケット受信すればリミットを有効にする
# —hashlimit-mode srcip    ソースIPを元にアクセスを制限する
# —hashlimit-htable-expire 120000   リミットの有効期間。単位はms
-A INPUT -p icmp --icmp-type echo-request -m hashlimit --hashlimit-name t_icmp --hashlimit 1/m --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-htable-expire 120000 -j ACCEPT

# (7) 確立済みの通信は、ポート番号に関係なく許可する
-A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT

# (8) 任意へのDNSアクセスの戻りパケットを受け付ける
-A INPUT -p udp --sport 53 -j ACCEPT

# (9) SSHを許可する設定
# hashlimitを使う
# -m hashlimit                   hashlimitモジュールを使用する
# —hashlimit-name t_sshd 記録するファイル名
# —hashlimit 1/m              リミット時には1分間に1パケットを上限とする
# —hashlimit-burst 10       規定時間内に10パケット受信すればリミットを有効にする
# —hashlimit-mode srcip   ソースIPを元にアクセスを制限する
# —hashlimit-htable-expire 120000   リミットの有効期間。単位はms
-A INPUT -p tcp -m state --syn --state NEW --dport 22 -m hashlimit --hashlimit-name t_sshd --hashlimit 1/m --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-htable-expire 120000 -j ACCEPT

# (10) 個別に許可するプロトコルとポートをここに書き込む。
# この例では、HTTP(TCP 80)とHTTPS(TCP 443)を許可している。
-A INPUT -p tcp --dport 80   -j ACCEPT
-A INPUT -p tcp --dport 443  -j ACCEPT

COMMIT

この設定内容を/etc/sysconfig/ の下にiptables というファイル名で保存します。
具体的には以下のコマンドになります。rootユーザーで作業してください。
vimコマンドでエディタを起動し、上記設定内容を貼り付けたあと、:wqで保存終了してください。

# cd /etc/sysconfig
# vim iptables

上記の設定内容について詳しく解説します。
(1) はポリシーの設定です。INPUT、OUTPUT、FORWARDそれぞれについてDROPまたはACCEPTの設定を指定します。

(2) 〜 (5) については、不正な接続の禁止などをする共通の設定です。このまま設定しておけば良いです。

(6) はpingの設定です。pingの応答を許可していますが、同一IPアドレスから繰り返しやってくるpingリクエストについては、外部からの攻撃とみなし拒否するようにしています。hashlimitオプションを使うことで、120秒の間に10回パケットを受信すれば、それ以降のリクエストには応答をしないように設定しています。

(7) は、確立済みの接続について通信を許可する設定です。これもよく使われる一般的な設定ですのでそのまま設定しておけば良いです。

(8) は、サーバーからのDNS問い合わせに対しての戻りパケット(UDP ポート53)を許可する設定です。これを許可しておくと、パソコンからサーバーへのSSH接続などで無駄に待たされることが無くなります。

(9) は、SSHを許可する設定です。ping設定のときと同じく、hashlimitオプションで接続回数による制限をかけています。
2分間の間に同一IPアドレスから10回接続要求があると不正な接続とみなし、それ以降の新しい接続要求を2分間拒否します。

(10) は、サービスごとに通信を許可する設定です。ここでは、TCPポート80のHTTPと、TCPポート443のHTTPS(SSL)を許可する設定をしています。
もし、他にも通信を許可したいサービスがある場合は、行を追加してください。以下の赤色の部分を通信許可したいサービスにあわせてカスタマイズすれば良いです。

-A INPUT -p tcp --dport 443    -j ACCEPT

もし、許可したいサービスのプロトコルがTCPなのかUDPなのか分からない場合は、いったんTCPとUDPのそれぞれの許可設定をしておいて(つまり2行の設定を書いておいて)、片方ずつ設定を無効にして本当に通信ができるかどうか試してみるなどして確認すれば良いと思います。または、本当に分からない場合はTCP、UDPともに通信許可をしておいても良いと思います。

設定が完了したあとは、iptablesを再起動します。
気をつけなればならないのは、SSHの設定です。SSHの通信を許可しておかないと、iptablesを有効にしたときに、新しくSSHの接続ができなくなります。
万が一、iptablesの設定に失敗してSSH通信ができなくなってしまった場合は、SSHターミナルからではなく、さくらVPSのコンソールパネルからVNCコンソール機能を使ってサーバーにログインし、iptablesの設定を正しく設定しなおしてください。

# service iptables restart

コマンド実行後[FAILD]と表示される場合は、設定ファイルに不備がありiptablesが有効になっていません。いま一度設定内容を確認してください。

設定が正しく行われたら、次のコマンドで設定状況を確認してみましょう。

# iptables -nL
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x00
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x3F
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 8 limit: up to 1/min burst 10 mode srcip htable-expire 120000
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp spt:53
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 flags:0x17/0x02 limit: up to 1/min burst 5 mode srcip htable-expire 120000
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain INPUTの項で、2280443のポートがACCEPTされていることが分かります。
以上でiptablesによるファイアウォールの設定ができました。

 

最後に、iptablesについて詳しく書かれたサイトを紹介します。
iptablesについて、より細かい設定を行いたい場合に参照してください。
CentOS iptablesによるパケットフィルタ
ファイアウォール(iptables)の設定

少しやり方は異なりますが、さくらインターネットの公式サポートサイトにもiptablesの設定方法について解説がありますので、こちらも合わせてご覧ください。
iptablesの設定方法|さくらインターネット公式サポートサイト

 

Webサーバー運用講座の第4回目は以上です。
次回はWebコンテンツのバックアップ/リストアの方法や、OSのセキュリティアップデートについて解説します。

あわせて読みたい

>>「サーバーってなに?」~初心者でもよくわかる!VPSによるWebサーバー構築講座(1)
>>あなたのサーバは大丈夫?Shellshock対策をしましょう
>>さくらのVPSからディスクイメージを移行してみよう – 「楽しいさくらのクラウド」
>>Movable Type をさくらのVPSにインストールしてみよう
>>DrupalをVPSにインストールしてみよう

おしらせ

banner_vps

 

初心によるWebサーバー運用講座者でもよくわかる!VPS 公開日
【第1回】「サーバーってなに?」~初心者でもよくわかる!VPSによるWebサーバー構築講座(1) 2014年11月20日
【第2回】「よく分かる公開鍵認証」~初心者でもよくわかる!VPSによるWebサーバー運用講座(2) 2015年9月18日
【第3回】「Muninでかんたんサーバー監視」~初心者でもよくわかる!VPSによるWebサーバー運用講座(3) 2015年10月20日
【第4回】ファイアウォールiptablesを簡単解説~初心者でもよくわかる!VPSによるWebサーバー運用講座(4) 2016年1月15日

WAFの基礎から、SiteGuard Liteのセットアップまで ~SiteGuardシリーズでセキュリティ強化(その1)~

$
0
0

はじめに

はじめまして。株式会社ジェイピー・セキュアの齊藤です。

皆様、「さくらの専用サーバさくらのクラウド」では、ウェブアプリケーションファイアウォール(Web Application Firewall。以下、WAF)が標準で利用できることをご存知でしょうか?

「さくらの専用サーバ/さくらのクラウド」をご利用の場合、対応OSのイメージに、弊社のWAF製品「SiteGuard Lite」が組み込まれているため、セキュアなWebサイトの構築が可能です。

この連載では、急速に普及が進んでいるWAFの基本について紹介するほか、「さくらの専用サーバ/さくらのクラウド」をご利用の皆様向けに、「SiteGuard Lite」の設定・運用イメージを紹介していきたいと思います。
連載は、全3回を予定しており、第3回では、CMS(Content Management System。以下、CMS)のセキュリティ対策についても紹介します。

第1回

WAFの概要と「SiteGuard Lite」について紹介します。また、「SiteGuard Lite」のセットアップと動作確認の方法を紹介していきます。

第2回

検査機能のコアとなるシグネチャ検査・シグネチャ更新設定のほか、通知設定など、「SiteGuard Lite」の詳細設定について紹介します。

第3回

CMSのセキュリティ対策について説明したのち、人気のWordPressについて、SiteGuardシリーズを活用したセキュリティ対策を紹介します。

WAFとは、どのような製品なのだろうか?Webサイトのセキュリティ対策に有効なのか?設定が難しいのではないか?
そのような疑問を解決できるよう、連載を通して、できるだけ分かりやすく紹介していきますので、どうぞ宜しくお願いいたします。

WAFとは

ご存知のことと思いますが、個人情報の窃取やサイト改ざんなど、Webサイトを狙った攻撃による事件・事故が後を絶たず、Webサイトのセキュリティ対策が求められています。
これらの事件・事故の原因は、SQLインジェクションやクロスサイトスクリプティングといったウェヴアプリケーションの脆弱性を悪用した攻撃によるものが代表的であり、その脅威は、Webサイトの規模や企業・個人に関係なく、身近なこととして意識する必要があります。
攻撃による被害を受けないようにするだけでなく、改ざんによるマルウェア配布サイトへの悪用など、加害者とならないように努めることも重要です。

安全なWebサイト・アプリケーションの構築は、セキュア設計・セキュアプログラミングが基本であり、それを完璧に行うことができれば何の心配もありません。
しかしながら、間違った対策や対策漏れが生じるケースもあり、現実問題として、脆弱性をゼロにするのは簡単なことではありません。
脆弱性診断によって、脆弱性が見つかった場合には、修正が不可欠ですが、運用上の理由(サイトを停止できない、バージョンアップできないなど)により修正が困難であったり、修正までに長い時間が必要になることもあります。

そこで、効果的にWebサイトのセキュリティを強化する一つの方法として、WAFを紹介させていただきます。
WAFは、ウェブアプリケーションの脆弱性を悪用した攻撃からWebサイトを保護するための有力なソリューションとして注目を集めています。

WAF

WAFを導入することで、SQLインジェクションやクロスサイトスクリプティングなど、ウェブアプリケーションの脆弱性を悪用する攻撃を効率良く防御することができます。
それだけでなく、不完全な対策や対策漏れに備えるセーフティネットとしての活用、2014年に大きく取り上げられたApache Strutsやbashの深刻な脆弱性への対策などにも、WAFが有効活用されています。
前述の運用上の理由に該当しますが、Apache Strutsやbashの深刻な脆弱性が発見されたときは、すぐに対策を実施することができないWebサイトを救済するために、WAFが大きな役割を果たしました。
2015年には、WordPressやJoomla!といったCMSの脆弱性を狙った攻撃も大きな話題になるなど、WAFの必要性は益々高まっています。

「さくらの専用サーバ/さくらのクラウド」では、標準でWAFを利用することができます。
この機会に、”ワンランク上のWebセキュリティ“を実現する一つの手段として、WAFの利用を検討してみてはいかがでしょうか。

ホスト型WAF「SiteGuard Lite」

WAFには、ゲートウェイ型やホスト型、サービス型のようにいくつかの形態があります。
「さくらの専用サーバ/さくらのクラウド」で標準利用できるWAFは、ホスト型WAF「SiteGuard Lite」です。
ホスト型のWAFは、ウェブサーバー上にインストールして利用しますので、各サーバー毎にインストールする必要がありますが、最もシンプルな構成で、ネットワークの変更が不要であるという利点があります。
そして、「SiteGuard Lite」は、ウェブサーバーApacheのモジュールとして動作するWAFです。
攻撃パターンを定義したシグネチャをもとに、HTTP/HTTPSのリクエストを検査するシグネチャ検査機能を主としています。

SiteGuard Lite

製品の主な特長は、

  • 高品質なシグネチャによる防御性能
  • シンプルで直観的なGUIで、かんたん設定

です。
業態を問わず、導入実績が豊富なWAF製品で、特にホスティング環境での実績と安定稼働には定評があります。

通常、製品のインストールは、RPMパッケージによるインストールとセットアップスクリプト実行の2ステップとなりますが、「さくらの専用サーバ/さくらのクラウド」をご利用の場合、対応OSのイメージに「SiteGuard Lite」が組み込まれた状態で提供されていますので、セットアップスクリプトを実行するだけで、「SiteGuard Lite」の利用を開始することができます。※

※すでにご利用中のサーバーに追加導入することはできません。
「専用サーバ:新規、OS再インストール」「クラウド:インストール済みアーカイブからのサーバ作成」でご利用いただくことができます。

セットアップスクリプトの実行

それでは、「さくらの専用サーバ/さくらのクラウド」の環境で、「SiteGuard Lite」のセットアップスクリプトを実行してみましょう。
ターミナルで、「SiteGuard Lite」のインストールディレクトリにあるsetup.shを実行します。
setup.shは、root権限で実行してください。

# cd /opt/jp-secure/siteguardlite/
# ./setup.sh

セットアップでは、Apacheの設定ファイルや実行コマンドの指定、「SiteGuard Lite」のウェブ管理画面で使用するポート番号の指定、ウェブ管理画面のアクセス制限などを行います。
難しそうに思われるかもしれませんが、ご安心ください。対話形式のスクリプトで簡単に設定できるようになっています。
Apacheの設定ファイルや実行コマンドなども自動的に検出しますので、基本的には[Enter]を押していくだけです。
あっと言う間にセットアップが完了するのですが、一つだけ、ウェブ管理画面のアクセス制限に関する項目については、適切に設定していただくことを推奨しています。

please enter the addresses allowed to access the web console for https.
ex:192.168.1. 10.0.0.0/24
please enter allowed addresses. [ALL] -->192.168.1.100(例)

デフォルト値は[ALL]で、ウェブ管理画面について、全ての接続元からのアクセスを許可します。
一般的な管理ページへのアクセス制限と同様、アクセスを許可する接続元を登録しておきましょう。

セットアップスクリプトの最後の処理で、Apacheの再起動を行い、セットアップ完了です。

Apache restart. Are you sure? [yes]|no -->Enter押下
stopping apache ...
starting apache ...
apache restart done.
-----------------------------------------------------
+ finished SiteGuard Lite setup +
-----------------------------------------------------
Please access following URL for starting service.
https://hostname:9443/
(default user:admin, default password:admin)

SELinuxを有効にした環境でご利用いただく場合は、「SELinux 環境での事前設定」が必要です。
設定方法につきましては、製品マニュアル(管理者用ガイド)を参照してください。
(専用サーバの場合は、技術ドキュメントのページで、クラウドの場合は、さくらのクラウド ニュースのSiteGuard Lite(WAF)のページで、製品マニュアルをダウンロードすることができます。)

基本動作の確認

初期設定

セットアップ完了後は、ウェブ管理画面を使用して「SiteGuard Lite」の設定を行います。
ブラウザを起動して、ウェブ管理画面に接続してみましょう。

https://[サーバーホスト名(またはIPアドレス)]:9443 にアクセスすると、「SiteGuard Lite」のログイン画面が表示されます。

SiteGuard Lite 画面-1

ログイン画面が表示されたら、初期ID・パスワードで、ウェブ管理画面にログインします。
ログイン画面が表示されない場合は、ポート9443への接続が許可されているかiptablesなどの設定を確認してみてください。

SiteGuard Lite 画面-2

初回ログイン時に、管理パスワードの変更画面が表示されますので、新しいパスワードを設定してからご利用ください。
管理ユーザ名の変更も同じ画面で行うことができます。
(初期パスワードの変更は必須です。変更するまで他の操作を行うことはできません。)

初期パスワードの変更が完了したら、検査機能を有効にしてみましょう。(初期値:無効)
稼働中のWebサイトにWAFを導入するときは、設定内容や手順を検討してから検査機能を有効にしますが、ここでは「さくらの専用サーバ/さくらのクラウド」での「SiteGuard Lite」の提供形態に合わせて、新規構築のイメージで、順に設定と確認方法を紹介していきます。

モジュール設定の[ウェブ攻撃検査]で有効を選択し、画面下の[適用]ボタンを押します。

SiteGuard Lite 画面-3緑色のチェックと「設定を保存しました。」のメッセージを確認してください。

SiteGuard Lite 画面-4これで、初期設定は完了です。

動作確認

初期設定が完了しましたので、動作確認を行います。
ブラウザを起動して、Webページを表示してみましょう。

http://[サーバーホスト名(またはIPアドレス)]

まずは、Webサイトのページが正しく表示されることを確認してください。

次に、「SiteGuard Lite」の検査機能が有効になっていることを確認します。
URLのパスに、”WAF-TEST-SIGNATURE”という文字列が含まれている場合に検出するテスト用のシグネチャが用意されていますので、検出テストパスにアクセスしてみましょう。

http://[サーバーホスト名(またはIPアドレス)]/WAF-TEST-SIGNATURE/

今度は、検査機能によって検出したことを示す[検出メッセージ]が表示されます。

SiteGuard Lite 検出メッセージ該当のリクエストは拒否(BLOCK)となり、HTTPの応答コードは「403 Forbidden」です。

表示される検出メッセージの内容は、[検出メッセージの編集]画面で変更することができます。
(9000バイトまで)
なお、Apacheの設定で、”ErrorDocument 403″を指定している場合は、ErrorDocumentで指定したメッセージが表示されます。
オリジナルエラーページの表示をご希望の場合は、必要に応じてErrorDocumentの使用を検討してみてください。

検出ログの確認

検出内容の詳細は、動作ログの[検出ログ]で確認します。

SiteGuard Lite 画面-5

ログの表示アイコンにカーソルをあてると、ポップアップが表示され、検出した日時や動作・接続元・メソッド・URL・検出したシグネチャなどの情報を見やすいかたちで確認することができます。SiteGuard Lite 画面-6以上で、初期設定と基本的な動作確認は完了です。

おわりに

今回は、WAFの概要と「さくらの専用サーバ/さくらのクラウド」で、ホスト型WAF「SiteGuard Lite」の利用を開始するまでの手順を紹介しました。
基本的な内容が中心となりましたが、まずは、ウェブ管理画面の操作方法を含めて、簡単な手順でスタートできるというイメージが伝われば幸いです。
次回は、「SiteGuard Lite」のシグネチャ検査やシグネチャの更新設定、管理者への通知設定、統計グラフの見方など、詳細設定や運用について紹介させていただく予定です。

SiteGuard Liteの詳細設定 ~SiteGuardシリーズでセキュリティ強化(その2)~

$
0
0

はじめに

前回は、WAFの概要と「さくらの専用サーバさくらのクラウド」の環境で、ホスト型WAF「SiteGuard Lite」を動作させるまでの手順を紹介しました。
今回は、「SiteGuard Lite」の防御機能の主となるシグネチャ検査機能のほか、通知設定や統計グラフの活用方法など、詳細設定について紹介していきます。

  • シグネチャ検査機能
  • 管理者への通知設定
  • 統計
  • syslogへの出力
  • 設定のバックアップ・リストア
  • 動作確認

紹介する内容は、製品マニュアル(管理者用ガイド)に記載されている内容ですが、今回の記事により、一通りの機能と設定を把握できるように構成しており、連載を通して「SiteGuard」シリーズの設定ができるようになっています。
テスト時・運用開始後の設定変更などについても、イメージできるように配慮していますので、宜しくお願いいたします。

シグネチャ検査機能

「SiteGuard Lite」は、標準搭載のトラステッド・シグネチャによる防御(シグネチャ検査機能)を主としています。
トラステッド・シグネチャによる検査を行うことで、ウェブアプリケーションの脆弱性を悪用する様々な攻撃から、Webサイトを保護することができます。

トラステッド・シグネチャ

トラステッド・シグネチャは、ジェイピー・セキュアが提供する「SiteGuard」シリーズに搭載されている高品質なシグネチャの名称です。
Apacheのモジュールとして動作する「SiteGuard Lite」は、HTTP/HTTPSのリクエストを検査し、

  • SQLインジェクション
  • クロスサイトスクリプティング
  • ディレクトリトラバーサル
  • OSコマンドインジェクション
  • HTTPヘッダインジェクション など

ウェブアプリケーションの脆弱性を悪用する攻撃を検出します。
また、Apache KillerやApache Struts、ShellShockと呼ばれたbashの脆弱性など、ウェブサーバーやフレームワークの脆弱性を悪用する攻撃を検出するシグネチャも用意されており、迅速なシグネチャリリースに定評があります。

シグネチャ検査によって、大規模な個人情報の流出といった甚大な被害を受けるSQLインジェクション攻撃を防御したり、CMS本体やプラグインの脆弱性にも多いクロスサイトスクリプティングなどを防御することができます。
「小規模なWebサイトだから」、「個人のブログサイトだから」のように、あまり気にされていない方もいるのですが、改ざん被害の結果として、マルウェアの配信サイトや迷惑メール配信などに悪用されるケースもありますので、Webサイトの規模や企業・個人に関係なく、加害者とならないように努める必要があります。

トラステッド・シグネチャの設定は、ウェブ管理画面の[モジュール設定]-[トラステッド・シグネチャの設定]で確認することができます。

siteguardlite-trusted_signature

シグネチャは、防御性能と運用性のバランスに配慮した”推奨設定”で、標準搭載しています。
基本的には、”推奨設定”でご利用いただいていますが、使用していないフレームワークに関するシグネチャは無効にするなど、個別に設定を変更することも可能です。
設定を変更した場合は、[適用]ボタンを押して、設定を反映してください。

シグネチャ更新設定

トラステッド・シグネチャの更新は、ウェブ管理画面の[シグネチャ更新設定]の画面で行います。
更新方法は、[今すぐ更新]ボタンによる手動更新とスケジュールによる自動更新があり、シグネチャ更新サイトにHTTPS(443)で接続します。
インターネットへの接続にプロキシサーバを経由する必要がある場合は、プロキシサーバの指定ができます。

まずは、最新のシグネチャに更新するため、[今すぐ更新]ボタンを押してみましょう。

siteguardlite-signature_update_01

シグネチャの更新に成功すると、「更新に成功しました!」のメッセージが表示されます。

siteguardlite-signature_update_02

シグネチャの更新に失敗した場合は、更新失敗のメッセージとエラーの内容が画面に出力されますので、原因の調査に役立ちます。

自動更新では、

  • 毎日 00:00
  • 毎週水曜日 01:00
  • 毎月1日 05:00

のように、更新間隔を指定することができます。(初期値:自動更新無効)

[保存]ボタンを押すと、rootのcrontabに更新スケジュールが登録されます。

siteguardlite-signature_update_03

スケジュールによる更新、メンテナンスや運用作業のタイミングに合わせた手動更新など、Webサイトの運用方針に合わせてご利用ください。
自動更新を設定していても、緊急性の高いシグネチャがリリースされたときの即時更新(手動更新との併用)が可能です。

シグネチャの更新ログは、[ログ]-[シグネチャ更新ログ]で確認することができます。

siteguardlite-signature_update_04

 カスタム・シグネチャ

「SiteGuard Lite」では、標準搭載されているトラステッド・シグネチャのほかに、お客様独自のルールを作成できるカスタム・シグネチャによる検査が可能です。(1000個までの条件を登録することができます。)
カスタム・シグネチャは、ウェブ管理画面の[モジュール設定]-[カスタム・シグネチャの編集]画面で、作成します。

siteguardlite-custom_signature_01

以下、予め用意されているサンプルをもとに、カスタム・シグネチャの作成例を紹介します。
いずれも、無効の状態で登録されていますので、必要に応じて、有効にしてご利用ください。

sample-01:検出の除外設定

カスタム・シグネチャでは、条件を指定した検出の除外設定を作成することができます。
sample-01は、”field1″というパラメータについて、signature-1~4とsignature-11のシグネチャによる検出を除外する設定です。
(ここでは、実際のトラステッド・シグネチャ名ではなく、仮のシグネチャ名を使用しています。)

siteguardlite-custom_signature_02

条件に、URLを加えた複数条件を登録することもできますので、柔軟な設定が可能です。
一部の検出を除外する場合などに、有効活用してください。

sample-02:ブルートフォース対策

カスタム・シグネチャには、「頻度判定」の機能があります。
作成した条件に対して、何秒間に何回一致したかを接続元IPアドレスでカウントしますので、ログインページへのブルートフォース攻撃といった高頻度の接続を検出することができます。

siteguardlite-custom_signature_03

sample-02では、login.phpへの接続が”1秒間に3回以上”発生した場合に検出します。

siteguardlite-custom_signature_04

機械的な不正ログイン試行などに有効なシグネチャで、こちらも要求メソッドなどを加えた複数条件を登録することができます。

sample-03:管理者アクセスの検査除外

接続元IPアドレスの指定で、条件に一致する接続を安全とみなす(検査を除外する)設定です。
CMSなどの管理ページの操作で、ページやコードの編集といった管理者操作がトラステッド・シグネチャの検出対象になってしまうことがあるため、管理者アクセスを安全とみなす設定として、作成しておくことを推奨しています。
sample-03では、/admin/というパスについて、192.168.1のネットワークからの接続を安全とみなします。

siteguardlite-custom_signature_05

一例となりますが、有名なCMSであるWordPressの場合、ブルートフォース対策のシグネチャであれば、sample-02の検査文字列で、

/wp-login\.php

のように、WordPressのログインページを指定します。
検査文字列を変更する場合は、[条件の編集]ボタンを押してください。
また、せっかくですので、シグネチャ名とコメントも分かりやすい内容に変更しておきましょう。

siteguardlite-custom_signature_06

管理者アクセスの検査除外については、sample-03の最初の条件になっている検査対象”パス”の検査文字列で、

/wp-admin/

のように、WordPressの管理アクセスのパスを指定します。
同じように、検査文字列の変更は[条件の編集]で行い、シグネチャ名とコメントも分かりやすい内容に変更しておきましょう。

siteguardlite-custom_signature_07

sample-03は、”パス”と”接続元IPアドレス”の組み合わせが条件になっていますが、条件を1つにして、接続元IPアドレスの指定だけで安全とみなす設定も可能です。
作成・編集したカスタム・シグネチャは、[適用]ボタンを押すことで、反映されます。

ここで、除外するトラステッド・シグネチャ名検査文字列に関する補足となりますが、それぞれ正規表現で指定します。

■設定例
^signature-1$                  signature-1が対象
^signature-[1-4]$             signature-1~4が対象
^192\.168\.1\.               192.168.1.xが対象
^192\.168\.1\.1(5|6)$    192.168.1.15と192.168.1.16が対象

^:      文字列の最初
$:      文字列の最後
\X:     記号Xのエスケープ表記
[X-Y]:  文字範囲指定
A|B:    AまたはB
():      グループ化

設定するときは、文字列の最初と最後を示す”^”と”$”や範囲指定について、気を付けてください。
記述にコツが必要となるケースもありますが、柔軟にシグネチャを作成できるという正規表現だからこそのメリットがあり、このカスタマイズ性も「SiteGuard」シリーズの魅力の1つです。

 管理者への通知設定

続いて、管理者への通知設定です。
「SiteGuard Lite」には、検査機能によって検出した内容のほか、製品に発生したエラー情報を管理者宛に通知する機能があります。
基本的な設定方法は同じですので、ここでは、検出通知をもとに説明していきます。
通知の設定は、[モジュール設定][管理者への通知設定]で行います。(初期値:無効)

検出通知を有効にして、通知間隔を指定します。(初期値:10分)
初期値の場合、検出情報を要約したメールが10分間隔で送信されます。
通知メッセージの内容は、[サマリ検出通知メッセージの編集]で編集することができます。
通知の間隔は、分単位による指定のほか、毎日00:00のような設定も可能です。

siteguardlite-notify_admin_01

メールを送信する宛先の指定も、同じ画面上で行います。

siteguardlite-notify_admin_02

宛先のメールアドレスのほか、差出人(From)を指定します。
宛先は、改行区切りで、複数のアドレスを指定することができます。
差出人の指定は任意で、差出人の指定がない場合は、宛先に指定された先頭のメールアドレスが差出人に設定されます。

このほか、SMTPサーバのホスト名(または、IPアドレス)とポート番号、SMTP認証が必要な場合は、認証のユーザ名とパスワードを指定します。
必要な情報を入力したら、[適用]ボタンを押して設定を反映してます。

外部からのWebサイトへのアクセスで発生した検出情報の要約が、メールで送信される有用な機能となっていますので、是非、利用してみてください。

siteguardlite-notify_admin_03

通知間隔の指定は、いずれか1つとなります。
検出した情報を早いタイミングで確認したい場合は、分単位での設定。デイリーレポートとして通知を受けたい場合は、毎日を設定のように、運用方針に合わせてご利用ください。
どちらも、検出がなかった場合、メールは送信されません。

統計

ウェブ管理画面のホームには、検出結果を集計した統計グラフが表示されます。
検出全体の種類別統計のほか、検出したシグネチャのTOP10を確認することができます。

siteguardlite-statistics_01

siteguardlite-statistics_02

ここまでの紹介では、前回の検出テスト用パス(WAF-TEST-SIGNATRE)へのアクセスだけしか試していませんが、実際に運用を開始していただくと、上図のような統計が確認できると思います。

統計の更新は、60分間隔(毎時0分)で行っていて、更新スケジュールは、rootのcrontabに登録されています。

0 * * * * cd /opt/jp-secure/siteguardlite;./siteguardlite_statistics.sh

統計は、現在の統計(最新)と前回の2世代を表示可能です。
[統計をクリア]ボタンを押すことで、統計のクリアと前回分としてのコピーが行われます。

統計のクリアは自動化することもできます。

0 0 1 * * cd /opt/jp-secure/siteguardlite; make statistics-clear

というスケジュールをrootのcrontabに登録しておくと、毎月1日の00:00に、過去1ヶ月分の統計を前回分としてバックアップし、新たに統計の作成を開始しますので、月次統計として活用することができます。

syslogへの出力

「SiteGuard Lite」のログは、インストールディレクトリにあるlogsに、ログファイルとして出力されます。
特に必要な場合、出力先をsyslogに変更することができます。

ログ出力の設定変更は、[アドバンスト設定]で行います。
デフォルト値は、ファイルになっていますので、これをsyslogに変更し、タグファシリティプライオリティを設定してください。

siteguardlite-syslog_01

siteguardlite-syslog_02

設定変更後は、忘れずに[適用]ボタンを押してください。
なお、syslogに出力したログファイルは、ウェブ管理画面の[ログ]-[動作ログ]には表示されませんので、ウェブ管理画面からのログ閲覧も行う場合は、ログの出力先でファイルとsyslogを選択してください。

設定のバックアップ・リストア

必要に応じて、設定変更を検討する場合はありますが、ここまでの内容で、基本的に「SiteGuard Lite」の設定は完了です。
「SiteGuard Lite」には、[バックアップ・リストア]の機能がありますので、万一の操作ミスや障害時に備えて、設定のバックアップを取得しておきましょう。

siteguardlite-backup_resotre

バックアップを取得するときは、[バックアップ]を押します。
リストア時は、取得したバックアップファイルを選択して、[リストア]を押すだけです。

バックアップ・リストアのもう1つの活用方法ですが、複数台の「SiteGuard Lite」に同じ設定を適用したい場合にも有効です。
2台のウェブサーバーを構築し、今回の連載をもとに、「SiteGuard Lite」を同じ設定で動作させる場合、1台目で設定した情報を[バックアップ]して、2台目に[リストア]することができます。
複数台の「SiteGuard Lite」を同じ設定で構築する場合には、是非、有効活用してください。

※[バックアップ]により、ウェブ管理画面で設定した各種設定のバックアップができますが、cronへの追加登録となる下記の設定は、バックアップの対象外となるため、リストア後の再設定をお願いします。

  • シグネチャの自動更新スケジュール
  • 統計クリアの自動化(前述の月次統計の例)

動作確認

ここまでの準備が整ったら、コンテンツ作成のほか、Webサイトの公開に向けたテストを実施し、通常アクセスやアプリケーションの動作に問題がないことを確認しましょう。
トラステッド・シグネチャの推奨設定は、防御性能と運用性のバランスを図っていますが、通常アクセスが検出されてしまった場合には、前述のカスタム・シグネチャの作成例を参考に、サンプルの編集または、新規カスタム・シグネチャを作成してください。

今回の連載では、「さくらの専用サーバ/さくらのクラウド」での「SiteGuard Lite」提供形態に合わせて、新規構築をイメージしていますが、「SiteGuard Lite」をあとからセットアップ(将来的に、稼働中のWebサイトへ導入)する場合は、「監視運用(モニタリング)」を推奨しています。
監視運用については、製品マニュアル(管理者用ガイド)を参照してください。
(専用サーバは、技術ドキュメントから、クラウドは、SiteGuard Lite(WAF)からダウンロードすることができます。)

おわりに

今回は、防御機能に関する説明だけでなく、シグネチャ更新や通知設定、統計といった運用開始後にも役立つ設定、仕様について紹介しました。
「ワンランク上のWebセキュリティ」の一手段として、シンプル・高性能なホスト型WAF「SiteGuard Lite」の有効活用を是非、ご検討ください。
次回は、CMSのセキュリティを中心に紹介していく予定です。
WAFによる対策のほか、人気のWordPressについて、セキュリティプラグイン「SiteGuard WP Plugin」を活用した対策を紹介します。

CMSのセキュリティ対策 ~SiteGuardシリーズでセキュリティ強化(その3)~

$
0
0

はじめに

この連載では、「さくらの専用サーバさくらのクラウド」で、ホスト型WAF「SiteGuard Lite」を利用するための手順や設定を紹介してきました。
連載の最終回となる今回は、WordPressを中心にCMSのセキュリティについて紹介していきます。
以下のポイントについて、「SiteGuard」シリーズによる対策を含めて、設定方法などを分かりやすく紹介していきたいと思いますので、宜しくお願いいたします。

  • 狙われるCMSの脆弱性
  • WAFによる対策
  • WordPress用セキュリティプラグイン「SiteGuard WP Plugin」

セキュリティプラグインについては、ジェイピー・セキュアが提供する「SiteGuard WP Plugin」(無償プラグイン)をもとに、説明させていただきます。

狙われるCMSの脆弱性

CMSは、簡単にブログを作成できるだけでなく、さまざまな機能拡張など、ユーザーにとって大きな魅力があり、今では多くの企業もCMSを活用して、Webサイトの構築・運用をしています。
しかしながら、不正ログインや改ざんなど、CMSで構築されたウェブサイトへの攻撃は増加の一途を辿っているのも事実であり、CMSのセキュリティ対策は重要な課題となっています。

国内のシェアは、WordPressが圧倒的ですが、

  • WordPress
  • Drupal
  • Joomla!

これらのCMSが、三大CMSと呼ばれることも多いため、ここ数年のセキュリティ事情について、少しずつ紹介します。

まず、WordPressですが、プラグインが豊富で、その拡張機能が大きな魅力である一方で、プラグインの脆弱性を悪用した攻撃が後を絶ちません。
2015年にかぎった話ではありませんが、人気プラグインの脆弱性発見が相次ぎ、多くのWebサイトが改ざんされるなど、深刻な状況が続きました。このほか、WordPress本体でも深刻なクロスサイトスクリプティングの脆弱性が見つかり、攻撃の実証コードや実演が公開されたことから、大きな話題になりました。

次に、Drupalですが、2014年の10月に深刻なSQLインジェクションの脆弱性が発見されたことが大きな話題となり、Joomla!については、2015年10月に発見されたSQLインジェクションの脆弱性に対する攻撃の増加と、12月のゼロデイによるリモートコード実行(原因は、PHPの既知の脆弱性)が記憶に新しいところです。
WordPress同様に、拡張機能の脆弱性が数多く報告されているのも実情であり、CMSが狙われる要因の一つとなっています。

プラグインやテーマなどの拡張機能は、不特定多数のユーザーや有志によって、自由に開発・提供されています。CMSの利用において、様々なメリットをもたらす反面、開発者ごとの安全性の配慮にばらつきがあるという実情から、深刻な脆弱性・攻撃へとつながってしまうことがあります。
CMS本体だけでなく、プラグインなどの拡張機能についても、運用中のサイトで利用している拡張機能のバージョンやメンテナンス状況、脆弱性の有無に注意するよう心がけてください。

 WAFによる対策

先に述べましたように、CMSにおいても、SQLインジェクションやクロスサイトスクリプティングなどによる攻撃、被害が多発しています。
2015年 WordPressに関しては、日に数件というペースで、プラグインの脆弱性が報告された時期もあり、クロスサイトスクリプティングとSQLインジェクションだけで脆弱性の6~7割を占めるという状況でした。
CMSの運用では、拡張機能を含めて、最新バージョンを利用することが重要ですが、「すぐにバージョンアップすることができない。」「利用しているプラグインが、最新の本体での動作をサポートしていない」など、バージョンアップが難しいことも多いのではないでしょうか。
このようなケースで、WAFを導入していると、WAFがセーフティネットとして大きな役割を果たします。

cms-waf

WordPress用セキュリティプラグイン「SiteGuard WP Plugin」

ここからは、人気のWordPressのセキュリテイ対策について、考えていきたいと思います。
SQLインジェクションやクロスサイトスクリプティングなどの対策はもちろんですが、WordPressの運用では、

  • 不正ログイン対策
  • コメントスパム対策
  • 管理画面(管理ページ)のアクセス制限

に悩むことも多いのではないでしょうか?

ジェイピー・セキュアでは、WordPressのセキュリティ対策と発展に貢献するために、「SiteGuard WP Plugin」を開発・提供しています。

siteguard-wp-plugin_image

「SiteGuard WP Plugin」は、シンプル且つ簡単に利用できるという「SiteGuard」シリーズのコンセプトを踏襲しており、難しい知識を必要とせず、インストールするだけでWordPressのセキュリティを向上させることができる日本語対応のセキュリティプラグインです。

「SiteGuard WP Plugin」を利用することで、外部からの不正ログインを防御するほか、管理ページへの不正アクセスやコメントスパムの脅威からウェブサイトを守ることができます。
なお、「SiteGuard WP Plugin」は、WordPressの公式ディレクトリへの登録、リリースとなっていますので、どなたでも無償でご利用いただくことができます。

siteguard-wp-plugin_dashboard

この記事では、先ほど課題として挙げた不正ログイン対策コメントスパム対策管理画面(管理ページ)のアクセス制限に役立つ機能を中心に紹介していきます。

ログインページ変更

WordPressのログインページである”wp-login.php“を変更し、機械的な不正ログインを回避するための機能です。
新しいログインページ名は、”login_(5桁の乱数)“で設定されますが、任意の名称を使用することもできます。

siteguard-wp-plugin_rename_loginpage
WordPressのスマートフォン用のアプリから接続するXML-RPC経由のアクセスは、ログインページ変更の対象外となりますが、簡単にログインページを変更することができる便利な機能です。
“wp-login.php”宛の機械的なアクセスが非常に多くなっていますので、不正ログイン対策に活用してみてください。(初期値:ON

変更後のログインページは、管理者宛にメールで通知されますので、メールを保存しておくか、忘れずにブックマークしましょう。
任意のログインページ名を設定する場合は、自分自身にとって分かりやすく、推測されにくいものを設定するようにしてください。

画像認証

ログインページとコメントページに画像認証(CAPTCHA)を追加する機能です。

siteguard-wp-plugin_captcha_01

画像認証(CAPTCHA)は、パスワード確認ページとユーザー登録ページにも表示させることができます。
また、表示する画像は、ひらがな英数字を選択することができ、各項目ごとに、有効・無効を設定することができるように配慮しています。
初期値:全ての項目でON・ひらがな

ログインページに画像認証(CAPTCHA)を設けることで、不正ログイン対策はより強固になり、

siteguard-wp-plugin_captcha_02

コメント欄の画像認証(CAPTCHA)により、コメントスパムへの対策も可能になります。

siteguard-wp-plugin_captcha_03

ひらがなの画像認証(CAPTCHA)が使用でき、読みやすいという点が好評です。

ログインロック

ログインに繰り返し失敗する接続元からのアクセスを禁止する機能です。

siteguard-wp-plugin_login_lock

デフォルト値では、5秒間に3回のログイン失敗があった場合に、その接続元からのアクセスを1分間禁止するという動作をします。
これにより、機械的な不正ログインの試行を効率良く防ぐことができます。(初期値:ON

「SiteGuard WP Plugin」は、ログインページ変更画像認証ログインロックの組み合わせにより、WordPressのログインページを強力に保護しています!

管理ページアクセス制限

管理ページ(/wp-admin/以下)への不正アクセスを防ぐための機能です。

siteguard-wp-plugin_adminpage_filter_01
WordPressの運用において、管理ページのアクセス制限は、重要な位置付けにありますが、接続元IPアドレスを固定することができない環境のアクセス制限は、困難であるという課題がありました。

管理ページアクセス制限の機能を使用することで、ログインに成功した接続元IPアドレスのみ、管理ページ(/wp-admin/)へのアクセスが許可されるようになりますので、簡単に管理ページのアクセス制限を適用できます。

siteguard-wp-plugin_adminpage_filter_0224時間以上、ログインしていない接続元IPアドレスは、順次削除されていきます。

なお、この管理ページアクセス制限の機能は、初期値がOFFになっています。
これは、変更後のログインページ忘れによる初心者の方のログイン不可など、管理ページへのアクセスを「/wp-admin/宛でも行えるようにして欲しい。」というリクエストが多かったためです。

WordPressの仕様上、ログインしていない状態で”/wp-admin/”にアクセスすると、ログインページにリダイレクトしますので、「SiteGuard WP Plugin」を利用する際は、管理ページアクセス制限を有効化(ON)し、リダイレクトによるログインページの表示を禁止することを推奨しています。

その他の機能

ログイン失敗時に詳細エラーを表示させないようにする機能やログインがあった場合のメール通知、WordPress本体やプラグイン、テーマに更新があった場合のメール通知、ピンバックの悪用を防ぐためのピンバック無効化の機能、ホスト型WAF「SiteGuard Lite」と連携したチューニングの補助機能があります。

  • ログイン詳細エラーメッセージの無効化
  • ログインアラート
  • ピンバック無効化
  • 更新通知
  • WAFチューニングサポート

更新通知の機能は、基本となる「最新バージョンの利用」を補助するための機能となっています。
運用中のサイトのバージョンや更新の有無を把握するための機能として、役立ててください。

 

いかがでしたか?
セキュリティ対策に役立つ機能や補助機能を一つのプラグインにまとめて提供していますが、機能毎にON/OFFを設定できるようになっています。
気に入った機能や使ってみたい機能がありましたら、是非お試しください。

プラグインのインストールは、他のプラグインと同様に、WordPressのダッシュボードから行うことができます。
ダッシュボードで、[プラグイン]-[新規追加]の順に選択し、”SiteGuard“を検索します。

siteguard-wp-plugin_install_01

“SiteGuard”が表示されたら、[今すぐインストール]を選択して、インストールを進めてください。

siteguard-wp-plugin_install_02

各機能の説明や使用方法については、「SiteGuard WP Plugin」の使用方法のページで確認することができます。

おわりに

この連載では、WAFの有効性とジェイピー・セキュア「SiteGuard」シリーズの活用方法、CMSのセキュリティについて紹介してきました。
セキュリティということから、少し難しい印象の話が続いてしまったかもしれませんが、できるだけ分かりやすく、役に立つ情報を紹介するように努めました。
連載の内容を「さくらの専用サーバ/さくらのクラウド」で構築するWebサイトのセキュリティ対策に、お役立ていただければ幸いです。

簡単!! レンタルサーバのセキュリティ対策!

$
0
0

「知らない」ではすまされない時代になってきた

2015年12月28日(月)に、経済産業省から「サイバーセキュリティ経営ガイドライン」が発表されました。
これは何かというと、IT に関するシステムやサービス等を供給する企業や、 IT を利用する企業の経営者と幹部に向けて、サイバーセキュリティリスクの対策をするようにと書いたガイドラインになります。
今の所、法的な罰則はありませんが、このガイドラインの中では対策を怠った場合の想定として下記のような事が想定されると警告しています。

・企業イメージの失墜
・信用の喪失
・損害賠償請求

このように行政機関から公式に警告が出ている以上、情報管理者はもう、何かあった時に「知らなかった」では済まされません。

そのため、個人情報をはじめ重要なデータがいっぱい詰まったサーバを扱う管理者は、ますます頭を悩ませる事になる時代になってきたというわけです。

さくらのレンタルサーバならセキュリティ対策も簡単!

でも、そこまで心配する事はありません。
さくらのレンタルサーバはそのほとんどの部分がさくらインターネットで保守、運用されているので、サーバ管理者様にはたった2つの部分を管理していただければいいようになっています。

・パスワードの管理
・ウェブコンテンツ(ホームページのデータ)の管理。

たったこれだけです。

パスワードについて

096846

さくらのレンタルサーバを運用するにあたって、3種類のパスワードがあります。
契約内容変更や新規契約の際などに使われる会員メニューログインのためのIDとパスワード。
サーバのマスターキーとなるサーバパスワード。
そしてメールアドレスなどに紐付いたユーザーのパスワードです。

パスワードは英数混合、記号も混ぜよう

パスワードを強度の高いものにするだけで、だいたいのサイバー犯罪は防げると専門家は言います。
パスワードの漏洩は文字列の総当り(ブルートフォース攻撃)で解析される事が多いといわれていますが、組み合わせる文字や文字数が多ければ多いほど、パスワードが強固になります。

例えば同じ8桁のパスワードを設定しようとした場合とくらべ、これを英数混合、大文字との組み合わせ、さらに記号文字も使った場合、単純計算で60万倍の強度になります。
もし、桁を8桁から9桁に増やせばさらに約100倍の強度です。

スーツケースについている数字3桁の鍵であれば総当りで30分くらいで開いてしまいますが、数字8桁の組み合わせよりも60万倍も複雑なパスワードだったら、コンピュータを使っても膨大な時間がかかってしまいます。これでは不正アクセス者もあきらめてしまいますよね。

パスワードを複雑なものにするのは利用者にとって面倒くさいものですが、米スプラッシュデータ社によると、「12345678」とか「iloveyou」とか「password」などにしてしまうと簡単に推測、悪用されてしまうそうですので注意が必要です。

パスワード個別に設定しよう(使いまわしはダメ!!)

いくらパスワードを強固なものにしていても、パスワードの使い回しをしていると意味がありません。
他の脆弱なサイトがハッキングされてしまった場合、攻撃者はまず、その情報を使って別のサイトにログインできるか試します(パスワードリスト攻撃)

「使い回しがよくないのはわかるけど、管理が大変だ」っていう人は、セキュリティソフトメーカーなどが出しているパスワードマネージャーを使うのも方法のひとつでしょう。

ウェブコンテンツについて

さくらのレンタルサーバでは、クイックインストールからWordPressやEC-CUBEなどのウェブアプリケーション(CMS)をインストールできます。

sakura_cms

WordPressやEC-CUBE、Joomla!といったウェブアプリケーションはとても便利です。
ウェブアプリケーションを使えば、あんまりサーバの知識がない人でも手軽にホームページの更新ができるし、プラグインで手軽に機能を拡張する事だってできます。
特に世界のホームページの25%はWordPressでできている、なんて事まで言われています。

cms_w3techs_november_2015_graph

venturebeat.comより引用
しかし、たくさんの人が使うソフトには、必ずそれを狙う輩が居ます。
特にWordPressの脆弱性はちょっと調べればたくさん出てくるので、古いバージョンを使っていると、それがそのまま誰にでもわかる不正アクセスの手段になってしまうんです。

WordPressのセキュリティを強化する

WordPressの本体やテーマ、プラグインは更新があるたびに管理画面で通知されます。
どれも管理画面に入ってしまえばワンクリックでバージョンアップできますので、こまめにチェックさえしていればいつだって安全な状態に保てるというわけです。

また、セキュリティ系のプラグインの中には何か更新があるたびに指定されたメールアドレス宛に通知してくれるものもありますので、毎日確認するのが面倒だという人は活用してみてください。
プラグインはWordPressの管理画面から追加できますが、信頼性の高い、そして頻繁に更新があるものを選ぶと外れがないと思います。

クイックインストールのWordPressの特徴

さくらのレンタルサーバのクイックインストールからインストールできるWordPressには、最初から厳選されたWordPressプラグインが用意されていますが、中でも『All In One WP Security & Firewall』はセキュリティに特化したプラグインとなっています。

ASP All In One WP Security & Firewallのダッシュボード画面

【マニュアル】WordPressのセキュリティを強化する

初期状態では有効になっていないので、是非、プラグインメニューから有効にして使ってみてください。

コントロールパネルでできるセキュリティ対策

さくらのレンタルサーバには、「国外IPアドレスフィルタ」が搭載されています。

これは何かというと、この国外IPアドレスフィルタを有効にする事で、海外からのFTPやSSH、WebDAV、それにWordPressの管理画面へのアクセスができなくなるという機能です。

ipfilter-img-010

現在、さくらのレンタルサーバで見られるパスワード漏洩や、ウェブ改ざんによる被害は、九割以上が海外からのアクセスによるものだったりします。そのため、国外IPアドレスフィルタを有効にしているアカウントでは、パスワードなどが漏れていたとしても、かなりの数の不正アクセスが未遂に終わっています。
国外IPアドレスフィルタと言ってもAWSやGoogleなどからは接続できますので、ぜひ活用してください。

最後に

不正アクセスというとニュースなどでは無駄に恐怖心を煽るような言い方をしますが、そんなのは世にある不正アクセスのほんの一部です。

確かにコンピュータを使う全ての人にとって不正アクセスは重要な問題となっています。
しかし、ちゃんとした対策をしたら、そのリスクは限りなく0に近づきます。不正アクセスで得られる利益よりも、時間や手間といったコストの方が高くつくなら、攻撃者もわざわざやる価値がありません。

ちょっとずつでも手間をかける事で未然に防げる被害の方が多いので、しっかり対策していきたいものです。

シェルスクリプトでバックアップのすすめ~初心者でもよくわかる!VPSによるWebサーバー運用講座(5)

$
0
0

VPSによるWebサーバー運用講座の連載5回目(最終回)です。
今回は、シェルスクリプトによるWebコンテンツのバックアップの方法や、OSのセキュリティアップデートについて解説します。
サーバーOSはCentOS 6.7として説明しています。

Webコンテンツの定期バックアップをしよう

VPS上にWordPressなどのCMS(コンテンツマネジメントシステム)をインストールしてWebサイトを運用しているケースは多いと思います。
こういったツールは、ファイル転送ソフトを使わなくてもブラウザだけで記事を書いたり編集したりできて便利です。しかし、作った記事コンテンツはサーバー上にしか存在せずパソコン上には残りません。何らかのアクシデントでデータベースのデータが消えてしまうと、バックアップがどこにもないので泣き寝入りするしかありません。
便利さの反面そういった落とし穴があるので、日頃からデータのバックアップを心がけておきたいものです。

ここでは、サーバーに標準付属のcronのスケジュール実行の仕組みと、シェルスクリプトを使ってデータベースのデータを含むWebコンテンツをバックアップする仕組みを構築します。

なぜシェルスクリプトを使うのか?

例えばWordPressだと便利なプラグインを使うことで、管理画面からバックアップの設定や実行を行うことができます。
BackWPupというプラグインは、ファイルやDBのバックアップを指定した時刻に取ることができます。
しかし、こういったツールに特有の不自由さもありますので、どんな場面でも便利に使えるツールではありません。

cronシェルスクリプトを使ったバックアップは、以下のような利点があります。

  1. WordPressに限らず、データベースを使うどんなCMSにも対応できる。
  2. CMS自体のバージョンアップや仕様変更にあまり影響されない。
  3. バックアップのファイルサイズや実行所要時間に制限がない。
  4. プラグインで実装でよく使われている擬似cronではないので、正確な時刻にスケジュール実行できる。
  5. Webサイトをたくさん所有しており、取得するべきバックアップ対象がいくつあっても拡張が容易で柔軟に対応できる。

逆に、シェルスクリプトによるバックアップは、cronの仕様やシェルスクリプトの知識が必要ですので、誰でも気軽に実装できるわけではありません。
少し学習が必要ですが、一度スクリプトを作ってしまうと他のサーバーや他のCMSにも再利用できますので利用価値は高いと思います。

バックアップスクリプトの仕様

以下のような仕様で、バックアップ用シェルスクリプトを作ります。

バックアップシェルスクリプト

 

  • 毎日1回cronでスケジュール実行して、コンテンツファイルとDBのバックアップファイルを作る。
  • バックアップファイルは10世代分(10日間分)保管する。
  • 最新のバックアップファイルは、別のサーバーにも1世代分だけ保存する
  • バックアップファイルの名前は
    wordpressfile-yyyymmdd_HHMM.tar.gz (WordPressを構成するファイル群)
    wordpressdb-yyyymmdd_HHMM.sql.gz (データベースのバックアップファイル)
    とし、/backup 以下に保存する。
  • 実行結果をメールで通知する。

CMS上の記事を間違って記事を消してしまったり、バージョンアップや更新に失敗してCMSが動作しなくなったときは、10世代分あるファイル・DBバックアップのいずれかからデータを戻して復旧できます。これは主にヒューマンエラーに対する備えです。
サーバーの障害でデータが失われてしまった場合は、別のサーバーに保存していた直前のバックアップファイルが役に立ちます。これはシステム障害に対する備えとなります。
バックアップの世代管理と保管場所を別の場所にすることで、トラブルに強いバックアップシステムを構築できます。

スクリプト作成の前準備

まず前準備として、別のサーバーへファイルを転送するときに必要な公開鍵認証の接続をセットアップします。
公開鍵認証を用意する理由は、別サーバーへパスワード/パスフレーズ無しでログインしファイルをコピーできるようにするためです。プログラムをスケジュール実行する場合は、別サーバーへログインするときにそのつどパスワード/パスフレーズを手で入力するわけにはいきませんので、パスワード/パスフレーズなしでアクセスする手段を用意します。

公開鍵認証によるパスワード無しscp

 

VPS側(ファイル送信側)で、公開鍵認証ファイルのペアを作成します。
rootユーザーで作業してください。

# cd
# mkdir .ssh
# chmod 700 .ssh
# cd .ssh
# ssh-keygen

ssh-keygenを実行すると、鍵を生成するための質問が表示されますが、ここではパスフレーズ無しで接続したいため、passphraseは何も入力せずリターンしてください。

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):何も入力せずリターン
Enter same passphrase again:何も入力せずリターン
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
2b:46:fb:9f:d9:ec:3d:84:c8:54:8d:5a:34:ca:xx:xx root@xxxxxx.vs.sakura.ne.jp
The key's randomart image is:
+--[ RSA 2048]----+
|          .ooo   |
|         . o=.E  |
|          o+ o   |
|          o .    |
|      . So . .   |
|     . . .o . .  |
|      + .    .   |
|     . o   = ..  |
|        ..+.+ .. |
+-----------------+

これで、/root/.ssh の下に

  1. id_rsa
  2. id_rsa.pub

の2つのファイルが作成されます。
id_rsaの権限を変更します。

# chmod 600 id_rsa

次に、コピー先の別サーバーでの設定です。
公開鍵認証は、コピー先別サーバーのvpsuserというユーザーに対して行いますので、vpsuserというユーザーを新規作成します。
コピー先別サーバーへログインし、rootユーザーで以下のコマンドを実行します。

# adduser vpsuser
# passwd vpsuser

パスワード文字列はご自身で決めてください。

vpsuserを作成後、このユーザーでコピー先別サーバーにログインし、公開鍵を置くため次のコマンドを実行します。

$ mkdir .ssh
$ chmod 700 .ssh
$ cd .ssh

authorized_keysというファイルを作成します。
先ほどコピー元サーバーで作成したid_rsa.pubの中の文字列をこのファイルに転記します。
以下のようなイメージになります。

$ vim authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwoiyK4GkblZmYzW0rzcVipGROU7rWDhdFJDYwqswEICVL5Q5121T7YujJD0Cc/twhH7VUbwSRGggnen4GgoUT9EVDDhWbOv4WENNRdsTJEGa4q76oeIwGxFKXgaJOUbzQVwRCOyLmkaAIDcm0o77Qok1vOitZ6M8jnzSx2PG+atFHhxIomlKIJjMNexdKUTeUf/COEAu7kvpPK8kerWzuTtIPm8qDNukVF6h2aVV5lnhew/FJBjL+X4uRbc8hBg5U3QA11N+fx6SqTF0or7zRPc/PQbfyTSb+CaOZFVI2yInOCxaar38vcGVGRvl/rervyPGu+7kJn0rUV10a0Afuw== root@xxxxxxxxxxxx.vs.sakura.ne.jp

vimを保存して終了し、authorized_keysの権限を600(本人のみ書込可能)にしておきます。

$ chmod 600 authorized_keys

以上で、公開鍵認証の設定ができました。
試しに、sshでパスワード無しで接続できることを確認してみましょう。
コピー元サーバーから、rootユーザーで以下のsshコマンドを実行します。

# ssh -i /root/.ssh/id_rsa vpsuser@(コピー先別サーバーのIPアドレス)

初回接続時に

Are you sure you want to continue connecting (yes/no)?

のようなメッセージが出ますが、’yes‘とタイプすれば次回以降パスワード無しでログインできるようになります。

これで、パスワード無しでコピー先別サーバーへ接続する準備が整いました。
もし、上記のssh コマンドでパスワードが求められてしまう場合は、コピー元/コピー先の.sshディレクトリの権限が正しいか、aurhorized_keysの権限が正しいかなどを確認してみてください。

公開鍵認証についてもっと詳しく知りたい方は以下の記事を参考にしてください。
「よく分かる公開鍵認証」~初心者でもよくわかる!VPSによるWebサーバー運用講座(2) – さくらのナレッジ

次に、コピー元サーバーでバックアップファイルを保存しておくディレクトリを作成します。
/backup というディレクトリをルートディレクトリ以下に作成しておきます。

# mkdir /backup

以上で前準備は完了です。

次に、以下に示すバックアップシェルスクリプトを
/usr/local/bin/cmsbackup.sh
として保存します。
青色の部分を自分の環境に合わせて変更してください。

#!/bin/bash
datestr=`date +%Y%m%d-%H%M%S`
STATUS=0

# 関数: scpを行う
# $1 コピー元ファイル名(フルパス)
# $2 コピー先ファイル名
function scpfile(){
    eval "scp -i /root/.ssh/id_rsa $1 vpsuser@IPアドレス:~/$2"
    if [ $? -ne 0 ]
    then
	echo "[ERROR]scp error. file=$1"
	STATUS=1
    fi
    return
}

# 関数: ファイルの削除を行う。
# $1: 削除対象のファイルパス(前方一致)
# 10世代分のファイルを残し、それより古いファイルは削除します。
function deletefile(){
    CNT=0
    for file in `ls -1t ${1}*`   # 更新日付が新しい順にファイル名のリストを作る
    do
	CNT=$((CNT+1))
        
	if [ ${CNT} -le 10 ]  # 10世代より過去のバックアップは削除する
        then
	    continue
        fi
	eval "rm ${file}"
    done
    return
}

# MAIN処理
# /var/www/html以下のファイルを
# /backup/wordpressfile_YYYYMMDD-HHMMSS.tar.gzとして保存します。
eval "tar czf /backup/wordpressfile_${datestr}.tar.gz /var/www/html"
if [ $? -ne 0 ]
then
    echo "[ERROR]tar error."
    STATUS=1
fi

# データベースのデータをエクスポートして
# /backup/wordpressdb_YYYYMMDD-HHMMSS.sql.gzとして保存します。
# 青色の部分を修正してください。
eval "mysqldump -u root -ppassword データベース名 |gzip -c > /backup/wordpressdb_${datestr}.sql.gz"
if [ $? -ne 0 ]
then
    echo "[ERROR]mysqldump error."
    STATUS=1
fi

# 10世代より前のファイルを削除します。
deletefile "/backup/wordpressfile_"  # WordPressファイルの削除
deletefile "/backup/wordpressdb_"  # データベースバックアップの削除

# 最新のバックアップファイルを別のサーバーへコピーします。
scpfile /backup/wordpressfile_${datestr}.tar.gz wordpress.tar.gz
scpfile /backup/wordpressdb_${datestr}.sql.gz wordpressdb.sql.gz

# 実行結果をメールで通知します。
# メールアドレスを設定してください。
if [ ${STATUS} -ne 0 ]
then
    SUBJECT="[ERROR]cms backup report"
else
    SUBJECT="[SUCCESS]cms backup report"
fi
echo "" | mailx -s "${SUBJECT}" "mail@example.com"

exit ${STATUS}

もし、vimでテキストを貼り付けたときに日本語が文字化けする場合は、
ホームディレクトリに .vimrc ファイルを作り、

set encoding=utf-8

と書いておけば文字化けは解消すると思います。

このスクリプトに実行権限をつけ、実行します。

# chmod 755 /usr/local/bin/cmsbackup.sh
# /usr/local/bin/cmsbackup.sh

うまく動作しましたでしょうか?
もし、エラーが出るなどしてうまく動かない場合は、以下のコマンドで実行すると処理をトレースできますのでデバッグに役立ちます。

# bash -x /usr/local/bin/cmsbackup.sh

バックアップ処理をスケジュール実行する

次に、毎日深夜3時にこのバックアップ処理を実行するようスケジュールしましょう。
スケジュール設定はcronという仕組みによって行います。設定ファイルは/etc/crontabです。

# vim /etc/crontab

設定ファイルに以下の行を追加して保存します。追加する場所はどこでも構いません。

0 3 *  *  * root /usr/local/bin/cmsbackup.sh

これで毎日深夜3時にroot権限で/usr/local/bin/cmsbackup.shが実行されるようになります。

設定内容の意味は以下のようになります。
crontab解説

cronのスケジュール設定についてより詳しく知りたい方は、以下を参考にしてください。
◇プログラムを予約して実行する◇初心者のためのLinuxサーバー構築講座

トラブルが起きた時のリストア

以上でCMSのバックアップの仕組みが構築できました。
では、万が一トラブルが発生して、バックアップファイルからデータを復旧しなければならなくなった時はどうすればよいでしょうか?
バックアップからの復旧に関するコマンドを解説します。

CMS内のファイルや、投稿した画像ファイルなどが失われてしまいそれを復旧したい場合は、コンテンツのバックアップファイルを解凍・展開してそれを cpコマンドで本来の場所に戻します。
解凍コマンドは圧縮したときのコマンドと同じくtarコマンドを使います。オプションは解凍して展開するオプションxzfになります。

# cd /backup
# tar xzf wordpressfile_YYYYMMDD-HHMMSS.tar.gz

実行すると同じディレクトリにvar/www/html/… という階層のディレクトリが作成されますので、必要なファイルを /var/www/html の下にコピーしてください。

データベースの復旧は少し複雑です。
まずはgzipコマンドでファイルを解凍します。

# gzip -d wordpressdb_YYYYMMDD-HHMMSS.sql.gz

次に、解凍されたsqlファイルをデータベースにインポートしますが、もしこの時点でインポート先のデータベースも失われてしまっている場合は、データベースを先に作成します。
ここでは、wordpressdbというデータベースを作成しています。

# mysqladmin -u root -p create wordpressdb

パスワードを求められますので入力してください。

そして、データをmysqlコマンドでインポートします。

# mysql -u root -p wordpressdb < wordpressdb_YYYYMMDD-HHMMSS.sql

こちらもパスワードを求められます。

以上でリストアできました。

これからの運用で気をつけること

これでひと通りのVPSのサーバー運用編は終わったわけですが、今後も安定してVPSを使い続けていくには気をつけておくべきことがあります。
VPSは、レンタルサーバーと違ってサーバーの面倒を自分で見なければなりません。たまに、サーバーのセキュリティ脆弱性の問題が発生することがありますので、そういう情報を敏感にキャッチして適切な対処ができるようにしましょう。

VPSにインストールされているソフトウェパッケージのバージョンの確認は、以下のコマンドで確認できます。

# yum list installed

以下のコマンドは、セキュリティアップデートがあるソフトウェアのみをアップデートするコマンドです。定期的に実行すると良いでしょう。

# yum --security update

さくらのVPSに関する重要なお知らせは以下に掲載されます。特にソフトウェア脆弱性に関するお知らせが出た場合はすみやかに対処しましょう。
お知らせ: | さくらインターネット
http://www.sakura.ad.jp/news/sakurainfo/newsindex.php

脆弱性対策情報ポータルサイトJVNに、緊急で必要な脆弱性対応などが掲載されるので、こちらもあわせてご覧ください。
Japan Vulnerability Notes
本連載は以上です。

5回にわたりお届けした「VPSによるWebサーバー運用講座」、いかがでしたでしょうか。
一度構築したサーバーを長く使い続けるためにも、運用にも気を配って末ながいおつきあいをしていただければと思います。

進む常時SSL化とその落とし穴

$
0
0

WebサイトのすべてのページをSSL暗号化する「常時SSL化」が急速に進んでいます。Webページとクライアント間の通信をSSL暗号化することで、通信を盗聴しても内容がわからないようにできます。そのため、これまではショッピングサイトの決済ページや企業の採用応募ページ、記名式の問い合わせページなど、個人情報やクレジットカード情報などを入力するページがSSL暗号化されていました。

常時SSL化が進んでいる背景には、それを推進するGoogleがSEOにおいてSSL暗号化サイトをより評価すると発表したことや、SSLサーバ証明書の種類が増えて、より安価な証明書を使用できるようになったこと、さらには「Let’s Encrypt プロジェクト」など無料SSLプロジェクトの台頭などが挙げられます。もちろん、モバイル端末の増加や国家に対する盗聴の不安といった背景も考えられます。

また暗号化の観点では、2016年から2017年にかけてアルゴリズムが「SHA-1」から「SHA-2」へ移行するという大きな動きがあります。CPUの高速化などによって、SHA-1アルゴリズムの暗号は容易に解読されてしまうようになったため、より強固なSHA-2を最低限の暗号化アルゴリズムにするというものです。例えばマイクロソフトでは、SHA-1を2017年以降は使用しないとしていますし、さらなる前倒しも検討しています。

マイクロソフトのセキュリティアドバイザリ

マイクロソフトのセキュリティアドバイザリ
https://technet.microsoft.com/ja-jp/library/security/2880823.aspx

マイクロソフトの動きに合わせ、さまざまなCA(認証局)もSHA-2移行を表明しており、またブラウザベンダーもSHA-2移行を奨励しています。例えばGoogleでは、「Chrome」におけるアドレスバーの警告表示を強化し、SHA-1で暗号化されているページの場合は「×印」や「斜線」が表示されるようになります。これはMozillaの「Firefox」でも同様です。

SSLサーバ証明書だけでなく、2016年はコードサイニング証明書でも大きな動きがあります。コードサイニング証明書とはアプリケーションファイルの発行元を証明するもので、ファイルが改ざんされていないことも証明します。しかしコードサイニング証明書にも厳格な認証を行わないものがあり、マルウェアを埋め込むなど攻撃者に悪用されるケースがあります。

このためマイクロソフトは、「Internet Explorer 9」以降(OSでは「Windows8」以降)にSmartScreen機能を搭載し、同社の持つ動的なリストなどを照合するようになりました。特に厳格な認証が行われるEVコードサイニング証明書では、インストール時に警告が表示されることがありません。一方でドライバソフトの場合、「Windows 10」以降のOSではマイクロソフトのドライバ署名(WHQL署名)がないと原則的にインストールできません。

SSL通信の増加によりセキュリティ機器の負荷増大も

暗号化が進んでいる一方で、ここ最近はSSLの脆弱性が立て続けに発見されています。特に「OpenSSL」に発見された「Heartbleed」の脆弱性は攻撃も数多く行われ、大きな話題になりました。SSLの脆弱性は、古くは「BEAST」や「BREACH」、最近では「POODLE」「FREAK」「DRAWN」などの脆弱性および攻撃が発覚しています。

現在のところ、もっとも安全な暗号化は「TLS 1.2」ですが、これのみとすると一部のいわゆるガラパゴス携帯でサイトを閲覧できなくなるケースもあり、悩ましい状況になっています。

なお、「QUALYS SSL LABS」(https://www.ssllabs.com/ssltest/)というサイトでは、URLを入力することでSSLの安全性をチェックすることができます。

「QUALYS SSL LABS」でFacebookをチェックした結果

「QUALYS SSL LABS」でFacebookをチェックした結果
https://www.ssllabs.com/ssltest/

さらに、最近話題となっているのがSSL通信の増加によるセキュリティ機器の負荷の増大です。IPSやファイアウォールなどといった一般的なセキュリティ機器は、SSL通信を一度復号化しないとチェックすることができません。この復号化にCPUリソースが大きく消費されてしまい、パフォーマンスが大幅に低下します。その割合は「次世代IPS」と呼ばれる製品であっても処理能力が4分の1に低下するといいます。

この状況に対応するには、処理能力の高いセキュリティ機器を導入するか、SSLの終端後に機器を設置するといった対策が必要になります。また仮想化環境でのSSLオフライン化や、DMZでの処理なども提案されています。

常時SSL化はセキュリティの面では非常に有効ですし、新たなプロトコル「HTTP/2」では従来の「HTTPS」よりも高速な処理が可能になると言われています。これからはSSL通信への対策も重要になりそうです。

2016.7.14 Drupal 7モジュールの深刻なセキュリティアップデート

$
0
0

7/14 AM1:00 Drupal 7 のモジュールで、深刻な脆弱性が公開されました。
(Drupal 6は、サポート対象から外れているため公開されていませんが、同じ問題を含んでいる可能性があります)

RESTful Web Searvices, Coderモジュールが Highly Critical、Webform Multiple File UploadがCriticalです。

いずれも、任意のPHPコードが実行できるため、サイトの改ざんやデータ取得などができます。利用されている場合は、至急、アップデートをお願いします。

今回は、前日に深刻な脆弱性の公開を行うというアナウンスがあり、1日後に公開した形です。Drupal利用者に事前に告知されて注視を促してからの発表となっており、それだけ重大な問題だということになります。

より詳細な内容は、Drupal歴9年の スタジオ・ウミの大野さんのブログが大変参考になりますので、ご紹介させていただきます。
大野さん、ありがとうございます!

皆さま、使っていないという思い込みがあったり、インストールして使っていないということもありますので、サイトをチェックすることをお勧めします。


「ドローン」を取り巻くサイバー脅威とは

$
0
0

2015年にニュースを騒がせたもののひとつに「ドローン」があります。ドローンは「無人航空機」を指すため、広義では米軍が実戦に投入している「UAV(無人偵察機)」なども含まれます。国土交通省では「構造上、人が乗ることができないもののうち、遠隔操作または自動操縦により飛行させることができるもの」などと定義し、農業用のミニコプターも含まれるとしています。しかし、ここでは最近話題になっているラジコンのマルチコプターをドローンと呼ぶことにします。

ドローンは、4個、6個、あるいは8個のプロペラで構成されます。プロペラはすべて同一方向を向いていますが、それぞれのプロペラの回転速度を調整することで、前進や後退、回転、オーバル飛行などが可能になっています。もちろんホバリングも可能で、宙返りもできると言われています。このため、ヘリコプターのようにプロペラのピッチ(角度)を変更するような機能は搭載されていません。

サイズも多彩で、手のひらに載るような小型のものから、映画の撮影にも使用できるような大型のものまであります。操作はラジコン飛行機などのようなプロポを使いますが、ハイグレードの機種になるとスマートフォンによる操作にも対応します。そのようなハイグレード機種になると、何も操作されない状態になると自動的にホバリングしたり、着陸する機能が搭載されていたり、「帰還」ボタンを押すとコントローラのある場所まで自動的に帰還する機能が搭載されています。

小型から中型の機種は価格帯も数千円から2万円弱と安価ですが、ジャイロやセンサ類などが簡略化されており、ハイグレード機種のようなホバリングや自動帰還の機能は搭載されていません。そのため非常に軽量で高い機動性を発揮しますが、横風に弱くコントロールも難しくなっています。それでもカメラを搭載しているので趣味程度の空撮ができます。2015年に多発した落下事故は、こういったホビーライクの機種であったと推測できます。

とりわけ首相官邸の屋上に落下したドローンは、土の入った容器や発煙筒が取り付けられており、ドローンによるテロの可能性を示唆していました。プロ向けの大型ドローンになると、人が多い場所に落下するだけでもケガ人が出てしまう可能性が高く、国土交通省においても大型のドローンは飛行可能地域が厳しく規制される方向になっています。

多彩なタイプがラインナップされる「ドローン」
多彩なタイプがラインナップされる「ドローン」

操作アプリの乗っ取りでドローンを自由に操る

落下などといった物理的な問題のほかに、ドローンではサイバーセキュリティも重要です。まず、スマートフォンをコントローラにする機種では、OSの脆弱性を悪用した乗っ取りが考えられます。これには脆弱性を悪用する偽アプリなどをインストールさせる方法や、通信に割り込む方法、あらかじめドローンの操作アプリを細工しておくなどの方法があります。乗っ取りに成功すると、攻撃者は遠隔からドローンを自由に操作できるようになります。

こういった不正アプリなどによる乗っ取りは、すでに多くの研究者が実証しており、ドローンを介してPCに感染するマルウェアも発表されています。もうひとつは、ドローンを標的としたDoS攻撃です。ドローンの操作に使用する無線の周波数帯は、Wi-Fiの周波数帯と重なっています。このため、たとえば複数のドローンが飛行している場所で、複数の人間がスマートフォンで一斉にテザリングを開始すれば、帯域が圧迫されてドローンの制御用の通信がダウンする可能性があるのです。

ドローンはこれからも進化を続け、災害時の物資輸送をはじめ、報道や物流、橋や高速道路、ダムなどの点検作業、エンターテインメントなど幅広い分野での活躍が期待されます。また、現時点でドローンは中国製が多く、構成部品は日本製が多いものの、修理時などは中国に送り返されてしまいます。ドローンの制御ソフトにスパイウェアがある可能性もゼロとは言えませんので、国産ドローンの登場も待たれています。ドローンに関する複数の団体も立ち上がってきましたので、今後もドローンの動向を注意深く意識したいところです。

ドローンの脅威には「無線経由」と「アプリ経由」の攻撃がある
ドローンの脅威には「無線経由」と「アプリ経由」の攻撃がある

VPCルータとのサイト間VPNを設定する上でのポイント~RTX1210を例に~ – 「さくらのクラウド入門」(7)

$
0
0

こんにちは、さくらインターネット クラウドチームの大喜多です。

ws000977

VPCルータのサイト間VPNに関するお問い合わせをよくいただくようになりました。特に多くお問い合わせをいただくのがYAMAHA製ルータ「RTXシリーズ」の設定についてです。そこで今回は実際にRTX1210のコンフィグをもとに、VPN接続できない場合のチェックポイントについて解説致します。

今回のネットワーク構成

今回例として取り上げるネットワーク構成は以下の通りです。
ws000981

YAMAHAルータにてVPCルータとサイト間VPNが張れないというお問い合わせをいただいた際に、まずお客様に「YAMAHAルータのconfig全体(show configコマンドで出力されたものすべて)を送ってください」とお願いします。これは、VPN設定部分のconfigだけでは問題の切り分けができないことを意味しています。チェックポイントは大きく分けて3つありますので、順に説明してまいります。

VPCルータのサイト間VPN設定

ws000982

RTX1210のコンフィグ

長くなりますが、チェックポイントを明確にするために全文掲載しています(コメント部分は省略しています)

# RTX1210 Rev.14.01.09 (Tue Jun 16 00:57:37 2015)
<中略>
ip route default gateway 59.106.69.97
ip route 192.168.3.0/24 gateway tunnel 1
ip filter source-route on
ip filter directed-broadcast on
ip lan1 address 192.168.1.102/24
ip lan2 address 203.0.113.102/27

ip lan2 secure filter in 300010 300020 200000 200001 200002 200003 200020 20002
1 200022 200023 200024 200025 200030 200032 200040 200042 60000 60001 60002 600
03 60004 60005
ip lan2 secure filter out 200010 200011 200012 200013 200020 200021 200022 2000
23 200024 200025 200026 200027 200099 dynamic 200080 200081 200082 200083 20008
4 200098 200099

ip lan2 nat descriptor 1

tunnel select 1
 ipsec tunnel 101
  ipsec sa policy 101 1 esp aes-cbc sha-hmac
  ipsec ike always-on 1 on
  ipsec ike encryption 1 aes-cbc
  ipsec ike group 1 modp1024
  ipsec ike hash 1 sha
  ipsec ike keepalive use 1 on dpd 15 2
  ipsec ike local address 1 192.168.1.102
  ipsec ike local id 1 192.168.1.102
  ipsec ike pfs 1 on
  ipsec ike pre-shared-key 1 text abcde123
  ipsec ike remote address 1 198.51.100.221
  ipsec ike remote id 1 198.51.100.221
  ipsec auto refresh 1 on
 ip tunnel mtu 1280
 ip tunnel tcp mss limit auto
 tunnel enable 1


ip filter 1010 reject * * udp,tcp 135 *
ip filter 1011 reject * * udp,tcp * 135
ip filter 1012 reject * * udp,tcp netbios_ns-netbios_ssn *
ip filter 1013 reject * * udp,tcp * netbios_ns-netbios_ssn
ip filter 1014 reject * * udp,tcp 445 *
ip filter 1015 reject * * udp,tcp * 445
ip filter 1020 reject 192.168.1.0/24 *
ip filter 1030 pass * 192.168.1.0/24 icmp
ip filter 1040 pass * * tcp telnet *
ip filter 1050 pass * * tcp www *
ip filter 2000 reject * *
ip filter 3000 pass * *
ip filter 60000 pass-log * 192.168.1.100 tcp * 60000
ip filter 60001 pass-log * 192.168.1.101 tcp * 60001
ip filter 60002 pass-log * 192.168.1.102 tcp * 60002
ip filter 60003 pass-log * 192.168.1.103 tcp * 60003
ip filter 60004 pass-log * 192.168.1.104 tcp * 60004
ip filter 60005 pass-log * 192.168.0.50 tcp * 60005
ip filter 100000 reject * * udp,tcp 135 *
ip filter 100001 reject * * udp,tcp * 135
ip filter 100002 reject * * udp,tcp netbios_ns-netbios_dgm *
ip filter 100003 reject * * udp,tcp * netbios_ns-netbios_dgm
ip filter 100004 reject * * udp,tcp netbios_ssn *
ip filter 100005 reject * * udp,tcp * netbios_ssn
ip filter 100006 reject * * udp,tcp 445 *
ip filter 100007 reject * * udp,tcp * 445
ip filter 100099 pass * * * * *
ip filter 200000 reject 10.0.0.0/8 * * * *
ip filter 200001 reject 172.16.0.0/12 * * * *
ip filter 200002 reject 192.168.0.0/16 * * * *
ip filter 200003 reject 192.168.1.0/24 * * * *
ip filter 200010 reject * 10.0.0.0/8 * * *
ip filter 200011 reject * 172.16.0.0/12 * * *
ip filter 200012 reject * 192.168.0.0/16 * * *
ip filter 200013 reject * 192.168.1.0/24 * * *
ip filter 200020 reject * * udp,tcp 135 *
ip filter 200021 reject * * udp,tcp * 135
ip filter 200022 reject * * udp,tcp netbios_ns-netbios_ssn *
ip filter 200023 reject * * udp,tcp * netbios_ns-netbios_ssn
ip filter 200024 reject * * udp,tcp 445 *
ip filter 200025 reject * * udp,tcp * 445
ip filter 200026 restrict * * tcpfin * www,21,nntp
ip filter 200027 restrict * * tcprst * www,21,nntp
ip filter 200030 pass * 192.168.0.0/16 icmp * *
ip filter 200031 pass * 192.168.1.0/24 established * *
ip filter 200032 pass * 192.168.0.0/16 tcp * ident
ip filter 200033 pass * 192.168.1.0/24 tcp ftpdata *
ip filter 200034 pass * 192.168.1.0/24 tcp,udp * domain
ip filter 200035 pass * 192.168.1.0/24 udp domain *
ip filter 200036 pass * 192.168.1.0/24 udp * ntp
ip filter 200037 pass * 192.168.1.0/24 udp ntp *
ip filter 200040 pass * 192.168.1.102 tcp * telnet
ip filter 200042 pass * 192.168.1.102 tcp * 22
ip filter 200099 pass * * * * *
ip filter 300010 pass 198.51.100.221/32 192.168.1.0/24 udp 500
ip filter 300020 pass 198.51.100.221/32 192.168.1.0/24 esp
ip filter 500000 restrict * * * * *
ip filter dynamic 100 * * ftp
ip filter dynamic 101 * * www
ip filter dynamic 102 * * domain
ip filter dynamic 103 * * smtp
ip filter dynamic 104 * * pop3
ip filter dynamic 106 * * tcp
ip filter dynamic 107 * * udp
ip filter dynamic 200080 * * ftp
ip filter dynamic 200081 * * domain
ip filter dynamic 200082 * * www
ip filter dynamic 200083 * * smtp
ip filter dynamic 200084 * * pop3
ip filter dynamic 200098 * * tcp
ip filter dynamic 200099 * * udp

nat descriptor type 1 masquerade
nat descriptor timer 1 600
nat descriptor timer 1 tcpfin 5
nat descriptor address outer 1 203.0.113.102
nat descriptor address inner 1 auto
nat descriptor masquerade incoming 1 reject 

nat descriptor masquerade static 1 9 192.168.1.102 udp 500
nat descriptor masquerade static 1 10 192.168.1.102 esp

nat descriptor masquerade session limit 1 1 500
dns server 8.8.8.8
dns private address spoof on
dashboard accumulate traffic on

nat descriptor masquerade static

まず最初に確認するポイントですが、configの下の方、緑色の文字の部分「nat descriptor masquerade static」の確認を行います。IPsecを張るためにはUDP500番ポートとESPの通信を許可しておく必要があります。また、重要なのはIPアドレスの部分です。理由は後述します。


nat descriptor masquerade static 1 9 192.168.1.102 udp 500
nat descriptor masquerade static 1 10 192.168.1.102 esp

ipsec ike local address/ipsec ike local id

config中央部分、青色の文字の部分がIPsecの設定です。ここで確認するのは「ipsec ike local address/ipsec ike local id」の部分です。


  ipsec ike local address 1 192.168.1.102
  ipsec ike local id 1 192.168.1.102

IPsecで接続する相手に対して自分のアドレスとidを広告しています。

「nat descriptor masquerade static」と「ipsec ike local address/ipsec ike local id」で設定されているIPアドレスは、必ず同一である必要があります。今回のケースでは、いずれもプライベートIPアドレスである「192.168.1.102」が設定されており、VPCルータの対向IDも「192.168.1.102」となっているので、問題ありません。お問い合わせいただくケースで最も多いのは、この部分のIPアドレスが不一致になっているケースがほとんどです。この例では全てプライベートIPアドレスになっていますが、VPN設定のIPアドレスがグローバルIPアドレスになっており、正しくIPsecが張れないということが多いのです。この部分は

・いずれもRTX1210のプライベートIPアドレス
・いずれもPTX1210のグローバルIPアドレス

のいずれかで揃っている必要がありますので、うまく接続ができない場合はまずこの部分をご確認ください。

secure filterの確認

これは稀な例ですが、フィルタによってUDP500番ポートとESPの通信が遮断されているケースがあります。

今回の例では、WAN側インタフェース(LAN2)に入ってくる(in)の部分でプライベートIP宛ての通信がrejectされるようになっていたため、UDP500番ポートとESPの通信のみを明示的に許可するfilterを追加しています。


ip filter 300010 pass 198.51.100.221/32 192.168.1.0/24 udp 500
ip filter 300020 pass 198.51.100.221/32 192.168.1.0/24 esp

また、ip filterの行が大量にありますが、全てのfilterが有効になっているわけではありません。ip lan2 secure filter in および ip lan2 secure filter outの部分でフィルタ番号が記載されているものが、実際にインタフェースに適用されているフィルタになります。今回のケースでもip filterの行はあるものの適用されていないフィルタがいくつかあります。

まとめ

今回はRTX1210の実際のconfigをもとに、サイト間VPNが失敗する場合にチェックするべきポイントについて取り上げました。また、こちらのサイト間VPNのマニュアルにはVPCルータのIPsecパラメータや他機種の設定例なども記載しておりますので、併せてご確認ください。

また、2017年1月17日に「さくらのクラウド体験ハンズオン VPN編」を開催致します。当日は実際にVPCルータとRXT1210を用いてサイト間VPNを構築するデモンストレーションと、VPCルータとL2TP/IPsecによるリモートアクセスVPNを張るハンズオンを予定しています。ぜひご参加ください。

不正アクセスからサーバを守るfail2ban。さくらのクラウド、VPSで使ってみよう!

$
0
0

こんにちは。さくらインターネットの前佛です。
今回は、サーバのログファイルを自動スキャンして、悪意のある SSH 通信を自動遮断するツール fail2ban の概要と使い方をご紹介します。

日々、不正アクセス

インターネット上のサーバは、SSH や HTTP など、公開しているポートに対する不正アクセスの試みに日々晒されています。不正アクセスは悪意を持った人からの攻撃だけではありません。マルウェアやワームなど、いわゆるボットからの攻撃にも日々晒されているのです。

そのため、誰でもアクセス可能なパブリックな環境にサーバを公開する場合、セキュリティに対して細心の注意を払う必要があります。

たとえば、近年話題になっている Linux 向けのマルウェアとしては XOR.DDoS が有名です。これは root ユーザのパスワードに対する総当たり攻撃(broute-force attach)を試みます。攻撃対象は公開されている SSH ポートに対してであり、もしも不正なログインが成功すると、自動的にマルウェアの構築あるいはダウンロードが試みられます。そして、不正ログインできたサーバを新たな攻撃元として、別のサーバに対する攻撃を繰り返していくものです。

このような攻撃に対しての備えは、理想としてはファイアウォールやルータ等を導入し、フィルタリング・ルールを厳格に運用すべきでしょう。しかしながら、環境によってはそのような対策を行えないこともあります。

具体的には SSH やメールの送受信など、複数のユーザが複数の環境から接続する必要性がある場合です。このような場合、SSH であればパスワードによる認証を防止する(公開鍵方式の認証しか受け付けない)や、root によるログインを禁止して対策をとる方法があります。

しかし、インターネットに公開しているサーバは SSH だけではありません。ウェブサイトを公開している場合であれば、ブログの管理画面のインターフェイスに対する不正なアクセス、あるいはデータベースの公開ポートに対する攻撃の兆候も日々見受けられるでしょう。

適切にセキュリティの設定を施していたとしても、サーバの再起動によって設定がリセットされたり、あるいは別の環境にシステムを移行したとき、思わず設定漏れにより攻撃に晒されてしまうリスクもあります。

このような脅威に対して、私たちサーバ管理者ができる対策の1つが、fail2ban の導入です。

不正攻撃のログ痕跡からアクセスを自動遮断する fail2ban

fial2ban はログファイルをスキャンし、悪意のある攻撃や兆候を元に、攻撃元の IP アドレスを自動で遮断(ban)するソフトウェアです。オープンソース・プロジェクトとして開発されており、GNU GPL v2 ライセンスの下、誰でも自由に使うことができます。

fail2ban の仕組み

fail2ban はクライアント・サーバ型のシステムであり Python 言語で書かれています。fail2ban-server(サーバ)はサーバ内に常駐し、対象のログファイル群を監視します。このサーバに対して設定や操作をするのが、fail2ban-client(クライアント)コマンドです。

fail2ban-1

fail2ban-serverはデーモンであり、ログファイル中の悪意のある攻撃や兆候を監視します。具体的な悪意のある兆候とは、特定のホストからの次のような行動です。

– パスワード認証の失敗が短時間に大量に続く
– exploits の実行と思われる兆候

これらの監視対象は /var/log/secure や /var/log/audit.log などのシステムログだけではありません。設定によって Apache のログファイル access_log なども参照します。fail2ban がログの何を監視するかの設定は、フィルタ(filter)と呼ぶ正規表現の文字列で予め指定しておきます。

そして、特定の攻撃の兆候を fail2ban が発見すると、アクション(action)と呼ばれる自動処理を実行します。この時、ファイアウォール・ルール(iptables等)を変更してアクセスの自動遮断や各種の設定変更、メール通知などを自動的に行うことができます。

fail2ban の設定とは、これらフィルタとアクション(1つまたは複数)を組みあわせたジェイル(jail)と呼ばれた指定を行うことです。この設定ファイル群は /etc/fail2ban/ 以下のディレクトリにあります。

覚えておいた方が望ましい注意点としては、ログの監視とアクションの実行までにはタイムラグがあることです。リアルタイムに状況を把握して反映するのではなく、数秒から数十秒かかる場合もあります(ログファイルによって差があります)。

以降では具体的な設定例を見ていきましょう。

SSH のフィルタ設定

さくらのクラウド、さくらのVPS(※)では fail2ban が標準で組み込まれています。特に何もしなくても、サーバを立ち上げた直後から SSH に対する攻撃の検出と、自動遮断機能が有効です。XOR.DDoS のような攻撃があれば、一定期間(デフォルトでは10分)は iptables によって接続できなくなります。
(※さくらのVPSでは、CentOS6/7を標準インストール機能でインストールした場合にfail2banが適用されます。CentOS6/7の標準インストール機能についてはこちらをご覧ください。)

この設定が有効化されているのは、 /etc/fail2ban/jail.conf 中の以下のファイルです。

bantime = 600
findtime = 600
maxretry = 5

– bantime … 対象ホストを自動遮断(ban)する時間です。デフォルトは 600 秒(10分)です。
– findtime と maxretry … ログファイルを findtime で指定した時間、攻撃とみられる兆候が maxretry 回続けば自動遮断します。デフォルトでは 600 秒で5回の兆候があれば、自動遮断します。

このデフォルト値を変更したい場合は、設定ファイルの変更後、fail2ban の設定再読み込みを行います。

systemctl の例(CentOS7, Ubuntu 16.04 等):

# systemctl reload fail2ban

initの例:

# service fail2ban restart

また、ジェイルの設定は /etc/fail2ban/jail.d/ 以下ディレクトリにあるファイルで有効になっています。さくらのクラウド、さくらのVPSでは local.conf の中で以下の設定があるためです。他にもジェイルのルールを追加したい場合は、このファイルの中に設定を追加するか、あるいは別の設定ファイルを作成します。

[DEFAULT]
 banaction = firewallcmd-ipset
 backend = systemd

[sshd]
 enabled = true

fail2ban のフィルタやアクションが有効かどうかは、ログファイル /var/log/fail2ban.log をご覧ください。これは SSH に対する攻撃(実際には、ログイン失敗の記録を /var/log/secure から検出)が5回以上続いたログを検出したため、接続元(xxx.xxx.xxx.xxx は IP アドレスです)に対する自動遮断(ban)が有効化されています。

2016-09-19 05:01:22,382 fail2ban.filter [1134]: INFO [sshd] Found xxx.xxx.xxx.xxx
2016-09-19 05:01:22,443 fail2ban.filter [1134]: INFO [sshd] Found xxx.xxx.xxx.xxx
2016-09-19 05:01:22,504 fail2ban.filter [1134]: INFO [sshd] Found xxx.xxx.xxx.xxx
2016-09-19 05:02:51,918 fail2ban.filter [1134]: INFO [sshd] Found xxx.xxx.xxx.xxx
2016-09-19 05:02:51,979 fail2ban.filter [1134]: INFO [sshd] Found xxx.xxx.xxx.xxx
2016-09-19 05:02:52,043 fail2ban.filter [1134]: INFO [sshd] Found xxx.xxx.xxx.xxx
2016-09-19 05:02:52,256 fail2ban.actions [1134]: NOTICE [sshd] Ban xxx.xxx.xxx.xxx

自動遮断(ban)されたあと一定期間後に自動回復します。長期的に遮断したい場合などは、必要に応じて、bantime や findtime 値を変更下さい。

補足:SSH サーバをより安全にするために

fail2ban の役割は、あくまでも外部からの攻撃に対して自動的に遮断するものです。それ以前に、サーバを不正な攻撃から守るために必要な設定方法をご紹介します。

TCP Wrapper を使うアクセス制御

Linux の sshd は、標準で TCP wrapper を使ったアクセス制御を使えます。iptables のように IP アドレスやネットワークを指定した遮断と許可だけでなく、ホスト名やドメイン名で制御できるのが特徴です。

設定に使うファイルは /etc/hosts.allow と /etc/hosts.deny の2つです。基本的には hosts.deny に拒否するサービスとネットワークを記述し、接続を許可したい環境を hosts.allow に書く流れです。

例えば ***.example.jp というホスト名に対してのみ SSH 接続を許可する設定を考えてみましょう。 hosts.allow ファイルには、次のような記述を追加します。特定のホストまたはネットワークに対する SSH を許可するには、「 sshd: <接続元>」の記述を追加します。

sshd: .example.jp
sshd: <ipアドレス>

これだけでは制限は有効にはなりません。 hosts.deny には、次のように sshd に対する接続を拒否する設定を追加します。

sshd: all

POP3 サーバやその他 TCP Wrapper を使うアプリケーションが無い場合は、次のように全てのサービスを拒否する方法も1つです。

all: all

この記述を追加し、ファイルを保存した瞬間から設定が有効になります。特に sshd の再起動等は必要ありません。

SSH サーバの設定変更

よりセキュリティを高めるには、特に必要が無い限り、SSH サーバ側で root での SSH ログイン禁止と、公開鍵認証以外のログインを禁止することをお勧めします。これらの設定を有効にするには SSH サーバの設定ファイル /etc/ssh/sshd_config を編集します。

PermitRootLogin no
UseLogin no

設定を有効にするには SSH サーバの再起動が必要です。

systemctl の例(CentOS7, Ubuntu 16.04 等):

# systemctl restart sshd

initの例:

# service sshd restart

SSH サーバの再起動後、設定変更に誤りがあればログインできなくなります。そのため、ログインしたままリモートからのログインが可能かどうか設定されることをオススメします。

まとめ

fail2ban を使えば、外部のネットワークからの不正攻撃に対して、自動的に遮断することができます。さくらインターネットでは、さくらのクラウド、さくらのVPSで fail2ban を標準で導入しているだけでなく、abuse チームにおける不正攻撃の検出や対処にも活用しています。(こちらはまた別の記事でご紹介する予定です)

皆さんにも、ぜひ本記事をご参考にしていただき、サーバ環境におけるセキュリティ向上のお役に立てられればと思います。

JANOG39 Meeting レポート~Day 1 & Backstage~

$
0
0

さくらインターネット エバンジェリストチームの法林です。

2017年1月18日~1月20日の3日間、石川県金沢市にてJANOG39 Meetingが開催されました。本記事ではDay 1(1月18日)の様子と、Backstage(ミーティングを支えるスタッフの姿)をレポート致します。

JANOGってなに?

JANOG(日本ネットワーク・オペレーターズ・グループ)は、インターネットの運用に携わる人々を中心とするコミュニティです。主な活動としては、メーリングリスト上での議論に加えて、半年に1回の会合があります。この会合がJANOGミーティングで、今回で39回目となります。歴史を感じますね。

JANOGミーティングでは、公募で集められた発表やパネルディスカッションを中心にプログラムが編成されます。その他に、ライトニングトーク、BoF(後述)、協賛各社による展示、懇親会などでイベントが構成されます。主な参加者層はネットワークエンジニアですが、近年のインターネットの発展に伴って参加者の業種・職種とも広がりを見せており、さまざまな立場の方が参加されます。その結果として参加者数も増加傾向にあり、今回は約750人が金沢に集結しました。

それから、JANOGミーティングの大きな特徴の1つにホスト制があります。これは、毎回1社(複数社の場合もあり)がホストとなり、その会社がイベントの財政を担うというものです。今回は株式会社DMM.comラボがホストを務めました。開催地や会場はホストが選定するので、ホストの地元や縁のある地域が選ばれることが多く、そのため開催地は毎回異なります。今回はDMM.comグループの創業地である石川県での開催となりました。

サイバーセキュリティBoF#2

サイバーセキュリティBoFに登壇した山下

Day1の最終セッションとして、BoFが8セッション並列で行われました。BoF(Birds of Feather)は「同じ羽の鳥は一緒に群がる」という言葉から来たもので、あるテーマに関して同好の士が集まって自由に議論する時間を指します。今回開催されたBoFのうち「サイバーセキュリティBoF#2」には、当社Abuseチームの山下健一が登壇しました。

当社におけるインシデント対応状況

山下からはホスティング事業者におけるインシデント対応の状況として、サーバに対する改ざんや不正ファイル設置などの被害が年間で1000件以上あること、DoSやポートスキャンの発信源となっているサーバも多発していること、事業者としてはもちろん見つけ次第ユーザに連絡して対応を依頼しているが、ユーザのリテラシーが低いとか事業で使っていて止められないなどの理由で対応が進まない事例も見られること、予防策として外部情報源を巡回してブロックリストを作成し不正アクセスを遮断していることなどを報告しました。

(なお、当社サーバのセキュリティ対応状況については、昨年11月に行われた「ウォルティ×ゲヒルン×さくらインターネット セキュリティの夕べ」における山下の発表もあわせてご覧ください)

当社サーバに対するインシデント発生状況

業界のお手本を目指して

その後の議論においても、山下への質問が多数寄せられました。例えば、リテラシーの低いユーザにroot権限のあるサーバを提供していること自体が問題ではないかとか、問題のありそうな顧客を見分ける方法はあるか、などです。議論の詳細は割愛しますが、それを見ていて感じたのは、当社は国内有数のホスティング事業者であり、さまざまな意味でリファレンス的な位置づけにあることです。つまり、当社の対応は当社だけでなく業界にも影響を与えるものであり、それだけに他社の模範となるような対応を目指していくべきであると感じました。

舞台裏を支えるスタッフ

ここでいったんプログラムの紹介を離れて、JANOGミーティングを支える人々をご紹介します。JANOGミーティングの開催には、プログラムの編成、会場の設営、ウェブサイトやSNSの運営など、イベントとして成立させるために働くスタッフの存在が欠かせません。JANOGは公募で集まったメンバーによる実行委員会がミーティングを運営しています。

会場控室で打ち合わせをする実行委員会の面々

プログラムはどうやって組むの?

まず、今回のプログラム委員長を務めた小椋祐也さん(株式会社アット東京)と馬淵俊弥さん(ビッグローブ株式会社)に、今回のプログラム編成の特徴などをうかがいました。

「JANOGは毎回テーマを設定するんですが、今回は『見つける、そして動きだす』としました。JANOGも参加者層が広がって、現場の人からマネージャーまでいろんな人達が来ますが、その人達が各プログラムごとに何かを見つけてほしいという思いでプログラムを考えました」(馬淵さん)
「馬淵さんからも話があったように最近のJANOGは参加者の幅が広くなっていますが、そんな中でも、どんな人もどれかのプログラムは自分の関心事に当たるように編成できたんじゃないかと思っています」(小椋さん)

プログラム委員長の馬淵さん(左)と小椋さん(右)

それから、最近のJANOGではプログラムを編成するにあたり、各スタッフがセッション順や時間割の案を作って実行委員会でプレゼンテーションを行い、最高の評価を得たものが採択されるという、通称「俺の考えた最強のJANOG」方式が採られています。今回、案が採用されたプログラム委員の三戸静香さん(セイコーソリューションズ株式会社)に、編成のポイントをお聞きしました。

「プログラム案を作るときに考えたのは、特定のレイヤーのものが固まらないようにバランス良く配置することですね。これも今回のテーマである『見つける、そして動きだす』を意識して、いろんな人が話題を見つけられるようにという配慮からです。それから、ミーティングが中だるみしないように、休憩のはさみ方もかなり考えました。実際に行われたミーティングを見ると、必ずしもすべてがイメージ通りに行ったわけではありませんが、予想以上に議論が盛り上がってくれてよかったです」

このように、JANOGはただ話を聞きに行くだけでなく、スタッフになれば自分の聞きたいセッションを企画するといった楽しみもあるのです。

プログラム委員の三戸さん

当社からもスタッフに参戦!

JANOGの実行委員会にはさまざまな企業からメンバーが集いますが、さくらインターネットからも技術本部の山口勝司がプログラム委員として参加しました。山口にスタッフのお仕事がどんなものか聞いてみました。

「プログラム委員はJANOGミーティングで行われるセッションの企画や編成を担当します。各委員ごとに担当プログラムがありまして、私は『ぼくの考えたさいきょうのDevSecOps』『DHCPも奥が深くて楽しいよ』の2件を担当しました。本業であるさくらの仕事の合間を縫ってJANOGの準備をするので思うように時間が取れず苦労しましたが、他のスタッフの協力もあって本番までやり遂げることができました。担当したプログラムはもちろん会場で見ましたが、『ぼくの考えたさいきょうのDevSecOps』で紹介されたVulsのデモがとても良くて、あれは参加者にも刺さったんじゃないかなぁと思います。JANOGのスタッフはとても楽しいので、やったことのない人にはぜひ経験してほしいですね」

山口に限らず、JANOGのスタッフを務めた人からは、ほぼ例外なく楽しかったというコメントを聞くことができます。筆者も何度かJANOGのスタッフを務めており、その経験は現在のコミュニティ運営にも生かされています。皆さんも機会がありましたらぜひスタッフに応募されてはいかがでしょうか。

なお、山口のコメントで紹介されたVulsのデモは、JANOG39のウェブサイトにて公開されているセッションのアーカイブ配信で見ることができますので、興味のある方はご覧ください。(2月24日(金)までの公開となります)

筆者も司会として参加

司会を務める筆者

また、筆者も本会議の司会者としてミーティングに関わりました。司会はミーティングをスケジュール通りに進行させる役割を担います。特にJANOGは発表だけでなく質疑応答を重視しているので、質問者を指名したり、所定の時間を超えそうなときは適当なところで切り上げるなどのコントロールも重要となります。今回、約10年ぶりにJANOGの司会を務めましたが、この10年の間にミーティングの規模も見違えるほど大きくなり、コミュニティとしての成長を感じました。若い人も着々とスタッフや発表者として登場しているので、今後のますますの発展を期待しています。

JANOG39 Meeting レポート 【全3回】 公開日
JANOG39 Meeting レポート~Day 1 & Backstage~ 2017年1月27日
JANOG39 Meeting レポート~Day 2~ 2017年1月27日
JANOG39 Meeting レポート~Day 3~ 2017年1月27日

さくらのインターンシップ 2018冬 カスタマーサポート・マーケティングコース

$
0
0
みなさんこんにちは! さくらインターネット 人事部の山田です。 2018年2月20日から22日にかけてインターンシップ(カスタマーサポート・マーケティングコース)を行いました。インターン生がさくらインターネットの社員として、カスタマーサポートやマーケティングについて学び、お客様に対してサービスをわかりやすく使っていただけるようなサポートサイトを作成しました!本記事では、ぎゅぎゅっと凝縮した3日間のインターンシップの模様をインターン生自身にレポートしていただきます。インターンシップに関する過去の記事もぜひご覧ください。 1.インターシップ体験レポート ~西村友希さん~ 京都女子大学現代社会学部 西村友希です。 「学びの多かったカリキュラム」レポート 1日目は座学が中心でした。さくらインターネットがどのような企業で、どのようなサービスを提供しているのかを学びました。 ライトニングトーク(以後、LT)会では「自分が印象に残った接客エピソード」を考えてくるという事前課題があり、それについて、1人2分程度でLTを行いました。 [caption id="attachment_15898" align="aligncenter" width="680"] みんなの視線が集中して、緊張[/caption] 私を含めて、アルバイトでの接客がうまくできた経験をお話するインターン生が多かったです。良かった、という経験ももちろんですが、悪い印象が残ってしまった経験も大切だという意見にとても納得しました。また、LT会の後には「いい接客とは何か」についてディスカッションをしました。「丁寧」「笑顔」などの意見の中、「安い早い」「期待以上の価値がある」など、納得させられる
Viewing all 325 articles
Browse latest View live