Case Study: phân tích hiện trường sau khi bị thâm nhập.

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Case Studies

Case Study: phân tích hiện trường sau khi bị thâm nhập.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	15/02/2012 11:11:40 (+0700) \| #1 \| 253862

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Nhân tiện trang diễn đàn BKAV vừa bị tấn công (defaced và mất DB), tôi xin đưa ra một "case study" thực tế như sau:

Một trang web của công ty vừa bị thâm nhập. Để bảo đảm bảo mật và uy tín của công ty, theo bạn, công ty ấy cần khai triển những gì và lý do tại sao?

Cho rằng (các phiên bản đưa ra ở đây hoàn toàn là ngẫu nhiên): trang web ấy chạy trên hệ điều hành Windows 2003, sử dụng IIS làm reverse proxy, Apache phiên bản 2.2.15, PHP phiên bản 5.3, sử dụng software thương mại là vBulletin có phiên bản 4.1.5 và cơ sở dữ liệu là mysql phiên bản 5.1. Tất cả các dịch vụ đều chạy trên cùng một máy chủ (dedicated server) và được firewall của ISP bảo vệ.

Vui lòng khai triển ở góc độ "forensics" để từ đó mới có thể đưa đến biện pháp.

Mời các bạn tham gia.

What bringing us together is stronger than what pulling us apart.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	15/02/2012 12:03:48 (+0700) \| #2 \| 253873

baothu
Elite Member

Joined: 15/09/2003 02:42:15
Messages: 57
Offline

Em xin mở hàng,
Có gì sai sót mong anh Conmale và các bạn chỉ bảo thêm.
Trong trường hợp này ,theo em ,công ty này cần phải triển khai 1 số điều :

1. Công ty này nên thiết lập ngay một web server khác và 1 trang "In Maintenance" và ngắt ngay server bị tấn công khỏi network ,hay nói cách khác ,cách ly server đó.

Mục đích: Để bảo vệ uy tín cho công ty ,và để cho kẻ tấn công không phán đoán được hành động của nạn nhân ,1 trang "In Maintenance Mode" cũng không làm cho khách hàng lo lắng vì maintenance cũng là chuyện bình thường đối với mọi trang web.

Cách ly server đó ra khỏi network để tránh tình trạng bị alter data ,log ,hay configuration trên server ,nhằm phục vụ cho mục đích forensic.

2. Lập tức thông báo cho nhóm điều hành forum thay đổi ngay password cho tài khoản email, tài khoản ftp,remote admin (nếu service tương ứng được cài đặt trên máy họ) đồng thời đưa ra hướng dẫn tạo mật khẩu an toàn. Yêu cầu các thành viên trong nhóm điều hành tiến hành quét virus ,rootkit ,trojan trên máy của họ. Nếu phát hiện điều gì bất thường ,phải báo cáo lại cho bộ phận IT chịu trách nhiệm khắc phục sự cố.

Mục đích: Việc này đảm bảo rằng kẻ tấn công không còn giữ quyền kiểm soát email ,account ftp,remote admin (nếu có) của các thành viên trong nhóm điều hành forum. Ngoài ra ,bước này cho phép ta xác định nguồn của cuộc tấn công có bắt đầu từ việc mất pasword ,dính rootkit hay keylogger của các thành viên trong nhóm điều hành hay không. Nếu có thì sẽ xác định được quá trình họ bị mất password (password không tuân theo hướng dẫn tạo password an toàn) ,hay thông qua việc download các software trên chính forum hay từ nguồn khác. Điều này sẽ giúp xây dựng chính sách bảo mật hợp lý sau khi đã khắc phục được sự cố.

3. Mời ngay 1 công ty hay các chuyên gia có kinh nghiệm ứng cứu sự cố và forensic smilie

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	15/02/2012 16:05:00 (+0700) \| #3 \| 253913

Ikut3
Elite Member

Joined: 24/09/2007 23:47:03
Messages: 1429
Location: Nhà hát lớn
Offline

Để bảo đảm bảo mật và uy tín của công ty, theo bạn, công ty ấy cần khai triển những gì và lý do tại sao?

1. Để đảm bảo bảo mật

- Thực hiện việc phân tách hệ thống, nhằm đóng băng hệ thống cũ và xây dựng hệ thống mới. Tránh tình trạng downtime quá lâu

- Xây dựng 1 đội nghiên cứu hoặc thuê bên thứ 3 chịu trách nhiệm truy dấu vết của attacker để lại trên máy chủ cũ.

- Liên hệ với các cơ quan chức năng có thẩm quyền để "rộng" đường trong việc điều tra

- Xây dựng các giải pháp phòng tránh tạm thời để tránh tình trạng hệ thống bị thâm nhập 1 lần nữa

- Rà soát các dịch vụ, lỗ hổng -phần mềm máy chủ đang chạy. Kiểm tra các user / pc nhân viên có thẩm quyền liên quan đến hệ thống

2. Để đảm bảo uy tín công ty

- Trỏ domain hiện tại sang một trang thông cáo, nhằm truyền tải nội dung giữa Cty và khách truy cập. Tránh tình trạng các thông tin từ các phía truyền thông tuyên truyền sai lệch

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	15/02/2012 16:18:58 (+0700) \| #4 \| 253916

jerrykun
Member

Joined: 25/02/2011 18:01:09
Messages: 41
Location: error_log
Offline

Mình xin phân tích và trình bày quan điểm như sau:
1. web của công ty vừa bị thâm nhập.
2. Để bảo đảm bảo mật và uy tín của công ty theo bạn, công ty ấy cần khai triển những gì và lý do tại sao?

1. web của công ty vừa bị thâm nhập là hệ quả của một số nguyên nhân tồn tại trước đó khách quan hoặc chủ quan. (VD: cá nhân nghịch phá , đối thủ cạnh tranh không lành mạnh, quan hệ khách hàng hoặc cộng đồng không tốt, nhân viên kỹ thuật trong công ty nghỉ việc, quản trị hệ thống thiếu quan tâm đến các dịch vụ trên máy chủ web,cập nhập,fix bugs ...vv.)

2. Bảo đảm bảo mật và uy tín của công ty là quá trình xây dựng lâu dài, từ lúc thành lập công ty và tiếp diễn. Bất kỳ công ty nào làm khi làm kinh doanh đều phải xây dựng cho mình kế hoạch phục hồi sau thảm họa (Disaster Recovery). Kế họach khôi phục sau thảm họa là quá trình chuẩn bị, là phản ứng từ trên xuống dưới, tất cả cá nhân liên quan. Việc chuẩn bị tốt chu đáo kế hoạch phản ứng với các danh sách thảm họa đã được phân loại sẽ giúp công ty giảm thiểu thiệt hại về vật chất lẫn uy tín của mình.

- Tùy theo quy mô lớn nhỏ của công ty cũng như dịch vụ mà mình cung cấp( VD: Website availability 24/7 ) mà xây dựng kế hoạch Disaster Recovery cho phù hợp. Như vậy, việc xây dựng kế hoạch khắc phục sau thảm họa là việc cần triển khai trước tiên song song với sự phát triển của công ty. Còn tình huống web bị thâm nhập là xãy ra sau, và cần chấp nhập sự thật khi public web ra internet bị tấn công là vấn đề không tránh khỏi. Ghi nhận trường hợp của bkav và các thông tin từ các tờ báo online được xem là có uy tín ở việt nam phản ảnh: Cho thấy sự thiếu chuẩn bị và cách đánh giá vấn đề dẫn đến các hành động, phản ứng của cá nhân đại diện bkav được cộng đồng mạng đánh giá là bất lợi cho doanh nghiệp khi kinh doanh sản phẩm và dịch vụ của mình sau này.

- Việc đánh giá mực độ hậu quả một cách nghiêm túc,cũng như công việc thu thập thông tin để tìm ra nguyên nhân cốt lõi của vấn đề là việc cần thiết nên làm. Có thể thấy vấn đề nghiêm trọng trong trường hợp của bkav xuất phát từ cách hành xử, phản ứng đã tồn tại từ rất lâu, chứ không phải vấn đề bị tấn công (defaced và mất DB) và bị cài file "hacked.html" trên máy chủ. bkav bị tấn công(defaced và mất DB) là hậu quả tất yếu
xuất phát từ nguyên nhân là cách hành xử, phản ứng từ vụ bị tấn công trước đó.

