TRUNG TÂM ĐÀO TẠO AN NINH MẠNG ATHENA

----------------------oOo---------------------

HỆ THỐNG PHÁT HIỆN

VÀ
PHÒNG CHỐNG XÂM NHẬP

INTRUSION DETECTION
AND PREVENTION SYSTEM

Thực hiện : Nguyễn Thành Danh

Đinh Công Chinh
Lớp Security +
I. Tổng quan về IDS/IPS
1. Khái niệm về IDS/IPS
a. Định nghĩa :
Intrusion Detection system ( IDS ) là một hệ thống giám sát hoạt động trên hệ thống
mạng và phân tích để tìm ra các dấu hiệu vi phạm đến các quy định bảo mật máy tính,
chính sách sử dụng và các tiêu chuẩn an toàn thông tin. Các dấu hiệu này xuất phát từ rất
nhiều nguyên nhân khác nhau, như lây nhiễm malwares, hackers xâm nhập trái phép,
người dung cuối truy nhập vào các tài nguyên không được phép truy cập..v.v
Intrusion Prevention system ( IPS ) là một hệ thống bao gồm cả chức năng phát hiện xâm
nhập ( Intrusion Detection – ID ) và khả năng ngăn chặn các xâm nhập trái phép dựa trên
sự kết hợp với các thành phần khác như Antivirus, Firewall hoặc sử dụng các tính năng
ngăn chặn tích hợp.

2. Chức năng của IDS/IPS

a. Các ứng dụng cơ bản của hệ IDS/IPS :
(1) Nhận diện các nguy cơ có thể xảy ra
(2) Ghi nhận thông tin, log để phục vụ cho việc kiểm soát nguy cơ
(3) Nhận diện các hoạt động thăm dò hệ thống
(4) Nhận diện các yếu khuyết của chính sách bảo mật
(5) Ngăn chặn vi phạm chính sách bảo mật
b. Các tính năng chính của hệ IDS/IPS
(1) Lưu giữ thông tin liên quan đến các đối tượng quan sát
(2) Cảnh báo những sự kiện quan trọng liên quan đến đối tượng quan sát
(3) Ngăn chặn các tấn công ( IPS )
(4) Xuất báo cáo

3. Kiến trúc của hệ IDS/IPS

a. Các phương pháp nhận diện
Các hệ thống IDS/IPS thường dùng nhiều phương pháp nhận diện khác nhau, riêng rẽ
hoặc tích hợp nhằm mở rộng và tăng cường độ chính xác nhận diện. Có thể chia làm các
phương pháp nhận diện chính sau:

(1) Nhận diện dựa vào dấu hiệu ( Signature-base detection ):

sử dụng phương pháp so sánh các dấu hiệu của đối tượng quan sát với các dấu hiệu
của các mối nguy hại đã biết. Phương pháp này có hiệu quả với các mối nguy hại đã
biết nhưng hầu như không có hiệu quả hoặc hiệu quả rất ít đối với các mối nguy hại
chưa biết,các mối nguy hại sử dụng kỹ thuật lẩn tránh ( evasion techniques ), hoặc các
biến thể. Signature-based không thể theo vết và nhận diện trạng thái của các truyền
thông phức tạp.
(2) Nhận diện bất thường ( Abnormaly-base detection ):
so sánh định nghĩa của những hoạt động bình thường và đối tượng quan sát nhằm xác
định các độ lệch. Một hệ IDS/IPS sử dụng phương pháp Anormaly-base detection có
các profiles đặc trưng cho các hành vi được coi là bình thường, được phát triển bằng
cách giám sát các đặc điểm của hoạt động tiêu biểu trong một khoảng thời gian. Sau
khi đã xây dựng được tập các profile này , hệ IDS/IPS sử dụng phương pháp thống kê
để so sánh các đặc điểm của các hoạt động hiện tại với các ngưỡng định bởi profile
tương ứng để phát hiện ra những bất thường.
Profile sử dụng bởi phương pháp này có 2 loại là static và dynamic. Static profile
 không thay đổi cho đến khi được tái tạo, chính vì vậy dần dần nó sẽ trở nên không
chính xác, và cần phải được tái tạo định kỳ. Dynamic profile được tự động điều chỉnh
mỗi khi có các sự kiện bổ sung được quan sát, nhưng chính điều này cũng làm cho nó
trở nên dễ bị ảnh hưởng bởi các phép thử dung kỹ thuật giấu ( evasion techniques )
Ưu điểm chính của phương pháp này là nó rất có hiệu quả trong việc phát hiện ra các
mối nguy hại chưa được biết đến.

Sự khác biệt giữa phương pháp Abnormaly-base và Signature-base

(3) Phân tích trạng thái giao thức ( Stateful protocol analysis ) :
Phân tích trạng thái protocol là quá trình so sánh các profile định trước của hoạt động
của mỗi giao thức được coi là bình thường với đối tượng quan sát từ đó xác định độ
lệch. Khác với phương pháp Anomaly-base detection, phân tích trạng thái protocol
dựa trên tập các profile tổng quát cung cấp bởi nhà sản xuất theo đó quy định 1
protocol nên làm và không nên làm gì. "Stateful" trong phân tích trạng thái protocol
có nghĩa là IDS/IPS có khả năng hiểu và theo dõi tình trạng của mạng, vận chuyển, và
các giao thức ứng dụng có trạng thái.
Nhược điểm của phương pháp này là chiếm nhiều tài nguyên do sự phức tạp trong
việc phân tích và theo dõi nhiều phiên đồng thời. Một vấn đề nghiêm trọng là phương
pháp phân tích trạng thái protocol không thể phát hiện các cuộc tấn công khi chúng
không vi phạm các đặc tính của tập các hành vi chấp nhận của giao thức.

b. Cơ sở hạ tầng của IDS/IPS

Nhiệm vụ chính của hệ thống IDS/IPS là phòng thủ máy tính bằng cách phát hiện một
cuộc tấn công và có thể đẩy lùi nó. Phát hiện vụ tấn công thù địch phụ thuộc vào số
lượng và loại hành động thích hợp.

Intrusion detection system activities

 Công tác phòng chống xâm nhập đòi hỏi một sự kết hợp tốt được lựa chọn của "mồi
và bẫy" nhằm điều tra các mối đe dọa, nhiệm vụ chuyển hướng sự chú ý của kẻ xâm
nhập từ các hệ thống cần bảo vệ sang các hệ thống giả lập là nhiệm vụ của 1 dạng
IDS riêng biệt ( Honeypot IDS ),cả hai hệ thống thực và giả lập được liên tục giám sát
và dữ liệu thu được được kiểm tra cẩn thận (đây là công việc chính của mỗi hệ
IDS/IPS ) để phát hiện các cuộc tấn công có thể (xâm nhập).
Một khi xâm nhập một đã được phát hiện, hệ thống IDS/IPS phát các cảnh báo đến
người quản trị về sự kiện này. Bước tiếp theo được thực hiện, hoặc bởi các quản trị
viên hoặc bởi chính hệ thống IDS/IPS , bằng cách áp dụng các biện pháp đối phó
(chấm dứt phiên làm việc, sao lưu hệ thống, định tuyến các kết nối đến Honeypot IDS
hoặc sử dụng các cơ sở hạ tầng pháp lý v.v) – tùy thuộc vào chính sách an ninh của
mỗi tổ chức

Intrusion detection system infrastructure

