カテゴリー: IT

マカフィーの記事を知ったのはカプコンのランサムウェアに関する報告があったから。
なので、カプコンのことにしか触れない

https://www.capcom.co.jp/ir/news/html/210413.html
北米にあった旧型VPNの脆弱性を突かれて不正侵入されたとのこと。
結局身代金は支払ってないから個人情報が流出した。
クレジットカードとかの情報が洩れないからいいだろうって判断だろうか。

SOCとEDRについては初耳だったので、上記サイトからメモ用に抜粋

SOC：Security Operation Centerの略。SOCサービスは、システムやネットワークを常時監視し、攻撃の検出・分析・対応などを支援する仕組みのこと

EDR：Endpoint Detection and Responseの略。ユーザが利用するパソコンやサーバなどの機器に不審な挙動を検知するソフトウェアを導入し、迅速な対応を支援する仕組みのこと

SOCについては下記のようなソフトウェアを導入して人が24時間関しているのかな
https://www.ntt-at.co.jp/product/soc/

EDRについては端末（PCやスマホ）などにウイルスが検出されたあとにすばやく端末をリカバリーを実施するもの
https://www.networld.co.jp/product/carbonblack/technical_guide/edr/

まず、winキー＋Rキーを押下。
[ファイル名を実行して実行]コマンドが表示されるので、
[mstsc]と入力。

リモートデスクトップ接続の画面が表示される。

#!/bin/bash
cat <<EOF | sendmail -i -t
From:test@test.work
To:test@test.work
Subject:test


test
EOF

上記の解説として、まず<<EOF　を用いてcat以下の内容を標準入力してほしいと記載。
そうすることで、下記のFromから始まる文章はコマンドと見なされずにすむ。
そのあとに、｜ でsendmailに引き渡しをして送信する。

上記で作成したファイルを引数にしてfor文で用いる。今回は10回同じメールを送信

for i in {1..10} ; do ./test.txt ; done

参考
Linux - bashワンライナーループ
Postfixをインストールしてメール送信してみる
知ると便利なヒアドキュメント

メール送信時に送信元のメールアドレスを変更することができる。
だから送信者を偽ってスパムメール等を送る人がいる。
SPF (Sender Policy Framework)とは、送信者がなりすましメールか検査するための仕組み。

検査をするためにDNSサーバーに「SPFレコード」を記載する。
SPFレコードには送信元としてメールを送ってもよいIPアドレスを記入する。

SPFレコードを記載後は、受信サーバーが送信元のDNSに問合せを行ってSPFレコードを確認する。
送信元のIPとSPFレコードのIPが一致したら受信を許可する。

SPFのレコードの例として下記のように、ipやドメインを記載する
"v=spf1 ip4:12.34.56.78 include:example.com -all"

と、一言でいえば送信元のIPに偽りがないか受信サーバーが受信前に
DNSに問合せをしてSPFレコードを確認するって話。

参考
送信ドメインを認証するためのSPFレコードに詳しくなろう
https://sendgrid.kke.co.jp/blog/?p=3509

ここ2週間くらいpostfixでずっとハマっていた話。前回の記事の続きになる。

環境：ubuntu20上でlxc内に作成したubuntu14

ハマっていた時の状況はThunderbirdでローカルのメール内の送受信には成功するけど、他のサーバーには受信ができても送信ができなく上記エラーが発生。
対象のエラー文は　/var/log/mail.log　で確認できる。

この問題を解消するには、/etc/postfix/main.cf　内の　mynetworks 　の設定が重要だった。
mynetworksについて検索すると、「ネットワークを許可したIPを記述するもの」と上位の検索にひっかかる。
例えば、
mynetworks = 127.0.0.0/8 [::1]/128,自分のサーバーのIP

ip a コマンドで確認して上記の通りに設定したけど、題名通りのエラーばかり。
port確認したり、自己証明書疑ったり、ansibleからpostfixをインストールしたからansibleの設定を見直したりと相当遠回りをした。

結果的には、自分が現在利用しているグローバルIPを許可するだけでよかった。
mynetworks = 利用中のグローバルIP

利用中のIPは、IPの確認くん　とかでわかる。
エラーログ的には確かにアクセスディナイだからそうなのかもしれないけど、
以前の別のVPSではそのような記述がなかったから試そうとしなかった。

でも今後メールを送信するとき、毎回postfixの設定に
利用中のグローバルIPを記載するのは不都合だな。

もっとスマートにできる方法を考えたい

参考
Postfixでメール送れたけど、宛先サーバに拒否られたｗ。
https://miff.blog.ss-blog.jp/2014-09-28-1

