【ダイナース撤退】「ダイナースグローバルマイレージ」サービス改定のご案内

本日、残念なお知らせを発見してしまった。

「ダイナースグローバルマイレージ」のマイル移行レートおよび年間移行マイル数の上限が2020年2月1日から変わるらしい。

その詳細は下図参照


年間移行上限はいいとして、移行レートが1:1から2:1に改悪されている・・・。

さすがにANAは大量の解約発生を恐れて対象外にしているようだ。

駄菓子菓子

自分はダイナースのポイントはデルタスカイペソに移行するつもりでいたので、被害甚大である。

少数派だと思うが、自分はANAのマイルは貯めていないのである。

JAL修行で解脱してJGC会員になってからは、ANAとは袂を分かちあったのである。

んじゃ、何故デルタスカイペソなのかだが、、、

昔々、持っているだけでデルタのゴールドメダリオンになれる魔法のクレジットカードがあり、その延長線上でスカイペソがあるから貯めているだけの話である。

次に何故に高額な年会費のかかるダイナースを持っているのかということなのだが、、、

これも昔々、まだシティバンクが日本にあった時代、年間30万円決済すると年会費が無料になるクレジットカードがあり、この特典に魅力を感じて持ち続けているだけの話である。

マイルはJALがメインであることと、ダイナースのポイントは無期限なので、いずれJALマイルに移行できる日が来ることを夢見ていたのだが、残念な結果になってしまった。

サービス改定を踏まえてとる行動は一つ。

ダイナースカード撤退(解約)

である。

撤退までのステップ

1.ダイナースカードで決済している定額払い物のカード情報の変更

2.ダイナースポイントのデルタスカイペソへの移行

3.カード解約

期限は2020年1月末まで。

早速ステップ1を進めよう。。。



閉山中の富士山でニコ生配信中に滑落死


富士山でニコ生配信中に滑落して死亡したというニュースを見た。

そういえば以前中国で、ユーチューバーで生計を立てる人が、視聴率を稼ぐべく危険な動画撮影にチャレンジして命を落とす事件があった。

まさか日本でもそんなことをする奴がいたのかと思ったのだが、、、、

どうも、ニュース記事を読むと、富士登山にしては軽装であったらしい。

動画を見てみたが、特に軽装で富士山に登頂する類のものではなく、閉山中の富士山に登るところを生配信する企画だったようである。

前出の中国人は生計を得るために命を懸けた結果、命を失ってしまったが、
今回の件は別に命を懸けているわけではなく、ただ単に閉山中の富士山になめてかかって命を落とした単なる阿呆のような気がしている。

とはいえ、「人の振り見て我が振り直せ」である。

自分も無意識のうちに阿呆なことをしていないか定期的にチェックせねばならない。

悪いIPを晒上げるサイト「AbuseIPDB」

東京オリンピック・パラリンピック開催まで1年を切りました。

世界的なイベントがあると世界中から日本に観光客が押し寄せますが、サイバー攻撃も一緒に押し寄せてきます。

特にオリンピックではDDoS攻撃が想定され、オリンピックの回を重ねるごとに攻撃も激しさを増してきます。

最近はボットを使った業務効率化(RPA)の導入が盛んですが、サイバー攻撃を仕掛ける側も同様にRPAを活用した効率的且つ効果的な攻撃手法を編み出しています。

世の中にはたくさんのIoT機器があり、それらはセキュリティ的に脆弱と言われている。

そんなIoT機器が乗っ取られて、1台1台がRPAで制御されて、特定の攻撃対象に向けて一斉DoS攻撃を仕掛けたら、、、、と思うと少しぞっとする。

ところで、システム管理者の方は、不審なIPから大量のアクセスが来た際、どのように対処するだろうか?

「このIPブロックしたいけど、サービスに影響しないだろうか?顧客からクレームを受けることにならないだろうか?」

こんな悩みからIP遮断に踏み込めないケースは無いだろうか?

そんなときの一助になりそうなのが、

AbuseIPDB

世界中のいろいろな人が悪いIPをこちらに晒上げており、不審なIPが確認できているのであれば、こちらで検索することをオススメする。

