ほほほのほ - tweet:2017

FreeBSDのWeb ServerにLet's Encryptの証明書を突っ込む

anonymous@undisclosed.example.com (Anonymous) — Mon, 14 May 2018 04:51:02 +0000

FreeBSDのWeb ServerにLet's Encryptの証明書を突っ込む

かねてからの懸案だったLet's Encrypt証明書対応のメモ。

2017/02/01現在、まだFreeBSDでの動作確認をしていないので、この記事を鵜呑みにしても動かない可能性が高い。

Let's Encryptとは？

Let's Encryptは、公共の利益を図る目的で Internet Security Research Group (ISRG) が運営する、無料で利用できる自動化されていてオープンな認証局。

その基本方針は

無料
- ドメインを保持する者が無料で信頼された証明書を取得可能
運用の自動化
- 証明書の取得から更新まで自動化することが可能
安全
- 認証局サイド、管理者の両面から、最先端のプラットフォームを提供
透明性
- 証明書の発行と失効が公式に記録され、一般公開され、誰でも監査できる
オープン
- 各手続き(プロトコル)を、オープン標準として公表
互助・協力
- コミュニティの利益のための共同の取り組みであり、1つの組織によって統制されているものではない

以上、About - Let's Encrypt - Free SSL/TLS Certificatesより抜粋。

実際に利用するレベルから見ると、

無料でSSLサーバ証明書を発行してくれるサービス。
- あくまでもサーバー証明書のみであり、個人証明書などは発行しない
ドメイン認証型の証明書
- 一般に、サーバー証明書は「ドメイン認証(DV)」、「組織(企業)認証(OV)」、「実在性監査済(EV)」がありますが、DVしか発行しない
  - 無料の証明書にそこまで要求してはいけません。そのレベルの要求をするならお金を払いましょう。

というサービスを提供してくれるサイト及びサービスである。

日本語訳のサイトがあるので、是非一度見て見ることを勧める。Let's Encrypt 総合ポータル

注意点

有効期間が90日
- もう少し長くても良いような気もするが、自動化されている前提ならこれでいいのかもしれない。
- 暗号アルゴリズムの危殆化やProtocolの更新などを考えると、短い方が良いかもしれない。
秘密鍵ファイルはパスフレーズで暗号化していない
- HTTP ServerやSMTP Serverなど、Server用途で利用するなら、これはこれで仕方がないことかもしれない
- 秘密鍵ファイルの取り扱いには十分な注意をすること。SSLでHTTP部分を（多少）守ったからといって、サーバーが安全になるわけではないことに十分に留意すること
国コードや組織名の入力がない
- DV(Domain Validation)ならば、Domainが存在しており、かつ、そのドメインが正当であると判断できればよいので、国コードや組織名はなくても問題ない
- もちろん、OVやEVならば、組織の存在認定などを受けることからも、国コードや組織名は必要

事前準備

まずは、何はともあれ、公開するサイトを作成すること。今回の諸元は以下のとおり

項目	内容	備考
Platform	XenServer
VMのCPU	vCPU x2
VMのMemory	2G
VMのDisk	20G(boot)+100G(Data/DB)
NIC	vNIC2本	管理用と対外接続用
OS	FreeBSD 11.0 Release	Install時点では -p7
pkg	Head(latest)
HTTPd	NGINX	pkgからinstall
CMS	DokuWiki / WordPress	手動 install
SMTPd	Postfix	試験用
IMAPd	dovecot	試験用

Let's Encryptから証明書を取得する方法は複数ある。 Let's Encrypt自身はLet's Encryptの配布するcertbotを利用することを強く推奨している。今回は、certbot利用する。

その他の実装

acme-client
- ports/securityに収録されている。
- OpenBSDで開発されており、LibreSSLを利用している。
- Cで記述されており、余計なパッケージ類が不要
- 連絡先のメールアドレスを指定できない模様。
- すこし古い(2017/02/01時点でportsは0.1.11だが、開発元では0.1.15)

certbotを利用する

certbotはPython 2.7系用のscriptなので、Python 2.7が導入されていなければならない。まぁ、自分の場合、XenToolsが入っているので、どうせPython2.7がInstallされているから諦めるのがいいかもしれない。

