gpg(GNU Privacy Guard)

鍵の生成

$ gpg –gen-key

初めて鍵を生成する際にはかなりの時間を要する。応答がないので、ハングアップしているようにみえるが、辛抱強く待つ必要がある。なお、鍵の生成を自動化する場合には、予め設定ファイルを作成の上、
$ gpg –batch –gen-key (設定ファイル)
とする。2048bitの公開鍵(RSA)設定ファイルの書式例は、下記のようになる。

%echo Generating a basic OpenPGP key
 Key-Type: RSA
 Key-Length: 2048
 Subkey-Type: RSA
 Subkey-Length: 2048
 Name-Real: (Real Name)
 Name-Comment: (コメント名)
 Name-Email: (メールアドレス)
 Expire-Date: (有効期限)
 Passphrase: (パスフレーズ)
 %commit
 %echo done

公開鍵の確認

$ gpg --list-keys

秘密鍵の確認

$ gpg --list-secret-keys

公開鍵のエクスポート

$ gpg --export -a '(gpg --gen-keyで指定したReal Name)' > エクスポートファイル名

鍵(公開鍵、秘密鍵共通)のインポート(エクスポートした鍵を他の環境にてインポートする)

$ gpg --import (エクスポートファイル名)

鍵の検証

$ gpg --fingerprint -a '(gpg --gen-keyで指定したReal Name)'

鍵の信頼

$ gpg --sign-key -a '(gpg --gen-keyで指定したReal Name)'

※–batch オプションはうまくいかなった

ファイルの暗号化

$ gpg -e -r (gpg --gen-keyで指定されたメールアドレス) (暗号化したいファイル)

暗号化したファイルには、.gpgという拡張子が付加される。

gpg –gen-keyで指定されたメールアドレスが同一となっている公開鍵がある場合には、最も古い鍵が使用されるようだ。鍵を指定したい場合には、–list-keysで表示される鍵のIDを代わりに使用するようにした方がよい。(鍵が更新される前提で、余り気にしないでもよいようになっているようだが、調査が必要)

ファイルの復号

$ gpg (暗号化されたファイル)

管理している鍵より対応する秘密鍵にて復号される。

鍵の失効

$ gpg --output (作成する失効証明書ファイル名) --gen-revoke -a '(gpg --gen-keyで指定したReal Name)'

作成された失効証明書をインポートすると、公開鍵が使用できなくなる。(秘密鍵自体は有効なので、公開鍵を使った暗号化はできないが、失効証明書をインポートする前に暗号化されたファイルを秘密鍵を使って復号することは可能)

鍵の削除

$ gpg --delete-secret-keys (鍵ID)
$ gpg --delete-keys (鍵ID)

鍵を削除する際には、秘密鍵を同時に管理している場合には、秘密鍵を先に削除する必要がある。

参考)

秘密鍵のエクスポート

$ gpg --export-secret-key -a '(gpg --gen-keyで指定したReal Name)' > エクスポートファイル名

参考サイト

gpg (GNU Privacy Guard)の使い方

gpgでのファイルの暗号化基礎

gpgで秘密鍵を作成する

鍵の自動生成(オフィシャルサイト/英文)

クラウドサービスで割り当てされるIPアドレス

クラウドサービスで割り当てされるIPアドレスは一度ブラックリストに載っていないかチェックしてから運用した方がよさそう。
前の所有者の悪い行いでブラックリストに登録されていると、メールが届かないとか、いろんなトラブルに巻き込まれそう。。。
TrendMicro
Symantec
ブラックリストのデータベースの信頼性も疑わしい。もう少ししたらレピュテーションサービスの意図的なフォルスポジティブによって、インターネットが支配される日が来るかもしれない。

NASで稼働しているSambaの脆弱性対策について考える

バッファローのNAS LS210D0301のファームウエアのバージョンアップ通知があったので、何の修正かと思ったら、1ヵ月以上前に報告されていた
CVE-2017-7494 Sambaの脆弱性により、リモートから任意のコードが実行可能な脆弱性
の対応だった。もう少し早くならないものか。。。。
もうすでに販売終了品だし、周辺機器メーカからすれば、どこまでサポートしなきゃいけないんだという話も出てきそうな内容だが。。。。
というか自分もこのCVEの情報を把握していなかったのも問題だし、NASがSambaで動いているという推測が働かないのもまずいなぁ。。。。と反省。

個人情報のオプトアウト

会員登録しているジェームスのDMが先日届き、よく見たところ裏面に提供された個人情報をカーディーラに提供する
提供することに同意できない場合には、連絡してください
といった趣旨の記載があった。
個人情報提供者が、本人の同意を得ることなく第三者に個人情報を提供するのは個人情報保護法に違反するのでは?
と思って調べてみました。
結論としては、個人情報保護法23条2項に明記されている例外的に個人情報の第三者提供(販売)できるオプトアウトという手法に該当しており、
手続に問題なければ違法ではないというのが見解のようだ。
DMが家に届く=送付元に個人情報を提供している
ということなので、DMは捨てないでよく見ておかないとオプトアウトされる恐れがあり、本人の意図に反して、個人情報が拡散するという怖いリスクがある。
本人の要求があった場合に第三者提供を停止する運用を行っている
といっても、第三者に提供済みの個人情報は削除されるかどうかはかなり怪しい。。。。
まとめると、(当たり前の話だが)個人情報を提供するのは最小限にとどめておいた方がよいということだ。
改正個人情報保護法でオプトアウトの手続はどう変わったか
個人情報販売の適法要件(オプトアウト)

