2016-07-07

マクニカネットワークス、日本を襲った大規模な攻撃キャンペーンを分析した「標的型攻撃の実態と対策アプローチ第1版」を公開

本レポートでは、マクニカネットワークスが2014～2015年に多く観測されたEmdiviと呼ばれるRAT（Remote Access Trojan）が用いられた攻撃キャンペーンを分析し、攻撃者が使う手法（TTPs = Tactics, Techniques, and Procedures）と、標的型攻撃に従来からよく見られるTTPs、そして企業の成熟度に応じた対策の考え方を解説しています。

とのことです。

詳細なレポートは以下のページからダウンロード可能です。

www.macnica.net

2016-07-02

パスワードに文字数制限があるサイトはヤバイ

パスワードに文字数制限があるのは、つまりデータベースのカラムに文字数制限がある。

したがって、平文で保存している可能性が高い。

2016-06-28

ぼくのかんがえたさいきょうのパスワード管理

ちまたでは【パスワードの定期変更は意味がある／ない】の議論がつきませんが、みなさまいかがお過ごしでしょうか。

自分なりに満足の行くアカウント管理ができつつあるので、紹介したいと思います。

モットーは【簡単かつセキュアに】

こうやりたい。しかも簡単に。

実現したいのはこんなアカウント管理です。

スマホでもPCでも同じように管理する
メールアドレスを登録するサイト毎に変更する
パスワードを登録するサイト毎に変更する
- 可能な限り、20文字以上で大文字小文字数字記号が入り乱れたものにする。
あんまりブラウザのパスワード記憶に頼りたくない。

いやいや、無理やん。

面倒くさい。

メールアドレスとか何個作らなあかんねんと。

パスワード、覚えられるわけがないと。

けど、できちゃうんです。相当楽に。

用意するもの

用意するものは3つだけです。

Gmail
Dropbox
keepassx

なぜ、google アカウント？というのは後述します。

GmailはGoogle の提供するメールサービス、 Dropbox はファイル共有サービスです。

keepassx はオープンソースのパスワード管理ソフトです。聞き慣れないアプリかもしれませんが、MacでもWindows でもLinuxでも使えるすぐれものです。

Mac 製品しか使わないって人はkeepassx の代わりに、1Password がいいと思います。(Androidのクライアントもあるようです)

ぼくのかんがえたさいきょうのパスワード管理

登録時

サイトに登録するときは次のようにしています。

メインのメールアドレスをcameong@gmail.com とします。

keepassx のデータベースをDropbox につくる (初回だけ)
メールアドレスをcameong+"ランダムな文字列"@gmail.com で登録する
パスワードを20文字以上のランダムなものを作る
メールアドレスとパスワードとサイトドメインをkeepassx に保存する。
Dropbox を使う端末(PC, スマホ)で連携する

ランダムなパスワード生成は mac だと pwgen などを使うといいでしょう。

cameong.hatenablog.com

--- 追記 2016/7/2 ---

keepass に標準のパスワード生成機能があるようです。

こちらも便利ですね！

gyazo.com

追記ここまで

注意点としては

アカウント情報の更新をする端末を決めておきましょう
- じゃないとkeepassx のデータベースが壊れるかもしれません
- すくなくともiPhone はkeepassxのデータをデバイス内に保存してるので、リアルタイムに同期はしていません。
- ぼくはPCで更新するようにしています
- 【追記】↑リアルタイム同期しているとの報告も受けました。設定によって変更できるかも。
keepassx に鍵をかけるか暗号化しましょう
サイトのドメインも忘れずに登録しておきましょう

ログイン時

サイトにログインするときは、すごく簡単です。

ログイン画面に行く
keepassx を開く
サイトのドメインを検索し
id, password をそれぞれkeepassx からコピペする

おしまい。簡単ですね。

PCでもスマホでも同じアクションでログインできます。

解説

すこし、解説します。

cameong+"ランダムな文字列"@gmail.comはちゃんと自分のところにとどくのか？

はい、届きます。

Gmailの仕様でメールアドレスのローカルパート(@より前) の+以降は無視され、+より前のメールアドレス宛に届きます。

ですので、cameong+"ランダムな文字列"@gmail.com は全て cameong@gmail.comに届く寸法になります。

