Chap-6. セキュリティ関連の軽いトピックス

Sec-1．Spam メールの実態把握について(Postfix 前提) (2023-10)
Sec-1-1．コンピュータの名前
Sec-1-2．Postfix がやっていること、できること
Sec-1-3．今回やりたいこと
Sec-1-4．データを集めた結果について
Sec-2．dovecot の設定について
Sec-3．nftables を試してみて
Sec-4．最新カーネルとLTSカーネルについて (2023-05)

　このチャプタは、何度か書き直してます。最初はセキュリティ関連でパケットフィルタの設定など書いていました。
そのうち、都合があって Slackware 関連の話題にテーマを変えました。
またテーマを変えて「セキュリティ関連の軽いトピック」とします。あくまで、軽い話題だけ。
なので、あまり技術的な細部には踏み込みません。軽い読み物のつもりでご覧ください。
Sec-1. は 2023-10 書き直しです。
Sec-１．Spam メールの実態把握について(Postfix 前提) 　

2023-10
　このセクションを書く上での前提条件
・スパムかどうかの判定をせず善良なメールまで弾く設定は根本的に悪い設定
・その条件のもと、スパムへの命中率の高い設定が良い設定
この前提条件で以下書いていきます。
Sec-1-1.　コンピュータの名前　

　簡単に名前についてふれます。
例えばミドルタワー型のコンピュータが２台、ブック型のコンピュータが２台あったとします。
それぞれ、適当にマシン固有の名前をつけます。いわゆるマシンネーム。MID1、MID2、BOOK1、BOOK2 とか。マシンに固有の名前です。
手帳にメモを書きます。MID1 は CPU が hoge でマザーボードは hoge でメモリーは hogeーGB、電源はいつ交換した。（電源交換時期はけっこう重要）
同様に MID2、BOOK1、BOOK2 についてもメモをしておきます。簡単にやるならメモをコンピュータに貼り付けておく。こういうマシン固有の情報はハードウェアを管理する上で重要です。

　次にネットワーク上の名前。ネットワーク上のノードにつける名前。以下の感じ

　それぞれネットワークのノードごとに役割を決めます。pochi は LAN 内の主要マシン。開発とか色々、サーバソフトのお試しもやります。重要なデータはすべて pochi が持ちます。
tama はその予備。「これ、install して大丈夫かなあ・・・」なんてヤツはまず tama に入れてみて様子を見ます。調子良ければ pochi にも入れます。なので tama にはあまり重要なデータは持たせません。なかばお試し機だし。
mike、taro の役割は交互にサーバ運転することです。適当に、交互に休ませます。なので仕立て方・仕上げ方は２つとも同じ。
うちのネットワーク内ではこんな具合で、ノードごとに役割を決めています。普通は決めると思います。
　例えば MID1 を pochi に当てていたのが、たまたまマザーボードの交換とかあって一時的に tama にあった MID2 を pochi に持っていったりします。
MID2 の仕立て具合を一時的に pochi 用にします。
UNIX 系ネットワークの解説本だと「マシン固有の名前」と「ネットワークノードごとの名前」の使い分けが書いてあったりします。
　マシン固有の名前は、カーネルをコンパイルするならカーネルにつけることもあります。最近はカーネルコンパイルが一般的でなくなっていると思います。なので視覚的にあるいはマシンに貼り付けたメモで識別するだけです。
　ネットワークノード上の名前は /etc/hostname ファイルと /etc/hosts ファイルで識別しています。詳細は省略。
LAN 内用にネームサーバを立てていれば $ ssh user-a@pochi とか $ ssh user-b@tama とかしてログイン出来ます。sftp を使えば tar 玉にまとめたバックアップファイルを転送したり出来ます。
UNIX 系ネットワークでのごく普通の管理とか使い方です。注：もちろん全て固定 IP アドレスです。

　実は、よく使う名前がもう一種類あります。smtp サーバが使う名前です。
これは postfix なら /etc/postfix/main.cf の中で普通は管理していて、smtp サーバ同士の会話で使います。詳細説明省略。
これをワルは SPAM メールを投げるときに悪用します。
例えば ufj.co.jp とか amazon.co.jp とか、自分が管理してもないドメイン名にして（自分のサーバの名前を偽って）メールを投げます。
Sec-1-2.　Postfix がやっていること、できること　

