ホーム » コンピュータ » Network » ドメイン

ドメイン」カテゴリーアーカイブ

システム

最近の投稿

アーカイブ

カテゴリー

よく出来たフィッシングだな….

コロナ感染入院給付金の請求

日本生命からの自宅サーバのメアドに届いたメール。
自宅サーバに届くメールは、tsaitoh.net のドメイン管理者を狙う場合が多いので、自分で管理しているシステム以外から届くメールはほとんど悪意まみれのフィッシングメール。
メール先頭の送信相手欄に、本人名で始まっていないし、典型的な危ないメールだけど、出来がいいフィッシングだなぁ…
と思いフィルタ設定をしようと “Received:”タグを確認して、送信元の IP アドレスを確認したら本物だった。
改めて、日本生命さんのサイトに”メールのリンクを使わずに”ログインして確認してみたけど、しっかり自宅サーバのメアドも登録してあった。

<重要>【三井住友カード】お取引が決済できませんでした

こっちは、明らかにおかしいメール。でも送信IPは、googleusercontent.com 。まかりなりにもGoogle さん。でも、GoogleのVMサービスなので怪しいに違いはない。
通常は、FireWall で接続を完全ブロックするんだけど、Google さんだし、postfix の smtpd_client_restrictions にて接続制限を加える。
((( /etc/postfix/main.cf )))
smtpd_client_restrictions = permit_mynetworks,
          check_client_access regexp:/etc/postfix/smtpd_client_regexp
          :
((( /etc/postfix/smtpd_client_regexp )))
:
/\.googleusercontent.com$/	REJECT
{CAPTION}

自宅ドメインのwhois情報の修正

セキュリティの話をする際に、whois とかを使うこともあるけど、自宅ドメイン名で検索するとクソまじめに登録してあったから住所とかそのまんま検索できていた。

改めてプライバシー対策ということで、さくらインターネット🌸のwhois情報を修正してみた。最初、番地情報を消したりしたけど、エラーが発生して修正できず。レジストラの情報を書くのはアリ見たいだったので、入力フォームにある「さくらインターネット」の情報をそのまま入力したら、エラーも発生せず修正できた。

トラブルが発生しても、一旦レジストラに連絡が行ってから、こちらに連絡が来るんだろうし、これでも問題ないかな。

CAA レコードが未設定で dehydrated (Let’s Encrypt) が失敗

自宅ドメインの SSL 証明には、Let’s Encrypt (実体は dehydrated) を使っているけど、CERT の有効期限の確認の処理で警告がでてきて、月に1度実施の更新でエラーを吐いているみたい。

DNS に CAA レコードが無いと失敗する

更新を実行すると、以下の表示が出ている。

