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

そらとぶへび

仕事・プライベートを通しての気づき、JavaやPHP、データベースやサーバの話などこつこつと書いていきます

ELB配下のEC2にBasic認証とヘルスチェックを設定する。

AWS

ELB配下のEC2とするためヘルスチェックを設定したい。しかしBasic認証をかけておきたい。
という場合の設定。
備忘のためメモしておきます。


Basic認証配下にヘルスチェック先があると、401エラーになってしまい正常なヘルスチェックができない。
その場合は、以下のようにApacheのConfを設定し、ヘルスチェック先のみベーシック認証対象から除外します。

ベーシック認証を設定。ただしヘルスチェック先を除外する。
# いずれかの条件を満たせばアクセス可
Satisfy Any

# ベーシック認証によりアクセスを許可
AuthUserfile /home/hogehoge/application/public/.htpasswd
AuthGroupfile /dev/null
AuthName "Please enter your ID and password"
AuthType Basic
require valid-user

# リクエストURLがヘルスチェック先の場合は、アクセスを許可
setEnvIf Request_URI "/health_check/index.php" healthcheck
Order Deny,Allow
Deny from all
Allow from env=healthcheck
ヘルスチェックログの出力先を分ける

ヘルスチェックログとアプリログを混在しないように、以下の設定で出力先を分けます。

  DocumentRoot /home/hogehoge/application/public
  SetEnvIf User-Agent "ELB-HealthChecker.*" nolog
  SetEnvIf User-Agent "ELB-HealthChecker.*" elb
  ErrorLog /home/hogehoge/application/logs/error_log
  CustomLog /home/hogehoge/application/logs/access_log combined env=!nolog
  CustomLog /home/hogehoge/application/logs/health_check_access_log combined env=elb

ちなみに、ロードバランサー作成後にヘルスチェック先変更する場合は、ターゲットグループの方のタブから行うらしい。。

ChromeやSafariで現在地情報が取得できない件

GPS関連(Geolocation API )を調べていて気が付いたのですが、
ChromeSafariの仕様変更により、http接続の場合、現在地情報の取得ができなくなったため、
スマートフォン関連での現在地検索が利用できなくなっていました。

 ・Google Chrome(PC用を含む)  2016年4月から 
 ・iOSiPhoneiPadiPod touch) 2016年9月から

今後も、http接続での現在地取得を禁止するブラウザが増えていく傾向にあるようです。

サイト全体がhttpsに対応していればリダイレクトさせる、
そうでない場合は、GPS取得時のみだけでも、httpsに対応したページを作成する
などの対応が必要になります。


@IT ・Webブラウザで現在地情報を正しく取得できない場合の原因と対策
Tech TIPS:Webブラウザで現在地情報を正しく取得できない場合の原因と対策 - @IT

CSV(Creating Shared Value/共有価値創造)とは何ぞや

もともと経営論云々というのは疎くて、あまり興味を持っていなかったけれど、
最近、CSV経営という概念を知って共感・感銘を受けたので、簡単にまとめてみます。
f:id:lue4881:20161022105003j:plain

CSV(Creating Shared Value/共有価値創造)とは

マイケル・ポーター教授の提唱するCSV(Creating Shared Value/共有価値創造)とは、単に「経済価値」のみを追求するのではなく、「社会価値」を生み出していこうとするソーシャルビジネス的な視点が含まれる概念となります。

ここでいう「社会的価値」とは、事業を通して社会問題、社会課題を解決することで、企業としての存在価値・競争力を高めていこうとする経営戦略です。

従来のCSR(Corporate Social Responsibility/企業の社会的責任)がコンプライアンスや環境マネジメント、社会貢献活動など本業以外での活動を指していたことに対し、CSVでは本業、つまり事業そのものが社会的貢献につながることを目指しています。

どんな企業がCSVに取り組んでいるか

www.nestle.co.jp

例としてネスレはCreating Shared Value Teamを社内につくり、世界各地でCSVプロジェクトをつくり、積極的な取り組みが行われています。