　Sec-1-1.の最後に書いた「ワルがやること」に関連して名前とアドレスのことを整理します。

　以下で名前Ａは smtp サーバの名前(FQDN)、アドレスＡは smtp サーバの名前から正引した IP アドレスとします。
また名前Ｂはアクセスしてきた IP アドレスから逆引きした名前(FQDN)、アドレスＢはアクセスしてきた IP アドレスとします。
左側が名前で右側が IP アドレスです。

最初に把握できる情報
＊名前Ａ　ーーーーー　不明
＊不明　　ーーーーー　アドレスＢ

Postfix自身の努力によって以下のようになる
＊名前Ａ　ーーーーー　不明
＊名前Ｂ　ーーーーー　アドレスＢ

名前Ｂは Postfix がアドレスＢを使って逆引きで求める。

本来あるべき状態
＊名前Ａ　ーーーーー　アドレスＡ
＊不明　　ーーーーー　アドレスＢ

スパマーたちは名前を偽装してスパムメールを送っているので、名前Ｂは不要であって必要なのはアドレスＡです。

最後のような情報があれば、名前を（したがってアドレスも）偽装しているメールを正確に特定できます。二段目の情報だけでスパム対策をやると、偽装しているメールの特定は出来ません。
しかし残念なことに、exim4、postfix、sendmail という 2023 時点での代表的なメールサーバソフトはいずれもアドレスＡの情報を持っていないらしいです。出典URLは失念しました。
Sec-1-3.　今回やりたいこと　

　前から Postfix を多少改造してアドレスＡを求め、それを利用してスパムメールの傾向を把握したい、あるいは実態調査したいと思っていました。
もしもうまく行くようならスパム対策にも使いたい。
この夏にちょっとやる気をだしてトライしてなんとか出来ました。
以下は、やりたい、チャレンジしたいと思った事柄です。

＊TYPE-A はアドレスＡとアドレスＢが一致しないメール。すなわちメールサーバの名前や IP アドレスを偽装しているメール。極めて悪メールである可能性の高いグループ
＊TYPE-B はアドレスＡとアドレスＢは一致するが、名前Ａと名前Ｂが一致しないメール。内容がスパムかどうかは別として、アドレス偽装はやっていない。dDNS サイト等。
＊TYPE-C は名前Ａと名前Ｂが一致し、さらにアドレスＡとアドレスＢが一致するメール。普通のプロバイダなとのメール

　プログラミングをやってみたところ、表面的に見ると a. から f. まで全部出来ました、一応。ただし実態として c. d. はやると具合が悪いことがわかりました。
要するに中間ファイルの段階でいじるわけですが、c. d. をいじると Postfix の改ざん検知が作動して「これはメールとしては扱えない。ダメなヤツだ」という判定がなされてしまいます。多分、想像ですが md5 等の改ざん検知システムが組み込まれている。
で、内容を改変すると /var/spool/postfix/corrupt/ という壊れたメールを集める専用のディレクトリに移されてしまい、配送ルートからは外れます。メールとしては扱われなくなります。
一瞬、この改ざん検知をかいくぐってなんとか出来ないものか・・・と考えましたが、すぐに諦めました。
それをやろうとすると、相当詳細にソースコードを熟読し理解する必要があります。すごい作業量になって手におえません。
そんな技術も、やる気も、根気もありません。無理
今回 Postfix をいじるにあたっての方針はいつもどおり「なるべく簡単に済ませる。難しいことにはチャレンジしない」という方針です。なので c. d. は諦めました。
幸い、e. f. がうまく行くのでスパムメールの傾向把握や実態調査（場合によってはスパム対策も・・）は出来ます。
なお、e. f. をやると Postfix が warning を出します。「あれ、中間ファイルの段階で無くなっちまったぞ」って感じの警告です。
しかし警告を出すだけで Postfix はその後も変わりなく動き続けます。なのでオケです。

結果的に a. b. e. f. が出来たのでそれを利用して、まずメールの傾向調査（実態調査）をやりました。

