external storage 1

FreeBSD clamav-milter sendmail

2025 FreeBSD 14.2 で確認

clamav-milter は clamav パッケージに同梱

pkg install clamav

clamav-1.4.2

デフォルト設定で X-Virus-Scanned, X-Virus-Status ヘッダ追加されなくなった

/usr/local/etc/clamav-milter.conf

# If this option is set to "Replace" (or "Yes"), an "X-Virus-Scanned" and an
# "X-Virus-Status" headers will be attached to each processed message, possibly
# replacing existing headers.
# If it is set to Add, the X-Virus headers are added possibly on top of the
# existing ones.
# Note that while "Replace" can potentially break DKIM signatures, "Add" may
# confuse procmail and similar filters.
# Default: no
#AddHeader Replace

LogVerbose デフォルト no

yesにしないと /var/log/maillogに Milter (clmilter) add: header: X-Virus-Scanned などはでない

# Enable verbose logging.
#
# Default: no
#LogVerbose yesLogVerbose yes

参考

FreeBSD 12 で自宅サーバ作成 メールサーバ編その2 #clamav - Qiita 2022 FreeBSD 12

ランサムウェア対策

3-2-1-1-0バックアップ・ルールは、5つの条件を満たすことを要求していることです。

  • 本番用コピーを含め、少なくとも3つのデータコピーを用意すること。
  • テープとクラウドストレージのように、少なくとも2つの異なるストレージメディアを使用すること。
  • 少なくとも1つは、マシンが物理的に破損した場合に備えて、オフサイトで保管すること。
  • 少なくとも1つのコピーはオフラインで保管するか、クラウドを使用する場合はイミュータブル（不変）であること（不変とは、このコピーがいかなる状況下でも変更されないことを意味します）。
  • バックアップはエラーゼロで完了すること。

3-2-1-1-0 バックアップ・ルールとは | 製品サポート FAQ & Tipsサイト

postgresql レプリケーション recovery_target_timeline

意図せずレプリケーションが停止した原因は、db002へのレプリケーション開始時に、PostgreSQLのタイムラインIDの変更に対して追従するためのrecovery_target_timelineという項目を設定し忘れていたことです。

PostgreSQLでは、マスター昇格した際にタイムラインIDがインクリメントされます。レプリケーションのためにスレーブへ転送するWALにはタイムラインIDが含まれており、PostgreSQL 9.3のデフォルト設定では、マスターのタイムラインIDがインクリメントされても、スレーブが新しいタイムラインIDをもつWALを受け付けずにレプリケーションが停止する仕様になっています。 ただし、recovery.confファイルに、recovery_target_timeline = 'latest'を設定した状態でレプリケーションしている場合、スレーブは新しいタイムラインIDを受け付け、引き続きレプリケーションを継続します。

recovery_target_timeline = 'latest'の設定は、今回の移行のように孫スレーブが必要になるケースにて有用です。しかし、Mackerelにおける通常運用状態では、この設定は不要であったため、必要なときのみ自前のレプリカ作成スクリプトのオプションにて設定する運用でした。その結果、必要にもかかわらずオプション設定を忘れてしまうというヒューマンエラーが発生しました。
システム移行メンテナンスにおける一部時間帯に更新されたデータが消失した原因のご報告 - Mackerel ブログ #mackerelio 2017

Cloudflare ASN block

IP アドレス、ASN、国でブロックできる

WordPress Security: Block or Challenge ASNs with CloudFlare

https://radar.cloudflare.com/traffic/as45102

カスタムルールかIP アクセス ルールで設定

WAF
カスタムルール
ツール > IP アクセス ルール

Blocking ASN in Firewall Rules or IP Access Rules - Security - Cloudflare Community 2023

自律システムとは？| ASNとは？ | Cloudflare

varnish TTL beresp.ttl

Keep in mind that the Cache-Control header’s max-age and s-maxage directives are used to determine the TTL and that the cache is already bypassed when either of these directives would result in a zero TTL

https://www.varnish-software.com/developers/tutorials/varnish-builtin-vcl/

varnish default_ttl

120s

# varnishadm param.show default_ttl
default_ttl
        Value is: 120.000 [seconds] (default)
        Minimum is: 0.000

        The TTL assigned to objects if neither the backend nor the VCL
        code assigns one.

        NB: This parameter is evaluated only when objects are created.
        To change it for all objects, restart or ban everything.

Varnish Default TTL - GetPageSpeed 2020

Fastly

TTLの設定に関連するヘッダーは何種類かあるのですが、FastlyサーバーでのTTLに関連するヘッダーはCache-Control, Expires, Set-Cookie, Surrogate-Controlヘッダーです。

