Gần đây (nhưng đây cũng là một câu hỏi thường xuyên) chúng tôi đã thấy 3 chủ đề thú vị về hack và bảo mật:

Làm thế nào để tôi đối phó với một máy chủ bị xâm nhập? .
Tìm cách máy chủ bị hack đã bị hack
Câu hỏi về quyền truy cập tệp

Cái cuối cùng không liên quan trực tiếp, nhưng nó nhấn mạnh việc dễ dàng gây rối với quản trị máy chủ web.

Vì có một số điều có thể được thực hiện, trước khi có điều gì đó tồi tệ xảy ra, tôi muốn có đề xuất của bạn về mặt thực tiễn tốt để hạn chế tác dụng ngược của một cuộc tấn công và cách phản ứng trong trường hợp đáng buồn sẽ xảy ra.

Đây không chỉ là vấn đề bảo mật máy chủ và mã mà còn là các biện pháp kiểm toán, ghi nhật ký và truy cập.

Bạn có bất kỳ danh sách thực hành tốt nào hay bạn muốn dựa vào phần mềm hoặc các chuyên gia liên tục phân tích (các) máy chủ web của bạn (hoặc không có gì cả)?

Nếu có, bạn có thể chia sẻ danh sách của bạn và ý tưởng / ý kiến ​​của bạn?

CẬP NHẬT

Tôi đã nhận được một số phản hồi tốt và thú vị.

Tôi muốn có một danh sách đơn giản, do đó có thể có ích cho các quản trị viên an ninh CNTT mà còn cho các trang web người quản gia bậc thầy.

Ngay cả khi mọi người đưa ra câu trả lời đúng và chính xác, hiện tại tôi thích câu trả lời của Robert vì nó đơn giản, rõ ràng và súc tích nhất và là một trong những sysadmin1138 vì nó hoàn chỉnh và chính xác nhất.

Nhưng không ai xem xét quan điểm và nhận thức của người dùng, tôi nghĩ đó là lần đầu tiên phải được xem xét.

Người dùng sẽ nghĩ gì khi truy cập trang web bị tấn công của tôi, nhiều hơn nữa nếu bạn sở hữu dữ liệu hợp lý về họ. Đây không chỉ là vấn đề lưu trữ dữ liệu ở đâu, mà là làm thế nào để làm dịu người dùng tức giận.

Điều gì về dữ liệu, phương tiện truyền thông, chính quyền và đối thủ cạnh tranh?

Có hai lĩnh vực lớn để tập trung vào:

1. Làm cho nó khó khăn để có được trong.
2. Tạo các chính sách và thủ tục để xử lý một cách bình tĩnh và hiệu quả sự kiện ai đó đi vào điểm 1.

Làm cho nó khó vào

Đây là một chủ đề rất phức tạp và rất nhiều chủ đề tập trung vào việc đảm bảo bạn có đủ thông tin để tìm hiểu WTF đã xảy ra sau thực tế. Các gạch đầu dòng trừu tượng cho đơn giản:

• Giữ nhật ký (xem thêm, Quản lý sự kiện thông tin bảo mật)
  • Bất kỳ nỗ lực ủy quyền nào, cả thành công và thất bại, tốt nhất là vẫn còn nguyên thông tin nguồn.
  • Nhật ký truy cập tường lửa (điều này có thể phải bao gồm tường lửa trên mỗi máy chủ, nếu đang sử dụng).
  • Nhật ký truy cập máy chủ
  • Nhật ký xác thực máy chủ cơ sở dữ liệu
  • Nhật ký sử dụng dành riêng cho ứng dụng
  • Nếu có thể, SIEM có thể đưa ra các cảnh báo về các mẫu đáng ngờ.
