Câu hỏi Làm thế nào để đối phó với một máy chủ bị xâm nhập?


Đây là một Câu hỏi về Canonical về Bảo mật máy chủ - Trả lời các sự kiện vi phạm (Hacking)
  Xem thêm:

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

  • Cá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ữ "bằng chứng", có những cân nhắc ban đầu khác không?
  • Tôi làm cách nào để nhận dịch vụ trực tuyến?
  • Làm cách nào để tôi ngăn điều tương tự xảy ra ngay lập tức?
  • Có những phương pháp hoặc phương pháp hay nhất để học hỏi từ sự việc này không?
  • Nếu tôi muốn đặt mộ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 Phục hồi Thiên tai 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 chiều vào ngày 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à kết quả là    DOS tấn công vào nhà cung cấp của chúng tôi. Các máy chủ truy cập Internet   đã bị đóng cửa có nghĩa là hơn 5-600 trang web khách hàng của chúng tôi hiện đang   xuống. Bây giờ đây có thể là một hack FTP, hoặc một số điểm yếu trong mã   một vài nơi. Tôi không chắc 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 đang ở rất nhiều   kiện tụng nếu tôi không nhận được máy chủ sao lưu càng sớm càng tốt. Bất kỳ trợ giúp nào là   đánh giá cao. Chúng tôi đang chạy Open SUSE 11.0.


2011/01.03 - Nhờ mọi người 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 về máy chủ này, chỉ là 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ẽ trình bày chi tiết những gì chúng tôi đã làm.

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

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

Sau một lần nghỉ thuốc lá ngắn, chúng tôi kết luận rằng, do các tập tin   vị trí, 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 an toàn. Sau khi một số googling, chúng tôi thấy rằng đã có   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, để có hình ảnh cho một công ty thu âm. (Phần   rằng nó thậm chí không bao giờ thực sự được sử dụng), đăng tải biểu mẫu này chỉ cần tải lên bất kỳ   tệp, nó không kiểm tra phần mở rộng của tập tin, và thậm chí không kiểm tra   kiểm tra xem liệu người dùng đã đăng nhập chưa.

Điều này có nghĩa là mọi tệp 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 vệ lỗ hổng với ZenCart trên trang web bị nhiễm   trang web và xóa các tệp vi phạm.

Công việc đã xong, và tôi về nhà lú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 đề đó. Khi cập nhật bảo mật được phát hành, toàn bộ   thế giới được nhận thức về sự dễ bị tổn thương.   - Luôn sao lưu và sao lưu dự phòng của bạn.   - Sử dụng hoặc sắp xếp cho một người nào đó sẽ có mặt ở đó trong những thời điểm như thế này. Để ngăn chặn bất kỳ ai dựa vào một bài đăng thú vị trên Máy chủ   Lỗi.


578
2018-01-02 21:31


gốc


Tôi biết bạn cảm thấy thế nào - chúng tôi đã rất may mắn với những tin tặc "hữu ích" trên trang web này, nơi họ cho chúng tôi biết những gì họ đã làm! Tôi đang mong chờ các câu trả lời tuyệt vời cho câu hỏi này, chỉ trong trường hợp chúng tôi nhận được khách "không phải là hữu ích" trong tương lai. - Jarrod Dixon♦
Gọi một chuyên gia để giúp đỡ! - marcog
Tôi không muốn âm thanh thông minh hoặc không thông cảm (tôi không phải), và tất nhiên tôi không biết gì về tình hình của bạn, nhưng nếu bạn là người duy nhất chịu trách nhiệm thiết lập trang web 500-600, có thể là một lỗ hổng cơ bản trong cách máy chủ này chạy. Một số công ty sử dụng một sysadmin chuyên dụng, những người không làm bất cứ điều gì khác cả ngày nhưng duy trì máy chủ - một nhiệm vụ không phải tự động trong phạm vi của một lập trình viên, mặc dù nó có vẻ như vậy. Có lẽ đó là một cái gì đó đáng xem xét khi cuộc khủng hoảng kết thúc. Dù sao, ngay bây giờ, tốt nhất của may mắn trong việc giải quyết tình hình ở bàn tay. - Pekka 웃
Không nhất thiết giả sử bạn có một bộ rễ gốc đầy đủ và mật khẩu gốc của bạn bị xâm phạm. Nó có thể chỉ là một kịch bản bash / perl lén lút, và nó có thể làm sạch nó mà không hình thành mặc dù những gì các ca đoàn harps về về đây ... serverfault.com/questions/639699/… - Hayden Thring


Các câu trả lời:


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 dựa trên bài đăng tôi đã viết cách đây từ lâu khi tôi vẫn có thể bị làm phiền với blog.

Đừng hoảng loạn