ERROR: Challenge is invalid! (returned: invalid) (result: ["type"] "http-01"
:
["error","detail"]      "CAA record for tsaitoh.net prevents issuance"

Let’s Encrypt が更新する際に、ドメイン名の CAA レコードを参照しているけど、CAA レコードが正しくないために、SSL 更新に失敗している。

DNS Certification Authority Authorization とは、ドメイン名の所有者が認証局に対して、自分のドメイン名の公開鍵証明書の発行を許可するかどうかを指定できるようにするインターネットセキュリティポリシーのしくみである。(Wikipedia)

CAAレコードに letsencrypt.org を登録

自宅ドメインは、Dynamic DNS に mydns.jp を使っているので、mydns.jp の設定画面の “DOMAIN INFO” の所で、
「@ CAA 0 issue “\000”」 となっていたので、下記の設定を追加する。

Hostname Type Content Target ID
@ CAA 0 issue “letsencrypt.org” mydnsXXXXX

この設定の後、nslookup では、下記のようなデータが取れるようになった。

$ nslookup -query=CAA tsaitoh.net
tsaitoh.net     rdata_257 = 0 issue "letsencrypt.org"

他の仕事関連のドメイン名も同様の症状が発生するようになるはずなので、mydns.jp 関連の他ドメインで同様設定を追加する。

G.ROOT-SERVERS.NET が繋がらない

自宅のDNSのトラブルで、ルートサーバが国ドメイン単位での接続拒否でつながらないのが原因? だったかもしれないのだが、職場の自室で動かしている Cache DNS でも同様のトラブルが出るので、ルートサーバの接続確認。G.ROOT-SERVERS.NET. だけつながらない。自宅でも職場でも同様。

$ grep 3600000 /etc/bind/db.root \
  | grep A | grep -v AAAA | grep -v NS \
  | awk '{print $4}' | fping
199.7.91.13 is alive
192.203.230.10 is alive
:
192.58.128.30 is alive
192.112.36.4 is unreachable ← G.ROOT-SERVERS.NET. だけつながらない

G.ROOT-SERVERS.NET. はアメリカ国防総省の管理か….単に一時的な問題なのかな…

接続拒否国ドメインに PA, IO を追加

相変わらず、メールなどに怪しい所からの接続。国ドメインを確認したら、PA(パナマ共和国) と IO(イギリス領インド洋地域)。

大変申し訳ないけど、我が家のようなサイトは縁がない国なので、接続拒否。

現時点、我が家では下記ドメインが管理している IP アドレスは接続を拒否している。

AE, AF, AM, AZ, BD, BG, BR, BY, CL, CN, ES,
HK, ID, IN, IL, IO, IR, IQ, JO, KG, KP, KR, KW, KZ,
LB, MY, NL, OM, PA, PH, PS,
QA, RO, RU, SA, SY, TH, TJ, TR, UA, UZ, VN, YE

DNSのルートサーバ問題?

自宅では、自宅内だけの DNS を実現するために、DNSサーバ bind を動かしているけど、ブラウザで作業中にたまに DNS によるエラーでページが表示されない。

もしかして、変なところからの攻撃を防ぐために 国別のIPアドレス情報(GEOIP)を元に、接続拒否をしているのが原因かもしれない。確認を行うと、DNS ルートサーバの 中に、スウェーデン(SE)とオランダ(NL) が含まれていて、オランダが拒否リストに入ってた。

ということで、i.root-server.net(SE) , k.root-server.net(NL) を個別に許可リストに加える。

((2022-04-06))

再起動すると、ferm が動いていないのか iptables が未設定の状態になっている。確認をすると、OS起動時のエラーの中に、i-root-server.net の名前解決に失敗して、firewall 設定が途中で止まっている。DNS の設定が動いていない前段階で ferm を動かす順序なのでしかたがない。

ということで、許可リストの設定ファイルで、i.root-server.net などは IPアドレス記載に変更した。

国別拒否リストでVN,PH追加

自宅サーバへの攻撃のチェック中。IPアドレスの所属する国を確認した拒否リストを作ってフィルタリングしているけど、改めて攻撃者のIPアドレスを、whois を使って国を確認する。

今回は、現時点で許可している状態で、ssh への攻撃をドメイン毎に分類して作成したCクラスの拒否リストの国を確認したら、ベトナム 60 件、フィリピン 12件。ということで、日本としては仲良くしたい国かもしれんけど、ゴメン拒否の国に追加やわ。

 

自宅メールサーバをDKIM対応へ

Yahoo のメールアカウントに、迷惑メール対策のため「DMARC」導入を開始しますとのメールが届いている。送信側ドメイン認証のひとつで、なりすましだった場合の取り扱いを設定することができるらしい。

しかし、自宅メールサーバは、mydns.jp を用いたダイナミックDNSを用いたサイト。このため、メールサーバを立ち上げても spam 送信元と誤認(なりすましと誤認)される可能性も高く、自宅サーバからのメールは、受け取り側で迷惑メールフォルダに落ちないか心配したり、すぐに相手に届くか不安であった。

ということで、DMARC の前に、DKIM にて信用してもらえるように設定を行う。DKIMは受信したメールが正しいメールサーバから送られ改ざんされていないか確認する方式SPFは以前に導入済みだけど、正しいメールサーバから発信されたか確認する方式なので、DKIM ほどの信頼はない。

opendkim のインストール

Debian では、opendkim のパッケージが配布されているので必要なパッケージをインストールする。設定のために セレクタ名 を postfix としてプライベートキーを生成する。/etc/dkimkeys/postfix.txt には、DNS に登録する “IN TXT” の設定が生成される。

$ sudo aptitude install opendkim opendkim-tools
$ cd /etc/dkimkeys
$ sudo opendkim-genkey -D /etc/dkimkeys -b 1024 -d tsaitoh.net -s postfix
$ sudo chown opendkim:opendkim /etc/dkimkeys/*

opendkim の設定として、上記処理で作られたプライベートキーを登録し、DKIM キーを付加する処理のためのサーバと接続するためのソケットを定義する。

((( 以下のファイルを編集 )))
$ sudo vi /etc/opendkim.conf
Domain   tsaitoh.net
KeyFile  /etc/dkimkeys/postfix.private
Selector postfix

Socket   inet:8892@localhost

DKIM 電子署名を付加するための postifix の設定

postfix でメールを送信する時に opendkim に接続し DKIM の電子署名を付加するために、前述のソケットに対応する設定を以下の様に記載する。

((( /etc/postfix/main.cf )))
$ sudo vi /etc/postfix/main.cf
smtpd_milters = inet:127.0.0.1:8892

DKIM のための DNS の設定

DNSに、公開鍵などの設定を行う。mydns.jp を使っているので、mydns.jp にログインし、DOMAIN INFO にて、以下の設定を加える。

_adsp._domainkey   IN TXT dkim=unknown
postfix._domainkey IN TXT v=DKIM1; h=sha256; k=rsa; p=XXX...XXX

DNS設定が正しく反映されているか確認。

$ nslookup -query=TXT _adsp._domainkey.tsaitoh.net 8.8.8.8
_adsp._domainkey.tsaitoh.net    text = "dkim=unknown"
$ nslookup -query=TXT postfix._domainkey.tsaitoh.net 8.8.8.8
postfix._domainkey.tsaitoh.net  text = "v=DKIM1; h=sha256; k=rsa; p=XXX...XXX

サーバの再起動とDKIMの確認

$ sudo service opendkim start
$ sudo service postfix restart

試しに Google のアカウントにメールを送ったら、メールヘッダに以下が表示されるようになった。SPF は、以前に設定済みなので、自宅サーバからのメールは、確実に相手に届くようになったと思われる。

ARC-Authentication-Results: i=1; mx.google.com;
        dkim=pass header.i=@tsaitoh.net ....
        spf=pass (google.com: domain of ....

ネットワークが繋がらない filter-aaaa-on-v4

最近、職場や自宅にて時々ネットワークが繋がらないときがある。

ネットワークの設定などは自前サーバを配置しているとはいえ、ちゃんと設定してあるはず。

繋がらないという状態でも、異なるサイトなら問題なくつながるので、プロバイダーや自宅ネットワークが落ちているということはない。でも、ふと IPv6 アドレスが問題になっているのかと反省。

自宅内は閉じているとはいえ、IPv6が使える状態。もしかして、上流接続はIPv4しか使えないけど、たまにIPv6アドレスを引いてしまうとかであろうか。

filter-aaaa-on-v4

そこで、色々調べ、IPv4 アドレスからの問い合わせは、IPv6 を使わせないための設定をしてみた。

((( /etc/bind/named.conf.options )))
options {
    :
    listen-on-v6       { any; } ;
    filter-aaaa-on-v4  yes ;
}

動作確認

$ nslookup localhost 
Name:    localhost
Address: 127.0.0.1

$ nslookup localhost ::1
Name:    localhost
Address: 127.0.0.1
Name:    localhost
Address: ::1

気のせいかもしれないけど、職場の環境も filter-aaaa-on-v4 つけたけど、IPv4 fallback がなくなったのかな。応答が速くなったように感じる。

www.googleapis.comの名前引き

自宅では、予定を google-home で自動で喋らせたりするために、gcalcli などのコマンドを使っている。しかし、最近エラーで予定取得に失敗することが増えた。python 関係のライブラリの更新の不整合かと思っていたが、どうも www.googleapis.com の問題のよう。

gcalcli がエラーになったり、成功したりと再現性がないので、エラーメッセージで www.googleapis.com に接続できないっていうし、”nslookup www.googleapis.com” を実行すると、名前引きに失敗する。しかしながら、”nslookup www.googleapis.com 8.8.8.8″ なら成功する。何度か調べていると、通常の nslookup でも名前がひけたりする。意味不明。

bind の設定は….以前、セキュリティ対策で導入した、”OpenDNS (Cisco Umbrella)”を使うようになっている。これが原因か…。bindの設定を修正して、安定して gcalcli が動くようになったかな。
# Cisco Umbrella は、怪しいサイトの可能性の場合、名前引きを失敗させる Open な DNS

Google API を使った攻撃があるのか? OpenDNS にグレー判定されてんの?

Google 検索

My Google   Yahoo

Microsoft

ファンサイト