2022/04/02(土)フィッシングメール・アホメール(?)その4

2022/04/02 4:16 はんかくさい
今回は、雰囲気をご理解いただくために、画像で掲載します:
20220402.png


見るからに日本で使われるフォントではないし、Amazon のメールアドレスではない。
しかも「このメールは次のアドレス宛に送信されました:」の部分で表示するメールアドレスは、全く身覚えが無い他人のメールアドレス。
これは、フィッシングメールであることが、すぐ判りますね。こんなのが時折すり抜けて来るんです。。
だからといって、「メールアドレスが違う!」とか、*絶対に*返信してはいけません。
↑ これ重要です。返信しただけで、更なる数のフィッシングメールが送りつけられる可能性の方が高くなります。
  「返信しないでください」と書いてあるが、実際は返信出来てしまうのがフィッシングメールのアドレスなのです。

当然、その度に spam メールであることを、メールサーバに教え込む作業をしていますが、ウィルスのように変異するので、効果が現れるにはちょっと数をこなす必要があるかもです。

2022/04/02(土)フィッシングメール・アホメール(?)その3

2022/04/02 3:55 はんかくさい
Amazon を騙るフィッシングメールは昔から多いです。
以前は、それでも本物か偽者か識別はなんとか出来たんですが、これはちょっと難しい・・・

差出人:Amazon <no-reply@amazon.co.jp>
件名 :Amazon.co.jp にご登録のアカウント(名前、パスワード、その他個人情報)
Amazonアカウントのエラーまたは不完全なプロファイルにより、システムは残念ながら高リスクのアカウントに設定されており、アカウントと対応する機能の権限が部分的にロックされています。
Amazonアカウントのロック解除にご協力ください。以下のリンクを使用して、Amazon Webサイトにアクセスし、情報を更新してください。


支払い情報を更新する
登録
※ 24時間経過してもこのメッセージに返信しない場合、アカウントのステータスは1週間後に放棄され、完全に削除されるように設定されます。


お客様のアカウントのセキュリティを強化するため、2段階認証を有効にすることをお勧めします。 Amazon.co.jp では、個人情報を細心の注意を払って慎重に取り扱い、利用および共有させていただいています。本プライバシー規約(以下「本規約」といいます)は、本規約を参照するAmazonのウェブサイト、端末、製品、サービス、オンラインストア及び実店舗(以下「Amazonサービス」といいます。)を通じたAmazon(Amazon.com, Inc.を含め、Amazon.com Services LLC及びその国内外の関連会社をいいます。)による個人情報の取得及び取扱いに関する方針を説明するものです。Amazonサービスをご利用いただいた場合、本規約に同意していただいたものとみなされます。
こんな場合は、電子メールの生ソースを見て判断するのが確実だが、知識が要ります:
(悪用されないように、一部本物のメールアドレス部分は変更しています)
From - Fri Apr 1 04:47:30 2022
X-Account-Key: account1
X-UIDL: 000239e94a73fe99
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-Path: <arnazon-update@zimmed.shop>
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mx1.example.com
X-Spam-Level: ***
X-Spam-Status: No, score=3.3 required=4.0 tests=AMAZON_IMG_NOT_RCVD_AMZN,
BAYES_00,DKIM_ADSP_DISCARD,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,
SPF_HELO_PASS,SPF_PASS,URIBL_DBL_PHISH,URIBL_PH_SURBL autolearn=no
autolearn_force=no version=3.4.6
Delivered-To: noname@example.com
Received: from zimmed.shop (zimmed.shop [113.31.112.72])
by pmx1.admin-plus.net (Postfix) with ESMTP id 08A0528F2AA6
for <noname@example.com>; Fri, 1 Apr 2022 04:46:55 +0900 (JST)
Received: from zc (unknown [43.249.207.181])
by zimmed.shop (Postfix) with ESMTPA id 7AAB632002B9
for <noname@example.com>; Fri, 1 Apr 2022 03:46:45 +0800 (CST)
DKIM-Filter: OpenDKIM Filter v2.11.0 zimmed.shop 7AAB632002B9
Sender: arnazon-update@zimmed.shop
Message-ID: <20220401034714546202@zimmed.shop>
From: "Amazon" <no-reply@amazon.co.jp>
To: <noname@example.com>
Subject: =?utf-8?B?QW1hem9uLmNvLmpwIOOBq+OBlOeZu+mMsuOBruOCouOCqw==?=
=?utf-8?B?44Km44Oz44OI77yI5ZCN5YmN44CB44OR44K544Ov44O844OJ44CB44Gd44Gu5LuW5YCL5Lq65oOF5aCx?=
=?utf-8?B?77yJIA==?=
Date: Fri, 1 Apr 2022 03:47:01 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0209_01EC2A56.1A560F00"
X-mailer: Hyajcpyad 2
X-Virus-Scanned: clamav-milter 0.104.1 at mx1.basekernel.ne.jp
X-Virus-Status: Clean
X-Antivirus: Avast (VPS 220331-10, 2022/3/31), Inbound message
X-Antivirus-Status: Clean
上記で、赤字の部分が amazon.co.jp でないため、詐称の可能性が高い。
実は、電子メールは、構造的に封書なので、ちょっと細工すると差し出し元を詐称出来てしまうのです。

