Tối 13/10
Tối nay thứ Tư, ngày giữa tuần nên tôi không có cái tiện nghi thời gian để ngồi tẩn mẩn với mấy cái logs hàng giờ đồng hồ. Tuy nhiên, tôi có đủ thời gian để tải về dăm ba đoạn log để kiểm nghiệm ứng dụng dùng snort để "phá" cái state của connection. Tôi log vào HVA server và chạy một đoạn lệnh dùng để lấy chỉ một đoạn log từ khoảng 7 giờ tối đến 9 giờ tối của firewall và web server log. Chà, chỉ có hai giờ đồng hồ mà đoạn log cho firewall hơn 2Mb và đoạn log cho web server hơn 5Mb (?), nhất định phải có rất nhiều thông tin trong này.

Thật là khủng khiếp khi rà xuyên qua đoạn log trên. Ấn tượng xem nhẹ những mảnh "x-flash" bé nhỏ từ từ nhường chỗ cho sự khiếp đảm khi tôi mục kích số lượng gói tin truy cập mang tính vi phạm mà firewall đã ghi nhận và cản trở. Lúc đầu tôi rất ngỡ ngàng và hơi nghi ngờ với kết quả trên. Tôi mở firewall rule ra xem xét lại một lần nữa thật kỹ, phân tích từ dòng trong mỗi function. Tôi cảm thấy an tâm khi các giá trị ứng dụng trong firewall rule đều đúng cả. Không nghi ngờ gì nữa, đúng là firewall đã thực hiện chính xác những gì nó được ấn định. Ấn định giới hạn connection ứng hiệu, ấn định loại trừ invalid packets (do bị snort reset) cũng ứng hiệu. Tôi vẫn thấy các thông tin trong web server log tường trình rải rác cách mảnh "x-flash" vẫn đi đến web server với status 200 -27-. Tôi ngồi yên ngẫm nghĩ và duyệt qua trong đầu từng bộ phận của trọn bộ cơ chế cản lọc đã được hình thành cho đến lúc này. Nói về mặt số liệu thì tôi cảm thấy hài lòng vì các biện pháp rõ ràng có tác dụng, nhưng nói về mặt hiệu xuất tối đa của server cũng như những ảnh hưởng phụ đến người dùng hợp lệ thì tôi không thoả mãn. Điều này cũng dễ hiểu vì có hai chuyện vẫn xảy ra:

- trung bình cứ 4 cú "x-flash" đi vào thì 3 cú bị cản, 1 cú lọt vào trong. 1 cú lọt vào này chiếm một phần tài nguyên của máy chủ một cách vô ích vì máy chủ vẫn phải giải quyết yêu cầu của "x-flash" này mặc dù chính người gởi cú "x-flash" có lẽ cũng chẳng biết anh ta (hay cô ta) đã gởi nó đi.

- và để cản các cú "x-flash" tai quái kia, chắc chắn firewall đã ít nhiều ảnh hưởng đến quá trình truy cập của các người dùng hợp pháp. Bởi lẽ, nói về mặt giao thức thì chính các "x-flash" kia cũng hợp pháp không khác gì các đòi hỏi truy cập đi từ IE, Mozilla, Opera...

Trong quá trình dò xuyên qua firewall log, tôi tìm thấy khá nhiều các gói tin vi phạm bị snort "ra lệnh" huỷ bỏ (có còn nhớ đến giá trị resp:rst_all và react:block trong snort signature trước đây không?) nhưng kèm theo đó là một phản ứng phụ có thể khắc phục được nhưng tạo khó chịu khi phát hiện ra nó. Hãy cùng phân tích một cụm log sau:

Oct 13 21:34:48 hvaonline kernel: INVALID_STATE: IN=eth0 OUT= SRC=203.162.3.193 DST=192.168.1.100 LEN=56 TOS=0x00 PREC=0x00 TTL=248 ID=60756 PROTO=ICMP TYPE=11 CODE=0 [SRC=43.244.42.107 DST=203.210.158.196 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=TCP INCOMPLETE [8 bytes] ]

Oct 13 21:34:49 hvaonline kernel: INVALID_STATE: IN=eth0 OUT= SRC=203.162.3.193 DST=192.168.1.100 LEN=56 TOS=0x00 PREC=0x00 TTL=248 ID=61332 PROTO=ICMP TYPE=11 CODE=0 [SRC=43.244.42.107 DST=222.252.33.143 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=TCP INCOMPLETE [8 bytes] ]