まずなによりもpkgで。
- pkg install py27-certbot
  - 思ったよりも大量のpython関連モジュールが入るのでビビる。
  - これ、わからないでもないけど、勘弁して欲しい気もするなぁ。

証明書関連処理

必要なサイトのURLを確認する。ここでは、仮に、Named Virtual Hostとして、

www.example.com
www.example.org

を保持しており、管理者のMail Addressを

foo@example.net

とする。

引数関係はコマンド解説（コマンドリファレンス）を参照のこと。ちょっとだけメモ。

–rsa-key-size N : RSAの鍵長。defaultは2048。
–must-staple : OCSP Must Staple 拡張を追加。defaultは追加しない
-cert-path CERT_PATH : 証明書を保存するPathを指定する。defaultは None
–key-path KEY_PATH : 証明書のインストールや失効に用いる秘密鍵のパスを指定する。defaultは None
–config-dir CONFIG_DIR : 設定ファイルのあるディレクトリを指定する。defaultは /etc/letsencrypt
–work-dir WORK_DIR : 作業用ディレクトリを指定する。defaultは /var/lib/letsencrypt
–logs-dir LOGS_DIR : ログファイルの保存先ディレクトリを指定する。defaultは /var/log/letsencrypt

取得の前提条件

DV証明書である以上、Domainにアクセスできなければならない。したがって、上記2ドメインにhttpでアクセスするとサイトが返答する状況にしておくことが重要また、管理用のメールアドレスもちゃんとメールが受け取れるようになっていることが重要。

取得

certbot certonly --webroot \
  -w /tmp/le/com -d www.example.com \
  -w /tmp/le/org -d www.example.org \
  -m foo@example.net --agree-tos

更新

certbot certonly --webroot \
  -w /tmp/le/com -d www.example.com \
  -w /tmp/le/org -d www.example.org \
  --renew-by-default

この更新スクリプトを作成し、cronでDailyに実行すれば、勝手に証明書が取得できる。取得した証明書のTimestampを確認して、必要に応じてnginx restartすれば済むはず

問題点

上記のやり方の場合、現在の自分の構成ではうまく動作しない。現状の構成は、

                        +--- WAF1
                        |
            +--- lb1 ---+--- IPS1 ---+--- Web
Internet ---+           |            |
            +--- lb2 ---+--- IPS2 ---+--- Web
                        |
                        +--- WAF2

となっているため、Let's Encryptをlb1/lb2に仕掛けなければならない。この場合、以下の問題が発生する

証明書はlb1/2に設置されなければならない
チャレンジ(存在検査)用のTokenはWeb Server側に仕掛けなければならない

これを解決するには、

–server SERVER : ACME ディレクトリリソースの URI を指定

を利用し、URIにWebサーバー側で提供することのないURIを設定した上で、そこにチャレンジしてもらうという手が考えられる。流れはおそらく

外部のHostからLet's EncryptのTokenを引っ張ってくる
lbの設定で、nginxでいうlocation指定にあるコンテンツにTokenを記載
Let's EncryptでChllangeしてもらう

となるはず。これをacme-clientで実行できるならば、そちらでやる手もあるし、certbotでやる手もありそうだ。何れにしても、lbで処理を行うことは難しいと考えられるので、何らかのscriptを考える必要がありそうだ。

なお、Let's EncryptにおけるACMEでのドメインの検査は、http-01, tls-sni-01, dns-01の３種類があるので、dns-01を利用する手も考えられる。しかし、自分の管理しているDNSはDNS Server間での同期処理はさせず、全DNS Serverにコンテンツを個別に設置している。しかも、一部のNSは外部に設置しているので、更新処理を自動化するのは悩ましい。

なお、ACMEはInternet Draft(ID)になっており、2017/02/01現在、draft-ietf-acme-acme-04として公開されている。これを見ると、oob-01も定義されている模様。

この問題に関しては、少しゆっくり考える必要がありそうだ。

Let's Encryptを少し調べてみた