封書は「封筒」の中に「信書」を入れますね。電子メールもこれと全く同じ構造なのです。
なので From が2つあるのです。
「封筒」は「エンベロープ」と言います。電子メールの世界でも「エンベロープ」があります。
メールサーバは、発信については「エンベローブ」の内容だけを見て、配送します。
一方で、普段お使いの電子メール送受信ソフトウェア(一般的にMUAと称す)は、受信処理の際、エンベローブではなく、本文の初めの方にくっついてくる情報(ヘッダと称す)を参照して表示します。
(そして、エンベローブの大部分は表示されない)

つまり、エンベローブの From は配送さえ出来ればなんでもよく、故に本文ヘッダの From: は、詐称出来てしまうのです。
ですが、本文ヘッダの一部はメールサーバが付加していくので、基本的に中継サーバや受信端で魔改造でもしない限り、メールサーバが付加する項目の詐称は困難です。ここに辛うじて判断材料が残っている形です。

2022/04/02(土)フィッシングメール・アホメール(?)その2

2022/04/02 3:17 はんかくさい
差出人:ETC利用照会サービス <etc-meisai@mmananes.com>
件名 :【ETCサービスは】【通知書】番号:E06283625089
ETCサービスは無効になりました。
当社からクレジットカード会社に問い合わせたところ、
弊社にご登録されているご情報と、カード会社が保有しております情報が相違しており
ご注文者様ご本人名義のカードであることの確認が取れませんでした。

弊社では不正利用防止の観点から、相違が認められご本人様名義のカードであることの確認が取れないまま
カード払いでご注文の継続を行うことができません。

→ご認証はこちらから

ご不便とご心配をおかけしまして誠に申し訳ございませんが、
何とぞご理解賜りたくお願い申しあげます。

※このメールは送信専用です。
 このアドレスに送信いただいても返信いたしかねますので、あらかじめご了承願います。
※本メールに心当たりがない場合は、速やかに削除お願いいたします。

なお、ご不明な点につきましては、お手数ですが、
ETC利用照会サービス事務局にお問い合わせください。

■ETC利用照会サービス事務局
 年中無休 9:00~18:00
 ナビダイヤル 0570-001069
 (ナビダイヤルがご利用いただけないお客さま 045-477-1262)
電話番号は本物。ドメインは見るからに違っている。 .cn な場合もある。
そして、本物の「ETC利用照会サービス事務局」から、注意喚起がなされています。
https://www.etc-meisai.jp/caution/caution_phishing.html (ページリンクは、2022/04/02 現在)

2022/04/02(土)フィッシングメール・アホメール(?)その1

2022/04/02 3:03 はんかくさい
弊社のメールサーバには、メールアドレス毎に個別機能する spam メールフィルタなるものを実装しているが、
最近、フィルタをすり抜けてくる spam な電子メールが散見され、中には本物と見分けがつきにくいものもある。

また、時々アホなメールや新しい型の変なメールなんかも来るようになったので、
注意喚起も兼ねて、内容を晒していこうと思います。このシリーズで紹介するのと同じような電子メールには、
決して対応しないようにしてください。

また、安全対策のため、HTML 形式ではなく、テキスト形式で表示します。予めご了承ください。

