ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Nguyễn Đức Thắng

XÂY DỰNG DỊCH VỤ
FIREWALL AS A SERVICE
VÀ ỨNG DỤNG VÀO HỆ THỐNG OPENSTACK

KHÓA LUẬN TỐT NGHIỆP HỆ ĐẠI HỌC CHÍNH QUY
Ngành: Công nghệ thông tin

HÀ NỘI – 2020
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ


TÓM TẮT
Tóm tắt: Ngày nay, với sự phát triển mạnh mẽ của công nghệ thông tin, đặc biệt là Cloud
Computing, các công ty đang dần chuyển giao cơ sở hạ tầng dịch vụ của họ sang nền tảng
Cloud. Đáp ứng nhu cầu đó, nhiều hãng công nghệ lớn đã đưa ra các nền tảng Cloud
Computing nhằm phục vụ cho các doanh nghiệp cần sử dụng. OpenStack là một nền tảng
Cloud đáng chú ý do được phát triển bởi cộng đồng mở trên toàn thế giới. Trong OpenStack,
các dịch vụ được cài đặt và cung cấp dưới dạng các thành phần Component đơn lẻ và kết hợp
với nhau để tạo thành một hệ thống lớn. Trong đó, OpenStack có cung cấp Networking
Service (Neutron) với trách nhiệm quản lý hệ thống mạng trong Cloud. Neutron có cung cấp
các cơ chế bảo mật cho hạ tầng mạng mà nó quản lý đó là Security Group và được đặt vào
từng Port của các máy ảo (instance) hay Port của các Router ảo. Tuy nhiên, việc quản lý các
Security Group trên từng Port đem đến nhiều bất tiện cho người quản trị Cloud. Ngoài ra,
Security Group cũng có thể chưa đáp ứng đủ các yêu cầu bảo mật mà người quản trị mong
muốn. Khóa luận này sẽ tập trung vào việc phân tích phương thức hoạt động của Networking

Service của OpenStack, đưa ra giải pháp bằng việc xây dựng một dịch vụ Firewall as a
Service độc lập với hệ thống OpenStack và tích hợp vào hệ thống OpenStack hiện tại. Từ đó,
đặt ra một hướng tiếp cận mới cho việc phát triển các dịch vụ hỗ trợ cho OpenStack và các
nền tảng Cloud Computing khác. Các nội dụng nghiên cứu và trình bày trong khóa luận đều
được triển khai thực tế trên hệ thống OpenStack thực. Kết quả thực nghiệm cho thấy hướng
tiếp cận mới trong việc phát triển dịch vụ của OpenStack đem lại hiệu quả tích cực cho người
quản trị cũng như nhà phát triển.
Từ khóa: Firewall, Firewall as a Service, Cloud Computing, OpenStack.


LỜI CẢM ƠN
Đầu tiên, em xin gửi lời cảm ơn chân thành tới TS. Hoàng Xuân Tùng đã cho em
cơ hội được học tập và nghiên cứu tại bộ môn Mạng và truyền thông máy tính. Sự
hướng dẫn, hỗ trợ và động viên của Thầy đã giúp em trong việc nghiên cứu và hoàn
thành khoá luận này.
Em xin cảm ơn các thầy, cô trong bộ môn Mạng và truyền thông máy tính, các
thầy cô giảng dạy tại trường Đại học Công nghệ đã giúp đỡ em trong suốt quá trình
học tập và nghiên cứu.
Bên cạnh đó, em xin cảm ơn bạn bè tại trường Đại học Công nghệ đã đồng hành
cùng em suốt gần 4 năm qua.
Em xin chân thành cảm ơn!
Hà Nội, ngày … tháng … năm 2020
Tác giả khóa luận

Nguyễn Đức Thắng


LỜI CAM KẾT
Tôi xin cam đoan những kiến thức được trình bày trong luận án này là do tôi tìm
hiểu và triển khai dưới sự hướng dẫn của TS. Hoàng Xuân Tùng.

Tất cả các tham khảo từ các nghiên cứu liên quan đều được tôi nêu ra một cách
rõ ràng trong danh mục tài liệu tham khảo. Trong khoá luận không có việc sao chép tài
liệu, công trình nghiên cứu của người khác mà không chỉ rõ về nguồn gốc của tài liệu.
Tôi xin chịu mọi trách nhiệm về công trình nghiên cứu của riêng mình!
Hà Nội, ngày … tháng … năm 2020
Tác giả khoá luận
Nguyễn Đức Thắng


MỤC LỤC


DANH MỤC HÌNH ẢNH


DANH MỤC BẢNG


BẢNG KÝ HIỆU CHỮ VIẾT TẮT
STT
1
2
3
4
5
6
7

Chữ viết tắt
FWaaS

IaaS
SDN
CLI
NIDS
OSI
NIC

Ý nghĩa
Firewall as a Service
Infrastructure as a Service
Software-Defined Network
Command Line Interface
Network Instrusion Detection System
Open Systems Interconnection
Network Interface Card

8


MỞ ĐẦU
Cloud Computing đang là xu thế mới trong các hệ thống thông tin mà cả thế giới
đang hướng tới. Các công ty, doanh nghiệp đều đang từng bước chuyển giao, triển khai
các hệ thống dịch vụ của họ trên nền tảng cloud thay vì các phần mềm, ứng dụng
truyền thống trước kia. Kết quả của việc chuyển đổi này đem lại nhiều hiệu quả tích
cực như tiết kiệm chi phí triển khai và nâng cao tính linh hoạt.
OpenStack là một hệ thống Cloud Computing được sử dụng để cung cấp các dịch
vụ Cloud cho các doanh nghiệp. OpenStack có thể quản lý một lượng lớn các máy ảo,
bộ nhớ lưu trữ và các tài nguyên mạng trên một datacenter. Tất cả được quản lý và
cung cấp thông qua các giao diện API chuẩn cùng với cơ chế xác thực chung nhờ vào
Authentication Service do OpenStack cung cấp dưới dạng một component như

