このブログを検索

2021/06/06

postfixとdovecotの証明書更新

 先日適当にやってなんとか使えるようになっていたメールサーバの証明書が有効期限がすぎて、

iphoneでしつこく警告が表示されるようになったので証明書を更新したのだが、

その際にちょっと苦労したのでメモ。


まず、前提条件

・CAとメールサーバは同じサーバ。同じcn

・postfixとdovecotで使用する証明書は同じ


今回はcaの秘密鍵や証明書がどこにあるのが最新だかわからなくなってしまったので、

全部最初から作り直した。


やること。

1. caの秘密鍵生成

2. caの証明書作成(csrを発行して署名)

3. サーバの秘密鍵生成

4. サーバ証明書作成(csrを発行して署名)


postfixとdovecotの設定ファイルに証明書と秘密鍵の場所を設定する。


# grep smtpd_tls /etc/postfix/main.cf

smtpd_tls_cert_file = /etc/pki/tls/certs/server.crt

smtpd_tls_key_file = /etc/pki/tls/private/server.key


# grep tls /etc/dovecot/dovecot.conf

ssl_cert = </etc/pki/tls/certs/server.crt

ssl_key = </etc/pki/tls/private/server.key

ssl_ca = </etc/pki/tls/certs/ca.crt


# grep tls /etc/dovecot/conf.d/10-ssl.conf

ssl_cert = </etc/pki/tls/certs/server.crt

ssl_key = </etc/pki/tls/private/server.key


postfixやdovecotの設定パラメータやその書き方はよく変わる。

古い設定もしばらくは有効らしいがきっとそのうち使えなくなるので

なるべく最新にする。


ログを見ていると最新じゃないとかこの設定はいらないとか出ている。


サーバ秘密鍵は暗号化してしまうとダメときいたので暗号化しないようにした。





caで署名するときに秘密鍵や証明書を指定しないと設定ファイルの値を使うので、

設定ファイルを直すか、明示的に指定すること。

もしたまたま秘密鍵や証明書が存在していると、意図しないものを使ってしまうことになり、あとで正しい証明書として認識されないので注意。


わからなくなったら全部消してやり直すべし。


/var/log/maillog を見ていれば何が悪いかはだいたいわかる。



ca証明書をクライアントにインストールする。

私の場合iphoneでしか使わない。

iphoneの場合、pem形式のファイルをメールに添付して送ると開いたときにプロファイルとして保存されるので、それをインストールする。



2021/05/13

公開鍵暗号方式における暗号化とデジタル署名の双方向性に関する考察

公開鍵暗号方式において、暗号化は、公開鍵を用いて行われ、受信者は秘密鍵を用いて暗号化されたデータを復号する。

 

このとき公開鍵と秘密鍵はペアであり、データを暗号化して送信する者をA、データを受信して復号する者をBとすると、公開鍵はBが作成して公開した鍵であり、秘密鍵はBが作成して自分で保持している鍵である。

 

公開鍵を公開しないと暗号化することができないし、

秘密鍵を公開してしまうと誰でも復号化できてしまう。

 

公開鍵暗号方式では署名と検証ということも行われる。

 

署名と検証においては送信者が秘密鍵を用いて署名し、

受信者が公開鍵を用いて検証する。

 

この話を聞くと、

『要するに暗号化は公開鍵で暗号化して、署名は秘密鍵で暗号化するってことだね?』

と言いたくなってしまうのだが、そうではない。

 

とりあえず、「署名は秘密鍵で暗号化するということではない」と覚えておけば、

会話して笑われたり怒られたりすることはない。

 

が、そこで『じゃあいったい署名ってどんな処理なの?そしてそれを検証するってどういう処理なの?』

 

と考えてほしい。

 

というか、私はそれを考えて軽く調べてみたのだがよくわからないのである

 

公開鍵暗号方式は、ある程度大きな数の素因数分解が困難であることを利用している。

ある程度大きな桁数の素数を掛けることは容易であるが、

結果からもとの二つの素数を求めることはコンピュータを使っても事実上不可能である。

 

 

d1をもとのデータ、d2を暗号化したデータ、k1を公開鍵、Eを暗号化する演算とすると、


d1 E k1 = d2

 

k2を秘密鍵、Dを復号する演算とすると

 

d2 D k2 = d1

 

となればよい。

 

 このとき、Eが単なる掛け算であったら、k1は公開されているので、