差出人:MyJCOM <JCOM-net-account@xaepebk.cn>
件名 :【J:COMカード】重要なお知らせ
32px
ご請求書が未払いの状態です

お支払い期日を過ぎています。

お支払いが遅れると、サービス停止の可能性。お早めにお支払いください。

支払い方法は無効だ

現在、お支払い方法が無効のため、サービスを一時停止する可能性がございます。チェックしてください

お支払い期限

2022年04月2日

支払い方法を追加する <https://www.jcom.nzrtjvc.cn/>


アプリをお持ちでない方は、
こちら <https://www.jcom.nzrtjvc.cn/>からお支払いください。

help-icon
お困りの方はヘルプ <https://www.jcom.nzrtjvc.cn/>をご確認ください

※このメールはお知らせ専用のアドレスより配信しております。このメールに直接返信し
てのお問い合わせにはご対応いたしかねますのでご了承ください。

© J:COM Inc.
.cn は、中華国のドメイン。この手の半分は、メールアドレスの最後が .cn だったりします。
事業する側にとっては安全対策上、常識の範疇ですが、ご存じでなかった方は、事業者の負担軽減ということで、無視して削除するなどの対応をしていただけると有難いです。

2022/03/31(木)postgresql にて、任意の select 文を csv 出力する

自分メモその2。ざっくりと、こんな感じ。
# psql -h サーバFQDN DB名 -U ユーザ名 -c "《任意のselect 文》;" -A -F , > output.csv
サーバFQDN は、ホスト名のほか、IPアドレスでも可能です。自ホストの場合は localhost と指定します。
DB名・ユーザ名は、そのままですね。
任意のselect文は、全体をダブルクォーテーションで括ります。終端には必ずセミコロン「;」を付けます。
select 文中に括弧やダブルクォーテーションが入る場合、エスケープが必要かもしれません。

 -A は、「桁揃えなしのテーブル出力」で、これを指定しないと、CSV 出力の際に余計なスペース等が入ってしまいます。
 -F は、「桁揃えなし出力時のフィールド区切り文字」で、デフォルトの区切り文字は "|" なので、CSV 出力の場合は、必ずカンマ「,」を指定します。

あとは、リダイレクトで出力ファイル名の指定。
文字コードは、DBの文字コードが適用されます。

2022/03/31(木)FreeBSD12/FreeBSD13 にて Let's Encrypt を使う(manual 編)

2022/03/31 2:18 サーバ運営・管理
いつもの自分メモ。地味にいつも嵌るので、、
FreeBSD Ports においては、 securiry/py-certbot をインストールするのは、従来と同じです。