Trước tiên, không có "sửa lỗi nhanh" 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 nào 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ỡ trong thời gian qua, cũng không phải đối phó với hậu quả của bất kỳ "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 bị các nạn nhân của tin tặc đột nhập vào máy chủ web của họ liên tục hỏi. Câu trả lời rất hiếm khi thay đổi, nhưng mọi người tiếp tục đặt câu hỏi. Tôi cung không chăc tại sao. Có lẽ mọi người 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 người mà họ tin tưởng để đưa ra lời khuyên cho họ. 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ực tuyến và bỏ qua 95% câu hỏi và câu trả lời trong trường hợp của họ gần đủ là người họ đọc trực tuyến.

Điều đó đưa tôi đến 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ì đó là sự phản ánh của 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 chủ nhân. Nhưng với ai đó ở bên ngoài tìm kiếm, cho dù một người bảo mật máy tính đang xem xét vấn đề để thử và giúp bạn hay thậm chí là kẻ tấn công, rất có thể vấn đề của bạn sẽ ít nhất 95% giống với mọi trường hợp khác mà họ đã bao giờ nhìn vào.

Không tự mình tấn công và không thực hiện các đề xuất theo dõi ở đây hoặc bạn nhận được từ người khác một cách cá nhân. Nếu bạn đang đọc điều này sau khi trở thành nạn nhân của một trang web hack 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 một cái gì đó hữu ích ở đây, nhưng đây không phải là lúc để cho bản ngã của bạn cản đường 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ị tấn công. 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 thử và giả vờ những điều không bao giờ xảy ra và không hành động chút nào.