- Như đã đề cập ở trên, Bảo đảm bảo mật là quá trình làm việc lâu dài song song với sự phát triển của công nghệ, là sự hợp tác từ cá nhân liên quan từ cấp Lãnh đạo tới nhân viên. Ghi nhận ý kiến của anh Conmale về kiện toàn bảo mật "Bảo mật ở các tầng, các lớp không đơn thuần chỉ cấu hình ứng dụng trên máy chủ web.

Thanks for viewing

Health, Knowledge, Family has the same value !

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	15/02/2012 18:36:47 (+0700) \| #5 \| 253925

K4i
Moderator

Joined: 18/04/2006 09:32:13
Messages: 635
Location: Underground
Offline

Chưa thấy bạn nào đề cập đến việc "làm việc các đơn vị chức năng có liên quan" như "Trung tâm an ninh mạng", "Lực lượng cảnh sát phòng chống tội pham công nghệ cao" nhỉ smilie

Sống là để không chết chứ không phải để trở thành anh hùng

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	15/02/2012 18:51:35 (+0700) \| #6 \| 253926

WinDak
Researcher

Joined: 27/01/2002 11:15:00
Messages: 223
Offline

comale wrote:

Cho rằng (các phiên bản đưa ra ở đây hoàn toàn là ngẫu nhiên): trang web ấy chạy trên hệ điều hành Windows 2003, sử dụng IIS làm reverse proxy, Apache phiên bản 2.2.15, PHP phiên bản 5.3, sử dụng software thương mại là vBulletin có phiên bản 4.1.5 và cơ sở dữ liệu là mysql phiên bản 5.1. Tất cả các dịch vụ đều chạy trên cùng một máy chủ (dedicated server) và được firewall của ISP bảo vệ.
Vui lòng khai triển ở góc độ "forensics" để từ đó mới có thể đưa đến biện pháp.

Theo em thấy thì website đã bị hack thì uy tín đã sứt mẻ rồi, việc còn lại là làm sao để không sứt mẻ thêm và phục hồi nó.

Dưới "góc độ forensic" thì việc tối quan trọng là tìm ra lỗ hổng và vá lỗi kịp thời. Nhưng cái khó ở đây là vừa tìm được lỗ hổng vừa phải đảm bảo việc làm ăn vẫn thuận lợi, đối với 1 công ty lớn chỉ cần đặt server offline 1p có thể thiệt hại nhiều tỉ đồng. Do đó cái một chiến lược tốt sẽ là một chiến lược "nhanh" mà vẫn "chắc". Ngoài những thứ các bạn khác đã nói ở trên thì mình xin bổ xung theo quan điểm của mình:

1) Luôn có 1 máy chủ dự phòng và thiết lập ở chế độ DEBUG mode và SAFE mode (disable các tính năng không cần thiết). Khi bị hack lập tức switch qua máy chủ này và lưu lại toàn bộ traffic vào ra để điều tra nếu hacker có ý quay lại.

2) Trong lúc đó khoanh vùng các application có khả năng bị lỗi cao. Cái này tùy thuộc nhiều vào dấu hiệu bị hack mà attacker để lại. (qua access log, event log của window, thời gian loggin, ip loggin). Ví dụ:
Nếu bị hack vào database thì khả năng cao là :
- sql injection trong vbulletin forums, các pluggin, app v.v..
- lỗi 0-day mysql server
Nếu bị deface / upload file lạ trên hệ thống:
- xem khả năng bị chiếm quyền root của server vì các ứng dụng webserver, php có lỗi 0-day
- khả năng admin bị cài virus và mất mật khẩu
- khả năng webserver bị lỗi cho upload file hay thay đổi file

3) Cùng lúc chạy các ứng dụng tìm rootkit kết hợp audit manually các file bị thay đổi trong hệ thống trong khoảng thời gian bị tấn công.

4) Sửa lỗi và thông báo cho các cơ quan chức năng, đặc biệt quan trọng theo mình là phải luôn trung thực, cầu tiến và bình tĩnh trong phát ngôn với các tổ chức bên ngoài.

-- w~ --

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	15/02/2012 18:58:33 (+0700) \| #7 \| 253928

Ikut3
Elite Member

Joined: 24/09/2007 23:47:03
Messages: 1429
Location: Nhà hát lớn
Offline

Ikut3 wrote:

- Liên hệ với các cơ quan chức năng có thẩm quyền để "rộng" đường trong việc điều tra

KAi wrote:

Chưa thấy bạn nào đề cập đến việc "làm việc các đơn vị chức năng có liên quan" như "Trung tâm an ninh mạng", "Lực lượng cảnh sát phòng chống tội pham công nghệ cao" nhỉ smilie

hứ hứ

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	15/02/2012 22:15:35 (+0700) \| #8 \| 253952

xnohat
Moderator

Joined: 30/01/2005 13:59:19
Messages: 1210
Location: /dev/null
Offline

Theo em, khi mà website đã bị deface như trường hợp BKAV vừa rồi thì công ty đó cần nhanh chóng ngắt cái server đó ra, thay bằng cái server khác như WinDak đề nghị, đấy là cách rất hay, vì các hacker có khả năng sẽ thử thâm nhập trở lại lần nữa nếu hắn thấy website đã bị hack nhưng đột ngột hoạt động trở lại.

Hơi ngoài lề một tí nhưng em thấy cần nói thêm:

Sau đó công ty nên soạn sẵn Thông cáo báo chí ( Media Release ), cung cấp đủ các thông tin, giải thích tình hình theo hướng có lợi cho công ty, rồi chủ động gửi cho các cơ quan báo chí, media, việc này sẽ giúp công ty nắm thế chủ động trong vấn đề kiểm soát thông tin. Nếu chậm chân, để các tờ báo, media phải tự mình tìm hiểu thông tin, xui xẻo họ hỏi đúng chỗ người ta không ưa mình thì nhiều khả năng các nhà báo, media sẽ được cung cấp các thông tin bất lợi cho công ty.

iJust clear, "What I need to do and how to do it"/i
br
brBox tán gẫu dời về: http://www.facebook.com/hvaonline

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	15/02/2012 22:38:43 (+0700) \| #9 \| 253954

rickb
Reseacher

Joined: 27/01/2007 17:47:27
Messages: 200
Offline

WinDak wrote:

comale wrote:

Cho rằng (các phiên bản đưa ra ở đây hoàn toàn là ngẫu nhiên): trang web ấy chạy trên hệ điều hành Windows 2003, sử dụng IIS làm reverse proxy, Apache phiên bản 2.2.15, PHP phiên bản 5.3, sử dụng software thương mại là vBulletin có phiên bản 4.1.5 và cơ sở dữ liệu là mysql phiên bản 5.1. Tất cả các dịch vụ đều chạy trên cùng một máy chủ (dedicated server) và được firewall của ISP bảo vệ.
Vui lòng khai triển ở góc độ "forensics" để từ đó mới có thể đưa đến biện pháp.

Theo em thấy thì website đã bị hack thì uy tín đã sứt mẻ rồi, việc còn lại là làm sao để không sứt mẻ thêm và phục hồi nó.

Dưới "góc độ forensic" thì việc tối quan trọng là tìm ra lỗ hổng và vá lỗi kịp thời. Nhưng cái khó ở đây là vừa tìm được lỗ hổng vừa phải đảm bảo việc làm ăn vẫn thuận lợi, đối với 1 công ty lớn chỉ cần đặt server offline 1p có thể thiệt hại nhiều tỉ đồng. Do đó cái một chiến lược tốt sẽ là một chiến lược "nhanh" mà vẫn "chắc". Ngoài những thứ các bạn khác đã nói ở trên thì mình xin bổ xung theo quan điểm của mình:

1) Luôn có 1 máy chủ dự phòng và thiết lập ở chế độ DEBUG mode và SAFE mode (disable các tính năng không cần thiết). Khi bị hack lập tức switch qua máy chủ này và lưu lại toàn bộ traffic vào ra để điều tra nếu hacker có ý quay lại.