anonymous@undisclosed.example.com (Anonymous) — Fri, 03 Feb 2017 05:47:55 +0000

Let's Encryptを少し調べてみた

FreeBSDでacme-clientを利用してLet's Encryptの証明書取得を行うことを考えた。ので、ちょっと調べたメモ

Let's Encryptとは？

Let's Encryptは、公共の利益を図る目的で Internet Security Research Group (ISRG) が運営する、無料で利用でき、自動化されていて、オープンな認証局。

Let's Encryptの基本方針

無料
- ドメインを保持する者が無料で信頼された証明書を取得可能
運用の自動化
- 証明書の取得から更新まで自動化することが可能
安全
- 認証局サイド、管理者の両面から、最先端のプラットフォームを提供
透明性
- 証明書の発行と失効が公式に記録され、一般公開され、誰でも監査できる
オープン
- 各手続き(プロトコル)を、オープン標準として公表
互助・協力
- コミュニティの利益のための共同の取り組みであり、1つの組織によって統制されているものではない

(以上、About - Let's Encrypt - Free SSL/TLS Certificatesより抜粋)

実際に利用するレベルから見ると、

無料でSSLサーバ証明書を発行してくれるサービス。
- あくまでもサーバー証明書のみであり、個人証明書などは発行しない
ドメイン認証型の証明書
- 一般に、サーバー証明書は「ドメイン認証(DV)」、「組織(企業)認証(OV)」、「実在性監査済(EV)」がありますが、DVしか発行しない
  - 無料の証明書にそこまで要求してはいけません。そのレベルの要求をするならお金を払いましょう。

というサービスを提供してくれるサイト及びサービスである。

日本語訳のサイトがあるので、是非一度見て見ることを勧める。Let's Encrypt 総合ポータル

注意点

有効期間が90日
- もう少し長くても良いような気もするが、自動化されている前提ならこれでいいのかもしれない。
- 暗号アルゴリズムの危殆化やProtocolの更新などを考えると、短い方が良いかもしれない。
秘密鍵ファイルはパスフレーズで暗号化していない
- HTTP ServerやSMTP Serverなど、Server用途で利用するなら、これはこれで仕方がないことかもしれない
- 秘密鍵ファイルの取り扱いには十分な注意をすること。SSLでHTTP部分を（多少）守ったからといって、サーバーが安全になるわけではないことに十分に留意すること
国コードや組織名の入力がない
- DV(Domain Validation)ならば、Domainが存在しており、かつ、そのドメインが正当であると判断できればよいので、国コードや組織名はなくても問題ない
- もちろん、OVやEVならば、組織の存在認定などを受けることからも、国コードや組織名は必要

証明書の取得方法

Let's EncryptはDV証明書を発行するにあたって、ACME(Automatic Certificate Management Environment)を使用する。このACMEは2017/02/03現在、draft-ietf-acme-acme-04として公開されており、将来RFCになることが期待されている。

このACMEを利用した証明書取得のためのツールは様々あるが、Let's Encryptを利用するにあたっては、Let's Encryptが公開しているcertbotを利用するのが最も簡単であると思われる。

様々な実装のリストもLet's Encryptが公開している。https://letsencrypt.org/docs/client-options/

acmeで証明書を取得・失効する流れ

acme-clientのManual Pageから抄訳

証明書取得の流れは以下の通り。

CA(Let's EncryptのACME Server)に接続し、リソースリストを要求する
(Option) RSAアカウント鍵を作成・登録する
RSAアカウント鍵の確認。これは、CAへの認証とその後すべてのやりとりに利用される
各domainごとに以下の処理を行う
1. CAに対し、認証のChallengeを提出
2. Challengeへの返答ファイルを作成する
3. Cアのchallengeによる検証を待つ
展開されたRSAもしくはECDSAのdomain鍵を読み込む
そのdomain及びaltnamesに記載されたドメイン用の、domain鍵を用いたX509リクエストを作成する
X509リクエストへの署名をCAに要求する
X509証明書(Certificate)をダウンロードする
CA issureから来たX509証明書を展開する
証明書チェーンをissureからダウンロードする

証明書失効の流れも同様。

CA(Let's EncryptのACME Server)に接続し、リソースリストを要求する
(もし見つかれば)、X509証明書を読み込み展開する
X509 失効要求書を作成する
CAに失効要求書を提出
証明書、チェン、そして、全チェーンを削除する。

Challenge

ACMEにおけるChallengeとは、要するに「存在確認」を意味する。この存在確認方法として以下の３つがIDに定義されている。

http-01
tls-sni-01
dns-01

Vulsrepo on nginx with FreeBSD

anonymous@undisclosed.example.com (Anonymous) — Mon, 14 May 2018 04:51:18 +0000

Vulsrepo on nginx with FreeBSD

NGINXは標準ではCGIを動作させることができない。そこで、fcgiwrapを利用して動かしてみる。

http://qiita.com/hmikisato/items/c793ced0ba2695a89de6を参考にした。

pkg install nginx fcgiwrap
pkg install p5-CGI p5-JSON

で、fcgiwrapの設定。rc.confに以下を記載

nginx_enable="YES"

fcgiwrap_enable="YES"
fcgiwrap_user="monitor"
fcgiwrap_socket_owner="monitor"
fcgiwrap_socket="unix:/var/run/fcgiwrap/fcgiwrap.socket"

nginx.confを以下のように編集

load_module /usr/local/libexec/nginx/ngx_mail_module.so;
load_module /usr/local/libexec/nginx/ngx_stream_module.so;

worker_processes  1;
user monitor;
events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    server {
        listen       80;
        server_name  localhost;

        location / {
            root   /home/monitor/htdocs/vulsrepo;
            index  index.html;
        }

	location ~ \.cgi {
		include		fastcgi_params;
		fastcgi_pass	unix:/var/run/fcgiwrap/fcgiwrap.socket;
		fastcgi_param	SCRIPT_FILENAME $document_root$fastcgi_script_name;
		root		/home/monitor/htdocs/vulsrepo;
	}

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/local/www/nginx-dist;
        }
    }
}

そして、nginxとfcgiwrapを起動

# service fcgiwrap start
# service nginx start

次にvulsrepoを導入。 Document rootを/home/monitor/htdocs/vulsrepoにしてあるので、以下を実行。

mkdir -p ~monitor/htdocs/vulsrepo
chown -R monitor:staff ~monitor/htdocs

次に、vulsrepoをgithubから取得

monitor$ cd /home/monitor/htdocs
monitor$ git clone https://github.com/usiusi360/vulsrepo.git

vulsの出力を取り込む必要があるので、

monitor$ vuls scan 
monitor$ vuls report -to-localfile -format-json --cvedb-path=/home/monitor/vuls/cve.sqlite3

を実行した上で、

monitor$ cd /home/monitor/htdocs/vulsrepo
monitor$ ln -s /home/monitor/vuls/results .

これで、Browserからアクセスすれば、Vulsrepoの出力が見れるはず。

重要

vulsrepoのcgi script(vulsrepo/dist/cgi/getfilelist.cgi)は、sh-bang!形式で、先頭行に#!/usr/bin/perlと記載されている。FreeBSDの場合、perlをpkgで投入すると、#!/usr/local/bin/perlに修正する必要があるので、注意すること

あとは、毎日の更新問題だけ。以下のようなscriptをcronでdailyに動かせばOK

#! /bin/sh

##### Main Routine
. ~/.goenv.sh
DATE=`date "+%Y"`

${HOME}/go/bin/go-cve-dictionary fetchnvd -years ${DATE}
${HOME}/go/bin/go-cve-dictionary fetchjvn -years ${DATE}

# Run vuls
cd $HOME/vuls

${HOME}/go/bin/vuls scan
${HOME}/go/bin/vuls report -to-localfile -format-json --cvedb-path=${HOME}/vuls/cve.sqlite3

sudoersの豆

anonymous@undisclosed.example.com (Anonymous) — Wed, 08 Mar 2017 05:12:40 +0000

sudoersの豆

sudoを使っていて、

あるアカウントに対して
あるコマンドの実行権だけrootで動かせるようにしたい
その際、引き継いで欲しい環境変数がある

という難しい状況が発生することがある。まぁvulsなんだが。

こういうときには、sudoersに、こんな風に設定すればよい

vuls ALL=(ALL) NOPASSWD:/usr/bin/yum --changelog --assumeno update *
Defaults:vuls env_keep="http_proxy https_proxy HTTP_PROXY HTTPS_PROXY"

これみて意味がわからなくて、manみてもわからなくて、ググれない人は、これ使っちゃダメですよw

Translator

anonymous@undisclosed.example.com (Anonymous) — Tue, 25 Apr 2017 03:37:25 +0000

Translator

何を血迷ったか、翻訳エンジンについてちょっとだけ調べてみたので、メモを。

かるーく（ゆるーく）調べた（ぐぐった）ところ、

英単語の平均文字数は 4.5文字とか5.1文字くらいらしい。まぁ、5文字と考えておけばいいか
英語1文章に含まれる単語数は、まぁ、色々違うらしい。
- カジュアルな文章で20単語位
- 一般的な文章で25単語位
- 新聞で20単語位
- 子供向け絵本で5単語位

ものすごく単純に RFC文書における単語数を数えて平均を取ってみると、52645文字、6718 単語と言われる。（7.836文字/単語) この数値は、単純にwcで見ただけなので、実際にはHeaderやFooter、Indexなどがある。ちゃんと調べるのは単純に面倒なので、大雑把に考えて、平均で6500単語、8文字/単語くらいと近似できると思うので、1 RFCあたり5.5万文字と見ればそんなに外さないと思われる。

