Đây là Câu hỏi Canonical về Bảo mật Máy chủ - Ứng phó với Sự kiện Vi phạm (Hacking)
Xem thêm:

• Mẹo bảo mật máy chủ LAMP
• Cài đặt lại sau khi thỏa hiệp root?

Phiên bản Canonical
Tôi nghi ngờ rằng một hoặc nhiều máy chủ của mình bị xâm nhập bởi tin tặc, vi rút hoặc cơ chế khác:

• Bước đầu tiên của tôi là gì? Khi tôi đến trang web, tôi có nên ngắt kết nối máy chủ, giữ lại "bằng chứng", có những cân nhắc ban đầu nào khác không?
• Làm thế nào để tôi đi về việc nhận dịch vụ trực tuyến?
• Làm thế nào để tôi ngăn điều tương tự xảy ra ngay lập tức?
• Có thực hành hay phương pháp tốt nhất để học hỏi từ sự cố này?
• Nếu tôi muốn đặt Kế hoạch ứng phó sự cố cùng nhau, tôi sẽ bắt đầu từ đâu? Đây có nên là một phần của Kế hoạch khắc phục thảm họa hoặc Kế hoạch kinh doanh liên tục của tôi không?

Phiên bản gốc

2011.01.02 - Tôi đang trên đường đi làm vào lúc 9h30 tối Chủ nhật vì máy chủ của chúng tôi đã bị xâm nhập bằng cách nào đó và dẫn đến một cuộc tấn công DOS vào nhà cung cấp của chúng tôi. Các máy chủ truy cập Internet đã ngừng hoạt động, điều đó có nghĩa là hơn 5-600 trang web của khách hàng của chúng tôi hiện đã ngừng hoạt động. Bây giờ đây có thể là một vụ hack FTP, hoặc một số điểm yếu trong mã ở đâu đó. Tôi không chắc chắn cho đến khi tôi đến đó.

Làm thế nào tôi có thể theo dõi điều này xuống một cách nhanh chóng? Chúng tôi sẽ tham gia rất nhiều vụ kiện tụng nếu tôi không cho máy chủ sao lưu càng sớm càng tốt. Bất kỳ trợ giúp được đánh giá cao. Chúng tôi đang chạy Open SUSE 11.0.

---

2011.01.03 - Cảm ơn mọi người vì sự giúp đỡ của bạn. May mắn thay, tôi không phải là người duy nhất chịu trách nhiệm cho máy chủ này, chỉ là người gần nhất. Chúng tôi quản lý để giải quyết vấn đề này, mặc dù nó có thể không áp dụng cho nhiều người khác trong một tình huống khác. Tôi sẽ nói chi tiết những gì chúng tôi đã làm.

Chúng tôi đã rút máy chủ khỏi mạng. Nó đang thực hiện (cố gắng thực hiện) một cuộc tấn công từ chối dịch vụ vào một máy chủ khác ở Indonesia, và bên có tội cũng ở đó.

Trước tiên, chúng tôi đã cố gắng xác định nơi mà máy chủ này đến từ đâu, vì chúng tôi có hơn 500 trang web trên máy chủ, chúng tôi dự kiến ​​sẽ có ánh trăng trong một thời gian. Tuy nhiên, với quyền truy cập SSH vẫn còn, chúng tôi đã chạy một lệnh để tìm tất cả các tệp được chỉnh sửa hoặc tạo trong thời gian các cuộc tấn công bắt đầu. May mắn thay, tập tin vi phạm đã được tạo ra trong kỳ nghỉ đông, điều đó có nghĩa là không có nhiều tập tin khác được tạo trên máy chủ tại thời điểm đó.

Sau đó, chúng tôi đã có thể xác định tệp vi phạm trong thư mục hình ảnh được tải lên trong trang web ZenCart .

Sau một thời gian nghỉ thuốc lá ngắn, chúng tôi đã kết luận rằng, do vị trí tệp, nó phải được tải lên thông qua một cơ sở tải lên tệp được bảo mật không đầy đủ. Sau một vài lần googling, chúng tôi thấy rằng có một lỗ hổng bảo mật cho phép các tệp được tải lên, trong bảng quản trị ZenCart, để chụp ảnh cho một công ty thu âm. (Phần mà nó chưa bao giờ thực sự sử dụng), đăng mẫu này chỉ tải lên bất kỳ tệp nào, nó không kiểm tra phần mở rộng của tệp và thậm chí không kiểm tra xem người dùng đã đăng nhập chưa.

Điều này có nghĩa là bất kỳ tệp nào cũng có thể được tải lên, bao gồm tệp PHP cho cuộc tấn công. Chúng tôi đã bảo mật lỗ hổng với ZenCart trên trang bị nhiễm và xóa các tệp vi phạm.

Công việc đã xong, tôi về nhà được 2 giờ sáng.

---

Đạo đức - Luôn áp dụng các bản vá bảo mật cho ZenCart hoặc bất kỳ hệ thống CMS nào khác cho vấn đề đó. Như khi cập nhật bảo mật được phát hành, cả thế giới đều nhận thức được lỗ hổng. - Luôn luôn sao lưu và sao lưu dự phòng của bạn. - Làm việc hoặc sắp xếp cho ai đó sẽ ở đó trong những lúc như thế này. Để ngăn chặn bất cứ ai dựa vào một bài viết hoảng loạn trên Server Fault.

Thật khó để đưa ra lời khuyên cụ thể từ những gì bạn đã đăng ở đây nhưng tôi có một số lời khuyên chung chung dựa trên bài đăng mà tôi đã viết từ lâu khi tôi vẫn có thể bị làm phiền khi viết blog.

Đừng hoảng sợ

Trước tiên, không có "cách khắc phục nhanh" nào ngoài việc khôi phục hệ thống của bạn từ bản sao lưu được thực hiện trước khi xâm nhập và điều này có ít nhất hai vấn đề.

1. Thật khó để xác định khi sự xâm nhập xảy ra.
2. Nó không giúp bạn đóng "lỗ hổng" cho phép họ phá vỡ lần trước, cũng như không giải quyết hậu quả của bất kỳ "hành vi trộm cắp dữ liệu" nào cũng có thể xảy ra.

Câu hỏi này liên tục được hỏi bởi các nạn nhân của tin tặc đột nhập vào máy chủ web của họ. Các câu trả lời rất hiếm khi thay đổi, nhưng mọi người cứ đặt câu hỏi. Tôi cung không chăc tại sao. Có lẽ mọi người chỉ không thích câu trả lời họ đã thấy khi tìm kiếm trợ giúp hoặc họ không thể tìm thấy ai đó mà họ tin tưởng để cho họ lời khuyên. Hoặc có lẽ mọi người đọc câu trả lời cho câu hỏi này và tập trung quá nhiều vào 5% lý do tại sao trường hợp của họ đặc biệt và khác với câu trả lời họ có thể tìm thấy trên mạng và bỏ lỡ 95% câu hỏi và câu trả lời trong trường hợp của họ gần giống nhau như một trong những họ đọc trực tuyến.