2) Trong lúc đó khoanh vùng các application có khả năng bị lỗi cao. Cái này tùy thuộc nhiều vào dấu hiệu bị hack mà attacker để lại. (qua access log, event log của window, thời gian loggin, ip loggin). Ví dụ:
Nếu bị hack vào database thì khả năng cao là :
- sql injection trong vbulletin forums, các pluggin, app v.v..
- lỗi 0-day mysql server
Nếu bị deface / upload file lạ trên hệ thống:
- xem khả năng bị chiếm quyền root của server vì các ứng dụng webserver, php có lỗi 0-day
- khả năng admin bị cài virus và mất mật khẩu
- khả năng webserver bị lỗi cho upload file hay thay đổi file

3) Cùng lúc chạy các ứng dụng tìm rootkit kết hợp audit manually các file bị thay đổi trong hệ thống trong khoảng thời gian bị tấn công.

4) Sửa lỗi và thông báo cho các cơ quan chức năng, đặc biệt quan trọng theo mình là phải luôn trung thực, cầu tiến và bình tĩnh trong phát ngôn với các tổ chức bên ngoài.

Mình thấy phần chạy ứng dụng tìm rootkit trong điểm thứ 3 của Windak nêu ra không cần thiết lắm, vì theo mình thì 1 khi hệ thống đã bị owned thì không thể tin tưởng để tiếp tục sử dụng tiếp mà phải chuyển sang 1 máy chủ fresh khác (còn máy owned thì offline để forensic). Thay vì đó, ta nên tập trung time cho forensic thì tốt hơn smilie

-rickb

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	15/02/2012 22:51:26 (+0700) \| #10 \| 253957

gamma95
Researcher

Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline

Do hạn chế về trình độ, nên nếu là mình thì mình sẽ rút điện Server và gọi cho C50 nhờ vả

Cánh chym không mỏi
lol

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	15/02/2012 22:54:25 (+0700) \| #11 \| 253959

vulehcm
Member

Joined: 21/11/2011 20:37:50
Messages: 46
Offline

Có điểm này mình chưa thấy có bạn nào trình bày đó là việc xác thực log trước khi tiến hành mang nó đi phân tích. Đây có lẽ là một bước bình thường với những bạn quen việc phân tích log nhưng cũng có rất nhiều bạn quên làm bước này. Thực ra theo mình đây là một bước rất quan trọng, vì thường thì nếu attacker đã owned system thì sẽ xáo trộn log để xoá dấu vết hoặc là đánh lạc hướng điều tra, gây rắc và khó khăn trong việc điều tra. Kinh nghiệm bản thân là nếu xác định hoặc có dấu hiệu system bị owned thì không nên tin 100% vào log.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	15/02/2012 22:59:52 (+0700) \| #12 \| 253960

gamma95
Researcher

Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline

vulehcm wrote:

Có điểm này mình chưa thấy có bạn nào trình bày đó là việc xác thực log trước khi tiến hành mang nó đi phân tích. Đây có lẽ là một bước bình thường với những bạn quen việc phân tích log nhưng cũng có rất nhiều bạn quên làm bước này. Thực ra theo mình đây là một bước rất quan trọng, vì thường thì nếu attacker đã owned system thì sẽ xáo trộn log để xoá dấu vết hoặc là đánh lạc hướng điều tra, gây rắc và khó khăn trong việc điều tra. Kinh nghiệm bản thân là nếu xác định hoặc có dấu hiệu system bị owned thì không nên tin 100% vào log.

Đúng rồi, có khi nó còn dùng log để gắp lửa bỏ tay người smilie

Cánh chym không mỏi
lol

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	15/02/2012 23:34:17 (+0700) \| #13 \| 253964

chube
Member

Joined: 22/10/2010 02:34:04
Messages: 105
Location: ░░▒▒▓▓██
Offline

Sau khi đã tham khảo những giải pháp thiết thực và hữu ích từ những bài viết trên, em xin điểm thêm một vài chi tiết nhỏ để chúng ta có thể đưa đến 1 giải pháp tốt nhất cho case study này :
Về đối ngoại :

- Điểm đầu tiên, đã là một công ty tức phải có nhiều nhân sự và nhiều bộ phận, thiết nghĩ họ nên có chính sách rõ ràng cho từng bộ phận với nhiệm vụ và mục đích khác nhau khi đối phó với sự cố này. Ở đây ta thấy trang web là bộ mặt của một công ty - nơi khách hàng thường xuyên vào để cập nhật thông tin và tìm hiểu về sản phẩm - , nhất là với 1 công ty chuyên về bảo mật thì uy tín là rất quan trọng vì độ bảo mật luôn tỉ lệ thuận cũng sự uy tín.

+ Vậy giải pháp cần triển khai đầu tiên để đảm bảo uy tín trước tiên là ... tăng cường lại độ bảo mật. How ? Người làm bảo mật thì luôn đi kèm trách nhiệm cao, vì vậy ta cần thẳng thắn thông báo ,giải thích một cách chính xác và rõ ràng về sự 'bất thường' trên bằng cách tạo 1 trang thông báo về sự cố vừa qua - đối với home page - hoặc 1 thread - đối với forum - , dĩ nhiên là sau khi liên hệ bộ phận R&D để remove trang defaced, ta thấy có 2 điểm mang lại dấu hiệu tích cực

.1 là các phóng viên của các trang báo mạng vừa có thể cập nhật nguồn tin cho báo mình, vừa lọc được những đối tựơng khi họ liên hệ với ta để cập nhật thêm nguồn tin khác.
.2 là làm diệu dư luận với nội dung cô đọng, không quá che giấu sai lầm.

- Điểm thứ hai, Forum là 1 diễn đàn được công ty đầu tư để trở thành 1 nơi giao lưu giữa người sử dụng, khách hàng ...vv với đại diện của công ty, vì vậy chí ít ban quản trị diễn đàn cũng là 1 phần thể hiện cho bộ mặt, thái độ cũng như lời nói của công ty

+ Vậy giải pháp cần triển khai kế tiếp chỉ là chọn lựa những thành viên có kĩ năng mềm tốt - vì em không lầm thì ngành nào chúng ta cũng được đào tạo kĩ năng mềm dù ít hay nhiều - nhằm xoa diệu dư luận, giải thích bằng sự tỉnh táo, tránh áp dụng các hình thức dễ gây tiêu cực cho thành viên tham gia thảo luận như banned - trừ khi họ vi phạm nghiêm trọng luật đề ra - .

Về đối nội :
- Điểm thứ ba , rõ ràng ta cần phải xem xét hiện trừơng, ở đây em cũng có vài thắc mắc, BKAV cũng từng có vài bài post về hệ thống HoneyPot của họ, vậy với dấu hiệu cho thấy sự hiện diện của DDOS trên forum của họ thì HoneyPot lúc này đang đóng vai trò gì ?

+ Vậy giải pháp lúc này là : Liên hệ với bộ phận R&D hay technican để thực hiện truy cứu nguyên nhân, yêu cầu họ làm 1 bản report mô tả đầy đủ sự kiện với các tư liệu cụ thể vì đây là các bằng chứng quan trọng, mặt khác ta làm 1 công văn liên hệ với các cơ quan có thẩm quyền để cung cấp sự kiện, vật chứng, đẩy mạnh điều tra vì họ là những người có nghiệp vụ. Quan sát nội dung attacker để lại, ta có thể đặt giả thiết gì về mối quan hệ của những attacker này với đồng phạm bị bắt ? Cân nhắc kĩ trước khi quyết định vì thoả thuận không đạt có thể dẫn đến nhiều điều rắc rối khác - Rõ ràng attacker đã có DB nên xét cho cùng họ đang có lợi thế - .

-Cuối cùng, ta cần xem lại chuỗi mắc xích từ các tầng ứng dụng web, do mỗi đối tựơng có những phiên bản khác nhau nên :

+ Cần kết hợp các thông tin bảo mật về các lỗi 0 day nhằm thực hiện cập nhật các bản vá
+ Đưa ra các chính sách an toàn cho người dùng vì DB đã bị tiết lộ
+ Thực hiện các biện pháp kĩ thuật dựa trên kết cấu hạ tầng mà họ là người nắm rõ nhất.
+ Liên tục tham khảo các bài viết mang tính thiết thực ở các diễn đàn uy tín (như HVA chẳng hạn smilie

) !