　データ収集開始前の自分の予想では TYPE-A は全部ワル。TYPE-B にはごく一部しかワルはいない。TYPE-C も同様と考えました。

　なお作業にあたって以下のような前提条件です。

　なお、スパムかどうかの判定は一つ一つのメールを見て、それらしいかどうか感じで判断するしかありません。いちいち危なそうな URL をクリックするわけには行きません。なので感じでの判断です。
そもそもスパムって「なんとかしないと困ったことになりますよ」みたいな脅す文言だらけ。不安を煽り脅しを入れてきます。ものすごくわかりやすいです。個人宛に来るメールはスパムかどうかサブジェクトを見ただけですぐ判断出来ます、笑。
　ただし、TYPE-A のメールのスパム判定は最初の二日間でやめました。TYPE-A については来るヤツ来るヤツ全部スパムでした。バカバカしくなって２日でチェックをやめました。やってられません、笑。
これには後日談がありますが・・・・

TYPE-B、TYPE-C については最後までスパム判定を続けました。
Sec-1-4.　データを集めた結果について　

　まず集計データを示します。 

　　　TYPE-A のメール　　８８６通　　　うちスパムの比率　９９％
　　　TYPE-B のメール　　　７５通　　　うちスパムの比率　６４％
　　　TYPE-C のメール　　３４１通　　　うちスパムの比率　　０％
　　　　全メール数　　　１３０２通

＊＊＊データのうち TYPE-A について補足です＊＊＊

ーー　日本最大級の通販サイトからくる TYPE-A メールについて　ーー
　ここはプロ野球球団のオーナーであり、かつ神戸のＪ１サッカークラブの大スポンサー。例のスペインのスター選手を招請した社長さんのいる会社です。
ここの設定は、従来の名前を比較する設定でも弾き返されているはずなので、それを承知でやっていると思われます。
つまり確信犯的にやっている、笑。
　設定ファイルで smtp サーバ名を書くべきところに自社のドメイン名を書いていると思います。
なので正引きすると当然に実際アクセスしてきたsmtpサーバのアドレスと一致しない。ネット系の見方をすると？です。
しかし「あくまで商取引の連絡」という見方をすれば、正規のドメイン名を書いているし、内容はまともなメールだし、なんの問題もありません。
そもそも「正しく smtpサーバ名を書かなければならない」というのは商取引上ではそんな決まりは無いし・・・
なお、このメールの投げ方をしているのは第一報だけ。「ご注文うけたまわりました。後ほど関係商店から連絡が行きます」みたいな感じの第一報です。
で、個別の関係商店からくるメールは普通の TYPE-C で来ます。これ以後の連絡はごく普通のネットワーク系のやり方です、笑。

ーー　その通販サイトのことについて、私の想像です　ーー
　この社長さん、例の大スターを連れてきたのも自分で会いに行っていたようでした。日本の多くのファンが拍手喝さいしたと思います。
またデンベレやグリーズマンが日本への人種差別行為をしたと話題になったときも、バルサは早期にグリーズマンとの契約を破棄しました。スポンサー企業である社長さんの圧があっただろうなあ・・・・というのは容易に想像出来ます。差別云々の真偽はともかくとして、多くの日本のファンはこの会社の行動を想像して拍手しただろうと思います。
社長さん、ファンの心理を心得ている感じです。プロ野球ではゲーム中の監督に選手起用の電話をかけるとか・・・いろいろ噂もあるので無条件に手放しに称賛する気はありません。だだ人心をよく理解しているのは、さすが大企業を経営している人だと思います。
そういう一連の行動から想像すると、会社の体質として正しいと信じたら既存の価値観に反対してでも突っ走るような姿勢がありそうです。もちろん、私の想像ですが・・・
TYPE-A メールを確信的に投げてくることについて私の受けた印象とか感想は以上のとおりなので、コメントは控えます。