Điều đó đưa tôi đến những thông tin quan trọng đầu tiên. Tôi thực sự đánh giá cao rằng bạn là một bông tuyết độc đáo đặc biệt. Tôi đánh giá cao rằng trang web của bạn cũng vậy, vì nó phản ánh bạn và doanh nghiệp của bạn hoặc ít nhất, công việc khó khăn của bạn thay mặt cho một nhà tuyển dụng. Nhưng với một người ở bên ngoài nhìn vào, cho dù một nhân viên bảo mật máy tính đang xem xét vấn đề để cố gắng giúp bạn hoặc thậm chí chính kẻ tấn công, thì rất có thể vấn đề của bạn sẽ giống nhau ít nhất 95% so với mọi trường hợp khác mà họ gặp phải từng nhìn.

Đừng thực hiện cuộc tấn công cá nhân và đừng thực hiện các đề xuất theo sau tại đây hoặc bạn nhận được từ cá nhân người khác. Nếu bạn đang đọc điều này sau khi trở thành nạn nhân của một vụ hack trang web thì tôi thực sự xin lỗi và tôi thực sự hy vọng bạn có thể tìm thấy thứ gì đó hữu ích ở đây, nhưng đây không phải là lúc để cái tôi của bạn cản trở những gì bạn cần làm

Bạn vừa phát hiện ra rằng (các) máy chủ của bạn đã bị hack. Giờ thì sao?

Đừng hoảng sợ. Tuyệt đối không hành động vội vàng, và tuyệt đối không cố gắng và giả vờ những điều không bao giờ xảy ra và không hành động gì cả.

Đầu tiên: hiểu rằng thảm họa đã xảy ra. Đây không phải là lúc để từ chối; đó là thời gian để chấp nhận những gì đã xảy ra, thực tế về nó và thực hiện các bước để quản lý hậu quả của tác động.

Một số bước này sẽ bị tổn thương và (trừ khi trang web của bạn giữ một bản sao các chi tiết của tôi) Tôi thực sự không quan tâm nếu bạn bỏ qua tất cả hoặc một số bước này, điều đó tùy thuộc vào bạn. Nhưng theo họ đúng cách sẽ làm cho mọi thứ tốt hơn cuối cùng. Thuốc có thể có vị rất tệ nhưng đôi khi bạn phải bỏ qua điều đó nếu bạn thực sự muốn thuốc chữa bệnh phát huy tác dụng.

Ngăn chặn vấn đề trở nên tồi tệ hơn nó là:

1. Điều đầu tiên bạn nên làm là ngắt kết nối các hệ thống bị ảnh hưởng khỏi Internet. Dù bạn có vấn đề gì khác, việc để hệ thống kết nối với web sẽ chỉ cho phép cuộc tấn công tiếp tục. Ý tôi là điều này hoàn toàn theo nghĩa đen; mời ai đó đến thăm máy chủ và rút cáp mạng nếu đó là những gì cần thiết, nhưng ngắt kết nối nạn nhân khỏi những kẻ lừa đảo trước khi bạn cố gắng làm bất cứ điều gì khác.
2. Thay đổi tất cả mật khẩu của bạn cho tất cả các tài khoản trên tất cả các máy tính trên cùng một mạng với các hệ thống bị xâm nhập. Không thực sự. Tất cả các tài khoản. Tất cả máy tính. Vâng, bạn đã đúng, điều này có thể là quá mức cần thiết; mặt khác, nó có thể không. Bạn không biết một trong hai cách, phải không?
3. Kiểm tra các hệ thống khác của bạn. Đặc biệt chú ý đến các dịch vụ phải đối mặt với Internet khác và các dịch vụ có dữ liệu nhạy cảm về tài chính hoặc thương mại khác.
4. Nếu hệ thống lưu giữ dữ liệu cá nhân của bất kỳ ai, hãy thông báo ngay cho người chịu trách nhiệm bảo vệ dữ liệu (nếu đó không phải là bạn) và URGE tiết lộ đầy đủ. Tôi biết điều này là khó khăn. Tôi biết điều này sẽ làm tổn thương. Tôi biết rằng nhiều doanh nghiệp muốn quét loại vấn đề này dưới thảm nhưng doanh nghiệp sẽ phải giải quyết - và cần phải làm như vậy với bất kỳ và tất cả các luật riêng tư có liên quan.

Tuy nhiên, khách hàng của bạn khó chịu có thể khiến bạn phải nói với họ về một vấn đề, họ sẽ khó chịu hơn nhiều nếu bạn không nói với họ và họ chỉ tự mình tìm hiểu sau khi ai đó tính phí hàng hóa trị giá 8.000 đô la bằng cách sử dụng thông tin thẻ tín dụng. lấy trộm từ trang web của bạn.

Nhớ những gì tôi đã nói trước đây? Điều tồi tệ đã xảy ra. Câu hỏi duy nhất bây giờ là bạn giải quyết nó tốt như thế nào.

Hiểu vấn đề đầy đủ:

1. KHÔNG đưa các hệ thống bị ảnh hưởng trở lại trực tuyến cho đến khi giai đoạn này hoàn tất, trừ khi bạn muốn trở thành người có bài đăng là điểm bùng phát để tôi thực sự quyết định viết bài viết này. Tôi sẽ không liên kết đến bài đăng đó để mọi người có thể cười một cách rẻ tiền, nhưng bi kịch thực sự là khi mọi người không học được từ những sai lầm của họ.
2. Kiểm tra các hệ thống 'bị tấn công' để hiểu cách các cuộc tấn công đã thành công trong việc xâm phạm an ninh của bạn. Thực hiện mọi nỗ lực để tìm ra các cuộc tấn công "đến từ đâu", để bạn hiểu những vấn đề bạn gặp phải và cần giải quyết để làm cho hệ thống của bạn an toàn trong tương lai.
3. Kiểm tra lại các hệ thống 'bị tấn công', lần này để hiểu các cuộc tấn công đã đi đến đâu, để bạn hiểu hệ thống nào bị xâm phạm trong cuộc tấn công. Đảm bảo bạn theo dõi bất kỳ con trỏ nào đề xuất các hệ thống bị xâm nhập có thể trở thành bàn đạp để tấn công các hệ thống của bạn hơn nữa.
4. Đảm bảo "các cổng" được sử dụng trong bất kỳ và tất cả các cuộc tấn công đều được hiểu đầy đủ, để bạn có thể bắt đầu đóng chúng đúng cách. (ví dụ: nếu hệ thống của bạn bị xâm phạm bởi một cuộc tấn công tiêm nhiễm SQL, thì bạn không chỉ cần phải đóng dòng mã bị lỗi cụ thể mà chúng đã xâm nhập, bạn sẽ muốn kiểm tra tất cả mã của mình để xem có phải cùng một loại lỗi không đã được thực hiện ở nơi khác).
5. Hiểu rằng các cuộc tấn công có thể thành công vì có nhiều hơn một lỗ hổng. Thông thường, các cuộc tấn công thành công không phải thông qua việc tìm ra một lỗi lớn trong một hệ thống mà bằng cách xâu chuỗi một số vấn đề (đôi khi là nhỏ và tầm thường) để thỏa hiệp một hệ thống. Ví dụ: sử dụng các cuộc tấn công tiêm nhiễm SQL để gửi lệnh đến máy chủ cơ sở dữ liệu, phát hiện ra trang web / ứng dụng bạn đang tấn công đang chạy trong bối cảnh người dùng quản trị và sử dụng các quyền của tài khoản đó như một bước đệm để thỏa hiệp các phần khác của hệ thống. Hoặc như tin tặc thích gọi nó: "một ngày khác trong văn phòng lợi dụng những lỗi phổ biến mà mọi người mắc phải".