Keystone.
Neutron là một Component cung cấp dịch vụ Networking Service và được xem
như là thành phần cốt lõi của hệ thống OpenStack. Neutron cho phép người quản trị
quản lý và cung cấp các tài nguyên mạng một cách nhanh chóng. Đồng thời, Neutron
cũng cung cấp thêm các cơ chế bảo mật cho người dùng như Security Group đặt trên
các Port của máy ảo và router. Nhờ đó, người quản trị có thể kiểm soát luồng truy cập
vào các mạng trong hệ thống cũng như các máy ảo.
Tuy nhiên, sẽ là một vấn đề lớn khi mà số lượng các máy ảo và các mạng nội bộ
trong hệ thống OpenStack tăng cao. Khi đó, việc đáp ứng yêu cầu bảo mật cho từng
máy hay mạng nội bộ khác nhau dẫn tới việc phải tăng thêm số lượng Security Group
cho hệ thống và gắn chúng vào các Port một cách hợp lý. Điều này sẽ dẫn tới việc tốn
một lượng thời gian và công sức cho người quản trị.
Vấn đề trên chính là đề tài mà khóa luận này lựa chọn để giải quyết. Theo đó,
khóa luận sẽ đề xuất ra một giải pháp giúp đơn giản hóa vấn đề bảo mật của hệ thống
OpenStack. Sau cùng, giải pháp sẽ được triển khai thực tế trên một hệ thống
OpenStack thực và đánh giá hiệu quả trong việc đảm bảo an toàn thông tin và sự tiện
lợi cho người quản trị hệ thống.

9


CHƯƠNG 1: GIỚI THIỆU
1.1. Đặt vấn đề
Sự phát triển của Cloud Computing dẫn tới sự ra đời của nhiều hệ thống Cloud
Computing Platform. Theo đó, các nền tảng này cung cấp các dịch vụ như
Infrastructure as a Service (IaaS), Networking as a Service (NaaS), Storage as a
Service (SaaS), ... cho người dùng là các công ty, doanh nghiệp có nhu cầu cần triển
khai các dịch vụ của họ lên Cloud và cung cấp cho người dùng. Đã có nhiều hãng công
nghệ lớn gia nhập vào cuộc chơi này với các hệ thống của riêng mình như Microsoft
Azure, Amazon Web Service (AWS), Google Cloud Platform (GCP), ...

Các bên cung cấp nền tảng Cloud Computing Platform đều cho người sử dụng
thuê và chạy các máy ảo cũng như xây dựng mạng trên chính data center của họ.
Người sử dụng chỉ cần trả phí cho các dịch vụ mà họ sử dụng và triển khai các ứng
dụng của họ bên trên các dịch vụ mà họ đã thuê từ bên thứ ba. Nhờ đó, người sử dụng
dịch vụ mà các nền tảng cung cấp không cần phải quan tâm tới sự vận hành bên dưới
của các thiết bị vật lý. Việc quản trị các tài nguyên vật lý cũng như độ ổn định của hệ
thống thuộc về trách nhiệm của bên cung cấp dịch vụ với nhiều chuyên gia hơn.
Tuy nhiên, bên cạnh các lợi ích mà các nền tảng Cloud Computing đem lại thì
vẫn còn một số bất cập. Điều đáng quan tâm nhất là hầu hết các bên cung cấp nền tảng
đều là các dịch vụ close-source. Theo đó, các dịch vụ của họ cung cấp ra ngoài cho
người sử dụng đều là các dịch vụ độc quyền và được cài đặt sẵn trên hệ thống
datacenter của riêng họ. Điều này khiến cho một số công ty lớn khi họ đã có sẵn một
hệ thống data center của riêng họ cần triển khai một hệ thống Cloud Computing trên
chính data center của họ. Do đó, OpenStack có thể được xem như cách giải quyểt cho
vấn đề này.
OpenStack là một hệ thống nền tảng Cloud open-source và được phát triển bởi
một cộng đồng lớn với trên 100.000 thành viên trên toàn thế giới. Trong đó, các dịch
vụ về Cloud được cài đặt dưới dạng các thành phần (Component) và liên kết với nhau
tạo thành một hệ thống Cloud. Người sử dụng chỉ cần lựa chọn các Component cần
thiết cho datacenter của họ và triển khai chúng trực tiếp trên hệ thống.
Trong OpenStack, Networking Service được xem như một thành phần không thể
thiếu cho hệ thống. Dịch vụ này giúp người quản trị có thể quản trị và tạo các tài
nguyên mạng ảo cho hệ thống như các subnet, router, ... Cũng như các dịch vụ mạng
trên các hệ thống Cloud khác, Networking Service hay Neutron của OpenStack cũng
10


cho phép người quản trị xây dựng các chính sách bảo mật cho hệ thống thông qua một
chức năng của Networking Service cung cấp là Security Group. Theo đó, nhà quản trị
chỉ cần xây dựng các chính sách bảo mật hợp lý cho từng Security Group. Sau đó, gán

