Techerest
EN

Cisco ZBF Advanced: DMZ, Guest, Self Zone และ Multi-Zone Firewall

9 ต.ค. 2569 Cisco DMZ Firewall Guest Network Networking Network Security Self Zone ZBF Zone-Based Firewall

Cisco Zone-Based Firewall Advanced เป็นการต่อยอดจาก ZBF พื้นฐาน จากระบบที่มีเพียง INSIDE และ OUTSIDE ไปสู่ Firewall Architecture ที่มีหลาย Security Zone เช่น INSIDE, OUTSIDE, DMZ และ GUEST รวมถึงการจัดการ Traffic ที่วิ่งเข้าออก Router เองผ่าน Self Zone

หัวใจของการออกแบบ ZBF ระดับสูง ไม่ใช่การสร้าง Zone ให้มากที่สุด แต่คือการกำหนด Traffic Matrix ให้ชัดเจนว่า Zone ใดสามารถเริ่ม Connection ไปยัง Zone ใด ใช้ Service อะไร และควรใช้ Inspect, Pass หรือ Drop อย่างไร

สารบัญ

ภาค 1: Multi-Zone Firewall Architecture

Multi-Zone Firewall Architecture คืออะไร?

ZBF พื้นฐานอาจเริ่มจาก Network เพียงสอง Zone: 

INSIDE
   |
   v
+---------+
|   ZBF   |
+---------+
   |
   v
OUTSIDE

แต่ Enterprise Network มักมี Network หลายประเภท ที่ไม่ควรมี Security Policy เหมือนกันทั้งหมด

ตัวอย่าง:

                    INTERNET
                        |
                        |
                    OUTSIDE
                        |
                        v
                 +-------------+
                 | Cisco Router|
                 |     ZBF     |
                 +-------------+
                  /     |     \
                 /      |      \
                v       v       v
             INSIDE    DMZ     GUEST
                |       |        |
              Users   Servers  Visitors

แต่ละ Zone มี Trust Level และ Requirement ต่างกัน

ออกแบบ INSIDE, OUTSIDE, DMZ และ GUEST

Zone บทบาท ตัวอย่างอุปกรณ์
INSIDE Internal Trusted Network User PC, Internal Systems
OUTSIDE External / Untrusted Network ISP, Internet
DMZ Network สำหรับ Service ที่ต้องแยกจาก LAN Web Server, Public Services
GUEST เครือข่ายสำหรับผู้ใช้งานที่ไม่ควรเข้าถึง Internal Network Guest Wi-Fi, Visitor Devices
SELF Router เอง SSH, SNMP, NTP, Routing/Control Traffic

ชื่อ Zone ไม่ได้สร้าง Security ขึ้นมาเอง 

Zone name
   !=
Security Policy

สิ่งที่กำหนด Security จริงคือ Policy และ Zone Pair ที่ออกแบบระหว่าง Zone ต่าง ๆ

ภาค 2: Traffic Matrix

Traffic Matrix คืออะไร?

ก่อนเขียน Cisco Configuration ควรสร้างตารางว่า ใครสามารถสื่อสารกับใคร

Source Destination Service Action
INSIDE OUTSIDE HTTP, HTTPS, DNS Inspect
GUEST OUTSIDE HTTP, HTTPS, DNS Inspect
GUEST INSIDE Any Drop
OUTSIDE DMZ HTTPS Inspect ตาม Public Service Design
DMZ INSIDE เฉพาะ Service ที่จำเป็น Restrict
INSIDE DMZ Administration / Application ตาม Requirement
INSIDE SELF SSH/SNMP ตาม Management Policy Restrict
Traffic Matrix ควรมาก่อน Configuration เพราะช่วยป้องกันการสร้าง Zone Pair และ Firewall Rule โดยไม่มี Business Requirement รองรับ

วางแผน Zone Pair

Zone Pair มีทิศทาง 

INSIDE -> OUTSIDE

GUEST -> OUTSIDE

OUTSIDE -> DMZ

DMZ -> INSIDE

INSIDE -> DMZ

แต่ละ Direction ถือเป็น Security Relationship คนละชุด