Oct 13 21:34:50 hvaonline kernel: INVALID_STATE: IN=eth0 OUT= SRC=203.162.3.193 DST=192.168.1.100 LEN=56 TOS=0x00 PREC=0x00 TTL=248 ID=62105 PROTO=ICMP TYPE=11 CODE=0 [SRC=43.244.42.107 DST=203.210.150.121 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=TCP INCOMPLETE [8 bytes] ]

Có chuyện gì đáng nói ở đây? Cả ba thông báo trên xảy ra liên tiếp mỗi giây và đều có cùng tính chất như nhau. Firewall đã cản và thông báo như sau:
- gói tin ICMP loại 11, code 0 -28- đi từ 203.162.3.193 đến private IP 192.168.1.100 của HVA server bị cản với thông báo "INVALID_STATE"
- phụ chú cho thông báo cản ở trên còn có các thông tin trong ngoặc [] cho biết TCP packet gởi từ public IP của HVA server 43.244.42.107 đến 203.210.158.196 có chiều dài 44 bytes, có ưu tiên dịch vụ ở mức bình thường, nhưng TTL chỉ có giá trị là 1.

Chuyện gì đã xảy ra ở đây? một gói tin có chiều dài 44 bytes được gởi từ public IP của HVA server đến 203.210.158.196 để trả lời một request nào đó đến từ IP này, hoặc cũng có thể là gói tin RST để cắt đứt connection giữa IP và HVA server (như snort cần phải làm khi gặp gói tin vi phạm). Tuy nhiên, với giá trị TTL là 1, sau khi gói tin này hoàn thành có 1 hop -29- thì "router" 203.162.3.193 bèn gởi ngược một gói ICMP ngược về IP của HVA để thông báo là gói tin này không tới đích được vì lý do "time exceeded" (ICMP type 11 code 0). Tương tự cho 2 IP còn lại 222.252.33.143 và 203.210.150.121.

Một thông tin lý thú là: IP của "router" 203.162.3.193 là IP thuộc VNPT. Nếu vậy có nghĩa là gói tin đi từ public IP của HVA vừa qua khỏi router của ISP mà HVA dùng (hop 1) là đụng ngay đến router đi vào VNPT (hop 2) và TTL bị chấm dứt? Gói tin đi ra từ public IP của HVA 43.244.42.107 chắc chắn được modem / router của HVA tạo ra vì nó mang public IP nhưng nó lại tự động ấn định giá trị cho gói tin gởi đi có TTL là 1 thì đây quả là điều buồn cười và thú vị. Nếu vậy, hoá ra mọi gói tin gởi đi từ modem / router của HVA dùng đều mang TTL là 1 sao? Có thế nào như vậy được? Nếu quả thật như vậy thì HVA server muốn trả lời request sẽ không bao giờ đi tới đích và lúc nào cũng nhận hàng loạt ICMP dội ngược lại báo "time exceeded"? Thật phi lý vì mọi người vẫn truy cập và vẫn nhận thông tin hồi báo từ HVA server được. Nếu vậy thì chỉ còn có một trường hợp là gói tin được gởi đi từ modem / router của HVA (đương nhiên là phải xuất xứ từ bên trong web server đi ra) có một đặc điểm gì đó khiến cho modem / router "ngang nhiên" ấn định TTL là 1. Rất tiếc là trong tay tôi chỉ có một nhúm các packets được sniff cho "đường vào" HVA server chớ không sniff cả hai đường ra vào nên tôi không tài nào biết được chuyện gì đã xảy ra.

Từ phân tích trên, tôi rút ra được hai điểm lý thú như sau:
- snort hẳn đã gởi RST ngược về các gói tin vi phạm. Tôi chỉ đoán là vậy vì đoạn thông báo ở trên của firewall chỉ trả ngược về 8 bytes thông điệp ICMP và đoạn thông tin gởi đi có chiều dài 44 bytes hoàn toàn biến mất (biểu thị bằng INCOMPLETE) nên không biết rõ gói tin gởi đi mang TCP flag nào. Tôi biết chắc chính firewall không "thèm" trả lời các gói tin vi phạm cho mất thời gian mà nó chỉ lặng lẽ cho vào thùng rác, cho nên, xác suất việc gói tin gởi đi từ HVA server mang RST do snort tạo ra là rất cao.