Hệ thống IDS/IPS là một thành phần của chính sách bảo mật. Trong số các nhiệm vụ IDS
khác nhau, nhận dạng kẻ xâm nhập là một trong những nhiệm vụ cơ bản. Nó có thể hữu ích
trong các nghiên cứu giám định sự cố và tiến hành cài đặt các bản patches thích hợp để cho
phép phát hiện các cuộc tấn công trong tương lai nhắm vào mục tiêu cụ thể

c. Cấu trúc & kiến trúc của hệ IDS/IPS

(1) Các thành phần cơ bản
(a) Sensor / Agent :
giám sát và phân tích các hoạt động. “Sensor” thường được dùng cho dạng
Network-base IDS/IPS trong khi “Agent” thường được dùng cho dạng
Host-base IDS/IPS
(b) Management Server :
là 1 thiết bị trung tâm dùng thu nhận các thông tin từ Sensor / Agent và quản lý
chúng. 1 số Management Server có thể thực hiện việc phân tích các thông tin sự
việc được cung cấp bởi Sensor / Agent và có thể nhận dạng được các sự kiện này
dù các Sensor / Agent đơn lẻ không thể nhận diện.
(c) Database server :
dùng lưu trữ các thông tin từ Sensor / Agent hay Management Server
(d) Console :
là 1 chương trình cung cấp giao diện cho IDS/IPS users / Admins. Có thể cài đăt
trên một máy tính bình thường dùng để phục vụ cho tác vụ quản trị, hoặc để giám
sát, phân tích.
(2) Kiến trúc của hệ IDS/IPS
Sensor là yếu tố cốt lõi trong một hệ thống IDS/IPS , nó mà có trách nhiệm phát hiện các
xâm nhập nhờ chứa những cơ cấu ra quyết định đối với sự xâm nhập. Sensor nhận
dữ liệu thô từ ba nguồn thông tin chính : kiến thức cơ bản ( knowledge base ) của
IDS, syslog và audit trail .Các thông tin này tạo cơ sở cho quá trình ra quyết định sau
này

Một ví dụ về hệ IDS. Chiều rộng mũi tên là tỷ lệ thuận với số lượng thông tin di
chuyển giữa các thành phần của hệ thống

Sensor được tích hợp với các thành phần chịu trách nhiệm thu thập dữ liệu - một
event generator. Dựa vào các chính sách tạo sự kiện nó xác định chế độ lọc thông tin
thông báo sự kiện. Các event generator (hệ điều hành, mạng, ứng dụng) tạo ra một
chính sách nhất quán tập các sự kiện có thể là log hoặc audit của các sự kiện của hệ
thống, hoặc các gói tin. Điều này, thiết lập cùng với các thông tin chính sách có thể
được lưu trữ hoặc là trong hệ thống bảo vệ hoặc bên ngoài. Trong những trường hợp
nhất định, dữ liệu không được lưu trữ mà được chuyển trực tiếp đến các phân tích
( thông thường áp dụng với các gói packet ).

Các thành phần chính của 1 hệ IDS/IPS

 Các hệ thống IDS/IPS có thể được triển khai theo 2 hướng là tập trung và phân tán.
Một ví dụ cụ thể cho hướng triển khai tập trung là tích hợp IDS/IPS cùng với các
thành phần an ninh khác như firewall. Triển khai phân tán ( distributed IDS ) bao
gồm nhiều hệ IDS/IPS trong 1 hệ thống mạng lớn, được kết nối với nhau nhằm nâng
cao khả năng nhận diện chính xác xâm nhập và đưa ra phản ứng thích hợp

II. Phân loại IDS/IPS

Phân loại các hệ IDS/IPS

1. Host-based IDS/IPS

Mô hình vị trí của HIDS/IPS trong 1 hệ thống mạng

Được triển khai trên từng host,thông thường là 1 software hoặc 1 agent, mục tiêu là giám
sát các tính chất cơ bản, các sự kiện liên quan đến các thành phần này nhằm nhận diện
các hoạt động khả nghi. Host-based IDS/IPS thường được triển khai trên các host có tính
chất quan trọng ( public servers, sensitive data servers ), hoặc 1 dịch vụ quan trọng
( trường hợp đặc biệt này được gọi là application-based IDS/IPS ).
Quá trình triển khai các agent HIDS/IPS thường đơn giản do chúng là một phần mềm
được cài đặt trực tiếp lên host. Application-based agent thường được triển khai thẳng
hàng ngay phía trước host mà chúng bảo vệ.

Mô hình triển khai Host-based IDS/IPS agent

Một trong những lưu ý quan trọng trong việc triển khai hệ thống Host-based IDS/IPS là
cân nhắc giữa việc cài đặt agent lên host hay sử dụng agent-based appliances.
Trên phương diện phát hiện và ngăn chặn xâm nhập, việc cài đặt agent lên host được
khuyến khích vì agent tương tác trực tiếp với các đặc tính của host và qua đó có thể phát
hiện và ngăn chặn 1 cách hiệu quả hơn. Tuy nhiên, do agent thường chỉ tương thích với 1
số hệ điều hành nhất định nên trong trường hợp này người ta sử dụng thiết bị. Một lý do
khác để sử dụng thiết bị là việc cài đặt agent lên host có thể ảnh hưởng đến performance
của host.
Hệ thống HIDS/IPS cung cấp các khả năng bảo mật sau:
(1) Khả năng ghi log.
(2) Khả năng phát hiện
(a) Phân tích mã ( phân tích hành vi mã, nhận diện buffer-overflow, giám sát hàm gọi
hệ thống, giám sát danh sách ứng dụng và hàm thư viện )
(b) Phân tích và lọc lưu lượng mạng
(c) Giám sát filesystem ( kiểm tra tính toàn vẹn,thuộc tính,truy cập của file )
(d) Phân tích log
(e) Giám sát cấu hình mạng
 (3) Khả năng ngăn chặn
(a) Phân tích mã: ngăn chặn thực thi mã độc
(b) Phân tích và lọc lưu lượng mạng: ngăn chặn truy cập, lưu mã độc, chặn các dịch
vụ hoặc giao thức không được phép
(c) Giám sát filesystem: ngăn chặn việc truy cập, thay đổi filesystem
(4) Các khả năng bảo vệ khác: ngăn chặn truy cập đến các removeable-media, củng cố
bảo mật cho host, giám sát trạng thái các tiến trình…

Các sản phẩm đại diện : Tripware, OSSEC, BroIDS, ISS, Samhain, Prelude-LML,Snort

2. Network-bases IDS/IPS

Mô hình vị trí của NIDS/IPS trong 1 hệ thống mạng

Thường dùng để giám sát, phân tích hoạt động hệ thống mạng trong 1 segment, phân tích
mạng, các giao thức ứng dụng từ đó nhận diện các hoạt động khả nghi. Thường được
triển khai ở các biên mạng ( network border ).
Hệ thống NIDS/IPS thường được triển khai trong 1 đoạn / mạng con riêng phục vụ cho
mục đích quản trị hệ thống ( management network ), trong trường hợp không có mạng
quản trị riêng thì 1 mạng riêng ảo ( VLAN ) là cần thiết để bảo vệ các kết nối giữa các hệ
NIDS/IPS.
Bên cạnh việc lựa chọn vị trí mạng phù hợp cho các thành phần của hệ NIDS/IPS, lựa
chọn vị trí phù hợp cho các Sensor cũng là 1 vấn đề quan trọng ảnh hưởng đến khả năng
detection của hệ NIDS/IPS. Trong hệ NIDS/IPS, các Sensor thường gặp ở 2 dạng là tích
hợp phần cứng ( appliance-based ) và phần mềm ( software-only ).