Let’s Encrypt でのSSL証明書更新に失敗する

このブログサイトでもお世話になっているLet’s Encryptの話題。
Let’s Encryptでいつもと同じように証明書の有効期間の更新を行おうとしたところ、成功したFQDNと失敗したFQDNがあった。
エラーメッセージにあるようなDNSレコードが間違っているような状態でもなく、おそらくcertbotのバージョンの非互換があるように思える。
※更新前に使用したcertbotのバージョンによっては、失敗している感じ?
$ sudo ./certbot-auto renew –pre-hook “systemctl stop httpd” –post-hook “systemctl start httpd”
Upgrading certbot-auto 0.9.3 to 0.12.0…
Replacing certbot-auto…
Creating virtual environment…
Installing Python packages…
Installation succeeded.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
——————————————————————————-
Processing /etc/letsencrypt/renewal/(成功したFQDN).conf
——————————————————————————-
Cert is due for renewal, auto-renewing…
Running pre-hook command: systemctl stop httpd
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for (成功したFQDN)
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0011_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0011_csr-certbot.pem
——————————————————————————-
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/(成功したFQDN)/fullchain.pem
——————————————————————————-
——————————————————————————-
Processing /etc/letsencrypt/renewal/(失敗したFQDN)
——————————————————————————-
Cert is due for renewal, auto-renewing…
Pre-hook command already run, skipping: systemctl stop httpd
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for (失敗したFQDN)
Waiting for verification…
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/(失敗したFQDN) produced an unexpected error: Failed authorization procedure. zaiteku.jp (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to (失敗したFQDN). Skipping.
The following certs are not due for renewal yet:
/etc/letsencrypt/live/(成功したFQDN)/fullchain.pem (skipped)
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/(失敗したFQDN)/fullchain.pem (failure)
Running post-hook command: systemctl start httpd
3 renew failure(s), 0 parse failure(s)
IMPORTANT NOTES:
– The following errors were reported by the server:
Domain: (失敗したFQDN)
Type: connection
Detail: Could not connect to (失敗したFQDN)
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
下記方法によって更新したらうまくいった。ただ、Webサービスを一度停止させなければならない点が問題。
$ sudo systemctl stop httpd
$ sudo ./certbot-auto certonly –standalone -d (失敗したFQDN)
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for (失敗したFQDN)
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0013_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0013_csr-certbot.pem
IMPORTANT NOTES:
– Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/(失敗したFQDN)/fullchain.pem.
Your cert will expire on 2017-06-09. To obtain a new or tweaked
version of this certificate in the future, simply run certbot-auto
again. To non-interactively renew *all* of your certificates, run
“certbot-auto renew”
– If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
$ sudo systemctl start httpd

SSL(TLS)通信について

TLSはHTTPSプロトコルやFTPSプロトコルをはじめとした、多くの暗号化通信において、トランスポート層にて利用されている。
今回、太陽光発電のリモコンが集計サーバとうまく通信できていないことの原因を調べるため、RTX1200のポートミラーリング機能を使ってパケットをキャプチャしてみたところ、
Enrypted Alertメッセージがリモコンから集計サーバへの通信時に発生したことを契機にサーバ側から通信が切断(FINフラグが設定)されていることがわかり、原因調査のためにいろんなサイトを探してみた。
Enrypted Alertメッセージが発生した原因は、WiresharkでSSL通信の中身を覗いてみるによれば、Wiresharkにて集計サーバの秘密鍵がないことによって発生しているようで、
なぜうまく通信ができないかの理由にはたどり着けなかったが、よい勉強になったので紹介しておく。
通信できなかった理由については、ミラーリング機能にて取得したポケットを集計サーバの管理会社へ送付し、問い合わせしてみようと思う。
参考サイト
SSL/TLS(Part.1)
HTTPSコネクションの最初の数ミリ秒
SSL Troubleshooting with Wireshark and Tshark (by Sake Blok)

2級FP技能士の仲間入り

平成28年9月11日(日)実施の2級ファイナンシャル・プランニング技能検定でなんとか合格でき、2級FP技能士になれた。
士業なのに、資格名称の独占使⽤権しか認められておらず、これではまったく飯は食えない。幅広い金融知識を学べた点は良い意味のスキルアップではあったが。。。。
そういう意味では、本日から登録が始まった情報処理安全確保支援士も同じ。
あいにく情報セキュリティアドミニストレータは持っていてもテクニカルエンジニア(情報セキュリティ)やセキュリティスペシャリストではないので、登録する資格すらないのだが、人材不足だと言っている一面がありながら、門戸が狭く資格登録に約2万円、資格維持に3年間で約15万円かかるって微妙な位置づけ。

Let’s Encrypt でのSSL証明書作成

無償でSSL証明書を発行できるLet’s Encrypt。HTTPS対応は必須になりつつある。
ちなみにこのブログもLet’s Encrypt でSSL証明書を取得している。
Let’s Encrypt の使い方を基に実際にやってみた。
バージョンが変わると一部実装が変わるので、最新はコマンド一覧を参考にしてほしい。
証明書を取得したいFQDNをwww.hogehoge.com、そのDocumentRootが/var/www/www.hogehoge.com/ として記載する。
証明書を発行する場合
Webサーバを停止した状態で、証明書を取得する場合
$ sudo ./certbot-auto certonly –standalone -d www.hogehoge.com
Webサーバを停止せずに証明書を発行する場合
$ sudo ./certbot-auto certonly –webroot -w /var/www/www.hogehoge.com/ -d www.hogehoge.com
x Saving debug log to /var/log/letsencrypt/letsencrypt.log x
x Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org x
x Obtaining a new certificate x
x Performing the following challenges: x
x http-01 challenge for zaiteku.jp x
x Using the webroot path /var/www/www.hogehoge.com/ for x
x all unmatched domains. x
x Waiting for verification… x
x Cleaning up challenges x
x Generating key (2048 bits): x
x /etc/letsencrypt/keys/****_key-certbot.pem x
x Creating CSR: /etc/letsencrypt/csr/****_csr-certbot.pem
IMPORTANT NOTES:
– Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/www.hogehoge.com/fullchain.pem. Your cert will
expire on YYYY-MM-DD(有効期限). To obtain a new or tweaked version of this
certificate in the future, simply run certbot-auto again. To
non-interactively renew *all* of your certificates, run
“certbot-auto renew”
– If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
証明書を更新する場合
$ sudo ./certbot-auto renew
ただ、この場合にはWebサーバを停止させる必要がある。
Saving debug log to /var/log/letsencrypt/letsencrypt.log
——————————————————————————-
Processing /etc/letsencrypt/renewal/www.hogehoge.com.conf
——————————————————————————-
Cert is due for renewal, auto-renewing…
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for www.hogehoge.com
——————————————————————————-
Port 443 is already in use by another process. This will prevent us from binding
to that port. Please stop the process that is populating the port in question
and try again. For automated renewal, you may want to use a script that stops
and starts your webserver. You can find an example at
https://certbot.eff.org/docs/using.html#renewal . Alternatively you can use the
webroot plugin to renew without needing to stop and start your webserver.
——————————————————————————-
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/www.hogehoge.com.conf produced an unexpected error: At least one of the required ports is already taken.. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/www.hogehoge.com/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)
無停止による証明書の更新方法について
下記コマンドで無停止で実行しようと思ったがうまくいかない
$ sudo ./certbot-auto renew –webroot -w /var/www/www.hogehoge.com/ -d www.hogehoge.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Currently, the renew verb is only capable of renewing all installed certificates that are due to be renewed; individual domains cannot be specified with this action. If you would like to renew specific certificates, use the certonly command. The renew verb may provide other options for selecting certificates to renew in the future.
下記コマンドでWebサーバの停止→証明書の更新→Webサーバの開始が可能(証明書の更新対象がない場合には再起動しない)
$ sudo ./certbot-auto renew –pre-hook “systemctl stop httpd” –post-hook “systemctl start httpd”
1.更新対象がある場合は次のようになる。
——————————————————————————-
Processing /etc/letsencrypt/renewal/www.hogehoge.com.conf
——————————————————————————-
Cert is due for renewal, auto-renewing…
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Running pre-hook command: systemctl stop httpd
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for www.hogehoge.com
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0004_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0004_csr-certbot.pem
——————————————————————————-
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/www.hogehoge.com/fullchain.pem
——————————————————————————-
2.更新対象がない場合には下記のようになる。
Saving debug log to /var/log/letsencrypt/letsencrypt.log
——————————————————————————-
Processing /etc/letsencrypt/renewal/www.hogehoge.com.conf
——————————————————————————-
Cert not yet due for renewal
The following certs are not due for renewal yet:
/etc/letsencrypt/live/www.hogehoge.com/fullchain.pem (skipped)
No renewals were attempted.
No renewals attempted, so not running post-hook

Script Insertion

スクリプト注入。
掲示板などの書き込みができるサイトにおいてサニタイジング(無害化:たとえば、エンコーディングなどの処理)が不十分である場合にスクリプトが書き込まれ、それを閲覧したユーザーがスクリプトを実行してしまう。
Webアプリケーションの脆弱性も参照のこと。

SHA-1 Broken

以前、SHA-1の暗号アルゴリズムのハッシュ値が衝突するというニュースが駆け巡ってどうやってDBへパスワードを保持するときにどの暗号化方式を使えばよいか迷ったことがある。
詳しい概要については、@ITにて参考にすることができる。