リストがあれば躊躇することなくIPブロックをしてしまえばよい。

IPブロックで物足りなければ、自分から不審IPを晒上げることもできる。

セキュリティは国や地域を超えたグローバルコミュニティで成り立っているんだなーと感じる今日この頃。

米国電力業界のセキュリティ基準


先日、IPAより、米国の電力業界で活用されている、セキュリティマネジメント成熟度の評価モデル「ES-C2M2」の解説書およびチェックシートが公開された。

米国の電力業界はコンプライアンスとセキュリティガイドラインの2層で成り立っているようである

【コンプライアンス】

NERC CIP Standard

 North American Electric Reliability Council Cyber-security Critical Infrastructure Protection Standard

 北米電力信頼度協議会が策定した重要インフラ防護基準

 かつ

 アメリカ合衆国連邦エネルギー規制委員会が承認した米国電力業界向け規制標準

 ※2003年の大停電を踏まえて、電力の安定供給を念頭において作成された主に大規模発電施設及び送電施設を対象としたサイバーセキュリティに関する標準

 ※基準且つ規制になっているところがポイント

 ※規制なので、準じないと罰則もある(1,000USD~1,000,000USD)

【セキュリティガイドライン】

ES-C2M2
 
 Electricity Subsector - Cybersecurity Capability Maturity Model Program

 サイバーセキュリティ対策を改善するためのマネジメント手法を記載したガイドライン

NIST IR 7628

 NIST IR 7628 Guidelines for Smart Grid Cybersecurity

 NIST(アメリカ国立標準技術研究所)によって発行されたスマートグリッドを対象にしたセキュリティガイドライン

NIST Framework

 米大統領令によりNISTで策定されたCyberSecurity Framework

日本では罰則付きの規制は金融業界にしかなく、その他の重要インフラ業界は所謂ベストエフォートの対応になっている。

セキュリティはコストとみなす経営者が多く、罰則付きの規制になるともう少しセキュリティ投資が進むのではないかと思った今日この頃。

18億円投じたのに、誰にも利用されず廃止になったセキュリティ対策


ITシステムを作るときに一番苦労するのは利便性とセキュリティのバランスです。

利便性を追求し過ぎ(=セキュリティを無視)して失敗した事例が7pay

で、その逆の事例が今日のネタである、政府共通プラットフォームのセキュアゾーン

日本年金機構の不正アクセス事案を受けて2017年に構築したのだが、セキュリティをガチガチに固めすぎた(=利便性を無視した)結果、どこの省庁も使ってくれず、2019年に廃止決定。

まさに日経コンピュータの「動かないコンピュータ」の格好のネタになりそうな・・・。

ちなみにこのセキュアゾーン、どんな特徴かというと、

1.専用回線から閲覧のみ可能。ダウンロードは出来ず、格納されたデータの取り出しや訂正には職員が直接設置場所へ出向く必要がある。

2.省庁内の別の情報システムとの連携が出来ない。

うーん。この二つの特徴を備えられると、

はっきり言って、用途が無い

ちなみに総務省がシステムの開発・運用を行っていたが、その総務省は最初からセキュアゾーンを使うつもりはなかったらしい。

自分が使うつもりのないモノ作るなよー

このセキュアゾーンの構築に18億円というのも驚きだが、ランニング費用は3.6億/年かかるらしい。

んで、誰も使わないけど年間3.6億円浪費するこのスバラシイ仕組みに会計監査院の調査が入ってめでたく廃止となったらしい。

セキュリティは重要だけど、利便性とのバランスがすごく重要であることを改めて実感した。

パスワードを使い回ししないメリット


JPCERTコーディネーションセンター(JPCERT/CC)が、ウェブサービスで使用するパスワードを使い回すことの危険性を啓発するキャンペーン「STOP! パスワード使い回し! キャンペーン 2019」やっています。

単一のIDとパスワードの組み合わせを複数のサイトで使いまわしている場合、管理がザルなサイトからうっかり情報をお漏らしされると、パスワードリスト攻撃により、根こそぎ被害を受けるリスクがあります。

