.txtでない拡張子のファイルをtext/plainとして扱いたい

OS: CentOS Linux release 7.7.1908 (Core)
httpd-2.4.6-90.el7.centos.x86_64
Internet Explorer 11.719.18362.0

.lstという拡張子の付くテキストファイルをInternet Explorerで表示したときに改行が反映されないという通報を受けて調査を進めたところ、Content-Typeがtext/plainとして扱われていないが為に表示がクシャリとなっている模様である。

Google Chromeでは改行がきっちり表現されていたからInternet Explorer固有の問題であると早合点して、Microsoft Edgeへの移行を進言すべく目論んでいたところ、Microsoft Edgeもやはり表示がクシャリとなってしまったからすっかり計画が狂ってしまった。

拡張子が.txtであれば勝手にtext/plain扱いされて良いけれどもファイル名の変更は受け入れられない情勢である。唯一、Apacheの設定変更のみが許されているのである。それでこうである。

$ sudo vi /etc/httpd/conf/httpd.conf
<FilesMatch "\.lst$">
  AddType text/plain lst
</FilesMatch>

これで拡張子が.lstのファイルもtext/plainとして扱われてInternet Explorerでも改行が反映された。反映されないときは概ねキャッシュが邪魔をしているからCrtl+F5でスーパーリロードするのが宜しい。

AddTypeディレクティブは無闇にセットすると.lst.guroのような拡張子であっても効果を発揮してしまうから本当は SetHandler text/plain を使うのが良いようである。

けれどもどうしてもSetHandlerの設定が反映されなかったので已む無くFilesMatchディレクティブで取り囲んだAddTypeでお茶を濁したものである。

参考:
AddType ディレクティブ

muninのapache_accessesプラグインがSSL対応になったサーバステータスページへアクセスできない問題に対応

OS: Ubuntu 18.04.1 LTS
Apache 2.4.35
munin-node 2.0.37-1ubuntu0.1

ApacheにSSLサーバ証明書を導入して以来、muninのapache_accessesプラグインの調子が頗る良くない。munin-run --debug apache_accesses を実行してもaccesses80.value Uとなるばかりでちっとも数値をひらえない。

$ sudo vi /usr/share/munin/plugins/apache_accesses
154         my $response = $ua->request(HTTP::Request->new('GET',$url));
155 print $response->message;

埒が明かぬのでapache_accessesプラグインの155行目に print $response->message;を挿入しても少し具体的な手がかりを得ようと試みたところこういう始末であった。

$ sudo munin-run --debug apache_accesses
(snip)
Can't connect to 127.0.0.1:80 (SSL connect attempt failed error:1408F10B:SSL routines:ssl3_get_record:wrong version number)accesses80.value U

SSL3.0での接続が具合悪いように見えるけれどもそも80番ポートへアクセスしているの為に処理がわやになっているのかと思うから設定ファイルでURLとポートを指定して伝えた。

$ sudo vi /etc/munin/plugin-conf.d/munin-node
[apache_*]
env.url https://127.0.0.1:%d/server-status?auto
env.ports 443

改めてmunin-runコマンドで以ってデバッグをおこなうと今度はこういう有様である。hostname verification failedという事は詮ずればサーバ証明書のCommon Nameは127.0.0.1とはぜんぜんチグハグであることが原因であろうと思う。

$ sudo munin-run --debug apache_accesses
(snip)
Can't connect to 127.0.0.1:443 (hostname verification failed)accesses443.value U

LWP::UserAgentの手引きを紐解くとデフォルトではホストネームの検証が実施される模様であるから此れを無理に取りやめる為の記述をapache_accessesプラグインの150行目にしたためる。

$ sudo cp -av /usr/share/munin/plugins/apache_accesses{,.orig}
$ sudo vi /usr/share/munin/plugins/apache_accesses
148 my $ua = LWP::UserAgent->new(timeout => 30,
149                 agent => sprintf("munin/%s (libwww-perl/%s)", $Munin::Common::Defaults::MUNIN_VERSION, $LWP::VERSION));
150 $ua->ssl_opts(verify_hostname => 0);

あとはmunin-nodeを再起動して様子を伺っているとどうやら宜しく動作しているようである。