• Thực thi kiểm soát truy cập thích hợp
  • Đảm bảo quyền được đặt chính xác ở mọi nơi và tránh 'quyền lười biếng' ("oh chỉ cho mọi người đọc") nếu có thể.
  • Kiểm tra định kỳ các ACL để đảm bảo rằng các quy trình thực sự được tuân thủ và các bước khắc phục sự cố tạm thời ("cho mọi người đọc, xem nó có hoạt động không") đã được xóa chính xác sau khi khắc phục sự cố xong.
  • Tất cả các quy tắc thông qua tường lửa cần phải được chứng minh và kiểm toán định kỳ.
  • Kiểm soát truy cập máy chủ web cũng cần phải được kiểm tra, cả ACL máy chủ web và hệ thống tệp.
• Thực thi quản lý thay đổi
  • Mọi thay đổi đối với môi trường bảo mật cần được theo dõi tập trung và xem xét bởi nhiều người.
  • Các bản vá nên được bao gồm trong quá trình này.
  • Việc xây dựng hệ điều hành chung (mẫu) sẽ đơn giản hóa môi trường và giúp thay đổi dễ dàng hơn để theo dõi và áp dụng.
• Vô hiệu hóa tài khoản khách.
• Đảm bảo tất cả mật khẩu không được đặt thành mặc định.
  • Các ứng dụng có sẵn có thể thiết lập người dùng với mật khẩu được xác định trước. Thay đổi chúng.
  • Rất nhiều thiết bị CNTT xuất xưởng với cặp người dùng / mật khẩu rất nổi tiếng. Thay đổi những thứ đó, ngay cả khi bạn đăng nhập vào điều đó chỉ một lần một năm.
• Thực hành ít đặc quyền nhất. Cung cấp cho người dùng quyền truy cập mà họ thực sự cần.
  • Đối với người dùng Admin, thiết lập hai tài khoản là khôn ngoan. Một tài khoản thông thường được sử dụng cho email và các nhiệm vụ văn phòng khác, và một tài khoản thứ hai cho công việc riêng tư nâng cao. VM làm cho điều này dễ sống hơn.
  • KHÔNG khuyến khích sử dụng thường xuyên tài khoản quản trị viên gốc / tài khoản gốc, thật khó để theo dõi ai đang làm gì khi nào.

Tạo các chính sách và thủ tục để xử lý một cách bình tĩnh và hiệu quả sự kiện ai đó tham gia

Một chính sách sự kiện bảo mật là phải có cho tất cả các tổ chức. Nó làm giảm đáng kể giai đoạn phản ứng "chạy xung quanh với đầu của chúng tôi", vì mọi người có xu hướng trở nên bất hợp lý khi phải đối mặt với các sự kiện như thế này. Xâm nhập là những việc lớn, đáng sợ. Xấu hổ khi phải chịu một sự xâm nhập có thể khiến các hệ thống cấp độ khác bắt đầu phản ứng không chính xác.

Tất cả các cấp của tổ chức cần phải nhận thức được các chính sách. Sự cố càng lớn, quản lý cấp trên càng có nhiều khả năng sẽ tham gia theo một cách nào đó và việc đặt ra các quy trình xử lý mọi việc sẽ hỗ trợ rất nhiều trong việc chống lại "sự giúp đỡ" từ trên cao. Nó cũng đưa ra một mức độ bao phủ cho các kỹ thuật viên trực tiếp tham gia ứng phó sự cố, dưới hình thức thủ tục quản lý cấp trung để giao tiếp với phần còn lại của tổ chức.

Lý tưởng nhất là chính sách Khôi phục thảm họa của bạn đã xác định thời gian một số dịch vụ có thể không khả dụng trước khi chính sách DR khởi động. Điều này sẽ giúp ứng phó sự cố, vì các loại sự kiện này là thảm họa. Nếu sự kiện thuộc loại mà cửa sổ khôi phục sẽ KHÔNG được đáp ứng (ví dụ: trang DR dự phòng nóng nhận được nguồn cấp dữ liệu thay đổi theo thời gian thực và kẻ xâm nhập đã xóa một loạt dữ liệu được sao chép vào trang DR trước khi chúng Do đó, các quy trình phục hồi lạnh sẽ cần được sử dụng) sau đó quản lý cấp trên sẽ cần tham gia vào các cuộc đàm phán đánh giá rủi ro.

