OpenBSD本家でlighttpdを動かす その4（OpenBSD 6.6R、2020/2/2）

先ほどOpenBSDでsyspatchとpkg_add -uを実施したところ、syspatchでは/var/www/tmpのオーナーは変わらず、pkg_add -uで/var/www/tmpのオーナーがwww:wwwに初期化されました。もう面倒なので、/var/www/tmpはwww:wwwで運用することにします。

変更箇所

openbsd# cat /etc/lighttpd.conf
#server.username            = "_lighttpd"
#server.groupname           = "_lighttpd"
server.username            = "www"
server.groupname           = "www"

openbsd# cat /etc/php-fpm.conf
user = www
group = www
;user = _lighttpd
;group = _lighttpd

listen.owner = www
listen.group = www
;listen.owner = _lighttpd
;listen.group = _lighttpd

openbsd# pwd
/var/www/logs/
openbsd# ls -lag
-rw-r--r--   1 www   www       3887 Feb  2 03:09 access.log
-rw-r--r--   1 www   www     247980 Feb  2 02:56 error.log

上記を修正しました。ちょっと様子見です。

タグ：lighttpd

OpenBSD本家でlighttpdを動かす その3（OpenBSD 6.6R、2019/12/29）

OpenBSDで定期的にsyspatchやpkg_add -uを実施するのですが、/var/www/tmpのオーナーがwww:wwwに戻ってしまいphp-fpmを使用するphpがPermission deniedを発生させていました。
それを考えると、lighttpdやphp-fpmは、www:wwwで動かした方が良いかもしれませんね。

タグ：lighttpd

OpenBSD本家でlighttpdを動かす その2（OpenBSD 6.6R、2019/11/10）

その1でだいたいのことは終わっています。が、実はここからが一番面倒だったりします。php動作が失敗し、Permission deniedのエラーメッセージのオンパレード。まあ、原因が分かってしまえば早いのですけどね。

openbsd# cat /var/www/logs/error.log
2019-11-10 13:08:43: (gw_backend.c.236) establishing connection failed: Permission denied socket: unix:/run/php-fpm.sock
2019-11-10 13:08:45: (gw_backend.c.315) gw-server re-enabled: unix:/run/php-fpm.sock  0 /run/php-fpm.sock
2019-11-10 13:35:39: (chunk.c.523) opening temp-file failed: /tmp/lighttpd/lighttpd-upload-tgN45f Permission denied
2019-11-10 13:36:53: (chunk.c.523) opening temp-file failed: /tmp/lighttpd/lighttpd-upload-5YM4rt Permission denied
2019-11-10 13:41:04: (chunk.c.523) opening temp-file failed: /tmp/lighttpd/lighttpd-upload-QWDxGe Permission denied

原因は文字通りアクセス権限、パーミッションです。ざっと以下が揃っている必要があります。

openbsd# cat /etc/lighttpd.conf
server.username            = "_lighttpd"
server.groupname           = "_lighttpd"

openbsd# cat /etc/php-fpm.conf
;listen.owner = www
;listen.group = www
listen.owner = _lighttpd
listen.group = _lighttpd

openbsd# ls -lag /var/www/run/
srw-rw----   1 _lighttpd  _lighttpd    0 Nov 10 13:52 php-fpm.sock

openbsd# ls -lag /var/www/htdocs/
drwxr-xr-x   5 _lighttpd  _lighttpd  512 Nov 10 14:55 .
drwxr-xr-x   5 _lighttpd  _lighttpd  512 Nov 10 15:42 js-cms

openbsd# ls -lag /var/www/
drwx-----T   3 _lighttpd  _lighttpd  512 Nov 10 17:13 tmp

面倒なのは、lighttpdは“_lighttpd：_lighttpd”がデフォルトの権限としてインストールされている一方、php-fpmや/var/wwwは“www：www”がデフォルトになっているので、どちらかに統一させる必要がありました。
私は_lighttpdに統一したのですが、もしかするとwwwに統一した方が楽だったかもしれません。
最後に以下のようなエラーも出ますが、lighttpd.confにserver.upload-dirs設定の記載がないので、適当に/tmpなどと追加しておきます。

