ページ移動

エントリー

カテゴリー「Cubieboard」の検索結果は以下のとおりです。

フィッシングメール

8日から詐欺メール(フィッシングメール)が4日間連日で送られてきていた

12日に気付き対策を実施

フィッシングメールの内容

「Amazon」と「えきねっと」を偽って送られてきている

どちらも同一メールアドレスへ4日間で2種類入っていた

(Amazon:パターン1)

Mail_AMA001.png

(Amazon:パターン2)

Mail_AMA003.png

(えきねっと:パターン1)

Mail_EKI001.png

(えきねっと:パターン2)

Mail_EKI004.png

調べてみると去年(2022年)の7~8月から問題になっているようだ

Amazonのメールでも怪しいことは判ったが,えきねっとはそもそも利用していないので速攻で判明

原因について考察

メールアドレスがどこからか漏れて知られてしまった訳だが,拙者の場合メールサーバを自身で運用しているので,迷惑メール対策し易いよう目的別にメールアドレスを設定している

今回知られてしまったメールアドレスは以下のサイトでのみ登録,他では利用していないので漏れたのは以下のサイトからの可能性が高い

  • Amazon(昔の出店メーカを含む → 最近はAmazon経由で届いているので知られていないと思う)
  • Vastking
  • Aliexpress
  • aitendo
  • 千石電商
  • スイッチサイエンス
  • RSコンポーネンツ
  • ドスパラ
  • あきばお

(注)可能性が高いと思われる順にしてある

(2023.04.15追加)

13日(この記事書いた後の23時36分)に千石電商「せんごくネット通販」からメールがあり,2023.4.7に不正アクセスがあってメールアドレスが流出したとの事

とりあえず流出元が判明

対策

メールアドレスを変更するのが良いかと考えるが再登録に時間を要するので,今回は即効性を重視し「postfix」のメールフィルターで対応

送信元メールアドレス

Amazon.co.jp <support@service.cmpvs.cn>
Amazon.co.jp <support@service.qidianyou.cn>
Amazon.co.jp <wwdf@service.706821.cn>
Amazon.co.jp <support@service.agjy5.cn>
えきねっとサポートセンター <support@service.077y.cn>
えきねっとサポートセンター <qme@service.msxdnj.cn>
えきねっとサポートセンター <ljhwp@service.ghng6on.cn>
えきねっとサポートセンター <support@service.eoguqcy.cn>

/etc/postfix/main.cf に以下の行を追加

header_checks = regexp:/etc/postfix/header_checks

/etc/postfix/header_checks にフィルターを記述

/^From:.*@.*\.cn/ REJECT

チャイナドメインからは全て拒否にした

最近の例では「.ci」(コートジボワール)もあるそうだ

設定を反映

# service postfix reload
踏み台

メールのREJECTをログで確認しようと閲覧したところ,情けないことにメールサーバが踏み台にされていたことが判明(対応ミス)

connect from unknown[193.56.29.158]
connect from unknown[193.56.29.192]
connect from unknown[103.151.125.9]

至急対応するためこちらを参考にIPによる制限を設定

また上記のアドレスの接続拒否を実施

# iptables -I INPUT -s 193.56.29.158 -j DROP
# iptables -I INPUT -s 193.56.29.192 -j DROP
# iptables -I INPUT -s 103.151.125.9 -j DROP


# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- 103.151.125.9 anywhere
DROP all -- 193.56.29.192 anywhere
DROP all -- 193.56.29.158 anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
#

とりあえずログからは消えた

サーバメンテナンス

NOAA用ディレクトリ作成と内部ネットワークからのアクセス許可を設定

uptime-year.png

長期稼働中だったのでシステムリセットを実施

(本)サーバー異常(復旧後)

時空系状況

  • 先日2日の16時過ぎから(本)サーバーに異常が発生
  • 異常はBlogへのアクセスが遅延することから判り,ネットワーク障害でないことからサーバーへネットワーク経由でログインしようとしたが拒絶されたためサーバーの再起動を試みる
  • 再起動は虚しく失敗し(異常による再起動の繰り返し状態)ハードウェア障害の疑いが濃くなったためUPS電源断後HDDを取り外す
  • ArmbianシステムでUSB接続したHDDのバックアップを試みると,問題なくHDDアクセスができたため必要なデータの退避完了
  • HDDのrootファイルシステムがスーパーブロックを含め異常となっていたがfsckにて修復完了(データとしてのファイルシステムは問題なし,ただしDBはrootファイルシステムに位置する)
  • ログファイルを参照したところHDDインタフェースの問題のようなエラーがありHDDのRW異常は発生していないようだ
  • HDDを再接続し電源投入,起動を確認
  • Blog以外の問題はなしでBlogはDBのテーブル異常により表示不可能になっていた
  • 異常のあったテーブル(5個)はバックアップファイルからリストア
  • 概ね復旧(現在)

特記事項

  • 復旧のためArmbianサーバを利用したが最新であるDebian10でのMySQLのセットアップが簡単にできなかった(未対応や変更点が多い)
  • 最新のArmbian用のphpmyadminがない(面倒だがセットアップはできた)
  • DBテーブルのFrmエラーだったのでRAWファイルを変更して解決しようとしたが不可だった
  • 破壊されていた5個のテーブルがバックアップより更新が古かったおかげで復旧できた
  • 破壊されていたテーブルの実ファイルは念のためディスクのフリーリストに載らないよう削除しないで残している
  • freoがPHP7.3で動作不良
  • freoを1.21.0ベースに更新
  • 再発の可能性あり

サーバメンテナンス

間に何度かリスタートしているが,ほぼ一年ぶりにサーバメンテナンスとリスタート

uptime-year.png

subversionの復活とストリーミングサーバでも構築できないかと思い,まずはソフトウェアのupdateを行おうとしたらソースリスト取得でエラーが発生

すったもんだし調査したところ,どうやらcubianは終息のようだ

既にdebianは次世代へ移行しているしマイナーボードの辛いところではある

今後はCubieboardでの運用が上手くいった経験から省電力で高性能(十分な性能)な1ボードCPUでサーバの冗長化を踏まえた分散化を考え少しづつ移行させてみようかと思う

ページ移動

ユーティリティ

検索

エントリー検索フォーム
キーワード

過去ログ

Feed