STOP!!パスワード使い回し!!（2018）

Posted by On Filed under MAILサーバ, WEBサーバ, サーバ, システム開発, セキュリティ, ネットワーク, 事業

複数の（インターネット上の）サービスで同じログインIDとパスワードを使い回しすると、どこかのサイトから流出した可能性のあるログインID・パスワードを用いた「パスワードリスト攻撃」（または「リスト型アカウントハッキング攻撃」）などと呼ばれる方法によって、第三者に不正にログインされる恐れがあります。

近年この方法によるアカウントの乗っ取りや、不正課金利用などの被害者が増加傾向にあります。

ID・パスワードをしっかり管理しましょう

(1) 名前などの個人情報からは推測できないこと
(2) 英単語などをそのまま使用していないこと
(3) アルファベットと数字が混在していること
(4) 適切な長さの文字列であること
(5) 類推しやすい並び方やその安易な組合せにしないこと
などの方法が有効です。
 
必ずしも定期的に変更する必要はないとの認識が総務省より示されました

パスワード「頻繁に変更はＮＧ」総務省が方針転換
　定期的に変えるのはかえって危険――。総務省がインターネット利用時のパスワードについて、従来の“常識”を覆すような注意喚起を始めた。（頻繁な変更は）「推測しやすい文字列になって不正アクセスのリスクが増す」というのが理由で、それよりも十分な長さかつ複雑なパスワードを使い続けるよう呼びかけ。
国民のための情報セキュリティサイト（総務省）
社員・職員全般の情報セキュリティ対策（PDF）

 

弊社おすすめのパスワード生成方法（2018年版）

※使い回さず、忘れにくいパスワードの特定のルールに従って生成することをおすすめします。以下に生成例を提示します。
(1) 記号を二つ決める
　　たいていのサービスで !$/%@# あたりの記号が使えるようになっています。
　　この中から二つ。
　　例えば「$」と「@」
(2) 覚えやすい英単語を二つ思い浮かべる（3文字～4文字程度が良い）
　　例えば「hand」と「foot」
(3) （0～9のうちから）数字を一つ思い浮かべる
　　例えば「4」
(4) サイト固有の英単語を含める
　　例えば弊社サイトであれば「works」
(5) 特定の順番に組み立てる
　　→「hand$foot@4works」
これでサイト毎に違う16文字（ベースが必ず11文字）のパスワードが出来上がり！
 

【資料】できるだけ長いパスワードを利用することの計算的根拠

使用する文字の種類 最大解読時間
入力桁数
6桁 8桁 10桁 12桁
英小文字（例abc + 123） 1秒以下 8秒 59分 4週間
英大文字のみ 又は 英小文字のみ + 数字（例ABC 又は abc + 123） 1秒以下 1分 1日 4年
英大文字 + 英小文字 + 数字（例ABC + abc + 123） 1秒 2時間 4日 3000年
英大文字 + 英小文字 + 数字 + 記号（例ABC + abc + 123 + #$%） 5秒 9時間 6年 34000年

※すべての組み合わせを試すために必要な時間を試算した結果のおおよその値。計算するシステムの能力にもよる。

 

「STOP!!パスワード使い回し!!」キャンペーン

当社は一般社団法人 JPCERT/CC（JPCERTコーディネーションセンター）の「STOP!!パスワード使い回し!!」キャンペーンに賛同しています。
具体的な予防方法の詳細がJPCERT/CCのキャンペーンページにて掲載されていますので、是非ご覧下さい。

STOP!!パスワード使い回し!!キャンペーン2018（JPCERT/CC PC版）
STOP!!パスワード使い回し!!キャンペーン2018（JPCERT/CC mobile版）
STOP!!パスワード使い回し!!2018

STOP!!パスワード使い回し!!（2017）

Posted by On Filed under MAILサーバ, WEBサーバ, サーバ, システム開発, セキュリティ, ネットワーク, 事業

複数の（インターネット上の）サービスで同じログインIDとパスワードを使い回しすると、どこかのサイトから流出した可能性のあるログインID・パスワードを用いた「パスワードリスト攻撃」（または「リスト型アカウントハッキング攻撃」）などと呼ばれる方法によって、第三者に不正にログインされる恐れがあります。

近年この方法によるアカウントの乗っ取りや、不正課金利用などの被害者が増加傾向にあります。