openbsd# cat /var/www/logs/error.log
2019-11-10 12:12:29: (configfile.c.1620) server.upload-dirs doesn't exist: /var/www//var/tmp

他にあるかもしれませんが、js-cmsはこれで動くようになりました。

タグ：lighttpd

OpenBSD本家でlighttpdを動かす その1（OpenBSD 6.6R、2019/11/10）

OpenBSDではapacheが標準Webサーバなのかと思っていたら、いろいろと選択肢があるようですね。

openbsd# pkg_info -Q httpd
apache-httpd-2.4.41
bozohttpd-20190228
darkhttpd-1.12
libmicrohttpd-0.9.66
lighttpd-1.4.54
sthttpd-2.26.4p4

個人的にはlighttpdが好きなので、lighttpd + PHPの環境を作ってみることにします。まずはlighttpd-1.4.54、php-7.3.11、php-cgi-7.3.11をインストールします。lighttpd自体の設定はWebにいっぱい転がっているので割愛します。

デフォルトのlighttpdの設定は以下のようにchrootする仕様になっています。

openbsd# cat /etc/lighttpd.conf
# chroot() to directory
server.chroot              = "/var/www/"

起動しようとすると早速怒られるので、以下を参考にmknodします。
https://stackoverflow.com/questions/18819557/configuring-devices-in-chroot-environment-openbsd

openbsd# cat /var/www/logs/error.log
2019-11-10 10:29:00: (server.c.785) opening /dev/null failed: No such file or directory
2019-11-10 10:29:00: (server.c.1518) Opening errorlog failed. Going down.

openbsd# cd /var/www
openbsd# mkdir dev
openbsd# cd dev
openbsd# mknod -m 666 null c 2 2

lighttpd.confのphp周りの設定を整えます。デフォルトでは以下のようになっています。

fastcgi.server             = ( ".php" =>
                               ( "localhost" =>
                                 (
                                  "socket" => "/var/run/lighttpd/php-fastcgi.socket",
                                   "bin-path" => "/usr/local/bin/php-cgi"
                                 )
                               )
                            )

bin-pathが通っていないと怒られるので、locateの結果から/usr/local/bin/php-cgi-7.3に直しますが、メッセージは変わりません。よくよく考えるとchrootしているので、見つからないのも当然ですね。
chrootを考慮してbin配下を再構築するのは面倒なので、proxyもしくはsocket経由でfastcgiと連携できるようにします。proxyよりsocket経由の方が早いらしいので、chroot後の階層を考慮して、以下のように修正しました。

openbsd# cat /etc/lighttpd.conf
fastcgi.server             = ( ".php" =>
                               ( "localhost" =>
                                 (
                                   "socket" => "/run/php-fpm.sock"
                                 )
                               )
                            )

php-fpmは放置すると肥大化していくらしいので、以下のページを参考にメモリ節約チューニングも施しておきます。
https://hackers-high.com/linux/php-fpm-config/

openbsd# cat /etc/php-fpm.conf
listen = /var/www/run/php-fpm.sock
pm = static
pm.max_children = 2

なぜかhtdocsが見つからないと言われますが、確実に存在しているのでlighttpd.confの表記を直します。

openbsd# cat /var/www/logs/error.log
2019-11-10 12:51:16: (response.c.161) file not found ... or so:  File exists / -> htdocs/

openbsd# cat /etc/lighttpd.conf
# server.document-root        = "htdocs/"
server.document-root        = "/htdocs/"

その2へ続く。

タグ：lighttpd

OpenBSD本家でpfを動かす その2（OpenBSD 6.6R、2019/11/10）