các Security Group này cho các Port của các máy ảo chạy trên mạng hay các Port trên
các Router ảo của dịch vụ. Các Port ở đây được hiểu như là các điểm kết nối giúp cho
việc kết nối các thiết bị với nhau, ví dụ như là thẻ giao diện mạng (NIC) của server để
kết nối vào một router hay switch của một mạng nào đó.
Việc quản trị các chính sách bảo mật theo Security Group mặc dù rất có hiệu quả
khi hệ thống còn nhỏ và ít phức tạp. Một khi hệ thống trở lên lớn hơn và phức tạp với
một lượng lớn máy ảo và router, việc quản trị theo Security Group cho từng Port trở
lên khó khăn hơn cả. Người quản trị sẽ phải tốn một lượng lớn thời gian để xác định
cũng như xây dựng security group tương ứng cho từng mạng, từng cụm máy ảo khác
nhau. Để quy hoạch một cách hợp lý các chính sách bảo mật cho hệ thống cũng cần
tốn một lượng lớn thời gian.
Ngoài ra, hiện tại các Security Group mà OpenStack cung cấp chỉ giúp cho hệ
thống xây dựng các chính sách bảo mật cơ bản bằng việc lọc gói tin theo địa chỉ IP,
Source Port, Destination Port,... Security Group mà hiện tại OpenStack cung cấp chỉ
có thể lọc gói tin theo các thông thuộc layer 3 – 4 trong mô hình mạng OSI. Nếu người
quản trị muốn lọc gói tin ở mức độ sâu hơn để đảm bảo an toàn hơn cho hệ thống, họ
cần phải can thiệp vào trong mã nguồn của Networking Service và phát triển các chức
năng mà họ muốn sử dụng.
Mặc dù là một hệ thống mã nguồn mở nhưng việc tiếp cận và phát triển các dịch
vụ trên OpenStack cũng khá khó khăn. Với tổng số lượng dòng code lên tới 20 triệu
dòng code thì việc nắm bắt và phát triển chức năng cho hệ thống OpenStack cũng tốn
một lượng lớn thời gian. Điều này có thể là một bất cập đối với những nhà quản trị hệ
thống khi mà họ không có đủ kinh nghiệm phát triển dịch vụ và cần triển khai dịch vụ
trong một thời gian ngắn.
Từ những vấn đề được đề cập ở trên, một bài toán có thể được đặt ra ở đây là liệu
rằng một người quản trị hệ thống OpenStack có thể xây dựng một dịch vụ hỗ trợ bảo
mật cho Networking Service hay cụ thể hơn là Component Neutron, đơn giản khi tiếp
cận, mở rộng và dễ dàng tích hợp vào OpenStack.
1.2. Phương hướng tiếp cận
Bài toán được đưa ra có thể giải quyết theo nhiều hướng khác nhau. Người phát

triển có thể tạo ra một dịch vụ phát hiện xâm nhập thông qua việc kiểm soát các tiến
11


trình đang chạy trong toàn hệ thống hoặc xây dựng những dịch vụ mã hóa những dữ
liệu nhạy cảm hoặc xây dựng một dịch vụ firewall giúp đảm bảo an toàn cho các luồng
dữ liệu vào, ra hệ thống. Trong các cách tiếp cận trên, xây dựng một dịch vụ firewall
đủ mạnh là một hướng giải quyết dễ tiếp cận hơn cả. Firewall sẽ nắm vai trò như một
rào chắn trung gian trong hệ thống mạng, kiểm soát lưu lượng vào, ra.
Để dễ dàng hơn cho quá trình phát triển cũng như tăng tính linh hoạt của dịch vụ,
người dùng của hệ thống có thể tự định nghĩa các chính sách bảo vệ của hệ thống của
riêng họ, độc lập và không ảnh hưởng tới các chính sách của người dùng khác trên hệ
thống. Cách tiếp cận này tuy đơn giản nhưng lại đem lại hiệu quả cao khi người dùng
hệ thống có thể tự do lựa chọn đâu là những kết nối bị nghi ngờ có thể gây hại hệ
thống của họ và ngăn chặn chúng kịp thời.
Hiện tại có hai hướng xây dựng firewall đó là stateful firewall và stateless
firewall. Trong đó, stateful firewall quản lý hầu hết các khía cạnh của các đường
truyền từ đặc điểm cũng như trạng thái của kết nối thông qua việc đọc toàn bộ các
thông tin của những gói tin. Trong đó, stateful firewall còn lưu trữ thông tin kết nối
của gói tin và đánh giá mức độ sử dụng tài nguyên của gói tin. Từ đó đưa ra các quyết
định ngăn chặn hay chấp nhận gói tin trong lưu lượng ra vào hệ thống. Việc đọc toàn
bộ thông tin gói tin và xử lý chúng để đưa ra quyết định sẽ gây ảnh hưởng rõ rệt tới
hiệu năng của hệ thống. Trong khí đó, stateless firewall chỉ đọc vào các thông tin trong
các gói tin và đưa ra quyết định loại bỏ hay chấp nhận gói tin thông qua các luật được
định nghĩa trước. Nhằm tăng hiệu năng của dịch vụ, khóa luận sẽ lựa chọn cách tiếp
cận xây dựng stateless firewall.
Khóa luận sẽ đề xuất hướng giải quyết cho bài toán theo ba bước chính: xây
dựng dịch vụ lọc và kiểm soát lưu lượng, cung cấp một giao diện bậc cao cũng như
công cụ giúp người sử dụng dịch vụ đễ dàng hơn trong việc tiếp cận và quá trình tích
hợp vào một hệ thống open-source cloud computing lớn mà cụ thể hơn chính là

OpenStack.
Trong quá trình xây dựng hệ thống, một số kĩ thuật được sử dụng để tăng cường
tính bảo mật cho dịch vụ sẽ được đề cập tới. Cùng với đó là các phương pháp giúp
tăng cường hiệu năng cho hệ thống cũng sẽ được nói đến. Cuối cùng, khóa luận sẽ nói
tới hiệu quả của dịch vụ trong việc bảo vệ hệ thống và ứng dụng của nó vào hệ thống
OpenStack.
1.3. Bố cục khóa luận
Bố cục của cả khóa luận sẽ bao gồm 4 phần chính đó là: đặt vấn đề, đưa ra các cơ
sở lý thuyết, đề xuất giải pháp cho bài toán và cuối cùng là xây dựng, tích hợp dịch vụ
trên hệ thống thực.
12