- gói tin gởi đi này bị rơi vào tình trạng "đánh gió" vì mới qua 1 hop đã kết thúc (hết TTL) , đúng là hoài của.

- cứ mỗi gói RST gởi đi lại có 8 bytes IMCP trở về và hẳn nhiên những gói ICMP này bị firewall của HVA âm thầm cho vào thùng rác vì nó thuộc tình trạng INVALID_STATE nên ảnh hưởng của "phản ứng phụ" này là zero.

Tại sao tôi lại quan tâm đến những chi tiết xem chừng như "vụn vặt" như thế này? Tôi thắc mắc lý do tại sao lại có dạng "phản ứng phụ" kỳ quái như vậy xảy ra? đây có phải là lỗi của modem / router tiếp diện với Internet của HVA hay không? hay đây là một quy định nào đó rất nhỏ trong cơ chế cản "x-flash" gây nên? Những câu hỏi này được đặt ra như một "đề bài" để tôi phải hoàn tất. Thật sự lý do khiến tôi đưa ra vấn đề này vào bài viết là vì một điểm khác, bạn thử nghĩ xem, nếu firewall của HVA không loại trừ các gói tin mang tính INVALID -30- thì chuyện gì xảy ra? Đúng rồi, HVA server sẽ là nạn nhân của chính nó vì những gói tin gởi đi để RST đầu truy cập bên kia được trả ngược lại với 8 bytes ICMP do gói tin mang TTL = 1. Hãy thử hình dung trường hợp HVA server đang bị "dội" liên tục với "x-flash" mà còn bị "dội" thêm với các gói ICMP vô tình kia thì hậu quả sẽ ra sao? Vài ngày sau tôi đã tìm ra câu trả lời cho lý do tại sao có những gói tin gởi đi với TTL = 1 (chỉ để thoả mãn cho sự tò mò của bản thân tôi). Vấn đề được đặt ra ở đây là: thiết kế một mô hình mạng + bảo mật cần có cái nhìn tổng quát với đường đi (ra vào) của thông tin nhưng cần có sự kiểm duyệt tỉ mỉ cho mỗi cơ phận trong quá trình ứng dụng. Một điều chỉnh nho nhỏ trên một cơ phận nào của trọn bộ cơ cấu mạng + bảo mật cũng có thể tạo ảnh hưởng tiêu cực (hoặc tích cực) đến tính hiệu xuất và tính an toàn.

Tôi không có ý định đào sâu hơn với những phân tích giao thức "tầng thấp" vì nó có thể quá "khô khan" đối với bạn nên chúng ta hãy tiếp tục khai triển các ứng dụng tầng cao hơn. Những áp đặt ở tầng "network" và "transport" đã tạm ổn, các cú "đánh gió" của snort vẫn thỉnh thoảng xảy ra và các cú ICMP vẫn thỉnh thoảng đi ngược về, nhưng... who cares? những cái này hoàn toàn vô hại. Tôi tiếp tục khảo sát đến tiêu điểm của các cuộc tấn công: web service. Mấy hôm nay tôi mó đến các "access log" của web server để xem tính chất truy cập nhưng chưa hề đụng đến "error log". Thử xem có thông tin gì hấp dẫn trong error log. Ôi giời... đập ngay vào mắt tôi là hàng chuỗi thông báo "segmentation fault" -31- trong error log. Tôi quá vô ý, lẽ ra đây là nơi cần xem xét ngay từ đầu để nắm tình hình chung trước khi tập trung vào hai tầng "transport" và "network" nhưng dù sao cũng là sự đã rồi. Tôi chỉ thấy sốt ruột vì một nhu liệu báo quá nhiều segfault như vậy chứng tỏ một điều chắn chắn là nó không hoạt động đúng quy cách hoặc có những giềng mối đến những lỗi về lập trình với chính web server và những modules thêm vào.