Một số thành phần của bất kỳ kế hoạch ứng phó sự cố:

• Xác định các hệ thống bị xâm nhập và dữ liệu tiếp xúc.
• Xác định sớm xem có bằng chứng pháp lý hay không cần được giữ lại để truy tố cuối cùng.
  • Nếu bằng chứng được giữ lại, đừng chạm vào bất cứ điều gì về hệ thống đó trừ khi hoàn toàn bắt buộc . Đừng đăng nhập vào nó. Không chọn lọc thông qua các tệp nhật ký. Làm. Không phải. Chạm.
  • Nếu bằng chứng được giữ lại, các hệ thống bị xâm nhập cần được để lại trực tuyến nhưng bị ngắt kết nối cho đến khi một chuyên gia pháp y máy tính được chứng nhận có thể mổ xẻ hệ thống theo cách tương thích với các quy tắc xử lý bằng chứng.
    • Tắt nguồn hệ thống bị xâm nhập có thể làm hỏng dữ liệu.
    • Nếu hệ thống lưu trữ của bạn cho phép điều này (thiết bị SAN rời rạc) chụp nhanh các LUN bị ảnh hưởng trước khi ngắt kết nối và gắn cờ chúng ở chế độ chỉ đọc.
  • Quy tắc xử lý bằng chứng rất phức tạp và thật dễ dàng để làm hỏng việc. Đừng làm điều đó trừ khi bạn được đào tạo về họ. Hầu hết các SysAdmins thông thường KHÔNG có loại đào tạo này.
  • Nếu bằng chứng được giữ lại, hãy coi việc mất dịch vụ là thảm họa mất phần cứng và bắt đầu các quy trình phục hồi với phần cứng mới.
• Quy tắc đặt trước cho những loại thảm họa đòi hỏi những loại thông báo. Luật pháp và quy định khác nhau tùy theo địa phương.
  • Các quy tắc liên quan đến 'tiếp xúc' và 'thỏa hiệp đã được chứng minh' có khác nhau.
  • Quy tắc thông báo sẽ yêu cầu bộ phận Truyền thông tham gia.
  • Nếu thông báo yêu cầu đủ lớn, quản lý cấp cao nhất sẽ phải tham gia.
• Sử dụng dữ liệu DR, xác định thời gian "WTF vừa xảy ra" có thể được sử dụng trước khi đưa dịch vụ trở lại tuyến trở thành ưu tiên cao hơn.
  • Thời gian phục hồi dịch vụ có thể yêu cầu công việc tìm ra những gì đã xảy ra để được phục tùng. Nếu vậy, hãy lấy hình ảnh ổ đĩa của thiết bị bị ảnh hưởng để phân tích sau khi các dịch vụ được khôi phục (đây không phải là bản sao bằng chứng, nó dành cho các kỹ thuật viên kỹ sư đảo ngược).
  • Lập kế hoạch cho các nhiệm vụ phục hồi dịch vụ của bạn để bao gồm việc xây dựng lại hoàn toàn hệ thống bị ảnh hưởng, không chỉ dọn dẹp mớ hỗn độn.
  • Trong một số trường hợp, thời gian phục hồi dịch vụ đủ chặt để hình ảnh đĩa cần được chụp ngay sau khi xác định thỏa hiệp đã xảy ra và bằng chứng pháp lý không được giữ lại. Khi dịch vụ được xây dựng lại, công việc tìm hiểu những gì đã xảy ra có thể bắt đầu.
• Chọn lọc thông qua các logfiles để biết thông tin liên quan đến cách kẻ tấn công xâm nhập và những gì chúng có thể đã thực hiện một lần vào.
• Chọn lọc các tập tin đã thay đổi để biết thông tin liên quan đến cách họ tham gia và những gì họ đã làm khi họ vào.
• Lọc qua nhật ký tường lửa để biết thông tin về nơi chúng đến, nơi chúng có thể đã gửi dữ liệu đến và số lượng có thể đã được gửi.

