本文へスキップ
株式会社オープンナレッジ
株式会社オープンナレッジ Open Knowledge Inc.
経産省SCS評価制度(★3・★4)重要項目

窓口をパンクさせる「DDoS攻撃」と、
会社の看板を守る「なりすましメール(DMARC)対策」。

大切な取引先に「あなたの会社の名前の偽メール」が届いたり、ある日突然ホームページが繋がらなくなったりする被害が全国で急増しています。図解と実践ツールで、静かで確実な守り方を紐解きます。

1. 基本と全体像

この記事の要点と4つの章のご案内

たとえ話と図解でわかる「DDoS・VPN・DMARC」のしくみに関するイメージ写真
たとえ話と図解でわかる「DDoS・VPN・DMARC」のしくみ
入力2項目で完成:自社ドメインの「DMARC(なりすまし防止)設定文」生成ツールに関するイメージ写真
入力2項目で完成:自社ドメインの「DMARC(なりすまし防止)設定文」生成ツール
窓口をパンクさせる「DDoS攻撃」と、 会社の看板を守る「なりすましメール(DMARC)対策」。 の各章におけるテーマと要点一覧表
章構成 主なテーマ 要点と確認ポイント
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(ディードス)攻撃」とは何ですか? 大切な取引先に「あなたの会社の名前の偽メール」が届いたり、ある日突然ホームページが繋がらなくなったりする被害が全国で急増しています。図解と実践ツールで、静かで確実な守り方を紐解きます。
第1章〜第4章では、実務チェックリスト・公的制度基準・詳しい技術仕様を確認できます。
01 / Visual Metaphor & Architecture

たとえ話と図解でわかる「DDoS・VPN・DMARC」のしくみ

01. DDoS攻撃への備え 「1万件のいたずら電話」 ・静的配信(Astro)で負荷を1/20に ・同一IPからの連打を入口で自動制限 → 本当のお客様の通信だけを通す 02. VPN・境界機器の保護 「勝手口の古い鍵を交換」 ・ランサム侵入の80%超がVPN/RDP ・ファームウェアの自動更新と監視 → 不要な外部公開ポートを全体閉鎖 03. SPF / DKIM / DMARC 「手紙の消印と封蝋(ふうろう)」 ・SPF:正しい発送元サーバーか確認 ・DKIM:電子署名で途中の改ざん検知 → DMARC:偽装メールを自動拒否
02 / Interactive DNS Record Generator

入力2項目で完成:自社ドメインの「DMARC(なりすまし防止)設定文」生成ツール

会社のホームページやメールのドメイン名(例:example.co.jp)と保護レベルを選ぶだけで、DNSサーバーに貼り付ける設定行がその場で生成されます。

DNS(ネームサーバー)に追加する TXT レコード:
_dmarc.example.co.jp. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-report@example.co.jp; pct=100; adkim=s; aspf=s;"
03 / Governance & 2026 METI SCS Alignment

経済産業省「SCS評価制度(★3・★4)」および公的ガイドラインとの対応関係

2026年より運用が開始される経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度)」および総務省・経済産業省のメール送信ドメイン認証ガイドラインにおいて、①公開WebサーバーのDDoS耐性と静的分離、②VPN等の境界機器における脆弱性管理と多要素認証、③SPF・DKIM・DMARC(p=quarantine / reject)による送信元証明は、取引先への信頼性を示す中核項目として位置づけられています。

01 境界露出の最小化

不要な管理ポートや古いVPN機器を棚卸しし、外部から直接到達可能な攻撃面(Attack Surface)を最小化します。

02 ドメインなりすまし遮断

DNSのTXTレコードにSPF・DKIM・DMARCを設定し、自社名を騙る偽メールが取引先へ届くリスクを防ぎます。

03 継続的な死活・証明書監視

TLS証明書の有効期限やDNS設定の変更を継続的に監視し、異常発生時に迅速に検知できる体制を整えます。

技術仕様・実装解説(FREEBSD PF SYNPROXY & RFC 7489 DMARC) 4. 詳しい技術仕様としくみ
技術アーキテクチャと実装仕様

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 アライメント) の検証アルゴリズムを定式化する。

L4 DDoS Mitigation
FreeBSD 14 pf synproxy state
SYN Cookie PRF
SipHash-2-4 (64-bit MAC)
DNS Integrity
RFC 8080 DNSSEC Ed25519 (Alg 15)
Email Auth Policy
SPF -all + DKIM + DMARC p=reject
1. 設計仕様・数理モデル(Formal Architecture, Protocol Internals & Mathematical Formulation)

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; に従って受信ゲートウェイは当該メールを即時破棄する。

2. パラメータ・構成仕様(L4 DDoS & Email Authentication Protocol Stack Specification)
Layer / RFCMechanismCryptographic / Kernel PrimitiveProduction Enforcement Parameter
L4 TCP (RFC 9293)FreeBSD pf synproxy + syncookiesSipHash-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 AlignmentRSA-2048 / Ed25519 Signature + Strict Domain Matchv=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; pct=100
3. 実装コード・設定仕様(Executable Specification Code (crates/ok-net-auth/src/dmarc_alignment.rs)) Rust Edition 2024 (#![forbid(unsafe_code)])
#![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
    }
}
4. 詳しい技術仕様としくみ(システム設計・数理モデル・実装例)

FIDO2 / WebAuthn Level 3 と CTAP2 公開鍵暗号によるフィッシング無効化プロトコル実装

プロトコル仕様・数理モデル・Rust 2024 実装コードの詳細は、専門技術モノグラフにて公開しています。

技術モノグラフを読む →
ご質問・公的制度の活用に関するお問い合わせ窓口

掲載資料に関するご質問・公的制度活用のご案内

本ページの図解や解説内容に関するご質問、経済産業省「SCS評価制度」やIPA「SECURITY ACTION・サイバーセキュリティお助け隊サービス」等の公的制度の確認方法について、落ち着いた参考窓口としてご案内しております。売り込みや営業連絡は一切行いませんので、社内勉強会やご家庭での確認資料としてご自由にご活用ください。

図解・ビジュアルの拡大表示

図表内のテキストもそのまま選択・検索可能です(ベクターSVG描画) 枠外クリックまたは ESC キーで閉じます