＊＊＊その他、全般的な感想・想像＊＊＊
＊TYPE-A のメール数の多さは驚異的です。危険は身近にあります。
＊TYPE-A の中に善良メールが一定数あることについて、チョンボをやってしまうサバ管さんが一定数（一定比率）いるということです。統計的に考えればあり得ることです。
＊TYPE-B の絶対数が思ったより少なかった。多分、メールサーバーのリレーを使って擬似的に TYPE-C になっている。それと dDNS での自宅サーバが流行ったあとでブログ等 SNS 系が大流行しています。情報発信が目的なら自宅サバに頼らなくても良くなった。なのでそっちに流れた人達も多くいるだろうと、想像しています。
＊TYPE-B 中でスパムを投げてくるサイトの割合が思ったより多かった。ほとんどのスパマーは TYPE-A で投げてきます。そのやり方すら理解していないスパマーが一定数いるということです。
よく映画のシーンでワルの兄貴分が出来の悪い弟分のことを「こいつはダメなやつだ。マトモなワルにすらなれない・・・」と嘆くシーンがあります。私は初めて「マトモなワルにすらなれない」という実例を見た気がします。
＊TYPE-C にはチェックした限り一通もスパムはありませんでした。想像以上にここはマトモだったので良かったと思います。

＊＊＊その他、踏み台について＊＊＊
　踏み台になっているサイトがあるかどうか、ログだけから判定するのは難しいです。が、ある程度の考察は出来ます。
ログを見るだけで言えることは以下のようなことです。
＊TYPE-C には多分無い、笑。当然ですね。
＊TYPE-B にも多分無い、踏み台にしておきながら正引きしたときのアドレスが一致するようなサーバ名は使わないと思います。なので TYPE-B からくるスパムはもろにそのサイトが投げているスパムでしょう。
＊TYPE-A のメールのうち名前Ｂが unknown になっているものについては踏まずに投げてる。一時的なアクセスをやって投げているわけなので踏み台利用では無いと思います。
＊TYPE-A のメールのうち名前ＢもアドレスＢもあるものの中には踏み台にされているものがあるかもしれない。もともとが TYPE-B であれ TYPE-C であれ、踏まれたら適当なサーバネームを名乗るでしょう。そうなると TYPE-A になります。ただし、本当に踏まれているかどうかの判断はログからは無理です。

自分でやっている独自ログの一部を以下に示します。
一つのメールあたり二行。一行目は日付。二行目は名前Ａ、アドレスＡがＢとマッチしたかの判定、アドレスＢ、名前Ｂ、判定結果の仕分け
一部は伏せ字にしてあります。 


Sun Sep 24 18:17:17 JST 2023
mta577.kth.gm.yahoo.co.jp  **ip-matched-ok**  183.79.220.96  mta577.kth.gm.yahoo.co.jp  (TYPE-C)

Sun Sep 24 20:04:11 JST 2023
bmmpp0703.jpx1.mta.emberpoint.com  **ip-matched-ok**  106.185.83.229  bmmpp0703.jpx1.mta.emberpoint.com  (TYPE-C)

Sun Sep 24 20:19:04 JST 2023
imgmailin.store  **NO-match**  195.133.***.***  b*****ley.jose******eo.com  (TYPE-A)

Sun Sep 24 22:32:33 JST 2023
online-shoppers.beauty  **NO-match**  194.87.210.182  unknown  (TYPE-A)

Mon Sep 25 01:17:04 JST 2023
pumbnh.net  **NO-match**  110.166.254.104  unknown  (TYPE-A)

Mon Sep 25 03:18:58 JST 2023
sbishinseibank.co.jp  **NO-match**  192.253.226.64  unknown  (TYPE-A)

Mon Sep 25 04:49:12 JST 2023
mail0.smtb.jp  **NO-match**  45.94.68.69  unknown  (TYPE-A)

Mon Sep 25 05:16:00 JST 2023
ffrokyec.asia  **NO-match**  36.25.33.93  unknown  (TYPE-A)

Mon Sep 25 08:11:58 JST 2023
mta250.kks.gm.yahoo.co.jp  **ip-matched-ok**  183.79.94.183  mta250.kks.gm.yahoo.co.jp  (TYPE-C)

Mon Sep 25 08:26:34 JST 2023
mail0.smtb.jp  **NO-match**  45.128.222.45  unknown  (TYPE-A)