อย่าคิดว่า: 

A -> B

means

B -> A

ข้อยกเว้นที่สำคัญคือ Return Traffic ของ Session ที่ถูก Inspect สามารถใช้ Stateful Information ของ Session เดิมได้

ภาค 3: Policy ระหว่าง Zone

INSIDE → OUTSIDE

Requirement:

INSIDE Users
    |
    +--> HTTP
    +--> HTTPS
    +--> DNS
    |
    v
Internet

Class Map:

class-map type inspect match-any CM-INSIDE-INTERNET
 match protocol http
 match protocol https
 match protocol dns

Policy Map:

policy-map type inspect PM-INSIDE-INTERNET
 class type inspect CM-INSIDE-INTERNET
  inspect
 class class-default
  drop

Zone Pair:

zone-pair security ZP-INSIDE-OUTSIDE
 source INSIDE
 destination OUTSIDE
 service-policy type inspect PM-INSIDE-INTERNET

GUEST → OUTSIDE

Guest Network ควรสามารถ ออก Internet ได้ แต่ไม่จำเป็นต้องใช้ Policy เดียวกับ Corporate Users 

class-map type inspect match-any CM-GUEST-INTERNET
 match protocol http
 match protocol https
 match protocol dns
policy-map type inspect PM-GUEST-INTERNET
 class type inspect CM-GUEST-INTERNET
  inspect
 class class-default
  drop
zone-pair security ZP-GUEST-OUTSIDE
 source GUEST
 destination OUTSIDE
 service-policy type inspect PM-GUEST-INTERNET

Architecture:

GUEST
  |
  | HTTP / HTTPS / DNS
  v
 ZBF
  |
  v
OUTSIDE

GUEST → INSIDE

โดยทั่วไป Guest Network ไม่ควรสามารถเริ่ม Connection ไป Corporate LAN โดยไม่มี Requirement ที่ชัดเจน 

GUEST
  |
  | X
  v
INSIDE

เมื่อไม่มี Zone Pair ที่อนุญาต Traffic ระหว่าง Zone ดังกล่าว ZBF จะป้องกัน Inter-Zone Traffic ตามพฤติกรรมของ Zone Firewall

อย่าสร้าง Zone Pair ที่อนุญาต ip any any เพียงเพื่อแก้ปัญหา Connectivity โดยไม่ทราบ Root Cause เพราะอาจทำลาย Segmentation ที่ตั้งใจออกแบบไว้

OUTSIDE → DMZ

สมมติมี Public Web Server อยู่ใน DMZ 

Internet
   |
   | HTTPS
   v
OUTSIDE
   |
   v
 ZBF
   |
   v
 DMZ
   |
   v
Web Server

แนวคิดคืออนุญาตเฉพาะ Public Service ที่จำเป็น เช่น HTTPS

การ Publish Server จริง ยังอาจต้องใช้: 

Public IP
   +
Static NAT / Port Translation
   +
Routing
   +
ZBF Policy
   +
Server Firewall
   +
Application Hardening
ตัวอย่างนี้อธิบาย Architecture ไม่ควรเปิด Public Server โดยอาศัย ZBF Rule เพียงอย่างเดียว Security ของ Server, Patch Management, TLS, Authentication, Logging และ Monitoring ยังมีความสำคัญ

DMZ → INSIDE

Traffic จาก DMZ เข้าสู่ Internal Network ควรถูกจำกัดมากกว่า INSIDE → DMZ

ตัวอย่าง:

DMZ Web Server
      |
      | SQL 3306
      v
Internal Database

หาก Application Architecture จำเป็นต้องเชื่อม Database ควรอนุญาตเฉพาะ: 

Source:
Specific DMZ Server

Destination:
Specific Database Server

Protocol:
TCP

Port:
Required Database Port

แทน:

DMZ -> INSIDE
permit any

หลักนี้คือ Least Privilege

ภาค 4: Self Zone และ Management Plane

Self Zone คืออะไร?

Self Zone หมายถึง Router เอง

Traffic แบ่งได้เป็น:

Transit Traffic