ID・パスワードをしっかり管理しましょう
・複数のサービスで同一のID、パスワードの組み合わせを使用しない
・定期的にパスワードを変更する
・文字・数字・記号の混在した推測されにくい羅列にする
などの方法が有効です。

「STOP!!パスワード使い回し!!」キャンペーン
当社は一般社団法人 JPCERT/CC（JPCERTコーディネーションセンター）の「STOP!!パスワード使い回し!!」キャンペーンに賛同しています。
具体的な予防方法の詳細がJPCERT/CCのキャンペーンページにて掲載されていますので、是非ご覧下さい。

STOP!!パスワード使い回し!!キャンペーン2017 https://www.jpcert.or.jp/pr/2017/pr170002.html（外部サイト）
STOP!!パスワード使い回し!!

あなたのメールアドレスは何点？【やってみた】

Posted by On Filed under DKIM, DMARC, MAILサーバ, SPF, サーバ, セキュリティ, ネットワーク, 事業, 認証メール配信

突然ですが、皆さんが事業でお使いのメールアドレス（ドメイン）は何点かご存知ですか？

「そんなこと知らない」だったり「気にしたこともない」方が大半だと思います。

実は、皆さんがお使いのメールアドレス（ドメイン）はいろいろなところで『評価』され、大抵の場合『得点評価（スコアリング）』されています。

本日はその指標のひとつとして、「mail-tester」という迷惑メール度を判定してくれるサービスをご紹介します。

mail-testerサービスの概要
サイトに表示されるメールアドレスへ判定して欲しいメールアドレス/ドメインからメールを送信すると、様々な観点からチェックを行い、10点満点で評価をしてくれます。
また、評価項目毎に採点理由を表示してくれるため、改善ポイントがわかります。
送信したメールがどうして迷惑メールフォルダに入ってしまうのか判断の目安にすることができます。

主なチェック項目
○ SpamAssassinによる評価
○ メールのフォーマット
○ 各種認証設定の適用状況
　・SPF
　・Sender ID
　・DKIM
　・DMARC
○ 送信元IPアドレスの逆引き
○ 主なブラックリストへの登録状況

利用方法

1日に3回までならユーザ登録不要・無料で利用できます。
使い方もとても簡単です。

  1. サイトにアクセスして、テストメールを送信する宛先メールアドレスを確認します。
    mail-tester.com キャプチャ 1
  2. 上で確認したチェック用の宛先メールアドレスにテストしたいドメインのメールアドレスからメールを送信します。
  3. メールを送信後、しばらくしたら「THEN CHECK YOUR SCORE」ボタンをクリックします。
  4. 結果が表示されます。今回は某レンタルサーバーのデフォルトドメインのメールアドレスからメールを送信してみました。
    mail-tester.com キャプチャ 25点というなんとも怪しい雲行きの評価です…
    減点5点の内訳は次の評価項目でご確認ください。
  5. 「SCORE」が表示された下に、評価項目と項目ごとのマイナス点が表示されます。各項目の詳細な採点理由と対策が表示されます。
    mail-tester.com キャプチャ 3SpamAssassin（スパムフィルタ）に「スパム」である可能性として約2点減点されています。
    IPアドレスベースの送信ドメイン認証として、SPF/Sender IDが設定されていないため、それぞれ1点ずつ減点され、
    電子署名ベースの送信ドメイン認証として、DKIMが設定されていないため、1点減点され、送信ドメイン認証で計3点減点されています。
比較用に弊社”cast.works”ドメインの”info@cast.works”メールアドレスのテスト結果もご確認ください。
mail-tester.com キャプチャ 4

【総務省資料】DMRAC導入に関する法的な留意点

Posted by On Filed under DKIM, DMARC, MAILサーバ, SPF, サーバ, セキュリティ, ネットワーク, 事業, 認証メール配信

送信ドメイン認証や25番ポートブロックといった迷惑メール対策技術は、効果的な迷惑メール対策として実用化が図られてきたところです。
　他方、こういった技術の中には、その利用が電気通信事業法に規定されている通信の秘密の保護及び役務提供における差別的取扱いの禁止に抵触するおそれがあるものもあります。
　そこで、総務省ではこうした迷惑メール対策技術に関して、法的な整理を行い、迷惑メール対策技術の導入を促進しているところです。