パスワードリスト攻撃とは、ID・パスワードの組み合わせのリストを、管理がザルなサイトから攻撃者が入手し、その組み合わせでログインできるかどうか複数のサイトで試みる手口。

このパスワードリスト攻撃による被害事例は、ユニクロ(19年4月)クロネコヤマト(19年7月)などがある。

念のため申し上げておくと、ユニクロやクロネコヤマトはパスワードリスト攻撃による「被害者」です。

諸悪の根源は、ID・パスワード情報をお漏らししたサイトで、どこのどいつだという話なのだが、管理がザルなだけにパスワードの保護もしていなければ、不正アクセスにも気付けないダメな企業なので追いようがない。

唯一追跡する方法としては、自身が利用するサイトごとに異なるパスワードを設定することである。

自分は利用するサイトごとに異なるパスワードを設定している。

ある日、「あなたのアカウントをハックした」旨の脅迫メールが届いた。文中にはその証拠としてパスワードが記載されていたのだが、この情報のおかげで、お漏らししたサイトを特定することができた。(当事者はお漏らしの事実を受け入れないのだが・・・・)

こんなメリットもあるので、パスワードの使いまわしはやめましょう。

JPCERT/CCでは「安全なパスワードの条件」として、以下の設定方法を推奨している。

■パスワードの文字列は、長めにする(12文字以上を推奨)

■インターネットサービスで利用できるさまざまな文字種(大小英字、数字、記号)を組み合わせると、より強固になる

■推測されやすい単語、生年月日、数字、キーボードの配列順などの単純な文字の並びやログインIDは避ける

■他のサービスで使用しているパスワードは使用しない

ロボットホテルの末路


ロボットが接客するホテルチェーン「変なホテル」を運営するH.I.S.ホテルホールディングス(HD)は10月17日、「変なホテル舞浜 東京ベイ」(千葉県浦安市)の全100室に設置していた卵型コミュニケーションロボット「Tapia」に脆弱(ぜいじゃく)性が見つかったと発表した。



「変なホテル」は生産性の向上(人件費の削減)を目的に、フロント業務や荷物運びなど、これまで人が担っていた業務のほとんどをロボットに任せていることが最大の特徴。

生産性の向上でロボットを使っている以上、当然ロボットは通信機能を備えている。

通信機能を備えているということは、外部から入り込む余地を与えるということに他ならない。

今回の脆弱性は、「Tapiaのプログラムを書き換えると、他の客の映像や音声を取得し、遠隔地から任意のタイミングで視聴できる」というもので、twitterからの投稿が発端の様だ。

しかし、せっかく脆弱性の指摘をしてくれたのに、対応を放置したH.I.S.ホテルホールディングスとメーカーのMJIの対応はいかがなものかと思う。

個人的には通信機能を備えたロボットを使う以上、常に不正アクセスとの戦いになることは覚悟しなければならないと思う。

生産性の向上は期待できるかもしれないが、人件費削減の代わりに恒常的なセキュリティ投資が求められるため、トータルで見た場合コストパフォーマンスは悪いのではないのだろうか。

コインチェックの貸仮想通貨サービス

アセットアロケーションの一環で少しだけ仮想通貨を保有しています。(保有比率は諸説あるけど、個人的には現在コモディティと同じ扱いで全体の10%未満にしている)

僕の仮想通貨との出会いのきっかけは、実は、アセットアロケーションの師匠でもある内藤忍さんだったりする。

2014年に、内藤忍さん共催の仮想通貨(リップル)セミナーがありました。

有償のセミナーだったんだけど、払ったお金分リップルがもらえる(確か1,500円くらい)という特典付だった。

その時貰ったリップルは気にも留めていなかったのだが、当時のウォレットであった、リップルトレードが2016年に終了となり、リップルのサルベージを行ったところ、80,000円(約40倍)の価値になっていた。

リップルトレードからのサルベージに相当苦労したこともあり、リップルを見限って全額をビットコインに変えました。

2017年後半から空前の仮想通貨(現 暗号資産)ブームが始まり、保有するビットコインの半分をイーサリアムに変え、ICO(Initial Coin Offering:イニシャル・コイン・オファリング)投資にチャレンジしたが、一つとしてヒットすることなく、投下したイーサリアムはほぼ壊滅してしまった。。。

