Professional Documents
Culture Documents
----------------------oOo---------------------
INTRUSION DETECTION
AND PREVENTION SYSTEM
(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.
2
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
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ể
3
(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 ).
4
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
1. Host-based IDS/IPS
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
6
(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
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 ).
7
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.
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.
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.
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.
10
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 ).
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.
11
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
III. Cài đặt và cấu hình thử nghiệm IDS/IPS với Snort
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.
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.
13
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
Giả dụ các gói phần mềm được tải về và lưu tại desktop.
- cd /usr/local
- tar zxvf /home/ids_usr/Desktop/libnet-1.0.2a.tar.gz
- cd Libnet-1.0.2a
- ./configure && make && make install
14
Cài đặt Snort
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 “
- 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
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.
15
- 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 )
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
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
16
- 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
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
17
Khởi động Snort và hoàn tất cấu hình Barnyard
18
Sử dụng GFI để quét thử
19
Xem theo danh sách Alerts
20
Xem chi tiết 1 cảnh báo
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….
21
(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
oinkmaster.pl -o /etc/snort/rules
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.
22
Ư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
Ư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
23
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
24
c. IPS plugins
(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
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
25
-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ế
Cú pháp :
rule_action protocol source_address_range source_port_range
direction_operator destination_address_range destination_port_range
26
(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
(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
27
(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
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 )
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
28
(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
- 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
29
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
30
(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
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 :
31
Ở đâ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 :
Đế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:
32