pfはログ確認方法がちょっと特殊であり、テキストログに吐き出されたものをcatやlessで見るといったよく形ではありません。
簡単に言うと、tcpdumpのバイナリキャプチャ形式で吐き出されるため、tcpdumpによって見やすいようにデコードします。取っ付きにくいように感じるかもしれませんが、tcpdumpのフィルタオプションがそのまま使えるので、慣れればむしろ便利だったりします。

インタフェースを監視してリアルタイムのログを表示させるには、
　tcpdump -n -e -ttt -i pflog0

蓄積されたバイナリログを表示させるには、
　tcpdump -n -e -ttt -r /var/log/pflog

といった形で確認可能です。

先日のpf.confをもうちょっとスマートな形に書き換えてみました。

openbsd# cat /etc/pf.conf
#       $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

set skip on lo

#block return   # block stateless traffic
#pass           # establish keep-state

# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010

# Port build user does not need network
block return out log proto {tcp udp} user _pbuild

# my rules
set block-policy drop

/* 許可するサービス、ブロックするサービスなどを事前に定義 */
tcp_pass      = "{ smtp, submission, xxxx }"　　　/* sshのポートをxxxxに変更 */
tcp_block_log = "{ telnet }"
tcp_block     = "{ domain, ntp, 445, 1433, mysql, rdp }"
udp_pass      = "{ }"
udp_block     = "{ domain, ntp, snmp, ldap, sip }"

# scrub
match in all scrub (no-df)

block log all
block return in log quick proto tcp to any port ssh　　　/* もともとのsshポートは偽装応答。sshdの設定も変更 */
block in log quick proto tcp to any port $tcp_block_log　　　/* 変数を利用して集約 */
block in quick proto tcp to any port $tcp_block　　　/* 変数を利用して集約 */
block in quick proto udp to any port $udp_block　　　/* 変数を利用して集約 */
block in quick inet6 all

# blacklist　　　/* ブラックリストはファイルで管理 */
table <my_blacklist> persist file "/etc/pf.blacklist"
block in quick from <my_blacklist>

# pass rules
pass in log proto tcp to any port $tcp_pass modulate state
pass in proto icmp all keep state

pass out proto tcp all modulate state
pass out proto udp all keep state
pass out proto icmp all keep state

タグ：PF

OpenBSD本家でpfを動かす その1（OpenBSD 6.6R、2019/11/10）

OpenBSDにはpfというパケットフィルタリングツール、つまりはソフトウェアファイアウォールが付いています。FreeBSDだとipfwに該当するものです。まあ、FreeBSDにもpfは移植されていますけどね。
主要な機能面だけを見れば、他のフィルタリングツールと大差はないと思います。

しかしこのpf、他のツールにはない面白い特徴を持っています。それは、ポリシ評価がラストマッチング方式であるということです。実はこの方式自体はpf独自のものという訳ではく、pfの前身となっているipf（IP Filter）の思想を引き継いでいます。

ラストマッチング方式というのは世間一般で使用されているファイアウォールや、ネットワーク機器のフィルタとは概念が異なり、
・マッチ処理は途中でヒットするものがあっても評価が終わらず、残りのマッチ処理が継続される
・マッチ処理で該当した「最後」のポリシが実行される
となります。

よくあるファイアウォールポリシの例では、
　順序10 http, httpsの接続受付を許可
　順序20 自発の通信は許可
　順序30 全ての通信を不許可
といったものを見かけますが、これをpfで評価するとどんな通信も順序30がラストマッチングとなり、全ての通信がブロックされてしまいます。実際は、マッチ処理を途中で終わらせるquickオプションがあるため、自分たちがよく知っている直観的な記載をすることも可能です。
OpenBSDでサーバを立てる場合、pfの設定は必須となるでしょう。うちは以下のようなpf.confで運用しています。

openbsd# cat /etc/pf.conf
#       $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

set skip on lo　　/* ループバックインタフェースはスキップ */

# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010　　　/* ひな形にあるデフォルト */

# Port build user does not need network
block return out log proto {tcp udp} user _pbuild　　　/* ひな形にあるデフォルト */