Trong phần đặt vấn đề, khóa luận sẽ đưa ra những vấn đề còn tồn tại trong quá
trình tiếp cận các hệ thống lớn, cụ thể là các nền tảng điện toán đám mây. Đặt ra tầm
quan trọng của firewall trong các hệ thống đó trong quản lý và kiểm soát đường
truyền. Sau đó, những hướng tiếp cận cho bài toán được đề xuất và đưa ra hướng tiếp
cận mà khóa luận lựa chọn để giải quyết vấn đề.
Sau đó, khóa luận sẽ cung cấp các thông tin cơ bản về những khái niệm sẽ sử
dụng cho khóa luận. Theo đó, cơ sở của cách tiếp cận mà khóa luân lựa chọn đó là
khái niệm về mô hình Firewall as a Service (FWaaS). Những ưu điểm và nhược điểm
của mô hình này sẽ được trình bày trong phần cơ sở lý thuyết này. Ngoài ra, những
dịch vụ hiện đang cung cấp theo mô hình trên cũng được đề cập đến và phân tích. Đặc
biệt, khóa luận sẽ trình bày một cách rõ rảng về OpenStack, một nền tảng điện toán
đám mây mã nguồn mở. Cùng phân tích những khó khăn cho người mới tiếp cận với
các dịch vụ của hệ thống cũng như chỉ ra những bất cập về dịch vụ FWaaS và Security
Group của OpenStack.
Tiếp theo, giải pháp cho vấn đề của phần một sẽ được đề xuất chi tiết trong
chương ba. Trong đó, mô hình tổng quan của dịch vụ sẽ được trình bày và phân tích.
Các phương pháp để xây dựng một hệ thống độc lập sẽ được nhắc tới cùng với giải

pháp cho việc tích hợp vào một nền tảng điên toán đám mây
Cuối cùng là phần áp dụng các giải pháp đưa ra trong chương 3 vào thực nghiệm.
Khóa luận sẽ xây dựng kiến trúc chi tiết và đưa ra quy trình phát triển dịch vụ. Các
phương pháp tiến hành cho giải pháp sẽ được trình bày cùng với đó là các kết quả đạt
được sau khi cài đặt thành công dịch vụ trên hệ thống thực và đưa ra đánh giá về hiệu
quả của dịch vụ mới đối với hệ thống Cloud trên OpenStack.

13


CHƯƠNG 2: CƠ SỞ LÝ THUYẾT
Như đã đề cập từ trước, OpenStack có cung cấp một giải pháp cho vấn đề bảo
mật và an toàn thông tin bên trong Networking Service là Security Group. Ngoài việc
hỗ trợ Security Group, đội phát triển của Neutron còn có phát triển thêm một dịch vụ
cho hệ thống đó là plug-in Firewall as a Service. Trong chương này, khóa luân sẽ cung
cấp các thông tin cần thiết về OpenStack Networking Service và các giải pháp bảo mật
mà OpenStack cung cấp là FwaaS và Security Group và những hạn chế của hai giải
pháp.
2.1. OpenStack Networking Service
2.1.1. Neutron Component
Trong hệ thống OpenStack, Networking Service hay Neutron được xem như là
một thành phần quan trọng không thể thiếu. Neutron giữ vai trò quản lý và chuyển tiếp
các gói tin bên trong và bên ngoài networking component ở mức độ hạ tầng [1].
Neutron cung cấp một lượng lớn các chức năng và các plug-in giúp người quản trị có
nhiều lựa chọn cho việc triển khai hệ thống OpenStack. Ngoài ra Neutron còn cung
cấp một lượng lớn API đầy đủ cho nhà phát triển để xây dựng các plug-in phục vụ cho
hệ thống.
Neutron có thể được xem như là một hệ thống tập trung được sử dụng trong môi
trường OpenStack để quản lý và vận hành các hạ tầng mạng ảo thuộc về tầng logic và
các hạ tầng mạng vật lý thuộc về tầng data access [2]. Nhờ Neutron, người quản trị có

thể xây dựng lên các mô hình mạng phức tạp, nâng cao và có thể bao gồm các dịch vụ
như load balancer, VPN,… [2].
Để làm được điều đó, Neutron sử dụng một tầng trung gian là Network
Abstraction. Theo đó, Network Abstraction hoạt động dựa theo nguyên lý của SDN
(Software-Defined Network) giúp ảo hóa hạ tầng mạng vật lý và cung cấp cho nhà
phát triển một bộ API để tương tác, quản lý và xây dựng các tài nguyên mạng ảo [3].
Nhờ vào nguyên lý đó mà người quản trị có thể tạo và sử dụng các thiết bị và tài
nguyên mạng mà không hề bị phụ thuộc và hạ tầng vật lý. Khi nào cần cải tiến và tối
ưu hiệu năng thì người quản trị chỉ cần bổ sung thiết bị phần cứng cho hệ thống,
Neutron sẽ đảm nhận việc ảo hóa và sử dụng phần cứng cho hạ tầng mạng logic.
Neutron có cung cấp hai mechanism_driver cho người quản trị khi cài đặt nhằm
phục vụ cho tầng Network Abstraction đó là OpenVSwitch (OVS) và linuxbridge (LB)
với ML2 core_plugin frame work. Cả OpenVSwitch và linuxbridge đều được sử dụng
14


để tạo ra các thiết bị bridge ảo chạy trên hệ điều hành Linux và có vai trò quan trọng
trong Linux Networking. Trong đó, OpenVSwitch là một công cụ được sử dụng rộng
rãi trong các hệ thống dựa trên mô hình SDN nhờ vào việc nó hỗ trợ OpenFlow, một
giao thức được chuẩn hóa phục vụ cho việc triển khai SDN. Tuy nhiên, mặc dù
linuxbridge ít được sử dụng để triển khai SDN như OpenVSwitch, linuxbridge lại có
một vài ưu điểm hơn so với OpenVSwitch như kích thước nhỏ và là một tính năng đã
được tích hợp sẵn và trong nhân của hệ điều hành Linux. Ngoài ra, Linuxbridge sử
dụng và triển khai đơn giản hơn OpenVSwitch. Do vậy, khóa luân này sẽ cài đặt
OpenStack Neutron và sử dụng linuxbridge làm mechanism_driver.
2.1.2. Network Abstraction trong Neutron với Linux Bridge Agent
Neutron linuxbridge mechanism_driver chỉ sử dụng các Linux bridge và các cặp
veth như các thiết bị kết nối của hệ thống mạng [4]. Theo đó, layer-2 agent của
Neutron Linux bridge quản lý tất cả các linux bridge trên các compute node trong hệ
thống OpenStack. Còn với các node khác trong hệ thống thì nó cung cấp giải pháp như

