まず、winキー+Rキーを押下。
[ファイル名を実行して実行]コマンドが表示されるので、
[mstsc]と入力。
リモートデスクトップ接続の画面が表示される。
postfixで同じメールの回数を指定して送信する。
メールを大量に送る攻撃者ってどのようなことをしてるのだろうと思って
攻撃側の立場になりたいと思いスクリプトを作成してみた。
test.txt
#!/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を説明ができるようなメモ
メール送信時に送信元のメールアドレスを変更することができる。
だから送信者を偽ってスパムメール等を送る人がいる。
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
NOQUEUE: reject: RCPT from 454 4.7.1 : Relay access denied
ここ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でメール送れたけど、宛先サーバに拒否られたw。
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
体から服を着せてみる
体の構造を理解していれば、人の絵を服からかけるかもしれないけど服の影のつける場所とかがわからないのでまず裸体を描いてから服を着せてみた。

キャラとか服はその場で考えたもの。
腕につける布だとか、ドレスの影のつけ方はなんとなくそれっぽい気がしなくもない
4.3.0 Temporary lookup failure 未解決
ansibleでpostfixを立ち上げようとしても受信ができるが送信はできない。エラーはタイトルの通り。
色々調べてみてたどり着いたのは下記サイト。
ネームサーバー障害なのか。ansibleの使い方が悪かったのか。。。
4日ぐらい行き詰ってるのでメモ
https://fumiyas.github.io/2014/12/19/users-in-nss-failure.postfix-advent-calendar.html
エヴァの映画に前に序破Qみてきた
U-nextで1か月無料だからみてきた。実際無料じゃなかったけど泣
シンジ君14歳だしまだ子供だから仕方ないけど、Reゼロのスバルなみのうざさはあった。
ただ大人もしょうもないのでみんな悪いってことでいいんじゃないかな。
個人的に好きなシーンはQのシンジとカヲルのピアノを上達するには?ってやりとり。
あのやりとりを聞いて、よいインフラエンジニアとはなんだ?と思った。
爆速の通信速度の設定、セキュリティの強さ、冗長性。。。
他にもあるけど、お客様の財産が奪われるってことが最大のリスクだと思うので、
セキュリティの強さかな。
セキュリティのスキル伸ばそうかな
ディスクのファイルシステムを確認するコマンド
マウントしているディスクについては 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とか違う言い方だったら悩まずに済んだかもしれない。