# my rules
set block-policy drop　　　/* blockアクションでは、パケットを廃棄する */
tcp_pass = "{ ssh, smtp, https, submission }"　　　/* 接続を受け付けるサービスを定義 */

# scrub
match in all scrub (no-df)　　　/* パケットの正規化。攻撃に対する緩衝処理 */

/* 以下、実際の詳細な運用ポリシ */
block log all　　　/* 暗黙のdeny相当。どこにも該当しない場合の受け皿 */
block in quick proto tcp to any port "{ telnet, 445, 1433, mysql, rdp }"　　　/* 数が多い攻撃なので、ログに残さず破棄 */
block in quick inet6 all　　　/* VPSがIPv6非対応なのでIPv6関係は全面廃棄 */

# blacklist　　　/* ログに残ってる攻撃元をブラックリストで廃棄（手動） */
block in quick from 35.201.237.65
block in quick from 37.49.231.15
block in quick from 40.77.167.2
block in quick from 45.227.254.30
block in quick from 47.75.186.129
block in quick from 51.68.225.51
block in quick from 71.6.199.23
block in quick from 77.247.108.77
block in quick from 77.247.108.119
....

pass in proto tcp to any port $tcp_pass modulate state　　　/* 許可しているサービスは接続を受け付ける */
pass in proto icmp all keep state　　　/* ICMP系を許可（今後絞るかも） */

pass out proto tcp all modulate state 　　　/* 自発のTCPを許可 */
pass out proto udp all keep state 　　　/* 自発のUDPを許可 */
pass out proto icmp all keep state 　　　/* 自発のICMPを許可 */

とまあこんな感じです。最初は取っ付きにくい感じもしましたが、慣れてしまえば問題ありませんね。

タグ：PF

OpenBSD本家でOpenSMTPDを動かす その2（OpenBSD 6.6R、2019/11/06）

ここからはOpenBSD上のOpenSMTPDのお話です。
私はFreeBSDに移植された5.9系から本家最新の6.6系に乗り換えたのですが、前回私が「セキュリティのためなら死ねる」と書いたように、ものの見事に下位互換性をぶった切ってくれています。取りようによっては、粛正ともとれる潔さがありますね。

マニュアル整備もセキュリティ向上の一環、という思想から公式マニュアルが完備されているのは良いのですが、世界的に見て6.6系の情報やサンプルコンフィグが圧倒的に不足しており、かなり茨の道になるのではないかと思います。

文法の変更点として、従来はaccept構文の中にマッチ条件とアクションの双方を記載していた訳ですが、新しい文法ではマッチ条件(match構文)とアクション（action構文）が分離され、異なる複数のマッチ条件から同一のアクションに遷移させることが可能となりました。

うちのメールサーバは自立している純粋なメールサーバという訳ではなく、so-netのメールサーバに金魚のフンのようにぶら下がっています。基本的には、自分自身で保有している独自ドメイン上に無限のメールアドレスを作成し、以下の動作をさせています。
　（1）独自ドメイン上に作成したオリジナルメールアドレス（aliasメールアドレス）の受付
　（2）前述のaliasメールアドレスは、自分の保持している実メールアドレス（yahooやgmailなど）に宛先を置換（書き換え）
　（3）自分の実メールアドレスへの転送は、so-netメールサーバへリレーを依頼

もっと簡単に書くと、独自ドメイン上に作成したダミーメールアドレス宛にメールを送ると、gmail等の実体に変換され、自分に届くというものです。
私のsmtpd.confでは、こんな感じで実現しています。説明がないと困ると思うので/* ～ */でコメントを付記しています。

openbsd# cat /etc/mail/smtpd.conf
#       $OpenBSD: smtpd.conf,v 1.12 2019/07/24 15:31:53 kmos Exp $

# This is the smtpd server system-wide configuration file.
# See smtpd.conf(5) for more information.