で、難を逃れた残り半分のビットコインは現在も継続保有している。

あまりリスキーな投資をするつもりはないのだが、暗号資産は金と同じで保有するだけでは資産が増えない。

そこで登場するのが貸仮想通貨(レンディング)サービスである。

貸仮想通貨は、要は預貯金と同じで、預けて満期になると金利がついて返ってくるというもの。

コインチェックが、結構前からこの貸仮想通貨のサービスを行っている。

ネム流出事件が起きてからは、会社存続の危機もあり、怖くて預ける気にもならなかったが、マネックスグループ傘下となったことから、安心感が増し、5月に申し込みを行った。

人気で殺到しているのか、運用難で受付できない状態なのか、5ヶ月たっても運用が開始されない。


コールドウォレットに入れたところで、資産は増えないので、気長に待ちます。。。

気長に待つけど、不正アクセスによる流出だけはまじ勘弁。

COMODO社の情報流出事故

米国にCOMODOという会社がある。

TLSサーバー証明書を発行する認証局事業などを手掛けるセキュリティー企業です。

「コドモ」でも「ドコモ」でもなく、「コモド」です。

このセキュリティー企業が運営するフォーラム(掲示板サイト)が不正アクセスを受け、ユーザーの名前や電子メールアドレスなど、約24万5000人の個人情報が流出する事件が起きました。

【原因】
フォーラムで使用している掲示板構築ソフトvBulletinの脆弱性。

2019年9月23日に見つかった脆弱性で、ソフトベンダーから9月25日に修正プログラムが提供。

不正アクセスは9月29日に受けているので、修正プログラムの適用が遅れたために被害に遭った。

【想定被害額】
想定損害賠償額シミュレータの試算結果

・漏洩情報:約24万5000件

・漏洩情報:氏名、メールアドレス

・損害賠償額試算:2,940,000,000円(29億4,000万円)

【所感】

まともにシステム運用しているところであれば、通常検証環境に修正プログラムを適用し、テストを行って数日運用する。

んで、問題なければ本番環境に適用する流れになる。

そうしないと、システムそのものの安定運用が犠牲になってしまうリスクがある。

今回、修正プログラム公開から4日目で攻撃を受けているので、守る側としてはかなりキビシイ時間軸だと思った。

一般企業ならちょっと手に負えない気もする。

セキュリティ企業となると、それでも言い訳は厳しいのかもしれない。

以前マイクソ(マイクロソフトの略)のセキュリティパッチの不具合率を調べたことがあったのだが、セキュリティパッチの3割は不具合を抱えているという結果になった。

それを踏まえるとベンダーがリリースしたパッチを即座に適用するというのは安定稼働の観点からはリスクがある。

一方でパッチを早急に適用しないと、不具合を突いた攻撃を受けることになる。

あ、そこでWAF(Web Application Firewall)の登場となるわけか!

「パープルリス」と「炭鉱のカナリア」


セキュリティのお勉強で久しぶりに英語の雑誌と格闘した。

よく動物を使った格言のようなものがあります。

ちなみに先週知ったのは、

「炭鉱のカナリア」

これは、何らかの危険が迫っていることを知らせてくれる前兆をいいます。

石炭エネルギーが主力だった時代、多くの炭鉱がありましたが、炭鉱では有毒ガスのリスクと闘いながら働くこととなります。

有毒ガスが発生した場合、人間よりも先にカナリアが察知して鳴き声(さえずり)が止むことから、その昔、炭鉱労働者がカナリアを籠にいれて坑道に入ったことに由来するものです。

で、この「炭鉱のカナリア」は投資の世界でも生きていて、株価の急落や景気変調のリスクを示すシグナルの意味で使われます。

ちなみに、先週TOCOM SQUAREのラジオ公開生放送に参加してきたのだが、「炭鉱のカナリア」のサインとして、ハイイールド債から資金が流出しているという話を聞いた。

世界景気の減速は近づいているのだろうか!?




かなり話がそれたので、「パープルリス」の話に戻る。

