Showing posts with label Nghiên cứu. Show all posts
Showing posts with label Nghiên cứu. Show all posts

Friday, June 17, 2016

Tìm hiểu một số công nghệ Web!

CGI trong lập trình web là gì?

CGI (Common Gateway Interface) là một bộ thông dịch script cho các web server, là công cụ để chạy các ứng dụng web trên Linux/Unix, còn trên Windows thì có ASP.net.

Đây là một phương pháp cho phép giao tiếp giữa server và chương trình nhờ các định dạng đặc tả thông tin.
Lập trình CGI cho phép viết chương trình nhận lệnh khởi đầu từ trang web, trang web dùng định dạng HTML để chạy chương trình.
Chương trình CGI chạy dưới biến môi trường duy nhất. Khi WWW khởi tạo chương trình CGI nó tạo ra một số thông tin đặc biệt cho chương trình và đáp ứng trở lại từ chương trình CGI. Sau đó server xác định loại file chương trình cần thực thi.
Tóm lại, lập trình CGI là viết chương trình nhận và truyền dữ liệu qua internet với web server. Chương trình CGI sử dụng dữ liệu đó và gửi đáp ứng HTML trở lại máy khách.

CGI - PHP - ASP - JSP
1. Vài năm trước đây, con đường thực sự duy nhất để vận chuyển các dữ liệu động tới trang Web là kỹ thuật CGI (Common Gateway Interface). Các chương trình CGI cung cấp một sự liên hệ đơn giản để tạo các ứng dụng Web cho phép tiếp nhận các dữ liệu nhập vào, các yêu cầu truy vấn cơ sở dữ liệu từ phía người dùng và trả một vài kết quả về cho trình duyệt. Các chương trình CGI có thể được viết trên một vài ngôn ngữ, trong đó phổ biến nhất là Perl. Web server sử dụng CGI như là một cổng truy cập chặn giữa yêu cầu của người dùng và dữ liệu được yêu cầu. Nó sẽ được nạp vào bộ nhớ như một chương trình bình thường. Thông thường các web server sẽ chuyển các yêu cầu và triệu gọi chương trình CGI. Sau khi chương trình kết thúc, web server sẽ đọc dữ liệu trả về từ chương trình và gửi nó đến trình duyệt.
Nhược điểm lớn nhất của kỹ thuật CGI là nó hoạt động kém hiệu quả. Mỗi khi web server nhận một yêu cầu, một tuyến trình mới được tạo ra. Mỗi tuyến trình lại chứa trong nó các đoạn mã lệnh, dữ liệu… và không được chia sẻ lẫn nhau, do đó gây ra lãng phí bộ nhớ. Để khắc phục nhược điểm này, Microsoft và Netscape đã hợp tác và đưa ra một cải tiến đáng kể là chuyển chúng về dạng các file thư viện liên kết động (DLL ), cho phép chia sẻ mã lệnh giữa các tuyến trình. Đây chính là các kỹ thuật ISAPI và NSAPI.
Đen đủi thay, các kỹ thuật dựa trên DLL không phải là đã hoàn thiện. Chúng vẫn còn một số vấn đề:
- Khi các thư viện nền tảng được gọi, nếu muốn thoát các ứng dụng này, ta phải tắt chương trình triệu gọi (Web server) và khởi động lại máy tính.
- Các thư viện cần được đặt trong các tuyến trình bảo vệ, tức là chúng cần phải được cảnh giác về cách sử dụng các biến chung hoặc các biến tĩnh.
- Nếu  chương trình triệu gọi gây ra lỗi truy cập, nó có thể dẫn đến tình trạng server bị treo tắc tử.
- Và cuối cùng: khi đã được dịch ra các file DLL, công việc gỡ lỗi cũng như bảo trì mã lệnh trở nên vất vả hơn bao giờ hết.
2. Kỹ thuật Web mới nhất của Microsoft, kết hợp HTML, các đoạn Script, các thành phần xử lý phía server trong cùng một file, được gọi là ASP (Active Server Pages), với phiên bản mới nhất hiện nay là ASP.Net. ASP được triệu gọi bởi một thư viện liên kết động gắn với các Web server của Microsoft. Về bản chất, ta có thể coi ASP như là một ngôn ngữ thông dịch vậy. Một trang ASP có thể sử dụng HTML, JScript và VBScript. Qua các đoạn mã nhúng này, ASP có thể truy cập đến các thành phần phía server. Các thành phần này có thể được viết trên bất kỳ ngôn ngữ nào hỗ trợ các thành phần COM của Microsoft. Và đây chính là sức mạnh của ASP: nó có thể làm được bất kỳ cái gì mà máy chủ có thể làm được với các thành phần COM. Sau khi được thi hành, ASP sẽ sản sinh ra một trang Web có khuôn dạng HTML và trả nó về cho Web server.

Một bất lợi lớn đối với ASP là nó chỉ có thể hoạt động trên các họ Web server của Microsoft (bao gồm PWS trên Win9x hay IIS trên WinNT/2000/XP). Các nhà phát triển đang hướng đến những môi trường khác như Unix/Linux (hiện đã có bản Chili! ASP chạy trên các môi trường này), nhưng kết quả thì còn phải đợi thêm một thời gian nữa




Thursday, June 9, 2016

Tại sao bài báo khoa học bị từ chối?

Năm 2009, các nhà khoa học VN chỉ công bố được khoảng 960 bài báo khoa học trên các tập san quốc tế. Con số này cực kì khiêm tốn khi so với các nước trong vùng. Đằng sau con số này là hàng trăm bài báo bị các tập san từ chối không công bố. Bất cứ ai làm nghiên cứu khoa học cũng có ít nhất một lần ngậm ngùi thấy bài báo hay công trình nghiên cứu của mình bị tập san khoa học từ chối không công bố. Đứng trước một quyết định như thế của tập san, phản ứng đầu tiên mà nhà khoa học có là câu hỏi “tại sao”: tại sao họ từ chối công trình tuyệt vời này của tôi? Ngạc nhiên thay, rất ít nghiên cứu về lí do từ chối bài báo khoa học! Tuy nhiên, thời gian gần đây đã có vài phân tích về vấn đề này, và bài viết này có mục tiêu cung cấp cho bạn đọc một vài nguyên nhân từ chối bài báo khoa học.

Ở các nước tiên tiến và phần lớn các đang phát triển (có lẽ ngoại trừ Việt Nam), bài báo khoa học là một viên gạch lót đường cho sự thăng tiến trong nghề nghiệp của một nhà khoa học, là một đơn vị tiền tệ cực kì quan trọng cho việc xin được tài trợ cho nghiên cứu, và là một chỉ tiêu quan trọng để đo lường năng suất khoa học của một quốc gia. Do đó, có những nước, chẳng hạn như Hàn Quốc và Trung Quốc, chi ra hàng tỉ đôla để nâng cao sự có mặt của họ trên trường quốc tế qua hoạt động công bố ấn phẩm khoa học.

Bài báo khoa học là “sản phẩm” của một công trình nghiên cứu khoa học. Để đánh giá sự thành bại của một công trình, người ta thường xem xét đến bài báo khoa học đã được công bố ở đâu, và trong vài trường hợp cần thiết, bằng sáng chế được đăng kí ở đâu. Xin nói thêm rằng ở nước ngoài, người ta không có kiểu “nghiệm thu” như ở Việt Nam để đánh giá sự thành bại của một công trình nghiên cứu khoa học.

Qui trình xuất bản

Qui trình để xuất bản một bài báo khoa học cũng khá đơn giản. Đầu tiên là tác giả (hay thường là nhóm tác giả) soạn bài báo khoa học, sau đó họ chọn một tập san để gửi gấm “đứa con tinh thần” của mình. Ban biên tập tập san khi nhận được sẽ xem qua một cách nhanh chóng, và nếu thấy chưa đạt yêu cầu sẽ gửi trả lại cho tác giả trong vòng 1 tuần; nếu thấy đạt yêu cầu và có tiềm năng, họ sẽ gửi cho 2 hoặc 3 chuyên gia bình duyệt (reviewers hay referees). Các chuyên gia bình duyệt sẽ đọc và đánh giá bài báo, viết báo cáo gửi cho tổng biên tập của tập san, với những đề nghị như (a) cho công bố không cần sửa; (b) cho công bố những cần sửa chút ít; (c) cho công bố nhưng sửa nhiều hay viết lại; (d) từ chối. Chỉ một trong 3 chuyên gia bình duyệt đề nghị từ chối thì bài báo sẽ bị từ chối. Nếu 2 chuyên gia đề nghị chấp nhận cho công bố và 1 người không chấp nhận, thì ban biên tập sẽ gửi cho một chuyên gia khác bình duyệt tiếp. Điều cần nói là các chuyên gia này biết tác giả là ai (qua bản thảo bài báo), nhưng tác giả không biết 3 chuyên gia này là ai. Thời gian bình duyệt của các chuyên gia có thể kéo dài từ 2 tuần đến 6 tháng, hoặc có thể lâu hơn (tùy theo bộ môn khoa học).