メールのヘッダーって一度に受け取る情報が多くて苦手。
例えば下記のようなもの

<hornertsukada@sikaku.com>:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: <〇@□.net>
Received: (qmail 31328 invoked from network); 2 Feb 2021 16:34:11 +0900
Received: from unknown (HELO ?118.47.236.▲?) (118.47.236.▲)
  by mail.val.co.jp with SMTP; 2 Feb 2021 16:34:11 +0900
Message-ID: <4B9A42455D939D5A8B53544C828C4B9A@ROR8C5ND8V>
From: <〇@□.net>
To: <hornertsukada@sikaku.com>

メールのヘッダーの読み解き方としては、下から上へと読み解いていくのが基本なので、
上記の場合、To,From,Message-ID....から読んでいく。
個人的に苦手なのが、Receivedから。
改めて調べてみたところ、Receivedは中継しているサーバーのホストやIPを指す。
上記の場合はIP。
さらに上のRecivedはqmail っていうMTAによって送信されていることを指している。
Return-Path、はメールのエラーが発生したときに通知されるメールアドレス。
上記の場合は、<〇@□.net>

ちなみの上記はエラーメールであり存在しないアカウントに送信したために送られてきた
Sorry, no mailbox here by that name. (#5.1.1)

このメールを例にしたのは最近、偽セクストーションメールが流行っているからだ。
https://twitter.com/ipa_anshin/status/1349590829225021440

適当なメールアドレスを入手してそれを送信元のメールにして、
送信先の相手に恐喝する内容が記載されている。

偽セクストーションメールついては基本的には無視していいんだけど、
アカウントを乗っ取られた可能性や中身に該当するものが場合不安になる人が多いんだそう。
でも大抵はヘッダーを見ると送信元のホストから詐称メールとわかる。

とはいえ、メールアカウントを知られた時点で詐称メールに利用されるのは勘弁だな。
企業とかの場合信用がさがるし。

参考
メールのヘッダ情報の読み方
https://blog.heteml.jp/?p=4897
しつこいウイルスメールへの対処法～Fromを詐称されたメールから送信元を特定
https://www.itmedia.co.jp/broadband/0302/27/lp23.html
あるスパム送信者の環境
https://inuz.hatenablog.com/entry/20060303/p1

ansibleでpostfixを立ち上げようとしても受信ができるが送信はできない。エラーはタイトルの通り。
色々調べてみてたどり着いたのは下記サイト。
ネームサーバー障害なのか。ansibleの使い方が悪かったのか。。。
4日ぐらい行き詰ってるのでメモ
https://fumiyas.github.io/2014/12/19/users-in-nss-failure.postfix-advent-calendar.html

マウントしているディスクについては　df -Tで確認できるけど
マウントされていないディスクについて確認するのが困った。

parted -lで対象のディスクを見る方法もあるが、
blkidコマンドで確認しやすいと思う。

blkid 対象のディスク
例
root@vds05:~# blkid /dev/sda1
/dev/sda1: UUID="a3867239-aa78-4444-8fa2-e64c90c25898" TYPE="ext2"

今まで自分はネームサーバーの存在意義についてよくわからなかった。
ネームサーバーとは一般的にDNSのことを指し、DNSとはドメインとIPを結び付けるものといわれている。
なので、DNSとは、ドメイン＝IPだと思っていて、Aレコード＝DNSと考えていたからだ。
もちろんドメインの使い道はwebサーバーだけじゃないのはわかってたけど。

ネームサーバーはどちらかというと、対象のドメインのレコードを知るための手がかりで、
その手掛かりとしてIPを利用していると思うようにする。
つまりネームサーバーに利用するIPは対象のドメインの各レコードの情報知るための住所。

ややこしいところとしては、各レコードのIPを知りたいのに、それを知る手段がIPだということ。
仮にDNSがIPとかじゃなくて、DPとか違う言い方だったら悩まずに済んだかもしれない。

PacletiXVPNを利用すれば、レイヤー2でVPNを構築するためプロトコルを気にせずに通信ができるそう。
例えば、ポート25が閉じられていて対象のリモートサーバーにメールを飛ばせない時は、
ポート443からメールを飛ばせるようなことができる。

PacletiXVPNはGUI上で操作できるため初心者でも容易だそうな。

なおVPNはトンネリングと暗号化で成り立っており、トンネリングは、
パケットAでしか通せない情報をパケットBも通すためにカプセル化すること。
暗号化はパケット内の情報を第三者にみせないこと。

カプセル化ってものをいつかやってみたい。