”Stop Looking for the Purple Squirrel・・・・”というタイトルの記事を見ていたのだが、google先生に翻訳してもらうと、「紫リスを探すのをやめる・・・・」となった。

「パープルリス」って何やねんと思っていたら、驚いたことにWikipedia先生に解説があった・・・。

【Wikipedia先生解説】
パープルリスは、採用担当者が雇用要件に完全に適合する、適切な教育、経験、資格の範囲を正確に備えた求職者を説明するために使用する用語です。含意は、要件の過剰な仕様が紫色のリスと同じくらい見つけにくい完璧な候補になることです。
----

日本もそうですが、米国もセキュリティ業界は人材難な様で、「パープルリス」を探すのではなく、雇用慣行の改善を図ろうという内容でした。

例えば、

・女性や有色人種の登用促進

 それぞれセキュリティ業界の10%程度しかいないらしい

・求人情報の表現見直し
 
 「野心的」、「支配的」、「自信がある」などの男性に関連する言葉が多いらしい

・教育の重視

 資格を持っている人を前提にするのではなく、採用後トレーニングする前提で考える

米国もオープンなようで、あまりオープンではないのですね・・・。

スマホ証券「One Tap BUY」のメリットデメリット


One Tap BUYというスマホ証券がある。

個人的にはスマホでオンラインバンキングやオンラインショッピングというのが理解できない世代なのだが、今の若い人はスマホは使うけどパソコンは使わない人のほうが多いらしいので、そういうご時世ということで。

スマホ証券という時点で個人的には残念な感じしかないのだが、米国株投資に関しては、他の大手オンライン証券にはない独特な特徴がある様である。

メリットデメリット等をまとめてみたい。

【メリット】

■小額(千円)から取引出来る

米国株は日本株と違って1株から取引できるが、千円から取引できるというのは初心者に優しい気がする。

■積み立て購入が可能

これ、実はかなり大きいメリット。米国株を積み立て購入できるのはここだけなのではないだろうか。

ドルコスト平均法を活用してコツコツ購入していくことができる。



【デメリット】

■取り扱い銘柄が少ない

■手数料がちょっと高い(大手オンライン証券会社と比較して0.05%割高)

■指値注文とかができない

--

少額から米国株に投資できるのはとても魅力的。

親の管理が前提となるが、未成年でも口座が作れるため、子供の口座を作り、米国株をお年玉としてプレゼントすれば、投資教育にもなるかもしれない。

個人的には同じプレゼントでも、現金を消費するより、米国株でプレゼントしたほうが遥かに精神衛生上良い。

気になった点としては、少額で投資を始めるのはいいとして、出口戦略をどうするかかな。

投資にある程度慣れてスキルアップしてくると、少しでも良い条件で購入したくなってくる。

つまり、指値注文とかを駆使したくなってくるタイミングがいずれやってくることになるが、One Tap BUYは初心者向きゆえ、そのような高度な注文には対応していない。

そうなると、別の証券会社に移行することになるが、その場合の手数料とかってどうなんだろう?

PaaSとIaaS


恥ずかしながら、PaaSとIaaSの違いを混同していたことが判明したため、再整理。


PaaSとは?

Platform as a Serviceの略。

アプリケーションソフトが稼働するためのデータベースやプログラム実行環境などが提供されるサービス。

プログラムだけを用意すればよいというメリットがある一方、データベースの設定やプログラムの実行環境に制限があるので、開発の自由度は下がる。

インフラから開発する手間を省きたいけれど、ある程度カスタマイズしたいというときに利用するのが良い。

例:Google Apps Engine、Microsoft Azure


IaaSとは?

Infrastructure as a Serviceの略。

情報システムの稼働に必要な仮想サーバやハードディスク、ファイアウォールなどのインフラを、インターネット上のサービスとして提供する形態。

SaaSやPaaSなどと違って自由度が高く、ハードウェアのスペックやOSを好きなように選べる。

その分、OSやハードウェア、ネットワークの知識が必要となり、セキュリティ対策も当然必要。

例:Google Compute Engine、Amazon Elastic Compute Cloud(AWS)

ドキュメントルートに受領ファイルを置かない


