Category: Linux

Debian実マシンをぶっ壊す

昨夜，なんにもしてないのにDebianの実マシンを壊してしまいました．

Debianの新しい安定リリースbookwormが6月にリリースされていたのに今頃気が付き，まずは仮想マシンからupgradeしてみました．Debianの仮想マシンはAMD64版とx86 32bit版の2つを飼っていて，特になんにも考えず，/etc/apt/sources.list内のbullseyeをbookwormに書き換えて，apt update; apt upgrade; apt full-upgradeや，apt autoclean; apt autoremoveをしたらbookwormになりました．

楽勝だったので実マシンもupgradeすることにしましたが，かけがえのない実マシンなのでより慎重にとsources.listを書き換える前にapt update; apt upgrade; apt autoclean; apt autoremoveをしてから，sources.listを書き換え，仮想マシンと同じ手順を施しましたが，ぶっ壊れて再起動しなくなりました．updateの過程でファイル関係のエラーメッセージが出ていたようですが，気にせずやったのが良くなかったようで，Manjaroを起動して，Debianのrootパーティションをfsckすると，修復不能と出ました😓

これはいったんパーティションをフォーマットし直すしかないので，バックアップを確認すると，ちょうど一年前の7月のものが最新でした😓 それでも動かないのではしょうがないので，パーティションをフォーマットしてからrsyncで1年前のバックアップをコピーバックしました．

しかし，grubの設定の仕方をすっかり忘れてしまい，昨夜のうちには起動できませんでした．

自分の記録を見ると，インストール用DVDイメージからレスキューモードでgrubの設定をするようです．一年前のDVDイメージを探すのも面倒なので，bookwormにupgradeできた仮想マシンのディスクイメージをDebianのパーティションにコピーして， 最新のDVDイメージからrescueすることにします．この仮想マシンはもともと実マシンから移転したものです．

まあバックアップの意味もあって仮想マシンを飼っているわけです．ただし，仮想マシンの仮想ディスクからコピーバックするのはかなり時間がかかります．今回実マシンの復元に成功したら，今後はまめにバックアップを取ることにします．

なんにもしてないのに壊れるわけはなく，厳密に言えば，「何も悪いことはしてないのに…」です．世の中に蔓延する「何もしてないのに壊れた」も，責任逃れのいいわけです．
一年前のバックアップがその時点でup-to-dateな保証もないし😓

突如としてMTAへの攻撃が止む

何年か続いていたMail Transfer Agent (MTA)への攻撃が7月2日をもって止みました．

2年前からの不正なアクセスのIPアドレスを全部iptablesで “DROP” しています．その数は7000余りです．

たぶんまた何か月か経ったら新しいIPアドレス（＝ボット）を使って攻撃してくるとは思いますが．

ATOKの使用終了を検討中 (2)

今もGoogle日本語入力の評価を続けています．まだ十分に自分ナイズされていないから，自分では絶対に使わない言葉が第1候補に出てきたりして途惑うことが多いです．これは使い込んでいけば解消されるとは思いますが，今のところ確かなことは解りません．

それから，あいかわらず連文節変換がだめです．こんな日本語ないだろうということをしばしばやらかしてくれます．

それと細かいことですが，個人的には文書中やタイトルに付ける日付は， “2023年6月14日(水)” の型式にしていまして，ATOKでは「きょう」，「きのう」，「おととい」，「あす」，「あさって」等と入力して “変換” すると，その形式が第1の候補に出ます．

一方のGoogle日本語入力では例えば「きょう(変換)」とすると， “2023年6月14日” は出ますが，かならず第6候補で，何回入力しても第1候補に上がってきません．また，曜日を思い出して「すい(変換)」として追加しなければなりません．それも後ろから2番目の候補です．

曜日を思い出すのにひとタイミング遅れますが，認知症予防になって良いのかも知れません．

また，かつて何度か経験したのですが，評判のよい変換ソフトを試してみたものの，かな入力では非常に使いにくい，ということがありました．たぶん，かな入力はいちおう付けてみたものの，開発した会社にかな入力を実用的に使っている人がいなくて評価できなかったのでしょう．今日そんなことがあるのかどうか解りませんが，新しい日本語入力システムを使う際の最大の懸念材料です．

その辺ATOKはかな入力に対して全く問題ありませんし，Google日本語入力も今のところかな入力に関連した問題はないです．

もうしばらくGoogle日本語入力を使ってみます．

スペースキー押し下げ．
候補順については自分ナイズできているからと思います．
全く使い物にならないレベルのものもありました．
だから長年使っているわけです．

ATOKの使用終了を検討中