もし、Gmail 以外に同等の機能のあるメールサービスがあれば、なにを使っても大丈夫です。(あったら教えて下さい)

--- 追記 2016/7/2 ---

@icloud.com も同様の機能があるようです。( from id:takuya_1st )

追記ここまで

パスワード忘れた時

パスワードを忘れた時、通常であれば、パスワードリセットフォームからメールアドレスを入力するのですが、この方法だとメールアドレスを記憶しておくのは無理です。

基本的にはkeepassxにどのサイトをどのメールアドレスを利用しているか保存してあるはずなので、keepassx を見れば大丈夫です。

もし、keepassx に書きわすれていた時は、、、Gmailで登録したサイトのドメインを検索してください。

(普通であれば)登録したメールアドレス宛にアカウント有効化のメールが届いているはずなので

有効化のメールを探す。
To アドレスを調べる。

この方法で登録アドレスがわかると思います。

なぜメールアドレスをサイトごとに変更するのか

メールアドレスに+hash を足してサイトごとの登録メールアドレスを変えているのは、【登録しているサイト以外にメールアドレスを知られたくない】ためにおこなっています。

たとえば、

サイトAで cameong+AAA@gmail.com のメールアドレスを登録
サイトBでcameong+BB@gmail.com のメールアドレスを登録

していたとします。

もしサイトAのメールアドレスとパスワードが流出した場合、サイトBのメールアドレスを検知するのは困難ですので

サイトBと称してcameong@gmail.com宛にメールが送られてくると怪しいわけです。(サイトBからはcameong+BB@gmail.com宛に送られてくる。)

ソーシャルハッキングがますます増えている昨今では、+hash は一定の効果があるのではないかと思います。

パスワード流出の二次被害防止のために、最低限でもサイトごとに異なるパスワードを登録してください。

2段階認証

大本のメールアドレスを他人に乗っ取られてしまうと↑でやったことが意味なくなってしまいますので、2段階認証を使って強固にしましょう。

ぼくは2段階認証のクライアントにauthy を使っています。

はじめはauthenticator を使っていたのですが、登録できる端末が1つしか無いので、もしその端末が水没したりすると終わるので、複数デバイスで利用可能なauthy を利用しています。