ちょっと面白かったのは、Plain English　読みやすさの指標（FKR/FKG/GFS）って一体何が基準なの！？の記事。軽く眺めておくといいかも。

Google様で 翻訳 API で検索してみる

Googleの翻訳API
- 原則有料。
- 言語検出および翻訳に関しては 1万文字/$20
  - RFCで考えると、5.5万/1万*20 = $120 として、$1=¥110とすれば、¥13,200位か。
- google翻訳知らない人は google translateでぐぐれ
MicrosoftのTranslator API
- 個人利用と法人利用（ビジネス利用）がある
- サービスとしても提供されている
- 200万字まで無料。（文字数であり、単語数ではない）
  - RFCで考えてみると200万/5.5万≒36 だから、36本翻訳できる計算になる。
    - 個人の普段使いだと思えば十分だが、プロの翻訳者では少ないというあたりなんだろうな。
- それ以降は段階的に料金が上がる。値段表が出るページ

実質で使える翻訳APIはMSとGoogleしかなさそうだが、翻訳精度がよほど高くない限りGoogleは使えないなぁ。 MSの翻訳エンジン、textで流し込むぶんには結構いい翻訳精度だったし。

ただ、どちらの翻訳エンジンも文脈は解釈しない（できない）から、どうしたって人様が手をかけてやる必要は（いまのところ）ある。

