よく訓練されたアップル信者、都元です。前回は「Amazon VPCを使ったミニマム構成のサーバ環境を構築する」と題して、Amazon VPCに小さなサーバ環境を構築しました。この環境は、アプリケーションサーバ(Webサーバ)がユーザからのHTTPを受け付けつつ、管理者によるメンテナンスのためのSSHの受け付けも兼ねている状態です。セキュリティの観点からは、あまり好ましい状態とは言えませんね。 そこで今回は、メンテナンスのための踏み台(bastion)サーバを構築し、よりセキュアな構成にしてみましょう。環境の構成図は右の通りです。まず、アプリケーションサーバはHTTPのみを受け付けるようにSecurity Groupを調整します。また、public subnetの中にもう一つサーバを起動し、踏み台として使います。こちらはSSHのみを受け付けるように調整します。踏み台サーバは常時起動しておく必
IPA(独立行政法人情報処理推進機構)は26日、「脆弱性を悪用する攻撃への効果的な対策についてのレポート」と題するレポート(PDFファイル)を公開した。IPAのWebサイトからダウンロードできる。 IPAが、脆弱性を悪用した攻撃の増加に伴い、その対策を主にシステム運用管理者を対象に纏めたもので、PDFファイル24ページのレポートになる。特に2013年は、CMSの脆弱性を悪用したWebサイトの改ざんやクライアントソフトの脆弱性を悪用したウイルスなど脆弱性に起因する情報漏えい被害も多く、改めてIPAがリスクの考え方や対策を纏めた。 レポートは、1.脆弱性を悪用した攻撃、2.効果的な対策、3.対策の自動化の動向の3章の構成。会社などの組織下においては、脆弱性対策による影響も存在するため、すべてのソフトウェアに対して闇雲に行うのではなく、どのような観点から対策を絞り込むべきかなど、最適な対策を提案
最近、大規模なWordPressのサイトの乗っ取りが発生しました。今回の原因はWordPressではなくサーバの設定に問題があったようですが、LAMPサーバの設定を正しく行うのは難しいですし、ApacheやPHP、WordPressのバージョンアップをきちんと行っていくのは、結構大変です。 自分でサーバを運用していて、セキュリティ対策をきちんとしていると言える人は、実はあまり多くないのでは無いでしょうか?プラグインなどを複数導入している場合には、それらのプラグインのセキュリティ対策を行うのはかなり難しいといえます。 そんな中、高セキュリティ環境でWordPressを運用する方法はないのか考えてみました。それにはサーバ上でアプリを動かさないのが一番では無いでしょうか? 私のブログであれば、Voteなど動的な機能は使っていないので、WordPressのデータから静的なHTMLを生成して、Ama
AWSは今エンタープライズ祭り AWSと聞いて、ホームページを運営するためのレンタルサーバーぐらいに思っている方は認識を改めた方が良いかと思います。今、AWSをエンタープライズ分野で利用する企業が増えています。そこで、必ずといっていいほど出てくるキーワードが、セキュリティです。まぁ、自前でラックを用意して運用するよりも、AWSに預けた方が安全なのは明らかなのですが、セキュリティがザルなオンプレからクラウドに移行するにあたって、改めて考えてみようということで読んで頂ければと思っています。今回は、トレンドマイクロ社が公開しているホワイトペーパーを読みながら理解を深めます。 クラウドコンピューティングとは 毎度おなじみの用語の定義です。ここでは、NIST(The US National Institute of Standards and Technology)が定義するクラウドコンピューティン
(2013/08/29)追記 ロリポップ上のWordPressが不正アクセスされる事例が増えているようです(参考)。現時点で侵入経路等は明らかでありませんが、以下に説明する方法で、公開ページに対するSQLインジェクション攻撃や、管理コンソールに対する不正ログインに対しては、かなり効果があると考えられます。ユーザーの参考になれば幸いです。また、タイトルを変更しました。 追記終わり 今年の9月27日から、ロリポップのレンタルサーバーの全プランで、WAF(SiteGuard Lite)が標準装備されるようになりました。 WAF(ウェブアプリケーションファイアウォール)を導入いたしました ロリポップ!レンタルサーバーはWAF標準装備です。 http://lolipop.jp/waf/より引用 これは大変良いことですね。インターネット上のすべてのサイトが攻撃の対象ですし、被害も増えている印象がありま
皆さんこんにちは。 梅雨が明けて真夏日ばかりの日々ですね。暑いのが苦手なので、この季節は堪えます。 さて、先日外部の方にEC2のインスタンス管理を任せたいという事案が発生しました。頻繁に使うインスタンスではないため、使用時だけ立ち上げて終わったら落とす、という運用です。 インスタンスの起動は事前準備が要らないManagement Consoleを使うことになりました。ただ、普段のAWSアカウントを渡すわけにはいきません。このエントリーは操作範囲を極力限定したアカウントを作るための備忘録です。 条件 概ね以下の2つです。 Management Consoleにログインできる 特定のインスタンスだけ操作できる ちなみに、これだけだとEC2のインスタンス一覧は見えてしまうのですが、そこは止む無しと判断しました。 AWSのポリシー設定について AWSの各リソースや操作に関する権限は、グループやユー
図●改定で特に変化が大きかった箇所 共通鍵暗号(64ビット・ブロック暗号、128ビット・ブロック暗号、ストリーム暗号)のカテゴリは、改定前には多くの国産暗号がリストに掲載されていたが、それらの多くが改定で落とされた。ハッシュ関数は、安全性に問題がある二つの方式が削られている。(日経エレクトロニクス2013年4月15日号p.11から抜粋) 電子政府で用いる暗号方式を評価・調査するプロジェクトであるCRYPTRECが公開している「電子政府推奨暗号リスト」が10年ぶりに改定された(Tech-On!の関連記事)。同リストは、日本政府が電子システムを調達する際に使用を推奨する暗号方式を示すもの。技術的に安全性が確認された暗号方式を政府が示す役割も担っている。いわば“日本の標準暗号”を示すリストだ。 今回の改定では、2012年春に予告された通り、リストから多くの国産暗号が消えた(Tech-On!の関連
PSN侵入の件から始めよう 今年のセキュリティの話題の中でも特に注目されたものとして、4月20日に起こったPSN侵入事件があります。5月1日にソニーが記者会見をネット中継したことから、ゴールデンウィーク中にもかかわらず多くの方がネット中継を視聴し、感想をTwitterに流しました。もちろん、筆者もその1人です。 このときの様子は、「セキュリティクラスタまとめのまとめ」を連載している山本洋介山さんが、Togetterでまとめています。 Togetterのまとめを読むと、漏えいしたパスワードがどのように保護されていたかが非常に注目されていることが分かります。Togetterのタイムラインで、14:48ごろにいったん「パスワードは平文保存されていた」と発表されると、「そんな馬鹿な」という、呆れたり、驚いたりのつぶやきが非常に多数流れます。 しかし、15:03ごろに「パスワードは暗号化されてなかっ
先ほど気づいたのですが、かなり危険なバグかつ脆弱性なので手短に共有します。 他人でいつの間にかログインしていた facebook上のTLに流れてきたslideshareへのリンクを踏んで普通に資料を読んでいました。最初は気付かなかったのですが、なぜか右上にあるアイコンが自分のものではないアイコンが出ています。 ウチの会社の社長のアカウントなのですが、意図せずに勝手にユーザーアカウントが切り替わっています。 コメントも可能 ちょっと下にいくと、コメントができる欄がありますがここにも自分のアカウントではなくアカウントに切り替わっています。アイコンのURLが同一だからキャッシュしているなどではなく、完全に別ユーザーとしてログインをしている状態になっています。非常に危険な状態。 この時点で明らかにおかしいので本人に伝えました。 ※上記のキャプチャはコメント後に取得したキャプチャです。 コメント投稿
合わせて読んでください:Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 (2014-02/07) XMLHttpRequestを使うことで、Cookieやリファラ、hidden内のトークンを使用せずにシンプルにCSRF対策が行える。POSTするJavaScriptは以下の通り。(2013/03/04:コード一部修正) function post(){ var s = "mail=" + encodeURIComponent( document.getElementById("mail").value ) + "&msg=" + encodeURIComponent( document.getElementById("msg").value ); var xhr = new XMLHttpRequest(); xhr
AppBank の主任です。昨年、Dropbox でも「2ステップ認証」が利用可能になり、セキュリティを向上させる手段が増えました。 「2ステップ認証」とは、ユーザー名とパスワードという通常の認証に加え、一定間隔で生成されるコードを入力する認証も行うもの。 ユーザー名・パスワードは固定ですがコードはランダムなので、乗っ取り・不正アクセスをより困難にします。Google でも採用されています。 という訳で今回は Dropbox で 2ステップ認証を設定する方法をご紹介します。 ※Google/Gmail で2ステップ認証を行う方法は以下の記事でご紹介しています。→Gmailの乗っ取りを防ぐ「2段階認証」を設定する方法 iPhoneアプリをインストールする あらかじめ2ステップ認証に必要なアプリをダウンロードしましょう。必要なのは Google Authenticator。無料です。 Drop
Outbound Port 80 blocking ⽵竹 <takesako@shibuya.pm.org> http://www.janog.gr.jp/meeting/janog31/program/OP80B.html [ ] � MacBook Air ⾏行行 � [ ] � ⾏行行 ⼈人 � [ ] � ⼊入 � [ ] � ⼈人 � [ ] � ⽤用 Google Wireshark ⾯面⼈人 Firesheep � 2010 10⽉月 �Firefox � �Eric Butler⽒氏 � LAN facebook Twitter ⽂文 HTTP Cookie � �PoC⽰示 Firesheep ⾯面 Eric Butler⽒氏⽤用 Firesheep � Web �Amazon.com CNET dropbox Evernote Facebook Flickr Gith
JINS PC を使い始めました。普段はメガネをかけていないため、レンズに照明がうつり込むのが気になる、耳が痛い、と気になって気になってしかたがない yone です。効果があればよいのですが。 1. オレオレ認証局の活用 前回の記事で、オレオレ認証局 (プライベート認証局) の構築と、それを使ったウェブサーバ証明書の発行を紹介しました。記事の最後に、その他の証明書活用を紹介しましたが、今回はそのなかから「クライアント証明書」の事例を解説します。 2. クライアント証明書 一般公開しているウェブページではなく、特定の人だけに見せたいページを作る場合、Basic 認証を使うことが多いでしょう。ほぼ全てのブラウザが対応しており、広く使われています。 お手軽でよいのですが、盗聴・改竄に弱いという弱点があります。弱点を改善した Digest 認証というものがありますが、Basic 認証ほど普及してい
この記事はPHP Advent Calendar 2012の20日目です。昨日はTakayuki Miwaさんの「ComposerとHerokuではじめる!PHPクラウド生活」でした。 以前、「『よくわかるPHPの教科書』のSQLインジェクション脆弱性」というタイトルで、同書のSQLインジェクション脆弱性について説明しましたが、SQLインジェクション脆弱性のあるSQL文がDELETE FROMだったので、先のエントリでは、脆弱性の悪用方法としてはデータ(ミニブログの記事)の削除を説明しました。簡単に「全ての記事を削除できる」ので重大な脆弱性ではありますが、個人情報などが漏洩する例ではありませんでした。 このエントリでは、ブラインドSQLインジェクションという技法により、DELETE FROM文の脆弱性から、個人情報を得る手法を説明します。 脆弱性のおさらい ここで、脆弱性のおさらいをしまし
セキュリティグループ汚れていませんか? ドキッとしたあなた、あなたですよw!開発時と本番時、さらにはメンテナンス時にセキュリティグループのレコードを追加・修正する方も多いかと思います。AWSはかなり細かくファイアウォールを設定できますので、実用的でありがたい機能なのですが、私が様々な自社・他社のプロジェクトを拝見していると、結構汚れていることがあります。汚れているとはどんな状態か?それは、誰がいつ設定したか分からない必要なのか不要なのか分からない混沌とした状態のセキュリティグループです。 例えば以下のような。。。 誰がどこからアクセスするんじゃいってツッコミたくなりますよね? そして最終的には以下のようになってしまいます。 0.0.0.0/0って全部OKじゃん・・・ セキュリティグループの単位 そもそもセキュリティグループの単位をどうするかって話ですが、私は機能単位にしています。そしてロー
大垣(@yohgaki)さんと、セッションアダプション脆弱性が「重大な脅威」か否かで論争を続けています。 大垣さん:第25回 PHPのアキレス腱 ── セッション管理徳丸:PHPのSession Adoptionは重大な脅威ではない大垣さん:PHPのセッションアダプション脆弱性は修正して当然の脆弱性議論がかみ合わないので、twitterで「ブログ読みました。サンプルも動かしました。問題は分かるのですが、セッションアダプションがないPHPだと、何が改善されるのかが分かりません。教えて下さい」とツイートしたところ、大垣さんがブログで返信下さいました。 大垣さん: セッションアダプション脆弱性がないセッション管理が必要な理由これを読んでかみ合わない理由が分かりました。大垣さん、ありがとうございます。以下大垣さんのブログの末尾を引用します。 脱線しましたが、何が改善されるのか?結論は ログイン時に
ちょっと前にライフハッカー[日本版]で取り上げられていた、Macに簡単にロックをかけられるというアプリ「QuickLock」を試してみました。 関連:Macに簡単にロックをかけられるアプリ『QuickLock』 : ライフハッカー[日本版] 一度インストールすると、メニューバーに表示される鍵の形をしたアイコンをクリックするだけでシステムをロックする事ができます。もしくは、キーボードにショートカットキーを割り当てることもできます(例えば[command]+[L]など)。そして、ロックを解除するときは、自分で設定した好きなパスワードを使用できます。パスワード入力後に[Enter]キーを押さなくても良いので、Macのロック解除を瞬時に行うことができ、使い心地は快適です。 via: Macに簡単にロックをかけられるアプリ『QuickLock』 : ライフハッカー[日本版] 確かにMac標準のロック
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く