Tại sao không chỉ "sửa chữa" khai thác hoặc rootkit mà bạn đã phát hiện và đưa hệ thống trở lại trực tuyến?

Trong những tình huống như thế này, vấn đề là bạn không còn kiểm soát hệ thống đó nữa. Nó không phải là máy tính của bạn nữa.

Cách duy nhất để chắc chắn rằng bạn có quyền kiểm soát hệ thống là xây dựng lại hệ thống. Mặc dù có rất nhiều giá trị trong việc tìm kiếm và sửa lỗi khai thác được sử dụng để xâm nhập vào hệ thống, bạn không thể chắc chắn về những gì khác đã được thực hiện đối với hệ thống một khi những kẻ xâm nhập đã giành quyền kiểm soát (thực sự, nó không phải là chưa từng thấy đối với các tin tặc tuyển dụng hệ thống vào một mạng botnet để vá các khai thác mà họ đã sử dụng, để bảo vệ "máy tính" mới của họ khỏi các tin tặc khác, cũng như cài đặt rootkit của họ).

Lập một kế hoạch để phục hồi và đưa trang web của bạn trở lại trực tuyến và tuân thủ nó:

Không ai muốn ngoại tuyến lâu hơn họ phải có. Đó là sự cống hiến. Nếu trang web này là một cơ chế tạo doanh thu thì áp lực đưa nó trở lại trực tuyến nhanh chóng sẽ rất lớn. Ngay cả khi điều duy nhất bị đe dọa là danh tiếng của công ty bạn, điều này vẫn sẽ tạo ra rất nhiều áp lực để nhanh chóng đưa mọi thứ trở lại.

Tuy nhiên, đừng từ bỏ cám dỗ để trở lại trực tuyến quá nhanh. Thay vào đó hãy di chuyển nhanh nhất có thể để hiểu nguyên nhân gây ra sự cố và giải quyết nó trước khi bạn quay lại trực tuyến nếu không bạn gần như chắc chắn sẽ trở thành nạn nhân của một vụ xâm nhập một lần nữa, và hãy nhớ rằng, "bị hack một lần có thể bị coi là bất hạnh; để bị hack một lần nữa ngay sau đó trông giống như sự bất cẩn "(với lời xin lỗi tới Oscar Wilde).

1. Tôi cho rằng bạn đã hiểu tất cả các vấn đề dẫn đến sự xâm nhập thành công ngay từ đầu trước khi bạn bắt đầu phần này. Tôi không muốn phóng đại trường hợp này nhưng nếu bạn chưa làm điều đó trước thì bạn thực sự cần phải làm vậy. Lấy làm tiếc.
2. Không bao giờ trả tiền tống tiền / bảo vệ. Đây là dấu hiệu của một dấu dễ dàng và bạn không muốn cụm từ đó được sử dụng để mô tả về bạn.
3. Đừng cố gắng đưa (các) máy chủ tương tự trở lại trực tuyến mà không cần xây dựng lại đầy đủ. Sẽ nhanh hơn rất nhiều khi xây dựng một hộp mới hoặc "nuke máy chủ từ quỹ đạo và cài đặt sạch" trên phần cứng cũ hơn là kiểm tra từng góc của hệ thống cũ để đảm bảo nó sạch sẽ trước khi đặt lại trực tuyến một lần nữa. Nếu bạn không đồng ý với điều đó thì có lẽ bạn không biết ý nghĩa thực sự của nó là gì để đảm bảo hệ thống được làm sạch hoàn toàn hoặc quy trình triển khai trang web của bạn là một mớ hỗn độn. Bạn có thể có các bản sao lưu và triển khai thử nghiệm trang web của mình mà bạn chỉ có thể sử dụng để xây dựng trang web trực tiếp và nếu bạn không bị hack thì đó không phải là vấn đề lớn nhất của bạn.
4. Hãy cẩn thận về việc sử dụng lại dữ liệu "sống" trên hệ thống tại thời điểm xảy ra vụ hack. Tôi sẽ không nói "không bao giờ làm điều đó" bởi vì bạn sẽ phớt lờ tôi, nhưng thật lòng tôi nghĩ bạn cần phải xem xét hậu quả của việc giữ dữ liệu xung quanh khi bạn biết rằng bạn không thể đảm bảo tính toàn vẹn của nó. Tốt nhất, bạn nên khôi phục điều này từ bản sao lưu được thực hiện trước khi xâm nhập. Nếu bạn không thể hoặc sẽ không làm điều đó, bạn nên rất cẩn thận với dữ liệu đó vì nó bị ô nhiễm. Bạn đặc biệt nên biết về hậu quả đối với người khác nếu dữ liệu này thuộc về khách hàng hoặc khách truy cập trang web hơn là trực tiếp với bạn.
5. Giám sát (các) hệ thống cẩn thận. Bạn nên quyết tâm thực hiện điều này như một quá trình đang diễn ra trong tương lai (nhiều hơn bên dưới) nhưng bạn phải chịu thêm cảnh giác trong suốt thời gian ngay sau khi trang web của bạn trở lại trực tuyến. Những kẻ xâm nhập gần như chắc chắn sẽ quay trở lại, và nếu bạn có thể phát hiện ra chúng đang cố gắng đột nhập trở lại, bạn chắc chắn sẽ có thể nhìn thấy nhanh chóng nếu bạn thực sự đã đóng tất cả các lỗ hổng mà chúng sử dụng trước đó cộng với bất kỳ lỗ hổng nào chúng tự tạo ra và bạn có thể thu thập hữu ích thông tin bạn có thể chuyển cho cơ quan thực thi pháp luật địa phương của bạn.

Giảm rủi ro trong tương lai.

Điều đầu tiên bạn cần hiểu là bảo mật là một quy trình mà bạn phải áp dụng trong toàn bộ vòng đời thiết kế, triển khai và bảo trì hệ thống đối mặt với Internet, không phải là thứ bạn có thể tát vài lớp qua mã của mình sau đó như giá rẻ Sơn. Để được bảo mật chính xác, một dịch vụ và ứng dụng cần được thiết kế ngay từ đầu với ý nghĩ này là một trong những mục tiêu chính của dự án. Tôi nhận ra điều đó thật nhàm chán và bạn đã nghe tất cả trước đó và tôi "chỉ không nhận ra người đàn ông áp lực" khi đưa dịch vụ beta web2.0 (beta) của bạn vào trạng thái beta trên web, nhưng thực tế là điều này vẫn giữ được lặp đi lặp lại bởi vì đó là sự thật ngay lần đầu tiên được nói và nó chưa trở thành lời nói dối.

Bạn không thể loại bỏ rủi ro. Bạn thậm chí không nên cố gắng để làm điều đó. Tuy nhiên, điều bạn nên làm là hiểu những rủi ro bảo mật nào là quan trọng đối với bạn và hiểu cách quản lý và giảm cả tác động của rủi ro và xác suất rủi ro sẽ xảy ra.