.-/ / )
|/ / /
/.' /
// .---.
/ .--._\ Awesome Season to hack :') Dont you think so? xD
/ `--' /
/ .---'
/ .'
/

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 06:45:33 (+0700) \| #14 \| 253975

chiro8x
Member

Joined: 26/09/2010 00:38:37
Messages: 661
Location: /home/chiro8x
Offline

1. Đưa hệ thống phòng hờ vào vận hành, hệ thống này lưu trử trạng thái của lần hoạt động ổn định gần nhất từ hệ thống chính.
- Lí do : Việc ngưng cung cấp dịch vụ vào lúc này càng làm suy giảm uy tín, nhưng bên cạnh đó cần khuyến cáo cho người dùng về những khả năng có thể xãy ra. Và mức độ nghiêm trọng của sự việc.

2. Tìm kiếm giải pháp tình thế khả thi, áp dụng lên hệ thống phòng hờ, theo dỏi hệ thống phòng hờ và khả năng hệ thống phòng hờ bị tấn công.
- Lý do : Trong lúc chúng ta mãi mê với việc tìm ai là thủ phạm thì hệ thống phòng hờ lại bị tấn công một lần nữa đó có lẽ là việc làm chẳng khôn ngoan cho lắm.

3. Cách ly hệ thống gây lỗi và có khả năng gây lổi để tìm hiểu nguyên nhân. Tìm hiểu mức độ thiệt hại sau khi bị tấn công, các phương thức tấn công...cập nhật các bản patch gần nhất, tìm cái giải pháp tình thế.
- Lý do : Cần phải tìm nguyên nhân gây lỗi, ứng dụng, services gây lỗi, phương thức người khác dùng để thâm nhập....

4. Đưa những thông tin sai lệch về tình hình lỗi, và nguyên nhân gây lỗi cho báo chí.
- Lý do : báo chí chẳng quan tâm tới kỹ thật, và cũng không nhất thiết phải khai nhà tôi có gì, những thông tin sai lệch thế này sẽ làm giảm khả năng bị tấn công.

5. Xem xét lại tổng thể vụ việc, đánh giá về khả năng khắc phục, mức độ của sự việc.
+ Hệ thống không bị hư hại nghiêm trọng -> đưa ra các biện pháp khắc phục.
+ Hệ thống bị hư hại hư hại ít -> Tìm hiểu các bện pháp kỹ thuật thay thế, và tìm kiếm sự tư vấn từ các nhà bảo mật.
+ Hệ thống bị hư hại nghiêm trọng -> Tìm kiếm sự giúp đở từ các cơ quan điều tra, và các tổ chức có uy tín.
- Lý do : Tuỳ theo mức độ của sự việc mà xem xét về nhân lực và vật lực có đủ để tiến hành khắc phục sự cố hay không.

6. Làm sạch hệ thống chính, sửa chửa và đưa vào vận hành.
- Lý do : Hệ thống chính có thể đã bị nhiễm backdood,

7. Đưa hệ thống chính vào vận hành và kiểm tra hệ thống phòng hờ.
- Lý do : Trong quá trình duy trì dịch vụ trên hệ thống phong hờ, có thể một số biện pháp tấn công khác đã được triển khai.

8. Công bố thông tin về sự cố (1 phần của sự thật là đủ) và hổ trợ người dùng bảo vệ an toàn thông tin.
- Lý do : Không nên cho những người không nên biết, biết quá nhu cầu biết của họ.

9. Đặt các giả thiết về khả năng bị tấn công, rà soát và loại bỏ.
- Lý do : Khả năng bị tấn công do chính người trong công ty, người tấn công tiếp xúc vật lý với hệ thống....

10. Sống cho đàng hoàng đừng để thiên hạ ghét.
- Lý do : Để những lần bị hack sau không tới sớm hơn.

while(1){}

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 07:13:31 (+0700) \| #15 \| 253979

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

WinDak wrote:

comale wrote:

Cho rằng (các phiên bản đưa ra ở đây hoàn toàn là ngẫu nhiên): trang web ấy chạy trên hệ điều hành Windows 2003, sử dụng IIS làm reverse proxy, Apache phiên bản 2.2.15, PHP phiên bản 5.3, sử dụng software thương mại là vBulletin có phiên bản 4.1.5 và cơ sở dữ liệu là mysql phiên bản 5.1. Tất cả các dịch vụ đều chạy trên cùng một máy chủ (dedicated server) và được firewall của ISP bảo vệ.
Vui lòng khai triển ở góc độ "forensics" để từ đó mới có thể đưa đến biện pháp.

Theo em thấy thì website đã bị hack thì uy tín đã sứt mẻ rồi, việc còn lại là làm sao để không sứt mẻ thêm và phục hồi nó.

Dưới "góc độ forensic" thì việc tối quan trọng là tìm ra lỗ hổng và vá lỗi kịp thời. Nhưng cái khó ở đây là vừa tìm được lỗ hổng vừa phải đảm bảo việc làm ăn vẫn thuận lợi, đối với 1 công ty lớn chỉ cần đặt server offline 1p có thể thiệt hại nhiều tỉ đồng. Do đó cái một chiến lược tốt sẽ là một chiến lược "nhanh" mà vẫn "chắc". Ngoài những thứ các bạn khác đã nói ở trên thì mình xin bổ xung theo quan điểm của mình:

1) Luôn có 1 máy chủ dự phòng và thiết lập ở chế độ DEBUG mode và SAFE mode (disable các tính năng không cần thiết). Khi bị hack lập tức switch qua máy chủ này và lưu lại toàn bộ traffic vào ra để điều tra nếu hacker có ý quay lại.

2) Trong lúc đó khoanh vùng các application có khả năng bị lỗi cao. Cái này tùy thuộc nhiều vào dấu hiệu bị hack mà attacker để lại. (qua access log, event log của window, thời gian loggin, ip loggin). Ví dụ:
Nếu bị hack vào database thì khả năng cao là :
- sql injection trong vbulletin forums, các pluggin, app v.v..
- lỗi 0-day mysql server
Nếu bị deface / upload file lạ trên hệ thống:
- xem khả năng bị chiếm quyền root của server vì các ứng dụng webserver, php có lỗi 0-day
- khả năng admin bị cài virus và mất mật khẩu
- khả năng webserver bị lỗi cho upload file hay thay đổi file

3) Cùng lúc chạy các ứng dụng tìm rootkit kết hợp audit manually các file bị thay đổi trong hệ thống trong khoảng thời gian bị tấn công.

4) Sửa lỗi và thông báo cho các cơ quan chức năng, đặc biệt quan trọng theo mình là phải luôn trung thực, cầu tiến và bình tĩnh trong phát ngôn với các tổ chức bên ngoài.

Mình xin bổ sung thêm 1 ý kiến, sau bước 1 của WinDak mình sẽ nhanh chóng xác định chính xác với biên độ khoảng 5-10 phút thời điểm trước,diễn ra và sau khi hệ thống bị xâm nhập. Sau đó tới bước 2 WinDak đề cập mình sẽ kết hợp với phần thông tin trên Firewall cùa ISP thực hiện forensic.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 07:39:46 (+0700) \| #16 \| 253980

vulehcm
Member

Joined: 21/11/2011 20:37:50
Messages: 46
Offline

Đối với một doanh nghiệp kinh doanh thì mình nghĩ nên có thêm 2 phần quan trọng sau:

1. Các bộ phận liên quan ví dụ support, call center, marketing, ... lập một report về các quan hệ khách hàng trong thời gian gần nhất, tìm hiểu và xác định rõ ràng lý do bị tấn công từ đó khoanh vùng các mục tiêu để dễ dàng làm việc. Các bộ phận như nhân sự, quản lý, ... cũng làm việc tương tự nhưng lại tìm hiểu và xác định lý do bị tấn công trên góc nhìn người trong doanh nghiệp.

2. Làm một bản report tương tự nhưng đối tượng nghiên cứu lại là các khách hàng lớn, các doanh nghiệp liên kết hoặc là với các quan hệ doanh nghiệp phức tạp nhằm tìm hiểu lý do. Có rất nhiều cuộc tấn công xuất phát từ lý do kinh doanh.

Ngoài ra, nếu ngay từ đầu có kế hoạch quản lý rủi ro (risk management plan) nào đó thì nên áp dụng ngay bây giờ.

P/s: những lúc thế này mới thấy việc ngay từ đầu tổ chức, xây dựng chặc chẽ là rất quan trọng và hữu ích.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 07:58:40 (+0700) \| #17 \| 253981

.lht.
Member

Joined: 26/09/2010 10:06:38
Messages: 75
Location: Inside you
Offline

Với mình thì trước khi làm 1 cái gì đó cũng phải có 1 plan.

Plan và các quá trình của mình sẽ như sau:

TRƯỚC KHI TRIỂN KHAI DỊCH VỤ

1) Thu thập thông tin
- Công đoạn này là xem xét kĩ yêu cầu của công việc và dịch vụ.
=> Tránh thiếu sót hay thừa thãi về sau.
2) Chuẩn bị
- Liệt kê ra 1 danh sách những gì ta cần để thực hiện như là: nguyên liệu (máy chủ, phần mềm, ...)
- Ở bước này kèm theo luôn cả tìm hiểu thông tin về những nguyên liệu đó - như là cấu hình phần cứng liệu có đủ, phần mềm version nào ổn định, tìm hiểu thêm xem có bug mới nào của nó đã được report .... và cuối cùng là theo cảm tính đánh giá về hãng cung cấp để lựa chọn sản phẩm.
- Với yêu cầu đề ra ở đây là "Đảm báo tính bảo mật và uy tín", ta cần dự phòng và tính trước những sự cố -> Chuẩn bị server dự phòng.
- Chuẩn bị nhân lực, phân chia công việc rõ ràng.

TRIỂN KHAI DỊCH VỤ
1) Xây dựng
- Cài đặt và cấu hình server cẩn thận, phân quyền rõ ràng <> Phần lớn các công ty hiện nay mình thấy họ sử dụng tài khoản root để chạy chung các dịch vụ/ tác vụ trên server.
2) Thử nghiệm và theo dõi trước khi đưa vào sử dụng
- Tiến hành chạy thử và theo dõi kiểm tra xem có phát sinh lỗi gì hay không, ...

SAU KHI TRIỂN KHAI DỊCH VỤ
1) Theo dõi
- Kiểm tra log liên tục.
- Theo dõi và ghi nhận những điểm "không ổn" và đưa ra phương án để "giải quyết".
- Luôn luôn cập nhật thông tin về các bug,exploit và update hệ thống.
2) Thu thập ý kiến đóng góp người dùng ...

SỰ CỐ SAU KHI TRIỂN KHAI DỊCH VỤ
* Bước này sẽ được giải quyết đơn giản hơn nếu mà ta từ những bước trước chuẩn bị sẵn.
1) Ngắt hoàn toàn các hoạt động của máy chủ chính và những hoạt động liên quan của nó và đưa máy chủ dự phòng vào hoạt động.
2) Đưa ngay thông báo/ cảnh báo đến người dùng.
3) Tiến hành phân tích và điều tra phát hiện lỗi:
- Nếu chúng ta thường xuyên theo dõi log và cập nhật thông tin mới, ta sẽ thu thập được từ đó những thông tin hữu ích.
- Nếu quyền hạn được phân chia rõ ràng, cũng góp phần giúp ta nhanh chóng khoanh vùng đối tượng.
4) Còn tuỳ vào tính chất sự việc mà liên hệ với bên thứ 3 để "cùng giải quyết".
-------------------------------------------

Ở đây theo ý kiến cá nhân của riêng mình, thì trước khi làm 1 cái gì đó cũng nên liệu trước các vấn đề có thể sảy ra và chuẩn bị sẵn từ trước.
Như tình huống của anh conmale đưa ra, nếu ta ngay từ đầu đã đề phòng và chuẩn bị trước thì đã không đến nỗi tệ hại lắm smilie

Còn về uy tín của công ty, không có gì là hoàn hảo cả. Cái "uy tín" này còn phải dựa vào cách ứng xử của công ty đó trong trường hợp này thế nào, có khiến người dùng mất cảm tình hay không mà thôi smilie

)

Trash from trash is the place for new good things ~

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 08:05:53 (+0700) \| #18 \| 253982

vd_
Member

Joined: 06/03/2010 03:05:09
Messages: 124
Offline

1. Cách ly server và đưa vào môi trường riêng để forensic
2. Dựng maintenance server (@baothu)
3. Trong khi chưa tìm ra why, when, how thì nên rebuild server từ đầu, không restored từ backup
4. Press release: sorry khách hàng, tự nhận lỗi, thông báo tình trạng đang điều tra, điếu đóm báo chí (ở VN phải vậy) PR của Cty hơi bị mệt a
5. Bây giờ đến bước forensic:
5.1 đọc log. Hệ thống có central log server + lưu hash integrity thường xuyên + backup log thường xuyên => chúc mừng, nếu để log trên chính server đó thì chia buồn
5.2 đọc log firewall, ids&ips và packet dump server để xem traffic vào ra server như thế nào
5.3 live memory dump qua 1 máy khác và dùng tool để xem các process nào đang chạy, các file handle nào đang open và các network connection như thế nào
5.4 tắt server, gỡ disk và scan toàn bộ disk kiếm coi có gì nữa không
6. Trả lời được when => restore từ backup trước đó
Trả lời được how => patch, fix và update system & network
Trả lời được why => sửa policy, process, company image
Trả lời được who => call 113
7. Xong hết nên có press release
8. Share kinh nghiêm trên HVA smilie

hoặc cộng đồng chuyên gia để mọi người cùng học hỏi (như apache đã từng làm).

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 08:17:33 (+0700) \| #19 \| 253984

.lht.
Member

Joined: 26/09/2010 10:06:38
Messages: 75
Location: Inside you
Offline

To chiro8x:
- Cung cấp thông tin sai lệch cho báo chí sẽ làm ảnh hưởng rất nhiều đên danh dự và uy tín của công ty đó bạn smilie

Trong trường hợp này, người ta thường không cung cấp bất cứ thông tin gì và chờ đến lúc điều tra rõ ràng.

To vd_:
- Rebuild lại server sẽ mất thời gian -> tăng thời gian downtime của hệ thống. Vì vậy ngay từ đầu nếu ta chuẩn bị sẵn server dự phòng thì sẽ khác.

Nếu có thể thì mình thiết lập 2 hệ thống khác nhau (cấu hình, phần mềm, ... ?), hệ thống chính nếu bị tấn công thì đưa hệ thống thứ 2 vào.

Trash from trash is the place for new good things ~

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 08:38:57 (+0700) \| #20 \| 253988

vulehcm
Member

Joined: 21/11/2011 20:37:50
Messages: 46
Offline

Trong đề trên chỉ có một máy chủ thôi các bạn à. Các bạn cứ đưa ra hệ thống này hệ thóng nọ theo ý của các bạn rồi trả lời trên hệ thống của các bạn thì không thiết thực lắm. Nếu trả lời theo kiểu đó tớ cũng có thể nói "Ngay từ đầu nên đầu tư khoảng 30 server, đường truyền 5GB/s và thuê 40 chuyên gia và 10 anh C50 liên tục canh ngày này qua ngày khác, có chuyện gì cứ tấp cho C50".

Nhắc lại đề của anh conmale cho các bạn Linux admin:

Cho rằng (các phiên bản đưa ra ở đây hoàn toàn là ngẫu nhiên): trang web ấy chạy trên hệ điều hành Windows 2003, sử dụng IIS làm reverse proxy, Apache phiên bản 2.2.15, PHP phiên bản 5.3, sử dụng software thương mại là vBulletin có phiên bản 4.1.5 và cơ sở dữ liệu là mysql phiên bản 5.1. Tất cả các dịch vụ đều chạy trên cùng một máy chủ (dedicated server) và được firewall của ISP bảo vệ.

Có bạn nào nghĩ đến chuyện ngay từ đầu chúng ta sẽ triển khai 2 VPS trên dedicated server này không (anh conmale không nói rõ điểm này) ? Lúc đó thì forensics thế nào nhỉ?

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 09:21:24 (+0700) \| #21 \| 253993

leaves
Member

Joined: 15/02/2012 02:18:57
Messages: 1
Offline

Mình xin góp chút ý kiến, có vẻ mang tính lý thuyết nhưng mình nghĩ là cần thiết.
Chuẩn bị:
- Có kế hoạch dự phòng thảm họa - càng chi tiết càng tốt, chỉ rõ vai trò, chức năng các bộ phận, cách thức phản ứng với một số trường hợp cụ thể như DDoS, mất quyền, lỗi liên quan đến DNS v.v...
- Định kỳ diễn tập như diễn tập quân sự để tăng cường khả năng phối hợp
Trong quá trình vận hành:
- Định kỳ xem qua log, đặc biệt các log liên quan đến quản trị, có thể dung tool để filter - mình nghĩ cái này rất quan trọng, trong diễn đàn cũng nhiều chủ đề về cái này. giám sát log mới có khả năng phát hiện sớm những nguy cơ, rủi ro tấn công cũng như các lỗi khác của hệ thống - Nếu có thể, đẩy log ra 1 hệ thông ngoài để lưu trữ, phân tích định kỳ (Spunk chẳng hạn)
- Thường xuyên theo dõi, cập nhật các bản vá liên quan, signature của FW, IPS
Phản ứng khi bị tấn công:
- Nếu đã có kịch bản sẽ chủ động hơn trong việc phòng chống
- các biện pháp thì các bác phía trên đã bàn nhiều rồi smilie

Sau khi bị tấn công:
- Rà soát xem có rút được bài học kinh nghiệm gì không, cố gắng học từ sai lầm của người khác chứ đừng để mình mắc lỗi rồi mà vẫn không học được gì smilie

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 12:53:52 (+0700) \| #22 \| 254010

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

conmale wrote:

Vui lòng khai triển ở góc độ "forensics" để từ đó mới có thể đưa đến biện pháp.

Mời các bạn tham gia.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 13:06:55 (+0700) \| #23 \| 254011

sieunhan93
Member

Joined: 07/05/2007 22:21:29
Messages: 4
Offline

Em nghĩ như sau smilie

1. Triển khai một server backup phòng cho việc bị tấn công thế này, 2 server luôn đồng bộ với nhau và luôn dưới dạng passive và active, khi nào bị tấn công 1 server thì lập tức ngắt server để xử lí. Tất nhiên là khi ngắt server chính thì server phụ vẫn chứa lỗi tiềm tàng của server chính. Nhưng mình sẽ tạm thời thay đổi password của admin để phòng việc bị lộ pass. Việc đổi pass có thể mã hoá md5 2 lần để tránh việc attacker brute-force thành công

2. Triển khai IDS/IPS bằng snort để lưu lại log rồi từ đó phân tích file log để phát hiện truy cập. Triển khai firewall để đưa ra các chính sách bảo mật

3. Luôn luôn update các bản vá mới nhất cho windows cũng như IIS, Apache, tham gia nhiều trang UG hoặc các trang công bố các exploit của server, vbb để fix lỗi ngăn ngừa

4. Kiểm tra kĩ các permission của các user

5. định kì backup server 1 tuần 1 lần để tránh tổn thất khi bị tấn công, quét shell liên tục phòng tránh server bị up shell

6. Nhiều kiddiescript có thể vọc vạch nên cấu hình host cẩn thận, không cho up shell, không cho attacker có thể bypass (tất nhiên với những người nhiều kinh nghiệm thì vẫn có thể)

7.Khi bị tấn công thì phải thừa nhận và công bố trên báo chí, không quăng boom và nguỵ biện như bkav smilie

Việc này đảm bảo được uy tín bởi vì tâm lí người dùng không muốn bị lừa đảo tránh để báo chí viết lung tung gây ảnh hưởng

8. Hợp tác với các cơ quan như C50, ISP để điều tra

9. Mời các hacker tấn công để kiểm tra hệ thống, trao thưởng cho hacker mũ trắng phát hiện lỗi v nhằm tăng uy tín và fix được lỗi hệ thống smilie

Mong được các anh chỉ giáo thêm smilie

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 14:40:07 (+0700) \| #24 \| 254019

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Bà con tham gia rất nhiệt tình. Mới có 1 ngày mà có đến 22 thảo luận và gần 900 views smilie

. Chứng tỏ "case study" có sự lôi cuốn vì tính thực tế của nó.

Xuyên suốt các thảo luận cho đến nay, hầu hết mọi khía cạnh đều được đề cập đến nhưng tiêu điểm vẫn chưa được khai thác đúng mức mà có chiều hướng nghiêng hẳn về phía "phòng chống" (mặc dù có vài bạn nhắc nhỏ smilie

). Thật ra, khai triển nặng ở góc độ forensics không đơn giản, nhất là chúng ta không có gì để mà... điều tra cụ thể nhưng forensics vẫn có thể được khai triển ở cấp độ khái niệm.

Trước tiên, chúng ta nên xét thật kỹ "đề bài" bởi vì nó gói ghém những chi tiết quan trọng để dựa vào đó mà phân loại và xoáy sâu vào từng phần. Cái này cũng giống như một đề toán hoặc một chỉ thị (cấp trên) đưa xuống để đám kỹ thuật khai triển vậy. Chủ đề cung cấp những thông tin sau:

"Cho rằng (các phiên bản đưa ra ở đây hoàn toàn là ngẫu nhiên): trang web ấy chạy trên hệ điều hành Windows 2003, sử dụng IIS làm reverse proxy, Apache phiên bản 2.2.15, PHP phiên bản 5.3, sử dụng software thương mại là vBulletin có phiên bản 4.1.5 và cơ sở dữ liệu là mysql phiên bản 5.1. Tất cả các dịch vụ đều chạy trên cùng một máy chủ (dedicated server) và được firewall của ISP bảo vệ. ".

Chúng ta có gì?

a. Một máy chủ có nhiều dịch vụ.
b. Máy chủ ấy được ISP bảo vệ.
c. Phiên bản của của hệ điều hành và các dịch vụ.

Khi nói đến điểm a và nói đến forensics, chúng ta nghĩ ngay đến khả năng bị thâm nhập ngay trên 1 máy chủ bởi vì giới hạn được đưa ra chỉ gói ghém trên 1 máy. Khi nói đến 1 dedicated server, ta dễ hình dung đến khả năng penetrate đến chính máy chủ ấy thay vì nhảy từ một máy chủ láng giềng nào khác. Điều này có thể (hoặc có thể không) giới hạn biên độ điều tra bởi vì nếu chưa xét rõ xem ngoài dedicated server ấy, nạn nhân có sở hữu máy chủ nào gần đó và mở toang cửa để thâm nhập và dùng nó làm bàn đạp để xâm nhập mục tiêu?

Tôi đã từng va phải trường hợp (khi audit một số hệ thống) là bên cạnh máy chủ được sử dụng chính thức (máy A) còn có một máy khác dùng để thử nghiệm (máy B). Khốn khổ là từ máy B có thể rsh hoặc rlogin thẳng vô máy A mà không cần xác thực gì hết. Bởi vậy, bỏ rơi khả năng "máy chủ láng giềng" có thể là bỏ hẳn một mảng rất lới giúp mang lại kết quả cho việc điều tra.

Khi nói đến điểm b, chúng ta nói đến khả năng máy chủ kia hoàn toàn không có cơ chế bảo vệ mà chỉ phụ thuộc vào "dịch vụ bảo vệ" mà ISP cung cấp. Đây có thể là sự trông cậy chết người mà chủ nhân của máy chủ ấy vướng phải. Chẳng có gì bảo đảm rằng hệ thống bảo vệ của ISP chặt chẽ và đúng với nhu cầu và cấu hình thực tế trên cái dedicated server này. Firewall, IPS, IDS..v...v... không thể hoàn toàn lấp được những lỗi và những tắc trách trong cấu hình. Đó là chưa kể khi đụng tình huống, liệu ISP có lưu giữ những thông tin cần thiết cho mục đích forensics hay không?

Điểm c giúp ta xác định các vectors có thể (Windows 2003, Apache, IIS, PHP, vBB, Mysql). Đây có lẽ là những mảnh thông tin rõ ràng nhất và dễ dàng nhất (bug-track everyone? smilie

) nhưng cũng là mảnh cần nhiều thời gian để phân tích logs, điều tra các lỗ hổng ..v..v....

Hãy thử nhìn sự việc ở góc độ một chuyên viên bảo mật và điều tra thay vì ở góc độ một "lính" được sai để... đánh smilie

. Hãy nhìn bức tranh tổng thể và hình thành cụ thể "kế hoạch tác chiến" từng mảnh một từ những điểm a, b và c. Khoan hãy nhảy thẳng vào góc độ "phòng chống" bởi vì chưa có gì rõ ràng hết.

Mời bà con tiếp tục.

What bringing us together is stronger than what pulling us apart.

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 14:58:51 (+0700) \| #25 \| 254020

phanledaivuong
Member

Joined: 23/05/2008 17:34:21
Messages: 315
Location: /dev/null
Offline

Do khai triển ở góc độ "forensics" nên em sẽ giả sử như 1 vụ tai nạn giao thông để dễ điều tra theo, như công an hay làm.

Tai nạn giao thông thì đầu tiên là phải:

- Giữ nguyên hiện trường = Giữ nguyên hiện trạng của máy chủ, tách máy chủ này ra khỏi mạng network, không thay đổi gì cả để tiện điều tra. (Chứ giờ thằng này đang sang đường sai lè, người nhà nó chạy ra đá hộ vào cái công tắc "xi nhan" thì công việc điều tra hỏng hết)

- Giúp việc đi lại được tiến hành bình thường:
+ đối với ô tô to (Không có 1 server để chạy dự phòng ) -> căng dây báo hiệu cho các xe không đi vào = cho đăng 1 thông báo website đang bảo trì hệ thống.
+ đối với xe cơ giới loại nhỏ, xe máy, xe đạp (có 1 server để chạy dự phòng khi gặp sự cố ) = tiếp tục cho website chạy bình thường. máy chủ này bật chế độ monitor lại, để monitor lại toàn bộ mọi thứ tác động đến máy chủ.

- Thông báo với gia đình nạn nhân = thông báo các thông tin cần thiết cho khách hàng, để tránh tình trạng 1 số báo lá cãi đưa tin bậy. (việc này là để đảm bảo uy tín của công ty, tránh tình trạng như BKAV )

- Điều tra xem lái xe có uống rượu bia, và gia đình có tiểu sử về bệnh thần kinh hay không = kiểm tra xem các ứng dụng được cài đặt trên server có lỗi gì không?

- Xem các yếu tố tác động trực tiếp và gián tiếp đến vụ tai nạn = Yêu cầu ISP cung cấp thêm các thông tin để tiện điều tra.

- Truy tìm thằng gây tai nạn xong bỏ chạy = bắt thằng hack smilie

gamma95 wrote:

Do hạn chế về trình độ, nên nếu là mình thì mình sẽ rút điện Server và gọi cho C50 nhờ vả

Đọc bài của bác gà mở mà em rối tung đầu, chả biết thảo luận cái gì nữa

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 16:28:20 (+0700) \| #26 \| 254035

.lht.
Member

Joined: 26/09/2010 10:06:38
Messages: 75
Location: Inside you
Offline

Hì,

Có lẽ tại quá chú ý vào "Để bảo đảm bảo mật và uy tín của công ty, theo bạn, công ty ấy cần khai triển những gì và lý do tại sao?" nên em đi sang chiều hướng phòng chống.

Do bản thân em cũng chưa được trải nghiệm thực tế hay được chỉ dẫn qua nên có thế cái góc nhìn của em vẫn chưa được rõ ràng, các ý kiến nêu ra cũng chỉ là ý kiến cá nhân. Nhưng không sao smilie

tiếp tục lấy sự "hóng hớt" và "bồi dưỡng" thêm kiến thức và tiếp tục thảo luận là tiêu chỉ smilie

Ở đây chúng ta nắm được các thông tin sau:

a. Một máy chủ có nhiều dịch vụ.
b. Máy chủ ấy được ISP bảo vệ.
c. Phiên bản của của hệ điều hành và các dịch vụ.

Điều cần làm trước hết khi sảy ra sự cố:
1) Dữ nguyên hiện trạng và cách ly máy chủ này.
2) Thông báo/ Cảnh báo đến người sử dụng. (Điều này nên thực hiện sớm nhất có thể, nó sẽ ảnh hưởng đến cách đánh giá từ phía người sử dụng)
3) Sử dụng máy chủ dự phòng để đưa dịch vụ hoạt động trở lại - song song đó tiến hành theo dõi kĩ lưỡng các truy cập (Nếu ta đứng ở phía attacker, với cái tâm lý "hả hê" thì cứ vài phút lại F5 trở lại coi thành quả của mình chẳng hạn smilie

hoặc attacker vô tình để lộ thông tin.)

Tiến hành phân tích máy chủ bị thâm nhập
1) Nhìn ngay vào cái đồng hồ, khoanh vùng thời gian sảy ra sự cố.
2) Khoanh vùng đối tượng.
- Trước khi đi sâu vào kĩ thuật, xem xét khả năng nhân viên để lộ mật khẩu.
- Kiểm tra các kết nối "đặc quyền" được cho phép từ bên ngoài.
- Cuối cùng mới đi vào kĩ thuật.
3) Khi đi vào kĩ thuật, đầu tiên ta sẽ chú ý đến "hệ thống phòng thủ" vốn có
- Lúc này xem xét lại khả năng phát hiện và ngăn chặn của hệ thống, ghi nhận những điểm yếu kém của nó - Góp phần giúp ta suy đoán ra phuơng thức attacker sử dụng.
4) Thu thập thông tin từ logs và tìm hiểu về lỗ hổng của phần mềm
- Dựa vào những dấu hiệu mà ta suy đoán.

Điều tra attacker (Còn tuỳ trường hợp và tình huống)
1) Dựa vào các thông tin thu thập được từ bước phân tích, ta đặt mình vào phía attacker.
2) Suy đoán những hướng đi và phuơng thức rồi tiến hành "đặt bẫy" - khả năng attacker trở lại cao.
3) Tìm hiểu thêm thông tin từ bên ngoài ...

Trash from trash is the place for new good things ~

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 16:29:33 (+0700) \| #27 \| 254036

tmd
Member

Joined: 28/06/2006 03:39:48
Messages: 2951
Offline

a. Một máy chủ có nhiều dịch vụ.
b. Máy chủ ấy được ISP bảo vệ.
c. Phiên bản của của hệ điều hành và các dịch vụ.

Một máy chủ duy nhất, thông thường một vài đơn vị nhiều chí phí không thích sài dịch vụ shared hay dịch vụ server nằm trong 1 cụm server. Chuyện Server này như chuyện vác 1 cái server tới ISP, thuê chổ đặt, thê IP, thuê firewall(email,web,...), proxy server, thuê hoặc không thuê quản trị ở ISP. Và gần như là phó mặt luôn cho quản trị của ISP.

Chuyện trên dẫn tiếp chuyện , HDH và tùm lum dịch vụ ở trên cái server đó có được update hay không, phải xem người đi gửi server có kí hợp đồng với ISP về công việc này không. Có yêu cầu thông báo tình trạng log gửi qua mail cho người gửi server hay không. Chuyện này lại càng phụ thuộc vào người gửi.

Hai chuyện trên dẫn tiếp chuyện, người gửi server(khách hàng) có quan tâm tới LOG hoạt động của các dịch vụ, thường xuyên theo dõi bug có thể gây ra vấn đề dịch vụ gặp lỗi ngẫu nhiên, lỗi mất quyền truy cập dịch vụ vào tay kẻ xấu khai thác lỗi,.... bug-track

Những chuyện trên sẽ là cơ sở để xem xét hiện trạng của server và các dịch vụ. Tình trạng nguyên thuỷ của các dịch vụ, HDH hay gọi là nguyên trạng có những gì. Sau đó , quản trị ở ISP đã thêm những configuration trực tiếp gì lên server, có ghi lại cấu hình sau đó không. Có cấu hình log liết gì không ? Có PLAN backup và có PLAN theo dõi LOG và thông báo sự cố không ?

Lại tiếp tục tính tiếp việc theo dõi hiện trạng , sau khi có sự cố. Ghi nhận lại thời điểm mà sự cố xảy ra để làm một cái mốc thời gian, tuy có thể nó không thực sự đúng với thời điểm mà kẻ xấu đã khai thác 1 lỗi. Từ đó kiểm tra ngược lại, dịch vụ nào có lỗi gì được khai thác, thời điểm dịch vụ được thêm cấu hình, dịch vụ tạo được thêm, thay đổi, chèn 1 data,configuration vào để phục vụ cho việc khai thác lỗi.

Đứng lại suy nghĩ tại sao để phán đoán tình hình, khách hàng thuê FIrewall tập trung của ISP nên không hề suy xét tới thiết lập các biện pháp hỗ trợ phán đoán sự cố ngay trên server, cập nhật server. Việc này khẳng định nghi ngờ chính các dịch vụ trên server bị thao túng. Và một vấn đề khác cũng phải xem lại, firewall của ISP là loại phục vụ cho vô vàn dịch vụ dùng chung. Có thể nó cũng đã cho qua một số truy vấn server, được phép và hợp lệ, tất nhiên là đối với nó.

Công tác cụ thể tiếp theo là moi móc các dịch vụ và HDH. Chuyện này như chị gamma95 đề xuất, gọi C50 là một cách.
Biện pháp cụ thể ra sao, mời các bác chuyên kiêm tra ra tay.

3 giai đoạn của con... người, ban đầu dek biết gì thì phải thăm dò, sau đó biết rồi thì phải thân thiết, sau cùng khi quá thân thiết rồi thì phải tình thương mến thương. Nhưng mà không thương được thì ...

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 18:44:03 (+0700) \| #28 \| 254048

__mask
Member

Joined: 05/02/2012 10:50:34
Messages: 4
Location: Desert
Offline

Trên phương diện của 1 forensic tôi có 1 vài nhân định:
- Không nên chủ quan mình là "chuyên gia bảo mật hàng đầu " mà chủ quan, rà soát lại tất cả hệ thống , tốt hơn là nên có sự tham gia của các chuyên gia bên ngoài công ty (C50...)
- Cách li sever bị hack đề phòng hacker vẫn có thể cài mã độc nhăm lấy thông tin của nhưng người tò mò truy cập vào, mặt khác , tránh lây lan ...
- Theo nhân định của Conmale hay đúng hơn là "suy đoán" dựa trên nhưng gì Conmale thấy thì Sever của BKAV dngf IIS vì vậy phải path các lỗ hổng... (Các hacker có thể sử dụng những lỗi bảo mật rất bình thường dó ý thức chủ quan của người quản trị về những lỗi bình thường đó).
- Tổ chức cuộc họp kín trong BQT nói riêng cũng như lãnh đạo công ty nói chung để rút kinh nghiệm, đòng thời đưa ra phuơng an trấn an dư luận, vì đây là cách chuyên nghiệp nên làm của 1 công ty "uy tín" như BKAV.
- Cuối cùng cũng không kém phần quan trọng, là điều tra chính các thành viên trong nội bộ BKAV.
Thân..

Không thể kiểm soát mọi thứ đến với mình, nhưng ta có thể kiểm soát được thái độ của mình khi điều đó xảy đến

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	16/02/2012 23:06:01 (+0700) \| #29 \| 254070

TheEyes
Member

Joined: 15/02/2012 09:11:05
Messages: 4
Offline

Nếu em là chuyên viên nhận trách nhiệm khắc phục server sau khi bị thâm nhập. Em nghĩ em sẽ làm như thế này:

Xác định các đối tượng liên quan:
Ai liên quan đến sự cố thâm nhập ?
- Khách hàng
- Công ty
- ISP
- Xã hội

Công ty cần làm gì với các bên ?
- Với khách hàng:
+ Trong thời gian đầu nên chỉ thông báo với khách hàng server đang bảo trì
+ Đồng thời chuẩn bị sẵn sàng trường hợp sự cố dai dẳng, không thể chốc lát mà giải quyết được
-> Cần phải nói rõ với khách hàng về mức độ thiệt hại
-> Chuẩn bị các phương án đền bù nếu mức độ thiệt hại ảnh hưởng đến khách hàng

- Với ISP:
+ Contact trực tiếp với bên ISP
-> Yêu cầu họ cô lập server
-> Yêu cầu họ giữ nguyên hiện trạng
-> Tiếp tục yêu cầu họ báo cáo tình hình server, mức độ thiệt hại, ảnh hưởng

Những báo cáo đó có thể được chính nhân viên của công ty đó phân tích (nếu họ có thể) hoặc chuyển giao cho bên thứ ba như C50 hoặc tiến hành trong sự hợp tác cả ba bên: nhân viên kỹ thuật của công ty, ISP và C50

+ Xem xét các điều khoản với ISP. Trách nhiệm của ISP trong trường hợp này là gì ?

- Với xã hội:
-> Cần một phát ngôn viên chính thức để thông cáo tình hình với báo chí. Luôn luôn đảm bảo giữ một kênh thông tin liên lạc thường xuyên và chính thức với cánh báo giới.

- Hiện trạng là gì ?
+ Dịch vụ nào không hoạt động
+ Những bất thường xảy ra đã ghi nhận được

- Xác nhận thời điểm tấn công gần đúng qua file log
smilie

Riêng chuyện file log có thể bị làm giả, mất tính toàn vẹn thì em cũng chưa biết sẽ xử lý thế nào ?

- Loại hình mà attacker đã sử dụng để thâm nhập server
+ Kết hợp hai yếu tố trên cộng với xem xét lại cấu hình hệ thống tìm ra cách mà attacker đã dùng để thâm nhập
+ Tại đây, nhân viên phân tích cũng sẽ lưu tâm đến các yếu tố liên quan: Liệu xung quanh thời điểm bị tấn công, dedicated server có liên hệ với server nào khác, có được sửa đổi cấu hình gì không.

- Thử nghiệm
+ Thử dựng lại tình huống tương tự với các điều kiện tương tự để xác nhận các phỏng đoán về cách thâm nhập

- Xác định nguyên nhân
+ Biết được cách thâm nhập thì sẽ tìm ra lỗ hổng của hệ thống

- Khắc phục
+ Tìm cách bít lỗ hổng này

- Tính đến các giải pháp lâu dài:
Lỗ hổng đã được vá. Công ty cần xem xét xây dựng bổ sung quy chế bảo mật và điều khoản chặt chẽ minh bạch với ISP

- Mở rộng điều tra:
Tìm xem nguồn gốc tấn công đến từ đâu ?
...
Đến đây thì em mù mờ. Em không có những kỹ năng chuyên sâu của lãnh vực bảo mật và forensics nên không thể đi sâu hơn nhưng với đề bài này thì em nghĩ tiêu điểm của case study không nhằm hướng tới các chi tiết kỹ thuật phức tạp, nặng tính chuyên môn smilie

Do what you like !

[Analyzing] Case Study: phân tích hiện trường sau khi bị thâm nhập.	17/02/2012 10:11:51 (+0700) \| #30 \| 254106

Ikut3
Elite Member

Joined: 24/09/2007 23:47:03
Messages: 1429
Location: Nhà hát lớn
Offline

- Xác nhận thời điểm tấn công gần đúng qua file log
smilie Riêng chuyện file log có thể bị làm giả, mất tính toàn vẹn thì em cũng chưa biết sẽ xử lý thế nào ?

- Quản lí log tập trung, log dữ liệu không trực tiếp lưu trên máy chạy dịch vụ đó mà mỗi record trong quá trình ghi nhân sẽ được đẩy qua Log Centralize.

- Tuy nhiên nếu Attacker hoàn toàn có thể làm sai log (đầu độc, gây nhiễu, v.v...) trước khi quá trình đẩy log từ máy chủ dịch vụ đến máy chủ lưu trữ log. Đối với vấn đề này, thì mình vẫn chưa có giải pháp nào, mời mọi người cho ý kiến

Go to:

Users currently in here
1 Anonymous