最近の投稿
エアコンの更新 RAS-YF40N2024-04-21
「お代官様、こちら袖の下にございます」2024-04-20
おはよー2024-04-11- xz-utils のバックドア問題2024-04-07XZ形式の圧縮ファイル生成/解凍の xz-utils […]
足羽川の桜🌸2024-04-07
usacloud monitor-cpu
$ usacloud server list -q
$ usacloud server monitor-cpu ¥
--start 2022-11-11T00:00:00+09:00 ¥
--end 2022-11-11T12:00:00+09:00 ¥
123456789012
$ usacloud server monitor-cpu ¥
--start 2022-11-15T15:55:00+09:00 ¥
123456789012 2>/dev/null ¥
| jq -r ".[].CPUTime" ¥
| tail -1
0.012345
自宅ドメインのwhois情報の修正
セキュリティの話をする際に、whois とかを使うこともあるけど、自宅ドメイン名で検索するとクソまじめに登録してあったから住所とかそのまんま検索できていた。
改めてプライバシー対策ということで、さくらインターネット🌸のwhois情報を修正してみた。最初、番地情報を消したりしたけど、エラーが発生して修正できず。レジストラの情報を書くのはアリ見たいだったので、入力フォームにある「さくらインターネット」の情報をそのまま入力したら、エラーも発生せず修正できた。
トラブルが発生しても、一旦レジストラに連絡が行ってから、こちらに連絡が来るんだろうし、これでも問題ないかな。
Buffalo ルータの更新 ver 2.86
JVNから、Buffalo ルータの脆弱性情報が流れてきた。自宅のルータも該当しているので、Buffalo のページからダウンロードして、さっそく適用。ver 2.85→2.86
しかしながら、このセキュリティ対策のおかげで、munin にて ルータのパケット流量をモニタリングするための script が動かなくなって、パケット流量が取れなくなった。
CAA レコードが未設定で dehydrated (Let’s Encrypt) が失敗
自宅ドメインの SSL 証明には、Let’s Encrypt (実体は dehydrated) を使っているけど、CERT の有効期限の確認の処理で警告がでてきて、月に1度実施の更新でエラーを吐いているみたい。
DNS に CAA レコードが無いと失敗する
更新を実行すると、以下の表示が出ている。
ERROR: Challenge is invalid! (returned: invalid) (result: ["type"] "http-01" : ["error","detail"] "CAA record for tsaitoh.net prevents issuance"
Let’s Encrypt が更新する際に、ドメイン名の CAA レコードを参照しているけど、CAA レコードが正しくないために、SSL 更新に失敗している。
DNS Certification Authority Authorization とは、ドメイン名の所有者が認証局に対して、自分のドメイン名の公開鍵証明書の発行を許可するかどうかを指定できるようにするインターネットセキュリティポリシーのしくみである。(Wikipedia)
CAAレコードに letsencrypt.org を登録
自宅ドメインは、Dynamic DNS に mydns.jp を使っているので、mydns.jp の設定画面の “DOMAIN INFO” の所で、
「@ CAA 0 issue “\000”」 となっていたので、下記の設定を追加する。
| Hostname | Type | Content | Target ID |
| @ | CAA | 0 issue “letsencrypt.org” | mydnsXXXXX |
この設定の後、nslookup では、下記のようなデータが取れるようになった。
$ nslookup -query=CAA tsaitoh.net tsaitoh.net rdata_257 = 0 issue "letsencrypt.org"
他の仕事関連のドメイン名も同様の症状が発生するようになるはずなので、mydns.jp 関連の他ドメインで同様設定を追加する。
Edgerouter-x 2.0.9-hotfix4
ふと、ファームウェアの確認などをしたら、Edgerouter-x の最新が数日前に出ていたみたい。
過去の記事をみて、インストール。暑い時期だったのか、最初ファームのルータへのアップロードに失敗して心配だったけど、リトライしたら普通に成功。
nagios4 をインストール
icinga が最新パッケージではサポートされていないので、icinga2 や zabbix をインストールしようとしたけど、データベースの初期化やらが面倒で上手く動かせていない。でも改めて確認したら、nagios3 から 更新しようとしたけど一度諦めた nagios4 のパッケージがインストールしやすくなっていた。しかもDebian12(bookworm)でも使える。
もともと、icinga は nagios からの派生だし、nagios3時代の名残りのファイルも残ってたし、設定ファイルのそれなりの変更は必要だったけど、監視コマンドなどの設定はそのまま流用できた。
設定ではまったこと
設定がそれなりに完成したけど、最初警告メールが飛ばずに悩んだ。
原因は、サービスの設定ファイルのテンプレート generic-service だった。いい加減な設定でメールが飛ぶのを防ぐために、templates.cfg で設定している generic-host や generic-service をそのままサービス監視の定義に使うと、テンプレートの設定の generic-service の定義の最後についている “register 0” によって、これはテンプレートだから…ということで、通知などの機能が動かない様になっている。
そこで generic-service から派生させた local-service などを使うべき。
# ダメなサービス定義
define service{
use generic-service ; Name of service template to use
host_name localhost
:
}
# 有効なサービス定義
define service{
use local-service ; Name of service template to use
host_name localhost
:
}
もう少し調整したいところもあるけど、ひとまず使えるようになってきた。
北陸情報通信協議会会長表彰
といっても、ict4e の原さんや、講習会で協力いただいた電子情報OBのおかげです。postgreyの更新トラブル
postgrey に更新があった(1.36-5.2 ⇒ 1.37-1)ため、外部からのメールが届かなくなり、設定の変更が必要となった。
postgrey trouble
職場で動かしている WordPress の2段階認証メールを自宅サーバに転送しているが、2段階認証のメールが届かなくなった。原因は、怪しいメールは一旦拒絶することで spam を拒否してくれる postgrey がうまく機能していないと思われる。
/var/log/mail.log を見ると、下記のようなエラーで postgrey が起動していない。
May 5 16:53:15 ...: warning: problem talking to server 127.0.0.1:10023: Connection refused
エラーを探すと /var/log/syslog に以下のメッセージを残して、postgrey 起動に失敗しているので、
May 5 17:11:53 ... postgrey[974882]: Option greylist-text requires an argument
/etc/default/postgrey の POSTGREY_TEXT のオプションをコメントアウト。
((( /etc/default/postgrey ))) - POSTGREY_TEXT="" + # POSTGREY_TEXT="reject by postgrey"
しかし、この変更後も職場からのメールが reject されている。
May 5 17:19:20 ... postfix/smtpd[975541]: NOQUEUE: reject: RCPT from unknown[xxx.xxx.xxx.xxx]: 450 4.2.0 <t-saitoh@tsaitoh.net>: Recipient address rejected: reject by postgrey; from=<www-data@...> to=<...@...> ...
たぶん、職場のサーバは Azureで動かしているが、今回の更新による拒否判定が厳しくなったんだろう。仕方がないので、/etc/postgrey/whitelist_clients.local に、自分の管理している Azure サーバのIPアドレスを書き並べる
((( /etc/postgrey/whitelist_clients.local ))) xxx.xxx.xxx.xxx 職場のWordPressサーバのIPアドレス
でも、postgrey-1.37 の更新は本家の changelog を見ると 2016年 みたいだけど、debian パッケージでは随分遅れての 更新だな。手法的にも、もっと確実な、SPF とか DKIM の対応がすすんで、postgrey は時代遅れなのかな。自宅サーバでは、postgrey で reject しそうな接続元は GEOIP で SMTP 拒否しまくりだし、あまり役に立ってないかも。
postfix backward compatibility
今回のトラブルで改めて、postfix のエラーログを見ているとpostfixの再起動時に以下のようなメッセージが出ている。
May 5 19:06:07 ...: Postfix is running with backwards-compatible default settings May 5 19:06:07 ...: See http://www.postfix.org/COMPATIBILITY_README.html for details May 5 19:06:07 ...: To disable backwards compatibility use "postconf compatibility_level=3.6" and "postfix reload"
設定ファイルでは、compatibilty_level が 2 とかになっていたので、書いてある通り 3.6 に上げておく。
((( /etc/postfix/main.cf ))) compatibility_level = 3.6
G.ROOT-SERVERS.NET が繋がらない
自宅のDNSのトラブルで、ルートサーバが国ドメイン単位での接続拒否でつながらないのが原因? だったかもしれないのだが、職場の自室で動かしている Cache DNS でも同様のトラブルが出るので、ルートサーバの接続確認。G.ROOT-SERVERS.NET. だけつながらない。自宅でも職場でも同様。
$ grep 3600000 /etc/bind/db.root \
| grep A | grep -v AAAA | grep -v NS \
| awk '{print $4}' | fping
199.7.91.13 is alive
192.203.230.10 is alive
:
192.58.128.30 is alive
192.112.36.4 is unreachable ← G.ROOT-SERVERS.NET. だけつながらない
G.ROOT-SERVERS.NET. はアメリカ国防総省の管理か….単に一時的な問題なのかな…
接続拒否国ドメインに PA, IO を追加
相変わらず、メールなどに怪しい所からの接続。国ドメインを確認したら、PA(パナマ共和国) と IO(イギリス領インド洋地域)。
大変申し訳ないけど、我が家のようなサイトは縁がない国なので、接続拒否。
現時点、我が家では下記ドメインが管理している IP アドレスは接続を拒否している。
AE, AF, AM, AZ, BD, BG, BR, BY, CL, CN, ES,
HK, ID, IN, IL, IO, IR, IQ, JO, KG, KP, KR, KW, KZ,
LB, MY, NL, OM, PA, PH, PS,
QA, RO, RU, SA, SY, TH, TJ, TR, UA, UZ, VN, YE
Google 検索