Người ta thường sử dụng 2 kiểu triển khai sau:

Thẳng hàng ( Inline ):

1 Sensor thẳng hàng được đặt sao cho các lưu lượng trên mạng mà nó giám sát đi xuyên
qua nó giống như trong trường hợp cùa firewall. Thực tế là 1 số Sensor thẳng hàng được
sử dụng như 1 loại lai giữa firewall và NIDS/IPS, một số khác là NIDS thuần túy. Động
cơ chính của việc triển khai Sensor kiểu thẳng hàng là nó có thể dừng các tấn công bằng
việc chặn lưu lượng mạng ( blocking network traffic ).
Sensor thẳng hàng thường được triển khai tại vị trí tương tự với firewall và các thiết bị
bảo mật khác: ranh giới giữa các mạng.

Mô hình triển khai Sensor kiểu thẳng hàng

Sensor thẳng hàng còn có thể được triển khai tại các vùng mạng kém bảo mật hơn hoặc
phía trước các thiết bị bảo mật hoặc firewall để bảo vệ và giảm tải cho các thiết bị này.

Thụ động ( Passive ):

Sensor kiểu thụ động được triển khai sao cho nó có thể giám sát 1 bản sao của các lưu
lượng trên mạng. Thường được triển khai giám sát các vị trí quan trọng trong mạng như
ranh giới giữa các mạng, các đoạn mạng quan trọng ví dụ như Server farm hoặc DMZ.
Sensor thụ động có thể giám sát lưu lượng mạng qua nhiều cách như Spanning port (
hoặc Mirror port ), Network tap hoặc IDS loadbalancer.

Mô hình triển khai Sensor kiểu thụ động

Hệ thống NIDS/IPS cung cấp các khả năng về bảo mật sau:
(1) Khả năng thu thập thông tin
(a) Nhận dạng host
(b) Nhận dạng hệ điều hành
(c) Nhận dạng ứng dụng
(d) Nhận dạng đặc điểm mạng
(2) Khả năng ghi log
(3) Khả năng nhận diện
(a) Hoạt động thăm dò và tấn công trên các lớp ứng dụng,vận chuyển và mạng
(b) Các dịch vụ ứng dụng không mong đợi ( unexpected application services )
(c) Vi phạm chính sách ( policy violations )
(4) Khả năng ngăn chặn
(a) Kiểu thụ động: ngắt phiên TCP hiện tại
(b) Kiểu thẳng hàng: thực hiện tác vụ firewall thẳng hàng, điều tiết băng thông sử
dụng, loại bỏ các nội dung gây hại
(c) Ngoài ra chức năng ngăn chặn còn có thể thay đổi cấu hình của 1 số thiết bị bảo
mật cũng như thực thi các ứng dụng thứ 3 hoặc các script.

Lưu ý khi triển khai NIDS/IPS: khi triển khai các hệ NIDS/IPS, 1 trong những điểm cần
lưu ý là phải triển khai các Sensor ở dạng ẩn ( Stealth mode ). Trong dạng này, các
interface của Sensor không được gán địa chỉ IP ( trừ interface quản lý ) để tránh việc khởi
tạo kết nối từ các host khác nhằm ẩn Sensor khỏi sự phát hiện của kẻ tấn công.

Điểm yếu của hệ thống NIDS/IPS chính là việc nó rất dễ bị ảnh hưởng bởi nhiều loại tấn
công liên quan đến khối lượng lưu lượng mạng lớn ( large volume of network traffic ) và
kiến trúc Single-point of Failure khi triển khai Sensor kiểu thẳng hàng.

So sánh giữa HIDS va NIDS

Chức năng HIDS NIDS Ghi chú

Bảo vệ với mạng **** **** Cả hai loại đều có khả năng bảo vệ trong mạng
Bảo vệ không mạng **** NIDS chỉ hoạt động trong môi trường mạng
Dễ quản trị **** ****
Độ linh hoạt **** ** NIDS kém linh hoạt vì liên quan đến hạ tầng mạng
Giá *** * Chọn HIDS có lợi hơn nếu đúng yêu cầu bảo vệ
Triển khai **** **** Cả HIDS và NIDS đều dễ triển khai
Đào tạo sử dụng **** ** NIDS cần đào tạo nhiều hơn để có thể sử dụng
Cost of Ownership *** ** Chi phí cho HIDS rẻ hơn với thời gian sử dụng dài
Băng thông mạng 0 2 NIDS chiếm băng thông mạng , HIDS thì không
Tổng chi phí mạng 1 2 NIDS chiếm gấp đôi chi phí mạng
Spanning port **** NIDS cần có spanning port để quét network traffic
Database update **** ** HIDS luôn tự động cập nhật cho clients
Tương thích ** **** NIDS có sự tương thích với các nền tảng khác nhau
Registry scan **** HIDS có khả năng quét registry
Logging *** ***
Cảnh báo *** ***
Packet rejection **** Chỉ NIDS mới có chức năng loại bỏ packet
Yêu cầu kiến thức riêng *** **** NIDS yêu cầu nhiều kiến thức để cài đặt và vận hành tốt
Quản lý tập trung *** **** NIDS có tính quản lý tập trung cao hơn
Nguy cơ bị vô hiệu hóa * **** NIDS có nguy cơ cao vì là Singe-point-of-Failure
Multiple LAN detection **** ** HIDS có khả năng detect trên nhiều đoạn mạng hơn NIDS
 Trong thực tế, NIDS/IPS thường được sử dụng tại biên mạng nhằm phát hiện các dấu
hiệu tấn công và hạn chế các tấn công này ở mức network. Đối với những máy chủ hoặc
máy client quan trọng, việc bổ sung HIDS cho các máy này là cần thiết để tăng cường
khả năng bảo mật khi kết hợp với các hệ NIDS trong cùng hệ thống.

Các sản phẩm đại diện : Snort, ISS, Juniper IDS, Tipping Point IDS, Trustware ipAgent,
Cisco IPS, Reflex Security

3. Wireless IDS/IPS

Thường được triển khai trong tầm phủ sóng wireless của hệ thống nhằm giám sát,phân
tích các protocol wireess để nhận diện các hoạt động khả nghi.
Sự khác biệt lớn nhất giữa NIDS/IPS và Wireless IDS/IPS nằm ở việc NIDS/IPS có thể
giám sát tất cả các packet trong mạng thì Wireless IDS/IPS giám sát bằng cách lấy mẫu
lưu lượng mạng.
Sensor trong hệ thống Wireless IDS/IPS sử dụng 1 kỹ thuật gọi là quét kênh ( channel
scanning ), nghĩa là thường xuyên đổi kênh giám sát. Để hỗ trợ cho việc giám sát hiệu
quả, các Sensor có thể được trang bị nhiều antenna thu phát công suất cao.

Wireless Sensor thường gặp dưới 3 hình thức là

Chuyên biệt ( Dedicated ) :

thường ở dạng thụ động, được vận hành dưới dạng giám sát tần số phát ( radio frequency
monitoring mode ), được triển khai theo 2 dạng là cố định ( thiết bị ) và di động ( phần
mềm hoặc thiết bị ).

Tích hợp trong Access Point

Tích hợp trong Wireless switch

Mô hình triển khai Wireless IDS/IPS

 Vấn đề vị trí triển khai Wireless IDS/IPS là 1 vấn đề cơ bản, khác biệt hoàn toàn so với
