Bài viết chuyên đề

Trong các bài viết trước, chúng ta đã cùng nhau khảo sát hai loại Access – list cơ bản là Standard ACL và Extended ACL. Đây là hai loại ACL được sử dụng rất nhiều trên các thiết bị mạng của Cisco chạy Cisco IOS.

Bên cạnh hai loại cơ bản trên, Cisco IOS còn tích hợp nhiều loại ACL khác với những công dụng rất đặc biệt:

• Reflexive ACL: hoạt động giống như một dạng tường lửa (firewall) đơn giản. Reflexive ACL kiểm soát lưu lượng theo nguyên tắc chỉ cho phép lưu lượng từ bên ngoài mạng đi vào bên trong mạng nếu như lưu lượng đó là lưu lượng trả về cho một luồng lưu lượng xuất phát từ bên trong mạng đi ra ngoài trước đó.
• Dynamic ACL: cung cấp một cơ chế xác thực để cho phép tiến hành một loại hình trao đổi dữ liệu nào đó. Một host muốn thực hiện một session trao đổi dữ liệu (ví dụ: mở một kết nối Web – HTTP), host này phải tiến hành xác thực bằng cách gửi một cặp username/password đến router có cấu hình dynamic ACL. Nếu xác thực thành công, Dynamic ACL này sẽ tự động tạo một dòng (entry) permit session này và như vậy dữ liệu của session có thể đi qua; ngược lại, nếu xác thực không thành công, dòng permit không được tạo ra, session sẽ bị cấm.
• Timed based ACL: cung cấp một cơ chế cho phép gán yếu tố thời gian lên các dòng của ACL. Các dòng này sẽ chỉ có hiệu lực trong khoảng thời gian được gán. Ví dụ: với time – based ACL, ta có thể cấm người dùng lướt web trong khoảng thời gian từ 08g00 đến 12g00, mở ra cho người dùng được lướt web từ 12g00 đến 13g00 và từ 13g00 đến 17g00 lại cấm lướt web trở lại.

Chúng ta sẽ cùng khảo sát các loại ACL đặc biệt trên trong bài viết này và các bài viết tiếp theo, bắt đầu với Reflexive ACL.

Như thường lệ, chúng ta sẽ tìm hiểu các vấn đề cần quan tâm thông qua các ví dụ lab cấu hình.

Mô tả:

Ta sử dụng lại sơ đồ bài lab của ví dụ trước đây nhưng với các yêu cầu khác. Để tiện theo dõi, phần mô tả của sơ đồ lab sẽ được nhắc lại.

Trên sơ đồ hình 1 là một phần của một mạng doanh nghiệp. Phần này gồm hai router R1 và R2 đại diện cho hai chi nhánh của doanh nghiệp. R1 và R2 được đấu nối với nhau bằng một đường leased – line qua các cổng S0/0/0 của hai router. R1 kết nối vào VLAN 10. R2 sử dụng cổng F0/0 đấu nối xuống VLAN 20 và cổng F0/1 đấu nối với phần còn lại của mạng doanh nghiệp. Quy hoạch IP cho các đấu nối và cho các VLAN được chỉ ra như trên hình 1. Giao thức định tuyến chạy trên sơ đồ lab ví dụ này là giao thức EIGRP.

Khác với bài lab của lần trước, yêu cầu của bài lab lần này là cấu hình R1 thành một dạng tường lửa đơn giản chặn mọi loại lưu lượng đi đến VLAN 10 mà không ảnh hưởng đến việc VLAN 10 đi ra bên ngoài đến các mạng khác.

Yêu cầu:

• Cấu hình R1 để cho phép các gói tin ICMP, TCP và UDP xuất phát từ VLAN 10 được phép đi ra bên ngoài.
• Tất cả mọi loại dữ liệu từ bên ngoài đi vào VLAN 10 đều bị cấm, ngoại trừ các gói tin trả về cho các gói tin ICMP, TCP và UDP đã đi ra trước đó từ VLAN 10.
• Giải pháp cấu hình đưa ra không được ảnh hưởng đến hoạt động định tuyến của R1 với phần còn lại của mạng doanh nghiệp. R1 cũng phải thực hiện được ping và Telnet đến các thiết bị khác trong mạng.

Thực hiện:

Cấu hình cơ bản trên các router:

Cấu hình cơ bản về đặt địa chỉ IP và thực hiện định tuyến EIGRP hoàn toàn giống như đã thực hiện ở bài lab ví dụ trong bài viết trước về Extended ACL. Để tiện cho việc theo dõi, cấu hình này được trình bày lại trong bài viết này.

Trên R1:

Trên R2:

Ta kiểm tra rằng R1 và R2 đã thấy các subnet của nhau trong bảng định tuyến:

Các subnet đã đi được đến nhau:

Cấu hình ACL trên router R1:

Trong bước tiếp theo, chúng ta cấu hình ACL thực hiện các yêu cầu đã đặt ra.

Đầu tiên, chúng ta sử dụng Reflexive ACL để chỉ cho phép các host thuộc VLAN 10 gửi các gói tin ICMP, TCP và UDP ra bên ngoài. Mọi dữ liệu từ bên ngoài đi đến VLAN 10 ngoại trừ các gói tin trả về cho các gói tin xuất phát từ VLAN 10, đều bị cấm.

 

Để thực hiện Reflexive ACL, chúng ta sử dụng hai ACL ngược chiều nhau, một ACL kiểm soát các dòng dữ liệu đi ra khỏi VLAN 10 và một ACL kiểm soát các dòng dữ liệu đi vào VLAN10. Hai ACL này lần lượt có tên là OUTBOUND và INBOUND. Trong ACL kiểm soát chiều out, chúng ta khai báo các dòng permit các loại dữ liệu được phép đi ra khỏi VLAN 10 là ICMP, TCP và UDP. Điểm khác biệt với các dòng ACL thông thường là ở đây với mỗi dòng của ACL OUTBOUND, chúng ta đều gắn kèm thêm thông số “reflect VLAN10”. Trong ACL INBOUND theo chiều ngược lại, chúng ta không khai báo bất kỳ dòng nào liên quan đến dữ liệu trả về cho các loại lưu lượng trên mà chỉ sử dụng một thông số là “evaluate VLAN10”. Nếu hai thông số “reflect” và “evaluate” đều tham chiều đến cùng một tên gọi (ở đây là “VLAN10”) thì cứ mỗi khi có gói tin đi ra match với bất kỳ dòng nào của ACL OUTBOUND có gắn “reflect”, một entry phản xạ gương sẽ được IOS tự động tạo ra trên một ACL khác có tên là “VLAN10” theo chiều in để cho phép gói tin trả về (ACL khác này được gọi là Reflexive ACL).

Ví dụ: xét gói tin ICMP đi từ host 192.168.10.2 đến host 192.168.20.1. Ta thấy gói tin này match với dòng “permit icmp any any reflect VLAN10” của ACL OUBOUND. Ngay lập tức, một entry phản xạ sẽ được tự động tạo ra để cho phép dữ liệu trả về cho gói tin này: “permit icmp host 192.168.20.1 host 192.168.10.2”. Entry này nằm trong Reflexive ACL VLAN10 cùng tham gia kiểm soát dữ liệu theo chiều in trên cổng.

Như vậy với cơ chế tạo ảnh phản xạ đã nói đến ở trên, dữ liệu đi vào bên trong VLAN 10 chỉ có thể là dữ liệu trả về cho một luồng dữ liệu xuất phát từ VLAN 10 trước đó.

Mỗi dòng phản xạ được tạo ra nếu không được sử dụng, sẽ bị xóa sau một khoảng thời gian inactive timeout. Giá trị mặc định của khoảng thời gian timeout này là 300s. Ta có thể hiệu chỉnh khoảng thời gian này bằng câu lệnh:

Các ACL INBOUND và OUTBOUND sau khi được tạo ra sẽ được gán trên cổng đấu nối của R1 ra bên ngoài. Trong ví dụ này là cổng S0/0/0.

Tuy nhiên, sau khi thực hiện gán xong các ACL này lên cổng, từ R1, chúng ta nhận thấy rằng quan hệ láng giềng EIGRP giữa R1 và R2 bị down:

Điều này xảy ra là vì trong ACL INBOUND của R1 chưa có một entry nào permit dữ liệu của EIGRP khi nó đi vào cổng S0/0/0. Chúng ta cần phải bổ sung thêm một dòng permit loại dữ liệu này theo chiều in để đảm bảo thông suốt định tuyến giữa R1 và R2.

