Infrastructure ACL基礎架構 ACL

To increase the overall security of your network, you have to protect the traffic that transits the network devices using the forwarding path, such as email, web traffic, and so on, as well as the traffic that is intended for the network devices themselves, such as Secure Shell (SSH) and Simple Network Management Protocol (SNMP) for management, Border Gateway Protocol (BGP) and Enhanced Interior Gateway Routing Protocol (EIGRP) as routing protocols between network devices, and so on.

為了提升網路的整體安全性，你必須保護透過轉送路徑穿越網路裝置的流量，例如電子郵件、網頁流量等，同時也要保護目的地為網路裝置本身的流量，例如用於管理的安全外殼協定（SSH）與簡單網路管理協定（SNMP），以及作為網路裝置間路由協定的邊界閘道協定（BGP）與增強型內部閘道路由協定（EIGRP）等。

Access control lists (ACLs) provide a powerful mechanism to control the traffic entering or leaving your network. To protect infrastructure devices and minimize the risk, impact, and effectiveness of direct infrastructure attacks, administrators are advised to deploy infrastructure access control lists (iACLs), as one of the most critical security controls that can be implemented in networks. The iACLs explicitly permit only authorized traffic to the infrastructure equipment, as well as permit transit traffic (all traffic not destined for the infrastructure).

存取控制清單（ACL）提供強大的機制，用來控制進出網路的流量。為了保護基礎架構裝置並將直接針對基礎架構的攻擊之風險與衝擊降到最低，建議管理者部署基礎架構存取控制清單（iACL），這是網路中可實施的最關鍵安全控制之一。iACL 明確允許只有經授權的流量進入基礎架構設備，同時也允許轉送流量（所有非以基礎架構為目的地的流量）通過。

The protections provided by iACLs are relevant to both the management and control planes on the devices. The iACLs enable you to implement policy enforcement to the traffic sent to infrastructure devices. Therefore, you can construct an iACL by explicitly permitting only authorized traffic sent to these devices in accordance with existing security policies and configurations.

iACL 所提供的保護同時涵蓋裝置上的管理平面與控制平面。iACL 讓你能夠對送往基礎架構裝置的流量實施政策強制執行。因此，你可以依照現有的安全政策與設定，只明確允許經授權的流量送往這些裝置，藉此建立 iACL。

Once created, the iACL must be applied to all interfaces that face noninfrastructure devices. This includes interfaces that connect to the internet, other organizations, remote access segments, user segments, and segments in data centers.

iACL 建立後，必須套用到所有面向非基礎架構裝置的介面。這包括連接到網際網路、其他組織、遠端存取區段、使用者區段，以及資料中心內各區段的介面。

Because iACLs are designed as a first line of defense against external threats, they should be deployed at network ingress points to protect the infrastructure from various risks, both accidental and malicious. More precisely, iACLs are extended ACLs that restrict external access to the infrastructure address space. They allow only authorized devices to communicate with infrastructure elements such as routers and switches, while letting transit traffic flow freely.

由於 iACL 的設計目的是作為抵禦外部威脅的第一道防線，因此應部署在網路入口點，以保護基礎架構免受各種意外或惡意的風險。更精確地說，iACL 是一種延伸 ACL，用來限制外部對基礎架構位址空間的存取。它們只允許經授權的裝置與路由器、交換器等基礎架構元件通訊，同時讓轉送流量自由通過。

For example, iACLs deployed at a network ingress point from the internet should implement basic RFC 1918, RFC 3330, and antispoof filtering.

例如，部署在來自網際網路之網路入口點的 iACL，應實作基本的 RFC 1918、RFC 3330 與防偽造過濾。

When developing an iACL, you should understand the required protocols by the specific infrastructure. Although every site has specific requirements, certain protocols are commonly deployed and must be understood. For example, external BGP connections to external peers needs to be explicitly permitted. Any other protocols that require direct access to the infrastructure router need to be explicitly permitted as well. For example, if you terminate a Generic Routing Encapsulation (GRE) tunnel on a core infrastructure router, then protocol 47 (GRE) also needs to be explicitly permitted. Similarly, if you terminate an IPv6 over IPv4 tunnel on a core infrastructure router, then protocol 41 (IPv6 over IPv4) also needs to be explicitly permitted.

在開發 iACL 時，你應了解特定基礎架構所需的協定。雖然每個站台都有其特定需求，但仍有一些協定是常見部署且必須理解的。例如，與外部對等體之間的外部 BGP 連線必須明確允許。任何其他需要直接存取基礎架構路由器的協定，也都必須明確允許。舉例來說，如果你在核心基礎架構路由器上終止一條通用路由封裝（GRE）通道，則協定 47（GRE）也必須明確允許。同樣地，如果你在核心基礎架構路由器上終止一條 IPv6 over IPv4 通道，則協定 41（IPv6 over IPv4）也必須明確允許。

In addition to required protocols, the infrastructure address space needs to be identified since this is the address space that the iACL protects. The infrastructure address space includes any addresses that are used for the internal network and are rarely accessed by external sources such as router interfaces, point-to-point link addressing, and critical infrastructure services. Since these addresses are used for the destination portion of the iACL, summarization is critical. Wherever possible, these addresses must be grouped into classless interdomain routing (CIDR) blocks.