Những bước bạn có thể thực hiện để giảm xác suất tấn công thành công?

Ví dụ:

1. Lỗ hổng cho phép mọi người xâm nhập vào trang web của bạn là một lỗi đã biết trong mã nhà cung cấp, trong đó có một bản vá? Nếu vậy, bạn có cần suy nghĩ lại cách tiếp cận của bạn về cách bạn vá các ứng dụng trên các máy chủ đối mặt với Internet của bạn không?
2. Có phải lỗ hổng cho phép mọi người xâm nhập vào trang web của bạn là một lỗi không xác định trong mã nhà cung cấp, mà bản vá không có sẵn? Tôi chắc chắn không ủng hộ việc thay đổi nhà cung cấp bất cứ khi nào điều gì đó như thế này cắn bạn vì tất cả họ đều gặp vấn đề và bạn sẽ hết nền tảng trong một năm nhiều nhất nếu bạn thực hiện phương pháp này. Tuy nhiên, nếu một hệ thống liên tục làm bạn thất vọng thì bạn nên chuyển sang một thứ gì đó mạnh mẽ hơn hoặc ít nhất, tái kiến ​​trúc hệ thống của bạn để các thành phần dễ bị tổn thương được bọc trong bông gòn và càng xa càng tốt khỏi mắt thù địch.
3. Là một lỗ hổng trong mã do bạn (hoặc một nhà thầu làm việc cho bạn) phát triển? Nếu vậy, bạn có cần suy nghĩ lại cách tiếp cận của bạn về cách bạn phê duyệt mã để triển khai cho trang web trực tiếp của bạn không? Có thể lỗi đã được bắt gặp với một hệ thống kiểm tra được cải tiến hoặc với các thay đổi đối với "tiêu chuẩn" mã hóa của bạn (ví dụ: trong khi công nghệ không phải là thuốc chữa bách bệnh, bạn có thể giảm xác suất tấn công SQL SQL thành công bằng cách sử dụng các kỹ thuật mã hóa được ghi chép tốt ).
4. Là lỗ hổng do vấn đề với cách máy chủ hoặc phần mềm ứng dụng được triển khai? Nếu vậy, bạn có đang sử dụng các quy trình tự động để xây dựng và triển khai các máy chủ nếu có thể? Đây là một trợ giúp tuyệt vời trong việc duy trì trạng thái "cơ sở" nhất quán trên tất cả các máy chủ của bạn, giảm thiểu số lượng công việc tùy chỉnh phải thực hiện trên mỗi máy chủ và do đó hy vọng giảm thiểu cơ hội xảy ra lỗi. Tương tự với việc triển khai mã - nếu bạn yêu cầu một cái gì đó "đặc biệt" để triển khai phiên bản mới nhất của ứng dụng web của bạn thì hãy cố gắng tự động hóa nó và đảm bảo nó luôn được thực hiện một cách nhất quán.
5. Có thể xâm nhập đã được bắt trước đó với giám sát tốt hơn các hệ thống của bạn? Tất nhiên, giám sát 24 giờ hoặc hệ thống "theo yêu cầu" cho nhân viên của bạn có thể không hiệu quả về chi phí, nhưng có những công ty có thể giám sát các dịch vụ đối mặt với web của bạn và cảnh báo bạn trong trường hợp xảy ra sự cố. Bạn có thể quyết định rằng bạn không đủ khả năng này hoặc không cần nó và điều đó thật tốt ... chỉ cần xem xét nó.
6. Sử dụng các công cụ như tripwire và nessus khi thích hợp - nhưng đừng chỉ sử dụng chúng một cách mù quáng vì tôi đã nói như vậy. Dành thời gian để tìm hiểu cách sử dụng một vài công cụ bảo mật tốt phù hợp với môi trường của bạn, giữ cho các công cụ này được cập nhật và sử dụng chúng một cách thường xuyên.
7. Xem xét việc thuê các chuyên gia bảo mật để 'kiểm toán' bảo mật trang web của bạn một cách thường xuyên. Một lần nữa, bạn có thể quyết định rằng bạn không đủ khả năng này hoặc không cần nó và điều đó thật tốt ... chỉ cần xem xét nó.

Những bước bạn có thể làm để giảm hậu quả của một cuộc tấn công thành công?

Nếu bạn quyết định rằng "nguy cơ" tầng dưới của lũ lụt nhà bạn là cao, nhưng không đủ cao để đảm bảo di chuyển, ít nhất bạn nên di chuyển những người thừa kế gia đình không thể thay thế lên tầng trên. Đúng?

1. Bạn có thể giảm lượng dịch vụ tiếp xúc trực tiếp với Internet không? Bạn có thể duy trì một số khoảng cách giữa các dịch vụ nội bộ và các dịch vụ đối mặt với Internet của bạn không? Điều này đảm bảo rằng ngay cả khi các hệ thống bên ngoài của bạn bị xâm phạm, cơ hội sử dụng điều này làm bàn đạp để tấn công các hệ thống nội bộ của bạn bị hạn chế.
2. Bạn đang lưu trữ thông tin bạn không cần lưu trữ? Bạn có lưu trữ thông tin đó "trực tuyến" khi nó có thể được lưu trữ ở một nơi khác. Có hai điểm cho phần này; một điều hiển nhiên là mọi người không thể đánh cắp thông tin từ bạn mà bạn không có, và điểm thứ hai là bạn càng lưu trữ ít, bạn càng cần phải duy trì và mã hóa, và do đó sẽ có ít cơ hội hơn cho các lỗi. mã hoặc thiết kế hệ thống của bạn.
3. Bạn có đang sử dụng các nguyên tắc "ít truy cập nhất" cho ứng dụng web của mình không? Nếu người dùng chỉ cần đọc từ cơ sở dữ liệu, thì hãy đảm bảo tài khoản mà ứng dụng web sử dụng để phục vụ việc này chỉ có quyền truy cập đọc, không cho phép nó truy cập ghi và chắc chắn không truy cập cấp hệ thống.
4. Nếu bạn không có nhiều kinh nghiệm về một cái gì đó và nó không phải là trung tâm của doanh nghiệp của bạn, hãy xem xét việc thuê ngoài nó. Nói cách khác, nếu bạn điều hành một trang web nhỏ nói về việc viết mã ứng dụng máy tính để bàn và quyết định bắt đầu bán các ứng dụng máy tính để bàn nhỏ từ trang web thì hãy xem xét "thuê ngoài" hệ thống đặt hàng thẻ tín dụng của bạn cho ai đó như Paypal.
5. Nếu có thể, hãy thực hiện khôi phục thực hành từ các hệ thống bị xâm nhập trong kế hoạch Khôi phục Thảm họa của bạn. Đây được cho là một "kịch bản thảm họa" khác mà bạn có thể gặp phải, chỉ đơn giản là một vấn đề với các vấn đề và vấn đề riêng khác với 'phòng máy chủ bị bắt lửa' / 'đã bị xâm chiếm bởi loại máy chủ khổng lồ ăn thịt người.

... Và cuối cùng