các loại Sensor trong các hệ thống NIDS/IPS hay HIDS/IPS do đặc thù của mạng
Wireless. Thông thường các Wireless IDS/IPS thường được triển khai ở các khu vực mở của
hệ thống mạng ( khu vực khách, công cộng … ), ở các vị trí có thể giám sát toàn bộ vùng
sóng của mạng Wireless, hay được triển khai để giám sát trên 1 số băng tần và kênh
xác định.

Hệ thống NIDS/IPS cung cấp các khả năng về bảo mật sau:
(1) Khả năng bảo mật
(2) Khả năng thu thập thông tin
(a) nhận diện thiết bị Wireless
(b) nhận diện mạng Wireless
(3) Khả năng ghi log
(4) Khả năng nhận diện
(a) nhận diện các mạng và thiết bị Wireless trái phép
(b) nhận diện các thiết bị Wireless kém bảo mật
(c) nhận diện các mẫu sử dụng bất thường
(d) nhận diện các hoạt động của wireless scanner
(e) nhận diện các tấn công từ chối dịch vụ DoS qua cơ chế phân tích trạng thái giao
thức ( Stateful protocol analysis ) và nhận diện bất thường ( Abnormaly detection)
(f) nhận diện các tấn công đóng giả và Man-in-the-Middle.

Hệ thống Wireless IDS/IPS có khả năng xác định vị trí vật lý của mối đe dọa được
nhận diện bằng phương pháp đo tam giác ( triangulation ) dựa vào mức tín hiệu từ mối
đe dọa đến Sensor và từ đó tính ra được vị trí tương đối của mối đe dọa đối với
mỗi Sensor.
(5) Khả năng ngăn chặn ( ngắt kết nối wireless, tác động đến switch để chặn kết nối từ
Access Point hoặc Station nghi ngờ là nguồn tấn công ).

Tuy nhiên, cũng như mạng Wireless, Wireless IDS/IPS cũng rất nhạy cảm với các dạng
tấn công từ chối dịch vụ cũng như các tấn công sử dụng kỹ thuật lẩn tránh ( evasion
techniques ).

Các sản phẩm đại diện : WIDZ, AirMagnet, AirDefense, Snort-Wireless…

4. Network behavior Analysis system ( NBAS )

Là 1 dạng NIDS/IPS được triển khai trong hệ thống mạng nhằm nhận diện các threats tạo
ra các luồng traffic bất thường trong hệ thống ( DDoS, malwares… ). Thường được dùng
để giám sát luồng traffic trong hệ thống nội bộ cũng như có thể giám sát luồng traffic
giữa hệ thống trong và các hệ thống ngoài.
 Mô hình triển khai NBAS

Khác biệt giữa NBAS và NIDS/IPS ở chỗ NBAS phân tích lưu lượng mạng hoặc các
thống kê trên lưu lượng mạng để nhận diện các luồng lưu lượng bất thường.

Hệ thống NBAS có thể được triển khai dưới 2 dạng là thụ động và thẳng hàng. Với kiểu
triển khai thụ động, được triển khai tại các vị trí cần giám sát như ranh giới mạng, các
đoạn mạng quan trọng. Với kiểu thẳng hàng, tương tự như NIDS/IPS, có thể triển khai sát
với firewall biên, thường là phía trước để giảm thiểu số lượng các tấn công đến có thể
làm quá tải firewall biên.

5. Honeypot IDS

Mô hình vị trí của Honeypot IDS trong 1 hệ thống mạng

 Là 1 dạng IDS dựa trên phương pháp “mồi” & “bẫy”, tạo ra các hệ thống giả lập tương tự
các hệ thống chính nhằm chuyển hướng tấn công của attacker vào hệ thống giả lập này từ
đó quan sát dấu vết và truy vết tấn công.

III. Cài đặt và cấu hình thử nghiệm IDS/IPS với Snort

1. Giới thiệu chung về Snort

Snort được phát triển năm 1998 bởi Sourcefire và CTO Martin Roesch, là 1 phần mềm miễn
phí mã nguồn mở có khả năng phát hiện và phòng chống xâm nhập trái phép vào hệ thống
mạng có khả năng phân tích thời gian thực lưu lượng mạng, và ghi log gói tin trên nền mạng
IP. Ban đầu được gọi công nghệ phát hiện và phòng chống xâm nhập hạng nhẹ, Snort đã dần
phát triển và trở thành tiêu chuẩn trong việc phát hiện và phòng chống xâm nhập. Với hơn
3,7 triệu lượt tải về và hơn 250 ngàn người dùng đăng ký, Snort trở thành công nghệ phát
hiện và phòng chống xâm nhập được sử dụng rộng rãi nhất hiện nay.

Snort có thể thực hiện phân tích giao thức và tìm kiếm nội dung, từ đó có thể phát hiện rất
nhiều kiểu thăm dò và tấn công như buffer-overflow, stealth ports scanning, tấn công CGI,
OS fingerprint, thăm dò SMB..v.v. Để có thể làm được điều này, Snort dùng 1 loại ngôn ngữ
mô tả các quy tắc giao thông mạng mà nó sẽ thu thập hoặc bỏ qua, cũng như sử dụng cơ chế
phát hiện xâm nhập theo kiến trúc modular plug-ins. Nó cũng có khả năng cảnh báo tức thời,
kết hợp với các cơ chế cảnh báo syslog, tập tin người dùng chỉ định, Unix socket hoặc
Winpopup message.
Snort có thể sử dụng với 3 kiểu chính :
- Packet sniffer như tcpdump
- Packet logger
- Hệ thống phát hiện và phòng chống xâm nhập hoàn chỉnh.

2. Chuẩn bị môi trường ( system prerequisites )

Hệ điều hành : Ubuntu Linux 9

Các gói phần mềm hỗ trợ :
MySQL
Libnet 1.0.2a
Libpcap 0.8
BASE 1.4.4
Barnyard2
Apache

3. Cài đặt Snort ( Installing Snort )

Sau khi cài đặt xong hệ điều hành,giả sử ta tạo 1 user tên là ids_usr và login. Mở CLI, login
as root user

Sudo bash

Việc đăng nhập root user nhằm mục đích thuận lợi cho quá trình cài đặt, không phải dùng
lệnh sudo, cũng như dễ dàng truy cập các thư mục hệ thống.
Cài đặt các gói phần mềm hỗ trợ :

• mysql-client-5.0
• mysql-server-5.0
• libpcap0.8-dev
• libmysqlclient15-dev
• bison
• flex
• apache2
• libapache2-mod-php5
• php5-gd
• php5-mysql
• libtool
• libpcre3-dev
• php-pear
• ssh

Mở CLI, dùng lệnh :

Apt-get install <package>

Trong đó package là các gói phần mềm bên trên.

Download các gói phần mềm sau

- Download libnet-1.0.2a.tar.gz from http://www.filewatcher.com/m/libnet-

1.0.2a.tar.gz.140191.0.0.html.
- B.A.S.E ( Basic Analysis and Security Engine ) cung cấp giao diện Web cho việc truy
vấn và phân tích các cảnh báo từ Snort. Download B.A.S.E 1.4.4 tại :
http://sourceforge.net/projects/secureideas/files/
- ADOdb là 1 tiện ích trừu tượng hóa cơ sở dữ liệu, cho phép nhiều kiểu tương tác giữa
PHP và cơ sở dữ liệu. Download ADOdb 5.10 tại :
http://sourceforge.net/projects/adodb/files/
- Đăng ký làm thành viên của Snort, sau đó download gói rules cho Snort ở đây :
http://www.snort.org/snort-rules . Lưu ý là có 2 gói rules, 1 gói dành cho người dùng trả
tiền ( Subscription release ) và 1 gói miễn phí cho người dùng đăng ký ( registered-user
release ). Điểm khác biệt duy nhất là gói miễn phí sẽ được cung cấp sau gói trả phí 30
ngày.

