Network」カテゴリーアーカイブ

システム

最近の投稿

アーカイブ

カテゴリー

wordpressでWP_SITEURL,WP_HOMEでプロトコル指定を省略できないか?

ケーブルテレビのSTBのブラウザで、自宅サーバに接続させようとすると接続が拒否られる。letsencryptのroot証明を受け付けてくれないのが原因。一部の動作確認ページをブラウザから接続させたいと思うけど、自宅サーバはWordPressなのでhttpsで WP_HOME, WP_SITEURL がしてあるために、強制的に https になってしまう。

試しに、wp-config.php で “https://hostname” でなく、”//hostname” とか “/” を指定してみた。

“/” だと、ページが上手く表示されない。(cssなどがうまく読み込めていない様子)

“//hostname” だと、ページは表示できるけど、wp-login.php でのログインが上手くいかない。(多要素認証のプラグインが影響しているのかもしれない)

職場からの接続をFWの拒否リストに入れてた…

職場のWordPressの多要素認証対策で、自宅サーバにワンタイムパスワードを送っているんだけど、職場で自宅サーバに imap 接続ができなくなっていた。

症状としては、Thunderbird で自宅サーバ宛のメールが読めなくなった。色々と確認する中で、”telnet-ssl -z ssl 自宅サーバ imaps” を試すと、接続ができない。自宅だと問題なし。色々と疑ってかかったら、結論は、自宅サーバの FireWall に、職場からのアクセス拒否のルールが加えられていた。

んで、このアクセス拒否ルールが加えられた原因は、職場からのメールで “Sender address rejected: Domain not found” の log が残るから。

自宅サーバでは、”Sender address rejected” の警告が続くとメール系の接続拒否リストに登録する処理が書いてある。

ということで、/etc/postfix/sender_restrictions で MX レコードの引けないメールサーバの受入れ設定を記述する。また、接続拒否リストの生成スクリプトで、職場のアドレスを登録しないように修正する。

車載WiFi AN-S092を導入

WiFiルータとして、Huawei E5785 を利用していたけど、出先で使う頻度も少ないしもっと活用ということで車載WiFi として活用。

ただし E5785 だと車載ルータとしてつかう場合、車に乗るたびに起動操作が必要となるし、車を降りるとシャットダウンが必要。単純に車の電源に連動して使いたいということで車載用のWiFiルータを探し、KEIYO (あんまり聞かない日本企業) の AN-S092 を見つける。単純にUSB給電と共に起動し、バッテリーも無いので車を離れれば勝手に切れる。

早々に届いてセットアップ。でも、ちょっと手間取ったかな。

KEIYO AN-S092 のセットアップ

Huawei E5785 は、mineo(au) で使っていて、au VoLTE対応SIMで micro SIM サイズで使っていたけど、AN-S092 は nano SIM サイズなので、micro SIM の外枠を外してスロットに入れる。

設定が手間取ったのは、Web管理画面パスワードと SSID パスワードの設定。(説明書)

E5785 と同じ設定にしようとしたら、Web管理者画面に入れない。管理者パスワードに短いものを設定したけど、パスワードは8文字以上の制限があるようだ。ということで付属のリセットピンで工場出荷状態に初期化。

WiFiの設定も変更したけど、パスワードがはじかれる。WiFiパスワードは英数字のみ みたい…。管理者パスワードもWiFiパスワードも、設定後に使えないパスワードなら、登録時点で拒否してほしいな。ということで、再びリセットピンで工場出荷状態に初期化。英数字のみに気づくまでに、リセットピンでのリセット数回…..(x_x; スマホだとタイプミスも多いので PC で設定となった。

ということで、Amazon さんにレビューを書いておいた。設定さえちゃんとすれば便利なので高評価つけてるけど。

\

postfixの設定見直し

自宅サーバに届く迷惑メールの設定はそれなりにやってるつもりだけど、相変わらず届く。

迷惑メールの送信側も、DKIM や SPF といった迷惑メールに誤認されない対策をして送ってきている。そこで改めて postfix の設定を見直す。

RBLサイトの整理, 正引き・逆引きチェック

迷惑メール送信者のデータベース(RBL)の設定をしていたけど、all.rbl.jp, zen.spamhaus.org はサービスを停止しているようで、nslookup all.rbl.jp とかも失敗するし設定を削除。

Dynamic DNS サイトのような迷惑メールサイトからのメールを拒否するために、reject_unknown_reverse_client_hostname を設定していたけど、DKIM, SPF まで設定した迷惑メールサーバも多いので、設定をさらに厳しく reject_unknown_client_hostname に変更。

この設定を変更すると、逆引きと正引きが一致しない Dynamic DNS サイト(まさに自サイト tsaitoh.net はこの状態)からのメールを拒否することになる。しかし、迷惑メールの制限を強化したいし、身の回りの 逆引きと正引きが一致しない所からのメールは、smtpd_client_regexp で受信許可するようにしよう。

  ((( /etc/postfix/main.cf )))
  smtpd_client_restrictions = permit_mynetworks,
                  check_client_access regexp:/etc/postfix/smtpd_client_regexp
-                 reject_rbl_client all.rbl.jp,           # サービス停止
-                 reject_rbl_client zen.spamhaus.org,     # サービス停止
                  reject_rbl_client bl.spamcop.net,
-                 reject_unknown_reverse_client_hostname, # 逆引きだけをチェック
+                 reject_unknown_client_hostname,         # IP->name->IPのチェックあり
                permit

 

よく出来たフィッシングだな….

コロナ感染入院給付金の請求

日本生命からの自宅サーバのメアドに届いたメール。
自宅サーバに届くメールは、tsaitoh.net のドメイン管理者を狙う場合が多いので、自分で管理しているシステム以外から届くメールはほとんど悪意まみれのフィッシングメール。
メール先頭の送信相手欄に、本人名で始まっていないし、典型的な危ないメールだけど、出来がいいフィッシングだなぁ…
と思いフィルタ設定をしようと “Received:”タグを確認して、送信元の IP アドレスを確認したら本物だった。
改めて、日本生命さんのサイトに”メールのリンクを使わずに”ログインして確認してみたけど、しっかり自宅サーバのメアドも登録してあった。

<重要>【三井住友カード】お取引が決済できませんでした

こっちは、明らかにおかしいメール。でも送信IPは、googleusercontent.com 。まかりなりにもGoogle さん。でも、GoogleのVMサービスなので怪しいに違いはない。
通常は、FireWall で接続を完全ブロックするんだけど、Google さんだし、postfix の smtpd_client_restrictions にて接続制限を加える。
((( /etc/postfix/main.cf )))
smtpd_client_restrictions = permit_mynetworks,
          check_client_access regexp:/etc/postfix/smtpd_client_regexp
          :
((( /etc/postfix/smtpd_client_regexp )))
:
/\.googleusercontent.com$/	REJECT
{CAPTION}

リモート監視 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 の監視を外す。

Google 検索

My Google   Yahoo

Microsoft

ファンサイト