$ sudo systemctl restart munin-node
$ systemctl status munin-node
● munin-node.service - Munin Node
   Loaded: loaded (/lib/systemd/system/munin-node.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2018-10-22 04:28:32 JST; 3s ago

参考:
LWP::UserAgent – Web user agent class – metacpan.org

ApacheのSSL設定を見直してセキュリティレベルを向上させる

OS: Ubuntu Server 18.04.1 LTS
Apache 2.4.35
OpenSSL 1.1.0g 2 Nov 2017

ApacheでSSLサーバ証明書の設定をこなしたけれども殆どデフォルトの儘に任せていたからQualysのSSL Server Testを実施するとこういう有様である。

前方秘匿性をサポートしていないからB判定という次第である。RSAによる鍵交換が有効になっていると此れは前方秘匿性が無いから誠に遺憾であってECDHE(楕円曲線ディフィー・ヘルマン鍵共有)を活用なさいという旨、記載があったけれども意味を飲み込める範疇を遥かに超えているのである。

こうなるとApacheの設定を如何にしたらいいかぜんぜん想像が及ばないから、も少し手軽に設定を何とかできないかと調べていくとMozilla SSL Configuration Generatorという大変心強いサイトをmozillaが用意して呉れていた。

Webサーバの種類とバージョン、OpenSSLのバージョンを選択してやるだけで設定をパッと示してくれるから実に有り難い仕組みである。Modern、Intermediate、Oldの選択肢はサポートするブラウザの後方互換性をどれだけ確保するか決定できる。Oldは随分昔のブラウザまで対応する代わりに脆弱性が確認されているSSLv3を使うし、Modernは今の所安心できそうなSSLプロトコルと暗号スイートで構えるけれども古いブラウザは切り捨ててゆく方針となるようである。

$ openssl version
OpenSSL 1.1.0g  2 Nov 2017

$ /usr/local/apache2/bin/httpd -v
Server version: Apache/2.4.35 (Unix)
Server built:   Oct  3 2018 13:34:46

パッと示された設定をうまい具合にhttp-ssl.confへ書き込んだらQualysのサイトへアクセスしてClear cacheをクリックし、再度SSL Server Testを執り行うと何だか分からないけれども大変よさそうな評価である。

検査結果

参考:
SSL Server Test (Powered by Qualys SSL Labs)
Mozilla SSL Configuration Generator
Security/Server Side TLS

ApacheにSSLサーバ証明書の設定をおこなう

OS: Ubuntu Server 18.04.1 LTS
Apache 2.4.35

SSLサーバ証明書を取得したらWebサーバの設定もアタボウに必要である。ソースからインストールしたApache2の設定ファイルを編集してゆく。幸い conf/extra/httpd-ssl.conf に雛形が用意されているので大きく書き換える必要が無くて大変有難いものである。

暗号化通信をおこなうためのモジュールがロードされていないと

AH00526: Syntax error on line 2 of /usr/local/apache2/conf/extra/httpd-ssl.conf:
Invalid command 'SSLCipherSuite', perhaps misspelled or defined by a module not included in the server configuration

というエラーメッセージを頂戴したり

AH00526: Syntax error on line 8 of /usr/local/apache2/conf/extra/httpd-ssl.conf:
SSLSessionCache: 'shmcb' session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?).

という具合にSSLセッションをキャッシュする機能を活用するためのモジュールが必要である旨、知らされるから予めモジュールをロードするように各項目をコメントアウトしておく。

$ sudo vi /usr/local/apache2/conf/httpd.conf 
LoadModule ssl_module modules/mod_ssl.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
Include conf/extra/httpd-ssl.conf

あとはhttpd-ssl.confの雛形を利用してVirtualHostの設定をしたり証明書や秘密鍵を読み込むようよしなに書き換えてconfigtestでSyntax OKが出れば終いである。

$ sudo vi /usr/local/apache2/conf/extra/httpd-ssl.conf
SSLCertificateFile "/etc/letsencrypt/live/www7390uo.sakura.ne.jp/fullchain.pem"
SSLCertificateKeyFile "/etc/letsencrypt/live/www7390uo.sakura.ne.jp/privkey.pem"

mod_rewriteで以ってHTTPでのアクセスをHTTPSへリダイレクトさせる為に.htaccessも追加してやった。クライアントへ返すHTTPステータスコードは301 Moved Parmanentlyにしてやれば良さそうな情勢である。

$ vi .htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

ownCloudのX-Frame-Optionsにまつわる警告の解決に取り組む

OS: Ubuntu Server 18.04.1 LTS
Apache 2.4.34
ownCloud Server 10.0.10.4

ownCloudの設定画面にある「管理」の中の「一般」という項目へアクセスするとセキュリティ&セットアップ警告が幾つか表示されている。

そのうちの

“X-Frame-Options” HTTP ヘッダは “SAMEORIGIN” に設定されていません。これは潜在的なセキュリティリスクもしくはプライバシーリスクとなる可能性があるため、この設定を見直すことをおすすめします。

に対応してゆく。然し乍らクリックジャッキング攻撃を避けられるという宣伝に乗ってとうにhttpd.confへ記述を済ませているのに此は如何にとおもう。

$ grep 'SAMEORIGIN' /usr/local/apache2/conf/httpd.conf
Header always append X-Frame-Options "SAMEORIGIN"

すみずみまで点検しているとownCloudが用意して呉れた.htaccessでも同じ目的の達成を目標として瓜二つの設定が記載されていた。

$ cat public_html/owncloud/.htaccess
    Header set X-Frame-Options "SAMEORIGIN"

どうやらhttpd.confと.htaccessの二つの設定が混じり合ってX-Frame-Optionsヘッダが変梃りんな応答になってしまう模様である。これが原因で件のセキュリティ&セットアップ警告が表示されている。

ひとまず.htaccessの Header set X-Frame-Options "SAMEORIGIN"をコメントアウトすることで警告が現れなくなった。

参考:
X-Frame-Options – HTTP | MDN
Apache Module mod_headers