Mẹo để duyên dáng tiếp quản máy chủ sản xuất (UNIX)

Sau nhiều tháng bị lãng quên, ngọn lửa thư điện tử và cuộc chiến quản lý của chúng tôi đã bị sa thải và trao lại "thông tin đăng nhập máy chủ" cho tôi. Thông tin đăng nhập như vậy bao gồm một mật khẩu gốc và không có gì khác: không thủ tục, không tài liệu, không mẹo, không có gì.

Câu hỏi của tôi là: giả sử anh ta bỏ lại boobytraps, làm thế nào để tôi duyên dáng tiếp quản các máy chủ với ít thời gian chết nhất có thể?

Đây là những thông tin chi tiết:

• một máy chủ sản xuất đặt trong một trang trại máy chủ ở tầng hầm; Máy chủ Ubuntu 9.x có lẽ, với các bản vá grsec (tin đồn tôi nghe thấy lần trước tôi đã hỏi quản trị viên)
• một máy chủ nội bộ có chứa tất cả tài liệu nội bộ, kho lưu trữ tệp, wiki, v.v ... Một lần nữa, máy chủ Ubuntu, vài năm tuổi.

Giả sử cả hai máy chủ đều được vá và cập nhật, vì vậy tôi không cố gắng hack theo cách của mình trừ khi có lý do chính đáng (nghĩa là có thể giải thích cho quản lý cấp trên).

Máy chủ sản xuất có một vài trang web được lưu trữ (apache-php-mysql tiêu chuẩn), máy chủ LDAP, bộ / máy chủ email ZIMBRA và theo như tôi có thể nói với một số máy trạm vmware đang chạy. Không biết chuyện gì đang xảy ra ở đó. Có lẽ một người là bậc thầy LDAP, nhưng đó là một phỏng đoán hoang dã.

Máy chủ nội bộ có wiki / cms nội bộ, nô lệ LDAP sao chép thông tin đăng nhập từ máy chủ sản xuất, thêm một số máy trạm vmware và sao lưu đang chạy.

Tôi chỉ có thể đi đến quản trị viên của trang trại máy chủ, chỉ vào máy chủ, nói với họ 'hãy sudotắt máy chủ đó đi', đăng nhập vào chế độ người dùng duy nhất và theo cách của tôi với nó. Tương tự cho máy chủ nội bộ. Tuy nhiên, điều đó có nghĩa là thời gian chết, quản lý cấp trên buồn bã, sysadmin cũ bắn lại tôi nói 'thấy không? bạn không thể làm công việc của tôi 'và những phiền toái khác, và quan trọng nhất là tôi sẽ phải mất một vài tuần thời gian không được trả lương.

Ở đầu kia của quang phổ, tôi chỉ có thể đăng nhập bằng root và inch qua máy chủ để cố gắng hiểu những gì đang xảy ra. Với tất cả các rủi ro gây ra những bất ngờ để lại.

Tôi đang tìm kiếm một giải pháp ở giữa: cố gắng giữ mọi thứ hoạt động như cũ, trong khi hiểu những gì đang xảy ra và làm thế nào, và quan trọng nhất là tránh kích hoạt bất kỳ bẫy booby nào bị bỏ lại .

Đề xuất của bạn là gì?

Cho đến nay tôi đã nghĩ đến việc 'thực hành' với máy chủ nội bộ, ngắt kết nối mạng, khởi động lại với một đĩa CD trực tiếp, bỏ hệ thống tệp gốc vào ổ đĩa USB và tải nó vào một máy ảo bị cô lập, bị ngắt kết nối để hiểu cách thức sysadmin trước đây suy nghĩ (a-la 'biết kẻ thù của bạn'). Có thể tạo ra kỳ tích tương tự với máy chủ sản xuất, nhưng một bãi chứa đầy đủ sẽ khiến ai đó chú ý. Có lẽ tôi chỉ có thể đăng nhập bằng root, kiểm tra crontab, kiểm tra .profile cho bất kỳ lệnh nào được đưa ra, kết xuất bản cuối cùng và bất cứ điều gì xuất hiện trong tâm trí.

Và đó là lý do tôi ở đây. Bất kỳ gợi ý, cho dù nhỏ, sẽ được đánh giá rất cao.

Thời gian cũng là một vấn đề: có thể có các tác nhân xảy ra trong một vài giờ, hoặc một vài tuần. Cảm thấy giống như một trong những bộ phim Hollywood tồi tệ, phải không?

Như những người khác đã nói rằng có vẻ như một tình huống lỏng lẻo.

(Bắt đầu từ cuối)

• Triển khai hoàn toàn mới

Tất nhiên, bạn không thể lấy máy chủ xuống và để trình cài đặt làm điều kỳ diệu.

Quy trình chung