Microsoft Translator

anonymous@undisclosed.example.com (Anonymous) — Tue, 25 Apr 2017 04:38:30 +0000

Microsoft Translator

迂闊にもMS Translatorがいけてることに気がついたので、ちょっと試してみる。

しかし、MicrosoftのSubscriction関連の設定は面倒だった。

Microsoft Translatorのページを開く
- ここに色々情報がまとまっているので、頑張って見てみるといい
Microsoft DataMarketのページを開き、右上からSign-Inする
- 登録がない人は、ここから登録すること。
- Skype使っていて移行した人はそのアカウントで良い。電子メールアドレスでも電話番号でも良い。
  - Skype IDでloginした
アプリケーションの登録ページを開き、必要な情報を入力する
- クライアントID: アプリケーションの識別子。他とぶつからない好きな文字列を入力
- 名前: アプリケーションの名前
- 顧客の秘密: 特に変更する必要はない
- リダイレクトURI: Microsoft Translatorの場合、無効なURLを入力すれば良い
- サブドメインアクセスを有効にする: オフのままで良い
- 説明: 登録内容の説明など
- クライアントID(client id)と顧客の秘密(client secret)は、APIを利用する際に必要になる。
あとは、API使って普通に叩けばOK

LDAP管理ソフトを探す

anonymous@undisclosed.example.com (Anonymous) — Thu, 18 May 2017 02:52:48 +0000

