あきネット

フリーソフトウェアやオープンソースをはじめ、コンピューターやインターネットに関するTIPSや話題を扱います

北のまちから南のまちへと素敵な何かを届けます。
それは、六花かもしれないし、ナナカマドの実かもしれないし、雪の下キャベツかもしれません。

メールを暗号化しない日本マスメディアの不可解

最近は、国営放送のメール誤送信が騒動になっていますね。


ジャーナリストの能力がないといいますか、ジャーナリズムをやっている気もないのでしょうね。


例えば、データのやりとりにしても、URL貼り付けて平文メールで送るなんて、愚かにもほどがあろうものです。


誤送信でなくとも既に漏洩だといえます。
平文メールだから。


少なくとも、貼り付けたURLが、許可した特定の相手にしか使えないものであったり、データを開くのに公開鍵暗号方式など高度な認証が施されていたりすれば、平文メールで送る手もありますけれどね。


マスメディアの者なのに、例えばスノーデン氏とか、Tails や Tor のことも知らないのでしょうねえ。
マスコミ人失格といいますか、教養人でもないのでしょう。



簡単に言うと、GnuPG とかを使って OpenPGP を利用して、公開鍵暗号方式で電子署名と暗号化を行えばよいわけですよ。公開鍵を本人確認と同時に手交しましょう(世界の常識)。
機密データを受け渡しするのにも、CC とか BCC とか、送信先を複数にしたメールを送るのは反則ですね。


そもそも、国営放送とか、メールクライアントに何を使っているのでしょうかね?



再発防止策とかいう以前に、何を間違えていたのか判っていないのでしょうから、論外ですよ。無理。



きっと、GnuPG とか PGP とかワカリマセンというレベルなのでしょうから、
最低限でも、ログインで認証のかかったグループウェアだとかでデータのやり取りをしてください。


ましてや、詐欺恐喝で強制契約させ「みなさまの受信料」を徴税している国営放送(経営者選任も予算決算も国がやる国営放送)が、その組織とカネでやっているのですからね。


Firewalld のバックエンドは、バージョン0.6.0から nftables

Red Hat 系のディストリビューションでも採用されている Firewalld ですが、
バージョン 0.6.0 以降はデフォルトのバックエンドが nftables に変更されています。


Release firewalld-0.6.0 · firewalld/firewalld · GitHub


nftables backend

This is the new default for all firewalld's abstractions. The direct interface still supports iptables, ip6tables, and ebtables. It is configurable via FirewallBackend in /etc/firewalld.conf - valid values are; nftables, iptables.



2018年7月6日にリリースされています。
0.6.0 以降のバージョンが入っているディストリビューションは現在のところ限られているでしょうけれども、今後増えてくると思われます。


以前のバージョンでは iptables / ip6tables / ebtables でしたが、
nftables をバックエンドにすると当然ながら、 iptables / ip6tables / ebtables のコマンドではフィルタリングの状態が判りません。そして、デフォルトでは nftables なので、意図的にデフォルトから変えないと、iptables などは使われません。


ウェブ上の情報もほとんどが、 iptables などがバックエンドだという前提で書かれているものですので、 nftables のほうにデフォルトが替わってからは、これらの情報は通用しなくなってきます。



$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

iptables -L だとカラですので、ファイアーウォールが利いていないのかと錯覚します。
しかし、


