As I Please

MTのいんすとーるの練習と、その他びぼうろく・・・

タグ「Freebsd」が付けられているもの


メールがspamassasin (sa-spamd) を通っていない。

spamassasinは怪しいメールには、メール本文の冒頭に警告メッセージをつけてくれるので、スマートフォンなどのメール通知で怪しいメールが来たかどうかをすぐに見分けることができる。本当はすぐに隔離して mailboxに入らないようにすればいいんでしょうが。。。
ところが最近、別のサーバ(MX secondary)に届くメールにそれが入らなくなってしまった。どうも milterでsa-spamd を通らなくなってしまったようだ。
milter-manager ? spamd ? socketのowner,permission ? 何が悪いのかよくわからないまま、perlのライブラリ、ruby、openssl,gpgなどいろいろアップデートしてみたが、なかなか解決と行かなかった。


/var/log/spamd.log をつぶさに追っかけて、spamdがちゃんと起動していないのが原因のよう。
どうも sendmail をバージョンアップしたときからおかしくなってしまったよう。


error: Can't locate Net/SSLeay.pm in @INC
spamd: error: Bad arg length for Socket::unpack_sockaddr_in, length is 28, should be 16

あたりが問題だったようで、以下の記事を参照に、Socket6 を再インストールしたら解決した。
https://freebsd.sing.ne.jp/daily/09/09/05.html

sshへの不正アクセスが多いので、denyhosts をいまさらながらに導入

しつこいのは手動で /etc/hosts.allow をメンテしていたり、/etc/ssh/sshd_config で MaxAuthTries 2 とかですぐにたたき落とすようにしていたけど、やはり自動化しておいたほうが無難かと。

http://tokcs.com/2012/12/freebsd-denyhosts%E3%82%92%E5%B0%8E%E5%85%A5/を見つけてdenyhostsが簡単そうなので、インストールしてみる。
portsから入れたが、python3 が入っていればすんなり入る。
/sbin/iptables を起動しようとしたりするけどとりあえず放っておく。
早速起動したら、/var/log/auth.log を見て、3つのIPアドレスを denyした。
台湾、フランス、ロシア(シベリア)
今後はこの手は必須で入れておく必要ありかなぁ。。。時にアドレスリストのメンテが必要かもしれない(膨大に増えていく?)けど。


cmake on FreeBSD9

やっぱり いまどき gccだけじゃなく、clang, llvm あたりを入れておきたいということで、sourceをもってきてみたら、ほぼほぼ cmakeを要求される。
昔に入れたcmakeは ver3.5.2 で古すぎる。
最新のもの(3.18.0)を持ってきて bootstrapをかけると dup3,accept4,pipe2 あたりが必要で、これは FreeBSD10以降じゃないと入っていない。
ということで FreeBSD9で使えるcmakeを探してみると、、、1つ前の 3.17.3で FreeBSDのバージョンを見て、dup3,pipe2とかを利用したりしなかったり。3.18.0だと問答無用に使っている。ということで、まずは
dup3とかが入っていない /usr/lib/libc.so (/lib/libc.so7へのシンボリックリンク)を利用してcmake(3.17.3)を作成する。
sourceを持ってきて、

CC=/usr/local/bin/gcc ./bootstrap
でコンパイルしてみると、

/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.14 required by /usr/local/src/cmake-3.17.3/Bootstrap.cmk/cmake not found

次は


CC=/usr/local/bin/gcc CPP="-std=c++17" LD_LIBRARY_PATH=/usr/local/lib CXX="/usr/local/bin/g++"

で行ったが、

/usr/local/src/cmake-3.17.3/Source/cmFileCommand.cxx: メンバ関数 ‘bool \xe7\x84\xa1\xe5\x90\x8d}::cURLProgressHelper::UpdatePercentage(double, double, std::__cxx11::string&)’ 内:
/usr/local/src/cmake-3.17.3/Source/cmFileCommand.cxx:1445:38: エラー: ‘lround’ is not a member of ‘std’
this->CurrentPercentage = std::lround(value / total * 100.0);

で失敗する。 std::lround が無いバージョンを探すと、https://gitlab.kitware.com/cmake/cmake/-/blob/v3.13.4/Source/cmFileCommand.cxx のようで、3.13.4 を持ってきてやり直してみる。
CC="/usr/local/bin/gcc" CXX="/usr/local/bin/g++" ./bootstrap
CC="/usr/local/bin/gcc" CXX="/usr/local/bin/g++" gmake
CC="/usr/local/bin/gcc" CXX="/usr/local/bin/g++" gmake test
CC="/usr/local/bin/gcc" CXX="/usr/local/bin/g++" gmake install
test でいくらか失敗するけど、まぁそのくらいなら、、、で入れてしまう。 /usr/lib/libstdc++.so.6 が、、、と言われるので、バックアップとって/usr/local/lib/にsymlink をはってしまう。

cmake on FreeBSD9

