ルーターやスイッチの設定作業でACLの適用を求められたとき、「名前は聞いたことあるけど、ちゃんと理解できているか自信がない…」と感じたことはありませんか?
ACL(アクセス制御リスト)はネットワーク機器が持つパケットフィルタリング機能の基本中の基本です。正しく設定できればセキュリティの厚みが増しますが、適用方向や処理順序を誤るとかえって業務通信を止めてしまうリスクもあります。
この記事では、ACLの仕組み・種類・動作原理から実際の設定例・よくある落とし穴まで、現場で使えるレベルで解説します。Cisco IOS系のコマンドを例に挙げますが、概念そのものは他ベンダーの機器にも共通する内容です。

ACL(アクセス制御リスト)とは?なぜ重要か
ACL(Access Control List)は、ルーターやL3スイッチがパケットを転送する際に「このパケットを通過させるか・破棄するか」を判断するためのルールリストです。ファイアウォールと似た機能に見えますが、ACLはネットワーク機器自身に組み込まれているため、追加のアプライアンスなしに使えます。
主な用途は以下のとおりです。
・不要トラフィックの遮断: 外部からの特定ポートへのアクセスをネットワーク機器の段階でブロックする
・管理アクセスの制限: ルーター・スイッチの管理ポートに接続できる送信元IPを絞り込む
・セグメント間の通信制御: 部門VLAN間で許可する通信をきめ細かくコントロールする
・QoSやNATとの連携: 特定の通信のみ帯域制御やアドレス変換を適用する
重要なのは、ACLが「境界のファイアウォール」だけでなく内部ネットワークにも適用できる点です。攻撃者が境界を突破した後の横移動(ラテラルムーブメント)を抑制するためにも、内部セグメント間にACLを設けることが有効です。
ACLの種類を整理する
ACLは大きく標準ACLと拡張ACLの2種類に分けられます。どちらを使うかは「どこまで細かく条件を指定したいか」で決まります。
1. 標準ACL(Standard ACL)
判断基準は送信元IPアドレスのみです。シンプルで設定しやすい反面、あるIPからのすべての通信を許可・拒否するという粗い制御になります。Cisco IOSでは番号1~99または1300~1999が割り当てられます。
# 標準ACLの例(名前付き推奨) ip access-list standard MGMT-ACCESS permit 192.168.10.0 0.0.0.255 # 管理用サブネットを許可 deny any log # それ以外を拒否してsyslogに記録
標準ACLは送信元しか見ないため、宛先に近いインターフェースに適用するのが原則です。送信元に近い場所で適用すると、本来通したい他の宛先への通信まで止めてしまいます。
2. 拡張ACL(Extended ACL)
送信元・宛先のIPアドレスに加え、プロトコル(TCP/UDP/ICMP等)・ポート番号も条件として指定できます。「社内PCからWebサーバーの80番と443番のみ許可」のような細かい制御が可能です。Cisco IOSでは番号100~199または2000~2699が割り当てられます。
# 拡張ACLの例(名前付き推奨) ip access-list extended OFFICE-TO-WEB permit tcp 10.0.1.0 0.0.0.255 host 10.0.2.10 eq 80 permit tcp 10.0.1.0 0.0.0.255 host 10.0.2.10 eq 443 deny ip any any log
拡張ACLは条件が細かい分、送信元に近いインターフェースのinboundに適用するのが鉄則です。不要なパケットを早い段階で破棄することでルーターへの処理負荷も抑えられます。
番号付き vs 名前付き
古い機器では番号付きACLしか使えない場合もありますが、現在の機器では名前付きACL(Named ACL)を強く推奨します。名前で意味が伝わるうえ、行の挿入・削除を行番号で指定して行えるため、後から修正しやすくなります。
ACLの動作原理 ─ ここを誤ると事故になる
1. 上から順番に評価する(最初のマッチで決定)
ACLのルールはリストの上から順番に評価され、最初に一致したルールが適用されます。以降のルールは評価されません。これを「First Match」と呼びます。
たとえば「192.168.1.100だけを拒否し、192.168.1.0/24全体は許可する」という意図で書くとき、順序を間違えると動作が逆になります。
# NG例: 192.168.1.100も先のpermitにマッチしてしまう ip access-list standard BAD-ORDER permit 192.168.1.0 0.0.0.255 # 100を含むサブネットが先にpermit deny host 192.168.1.100 # ここには到達しない # OK例: 個別ホストのdenyを必ず先に書く ip access-list standard GOOD-ORDER deny host 192.168.1.100 # 先に特定ホストを拒否 permit 192.168.1.0 0.0.0.255 # その後でサブネット全体を許可
2. 末尾に「暗黙のdeny any」が存在する
ACLの末尾には、明示的に書かなくても「deny any」(すべて拒否)が自動で追加されています。これを「暗黙のdeny」と呼びます。
ACLを新規作成してインターフェースに適用した瞬間、リストに書いていない通信はすべて遮断されます。必要な通信のpermitルールを書き忘れると、業務通信が止まります。設定前に「何を許可するか」を必ずリストアップしておきましょう。
3. inbound(in)とoutbound(out)の違い
ACLはインターフェースの方向を指定して適用します。
・inbound(in): そのインターフェースから入ってくるパケットに適用
・outbound(out): そのインターフェースから出ていくパケットに適用
方向の選択ミスは典型的な設定事故の原因です。「どこから来て、どこへ向かうパケットを制御したいか」をフロー図で確認してから設定するクセをつけてください。
具体的な防御手順
1. 設計前のチェックリスト
設定に入る前に次の点を整理します。
・フィルタリングの対象通信は何か? 送信元・宛先IP、プロトコル、ポートを書き出す
・許可するものを先にリストアップ — 「何を拒否するか」より「何を許可するか」から考えると見落としが減る
・適用するインターフェースと方向 — 標準ACLは宛先寄り、拡張ACLは送信元寄りのinboundが基本
・ログが必要か? denyエントリに`log`を付けるとsyslogに記録でき、不正アクセスの検知に役立つ
・変更前にコンソール接続を確保する — 誤ったACLを適用するとSSHが切断される
2. 管理アクセスをIPで制限する(標準ACL活用例)
ルーター・スイッチのSSH管理を、情シスのPCや踏み台サーバーのIPからのみ許可します。3行で済む最も即効性の高い対策の一つです。
# 管理アクセス制限ACLの作成 ip access-list standard MGMT-ONLY permit host 192.168.100.10 # 情シスのPC permit 10.0.200.0 0.0.0.255 # 踏み台サーバーのサブネット deny any log # それ以外は拒否・記録 # VTY(SSH/Telnet接続用の仮想端末)に適用 line vty 0 4 access-class MGMT-ONLY in transport input ssh # Telnet無効化も合わせて実施
3. サービス別にトラフィックを制御する(拡張ACL活用例)
オフィスセグメント(10.0.1.0/24)からWebサーバー(10.0.2.10)へのHTTP/HTTPSのみ許可し、その他のポートへのアクセスを遮断します。
ip access-list extended OFFICE-TO-SERVER permit tcp 10.0.1.0 0.0.0.255 host 10.0.2.10 eq 80 permit tcp 10.0.1.0 0.0.0.255 host 10.0.2.10 eq 443 deny ip any any log # オフィス向けインターフェースのinboundに適用(送信元に近い側) interface GigabitEthernet0/1 ip access-group OFFICE-TO-SERVER in
4. インターネット境界での不要ポートブロック(拡張ACL活用例)
WAN側インターフェースのinboundに適用し、公開サービス以外の外部からの通信を遮断します。`established`キーワードを使うと、内部から開始されたTCPセッションの戻りパケットを効率よく許可できます。
ip access-list extended WAN-INBOUND # 内部から開始した既存セッションの戻りパケットを許可 permit tcp any any established # 公開WebサーバーへのHTTP/HTTPSのみ許可 permit tcp any host 203.0.113.10 eq 80 permit tcp any host 203.0.113.10 eq 443 # その他すべてを拒否してログ記録 deny ip any any log interface GigabitEthernet0/0 ip access-group WAN-INBOUND in
中小企業でも今日からできること
複雑なACL設計は後回しにしても、まず次の2点を実施するだけでセキュリティが大きく向上します。
・管理ポートへのアクセス制限(最優先): ルーターやスイッチのSSHを情シスのPCや特定サブネットのIPに絞る標準ACLをVTYラインに設定する。コマンド数行で済むうえ、機器を乗っ取られるリスクを劇的に下げられます
・WANインターフェースのinboundフィルタリング: 公開サービス以外のポートを外部から遮断する拡張ACLをWAN側インターフェースのinboundに適用する
ネットワーク機器全般の初期設定変更から管理ポリシーまでまとめて確認したい場合は「ネットワーク機器のハードニング実践ガイド」も参照してください。
L3スイッチを使った内部セグメント間の通信制御については「スイッチングセキュリティ実践ガイド」が参考になります。
なお、Linuxサーバー上でのパケットフィルタリング(nftables・firewalld)については、姉妹サイトLinuxMaster.JPで詳しく解説しています。
よくある誤解と注意点
【誤解1】ACLだけで十分?
ACLはパケットのヘッダー情報(IPアドレス・ポート番号)のみを見るシンプルなフィルタリングです。HTTPボディ内の不正コードやアプリケーション層の攻撃は検査できません。ACLはあくまで「入口の門番」であり、次世代ファイアウォール(NGFW)やWAFと組み合わせて多層防御を構成することが理想的です。
【誤解2】L2スイッチにACLは関係ない?
L2スイッチ(レイヤー2スイッチ)はルーティングを行わないため標準的なIPベースのACLは使えませんが、L3スイッチ(レイヤー3スイッチ)はルーターと同様にACLを適用できます。VLAN間通信を制御するためにL3スイッチのSVIインターフェースにACLを設定するのは、セグメント分割を実施している企業では一般的な構成です。
【誤解3】ACL番号を覚えていれば番号付きACLで十分?
番号付きACLは行の挿入が難しく、変更のたびにACL全体を書き直すリスクがあります。現場では必ず名前付きACLを使いましょう。`ip access-list extended 名前` 形式で定義したACLは、特定の行番号を指定した挿入・削除が可能です。
【注意】設定変更前にコンソール接続を確保する
誤ったACLを適用するとSSHやTelnetでの管理接続が切断されてしまいます。ACLの変更はコンソールケーブルを接続した状態、またはアウトオブバンド(OOB)管理経路を確保した状態で行うのが安全です。本番環境での変更は必ず変更前の設定バックアップも取っておきましょう。