Webサーバ自体が Firewall 内部で、ルータのIPマスカレードや、NATで外部から直接アクセスできない(Firewall の内と外でIPアドレスが違うと Let's Encrypt のツールでは自動取得・自動更新は難しいと思う)ネットワーク構成の場合、--manual オプションで使うのが当方の環境では最も確実です。
但し、アクセス制限をかけたり、リダイレクトしている場合は、それらを全て一旦全て解除し、出来る限りフリーアクセスの状態にしないと、HTTPステータスが 401 になったり、 301 になったりで上手くいかない。

他に、もっと効率的な手法があればいいのですが、、
# certbot certonly --manual --preferred-challenges http-01 -d host.example.com
のように入力すると、
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for host.example.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Create a file containing just this data:

yPcvsXmaN4k_2rk-ZxFKmbp0EwgrmlgLflIPa5EsYtU.xGBBOehwohStkrITKI6h3ng8cYkGYXMtZXQnLK8SHUA

And make it available on your web server at this URL:

http://host.example.com/.well-known/acme-challenge/yPcvsXmaN4k_2rk-ZxFKmbp0EwgrmlgLflIPa5EsYtU

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
のように表示されます。

外部から、
http://host.example.com/.well-known/acme-challenge/yPcvsXmaN4k_2rk-ZxFKmbp0EwgrmlgLflIPa5EsYtU

でアクセス出来るよう、ファイルの中身が
yPcvsXmaN4k_2rk-ZxFKmbp0EwgrmlgLflIPa5EsYtU.xGBBOehwohStkrITKI6h3ng8cYkGYXMtZXQnLK8SHUA

であるコンテンツをサーバ上に設置するように。。 という意味のメッセージの模様:

上手くいくと、
Successfully received certificate.
Certificate is saved at: /usr/local/etc/letsencrypt/live/host.example.com/fullchain.pem
Key is saved at: /usr/local/etc/letsencrypt/live/host.example.com/privkey.pem
This certificate expires on 2022-06-28.
These files will be updated when the certificate renews.

NEXT STEPS:
- This certificate will not be renewed automatically. Autorenewal of --manual certificates requires the use of an authentication hook script (--manual-auth-hook) but one was not provided. To renew this certificate, repeat this same certbot command before the certificate's expiry date.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
* Donating to EFF: https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
のようなメッセ―ジが表示されます。
得られた公開鍵・秘密鍵を実際に運用するサーバに適切にセットアップすることで、公開鍵・秘密鍵のアップデート、新規登録が共に可能です。

尚、有効期間は 90日だが、一度同じホスト(FQDN)名で、Let's Encrypt のサーバ証明書を作ると、デフォルトでは、前回の有効期限から90日となる模様。

2022/02/10(木)Windows 11 にしてみた

一度、インストール失敗したこともあり、半日かかりました。
アップデートの際は、必ずアンチウィルスの動作を無効にしましょう。これがアップデートのときに問題を引き起こします。(下図参照)
20220210.png

これは、当方で有償ライセンスで使用している Avast! の例です。
ハッキリ言って表現が悪いのですが「永久に」というよりは、「再度有効にするまで無効にする」という意味です。

結論から言うと、「今、慌ててやる必要はない」です。
20220210.jpg


GUI インタフェースはハッキリ言うと「改悪」そのものと言って良い。

改悪の極みはエクスプローラで、
Windows 10 のエクスプローラーだと、右クリックで選択出来たものが、
Windows 11 のエクスプローラでは、「その他の機能」に殆どが移行し、例えば「名前の変更」なんかは、
右クリック1回、「その他の機能」の左クリック1回、ここで始めて「名前の変更」の左クリック。
で、合計3回させられます。

タスクトレイに日時が表示されるのは変わらないですが、勘違いなセキュリティ対策なのか、
タスクトレイの改造が外部ソフトウェアで出来なくなった上に、秒の表示が出来ません。
更に、文字の大きさが小さい。
こうするなら、タスクトレイ改造相当のカスタマイズ機能を標準でサポートするべきです。

唯一の改善点(?)は、同じディスプレイ上で明確に仮想画面を持てるようになったことくらいでしょうか。
「デスクトップ1」「デスクトップ2」というのがそれ。追加できるみたいです。

これ見て思ったのは、「MacOS のパクリ?」というところ。
でも、これは便利です。
まぁ BSD系Unix とかでは昔から普通にあった機能ですけどね。CUI環境でも8画面程度の仮想画面を持っています。

2021/12/15(水)Apache Log4j 使っていません。

2021/12/15 5:53 サーバ運営・管理
ちまたでは、大騒ぎになっていますが・・・
弊社では、このソフトウェアは使用していません。

問題となった機能を、デフォルトで無効・削除したバージョン 2.16.0 が昨日公開されたようです。

[2021/12/21 追記]
さらに、脆弱性対策漏れがあったとして、バージョン 2.17.0 が 12/17 に公開されたようです。

2021/11/26(金)clamAV は 0.104 から構築方法が変わっている模様・・・

2021/11/26 6:51 サーバ運営・管理
いつものように、ソースコードからの構築を行うべく、
# ./configure --enable-experimental --with-iconv --enable-milter
とか、やって構築しようとしたらエラーを吐くので、ちょっと見て見たら単純に configure スクリプトが無い。
更に調べたら、cmake を使う構築方法に変わったとのこと。

今まで、機会が無くやったことが無いので面食らいました。。。
clamAV 0.104 以降で cmake で構築する場合、先ず、
# cd clamav-0.104.1
# mkdir build
# cd build
# cmake .. -D ENABLE_EXPERIMENTAL=NO -D ENABLE_JSON_SHAREDOFF
とか実行して、まさに configure と同じ役割で構築環境を作り出すのですが、依存するモジュールやライブラリが結構あって、存在しないと、 cmake がエラーを吐いて終了します。最初は、これに面食らいます。

不足があるかもしれませんが、事前に下記の依存モジュールやライブラリが必須のようです:
 ・pcre-8.45   (Ports から カテゴリ:devel)
 ・pcre2-10.39  (Ports から カテゴリ:devel)
 ・autoconf-2.69_3(Ports から カテゴリ:devel)
 ・cmake-3.21.4_1 (Ports から カテゴリ:devel)
 ・libltdl-2.4.6 (Ports から カテゴリ:devel)
 ・libtool-2.4.6_1(Ports から カテゴリ:devel)
 ・libxml2-2.9.12 (Ports から カテゴリ:textproc)
 ・db5-5.3.28_7  (Ports から カテゴリ:databases)  ※ これは BerkeleyDB 5.3.28 です
 ・curl-7.80.0  (Ports から カテゴリ:ftp)
 ・json-c-0.15_1 (Ports から カテゴリ:devel)
 ・jsoncpp-1.9.5 (Ports から カテゴリ:devel)
 ・check-0.15.2  (Ports から カテゴリ:devel)
 ・ncurses-6.3  (Ports から カテゴリ:devel)
上手くいったら、
# cmake --build .
# cmake --build . --target install
とやると、ソースコードからインストールできるようです。
(ドットを省略しないことに注意を)

2021/08/28(土)FreeBSD13 からのソースコードによるOS更新は、gitup が最も手軽

2021/08/28 5:00 サーバ運営・管理
先日、FreeBSD のソースコード管理が subversion から git に変更になった旨を『厄介だ』と紹介したのですが・・・
その厄介さを払拭するメンテナンスツールが既に用意されていたのでした。

この手の情報が数えるほどしかなく、日本語による情報を当方が見つけたのはここだけです → KNCN weblog /usr/src を gitup で取得する
#見落としの可能性もあるのでご容赦を・・

これは、OSの標準コマンドではないので、出来る限り最新のports から、
# cd /usr/ports/net/gitup
# make install
# make clean
# rehash
とかやって、インストールします。インストール後、 /usr/local/etc/gitup.conf を以下のように適宜編集します:
(一部抜粋)
# $FreeBSD$
#
# Default configuration options for gitup.conf.
{
        "defaults" : {
                "host"           : "git.freebsd.org",
                "port"           : 443,
#               "proxy_host"     : "",
#               "proxy_port"     : 0,
#               "proxy_username" : "",
#               "proxy_password" : "",
#               "source_address" : "",
                "low_memory"     : false,
                "display_depth"  : 0,
                "verbosity"      : 1,
                "work_directory" : "/var/db/gitup",
        },

        "ports" : {
                "repository_path"  : "/ports.git",
                "branch"           : "main",
                "target_directory" : "/usr/ports",
                "ignores"          : [
                        "distfiles",
                        "packages",
                ],
        },

        "release" : {
                "repository_path"  : "/src.git",
                "branch"           : "releng/13.0",
                "target_directory" : "/usr/src",
                "ignores"          : [
                        "sys/amd64/conf",
                        "sys/arm64/conf",
                        "sys/i386/conf",
                        "sys/pc98/conf",
                        "sys/powerpc/conf",
                        "sys/riscv/conf",
                        "sys/sparc64/conf",
                ]
        },

        "stable" : {
                "repository_path"  : "/src.git",
                "branch"           : "stable/13",
                "target_directory" : "/usr/src",
                "ignores"          : [
                        "sys/amd64/conf",
                        "sys/arm64/conf",
                        "sys/i386/conf",
                        "sys/pc98/conf",
                        "sys/powerpc/conf",
                        "sys/riscv/conf",
                        "sys/sparc64/conf",
                ]
        },
見ての通り、JSON 形式な設定ファイル。
初めてだと JSON 形式に面食らうんですが、割と直感的に変更できます。
gitup.conf を編集後、
# gitup release
とやれば、今まで同様の /usr/src 配下へのソースコード取得、
今後は、ports ツリーもgit 管理になるらしいので、そうなった際は、
# gitup ports
で、従来のように /usr/ports 配下への取得が出来るようです。
ただ、ports ツリーの取得は、前処理・後処理があるので、portsnap のほうが使い勝手は良いです。
〔参考〕portsnap が更新しない場合の対処法

尚、新規取得時も更新時も同じコマンドラインで出来ます。