Nếu các chuyên gia đề nghị phải sửa lại thì tổng biên tập gửi lại cho tác giả với toàn bộ báo cáo của các chuyên gia. Tác giả có trách nhiệm phải sửa từng điểm một trong bài báo, hay làm thêm thí nghiệm, thêm phân tích, v.v… để đáp ứng yêu cầu của các chuyên gia bình duyệt. Bản thảo thứ hai lại được gửi cho ban biên tập, và qui trình bình duyệt lần thứ 2 lại được khởi động. Nếu các chuyên gia thấy tác giả chưa đáp ứng yêu cầu, bài báo có thể bị từ chối. Nếu các chuyên gia thấy tác giả đã đáp ứng tất cả những đề nghị thì họ có thể sẽ đồng ý cho công bố bài báo. Nếu được chấp nhận, bài báo sẽ được gửi cho biên tập viên của nhà xuất bản, và họ sẽ có người chuyên lo phần ngôn ngữ để biên tập bài báo. Thật ra, phần lớn bài báo chẳng có gì phải sửa về tiếng Anh, nhưng vì các nhà xuất bản muốn tiết kiệm giấy, nên nhiệm vụ của biên tập viên là tìm mọi cách, mọi nơi để giảm số chữ. Chẳng hạn như những danh xưng, bằng cấp, chức danh, v.v… của tác giả có tập san có chính sách cắt bỏ hết vì họ cho rằng tốn giấy. Họ sẽ xem xét đến biểu đồ và bảng số liệu xem có gì trùng hợp không để cắt bỏ khỏi bài báo. Những biên tập viên này cực kì giỏi về viết lách và rất kinh nghiệm trong việc trình bày một bài báo khoa học sao cho gọn nhẹ mà nội dung vẫn đầy đủ.

Như là một qui luật, phần lớn các bài những khoa học nộp cho tập san khoa học bị từ chối không cho công bố ngay từ giai đoạn bình duyệt, thậm chí ngay từ giai đoạn trước khi gửi bài báo ra ngoài bình duyệt. Tỉ lệ từ chối dao động lớn giữa các tập san. Tập san càng uy tín chừng nào, tỉ lệ từ chối càng cao chừng ấy. Uy tín ở đây được đo lường bằng hệ số impact factor (IF). Tập san có ảnh hưởng lớn thường có hệ số cao. Những tập san lâu đời và có ảnh hưởng lớn trong khoa học như Science (IF 30), Nature (IF 31), Cell (31.3), hay trong y khoa như New England Journal of Medicine (52.6), Lancet (28.6), JAMA (25.6), mỗi năm nhận được khoảng 6000 đến 8000 bài báo khoa học, nhưng tỉ lệ từ chối lên đến 90% hoặc 95%. Ngược lại, những tập san nhỏ và chuyên ngành thường có hệ số impact factor thấp, và tỉ lệ từ chối chỉ khoảng 50% đến 60%. Những tập san địa phương có vẻ dễ dải hơn, với tỉ lệ từ chối chỉ 20 hay 30%.

Lí do từ chối ?

Nhưng tại sao các tập san có “thói quen” từ chối công bố các công trình nghiên cứu của đồng nghiệp? Đây là một câu hỏi chính đáng, nhưng rất khó có câu trả lời, vì trong quá khứ rất ít nghiên cứu tìm hiểu những nguyên nhân dẫn đến từ chối một bài báo khoa học. Tuy nhiên, một cuộc điều tra gần đây cung cấp cho chúng ta một vài dữ liệu thú vị và quan trọng. Trong cuộc điều tra này, tác giả gửi 83 câu hỏi đến đến 25 nhà khoa học từng chiếm giải Nobel y sinh học, 67 tổng biên tập và 50 chuyên gia bình duyệt của các tập san y sinh học. Nhưng chỉ có khoảng 25% trong số này trả lời tất cả những câu hỏi, và kết quả phân tích cho thấy như sau.

Khi được hỏi khuyết điểm nào phổ biến nhất để từ chối ngay một bài báo khoa học, thì có 3 lí do chính sau đây: 71% là do thiết kế nghiên cứu có vấn đề, 14% do diễn giải kết quả nghiên cứu sai, và 14% là do đề tài nghiên cứu không quan trọng.

Một bài báo thường được viết theo cấu trúc IMRAD (tức là có phần dẫn nhập, phương pháp, kết quả, và bàn luận). Khi được hỏi phần nào thường phạm phải sai lầm nhiều nhất thì câu trả lời là 55% ở phần phương pháp, 24% phần bàn luận, và 21% phần kết quả. Trong 4 phần của một bài báo, phần nào là nguyên nhân dẫn đến từ chối bài báo? Phân tích kết quả cho thấy khoảng phân nủa là phần phương pháp (52%), kế đến là phần kết quả (28%), và phần bàn luận (21%).

Nói tóm lại, các kết quả phân tích trên đây cho thấy khuyết điểm phổ biến nhất và cũng là nguyên nhân thông thường nhất dẫn đến quyết định từ chối một bài báo khoa học nằm ở phần phương pháp. Điều này có lẽ cũng không khó hiểu, bởi vì nếu phương pháp sai thì kết quả sẽ sai, các bàn luận và kết luận cũng có thể sai. Mà, sai sót về phương pháp thì không sửa được (vì nghiên cứu đã làm rồi). Không có tập san khoa học nào muốn công bố một bài báo khoa học với nhiều sai sót, nên quyết định từ chối những bài báo do khiếm khuyết về phương pháp là điều hoàn toàn có thể đoán được.

Trong phần phân tích chi tiết về các lí do từ chối, tác giả còn cung cấp một số dữ liệu quan trọng trong phần diễn giải kết quả, tầm quan trọng của nghiên cứu, khiếm khuyết trong cách trình bày kết quả nghiên cứu, và viết văn. Về diễn giải kết quả nghiên cứu, có đến 61% các tác giả diễn giải hay kết luận không nhất quán với dữ liệu, và phần còn lại là dữ liệu không có tính thuyết phục cao (25%) hay còn quá sơ khởi (7%).

Về nội dung, thiếu cái mới trong công trình nghiên cứu là lí do hàng đầu (80% bài báo bị từ chối vì lí do này). Thiếu tứng ứng dụng (13%) cũng là một lí do để từ chối, nhưng không quan trọng bằng thiếu cái mới, tuy quan trọng hơn lí do vì chủ đề nghiên cứu quá hẹp (8%). Về trình bày dữ liệu, có 3 nguyên nhân chính dẫn đến bài báo bị từ chối đăng: trình bày dữ liệu không đầy đủ (32%), có mâu thẫn giữa các dữ liệu trình bày (25%) và không cung cấp đầy đủ chi tiếtt về phương pháp nghiên cứu (25%). Về cách viết, các tổng biên tập và chuyên gia bình duyệt có vẻ không ưa cách viết lách quá nhiều chữ nhưng ít ý tưởng và đây chính là nguyên nhân hàng đầu dẫn đến bài báo bị từ chối (43%). Ngoài ra, diễn đạt ý tưởng không khúc chiếc (21%) và câu văn thừa (11%) cũng là những nguyên nhân bị từ chối.

Địa phương chủ nghĩa ?

Phần lớn các tập san khoa học -- dù là trụ sở đặt ở Mĩ hay Âu châu, hay trực thuộc các hiệp hội khoa học của Mĩ hay Âu châu -- mang tính quốc tế, hiểu theo nghĩa ban biên tập nhận bài từ tất cả các nhà khoa học trên thế giới. Câu hỏi đặt ra là có sự khác biệt nào về tỉ lệ từ chối giữa các nước hay không.

Theo thống kê của các tập san y khoa lớn như New England Journal of Medicine, JAMA, không có khác biệt lớn về tỉ lệ từ chối giữa các nước Mĩ (hay nói tiếng Anh) và ngoài Mĩ. Năm 2000, 25% trong tổng số bài báo JAMA nhận được xuất phát từ các nước ngoài Mĩ, và tỉ lệ từ chối là 95%. Tỉ lệ từ chối các bài báo từ Mĩ của JAMA là 93%. Tập san New England Journal of Medicine cho biết trong tổng số bài báo tập san nhận được hàng năm, 1/2 đến từ các nước ngoài Mĩ. Trong tổng số các bài báo được chấp nhận cho đăng trên New England Journal of Medicine, 1/3 có nguồn gốc ngoài Mĩ.