như layer-3 routing, DHCP, metadata service hay các dịch vụ mạng khác [4].
Trong OpenStack Networking có hai loại mạng, đó là provider network và selfservice network. Trong đó, provider network cho phép tạo các kết nối layer-2 cho các
máy ảo và hỗ trợ thêm các dịch vụ khác như DHCP và metadataservice. Các mạng
theo kiểu này ánh xạ trực tiếp vào hệ thống mạng layer-2 trong datacenter và thường
sử dụng chuẩn VLAN (802.1q) tagging để định danh và phân chia các mạng đó [5].
Các tác vụ mạng thuộc layer-3 được provider network chuyển thành trách nhiệm của
hạ tầng mạng vật lý. Trong các trường hợp thông thường, triển khai OpenStack là việc
thực hiện trong môi trường hỗn hợp giữa ảo hóa và hệ thống vật lý. Do mạng Provider
cần có sự can thiệp vào hạ tầng mạng vật lý nên mạng provider chỉ được tạo và quản
lý bởi người quản trị có đủ quyền hạn.
Bên cạnh provider network, self-service network là kiểu mạng cho phép người sử
dụng phổ thông tạo và quản lý mà không cần quyền quản trị cao nhất. Các mạng loại
này hoàn toàn là ảo và yêu cầu cần có các router ảo để có thể kết nối tới các mạng
provider và các mạng bên ngoài như Internet [5]. Seft-service cung cấp cho người sử
dụng nhiều lựa chọn về overlayer protocols như GRE, VXLAN hay VLAN. Tuy nhiên
trong hầu hết các trường hợp thì GRE và VXLAN được sử dụng nhiều hơn cả do nó có
thể tạo được nhiều subnet hơn so với giao thức phân mảnh gói tin thuộc layer-2 sử
dụng VLAN tagging (802.1q) [5].

15


2.1.3. Virtual Router trong Neutron
Trong OpenStack, để kết nối giữa các subnet với nhau cần phải tạo một kết nối
thuộc layer-3 giữa các subnet. Như đã biết thì việc định tuyến gói tin thuộc tầng mạng
là trách nhiệm của router. OpenStack Networking Service cũng hỗ trợ cho người sử
dụng tạo và quản lý các router ảo để cung cấp các kết nối thuộc layer-3 giữa các mạng.
Tuy nhiên, linuxbridge mechanism_driver chỉ có thể cung cấp các kết nối layer-2
cho hệ thống mạng của OpenStack. Do đó, Neutron đã hỗ trợ thêm một plug-in đảm
báo cho việc triển khai và quản lý các kết nối layer-3 đó là Neutron l3-agent. Plug-in

này đảm nhận cung cấp và quản lý các kết nối thuộc layer-3 cho các network. Cụ thể
hơn, l3-agent cung cấp các API để tạo và sử dụng các router ảo để kết nối các mạng
layer-2.

Hình 1. Neutron Networks với L3-agent [6]
L3-agent sử dụng đơn thuần Linux IP Stack và công cụ iptables để thực hiện các
chức năng của L3 như forwarding và NAT [6]. Đồng thời, Neutron l3-agent sử dụng

16


Linux networking namespace làm mặc định để cung cấp các môi trường định tuyến cô
lập giúp hỗ trợ cho người dùng tạo và sử dụng nhiều router cùng một lúc với các
không gian địa chỉ IP có thể bị trùng nhau [6]. Nhờ vào đặc điểm này của l3-agent, ta
có thể phát triển các dịch vụ, plug-in hỗ trợ cho l3-agent của Neutron.
2.2. Neutron FWaaS
Nhóm phát triển của Neutron cũng đã đưa ra phương án cho dịch vụ FWaaS cho
hệ thống OpenStack. Tuy nhiên, dịch vụ này vẫn chưa được hoàn thiện và hiện không
còn được phát triển và bảo trì do một số nguyên nhân và hiện tại hoàn toàn không còn
được hỗ trợ cho các phiên bản mới của OpenStack. Phiên bản mới nhất mà FWaaS v2
hỗ trợ là phiên bản OpenStack Ocata. Trong phạm vi khóa luận này, phiên bản
OpenStack được sử dụng là Stein và hai dịch vụ FWaaS v1 và v2 hoàn toàn không còn
được hỗ trợ cho hệ thống.
Tuy đã không còn được hỗ trợ nhưng ý tưởng về việc xây dựng và sử dụng dịch
vụ FWaaS tại các Virtual Router trong OpenStack Networking cũng đáng được quan
tâm. Ý tưởng về dịch vụ này có thể giúp cho hệ thống tăng cường về mặt an toàn dữ
liệu và sự tiện dụng cho người quản trị.
2.2.1. Neutron FWaaS v1
Neutron FWaaS v1 là phiên bản ban đầu của việc triển khai dịch vụ Firewall as a
Service của OpenStack Neutron. FWaaS v1 cung cấp sự phòng hộ cho các Virtual

Router [7]. Một khi mà Firewall được áp dụng cho Router thì toàn bộ các port thuộc
router sẽ được bảo vệ.

17