Có lẽ tôi đã bỏ qua những thứ mà người khác cho là quan trọng, nhưng các bước trên ít nhất sẽ giúp bạn bắt đầu sắp xếp mọi thứ nếu bạn không may trở thành nạn nhân của tin tặc.

Trên tất cả: Đừng hoảng sợ. Nghĩ trước khi hành động. Hành động kiên quyết khi bạn đã đưa ra quyết định và để lại nhận xét bên dưới nếu bạn có điều gì đó để thêm vào danh sách các bước của tôi.

Nghe có vẻ như ở trên đầu của bạn một chút; vậy là được rồi. Gọi cho sếp của bạn và bắt đầu đàm phán về ngân sách phản hồi an ninh khẩn cấp. $ 10.000 có thể là một nơi tốt để bắt đầu. Sau đó, bạn cần phải nhờ ai đó (PFY, đồng nghiệp, quản lý) bắt đầu gọi cho các công ty chuyên về ứng phó sự cố an ninh. Nhiều người có thể trả lời trong vòng 24 giờ và đôi khi còn nhanh hơn nếu họ có văn phòng tại thành phố của bạn.

Bạn cũng cần ai đó để phân loại khách hàng; Không nghi ngờ gì, ai đó đã là. Ai đó cần được gọi điện thoại với họ để giải thích những gì đang xảy ra, những gì đang được thực hiện để xử lý tình huống và trả lời câu hỏi của họ.

Sau đó, bạn cần ...

1. Bình tĩnh. Nếu bạn chịu trách nhiệm ứng phó sự cố, những gì bạn làm bây giờ cần thể hiện sự chuyên nghiệp và lãnh đạo tối đa. Tài liệu mọi thứ bạn làm, và giữ cho người quản lý và nhóm điều hành của bạn thông báo về các hành động chính bạn thực hiện; điều này bao gồm làm việc với một nhóm phản hồi, vô hiệu hóa máy chủ, sao lưu dữ liệu và đưa mọi thứ trực tuyến trở lại. Họ không cần thông tin chi tiết, nhưng họ sẽ nghe bạn sau mỗi 30 phút hoặc lâu hơn.

2. Hãy thực tế. Bạn không phải là một chuyên gia bảo mật và có những điều bạn không biết. Vậy là được rồi. Khi đăng nhập vào máy chủ và xem dữ liệu, bạn cần hiểu giới hạn của mình. Bước đi nhẹ nhàng. Trong quá trình điều tra của bạn, hãy đảm bảo bạn không dẫm đạp thông tin quan trọng hoặc thay đổi thứ gì đó có thể cần thiết sau này. Nếu bạn cảm thấy không thoải mái hoặc bạn đang đoán, đó là một nơi tốt để dừng lại và nhờ một chuyên gia có kinh nghiệm đảm nhận.

3. Nhận một thanh USB sạch và ổ cứng dự phòng. Bạn sẽ thu thập bằng chứng ở đây. Tạo bản sao lưu của tất cả mọi thứ bạn cảm thấy có thể có liên quan; liên lạc với ISP của bạn, kết nối mạng, vv Ngay cả khi cơ quan thực thi pháp luật không tham gia, trong trường hợp kiện bạn sẽ muốn bằng chứng này chứng minh rằng công ty của bạn xử lý sự cố bảo mật một cách chuyên nghiệp và phù hợp.

4. Quan trọng nhất là dừng lỗ. Xác định và cắt quyền truy cập vào các dịch vụ, dữ liệu và máy bị xâm nhập. Tốt nhất, bạn nên kéo cáp mạng của họ; nếu bạn không thể, sau đó kéo điện.

5. Tiếp theo, bạn cần loại bỏ kẻ tấn công và đóng (các) lỗ hổng. Có lẽ, kẻ tấn công không còn có quyền truy cập tương tác vì bạn đã kéo mạng. Bây giờ bạn cần xác định, tài liệu (có bản sao lưu, ảnh chụp màn hình và ghi chú quan sát cá nhân của riêng bạn hoặc tốt nhất là bằng cách xóa các ổ đĩa khỏi các máy chủ bị ảnh hưởng và tạo một bản sao hình ảnh đĩa đầy đủ), sau đó xóa bất kỳ mã và quy trình nào mà anh ta để lại . Phần tiếp theo này sẽ hút nếu bạn không có bản sao lưu; Bạn có thể cố gắng gỡ rối kẻ tấn công khỏi hệ thống bằng tay, nhưng bạn sẽ không bao giờ chắc chắn rằng bạn có mọi thứ anh ta bỏ lại. Rootkit là xấu xa, và không phải tất cả đều có thể phát hiện được. Phản hồi tốt nhất sẽ là xác định lỗ hổng mà anh ta đã sử dụng để tạo ra, sao chép hình ảnh của các đĩa bị ảnh hưởng và sau đó xóa sạch các hệ thống bị ảnh hưởng và tải lại từ bản sao lưu tốt đã biết. Đừng ' t mù quáng tin tưởng vào bản sao lưu của bạn; xác minh điều đó! Sửa chữa hoặc đóng lỗ hổng trước khi máy chủ mới truy cập lại vào mạng và sau đó đưa nó lên mạng.

6. Sắp xếp tất cả dữ liệu của bạn vào một báo cáo. Tại thời điểm này, lỗ hổng đã được đóng lại và bạn có một chút thời gian để thở. Đừng cố gắng bỏ qua bước này; nó thậm chí còn quan trọng hơn phần còn lại của quá trình. Trong báo cáo, bạn cần xác định những gì đã sai, cách nhóm của bạn phản hồi và các bước bạn đang thực hiện để ngăn sự cố này xảy ra lần nữa. Càng chi tiết càng tốt; điều này không chỉ dành cho bạn, mà là cho quản lý của bạn và là người bào chữa trong một vụ kiện tiềm năng.

Đó là một đánh giá cao về những việc cần làm; hầu hết các công việc chỉ đơn giản là tài liệu và xử lý sao lưu. Đừng hoảng sợ, bạn có thể làm những thứ đó. Tôi mạnh mẽ đề nghị bạn nhận được sự giúp đỡ bảo vệ chuyên nghiệp. Ngay cả khi bạn có thể xử lý những gì đang diễn ra, sự giúp đỡ của họ sẽ là vô giá và họ thường đi kèm với thiết bị để làm cho quá trình dễ dàng hơn và nhanh hơn. Nếu sếp của bạn chùn bước với chi phí, hãy nhắc nhở anh ta rằng nó rất nhỏ khi so sánh với việc xử lý một vụ kiện.

Bạn có niềm an ủi của tôi cho tình huống của bạn. Chúc may mắn.

CERT có một tài liệu Các bước để khôi phục từ Thỏa hiệp hệ thống UNIX hoặc NT là tốt. Các chi tiết kỹ thuật cụ thể của tài liệu này có phần lỗi thời, nhưng rất nhiều lời khuyên chung vẫn được áp dụng trực tiếp.

Một bản tóm tắt nhanh chóng của các bước cơ bản là đây.