Tôi mở một cái "đuôi" tail trên console để theo dõi các errors xảy ra với web server, càng xem tôi càng thêm sốt ruột vì hầu như mỗi giây trôi qua là mỗi segfault hiện lên màn hình. Lý do làm tôi sốt ruột rất đơn giản, nó không chỉ mang dấu hiệu cho tiềm năng đổ vỡ của web service bất cứ lúc nào mà còn là dấu hiệu của mức phục vụ kém hiệu năng của server. Cứ mỗi segfault xảy ra thì chúng ta có thể đoán một process nào đó cần được mở ra để phục vụ nhưng không thành công và kết quả thì... ai cũng có thể đoán được: đúng vậy, request từ trình duyệt hoàn toàn không nhận được kết quả gì cả nếu chính process được mở ra để trả lời bị segfault. Tôi quyết định chỉnh lại log level trở thành "debug" level -32- và tái khởi động web server -33-. Mở ra một cái "đuôi" tail mới trên console, tôi hơi thất vọng vì mình không tìm thêm được bao nhiêu thông tin có ích trong việc tìm nguồn gốc của các segfault. Error log thông báo thông tin tương tự như sau:
Code:


Tôi thở dài, đành phải dùng đến biện pháp chạy web server xuyên qua gdb -34- để tìm lỗi vậy. Tôi rất miễn cưỡng khi làm thế này, không phải vì phải động đến gdb mà vì đây là một site đang "sống", đang hoạt động và đang bị... DoS. Nhưng không làm thế thì làm sao tìm lỗi để trị nó? Tôi kiểm tra qua tình hình netstat hiện thời của server, chà! không được, có quá nhiều người dùng đang online ngay lúc này, chắc phải để sáng sớm mai khi chẳng có mấy ai vào HVA forum. Cũng đã khuya, tôi xếp laptop lại.

Sáng 14/10:

Như thường lệ, tôi có mặt ở công ty rất sớm. Làm một ly cà fê, tôi mở máy lên và log vào HVA server. Để xem thử tình hình server ra sao? Tôi gõ w và tiếp theo là netstat -nat. Hèm... tốt, server im ắng lắm, chỉ có lác đác vài mạng thì chắc không sao (lão JAL đã thông báo tôi cứ việc làm những gì tôi cần làm, được "lệnh" rồi mà ). Tôi thử "đì bấc" một child process theo kiểu hú hoạ xem sao vì error log cứ tiếp tục thông báo lỗi mỗi giây. Sáng nay ít người vào nên segfault không được báo ở mức độ đó nhưng ít nhất cũng 30 giây một lỗi. Tôi xem thử có bao nhiêu child process được forked -35-:
Code:


Chà, mười mấy "đứa con" (child process) đang nằm chờ. Tôi vớ ngay một trong mười mấy đứa, process xxxx và thử xem:
Code:


sau khi hàng tá symbols được load đâu đó, rồi nó đứng yên chờ.

Tôi biết debug kiểu này thật không khác gì "chó ngáp nhằm ruồi" vì trong đống child process kia có thể một hoặc nhiều "đứa" bị segfault chớ không phải ngay cái process xxxx tôi đang thử. Hơn nữa, "đứa" tôi đang dùng để thử có thể không có dịp tiếp nhận connection trong khi tôi đang thử thì "đì bấc" cái nỗi gì? Mèn, tôi lẩm nhẩm "việc gì phải e dè, cho cái web server chỉ chạy trên 1 process rồi tha hồ mà xem cái của khỉ gì đang xảy ra". Quyết định vậy xong, tôi thực hiện ngay. Tôi dừng hẳn web server và khởi động từ bên trong gdb -36- với thông số -DONE_PROCESS để buộc server chỉ chạy ở chế độ single process để tiện "đì bấc". Dịch vụ khởi tạo bình thường, thư viện dẫn bình ổn, và ngay sau đó: bang! có ngay một connection mới đi vào, socket mở ra để tiếp nhận. Cha chả, để xem thử cái gì xảy ra.