Có chính sách và thủ tục trước khi thỏa hiệp, và được biết đến bởi những người sẽ thực hiện chúng trong trường hợp thỏa hiệp, là điều chỉ cần làm. Nó cung cấp cho mọi người một khung phản hồi tại thời điểm mọi người sẽ không suy nghĩ thẳng. Quản lý cấp trên có thể sấm sét và bùng nổ về các vụ kiện và cáo buộc hình sự, nhưng thực sự mang lại một vụ án là một quá trình tốn kém và biết rằng trước đó có thể giúp làm giảm cơn giận dữ.

Tôi cũng lưu ý rằng những loại sự kiện này cần phải được đưa vào kế hoạch ứng phó thảm họa chung. Một sự thỏa hiệp sẽ rất có khả năng kích hoạt chính sách phản hồi 'phần cứng bị mất' và cũng có khả năng kích hoạt phản hồi 'mất dữ liệu'. Biết thời gian phục hồi dịch vụ của bạn giúp đặt kỳ vọng nhóm phản hồi bảo mật có thể mất bao lâu để đổ vào hệ thống bị xâm nhập thực tế (nếu không giữ bằng chứng pháp lý) trước khi cần phục hồi dịch vụ.

Làm thế nào đúng thủ tục trợ giúp có thể giúp đỡ

Chúng ta cần xem xét cách khách hàng giải quyết ở đây (điều này áp dụng cho cả khách hàng nội bộ và bên ngoài liên hệ với bộ phận trợ giúp).

Trước hết, giao tiếp là quan trọng ; Người dùng sẽ tức giận về sự gián đoạn đối với doanh nghiệp và cũng có thể lo ngại về mức độ / hậu quả của bất kỳ vi phạm thông tin nào có thể xảy ra như một phần của sự xâm nhập. Thông báo cho những người này sẽ giúp kiểm soát sự tức giận và lo lắng của họ, cả hai từ quan điểm rằng chia sẻ kiến ​​thức là tốt, và từ quan điểm có lẽ hơi ít rõ ràng rằng một điều họ sẽ cần nghe là bạn đang kiểm soát tình hình.

Bộ phận trợ giúp và quản lý CNTT cần đóng vai trò là "chiếc ô" vào thời điểm này, che chở cho những người làm công việc để xác định mức độ xâm nhập và khôi phục dịch vụ khỏi vô số điều tra làm gián đoạn công việc đó.

1. Hãy thử và đăng các cập nhật thực tế cho khách hàng và làm việc với họ để xác định mức độ khẩn cấp để đưa dịch vụ trở lại trực tuyến. Nhận thức được nhu cầu của khách hàng rất quan trọng, nhưng đồng thời không cho phép họ đưa ra lịch trình không khả thi cho bạn.
2. Hãy chắc chắn rằng nhóm trợ giúp của bạn biết những thông tin nào có thể và không thể được tiết lộ, và họ không nên khuyến khích những tin đồn và suy đoán (và tuyệt đối không nên thảo luận bất cứ điều gì có thể làm ảnh hưởng đến bất kỳ hành động pháp lý nào mà tổ chức của bạn có thể thực hiện hoặc đối mặt).
3. Một điều tích cực mà bộ phận trợ giúp nên làm là ghi lại tất cả các cuộc gọi liên quan đến sự xâm nhập - điều này có thể giúp đo lường sự gián đoạn gây ra bởi cả chính sự xâm nhập và các quá trình tiếp theo để đối phó với nó. Đặt cả thời gian và chi phí tài chính cho sự xâm nhập và giảm thiểu có thể rất hữu ích cả với việc tinh chỉnh các chiến lược trong tương lai, và rõ ràng có thể chứng minh hữu ích với bất kỳ hành động pháp lý nào. Sự cố ITIL so với ghi sự cố có thể giúp ích ở đây - cả sự xâm nhập và giảm thiểu có thể được ghi lại thành các sự cố riêng biệt và mỗi người gọi được theo dõi là sự cố của một hoặc cả hai vấn đề.

Các tiêu chuẩn triển khai có thể giúp như thế nào

