Paranoid Sysadmin -vs- Phiên bản PHP lỗi thời

8

Làm thế nào một sysadmin hoang tưởng có thể tự tin cập nhật các phiên bản PHP ổn định mới nhất? (sửa lỗi bảo mật đã đến khá thường xuyên).

Đây là một máy chủ sản xuất, và vì vậy "phá vỡ mọi thứ" đang khiến anh chàng của tôi sợ chết. Thời gian chết để bảo trì không phải là vấn đề.

Cụ thể, chúng tôi đang chạy một Linux Linux gần đây, nhưng câu trả lời chung chung hoặc tổng quát hơn là hoàn toàn chấp nhận được.

Làm thế nào để bạn xử lý cập nhật bảo mật cho máy sản xuất? Chúng ta không biết gì về việc anh chàng này sợ đến mức chỉ sử dụng trình quản lý gói để "cập nhật"?

Có lời khuyên nào không?

php security upgrade

— kẻ hèn nhát vô danh
nguồn

2

bị hoang tưởng về BẤT CỨ php vá, gtk + wrapper, cửa sổ điều khiển cập nhật, vv là một IMHO tốt điều - đây là nhiều hơn chỉ là PHP đó là một miếng vá chung philosiphy see serverfault.com/questions/104665/... cho một cuộc thảo luận tốt về vá nói chung .

— Zypher

@Zypher Cảm ơn các liên kết. Tình hình ở đây không lý tưởng, nhưng chúng tôi đang làm việc theo hướng đó. Bằng chứng rõ ràng rằng mọi thứ cần phải nhanh lên và đến đó. =)

— kẻ hèn nhát vô danh

6

Tôi xử lý PHP giống như cách tôi xử lý mọi thứ khác: Trước tiên hãy nâng cấp môi trường phát triển (bản sao sản xuất VMWare), hồi quy kiểm tra địa ngục, sau đó quảng bá nó lên sản xuất bằng các mẫu triển khai tương tự mà chúng tôi đã sử dụng cho máy chủ VMWare. (Nếu bạn đang sử dụng trình quản lý gói để thực hiện nâng cấp, bạn sẽ sử dụng các gói tương tự).

Vì một lớp cách nhiệt bổ sung, môi trường sản xuất của chúng tôi bao gồm các máy chủ dự phòng được ghép nối và một máy chủ được đưa ra khỏi vòng quay sản xuất để nâng cấp, sau đó kiểm tra kỹ trước khi chúng tôi chuyển sang máy chủ đó để nâng cấp đối tác.

Là một cập nhật bảo mật quy tắc chung được áp dụng ngay khi thực tế và các cập nhật sửa lỗi không bảo mật / không quan trọng được áp dụng hàng quý để giảm thiểu thời gian chết.

— voretaq7
nguồn

Có sự dư thừa là rất tốt. Chúng tôi đang chuyển rất nhiều thứ sang ảo, điều này sẽ giúp việc này dễ dàng hơn rất nhiều. Chỉ cần chắc chắn rằng những giả định của tôi không điên rồ. =) Cảm ơn câu trả lời của bạn.

— kẻ hèn nhát vô danh

Máy ảo là một phát minh tuyệt vời - Về lý thuyết, các hệ thống sản xuất dự phòng đều có thể là máy ảo, tiết kiệm chi phí rất lớn nếu bạn trả tiền cho chính mình :) Các ưu điểm khác bao gồm khả năng chụp nhanh máy ảo của bạn trước khi bạn nâng cấp gần quay trở lại.

— voretaq7

4

PHP nằm trong danh sách hàng đầu của tôi về những điều cần cập nhật lên phiên bản hiện tại. Tôi tin tưởng nó ít hơn hầu hết mọi thứ.

Cuối cùng, đặt cược tốt nhất của bạn là xem xét mọi thay đổi từ phiên bản hiện tại của bạn đến mới nhất và cân nhắc rủi ro một cách hữu hình.

Nếu bạn đang nói nâng cấp các phiên bản nhỏ, chẳng hạn như 5.3.1 lên 5.3.2, tôi sẽ không lo lắng quá nhiều.

Nếu bạn đang nâng cấp từ 5.2.x lên 5.3.x, bạn có thể sẽ giới thiệu một số vấn đề tương thích.