Sau khi bổ sung xong dòng ACL, quan hệ láng giềng EIGRP đã được khôi phục lại giữa R1 và R2:

Bên cạnh đó, yêu cầu được đặt ra là ta phải đảm bảo R1 ping và telnet được đến các thiết bị khác. Thực hiện cấu hình đặt password telnet cho R2 và thử ping, telnet đến R2 từ R1:

Ta thấy rằng dù kết nối trực tiếp với nhau thông qua subnet 192.168.12.0/30, R1 vẫn không ping, không telnet được vào R2. Nguyên nhân của vấn đề này là ở chỗ, ACL áp theo chiều out trên cổng sẽ không có tác dụng với mọi lưu lượng xuất phát từ chính router. Do đó, các gói tin ping và telnet của R1 không “hit” được vào các entry ICMP và TCP của ACL OUTBOUND và vì vậy không tạo được ảnh phản xạ trên Reflexive ACL VLAN10 dẫn đến mọi dữ liệu trả về từ R2 cho các hoạt động ping và telnet của R1 đều bị drop bởi ACL INBOUND. Để khắc phục vấn đề này, chúng ta cần phải có các dòng ACL permit các dữ liệu trả về cho hoạt động ping và telnet của R1 trong ACL INBOUND hoặc phải làm cách nào đó để biến dòng lưu lượng xuất phát từ bản thân R1 trở thành dòng lưu lượng transit qua R1. Ta sẽ sử dụng cách thứ hai trên router R1.

Ý tưởng của cách này rất đơn giản: lái dòng lưu lượng xuất phát từ R1 đi qua một interface loopback để quay ngược trở lại R1, và như thế, traffic xuất phát từ R1 đã trở thành Transit traffic qua R1! Ta sử dụng Policy Based Routing để thực hiện điều này.

Đến đây, chúng ta đã hoàn tất yêu cầu đặt ra. Chúng ta kiểm tra lại các ACL vừa thực hiện:

Kiểm tra hoạt động của ACL:

Trong bước này, chúng ta thực hiện kiểm tra hoạt động của giải pháp ACL đã thực hiện ở trên. Vì đây là một bài lab Cisco, và để tiện cho việc thực tập cũng như cấu hình lab, chúng ta sẽ sử dụng một router Cisco giả lập một host của VLAN 10 để test xem các yêu cầu được đặt ra đã được đáp ứng chưa (hình 2).

 Ta cấu hình các địa chỉ và gateway cho “user” R3 của VLAN 10:

Kiểm chứng rằng các host thuộc VLAN 10 đã đi ra được bên ngoài bằng ping và Telnet:

Kiểm tra các ACL trên R1 để thấy rằng các entry phản xạ đã được tạo ra:

Tiếp theo, ta kiểm chứng rằng từ bên ngoài không thể truy nhập vào VLAN 10, thử với ping và telnet:

Để kiểm tra với UDP, chúng ta có thể sử dụng DNS vì các truy vấn DNS chạy trên nền UDP, port 53. Ta bật các dịch vụ DNS trên R2 và R3:

R3 thuộc VLAN 10 có thể thực hiện query DNS ra bên ngoài:

Kiểm tra Reflexive ACL trên R1:

Từ kết quả show ta thấy một entry phản xạ đã được tạo ra cho dữ liệu UDP trả về.

Ta tiếp tục kiểm chứng rằng từ bên ngoài không thể truy nhập UDP đến VLAN 10:

Trong các bước ở trên, chúng ta có thực hiện một giải pháp để cho phép R1 có thể ping và telnet được các thiết bị khác. Chúng ta thực hiện kiểm tra điều này:

Nếu thực hiện bật “debug ip policy” trên R1, ta có thể thấy Policy Based Routing đã hoạt động để lái luồng lưu lượng xuất phát từ chính R1 đi qua loopback 0 và từ đó trở thành transit traffic để có thể “hit” được các entry trong ACL outbound.

Đến đây, chúng ta đã hoàn thành các yêu cầu do bài lab đặt ra và kết thúc ví dụ khảo sát hoạt động của Reflexive ACL. Chúng ta sẽ tiếp tục khảo sát hoạt động của các loại ACL khác trong các bài viết tới.

TRUNG TÂM WAREN