総務省資料 平成29年7月6日

送信ドメイン認証技術等の導入に関する法的解釈について

概要
送信ドメイン認証及び25番ポートブロックに関する法的留意点の概要 [PDF資料]

法的整理
受信側における送信ドメイン認証技術導入に関する法的な留意点 [PDF資料]
DMRAC導入に関する法的な留意点 [PDF資料]

Gmailの各種表示の意味を解説します

Posted by On Filed under DKIM, Google, MAILサーバ, SPF, SSL/TLS, サーバ, セキュリティ, ネットワーク, 認証メール配信

GoogleのWEBメールシステムであるGmailをお使いの方は、御社のお客様にも多いのではないでしょうか。

以前の記事でもお知らせ致しましたが、Gmailアドレスへ御社のドメインからメールを送信した場合、どのように表示されているかを知ると、お客様が御社をどのようなイメージで見ているか…がわかるかもしれません。

下の図は、弊社のcast.worksメールサーバーからGmailへメールを送信したものを、画面キャプチャしたものです。
弊社のメールサーバーは
・送信ドメイン認証技術（SPFとDKIM）の設定
・メールサーバー間のSSL/TLSによる暗号化
を実装しているため、注意喚起すべき表示がありません。

この記事では、図中の赤い文字の部分を解説させていただきます。

Gmailの表示解説

御社のメールサーバーが送信ドメイン認証技術に対応していない場合
WEB版GmailとAndroidでは、送信ドメイン認証技術である”SPF”または”DKIM”のどちらかで認証がされない場合、メールのプロフィールアイコンに“？”（はてなマーク）が表示されます。

また、送信者の右側に「経由」と表示される場合があり、ドメインで署名したDKIMキーがFromアドレスで使用するドメイン名と異なる署名（第三者署名）であった場合に表示されます。
Gmailで経路情報が表示されないようにするためには、正しく設定されたSPFと、DKIMが第三者署名ではなく作成者署名である必要があります。
作成者署名で登録することで、この「署名元」に独自ドメインを表示することができ、受信者からみた際のメールの信頼度が上がります。

御社のメールサーバーがメールサーバー間のSSL/TLS通信に対応していない場合
赤い鍵アイコンが表示され、「暗号化」項目に【ドメイン名】はこのメッセージを暗号化していませんと表示されます。
※正確には赤い錠アイコン

【情報追記】
送信元項目
メール送信元のサーバー情報が表示されます。
メールマガジンの配信システムなどを利用している場合は、サービス提供者のドメインが表示される場合もあります。

自社のメールアドレスから送信したメールが、Gmailで赤い文字が多く表示されている事業者さまは、是非この際にメールサーバーの乗り換えをご検討ください。

Gmailに認証に関する警告機能が追加されます

Posted by On Filed under DKIM, Google, MAILサーバ, SPF, サーバ, セキュリティ, 事業, 認証メール配信

参考リンク：
Google、「Gmail」にセーフブラウジング保護を追加 → 外部リンク

米Googleがメールサービス「Gmail」に認証に関する警告機能を追加します。
この機能の追加により、Web版とAndroid版のGmailで、SPFまたはDKIMで認証されないメールの送信者プロフィール画像・企業ロゴ欄に？マークを表示して、メールが認証されていないことをひと目で確認できるようになり、利用者が「このメールに使われているメールアドレスは危険かもしれない」という判断ができるようになります。

※貴社のメールサーバーが送信ドメイン認証技術の「SPF」あるいは「DKIM」に対応していない場合、メールの送信相手がGmailをお使いであれば「？」マークが表示されますよ…という意味です。

「あやしいメールを開くな」…注意は無意味か？

Posted by On Filed under DKIM, DMARC, MAILサーバ, SPF, サーバ, セキュリティ, 事業, 認証メール配信

米Verizonによる分析

参考リンク：
「あやしいメールを開くな」は無意味？　掛け声で終わらせない方法 → 外部リンク
米Verizonの分析では2015年に発生した900件以上のデータ侵害になりすましメールが使われた。
データ漏えい事案のうち900件以上で、フィッシングメール（なりすましメール、標的型攻撃メール）が使われ、受信者の30％が開封していたことが分かった。13％はマルウェアなどが密かに埋め込まれた添付ファイルを開き、11％はメールのリンクから誘導されるフィッシングサイト（なりすましサイト、偽サイト）にアクセスして個人情報などを入力してしまっていたことも判明した。
「あやしいメールを開くな」とよく言われるが、同社は補完的な対応が不可欠だと指摘する。