# my table
table aliases file:/etc/mail/aliases　　　/* OpenBSDのシステムaliasを読み込み */
table mymail_mydomain db:/etc/mail/my_aliases_mydomain.db　　　/* 独自ドメインにおけるダミーアドレスと実体のマッピング */
table mymail_recipient db:/etc/mail/my_recipient.db　　　/* so-netメールサーバにリレーを許可するメールアドレス（＝実メールアドレス） */
table mymail_auth db:/etc/mail/my_auth.db　　　/* リレー先としてso-netメールサーバを利用するためのクレデンシャル情報（認証情報）*/
table mymail_blacklist db:/etc/mail/my_blacklist.db　　　/* ブラックリスト */


# global config
listen on lo0
listen on vio0
smtp limit max-mails  20　　　/* この辺はお好みで */
smtp limit max-rcpt   100　　　/* この辺はお好みで */
smtp max-message-size 10M　　　/* この辺はお好みで */


# my action
action "act_local" mbox alias <aliases>　　　/* ローカルへの配送 */
action "act_aliases" expand-only alias <mymail_mydomain>　　　/* aliasメールアドレスと実体をマッピングさせるだけの処理 */
action "act_relay" relay host smtp+tls://[e-mail]:587 auth <mymail_auth>　　　/* so-netメールサーバへのリレー */


# my match
# match from local !for local reject　　　/* aliasメールアドレスを実体にマッピングさせるとfrom localとして再評価されるため、これが存在するとリレー処理が失敗する */
match from src <mymail_blacklist> for any reject　　　/* ブラックリストに該当する送信元は拒否 */
match from local for local action "act_local"　　　/* ローカルへの配送用 */
match from any for domain "mydomain.com" action "act_aliases"　　　/* 独自ドメインのダミーアドレスを受理するための条件 */
match from local for any rcpt-to <mymail_recipient> action "act_relay"　　　/* 実体メールをso-netにリレーさせるための条件 */

タグ：OpenSMTPD

OpenBSD本家でOpenSMTPDを動かす その1（OpenBSD 6.6R、2019/11/06）

・健康（＝セキュリティ）のためなら死ねる
・セキュリティ潔癖症

と誰が言ったか知りませんが、ここからOpenBSDを連想できる人は、なかなかよく分かってらっしゃる人かもしれません。これらは揶揄した表現ではありますが、個人的にはOpenBSDの姿勢や信条を端的に表すものとして、良い意味で好きな表現だったりもします。

さてさて、VPSで構築している公開メールサーバについて、長らくFreeBSD 11.3R + OpenSMTPDという運用を続けてきましたが、先日、FreeBSD 12.1Rがリリースされ、いよいよ本格的に12系にシフトしまうのと、FreeBSDに移植されたOpenSMTPDがOpenSSLのバージョンの関係で5.9系で放置されているので、思い切ってVPSをOpenBSDに入れ替え、最新のOpenSMTPDでメールサーバを構築し直すことに決めました。

･･･とまあ、すごくタイムリーなのですが、FreeBSD 12.1Rのリリースに伴い、portsのOpenSMTPDも本家と同じ最新の6.6系にアップデートされていました。あらら。

root@MyFreeBSD:~ # cat /usr/ports/mail/opensmtpd/Makefile
# Created by: Ashish SHUKLA <[e-mail]>
# $FreeBSD: head/mail/opensmtpd/Makefile 515714 2019-10-26 16:24:47Z fluffy $

PORTNAME=       opensmtpd
PORTVERSION=    6.6.0
DISTVERSIONSUFFIX=      p1

まあ、結果的に言えば、このタイミングで無理にOpenBSDに変える必要はなかったということになりますが、後悔はしていません。OpenBSDも充分に面白いことが分かったので、自宅サーバはFreeBSD、パブリック公開サーバはOpenBSDという形でやっていきますかねえ。

時の流れとは不思議なもので、よもや私がOpenBSDを使うことになるとは思ってもみませんでした。

タグ：OpenSMTPD

OpenBSDでJS CMSを動かす （OpenBSD 6.6R、2019/11/04）