＊＊＊　私の個人的な結論、Postfix で何が出来そうか、当サイトは今後どうするか　＊＊＊
＊かねてより私が批判的に見ている「サーバの名前Ａと名前Ｂを比較して受信拒否する手法」は言い換えれば TYPE-A と TYPE-B をスパムであるかどうか一切考慮せずに受信拒否するいい加減なやり方です。善良なメールまで受信拒否してしまうので論外です。残念ながら官公庁サイトでいまだにこの設定を使っているところが多数ありそうです。最初に書いた前提条件のとおり、悪いやり方です。
また、メールを受信拒否する手法は受け取り手の無い多くのメールをインターネットに投げ返すわけです。これはインターネット内をさまようゴミメールを作ることになります。はた迷惑な悪い手法だと思います。望ましいのは受信拒否するのではなく、スパムメールを自サイトで黙って削除することです。これならインターネットのゴミを発生させたりしません。
当サイトとして、こんなやり方を採用するつもりは無いです。

＊一方で「サーバのアドレスＡとアドレスＢを比較して TYPE-A のメールを捨てる手法」は前述の方法よりはマシだと思います。善良なメールを捨てないようにする意味での命中率は比べ物にならないくらい高いです。インターネットにゴミを撒き散らすこともやりません。
ただし一つの問題点として、確信犯的に TYPE-A でメールを投げてくるサイトがあるのと、チョンボしているサバ管さんが少しいることも考慮する必要があります。うちのような田舎サイトでも削除しないように配慮すべきメルサバを６０日間に５箇所発見しました。いずれも善良なメールなので捨てたり受信拒否することは出来ません。
またもう一つの問題点として、この手法だと TYPE-B については善良なメールもスパムメールも共に通します。
もしこの手法を採用するなら、以上の２点についてプログラムの改良や熟成が必要です。２点の改良は難しくなさそうですが時間をかけて熟成する必要があります。なので、手放しでこれを良い手法などとは言えません。

＊メーラのサブジェクト等チェックを利用するという、サーバに頼らない手法もあります。今回の Postfix を改良する以前はメーラーのサブジェクト等チェックだけでしのいでいましたが、それなりの満足感はありました。マアマア悪くなかったです、笑。

とりあえず、いま言えるのはこんなところだと思います。Postfix での対策を主眼点にすると歯切れの悪い結論です。
当サイトとして今後どうするか、まだ思案中です。

補足ですが、アドレスＡとアドレスＢを比較する手法は小規模なサイト（例えばうちのメルサバ）でないと無理です。間違って TYPE-A になってしまっているメルサバをログから見つけて救済する作業（プログラムに読ませる救済データのメンテ）が継続的に必要ですが、大規模サイトでそれをやるのは事実上不可能でしょう。
大規模サイトだと Spamassasin 又はこれに類するものを利用するしか手法は無いと思います。

2023-11-10　書き足し
　10月1日から今日まで40日程度、改造した postfix でサーバ運用してみました。使おうかどうか迷いましたが（ログ監視が欠かせなくなる）、せっかく数日の手間をかけて改造したので使ってみることにしました、笑。
間違って TYPE-A になってしまっているサーバが無いかチェックを続けていたところ、さらに2箇所発見しました。ただしそれ以上増える様子はありません。
うちのサイトでつき合っているメルサバの範囲で考えれば、間違えているメルサバは 10 箇所未満のようです。もちろん、そのメルサバは全部救済してあります。善良なメールを問答無用で送り返すような間違ったサーバ運用はダメです。
　また TYPE-B でくるスパムについては、パターンを観察しているとかなり有意なパターンがあり、それをとらえて処理するとサーバで簡単にスパムを排除できるようです（と言っても、排除用データリストに三語加えるだけ） 。それで多分 TYPE-B のスパムの 95％くらい排除できます。
それ以外の 5％についてはメーラーの Subject 等のチェックで対応出来ると思います。ただし、実際にくる「それ以外の 5％のスパム」というのは今の所 2 週間から 3 週間に 1 通くらいです。全般的にメルサバの運用は具合よくいっています。善良なメールを間違えて捨ててしまうことも無さそうです。ホッとしています。