求められる「三位一体の対策」

前回のエントリー「三位一体の対策を – IPAが標的型攻撃に注意喚起」でも記載しましたが、もう一度さらに平易な言葉な置き換えて記載しておきたいと思います。

メールに対する警戒意識の向上と維持

      「あやしいメールを開くな」と普段から指示を行うことについて、間違っているとは思いません。
      が…現在のシステムにおいては「作業者が故意に開かなくても」システムの脆弱性を突いてセキュリティ上の重大な問題を引き起こすマルウェア・ウイルスが存在します。
      このような状況を利用者（従業員）がしっかりと認識をしたうえで警戒心の向上・維持を行うことが求められています。

受信メールの真正性を保証する仕組みの導入

      最近のメールは見た目で「あやしいメール」かどうかが判断できないほど巧妙になっています。
      なりすましメールへの対応策として「見た目」ではなく、「送信ドメイン認証」（SPF・DKIM）等のシステマチックな対応が必要です。

個人情報を保有するデータベースをインターネットにアクセスするネットワークから切り分ける

      外部からのメールを受信するためだけに、VirtualBOXなど仮想化された環境を準備し、その仮想化PCの中のメール受信ソフトでメールを受信するようにします。
      このようにすることにより、万一ウイルス等に感染しても、会社内のネットワークを直接汚染することがなくなります。

三位一体の対策を – IPAが標的型攻撃に注意喚起

Posted by On Filed under DKIM, DMARC, MAILサーバ, SPF, サーバ, セキュリティ, 事業, 認証メール配信

IPAによる注意喚起

標的型攻撃メールを起因とした個人情報流出の事案が後を絶ちません。
この状況に対し情報処理推進機構（IPA）は、大規模な情報漏えいに繋がりかねない企業を狙う標的型攻撃に対応するために、リテラシの向上・適切な運用管理・セキュアなシステムの構築 の三位一体で対策をする必要があると企業・組織に対して注意喚起を行いました。

参考リンク：
【注意喚起】攻撃の早期検知と的確な初動による深刻な被害からの回避を → 外部リンク

リテラシの向上・適切な運用管理 という側面から

メールに対する警戒意識の向上と維持

      非常に巧妙化している標的型攻撃メールの文面・タイトル等の内容に対し、従業員に定期的な教育を行い、攻撃メールに対する警戒心の向上・維持を図ることを勧めています。
      また、誤ってメールを開いてしまった場合も含めた、従業員から所定の担当部門への報告訓練などにも言及されています。

受信メールの真正性を保証する仕組みの導入

      なりすましメールへの対応策として「送信ドメイン認証」（SPF・DKIM）などメールの真正性を保証する仕組みの導入も検討に値する…としています。

セキュアなシステムの構築・適切な運用管理 という側面から

個人情報を保有するデータベースをインターネットにアクセスするネットワークから切り分ける

      ことが必要…としています。
      また、不審な添付ファイルを開かなければならない場合については、仮想環境で開くなど添付ファイル確認用の環境のシステム面での整備も検討を要する…としています。

スパムメールに対するセキュリティ的考察

Posted by On Filed under DKIM, DMARC, MAILサーバ, SPF, サーバ, セキュリティ

個人情報流出

旅行代理店大手JTB（ジェイティービー）が、6月14日 氏名や住所・電話番号・パスポート番号などを含む顧客情報を不正アクセスにより流出した可能性があると発表しました。

参考リンク：
不正アクセスによる個人情報流出の可能性について → 外部リンク

今回発生した事例では、「取引先を装ったメール」により偽の添付ファイルを開かせることでウイルスに感染させるという「標的型攻撃」と呼ばれる手口が使われていたようです。

スパムメール – 標的型攻撃

「標的型攻撃」でターゲットに送信されるメールは「スパムメールとわかりにくく」なってきています。
特定の企業や団体、組織を狙い、ウェブ上に公開されている組織の情報を用いたり、実在する企業名や担当者を用い、メールヘッダーを偽装することで、見かけ上本物の業務メールのように見える点が特徴で、メールの内容も「お世話になっております」など一般的にビジネスで使われる文章を使い、スパムメールに気をつけていても見分けがつかないほど巧妙に作成されている場合が多くなってきました。