除了必要的協定之外，還需要識別基礎架構位址空間，因為這正是 iACL 所要保護的位址空間。基礎架構位址空間包括用於內部網路、且很少被外部來源存取的所有位址，例如路由器介面、點對點鏈路定址，以及關鍵基礎架構服務。由於這些位址會用作 iACL 的目的地部分，彙總就變得非常重要。只要有可能，就應將這些位址分組為無類別跨網域路由（CIDR）區塊。

The following figure illustrates an example of a company that is multihomed to two ISPs through two local routers. The iACLs are applied inbound on the ingress interfaces of company routers, which represent entry points to the network. Each router has a BGP connection to one ISP, for load sharing of the internet traffic on the basis of predetermined policies.

下圖說明一家公司透過兩台本地路由器，同時連接兩家 ISP（多重接取）的範例。iACL 套用在公司路由器的入向入口介面上，這些介面代表網路的進入點。每台路由器都與一家 ISP 建立 BGP 連線，依據預先制定的政策對網際網路流量進行負載分擔。

Since many attacks rely on flooding routers with fragmented packets, filtering incoming fragments to the infrastructure provides an added measure of protection and helps ensure that an attack cannot inject fragments by simply matching Layer 3 rules in the iACL.

由於許多攻擊依賴以分段封包淹沒路由器，過濾送往基礎架構的傳入分段可提供額外的保護措施，並確保攻擊者無法僅透過符合 iACL 中的第 3 層規則來注入分段封包。

ACLs can use the fragments keyword that enables specialized fragmented packet-handling behavior. Without this fragments keyword, noninitial fragments that match the Layer 3 statements (irrespective of the Layer 4 information) in an ACL are affected by the permit or deny statement of the matched entry. However, by adding the fragments keyword, you can force ACLs to either deny or permit noninitial fragments with more granularity.

ACL 可以使用 fragments 關鍵字，啟用特殊的分段封包處理行為。若不使用 fragments 關鍵字，符合 ACL 中第 3 層陳述式的非初始分段封包（不論第 4 層資訊為何）都會受到相符項目的允許或拒絕陳述式影響。然而，加上 fragments 關鍵字後，你可以更精細地強制 ACL 拒絕或允許非初始分段封包。

Filtering fragments can be added to the example as an additional layer of protection against a denial of service (DoS) attack that uses noninitial fragments (that is, fragment offset > 0). Using a deny statement for noninitial fragments at the beginning of the iACL denies all noninitial fragments from accessing the router. Under rare circumstances, a valid session might require fragmentation, and will be filtered if a deny fragment statement exists in the ACL.

過濾分段封包可作為範例中額外的一層保護，用來防禦利用非初始分段封包（即分段偏移量 > 0）發動的阻斷服務（DoS）攻擊。在 iACL 開頭對非初始分段封包使用拒絕陳述式，會拒絕所有非初始分段封包存取路由器。在罕見情況下，有效的會話可能需要分段，若 ACL 中存在 deny fragment 陳述式，這類流量將被過濾。

To deny any noninitial fragments, while nonfragmented packets or initial fragments are able to pass to the next lines of the ACL, use the following entries at the beginning of an iACL:

若要拒絕所有非初始分段封包，同時讓未分段封包或初始分段封包能夠繼續傳遞至 ACL 的下一行，請在 iACL 開頭使用以下項目：

These separate entries in the iACL facilitate classification of the attack, since each protocol, TCP, UDP, and Internet Control Message Protocol (ICMP), increments separate counters in the ACL.

iACL 中這些分開的項目有助於對攻擊進行分類，因為 TCP、UDP 與網際網路控制訊息協定（ICMP）等每種協定，都會在 ACL 中累計各自獨立的計數器。

As previously mentioned, an iACL built without the proper understanding of the protocols and devices involved, may end up being ineffective and may even cause a DoS attack, instead of preventing it. Therefore, you should have a clear understanding of the legitimate traffic required by your infrastructure before deploying an iACL. Also, you should use a conservative methodology for deploying iACLs, leveraging iterative iACL configurations that can help you identify and incrementally filter unwanted traffic.

如前所述，若在未充分了解所涉及協定與裝置的情況下建置 iACL，可能會導致其失效，甚至反而引發 DoS 攻擊，而非加以防範。因此，在部署 iACL 之前，你應對基礎架構所需的合法流量有清楚的理解。此外，你應採用保守的方法來部署 iACL，運用反覆迭代的 iACL 設定，協助你識別並逐步過濾不需要的流量。

The following example illustrates the iACL applied inbound on interface Gi 0/0 on router R1, which provides antispoof filters, permits external BGP peering to the external peer, and protects the infrastructure from all external access. R2 uses a similar iACL.

以下範例說明套用在路由器 R1 的 Gi 0/0 介面入向的 iACL，該 iACL 提供防偽造過濾，允許與外部對等體之間的外部 BGP 對等連線，並保護基礎架構免受所有外部存取。R2 使用類似的 iACL。

The network troubleshooting tools ping and traceroute use ICMP, which you can also filter in the iACLs. Therefore, you can permit ICMP messages by name or type and code, to allow traffic from trusted management stations to the infrastructure devices while blocking all other ICMP packets to these devices.

網路疑難排解工具 ping 與 traceroute 使用 ICMP，你也可以在 iACL 中過濾 ICMP。因此，你可以依名稱或類型與代碼允許 ICMP 訊息，讓來自受信任管理站台的流量能夠傳送到基礎架構裝置，同時封鎖所有其他送往這些裝置的 ICMP 封包。