最近の投稿
学習リモコンRM-PZ3D2024-12-18親の寝室のテレビのリモコンが動かなくなり、SONYの学習リモコンRM-PZ3D […]
Switchbot APIが急に動かなくなった2024-12-16Switchbot のデータを、OpenWonderLabs / Switchbot API v1.1 […]- homebridge-gsh で接続できず再設定2024-12-06数日前から、Google Home から照明やエアコンを操作していたのが動かなくなる。 […]
がぉ〜っ2024-12-02
のび〜ぃ2024-12-02
FortiGuard Web Filter
自宅サーバで CTF 問題とかを公開している中、nmap の実験で自宅サーバをチェックすることがあるけど、8008, 8010 とかのポートが表示されるのが気になっていた。
$ nmap tsaitoh.net Starting Nmap 7.80 ( https://nmap.org ) at 2022-12-06 14:12 JST PORT STATE SERVICE (略) 8008/tcp open http 8010/tcp open xmpp 8022/tcp closed oa-system 8080/tcp closed http-proxy Nmap done: 1 IP address (1 host up) scanned in 4.35 seconds
自宅のサーバでは、FireWall でポート制限しているし、対外接続のルータでも、特定のポートだけ DMZ 設定などでサーバに接続できるようにしていた。CTF の問題作る中で一時的に開いたものかと思ってた。
FortiGuard WebFilter
でも改めて http://tsaitoh.net:8008 とかしてみたら、下記の画面が表示された。どうも自宅のルータより外部の丹南ケーブルテレビ側のルータで、FortiGuard の WebFilter が動いているかと思われる。
そこで、”traceroute tsaitoh.net” を実行すると表示される自宅サーバの一つ手前のルータ?を調べてみる。
$ traceroute 64.33.3.150
traceroute to 64.33.3.150 (64.33.3.150), 30 hops max, 60 byte packets
(略)
9 218.100.9.53 (218.100.9.53) 10.949 ms 10.658 ms 10.647 ms
10 core-sw2-e-5.ntwk.ttn.ne.jp (202.127.81.22) 16.457 ms
core-sw1-e-5.ntwk.ttn.ne.jp (202.127.81.10) 16.535 ms 16.526 ms
11 ftth-sw1-po-2.ntwk.ttn.ne.jp (202.127.81.30) 25.875 ms 26.144 ms
ftth-sw1-po-1.ntwk.ttn.ne.jp (202.127.81.26) 22.889 ms
12 olt1-la-1.ntwk.ttn.ne.jp (202.127.81.34) 20.911 ms 20.902 ms 37.585 ms
(略)
試しに、”nmap 202.127.81.34″を実行すると同様に 8008,8010 ポートが開いている。
$ nmap 202.127.81.34 Starting Nmap 7.80 ( https://nmap.org ) at 2022-12-06 14:35 JST Nmap scan report for olt1-la-1.ntwk.ttn.ne.jp (202.127.81.34) Host is up (0.0039s latency). Not shown: 995 filtered ports PORT STATE SERVICE 80/tcp open http 113/tcp closed ident 443/tcp open https 8008/tcp open http 8010/tcp open xmpp
そこで、このルータに同様に http://202.127.81.34:8008 にブラウザでアクセスしても最初のような、FortiGuard の表示となった。ということで、8008,8010 は、FortiGuard で WAF(Web Application firewall) が設定されているのが原因と思われる。
WebFilter 廃止になるのかな?
ただ、丹南ケーブルにて「安心インターネットサービス停止」のアナウンスが出ている。会員向けのProxyサーバの運用停止の案内だけど、これも影響するのかな。どちらにしろ、2023/1/15(日)になれば分かるかな。
Edgerouter-X が寿命?
VPNルータとして導入した Edgerouter-X だけど、最近何日かおきにトラブル。
現状は、実質 SW-HUB 状態の使い方だけど、HUB 機能は動いているものの、管理画面などの Web 機能に繋がらない。電源を入れなおせば復活する。当初導入は VPN 機能だったけど、ルータを交換したら L2TP 使えるし、ただの HUB での利用なら Giga HUB の方が安いし、メンテナンスも不要だし。
(2022-11-19)
ということで、Amazonでポチった安い 5ポート Giga HUB に入れ替え。あんど、munin や nagios4 での Edgerouter の監視を外す。
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
Google 検索