Hình 2. Hoạt động của Neutron FWaaS [7]
Cách hoạt động của FWaaS v1 cũng tương đối đơn giản nhưng lại đem lại hiệu
quả cao trong việc đảm bảo an toàn cho các mạng kết nối với router. FWaaS v1 sẽ
được cài đặt trên các Networking Node của hệ thống OpenStack, nơi mà các
OpenStack Router được cài đặt và hoạt động. FWaaS v1 chỉ cung cấp các chức năng
cơ bản của Firewall cơ bản thuộc layer-3 là lọc gói tin dựa trên các thông tin về port
ranges, protocols và IP address [7].
2.2.2. Neutron FWaaS v2
Neutron có cung cấp một phiên bản mới hơn của FWaaS v1 với tên gọi là FWaaS
v2. Theo đó, FWaaS v2 cung cấp nhiều dịch vụ chi tiết hơn so với phiên bản tiền
nhiệm [7]. Điểm đáng chú ý nhất của v2 đó là khái niệm về một firewall được thay thế
bởi khái niệm firewall group. Một firewall group là sự kết hợp của hai policy đó là:
ingress policy và egress policy [7]. Trong đó, ingress policy giúp kiểm soát luồng dữ
liệu vào trong router trước khi định tuyến.
Còn egress policy thì ngược lại, giúp
kiểm soát các luồng dữ liệu ra khỏi router sau khi xử lý và định tuyến.
Ngoài ra, trong phiên bản FWaaS v2, các firewall group không còn được áp dụng
ở mức router (áp dụng trên toàn bộ port của router) mà sẽ được áp dụng tại mức port
[7]. Theo đó, các router port có thể được gán với các firewall group. Bằng việc gán các

18


firewall group cho các port trên OpenStack Route, khả năng bảo vệ hệ thống của

FWaaS v2 tăng lên đáng kể khi mà các luồn dữ liệu được kiểm soát chặt chẽ hơn.
Tính năng
v1
Hỗ trợ L3 firewalling cho routers
YES
Hỗ trợ L3 firewalling cho router ports
NO
Hỗ trợ L2 firewallling
NO
Hỗ trợ CLI
YES
Hỗ trợ component Horizon (OpenStack Dashboard)
YES
Bảng 1. So sánh giữa FWaaS v1 và v2 [7].

v2
NO
YES
NO
YES
NO

Bảng trên đưa ra so sánh các tính năng đang được hỗ trợ bởi hai phiên bản của
dịch vụ FWaaS. Theo đó, cả hải dịch vụ đều không hỗ trợ tính năng L2 firewalling,
chặn các kết nối thuộc layer-2. Ngoài ra, phiên bản FWaaS v2 không hỗ trợ cho
OpenStack Dashboard mà chỉ hỗ trợ CLI khiến việc sử dụng các tính năng của dịch vụ
trở nên khó khăn, yêu cầu người quản trị cần phải truy cập vào hệ thống OpenStack
bằng CLI để làm việc.
2.2.3. Tình trạng phát triển hiện tại của plug-in Neutron FWaaS
FWaaS v2 của Neutron hiện đã bị ngừng phát triển kể từ sau phiên bản Pike của

OpenStack. Theo như thông báo của đội phát triển của Neutron thì tính năng FWaaS bị
ngừng phát triển một phần do sự thiết hụt nhân sự trong việc phát triển và bảo trì [8].
Một phần khác là do các tính năng mà FWaaS cung cấp hiện đang bị trùng với các tính
năng của Security Group, tính năng cần được hỗ trợ và bảo trì hơn [9]. Ngoài ra, dịch
vụ FWaaS hiện tại đang khá hạn chế và cần phải cải thiện đáng kể để có thể đáp ứng
được nhu cầu của người sử dụng [9].
Cho tới phiên bản hiện tại đang được khóa luận sử dụng của OpenStack là Stein
thì tính năng FWaaS đã hoàn toàn ngừng phát triển và không còn được hỗ trợ. Các
chức năng của dịch vụ FWaaS vẫn có thể được cài đặt bằng tay vào hệ thống mới
nhưng có thể gây ra lỗi hệ thống do khả năng không tương thích với các component
thuộc phiên bản mới của OpenStack.
2.2.4. Các vấn đề về Security Group trong Neutron
Security Group được xem như là một cơ chế bảo mật cơ bản của OpenStack.
Security Group là một tập hợp các luật lọc theo địa chỉ IP, layer-4 Port, … và có thể
được áp dụng cho tất cả các máy ảo trong dự án [10]. Security Group giữ nhiệm vụ
xác định và giới hạn các luồng truy cập ra vào các máy ảo. OpenStack Compute

19


Service hay Nova Component cho phép người sử dụng gán các Security Group vào
cho từng máy ảo kể cả khi khởi tạo hay khi máy ảo đã hoạt động. Mỗi máy ảo có thể
được gán cho một hoặc nhiều Security Group [11] tùy vào nhu cầu bảo mật của từng
máy ảo trong mạng. Nếu như người dùng không tạo Security Group hoặc không gán
Security Group vào máy ảo khi khởi tạo thì hệ thống sẽ tự động gán Security Group
Default vào máy ảo [11]. Và Security Group Default sẽ không thể bị xóa hay thay đổi
tên như các Security Group thông thường.
Có thể xem Security Group như một Firewall ảo cho các server chạy trong hệ
thống mạng của OpenStack. Mỗi Security Group bao gồm tập hợp các luật thuộc về
hai loại chính sách là: ingress policy và egress policy. Trong đó, tương tự như FWaaS

v2, ingress policy điều khiển các luồng truy cập vào bên trong server. Còn egress
policy quản lý các luồng truy cập đi ra ngoài mạng từ bên trong server. Các luồng truy
cập mà không thỏa mãn các luật được khai báo trong Security Group sẽ bị từ chối truy
cập theo mặc định [11].
Một điểm tương tự giữa dịch vụ FWaaS và Security Group đó là hỗ trợ các cơ
chế bảo mật thuộc layer-3 và layer-4. Trong đó, mỗi luật trong Security Group sẽ định
nghĩa các thông tin cơ bản của gói tin thuộc về tầng mạng trong mô hình mạng 7 tầng
của OSI và các hành động tương ứng với các gói tin khớp với các thông tin này. Các
luật khớp có thể là tên giao thức, địa chỉ IP, số hiệu Port. Đặc biệt bên trong biểu mẫu
thêm một luật của Security Group có cung cấp các mẫu gợi ý về các luật cho nhiều
dịch vụ như IMAP, POP3, HTTPS, DNS,... dựa vào số hiệu port mà các dịch vụ đó
thường sử dụng để triển khai trên hệ thống.
Mặc dù các Security Group đã có thể đảm bảo các chỉ tiêu an toàn cơ bản cho các
server chạy trên hệ thống OpenStack. Tuy nhiên, với các chức năng hiện tại của
Security Group cũng như FWaaS vẫn có thể chưa có khả năng đáp ứng đủ các nhu cầu
của người sử dụng. Một ví dụ đơn giản có thể được đặt ra đó là khi người sử dụng
muốn ngăn chặn các gói tin chỉ từ một máy chủ từ bên ngoài. Security Group và
FWaaS có thể ngăn chặn luồng truy cập của server này dựa trên địa chỉ IP. Tuy nhiên,
địa chỉ IP của server có thể thay đổi bất cứ lúc nào và người quản trị cần phải cập nhật
lại luật bảo mật cho Security Group. Điểm này rất bất tiện người quản trị khi phải thực
hiện cập nhật trên từng Security Group. Một ý tưởng được đặt ra đó là cài đặt luật lọc
gói tin hỗ trợ layer-2 filtering bằng việc lọc địa chỉ MAC của gói tin khi đi qua. Ý
tưởng này đảm bảo hơn so với việc lọc thông qua địa chỉ IP do server không thể thay
đổi địa chỉ MAC của riêng nó.