• Tham khảo chính sách bảo mật hoặc quản lý của bạn.
• Kiểm soát (lấy máy tính ngoại tuyến)
• Phân tích sự xâm nhập, nhận nhật ký, tìm ra những gì đã sai
• Sửa chữa đồ đạc
  • Cài đặt phiên bản sạch của hệ điều hành của bạn !!! Nếu hệ thống đã bị xâm phạm, bạn không thể tin tưởng nó, khoảng thời gian.
• Cập nhật hệ thống để điều này không thể xảy ra lần nữa
• Tiếp tục hoạt động
• Cập nhật chính sách của bạn cho tương lai và tài liệu

Tôi muốn đặc biệt chỉ cho bạn phần E.1.

E.1. Hãy nhớ rằng nếu một máy bị xâm nhập, mọi thứ trên hệ thống đó có thể đã được sửa đổi, bao gồm kernel, nhị phân, tệp dữ liệu, quy trình đang chạy và bộ nhớ. Nói chung, cách duy nhất để tin rằng một máy không có backtime và sửa đổi kẻ xâm nhập là cài đặt lại hoạt động

Nếu bạn chưa có hệ thống như tripwire, không có cách nào khả dĩ để bạn chắc chắn 100% rằng bạn đã dọn sạch hệ thống.

1. Xác định vấn đề. Đọc nhật ký.
2. Chứa . Bạn đã ngắt kết nối máy chủ, vậy là xong.
3. Diệt trừ . Cài đặt lại hệ thống bị ảnh hưởng, rất có thể. Đừng xóa ổ cứng của cái bị hack, hãy sử dụng cái mới. An toàn hơn, và bạn có thể cần một cái cũ để phục hồi các bản hack xấu xí không được sao lưu và làm pháp y để tìm hiểu chuyện gì đã xảy ra.
4. Phục hồi . Cài đặt bất cứ thứ gì cần thiết và phục hồi các bản sao lưu để đưa khách hàng của bạn trực tuyến.
5. Theo dõi . Tìm hiểu vấn đề là gì và ngăn nó xảy ra lần nữa.

Câu trả lời "viên thuốc đắng" của Robert là tại chỗ nhưng hoàn toàn chung chung (cũng như câu hỏi của bạn). Có vẻ như bạn có một vấn đề về quản lý và rất cần một sysadmin toàn thời gian nếu bạn có một máy chủ và 600 máy khách nhưng điều đó không giúp ích gì cho bạn bây giờ.

Tôi điều hành một công ty lưu trữ cung cấp một chút nắm bắt trong tình huống này, vì vậy tôi đối phó với rất nhiều máy móc bị xâm nhập, nhưng cũng đối phó với thực tiễn tốt nhất cho chính chúng ta. Chúng tôi luôn nói với khách hàng bị xâm phạm của mình để xây dựng lại trừ khi họ không hoàn toàn chắc chắn về bản chất của sự thỏa hiệp. Không có lộ trình chịu trách nhiệm khác trong dài hạn.

Tuy nhiên, bạn gần như chắc chắn chỉ là nạn nhân của một đứa trẻ kịch bản muốn có bệ phóng cho các cuộc tấn công DoS, hoặc người gửi IRC, hoặc một cái gì đó hoàn toàn không liên quan đến trang web và dữ liệu của khách hàng của bạn. Do đó, như một biện pháp tạm thời trong khi bạn xây dựng lại, bạn có thể xem xét việc đưa ra một tường lửa bên ngoài nặng nề trên hộp của mình. Nếu bạn có thể chặn tất cả các kết nối UDP và TCP bên ngoài không thực sự cần thiết cho hoạt động của trang web của bạn, bạn có thể dễ dàng làm cho hộp bị xâm phạm của mình trở nên vô dụng đối với bất kỳ ai mượn nó từ bạn và giảm thiểu ảnh hưởng đến mạng của nhà cung cấp của bạn bằng không.

Quá trình này có thể mất vài giờ nếu bạn chưa thực hiện trước đó và chưa bao giờ xem xét tường lửa, nhưng có thể giúp bạn khôi phục dịch vụ khách hàng của mình có nguy cơ tiếp tục cung cấp cho kẻ tấn công quyền truy cập vào dữ liệu khách hàng của bạn . Vì bạn nói rằng bạn có hàng trăm khách hàng trên một máy, tôi đoán rằng bạn đang lưu trữ các trang web tài liệu nhỏ cho các doanh nghiệp nhỏ chứ không phải 600 hệ thống thương mại điện tử có đầy đủ số thẻ tín dụng. Nếu đó là trường hợp có thể là rủi ro chấp nhận được cho bạn và đưa hệ thống của bạn trở lại trực tuyến nhanh hơn kiểm tra 600 trang web để tìm lỗi bảo mật trước khi bạn mang lại bất cứ điều gì. Nhưng bạn sẽ biết dữ liệu nào ở đó và bạn sẽ cảm thấy thoải mái như thế nào khi đưa ra quyết định đó.

Đây hoàn toàn không phải là cách thực hành tốt nhất, nhưng nếu đó không phải là điều đã xảy ra với chủ nhân của bạn cho đến nay, hãy vẫy ngón tay với họ và yêu cầu hàng chục ngàn bảng cho một đội SWAT vì điều gì đó họ có thể cảm thấy là lỗi của bạn (tuy nhiên không chính đáng! ) không giống như tùy chọn thực tế.

Sự trợ giúp của ISP của bạn ở đây sẽ rất quan trọng - một số ISP cung cấp máy chủ bảng điều khiển và môi trường khởi động mạng (cắm, nhưng ít nhất bạn biết loại thiết bị nào cần tìm) sẽ cho phép bạn quản trị máy chủ trong khi ngắt kết nối mạng. Nếu đây là một lựa chọn, hãy yêu cầu và sử dụng nó.

Nhưng về lâu dài, bạn nên lập kế hoạch xây dựng lại hệ thống dựa trên bài đăng của Robert và kiểm toán từng trang web và thiết lập của nó. Nếu bạn không thể thêm sysadmin vào nhóm của mình, hãy tìm một hợp đồng lưu trữ được quản lý nơi bạn trả tiền cho ISP để được trợ giúp về sysadminning và phản hồi 24 giờ cho loại điều này. Chúc may mắn :)

Bạn cần cài đặt lại. Lưu những gì bạn thực sự cần. Nhưng hãy nhớ rằng tất cả các tệp có thể chạy của bạn có thể bị nhiễm và giả mạo. Tôi đã viết như sau trong python: http://frw.se/monty.py tạo MD5-sumbs của tất cả các tệp của bạn trong một thư mục nhất định và lần sau khi bạn chạy nó, nó sẽ kiểm tra xem có gì đã được thay đổi không và sau đó xuất ra cái gì tập tin thay đổi và những gì thay đổi trong các tập tin.

Điều này có thể hữu ích cho bạn, để xem các tập tin lạ có được thay đổi thường xuyên không.

Nhưng điều duy nhất bạn nên làm bây giờ, là loại bỏ máy tính của bạn khỏi internet.

LƯU Ý: Đây không phải là một khuyến nghị. Giao thức Ứng phó sự cố cụ thể của tôi có thể sẽ không áp dụng không được sửa đổi đối với trường hợp của Grant unwin.

