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

Sec-1.SMTPへの制限について
Sec-2.dovecot の設定について
Sec-3.nftables を試してみて

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



Sec-1.SMTPへの制限について 

 セキュリティ関連の話題として、最初に触れたい話は、やはり SMTP への制限のことです。例の「逆引きが出来ないメールサーバからの受け取りを拒否する」という設定のことです。
もう、こんな制限はヤメましょう。

この制限の問題点
smtpd_client_restrictions = reject_unknown_client

 ヤメましょうと主張するからには、理由を説明しなければなりません。以下に説明します。
数学の「集合」を例にして説明すると、一番分かりやすいと思います。
上記の設定は「逆引きが出来ないメールサーバは、一律にみんな悪いやつら」という前提に立っています。つまり、下の図の概念。


revIP2

 これなら、完全に上の前提どおりではないにせよ、まあ、許せる範囲ですね。でも、実態は下の図のような具合です。


revIP1

 円の中の白い部分(黄色以外の部分)は、「逆引き出来ないメールサーバだけど、悪くない人達」です。ちなみに自分もここにいると思います。いや、ホントです。スパムなんて絶対に投げません!
下の図が現実の姿なのに、上の制限を適用すると、「何も悪くない沢山の人達を巻き添えにして、一部の悪い奴らのメールを拒否している」ってことになります。

残念ながら、いまだに「メールサーバ」「逆引き」で検索すると、この制限を勧めている記事をたくさん見かけます。
もういい加減、こんな制限をウェブサイトに載せておくのはやめてほしいと思います。私を始め dynamicDNS でメールサーバ立ててる人たちは 2019-11 現在だと沢山います。アキバのパソコンショップさんたちの中にも、dynamicDNS でメールサーバ立てて送ってくる所、結構あります。
逆引きが設定出来ないのは、個人の努力不足ではなく、dynamicDNS の制度上やむを得ない話なのです。
だから、こういう制限をサーバに適用したり、ネットで広めたりするのはやめてください。
是非是非、お願いします。





Sec-2.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-3.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   する ------------   これで判定終わり
}

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

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

なお、3つのチェーンについて、ポリシーを 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はこういうセキュリティ関係は新しめのバージョンのようです。