2023-11-18　補足
　メーラでのスパム対応について。sylpheed は簡単に設定出来て evolution では出来ない（私は）と以前書きました。
最近になってようやく evolution でスパムメールの振り分けが出来るようになりました。キーワードを決めて振り分けです。
前は、［編集］ーーー［設定］ーーー［メールの設定］ーーー［ジャンク］から設定していて、それはまだ出来ません。きっと本来は出来るんでしょうが、私はまだそのレベルに到達していません、汗、笑。
しかし［編集］ーーー［フィルターの定義］から入りスパムを入れるためのフォルダーに集めるようにしたら、うまくいきました。スパムを集めるためのフォルダーを作っておくのがコツだったようです。
Sec-２．dovecot の設定について

　巷には dovecot の設定について解説した記事が沢山あります。あえて私ごときが書くことは無いのですが、LAN からしかメールを pop しない、我が家のような使い方の場合の話です。
セキュリティに関連しているといえば・・・・まあ関連しています。「そんなに、ログチェックしなくて良いだろう」って意味ですけど。
対象として debian 10.1 (10.2) で apt install した dovecot を前提とします。
運用のイメージは下の図のとおりです。LAN側からはメールを引けるけど、外部からはメールが引けません。ものすごく臆病者の設定です。（汗）
dovecot

まず、前置きの話から。
postfix が相方で dovecot をポップサーバとして動かす時の定番の設定は、概ね以下のかんじですね。

　後ほかに気をつけるのは、メールアカウントのあるユーザ ID については、ホームディレクトリをちゃんと作って、mode 755 にしておく必要があります。dovecot がホームディレクトリ中に書き込みをします。（pop3d だと、そういうことはありませんが・・）
こんな感じで、LAN 側からメールが引けるようになるはずです。

　ただし、また pop3d のときと違いが出ます。dovecot ってデフォルトのままだと、メールを引く行為をいちいちログに残します。いや、うるさいログになっちゃいます。
ここでセキュリティの話が関係します。外から pop するなら、当然平文パスじゃなくて暗号化するでしょうし、ログも全部取っておいたほうが良いと思います。
でも、LAN からしかメールを引かないなら、いちいちログ取る必要なんてありません。どうせ pop するのは自分だけだし。なので、info レベルのログは取らないことにします。その場合。

これで、info レベルのログは全部破棄されます。ただし、warn とか、大事なレベルのログはちゃんと取られます。大丈夫。
このセクションで書きたかったことは、「LAN からしかメール引かないなら、info レベルのログは取らなくて良いでしょ」ってことだけです。前置きの方が長かったです（笑）。
Sec-３．nftables を試してみて

　debian 10.2 あたりから、iptables の互換性がおかしくなったような気がします。
気のせいかもしれませんが、何か変です。いままで通っていた iptables のスクリプトがうまく作動しなくなりました。
ご存知のとおり、2019-11 時点での debian の iptables はバックで nftables が動いていて、フロントでは iptables 互換パッケージが動いている（そうです）。その互換パッケージがなんだか、変。
変な部分をなおすことなんて出来ないので、やむなく iptables から nftables に乗り換えることにしました。そのときに感じた軽いトピック話です。
技術的解説ではなく、自分が感じた印象や概要説明のみです。細部には踏み込みません。

まず、最初に参考サイトの紹介です。とても丁寧に書いてあります。私は何も勉強せずに、このサイトだけを見て使い始めました。

https://knowledge.sakura.ad.jp/22636/
---- Linuxにおける新たなパケットフィルタリングツール「nftables」入門 -----

さくらのナレッジってとこです。著者さん、ありがとうございます。
基本的には、上記のサイトを見れば（これまで iptables 使っていた人なら）簡単なことならば、すぐに使えるようになると思います。
以上です・・・・・って書くとあんまりなので、かいつまんで概要と印象を書きます（笑）

