窓口をパンクさせる「DDoS攻撃」と、
会社の看板を守る「なりすましメール(DMARC)対策」。
大切な取引先に「あなたの会社の名前の偽メール」が届いたり、ある日突然ホームページが繋がらなくなったりする被害が全国で急増しています。図解と実践ツールで、静かで確実な守り方を紐解きます。
この記事の要点と4つの章のご案内
| 章構成 | 主なテーマ | 要点と確認ポイント |
|---|---|---|
| 1. 基本と全体像 | たとえ話と図解でわかる「DDoS・VPN・DMARC」のしくみ | 一言でいうと「何万台もの悪用された機器から一斉に無言電話(大量のアクセス)をかけ続け、ホームページや予約窓口を話し中にしてパンクさせる妨害攻撃」です。2024年末〜2026年にかけて日本の航空会社、銀行、自治体、そして地域の中小ECサイトでも被害が急増しています。 |
| 2. 現場での進め方と対策 | 入力2項目で完成:自社ドメインの「DMARC(なりすまし防止)設定文」生成ツール | 自社の名前やメールアドレスを勝手に騙る「なりすましメール(偽の請求書やフィッシング詐欺)」を防ぐための3つの国際ルールです。SPFは「発送元の住所確認」、DKIMは「途中で改ざんされていない封蝋(電子署名)」、DMARCは「偽物が届いたら受取拒否にして通知するルール」にあたります。GmailやYahoo!メール等でも設定が事実上必須となっています。 |
| 3. 関連する制度とルール | 経済産業省「SCS評価制度(★3・★4)」および公的ガイドラインとの対応関係 | 警察庁の統計では、ランサムウェア侵入経路の80%以上がVPN機器やリモートデスクトップです。01 機器のソフト(ファームウェア)を最新に保つこと、02 推測されやすいパスワードをやめてクライアント証明書やパスキーを併用すること、03 使っていない外部公開ポートを閉じることの3点で確実に防げます。 |
| 4. 詳しい技術仕様としくみ | 最近ニュースでよく聞く「DDoS(ディードス)攻撃」とは何ですか? | 大切な取引先に「あなたの会社の名前の偽メール」が届いたり、ある日突然ホームページが繋がらなくなったりする被害が全国で急増しています。図解と実践ツールで、静かで確実な守り方を紐解きます。 |
たとえ話と図解でわかる「DDoS・VPN・DMARC」のしくみ
入力2項目で完成:自社ドメインの「DMARC(なりすまし防止)設定文」生成ツール
会社のホームページやメールのドメイン名(例:example.co.jp)と保護レベルを選ぶだけで、DNSサーバーに貼り付ける設定行がその場で生成されます。
_dmarc.example.co.jp. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-report@example.co.jp; pct=100; adkim=s; aspf=s;"
経済産業省「SCS評価制度(★3・★4)」および公的ガイドラインとの対応関係
2026年より運用が開始される経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度)」および総務省・経済産業省のメール送信ドメイン認証ガイドラインにおいて、①公開WebサーバーのDDoS耐性と静的分離、②VPN等の境界機器における脆弱性管理と多要素認証、③SPF・DKIM・DMARC(p=quarantine / reject)による送信元証明は、取引先への信頼性を示す中核項目として位置づけられています。
不要な管理ポートや古いVPN機器を棚卸しし、外部から直接到達可能な攻撃面(Attack Surface)を最小化します。
DNSのTXTレコードにSPF・DKIM・DMARCを設定し、自社名を騙る偽メールが取引先へ届くリスクを防ぎます。
TLS証明書の有効期限やDNS設定の変更を継続的に監視し、異常発生時に迅速に検知できる体制を整えます。
FreeBSD 14 pf カーネルにおける synproxy state 状態機械と DNSSEC (Ed25519) / SPF / DKIM / DMARC 暗号検証
本稿では、企業の公開Web・メール基盤を標的とする L3/L4 SYN Flood DDoS 攻撃、DNSキャッシュポイズニング、およびドメインなりすましメールをネットワーク境界で遮断するため、(1) FreeBSD 14 pf カーネルの synproxy state と SipHash-2-4 SYN Cookie による3ウェイ・ハンドシェイク代行、(2) RFC 8080 Ed25519 (Algorithm 15) を用いた DNSSEC 署名連鎖、および (3) RFC 7208 (SPF) / RFC 6376 (DKIM rsa-sha256 正規化) / RFC 7489 (DMARC p=reject アライメント) の検証アルゴリズムを定式化する。
1. 【FreeBSD 14 pf synproxy state による TCP 3-Way Handshake カーネル代行】 送信元IPをランダムに偽装した大量の TCP SYN パケットを送りつける SYN Flood 攻撃に対し、バックエンドの Web サーバー(Nginx / Rust Axum)が直接 SYN+ACK を返して TCB(Transmission Control Block)メモリを確保すると、数万パケット/秒でバックログキューが飽和する。FreeBSD 14 のパケットフィルタ pf において pass in on ext_if proto tcp to (ext_if) port { 80, 443 } synproxy state を有効化すると、pf がカーネル空間(sys/netpfil/pf/pf.c)でクライアントとの 3-Way Handshake を構造的に代行する。クライアントから有効な最終 ACK が返却され TCP 接続が確立した瞬間にのみ、pf がバックエンドとのハンドシェイクを開始しシーケンス番号変換(Sequence Number Translation)を透過的に継続するため、偽装 SYN パケットはバックエンドのソケットキューへ1パケットも到達しない。
2. 【RFC 6376 DKIM relaxed/relaxed 正規化と RSA-SHA256 / Ed25519 署名検証】 メール送信元の正当性を証明する3大プロトコル(SPF / DKIM / DMARC)において、SPF(RFC 7208)は配送経路の SMTP MAIL FROM(RFC 5321)のみを検証するため、メーラーに表示される From: ヘッダ(RFC 5322)の偽装を単独では防げない。DKIM(RFC 6376)はメール本文の SHA-256 ハッシュ bh= と主要ヘッダ群(From:To:Subject:Date:Message-ID)を relaxed/relaxed 正規化(連続空白の単一スペース化、ヘッダ名の小文字化、末尾空行の除去)した上で秘密鍵で署名し、受信側が DNS の <selector>._domainkey.<domain> TXT レコードから取得した公開鍵で検証する。
3. 【RFC 7489 DMARC Identifier Alignment の論理積条件】 DMARC(RFC 7489)が pass となるための必要十分条件は、単なる SPF または DKIM の成功ではなく、メーラーが人間に表示する RFC5322.From ドメイン d_from との識別子アライメント(Identifier Alignment)である。すなわち、(SPF_result == pass AND Align(d_spf, d_from)) OR (DKIM_result == pass AND Align(d_dkim, d_from)) が真とならない限り、DMARC ポリシー v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; に従って受信ゲートウェイは当該メールを即時破棄する。
| Layer / RFC | Mechanism | Cryptographic / Kernel Primitive | Production Enforcement Parameter |
|---|---|---|---|
| L4 TCP (RFC 9293) | FreeBSD pf synproxy + syncookies | SipHash-2-4 over (src_ip, dst_ip, ports, secret) | max-src-conn 60, max-src-conn-rate 30/5, overload <bruteforce> |
| DNS (RFC 4035 / 8080) | DNSSEC Chain of Trust (DS -> DNSKEY) | Ed25519 (Alg 15) / ECDSA P-256 (Alg 13) | Authoritative RRSIG validation before MX/TXT lookup |
| SMTP (RFC 7208) | Sender Policy Framework (SPF) | CIDR Tree Evaluation (max 10 DNS mechanism lookups) | v=spf1 ip4:160.251.x.x/32 -all (HardFail on unauthorized IP) |
| MIME (RFC 6376 / 7489) | DKIM + DMARC Alignment | RSA-2048 / Ed25519 Signature + Strict Domain Match | v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; pct=100 |
#![forbid(unsafe_code)]
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum AlignmentMode {
Relaxed,
Strict,
}
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum DmarcDisposition {
Pass,
Quarantine,
Reject,
}
/// Extracts the organizational domain (approximated for standard 2-level/ccTLD registrable labels).
#[inline]
pub fn org_domain(domain: &str) -> &str {
let d = domain.trim().trim_end_matches('.');
let parts: usize = d.bytes().filter(|&b| b == b'.').count() + 1;
let keep_labels = if d.ends_with(".co.jp") || d.ends_with(".or.jp") || d.ends_with(".ne.jp") {
3
} else {
2
};
if parts <= keep_labels {
return d;
}
let mut seen_dots = 0;
for (idx, b) in d.bytes().enumerate().rev() {
if b == b'.' {
seen_dots += 1;
if seen_dots == keep_labels {
return &d[idx + 1..];
}
}
}
d
}
#[inline]
pub fn identifiers_align(auth_dom: &str, header_from_dom: &str, mode: AlignmentMode) -> bool {
match mode {
AlignmentMode::Strict => auth_dom.eq_ignore_ascii_case(header_from_dom),
AlignmentMode::Relaxed => org_domain(auth_dom).eq_ignore_ascii_case(org_domain(header_from_dom)),
}
}
/// Evaluates RFC 7489 Section 6.6.2 DMARC verification and returns policy disposition.
pub fn evaluate_dmarc(
rfc5322_from_dom: &str,
spf_passed: bool,
rfc5321_mail_from_dom: &str,
aspf: AlignmentMode,
dkim_passed: bool,
dkim_d_tag_dom: &str,
adkim: AlignmentMode,
) -> DmarcDisposition {
let spf_aligned = spf_passed && identifiers_align(rfc5321_mail_from_dom, rfc5322_from_dom, aspf);
let dkim_aligned = dkim_passed && identifiers_align(dkim_d_tag_dom, rfc5322_from_dom, adkim);
if spf_aligned || dkim_aligned {
DmarcDisposition::Pass
} else {
DmarcDisposition::Reject
}
}
FIDO2 / WebAuthn Level 3 と CTAP2 公開鍵暗号によるフィッシング無効化プロトコル実装
プロトコル仕様・数理モデル・Rust 2024 実装コードの詳細は、専門技術モノグラフにて公開しています。