やっぱり いまどき gccだけじゃなく、clang, llvm あたりを入れておきたいということで、sourceをもってきてみたら、ほぼほぼ cmakeを要求される。
昔に入れたcmakeは ver3.5.2 で古すぎる。
最新のもの(3.18.0)を持ってきて bootstrapをかけると dup3,accept4,pipe2 あたりが必要で、これは FreeBSD10以降じゃないと入っていない。
ということで FreeBSD9で使えるcmakeを探してみると、、、1つ前の 3.17.3で FreeBSDのバージョンを見て、dup3,pipe2とかを利用したりしなかったり。3.18.0だと問答無用に使っている。ということで、まずは
dup3とかが入っていない /usr/lib/libc.so (/lib/libc.so7へのシンボリックリンク)を利用してcmake(3.17.3)を作成する。
sourceを持ってきて、

CC=/usr/local/bin/gcc ./bootstrap
でコンパイルしてみると、

/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.14 required by /usr/local/src/cmake-3.17.3/Bootstrap.cmk/cmake not found

次は


CC=/usr/local/bin/gcc CPP="-std=c++17" LD_LIBRARY_PATH=/usr/local/lib CXX="/usr/local/bin/g++"

で行ったが、

/usr/local/src/cmake-3.17.3/Source/cmFileCommand.cxx: メンバ関数 ‘bool \xe7\x84\xa1\xe5\x90\x8d}::cURLProgressHelper::UpdatePercentage(double, double, std::__cxx11::string&)’ 内:
/usr/local/src/cmake-3.17.3/Source/cmFileCommand.cxx:1445:38: エラー: ‘lround’ is not a member of ‘std’
this->CurrentPercentage = std::lround(value / total * 100.0);

で失敗する。 std::lround が無いバージョンを探すと、https://gitlab.kitware.com/cmake/cmake/-/blob/v3.13.4/Source/cmFileCommand.cxx のようで、3.13.4 を持ってきてやり直してみる。
CC="/usr/local/bin/gcc" CXX="/usr/local/bin/g++" ./bootstrap
CC="/usr/local/bin/gcc" CXX="/usr/local/bin/g++" gmake
CC="/usr/local/bin/gcc" CXX="/usr/local/bin/g++" gmake test
CC="/usr/local/bin/gcc" CXX="/usr/local/bin/g++" gmake install
test でいくらか失敗するけど、まぁそのくらいなら、、、で入れてしまう。 /usr/lib/libstdc++.so.6 が、、、と言われるので、バックアップとって/usr/local/lib/にsymlink をはってしまう。

certbot on FreeBSD9