Việc triển khai một mẫu đã đặt (hoặc ít nhất là một danh sách kiểm tra) cũng giúp ích, cùng với việc thực hành kiểm soát / quản lý thay đổi đối với mọi tùy chỉnh / nâng cấp cho mẫu triển khai của bạn. Bạn có thể có một số mẫu để tính toán cho các máy chủ thực hiện các công việc khác nhau (ví dụ: mẫu máy chủ thư, mẫu máy chủ web, v.v.).

Một mẫu nên hoạt động cho cả HĐH và ứng dụng, và bao gồm không chỉ bảo mật mà tất cả các cài đặt bạn sử dụng, và lý tưởng nhất là được viết kịch bản (ví dụ: mẫu) thay vì áp dụng thủ công (ví dụ: danh sách kiểm tra) để loại bỏ lỗi của con người nhiều nhất có thể.

Điều này giúp theo một số cách:

• Cho phép bạn khôi phục / xây dựng lại nhanh hơn trong trường hợp xảy ra sự xâm nhập (lưu ý rằng bạn không nên triển khai từ mẫu này 'như hiện tại' vì bạn biết nó dễ bị tấn công, nhưng nó cho phép bạn quay lại "cấu hình tốt được biết đến cuối cùng của bạn " Cần phải trải qua quá trình tăng cường hơn nữa trước khi triển khai trực tiếp ... và đừng quên cập nhật mẫu triển khai của bạn một khi bạn chắc chắn rằng nó đã bị khóa đúng cách)
• Cung cấp cho bạn một "đường cơ sở" để so sánh một máy chủ bị hack với
• Giảm các lỗi không cần thiết có thể dẫn đến xâm nhập ở nơi đầu tiên
• Giúp quản lý thay đổi và vá lỗi vì khi rõ ràng bạn cần một bản vá / nâng cấp hoặc thay đổi thủ tục để bảo mật (hoặc bất kỳ lý do nào khác cho vấn đề đó), giúp dễ dàng xem hệ thống nào cần thay đổi, giúp viết bài kiểm tra dễ dàng hơn để xem thay đổi được áp dụng chính xác, v.v.).
• Nếu mọi thứ đều nhất quán nhất có thể và hợp lý, nó sẽ giúp làm cho những sự kiện bất thường và đáng ngờ tiếp tục diễn ra.

Đối với hầu hết các máy chủ của chúng tôi, chúng tôi dựa vào tường lửa máy chủ và mạng, phần mềm chống vi-rút / phần mềm gián điệp, IDS mạng và IDS máy chủ cho phần lớn phòng ngừa của chúng tôi. Điều này cùng với tất cả các hướng dẫn chung như quyền riêng tư tối thiểu, gỡ cài đặt các chương trình không cần thiết, cập nhật, v.v. Từ đó chúng tôi sử dụng các sản phẩm như Nagios, Cacti và giải pháp SIEM cho các lớp cơ sở khác nhau và thông báo về các sự kiện xảy ra. HIDS của chúng tôi (OSSEC) cũng thực hiện nhiều thao tác ghi nhật ký kiểu SIEM. Về cơ bản, chúng tôi cố gắng thực hiện các công cụ chặn càng nhiều càng tốt, nhưng sau đó đăng nhập tập trung để nếu điều gì đó xảy ra, chúng tôi có thể phân tích và tương quan nó.

Những gì bạn thực sự muốn có thể rơi vào 3 lĩnh vực cơ bản:

1. Cấu hình hệ thống tiêu chuẩn
2. Giám sát hệ thống / ứng dụng
3. Ứng phó sự cố

Nếu bạn có sẵn bất kỳ thông tin nào (đảm bảo | bảo mật), thì bạn chắc chắn nên nói chuyện với họ. Mặc dù Ứng phó sự cố thường là nội dung duy nhất của văn phòng nói trên, phần còn lại phải là nỗ lực phát triển chung giữa tất cả các bên bị ảnh hưởng.