20


Ngoài ra, Security Group hiện tại hoạt động trong OpenStack Neutron ở mức độ
Port. Điểm này hoạt động rất tốt cho các dự án OpenStack nhỏ và vừa, cấu trúc mạng

còn đơn giản. Một khi mô hình mạng của dự án mở rộng với nhiều máy ảo và tài
nguyên mạng, số lượng port của hệ thống lớn và topo mạng sẽ tăng sự phức tạp. Khi
đó, để có thể đảm bảo an toàn cho hệ thống, người quản trị cần phải xây dựng một hệ
thống Security Group đủ tốt, đồng thời gán các Security Group vào các port tương
ứng. Việc này rất tốn thời gian và công sức khi phải xây dựng một tập hợp các
Security Group một cách đầy đủ và phân phối hợp lý trên các Port của hệ thống giúp
tránh cho việc tạo ra một hệ thống phức tạp và rắc rối. Bên cạnh đó, công việc quản trị
và bảo trì hệ thống cũng sẽ gặp nhiều khó khăn khi có lỗi xảy ra. Có thể người quản trị
cần phải kiểm tra lại toàn bộ các luật lọc gói tin bên trong các Security Group trên
từng Port để tìm giải pháp thích hợp.
2.3. Các nghiên cứu liên quan
Hiện đã có một vài nghiên cứu liên quan đến việc xây dựng các dịch vụ bảo mật
“as a Service” cho hệ thống các hệ thống Cloud, cụ thể hơn là OpenStack. Trong đó,
đã có rất nhiều nhóm nghiên cứu và triển khai các cải tiến cho một loại hình dịch vụ
bảo vệ là NIDS (Network Instrusion Detection System).
Các hệ thống NIDS có chức năng chính là phát hiện và giám sát các cuộc tấn
công trên mạng máy tính. Các hệ thống NIDS thường được triển khai ở trên một máy
trong mạng và hoạt động như một dịch vụ mạng. Khi đó, các luồng gói tin đi trong
mạng sẽ được “mirror” vào hệ thống NIDS và hệ thống sẽ phân tích dữ liệu gói tin,
phát hiện các truy cập trái phép và đưa ra các quyết định để bảo vệ hệ thống mạng.
Nhóm nghiên cứu của trường đại học Bakrie, Jakarta, Indonesia đã phát triển một hệ
thống NIDS dựa trên sử dụng phương pháp dựa trên chữ ký (signature-based) để xác
định dữ liệu gói tin cho một mạng private của OpenStack [12]. Một nhóm nghiên cứu
khác của trường đại học Tennessee, Chattanoog cũng đã xây dựng một hệ thống NIDS
cho OpenStack Cloud. Trong đó, họ phân tích sự tiêu thụ và tốn kém tài nguyên mạng
của các cơ chế kiểm soát mà các hệ thống NIDS sử dụng từ đó đề xuất ra một dịch vụ
nhỏ NIDS as a Service bằng việc sử dụng ít tài nguyên CPU hơn so với các dịch vụ
trước đó [13]. Tuy nhiên, các dịch vụ NIDS trên thường chiếm một lượng lớn tài
nguyên mạng như bộ nhớ, CPU và lưu lượng mạng. Đồng thời xây dựng các giải pháp
khá phức tạp và có ảnh hưởng rõ rệt tới hiệu năng truyền tải của mạng.

Ngoài các công trình nghiên cứu về loại hình hệ thống NIDS đã đề cập phía trên
thì Firewall cũng được một số nhóm nghiên cứu tham gia vào phân tích và phát triển

21


các dịch vụ Firewall as a Service dành cho hệ thống Cloud. Nhóm các nhà nghiên cứu
ở Banglore, Karnataka, Ấn Độ có triển khai một dịch vụ FWaaS sử dụng công cụ
Ansible để cung cấp cho người dùng một giao diện GUI giảm thiểu công sức và hạn
chế lỗi do người dùng gây ra và hỗ trợ cho trường hợp nhiều trường hợp khác nhau
của OpenStack Neutron trong môi trường multi cluster cloud [14]. Một nhóm nghiên
cứu khác đến từ Hungary và Slovakia có xây dựng một công cụ phân tích các luật
trong module FWaaS của OpenStack và cung cấp cho người dùng các thông tin dễ đọc
hơn để có thể tìm ra các lỗ hổng hệ thống và tăng cường bảo mật cho hệ thống [15].

22