(ルールについて）
上から順、つまりテーブル・・・チェーン・・・ルールって説明でなく、下から順に行きます。
まず、ルールです。

  rule1
  rule2
  rule3
  ・・・・・
  ・・・・・

こんな順に rule が並んでいるとします。rule ってのは、例えば TCP25 を通すとか、established を通すとか、ま、いまはインプット側で話しますが、そんなルールのことです。一行でひとつのルールです。
ごく普通に上から順に適用されていきます。
iptables だと、このルール郡のなかで rule2 を削除しようとすると、テキストファイルを編集し、iptables 全体をリスタートする必要がありました。でも、nftables だと運用中の状態で、rule2 を削除したり、rule2 と rule3 の間に rule2b を入れたり出来ます。リスタートする必要がありません。
いや、これだけでもすごく便利でありがたいです。
やり方は、上記参考サイトに書いてあります。そこを見てください。

（チェーンについて）
　次にチェーンです。複数のチェーンがあるとすると、これの適用順はどうなるか？等々
順はチェーンの定義で優先度を決めればオケです。例えば下のような具合。

chain chain01{ 
  priority 10
　・・・・・
　・・・・・
}

chain chain02{ 
  priority 20
　・・・・・
　・・・・・
}

chain chain03{ 
  priority 30
　・・・・・
　・・・・・
}

最初の chain ってのは、これはチェーンだという宣言。
次の、chain01、chain02、chain03 はチェーンの名前。適当につけてます。
{　}の中に入って、最初に priority ってありますが、（ホントはもっといろいろ書きます。とりあえずこれだけ）優先度です。
上の例だと、10、20、30 の順に適用されていきます。
こんな感じで、複数のチェーンの適用順をわかりやすく管理できます。

この中で、ルールがどんな具合に適用されていくか、です。
ここでチェーン中の最初の記述をちょいと正確に書きます。インプットのフィルタで、ポリシーが accept とします。 

chain chain01{ 
  type filter hook input priority 10; policy accept;
　rule1 --------------  accept する ---------------  次のチェーンに入る
　rule2 --------------  drop   する ---------------  これで判定終わり
}

chain chain02{ 
  type filter hook input priority 20; policy accept;
　rule3 --------------  accept する --------------  次のチェーンに入る
　rule4 --------------  drop   する --------------  これで判定終わり
}

chain chain03{ 
  type filter hook input priority 30; policy accept;
　rule11 --------------  accept する ------------   最後のチェーンなのでこれで判定終わり
　rule12 --------------  drop   する ------------   これで判定終わり
}

いま例として上げている３つのチェーンは、全部インプットに対するチェーンで、ポリシーは accept です。
基本的にさっきと同じ。chain01 から順に適応されます。
その際、例えば chain01 の rule1 で accept となったパケットはその後どうなるか？　実は次のチェーンで再びまな板に乗ります。再度判定されるわけです。
一方で、chain01 の rule2 でdrop となったパケットはこれで判定終了。廃棄決定です。
最後の chain03 の rule11 で accept と判断されたものは、次のチェーンが無いので、これで判断終了です。
chain03 の rule12 で drop と判断されたものも、もちろんこれで判断終了です。

こんな具合なので、いくつかチェーンを作って、最初の方のチェーンは一般的に弾くような記述とします。
例えばスプーフィングとか、syn フラッドの前兆のパケットとか、要するに一方的に弾きます。
で、最後のチェーンで、通すものは通し、最後にそれ以外は全部 drop するルールを書いておきます。定番の書き方ですね。

なお、３つのチェーンについて、ポリシーを drop とした場合、どんな記述になるか、試していないので知りません。
ここは無責任でいきます（笑）
興味のある人は、どうぞ試してみてください。
個人的な印象ですが、全部ポリシーを accept にしておいて、上記のような定番の書き方が分かりやすいです。超個人的な感想です。

（テーブルについて）
　最後にテーブルです。
複数のチェーンをまとめて一つのテーブルにして名前をつけます。

table ip tekitou {
    chain chain01 {
        type filter hook input priority 10; policy accept;
        ・・・
        ・・・
    }

    chain chain02 {
        type filter hook input priority 20; policy accept;
　　　　・・・
　　　　・・・
    }

    chain chain03 {
        type filter hook input priority 30; policy accept;
　　　　・・・
　　　　・・・
    }
}

こんな感じです。table ってのは、これはテーブルだという宣言です。次の ip は IPv4 です。名前をつけて、後はチェーンを入れておきます。
以上のものを例えば、nft.rule とかってファイルにしておいて

# /usr/sbin/nft　-f　nft.rule

とすると、ルールセットが読み込まれて動き出します。
消す時は

#/usr/sbin/nft　flush　ruleset

とすると、テーブルごとルールが全部消えます。

　追加で、もう一点書いておきます。
iptables のときに複雑な（込み入った）ルールを書いていて、それを nftables のルールに変更するのが大変なら、iptables-translate で機械的に翻訳するのがオススメです。使い方はマニュアル見てください。で、適当にやってみれば、結構良い感じに翻訳してくれます。グッドです。
なお、肝心の個々のルールの書き方は示しません。参考サイトとかマニュアルを見てください。iptables 使っていた人なら、すぐに理解できると思います。

（感想など）
　nftables のイメージはだいたいこんな感じです。
例によって超個人的感想ですが、iptables より使いやすいです。速度や安定性がどうなのか、それは簡単なチェック程度ではわかりません。参考サイトの解説によれば、高速化されているらしいです。
とりあえず、自分はこれを気に入って使っています。
2020 年 3 月時点で使っている nftables のバージョンですが、Debian、CentOS、ArcoLinux は ver 0.9.x です。Ubuntu、LinuxMint、openSUSE は ver 0.8.2 ですね。
openSUSE を除き、サーバ系のOSはこういうセキュリティ関係は新しめのバージョンのようです。
Sec-４．最新カーネルとLTSカーネルについて(2023-05)　

　このチャプターらしく軽くふれます。最新のカーネルとLTSカーネルのそれぞれについて、不具合の発生状況とか出具合とかそんな観点です。

　まず最新カーネルの不具合です。
5.7 だか 5.8 の頃（詳細時期は失念）nvidia のドライバーがおかしくてカーネル不調でした。一時的な現象でしたが使っている機器によっては、システムが立ち上がらなくなるとか結構深刻でした。
2022 秋頃に 6.0 カーネルもおかしかった。Slackware のウェブサイトではそんなことが記述されていて Slackware-current は 6.0 を飛ばして 6.1 に上げました。懸命な判断だったと思います。
6.0 カーネルについては debian-testing も clear-linux も一時的にそのカーネルのときに様子がおかしかったです。
感覚的な話ですが一年か二年に一度程度の不具合発生のようです。カーネルの不具合はシステム全体の不調となりやすいのでまずいです。

　次にLTSカーネルの不具合です。
2022 夏頃、intel-core i 第10世代CPUを使っていると 5.10や5.15LTS カーネルで spectre-meltdown-checker がパスできませんでした。つまりセキュリティバグの修正ができなかった。これも一時的な現象でやがて適正な修正版マイクロコードが出回って、今は無事にチェッカーをクリヤできるようになっています。
どうやら「問題ない・大丈夫」と思われていた第10世代 core i CPU でセキュリティバグが見つかって現場が混乱したようです。
このとき最新版のカーネルはすぐに対応できたけど LTS 版は多少対応時期が遅れました。褒められた話ではないです。
ただし LTS カーネルの場合にはこの事例くらいしか不具合が思い当たりません。LTS カーネルは、割合とバグ・不具合が発生しにくいようです。

　ここで最新版カーネルを使うのと LTS カーネルを使うのとどちらが良いかなんて、結論は出しません。出せません。各自が好きに決めることです。
ただし、ユーザがどちらにしようか選択できるディストリは、その点では素晴らしいと思います。
では、ユーザがどちらのカーネルを使うか自由に選択できるディストリは何か？という話。これがこのセクションの本題です。簡単に言えば話のネタです、笑。

これまで私が試したことのあるディストリに話を限定します。そうすると現状では以下の２つだと思います。

残念ながら SUSE(tw) や Fedora ではカーネルを選べそうにありません。Debian-unstable　Debian-testing もユーザが自由に選ぶことはできません。
ただし Chap-13 に書きましたが Debian では xanmod カーネルという第三者の提供している仕組みで　LTSカーネルを使い続けることができそうです。
これはおすすめするという意味では無くて、単なる情報提供です。ご参考までに
一つ前のものは以下の URL です。
　　　　 https://www.quinos.net/topic6/topic6.01.html