LDAP管理ソフトを探す

以前、(PHP LDAP Admin)のつぶやきを書いたが、その後状況が変わっていないかちょっと調べてみる。

Admin4 どうやら、細々メンテナンスはされている模様。2年に1回くらいUpdateされているように見える
- Pythonなので、割と何でも動かせそう
The Apache Directory Studio(TM) でかい。Java…
Fusion Directory FreeBSDでも動かしている人はいるらしい。画面からでは理解しにくい…
- PHP+perl+いろいろ。ちょっと面倒そうな感じ
LDAP Account Manager 悪くなさそうなんだけど、いまいち。商用版がある
- Accountの管理だけならおそらくこれでいい。FreeBSDのportsがある
PHP LDAP Admin もう終わってるとおもう。2013年以降更新なし
Self Service Password これは、ユーザーに公開するパスワード変更用のI/Fとしては良さそう
- FreeBSDのportsにある

こうしてみると、LDAP管理系のソフトが本当にない。Java使えばいいんだろうけど、管理がなぁ… ActiveDirectoryに行く気持ちがわかってきた…

古いの承知でPHP LDAP Admin使うのか？…Admin4かなぁ…

shell scriptとwhileとreadとssh

anonymous@undisclosed.example.com (Anonymous) — Fri, 23 Jun 2017 12:45:00 +0000

shell scriptとwhileとreadとssh

大変にハマったのでメモ書き。今日はもういいや。

shell scriptにおいて、ファイルから1行ずつ読み込んで処理をするような場合、以下のようにかける。

while read line; do
  echo ${line}
done < file

ところが、この手を使ってsshを実行すると、なぜか最初の行しか実行されない

while read line; do
  ssh xxx.xxx.xxx.xxx ${line}	# XXX 期待通りに動かない
done < file

原因はsshコマンド実行に伴う標準入力の切替と考えられる。 sshコマンドを実行すると、ローカルホストのstdinからの入力を終了し、sshで指定したリモートホストのstdinからの入力受付を開始する。従って、ローカルホストのファイルの読込みを終了させた上でsshコマンドを実行し、再びreadコマンドを実行しようとしていると考えられる。もちろん、この時点で既にファイルがcloseされている為、whileが終了してしまう。

対策は、sshに-nオプションをつけること。これよって、sshコマンドのstdin切り替えを禁止することが出来る。

この原因がちっともわからず、数時間を無駄にしてしまった。

while read line; do
  ssh -n xxx.xxx.xxx.xxx ${line}	# これで/dev/nullがsshのstdinにつながる
done < file

このほかに、for文で for line in `cat file` で代用する手も考えられるが、これは、行にスペースがある場合、$lineに代入される値が１行まるごとではなく、スペースまでの部分になるので、ここにも明確な罠があると考えられる。これを回避するにはIFSを変えれば良いのだから、

IFS=$'\n'				# 区切り文字を" "から"\n"に変える
for line in `cat file`; do		# while readの代わりにcatで読み込ませる
  ssh -n xxx.xxx.xxx.xxx ${line}
done

あと、whileはちょっと特殊な制御文で、場合によってはwhile内で変数設定しているはずなのにloopをでてくると変数が空のようなことが起こる。これは、Whileと他のコマンドを組み合わせた場合、組み合わせ方次第で処理がsubshellがわで処理されてしまう事が原因である。 shellでpipelineを用いて実行した処理は、subshellで処理される。while loopの内部でpipelineを利用すると、whileブロック全体がsubshellで処理されるため、whileブロックの内部と外部で変数の共有が出来ない。このような場合、whileに対して出力をredirectしてやることで解決できる。

while read line; do
  OUT=`echo ${line} | sed 's/test/test2'`
done < $1
echo ${OUT}

なお、/bin/shの引数に -v や -x をつけると、デバッグに大変に役立つ

WebPageのSSL化

anonymous@undisclosed.example.com (Anonymous) — Mon, 26 Jun 2017 05:45:29 +0000