ATOKは，現役の頃から，というか，1980年代半ばからJustSystemのワープロ一太郎の日本語入力として，公私で使ってきました．たぶん，今使っているユーザー辞書は1990年頃からのものに，継ぎ足し継ぎ足ししていると思います．ですからときどきおかしな変換をやらかしてくれますが，全般的には満足のいくものです．

現在はATOK PassportというmacOS, Windows, iOSおよびAndroidで同時に10台までインストール可能というサブスクシステムを利用しています．

しかし，あらゆる物価の上がる今日，リストラの対象に考えています．Linuxのほうではかなり前からMozcを使ってきていて，特に大きな不具合は感じていません．

MozcとGoogle日本語入力は2010年に分かれたそうでもう13年経ちますからその後MozcがGoogle日本語入力とともに成長したのかどちらかが置いていかれたのか，それぞれ別の方向に進化したのか解りません．また，Google日本語入力がはたしてユーザーにとってというか，筆者にとって使いよい方向に進化しているのかどうかもある程度使い込んでみないと解らないでしょう．

ということで，しばらくGoogle日本語入力を使用してみて，まあ，いいだろうということであれば，ATOK Passportの契約を終了してアンインストールすることにします．

iOSとAndroidにはインストールしてあるものの実質的に使用していません．

執拗なメール攻撃者との戦い

ここ数年でしょうか，SMTPでメールを送り込もうという試みが繰り返されています．認証の設定の不備を発見してSPAMの踏み台にしようとしているのではないかと推測しています．

sendmailのログは1年間保存しています．そこから， “AUTH failure” または “Access denied”を含む行のIPアドレスを集めました．これはsed, uniq, sortなどのunix/linuxに標準的についてくるツールでできます．

こちらのMTAに対してどこの馬の骨か解らないIPアドレスからメールを送り込もうと接続してきたら，こちらからは「認証が必要だよ」と返すので，なんか適当なuser IDとパスワードを送ってきます．ちまたに出回っているID/passwordの組み合わせを使った辞書攻撃と思われますが，それで破られることはないので結果として “AUTH failure”になるわけです．

まれに相手をまともなMTAと認めるのか，UserID@当サイトドメイン の型式のメールをまとめて100くらい送り込んでこようとします．そのUserIDがタコ過ぎて当サイトでは100% “User unknown”となります．このケースでは，”User unknown”の行に相手先のIPアドレスが含まれていないので，その処理のIDを抽出して，そのIDとIPアドレスを含む別の行からIPアドレスを取り出す，という感じで一手間余計にかかります．ここは，Perlスクリプトを書きました．

そうして過去1年と今月3週間分のログから不正な接続元のIPアドレスを抽出したところ，ユニークなIPアドレスが6,788個ありました．

せっかく抽出したのだからiptalbes で全てのIPアドレスを “DROP”するように設定してみました．当サイト始まって以来の巨大なテーブルとなりました．

しかし，全く効果がありません．次から次へと新しいIPアドレスで不正アクセスを試みてきます．

いくら大量のBOTを要しているにしてもその数は有限なわけですが，1年分くらいのデータでは防ぐことはできないようです．

次から次へと新しいIPアドレスで不正アクセスしてくるのですが，繰り返し使われるIPアドレスもあります．この1年で10万回以上不正アクセスしてきたIPアドレスが2つあり，それぞれモスクワと香港の会社が管理するIPアドレスです．第3位も香港で約5万回です．この3つは特に悪質なので曝します．

62.233.50.137
91.240.118.159
176.113.115.117

6,788個のうち100回以上不正アクセスしてきたIPアドレスは55個です．残りは大半が1〜2回なので，そのBOTの規模は計り知れません．

この100回以上攻めてきた55個は，従来の/24のサブネットでブロックするように設定しました（残りの6,733個は開放しました😓）．

今後の方針としてはときどき見直して，一定の期間に大量の不正アクセスをしてきたサイトのIPアドレスをiptablesで “DROP” するよう追加していきます．また逆に，不正アクセスが成功した事例はないか解析し，今後も監視していきます．

さらに，2018年からのbackupもあります．
全く別のIPアドレスからほぼ同時に同じUserIDが送られてきます．BOTを操っているとあたまでは解りますが，なんとも不気味です．
どういう基準か解りません😓
たぶんQueue ID．
2023年5月．
ちなみに，Perlスクリプトで抽出したMTAとしての接続に成功したIPアドレスは，この1か月間に208個（それ以前の12か月間はゼロ）ありますが，2回使用されたIPアドレスが7個あるだけで残りは全部ユニークです😱

サブネットなしの個々のIPアドレスを “DROP”．
多少，時間あたりの不正接続の頻度が減ったような感じはあります．