PC ---- Router ---- Internet


Traffic to Router

Admin ----> Router


Traffic from Router

Router ----> NTP / DNS / Syslog

Traffic สองกลุ่มหลัง เกี่ยวข้องกับ Router ในฐานะ Source หรือ Destination และต้องพิจารณา Self Zone เมื่อออกแบบ ZBF Policy

ออกแบบ Self Zone Policy

ตัวอย่าง Requirement:

Management PC
192.168.99.10
       |
       | SSH
       v
     Router

Administrator อาจต้องการ:

  • อนุญาต SSH จาก Management Network
  • อนุญาต SNMP จาก Monitoring Server
  • ให้ Router ใช้ NTP Server
  • ให้ Router ส่ง Syslog
  • อนุญาต Routing Protocol ที่จำเป็น
  • ปฏิเสธ Management Traffic ที่ไม่จำเป็น
Self Zone เป็นส่วนที่ต้องระวังมาก เพราะ Policy ที่ผิดสามารถตัด SSH, SNMP, AAA, Routing Protocol หรือ Management Session ที่กำลังใช้ Configure Router อยู่

ก่อนแก้ Self Zone ควรมี: 

Console Access

or

Out-of-Band Management

or

Tested Rollback Plan

ภาค 5: Multi-Zone Cisco ZBF Lab

Topology สำหรับ Lab

                         INTERNET
                             |
                         203.0.113.1
                             |
                          Gi0/1
                         OUTSIDE
                             |
                      +-------------+
                      |     R1      |
                      | Cisco ZBF   |
                      +-------------+
                       /     |      \
                      /      |       \
                     /       |        \
                Gi0/0      Gi0/2     Gi0/3
                  |          |          |
               INSIDE       DMZ       GUEST
                  |          |          |
          192.168.10.0   172.16.10.0 192.168.30.0
               /24          /24          /24

Gateway:

INSIDE
192.168.10.1

DMZ
172.16.10.1

GUEST
192.168.30.1

OUTSIDE
203.0.113.2

Step 1 — Configure Interfaces

interface GigabitEthernet0/0
 description INSIDE-LAN
 ip address 192.168.10.1 255.255.255.0
 ip nat inside
 no shutdown

interface GigabitEthernet0/1
 description INTERNET
 ip address 203.0.113.2 255.255.255.252
 ip nat outside
 no shutdown

interface GigabitEthernet0/2
 description DMZ
 ip address 172.16.10.1 255.255.255.0
 ip nat inside
 no shutdown

interface GigabitEthernet0/3
 description GUEST
 ip address 192.168.30.1 255.255.255.0
 ip nat inside
 no shutdown

Step 2 — Configure Default Route

ip route 0.0.0.0 0.0.0.0 203.0.113.1

Step 3 — Configure PAT

ip access-list standard NAT-INTERNAL
 permit 192.168.10.0 0.0.0.255
 permit 192.168.30.0 0.0.0.255

ip nat inside source list NAT-INTERNAL interface GigabitEthernet0/1 overload

ในตัวอย่างนี้ INSIDE และ GUEST สามารถถูก PAT ออก WAN Interface

DMZ Public Server อาจใช้ Static NAT แยกต่างหากตาม Requirement

Step 4 — Create Security Zones

zone security INSIDE
zone security OUTSIDE
zone security DMZ
zone security GUEST

Step 5 — Create Internet Class Map

class-map type inspect match-any CM-WEB-DNS
 match protocol http
 match protocol https
 match protocol dns

Step 6 — Create INSIDE Internet Policy

policy-map type inspect PM-INSIDE-OUTSIDE
 class type inspect CM-WEB-DNS
  inspect
 class class-default
  drop

Step 7 — Create GUEST Internet Policy

policy-map type inspect PM-GUEST-OUTSIDE
 class type inspect CM-WEB-DNS
  inspect
 class class-default
  drop

Step 8 — Create Zone Pairs

zone-pair security ZP-INSIDE-OUTSIDE
 source INSIDE
 destination OUTSIDE
 service-policy type inspect PM-INSIDE-OUTSIDE

