ESET Endpoint Protection Standardが微妙な話

キヤノンITソリューションズから発売されているESET Endpoint Protection Standardは幅広いプラットフォームのサポートと、ライセンスがシンプルなのは非常に素晴らしいし、AWSでは月額課金のサービスもあり非常に魅力的だが、次の点で問題と感じた。

ESET Remote AdministratorはCentOSをサポートしているが、MariaDBではインストールできないというオチ。
つまり有償のOSであるWindows ServerもしくはRedHat Enterprise Linuxを入れるかCentOSで試行錯誤してMySQL入れることになりそう。(リポジトリがないため、yumでインストールというわけにはいかなさそう)
これがないと統合管理が難しく、せっかく幅広いプラットフォームへのサポートの魅力が半減?する。

サーバーOS向けウイルス・スパイウェア対策プログラム(ESET File Security for Linux)は、Webインターフェイスを提供しているがすべて英語。マニュアルが日本語なので利用面では問題ないが、いちいちマニュアルを参照しないといけないというのはいただけない。

11/20追記)
CentOSにyumでMySQL 5.7を簡単にインストールするためには、Installing MySQL on Linux Using the MySQL Yum Repositoryを参考にしてインストールできる。

CentOS 7.1であれば下記手順となる。
sudo yum install yum-utils
sudo yum install https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm
sudo yum-config-manager –enable mysql57-community
sudo yum install mysql-community-server

NIST Special Publication 800-63 Revision3

パスワードは定期的な強制的な変更を行うべきではないと記載されている文書。(変更しなくて良いとは書いていない)
パスワード運用の見直しのきっかけにもなっている。

日本語訳はIPAから出ていないので、世界の電子認証基準が変わる:NIST SP800-63-3を読み解くNIST SP 800-63-3の概要と今回の改訂がもたらす影響を参照するとよい。

原文はこちらから参照できる。

SSL Server Test

日経NETWORK 2018年9月号より

米クリオスのSSLラボが提供するSSLチェックツール
https://www.ssllabs.com/

財テク.jpというサイトをチェックしたところレーティングはBでKey Exchangeに問題があるとの判定だった。

B判定の主な原因として、下記3点があった。
This server uses SSL 3, which is obsolete and insecure. Grade capped to B.
SSL3に対応している。

This server accepts RC4 cipher, but only with older protocols. Grade capped to B.
ChiperにRC4が利用できる。

This server does not support Forward Secrecy with the reference browsers. Grade capped to B.
Foward Securityに対応していない。。。。

一方で、HSTSに対応している点は評価された。
HTTP Strict Transport Security (HSTS) with long duration deployed on this server.

SSL対応状況について

Chorome68からSSLに対応していないサイトは警告されるようになった。
「日立製作所も対応していないからといって、当社も対応する必要がありません。」
という会社があるとしたら、ホームページの重要性について理解されていないと思わざるを得ない。。。。

利用者視点で言えば、HSTSに対応していないというのもいただけないのだが、なぜSSLの対応にこれだけ腰が重いのかが理解に苦しむ。。。。

Mailsploit

Fromヘッダにヌルバイトが含まれるとSPF,DKIM,DMARCを採用して、送信元が詐称されたメールを拒否できるように対応していたとしてもクライアントメールソフトで送信元が詐称されたメールが届いてしまうように見える問題。
メールソフトが正しくヌルバイトを取り扱い出来ない場合には、送信元が正しく表示されないことで詐称されたメールと勘違いして中身を開いてしまう点が深刻である。

Mailsploitは何が脅威なのかを考えてみるに詳しく記載されている。

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で動いているという推測が働かないのもまずいなぁ。。。。と反省。