いろいろとブログ系CMSエンジンを探しているのですが、OpenBSDではApache2は使えるもののpkg_addで使用できるライブラリが限られているので、なかなか選択肢がないのですよね。
あとメモリ1GBの環境でひっそりと動かしたいので、DBにMySQLを要求するものはなるべく避けたいです。できればSQLiteが良いです。
・SOY CMS：リダイレクト関係がうまく動かない。失敗
・OneThird CMS：インストーラ含めphpスクリプトがうまく動かない。失敗
・WordPressのSqlite版：公開停止になってた
・CMONOS：よく覚えていないが失敗

とまあ途方に暮れていたのですが、JS CMSがなかなか良さげです。
https://www.js-cms.jp/

ざっと動かしてみた感想は、
■良いところ
・何よりOpenBSDでちゃんと動く！
・なんとDBレス。エンジンが静的にHTMLを生成する。めちゃめちゃ軽い
・インタフェースは一通り揃ってる。そんなに悪くない
・WordPressのように1から100までやってくれるのではなく、HTMLの生成をアシストしてくれるような動作。設計思想的には私はこっちの方が好き（車で言うとオートマではなく、マニュアルのような感じ）
・バックアップが楽（ディレクトリをまるごとバックアップすれば良い。初期状態で1.5MB程度）
・以下のJS CMSの公式サイトもJS CMSエンジンで作っているようで、まさにこんな感じのサイトが作成できます

■悪いところ
・ページの作成にHTMLタグやスタイルシートの知識が必要（概念を知っておく必要あり）
・ドキュメントが古い、更新されていない（まあなんとなく分かるのでさほど困らない）
・ページの生成が静的のため、自分の修正を反映すべきHTMLページを全て手動で更新（反映）していく必要がある
・テーマのようなものはなく、デザインはほぼ手動

といった感じです。

OpenBSDでbaserCMSを動かす （OpenBSD 6.5R、2019/09/10）

とりあえず表面的ですが、OpenBSD上でbaserCMSが動きました。基本的にはWebに転がっているインストーラを展開して設置するだけです。ただ不親切なのは、主流が4.x系なのに、インストール解説ページは2.x系向け、3.x系向けしか用意されていませんでした。

一つ面白いと思ったのは、OpenBSDの思想だと思うのですが、X系のライブラリが不足してインストールで詰まりました。これはFreeBSDであれば、X系のライブラリまでがportsの依存関係に含まれていて、必要なものは自動で再帰的にインストールしてくれるのですが、OpenBSDの場合はそういった依存関係はなく、ベースシステムに含まれるXorgが全てのようです。
もっとわかりやすく言えば、私はXorgを使わないのでX関係は不要だと思い、OpenBSDの最初のインストール段階でXorgに関係するものを全て“外して”インストールしたのですが、後（≒pkg_add）になって必要になったということです。
再度OpenBSDのインストール工程を行い、「Install」ではなく「Upgrade」でX関係を導入し、事なきを得ました。

baserCMSが動き始めると初期チェックでgdライブラリがないと言われます。以下のようにphp-gdをインストールすれば良いのですが、そのままではphp -mの一覧には出てきません。

OpenBSD# pkg_info -Q gd
php-gd-7.3.9 (installed)

OpenBSD# locate gd
/usr/local/lib/php-7.3/modules/gd.so

OpenBSD# php-7.3 -m
[PHP Modules]
bcmath
calendar
Core...

これは/etc/php-7.3.iniを編集する必要があります。少し分かりにくいのは、gd2のひな形は用意されているのですが、gdは用意されておらず、自身でgdの行を独自に追加してあげる必要があることです。他にもextension=mysqliなどはWordPressで必要になった際に有効にしています。

;extension=gd2
extension=gd
extension=mysqli
extension=pdo_mysql
extension=pdo_sqlite

なお、baserCMSは小規模運用の場合sqliteでもいけるようなので、個人ブログ程度ならそういった運用もありかもしれません。

タグ：PHP