• Nhận ngân sách cho máy chủ dự phòng (sao lưu như trong bộ lưu trữ dữ liệu)
• tạo ảnh chụp nhanh của dữ liệu và đặt chúng ở đó trước khi làm bất cứ điều gì
• Nhận được ký kết bởi quản lý!
• Tập hợp danh sách các yêu cầu (là wiki cần thiết, người đang sử dụng các phiên bản VMWare, ...)
  • Từ quản lý và
  • Từ người dùng
• Nhận được ký kết bởi quản lý!
• Tắt các dịch vụ chưa niêm yết trong một tuần (mỗi lần một dịch vụ - iptables có thể là bạn của bạn nếu bạn muốn tắt các dịch vụ bên ngoài nhưng nghi ngờ rằng nó vẫn có thể được sử dụng từ một ứng dụng trên cùng một máy chủ)
  • Không có phản ứng? -> sao lưu cuối cùng, xóa khỏi máy chủ
  • Phản ứng thế nào? -> Nói chuyện với người dùng dịch vụ
  • Thu thập các yêu cầu mới và Geet đã được quản lý ký kết!
• tất cả các dịch vụ chưa niêm yết trong một tháng và không có phản ứng? -> rm -rf $service(nghe có vẻ ồn ào nhưng ý tôi là ngừng hoạt động dịch vụ)
• lấy ngân sách cho một máy chủ dự phòng
• di chuyển một dịch vụ tại một thời điểm để phụ tùng
• được ký bởi quản lý!
• tắt máy chủ di chuyển (tắt nguồn)
• tìm hiểu thêm nhiều người đến la hét với bạn -> yay, bạn vừa tìm thấy thức ăn thừa
• thu thập các yêu cầu mới
• bắt đầu lại và di chuyển dịch vụ
• lặp lại 4 bước cuối cùng cho đến khi không có người đến sau bạn trong một tháng
• triển khai lại máy chủ (và quản lý đã ký tắt!)
• rửa sạch và lặp lại toàn bộ quá trình.
  • máy chủ được triển khai lại là phụ tùng mới của bạn

Bạn đã đạt được gì?

• Hàng tồn kho của tất cả các dịch vụ (cho bạn và quản lý)
• Tài liệu (sau tất cả những gì bạn cần viết ra một cái gì đó cho quản lý, tại sao không làm nó đúng cách và làm một cái gì đó cho bạn và quản lý)