なかなかやめられない古いOSで、次は証明書(let's encrypt) を使い続けたくて。。。 運用には certbot を使うのがデフォルトのようで、ports が使えないことを前提にすれば、git clone で持ってくるのがベスト。 ということで、

git clone https://github.com/certbot/certbot

を行ったら、

SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

ということで、gitが tls1.2をしゃべらない!のが問題(古い git clientすぎた)ので、まずはこれをバージョンアップしてみた。ところが、、、直らない。。。見ると gitは裏では curl を使っているようなので、これが tls1.2を使うようにしないといけなかった。ということで、curlも最新版を持ってきて openssl も tls1.2 を使えるバージョンを参照してinstall. でも、今度は git-remote-https.core を吐いて何もすすまない。shared ライブラリ参照が違うとかそこらへんだろうから、ということで、libzも入れ直してみたがやはりおかしい。。。 コンパイラ環境の問題かもと疑ってみると、そこらへんだったみたい。 curl -> /usr/bin/gcc 利用 git -> /usr/bin/gcc 利用は coreを吐く。 ということで環境変数 CC=/usr/local/bin/gcc を設定しコンパイルしなした gitだとちゃんと cloneできた。 libz,libiconv,libintl,libchasetあたりも/usr/local/lib 側をちゃんとリンクしてくれた。 いまどきllvm,clangなんでしょうが、、、、、もうちょい生きながらえさせて。 git cloneでファイルをダウンロードできたが、次にhttps://certbot.eff.org/docs/contributing.htmlを参照して、

python3 tools/venv3.py

なのだが、ここでどうも yaml(pyyaml)のところでエラー。これも gccを利用しているが/usr/bin/gcc を見ているケースと/usr/local/bin/gcc を見るケースがあるのが問題のよう。 .cshrc で /usr/local/bin を優先させることで /usr/local/bin/gcc を先に見るようにしたところ、まずはここはクリア。 bash で
source venv3/bin/activate
run_acme_server &
certbot_test certonly --standalone -d test.example.com
と実行してまずはローカルで動くかどうかを試すのだが、run_acme_server のところで落ちる。うまく webserver が起き上がってくれない。
[venv3] root@host:/usr/local/src/certbot # run_acme_server
=> Starting pebble instance deployment...
ELF binary type "0" not known.
=> Tear down the test infrastructure...
=> Test infrastructure stopped and cleaned up.
Traceback (most recent call last):
  File "/usr/local/src/certbot/venv3/bin/run_acme_server", line 11, in 
    load_entry_point('certbot-ci', 'console_scripts', 'run_acme_server')()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 221, in main
    with acme_server as acme_xdist:
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 96, in __enter__
    self.start()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 62, in start
    raise e
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 57, in start
    self._prepare_pebble_server()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 135, in _prepare_pebble_server
    self._launch_process(
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 205, in _launch_process
    process = subprocess.Popen(command, stdout=stdout, stderr=subprocess.STDOUT, cwd=cwd, env=env)
  File "/usr/local/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/lib/python3.8/subprocess.py", line 1702, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
OSError: [Errno 8] Exec format error: '/usr/local/src/certbot/certbot-ci/certbot_integration_tests/assets/pebble_v2.3.0_linux-amd64'
なんか、certbot が linuxの実行ファイル(linux binary for amd64)を抱えていてこれが freebsdでは動かない、ということのようだ。linux-compat とか入れればいいのかもしれないがそこまでやるかな。。。ということでこの線はあきらめて、、、 certbot は普通に python(2or3)のコードだったことを思い出して、$src/certbot/の中を見ると、setup.pyがあるので、
python3 setup.py build
python3 setup.py install
で、/usr/local/bin/certbot にインストールされた。
certbot certonly --standalone -d test.example.com
でちゃんと証明書が降りてきた。

certbot on FreeBSD9

なかなかやめられない古いOSで、次は証明書(let's encrypt) を使い続けたくて。。。 運用には certbot を使うのがデフォルトのようで、ports が使えないことを前提にすれば、git clone で持ってくるのがベスト。 ということで、

git clone https://github.com/certbot/certbot

を行ったら、

SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

ということで、gitが tls1.2をしゃべらない!のが問題(古い git clientすぎた)ので、まずはこれをバージョンアップしてみた。ところが、、、直らない。。。見ると gitは裏では curl を使っているようなので、これが tls1.2を使うようにしないといけなかった。ということで、curlも最新版を持ってきて openssl も tls1.2 を使えるバージョンを参照してinstall. でも、今度は git-remote-https.core を吐いて何もすすまない。shared ライブラリ参照が違うとかそこらへんだろうから、ということで、libzも入れ直してみたがやはりおかしい。。。 コンパイラ環境の問題かもと疑ってみると、そこらへんだったみたい。 curl -> /usr/bin/gcc 利用 git -> /usr/bin/gcc 利用は coreを吐く。 ということで環境変数 CC=/usr/local/bin/gcc を設定しコンパイルしなした gitだとちゃんと cloneできた。 libz,libiconv,libintl,libchasetあたりも/usr/local/lib 側をちゃんとリンクしてくれた。 いまどきllvm,clangなんでしょうが、、、、、もうちょい生きながらえさせて。 git cloneでファイルをダウンロードできたが、次にhttps://certbot.eff.org/docs/contributing.htmlを参照して、

python3 tools/venv3.py

なのだが、ここでどうも yaml(pyyaml)のところでエラー。これも gccを利用しているが/usr/bin/gcc を見ているケースと/usr/local/bin/gcc を見るケースがあるのが問題のよう。 .cshrc で /usr/local/bin を優先させることで /usr/local/bin/gcc を先に見るようにしたところ、まずはここはクリア。 bash で
source venv3/bin/activate
run_acme_server &
certbot_test certonly --standalone -d test.example.com
と実行してまずはローカルで動くかどうかを試すのだが、run_acme_server のところで落ちる。うまく webserver が起き上がってくれない。
[venv3] root@host:/usr/local/src/certbot # run_acme_server
=> Starting pebble instance deployment...
ELF binary type "0" not known.
=> Tear down the test infrastructure...
=> Test infrastructure stopped and cleaned up.
Traceback (most recent call last):
  File "/usr/local/src/certbot/venv3/bin/run_acme_server", line 11, in 
    load_entry_point('certbot-ci', 'console_scripts', 'run_acme_server')()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 221, in main
    with acme_server as acme_xdist:
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 96, in __enter__
    self.start()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 62, in start
    raise e
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 57, in start
    self._prepare_pebble_server()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 135, in _prepare_pebble_server
    self._launch_process(
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 205, in _launch_process
    process = subprocess.Popen(command, stdout=stdout, stderr=subprocess.STDOUT, cwd=cwd, env=env)
  File "/usr/local/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/lib/python3.8/subprocess.py", line 1702, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
OSError: [Errno 8] Exec format error: '/usr/local/src/certbot/certbot-ci/certbot_integration_tests/assets/pebble_v2.3.0_linux-amd64'
なんか、certbot が linuxの実行ファイル(linux binary for amd64)を抱えていてこれが freebsdでは動かない、ということのようだ。linux-compat とか入れればいいのかもしれないがそこまでやるかな。。。ということでこの線はあきらめて、、、 certbot は普通に python(2or3)のコードだったことを思い出して、$src/certbot/の中を見ると、setup.pyがあるので、
python3 setup.py build
python3 setup.py install
で、/usr/local/bin/certbot にインストールされた。
certbot certonly --standalone -d test.example.com
でちゃんと証明書が降りてきた。

sendmail-8.15.2 .on FreeBSD-9

重力波関連の速報が知りたくて、GCN Circularsのメールを受信しているけど、NASAの シスアドからメールが。

Subject: TLSv1.1-related mail bounces with NASA/GSFC

Hello,

I am a system administrator with the Astrophysics Science Division at NASA/Goddard Space Flight Center.

Due to a directive from the US Department of Homeland Security, I have made a change today to our mail server "capella2.gsfc.nasa.gov" (the mail server for the Gamma-ray Coordinates Network, https://gcn.gsfc.nasa.gov/ ) such that it now blocks TLSv1 and TLSv1.1.

Our logs show entries of the form:
May 10 xx:xx:xx capella2 sendmail[yyyyy]: STARTTLS=client: 11833:error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol:s23_clnt.c:714:
May 10 xx:xx:xx capella2 sendmail[yyyyy]: ruleset=tls_server, arg1=SOFTWARE, relay=, reject=403 4.7.0 TLS handshake failed.

I am not sure what changes might be needed on your side, but I at least wanted to alert you (because otherwise you or your users might have a "why is this suddenly failing" feeling!). I hope this is helpful.

Regards,

David

P.S. In terms of changes needed, you might need to upgrade your mail server software (sendmail, postfix, Exim, etc) to one that can "speak" TLSv1.2 or newer. Your site doesn't need to require TLSv1.2 as a minimum, as we have had to do, but it needs to be an option. Alternatively, you can let us know of a different mail address on your end to use.

と。sendmail のやりとりで TLS1.2じゃないから上げてね、というリクエスト。システムの自動応答かと思ったらどうもそうでもないような。

"US Department of Homeland Security"ってなんだ?と思ったら国土安全保障省 ?ひぇひぇ。こういうところが勧告するですね、アメリカは。
DNSのMXは primary 10,secondary 20にしていたので、通常は primary のメールサーバに来ていたが、このNASAのメールが急に secondary にメールが届くようになったので何事だろうと思っていたらこういうことだったのか。 実はprimary は TLS1.0,1.1は喋るが TLS1.2は対応していないlibssl.soをリンクしてるsendmail で動いていた。secondary はちゃんと TLS1.2を喋る libssl.soだったのでこちらに流れてきていたもののようだ。 openssl はちゃんと入れていたつもりが、sendmail はOS附属の古い libssl.so をリンクしていた。 ということで、古いOSに最新のsendmail + TLS1.2対応の ものを再インストールする必要が。 postfix,eximとかに変えることも一瞬考えるけど、milter系のものやMLソフトの整備を考えると手が出ない。 FreeBSDは、patchなどについては portsのファイルを見るとヒントになることが多いのでそれらを考慮して次のようにおこなった。
  1. まず既存の bin,configのバックアップ
  2. 必要なpatch をあてる。
  3. sendmail の configの作成
  4. compile
  5. install
と言うことで作業。
  1. まず既存のbin,configのバックアップ
  2. sendmail だけではなくて、いくつかのバイナリ・設定ファイルが作られるので、それを調べて見る。 sendmail-8.15.2.tar.gz を展開して srcのトップディレクトリで 'sh ./Build' を実行すると、 "$src/obj.`uname`.`uname -r`.`uname -p'にバイナリ別のディレクトリができる。 具体的には、
    obj.FreeBSD.9.3-RELEASE-p49.amd64
    の下に、
    editmap libsmdb mail.local makemap rmap smrsh
    libsm lbismuitl mailstats praliases sendmail vacation
    が出来た(12ディレクトリ)。
    これらが後にインストールされると思われるので、おのおのバックアップ。

    /usr/local/bin/rmail
    /usr/local/bin/mailstats
    /usr/local/bin/vacation

    /usr/local/sbin/editmap
    /usr/local/sbin/makemap
    /usr/local/sbin/praliases
    /usr/local/sbin/sendmail

    /usr/lcoal/libexec/smrsh
    /usr/local/libexec/mail.local

    libが3つ(libsmdb,libsm,libsmutil)あるがこれらはコンパイル時にstaticにリンクされるようなのでとりあえずこのまま放っておいて良いみたい。
    src/libmilter があるがこれはBuildしても自動では作成されない。sendmail/milter.c があり、sendmailをコンパイルするとkには milter.o がリンクされているのでたぶんこれは sendmailを作成時には不要のよう。3rdパーティのプログラムを使う(かもしれない)ときに libmilter.a,libmilter.so とかでリンクするためにあるようだ。(see $src/libmilter/README)
    これは明示的に 'cd libmilter; sh ./Build; sh ./Build install' で良さそう。

    config系は

    /etc/mail/
    /usr/local/share/sendmail/
    /etc/rc.sendmail

    あたりをバックアップ。
  3. patchをあてる。
  4. ports の mail/sendmail/files/ 以下に patch-xxx がある。これらを当てればいいはず、、だが、ports用のマクロ設定(%%CC%%とかに置き換え等)がありちょっとためらう。特にこのパッチを当てなくても warningが少しでるがcompileはうまくいっているようなので、今回は当てなかった。
  5. configの作成
  6. $src/INSTALL にあるように、 $src/devtools/Site/site.config.m4 を作成する。 site.config.m4.sample があるが、これはほぼ当てにならない。portsの mail/sendmail/files/ の中に site.config.m4の機能別のファイルがあるのでこれらをconcatinate して作るのが正しいかと。このディレクトリにある、site.config.m4に、ipv6,tls,sasl2,milter を今回は追加した。
    dnl
    dnl 0) use site.config.m4
    dnl
    define(`confEBINDIR',`/usr/local/libexec')
    define(`confMANROOT',`/usr/local/man/cat')
    define(`confMANROOTMAN',`/usr/local/man/man')
    define(`confMBINDIR',`/usr/local/sbin')
    define(`confSBINDIR',`/usr/local/sbin')
    define(`confUBINDIR',`/usr/local/bin')
    define(`confNO_STATISTICS_INSTALL',`True')
    define(`confHFDIR', `/usr/local/share/sendmail')
    APPENDDEF(`conf_sendmail_ENVDEF', `-DTCPWRAPPERS')
    APPENDDEF(`conf_sendmail_LIBS', `-lwrap')"
    dnl
    dnl
    dnl 1) use site.config.m4.ipv6
    dnl
    APPENDDEF(`conf_sendmail_ENVDEF', `-DNETINET6')
    APPENDDEF(`conf_libmilter_ENVDEF', `-DNETINET6')
    APPENDDEF(`conf_libsm_ENVDEF', `-DNETINET6')
    dnl
    dnl 2) use site.config.m4.tls
    dnl
    APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS -D_FFR_TLS_EC')
    APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto')
    dnl
    dnl 3) use site.config.m4.sasl2
    dnl
    dnl APPENDDEF(`conf_sendmail_ENVDEF', `-I%%LOCALBASE%%/include')
    dnl APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
    dnl APPENDDEF(`confLIBDIRS', `-L%%LOCALBASE%%/lib')
    dnl APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
    APPENDDEF(`conf_sendmail_ENVDEF', `-I/usr/local/include')
    APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
    APPENDDEF(`confLIBDIRS', `-L/usr/local/lib')
    APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
    dnl
    dnl 4) use site.config.m4.milter
    dnl
    APPENDDEF(`conf_libmilter_ENVDEF', `-DMILTER')
    APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')
    dnl
    
  7. compile
  8. $src にて、'sh ./Build'
  9. install
  10. $srcにて、'sh ./Build install'
元々 8.15.2 用で使っていた sendmail.cf はそのまま使えた。 これで TLS1.2も話す sendmail になったか。

ps.1
某日、STARTTLSを使ってちゃんとTLSで接続してくるメールを見てみたらいろいろあったので メモ。
クライアント証明書つきのTLS通信(但し認証(verify)はもちろんしていない)
  • NASA
  • Google (Gmailの転送)
  • SwarovskiのML
  • T-PointのML
  • オレオレCA証明書で発行したクライアント証明書を使っているMTA
ただの TLS通信。転送路は TLSのようだが特に認証無し。
  • shopify の広告DM
  • SBIのDairy mail
  • Land's Endの広告DM
  • 東洋経済のML
  • トクバイのML
  • キタムラのML
  • ホンダのML
  • DMMからのメール
  • JustsystemからのML
  • AmazonからのDM
  • GU(ユニクロ)からのML
  • みずほ銀行からのDM
  • OpenHouseからのDM
  • GMOからのML
  • EXPANSYSからのML
  • MoneyforwardからのML
  • JTBからのML
  • Generate DesginからのML
  • Wealthnavi からのML
  • QNAP からのML
  • Nature RemoからのML
  • furusat taxからのML
  • IPCamのメール通知クライアント(sasl認証)
単に forged なだけか、おかしな通信
  • security.criminalip.com
  • ninja.census.shodan.io
  • わざわざ SSL3.0,TLS1.0,TLS1.1,TLS1.2と繋がるか調べにやってきてる。
  • bezeqint.net
今後は sendmailもクライアント接続してくる側も証明書呈示するようになっていくんですかね。 とりあえず、うちも STARTTLSで接続したときに let's encryptあたりの証明書を呈示するようにしておいてみるか?

ps.2
TLS1.2対応になったことを、NASAのシスアドに連絡してみたところ、返答が。

I am glad to hear it is working for you once again!

Yes, I can see the moment in our logs when it got fixed:

Here is the last line of failure and the first line of success:

May 11 xx:xx:xx capella2 sendmail[15971]: ruleset=tls_server, arg1=SOFTWARE, relay=aaa.bbb.ccc, reject=403 4.7.0 TLS handshake failed.

May 11 yy:yy:yy capella2 sendmail[15971]: STARTTLS=client, relay=aaa.bbb.ccc., version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128

Thanks,

David


わざわざ丁寧にありがとう。

sendmail-8.15.2 .on FreeBSD-9

重力波関連の速報が知りたくて、GCN Circularsのメールを受信しているけど、NASAの シスアドからメールが。

Subject: TLSv1.1-related mail bounces with NASA/GSFC

Hello,

I am a system administrator with the Astrophysics Science Division at NASA/Goddard Space Flight Center.

Due to a directive from the US Department of Homeland Security, I have made a change today to our mail server "capella2.gsfc.nasa.gov" (the mail server for the Gamma-ray Coordinates Network, https://gcn.gsfc.nasa.gov/ ) such that it now blocks TLSv1 and TLSv1.1.

Our logs show entries of the form:
May 10 xx:xx:xx capella2 sendmail[yyyyy]: STARTTLS=client: 11833:error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol:s23_clnt.c:714:
May 10 xx:xx:xx capella2 sendmail[yyyyy]: ruleset=tls_server, arg1=SOFTWARE, relay=, reject=403 4.7.0 TLS handshake failed.

I am not sure what changes might be needed on your side, but I at least wanted to alert you (because otherwise you or your users might have a "why is this suddenly failing" feeling!). I hope this is helpful.

Regards,

David

P.S. In terms of changes needed, you might need to upgrade your mail server software (sendmail, postfix, Exim, etc) to one that can "speak" TLSv1.2 or newer. Your site doesn't need to require TLSv1.2 as a minimum, as we have had to do, but it needs to be an option. Alternatively, you can let us know of a different mail address on your end to use.

と。sendmail のやりとりで TLS1.2じゃないから上げてね、というリクエスト。システムの自動応答かと思ったらどうもそうでもないような。

"US Department of Homeland Security"ってなんだ?と思ったら国土安全保障省 ?ひぇひぇ。こういうところが勧告するですね、アメリカは。
DNSのMXは primary 10,secondary 20にしていたので、通常は primary のメールサーバに来ていたが、このNASAのメールが急に secondary にメールが届くようになったので何事だろうと思っていたらこういうことだったのか。 実はprimary は TLS1.0,1.1は喋るが TLS1.2は対応していないlibssl.soをリンクしてるsendmail で動いていた。secondary はちゃんと TLS1.2を喋る libssl.soだったのでこちらに流れてきていたもののようだ。 openssl はちゃんと入れていたつもりが、sendmail はOS附属の古い libssl.so をリンクしていた。 ということで、古いOSに最新のsendmail + TLS1.2対応の ものを再インストールする必要が。 postfix,eximとかに変えることも一瞬考えるけど、milter系のものやMLソフトの整備を考えると手が出ない。 FreeBSDは、patchなどについては portsのファイルを見るとヒントになることが多いのでそれらを考慮して次のようにおこなった。
  1. まず既存の bin,configのバックアップ
  2. 必要なpatch をあてる。
  3. sendmail の configの作成
  4. compile
  5. install
と言うことで作業。
  1. まず既存のbin,configのバックアップ
  2. sendmail だけではなくて、いくつかのバイナリ・設定ファイルが作られるので、それを調べて見る。 sendmail-8.15.2.tar.gz を展開して srcのトップディレクトリで 'sh ./Build' を実行すると、 "$src/obj.`uname`.`uname -r`.`uname -p'にバイナリ別のディレクトリができる。 具体的には、
    obj.FreeBSD.9.3-RELEASE-p49.amd64
    の下に、
    editmap libsmdb mail.local makemap rmap smrsh
    libsm lbismuitl mailstats praliases sendmail vacation
    が出来た(12ディレクトリ)。
    これらが後にインストールされると思われるので、おのおのバックアップ。

    /usr/local/bin/rmail
    /usr/local/bin/mailstats
    /usr/local/bin/vacation

    /usr/local/sbin/editmap
    /usr/local/sbin/makemap
    /usr/local/sbin/praliases
    /usr/local/sbin/sendmail

    /usr/lcoal/libexec/smrsh
    /usr/local/libexec/mail.local

    libが3つ(libsmdb,libsm,libsmutil)あるがこれらはコンパイル時にstaticにリンクされるようなのでとりあえずこのまま放っておいて良いみたい。
    src/libmilter があるがこれはBuildしても自動では作成されない。sendmail/milter.c があり、sendmailをコンパイルするとkには milter.o がリンクされているのでたぶんこれは sendmailを作成時には不要のよう。3rdパーティのプログラムを使う(かもしれない)ときに libmilter.a,libmilter.so とかでリンクするためにあるようだ。(see $src/libmilter/README)
    これは明示的に 'cd libmilter; sh ./Build; sh ./Build install' で良さそう。

    config系は

    /etc/mail/
    /usr/local/share/sendmail/
    /etc/rc.sendmail

    あたりをバックアップ。
  3. patchをあてる。
  4. ports の mail/sendmail/files/ 以下に patch-xxx がある。これらを当てればいいはず、、だが、ports用のマクロ設定(%%CC%%とかに置き換え等)がありちょっとためらう。特にこのパッチを当てなくても warningが少しでるがcompileはうまくいっているようなので、今回は当てなかった。
  5. configの作成
  6. $src/INSTALL にあるように、 $src/devtools/Site/site.config.m4 を作成する。 site.config.m4.sample があるが、これはほぼ当てにならない。portsの mail/sendmail/files/ の中に site.config.m4の機能別のファイルがあるのでこれらをconcatinate して作るのが正しいかと。このディレクトリにある、site.config.m4に、ipv6,tls,sasl2,milter を今回は追加した。
    dnl
    dnl 0) use site.config.m4
    dnl
    define(`confEBINDIR',`/usr/local/libexec')
    define(`confMANROOT',`/usr/local/man/cat')
    define(`confMANROOTMAN',`/usr/local/man/man')
    define(`confMBINDIR',`/usr/local/sbin')
    define(`confSBINDIR',`/usr/local/sbin')
    define(`confUBINDIR',`/usr/local/bin')
    define(`confNO_STATISTICS_INSTALL',`True')
    define(`confHFDIR', `/usr/local/share/sendmail')
    APPENDDEF(`conf_sendmail_ENVDEF', `-DTCPWRAPPERS')
    APPENDDEF(`conf_sendmail_LIBS', `-lwrap')"
    dnl
    dnl
    dnl 1) use site.config.m4.ipv6
    dnl
    APPENDDEF(`conf_sendmail_ENVDEF', `-DNETINET6')
    APPENDDEF(`conf_libmilter_ENVDEF', `-DNETINET6')
    APPENDDEF(`conf_libsm_ENVDEF', `-DNETINET6')
    dnl
    dnl 2) use site.config.m4.tls
    dnl
    APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS -D_FFR_TLS_EC')
    APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto')
    dnl
    dnl 3) use site.config.m4.sasl2
    dnl
    dnl APPENDDEF(`conf_sendmail_ENVDEF', `-I%%LOCALBASE%%/include')
    dnl APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
    dnl APPENDDEF(`confLIBDIRS', `-L%%LOCALBASE%%/lib')
    dnl APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
    APPENDDEF(`conf_sendmail_ENVDEF', `-I/usr/local/include')
    APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
    APPENDDEF(`confLIBDIRS', `-L/usr/local/lib')
    APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
    dnl
    dnl 4) use site.config.m4.milter
    dnl
    APPENDDEF(`conf_libmilter_ENVDEF', `-DMILTER')
    APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')
    dnl
    
  7. compile
  8. $src にて、'sh ./Build'
  9. install
  10. $srcにて、'sh ./Build install'
元々 8.15.2 用で使っていた sendmail.cf はそのまま使えた。 これで TLS1.2も話す sendmail になったか。

ps.1
某日、STARTTLSを使ってちゃんとTLSで接続してくるメールを見てみたらいろいろあったので メモ。
クライアント証明書つきのTLS通信(但し認証(verify)はもちろんしていない)
  • NASA
  • Google (Gmailの転送)
  • SwarovskiのML
  • T-PointのML
  • オレオレCA証明書で発行したクライアント証明書を使っているMTA
ただの TLS通信。転送路は TLSのようだが特に認証無し。
  • shopify の広告DM
  • SBIのDairy mail
  • Land's Endの広告DM
  • 東洋経済のML
  • トクバイのML
  • キタムラのML
  • ホンダのML
  • DMMからのメール
  • JustsystemからのML
  • AmazonからのDM
  • GU(ユニクロ)からのML
  • みずほ銀行からのDM
  • OpenHouseからのDM
  • GMOからのML
  • EXPANSYSからのML
  • MoneyforwardからのML
  • JTBからのML
  • Generate DesginからのML
  • Wealthnavi からのML
  • QNAP からのML
  • Nature RemoからのML
  • furusat taxからのML
  • IPCamのメール通知クライアント(sasl認証)
単に forged なだけか、おかしな通信
  • security.criminalip.com
  • ninja.census.shodan.io
  • わざわざ SSL3.0,TLS1.0,TLS1.1,TLS1.2と繋がるか調べにやってきてる。
  • bezeqint.net
今後は sendmailもクライアント接続してくる側も証明書呈示するようになっていくんですかね。 とりあえず、うちも STARTTLSで接続したときに let's encryptあたりの証明書を呈示するようにしておいてみるか?

ps.2
TLS1.2対応になったことを、NASAのシスアドに連絡してみたところ、返答が。

I am glad to hear it is working for you once again!

Yes, I can see the moment in our logs when it got fixed:

Here is the last line of failure and the first line of success:

May 11 xx:xx:xx capella2 sendmail[15971]: ruleset=tls_server, arg1=SOFTWARE, relay=aaa.bbb.ccc, reject=403 4.7.0 TLS handshake failed.

May 11 yy:yy:yy capella2 sendmail[15971]: STARTTLS=client, relay=aaa.bbb.ccc., version=TLSv1.2, verify=FAIL, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128

Thanks,

David


わざわざ丁寧にありがとう。

spf導入メモ(4) milter-manager

最後に、milterを束ねてくれる milter-manager のインストール。FreeBSDだと gmake でインストールしないとうまく入らないかも。 enma については milter-manager の detector.rb が見つけてくれないので、/usr/local/etc/milter-manager/milter-manager.local.confを作成する。
define_milter("milter-enma") do |milter|
  milter.connection_spec = "inet:10025@127.0.0.1"
  milter.description = "yenma milter"
  milter.enabled = true
  milter.fallback_status = "accept"
  milter.evaluation_mode = false
  milter.applicable_conditions = ["Remote Network", "Unauthenticated"]
  #milter.command = "/usr/local/etc/rc.d/milter-enma"
  milter.command = "/usr/local/etc/rc.d/yenma"
  milter.command_options = "start"
  milter.user_name = nil
  milter.connection_timeout = 300.0
  milter.writing_timeout = 10.0
  milter.reading_timeout = 10.0
  milter.end_of_message_timeout = 300.0
end
milter.applicable_conditions に "Unauthenticated" をつけているので、smtp-auth, SSL/TLS認証で投げ込んでこない、spammer MTA clientについては spfチェックを行う。 認証して投げ込んでくるクライアントは spf通らないのでありがたい。

spf導入メモ(4) milter-manager

最後に、milterを束ねてくれる milter-manager のインストール。FreeBSDだと gmake でインストールしないとうまく入らないかも。 enma については milter-manager の detector.rb が見つけてくれないので、/usr/local/etc/milter-manager/milter-manager.local.confを作成する。
define_milter("milter-enma") do |milter|
  milter.connection_spec = "inet:10025@127.0.0.1"
  milter.description = "yenma milter"
  milter.enabled = true
  milter.fallback_status = "accept"
  milter.evaluation_mode = false
  milter.applicable_conditions = ["Remote Network", "Unauthenticated"]
  #milter.command = "/usr/local/etc/rc.d/milter-enma"
  milter.command = "/usr/local/etc/rc.d/yenma"
  milter.command_options = "start"
  milter.user_name = nil
  milter.connection_timeout = 300.0
  milter.writing_timeout = 10.0
  milter.reading_timeout = 10.0
  milter.end_of_message_timeout = 300.0
end
milter.applicable_conditions に "Unauthenticated" をつけているので、smtp-auth, SSL/TLS認証で投げ込んでこない、spammer MTA clientについては spfチェックを行う。 認証して投げ込んでくるクライアントは spf通らないのでありがたい。

spf導入メモ(3) enma(yenma)

いろいろ調べてみて、使う spfは国産の enma(yenma)が一番良さそう?と思われる。 milter-manager で利用可能な milter一覧はhttps://milter-manager.osdn.jp/reference/ja/available-milters.htmlにあり、spfだけなら spfmilterがあり、libspf or libspf2などのインストールも比較的簡単そうだけど、enmaは国産(IIJ)でもあり、すでに枯れているようだし、securemx.jp でも黙って使っていて(Mail Header を見るとわかる)、open source の最新版(https://github.com/iij/yenma/releases)の v2.0.0-rc1で良さそうな気がする。 ldns は
./configure --libdir=/usr/local/lib --disable-dane-verify
gmake
gmake install
でインストール。 FreeBSDで gcc,gmake で作ったが、起動時にどうもエラーが。user: mailnull を confに指定するとうまく起動しない。'sysconf failed' のエラーが。 調べていくと、common/daemon_stuff.c の中で
long buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
がおかしいらしい。ChangeLogを見ると、
2008-08-26
   * fix sysconf(_SC_GETPW_R_SIZE_MAX) problem on FreeBSD
とあるが、これがまた 最近の FreeBSDでは enbugしてしまったのだろうか? とりあえず、
# diff common/daemon_stuff.c common/daemon_stuff.c.org
217,218c217
<     //    long buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
<     long buflen = 16384;
---
>     long buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
と、適当な値を設定してcompileし直したところ、どうもうまく通過。 起動scriptは、/usr/ports/mail/enma/files/milter-enma.in を適当に書き換えて/usr/local/etc/rc.d/ 以下に設置、あとは /etc/rc.confに enma の記述を追加。 とりあえず spfだけチェック。dkim,sender id,dmarcは false でチェックしないようにしてみた。

spf導入メモ(3) enma(yenma)

いろいろ調べてみて、使う spfは国産の enma(yenma)が一番良さそう?と思われる。 milter-manager で利用可能な milter一覧はhttps://milter-manager.osdn.jp/reference/ja/available-milters.htmlにあり、spfだけなら spfmilterがあり、libspf or libspf2などのインストールも比較的簡単そうだけど、enmaは国産(IIJ)でもあり、すでに枯れているようだし、securemx.jp でも黙って使っていて(Mail Header を見るとわかる)、open source の最新版(https://github.com/iij/yenma/releases)の v2.0.0-rc1で良さそうな気がする。 ldns は
./configure --libdir=/usr/local/lib --disable-dane-verify
gmake
gmake install
でインストール。 FreeBSDで gcc,gmake で作ったが、起動時にどうもエラーが。user: mailnull を confに指定するとうまく起動しない。'sysconf failed' のエラーが。 調べていくと、common/daemon_stuff.c の中で
long buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
がおかしいらしい。ChangeLogを見ると、
2008-08-26
   * fix sysconf(_SC_GETPW_R_SIZE_MAX) problem on FreeBSD
とあるが、これがまた 最近の FreeBSDでは enbugしてしまったのだろうか? とりあえず、
# diff common/daemon_stuff.c common/daemon_stuff.c.org
217,218c217
<     //    long buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
<     long buflen = 16384;
---
>     long buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
と、適当な値を設定してcompileし直したところ、どうもうまく通過。 起動scriptは、/usr/ports/mail/enma/files/milter-enma.in を適当に書き換えて/usr/local/etc/rc.d/ 以下に設置、あとは /etc/rc.confに enma の記述を追加。 とりあえず spfだけチェック。dkim,sender id,dmarcは false でチェックしないようにしてみた。

node.js のinstall で stop (uv_fs_lchown)

FreeBSDで node.js を portsでインストールしようとしたら、エラーで進まず。 'uv_fs_lchown'がうんたら、というエラー。ぐぐると、このページがトップに。 libuv がダメダメらしいということで、/usr/ports/devel/libuv/ を入れ直す。その後 /usr/ports/www/node/ はあっさりインストール終了。

node.js のinstall で stop (uv_fs_lchown)

FreeBSDで node.js を portsでインストールしようとしたら、エラーで進まず。 'uv_fs_lchown'がうんたら、というエラー。ぐぐると、このページがトップに。 libuv がダメダメらしいということで、/usr/ports/devel/libuv/ を入れ直す。その後 /usr/ports/www/node/ はあっさりインストール終了。