WebPageのSSL化

本サイトを含め、個人的に管理しているサイトがそこそこあるわけだが、昨今の様々な要請からSSL化を進めることにした。（そういうわけでLet's Encryptと格闘していたのだが）

その結果、WordPressとRedmine系を除いて、概ねLet's Encryptの証明書を利用したSSL化が一通り区切りがついた。

まぁ、証明書が入手できさえすれば、SSL化は簡単ではあるけど。

server {
  listen      xxx.xxx.xxx.xxx:80;
  server_name www.seirios.org;
  return      301 https://$host$request_uri;
}

server {
  listen      xxx.xxx.xxx.xxx:443 ssl;
  server_name www.seirios.org;
  ssl         on;
  ...
}

結構重要なこととして、コンテンツ側に記載されているLink等のうち、自らを示しているURLを一通り確認すること。これをしないと、結局一部SSL化されないURLが残るので、面倒なことになりかねない。

気になった記事から思ったこと @20170705-1

anonymous@undisclosed.example.com (Anonymous) — Thu, 06 Jul 2017 03:10:24 +0000

気になった記事から思ったこと @20170705-1

非常に個人的な意見なので、気に入らない人は華麗にスルーしてください。

http://itpro.nikkeibp.co.jp/atcl/column/14/549762/062900154/?n_cid=nbpitp_fbed&rt=nocnt&ST=spleafの記事についておもうことを少し。

googleが検索市場で独占的な地位にいる
- 代替が事実上存在しない(百度？bing? yahoo?)以上、独占状態になるのは当然。
- これだけの長きにわたって、「無料で高精度」の検索エンジンを提供しているのだから、googleがすごいのだとしか言いようもない。
- 対抗が現れるまではどうしようもないというのが実情だろう

スポンサー広告を優先して、公平な市場競争を阻害した
- タダで受け取っている情報にある種のバイアスがかかるのは当然。
- バイアスは小さい方が望ましいが、googleはボランティアではない。
- バイアスがかかることが嫌なら検索エンジンを変えればいい。ないなら作るしかない。(死屍累々の道だけど)

個人的には、googleが正しいとは思わない(むしろできるなら使いたくない)。しかし、この件に関して言えば、「ヨーロッパすらこの程度か。日本の民間人と変わらないレベルだ」と思ってしまう。世界的に「情報と安全はタダ」の方向に思考が向かっているとしか思えない。本当なら、利用する側がすべき選択や判断を提供者側に押し付けて、自らは被害を受けた、的なワガママに見えてしまう。

いっそ、googleは、「バイアスをかけない検索結果の提供」を始めればいいんじゃないかと。「有料」で。そうすれば、情報の対価と、企業広告・スポンサードの意味がわかるんじゃないか？とおもうのです。

わかるかなぁ(松鶴家千とせ風)

気になった記事から思ったこと @20170705-2

anonymous@undisclosed.example.com (Anonymous) — Thu, 06 Jul 2017 03:08:51 +0000

気になった記事から思ったこと @20170705-2

山賀さんの記事より。

要するに、

多くのユーザーが、脆弱性を抱えているadobe flashを利用している
調査範囲内では、古いプレーヤーの利用率が、前年の調査より上がっている
flash playerの利用率自体は減少傾向にある
duo securityは、chromeの利用を推奨している。セキュリティ系の企業が名指しで実装を推奨するのは珍しい

といった内容です。

記事中に記載されていませんでしたが、Duo security (最初avastと書きましたが、思い込みでの勘違いでした。訂正します) がchromeを推すのは、恐らく、

chrome自身にflash playerが内蔵されている
chromeは更新が早く、常に最新のflash playerに対応している
調査結果から、割合chromeユーザーは更新頻度が高いと見られる

からでしょう。推すことに対する是非は人によるでしょうが、例えばavastは昔からchrome推しなので、まぁそんなものかと。まだ、著者の山賀さん曰く

「あまりの調査結果に「やむにやまれず」という思いはちょっと感じられます^^」

とありましたが、僕もそう思います。

個人的にはflashはもう滅びて欲しいけど、使うなら常に最新の物を使いたいものですね。