本記事のまとめ
| 項目 | 標準ACL | 拡張ACL |
|---|---|---|
| フィルタ条件 | 送信元IPのみ | 送信元・宛先IP+プロトコル・ポート |
| 制御の粒度 | 粗い | 細かい |
| 推奨適用位置 | 宛先に近いインターフェース | 送信元に近いインターフェース(inbound) |
| 主な用途 | 管理アクセス制限・VTYライン制限 | セグメント間制御・WAN境界フィルタリング |
| 暗黙のdeny | あり(末尾に自動追加) | あり(末尾に自動追加) |
| 評価順序 | 上から順・最初のマッチで決定 | 上から順・最初のマッチで決定 |
ACLはシンプルな機能ですが、「暗黙のdeny」「評価順序」「適用方向」の3点を正しく理解しないと意図と逆の動作を引き起こします。まずは管理ポートへのアクセス制限からはじめ、設定実績を積みながら境界フィルタリングやセグメント間制御へと広げていくのが現実的なアプローチです。
PR
実践 パケット解析 第3版(Chris Sanders/オライリー・ジャパン)
Wiresharkを使ったパケット解析の定番書。ACLのフィルタリングルールを設計する際に「実際のパケットがどう見えるか」を理解する土台として、ネットワーク担当者に広く読まれています。