www.jri.co.jp

上記の記事では、伊藤園ツムラ、エーピーカンパニーの3社を事例に挙げています。


いずれも、ただ調達価格だけで取引先を選ぶのではなく、お互いにパートナーとしてビジネスを育てていくというイメージです。
資源調達先の支援を通じて、品質向上や長期的なエンゲージメント効果があるのだそうです。

まとめ

企業が一時的な経済利益の最大化を主目的として活動した結果引き起こされる社会問題・環境問題が数えきれないほどにあります。
そのなかで、CSVの理念に基づいて事業に取り組む企業が増えていくことは、望ましいものだと感じています。

スパムメール・偽装メールの確認方法

セキュリティ 情報処理試験

まず初めに、メールヘッダの読み方について、説明します。

メールクライアントソフトによって、表示のさせ方は異なりますが、
ヘッダ情報としては、以下の構造になっています。

===============================================================
[エンベローブ]
 MAIL FROM ・・・送信元
 RCPT TO  ・・・送信先
 DATA

[ヘッダ]
 Retrurn-Path ・・・送信元アドレス
 Delivered-To ・・・宛先アドレス
 Recevived   ・・・メールを送信したメールサーバの情報
 From     ・・・送信元アドレス(メールの作成者が入力したもの)
 To      ・・・宛先アドレス(メールの作成者が入力したもの)
 Subject    ・・・件名

[メール本文]
 ・・・
 ・・・
 ・・・

===============================================================

エンベローブはメールサーバが送信に使う情報、
ヘッダは送信者や受信者の便宜のために準備された情報になります。

基本的に両者は同じ情報ですが、メールサーバはエンベローブしか見ていないので、
エンベローブとヘッダに差異があっても、送信自体には問題がありません。
つまり、送信元でヘッダ情報はいくらでも偽装が可能になっています。

ただし、Recevivedフィールドは、経由したメールサーバが付加した情報なので、
比較的改ざんの難しい場所
になります。
なので、ほかのフィールドとRecevivedフィールドの整合性が取れないことを頼りに、
偽装メールを判別することができます。

Recevivedフィールドは以下のような記述となっています。

Recevived:from 送信元 MTA by 送信元 MTA

この送信元と、送信先がちぐはぐになっていれば、偽装された可能性は高いと判断することができます。

DNSに関するあれこれ

セキュリティ 情報処理試験 開発

f:id:lue4881:20160926231339j:plain

ここでは、DNSに関する基本とDNSキャッシュポイズニングに対する対策を紹介します。

DNSサーバの基本

DNSサーバはコンテンツサーバとキャッシュサーバに分類できます。

コンテンツサーバ・・・オリジナルのDNS情報を補完するサーバ
キャッシュサーバ・・・コンテンツサーバから得られたDNS情報を一時的に保管するサーバ

名前解決の問い合わせがあった場合、以下のような流れで、処理を行います。

  1. クライアントは通常、自組織のキャッシュサーバに再帰的な問い合わせを行う。
  2. キャッシュサーバは問い合わせを受けて、コンテンツサーバに問い合わせを行う。
  3. キャッシュサーバはコンテンツサーバから得られたDNS情報をクライアントに返答する。
  4. それと同時に、DNS情報のコピーを一定期間保存する。

問題点として、コンテンツサーバからの回答は、とくに認証を必要としないことです。つまり本物の回答の前に、偽の回答を返答してしまえば、うそのDNS情報をキャッシュサーバに記憶させることができてしまいます。これを、DNSキャッシュポイズニングといいます。

DNS情報を汚染されたキャッシュサーバに問い合わせをすると、攻撃者が設置した悪意のあるサーバに通信を誘導されます。また、大きなDNS情報を記憶させたうえで、キャッシュサーバに送信元を詐称した問い合わせを行うことで、DNSリフレクション(DNS amp攻撃)が行われます。

DNSサーバを運用する際には、自社が最終ターゲットでないとしても、踏み台にならないように対策が必要になってきます。