(authentiator でも端末が使えなくなった時のためにリカバリープランはあるのですが、面倒くさくて）

www.appbank.net

運用しながら、管理方法を改善しています。

こんな管理方法があるよ！などありましたら、コメント欄等でおしえてください。

それでは、よいパスワード管理ライフを！

--- 追記 2016/7/2 ---

keepass より高機能なパスワード保存アプリには次のようなものがあります。

1Password

www.motex.co.jp

Dashlane www.dashlane.com

どちらもマルチデバイス対応しているようなので、試してみたいと思います。

追記ここまで

2016-05-07

Google Cloud Storage をnginx でhttpsで公開する

Google Cloud Storage(GCS) は独自ドメインでファイルを公開する機能が付いているが、http のみしか対応していない。 https で対応するには以下のようにnginxでプロキシするなどの方法を取る必要がある。

config

画像用ドメイン: static.kmn.jp バケット名: static.kmn.jp (※ https化にはlet's encrypt を利用しているため、そのための設定も入っている。)

$ cat /etc/nginx/conf.d/static.kmn.jp
# Cache 10GB for 1 Month
proxy_cache_path           /var/cache/nginx levels=1:2 keys_zone=GS:10m inactive=720h max_size=10240m;

upstream gs {
    server                   'storage.googleapis.com:443';
    keepalive                100;
}

server {
    set $my_domain "static.kmn.jp";
    server_name static.kmn.jp;

    ###
    # <tls setting>
    ###

    listen 443 ssl;
    # nginx 1.9.5 以降の場合
    # listen 443 ssl http2;

    server_name static.kmn.jp;
    server_tokens off;

    ssl_certificate     /etc/letsencrypt/live/static.kmn.jp/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/static.kmn.jp/privkey.pem;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    # 環境によっては off にすると動かないので注意 (default は on)
    ssl_session_tickets on;

    # 2048bit 推奨
    ssl_dhparam /etc/ssl/private/dhparam.pem;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
    ssl_prefer_server_ciphers on;

    ###
    # </tls setting>
    ###


    # Logs
    access_log off;
    error_log /var/log/nginx/static.kmn.jp.error.log error;

    # Cache Control
    expires max;
    add_header Cache-Control "public, max-age=31536000";

    # Nameserver
    resolver                   8.8.8.8 valid=300s;
    resolver_timeout           10s;

    # Proxy Cache
    proxy_temp_path /tmp/nginx;
    proxy_cache_lock on;
    proxy_cache_key "$uri"; # Ignore Parameters

    ## https://github.com/FRiCKLE/ngx_cache_purge
    #proxy_cache_purge on from 127.0.0.1;

    # Limit Request Methods to GET|HEAD|PURGE
    if ( $request_method !~ "GET|HEAD|PURGE" ) {
        return 405;
    }

    location / {
        proxy_set_header    Host storage.googleapis.com;
        proxy_hide_header   x-goog-hash;
        proxy_hide_header   x-goog-generation;
        proxy_hide_header   x-goog-metageneration;
        proxy_hide_header   x-goog-stored-content-encoding;
        proxy_hide_header   x-goog-stored-content-length;
        proxy_hide_header   x-goog-storage-class;
        proxy_hide_header   x-xss-protection;
        proxy_hide_header   accept-ranges;
        proxy_hide_header   alternate-protocol;
        proxy_hide_header      Set-Cookie;
        proxy_ignore_headers   "Set-Cookie";
        proxy_intercept_errors on;

        proxy_cache            GS;
        proxy_cache_valid      200 720h; # Cache For 1 Month
        proxy_cache_bypass     $http_cache_purge;
        add_header              X-Cache $upstream_cache_status;

        proxy_http_version     1.1;
        proxy_set_header       Connection "";
        proxy_pass             https://gs/$my_domain$uri;
    }
}

# let's encrypt の自動更新用の設定
server {
  listen        80;
  server_name   static.kmn.jp;

  location      '/.well-known/acme-challenge' {
  default_type  "text/plain";
    root        /tmp/letsencrypt-auto;
  }

  location / {
    return      301 https://$server_name$request_uri;
  }
}

設定反映

sudo service nginx configtest && sudo service nginx reload

参考

touhonoob/gs.nginx.conf

2016-05-07

Let's encrypt で無料SSL運用

Let's Encrypt(以下LE) の導入手順

導入手順

LE のダウンロード
前処理: Port80 でドメインの所有証明
LEで証明書取得
DH対応
LE導入後のPort443,80設定
自動更新設定

secure.example.com で導入例

LE のダウンロード

$ git clone https://github.com/letsencrypt/letsencrypt.git

前処理: Port80 でドメインの所有証明

導入前のnginx のconfig

$ cat /etc/nginx/sites-enabled/secure.example.com
server {
  listen              80;
  server_name         secure.example.com;
  location '/.well-known/acme-challenge' {
  default_type "text/plain";
    root        /tmp/letsencrypt-auto;
  }

  location / {
    root        /tmp/letsencrypt-auto;
    #return              301 https://$server_name$request_uri;
  }
}

nginx に設定を反映しておく

$ sudo service nginx configtest && sudo service nginx reload

エラーだとnginxの設定がなにかおかしい。修正するまでくりかえす。

LEで証明書取得

$ MAIL="your_mail_address@example.com"
$ /home/cameong/letsencrypt/letsencrypt-auto certonly --webroot --webroot-path /tmp/letsencrypt-auto/ -d secure.example.com --server https://acme-v01.api.letsencrypt.org/directory -m $MAIL

下みたいになればok

Checking for new version...
Requesting root privileges to run letsencrypt...
   sudo /home/cameong/.local/share/letsencrypt/bin/letsencrypt certonly --webroot --webroot-path /tmp/letsencrypt-auto/ -d secure.example.com --server https://acme-v01.api.letsencrypt.org/directory -m your_mail_address@example.com

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/secure.example.com/fullchain.pem. Your
   cert will expire on 2016-07-20. To obtain a new version of the
   certificate in the future, simply run Let's Encrypt again.
 - If you like Let's Encrypt, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

この際、公開鍵, 秘密鍵が以下のPATHに設置される

鍵	path
証明書	/etc/letsencrypt/live/secure.example.com/fullchain.pem
秘密鍵	/etc/letsencrypt/live/secure.example.com/privkey.pem

Diffie-Hellman対応

暗号強度を強めるために、DH対応を行う。

$ sudo openssl dhparam -out /etc/ssl/private/dhparam.pem 2048

LE導入後のPort443,80設定

$ cat /etc/nginx/conf.d/secure.example.com
# HTTPS サーバの設定
server {
    listen 443 ssl;
    # nginx 1.9.5 以降の場合
    # listen 443 ssl http2;

    server_name secure.example.com;
    server_tokens off;

    ssl_certificate /etc/letsencrypt/live/secure.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/secure.example.com/privkey.pem;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    # 環境によっては off にすると動かないので注意 (default は on)
    ssl_session_tickets on;

    # 2048bit 推奨
    ssl_dhparam /etc/ssl/private/dhparam.pem;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
    ssl_prefer_server_ciphers on;

    ## HTTPS のみでサービスを提供する場合にだけ設定します
    #add_header Strict-Transport-Security max-age=15768000;

    # HPKP (HTTP Public Key Pinning) に対応すると更に安全性の高い設定になりますが、運用コストが上がるのでここでは省略します。

    # OCSP Stapling に対応すると暗号化通信の開始を早めることが出来ます。ここでは省略します。

    # ドキュメントルート
    root /var/www/html/secure.example.com;
    error_page 404 /404.html;
    access_log /var/log/nginx/secure.example.com_access.log main;
    error_log  /var/log/nginx/secure.example.com_error.log error;
}

server {
  listen              80;
  server_name         secure.example.com;
  location '/.well-known/acme-challenge' {
  default_type "text/plain";
    root        /tmp/letsencrypt-auto;
  }

  location / {
    return              301 https://$server_name$request_uri;
  }
}

自動更新設定

cat /usr/local/bin/auto-update_le.sh
#!/bin/bash
DOMAINS="-d secure.example.com -d www.example.com"
DIR=/tmp/letsencrypt-auto
LETSENCRYPT="/home/cameong/letsencrypt/letsencrypt-auto"
[ -d $DIR ] || mkdir -p $DIR
$LETSENCRYPT certonly --server https://acme-v01.api.letsencrypt.org/directory -a webroot --webroot-path=$DIR $DOMAINS --force-renew && service nginx reload

cronに設定する

cat /etc/cron.d/auto-update_le
# 毎月2日10:00に鍵を更新する
0 10 2 * * root bash /usr/local/bin/auto-update_le.sh > /var/log/auto-update_le.log 2>&1

HTTPS の強度測定

ssllabsでhttpsの強度を測定する。

参照

qiita.com

cameong.hatenablog.com

2016-04-30

google webmaster tool ドメインを登録をnginx の設定だけで実現する

server ディレクションに以下を追加

/googledg2d2c1f4c67d739.htmlの箇所はwebmaster tool でアクセスするパスになります。

  location = /googledg2d2c1f4c67d739.html {
            rewrite ^/(.*)  $1;
            return 200 "google-site-verification: $uri";
    }

参考 How do I verify site ownership on Google Webmaster Tools through nginx.conf? - Server Fault

2016-04-20

Let's Encrypt を自動更新するためのNginxの設定

example.com example.jpの２つのドメインをLet's Encrypt でtls 化しているとする。

ドメイン所有の確認の理由からPort80に設定を入れる。

nginx

Port 80 の設定

server {
  listen              80;
  server_name         example.com example.jp;
  location '/.well-known/acme-challenge' {
  default_type "text/plain";
    root        /tmp/letsencrypt-auto;
  }

  location / {
    return              301 https://$server_name$request_uri;
  }
}

自動更新スクリプト

#!/bin/bash
DOMAINS="-d example.com -d example.jp"
DIR=/tmp/letsencrypt-auto
LETSENCRYPT="/PATH/TO/YOUR/letsencrypt-auto"
[ -d $DIR ] || mkdir -p $DIR
$LETSENCRYPT certonly --server https://acme-v01.api.letsencrypt.org/directory -a webroot --webroot-path=$DIR $DOMAINS --force-renew && service nginx reload

あとはこのスクリプトをcronなどに仕込む。

One-line certificate generation/renews with Letsencrypt and nginx · GitHub