CHƯƠNG 3: ĐỀ XUẤT GIẢI PHÁP
3.1. Dịch vụ FwaaS
Security Group bên trong OpenStack Networking đã có thể đáp ứng đủ nhu cầu
bảo mật cho hệ thống Cloud. Việc quản trị các traffic ra vào hệ thống trên các Port của
các thực thể mạng đủ đảm bảo cho các yêu cầu bảo mật hệ thống. Tuy nhiên, như đã
đề cập ở chương 2, việc sử dụng Security Group đem đến một vài điểm bất tiện khi
thao tác trên một hệ thống mạng với quy mô lớn và phức tạp. Một ví dụ đơn giản có
thể nhắc đến đó là khi thực hiện giới hạn luồng gói tin qua lại giữa các mạng. Với
Security Group cần phải thực hiện với các Security Group thuộc từng cụm Port tương
ứng. Khóa luận sẽ đề xuất một dịch vụ FWaaS ở mức độ Router mà tại đó, việc điều
khiển luồng gói tin qua các mạng sẽ chỉ cần thực hiện tại một điểm duy nhất đó là
Router thay vì từng Port. Ngoài ra, dịch vụ được đề xuất còn cung cấp các cơ chế bảo

mật thuộc nhiều tầng khác nhau thay vì chỉ lọc gói tin theo layer 3-4 mà Security
Group đã làm, giúp mở rộng khả năng bảo vệ hệ thống mạng của OpenStack.
Khóa luận này sẽ tập trung đi sâu vào phát triển dịch vụ FWaaS một cách hoàn
toàn độc lập với hệ thống OpenStack và có thể chạy trên hệ điều hành Linux như một
chương trình bình thường và thực hiện như một chức năng Firewall của hệ điều hành.
3.1.1. Đề xuất kiến trúc dịch vụ
Trước khi phát triển một phần mềm hay dịch vụ nào đó thì việc đầu tiên cần phải
làm là xây dựng kiến trúc cho dịch vụ đó. Do hệ thống OpenStack với component
Horizon (OpenStack Dashboard) được phát triển với kiến trúc của một ứng dụng Web
nên dịch vụ FWaaS mà khóa luận sẽ phát triển theo hướng xây dựng một ứng dụng
Web.
Như đã đề cập từ trước, trong phiên bản Stein của OpenStack chỉ cung cấp
Security Group làm giải pháp bảo mật cho cả hệ thống và còn đem lại nhiều bất lợi
cho người sử dụng cũng như chỉ cung cấp các cơ chế lọc gói tin cơ bản của layer-3 dựa
trên địa chỉ IP và số hiệu cổng. Cơ chế bảo mật trên có thể chấp nhận được khi cài đặt
cho từng máy ảo ở mức port. Tuy nhiên, do nhu cầu bảo vệ hệ thống ngày càng tăng
do sự phát triển không ngừng của công nghệ thông tin nên việc hỗ trợ các cơ chế bảo
mật mới của hệ thống OpenStack là cần phải có. Do đó, khóa luận sẽ đề xuất ra một cơ
chế mới hỗ trợ việc lọc gói tin trên nhiều layer trong mô hình mạng OSI.
Hình ảnh dưới đây sẽ mô tả cách mà dịch vụ FWaaS của khóa luận sẽ hoạt động.
Trong đó, mô hình triển khai với một Provider Network với nhiều Self-Service
23


Network là mô hình triển khai phổ biến hơn cả với OpenStack Neutron. Theo như hình
ảnh mô tả, dịch vụ FWaaS sẽ giữ vai trò quản trị và điều phối các Firewall nằm giữa
các mạng trong hệ thống. Nói cách khác, các Firewall này sẽ được dịch vụ cài đặt vào
trong các Router ảo mà Neutron tạo ra khi kết nối giữa các mạng trong hệ thống và
điều khiển các luồng dữ liệu vào ra trong mạng.


Hình 3. Mô tả hoạt động của dịch vụ FWaaS
Dịch vụ FWaaS sẽ hoạt động ở mức độ Router trong Neutron của hệ thống
OpenStack. Do đã phân tích từ trước, Security Group đã có thể đáp ứng tốt các yêu cầu
bảo mật ở mức độ Port của hệ thống. Dịch vụ FWaaS mà khóa luận phát triển sẽ chỉ
quan tâm tới việc xây dựng các Firewall hoạt động ở mức độ Router (hoạt động trên
toàn bộ các Port) và cung cấp thêm các tính năng filtering trên nhiều tầng khác của mô
hình 7 tầng OSI.
Cách thức hoạt động của dịch vụ khá đơn giản nhưng lại đem lại hiệu quả cao
trong việc tiết kiệm tài nguyên và tăng cường hiệu năng của hệ thống.

24


Hình 4. Cách thức hoạt động của dịch vụ FWaaS
Theo hình trên, dịch vụ Firewall sẽ giữ vai trò như một người điều phối giữa các
Router và người sử dụng. Dịch vụ sẽ cung cấp các API cho người sử dụng để tương tác
với người dùng. Một khi nhận các lệnh từ người quản trị, dịch vụ sẽ đi vào bên trong
các Router tương ứng và thực hiện thao tác trên bảng các luật lọc gói tin được cài đặt
bên trong Router này. Nhờ đó, các gói tin khi đi qua Router đều phải đi qua một dãy
các luật được cài dặt trên Router và chỉ được phép đi qua khi không vi phạm bất kỳ
luật nào trong các luật được cài đặt.
Đã đề cập đến từ trước, do OpenStack Dashboard Component sử dụng ứng dụng
web để cung cấp cho người dùng giao diện để tương tác nên dịch vụ FWaaS của khóa
luận cũng sẽ xây dựng theo kiến trúc ứng dụng Web đơn giản. Trong đó, server sẽ
cung cấp cho người dùng các file cần thiết của front-end của ứng dụng mỗi khi truy
cập vào cổng mà server đang chạy. Sau đó, người dùng sẽ tương tác với dịch vụ thông
qua ứng dụng front-end vừa tải. Mỗi khi thực hiện một thao tác trên giao diện, ứng
dụng front-end sẽ tạo các yêu cầu lên Web Service thông qua REST API. Khi nhận
được yêu cầu, Web Service sẽ chuyển yêu cầu cho Firewall Engine và Firewall Engine
sẽ thực hiện các yêu cầu lên bảng các luật bên trong các Router tương ứng với yêu cầu.


25