Thứ nhất: 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ẽ gây tổn thương, và (trừ khi trang web của bạn nắm giữ một bản sao 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, 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. Các loại thuốc có thể hương vị khủng khiếp nhưng đôi khi bạn phải bỏ qua rằng nếu bạn thực sự muốn chữa bệnh để làm việc.

Ngừng vấn đề trở nên tồi tệ hơn nó đã là:

  1. Việc đầ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, hãy để 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; có được một người nào đó đến thực tế truy cập vào máy chủ và rút dây cáp mạng nếu đó là những gì nó cần, 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 có cùng 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. Có, bạn nói đú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à đối với những dịch vụ giữ 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 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 sẽ tiết lộ đầy đủ. Tôi biết điều này là khó khăn. Tôi biết cái này sẽ bị 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 đối phó với nó - và cần phải làm như vậy với một mắt trên 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 có thể khó chịu nếu bạn nói với họ về một vấn đề, họ sẽ khó chịu hơn nếu bạn không nói với họ, và họ chỉ tự tìm ra sau khi ai đó tính phí 8.000 đô la hàng hóa bằng cách sử dụng chi tiết 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 xấu đã xảy ra. Câu hỏi duy nhất là bạn đối phó tốt với nó như thế nào.

Hiểu rõ vấn đề:

  1. KHÔNG đặt 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 toàn hoàn chỉnh, trừ khi bạn muốn trở thành người có bài đăng là điểm đến hạn cho 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 viết đó để mọi người có thể nhận được một tiếng cười rẻ tiền, nhưng thảm kịch thực sự là khi mọi người không học hỏi từ những sai lầm của họ.
  2. Kiểm tra các hệ thống 'tấn công' để hiểu các cuộc tấn công thành công như thế nào trong việc xâm phạm bảo mật của bạn. Thực hiện mọi nỗ lực để tìm ra nơi các cuộc tấn công "đến từ", để bạn hiểu những vấn đề bạn có và cần phải 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 'tấn công', lần này để hiểu các cuộc tấn công diễn ra ở đâu, để bạn hiểu những hệ thống nào đã bị tấn công 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 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 đượ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ị tấn công bởi một cuộc tấn công SQL injection, thì bạn không chỉ cần đóng một dòng mã mà họ đã phá vỡ, bạn sẽ muốn kiểm tra tất cả mã của bạn để xem có cùng loại lỗi hay 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 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 cùng nhau một số vấn đề (đôi khi 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 SQL injection để gửi các lệnh đến một máy chủ cơ sở dữ liệu, phát hiện trang web / ứng dụng mà bạn đang tấn công đang chạy trong ngữ cảnh của người dùng quản trị và sử dụng quyền của tài khoản đó làm bước đệm để thỏa hiệp các phần khác của hệ thống. Hoặc như tin tặc muốn gọi nó: "một ngày khác trong văn phòng lợi dụng những sai lầm 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 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ó quyền kiểm soát hệ thống đó nữa. Nó không phải máy tính của bạn nữa.

Cách duy nhất để trở thành 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 để đột 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 cho hệ thống một khi những kẻ xâm nhập giành quyền kiểm soát. hệ thống vào một 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 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ủ:

Không ai muốn ngoại tuyến lâu hơn họ phải làm. Đó 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 một cách nhanh chóng sẽ rất căng thẳng. Ngay cả khi điều duy nhất bị đe dọa là danh tiếng của công ty bạn / của bạn, điều này vẫn sẽ tạo ra rất nhiều áp lực để đưa mọi thứ trở lại nhanh chóng.

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

  1. Tôi giả sử 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 vụ án 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 hiệu dễ dàng và bạn không muốn cụm từ đó từng được sử dụng để mô tả bạn.
  3. Đừng bị cám dỗ để đưa cùng một máy chủ trở lại trực tuyến mà không cần xây dựng lại hoàn toàn. Sẽ nhanh hơn 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 đưa nó trở 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ó thể bạn không biết nó thực sự có nghĩa là gì để đảm bảo một hệ thống được dọn dẹp hoàn toàn, hoặc các quy trình triển khai trang web của bạn là một mớ hỗn độn không vui. Bạn có thể có bản sao lưu và triển khai thử nghiệm trang web của mình mà bạn có thể sử dụng để xây dựng trang web trực tiếp và nếu bạn không bị tấn công thì đó không phải là vấn đề lớn nhất của bạn.
  4. Hãy rất cẩn thận về việc tái sử dụng dữ liệu đã được "sống" trên hệ thống tại thời điểm hack. Tôi sẽ không nói "không bao giờ làm điều đó" bởi vì bạn sẽ chỉ phớt lờ tôi, nhưng thẳng thắn tôi nghĩ bạn cần xem xét hậu quả của việc giữ dữ liệu xung quanh khi bạn biết bạn không thể đảm bảo tính toàn vẹn của nó. Lý tưởng nhất, bạn nên khôi phục điều này từ mộ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 đó bởi vì nó bị nhiễm độc. Bạn nên đặc biệt chú ý đến hậu quả của 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 thay vì trực tiếp cho bạn.
  5. Giám sát cẩn thận (các) hệ thống. Bạn nên giải quyết để làm điều này như là một quá trình liên tục trong tương lai (nhiều hơn dưới đây) nhưng bạn phải chịu thêm đau đớn để thận trọng trong 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 họ đang cố gắng đột nhập, 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ỗ mà họ đã sử dụng trước đó. 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 nguy cơ trong tương lai.

Điều đầu tiên bạn cần hiểu là bảo mật là một quá trình mà bạn phải áp dụng trong toàn bộ vòng đời của việc thiết kế, triển khai và duy trì hệ thống đối mặt với Internet, chứ không phải cái gì bạn có thể tát vài lớp trên mã của bạn sau đó Sơn. Để đảm bảo an toàn, một dịch vụ và một ứng dụng cần được thiết kế ngay từ đầu với mục đích này là một trong những mục tiêu chính của dự án. Tôi nhận ra đó là nhàm chán và bạn đã nghe tất cả trước đó và rằng tôi "không nhận ra người đàn ông áp lực" của dịch vụ beta web2.0 beta (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 giữ lặp đi lặp lại bởi vì đó là sự thật lần đầu tiên nó được nói và nó chưa trở thành một 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 quan trọng đối với bạn và hiểu cách quản lý và giảm thiểu tác động của rủi ro và xác suất rủi ro sẽ xảy ra.

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

Ví dụ:

  1. Là lỗ hổng cho phép mọi người đột nhập vào trang web của bạn một lỗi đã biết trong mã nhà cung cấp, có bản vá nào có sẵn không? Nếu vậy, bạn có cần phải nghĩ lại cách tiếp cận của mình về cách bạn vá các ứng dụng trên các máy chủ phải đối mặt với Internet của bạn không?
  2. Là lỗ hổng cho phép mọi người đột nhập vào trang web của bạn một lỗi không xác định trong mã của nhà cung cấp, mà bản vá không có sẵn? Tôi chắc chắn không chủ trương thay đổi nhà cung cấp bất cứ khi nào một cái gì đó như thế này cắn bạn bởi vì tất cả họ đều có vấn đề của họ và bạn sẽ chạy ra khỏi nền tảng trong một năm nhiều nhất nếu bạn có cách tiếp cận này. Tuy nhiên, nếu một hệ thống liên tục cho phép bạn xuống thì bạn nên di chuyển sang thứ gì đó mạnh mẽ hơn hoặc ít nhất, kiến ​​trúc lại hệ thống của bạn để các thành phần dễ bị tổn thương vẫn bị bao bọc trong bông vải và càng xa càng tốt khỏi đôi mắt thù địch.
  3. Là lỗ hổng trong mã được phát triển bởi bạn (hoặc một nhà thầu làm việc cho bạn)? Nếu vậy, bạn có cần phải nghĩ lại cách tiếp cận của mình 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 đã bị bắt với hệ thống kiểm tra được cải tiến, hoặc với những 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 injection thành công bằng cách sử dụng kỹ thuật mã hóa được ghi chép đầy đủ. ).
  4. Có phải lỗ hổng do sự cố về cách máy chủ hoặc phần mềm ứng dụng được triển khai không? Nếu vậy, bạn có đang sử dụng các thủ tục tự động để xây dựng và triển khai các máy chủ nếu có thể không? Đây là một trợ giúp lớn 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 được thực hiện trên mỗi máy chủ và do đó hy vọng giảm thiểu cơ hội cho một sai lầm được thực hiện. 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" được thực hiện để triển khai phiên bản ứng dụng web mới nhất 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ể sự xâm nhập đã bị bắt trước đó với sự giám sát tốt hơn các hệ thống của bạn không? Tất nhiên, giám sát 24 giờ hoặc hệ thống "gọi điện" 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 ngoài đó có thể giám sát dịch vụ web của bạn và cảnh báo bạn trong trường hợp có sự cố. Bạn có thể quyết định bạn không đủ khả năng này hoặc không cần nó và đó là tốt ... chỉ cần đưa vào xem xét.
  6. Sử dụng các công cụ như tripwire và nessus khi thích hợp - nhưng khô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ê 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 bạn không thể đủ khả năng này hoặc không cần nó và đó là tốt ... chỉ cần đưa vào xem xét.

Bạn có thể thực hiện những bước nào để 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ơ" của tầng thấp hơn trong lũ nhà của bạn là cao, nhưng không đủ cao để đảm bảo di chuyển, bạn nên ít nhất di chuyển các gia truyền không thể thay thế gia đình lên lầu. Đúng?

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

... Và cuối cùng

Tôi có lẽ đã bỏ qua những thứ mà người khác xem là quan trọng, nhưng các bước trên ít nhất sẽ giúp bạn bắt đầu phân loại mọi thứ nếu bạn không đủ may mắn để 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 vững chắc sau 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 mình.


988
2018-01-02 21:46



+1 cho một bài đăng tuyệt vời để có mặt để mọi người bắt đầu theo một hướng. Tôi biết mức độ phổ biến của các quản trị viên máy chủ nghiệp dư vào chế độ hoảng loạn này lần đầu tiên họ có 'hack' xảy ra với họ. nó là một khổng lồ sai lầm là ở chỗ đó, nhưng nó xảy ra. Hy vọng rằng điều này sẽ không xảy ra cho cùng một người, hai lần. - Andrew Barber
+1 "... nhưng đây không phải là lúc để bản ngã của bạn cản trở những gì bạn cần làm." Điều này quan trọng đối với Quản trị viên Sys để hiểu đôi khi. Bất kể bạn hiểu biết bao nhiêu, luôn có những người (đôi khi độc hại), những người hiểu biết hoặc thông minh hơn bạn. - Grahamux
Câu trả lời chính xác. Tôi không chắc chắn lý do tại sao tất cả mọi người đang điều trị "gọi thực thi pháp luật" bước như là tùy chọn mặc dù. Nếu bạn chịu trách nhiệm về dữ liệu của người khác (và lo lắng về việc kiện tụng), đây sẽ là một trong những điều đầu tiên trong danh sách những việc bạn cần làm. - wds
Rất tốt khi viết lên, chỉ một bản ghi nhớ - "thực hiện công bố đầy đủ và thẳng thắn cho bất kỳ ai có khả năng bị ảnh hưởng cùng một lúc." Danh dự, nhưng không phải lúc nào cũng đúng. Để giải quyết một sự thỏa hiệp, bạn có thể cần phải cắt giảm một số góc quản trị và công ty của bạn thường sẽ cắt giảm một số bạn, tuy nhiên ... tiết lộ hay không, cụ thể là khi có ý nghĩa bảo vệ dữ liệu có thể là vấn đề ở trên mức lương của bạn và có thể có ý nghĩa pháp lý. Nó có thể là tốt hơn để đề nghị bạn ngay lập tức thông báo 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 đủ. - TheoJones
@GilesRoberts máy chủ ảo thường có bảng điều khiển cho phép bạn thao tác các cài đặt của khách của họ và thậm chí điều khiển từ xa chúng mà không cần sử dụng RDP hoặc SSH để thực sự đăng nhập vào khách. Bạn có thể cách ly khách bằng các điều khiển của máy chủ để làm như vậy, sau đó sử dụng các công cụ xem từ xa để điều tra khách khi rảnh rỗi. - Rob Moir


Nghe có vẻ như hơi ở trên đầu bạn; vậy là được rồi. Gọi cho sếp của bạn và bắt đầu đàm phán cho ngân sách trả lời bảo mật 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 có ai đó (một PFY, một đồng nghiệp, một người quản lý) để bắt đầu gọi các công ty chuyên về phản ứng sự cố an ninh. Nhiều người có thể trả lời trong vòng 24 giờ, và đôi khi thậm chí còn nhanh hơn nếu họ có một văn phòng trong 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 đó đã có. Ai đó cần phải 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 hình, 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 về phản ứng sự cố, những gì bạn làm bây giờ cần phải chứng minh sự chuyên nghiệp và lãnh đạo tối đa. Ghi lại tất cả 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ực hiện các hành động chính mà bạn thực hiện; điều này bao gồm làm việc với nhóm phản hồi, tắt 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 chi tiết đẫm máu, nhưng họ sẽ nghe từ bạn mỗi 30 phút hoặc lâu hơn.

  2. Hãy thực tế. Bạn không phải là chuyên gia bảo mật và có những thứ 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. Tread nhẹ nhàng. Trong quá trình điều tra của bạn, hãy chắc chắn rằng bạn không dậm vào thông tin quan trọng hoặc thay đổi một cái gì đó mà 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à có được một chuyên gia giàu kinh nghiệm để tiếp quả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 mọi thứ bạn cảm thấy có thể có liên quan; giao tiếp với ISP của bạn, bãi chứa mạng, vv Ngay cả khi 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 phạm. Tốt hơn, bạn nên kéo cáp mạng của họ; nếu bạn không thể, sau đó kéo sức mạnh.

  5. Tiếp theo, bạn cần phải loại bỏ những kẻ tấn công và đóng lỗ (s). 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 (với 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 hơn là bằng cách xóa ổ đĩa khỏi máy chủ bị ảnh hưởng và tạo bản sao hình ảnh đầy đủ), rồi xóa mọi mã và quy trình mà bạn để 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 để lại. Rootkit là luẩn quẩn, và không phải tất cả đều có thể phát hiện được. Phản ứng tốt nhất sẽ là xác định lỗ hổng mà anh ta thường sử dụng để xâm nhập, tạo bản sao ảnh của các đĩa bị ảnh hưởng và sau đó quét sạch các hệ thống bị ảnh hưởng và tải lại từ bản sao lưu đã biết. Đừng 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ủ lưu trữ mới xuất hiện lại trên mạng và sau đó mang nó trực tuyến.

  6. Tổ chức tất cả dữ liệu của bạn thành 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ó thời gian để thở. Đừng bị cám dỗ 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 điều gì đã xảy ra, nhóm của bạn đã phản hồi như thế nào 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à còn đối với việc quản lý của bạn và như một sự phòng thủ trong một vụ kiện tiềm năng.

Đó là một đánh giá cao về những gì cần làm; hầu hết công việc chỉ là tài liệu và xử lý sao lưu. Đừng hoảng sợ, bạn có thể làm điều đó. tôi mạnh mẽ khuyên bạn nên nhận trợ giúp bảo mật chuyên nghiệp. Ngay cả khi bạn có thể xử lý những gì đang xảy ra, sự giúp đỡ của họ sẽ 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 bẩm sinh với chi phí, hãy nhắc 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 hình của bạn. Chúc may mắn.


199
2018-01-02 22:16



+1 Câu trả lời hay. Có vẻ như OP không có "phản ứng khẩn cấp" được xác định trước và bài đăng của bạn, trong số những điều tốt đẹp khác, nên hướng họ đến việc thiết lập. - Rob Moir


CERT có tài liệu Các bước phục hồi từ một hệ thống UNIX hoặc NT Compromise điều đó tốt. Các chi tiết kỹ thuật cụ thể của tài liệu này hơi 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.

Tóm tắt nhanh về các bước cơ bản là điều nà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 (mang 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ì đã xảy ra
  • Sửa chữa công 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ó, 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 chỉ dẫn cụ thể bạn đến phần E.1.

E.1.   Hãy nhớ rằng nếu máy là   bị xâm phạm, mọi thứ trên hệ thống đó   có thể đã được sửa đổi, bao gồm   hạt nhân, tệp nhị phân, datafiles,   các tiến trình đang chạy và bộ nhớ. Trong   nói chung, cách duy nhất để tin tưởng rằng   máy miễn phí từ backdoors và   sửa đổi kẻ xâm nhập là cài đặt lại   hoạt động

Nếu bạn không có một hệ thống đã có sẵn như tripwire không có cách nào có thể cho bạn được 100% nhất định rằng bạn đã làm sạch hệ thống.


105
2018-05-08 09:02



Thậm chí sau đó tripwire có thể bị lừa với các mô-đun hạt nhân và như vậy. Cài đặt lại. - reconbot
Câu hỏi liên quan về làm thế nào để đáp ứng trong một cuộc khủng hoảng cũng có thể hữu ích ở đây. - Zoredache


  1. Nhận đị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. Xóa bỏ. Cài đặt lại hệ thống bị ảnh hưởng, rất có thể. Tuy nhiên, đừng xóa ổ cứng của máy bị tấn công, hãy sử dụng ổ cứng mới. Đó là an toàn hơn, và bạn có thể cần một cái cũ để phục hồi các hacks xấu xí mà không được sao lưu, và để làm pháp y để tìm hiểu những gì đã xảy ra.
  4. Bình phục. Cài đặt mọi thứ cần thiết và khôi phục các bản sao lưu để đưa khách hàng của bạn trực tuyến.
  5. Theo sát. Tìm ra vấn đề là gì và ngăn nó xảy ra lần nữa.

64
2018-01-02 21:49





Câu trả lời "cay đắng" của Robert là phát hiện tại chỗ nhưng hoàn toàn chung chung (tốt, như câu hỏi của bạn). Có vẻ như bạn có vấn đề về quản lý và 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 bạn ngay 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 tay trong tình huống này, vì vậy tôi đối phó với rất nhiều máy bị xâm nhập, nhưng cũng phải thực hành tốt nhất cho riêng mình. Chúng tôi luôn nói với các khách hàng bị xâm phạm của chúng tôi để 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 một thỏa hiệp. Không có con đường có trách nhiệm nào 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 kiddy script muốn một bệ phóng cho các cuộc tấn công DoS, hoặc các bouncers IRC, hoặc một cái gì đó hoàn toàn không liên quan đến các trang web và dữ liệu của khách hàng của bạn. Vì vậy, 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 bức tường lửa outbound nặng trên hộp của bạn. Nếu bạn có thể chặn tất cả các kết nối UDP và TCP không cần thiết cho hoạt động của trang web, bạn có thể dễ dàng làm cho hộp bị xâm phạm của bạn vô dụng đối với bất kỳ ai mượn nó và giảm thiểu hiệu ứng trên mạng của nhà cung cấp của bạn về 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ờ coi 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 nhỏ dành cho các doanh nghiệp nhỏ và không phải 600 hệ thống thương mại điện tử đầy đủ số thẻ tín dụng. Nếu đó là trường hợp này có thể là một nguy cơ chấp nhận được cho bạn, và làm cho hệ thống của bạn trở lại trực tuyến nhanh hơn kiểm toán 600 trang web cho các lỗi bảo mật trước bạn mang lại bất cứ điều gì trở lại. Nhưng bạn sẽ biết dữ liệu ở đó là gì, và bạn cảm thấy thoải mái khi quyết định như thế nào.

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

Trợ giúp của ISP của bạn ở đây sẽ khá quan trọng - một số ISP cung cấp một máy chủ bàn điều khiển và môi trường khởi động mạng (plug, nhưng ít nhất bạn biết loại cơ sở để tìm) sẽ cho phép bạn quản trị máy chủ trong khi ngắt kết nối khỏi mạng. Nếu đây là tùy 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 viết 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 kiếm quản lý lưu trữ thỏa thuận nơi bạn thanh toán cho ISP của mình để được trợ giúp quản lý và phản hồi 24 giờ đối với loại điều này. Chúc may mắn :)


49
2018-01-03 13:48





Bạn cần phải 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 runnable của bạn có thể bị nhiễm và bị can thiệp. 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 cụ thể và lần sau khi bạn chạy nó, nó sẽ kiểm tra xem có bất kỳ thứ gì đã được thay đổi không và sau đó xuất ra tệp nào đã thay đổi và những gì đã thay đổi trong tệp.

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

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 từ internet.


38
2018-05-08 08:02



Vì vậy ... bạn đã thực hiện tripwire. - womble♦
Vâng, có gì sai với điều đó? - Filip Ekberg
+1 để rút phích cắm, phân tích (nhờ ai đó thực hiện pháp y thực sự) và xóa - Oskar Duveborn
Với sự lựa chọn giữa một kịch bản Python ẩn danh và một giải pháp tiêu chuẩn được hỗ trợ, được giải thích rõ ràng (được phần nào), bạn đang hy vọng họ sẽ chọn cái cũ? - tripleee


CHÚ THÍCH: Đây không phải là một khuyến nghị. Cụ thể của tôi Ứng phó sự cố giao thức có lẽ sẽ không không áp dụng chưa sửa đổi cho 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 để 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 giao thức bị xâm nhập Là:

  1. Xác định rằng kẻ tấn công có thể đạt được 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 hoặc điện? Xin vui lòng xem thảo luận riêng.
  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ừ một đĩa CD trực tiếp
  5. (không bắt buộc) Lấy hình ảnh của tất cả các ổ đĩa hệ thống dd
  6. Bắt đầu thực hiện 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 tin đã được sửa đổi vào thời gian đó. Cố gắng trả lời Làm sao? 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 người dùng và mật khẩu người dùng trước khi tiếp tục dịch vụ

Ngay cả khi "tất cả backdoors và rootkit được dọn dẹp", đừng tin tưởng rằng hệ thống - cài đặt lại từ đầu.


34
2018-05-18 22:36



-1 Rút phích cắm máy chủ khỏi nguồn điện? Bạn vừa mất một nửa số liệu pháp y của bạn! - Josh Brower
@ Josh, tôi đã điều chỉnh câu trả lời của mình - bây giờ nó là trung lập về câu hỏi What to Unplug. - Aleksandr Levchuk
Phép kiểm tra RAM (ví dụ: / dev / shm) có thể hữu ích. Tôi thích rút cáp nguồn (nhưng cố gắng đăng nhập và rsync / proc ngay trước). Chúng tôi cũng có thể giới thiệu các ảnh chụp nhanh VM thường xuyên để có thể thực hiện được phép kiểm tra RAM. Những lý do cho việc đi cáp điện là (1) Khi bạn làm pháp y trong một hệ thống bị tấn công, bạn đang "bước qua tất cả các cảnh tội phạm"; (2) Bộ gốc vẫn tiếp tục chạy - không quá khó để có thể thực thi điều gì đó (ví dụ: xóa hệ thống) trên Liên kết mạng xuống biến cố. Kyle Rankin trong phần giới thiệu tuyệt vời về Forensics (goo.gl/g21Ok) đề nghị kéo cáp nguồn. - Aleksandr Levchuk
Không có một kích thước nào phù hợp với tất cả giao thức IR - Một số tổ chức có thể cần phải giữ cho hệ thống bị xâm nhập trực tuyến trong một thời gian lâu hơn, vì bất kỳ lý do gì. Quan điểm của tôi là tốt hơn nên đề xuất một giao thức IR chung (như Jakob Borgs ở trên) chứ không phải là giao thức bắt đầu bằng "Kéo phích cắm điện của máy chủ bị xâm phạm. " - Josh Brower


Theo kinh nghiệm hạn chế của tôi, sự 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ộ phần mềm gốc có nhiều khả năng bao gồm việc thay thế các tệp 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 hạt nhân thấp hơn một chút. Plus, đó là hệ điều hành nhà cho rất nhiều tác giả phần mềm độc hại. Các hướng dẫn chung là luôn luôn để xây dựng lại máy chủ bị ảnh hưởng từ đầu, và nó là hướng dẫn chung cho 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 quyền hạn-đó-sẽ không cho phép bạn xây dựng lại nó chống lại sự nhấn mạnh vất vả của bạn rằng nó cần nó), bạn tìm kiếm những gì?

Vì có vẻ như nó đã được một thời gian kể từ khi sự xâm nhập được phát hiện, và một hệ thống khôi phục đã được thực hiện, nó rất có thể là các dấu vết của cách họ đã in đã được dẫm lên trong các stampede để khôi phục dịch vụ. Không may.

Lưu lượng mạng bất thường có lẽ là dễ tìm 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ủ đang hoạt động và làm bất cứ điều gì. Giả sử, tất nhiên, 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ẽ rằng hệ thống vẫn bị xâm phạm và cần làm phẳng. Nó có thể là đủ tốt để thuyết phục TPTB rằng một định dạng lại thực sự, thực sự, đáng để có thời gian chết.

Nếu không, hãy sao chép các phân vùng hệ thống của bạn và gắn chúng vào hộp khác. Bắt đầu so sánh nội dung với máy chủ ở cùng cấp bản vá với mức độ bị xâm phạm. 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ể trỏ đến các khu vực bị bỏ qua trên máy chủ bị xâm nhập. Đây là một LOT của chọn lọc thông qua các thư mục và nhị phân, và sẽ được khá nhiều lao động. Nó thậm chí có thể tốn nhiều công sức hơn là cải cách / xây dựng lại sẽ là, và có thể là một thứ khác để tấn công TPTB về việc thực sự thực hiện cải cách mà nó thực sự cần.


28
2018-01-03 14:31



'Định dạng con chó con đó.' - 1, lời khuyên hiền triết. Xem thêm: "Nuke nó từ quỹ đạo, đó là cách duy nhất để chắc chắn." - Avery Payne


Tôi muốn nói @Robert Moir, @Aleksandr Levchuk, @blueben và @Matthew Bloch đều có khá nhiều điểm trong phản hồ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ố có nhiều hơn ở cấp độ cao và nói về các thủ tục bạn nên có tại chỗ (nói chung).

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

(Chèn bản câu trả lời được chứng nhận SANS được soạn thảo ở đây) Dựa trên kinh nghiệm quá khứ, tôi muốn nói như sau:

Bất kể bạn đang xử lý các phản ứng, thông báo, kế hoạch hợp pháp và 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 tầm 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, đưa khách hàng trở lại ASAP trực tuyến ở trạng thái ban đầu của họ, điều này đã được đề cập đến trong các phản hồi.

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

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

Có lẽ họ cần phải thuê một SA chuyên dụng tại chỗ. Có lẽ họ cần một người bảo vệ. 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ó lẽ năng lực cốt lõi của họ không thuộc về quản lý máy chủ và điều đó không có ý nghĩa đối với họ để cố gắng phát triển điều đó. Hoặc, có thể họ là một tổ chức khá kỹ thuật và đã có thể đưa ra quyết định tuyển dụng phù hợp và mang lại một đội ngũ chuyên trách toàn thời gian.


28
2018-01-04 02:21



Vâng, nó phụ thuộc, chúng tôi biết. Nói rằng điều đó không thực sự giúp ích gì nhiều. - DOK


Sau khi làm việc và xem xét máy chủ, chúng tôi đã tìm ra được vấn đề. May mắn thay, các tệp vi phạm đã được tải lên hệ thống vào ngày Chủ Nhật, khi văn phòng bị đóng và không có tệp nào được tạo, ngoài các tệp nhật ký và tệp bộ nhớ cache. Với một lệnh shell đơn giản để tìm ra những tập tin đã được tạo ra 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 / images / 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ỳ tên ngốc nào để tải lên hình ảnh không 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à cố định 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 phải là 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 tôi trên đường đi làm. Cảm ơn tất cả các bạn đã giúp đỡ.

Để tham khảo về bất kỳ ai truy cập bài đăng này trong tương lai. tôi sẽ không phải khuyên bạn nên kéo phích cắm điện.


24
2017-12-05 12:52



Grant, tôi rất vui vì nó hoạt động rất tốt cho bạn. Đó là thứ gì đó nhỏ bé - ít nghiêm trọng hơn nhiều người trong chúng ta nghĩ. Cuộc thảo luận này đã dạy tôi một bài học về giao tiếp, đưa ra nhiều lời khuyên và thực phẩm tốt cho suy nghĩ về những phản ứng không đứng đắn. - Aleksandr Levchuk
Cảm ơn bạn đã quay lại và cho chúng tôi biết cách bạn tiếp tục - như bạn có thể thấy, câu hỏi của bạn đã tạo ra khá nhiều cuộc thảo luận. Tôi vui vì bạn dường như không bị ảnh hưởng nặng nề bởi điều này và giải pháp của bạn khá đơn giản. - Rob Moir
Đây phải là nhận xét (hoặc được bao gồm dưới dạng văn bản trong câu hỏi của bạn), không phải là câu trả lời cho câu hỏi của bạn. - Techboy
@ Techboy: Có vẻ như anh ấy chưa liên kết tài khoản SO và SF của anh ấy, vì vậy anh ấy không thể chỉnh sửa câu hỏi của anh ấy. @Grant: Bạn có thể liên kết các tài khoản của mình thông qua bảng điều khiển "Tài khoản" trên trang người dùng của bạn. - Hippo
mà không có cấu hình cơ sở, làm sao bạn biết không chạy rootkit? - The Unix Janitor


Tôi có ít đóng góp cho các câu trả lời kỹ thuật rộng rãi nhưng cũng xin lưu ý một số câu trả lời sau:

Hành động phi kỹ thuật:

  • Báo cáo sự việc nội bộ.
    Nếu bạn không có kế hoạch phản hồi sự cố đã có thể xuất hiện một 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 ảnh hưởng kinh doanh của một máy chủ bị xâm phạm.
    Các yêu cầu kinh doanh có thể vượt qua các 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 đang có máy chủ bị xâm nhập này ở nơi đầu tiên. ("Hãy để điều đó cho báo cáo sau hành động.")

  • Bao gồm một sự cố bảo mật không phải là một lựa chọn.

  • Báo cáo cho 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à một thứ cần được đưa vào kế hoạch phản ứng 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ố bảo mật cho cơ quan thực thi pháp luật địa phương, cơ quan điều tiết 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ế chỉ được thực hiện trong bộ phận CNTT. Mong đợi sự tham gia của ban quản lý và các bộ phận truyền thông pháp lý và doanh nghiệp (tiếp thị).
    Bạn có lẽ không nên mong đợi quá nhiều, internet là một nơi rộng lớn nơi biên giới có í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 các tội phạm kỹ thuật số và có thể mang tội đến công lý.


15
2017-09-11 06:50