Dựa trên một bài đăng tôi đã viết từ rất lâu trước đây khi tôi vẫn có thể bị làm phiền với blog.
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 mẩu 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 nhưng cuối cùng làm như vậy sẽ giúp mọi việc tốt hơn. 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à:
- Đ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. Cho 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.
- 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?
- 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.
- Nếu hệ thống lưu giữ dữ liệu cá nhân của bất kỳ ai, hãy tiết lộ đầ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. 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 tôi sợ bạn sẽ phải giải quyết nó.
Vẫn còn do dự để thực hiện bước cuối cùng này? Tôi hiểu, tôi làm. Nhưng hãy nhìn nó như thế này:
Ở một số nơi bạn có thể có một yêu cầu pháp lý để thông báo cho chính quyền và / hoặc nạn nhân của loại vi phạm quyền riêng tư này. 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 đủ:
- 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 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; Tôi đang liên kết để cảnh báo bạn về hậu quả của việc không tuân theo bước đầu tiên này.
- 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.
- 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.
- Đả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. (vd đã được thực hiện ở nơi khác).
- 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".
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).
- 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.
- 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.
- Đừng cố đư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 đủ. Việc xây dựng một hộp mới sẽ nhanh hơn rất nhiều 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 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.
- 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.
- 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à khả năng 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ụ:
- 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?
- 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.
- 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 ).
- 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.
- 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ó.
- 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.
- 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?
- 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ế.
- 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.
- 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.
- 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.
- 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. (chỉnh sửa, trên mỗi XTZ)
... 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.