d1を求めるにはd2 k1で割ればよいことになってしまう。

 

だから、Ek2を使わないと復号できないような演算でなければならない。

 

それはどういう方法だろうか?

 


 

RSA暗号のwikipediaを見る


鍵のペア(公開鍵と秘密鍵)を作成して公開鍵を公開する。

まず、適当な正整数 e を選択する。

また、大きな2つの素数の組み{p,q}を生成し、

それらの積 n=pq を求めて、

組み{e,n}を平文の暗号化に使用する鍵(公開鍵)とする。

2つの素数{p,q} は秘密に保管し、

暗号文の復号に使用する鍵(秘密鍵)の生成にも使用する

d=e^-1 mod Φ

ここで

Φ=lcm(p-1,q-1)

lcmは最小公倍数

暗号化(平文 m から暗号文 c を作成する):

c=m^e mod n

復号(暗号文 c から元の平文 m を得る):

m=c^d mod n

暗号化(乗)は公開鍵 {e,n} があれば容易に計算でき、

復号(乗)も容易に計算できる。

しかし、秘密鍵 d を知らずに解読(法 n の下で e 乗根を計算)するのは、

の素因数を知らないと難しい(大きい合成数の素因数分解も難しい)」

と考えられている。

つまり、「秘密鍵を用いずに暗号文から平文を得ることは難しい」と信じられている。

これがRSA暗号の安全性の根拠である。



 

鍵生成

 

をセキュリティパラメータとする。

p,q(ただしp≠q)をk/2ビットの素数とし、

n=pqとする。

eΦ(n)未満の正の整数で、

Φ(n)と互いに素な数とし、

dを、Φ(n)を法としたeの逆数 ( deΞ1 (mod Φ(n)) )とする。

ただしここでΦはオイラーのφ関数で、

この場合は

Φ(n)=(p-1)(q-1)

である。

dは、e,Φ(n)が既知の時には拡張されたユークリッドの互除法を使えば容易に求まる。

deΦ(n)で割った整数商をxとした場合、

de+(-x)Φ(n)=1

が成り立ち、

かつ

eの取り方から

gcd(e,Φ(n)) = 1

であるのでこれを解けばよい、

dを秘密鍵とし

n, eを公開鍵とする

pqが漏れるとdが計算で求まるため、pqは安全に破棄すること

 

暗号化

 

aを平文空間Znの元とする。

b=a^e mod n を計算し、bを出力する。

 

復号化

bを暗号文とする。

a' = b^d mod n を計算し、a'を出力する。

 

ここでa'=aとなり、復号できる。

  

ちなみに公開鍵暗号方式は最初RSA暗号方式なしに考案されて、

それを実現するためにRSA暗号方式が考えられたらしい。

 

 

さて。

 

では署名と検証である。

 

だいたい、以下のように説明されている。

 

送信者がデータのハッシュ値を計算して秘密鍵で暗号化し添付(これが署名)

受信者が暗号化されたハッシュ値を公開鍵で復号

受信者が自分でデータのハッシュ値を計算して、復号したハッシュ値と等しいかどうかを確認

 

wikipediaに書いてある通り、暗号化も復号化もおこなっている演算はある数について

ある数の累乗を求めそれをある数で割った余りを計算している。


同じ計算を違うパラメータでおこなうことによって暗号化になり復号化になるのである。


デジタル署名においては先に秘密鍵による演算がなされてその結果に対して公開鍵による演算がなされる。


これを、『秘密鍵により暗号化し公開鍵により復号化する』と言ってはいけないのだ。

そう言うと怒る人がいる。


怒る理由は、私が調べて理解したところでは以下の2点である。


1. それはRSA暗号方式にしかあてはまらない

2. 署名で「暗号化」するのはデータではなくデータのハッシュである




以下はRSA暗号方式を使うこと前提にした話である。



私が調べて理解した知識によれば、「秘密鍵でも暗号化できる」。


ただし、デジタル署名で暗号化するのはデータそのものではなくデータのハッシュである。


秘密鍵で暗号化されたデータのハッシュを公開鍵で復号化し、

自分でデータのハッシュを計算してその結果を復号化したハッシュと比較する、

これが「署名の検証」である。



では、データのハッシュを公開鍵で暗号化して秘密鍵の保持者に送信したら「署名」になるか?


ならない。


なぜなら公開鍵は公開されているので誰でもそれを使ってハッシュを暗号化することはできるからだ。