Trong phút chốc trên gdb console hiện ra hàng loạt thông tin liên quan đến mmap của php và tiếp theo đó là thông tin về việc truy dụng memory (mmap) cho một số các modules khác mà web service đang dùng. Bởi lẽ dịch vụ đang chạy ở chế độ single process, sigfault xảy ra ở đây dẫn đến tình trạng dịch vụ hoàn toàn bị tắt bỏ. Lý do đơn giản là khi dịch vụ chạy ở chế độ multi process thì nếu một "con" nào chết, process "mẹ" sẽ tiếp tục đẻ ra thêm nên dịch vụ vẫn tiếp tục hoạt động. Một cách tổng quát mà nói thì web service không hoạt động ở tình trạng "khoẻ mạnh", tôi cần biết chắc do mmap -37- được gọi để ấn định memory cho các modules và bị segfault là đủ. Rất tiếc tôi đã không lưu giữ chi tiết của kết quả "đì bấc" vì lúc ấy tôi nghĩ rằng các thông tin này không cần thiết, hơn nữa thông tin đì bấc đâu phải là "bằng chứng" của chuyện DoS mình đang điều tra cho nên càng không cần phải giữ lại. Đến nước này chỉ còn một giải pháp là tái biên dịch lại trọn bộ nhu liệu của web server và các modules kèm theo. Lý do phải làm chuyện này vì tôi nghi ngờ web service trên HVA dùng binaries có sẵn và những binaries này dùng các thư viện kèm không tương ứng với những gì đang có trên hệ thống.

Tôi tái khởi động lại web service và để cho nó hoạt động như bình thường. Sau đó, tôi gởi ngay cho JAL một PM để thông báo cần phải biên dịch lại trọn bộ phần mềm của web server. Lúc này còn sớm lắm, Japan lại sau nơi tôi cư ngụ hai giờ đồng hồ (tính theo múi giờ). Tôi quyết định tải các gói mã nguồn cần thiết và bắt tay vào việc biên dịch. Dự định trong đầu tôi rất đơn giản:
- giữ nguyên những gì đang chạy trên hệ thống (để phòng bị).
- biên dịch vài cài dịch vụ web mới ở nơi khác.
- khi phần mềm của web server mới sẵn sàng, chỉ cần tắt bỏ cái cũ, khởi động cái mới.
- nếu có sự cố gì thể quay về cái cũ.

Sẵn dịp, tôi tải luôn một số modules cụ thể trợ giúp cho "công cuộc" chống x-flash. Biên dịch lại quá đơn giản và nhanh chóng, chưa đến mười lăm phút, tôi đã hoàn tất mọi thứ. Tôi chỉ cần copy cái cấu hình của web server hiện dụng và mang qua cho web server mới, điều chỉnh lại các chi tiết cần thiết. Dò xuyên qua mọi thứ một lần cuối, tôi hài lòng và logoff HVA server. Chắc phải vài giờ sau mới có hồi báo từ JAL, bây giờ phải giải quyết công việc ở sở cho xong rồi sẽ quay lại HVA sau.

Các bạn có thể theo dõi tiếp phần 6 tại http://hvaonline.net/hvaonline/posts/list/180.html

Chú thích:
-27- HTTP status code chia làm 5 nhóm: 10x, 20x, 30x, 40x và 50x. Mỗi nhóm biểu thị tình trạng kết nối giữa client và server qua giao thức HTTP. Xem thêm chi tiết ở: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

-28- ICMP hay Internet Control Message Protocol. Một giao thức cần thiết trong TCP/IP chuyên để thông báo tình trạng gói tin. Trong trường hợp trên ICMP type 11, code 0 dùng để biểu thị trình trạng gói tin khi chuyển đi đã bị "hết giờ" trước khi đến đích. Xem thêm thông tin về ICMP ở: http://www.faqs.org/rfcs/rfc792.html

-29- hop đơn vị tính cho mỗi router mà gói tin đi xuyên qua. Giá trị "hop" biểu thị rõ nhất khi dùng traceroute từ một IP này đến một IP kia. Cứ mỗi lần gói tin đi qua một router, giá trị TTL lại bị router ấy trừ đi 1 cho đến khi nào nó tới đích, mỗi lần trừ biểu thị cho 1 hop. Nếu traceroute chưa hoàn tất đường cần phải dò (trace) mà giá trị TTL của packet gởi đi đã chấm dứt (bằng 0) thì router nào "đụng" phải packet ấy phải gởi 1 gói ICMP type 11 code 0 (thông điệp "time exceeded") ngược về host nguyên thuỷ đã gởi gói tin đi để thông báo tình trạng gói tin.