Tuy nhiên, đối với các tập san chuyên ngành thì có sự khác biệt lớn giữa các nước ngoài Mĩ và Mĩ. Chẳng hạn như tập san Circulation Research (chuyên về tim mạch, impact factor ~10), mỗi năm họ nhận được khoảng 2000 bài báo từ khắp các nước trên thế giới, nhưng chủ yếu từ Mĩ (44%), Âu châu (31%), Nhật (6%), và Á châu (9%, không kể Nhật). Tỉ lệ từ chối chung là 85%, không khác mấy so với tỉ lệ từ chối các bài báo từ Hàn Quốc (88%), Đài Loan (91%). Riêng Trung Quốc, có đến 99% bài báo gửi cho tập san Circulation Research bị từ chối vì chất lượng quá kém và tiếng Anh chưa đạt.

Một phân tích thú vị khác của tập san American Journal of Roentgenology (IF ~4) cho thấy một “bức tranh” toàn cục thú vị (Bảng 2). Trong thời gian từ 2003 đến 2005, tập san này nhận được 5242 bài báo khoa học từ khắp nơi trên thế giới, nhưng chủ yếu từ Mĩ (43%), Nhật (11%), Hàn Quốc (9%), Đức (5%), và Canada (4%). Tuy nhiên, tỉ lệ bài báo được chấp nhận cho đăng dao động lớn giữa các nước. Trong số 2252 bài báo từ Mĩ, 72% được chấp nhận cho công bố, và trong tổng số 2990 bài báo ngoài Mĩ, tỉ lệ được chấp nhận là 60%. Nước có tỉ lệ chấp nhận thấp nhất là Ấn Độ, với chỉ 27% bài báo được công bố. Phân tích chi tiết theo ngôn ngữ mẹ đẻ, thì trong số 2684 bài báo từ các nước nói tiếng Anh (Mĩ, Canada, Anh, Úc) tỉ lệ chấp nhận cho công bố là ~71%. Trong số 2558 bài báo xuất phát từ những nước không nói tiếng Anh, tỉ lệ chấp nhận chỉ 60%.

Các nhà nghiên cứu phân chia các nguyên nhân từ chối thành 6 nhóm: nhóm: I liên quan đến thiếu cái mới hay dữ liệu không có ích; nhóm II liên quan đến những khuyết điểm về phương pháp và logic; nhóm III, khuyết điểm về phân tích dữ liệu; nhóm IV, vấn đề ngôn ngữ; nhóm V, chuyên gia bình duyệt không thích; và nhóm VI, không thích hợp cho tập san.

Khi phân tích lí do từ chối theo từng nhóm và nước (Bảng 3) chúng ta thấy phần lớn (60%) bài báo bị từ chối là thuộc vào nhóm I, tiếp đến là nhóm II (17%), nhóm III (7%), nhóm IV (3.5%), nhóm V (8%), và nhóm VI (4.4%).