困るのは、子供付けのページの動画がflashが多いことだな。これは、なんとかならないものかと思います。

HTTPで少しハマったことメモ

anonymous@undisclosed.example.com (Anonymous) — Wed, 19 Jul 2017 06:09:07 +0000

HTTPで少しハマったことメモ

NGINXやApache(おそらくSQUIDでも)あたりでReverse Proxy(まぁ、Load Balancer的に使う設定)をしようとした場合に、中継段となるhttpdでHeaderを追加したいことはしばしばある。こういう場合に、X-xxx-xxxのようなHeaderを追加することがしばしばある。

しかし、この手法は、一般的によく利用されている慣習であって、HTTP Protocol的に規定されているものではなかった。そして、この慣習は2012年6月に非推奨となった。

なぜそうなったかに関してはRFC6648を参照のこと。まぁ、要するに「非標準のフィールドが標準になったときに発生した不便さのため」ということになると思う。

んで、どうすりゃいいかということなのだが、要するに「使われていない」かつ意味がわかりやすいものを使えということらしい。

でも、それはそれで困るよなぁ…….

仕方がないから、被りそうもない文字列を入れるしかないか。

OPNSense

anonymous@undisclosed.example.com (Anonymous) — Fri, 10 Nov 2017 05:55:19 +0000

OPNSense

最近まで自宅の対外接続Router兼FirewallとしてpfSenseを利用していた。しかし、pfSenseの来船に関する変更を見て、ちょっと調べ直したら、OPNSense がかなりよくなっていることに気がついたので、OPNSenseに切り替えてみる気になった。

OPNSenseのIPSがsuricataになってた (いつからかわかってない)
OpenVPN を利用するためのClient ConfigurationがExportできるようになってた
Commandlineからの制御とは言え、pkgが利用できる
1. すなわち、CEoRで多少の面倒はみられると言うこと
pfSenseで自分が利用していた機能は全てOPNSenseで動作する
実質の影響はないとは言え、pfSenseのライセンス変更は正直気に入らなかった
1. もちろん、彼らはOpenであんなに素晴らしいシステムを公開しているのだから、彼らに文句を言う気はない。むしろ当然とも思う
2. 気に入らなかったら意見は述べて良い。それでも気に入らなければ別実装を使え！は鉄則。彼らだって完全なVoluntierではないのだから

というわけで、Installしたのでそのメモを。

（最終的なやつは別記事にしてあげるので、ここではメモのみ記述する）

Install

基盤は例によってXenServer。

vCPU	2
Mem	1G
HDD	10G
NIC	3

まずは最初の作業

OPNSenseのInstall ISO ImageをDownloadし、XenServer用のISO供給用NFSサーバーに設置
上記SpecでVMを作成し、ISOイメージから起動
Login Promptが出るので、User: installer / Passwd: opnsense でloginする
画面の指示に従いInstallを進める
Installが終了したら、再起動し、ISOイメージをEjectする

Consoleからの設定

起動すると、Login Promptが出るので、User: root / Passwd: opnsense でloginする
Network関連の設定をする
- 1) Assign interfaces から、認識しているNICを設定する
- 2) Set interface IP address から、LAN I/FにIP Addressを割り当てる
- ここまでを行うとconsole画面に割り当てたIPアドレスが表示されるようになる。
ここまで実行するとGUIで設定できるようになる

GUIからの設定

ここからは、普通に色々設定すれば良いのだが、特に気にしておくべきことをメモしておく。

まず、XenServer側で TSO をOffにしておく。
- XenServerにloginした上で、以下を実行
- ```
xe vif-param-set uuid=[VMのVIF UUID] other-config:ethtool-tso="off"
```
Browserで、設定したIPアドレスにアクセスする
System → Access → Users
- 自分用アカウントを作成する
System → Settings → Administration
- Secure Shell をEnableにし、SSH portを変更する
System → Settings → Tunables
- net.inet.tcp.tso を 0にする

その他

sshでlogin
1. sudo pkg update
2. sudo pkg install xe-guest-utilities
3. sudo echo “xenguest_enable=YES” » /etc/rc.conf.local