apache SSLオフロード rewrite

ServerName https://example.com

ServerName accepts a scheme as well, e.g. ServerName https://example.com. Changing this in the configuration and restarting Apache did the trick.
From the documentation:
Sometimes, the server runs behind a device that processes SSL, such as a reverse proxy, load balancer or SSL offload appliance. When this is the case, specify the https:// scheme and the port number to which the clients connect in the ServerName directive to make sure that the server generates the correct self-referential URLs.

https://serverfault.com/questions/746875/how-to-make-apache-s-mod-rewrite-redirect-over-https-by-default

SSL を処理するデバイス、例えばリバースプロクシやロードバランサや SSL 処理軽減アプライアンスの裏側でサーバが稼動する場合もあるでしょう。 そういった場合では、クライアントが接続するときに使う https:// スキームとポート番号を ServerName ディレクティブで指定して、自己参照 URL が正しく生成できるようにします。

https://httpd.apache.org/docs/2.4/mod/core.html#servername

fml DKIM DMARC

原因1. MLに投稿すると, さくらレンタルサーバーから投稿者のメールアドレスを
「騙って」メンバーに配布されるので, そもそもメーリングリストの手法は
なりすましである.

原因2. 投稿者の DKIM のシグナチャーがあるとそれが引き継がれるので
さくらレンタルサーバDNS 設定に基づく DKIM シグナチャーと
齟齬をきたし, メールが改ざんされたとみなされてしまう.

解決
原因1に対しては, 送信者をMLのメールアドレスにすることで解決.
原因2に対しては, 投稿者のDKIMシグナチャーを削除することで解決.
要するに, MLのメールアドレスがオリジナルの送信者であるかのように
振る舞わせるのである.

さくらレンタルサーバのメーリングリストを DKIM/DMARC に対応させる

DMARC アライメント

DMARC Alignmentチェックは、SPFDKIM、どちらかが合格していればOKです。
これは、SPFの場合、転送メールの場合は、SPFが不合格になります。
そこで片側だけが合格すればOKとなれば、転送メールであっても、メールの内容を変更してない場合はDKIMが合格し、Alignmentも一致するというわけです。

転送メールについては、DMARC Alignmentチェックが合格しない場合があるため、ARCという仕様で担保します。

SPFを基準にしたFromアドレス詐称検出では、私たちがメールを読む際に目にするFromアドレス「Header From」と、メールヘッダ内のReturn-Pathを照合します。

DKIMを基準にしたFromアドレス詐称検出では、私たちがメールを読む際に目にするFromアドレス「Header From」と、メールヘッダ内のDKIMの鍵のd=タグに記載されている鍵の所有者のドメイン名を照合します。
DMARC | MailData

Apache UserAgentで制限

# Apache2.4系の場合
SetEnvIf User-Agent "Bytespider" bothersome_bot
BrowserMatchNoCase "Bytespider" bothersome_bot
<RequireAll>
Require All Granted
Require not env bothersome_bot
</RequireAll>

https://www.advantech.jp/archives/3619

bothersome_bot

<IfModule mod_setenvif.c>
    SetEnvIf User-Agent "Bytespider" block-bot
</IfModule>

<IfModule mod_authz_core.c>
    <RequireAll>
        Require all granted
        Require not env block-bot
    </RequireAll>
</IfModule>

block-bot

https://zbnr-hp.com/denybot/
denybot

TCP Timestamp Option ICMP Timestamp

TCP Timestamp Option

これは、下記の変更によりコネクションごとにタイムスタンプがランダム化されるようになったためです。
コミット:
tcp: randomize tcp timestamp offsets for each connection 95a22ca
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95a22caee396cef0bb2ca8fafdd82966a49367bb

net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する #Linux - Qiita 2018

昔はOS起動時からの経過時間(uptime)がnmapでとれたようなんですが、今はとれなさそうです。
TCPのタイムスタンプを無効化する | クロジカ 2015

遠隔でuptimeを調べる 2011

ICMP Timestamp

ICMPタイムスタンプ要求/応答のDROPを確認する - blog 2019

usskimの日記 |ping で時刻を得る

ただしこのタイムスタンプ情報はIPヘッダ中に記録されるため(IPヘッダのサイズは最長でも60bytesに制限されている)、最大でも4つまでしか記録できないという制限がある。1エントリあたり、4bytesのIPアドレスと4bytesの時刻情報(GMTの当日0時0分からの経過ミリ秒数)が記録される。
pingのタイムスタンプ・オプションで進行状況を確認する − @IT 2010

sshd_config

Ciphers -chacha20-poly1305@openssh.com
MACs -*etm@openssh.com

SSHのセキュリティ弱体化攻撃「Terrapin」の対策公開、JPCERT/CC | TECH+(テックプラス) 2023

#       Ciphers
#              chacha20-poly1305@openssh.com,
#              aes128-ctr,aes192-ctr,aes256-ctr,
#              aes128-gcm@openssh.com,aes256-gcm@openssh.com
#
# CVE-2023-48795 Workaround
Ciphers -chacha20-poly1305@openssh.com

#       KexAlgorithms
#              sntrup761x25519-sha512@openssh.com,
#              curve25519-sha256,curve25519-sha256@libssh.org,
#              ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,
#              diffie-hellman-group-exchange-sha256,
#              diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,
#              diffie-hellman-group14-sha256
#
# Diffie-Hellman Ephemeral Key Exchange DoS Vulnerability (SSH, D(HE)ater)
#  disable diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521

#       MACs
#              umac-64-etm@openssh.com,umac-128-etm@openssh.com,
#              hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,
#              hmac-sha1-etm@openssh.com,
#              umac-64@openssh.com,umac-128@openssh.com,
#              hmac-sha2-256,hmac-sha2-512,hmac-sha1
#
# Weak MAC Algorithm(s) Supported (SSH)
#  disable umac-64-etm@openssh.com,umac-64@openssh.com
# CVE-2023-48795 Workaround
#  MACs -*etm@openssh.com
MACs umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

msmtp: cannot log to /var/log/msmtp.log: cannot open: Permission denied

Ubuntu 22.04

I had the same error message, and ultimately changing permissions, creating the log file, etc., didn't work. The problem in my case was caused by AppArmor: in my system, the file /etc/apparmor.d/usr.bin.msmtp only listed /var/log/msmtp as write permission in /var/log, so solution can be:

to use /var/log/msmtp as log in the configuration, instead of /var/log/msmtp.log

https://askubuntu.com/questions/878288/msmtp-cannot-write-to-var-log-msmtp-msmtp-log

/var/log/msmtp.log を /var/log/msmtp に変更する