zone-pair security ZP-GUEST-OUTSIDE
 source GUEST
 destination OUTSIDE
 service-policy type inspect PM-GUEST-OUTSIDE

ขณะนี้: 

INSIDE -> OUTSIDE
        INSPECT

GUEST -> OUTSIDE
        INSPECT

แต่ยังไม่ได้สร้าง: 

GUEST -> INSIDE

จึงยังคงแยก Guest จาก Corporate Network ตาม Design

Step 9 — Assign Interfaces to Zones

interface GigabitEthernet0/0
 zone-member security INSIDE

interface GigabitEthernet0/1
 zone-member security OUTSIDE

interface GigabitEthernet0/2
 zone-member security DMZ

interface GigabitEthernet0/3
 zone-member security GUEST
ใน Production ควรเตรียม Zone, Class Map, Policy Map, Zone Pair และ Rollback Procedure ก่อนนำ Interface เข้า Zone เพราะ Inter-Zone Traffic อาจได้รับผลทันที

Step 10 — แนวคิด Publish DMZ Web Server

สมมติ:

DMZ Web Server
172.16.10.10

Public IP
203.0.113.10

Static NAT Concept:

172.16.10.10
      |
      | Static NAT
      v
203.0.113.10

จากนั้นต้องมี OUTSIDE → DMZ Policy ที่อนุญาตเฉพาะ Service ที่ต้อง Publish 

Internet
   |
   | TCP 443
   v
OUTSIDE
   |
   v
ZBF Policy
   |
   v
DMZ
   |
   v
Web Server
รายละเอียดการ Match Address ร่วมกับ NAT และ ZBF อาจแตกต่างตาม Platform, IOS/IOS XE Version และ Packet Processing Behavior จึงควรตรวจ Configuration Guide ของ Platform จริงก่อน Deploy

ภาค 6: NAT กับ Multi-Zone ZBF

NAT และ ZBF มีหน้าที่ต่างกัน

ZBF
 |
 +-- Who may communicate?
 +-- Which service?
 +-- Inspect / Pass / Drop?


NAT
 |
 +-- Which address is translated?
 +-- Which port is translated?

ตัวอย่าง Guest User: 

192.168.30.20:51000
        |
        | ZBF Policy
        v
     INSPECT
        |
        | PAT
        v
203.0.113.2:32001
        |
        v
     Internet

หาก ZBF ถูกต้อง แต่ NAT ผิด Internet อาจยังใช้งานไม่ได้

หาก NAT ถูกต้อง แต่ ZBF Drop Traffic ก็ไม่สามารถผ่านได้

Stateful Inspection กับ Return Traffic

ตัวอย่าง INSIDE เริ่ม HTTPS Session: 

INSIDE
192.168.10.10
      |
      | HTTPS
      v
     ZBF
      |
      | INSPECT
      v
OUTSIDE
      |
      v
Web Server

เมื่อ Server ตอบกลับ:

Web Server
      |
      | Response
      v
OUTSIDE
      |
      v
Session State
      |
      v
INSIDE Client

Return Traffic ของ Session ที่ถูก Inspect สามารถอาศัย State ที่ Firewall สร้างไว้

แต่หาก Outside Host พยายามเริ่ม Connection ใหม่: 

OUTSIDE
   |
   | New unsolicited session
   v
INSIDE

จะต้องมี Policy รองรับ Direction นั้น หากมี Business Requirement ให้ทำเช่นนั้น

ภาค 7: Verification

ตรวจ Zone

show zone security

ตรวจ Zone Pair

show zone-pair security

ตรวจ Class Map

show class-map type inspect

ตรวจ Policy Map

show policy-map type inspect

ตรวจ Zone-Pair Statistics

show policy-map type inspect zone-pair

ตรวจ NAT

show ip nat translations
show ip nat statistics

ตรวจ Routing

show ip route
show ip route 0.0.0.0

ตรวจ Interface

show ip interface brief
show interfaces

ภาค 8: Advanced ZBF Troubleshooting

Troubleshooting Workflow

Physical Interface
       |
       v
IP Address
       |
       v