Có nguy cơ tự làm phiền mình, câu trả lời cho một câu hỏi liên quan sẽ lập chỉ mục rất nhiều tài nguyên hữu ích cho bạn: Mẹo để bảo mật máy chủ LAMP.

Tốt nhất, bạn nên có số lượng HĐH được hỗ trợ nhỏ nhất và xây dựng mỗi hệ điều hành bằng hình ảnh cơ sở. Bạn chỉ nên đi chệch khỏi cơ sở nhiều nhất có thể để cung cấp bất kỳ dịch vụ nào mà máy chủ cung cấp. Các sai lệch phải được ghi lại hoặc có thể được yêu cầu nếu bạn phải đáp ứng PCI / HIPAA / vv. hoặc tuân thủ khác. Sử dụng các hệ thống quản lý triển khai và cấu hình có thể giúp ích rất nhiều về mặt này. Các chi tiết cụ thể sẽ phụ thuộc rất nhiều vào HĐH của bạn, cobbler / Puppet / Altiris / DeployStudio / SCCM, v.v.

Bạn chắc chắn nên thực hiện một số loại xem xét nhật ký thường xuyên. Đưa ra tùy chọn SIEM có thể rất hữu ích, nhưng chúng cũng có nhược điểm là đắt tiền cả về giá mua và chi phí xây dựng. Kiểm tra câu hỏi này từ trang web IT Security SE để biết một số nhận xét về phân tích nhật ký: Làm thế nào để bạn xử lý phân tích nhật ký? Nếu điều này vẫn còn quá nặng, thậm chí các công cụ phổ biến như LogWatch có thể cung cấp một số bối cảnh tốt cho những gì đang diễn ra. Mặc dù vậy, phần quan trọng chỉ là dành thời gian để xem xét các bản ghi. Điều này sẽ giúp bạn làm quen với những gì cấu thành hành vi bình thường, để bạn có thể nhận ra sự bất thường.

Ngoài việc xem xét nhật ký, việc theo dõi trạng thái của máy chủ cũng rất quan trọng. Biết khi nào thay đổi xảy ra, cho dù có kế hoạch hay không, là rất quan trọng. Việc sử dụng một công cụ giám sát cục bộ như Tripwire có thể cảnh báo cho quản trị viên về những thay đổi. Thật không may, giống như SIEM và IDSes có nhược điểm là tốn kém để điều chỉnh và / hoặc mua. Hơn nữa, nếu không điều chỉnh tốt, ngưỡng cảnh báo của bạn sẽ cao đến mức mọi thông điệp tốt sẽ bị mất trong tiếng ồn và trở nên vô dụng.

Một hợp thông tin và tổ chức sự kiện an ninh quản lý chính sách (SIEM) tại chỗ sẽ đi một cách dài để làm cho cuộc sống an ninh của bạn dễ dàng hơn.

Tôi không phải là một chuyên gia bảo mật, vì vậy tôi chủ yếu trì hoãn với họ; nhưng bắt đầu với Hiệu trưởng tối thiểu hầu như luôn luôn làm cho công việc của họ dễ dàng hơn đáng kể. Áp dụng điều này giống như một cứu cánh hoạt động tốt cho nhiều khía cạnh của bảo mật: quyền truy cập tệp, người dùng thời gian chạy, quy tắc tường lửa, vv KISS cũng không bao giờ làm tổn thương.

Hầu hết các giải pháp được đề cập ở đây áp dụng ở cấp độ máy chủ và mạng nhưng chúng ta thường quên các ứng dụng web không an toàn. Các ứng dụng web là lỗ hổng bảo mật phổ biến nhất. Bằng cách ứng dụng web, kẻ tấn công có thể truy cập vào cơ sở dữ liệu hoặc máy chủ của bạn. Không có tường lửa, IDS, tường lửa có thể bảo vệ bạn chống lại những thứ đó. OWASP duy trì một danh sách 10 lỗ hổng nghiêm trọng nhất và cung cấp các bản sửa lỗi cho chúng.

http://www.scribed.com/doc/19982/OWASP-Web-Security-Guide