保険業界は重要インフラ分野の一つとなり、当然セキュリティ対策にしっかり投資を行っている。

一方で保険業界には大小様々な代理店が存在しており、保険証券を扱う代理店は「セキュリティってな~に~」みたいなところが多く、保険証券のデータの保存先がコンシューマー用のNASであったり、保険の相談申込ページ(Webサーバ)に保険証券をアップロードさせてWebサーバ上に保険証券を保存するというびっくり運用が存在する。

そもそもの話として、今回はWebサーバで実施しておく基本的なセキュリティ対策(apacheベース)を整理しておきたい。

まず、認識しておかないといけないのは、Webサーバをデフォルトの状態で運用することは、「危険」な状態であるということです。

ウェブサーバは通常、インターネット上に配置され不特定多数からのアクセスが発生するため、デフォルトの状態で運用するということは、外出時に自宅に鍵をかけないどころか、ドアを全開放して「外出中です」と張り紙を出して外出するようなものです。

1.ディレクトリ内容一覧表示の無効化

apacheには公開しているディレクトリ内容を一覧表示するディレクトリリスティング機能が実装されています。

本機能が有効になっているディレクトリを表示すると、以下のようなインデックス画面が表示されます。

デフォルトでは、ドキュメントルートでこの機能が有効になっています。

この場合、Webサーバの公開ディレクトリに直接アクセスを行うと、ディレクトリ内に存在するファイルの一覧が表示され、ディレクトリ内のファイルの一覧を取得することが可能です。

つまり、冒頭で話した様な、保険証券を問い合わせフォームに添付してアップロードさせるようなケースの場合、保険証券のデータをこのドキュメントルートに保存すると、保険証券のデータは漏洩します。

ディレクトリでファイルの一覧が表示されることにより、外部に流出する情報として、他に以下のような内容が考えられます。

【ファイル一覧機能により、外部に流出する可能性がある情報】

□公開を意図しないファイル

□バックアップファイル

□一時ファイル

□隠しファイル(ドットで始まるファイル名のファイル)

□ファイルの命名規則

□設定ファイルによるサーバ設定情報

□スクリプトファイルによるサーバ内部処理情報



2.HTTP TRACEメソッドの無効化

まず、そもそもTRACEメソッドとは?から。

HTTP 1.1(RFC2616)で定義されている、8種類のメソッドの一つ。

GET、POST、HEADなどはおなじみのものですが、それ以外にPUT、DELETE、OPTIONS、TRACE、CONNECTの5種があります。

このうち、TRACEメソッドは、HTTPリクエストを「オウム返しに」HTTPレスポンスとして返すもので、以下のようにGET等の代わりにTRACEとしてWebサーバーにリクエストします。
TRACE /auth/index.php HTTP/1.1
Host: example.jp
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:18.0) Gecko/20100101 Firefox/18.0
Cookie: PHPSESSID=4lel0hml53u2tbhcd9pmo7pkc4
Authorization: Basic eWFtYWRhOnBhc3N3b3Jk
Connection: keep-alive
レスポンスの例を以下に示します。
HTTP/1.1 200 OK
Date: Tue, 22 Jan 2013 13:51:09 GMT
Server: Apache/2.2.14 (Ubuntu)
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: message/http
Content-Length: 198