-30- các gói tin mang tính INVALID nói một cách tổng quát là các gói tin không thuộc một xuất truy cập nào, không được firewall điều tác và ghi nhận mà chỉ xuất hiện bất chợt và không đi qua các cơ chế giao thức hợp lệ. Đối với quy định riêng của HVA firewall, và riêng với giao thức ICMP thì chỉ có HVA server mới được quyền khởi tạo các gói tin ICMP và host nào đó nhận được, cần trả lời thì firewall mới mở cửa để nó đi vào với mục đích trả lời mà thôi. Nếu một gói tin ICMP (bất chấp loại nào) được khởi tạo từ bên ngoài và đi đến HVA server đều bị cản. Tính chất gói tin này có thể hoàn toàn hợp lệ về mặt giao thức nhưng bất hợp lệ đối với quy định trên HVA firewall.

-31- segmentation fault hay còn gọi tắt là SEGFAULT. Trường hợp segfault xảy ra khi một nhu liệu nào đó cần truy cập vào vị trí nào đó trên bộ nhớ nhưng không được phép hoặc cách truy cập này không hợp lệ.

-32- Các dịch vụ chạy trên *nix nói chung đều cho phép ấn định mức độ thông tin được log của dịch vụ báo cáo. Ở đây tôi dùng "debug" level có nghĩa là ở mức độ chi tiết nhất có thể được để lấy càng nhiều thông tin càng tốt nhằm mục đích xác định vùng lỗi xảy ra với dịch vụ. Cần nói thêm, "log" là phương tiện, là khởi điểm của quy trình tìm lỗi. Điều rất đáng ngạc nhiên là đa số những admin bình thường ít khi dùng đến nó khi gặp sự cố mà thường chỉ cậy vào thao tác "stop / start" một dịch vụ và hy vọng nó sẽ ổn. Nếu may mắn, dịch vụ ấy tiếp tục hoạt động, nếu không may dịch vụ lại vướng vào đám "lỗi" thì những admin này thường cầu cứu đến các dịch vụ hỗ trợ hoặc hỏi bất cứ nơi nào có thể hỏi được. Theo tôi, đây là một thói quen nên sửa đổi.

-33- Tái khởi động web server ở đây không giống như ngưng nó hoàn toàn rồi tái khởi động; làm thế này sẽ gián đoạn đến các xuất truy cập hiện đang xảy ra trên server. Tái khởi động ở đây chỉ là dạng "graceful", có nghĩa là server được nhận tín hiệu cần tái khởi động để nạp lại thông tin của cấu hình, nó sẽ đợi cho các process có những connection đang diễn tiến xong rồi mới kết thúc chúng. Làm thế này đối với người dùng hoàn toàn "trong suốt" và không có gián đoạn nào.

-34- gdb hay GNU Debugger, một công cụ không thể thiếu được cho những ai cần debug các chương trình được viết bằng C, C++ hay Modular 2. Nó cho phép người dùng "xem" những gì xảy ra trong khi một chương trình đang chạy và nếu chương trình bị treo, báo lỗi hay bất cứ chuyện gì bất thường xảy ra, nó có thể cung cấp những thông tin cần thiết để xác định cụ thể nguyên nhân sự cố nằm ở đâu. gdb có trên các Linux distro (nếu cài thêm bộ development tool) và gần đây trở nên rất phổ biến trên các *nix thương mại như AIX, Solaris, UX-HP và tất nhiên MacOS X. Xem thêm thông tin về gdb ở: http://www.gnu.org

-35- prefork, cách tạo process mới cho mỗi connection. Đây là cách "cổ điển" nhưng vì phiên bản php hiện đang dùng trong trường hợp này không thuộc dạng "thread safe" nên phải dùng đến prefork. Điều này có nghĩa mỗi request đi vào và cần php phục vụ trang động (dynamic page) thì phải "fork" ra một process hoàn toàn mới. Khái niệm tổng quát là như vậy, nếu bạn cần đào sâu thì nên nghiên cứu thêm về cơ chế tạo process và thread cho một system (bài viết này cho môi trường *nix).

-36- đây là một trong những thủ thuật debugging dùng gdb, tôi không đi sâu vào chi tiết vì làm loãng nội dung. Nếu bạn thích thú thì chính tài liệu đi kèm với gdb có đầy đủ các thông tin cho vấn đề này.

-37- mmap hay "map pages of memory", một hàm dùng để xác định một khoảng bộ nhớ cho một process được tạo ra để thực thi một công tác nào đó trên hệ thống. Xem thêm chi tiết về mmap ở: http://www.opengroup.org/onlinepubs/009695...tions/mmap.html