pslaboが試したことの記録

はてなダイヤリーからはてなブログに引っ越してきました

この日記は現在実行中の減量記録を含む個人的なメモとして始めましたが、最近はコンピュータやガジェット、ハック、セキュリティネタのほうがメインになっております。

はてなダイヤリー時代はカテゴリ分けが適当だったのですが、これはそのうち直します。


CentOS7でsquidでSSLをフィルタリングするproxyをforward proxyで設定し、さらにGoogleの個人アカウントへのアクセスを禁止する

過去に、squidで透過型プロキシを立てるネタを2件ほど書いているのですが、透過型プロキシのテストは案外めんどくさいものです。Linuxがルータとして動作するように設定した上で port forward を設定し、さらにクライアント側もそのルータを経由するように設定せねばなりません。

そこで、こういった設定をせずとも SSLの中継をテストするために、通常の forward proxy でSSLを取り扱えるように設定してみます。そしてさらにGoogleの個人アカウントを禁止する設定も作ってみます。

まずは過去記事の紹介から

pslabo.hatenablog.com

[http://pslabo.hatenablog.com/entry/2017/06/11/Ubuntu_16.04_LTS%E3%81%A7_squid%E3%81%AE%E9%80%8F%E9%81%8E%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%AD%E3%82%B7%E3%82%92%E7%AB%8B%E3%81%A6%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AB_squid_%E3%82%92%E3%83%AA%E3%83%93:embed:cite]

今回の環境

いまさらCentOS6で環境を作るのもイマイチですから、今回はCentOS7でやってみることにします。 なお、CentOS7のsquidは–with-opensslつきでビルドされていますので、今回はこれをそのまま使います。

設定上のポイント

  • SELinux を使用している場合は「都度生成されるサーバ証明書ディレクトリに対して squid がアクセスできるように設定変更する」ことをお忘れなく。これを忘れると意味不明なエラーが出てハマることになります。
  • forward proxy の場合は ssl_bump の設定が client-first となります。(透過型の場合は server-first です)
  • https_port は設定しません。今回のケースでは、http_port ですべてのリクエストを取り扱います。
  • http_port の設定には intercept の設定を書きません。透過型ではなく forward proxy ですから。

実際の作業

CentOS7 のインストール

CentOS-7-x86_64-Minimal-1611.iso でインストールします。

squid のインストール

とりあえずはこれだけでOK。

sudo yum install squid

オレオレCAの作成

CentOS7 の場合は openssl をインストールすると /etc/pki/CA/private というディレクトリがあるので、ここにオレオレCAをセットアップするのが妥当な気がします。そこで今回は以下のように作業しています。(過去記事との違いは cd するディレクトリが違うことだけです)

cd /etc/pki/CA/private

# オレオレCA作成。
openssl req -new -newkey rsa:2048 -sha256 -days 3650 -nodes -x509 -keyout oreoreCA.pem  -out oreoreCA.pem

# オレオレCAの証明書作成。これは利用者のブラウザにインストールするものです。
openssl x509 -in oreoreCA.pem -outform DER -out oreoreCA.der

ssl_crtd の設定

これは以前の記事と基本的に同じですが、ここで作成する /var/lib/ssl_db には SELinux での権限割り当てが行われていないので、SELinux が有効な場合はsquid からのアクセスが失敗します。

/usr/lib64/squid/ssl_crtd -c -s /var/lib/ssl_db
chown -R squid /var/lib/ssl_db

よって SELinux が有効な場合は以下のコマンド実行を忘れないようにしてください。

chcon -R -t squid_cache_t /var/lib/ssl_db

これを忘れていると /var/log/squid/cache.log あたりにこういうメッセージが出てsquidが異常終了するという罰ゲームに遭遇します。このエラーメッセージを見ると ssl_crtd の初期化ができていないように読めますが、実はそうではなく、権限がないからアクセスできていない状態であることを、初期化できていないと判定しているわけです。

(ssl_crtd): Uninitialized SSL certificate database directory: 
/var/squid/ssl_db. To initialize, run "ssl_crtd -c -s /var/squid/ssl_db". 
(ssl_crtd): Uninitialized SSL certificate database directory: 
/var/squid/ssl_db. To initialize, run "ssl_crtd -c -s /var/squid/ssl_db". 
(ssl_crtd): Uninitialized SSL certificate database directory: 
/var/squid/ssl_db. To initialize, run "ssl_crtd -c -s /var/squid/ssl_db". 
(ssl_crtd): Uninitialized SSL certificate database directory: 
/var/squid/ssl_db. To initialize, run "ssl_crtd -c -s /var/squid/ssl_db". 
(ssl_crtd): Uninitialized SSL certificate database directory: 
/var/squid/ssl_db. To initialize, run "ssl_crtd -c -s /var/squid/ssl_db". 

squid を設定する

デフォルトの squid.conf.default との差分形式を掲示しておきます。ここで記述している内容は過去記事に書いてますので、不明点があればそちらをご参照いただきたく。また、一部の設定では証明書の検証エラーをスルーしていますので、そのまま用いるとセキュリティ上の問題が生じることにご注意ください。これはあくまで基本的な動作検証を目的に作成した設定です。

[root@localhost squid]# diff -u /etc/squid/squid.conf.default /etc/squid/squid.conf
--- /etc/squid/squid.conf.default   2017-04-13 04:43:17.000000000 +0900
+++ /etc/squid/squid.conf   2017-06-18 11:23:11.852000000 +0900
@@ -2,6 +2,21 @@
 # Recommended minimum configuration:
 #
 
+visible_hostname [適当なサーバ名]
+
+http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/pki/CA/private/oreoreCA.pem
+
+always_direct allow all
+ssl_bump client-first all
+
+sslproxy_cert_error allow all
+sslproxy_flags DONT_VERIFY_PEER
+
+cache_dir aufs /var/spool/squid 100 16 256
+
+acl to_google dstdomain .google.com
+request_header_add X-GoogApps-Allowed-Domains [自社ドメイン] to_google
+
 # Example rule allowing access from your local networks.
 # Adapt to list your (internal) IP networks from where browsing
 # should be allowed
@@ -56,7 +71,7 @@
 http_access deny all
 
 # Squid normally listens to port 3128
-http_port 3128
+#http_port 3128
 
 # Uncomment and adjust the following to add a disk cache directory.
 #cache_dir ufs /var/spool/squid 100 16 256

クライアント側の設定

oreoreCA.der をクライアント側のブラウザにインストールしてください。これを実施していない場合は、すべてのSSL/TLSな接続で証明書エラーが出てしまいます。

また、今回の設定は forward proxy ですから、クライアント側でプロキシサーバを明示的に設定しておく必要があります。

上記の設定で、自分の環境ではGoogleへの個人アカウントでの利用(メールとかGoogleドライブ)が禁止できることを確認できています。ただし、Google へのログイン自体は個人アカウントでも通ってしまいますので、検証の際は gmail 等の個別のサービスにアクセスしてみてください。

そして、forward proxy が意図通りに動くようになってから、transparent proxy の動作を確認するとよいでしょう。

MarkdownエディタのAtomにインストールする拡張機能のメモ

完全に私的なメモ。随時かつ不定期に更新。

japanese-menu

操作メニューを日本語にするために導入

language-markdown

入れてみたけど、入れない状態との違いが未だよく分からない。

markclip

画像をクリップボードから ctrl+v でコピペしたいのです。設定は file in folder にしてみた。

markdown-preview-plus

入れてみたけど、入れない状態との違いがイマイチわからない。

markdown-scroll-sync -> markdown-preview-enhanced

markdown-scroll-sync は編集画面とプレビュー画面のスクロールの同期が動かなかったので、markdown-preview-enhanced に変更

Macbook Pro 2016で出先でのプロジェクタ接続用にUSB-C→HDMI&VGA変換アダプタを調達した

過去にこんな記事を書いていたのですが……

pslabo.hatenablog.com

最終的に、こんな製品を買ってみました。

実際に試した範囲での感想はこんなところ

アダプタ1つでUSB-CからHDMIVGAの両方がとれるのに、アダプタが割と小さめ

もっとも重要視したのがコレ。1つのUSB-CでHDMIVGAが両方取れたとしてもアダプタ自体が大きいのは困ります。今回購入したのは、HDMIVGAを2つ横並びに並べた幅しかないので、結構小さいです。

HDIMは4K対応

4Kなモニタがないので実際に4Kが出るかどうかは知らないのですが、4Kだそうです。

VGAは1080pといいつつも 2560x1080 なウルトラワイドでも表示できた。

自宅には U2913WM があるのですが、これは 21:9 (2560x1080) という変則的な解像度です。しかし VGA 接続、HDMI接続ともに 2560x1080 で表示させることができました。

VGA & HDMI 同時接続でも 2560x1080 で表示できた。

HDMI & VGA の2本刺しは同じ画像を両方に出力と聞いていたのでU2913WM を PinP モードにして試してみたら、2560x1080 の同じ画像が両方に出力されました。

というわけで、この金額でVGA&HDMIが取れるのは、まあアリかなあと思っております。強いて言えば、USB-C端子の給電端子が付いていたら、Pro ではない Macbook で重宝しただろうなあ、というところでしょうか。

そういう意味では、USB-C が2系統以上付いている Macbook Pro 向けならば、これは悪くない選択肢だと思います。

Ubuntu 16.04 LTS で squid の透過型プロキシを立てるために squid をリビルドする

以前に、CentOS上のSquidSSLインターセプトしてフィルタリングする透過型プロキシを立てて、さらに Google の個人アカウント利用を禁止する設定を紹介しました。

pslabo.hatenablog.com

さて、同じことを Ubuntu 16.04 LTS で行おうとしてみたのですが、標準のリポジトリから配布されているバイナリでは、これは行えないようでした。その理由は下記の理由によります。

  • Ubuntu 向けの squid パッケージングは with-openssl を付けずにビルドされている

そこで、 Ubuntu 16.04 LTS で同じ設定を作るために、squid のリビルドを行ってみることにしました。

作業の流れ

概ね、以下の7ステップです。

  • source をダウンロードできるように apt の設定を変更する
  • ビルドに必要なパッケージをインストールする
  • ソースコードをダウンロードする
  • ビルドの設定を書き換える
  • ビルドする
  • ビルドしたパッケージをインストールする
  • apt update / apt upgrade で野良パッケージが標準リポジトリのパッケージで上書きされないようにする

source をダウンロードできるように apt の設定を変更する

sudo vim /etc/apt/sources.list します。ここで必要な設定は以下のエントリです。

deb-src http://jp.archive.ubuntu.com/ubuntu/ xenial main restricted

書き換えたら sudo apt update しておきます。

ビルドに必要なパッケージをインストールする

ここらへんをインストールしておきます。

sudo apt install devscripts build-essential fakeroot libssl-dev

ソースコードをダウンロードする

こんな感じですね。するとソースコードは git clone でもイケると言われます。しかしダウンロード自体は行なわれますので、今回はそのままで行くことにします。

$ apt source squid
Reading package lists... Done
Picking 'squid3' as source package instead of 'squid'
NOTICE: 'squid3' packaging is maintained in the 'Git' version control system at:
git://anonscm.debian.org/pkg-squid/pkg-squid3.git/
Please use:
git clone git://anonscm.debian.org/pkg-squid/pkg-squid3.git/
to retrieve the latest (possibly unreleased) updates to the package.
Skipping already downloaded file 'squid3_3.5.12-1ubuntu7.dsc'
Skipping already downloaded file 'squid3_3.5.12.orig.tar.gz'
Skipping already downloaded file 'squid3_3.5.12-1ubuntu7.debian.tar.xz'
Need to get 0 B of source archives.
Skipping unpack of already unpacked source in squid3-3.5.12

ま、今後は Git clone するかなあ。

ビルドの設定を書き換える

こんな感じで。

$ cd squid3-3.5.12/
$ vim debian/rules
"Configure the package” sectionに2行足す
--with-openssl=yes \
--enable-ssl-crtd

ビルドする

./configure
debuild -us -uc -b

ビルドしたパッケージをインストールする

一つ上の階層に、ビルドされたパッケージ (*.deb) がこんなふうにできているはずですので、これをインストールします。

$ ls squid*.deb
squid3_3.5.12-1ubuntu7_all.deb
squid_3.5.12-1ubuntu7_amd64.deb
squid-cgi_3.5.12-1ubuntu7_amd64.deb
squidclient_3.5.12-1ubuntu7_amd64.deb
squid-common_3.5.12-1ubuntu7_all.deb
squid-dbg_3.5.12-1ubuntu7_amd64.deb
squid-purge_3.5.12-1ubuntu7_amd64.deb

私が squid 関連でインストールするのは、ここらへんのパッケージです。ただし squid-purge や squidclient を入れるかどうかは個々人の好み次第ですかねえ。

$ sudo apt install ./squid3_3.5.12-1ubuntu7_all.deb ./squid_3.5.12-1ubuntu7_amd64.deb ./squid-common_3.5.12-1ubuntu7_all.deb ./squid-purge_3.5.12-1ubuntu7_amd64.deb ./squidclient_3.5.12-1ubuntu7_amd64.deb

apt update / apt upgrade で野良パッケージが標準リポジトリのパッケージで上書きされないようにする

こんなふうに実行しておけば、標準リポジトリのパッケージがアップデートされたときに上書きされることがないようです。

dpkg --set-selections <<EOF
squid hold
squid-common hold
squid-purge hold
squid3 hold
EOF

# dpkg --get-selections | grep squid
squid                                           hold
squid-common                                    hold
squid-langpack                                  install
squid-purge                                     hold
squid3                                          hold

ここまで出来ていれば squid による https の透過型プロキシを Ubuntu 16.04LTS 上でも構築する準備は完了です。あとは過去記事の内容で設定するだけです。

iOS11に行ける端末、行けない端末。そしてその先は?

iOS11が発表になり、32bit CPUが切り捨てられるということなので、現時点でサポートが有効な端末のCPU種別と対応OSバージョンを表にしてみる。

f:id:pslabo:20170607162310p:plain

iOS11がサポートされないのはCPUがA6の端末。

そうすると、おそらくは次のデバイスCPUがA7だから、iOS11が最後のアップデートになるのだろう。

そしてCPUがA8系列の次のデバイスは来年のiOS12で打ち止めの可能性高し。

Windows 10 2015 LTSB を Windows 10 2016 LTSB にインプレースアップグレードしてみる

Windows 10 には CB (Current Branch), CBB (Current Branch for Business), LTSB (Long Term Servicing Branch) の3つのブランチがあるわけですが、LTSB についてインターネット上で見かける情報は少なめです。

LTSB について、自分が把握しているのはこんなところ。

  • ある時点の機能アップデートがベースのパッケージングだが、バグ修正と脆弱性対応のパッチだけが提供される
  • 現時点では 2015 LTSB と 2016 LTSB がリリースされているが、今後は2年~3年毎のリリースとなるので、2017 LTSB はリリースされない
  • サポートはリリースから10年間
  • Windows10 の新機能を必要としない、基幹業務やミッションクリティカルな用途、あるいは組み込み機器向け
  • 通常の業務にこれを用いることは想定されていない
  • Windowsストアからのアプリのインストールには対応していない
  • Enterprise Edition 向けのオプションとして提供される
  • インストールメディアは専用のものが必要

さて、2015LTSB については手元に試験環境を作っていたのですが、2016 LTSB へのアップグレードはインプレースアップグレードが可能らしいので、実際に試してみることにします。

まず、インプレースアップグレード前の状態はこうです。 f:id:pslabo:20170527152024p:plain

インストール用のDVDメディアを装着して setup.exe を実行します。 f:id:pslabo:20170527152221p:plain

そうすると、LTSB ではないブランチのインプレースアップグレードと同様の流れでインストールが進みます。此処から先のスクリーンショット4枚くらいはコメント不要でしょうからスクリーンショットだけ。 f:id:pslabo:20170527152259p:plain

f:id:pslabo:20170527152319p:plain

f:id:pslabo:20170527152331p:plain

f:id:pslabo:20170527152337p:plain

インプレースアップグレードが終わった直後の状態はコレ。確かに 1607 に変わっているけれど、なんと、ライセンス認証が無効になっています。 f:id:pslabo:20170527152358p:plain

Windows10 CB, CBB の場合はバージョン1507のライセンスが最新の機能アップデートにも適用できますが、LTSB ではそういうわけにはいかないようです。ただしこれは MSDN 向けのプロダクトキーを用いての検証なので、本番運用時では話が違うかもしれません。

というわけで、LTSB はインプレースアップグレードできる、という話を検証してみました。

なお、LTSB は CB, CBB に比べると余計なものは一切インストールされないので、スタートメニューは実に清々しい状態です。

f:id:pslabo:20170527153725p:plain