セキュリティ


2017年7月17日

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

クラウドサービスで割り当てされるIPアドレスは一度ブラックリストに載っていないかチェックしてから運用した方がよさそう。
前の所有者の悪い行いでブラックリストに登録されていると、メールが届かないとか、いろんなトラブルに巻き込まれそう。。。
TrendMicro
Symantec

ブラックリストのデータベースの信頼性も疑わしい。もう少ししたらレピュテーションサービスの意図的なフォルスポジティブによって、インターネットが支配される日が来るかもしれない。

2017年7月 2日

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

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

というか自分もこのCVEの情報を把握していなかったのも問題だし、NASがSambaで動いているという推測が働かないのもまずいなぁ。。。。と反省。

2017年4月12日

個人情報のオプトアウト

会員登録しているジェームスのDMが先日届き、よく見たところ裏面に提供された個人情報をカーディーラに提供する
提供することに同意できない場合には、連絡してください
といった趣旨の記載があった。

個人情報提供者が、本人の同意を得ることなく第三者に個人情報を提供するのは個人情報保護法に違反するのでは?
と思って調べてみました。

結論としては、個人情報保護法23条2項に明記されている例外的に個人情報の第三者提供(販売)できるオプトアウトという手法に該当しており、
手続に問題なければ違法ではないというのが見解のようだ。

DMが家に届く=送付元に個人情報を提供している
ということなので、DMは捨てないでよく見ておかないとオプトアウトされる恐れがあり、本人の意図に反して、個人情報が拡散するという怖いリスクがある。

本人の要求があった場合に第三者提供を停止する運用を行っている
といっても、第三者に提供済みの個人情報は削除されるかどうかはかなり怪しい。。。。

まとめると、(当たり前の話だが)個人情報を提供するのは最小限にとどめておいた方がよいということだ。

改正個人情報保護法でオプトアウトの手続はどう変わったか
個人情報販売の適法要件(オプトアウト)

2017年3月10日

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

2017年1月21日

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)

2016年10月24日

2級FP技能士の仲間入り

平成28年9月11日(日)実施の2級ファイナンシャル・プランニング技能検定でなんとか合格でき、2級FP技能士になれた。

士業なのに、資格名称の独占使⽤権しか認められておらず、これではまったく飯は食えない。幅広い金融知識を学べた点は良い意味のスキルアップではあったが。。。。

そういう意味では、本日から登録が始まった情報処理安全確保支援士も同じ。
あいにく情報セキュリティアドミニストレータは持っていてもテクニカルエンジニア(情報セキュリティ)やセキュリティスペシャリストではないので、登録する資格すらないのだが、人材不足だと言っている一面がありながら、門戸が狭く資格登録に約2万円、資格維持に3年間で約15万円かかるって微妙な位置づけ。

2016年8月11日

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

2008年6月 2日

Script Insertion

スクリプト注入。

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

Webアプリケーションの脆弱性も参照のこと。

2008年5月 1日

SHA-1 Broken

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

詳しい概要については、@ITにて参考にすることができる。

2007年7月 3日

セキュリティと利便性

つい先日、メインバンクの新生銀行のログイン方法が強化されて、口座番号+パスワード+ログインパスワードの従来の認証パターンに乱数表による認証が追加された。

おそらく推測されやすいパスワードによる不正アクセスに対応したものなのかもしれないが、さすがに乱数表を入れられてしまうと覚えられないので乱数表を持ち歩かなきゃいけなくなってしまう。

乱数表をなくしてもログインされることはないだろうけど、再発行されるまでログインできない。

セキュリティ強度を上げれば使いにくいシステムになることは仕方ないわけだけど、ユーザーのリスク認識に応じてセキュリティ強度を選べるようにしてほしい。

2006年9月21日

様々な攻撃手法

ブルート・フォース攻撃 総当り攻撃。効率が最も悪い。

Dos攻撃 特定のホストまたはネットワークへのネットワーク負荷を多くすることで、事実上サービス停止にする攻撃。

2006年6月11日

Webアプリケーションの脆弱性

Webアプリケーションには主に14の脆弱性が含まれるらしい。

・XSS(Cross Site Scripting)
不正なスクリプトを埋め込ませることでクッキー情報などを他サイトに送りつけ不正取得などを可能にする。
参考サイト:マルチバイトの落とし穴

・Script Insertion
リクエスト内容がそのまま表示されてしまう脆弱性を悪用し、Javascriptをはじめとするスクリプトを埋め込むことで掲示板などを訪れたユーザーのCookie情報を取得したり、フィッシングを仕掛けたりできる。

・SQL Injection
正規のSQLに不正なコードを埋め込むことで、異なる条件による問い合わせや、まったく予期されない問い合わせを可能にする攻撃手法。

・CSRF(Cross Site Request Forgeries)

・ヌルバイト攻撃
ヌルバイトは文字列の終了を示すC言語の仕様を悪用した攻撃手法。バイナリセーフでない場合には、ヌルバイト以降に不正なコードを仕込むことでコード内に含まれるチェック機構をバイパスできる。

・Directory Traversal
予期しないディレクトリへのアクセスを可能にする攻撃手法。チェックさえ正しくされていればこのようなことは起こらないが、上位ディレクトリへのアクセスを許してしまうことで、Webアプリケーション実行ユーザーが許可されているファイルを取得できてしまう。

・HTTPレスポンス分割攻撃

・インクルード攻撃
PHPが外部URIをインクルードできてしまうため、他サイトの悪意あるコードを実行できてしまう。includeファイルにユーザーが入力可能な文字列を含めてしまうということ自体がそもそも脆弱性である。

・eval利用攻撃

・外部コマンド実行攻撃

・ファイルアップロード攻撃

・セッションハイジャック
セッションキーを無理やり指定してプログラムを実行させ、実行してしまったユーザーのセッション情報を後ですべて取得する方法。

・スパムメール踏み台攻撃
メール送信フォームが任意のユーザーに送れる場合に利用可能な攻撃方法。メール送信フォーム自体がスパムメール送信装置となってしまう。


XSSとSQL Injectionはかなり有名だが、ほかにも多くの脆弱性が考えられるとは。
PHPサイバーテロの技法にはこれらがサンプルコードとともに掲載されているので非常に分かりやすい。