では、ハッシュではなくデータそのものを秘密鍵で暗号化して公開鍵で復号化させたらどうか?



暗号化というのは、「鍵を生成した人」ではなく、「鍵を生成した人に暗号化したデータを送信する人」が行う。


では、逆の場合は?「鍵を生成した人」が、誰かに暗号化したデータを送りたいときにはどうすればいいのか?


その場合は、データを送りたい相手に鍵ペアを生成してもらうのか。




秘密鍵でハッシュを暗号化し復号できるなら、秘密鍵でデータそのものも暗号化できるはずだが、そういう話は聞かない。


それをしないひとつの理由として、秘密鍵は公開鍵より鍵長が長くて演算に時間がかかる、ということが説明されていたが、


時間がかかるからやらない、ということなら不可能ではないということだ。


(未完)





2021/05/07

postfixとdovecotのSSL化@CentOS8

iphoneのメール設定の現状確認

outgoing server
 SMTP: 
       Use SSL: on
       Authentication: Password
       Server Port: 587

Advanced - Incoming Settings
  Use SSL: off
  Authentication: Password
  IMAP Path Prefix: /
  Server Port: 143

この状態で送受信できている。

postfixはssl対応できている。

Incoming Settingsで、 Use SSLをonにすると、

Server Portが 993になるが、設定検証でnot respondingとなる。

dovecotがssl対応していない

一応、postfixの設定確認

/etc/postfix/main.cf
smtp_tls_security_level = may
→これでtlsが有効になっている
※smtpd_enforce_tls=yes は古い設定

tlsの付く設定は

smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
smtp_tls_CApath = /etc/pki/tls/certs
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtpd_tls_security_level = may

証明書関連ファイルの確認

postfix.pem
postfix.key
ca-bundle.crt
 -> /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt

これらの証明書は存在していて、タイムスタンプがどうやらcentos8をインストールした日のようだ。

最初から入っていた?

とりあえず動いてるっぽい。

dovecotの設定

/etc/dovecot/dovecot.conf

protocols=imap pop3

で、imaps pop3sが有効になっていない?

protocols=imap3 pop3s