TRACE /auth/index.php HTTP/1.1
Host: example.jp
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:18.0) Gecko/20100101 Firefox/18.0
Cookie: PHPSESSID=4lel0hml53u2tbhcd9pmo7pkc4
Authorization: Basic eWFtYWRhOnBhc3N3b3Jk
Connection: keep-alive
で、このTRACEメソッドが有効になっていると、Cross-Site Tracing(XST)攻撃と呼ばれる、XSS(Cross-Site Scripting)とTRACEメソッドを組み合わせた攻撃のリスクが発生する。(詳細はコチラ

そのため、TRACEメソッドを無効にすることでセキュリティを確保します。



3.X-Frame-Optionsヘッダの設定

クリックジャッキング攻撃の対策となるX-Frame-Optionsヘッダを設定します。

クリックジャッキングとは、ユーザが意図しない操作(ボタンやリンクのクリック)を実行させられる攻撃です。
(クリックジャッキングの詳細はコチラ

情報の公開・非公開設定がユーザの意図に反して気づかないうちに変更された結果、情報漏えい事故につながる等の被害が想定されるため、X-Frame-Optionsヘッダを設定します。



4.apache バージョンの非表示化

apacheのバージョン情報を取得することができる設定がデフォルトでは有効になっています。

バージョン情報の表示は直接の脆弱性とは関係ありませんが、利用しているapacheに脆弱性が存在する場合に脆弱性を突いた攻撃等を実施する手がかりとして利用される恐れがあります。

サービスへのアクセス時に表示されるこれらの情報はバナー情報と呼ばれ、バナー情報の隠蔽は攻撃者に攻撃の手がかりを与えないために有用な対策となるため、バナー情報はできる限り非表示とすることでセキュリティを向上できます。



5.SSL/TLSにおける安全性の低い暗号スイートの無効化

サーバ側のSSL/TLS設定において安全性の低い暗号スイート(プロトコル・暗号アルゴリズム、鍵長、ハッシュ関数)をサポートしている場合、安全性の低い暗号スイートが利用されることで、通信内容の盗聴につながる可能性が高まります。

安全性の低いプロトコル・暗号化アルゴリズム、鍵長、ハッシュ関数を無効化し、安全性の高いプロトコル・暗号化アルゴリズム、鍵長、ハッシュ関数のみをサポートすることでセキュリティを確保できます。

一般的に安全性の低い暗号スイートと呼ばれるものは、下記があります。

・MD5

・RC4

・3DES

・SSLv2

・SSLv3



6.SSL/TLSプロトコルのデータ圧縮機能の無効化

SSL/TLSプロトコルのデータ暗号化時の圧縮機能が有効になっている場合、SSL/TLSによって暗号化された通信内容の一部が漏えいする可能性があります。

暗号化前のデータ長(サイズ)の情報からデータ内容の総当たりによる推測が行われた場合、Cookie等のHTTPヘッダの一部が取得される脆弱性が存在するため、SSL/TLSにおけるデータ圧縮処理(Compression)機能は無効化します。

出典:攻撃を受ける前に見直すApacheの基本的なセキュリティ10のポイント

知っている人だけが救われる日本の支援制度


日本にはお金をもらえる公的制度がいくつかあります。

ちなみにこれらは「困った人」を助ける制度ではありません。

「知っている人」を助ける制度です。

なので、知らなければいつまでたっても給付を受けることはできません。

制度を知っていて行動を起こすことができる人のみを助けてくれます。

行政のサービスは平等なようで平等ではないです。

というわけで、普段からお金がもらえる制度は理解したうえで、条件を満たした場合はキッチリ権利を行使しなければなりません。

最近とある方から紹介された、あやたかさんのサイトで、まとめられていたので、自分なりに整理していきたい。

■教育訓練給付金

 これ、制度と自身のタイミングが合わなかったと思うのだが、個人的に縁のない制度になってる・・・。

■傷病手当金

 一部でインフルエンザでも使えるようなこと言っていますが、半分正解で半分間違い。

 普通インフルエンザになると泣く泣く有給休暇使うと思うけど、有給休暇使うと傷病手当金は支給対象外になる。

 感覚的には有給使いきっちゃったけど医者から自宅療養を指示された人が使う制度かな。

■高額療養費制度
 
 医療費が月8万を超えた場合に検討。

 鋭い人なら分かるかもだけど、この制度を知っていれば、基本高額な医療保険はいらない。

■すまい給付金

 年収750万未満の人が家を買うときは確認してみたほうが良いかも。

 ただ、個人的に住宅ローンで家を買うのは反対。

 住宅ローンは投資ではなく、浪費です!

■出産手当金
 
 出産の〇〇日前~出産後〇〇日までに出産で会社を休んだ場合にもらえる。

 会社を休んだ日をいちいちカウントしなければならないのかな?

 ちょっと面倒な気がする。。。

■育児休業給付金

 男性も対象なので、イクメンはぜひ検討すべき!

■介護休業給付金

 これ、知らんかった・・・

 いつ自分も介護に巻き込まれるか分からないので、いざというときにちゃんと使えるようにせねば

■災害時の給付金

 被災者生活再建支援制度(10世帯以上の被害時)、災害障害見舞金(5世帯以上の被害時)、災害見舞金などがある。

JALの赤ちゃん連れの座席が事前にわかるサービスが賛否両論!?


JALによく乗る人は、座席指定時に、変な顔が席を占領している状況に遭遇したことはないだろうか?

これ、「幼児マーク」という、赤ちゃん連れの座席が事前にわかるサービスらしい。



フライト中にイラつくケースとしてよくあるのが、フライト中ガキが泣き続けること。

「ガキ連れて飛行機乗るなよ」と心の中で思う一方、「そのガキを相手にしている親御さんは大変だな」と思いを改めて複雑な気持ちになり、なんとも気まずいフライトになる。

・・・どうも自分は子供が嫌いらしい。

そんなわけで個人的には搭乗予定にガキがいること、それがどこにいるのかを事前に知ることで、可能であれば極力ガキから離れ、それが出来なければ心の準備ができるということで、無条件に素晴らしいサービスだと思っていた。

ところが、どうも賛否両論になっているらしい。

ん、「否」の部分なんてあるのか?と思いながら、否定の意見に耳を傾けてみる。

どうやら、「そんなマークつけて避けるんじゃなくてみんな寛容になろうぜ」ってことらしい。

うーん。一理ある。

自分ももっと心の広い人間にならないとだめだな。

心を入れ替えよう。

アカウントののっとりと身代金の要求をするスパムメール「あなたは大きな変態です」


数日前から、アカウントののっとりと身代金の要求をするスパムメール「あなたは大きな変態です」が拡散しているらしい。

詳細はこちらでまとめられているので、届いた方は無視してあげてください。

ちなみに自分にも届いていないかとメールボックスをチェックしてみたが、残念ながら届いていなかった。

しかし、Amazonを騙る偽メールを発見したので、ちょっと掘り下げてみたい。

こちらが偽メールのスクリーンショット。


まず、差出人。

Amazon <hrh@nect.com>

となっている。

まず、この時点で偽メール確定なんだな。

ちなみに、nect.comドメインをチェックしてみる

うーん。レジストラの情報くらいしか分からない。

ま、そもそも差出人自体が偽装されているかもしれないので、差出人情報自体はアテにできないです。

ちなみにメールヘッダを確認すると、送信元のIPは下記となっている。

128.14.232.159

IP上は香港となる。

つまり、このメールは香港のIPアドレスから送信されたということになる。

ちなみに、送信元IPが香港ということだけで、このIPが偽メールの本当の送信元なのか、乗っ取られてただの中継サーバになっているだけなのかは分からない。

次にメール本文。

ログインIP(164.09.36.162)の記載がある。

んで、このIPはスウェーデン。

送信元IPは香港で、メール本文記載の利用者のIPとしているものはスウェーデン。

せめて日本のIPにすればいいのに。。。

次。

「ログイン」と記載されている箇所はリンクになっている。

リンク先は下記の通り。

https[:]//account-update.amazon.co.jp.fszjxh[.]com/

amazonドメインと見せかけた、fszjxh[.]comというドメインである。

※誤接続防止用に[]を付加しています。

次にこのドメインをVirusTotalで調べてみる。


幾つかのセキュリティエンジンでフィッシングサイトやマルウェアサイトの認定を受けています。

本文を読み進めていくと、ご丁寧に電話番号まで記載されています。

「パスワードを変更した覚えがない場合は、至急(03)-5767-5252までお電話ください。」

さて、この、03-5767-5252って、一体どこなのだろう?

調べてみると詐欺集団の電話番号ということが分かります。

ちなみに、実際にアクセスしてみるとどんな画面が出てくるのだろう?

直接アクセスするのはちょっと怖いので、urqueryの様な代理アクセスのサービスを使ってアクセスしてみます。


ん、名前解決ができない・・・・。

というわけで、リンクをクリックしてもアクセスできないようです。

結局迷惑メールは送信元をつかむのが難しいので、無視が基本となります。