Nếu bạn đang sử dụng các gói hệ thống, thông thường các bản phân phối sẽ không giới thiệu các bản nâng cấp sẽ phá vỡ hiệu suất hiện có. RHEL và CentOS vá các phiên bản cũ để sửa lỗi cho đến khi bản phát hành phân phối chính được phát hành. Việc kiểm tra cho bạn, thường, làm giảm rủi ro. Tôi hy vọng doanh nghiệp SuSE sẽ tương tự.

Đối với đường dẫn nâng cấp, cách tốt nhất là xây dựng máy chủ thử nghiệm và kiểm tra ứng dụng so với phiên bản mới nhất trước khi nâng cấp sản xuất.

— Warner
nguồn

Tôi đã nghĩ rằng các hệ thống quản lý gói được sử dụng các gói không được kiểm duyệt, nói chung là miễn phí, miễn là hộp của bạn không bị tàn phá khủng khiếp ở giữa. Rất vui được khẳng định điều đó. Cảm ơn.

— kẻ hèn nhát vô danh

Quản lý gói có thể rất hay bị bỏ lỡ - nó thường hoạt động tốt, nhưng tôi đã có những cú va chạm ở cấp độ trong gói ngay cả khi nhà cung cấp thượng nguồn nói rằng không có thay đổi nào về tính tương thích được đưa ra. Chắc chắn là một tình huống thử nghiệm trước khi bạn triển khai theo kinh nghiệm của tôi.

— voretaq7

Bạn chỉ sử dụng các gói hệ thống hay bạn có phần mềm do bạn tự biên dịch không?

— Warner

1

Một câu trả lời khác, ít được đánh giá cao là xây dựng một danh sách trắng các url và tính năng được phép. Trong Apache, bạn có thể làm điều này bằng cách kết hợp các tính năng proxy và viết lại.

Về cơ bản, bạn thực hiện hai cài đặt, một cài đặt có cấu hình bị loại bỏ: Proxy, viết lại và không thực thi mã; v.v ... Mọi URL "được phép" (có tham số, v.v.) sẽ được ủy quyền cho lần cài đặt thứ hai.

Sau đó, thêm chính bạn vào danh sách nhà phát triển của PHP và theo dõi cẩn thận các ghi chú phát hành. Bất cứ khi nào bạn thấy một cái gì đó trông giống như nó có thể là một lỗ hổng bảo mật, bạn xây dựng một shim trong cài đặt đầu tiên để phát hiện loại lỗi này và gửi lỗi cho người dùng.

Trong một thiết lập như thế này, bạn sẽ muốn chuyển hướng POST sang bộ lọc (nếu bạn cần POST hoàn toàn; một số trang web chỉ hoạt động tốt bằng cách chỉ cho phép POST từ một số địa chỉ IP!) Có thể tìm kiếm các nguồn được phép và trước xác nhận mọi thứ

Một danh sách trắng như vậy rất tốn thời gian để thiết lập, nhưng đối với các ứng dụng quan trọng cần chạy lâu hơn tuổi thọ ổn định của PHP (dường như chỉ vài năm), đây có thể là một cách tuyệt vời để tận dụng số lượng lớn PHP các ứng dụng mà không nhận được lỗ hổng của họ là tốt.

— Geocar
nguồn

1

Ngoài các cách trên, bạn có thể kích hoạt quay lại gói chỉ trong trường hợp.

Sau đó, nếu một cái gì đó phá vỡ sản xuất mà bạn hoàn toàn chắc chắn đã hoạt động tốt trong quá trình phát triển , ít nhất bạn có thể hoàn tác thay đổi nhanh chóng trước khi khắc phục sự cố.

Xem gói Rollback YUM để biết ví dụ trong Yum. Tôi chắc chắn các hệ thống quản lý gói khác có tương tự.

Tôi biết đó là vành đai và niềng răng và tôi đồng ý với Warner với các bản phát hành điểm. Thay đổi nhỏ không nên phá vỡ bất cứ điều gì. Cá nhân tôi không có bất kỳ vấn đề nào trong việc nâng cấp PHP, nhưng luôn an toàn hơn là xin lỗi.

— Richard Holloway
nguồn