に変更してdovecot再起動すると

 5月 07 10:13:53 god dovecot[1269884]: doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:28: 
 ssl_cert_file has been replaced by ssl_cert = <file
 5月 07 10:13:53 god dovecot[1269884]: doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:29: 
 ssl_key_file has been replaced by ssl_key = <file
 5月 07 10:13:53 god dovecot[1269884]: master: Dovecot v2.3.8 (9df20d2db) starting up for imap, pop3
 5月 07 10:13:53 god dovecot[1269887]: config: Warning: NOTE: 
 You can get a new clean config file with: doveconf -Pn > dovecot-new.conf
 5月 07 10:13:53 god dovecot[1269887]: config: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:26: 
 'imaps' protocol can no longer be specified (use protocol>
 5月 07 10:13:53 god dovecot[1269887]: config: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:26: 
 'pop3s' protocol can no longer be specified (use protocol>
 5月 07 10:13:53 god dovecot[1269887]: config: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:28: 
 ssl_cert_file has been replaced by ssl_cert = <file
 5月 07 10:13:53 god dovecot[1269887]: config: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:29: 
 ssl_key_file has been replaced by ssl_key = <file

古い設定方法だったようだ。

imaps pop3sは imap pop3に戻す

/etc/dovecot/conf.d/10-ssl.conf

に設定する

ssl = no

を変更

ssl = yes

下記設定はデフォルトなのだが、見るとやっぱり証明書がある。

ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
ssl_key = </etc/pki/dovecot/private/dovecot.pem

firewalldでimaps pop3sを開ける

# firewall-cmd --add-service={pop3s,imaps} --permanent
success

# firewall-cmd --reload
success

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client dns http imap imaps pop3 pop3s samba smtp smtp-submission smtps
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

dovecot再起動すると

May  7 10:27:57 god dovecot[1270364]: imap-login: Error: Failed to initialize SSL server context: 
Can't load DH parameters: error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small: 

セキュリティ的に厳しくなった的なことらしい。

https://doteya.at.webry.info/201907/article_5.html
5月 07 10:34:05 god dovecot[1270813]: doveconf: Warning: 
Obsolete setting in /etc/dovecot/conf.d/10-ssl.conf:50: ssl_>
 5月 07 10:34:05 god dovecot[1270813]: master: Dovecot v2.3.8 (9df20d2db) 
 starting up for imap, pop3
 5月 07 10:34:05 god dovecot[1270816]: config: Warning: 
 NOTE: You can get a new clean config file with: doveconf -Pn >>
 5月 07 10:34:05 god dovecot[1270816]: config: Warning: 
 Obsolete setting in /etc/dovecot/dovecot.conf:28: ssl_cert_fil>
 5月 07 10:34:05 god dovecot[1270816]: config: Warning: 
 Obsolete setting in /etc/dovecot/dovecot.conf:29: ssl_key_file>
 5月 07 10:34:05 god dovecot[1270816]: config: Warning: 
 Obsolete setting in /etc/dovecot/conf.d/10-ssl.conf:50: ssl_dh>
 5月 07 10:34:06 god dovecot[1270816]: config: Warning: 
 please set ssl_dh=

ssl_dh= を設定してください、だそうだ。

下記設定を書いて、dh.pemを作成する。

# DH parameters length to use.
# 2021/05/07
#ssl_dh_parameters_length = 1024
ssl_dh_parameters_length = 2048
ssl_dh=</etc/dovecot/dh.pem


# openssl dhparam 2048 -out /etc/dovecot/dh.pem
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
..............................
(略)

take a long timeと表示されるが1分もかからない

dovecot再起動すると

May  7 10:37:28 god dovecot[1271026]: doveconf: Fatal: 
Error in configuration file /etc/dovecot/conf.d/10-ssl.conf 
line 51: ssl_dh: Can't open file /etc/dovecot/dh.pem: No such file or directory

見てみると確かにdh.pemがない。

もう一回やるがやっぱりできない。

ディレクトリを変えてカレントディレクトリに作ったりしても、できない。

調べると、opensslのコマンドオプションの書き方がバージョンにより変わったらしい。

https://iww.hateblo.jp/entry/20191109/dhparam
# openssl dhparam -out /etc/dovecot/dh.pem 2048
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
.............+.................
(略)

# ls -l
合計 32
drwxr-xr-x. 2 root root 4096  5月  7 10:35 conf.d
-rw-r--r--. 1 root root  424  5月  7 10:47 dh.pem
-rw-r--r--. 1 root root 4507  5月  7 10:18 dovecot.conf

dh.pemができた!

dovecotを再起動する。

# systemctl status dovecot
● dovecot.service - Dovecot IMAP/POP3 email server
   Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2021-05-07 10:48:33 JST; 10s ago
     Docs: man:dovecot(1)
           http://wiki2.dovecot.org/
  Process: 1271015 ExecStop=/usr/bin/doveadm stop (code=exited, status=0/SUCCESS)
  Process: 1271512 ExecStartPre=/usr/libexec/dovecot/prestartscript (code=exited, status=0/SUCCESS)
 Main PID: 1271518 (dovecot)
    Tasks: 4 (limit: 4993)
   Memory: 5.2M
   CGroup: /system.slice/dovecot.service
           tq1271518 /usr/sbin/dovecot -F
           tq1271521 dovecot/anvil
           tq1271522 dovecot/log
           mq1271523 dovecot/config

 5月 07 10:48:33 god systemd[1]: Started Dovecot IMAP/POP3 email server.
 5月 07 10:48:33 god dovecot[1271518]: doveconf: Warning: NOTE: 
 You can get a new clean config file with: doveconf -Pn > dovecot-new.conf
 5月 07 10:48:33 god dovecot[1271518]: doveconf: Warning: 
 Obsolete setting in /etc/dovecot/dovecot.conf:28: 
 ssl_cert_file has been replaced by ssl_cert = <file
 5月 07 10:48:33 god dovecot[1271518]: doveconf: Warning: 
 Obsolete setting in /etc/dovecot/dovecot.conf:29: 
 ssl_key_file has been replaced by ssl_key = <file
 5月 07 10:48:33 god dovecot[1271518]: doveconf: Warning: 
 Obsolete setting in /etc/dovecot/conf.d/10-ssl.conf:50: 
 ssl_dh_parameters_length is no longer needed
 5月 07 10:48:33 god dovecot[1271518]: master: Dovecot v2.3.8 (9df20d2db) 
 starting up for imap, pop3
 5月 07 10:48:33 god dovecot[1271522]: config: Warning: NOTE: 
 You can get a new clean config file with: doveconf -Pn > dovecot-new.conf
 5月 07 10:48:33 god dovecot[1271522]: config: Warning: 
 Obsolete setting in /etc/dovecot/dovecot.conf:28: 
 ssl_cert_file has been replaced by ssl_cert = <file
 5月 07 10:48:33 god dovecot[1271522]: config: Warning: 
 Obsolete setting in /etc/dovecot/dovecot.conf:29: 
 ssl_key_file has been replaced by ssl_key = <file
 5月 07 10:48:33 god dovecot[1271522]: config: Warning: 
 Obsolete setting in /etc/dovecot/conf.d/10-ssl.conf:50: 
 ssl_dh_parameters_length is no longer needed

ssl_dh_parameter_lengthは必要ないようだ。

warningとかはまだ出てるけど、とりあえず動いたっぽい。

iphoneのメールアカウント設定で incoming serverのsslを有効にする。

verifyでサーバ証明書の警告がでた。

continueをタップする。

メールを送ってみる。

受信できた!

これで送受信ともにssl化できた!

2021/05/01

LPIC303

LPIC303に受かった。 

LPICはレベル2が一番難しい、みたいなことを聞いていたが、どうだろうか。 

試験は一つでいいし、試験範囲もそれほど広くないが、 勉強するのはけっこう大変だった。 

なかなか覚えられない。 得点はlevel1からlevel3になるにつれてだんだん低くなった。 

LPICは合格点が低いので、今回はたぶん大丈夫だろうと思ったが、 予想以上に得点が低く、喜びがあまりなかった。 

でも、今回この試験を受けるにあたっていろいろ覚えたし、 いい経験になった。 

おもしろかった。

私は本業はネットワークなのだが、LPICの勉強をするのはCiscoの資格試験の勉強より楽しい。

本業じゃないからだろうか。

もちろん、Linuxならなんでもわかるなんて、とても言えない。 

受ける前は、LPIC-3を持ってる人をすごいなあと思っていたが.....

まだまだ、知らないことだらけ。

2021/04/30

SELinux有効化後 cgiが動かなくなった

自分のサーバで掲示板のようなcgiを動かしているのだが、SELinux有効化後に投稿したらInternal Server Errorになった。 特に何も変更していないので、すぐに「SELinuxのせいだ!」と思い、/var/log/messagesを見る。
Apr 30 05:16:08 god setroubleshoot[243206]: 
SELinux is preventing post.cgi from write access on the file temp.txt.
#012
#012*****  Plugin catchall (100. confidence) suggests   **************************
#012
#012If you believe that post.cgi should be allowed write access on the temp.txt file by default.
#012Then you should report this as a bug.
#012You can generate a local policy module to allow this access.
#012Do
#012allow this access for now by executing:
#012# ausearch -c 'post.cgi' --raw | audit2allow -M my-postcgi
#012# semodule -X 300 -i my-postcgi.pp
#012
cgiがファイルに書き込むことが許可されていない。 そして、それを許可するようにする方法も書かれている。 ausearchで問題が起きているcgiファイルを探して、パイプで audit2allowに渡してmoduleを作成し、 semoduleでそれをinsallする、ということのようだ。
# ausearch -c 'post.cgi' --raw | audit2allow -M my-postcgi
******************** 重要 ***********************
このポリシーパッケージを有効にするには、以下を実行して下さい:

semodule -i my-postcgi.pp

言われたとおりに

# semodule -i my-postcgi.pp

messagesには

semodule -X 300 -i my-postcgi.pp

と書いてあるが、-Xというのはpriorityを指定するオプションのようだ。

が、-Xなしで実行し、同様のcgiがもう一個あったのでそれも同様にすると、掲示板に投稿できるようになった。

そもそもなんでこのcgiがSELinuxで止められたかであるが、それにはちょっと心当たりがあって、 このcgiを作った時にファイルに書き込みができないということが起きて、権限の問題だろうということで、 よくわからないのでとにかくなんでもありの権限や所有者設定にしたのを覚えている。 おそらくそういう適当な権限設定のファイルを扱ったのでSELinuxが止めたのだと思う。

多分、cgi実行ユーザとファイル所有者が違う、とかいうことじゃないかと思うが、今回はめんどくさいのでこのまま許可してしまう。

2021/04/29

SELinux始めました

 SELinuxなんか無効にするのが当たり前となって10年くらいたった。(自分の中で)

さくらのVPSも、conohaのVPSも、SELinuxはデフォルトで無効じゃないか?

自分で無効にした覚えがないから。


初めてCentOSをさわった頃、たしか4か5の頃、なんかおかしいなと思ってSELinuxを無効にしたらうまくいった、ということがあって、そのうち最初から無効にするようになった。

私がLinuxを使うのはほとんどが実験や検証的な場合だったのでそれでよかった。


だが、セキュリティについていろいろとうるさくなってきた昨今、

「めんどくさいからオフる」

という思考回路を改めた方がいいのでは?と感じている。


そこで、とりあえず自分が使っているcentos8のSELinuxを有効にしてみた。


参考

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-working_with_selinux-enabling_and_disabling_selinux


いまSELinuxが有効かどうかは

getenforce

でわかる。

disabled

になっている。

Enforcingだと有効、Permissiveだとポリシーをチェックするが動作は止めない、disabledだとポリシーもチェックしない無効な状態である。

enforcing/permissiveの切り替えは setenforceコマンドでできるが、

disabledにする、disabledから再度有効にするには、

/etc/selinux/config

を書き換える必要がある。

有効にするなら

SELINUX=enforcing

上記のRedHatの情報を見ると、SELinuxが無効の状態から有効にするときにはいったんpermissiveにして再起動し、ログをチェックして問題がないことを確認してからenforcingにする、と書いてあった。


また、必要なSELinuxのパッケージをインストールしておく必要がある。

(私の場合は事前になんでもかんでも突っ込んでいた)


その通りにやってみると、私の場合sshdに関する以下のようなログが記録された。

Apr 29 03:03:12 god setroubleshoot[1550]: 
SELinux is preventing /usr/sbin/sshd from name_bind access 
on the tcp_socket port xxxxx. 
For complete SELinux messages run: 
sealert -l 78b09f6f-3440-421f-976d-55edb0af1088

port xxxxx の xxxxx は実際には数字が記録されていて、この数字はsshで使用するポートをデフォルトの22から変更したポート番号である。

「SELinuxが有効だとsshのポート変えられないのか!じゃあ無効にしよう!」

ではなく、

SELinuxの設定でもsshで使用するポートを変更あるいは追加すればよいのだ。

semanage port --list

で現在の設定が表示される。

sshでgrepすると

# semanage port --list | grep ssh
ssh_port_t     tcp      22

追加するには

# semanage port --add --type ssh_port_t --proto tcp xxxxx

dnssecはじめました(2)

参考

https://www.nic.ad.jp/ja/dns/dnssec/dnssec-startup-guide.html

centos8で

/home/dnssec

というフォルダを作り、そこへ移動

ZSK (Zone Signing Key) の生成

# dnssec-keygen -a RSASHA256 -b 1024 -n ZONE monqy.net
Generating key pair............................+++++ ............................+++++ 
Kmonqy.net.+008+47608

KSK (Key Signing Key) の生成

# dnssec-keygen -a RSASHA256 -b 2048 -n ZONE -f KSK monqy.net
Generating key pair..........................................................+++++ ...........+++++ 
Kmonqy.net.+008+36227
zoneファイルのあるフォルダへ移動
# cd /var/named

zoneファイルに署名

# dnssec-signzone -S -K /home/dnnssec/ monqy.net.zone
Fetching ZSK 31795/RSASHA256 from key repository.
Fetching KSK 3160/RSASHA256 from key repository.
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 stand-by, 0 revoked
monqy.net.zone.signed

zoneファイルの後ろに ".signed"がついたファイル "monqy.net.signed" ができる。

前回のエントリではゾーンファイル名に.zoneを付けていたが、 今回はドメイン名をそのままゾーンファイル名にした。 (なんか.zoneがついてるとうまくいかなかった気がしたが気のせいかもしれない)

これはテキストファイルで中身を見ることができるが、 RRSIG, NSEC, DNSKEYなどが追加されているのがわかる。

そして /etc/named.conf のゾーンファイル名を、 署名付きのものに変更して、namedを再起動する。

zone "monqy.net" {
        type master;
        file "monqy.net.signed";
};
で、dig
# dig @localhost monqy.net DNSKEY +dnssec +multi

とやると、なにやらずらずらと引ける。

この後、DSレコードを上位サーバに登録する必要があるらしい。

参考にしたサイトだと「DSレコードをJPNICに登録します」とあるが、 これは例がJPNICの管理しているIPアドレスの逆引きゾーンだからで、 私がやっている .net のドメインだとどこになるのか?

後で調べます。