Ở đó đã làm điều đó, nó không vui chút nào :(

Tại sao bạn cần phải có được ký bởi quản lý ?

• Làm cho các vấn đề hiển thị
• Hãy chắc chắn bạn sẽ không bị sa thải
• Cơ hội giải thích rủi ro
  • Sẽ không sao nếu họ không muốn bạn làm điều đó, nhưng sau tất cả, quyết định của họ là đưa ra sau khi họ có đủ đầu vào để đánh giá thời điểm đầu tư là xứng đáng.

Ồ, và trình bày kế hoạch tổng thể cho họ trước khi bạn bắt đầu , với một số ước tính về những gì sẽ xảy ra trong trường hợp xấu nhất và tốt nhất.

Nó sẽ tốn rất nhiều thời gian không phụ thuộc bố trí lại nếu bạn không có tài liệu hướng dẫn. Không cần phải nghĩ đến các cửa hậu, IMHO nếu bạn không có tài liệu di chuyển là cách duy nhất để đạt đến trạng thái lành mạnh sẽ mang lại giá trị cho công ty.

Bạn có lý do để tin rằng quản trị viên trước đó đã để lại một cái gì đó tồi tệ phía sau, hoặc bạn chỉ xem rất nhiều phim?

Tôi không yêu cầu phải lịch sự, tôi đang cố gắng để biết được mối đe dọa nào mà bạn nghĩ là có và khả năng xảy ra của nó. Nếu bạn nghĩ rằng khả năng thực sự rất cao là một số vấn đề gây rối nghiêm trọng có thể thực sự tồn tại thì tôi khuyên bạn nên xử lý nó như thể đó là một sự xâm nhập mạng thành công .

Trong mọi trường hợp, các sếp của bạn không muốn gián đoạn thời gian chết trong khi bạn giải quyết vấn đề này - thái độ của họ đối với thời gian ngừng hoạt động theo kế hoạch để dọn dẹp hệ thống so với thời gian ngừng hoạt động ngoài dự kiến ​​nếu có lỗi trong hệ thống (cho dù là lỗi thực sự hay là lỗi quản trị giả mạo) và nếu thái độ của họ là thực tế so với đánh giá của bạn về xác suất bạn thực sự sẽ gặp vấn đề ở đây.

Dù bạn làm gì, hãy xem xét những điều sau đây:

Chụp ảnh của hệ thống r ight ngay bây giờ . Trước khi bạn làm bất cứ điều gì khác. Trên thực tế, hãy lấy hai cái và đặt một cái sang một bên và không chạm vào nó một lần nữa cho đến khi bạn biết điều gì xảy ra với hệ thống của bạn, đây là bản ghi của bạn về hệ thống khi bạn tiếp quản nó.

Khôi phục bộ ảnh "thứ 2" cho một số máy ảo và sử dụng chúng để thăm dò những gì đang diễn ra. Nếu bạn lo lắng về những thứ được kích hoạt sau một ngày nhất định thì hãy đặt ngày chuyển tiếp một năm hoặc lâu hơn trong máy ảo.

Trước hết, nếu bạn định đầu tư thêm thời gian vào việc này, tôi khuyên bạn nên thực sự được trả tiền cho việc đó. Có vẻ như bạn đã chấp nhận trả tiền ngoài giờ như một sự thật, đánh giá từ lời nói của bạn - theo tôi, không nên như vậy, và đặc biệt không phải khi bạn gặp khó khăn như vậy vì lỗi của người khác (có thể là quản lý, sysadmin cũ hoặc có thể là sự kết hợp của cả hai).

Đưa máy chủ xuống và khởi động vào chế độ người dùng (init = / bin / sh hoặc 1 tại grub) để kiểm tra các lệnh chạy khi đăng nhập root. Thời gian chết là cần thiết ở đây, hãy nói rõ với ban quản lý rằng không có lựa chọn nào ngoài thời gian chết nếu họ muốn chắc chắn rằng họ sẽ giữ dữ liệu của họ.

Sau đó nhìn qua tất cả các cronjobs, ngay cả khi chúng trông hợp pháp. Cũng thực hiện sao lưu đầy đủ càng sớm càng tốt - ngay cả khi điều này có nghĩa là thời gian chết. Bạn có thể biến các bản sao lưu đầy đủ của mình thành các máy ảo đang chạy nếu muốn.

Sau đó, nếu bạn có thể chạm tay vào các máy chủ mới hoặc máy ảo có khả năng, tôi thực sự sẽ di chuyển các dịch vụ sang môi trường mới, sạch sẽ từng cái một. Bạn có thể làm điều này trong một số giai đoạn như để giảm thiểu thời gian chết nhận thức. Bạn sẽ có được kiến ​​thức chuyên sâu về các dịch vụ trong khi khôi phục sự tự tin của bạn đối với các hệ thống cơ sở.

Trong thời gian chờ đợi, bạn có thể kiểm tra rootkit bằng các công cụ như chkrootkit . Chạy nessus trên các máy chủ để tìm kiếm các lỗ hổng bảo mật mà quản trị viên cũ có thể sử dụng.

Chỉnh sửa: Tôi đoán tôi đã không giải quyết phần "duyên dáng" trong câu hỏi của bạn cũng như tôi có thể. Có thể bỏ qua bước đầu tiên (chuyển sang chế độ một người dùng để kiểm tra bẫy đăng nhập) - sysadmin cũ cung cấp cho bạn mật khẩu gốc và thiết lập thông tin đăng nhập để thực hiện một thao rm -rf /tác giống như tự xóa tất cả các tệp, vì vậy có có lẽ không có điểm nào để làm điều đó Theo phần sao lưu: hãy thử sử dụng một rsyncgiải pháp dựa trên để bạn có thể thực hiện hầu hết các bản sao lưu trực tuyến ban đầu và giảm thiểu thời gian chết.

Tôi sẽ đầu tư thời gian để tìm hiểu những ứng dụng chạy trên các máy chủ đó. Sau khi bạn biết những gì là bất cứ lúc nào bạn có thể cài đặt một máy chủ mới. Trong trường hợp bạn cảm thấy đó có thể là một cửa hậu, thì chỉ nên khởi động ở chế độ đơn hoặc có một số tường lửa ở giữa các máy chủ và Mạng bên ngoài.

Bạn đang bị hoang tưởng về bảo mật. Không cần phải mắc bệnh hoang tưởng. (b'cos bạn nói về bẫy booby). Đi qua danh sách phần mềm được cài đặt. Xem dịch vụ đang chạy là gì (netstat, ps, v.v.), xem các công việc định kỳ. Vô hiệu hóa tài khoản người dùng quản trị hệ thống trước đó mà không xóa tài khoản (dễ dàng thực hiện bằng cách trỏ vỏ vào nologin). Xem qua các tệp nhật ký. Tôi nghĩ với các bước này và từ kiến ​​thức của bạn về nhu cầu của công ty, từ đó bạn có thể đoán được việc sử dụng máy chủ, tôi nghĩ bạn sẽ có thể duy trì chúng mà không cần bất kỳ sự ủng hộ lớn nào.