VLAN / Layer 2
       |
       v
Routing
       |
       v
Source Zone
       |
       v
Destination Zone
       |
       v
Zone Pair
       |
       v
Class Map
       |
       v
Policy Map
       |
       v
Inspect / Pass / Drop
       |
       v
NAT
       |
       v
Upstream Path
       |
       v
Return Path
       |
       v
DNS / Application

ปัญหา 1 — INSIDE ใช้ Internet ได้ แต่ GUEST ใช้ไม่ได้

ตรวจ:

show zone security
show zone-pair security
show policy-map type inspect zone-pair

จากนั้นตรวจ:

show ip nat translations
show access-lists NAT-INTERNAL

อาจพบว่า ZBF ถูกต้อง แต่ NAT ACL ไม่มี Guest Subnet

ปัญหา 2 — GUEST เข้า INSIDE ได้

นี่เป็นปัญหาด้าน Segmentation ที่ต้องตรวจทันที

ตรวจว่า:

  • Interface อยู่ Zone ถูกต้องหรือไม่
  • มี Zone Pair GUEST → INSIDE หรือไม่
  • มี Policy ที่กว้างเกินไปหรือไม่
  • Traffic วิ่งผ่าน Router/ZBF จริงหรือไม่
  • มี Layer 2 Path ที่ Bypass Firewall หรือไม่

ปัญหา 3 — Internet เข้า DMZ ไม่ได้

ตรวจ:

Public NAT
     |
     v
OUTSIDE -> DMZ Zone Pair
     |
     v
Class Match
     |
     v
Policy Action
     |
     v
Routing
     |
     v
DMZ Server
     |
     v
Local Firewall
     |
     v
Application

อย่าตรวจเฉพาะ Cisco Router เพราะ Service อาจ Down ที่ Server เอง

ปัญหา 4 — Web ใช้ได้ แต่ Ping ไม่ผ่าน

หาก Class Map มีเพียง: 

HTTP
HTTPS
DNS

ICMP อาจไม่ Match Policy ที่อนุญาต 

Ping failed
   !=
Internet completely failed

ควรทดสอบ Service ที่ Policy ตั้งใจอนุญาตจริง

ปัญหา 5 — Policy Counter ไม่เพิ่ม

อาจเกิดจาก:

  • Traffic ไม่ผ่าน Router ตัวนี้
  • Zone Pair ผิด Direction
  • Interface อยู่ผิด Zone
  • Routing ส่ง Traffic ไป Path อื่น
  • Class Map ไม่ Match
  • Test Traffic ไม่ตรงกับ Protocol ที่กำหนด

ปัญหา 6 — Router SSH ไม่ได้หลังแก้ ZBF

ให้ตรวจ Self Zone, Management Policy และ Interface ที่ใช้บริหาร Router 

Admin PC
   |
   | SSH
   v
Router SELF
อย่าแก้ Self Zone แบบทดลอง บน Production Router ผ่าน SSH เพียงช่องทางเดียว โดยไม่มี Console หรือ Out-of-Band Access

ปัญหา 7 — Return Traffic หาย

ตรวจทั้ง:

Firewall State
      |
      v
NAT Translation
      |
      v
Routing
      |
      v
Return Route
      |
      v
Remote Host

Stateful Firewall ไม่สามารถแก้ปัญหา Routing หรือ Asymmetric Path ทุกกรณีได้โดยอัตโนมัติ

ภาค 9: หลักการออกแบบ Multi-Zone Firewall

1. แยก Zone ตาม Trust Boundary

Zone ควรสะท้อน Security Requirement ไม่ใช่สร้างตามจำนวน Interface เพียงอย่างเดียว 

Good concept:

Corporate Users -> INSIDE
Public Servers  -> DMZ
Visitors        -> GUEST
Internet        -> OUTSIDE

2. ใช้ Least Privilege

แทน:

DMZ -> INSIDE
ANY

ควรเป็น:

DMZ Web Server
     |
     | Required service only
     v
Specific Internal Server

3. แยก Public Server ออกจาก LAN

หลีกเลี่ยง:

Internet
   |
   v
Internal LAN Web Server

ควรพิจารณา:

Internet
   |
   v
Firewall
   |
   v
DMZ
   |
   v
Public Server

4. แยก Guest Network

GUEST
  |
  +----> Internet
  |
  X
INSIDE

Guest Network ไม่ควรได้รับ Trust เพียงเพราะอยู่ในอาคารเดียวกัน

5. ป้องกัน Management Plane

การป้องกัน Transit Traffic อย่างเดียวไม่เพียงพอ หาก Router เปิด Management จาก Network ที่ไม่ควรเข้าถึง

ควรพิจารณา:

  • SSH แทน Telnet
  • Management Network
  • AAA
  • ACL สำหรับ VTY
  • SNMPv3 เมื่อรองรับ
  • Syslog
  • NTP
  • Out-of-Band Management

ภาค 10: Production Deployment Checklist

ก่อน Deploy ZBF บน Production

1. Document topology

2. List all zones

3. Build traffic matrix

4. Identify management traffic

5. Identify routing protocols

6. Identify NAT requirements

7. Create class maps

8. Create policy maps

9. Create zone pairs

10. Verify policy direction

11. Prepare rollback

12. Confirm console/OOB access

13. Add zone membership

14. Test permitted traffic

15. Test denied traffic

16. Test return traffic

17. Verify NAT

18. Verify logs/counters

19. Monitor after change

20. Update documentation
Production Change ไม่ควรจบเพียง “Internet ใช้งานได้” แต่ควรทดสอบทั้ง Positive Test และ Negative Test เพื่อยืนยันว่า Traffic ที่ควรผ่าน ผ่านได้ และ Traffic ที่ไม่ควรผ่าน ถูกป้องกันจริง

สร้าง Security Test Matrix

Test Expected
INSIDE → HTTPS Internet PASS / INSPECT
INSIDE → DNS PASS / INSPECT
GUEST → HTTPS Internet PASS / INSPECT
GUEST → INSIDE BLOCK
OUTSIDE → INSIDE New Session BLOCK ตาม Design
OUTSIDE → DMZ HTTPS PASS เฉพาะ Public Service
OUTSIDE → DMZ SSH BLOCK หากไม่มี Requirement
DMZ → INSIDE Any BLOCK ยกเว้น Service ที่กำหนด
Unauthorized Network → Router SSH BLOCK

ภาค 11: คำถามที่พบบ่อย

ZBF จำเป็นต้องมีหลาย Zone หรือไม่?

ไม่จำเป็น Network ขนาดเล็ก อาจมีเพียง INSIDE และ OUTSIDE แต่ระบบที่ต้องแยก Public Server, Guest หรือ Management สามารถเพิ่ม Zone ตาม Security Requirement

DMZ คืออะไร?

DMZ คือ Network Segment ที่ใช้แยก Service ซึ่งมีความต้องการเข้าถึง แตกต่างจาก Internal LAN โดยเฉพาะ Public-Facing Services

DMZ ปลอดภัยโดยอัตโนมัติหรือไม่?

ไม่ การตั้งชื่อ Network ว่า DMZ ไม่ได้สร้าง Security ต้องมี Segmentation, Firewall Policy, Server Hardening, Patch Management, Logging และ Monitoring ที่เหมาะสม

Guest Wi-Fi ควรอยู่ Zone แยกหรือไม่?

ในระบบที่ต้องการแยก Guest ออกจาก Corporate Network การใช้ Security Zone หรือ Segmentation Mechanism ที่เหมาะสมช่วยกำหนด Policy ได้ชัดเจนขึ้น

Zone Pair ต้องสร้างทั้งสองทิศหรือไม่?

ไม่จำเป็นเสมอไป ขึ้นอยู่กับว่า แต่ละ Zone ต้องสามารถ เริ่ม Connection ไปอีก Zone หรือไม่ และ Return Traffic ของ Session ที่ Inspect สามารถใช้ Stateful Information ของ Session เดิมได้

ทำไม GUEST → INSIDE ไม่สร้าง Zone Pair?