$ sudo nft list table inet firewalld
table inet firewalld {
chain raw_PREROUTING {
type filter hook prerouting priority -290; policy accept;
}

chain mangle_PREROUTING {
type filter hook prerouting priority -140; policy accept;
}

chain filter_IN_internal {
(以下略)


nft コマンドを使用すれば判るわけですが、
iptables に慣れていると、nft コマンドを直接操作するのは難解です。
やはり、 Firewalld のようにフロントエンドが多くの人には必要かと考えられますね。




Nginx の location の設定は難解

ウェブサーバというと、Apache と Nginx と Lighttpd だと思うのですが、それぞれに何を優先しているかが異なります。
Apache は多機能であること、Nginx は高速であること、Lighttpd はリソース消費の少ないことでしょう。


Nginx は、同時アクセス者数が多いウェブサイトに向いたようにつくられています。
そのため、人気サイトで次々に導入されて話題になり、それに釣られて導入する人が増えたものと思われます。だから、「実際にあなたのサイトに向いているかどうか」というと、別です。


CPUコア数やメモリ量の少ないサーバマシンだと、Lighttpd が向いていることが多くなってきます。


そういうわけで、私の生活としては Nginx を使用しないといけないような事情はあまりないのですが、
技能的に、 Apache や Lighttpd だけではなく、シェアの大きな Nginx も運用してみないといけないよね、という思いもあって、Nginx も試しています。


設定のしやすさも、Lighttpd はプログラミング感覚で書けますし、Apache は特徴的だとはいえ不可解ではありません。
ところが Nginx は、性能最優先なので、見た目は単純でも、難解です。処理性能最優先なので、処理性能を落とすような設定のしかたは嫌われます。
Nginx は、癖のある、作者の思想をゴリ押しするソフトウェアです。


例えば、 .htaccess にわざと非対応にしているのが Nginx です。.htaccess を検索すると遅くなるからです。
なので、レンタルサーバみたいに不特定多数が利用するものでは .htaccess の需要が高いですが、 .htaccess に対応させるためには改造が必要です。 Nginx なのに .htaccess に対応しているレンタルサーバがあれば、性能をある程度犠牲にして改造を施してあるということです。


このように、実は、 Nginx は万人向きでは全くなく、ユースケースをとてもえらぶウェブサーバなのです。



さて、Nginx の設定で、特に難解なのは location の設定です。
location で、アクセス先にあわせて場合分けして設定を適用するわけですが、その書き方が、見た目は簡単なのに、難解です。


location に使用するmodifier(演算子)は、

  • (なし)
  • ~
  • ~*
  • ^~
  • =

の5種類です。こんな modifier を用いるのは Nginx 独特です。奇怪です。
Perl などは =~ というのがあって Lighttpd でも書きますが、Nginx にはありません( ~ 1文字がこれに相当します)。


このうち、なしと、 = は、文字列そのもののマッチです。


なしと、 ^~ は、前方一致です。


~ と ~*は、 regular expression によるパタンマッチです。
~ は大文字小文字を区別します (case sensitive)。 ~* は区別しません(case insensitive)。


^~ は、マッチすると、ほかのパタンマッチ(~のついている条件)を無視します
= は、完全一致で、一致すると、あとのマッチング解析をやめます。
つまり、 ^~ や = を巧く使うと、マッチング解析に無駄がなくなり高速になります。


しかしそれはつまり、
下手に ^~ や = を使うと、思い通りの結果にならなかったり、設定ファイルがエラーになったりします。


location は nest (入れ子構造)でも書け、ネストを巧く使えば場合分けに無駄が減り、やはり高速になります。
ところが、  ^~ や = といった、ほかの modifier より優先順位の高いものが混在すると、思い通りの結果にならなかったり、エラーになったりするわけです。
だから、 「Nginx の設定にはネストを使うな」、「ネストは使えない」と言う人までいます。


パタンマッチにしても、巧く使うと解析は速いです。下手に使うとボトルネックです。
例えば ^ (行頭) や $ (行末)記号を用いれば、当てはまるものがより絞り込めるので速くなるはずです。
反対に、 .* みたいに、何も絞り込んでいないのがいると、遅くなるはずです。


使う必要がなければ ~* も使わないほうが速いです。例えば、そもそも .JPG だとかいうようなファイル名などに大文字をつかうことをやめてしまえば、速くなるわけです。


設定を完成させるまでに試行錯誤の要る、面倒くさいウェブサーバが Nginx です 😂


そして、完成した設定は安易に編集していけない危険のあるのも Nginx です😅
管理者が複数いると大変ですね。


Nginx は、処理性能が先にありきなんです。
設定内容をざっと見て一瞬で解るようには、なかなか、いきませんね。