Phân tích lí do từ chối, chúng ta thấy rõ ràng có sự khác biệt giữa các nước. Đối với những nước như Hàn Quốc, Thổ Nhĩ Kì, Thụy Sĩ, Đài Loan, Ý, Ấn Độ, và Do Thái, lí do từ chối lớn nhất ở các nước là nhóm I, tức thiếu cái mới trong nghiên cứu. Nói cách khác, các nước này có xu hướng làm những công trình nghiên cứu –nói theo tiếng Anh là – “me too” (tức chỉ lặp lại những gì các nước khác đã làm mà phương pháp, kết quả và cách diễn giải hoàn toàn không có gì mới.

Điều đáng ngạc nhiên là trong số những bài báo từ Đức và Áo bị từ chối, có đến 33-40% là do những sai sót về phương pháp và lí luận! Riêng những nghiên cứu từ Trung Quốc thì trong số bài báo bị từ chối, 52% là do thiếu cái mới, 17% do vấn đề tiếng Anh, 14% là do khuyết điểm trong phương pháp nghiên cứu là logic, và 6% do phân tích dữ liệu sai.

Vài nhận xét

Những dữ liệu trên đây cung cấp cho chúng ta một bức tranh tương đối toàn diện về tình hình công bố quốc tế đối với các nhà khoa học trong ngành y sinh học. Có thể tóm tắt các dữ liệu trên đây qua 3 điểm chính như sau:

• trong tất cả các nguyên nhân từ chối công bố quốc tế, gần 2/3 là do khuyết điểm trong khâu thiết kế nghiên cứu và phương pháp nghiên cứu;

• những khuyết điểm này thường tập trung vào 2 khía cạnh chính: thiếu cái mới và lí luận logic;

• bài bào từ Mĩ và các nước nói tiếng Anh có tỉ lệ từ chối thấp hơn bài báo từ các nước không nói tiếng Anh;

Tuy nhiên, những phân tích trên đây cũng có vài hạn chế. Thứ nhất là các dữ liệu được thu thập từ các tổng biên tập, nhà khoa học và tập san trong lĩnh vực y sinh học; do đó có thể chưa phản ảnh đúng tình trạng thực tế trong các lĩnh vực khoa học khác như kĩ thuật, khoa học tự nhiên, khoa học xã hội. Thứ hai là dữ liệu từ một tập san nhỏ (hay chỉ có 25% nhà nghiên cứu trả lời) nên chắc chắn ngay cả trong lĩnh vực y sinh học cũng chưa phản ảnh đúng thực trạng, dù bức tranh chung thì chắc cũng khá đầy đủ.

Nếu những dữ liệu và phân tích trên đây cung cấp cho giới khoa học, nhất là trong lĩnh vực y sinh học, vài kinh nghiệm, tôi nghĩ đến những khía cạnh sau đây. Thứ nhất là khi có ý tưởng làm nghiên cứu, cần phải chú trọng đến cái mới. Cái mới ở đây không chỉ về ý tưởng, mà có thể là cái mới về phương pháp nghiên cứu (dù ý tưởng không mới), cái mới về kết quả và cách trình bày, và cái mới trong cách lí giải kết quả nghiên cứu. Thiếu những cái mới này thì nghiên cứu chỉ là một dạng “me too”, tức chỉ hoàn toàn bắt chước người khác từ A đến Z. Nếu là nghiên cứu “me too” thì rất khó được chấp nhận cho công bố trên các tập san có uy tín cao, hay dù có cơ hội được công bố thì tập san cũng thuộc vào loại làng nhàng, dưới trung bình.

Thứ hai là cần chú trọng đến khâu thiết kế nghiên cứu và phương pháp phân tích. Trong nghiên cứu thực nghiệm, thiết kế và phương pháp đóng vai trò cực kì quan trọng. Thiết kế nghiên cứu không thích hợp, thì dữ liệu có thể không có giá trị khoa học cao, và không có cơ may công bố trên các tập san có uy tín cao. Chẳng hạn như một công trình nghiên cứu y khoa thiết kế theo mô hình có yếu tố thời gian và có nhóm chứng lúc nào cũng có giá trị khoa học hơn là một công trình “nghiên cứu cắt ngang” (cross-sectional study). Trong nghiên cứu y học, phương pháp sai thì kết quả cũng sai hay không có giá trị cao. Chẳng hạn như nếu nghiên cứu về bệnh tiểu đường hay dinh dưỡng mà không có các đo lường về lượng mỡ bằng phương pháp DXA thì dữ liệu khó mà xem là có giá trị khoa học cao. Một nghiên cứu với thiết kế và phương pháp chưa đạt thì xác suất bị từ chối rất cao.

Thứ ba là cần thạo tiếng Anh. Phần lớn các tập san quốc tế, dù là tập san ở các nước Bắc Âu hay châu Á Thái Bình Dương đều sử dụng tiếng Anh. Có thể nói không ngoa rằng tiếng Anh đã trở thành một ngôn ngữ của cộng đồng khoa học. Đối với các nhà khoa học Việt Nam, tiếng Anh là một vấn đề lớn, vì phần lớn các nhà khoa học không thạo tiếng Anh. Ngay cả những người có khả năng giao tiếp bằng tiếng Anh, họ cũng rất khó viết nổi một bài báo khoa học. Ngay cả những người viết được thì xác suất sai sót về cú pháp, cách diễn đạt rất cao. Có thể nói không ngoa rằng không một bài báo y khoa nào được công bố trên các tập san ở trong nước viết đúng tiếng Anh! Nhưng như chúng ta thấy qua các dữ liệu trên, tiếng Anh là một rào cản đáng kể (nhưng không phải là rào cản duy nhất hay lớn nhất) đối với các nhà khoa học ngoài các nước nói tiếng Anh. Do đó, chúng ta cần phải đẩy mạnh việc trao dồi tiếng Anh trong giới khoa học, và tổ chức nhiều khóa học về cách viết bài báo khoa học bằng tiếng Anh. Tuy nhiên, tiếng Anh không phải là nguyên nhân chính để từ chối một công trình nghiên cứu có chất lượng cao. Ngược lại, tiếng Anh “văn hay chữ tốt” cũng không thể bù đấp được những khiếm khuyết về cái mới và phần thiết kế cũng như phương pháp nghiên cứu.

Đối với giới làm nghiên cứu khoa học, chuyện vui buồn trong công bố công trình nghiên cứu xảy ra thường xuyên. Có nhiều khi bài báo sau khi qua nhiều sửa đổi được chấp nhận cho công bố, và dĩ nhiên đó là một tin mừng. Nếu tập san có hệ số impact factor cao thì tác giả có khi tổ chức tiệc ăn mừng. Mừng vì công trình của mình được công bố trên một tập san lớn, và có cơ hội chia sẻ kinh nghiệm với đồng nghiệp quốc tế. Nhưng hầu như bất cứ ai làm việc trong nghiên cứu khoa học đều phải trải qua nhiều lần khi mà bài báo nghiên cứu của mình bị tập san khoa học từ chối không công bố. Đối với những nghiên cứu sinh lần đầu nhận được lá thư của tổng biên tập thông báo cho biết bài báo không được chấp nhận cho công bố là một bản tin sốc. Có khi sốc đến cao độ. Có khi buồn chán. Trong bối cảnh buồn chán đó, nhà khoa học có kinh nghiệm thường phải tỏ ra bình tĩnh để xem xét lại nguyên nhân bài báo bị từ chối. Cần phải biến sự việc tiêu cực (bị từ chối) thành một cơ hội lí tưởng để tự vấn. Trong quá trình tự vấn này, một số câu hỏi thông thường cần đặt ra:

• Tựa đề bài báo có phù hợp với dữ liệu nghiên cứu?
• Kết quả nghiên cứu có nhất quán với những lí giải trong phần bàn luận?
• Có phải lí giải trong bài báo là lí giải duy nhất, hay còn một lí giải, một cách diễn giải nào khác?
• Có cần thu thập thêm dữ liệu?
• Có cần một phương pháp phân tích khác tốt hơn?
• Kết quả có ý nghĩa thống kê và ý nghĩa thực tiễn?
• Kết quả nghiên cứu đã được trình bày một cách logic, mạch lạc, và rõ ràng?
• Tiếng Anh đã trao chuốt chưa?

Trả lời được những câu hỏi tự vấn trên chắc chắn sẽ có hiệu quả cải tiến bài báo một cách đáng kể. Cố nhiên, khi bài báo bị từ chối thì điều đó không có nghĩa là công trình chấm dứt ở đó, mà chúng ta vẫn có quyền khiếu nại, hay trong nhiều trường hợp, chúng ta có thể chỉnh sửa và nộp cho một tập san khác. Tuy nhiên, “biết người biết ta, trăm trận trăm thắng”, những lí do từ chối được mô tả trong bài viết này là những kinh nghiệm quí báu để chúng ta tự đánh giá và chuẩn bị cho nhiều nghiên cứu sau tốt hơn.


Nguồn coltech.vnu.edu.vn

Sunday, May 29, 2016

Các công nghệ đảm bảo an toàn phần mềm

1. Address Space Layout Randomization (ASLR)

ASLR là tính năng bảo mật khiến vị trí dữ liệu của chương trình được sắp xếp một cách ngẫu nhiên trong bộ nhớ. Trước ASLR, vị trí dữ liệu của chương trình trong bộ nhớ có thể dự đoán được, làm các cuộc tấn công trên chương trình đơn giản hơn. Với ASLR, kẻ tấn công phải đoán đúng vị trí trong bộ nhớ khi cố gắng khai thác lỗ hổng trong chương trình. Dự đoán không chính xác có thể dẫn đến việc chương trình bị treo, do đó kẻ tấn công sẽ không thể thử lại.
Tính năng bảo mật này cũng được sử dụng trên các phiên bản Windows 32-bit và nhiều hệ điều hành khác. Tuy nhiên trên các phiên bản Windows 64 bit, ASLR mạnh hơn rất nhiều. Hệ thống 64-bit có không gian địa chỉ lớn hơn nhiều so với hệ thống 32-bit, do đó ASLR cũng hiệu quả hơn nhiều.
2. Data Execution Protection (DEP)
DEP cho phép hệ điều hành đánh dấu một số khu vực trên bộ nhớ dưới dạng “non-executable” (không được thực thi) bằng cách thiết lập “NX bit”. Vùng bộ nhớ này chỉ được phép lưu trữ dữ liệu chứ không thể thực thi các lệnh sử dụng.
Ví dụ, trên hệ thống không DEP kẻ tấn công có thể sử dụng một số loại buffer overflow (lỗi tràn bộ đệm) để viết mã vào vùng bộ nhớ của ứng dụng sau đó có thể được thực hiện. Với DEP, kẻ tấn công có thể viết mã vào vùng bộ nhớ của ứng dụng - nhưng khu vực này sẽ được đánh dấu là không thể thực thi không thể được thực hiện giúp ngăn chặn cuộc tấn công.
Trên hệ điều hành Windows 64-bit có DEP dựa trên phần cứng (nếu bạn có CPU hiện đại, các phiên bản Windows 32-bit cũng hỗ trợ DEP dựa trên phần cứng). Tuy nhiên, DEP luôn được kích hoạt đối với các chương trình 64-bit, trong khi theo mặc định, nó bị vô hiệu hóa đối với các chương trình 32-bit vì lý do tương thích.
Hộp thoại cấu hình DEP trong Windows chỉ áp dụng cho cho các ứng dụng, tiến trình 32-bit vì tài liệu của Microsoft cho biết, DEP luôn được sử dụng cho tất cả các tiến trình 64-bit.

Friday, July 11, 2014

Basic Dynamic Analysis: Sandbox

Dynamic analysis là bất cứ quá trình phân tích nào được thực hiện sau khi thực thi malware. Dynamic analysis techniques là bước thứ hai trong quá trình phân tích malware. Dynamic analysis thường được thực hiện sau basic static analysis đã được thực hiện xong, có hay không obfuscation, packing hoặc là việc phân tích đã tận dụng hết các kĩ thuật phân tích tĩnh chưa. Nó có thể yêu cầu monitering malware khi nó runs hoặc là kiểm tra hệ thống sau khi malware đã được thực thi.

Không giống như static analysis, dynamic analysis giúp bạn quan sát được các chức năng thực sự của malware, bởi vì, cho ví dụ, sự tồn tại của một action string trong một binary không có nghĩa là action sẽ thực sự được thực thi. Dynamic analysis còn là một cách hiệu quả để nhận dạng những chức năng mà malware thực hiện. Cho ví dụ, nếu malware của bạn là một keylogger, dynamic analysis có thể cho phép bạn tìm được vị trí của keylogger's log file trên hệ thống, phát hiện ra những kiểu records nó giữ, giải mã được nơi nó gửi thông tin của nó, và còn nhiều thứ khác. Những kiểu thông tin như vầy có thể rất khó có được khi ta chỉ sử dụng basic static techniques.

Mặc dù dynamic analysis techniques là cực kì mạnh mẽ, chúng chỉ nên được thực hiện sau khi basic static analysis đã được hoàn thành, bởi vì dynamic analysis có thể đặt mạng và hệ thống của bạn vào mối nguy hiểm. Dynamic techniques cũng có những giới hạn của chúng, bởi vì không phải tất cả code paths có thể thực thi khi một mảnh malware được run. Cho ví dụ, trong trường hợp command-line malware mà yêu cầu arguments, mỗi argument có thể thực thi các chức năng khác nhau của chương trình, và nếu không biết về options bạn không thể nào phân tích động tất cả các chức năng của chương trình. Bạn có thể cần sử dụng advanced dynamic hoặc static techniques để tìm ra cách làm cho malware thực thi tất cả các chức năng của nó. Bài viết này mô tả basic dynamic analysis techniques.

Sandboxes: The Quick-and-Dirty Approach

Một vài sản phầm phần mềm "tất cả trong một" có thể được sử dụng để thực hiện basic dynamic analysis, và phổ biến nhất là sử dụng sandbox. sandbox là một cơ chế bảo vệ (security mechanism) dành cho việc running các chương trình không đáng tin mà không phải lo sợ nó ảnh hưởng đến các hệ thống thực. Sandboxes bao gồm các môi trường được ảo hóa mà thường mô phỏng các dịch vụ mạng theo một vài kiểu mẫu nào đó để đảm bảo rằng phần mềm  hoặc là malware được tested sẽ hoạt động bình thường.

Using a Malware Sandbox

Nhiều malware sandboxes - như là Norman SandBox, GFI Sandbox, Anubis, Joe Sandbox, ThreatExpert, BitBlaze, và Comodo Instant Malware Analysis - sẽ phân tích malware miễn phí. Hiện tại, Norman Sandbox và GFI Sandbox (ban đầu có tên là CWSandbox) là 2 sandboxes phổ biến nhất.

Các sandboxes  cung cấp output dễ hiểu và là thích hợp cho bước phân loại ban đầu, miễn là bạn submit malware của mình lên sandbox websites. Mặc dù sandboxes được tự động, bạn có thể chọn để không phải submit malware chứa thông tin về công ty lên public website.

Hầu hết sandboxes làm việc tương tự như nhau, vì vậy tôi sẽ thảo luận về một sandbox, GFI sandbox. Figure 4-1 hiển thị bảng nội dung của một PDF report được sinh ra bởi việc running một file thông qua GFI Sandbox's automated analysis. Malware report bao gồm nhiều chi tiết khác nhau về malware, như là hành vi mạng nó thực hiện, file nó tạo ra, kết quả sinh ra thông qua việc scan với VirusTotal,...
 Reports được sinh bởi GFI sandbox khác nhau trong số lượng sections chúng chứa, dựa trên những gì analysis tìm được. GFI sandbox report 6 sections trong Figure 4-1, như sau:


  • Analysis Summary liệt kê static analysis information và một toàn cảnh ở mức cao của các kết quả phân tích động. 
  • File Activity section liệt kê các files được mở, được tạo, hoặc bị xóa cho mỗi process bị tác động bởi malware. 
  • Created Mutexes section liệt kê mutexes tạo bởi malware. 
  • Registry Activity section liệt kê các thay đổi đến registry.
  • Network Activity section bao gồm network activity được sinh ra bởi malware, bao gồm cả việc thiết lập một listening port hoặc thực hiện một DNS request. 
  • VirusTotal Results section liệt kê các kết quả của VirusTotal scan đối với malware.
Sandbox Drawbacks

Malware sandboxes thường có một vài nhược điểm chính. Cho ví dụ, sandbox đơn giản chỉ run executable, mà không có command-line options. Nếu malware executable yêu cầu command-line options, nó sẽ không thực thi bất cứ code nào và nó chỉ run khi cung cấp một option. Ngoài ra, nếu subject malware của bạn đang chờ cho command-and-control packet được trả về trước khi launching một backdoor, backdoor sẽ không được lanched trong sandbox. 

Sandbox có thể không record được tất cả events, bởi vì cả bạn lẫn sandbox không thể chờ đợi trong một thời gian đủ dài. Cho ví dụ, nếu malware được thiết lập để sleep trong vòng một ngày trước khi thực hiện các hành vi nguy hiểm, bạn có thể lỡ mất sự kiện đó. (Hầu hết sandboxes hook Sleep function và thiết lập nó ngủ chỉ trong một thời gian ngắn, nhưng để ngủ thì đâu phải chỉ có một cách này, và sandboxes không thể theo kịp tất cả những cách thức trên.)

Các khuyết điểm tiềm ẩn khác bao gồm:
  • Malware thường phát hiện khi nó đang đực running trong một máy ảo, và nếu một máy ảo bị phát hiện, malware có thể dùng việc running hoặc trở mặt cư xử khác đi. Không phải tất cả sandboxes đều giải quyết được vấn đề này. 
  • Một vài malware yêu cầu sự hiện diện của registry keys nhất định hoặc files trên hệ thống mà những thứ này có thể không được tìm thấy trong sandbox. Nhiều cái còn yêu cầu chứa dữ liệu hợp lệ, ví dụ như commands hoặc encrytion keys. 
  • Nếu malware là một DLL, một lượng nhất định exported functions sẽ không được invoked một cách thích hợp, bởi vì một DLL sẽ không run dễ dàng như là một excutable. 
  • Sandbox environment OS có thể không đúng với malware. Cho ví dụ, malware có thể crash Windows XP nhưng sẽ run mà không hề gì trong Windows 7.
  • Một sandbox không thể nói cho bạn những gì malware làm. Nó có thể report các chức năng cơ bản, nhưng không thể nói cho bạn nếu malware là một custom Security Account Manager (SAM) hash dump utility hoặc một encryted keylogging backdoor. 

Xây dựng lab phục vụ cho phân tích động malware

Malware labs có thể cực kì đơn giản hoặc rất phức tạp. Tất cả phụ thuộc vào resources hiện có của bạn (ví dụ như hardware, networking equipment, Windows licences, và những thứ khác), phụ thuộc vào bao nhiêu công việc phân tích bạn muốn tự động hóa, bao nhiêu options bạn muốn có. Bài viết này chỉ cho bạn cách set up một lab nhỏ bao gồm các mục tiêu ảo (virtual targets) và các mục tiêu vật lý (physical targets) sử dụng Internet thực hoặc mô phỏng. Hình phía dưới shows một ví dụ của môi trường lab.
Mô hình lab trên gồm các thành phần sau:

  • Physical targets: Đây là các máy tính xài hệ điều hành Windows, chúng sẽ đảm nhiệm việc thực thi malware. Đừng lo lắng về việc lây nhiễm malware lên các máy vật lý. Bạn có thể ngăn chặn không cho chúng lây malware lây nhiễm với Deep Freeze , hoặc bạn cũng có thể re-image chúng một cách nhanh chóng qua các giải pháp nhưTruman và FOG. Khi FOG  d được thảo luận trong Recipe 7-8, những physical targets được coi như là FOG clients. Dĩ nhiên, các máy tính thật không phải là một yêu cầu, nhưng thật là tốt khi ta có chúng trong trường hợp ta cần phân tích VM-aware malware. 
  • Virtual targets: Đây là các máy ảo chạy Windows bạn cũng sẽ thực thi malware trên các máy này. Mỗi khi bạn xong việc, bạn có thể phục hồi chúng về trạng thái trước khi bị lây nhiễm. Chúng tôi khuyến nghị bạn nên có ít nhất một hoặc hai VMs running các phiên bản khác nhau của Windows. Trong bài viết này, khi nhắc đến virtual targets tôi còn sử dụng hai thuật ngữ là virtual machine guests và VMs
  • Controller: Đây là một máy tính vật lý chạy Linux. Nó runs imaging software để điều khiển physical targets, các phần mềm máy ảo (như là VMware hoặc VirtualBox) để điều khiển virtual targets, và các chương trình để điều khiển, log, hoặc mô phỏng truy cập mạng. Xuyên suốt bài viết này, tôi nhắc tới controller như là FOG server và virtual machine host, phụ thuộc vào vai trò của nó trong vấn đề ta thảo luận. 
Thông thường chúng ta chỉ xài một laptop, nhưng với những yêu cầu phía trên đòi hỏi ta phải có 2 máy thật (Physical targets và Controller). Bạn có thể tạo một lab dựa trên một máy tính duy nhất. Tôi khuyến cáo bạn nên sử dụng Linux như là hệ điều hành của controller, nhưng nó không phải là yêu cầu, chỉ là lựa chọn của bạn mà thôi. Bạn cũng có thể tạo một portable, personal lab trên các máy tính chạy Windows hoặc Mac OS X. Tuy nhiên, bởi vì chúng ta không thể cung cấp instructions trên mọi cấu hình có thể, tôi sẽ sử dụng setup trong Figure 7-1 như là một mô hình chung trong bài viết này và tôi sẽ chỉ ra những chỗ bạn cần điều chỉnh nếu lab của bạn khác với cách thức chung.

Mạng trong mô hình này được chứa trong một LAN duy nhất bởi vì đó là những gì người ta sử dụng nhiều nhất. Mặc dù không được chỉ ra trong Figure 7-1, tôi đang giả định rằng firewall có một địa chỉ IP bên ngoài để giao tiếp với Internet. Nêu bạn có quyền truy nhập đến một mạng lớn hơn hoặc bạn có nhiều địa chỉ external IP lấy từ ISP của bạn, khi đó bạn có thể gắn cho mỗi target những IP để nó có thể được route.

Trước khi bắt đầu với việc setting up một lab , luôn nhớ trong đầu rằng việc setting up một môi trường an toàn là rất quan trọng, nếu bạn không muốn compromise hệ thống host và controller của bạn. Virtual machines chia sẻ rất nhiều resources với host computer và một cách nhanh chóng có thể trở thành một nguy cơ an ninh nếu bạn cấp phép cho chúng. Dưới đây là một vài điểm giúp bạn ngăn chặn malware "chạy thoát" khỏi môi trường bị cô lập đến nơi mà chúng bị hạn chế:

  • Đảm bảo rằng phần mềm máy ảo bạn đang sử dụng đã được cập nhật. Các lỗ hổng trong máy ảo có thể dẫn đến việc lây nhiểm malware lên host của bạn.
  • Cấu hình firewall trên host của bạn để drop incoming packets đến từ targets. 
  • Nếu bạn không muốn cho malicious code mà bạn run trong target có thể đi vào Internet, chắc chắn rằng bạn đã disable virtual network card, sử dụng host-only networking configuration, hoặc chứa traffic với simulation scripts (sẽ thấy trong Recipe 7-3)
  • Disable shared folders giữa host và target hoặc làm cho chúng read-only.
  • Ngăn chặn target truy nhập tới bất cứ shared devices hoặc removable media nào, ví dụ USB drives được cắm vào host của bạn. 
  • Đừng tùy chỉnh (customize) target system của bạn với bất cứ thông tin nào, nếu bị leaked bởi một trojan, các thông tin này có thể được sử dụng để nhận dạng bạn. 
Bạn cần có kiến thức về TCP/IP, Linux system administration, và Windows system administration. Bạn cần biết sử dụng máy ảo như VMware hoặc Virtual Box. Bạn cần phải quen thuộc với forensic tools, cũng như là khả năng tùy chỉnh Perl và Python scripts để phù hợp với nhu cầu của bạn. 

Networking

Cấu hình mạng hợp lý trong môi trường lab của bạn là một bước quan trọng cho việc capturing và phân tích traffic mà malware sinh ra. Việc giải quyết thách thức này yêu cầu sự hiểu biết về các network settings khác nhau mà hầu hết các sản phẩm máy ảo cung cấp. 
Tham khảo Table 7-1, đây là một bảng tổng kết về các chế độ mạng: host-only, NAT/shared, và bridged. 

Ba modes được định nghĩa như sau:
  • Host-only mode: Mode này tạo ra một private LAN được chia sẻ giữa host và VMs của nó. VMs không thể giao tiếp với các hệ thống bên ngoài- những hệ thống mà có thể tốt hoặc xấu, dựa trên mục đích của bạn. Đó là rất tệ nếu bạn muốn cho phép malware liên hệ (contact) với các sites thực tế trên Internet, bởi vì nó sẽ không hoạt động, nhưng một điều tốt đó là nếu bạn muốn chứa traffic trong môi trường sandbox của cá nhân bạn . 
  • NAT/Shared mode: VMs contact với máy khác trong LAN hoặc Internet, nhưng các kết nối thường có địa chỉ IP nguồn là địa chỉ IP của host. Các máy khác khổng thể khởi tạo các kết nối đến ngược trở lại VMs nếu không có cấu hình port-forwarding trên máy host. 
  • Bridge mode: VMs chia sẻ physcal Ethernet adaptor của host, nhưng chúng các địa chỉ IPv MAC của riêng chúng. VMs xuất hiện trong cùng local subnet với host. Đó là cấu hình duy nhất cho phép các máy khác tạo ra các kết nối gửi đến VMs. Nó còn là mode duy nhất cho phép các máy bên ngoài, như là router hoặc firewall, để phân biệt giữa traffic sinh ra bởi host và traffic sinh ra bởi một VM trên host. 
Chúng tôi khuyến nghị sử dụng bridged mode cho các VMs của bạn và gán cho chúng các địa chỉ IP vì vậy bạn mới có thể xác định được VM nào chịu trách nhiệm cho traffic mà bạn capture. Dĩ nhiên, nếu bạn chỉ có một VM và không có nhu cầu cho incoming connections đến VM của bạn, khi đó NAT/Shared mode sẽ thích hợp. 

RECIPE 7-1: ROUTING TCP/IP CONNECTIONS IN YOUR LAB

Trên máy của bạn, đối với controller trong sơ đồ ở đầu bài, sử dụng ifconfig để xác định địa chỉ IP của nó. Sau đó sử dụng ipconfig trên Windows targets của bạn để làm điều tương tự. Kiểm tra tất cả các máy nằm chung một subnet và đảm bảo rằng bạn có thể ping controller từ Windows targets. Để thuận tiện cho việc tham khảo, Table 7-2 cung cấp các giá trị có liên quan lấy từ lab của tôi, những thứ này sẽ còn liên quan trong các phần sau. 

Note: Nếu bạn bị hạn chế về mặt hardware, bạn có thể sử dụng máy ảo Linux như là controller. Trong trường hợp đó, bạn sẽ cần tối thiểu 2 VMs - một để running Windows (the target) và cái kia để running Linux (the controller).

Thế nào, bây giờ bạn đã kiểm tra được tính liên thông của mạng giữa controller và targets của bạn, bạn sẽ cần tạo ra một vài thay đổi để tất cả traffic sinh ra bởi programs trên target "đổ" vào controller. Chúng ta sẽ thảo luận một vài cách thức để thực hiện điều đó, vì vậy bạn có thể đánh giá được những điểm mạnh và điểm yếu, nhưng tôi thực sự khuyên bạn nên sử dụng chỉ một cách thức đó là kĩ thuật IP routing. 

Redirecting DNS

Nếu bạn đã biết DNS hostname của server(s) được liện hệ với malware, bạn có thể modify hosts file để điều hướng các kết nối đến controller's IP. Hosts file được đặt trong thư mục%SYSTEMROOT%\config\drivers\etc và nó được định dạng như sau:

# redirect DNS to the controller’s IP
172.16.176.130 commandserver.com

Entry phía trước forces processes trên target machine để kết nối với địa chỉ IP của controller sau khi resolving commandserver.com với DNS. Nếu bạn có một process trên controller của bạn lằng nghe incoming connections, bạn có thể log traffic và nhìn xem malware có thể làm gì khi kết nối thành công đến server thực sự commandserver.com.

Có một vài điểm yếu với phương thức này. Thứ nhất, bạn sẽ không thường xuyên "chắc ăn" biết được hostname mà một sample contact đến, và giả sử nếu bạn biết được đi nữa, thêm các entries đến host files mỗi lần phải thực hiện một cách thủ công và tẻ nhạt. Thứ hai, nếu malware resolves domains sử dụng DNS_QUERY_NO_HOSTS_FILE flag trong DnsQuery, khi đó nó sẽ bypass your hosts file entries.

Một lựa chọn khác là bạn có thể tạo một DNS server cho chính mình và cấu hình nó để trả về IP của controller cho một vài hoặc tất cả hostnames mà target cố gắng để resolve. Sử dụng kĩ thuật này, bạn không phải edit thủ công hosts file, nhưng malware vẫn có thể bypass setup của bạn thông qua việc không thực hiện DNS lookups và contacting với một hệ thống bằng IP của nó. Malware có thể lờ đi DNS settings trên target machine của bạn và resolve hostnames sử dụng một public DNS server thay thế (cho ví dụ, Google's open DNS).

Redirecting IP with Routing

Nếu bạn thay đổi thiết lập mạng trên target của mình, trỏ gateway của nó vào controller của bạn, sau đó tất cả traffic sẽ hit controller của bạn mặc kệ malware contacts với một hệ thống bởi DNS name hoặc IP. Nếu bạn có một quyết định quan trọng cần phải quyết - Bạn có muốn log hay là forward packets đến real servers trên Internet hay là bạn muốn redirect packets đến một hệ thống giả hoặc các dịch vụ mô phỏng ?

Nếu bạn forward packets đến real servers, bạn có thể biết được chính xác hơn những cư sử của malware trong tự nhiên, nhưng có một mối lo ngại đó là bạn có thể làm lộ IP của bạn với bad guys. Nếu bạn sử dụng một bộ phần mềm mô phỏng, bạn có thể tạo hoàn toàn một sandnet chứa chính nó, nhưng bạn sẽ không thực sự quan sát được malware trong môi trường tự nhiên.

Để route tất cả target machine's traffic thông qua controller, làm theo các bước sau:

  1. Trên controller chạy Linux, enable IP forwarding trong kernel bằng việc thực hiện command sau như root:
          $ sudo su
          # echo 1 > /proc/sys/net/ipv4/ip_forward
    2.    Trên controller, đảm bảo rằng iptables default firewall policy cho phép forwarding packets,           như sau
          $sudo iptables - P FORWARD ACCEPT
    3. Quay lại target, cấu hình mạng cho nó sao cho default gateway trỏ đến controller. Bạn có thể 
          thực hiện điều này thông qua 2 cách. Cách thứ nhất yêu cầu gõ command sau trong cmd.exe
          C:\> route change 0.0.0.0 mask 0.0.0.0 172.16.176.130

         Bạn cũng thể sử dụng GUI, như trong Figure 7-2. 


 Với thiết lập như trên, bạn có thể tự tin để capture, redirect, hoặc interact với bất cứ traffic được sinh bởi Windows target machine. Sở dĩ tôi nói từ "tự tin" một cách công bằng bởi vì mặc dù chúng ta không bao giờ có thể nhìn thấy nó trong tự nhiên, malware có thể reconfigure default gateway trên target machine và gửi traffic xung quan controller. Khả năng để làm điều đó phụ thuộc vào nơi đặt controller của bạn. Malware còn cần phải biết IP của next-hop router mà nhận hoặc và forwards traffic; tuy nhiên, có rất nhiều thứ bạn có thể học được từ một trace route đơn giản. 

Recipe 7-2: CAPTURING AND ANALYZING NETWORK TRAFFIC

Tất cả traffic gửi từ / đến targets của bạn đổ xuống controller, bạn đã có thể khởi động tiện ích capture trên controller và nhìn packets trong thời gian thực. 

NOTE: 
Bên cạnh phương thức capturing packets, bạn có thể sử dụng một vài kĩ thuật khác:
  • Kết nối machines trên mạng của bạn đến một old hub nếu bạn có một cái, và sử dụng dụng một mode sniffer.
  • Plug sniffer của bạn vào trong một switch hoặc router để cho phép port mirroring.
  • Kết nối target machines đến controller của bạn thông qua crossover cable. 

Using WireShark's GUI 

WireShark là một công cụ phân tích giao thức mạng trên Windows, Linux, MAC OS X, trên các OS khác. Bên cạnh việc capturing packets, WireShark có thể thực hiện việc kiểm tra "sâu" hàng trăm giao thức, và xuất ra kết quả là pcap file, CSV, hoặc XML. Nó còn có khả năng filter mạnh mẽ. Nếu WireShark chưa được cài đặt trên controller của bạn, bạn có thể tải nó bằng cách running command sau:

  $ sudo apt-get install wireshark

Figure 7-3 shows WireShark's GUI. Bạn sẽ chú ý đến source address của DNS queries là 172.16.176.138 - target VM. DNS server hồi đáp lại queries là 172.16.176.2, trên mỗi cấu hình trong bước phía trước. Bạn có thể nhìn thấy được target resolved hostnames trong wikipedia.orgvà google.com domains để giao tiếp với những servers này thông qua HTTP.

Using tshark

Nếu bạn thích các công cụ sử dụng command-line hơn (được khuyến khích cho việc phân tích tự động), bạn có thể sử dụng tshark , là một non-GUI version của Wireshark. Bạn có thể cài đặt nó như sau:

 $ sudo apt-get install tshark

Command sau đây shows cách để capture packets trên eth0 interface, tự động thoát ra sau 60 giây, và lưu packets vào output.pcap

 $ sudo tshark -i eth0 -a duration:60 -w output.pcap

Để đọc packets sử dụng cùng cách thức phân tích như GUI version của Wireshark, bạn có thể làm như sau:

 $ tshark -r output.pcap -V

Using tcpdump

tcpdump không bao gồm các phân tích giao thức mở rộng như Wireshark và tshark, nhưng nó cung cấp khả năng capture đáng tin và mạnh mẽ và các khả năng đọc trở lại. Nếu bạn cần cài đặt nó, sử dụng command sau:

 $ sudo apt-get install tcpdump

Command sau shows cách để capture packets trên eth0 interface đã được đánh đánh địa chỉ đến hoặc từ 172.16.172.138, và lưu tất cả bytes trong packet (thông qua việc thiết lập snaplen đến 0) trong output.pcap:

 $ tcpdump -i eth0 -s 0 -w output.pcap host 172.16.172.138

Từ khóa host là một trong nhiều BPF-style filters mà giúp cho bạn điều khiển chính xác những packets nào được lưu trong file của mình. Để có nhiều thông tin về BPF-style filters, gõ man tcpdump

Nếu bạn pass -r flag đến tcpdump, nó sẽ phân tích file packet capture được lưu.

 $ tcpdump -r output.pcap

Chúng tôi khuyến cáo bạn có thể pass -n flag để ngăn cho tcpdump khỏi thực hiện DNS lookups, những gì có thể tốn thời gian. Dĩ nhiên, nếu bạn muốn nhìn thấy DNS names thay cho IP addresses, đừng sử dụng -n flag.

Using snort IDS

Bạn có thể cài đặt Snort IDS lên controller của mình để cảnh báo bất cứ traffic đáng nghi nào gửi đến hoặc là gửi từ target machines trong khi malware đang running. Snort sẽ cho bạn một gợi ý tốt về các kiểu cảnh báo bạn sẽ nhìn thấy nếu một malware hay malware tương tự tồn tại trên mạng công ty. Commands sau tạo một simple Snort setup với Emerging Threats signatures trên controller của bạn:

 $ sudo apt-get install snort
 $ sudo wget -P /etc/snort/rules http://www.emergingthreats.net/rules/emerging-all.rules
 $ sudo echo 'include $RULE_PATH/emerging-all.rules' >> /etc/snort/snort.conf
 $ sudo /etc/init.d/snort start

Nếu bạn muốn kiểm tra xem mọi thứ thực hiện có thành công không hoặc nhìn xem command-line parameters startup script gửi đến Snort, khi đó bạn có thể view nó như sau:
 $ cat /proc/'pidof snort'/cmdline
/usr/sbin/snort –m 027 –D –d –l /var/log/snort –u snort –g snort –c \
/etc/snort/snort.conf –S HOME_NET=[172.16.176.0/24] –i eth0

http://iamtoet.blogspot.com/

Debugging

Debugger là một phần mềm hoặc phần cứng được sử dụng để kiểm tra và việc thực thi của một chương trình khác. Debuggers giúp sức trong quá trình phát triển phần mềm, bời vì các chương trình thường xuyên có những lỗi khi chúng được viết lần đầu tiên. Như khi bạn phát triển, bạn cung cấp input cho chương trình và nhìn vào output, nhưng bạn không thể biết được làm thế nào chương trình sinh ra kết quả như vậy. Debuggers cho bạn những cái nhìn sâu hơn về những gì chương trình làm khi nó đang thực thi. Debuggers được thiết kế để cho phép developers có thể đo lường (measure) và điều khiển (control) trạng thái bên trong và thực thi của một chương trình.

Debuggers cung cấp thông tin về một chương trình mà ta có thể rất khó hoặc là không thể khi sử dụng disassembler. Disassemblers cung cấp một snapshot về chương trình trước khi thực thi câu lệnh đầu tiên. Debuggers cung cấp một cái nhìn "động" về một chương trình như là nó run. Một ví dụ nhé, debuggers có thể show các giá trị memory addresses như chúng thay đổi xuyên suốt quá trình thực thi của một chương trình.

Khả năng đo lường và điều khiển thực thi của một chương trình cung cấp những hiểu biết quan trọng trong suốt quá trình phân tích malware. Debuggers cho phép bạn nhìn thấy mọi memory location, register, và argument đến mọi function. Debuggers còn giúp bạn thay đổi bất cứ thứ gì về thực thi chương trình vào bất cứ lúc nào. Cho ví dụ, bạn có thể thay đổi giá trị của một biến vào bất cứ thời điểm nào - tất cả những thứ bạn cần đó là thông tin đầy đủ về biến đó, bao gồm cả location của nó.

Source-Level và Assembly-Level Debuggers

Hầu hết software developers đều quen thuộc với source-level debuggers, những gì cho phép một programmer debug trong khi coding. Kiểu debugger này được tích hợp sẵn trong integrated development environments (IDEs). Source-level debuggers cho phép bạn đặt breakpoints, việc đặt breakpoints làm dừng thực thi chương trình  trên các dòng của source code, để kiểm tra trạng thái của các biến phía bên trong và đi qua (step through) thực thi của chương trình mỗi lần một dòng.

Assembly-level debuggers, thỉnh thoảng được gọi là low-level debuggers, hoạt động trên assembly code thay vì source code. Cũng như với source-code debuggers, bạn có thể sử dụng assembly-level debugger để step through một chương trình mỗi lệnh tại mỗi thời điểm, đặt breakpoints để dùng lại tại các dòng assembly code xác định, và phân tích memory locations.

Malware analysts thường sử dụng assembly-level debuggers bởi vì họ thường không có sẵn source code của một chương trình.

Kernel và User-Mode Debugging

Chúng ta gặp nhiều thách thức hơn khi debug kernel-mode code so với debug user-mode code bởi vì bạn phải cần tới 2 systems khác nhau cho kernel-mode. Trong user-mode, debugger đang running trên cùng một system với code được debugged. Khi debugging trong user mode, bạn đang debugging một single executable, những gì được tách rời với executables khác bởi hệ điều hành.

Kernel debugging được thực hiện trên 2 systems bởi vì chỉ có duy nhất một kernel; nếu kernel nằm tại một breakpoint, không có một ứng dụng nào có running trên system. Một system runs code được debugged, và system còn lại runs debugger. Ngoài ra, OS phải được cấu hình để cho phép kernel debugging, và bạn phải kết nối 2 machines.

Có 2 gói phần mềm dành cho user-mode debugging và kernel debugging. WinDbg là một công cụ phổ biến hỗ trợ cho kernel debugging. OllyDbg là một công cụ nổi tiếng  khác dành cho malware analysts . WinDbg cũng hỗ trợ user-mode debugging tốt, và IDA Pro có một built-in debugger, nhưng nó không cung cấp các tính năng hoặc dễ dàng sử dụng như OllyDbg.

Sử dụng Debugger

Có 2 cách debug một chương trình. Cách thứ nhất là start chương trình với debugger. Khi bạn start chương trình và nó được nạp vào trong bộ nhớ, nó dừng running trước thực thi của entry point của nó. Tại entry point, bạn có thể hoàn toàn điều khiển chương trình.

Bạn có thể gắn (attach) một debugger đến một chương trình khi nó đã running. tất cả threads của chương trình được paused, và bạn có thể debug nó. Đó là một cách tiếp cận tốt khi bạn muốn debug một chương trình sau khi nó đã running hoặc nếu bạn muốn debug một process bị ảnh hưởng bởi malware.

Single-Stepping 

Thứ đơn giản nhất có thể làm với một debugger là single-step qua một chương trình, điều đó có nghĩa là bạn run một lệnh và trả quyền điều khiển cho debugger. Single-stepping cho phép bạn nhìn thấy mọi thứ đang diễn ra bên trong một chương trình.

Bạn có thể single-step qua toàn bộ chương trình, nhưng bạn không nên làm như vậy khi gặp các chương trình phức tập bởi vì nó sẽ tiêu tốn một lượng thời gian khá lớn. Single-stepping là một công cụ tốt cho việc hiểu các chi tiết của một section code, nhưng bạn phải lựa chọn những code nào muốn phân tích. Tập trung vào bức tranh lớn, toàn cảnh hoặc là bạn sẽ bị lạc trong các tiểu tiết.

Ví dụ, disassembly trong Example 9-1 shows cách bạn có thể sử dụng một debugger để giúp bạn hiểu về một section code.

Example 9-1. Stepping through code
mov edi, DWORD_00406904
mov ecx, 0x0d
LOC_040106B2
xor [edi], 0x9C
inc edi
loopw LOC_040106B2
...
DWORD:00406904:       F8FDF3D0 (1)

Đoạn code sau có thể hiểu là truy nhập vào dữ liệu và sửa đổi nó trong một loop. Dữ liệu được hiểu thị tại cuối của (1) không phải là dạng ASCII text hay là bất cứ giá trị có thể nhận dạng nào, nhưng bạn có thể sử dụng một debugger để step through loop này để làm lộ ra đoạn code này đang làm gì.

Nếu bạn single-step qua loop này với hoặc WinDbg hoặc OllyDbg, bạn có thể nhìn thấy dữ liệu bị sửa đổi. Cho ví dụ, trong Example 9-2, bạn nhìn thấy 13 bytes được sửa đổi bởi hàm này thay đổi mỗi lần qua loop.

Example 9-2. Single-stepping through a section of code to see how it changes memory
D0F3FDF8 D0F5FEEE FDEEE5DD 9C (.............)
4CF3FDF8 D0F5FEEE FDEEE5DD 9C (L............)
4C6FFDF8 D0F5FEEE FDEEE5DD 9C (Lo...........)
4C6F61F8 D0F5FEEE FDEEE5DD 9C (Loa..........)
. . . SNIP . . .
4C6F6164 4C696272 61727941 00 (LoadLibraryA.)

Với một debugger được gắn vào, rõ ràng thấy rằng hàm này đang sử dụng single-byte XOR function để decode string LoadLibrary. Có thể khó khăn để nhận dạng string này chỉ với phân tích tĩnh.

Stepping-Over và Stepping-Into

Khi single-stepping qua code, debuggers dùng lại sau mọi lệnh. Tuy nhiên, khi bạn quan tâm đến những gì chương trình đang làm, bạn có thể không cần lo lắng về chức năng của mỗi call. Cho ví dụ, nếu chương trình của bạn calls LoadLibrary , bạn có thể không muốn step through mọi lệnh của LoadLibrary function.

Để điều khiển các lệnh mà bạn nhìn thấy trong debugger của bạn, bạn thể step-over hoặc là step-into các lệnh. Khi bạn step-over call instructions, bạn bỏ quả chúng. Cho ví dụ, nếu bạn step-over một call, lệnh tiếp theo bạn sẽ nhìn thấy trong debugger của bạn sẽ là lệnh đằng sau function call trả về. Mặt khác, bạn step-into một call instruction, lệnh tiếp theo bạn sẽ nhìn thấy trong debugger là lệnh đầu tiên của hàm được gọi.

Stepping-over cho phép bạn giảm một số lượng đáng kể các lệnh bạn cần phân tích, nhưng nó cũng tiềm tàng việc bạn có thể missing các chức năng quan trọng của chương trình phân tích nếu bạn step-over wrong functions. Thêm vào đó là một số lượng function calls không bao giờ return, và nếu chương trình của bạn gọi một function mà không bao giờ returns và bạn step-over nó, debugger sẽ không bao giờ giành lại được điều khiển. Khi điều đó xảy ra, khởi động lại chương trình và step đến cùng vị trí đó, nhưng lúc này, step-into funtion.

Pausing Excution với Breakpoints

Breakpoints được sử dụng để pause excution và cho phép bạn kiểm tra trạng thái của một chương trình. Khi một chương trình bị paused tại một breakpoint, nó được nhắc tới như làbroken . Breakpoints là cần thiết bởi vì bạn không thể access registers hoặc memory addresses trong khi một chương trình đang running, bởi vì các giá trị đó đang được thay đổi.

Example 9-3 demo nơi mà breakpoint trở nên hữu ích. Trong ví dụ này, có một lời gọi đến EAX. Trong khi disassembler không thể nói cho bạn biết function nào được gọi, bạn có thể set một breakpoint trên lệnh đó để tìm hiểu. Khi chương trình đụng phải breakpoint, nó sẽ bị dừng lại, và debugger sẽ show cho bạn giá trị của EAX, những gì là destination của hàm được gọi.

Example 9-3. Call to EAX
00401008 mov ecx, [ebp+arg_0]
0040100B mov eax, [edx]
0040100D call eax

Một ví dụ khác là trong Example 9-4 show điểm bắt đầu của một hàm với một lời gọi tớiCreateFile để mở một handle đến file. Trong assembly, rất khó khăn để xác định được tên của file, mặc dù một phần của tên được pass như là một parameter đến hàm. Để tìm file trong disassembly, bạn có thể sử dụng IDA Pro để search tất cả các lần mà hàm này được gọi để nhìn xem những arguments nào được gửi vào, nhưng nhiều giá trị cũng có thể được passed như là parameters hoặc đến từ các function calls khác. Có thể rất khó khăn để xác định filename. Sử dụng một debugger làm cho công việc trở nên rất dễ dàng.

Example 9-4. Using a debugger to determine a filename
0040100B xor eax, esp
0040100D mov [esp+0D0h+var_4], eax
00401014 mov eax, edx
00401016 mov [esp+0D0h+NumberOfBytesWritten], 0
0040101D add eax, 0FFFFFFFEh
00401020 mov cx, [eax+2]
00401024 add eax, 2
00401027 test cx, cx
0040102A jnz short loc_401020
0040102C mov ecx, dword ptr ds:a_txt ; ".txt"
00401032 push 0 ; hTemplateFile
00401034 push 0 ; dwFlagsAndAttributes
00401036 push 2 ; dwCreationDisposition
00401038 mov [eax], ecx
0040103A mov ecx, dword ptr ds:a_txt+4
00401040 push 0 ; lpSecurityAttributes
00401042 push 0 ; dwShareMode
00401044 mov [eax+4], ecx
00401047 mov cx, word ptr ds:a_txt+8
0040104E push 0 ; dwDesiredAccess
00401050 push edx ; lpFileName
00401051 mov [eax+8], cx
00401055 (1) call CreateFileW ; CreateFileW(x,x,x,x,x,x,x)

Chúng ta set một breakpoint trên một lời gọi đến CreateFileW tại (1), và sau đó nhìn vào các giá trị trên stack khi breakpoint được kích hoạt.

Bây giờ hãy tưởng tượng bạn có một mảnh malware và một packet capture. Trong packet capture, chúng ta nhìn thấy encrypted data. Chúng ta có thể tìm thấy lời gọi để gửi đi và chúng ta có thể khai phá ra encryption code, nhưng rất khó khăn để decrypt các dữ liệu đó, bởi vì bạn không biết encrytion routine hoặc key. May mắn thay, bạn có thể sử dụng một debugger để đơn giản hóa công việc bởi vì encryption routines thường là các hàm rời rạc mà chuyển dữ liệu.

Nếu bạn có thể tìm thấy encrytion routine được gọi, chúng ta có thể set một breakpoint trước khi dữ liệu đó được encrypted và nhìn xem dữ liệu được gửi.

Bạn có thể sử dụng một vài kiểu breakpoints, bao gồm software execution, hardware execution, và conditional breakpoints. Mặc dù tất cả breakpoints đều phục vụ chung một mục đích, phụ thuộc vào tình hình, một số breakpoints sẽ không làm việc được trong khi số khác làm việc được. Nào hãy cùng xét từng breakpoint một

Software Execution Breakpoints

Cho đến bây giờ, chúng ta đang nói về software execution breakpoints , những gì làm cho một chương trình dừng lại khi một lệnh được thực thi. Khi bạn set một breakpoint mà không có bất cứ options nào, hầu hết debbuggers phổ biến sẽ set software execution breakpoint bởi mặc định.

debugger implement một software breakpoint thông qua việc overwriting byte đầu tiên của một lệnh với OxCC, lệnh tương ứng với INT 3, breakpoint interrupt được thiết kế cho việc sử dụng với debuggers. Khi lệnh OxCC được thực thi, OS sinh ra một ngoại lệ và chuyển quyền điều khiển đến debugger.

http://iamtoet.blogspot.com/