「Linux」カテゴリーアーカイブ

WordPress 5.9-ja

2022-01-26

WordPress 5.9 が新しく公開された様子。早々に、5.8.3→5.9 に更新を行う。

WordPress 5.9で実装されたフルサイト編集機能とは

PHP8.1に更新

2022-01-25

PHPのバージョンが、php7.4 をメインに使っていたけど、他のシステムで php7.4-common のモジュールの整合性が悪いので、php8.1 が出ているみたいなので、更新を行い、モジュールの相性をチェック。

((( インストールされているphp7.4系モジュールすべてを8.1でインストール )))
$ sudo aptitude install `dpkg -l | grep php7.4 | awk '{print $2}' | sed s/php7.4/php8.1/`
((( php8.1 を有効化 )))
$ sudo a2enmod php8.1
$ sudo a2dismod php7.4 # a2enmod php8.1 したら 7.4 消してくれると思ってたけど、残ってて
                       # systemctl restart apache2 してもエラーになるから悩んだ
((( apache2 を再起動 )))
$ sudo systemctl restart apache2

php7系からphp8系の移行による文法などの違いから、いくつかの自作 PHP プログラムが動かなくなってチョロチョロとプログラムを修正することになったけど。

改めて、プログラムを修正していると、「このプログラムなら、php7.4でも警告が出ていたはず」だけど、動いていたよなぁ…という修正点ばかり。(^_^;

ctgserver.net からのspam攻撃

2022-01-05

自宅サーバに 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

逆引きできないホストからのメール拒否

2021-12-16

自宅サーバのメールに、よくできた偽装メールが届く。

国別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

たぶん、踏み台となっているコマンドサーバ(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の深刻な脆弱性CVE-2021-44228についてまとめてみた

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

raspberry-pi のディスク容量増

2021-12-03

自宅内の色々な処理(温湿度モニタリング, 家電リモコン制御, homebridge)をさせている、Raspberry-Pi のディスク容量(8GB) の容量が不足してきた。大した処理はしていないし、不要なパッケージは消していたけど、homebridge などを使っていたりで、ギリギリになってきた。

Raspberry Pi の SDD交換&拡張

しかたがないので、32GB SDD を買ってきて、イメージファイルでコピーを行う。

((( 元のraspberry-piのイメージ吸い出し )))
$ sudo dd bs=4M if=/dev/sdd of=~/rpi.img
((( 新しいSDDにイメージを書き戻し )))
$ sudo dd bs=4M if=~/rpi.img of=/dev/sdd
((( 新しいSDDでraspberry-piを起動し ))) 
$ sudo raspi-config --expand-rootfs

bind9-dnsutils の nslookup でデバッグ表示

2021-11-08

ＤNS関連の動作確認で動かしている script が変な表示を出すようになっている。

原因を探していくと、/usr/bin/nslookup コマンドで、検索オプションをつけると、デバッグ出力が表示されているみたい。出力先も標準エラー出力となっている。10/25リリースの 9.17.19-1 の問題??

$ ls -l /usr/bin/nslooup
-rwxr-xr-x 1 root root 105120 10月 25 21:29 /usr/bin/nslookup
$ dpkg -l | grep bind9-dnsutils
ii bind9-dnsutils 1:9.17.19-1 
$ nslookup -type=a tsaitoh.net
main parsing tsaitoh.net
addlookup()
make_empty_lookup()
make_empty_lookup() = 0x7ffa08b49000->references = 1

どうも、脆弱性問題が発生した対応時の debug モード付がリリースされたんじゃないのか？

CTFページへのアクセスが増えてら

2021-11-06

メールの送受信量のモニタに、我が家としては多いメール受信。不正メール中継されたかと心配になったけど、自宅サーバで公開している CTF のページの参照だった。(正解/不正解の確認をメールで行ってるため)

来週末に、高専 K-SEC の情報セキュリティ人材育成の CTF 初心者向けの講習会+大会があるからだろうな。

Makefile に git は邪道?

2021-10-02

今まで、git はあんまり使ってこなかったが、講習会向けのファイル配布を github で簡単にできるようにするために、準備。

だけど、使い慣れていないからコマンドをいちいち確認。でも、add , commit , push の流れとかも、いちいちキー入力するのは面倒。IDE 環境使えば git コマンドも簡単なのかもしれないけど、オールドタイプは「make 使えばいいじゃん…」となってしまう。

git コマンド発行用 Makefile

以下の Makefile をプロジェクトに入れておけば、add, commit, push も “make”一発。

# git@example.com:foo/bar.git
GH_ID           = foo
GH_PROJECT      = bar
GH_SSH          = git@example.com:$(GH_ID)/$(GH_PROJECT).git

REPOSITORY      = origin
BRANCH          = master

DATE            := $(shell date +%Y/%m/%d)
HOSTNAME        := $(shell hostname)

all:            add commit push
                @echo $(GH_SSH)

add:;           git add -u
commit:;        git commit -m $(DATE)-$(HOSTNAME)
push:;          git push $(REPOSITORY) $(BRANCH)
pull:;          git pull $(REPOSITORY) $(BRANCH)

ただ、この設定しちゃうと、ちょっとファイルを触っただけでも “make” しちゃう癖がついているので commit を乱発することになるので、バージョン管理という意味では邪道かもしれない。、

dotfile を git で管理

以前、git を活用している人の記事で、リモートサーバを渡り歩く時、自分用の .bashrc などの dotfile をいちいちコピーするのは面倒だから、git を使う…というのがあったのでやってみる。

自宅サーバで、ssh 経由で更新できる git サーバ環境を構築
dotfile 用のフォルダを作り、対象の dotfile をコピー
git init で dotfile フォルダを管理対象に
$HOME/.bashrc など消して、ln -sf dotfile/bashrc .bashrc で参照するように設定。
前述 git コマンド発行用のMakefile なども準備して、make
あとは、新しいサーバを触る時には、”git clone git@…dotfile.git”

dovecot が動かない Let’s Encrypt 証明書問題

2021-10-01

数日前から、iphoneで自宅サーバのメールを見ると証明書が有効期限切れとのエラーが表示される。パソコンから Thunderbird で見るのには影響がないようだ。設定を色々と確認しても改善しない。

/var/log/mail.log を見ると、”SSL issue: alert number 46″ などのエラーメッセージが残っていて、dovecot と合わせてググると、Let’s Encrypt のルート証明書が、2021/09/30 で切れるといった記事が見つかり、これが影響しているようだ。

dovecot の設定の修正

さらに検索すると、ようやく対応記事が見つかった。ssl_cert の cert.pem を fullchain.pem に替えるだけ。こちらの資料を見ても、dovecot とか postfix なら fullchain.pem を使うような説明がある。

((( /etc/dovecot/conf.d/10-ssl.conf )))
# ssl_cert = </var/lib/dehydrated/certs/自宅サーバ名/cert.pem
ssl_cert = </var/lib/dehydrated/certs/自宅サーバ名/fullchain.pem

((( restart dovecot )))
$ sudo systemctl restart dovecot

postfix の設定の修正

同じような設定は postfix も使っていたはず。試しに、iphone でメールを出そうとすると、dovecot と同じような証明書が信用できないとのメッセージでメールが送れない。

((( /etc/postfix/main.conf )))
# smtpd_tls_cert_file=/var/lib/dehydrated/certs/自宅サーバ名/cert.pem
smtpd_tls_cert_file=/var/lib/dehydrated/certs/自宅サーバ名/fullchain.pem

((( restart postfix )))
$ sudo systemctl restart postfix

tsaitoh.net

「Linux」カテゴリーアーカイブ

システム

最近の投稿

アーカイブ

カテゴリー

WordPress 5.9-ja

PHP8.1に更新

ctgserver.net からのspam攻撃

逆引きできないホストからのメール拒否

Java Log4j 攻撃が自宅サーバにも来ている？

UserAgent で履歴確認

jndi:ldap の履歴確認

わちゃ、こりゃ悪意の塊…