【実務・中級編】 DoS攻撃(Denial of Service)のベクトル – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

スマートコントラクトを殺す「ガス詰まり」：DoS攻撃の真実と生存戦略

現場でスマートコントラクトを触っていると、「コードさえ綺麗に書けばハッキングは防げる」という幻想を抱いている若手に時々出会う。だが、現実は甘くない。特にIoTやOTの制御ロジックをブロックチェーンにオフロードしようとするプロジェクトで、彼らが一番最初に見落とすのが「DoS（Denial of Service）攻撃」だ。

イーサリアムなどのEVM環境では、すべての処理が「ガス代」というコストで管理されている。このガス代の制限（Gas Limit）を逆手に取り、コントラクトを永遠に動かなくする攻撃は、ハッカーにとって最も安上がりで、かつ最も精神を削る攻撃手法の一つだ。

—

1. なぜ「プッシュ型決済」は死を招くのか

最も古典的かつ致命的なのは、ループ処理を使った決済ロジックだ。例えば、ユーザー全員に対して一斉に配当を支払うようなコントラクトを想像してほしい。

// 危険な実装：典型的なプッシュ型決済
function distributeDividends(address[] calldata recipients, uint256 amount) external {
    for (uint256 i = 0; i < recipients.length; i++) {
        // ここで外部アドレスへの送金を行う
        // もし受信者が「送金を受け取ると重い処理が走るコントラクト」だったら？
        payable(recipients[i]).transfer(amount);
    }
}

このコードの脆弱性は明白だ。recipients の配列が大きくなればなるほど、ガス代は増大する。もし攻撃者が「受信するたびに超重い処理が動くコントラクト」を大量にリストに紛れ込ませたらどうなるか？ガス制限に達し、トランザクションはリバート（失敗）する。結果、正規のユーザーへの支払いも永遠に完了できなくなる。これがスマートコントラクトにおける「DoS」の正体だ。

—

2. 回避策：プル型（Withdrawパターン）への転換

この問題を解決する唯一の解は、「こちらから送りつける（Push）」のをやめ、「自分で取りに来させる（Pull）」ことだ。これにより、失敗の影響を個別のユーザーに限定できる。

セキュアな実装パターン（Solidity）

// 安全な実装：プル型（Withdrawパターン）
mapping(address => uint256) public pendingWithdrawals;

function distributeDividends(address[] calldata recipients, uint256 amount) external {
    for (uint256 i = 0; i < recipients.length; i++) {
        // 直接送金せず、残高を記録するだけに留める
        pendingWithdrawals[recipients[i]] += amount;
    }
}

function withdraw() external {
    uint256 amount = pendingWithdrawals[msg.sender];
    require(amount > 0, "残高がありません");
    
    // 状態更新を先に行う（Reentrancy攻撃対策：Checks-Effects-Interactions）
    pendingWithdrawals[msg.sender] = 0;
    payable(msg.sender).transfer(amount);
}

この設計なら、もし誰かが「受け取り拒否」をするような悪意あるコントラクトを持っていたとしても、影響を受けるのはその本人だけだ。システム全体が止まることはない。

—

3. Webアプリ層からの防御：インフラの盾

ブロックチェーン側のガードを固めるのと同時に、そのコントラクトを叩くWebフロントエンドやバックエンド（API）も要塞化しなければならない。IoTデバイスが直接コントラクトを叩く場合は特に、レートリミット（Rate Limiting）が命綱になる。

Nginxによるレートリミット設定

API経由でコントラクトを操作させる場合、NginxでIPごとのリクエスト数を制限し、無駄なガス消費を誘発するスパム攻撃を弾く。

# /etc/nginx/conf.d/rate_limit.conf
# 1秒間に10リクエストまで。超過したIPは即座に弾く
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;

server {
    location /api/v1/trigger-contract {
        limit_req zone=one burst=5 nodelay;
        proxy_pass http://backend_cluster;
    }
}

—

4. 現場の教訓：防御のためのチェックリスト

最後に、後輩諸君に伝えておきたい「絶対に守るべき鉄則」をまとめておく。

1. ループの長さを決して信頼しない: 引数で配列を受け取る関数は、必ず最大長を制限し、requireでバリデーションをかけろ。
2. 外部呼び出しは常に「最後」に: callやtransferをループの中で呼び出すのは「自殺行為」と心得よ。
3. ガス代見積もりのテストを自動化: CI/CDパイプラインに、hardhat-gas-reporterなどを組み込み、リクエスト量に応じてガス消費が非線形に増加していないか常に監視しろ。
4. プッシュ型は例外なく悪: 「送金」だけでなく、「外部コントラクトへの通知」もすべてイベント発行（emit Event）に置き換え、オフチェーン側で拾う構成にせよ。

セキュリティとは、「完璧なコードを書くこと」ではない。「どこかで必ず誰かが悪さをする」という前提で、システム全体が致命傷を負わないように設計することだ。

今回のプル型決済への移行は、Web3開発における「基本のキ」だ。これを徹底するだけで、君たちのコントラクトの生存率は劇的に向上する。もし実装で詰まったら、いつでもコードを見せてくれ。現場からは以上だ。