หาก Requirement คือ ไม่ให้ Guest เริ่ม Connection ไป Corporate LAN ก็ไม่ควรสร้าง Policy ที่อนุญาต Direction ดังกล่าว โดยไม่มีเหตุผล

INSIDE กับ GUEST ใช้ NAT เดียวกันได้หรือไม่?

สามารถทำได้ในบาง Design หาก NAT Policy ครอบคลุม Source Networks ทั้งสอง แต่ Firewall Policy ของแต่ละ Zone ยังสามารถแยกจากกันได้

Public Server ควรอยู่ INSIDE หรือ DMZ?

ใน Architecture ที่ต้องการ แยก Public-Facing Service ออกจาก Internal Users DMZ เป็นแนวทางหนึ่ง ในการสร้าง Security Boundary ที่ชัดเจนกว่า

Self Zone คือ Interface หรือไม่?

ไม่ใช่ Interface ปกติ Self Zone เป็นแนวคิด สำหรับ Traffic ที่ Router เป็น Source หรือ Destination

ZBF ป้องกัน Router Management ได้ทั้งหมดหรือไม่?

ไม่ควรพึ่ง ZBF เพียง Feature เดียว Management Plane Security ควรพิจารณา SSH, AAA, Management ACL, SNMP Security, Logging และการจำกัด Management Source ร่วมกัน

Multi-Zone ZBF แทน VLAN ได้หรือไม่?

ไม่ได้ VLAN ใช้ Layer 2 Segmentation ส่วน ZBF ใช้ Security Policy ระหว่าง Zone ทั้งสองสามารถทำงานร่วมกันได้

ZBF แทน NAT ได้หรือไม่?

ไม่ได้ ZBF จัดการ Security Policy ส่วน NAT/PAT จัดการ Address Translation

ถ้า ZBF ถูกต้อง แต่ Internet ใช้ไม่ได้ ควรตรวจอะไร?

ตรวจ:

Interface
   |
VLAN
   |
IP / Gateway
   |
Routing
   |
ZBF
   |
NAT
   |
ISP
   |
Return Path
   |
DNS
   |
Application

บทสรุป

Cisco Zone-Based Firewall Advanced ไม่ได้หมายถึงการเขียน Configuration ให้ซับซ้อนขึ้น แต่คือการเปลี่ยนจาก Firewall แบบสองฝั่ง ไปสู่ Security Architecture ที่แบ่ง Network ตามหน้าที่ และระดับความเชื่อถือ 

                  OUTSIDE
                     |
                     |
              +------+------+
              |     ZBF     |
              +------+------+
                /    |    \
               /     |     \
              v      v      v
          INSIDE    DMZ    GUEST

จากนั้นสร้าง Traffic Matrix ก่อน Configuration: 

INSIDE -> OUTSIDE
Web / DNS
INSPECT


GUEST -> OUTSIDE
Web / DNS
INSPECT


GUEST -> INSIDE
BLOCK


OUTSIDE -> DMZ
Only required public services


DMZ -> INSIDE
Only explicitly required services

และต้องไม่ลืม Self Zone สำหรับ Router Management และ Control Traffic 

Transit Security
       +
Zone Segmentation
       +
NAT / PAT
       +
Routing
       +
Management Security
       +
Logging
       +
Monitoring
       =
Better Network Security Architecture

เมื่อเข้าใจ Multi-Zone ZBF แล้ว เราถือว่ามีพื้นฐานสำคัญ ของ Cisco Firewall Architecture เพียงพอสำหรับเดินต่อ ไปยังหัวข้อ Gateway Redundancy

บทความถัดไป: HSRP, VRRP และ GLBP ต่างกันอย่างไร? สร้าง Default Gateway Redundancy บน Cisco ซึ่งจะเริ่มภาค Network High Availability และเชื่อมต่อไปยัง IP SLA, Object Tracking และการออกแบบ Dual Router ในลำดับถัดไป

Share this
Facebook Share X
TECHEREST COMMUNITY

Share your thoughts here

Join the conversation and share your perspective on this article.

Comments will load when you reach this section.
← Newer Older →