標的型攻撃のここから先の流れは、

  • 偽装された添付ファイルを開かせることでウイルスに感染させるパターン（主流）
  • 悪意を持ったURLへのアクセスを誘導するパターン

となってきます。

スパムメール – ばら撒き型攻撃

また「標的型攻撃」に似た手法として「ばら撒き型攻撃」という手法も存在します。
「ばら撒き型攻撃」は標的型攻撃のように特定の企業や団体を標的にしたものではなく、不特定多数のメールアドレスに向けて発信され、個人のメールアドレス宛てに届くメールでも、ウイルス感染のリスクが増えてきました。

メールのセキュリティ向上 – 送信ドメイン認証（SPF・DKIM）

このように「スパムメール」を配信する悪質な利用者は「他者に成りすます」ことで自分たちの目的を遂行します。
ではどのようにすれば、自社に成りすまされることがなく、自社の顧客を守ることができるのか？
この問いに答えるのが「送信ドメイン認証」という技術（SPF・DKIM）です。

「自社のサーバーから送信した」ことを証明する「送信ドメイン認証」（SPF・DKIM）を実装したサーバーからメールを送信することは、「自社であること」を証明します。
言い換えれば「他社の証明されていないメール」は「スパムである」ことを証明することに繋がります。

自社のドメインを「送信ドメイン認証」に対応させることにより、自社とお客様を守るという需要はますます増えきます。
顧客の信用は、自社のセキュリティ向上により守るのです。

注:今回のJTBの事案では、メールに対するセキュリティ向上だけではなく、社内のネットワークについてのセキュリティ向上も必要となってくる可能性もあります。本文が長くなりますので、本投稿ではこの内容を扱いません

認証メール配信とは（送信ドメイン認証まとめ）

Posted by On Filed under DKIM, DMARC, MAILサーバ, SPF, サーバ, セキュリティ, 事業, 認証メール配信

「認証メール配信」に利用している技術、第四回は「送信ドメイン認証」についてまとめをしてみたいと思います。

このブログ第一回、第二回、第三回に書いてきましたとおり、送信ドメイン認証という技術は、大きく二種類に分けられます。
一つは送信元IPアドレスを根拠に、正規のサーバーから送られたかどうかを検証する技術で、
もう一つは、送られたメールの中に電子署名を挿入し、その正当性を検証する技術です。

実は前者にはSPF以外にもSender IDという技術があり、後者にはDKIM以外にDomainKeysという技術があります。
Sender IDはライセンスの自由性に問題があるため普及率が低く、DomainKeysは後継技術としてDKIMが策定されたため、普及しませんでした。

さらに、現在最も普及しているSPFとDKIMの送信ドメイン認証技術の認証結果を基に、自動でアクセスを制御したりレポーティングしたりできるようにする仕組みとしてDMARCが策定されましたが、未だ一般的に利用されている技術ではないのが実情です。

送信ドメイン認証のまとめ

【送信元IPアドレスを根拠に、正規のサーバーから送られたかどうかを検証する技術】
・SPF（Sender Policy Framework） → 第一回参照
・Sender ID → ライセンスの自由性に問題

【送られたメールの中に電子署名を挿入し、その正当性を検証する技術】
・DomainKeys → 後継技術としてDKIM
・DKIM（DomainKeys Identified Mail） → 第二回参照、第三回参照

【SPFとDKIM両方を利用する、次世代の送信ドメイン認証技術】
・DMARC（Domain-based Message Authentication、Reporting & Conformance） → 2012年1月、Google・Facebook・Microsoftをはじめ15社の企業がスパムやフィッシングの脅威撲滅を目的としたワーキンググループ。未だ普及率云々というフェーズではない

『認証メール配信』はどうして迷惑メールになりにくいのか まとめ

・SPFを利用し、全てのヘッダ情報においてドメインが一致しているから
・メールサーバのIPアドレスを逆引きした時に返ってくるホスト名のドメインでメールを送信するから
・DKIMを利用し、電子署名には第三者署名ではなく作成者署名を用いているから

目次へ戻る