Giả dụ các gói phần mềm được tải về và lưu tại desktop.

Cài đặt Libnet

- cd /usr/local
- tar zxvf /home/ids_usr/Desktop/libnet-1.0.2a.tar.gz
- cd Libnet-1.0.2a
- ./configure && make && make install
Cài đặt Snort

Sudo apt-get install snort-mysql

Ghi chú:

1. Trong quá trình cài đặt Snort bằng lệnh apt-get install, lưu ý khi quá trình cài đặt MySQL
xuất hiện, ta phải ghi nhớ mật khẩu root của database
2. Ngoài phương pháp install Snort bằng apt-get install, ta có thể download phiên bản mới
nhất của Snort tại : http://www.snort.org/downloads ( phiên bản mới nhất là 2.8.5.1 ) , sau đó
biên dịch :

- cd /usr/local
- tar zxvf /home/ids_usr/Desktop/snort-2.8.5.1.tar.gz
- cd snort-2.8.5.1
- ./configure --enable-targetbased && make && make install

Tuy nhiên, trong thực tế , tác giả gặp vấn đề với Snort cài đặt theo kiểu biên dịch mã nguồn
khi thực thi Snort ở phần sau xuất hiện thông báo “ mysql support is not compiled in this
build of snort “

Chuẩn bị môi trường làm việc cho Snort