Trong các cơ sở học tập của chúng tôi, chúng tôi có khoảng 300 nhà nghiên cứu chỉ làm tính toán. Bạn có 600 khách hàng với các trang web nên giao thức của bạn có thể sẽ khác.

Các bước đầu tiên trong khi máy chủ nhận được giao thức thỏa hiệp là:

1. Xác định rằng kẻ tấn công đã có thể lấy quyền root (đặc quyền nâng cao)
2. Rút phích cắm (các) máy chủ bị ảnh hưởng. Mạng hay quyền lực? Xin vui lòng xem một cuộc thảo luận riêng biệt .
3. Kiểm tra tất cả các hệ thống khác
4. Khởi động (các) máy chủ bị ảnh hưởng từ đĩa cd trực tiếp
5. (tùy chọn) Lấy hình ảnh của tất cả các ổ đĩa hệ thống vớidd

6. Bắt đầu làm pháp y sau khi chết. Nhìn vào nhật ký, tìm ra thời gian của cuộc tấn công, tìm các tệp đã được sửa đổi vào thời điểm đó. Thử trả lời thế nào? câu hỏi

   • Song song, lập kế hoạch và thực hiện phục hồi của bạn.
   • Đặt lại tất cả mật khẩu root và người dùng trước khi tiếp tục dịch vụ

Ngay cả khi "tất cả các cửa hậu và rootkit đã được dọn sạch", đừng tin vào hệ thống đó - cài đặt lại từ đầu.

Theo kinh nghiệm hạn chế của tôi, các thỏa hiệp hệ thống trên Linux có xu hướng 'toàn diện' hơn so với trên Windows. Các bộ công cụ gốc có nhiều khả năng bao gồm việc thay thế các nhị phân hệ thống bằng mã tùy chỉnh để ẩn phần mềm độc hại và rào cản để vá lỗi kernel thấp hơn một chút. Thêm vào đó, nó là hệ điều hành gia đình cho rất nhiều tác giả phần mềm độc hại. Hướng dẫn chung là luôn xây dựng lại máy chủ bị ảnh hưởng từ đầu và đó là hướng dẫn chung vì một lý do.

Định dạng con chó con đó.

Nhưng, nếu bạn không thể xây dựng lại (hoặc các quyền lực sẽ không cho phép bạn xây dựng lại nó trước sự khăng khăng vất vả của bạn rằng nó cần nó), bạn sẽ tìm kiếm điều gì?

Vì có vẻ như đã được một thời gian kể từ khi sự xâm nhập được phát hiện và việc khôi phục hệ thống đã được thực hiện, rất có thể các dấu vết về cách chúng xâm nhập đã bị giẫm đạp để khôi phục dịch vụ. Thật không may.

Lưu lượng truy cập mạng bất thường có lẽ là dễ tìm thấy nhất, vì điều đó không liên quan đến việc chạy bất cứ thứ gì trên hộp và có thể được thực hiện trong khi máy chủ hoạt động và làm bất cứ điều gì. Tất nhiên, giả định, thiết bị mạng của bạn cho phép mở rộng cổng. Những gì bạn tìm thấy có thể hoặc không thể chẩn đoán, nhưng ít nhất đó là thông tin. Nhận được lưu lượng truy cập bất thường sẽ là bằng chứng mạnh mẽ cho thấy hệ thống vẫn bị xâm phạm và cần phải làm phẳng. Nó có thể đủ tốt để thuyết phục TPTB rằng một định dạng lại thực sự, thực sự, đáng giá thời gian chết.

Không, hãy lấy một bản sao dd của các phân vùng hệ thống của bạn và gắn chúng vào một hộp khác. Bắt đầu so sánh nội dung với một máy chủ ở cùng cấp độ bản vá với máy chủ bị xâm nhập. Nó sẽ giúp bạn xác định những gì trông khác nhau (những md5sums một lần nữa) và có thể chỉ ra các khu vực bị bỏ qua trên máy chủ bị xâm nhập. Đây là RẤT NHIỀU sàng lọc thông qua các thư mục và nhị phân, và sẽ khá tốn công. Nó thậm chí có thể tốn nhiều công sức hơn so với việc định dạng lại / xây dựng lại, và có thể là một điều khác để đánh bại TPTB về việc thực sự định dạng lại mà nó thực sự cần.

Tôi muốn nói @Robert Moir, @Aleksandr Levchuk, @blueben và @Matthew Bloch đều được chú ý khá nhiều trong các câu trả lời của họ.

Tuy nhiên, câu trả lời của các áp phích khác nhau khác nhau - một số khác ở cấp độ cao hơn và nói về những thủ tục bạn nên có tại chỗ (nói chung).

Tôi muốn tách phần này thành nhiều phần riêng biệt 1) Triage, AKA Cách đối phó với khách hàng và ý nghĩa pháp lý, và xác định nơi sẽ đi từ đó (Được liệt kê rất tốt bởi Robert và @blueben 2) Giảm thiểu tác động 3 ) Ứng phó sự cố 4) Pháp y sau khi chết 5) Các hạng mục khắc phục và thay đổi kiến ​​trúc

(Chèn bản tuyên bố phản hồi được chứng nhận SANS GSC tại đây) Dựa trên kinh nghiệm trong quá khứ, tôi muốn nói như sau:

Bất kể bạn đang xử lý các phản hồi, thông báo, pháp lý và kế hoạch trong tương lai của khách hàng như thế nào, tôi muốn tập trung vào vấn đề chính trong tay. Câu hỏi ban đầu của OP thực sự chỉ liên quan trực tiếp đến # 2 và # 3, về cơ bản, làm thế nào để ngăn chặn cuộc tấn công, khiến khách hàng quay lại ASAP trực tuyến ở trạng thái ban đầu, được phản hồi rất tốt.

Phần còn lại của các phản hồi là tuyệt vời và bao gồm rất nhiều thực tiễn tốt nhất được xác định và các cách để ngăn chặn điều đó xảy ra trong tương lai cũng như phản ứng tốt hơn với nó.

Nó thực sự phụ thuộc vào ngân sách của OP và họ thuộc ngành nào, giải pháp mong muốn của họ là gì, v.v.

Có lẽ họ cần phải thuê một SA tại chỗ chuyên dụng. Có lẽ họ cần một người bảo mật. Hoặc có thể họ cần một giải pháp được quản lý hoàn toàn như Firehost hoặc Rackspace Managed, Softlayer, ServePath, v.v.

Nó thực sự phụ thuộc vào những gì làm việc cho doanh nghiệp của họ. Có thể năng lực cốt lõi của họ không nằm ở quản lý máy chủ và không có ý nghĩa gì khi họ cố gắng phát triển điều đó. Hoặc, có thể họ là một tổ chức kỹ thuật khá tốt và có thể đưa ra quyết định tuyển dụng đúng đắn và mang lại một đội ngũ chuyên trách toàn thời gian.

Sau khi làm việc và xem xét máy chủ, chúng tôi đã tìm ra vấn đề. May mắn thay, các tệp vi phạm đã được tải lên hệ thống vào Chủ nhật, khi văn phòng đóng cửa và không có tệp nào được tạo, ngoài các tệp nhật ký và bộ đệm. Với lệnh shell đơn giản để tìm ra tập tin nào đã được tạo vào ngày hôm đó, chúng tôi đã tìm thấy chúng.