これらのヘッダーの内容を参照し、以下のような優先順位で適用されるTTLを決定します。

  1. Set-CookieまたはCache-Control に private を含む場合 → キャッシュしない
  2. Surrogate-Control: max-age=ヘッダーに指定したTTL
  3. Cache-Control: s-maxage=ヘッダーに指定したTTL
  4. Cache-Control: max-age=ヘッダーに指定したTTL
  5. Expires:ヘッダーに指定したTTL
  6. Fastly設定上で指定されたFallback TTL(Default TTL)

FastlyサーバーのTTLの選択ロジック #CDN - Qiita 2023

  if (beresp.http.Expires || beresp.http.Surrogate-Control ~ "max-age" || beresp.http.Cache-Control ~"(s-maxage|max-age)") {
    # keep the ttl here
  } else {
        # apply the default ttl
    set beresp.ttl = 3600s;
  }

[fastly default vcl, no custom vcl] #fastly #varnish #vcl · GitHub

varnishlog vsl

Hit, HitMiss, HitPass
今まではVXIDのみでしたが、追加で残TTLを出力するようになりました。(Hitについてはgrace/keepTTLも出力)

Varnish5.2.0がリリースされました – cat /dev/random > /dev/null &

Hit - Hit object in cache
Object looked up in cache.

The format is:

%u %f %f %f [%u [%u]]
|  |  |  |   |   |
|  |  |  |   |   +- Content length
|  |  |  |   +----- Fetched so far
|  |  |  +--------- Keep period
|  |  +------------ Grace period
|  +--------------- Remaining TTL
+------------------ VXID of the object

https://varnish-cache.org/docs/trunk/reference/vsl.html

Remaining TTL

git メモリ制限 

$ vi ~/.gitconfig
...
[core]
        packedGitWindowSize = 128m
        packedGitLimit = 128m
[pack]
        windowMemory = 128m
        threads = 2
        deltaCacheSize = 128m
        packSizeLimit = 128m

※m1.smallくらいでこの設定にしました。t1.microだとメモリエラー出ました。

メモリエラーメッセージ：

fatal: Out of memory, malloc failed9.59 MiB | 4.16 MiB/s
error: pack-objects died with strange error

つくったchefリポジトリを会社のgithubにpushするまで #Git - Qiita 2015

t1.micro 615MiB
m1.small 1.7GiB

https://git-scm.com/docs/git-config

GUARDIANWALL MailSuite 運用

サービスの停止、起動

https://security-support.canon-its.jp/faq/show/1763?site_domain=GUARDIANWALL

・ADM サーバーにて実施
# service grdn-adm stop
# service grdn-adm start
 
・DFS メタサーバーにて実施
# service grdn-dfs-meta stop
# service grdn-dfs-meta start
 
・WGW メタサーバーにて実施
# service grdn-wgw-meta stop
# service grdn-wgw-meta start
 
・MGW メタサーバーにて実施
# service grdn-mgw-meta stop
# service grdn-mgw-meta start
 
・DFS ワーカーにて実施
# service grdn-dfs-work stop
# service grdn-dfs-work start
 
・WGW ワーカーにて実施
# service grdn-wgw-work stop
# service grdn-wgw-work start
 
・MGW ワーカーにて実施
# service grdn-mgw-work stop
# service grdn-mgw-work start

確認

service grdn-adm status
service grdn-dfs-meta status
service grdn-wgw-meta status
service grdn-mgw-meta status
service grdn-dfs-work status
service grdn-wgw-work status
service grdn-mgw-work status

？自動起動設定されるのは grdn-adm のみ？ 2.4.0

ログ

/var/lib/guardian/log/

◆ログファイルのパス、ログの出力内容

ADM / WGWメタサーバー / MGWメタサーバー / DFSメタサーバー
出力先ファイル
/var/lib/guardian/log/metadb/postgresql.log
出力内容
「YYYY-MM-DD hh:mm:ss GMT::@:LOG: autovacuum launcher started」
 
WGWワーカー
出力先ファイル
/var/lib/guardian/data/mgw/tenant/<テナントID>/log/log.YYYYMMDD
出力内容
 「YYYY/MM/DD hh:mm:ss mw_mss[<pid>]: daemon started <Version>」
 
MGWワーカー
出力先ファイル
/var/lib/guardian/log/wgw/httpd/error_log.YYYYMMDD
出力内容
「Day Month date hh:mm:ss YYYY」[notice] Apache/<version> (Unix) Phusion_Passenger/<version> configured -- resuming normal operations」
 
DFSワーカー
出力先ファイル
/var/lib/guardian/log/dfs/grdn-dfs-srch-worker_error_log
出力内容
「YYYY/MM/DD hh:mm:ss [srch_worker:info] start srch_worker <ポート番号><pid>」

https://security-support.canon-its.jp/faq/show/668?site_domain=GUARDIANWALL