- mkdir /etc/snort
- mkdir /var/log/snort
- mkdir /usr/local/lib/snort_dynamicrules
- cd /etc/snort
- tar zxvf /home/ids_usr/Desktop/snortrules-snapshot-CURRENT_s.tar.gz -C
/etc/snort
- cp /etc/snort/etc/* /etc/snort
- groupadd snort
- useradd -g snort snort
- chown snort:snort /var/log/snort
- touch /var/log/snort/alert
- chown snort:snort /var/log/snort/alert
- chmod 600 /var/log/snort/alert
- cp /etc/snort/so_rules/precompiled/Ubuntu-6.01.1/i386/2.8.4/*.so
/usr/local/lib/snort_dynamicrules
- cp –R /usr/lib/snort_* /usr/local/lib

Cấu hình MySQL

MySQL được dùng như Cơ sở dữ liệu cho Snort. Mặc dù nó không cần thiết để chạy Snort
nhưng nó làm cho việc truy vấn các sự kiện một cách dễ dàng hơn và cần thiết để B.A.S.E có
thể hoạt động.
 - mysql –p
- <nhập DB root password>
- create database snort;
- grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to
snort@localhost;
- SET PASSWORD FOR snort@localhost=PASSWORD(‘password’);
- exit
- cd /usr/local/snort-2.8.5.1/schemas
- mysql -p < create_mysql snort

Kiểm tra lại cấu hình cơ sở dữ liệu để chắc chắn cơ sở dữ liệu cho Snort đã được config đúng

- mysql –p
- < nhập DB root password >
- Show tables;
Xuất hiện 4 hàng dữ liệu ( row )
- Use snort;
- Show tables;
Xuất hiện 16 hàng dữ liệu ( row )

Chỉnh sửa file snort.conf

Snort.conf quy định cách thức Snort sẽ thực thi 1 khi được chạy. Ở cấu hình nâng cao sẽ đề
cập đến việc chỉnh sửa file snort.conf một cách cụ thể hơn. Ở đây ta chỉ chỉnh sửa 1 số tính
năng đơn giản

- Gedit /etc/snort/snort.conf
- Tìm dòng RULE_PATH và đổi thành /etc/snort/rules
- Tìm dòng “output log_unified” và thêm dòng sau đây phía dưới nó :
output log_unified2: filename snort.log, limit 128
Lưu ý : “unified2” chỉ ra format cho file log là version 2, dùng kết hợp với
Barnyard2.
- Tìm dòng “output database:” và thêm dòng sau đây phía dưới nó :
output database: alert, mysql, user=snort password=< password> dbname=snort
host=localhost

Cấu hình giao diện Web với ADOdb và B.A.S.E

Ta sẽ lần lượt giải nén ADObd, B.A.S.E vào thư mục Webroot, sau đó tiến hành cấu hình
cho ADOdb và B.A.S.E

- cd /var/www
- pear channel-update pear.php.net
- pear install Mail
- pear install Mail_Mime
- pear install Image_Canvas-0.3.2
- pear install Image_Graph-0.7.2
- tar zxvf /home/ids_usr/Desktop/adodb510.tgz
 - tar zxvf /home/ids_usr/Desktop/base-1.4.4.tar.gz
- gedit /etc/php5/apache2/php.ini
- Tìm dòng error_reporting. Kiểm tra xem nó có được thiết lập :
error_reporting = E_ALL & ~E_NOTICE hay không
- Tìm “Dynamic Extensions”. Thêm dòng này vào bên trong mục đó :
extension=mysql.so
extension=gd.so
- gedit /etc/apache2/apache2.conf
- Tại cuối file,thêm dòng
servername <your servername.domain>
- /etc/init.d/apache2 restart

Mở trình duyệt, tại thanh địa chỉ, nhập vào địa chỉ :
http://localhost/base-1.4.4

- Click “continue”
- Đường dẫn đến thư mục chứa ADOdb là /var/www/adodb
- Database Name=snort, Database Host=localhost, Database User=snort, Database
Password=password
- Admin User Name=snort, Password=<password>, Full Name=snort
- Click “Create BASE AG”.
Sau khi kết thúc, nếu có lỗi không ghi được file ta copy nội dung, sau đó dùng
gedit để tạo file và paste nội dung vừa copy vào.

 Gedit /var/www/base-1.4.4/base-conf.php
 Paste và Save

Cấu hình Barnyard2

Barnyard được viết nhằm mục đích đảm nhận các tác vụ xử lý xuất để Snort có thể dành nhiều
tài nguyên hơn cho việc xử lý các gói tin.

- cd /usr/local
- tar zxvf /home/ids_usr/Desktop/barnyard2-1.7.tar.gz
- cd barnyard2-1.7
- ./configure --with-mysql && make && make install
- cp /usr/local/barnyard2-1.7/etc/barnyard2.conf /etc/snort
- gedit /etc/snort/barnyard2.conf
- Tìm “thor” và thay thế bằng “localhost”
- Kiểm tra config interface để chắc chắn đang sử dụng interface “eth0”
- Tìm dòng “output database” và thay bằng :
output database: alert, mysql, user=snort password=<password> dbname=snort
host=localhost
Khởi động Snort và hoàn tất cấu hình Barnyard

- snort -c /etc/snort/snort/conf -i eth0

- Open a second CLI.
- Mkdir /var/log/barnyard2
- ls -la /var/log/snort.
Để ý 10 chữ số sau file snort.log sau cùng
- gedit /var/log/snort/barnyard.waldo
thêm nội dung sau rồi lưu và đóng file :
/var/log/snort
snort.log
<10 chữ số phía trên>
0

- khởi động barnyard: /usr/local/bin/barnyard2 -c /etc/snort/barnyard2.conf -G

/etc/snort/gen-msg.map -S /etc/snort/sid-msg.map -d /var/log/snort –f snort.log
-w /var/log/snort/barnyard.waldo

4. Thử nghiệm ( post-installed testing )

Khởi động Snort & Barnyard2

- snort -c /etc/snort/snort/conf -i eth0

- /usr/local/bin/barnyard2 -c /etc/snort/barnyard2.conf -d /var/log/snort –f
snort.log -w /var/log/snort/barnyard.waldo
Sử dụng GFI để quét thử

Truy cập B.A.S.E để xem cảnh báo

Xem theo danh sách Alerts

Xem theo categories

 Xem chi tiết 1 cảnh báo

Hiển thị đồ thị

IV. Cấu hình Snort nâng cao

1. Các tiện ích

Trong phần này, ta xem qua một số tiện ích của Snort, với mục đích giới thiệu các tính năng
có thể tích hợp nhằm có cái nhìn tổng thể về Snort như là 1 hệ NIDS/IPS đa năng.
Vì mục đích đó, các tiện ích sẽ được giới thiệu khái quát mà không đi sâu vào chi tiết cho
từng tiện ích.
a. Tự động cập nhật Snort rule với Oinkmaster

Oinkmaster là 1 Perl script giúp cập nhật và quản lý các rule của Snort, bao gồm các rule
chính thức ( official VRT rule ), các rule được phát triển bởi cộng đồng sử dụng Snort
( community rule ) , các rule được phát triển bởi nhà cung cấp thứ 3….
 (1) Cài đặt Oinkmaster
Download Oinkmaster tại :
http://oinkmaster.sourceforge.net/download.shtml

Mở CLI :
- tar zxvf /home/ids_usr/Desktop/oinkmaster-2.0.tar.gz
- cd /home/ids_usr/Desktop/oinkmaster-2.0
- cp oinkmaster.pl /usr/local/bin
- cp oinkmaster.conf /usr/local/etc
- cp oinkmaster.1 /usr/local/man/man1

(2) Đăng ký account tại Snort.org sau đó vào Get Rules, chọn Get Oink Code
https://www.snort.org/account/oinkcode

(3) Sửa file Oinkmaster.conf

- gedit oinkmaster.conf
- tìm “url =…” và sửa thành :
http://www.snort.org/pub-
bin/oinkmaster.cgi/5a08f649c16a278e1012e1c/snortrules-snapshot-2.8.tar.gz
( ví dụ oinkcode của ta là 5a08f649c16a278e1012e1c , và Snort là ver. 2.8 )

(4) khởi động Oinkmaster

oinkmaster.pl -o /etc/snort/rules

b. Quản trị Alert / Sensor : Snort consoles

Trong phần này, ta xem qua 1 số console quản trị Snort, một số chuyên phân tích các
thông tin được Snort thu thập, một số bao gồm cả chức năng cập nhật rule, chỉnh sửa cấu
hình rule. Các console được xem xét giới thiệu :
- SnortSnaft
- Cerebus
- ACID ( và phiên bản mới được dùng bên trên là B.A.S.E )
- SnortCenter

o SnortSnarf :
Là một Perl script thu thập các thông tin từ Snort và hiển thị dưới dạng HTML để có
thể duyệt một cách dễ dàng.
Ưu điểm :
Miễn phí, đơn giản và cung cấp 1 cái nhìn tổng thể về tình trạng.
Nhược điểm :
Chậm khi phải phân tích các file cảnh báo dung lượng lớn, tạo ra nhiều file
HTML.
Rất tiếc là SnortSnarf đã không còn được tiếp tục phát triển và hỗ trợ

o Cerebus :
Là một công cụ được phát triển bởi Drados Ruiu, cho phép duyệt, tổng hợp, quản lý
các cảnh báo từ Snort. Điểm mạnh nhất của Cerebus chính là việc cho phép tổng hợp
báo cáo từ nhiều file cảnh báo, điều này cho phép Admin của các mạng lớn có cái
nhìn tổng quát, và dễ dàng hơn khi phải làm việc với số lượng lớn các cảnh báo

Cerebus có thể download tại :

http://www.dragos.com/cerebus/download.html

Ưu điểm :
Nhanh, tương thích nhiều nền tảng khác nhau ( *nix, Win32 ), là công cụ tốt cho
việc tổng hợp và phân loại cảnh báo
Nhược điểm :
Là phần mềm Shareware, không có chức năng quản lý, đòi hỏi phải có kỹ năng
nhất định để sử dụng

o B.A.S.E
Cung cấp giao diện cuối dạng Web cho phép truy vấn và phân tích các cảnh báo được
thu thập bởi Snort.
( Xem thêm trong phần Demo )
Ưu điểm :
Được hỗ trợ từ cộng đồng Snort với tài liệu đầy đủ, tương thích với database và
cung cấp giao diện cuối hoàn chỉnh cho Snort
Khuyết điểm:
Do hoạt động trên nền Web nên tăng attack-surface
o SnortCenter
SnoftCenter là 1 công cụ quản lý kiến trúc client-server, hoạt động trên nền web giúp
cấu hình Snort và update các rule. Có thể nói, SnortCenter đã cung cấp 1 phương thức
quản lý Snort ( cấu hình, cập nhật Snort ) 1 cách trực quan, đơn giản và bảo mật.
Các tính năng chính:
 Tự động cập nhật các rule của Snort
 Stop-Start Snort
 Tạo và chỉnh sửa rule
 Tạo Snort template
 Tương thích với các nền tảng khác nhau
 Tương thích với SnortSam
 Kiến trúc client-server 1-nhiều
 Tương thích cơ sở dữ liệu
 c. IPS plugins

(1) Snort Inline

Snort Inline là một gói sửa đổi khác của Snort, cho phép kiểm tra các gói tin từ
iptables , phân tích và sau đó dùng các rule mới như drop,sdrop,reject để thông báo cho
iptables thực hiện các tác vụ tiếp theo như hủy,loại bỏ,sửa hoặc cho phép gói tin
đi qua dựa trên các rule của Snort.
Snort Inline có thể được cài đặt bằng 2 cách :
- dùng ./configure --enable-inline khi biên dịch mã nguồn của Snort
- download gói cài đặt hoàn chỉnh tại http://snort-inline.sourceforge.net/
Như đã nói ở trên, Snort Inline làm việc cùng với Iptables để cung cấp 1 giải pháp
NIDS/IPS tổng thể nên khi triển khai phải triển khai cả Iptables, điều này có thể gây
ra khó khăn nếu như hệ thống triển khai đã sử dụng 1 loại firewall khác.

(2) SnortSam
SnortSam là 1 agent có tính năng tương tự Snort Inline, khi Snort phát hiện ra 1 vi
phạm, nó cung cấp cảnh báo tương ứng với các điều kiện block cho trước đến 1 hoặc
nhiều SnortSam agent được cài đặt tích hợp trên firewall hoặc có kết nối đến firewall,
Agent này sẽ yêu cầu firewall block kết nối.
SnortSam đang được phát triển và ngày càng tương thích nhiều với các chủng loại
firewall từ các hãng khác nhau như Checkpoint, Cisco, Juniper, xBSD ipfw, *nix
IPTables, MS ISA Server…
SnortSam có thể download tại : http://www.snortsam.net/

2. Snort switches

USAGE: snort [-options] <filter options>

Options:

-A Set alert mode: fast, full, console, test or none (alert file alerts only) "unsock" enables UNIX
socket logging (experimental).
-b Log packets in tcpdump format (much faster!)
-B <mask> Obfuscated IP addresses in alerts and packet dumps using CIDR mask
-c <rules> Use Rules File <rules>
-C Print out payloads with character data only (no hex)
-d Dump the Application Layer
-D Run Snort in background (daemon) mode
-e Display the second layer header info
-f Turn off fflush() calls after binary log writes
-F <bpf> Read BPF filters from file <bpf>
-g <gname> Run snort gid as <gname> group (or gid) after initialization
-G <0xid> Log Identifier (to uniquely id events for multiple snorts)
-h <hn> Home network = <hn>
-H Make hash tables deterministic.
-i <if> Listen on interface <if>
-I Add Interface name to alert output
-k <mode> Checksum mode (all,noip,notcp,noudp,noicmp,none)
-K <mode> Logging mode (pcap[default],ascii,none)
-l <ld> Log to directory <ld>
-L <file> Log to this tcpdump file
 -M Log messages to syslog (not alerts)
-m <umask> Set umask = <umask>
-n <cnt> Exit after receiving <cnt> packets
-N Turn off logging (alerts still work)
-o Change the rule testing order to Pass|Alert|Log
-O Obfuscate the logged IP addresses
-p Disable promiscuous mode sniffing
-P <snap> Set explicit snaplen of packet (default: 1514)
-q Quiet. Don't show banner and status report
-r <tf> Read and process tcpdump file <tf>
-R <id> Include 'id' in snort_intf<id>.pid file name
-s Log alert messages to syslog
-S <n=v> Set rules file variable n equal to value “v”
-t <dir> Chroots process to <dir> after initialization
-T Test and report on the current Snort configuration
-u <uname> Run snort uid as <uname> user (or uid) after initialization
-U Use UTC for timestamps
-v Be verbose
-V Show version number
-w Dump 802.11 management and control frames
-X Dump the raw packet data starting at the link layer
-x Exit if Snort configuration problems occur
-y Include year in timestamp in the alert and log files
-Z <file> Set the performonitor preprocessor file path and name
-? Show this information

3. Snort rule

Marty Roesch, tác giả của Snort, ngay từ đầu đã chọn cách tạo ra một cú pháp đơn giản và có
tính mở rộng để viết rule, điều này cho phép người dùng Snort trên toàn thế giới tạo ra một
trong những tập dấu hiệu nhận dạng ( signature ) toàn diện nhất có sẵn cho mọi hệ IDS.

Mỗi rule có thể được sửa đổi riêng biệt , làm cho rule được sửa đổi ngày càng có sát với cơ
sở hạ tầng mạng Snort đang bảo vệ. Ngoài ra, các rule có thể được tự tạo ra từ đầu và hoàn
toàn sử dụng được với Snort điều này ho phép người dùng tùy chỉnh để tạo ra các quy tắc
làm cho Snort trở thành một ứng dụng bảo mật thật sự thực dụng.

Khi xây dựng một rule cho Snort, phải nhớ rằng ta đang thực sự tạo ra một dấu hiệu nhận
biết cho 1 lưu thông mạng, mục tiêu của dấu hiệu nhận biết này là làm sao có thể phát hiện ra
1 kiểu lưu thông riêng bằng cách so sánh các lưu thông khác với nó, chính vì vậy, phải nhớ
rằng luôn có 1 khoảng cách nhất định giữa dấu hiệu ta muốn rule kích hoạt và thực tế

a. Các thành phần chính

(1) Rule Header

Rule Header quy định loại cảnh báo, loại giao thức ( protocol ), địa chỉ IP, Ports được
giám sát trong dấu hiệu nhận dạng ( signature ).

Cú pháp :
rule_action protocol source_address_range source_port_range
direction_operator destination_address_range destination_port_range
 (a) Rule Action :
Thông số đầu tiên quy định Snort sẽ làm gì khi các gói tin phù hợp với rule.Có 3
lựa chọn :
(i) Alert
(ii) Log
(iii) Pass
(iv) Drop ( action riêng, mới của Snort Inline )

(b) Protocol:
Snort hỗ trợ 3 loại giao thức tại Rule Header là TCP,UDP và ICMP

(c) Director operator

Chỉ định cho Snort biết hướng sẽ áp dụng. có 2 loại là -> và < >

(d) Source and Destination IP Address

Snort hỗ trợ khai báo địa chỉ theo nhiều dạng : 1 vùng địa chỉ với netmask, hỗn
hợp vừa vùng vừa địa chỉ, khai báo qua biến ( ex: $EXTERNAL_NET.. ), hoặc
kiểu loại trừ với dấu “ ! “ ( ex: ! 192.168.1.1/24 )

(e) Source and Destination Ports

Snort hỗ trợ khai báo dạng 1 port, 1 dải port hoặc loại trừ

(2) Rule Option

Rule Option chính là phần dấu hiệu nhận biết ( signature ) và được quy định ưu tiên.
Phần dấu hiệu này được chỉ định bởi một hay nhiều từ khóa lựa chọn. Những từ khóa
lựa chọn này dùng để xây dựng nên dấu hiệu nhận biết cho lưu thông mạng mà ta
muốn Snort giám sát. Các từ khóa lựa chọn này được phân làm 8 loại sau :

(a) Các từ khóa lựa chọn liên quan đến nội dung ( Content-related )
Từ khóa lựa chọn quan trọng nhất lien quan đến việc kiểm tra nội dung. Dùng để
giám sát 1 mẫu đặt trưng trong phần tải của gói tin ( packet’s payload )
Các từ khóa lựa chọn liên quan đến nội dung chiếm khoảng 75% trong bộ rule của
Snort, tuy nhiên việc sử dụng chúng cần rất cẩn thận vì chúng thường chiếm nhiều
tài nguyên. Vì vậy, người ta thường hạn chế vùng tìm kiếm trong payload của gói
tin bằng cách giới hạn tìm kiếm bằng các từ khóa offset, depth, flow.
Bao gồm các từ khóa sau :
- Content
- Uricontent
- Content-list
- Nocase
- Offset
- Depth
- Regex
(b) Các từ khóa lựa chọn liên quan đến phiên làm việc ( Session-related )
- Flow
gồm các flow : to_client, to_server, from_client, from_server
ngoài ra có thể áp dụng rule cho các trạng thái riêng của phiên làm việc TCP
bằng 2 thông số : established, stateless.
- Session

(c) Các từ khóa lựa chọn liên quan đến IP ( IP-related )

Dùng để kiểm tra các thông số chứa trong IP Header . Bao gồm :
- Ttl
- Tos
- Id
- Ipopts ( eol, sec, nop, ts, satid, rr, lsrr, ssrr )
- Fragbits ( M-More Fragments, D- Don’t Fragment, R-Reserved Bit ), +,-,! )
- Dsize
- Ip_proto : quy định các loại giao thức

0 IP
1 ICMP
2 GGP
6 TCP
8 EGP
12 PUP
17 UDP
22 IDP
- Sameip
- Fragoffset

(d) Các từ khóa lựa chọn liên quan đến TCP ( TCP-related )

- Flags ( TCP flags )

F FIN
S SYN
A ACK
R Reset
P Push
U Urgent
0 No TCP Flags set
1 Reserved-Bit #1
2 Reserved-Bit #2
- Seq
- Ack
(e) Các từ khóa lựa chọn liên quan đến ICMP ( ICMP-related )

- Itype
0 Echo reply
1 Unassigned
2 Unassigned
3 Destination unreachable
4 Source quench
5 Redirect
6 Alternate host address
7 Unassigned
8 Echo
9 Router advertisement
10 Router selection
11 Time Exceeded
12 Parameter problem
13 Timestamp
14 Timestamp reply
15 Information request
16 Information reply
17 Address mask request
18 Address mask reply
19-29 Reserved (for robustness experiment)
30 Traceroute
31 Datagram conversion error
32 Mobile host redirect
33 IPv6 where-are-you
34 IPv6 I-am-here
35 Mobile registration request

36 37-255 Mobile registration reply Reserved

- Icode
Destination unreachable 0—Net unreachable
1—Host unreachable
2—Protocol unreachable
3—Port unreachable
4—Fragmentation needed and DF bit set
5—Source route failed
6—Destination network unknown
7—Destination host unknown
8—Source host isolated
9—Communication with destination network is
administratively prohibited
10—Communication with destination host is
administratively prohibited
11—Destination network unreachable for TOS
12—Destination host unreachable for TOS
Redirect 0—Redirect datagram for the network
1—Redirect datagram for the host
 2—Redirect datagram for the TOS and network
3—Redirect datagram for the TOS and host
Alternate host address 0—Alternate address for host
Time Exceeded 0—Time to live exceeded in transit
1—Fragment reassembly time exceeded
Parameter problem 0—Pointer indicates the error
1—Missing a required option 2—Bad length

- Icmp_id
- Icmp_seq

(f) Snort Response Option keywords

Quy định hành vi của Snort khi phát hiện 1 rule phù hợp
- Msg
- Logto
- Resp ( dùng cho module Flexible Response – FlexResp Snort )
- React ( block, warn, msg, proxy )
- Tag ( type, count, metric, direction )

(g) Meta Option keywords

- Reference
bugtraq http://www.securityfocus.com/bid/
cve http://cve.mitre.org/cgi-bin/cvename.cgi?name=
arachnids http://www.whitehats.com/info/IDS
mcafee http://vil.nai.com/vil/dispVirus.asp?virus_k=
url http://
- Sid
<100 chưa dùng, dàng riêng sử dụng sau
100-1000000 dùng cho các rule chuẩn của Snort
>1000000 dùng cho các rule tự tạo
- Rev
- Classtype
- Priority

(h) Các từ khóa lựa chọn khác

(i) Rpc
(ii) Rawbytes

b. Viết mới và thay đổi Snort rule

(1) Các phương pháp chính
- Chỉnh sửa rule có sẵn
- Tạo 1 rule từ các kiến thức hệ thống mạng
- Tạo 1 rule bằng việc phân tích lưu thông mạng
(2) Một ví dụ cơ bản trong việc viết và chỉnh sửa Snort rule

Để có thể viết hoặc sửa 1 Snort rule có hiệu quả và chỉ kích hoạt đúng với lưu thông
mạng mà ta muốn, việc nghiên cứu và phát hiện ra các thuộc tính riêng của lưu thông
đó là cực kỳ quan trọng. Một thuộc tính có thể chưa đặc tả được lưu thông đó nhưng
tập các thuộc tính phải là một đặc tả đầy đủ để có thể phân biệt.
Ta lấy 1 ví dụ với lưu thông mạng của tấn công Cross-site scripting ( XSS )

Cross-site Scripting là một kiểu tấn công đến các Website cho phép các mã độc được
nhúng vào các trang Web được tạo động. Nếu Website không kiểm tra các tác vụ
nhập từ người dùng, kẻ tấn công có thể chèn những đoạn mã làm cho ứng dụng Web
hoạt động 1 các bất thường. XSS thường dùng để đánh cắp cookies ( dùng để xác
thực ), truy cập các phần không được phép truy cập, hay tấn công ứng dụng Web.
Điểm chính của tấn công XSS là 1 scripting tag được chèn vào 1 trang cụ thể. Đây
chính là điểm mấu chốt mà ta có thể dùng để viết 1 rule.
Các tag thường được chèn vào là <SCRIPT> , <OBJECT>, <APPLET>, <EMBED>
Giả sử ta chọn lọc tag <SCRIPT>

Trước tiên ta tạo 1 rule kích hoạt khi lưu thông mạng có chứa <SCRIPT> trong nội
dung :

alert tcp any any -> any any (content:”<SCRIPT>”; msg:”WEB-MISC XSS
attempt”;)

Khi xảy ra tấn công XSS, rule sẽ được kích hoạt. Tuy nhiên nó cũng sẽ kích hoạt với
các lưu thông mạng bình thường như khi 1 người dùng gửi 1 email với JavaScript tạo
ra 1 sai tích cực ( false positive ). Để tránh việc này, ta phải sửa rule chỉ kích hoạt với
các lưu thông Web

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS

(content:”<SCRIPT>”; msg:”WEB-MISC XSS attempt”;)

Thay đổi như trên có thể phát hiện ra các lưu thông có chứa <SCRIPT> trong nội
dung liên quan đến các phiên HTTP. Nó được kích hoạt khi lưu thông từ mạng ngoài
( $EXTERNAL_NET ) gửi tới máy chủ Web ( $HTTP_SERVERS ) trên port mà
dịch vụ HTTP chạy ( $HTTP_PORTS ).
Tuy nhiên, khi nạp rule này, ta vẫn sẽ thấy các cảnh báo sai tích cực được tạo ra mỗi
khi 1 trang được yêu cầu có chứa JavaScript. Như vậy ta phải tinh chỉnh lại rule và
tìm kiếm những thuộc tính riêng biệt của lưu thông XSS

Tấn công XSS xảy ra khi người dùng chèn tag <SCRIPT> trong 1 yêu cầu gửi đến
Server, nếu Server gửi tag <SCRIPT> trong 1 phản hồi thì nó thường là 1 lưu thông
bình thường. Như vậy ta có thể tinh chỉnh rule như sau :

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”WEB-

MISC XSS attempt”; flow:to_server,established; content:”<SCRIPT>”;)
 Ở đây ta đã sử dụng từ khóa lựa chọn flow trong mục TCP-related, dùng khả năng tái
tạo luồng TCP của Snort để nhận diện hướng của luồng lưu thông. 2 option to_server
và established chỉ định rule áp dụng cho các phiên kết nối từ người dùng tới Server.
Đây chính là đặc trưng của tấn công XSS.

Như vậy ta đã có 1 rule nhận diện được đặc trưng của luồng lưu thông trong tấn công
XSS, để tránh việc kẻ tấn công có thể tránh được bằng kỹ thuật lẩn tránh ( Evasion
techniques ) như thay <SCRIPT> bằng các kiểu case-sensitive như <ScRiPT>,
<script>, .v.v ta có thể dùng thêm từ khóa lựa chọn nocase ( not case-sensitive ) của
mục Content-related, và quy định mức độ ưu tiên :

alert $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”WEB-

MISC XSS attempt”; flow:to_server,established; content:”<SCRIPT>”; nocase; )

Đến đây thì việc tạo 1 rule phát hiện tấn công XSS hoàn tất.

----------------------o00-----------------------

V. References:

1. Intrusion Detection Systems (IDS) – WindowsSecurity.com

2. Guide to Intrusion Detection and Prevention Systems (IDPS) – US National Institute of Standard and
Technology
3. Intrusion Detection with Snort - Jack Koziol. Sams Publishing 2003
4. Managing Security with Snort and IDS Tools – Kerry J. Cox & Christopher Gerg . O’Reilly 2004
5. Snort, Snort Inline, SnortSam, SnortCenter, Cerebus, B.A.S.E, Oinkmaster official documents
6. Snort 2.8.4.1 Ubuntu 9 Installation guide – Nick Moore , Jun 2009 , nmoore@sourcefire.com
7. Snort GUIs: A.C.I.D, Snort Center,and Beyond - Mike Poor, mike@digitalguardian.net
8. Various sources over Internet