続きを読む

【情報処理試験対策】サイバー攻撃手法と対策まとめ

開発 情報処理試験 セキュリティ

 そろそろ情報処理試験まで一か月を切りましたね。合格を目指して勉強している皆様は、順調でしょうか。

 

基本情報処理、応用情報処理から、セキュリティスペシャリスト試験、セキュリティマネジメント試験まで幅広く出題される情報セキュリティ分野でとりあげられるサイバー攻撃手法を紹介します。

主要なものだけリストアップしてもかなりの量になりますが、攻撃対象(システム、人)で分類するなども一つの手です。 

f:id:lue4881:20160924181842j:plain

 

 

1.外部公開されているWEBサーバなどシステムへの攻撃と対策

DoS攻撃

概要

サーバに負荷を集中させるなどしてサーバを使用不可に陥れる。営業妨害などを目的として利用される。

対策

どの通信を利用するかによって異なるが、基本的には不要なポートは閉じ、不正な通信をフィルタリングすることがあげられる。

TCP SYN Flood(3ウェイハンドシェイクを大量に送り付ける)

 →一定時間を過ぎた不成立コネクションは強制終了させる。不要なポートは閉じる。

Connection Flood(大量のコネクションを確立させる)

 →特定ノードやグループからのコネクション数を制限する。FWやIPSで攻撃元アドレスからの通信を遮断する。

UDP Flood(UDPポートに大量のデータを送り付ける)

 →不必要なUDPポートを閉じる

Ping Flood(Pingを大量に送り付ける)

 →ICMPによる通信を遮断し、WAN側からのpingには応答しない  

DDoS攻撃

概要

