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 でメールサーバ立てて送ってくる所、結構あります。
みんな、決して悪い人たちじゃありませんよ。だから、こういう間違った設定をサーバに適用したり、ネットで広めたりするのはやめてください。
是非是非、お願いします。





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 のスクリプトがうまく作動しなくなりました。
ご存知のとおり、現時点での debian の iptables はバックで nftables が動いていて、フロントでは iptables 互換パッケージが動いている(そうです)。その互換パッケージがなんだか、変。
変な部分を治すことなんて出来ないので、やむなく iptables から nftables に乗り換えることにしました。そのときに感じた軽いトピック話です。
技術的解説ではないです。

to be continued......