Tất cả các tệp vi phạm dường như đã nằm trong thư mục / hình ảnh / trên một số trang web zencart cũ của chúng tôi. Dường như có một lỗ hổng bảo mật cho phép (sử dụng curl) bất kỳ kẻ ngốc nào để tải lên những hình ảnh không phải vào phần tải lên hình ảnh trong phần quản trị. Chúng tôi đã xóa các tệp .php vi phạm và sửa các tập lệnh tải lên để không cho phép bất kỳ tệp tải lên nào không có hình ảnh.

Nhìn lại, nó khá đơn giản và tôi đã đưa ra câu hỏi này trên iPhone của mình trên đường đi làm. Cảm ơn tất cả những người giúp đỡ của bạn.

Để tham khảo của bất cứ ai ghé thăm bài viết này trong tương lai. Tôi không khuyên bạn nên rút phích cắm điện.

Tôi có rất ít đóng góp cho các câu trả lời kỹ thuật sâu rộng nhưng xin vui lòng lưu ý một số trong số này:

Các hành động phi kỹ thuật:

• Báo cáo sự cố trong nội bộ.
  Nếu bạn chưa có kế hoạch ứng phó sự cố có thể xuất hiện kỹ thuật CYA, nhưng bộ phận CNTT không phải là nơi duy nhất và thường không phải là nơi tốt nhất để xác định tác động kinh doanh của máy chủ bị xâm nhập.
  Yêu cầu kinh doanh có thể thổi phồng mối quan tâm kỹ thuật của bạn. Đừng nói "Tôi đã nói với bạn như vậy" và rằng ưu tiên của mối quan tâm kinh doanh là lý do bạn có máy chủ bị xâm nhập này ngay từ đầu. (" Để lại đó cho báo cáo sau hành động. ")

• Che đậy một sự cố an ninh lên không phải là một lựa chọn.

• Báo cáo với chính quyền địa phương.
  ServerFault KHÔNG phải là nơi tư vấn pháp lý, nhưng đây là điều cần được đưa vào kế hoạch ứng phó sự cố.
  Ở một số địa phương và / hoặc các ngành công nghiệp được quy định bắt buộc phải báo cáo (một số) sự cố an ninh cho cơ quan thực thi pháp luật địa phương, cơ quan quản lý hoặc thông báo cho khách hàng / người dùng bị ảnh hưởng.
  Bất kể, quyết định báo cáo cũng như báo cáo thực tế không chỉ được đưa ra trong bộ phận CNTT. Mong đợi sự tham gia từ ban quản lý và các bộ phận truyền thông (tiếp thị) hợp pháp và doanh nghiệp.
  Có lẽ bạn không nên kỳ vọng quá nhiều, internet là một nơi rộng lớn, nơi biên giới có rất ít ý nghĩa, nhưng các bộ phận tội phạm mạng tồn tại trong nhiều sở cảnh sát đã giải quyết tội phạm kỹ thuật số và có thể đưa tội ra công lý.

Tôi nghĩ tất cả sôi sục vì điều này:

Nếu bạn coi trọng công việc của mình, bạn nên có một kế hoạch và sửa đổi nó thường xuyên.

Không lập kế hoạch là lập kế hoạch thất bại, và nó không phải là nơi nào khác ngoài bảo mật hệ thống. Khi <redacted> chạm vào quạt, bạn nên sẵn sàng đối phó với nó.

Có một câu nói khác (hơi sáo rỗng) được áp dụng ở đây: Phòng bệnh hơn chữa bệnh .

Đã có một số khuyến nghị ở đây để giúp các chuyên gia kiểm toán các hệ thống hiện tại của bạn. Tôi nghĩ rằng đây là đặt câu hỏi không đúng lúc. Câu hỏi này nên được hỏi khi hệ thống được đưa ra, và các câu trả lời được ghi lại. Ngoài ra, câu hỏi không nên là "Làm thế nào chúng ta có thể ngăn chặn mọi người xâm nhập?" Nó phải là "Tại sao mọi người nên có thể đột nhập?" Kiểm tra một loạt các lỗ hổng trong mạng của bạn sẽ chỉ hoạt động cho đến khi các lỗ hổng mới được tìm thấy và khai thác. Mặt khác, các mạng được thiết kế từ đầu để chỉ đáp ứng theo một số cách nhất định đối với một số hệ thống nhất định trong một điệu nhảy được biên đạo cẩn thận sẽ không được hưởng lợi từ việc kiểm toán và tiền sẽ là một sự lãng phí.

Trước khi đưa một hệ thống lên internet, hãy tự hỏi - điều này có cần phải đối mặt với 100% internet không? Nếu không, đừng. Xem xét đặt nó phía sau một tường lửa nơi bạn có thể quyết định những gì internet nhìn thấy. Thậm chí tốt hơn, nếu nói tường lửa cho phép bạn chặn các truyền (thông qua proxy ngược hoặc bộ lọc thông qua một số loại) xem xét sử dụng nó để chỉ cho phép các hành động hợp pháp xảy ra.

Điều này đã được thực hiện - có (hoặc là) một thiết lập ngân hàng internet ở đâu đó có proxy cân bằng tải đối diện với internet mà họ sẽ sử dụng để tấn công véc tơ khỏi nhóm máy chủ của họ. Chuyên gia bảo mật Marcus Ranum đã thuyết phục họ thực hiện cách tiếp cận ngược lại, bằng cách sử dụng proxy ngược để chỉ cho phép các URL hợp lệ được biết thông qua và gửi mọi thứ khác đến máy chủ 404 . Nó đứng trước thử thách của thời gian một cách đáng ngạc nhiên.

Một hệ thống hoặc mạng dựa trên giấy phép mặc định chắc chắn sẽ thất bại một khi cuộc tấn công mà bạn không thấy trước xảy ra. Từ chối mặc định cung cấp cho bạn quyền kiểm soát lớn hơn nhiều đối với những gì được đưa vào và những gì không, bởi vì bạn sẽ không để bất cứ thứ gì bên trong được nhìn thấy từ bên ngoài trừ khi nó thực sự cần thiết .

Điều đó nói rằng, tất cả điều này không có lý do để có được tự mãn. Bạn vẫn nên có kế hoạch tại chỗ trong vài giờ đầu sau khi vi phạm. Không có hệ thống nào là hoàn hảo và con người mắc sai lầm.

Một người lái xe tốt bụng đã giúp tôi gần đây để tìm hiểu làm thế nào một kẻ tấn công có thể thỏa hiệp một hệ thống. Một số cracker cố gắng che giấu dấu vết của chúng bằng cách giả mạo thời gian sửa đổi trên các tập tin. Bằng cách thay đổi thời gian sửa đổi, thời gian thay đổi được cập nhật (ctime). bạn có thể thấy ctime với stat.

Lớp lót này liệt kê tất cả các tệp được sắp xếp theo ctime:

find / -type f -print0 | xargs -0 stat --format '%Z :%z %n' | sort -nr > /root/all_files.txt

Vì vậy, nếu bạn đại khái biết thời gian thỏa hiệp, bạn có thể xem tập tin nào được thay đổi hoặc tạo.