DoS攻撃を大量のノードから実行する。なかでも、踏み台サーバなどを利用して、大量にSYNパケットを投げる手法をDRDoS攻撃(分散反射型DoS攻撃という。直近では今月前半にヨドバシカメラが被害を受けたDNSamp攻撃(DNSリフレクション攻撃)、またICMPエコーを悪用したSmurf攻撃などが挙げられる。

国内の複数のウェブサイトでつながりにくい状況--「DNS amp」攻撃の疑い - CNET Japan

 

対策

手口により個別の対応が必要。(SmurfではICMPに応答しないなど)

IDS,IPSの導入も一定の効果がある。

ただ、ヨドバシの件のように莫大なトラフィックが集中した場合、一社での対応は難しく、プロバイダなどに相談して帯域制限を考えるなど、関係各社での協力体制が必要になる。

 

SQLインジェクション

概要

Webページ上の入力ホームに不正な文字列を入力し、攻撃用のSQL文を作成して、DBの内容を不正に閲覧、操作する。

対策

エスケープ処理をする。

バインド機構を利用する。

 

クロスサイトスクリプティングXSS

概要

悪意のあるスクリプトの文字列を記述したURLを作成して、攻撃対象のWebページにリンクを張る。そのリンクをクリックしたときに攻撃対象のWEBサイト上で悪意のあるスクリプトを含むページを作成させ、被害者のブラウザで起動させる。

対策

Webページに出力する文字列から、スクリプトを作成させるために用いる「’」「”」などの特殊文字を取り除き無害化する。(サニタイジング

WAFを導入する。

 

クロスサイトフォージェリ(CSRF

概要

利用者があるサイトでログイン状態にあることを利用して、クラッカーが利用者の名前で任意の操作を行う。

対策

利用がすんだらログアウトをすること。

WAFの導入。

 

OSコマンドインジェクション

概要

Webページ上の入力フォームにOSのコマンドライン上で有効なコマンドを入力させ、Webサーバー上で不正な命令を実行させる。

対策

Webページ上から直接コマンドラインにパラメータを送らないようにする。

 

DNSキャッシュポイズニング

概要

DNSサーバ上に誤ったドメイン情報を送り込み、そのDNSサーバを参照したPCを正規のWebサーバとは異なるサーバへ誘導する。

 

対策

DNSサーバプログラムのバージョンを最新に保ち、脆弱性を付かれないようにする。

DNSSECを導入する。

 

バッファオーバーフロー

概要

入力データを記録するデータ領域(バッファ)のサイズよりも大きいデータを送り込み、バッファをあふれさせることで、プログラムを誤動作させて管理者権限を奪う。

対策

入力データのサイズチェックを行い、不正なサイズのデータを受け付けないようにする。

 

IPスプーフィング

概要

送信IPアドレスを攻撃対象のネットワーク内のアドレスのように偽装したIPパケットを送り付けて、ファイアウォールのパケットフィルタリングをすり抜け、不正なIPパケットを攻撃対象のLAN内に侵入させる。

対策

社外から、社内のIPアドレスIPアドレス送信元とするIPパケットが送信された場合に侵入させないようにフィルタリングルールを設定する。

パケットの順番を管理するTCPヘッダのシーケンス番号の妥当性をチェックする。

 

ポートスキャン

概要

サーバ上で稼働するサービスの種類を確認するため、送信先ポート番号を1つずつ変化させたIPパケットを多数送信し、返答の有無を確認する。

対策

使用していないポートは閉じる。

送信先ポートを1つずつ変えたIPパケットを送ってくるような送信元からのアクセスを遮断する。

 

セッションハイジャック

概要

2者間で行われている通信をクラッカーが乗っ取る攻撃方法。サーバに成りすましたり、サーバ、クライアントの中間に割り込んだりと、方法は多岐にわたる。

対策

セッション番号の割り当てに乱数を使う。

暗号化と認証を行う。

ポート番号をランダムに選択する。

 

  

 

2.不正サイトへの誘導、アクセス権奪取など人をターゲットとした攻撃

Webビーコン

概要

imgタグが別サーバへアクセスしにいく特性を利用した攻撃。WebページやHTMLメールに小さい画像を埋め込み、悪意のあるプログラムをロードさせ、Webページ閲覧者やメール受信者の行動を把握する。

対策

メールをテキストとして読み込む。

画像の読み込みをブロックする。

 

フィッシング

概要

正規のWebサイトと酷似した偽のWebサイトを用意し、スパムメールや有名サイトと少し文字が違うドメイン名を用いる(利用者のうち間違えを期待)などで利用者を誘導して、個人情報を盗む。

対策

差出人不明のメールのURLなどにアクセスしない、業務に関係のないサイトを閲覧しないなどの運用規定の徹底。

ブラウザやセキュリティソフトのフィッシング判別機能を利用する。

 

ファーミング

概要

DNSキャッシュポイズニングなど名前解決情報の操作による不正サイトへの誘導。フィッシングと違って利用者に落ち度がなくても引っかかってしまう。

対策

サーバのディジタル証明書を確認する。

 

辞書攻撃

概要

よく用いられる文字、氏名や生年月日、電話番号など推測されるパスワードを片っ端から入力する。

対策

一般的な単語、氏名や生年月日、電話番号などをパスワードとして設定しない。

 

ブルートフォース

概要

考えられる文字列の組み合わせをすべて試すことで、パスワードを推測しようとする。

対策

パスワードの文字列をできるだけ長くし、かつ英語や記号、数字などの組み合わせたものにする。

 

ソーシャルエンジニアリング

概要

本人、関係者に成りすまして電話などでパスワードを聞き出す、ユーザの肩口からキーボードを盗み見する(ショルダーハッキング)など、人的な脆弱性を利用したもの

対策

折り返し電話をするなど、本人確認をおこなう。

のぞき見防止対策を行う

  

まとめ

今回は、情報処理試験向けに書いたので、対策については一般論的な話ばかりです。

また、実際の攻撃手法は多岐にわたり様々ですが、主要なところを押さえておけば、試験でも実業務でも適切に分類し対応することができると思います。

 

港区/アクアフィールド芝公園

水泳

ちょっと前にプール期間が終わってしまい、季節外れですが、

来年の夏に向けて(?)、お勧めなプールを紹介しておきます。

 

続きを読む