本サイトのサーバ OS をアップデートしました。これにより、以下の変更が発生しています。
なお、VPS は引き続き ConoHa を利用していますが、HDD の旧プランから SSD の新プランに移行しています。下にも書いているけれど、SSD のおかげか、はたまた fcgid に変更したからか、体感レベルでパフォーマンスは上がっています。
以下のような環境で設定した備忘録である。なお、IP アドレスは例である。
■環境
・マスター (Debian GNU/Linux Stretch) / nsd4
IPv4 アドレス: 192.0.2.1 IPv6 アドレス: 2001:0DB8::1
・スレーブ (Debian GNU/Linux Wheezy) / nsd3
IPv4 アドレス: 192.0.2.2 IPv6 アドレス: 2001:0DB8::2
Postfix で RBL を使用する場合、単純に「smtpd_recipient_restrictions」内のしかるべき場所に「reject_rbl_client」で指定してあげたら良いだけです。
ただ、改めてドキュメントを見ていると、返答された A レコードの内容によって通したり通さなかったり出来る模様でした。
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_rbl_client all.rbl.jp, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org=127.0.0.[2;3;4;5;6;7;10;11]
こんな感じで書いた場合、
となる様でした。
なお、「reject_rbl_client」パラメータの「rbl_domain=」の後の IPv4 アドレスは Postfix 2.1 以降、[] 内の値を「;」文字で分割できるのは、Postfix 2.8 以降で使用できる模様です。
ちなみに、zen.spamhaus.org を使用している場合で、本当に設定が有効になっているかどうかを確認するには、設定したサーバから「nelson-sbl-test [アットマーク] crynwr.com」あてにメール送信をします。
正しく設定されていると、サーバ側のメールログにブロックされている旨が記録されますし、結果もメールで返送されてきます。
Debian GNU/Linux 7 での設定例です。キャッシュは使用しません。プロキシのポート番号は 8080 です。
■設定とインストール
・インストール
# apt-get install squid3
・認証用ファイルを作る
以下のような形式のプレーンテキストファイルを「/etc/squid3/passwd」に作成し、適切な権限を与えます。
Username:Password
# cd /etc/squid3 # echo "Username:Password" > passwd # chmod 600 passwd # chown proxy:proxy passwd
・squid3 の設定ファイルを編集
/etc/squid3/squid.conf を編集する。
# Digest 認証部分 auth_param digest program /usr/lib/squid3/digest_pw_auth /etc/squid3/passwd auth_param digest children 5 auth_param digest realm Proxy Server auth_param digest nonce_garbage_interval 5 minutes auth_param digest nonce_max_duration 30 minutes auth_param digest nonce_max_count 50 # キャッシュマネージャーの ACL acl manager proto cache_object # localhost の ACL acl localhost src 127.0.0.1/32 ::1 # Digest 認証の ACL acl passwdauth proxy_auth REQUIRED # Proxy での SSL ポート番号並びに通すポートと CONNECT メソッドの ACL acl SSL_ports port 443 acl Safe_ports port 80 acl Safe_ports port 443 acl CONNECT method CONNECT # キャッシュマネージャーへのアクセス制限 (localhost のみ) http_access allow manager localhost http_access deny manager # プロキシへのアクセス制限 (あらかじめ定義したポート、メソッドで localhost は許可、それ以外は Digest 認証が必要) http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access allow passwdauth http_access deny all # プロキシのポート番号 http_port 8080 # キャッシュ設定 (使用しない) cache_mem 0 MB cache deny all # 実行ディレクトリ coredump_dir /var/spool/squid3 # プロキシサーバが出力するヘッダを抑制 forwarded_for delete via off
・設定確認
# squid3 -k parse
「via off」部分で WARNING が出ますが、ヘッダの抑制は行われます。
・再起動
# /etc/init.d/squid3 restart
■その他
squid3 が動作しているサーバが IPv6 アドレスも持っている場合、IPv4 な接続元から squid3 経由で通信すると、要求された接続先が IPv6 アドレスを持っている場合、IPv6 でアクセスすることを確認しました。プロキシ形での IPv4 <-> IPv6 変換としても使用できそうです。
Debian 8 上に DNS64 + NAT64 を設定した備忘録である。例によって無保証である。
2017/02/11 追記: Jool 3.5.x 系でも同じようにインストール出来ることを確認した。
Linux カーネルのビルドは、「Kernel Building – Raspberry Pi Documentation」に記載の通り、DNS64, NAT64 関係は、「DSAS開発者の部屋:Raspberry Pi 2 で NAT64 箱をつくってみた」の通りとなる。
両者のドキュメントに感謝しつつ、実際に設定を行ってみた。なお、私の環境では、USB で NIC を接続して別インタフェースを接続している。
「Raspberry Pi 2 Model B を AirPlay サーバに」で、「ShairPort」を使用して、AirPlay サーバを設定したのですが、以下の点で、若干問題が生じたのと、気になっていた点がありました。
派生版 (?) の「Shairport Sync」を使用してみたところ、これらの問題を解決することが出来ました。
■前提条件
「Raspberry Pi 2 Model B を AirPlay サーバに」の「ALSA の設定」の項目の設定が全て完了し、また前回と環境も同じであることとなります。
自宅内の DNS キャッシュサーバについて、BIND9 から Unbound へ移行してみました。
BIND9 はネット上に資料が豊富にあって、割と設定面では困らないのですが、度重なるぜい弱性への対応に疲れがちなので・・・。
例によって、自分用メモです。また、Debian GNU/Linux 8 環境で設定しています。
何本煎じのネタかわからないぐらい情報がありますが、自分自身で Raspberry Pi 2 Model B 上の Debian GNU/Linux 8 (Raspbian ではない) のシステムに、「abrasive/shairport · GitHub」をインストールした際の記録です。
手元の iOS デバイスの音楽を、iOS デバイスと同一ネットワーク内のサーバに接続した USB-DAC 経由でスピーカーから流す、と言うのを行いました。
なお、サーバには既に avahi-daemon が設定済みであることが前提です。
この例では、マスターサーバから、
・スレーブサーバ 1 には普通のゾーン転送
・スレーブサーバ 2 には TSIG を使用してのゾーン転送
という、複数のサーバに対して、TSIG を使用する・しないが混在しているような場合の設定を行う。
「実用 BIND 9で作るDNSサーバ（5）：スレーブ・サーバのゾーン転送とセキュリティ (3/3) – ＠IT」を参考にさせて頂き、また同ページに詳しい情報は掲載されているが、自分の環境での実装メモである。
そんな設定をサーバ側でしていないのに、URL スキームに http を指定しているのに、「なぜ常に https でアクセスされてしまうのじゃー」、と悩んだ現象の原因と解決方法です。
■原因
HSTS という、URL スキームに関係なく、https でアクセスさせる仕組みが原因でした。
でも、Web サーバ側では明示的に HSTS の「Strict-Transport-Security」ヘッダを出した覚えはありません。
さらに探っていくうちに、該当 URL のサブディレクトリにインストールした、OwnCloud において、「設定」内の「常にHTTPSを使用する」にチェックを入れていると、「Strict-Transport-Security」ヘッダが出力される仕様でした。
このため、この設定を行った後、https で該当 URL の OwnCloud にアクセスしてしまうと、ブラウザが「この URL は常に https で接続しなくちゃ」と認識して、以後、http:// からアドレスを打ち込んでも、https に遷移してしまうと言うことでした。
■元に戻す方法 (HSTS を無効にする)
該当ホストの HSTS を無効にするには、Web サーバ側で「Strict-Transport-Security: max-age=0」を出力してあげれば OK のようです。
Apache であれば header モジュールを有効にした上で、VirtualHost ディレクティブ内などで
Header always set Strict-Transport-Security "max-age=0"
の様に設定します。AllowOverride で FileInfo が許可されていれば、.htaccess でも対応できると思います。
その上で、一度該当 URL にブラウザでアクセスして、ブラウザ側に「このホストは HSTS が無効になったんだな」と認識させてあげれば、以後は http から https への自動遷移は発生しません。
■参考
「RFC 6797 – HTTP Strict Transport Security (HSTS)」によれば、以下のような記載がありました。
A max-age value of zero (i.e., “max-age=0”) signals the UA to cease regarding the host as a Known HSTS Host, including the includeSubDomains directive (if asserted for that HSTS Host).