リモート監視 nagios-nrpe を使ってみる
Raspberry-Pi で WiFi スキャンをさせたいけど、警告を出すために raspberry-pi 側に nagios4 のような本格的な監視システムを入れるのは資源のムダに思えたので、軽量な監視とすべく、リモート監視用の nagios-nrpe-server を使ってみた。
メインサーバ port=5666 リモート 監視プラグイン nagios4 ----> check_nrpe ------------> nrpe ----> check_root nagios-nrpe-plugin nagios-nrpe-server
nrpe は リモートの監視プラグインを check_nrpe と nagios-nrpe-server が経由して呼出してくれる。
リモートの監視側
nagios-nrpe-server をインストールして、監視サーバからの接続を許可する。インターネット経由で監視するなら、5666 ポートが通るようにファイアウォールの設定が必要。
((( 必要パッケージのインストール ))) $ sudo aptitude install nagios-nrpe-server ((( /etc/nagios/nrpe.cfg ))) # 監視サーバからの接続を許可 allowed_hosts=127.0.0.1,::1,192.168.xx.00/24 ~~~~~~~~~~~~~~~~~(追加) ((( /etc/nagios/nrpe.d/enabled.cfg ))) # 監視するためのチェック処理を登録。nrpe.cfg から nrpe.d/*.cfg に設定を移動 command[check_root]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p / command[check_load]=/usr/lib/nagios/plugins/check_load $ARG1$ ((( /etc/default/nagios-nrpe-server ))) # 自宅内のような閉じた中でSSLが不要の場合 NRPE_OPTS="-n" ((( nagios-nrpe-server を再起動 ))) $ sudo systemctl restart nagios-nrpe-server
メインの監視サーバ側
nrpe用のプラグインをインストールすると、/etc/nagios-plugins/config/check_nrpe.cfg や /usr/lib/nagios/plugins/check_nrpe を入れてくれる。
((( 監視側にnrpe用のプラグインを追加 ))) $ sudo aptitude install nagios-nrpe-plugin # nagios or icinga はインストール済み ((( nrpe の入ったリモートが呼び出せるか確認 ))) $ /usr/lib/nagios/plugins/check_nrpe -H リモート -c check_root DISK OK - free space: / 21321 MB (74% inode=86%);| /=7363MB;23944;26937;0;29930 ((( /etc/nagios-plugins/config/check_nrpe.cfg ))) # nagios/icingaなどのcommand設定の確認 # this command runs a program $ARG1$ with no arguments and enables SSL support define command { command_name check_nrpe command_line /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ } # this command runs a program $ARG1$ with no arguments and disables SSL support define command { command_name check_nrpe_nossl command_line /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -n } ((( nagios4 のサービス監視に check_nrpe を呼出す設定を追加 ))) define service{ use local-service host_name リモート service_description DISK check_command check_nrpe!check_root # check_command check_nrpe_nossl!check_root # SSLなしで設定した場合 } ((( nagios4 を再起動 ))) $ sudo systemctl restart nagios4
nagios4 で監視ができるようになったので、温湿度センサーや空気品質センサーの確認も nrpe 経由に変更してみた。
catt で chromecast を制御
chromecast を Linux から制御する python script の cast_url とかを使っていたけど、もっと使いやすくなった catt というものが公開されていた。
こちらで公開されていた DLNA サーバを検出する simple-dlna-browser も便利。
$ simple-dlna-browser -L http://192.168.xx.yy:zzzzz/dms/ddd.xml (TZ-HT3500) $ catt scan Scanning Chromecasts... 192.168.xx.yy - ベッドルーム - Google Inc. Google Nest Mini 192.168.xx.yy - リビングルーム - Google Inc. Chromecast 192.168.xx.yy - 居間(google home) - Google Inc. Google Home Mini $ catt -d リビングルーム cast https://www.youtube.com/watch?v=HBSC0RDuUlQ Casting remote file https://www.youtube.com/watch?v=HBSC0RDuUlQ... Playing "DREAMS COME TRUE - うれしい!たのしい!大好き!(from DWL2007 Live Ver.)" on "リビングルーム"... $ catt -d リビングルーム stop
なんちゃってIPv6でトラブル
自宅では、IPv6 でインターネットにつながらない状態の癖に、IPv6 の運用実験として色々な設定をしている。
しかし、最近繋がらないページなどが時々出ていて、どうも IPv6 サイトが原因だと予測はしていた。
今回、病院に入っていて家に不在の時に限って、ママがゲームサイトに繋がらないと文句を言ってきた。今までは動いていたのだが、ゲームサイトにも IPv6 化が進んでいる中で、ゲームサービスが IPv6対応になったんだろうな。おかげで IPv4 しかつながらないネットワーク環境のくせに、スマホがインターネットに IPv6 で繋ごうとするのが原因。
自宅では、IPv6 対応のために、DHCPサーバで IPv6 アドレス配布の設定をしていた。しかしこれが誤解のもと。実は IPv6 アドレスの自動設定機能の radvd を動かしていて、この設定は動いていないと思っていたが、実は radvd の設定が生きていた。
このため、DHCPv6の設定を消しても、radvd が相変わらずスマホに IPv6 ルータ情報をアナウンスするため、IPv6 で外に繋がらない状態となっていた。
ということで、/etc/radvd.conf を別名で残しつつ、”sudo aptitude purge radvd” で radvd の機能を止めた。
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 の最新が数日前に出ていたみたい。
過去の記事をみて、インストール。暑い時期だったのか、最初ファームのルータへのアップロードに失敗して心配だったけど、リトライしたら普通に成功。