Lưu trữ nhiều trang web - lỗ hổng quan trọng bị bỏ qua để bảo mật các trang web với nhau?

EDIT # 2 ngày 23 tháng 7 năm 2015: Tìm kiếm một câu trả lời mới xác định một mục bảo mật quan trọng bị bỏ lỡ trong thiết lập bên dưới hoặc có thể đưa ra lý do để tin rằng mọi thứ được bảo hiểm.

EDIT # 3 ngày 29 tháng 7 năm 2015: Tôi đặc biệt đang tìm kiếm một cấu hình sai có thể xảy ra như vô tình cho phép một cái gì đó có thể bị khai thác để tránh các hạn chế bảo mật hoặc tệ hơn là để mở một cái gì đó rộng mở.

Đây là thiết lập lưu trữ chia sẻ nhiều trang web và chúng tôi muốn sử dụng một cá thể Apache được chia sẻ (nghĩa là chạy dưới một tài khoản người dùng) nhưng với PHP / CGI chạy khi mỗi người dùng trang web đảm bảo không có trang web nào có thể truy cập các tệp của trang web khác và chúng tôi muốn đảm bảo không có gì bị bỏ lỡ (ví dụ: nếu chúng tôi không biết về phòng chống tấn công symlink).

Đây là những gì tôi có cho đến nay:

• Đảm bảo các tập lệnh PHP chạy dưới dạng tài khoản và nhóm người dùng Linux của trang web và bị bỏ tù (chẳng hạn như sử dụng CageFS) hoặc ít nhất là bị hạn chế sử dụng quyền của hệ thống tệp Linux.
• Sử dụng suexec để đảm bảo rằng các tập lệnh CGI không thể chạy như người dùng Apache.
• Nếu cần phía máy chủ bao gồm hỗ trợ (chẳng hạn như trong tệp shtml), hãy sử dụng Options IncludesNOEXECđể ngăn CGI không thể chạy khi bạn không mong đợi (mặc dù điều này không đáng lo ngại nếu sử dụng suexec).
• Có bảo vệ tấn công symlink tại chỗ để tin tặc không thể lừa Apache phục vụ các tệp của trang web khác dưới dạng văn bản gốc và tiết lộ thông tin có thể khai thác như mật khẩu DB.
• Định cấu hình AllowOverride/ AllowOverrideListchỉ cho phép bất kỳ chỉ thị nào mà tin tặc không thể khai thác. Tôi nghĩ rằng điều này ít quan tâm hơn nếu các mục trên được thực hiện đúng.

Tôi sẽ đi với MPM ITK nếu nó không quá chậm và không chạy bằng root, nhưng chúng tôi đặc biệt muốn sử dụng một Apache được chia sẻ nhưng đảm bảo nó được thực hiện an toàn.

Tôi đã tìm thấy http://httpd.apache.org/docs/2.4/misc/security_tips.html , nhưng nó không toàn diện về chủ đề này.

Nếu nó hữu ích để biết, chúng tôi dự định sử dụng CloudLinux với CageFS và mod_lsapi.

Có bất cứ điều gì khác để đảm bảo làm hoặc biết về?

EDIT ngày 20 tháng 7 năm 2015: Mọi người đã gửi một số giải pháp thay thế tốt có giá trị nói chung, nhưng xin lưu ý rằng câu hỏi này chỉ nhắm mục tiêu bảo mật cho thiết lập Apache được chia sẻ. Cụ thể là có một cái gì đó không được đề cập ở trên có thể cho phép một trang web truy cập các tệp của trang web khác hoặc thỏa hiệp các trang web khác bằng cách nào đó?

Cảm ơn!

Tôi hoàn toàn đồng ý với các mục bạn có cho đến nay.

Tôi đã từng chạy một thiết lập nhiều người dùng như vậy vài năm trước và về cơ bản tôi đã tìm thấy sự đánh đổi tương tự: mod_php rất nhanh (một phần vì mọi thứ chạy trong cùng một quy trình) và suexec chậm nhưng an toàn (vì mọi yêu cầu đều tạo ra một quá trình). Tôi đã đi với suexec, vì yêu cầu cách ly người dùng.

Hiện tại có một tùy chọn thứ ba mà bạn có thể xem xét: cung cấp cho mỗi người dùng trình nền php-fpm của riêng họ. Điều này có khả thi hay không tùy thuộc vào số lượng người dùng, bởi vì mỗi người trong số họ phải có ít nhất một quy trình php-fpm bằng tài khoản người dùng của họ (daemon sau đó sử dụng cơ chế giống như prefork để mở rộng cho các yêu cầu, vì vậy số lượng quy trình và việc sử dụng bộ nhớ của họ có thể là các yếu tố hạn chế). Bạn cũng sẽ cần một số thế hệ cấu hình tự động, nhưng điều đó có thể thực hiện được với một vài tập lệnh shell.

Tôi chưa sử dụng phương pháp đó trong các môi trường lớn nhưng IMHO là một giải pháp tốt để cung cấp hiệu suất trang web PHP tốt trong khi vẫn cách ly người dùng ở cấp độ quy trình.

Tất cả mọi thứ bạn có cho đến nay dường như cũng nghĩ ra. Điều duy nhất mà tôi có thể thấy là một vấn đề là thực tế hầu hết các khai thác tìm cách giành quyền truy cập root bằng cách này hay cách khác. Vì vậy, ngay cả khi mỗi trang web và các quy trình và tập lệnh tương ứng của nó bị bỏ tù một cách chính xác và mọi thứ đều có người dùng riêng và cho phép một hacker có quyền root không quan tâm, họ sẽ bỏ qua mọi thứ bạn đã thiết lập.

Đề nghị của tôi sẽ là sử dụng một số loại phần mềm VM (VMware, VirtualBox, Qemu, v.v.) để cung cấp cho mỗi trang web đó là bản riêng của hệ điều hành. Điều này cho phép bạn, với tư cách là quản trị viên hệ thống, không phải lo lắng về một trang web bị xâm nhập. Nếu tin tặc có quyền root bằng cách khai thác php (hoặc bất kỳ phần mềm nào khác) trên VM của trang web, chỉ cần tạm dừng VM và phân tích nó sau, áp dụng các bản sửa lỗi hoặc quay trở lại trạng thái không bị phá vỡ. Điều này cũng cho phép quản trị viên trang web áp dụng phần mềm cụ thể hoặc cài đặt bảo mật cho môi trường trang web cụ thể của họ (có thể phá vỡ một trang web khác).

Hạn chế duy nhất cho điều này là phần cứng của bạn nhưng với một máy chủ phong nha và các phần mở rộng kernel chính xác thì điều này rất dễ đối phó. Tôi đã chạy thành công kiểu thiết lập này trên Linode, được cấp cho cả Máy chủ và Khách rất rất thưa thớt. Nếu bạn cảm thấy thoải mái với dòng lệnh mà tôi cho rằng bạn không có vấn đề gì.

Kiểu thiết lập này làm giảm số lượng vectơ tấn công bạn phải theo dõi và cho phép bạn tập trung vào bảo mật Máy chủ và xử lý mọi thứ khác trên một trang web trên cơ sở trang web.

Tôi sẽ đề nghị mỗi trang web chạy dưới daemon Apache của riêng nó và chroot Apache. Tất cả chức năng php hệ thống sẽ thất bại do môi trường chroot Apache sẽ không có quyền truy cập vào / bin / sh. Điều này cũng có nghĩa là chức năng mail () của php sẽ không hoạt động, nhưng nếu bạn đang sử dụng nhà cung cấp thư bên ngoài để gửi thư từ ứng dụng email của mình, thì đây không phải là vấn đề đối với bạn.

SELinux có thể hữu ích với mod_selinux. Một hướng dẫn nhanh được giới thiệu ở đây:

Làm cách nào tôi có thể sử dụng SELinux để giới hạn các tập lệnh PHP?

Vì các hướng dẫn có một chút ngày, tôi đã kiểm tra xem điều này có hoạt động trên RHEL 7.1 không:

Tôi đã sử dụng phiên bản của Fedora 19 và được biên dịch với bản giả lập chống lại RHEL 7.1 + EPEL.

YMMV nếu bạn sử dụng các mô hình cấu hình epel cơ bản với:

[mockbuild@fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \
    mod_selinux-2.4.3-2.fc19.src.rpm

Nâng cấp hệ thống mục tiêu của bạn đầu tiên để đảm bảo rằng selinux-policyhiện tại.

Cài đặt trên hộp đích (hoặc đặt vào gương cục bộ của bạn trước):

yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm

Bây giờ, bạn phải chỉ định mỗi máy chủ ảo trong apache một danh mục. Điều này được thực hiện bằng cách thêm một dòng như trong ví dụ dưới đây được gọi selinuxDomainVal.

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host1
    ServerName host1.virtual
    selinuxDomainVal *:s0:c0
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host2
    ServerName host2.virtual
    selinuxDomainVal *:s0:c1 
</VirtualHost>

Tiếp theo, trong thư mục gốc của tài liệu cho mỗi máy chủ lưu trữ, hãy dán lại các gốc tài liệu của chúng vào cùng loại với các tài liệu được gắn nhãn trong cấu hình httpd.

chcon -R -l s0:c0 /var/www/vhosts/host1
chcon -R -l s0:c1 /var/www/vhosts/host2

Nếu bạn muốn làm cho nhãn được tôn vinh nếu bạn thực hiện dán lại hệ thống, bạn cũng nên cập nhật chính sách địa phương!

semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/host1(/.*)?' 
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/host2(/.*)?'

Đã có rất nhiều câu trả lời kỹ thuật tốt được cung cấp (vui lòng xem tại đây: https://security.stackexchange.com/q/77/52572 và Mẹo để bảo mật máy chủ LAMP ), nhưng tôi vẫn muốn đề cập ở đây một điểm quan trọng (từ góc nhìn khác) về bảo mật: bảo mật là một quá trình . Tôi chắc rằng bạn đã xem xét điều này rồi, nhưng tôi vẫn hy vọng nó có thể hữu ích (cũng cho những người đọc khác) đôi khi suy nghĩ lại về nó.

Ví dụ: trong câu hỏi của bạn, bạn tập trung chủ yếu vào các biện pháp kỹ thuật: "câu hỏi này chỉ nhắm mục tiêu bảo mật cho thiết lập Apache được chia sẻ. Cụ thể, có bất kỳ bước bảo mật nào quan trọng cần thực hiện nhưng bị thiếu trong danh sách trên khi chạy chia sẻ Apache và PHP. "

Hầu như tất cả các câu trả lời ở đây và trên 2 câu hỏi khác mà tôi đã đề cập dường như hoàn toàn là kỹ thuật (ngoại trừ khuyến nghị để được cập nhật). Và theo quan điểm của tôi, điều này có thể khiến một số độc giả có ấn tượng sai lệch, rằng nếu bạn định cấu hình máy chủ của mình theo thông lệ tốt nhất một lần, thì bạn sẽ an toàn mãi mãi. Vì vậy, đừng quên những điểm mà tôi bỏ lỡ trong câu trả lời:

1. Trước hết, đừng quên rằng bảo mật là một quá trình và đặc biệt là về chu trình "Kế hoạch-Thực hiện-Kiểm tra-Hành động", theo khuyến nghị của nhiều tiêu chuẩn, bao gồm ISO 27001 ( http://www.isaca.org/ Tạp chí / tài liệu lưu trữ / 2011 / Tập-4 / Trang / Lập kế hoạch để thực hiện-ISO27001.aspx ). Về cơ bản, điều này có nghĩa là bạn cần thường xuyên sửa đổi các biện pháp bảo mật, cập nhật và kiểm tra chúng .

2. Thường xuyên cập nhật hệ thống cho bạn. Điều này sẽ không giúp chống lại các cuộc tấn công được nhắm mục tiêu sử dụng các lỗ hổng zero-day, nhưng nó sẽ giúp chống lại hầu hết các cuộc tấn công tự động.

3. Giám sát hệ thống của bạn. Tôi thực sự thiếu điểm này trong câu trả lời. Theo quan điểm của tôi, điều cực kỳ quan trọng là phải được thông báo sớm nhất có thể về một số vấn đề với hệ thống của bạn.

   Đây là những gì số liệu thống kê nói về nó: "Thời gian trung bình từ khi xâm nhập đến khi khám phá là 173,5 ngày" ( http://www.triumfant.com/detection.html ), "205 số ngày trung bình trước khi phát hiện" ( https: // www2 .fireeye.com / rs / fireye / hình ảnh / rpt-m-Trend-2015.pdf ). Và tôi hy vọng rằng những con số này không phải là tất cả chúng ta muốn có.

   Có rất nhiều giải pháp (bao gồm miễn phí) không chỉ để theo dõi trạng thái của dịch vụ (như Nagios), mà cả các hệ thống phát hiện xâm nhập (OSSEC, Snort) và hệ thống SIEM (OSSIM, Splunk). Nếu nó trở nên quá phức tạp, ít nhất bạn có thể kích hoạt một cái gì đó như 'fail2ban' và / hoặc chuyển tiếp nhật ký của bạn đến máy chủ syslog riêng biệt và có thông báo email về các sự kiện quan trọng.

   Một lần nữa, điểm quan trọng nhất ở đây không phải là bạn chọn hệ thống giám sát nào, quan trọng nhất là bạn có một số giám sát và sửa đổi nó thường xuyên theo chu trình "Kế hoạch-Làm-Kiểm tra-Hành động" của bạn .

4. Hãy nhận biết các lỗ hổng. Tương tự như giám sát. Chỉ cần đăng ký một số danh sách lỗ hổng sẽ được thông báo, khi một số lỗ hổng nghiêm trọng được phát hiện cho Apache hoặc dịch vụ khác quan trọng cho thiết lập của bạn. Mục tiêu là được thông báo về những điều quan trọng nhất xuất hiện trước khi cập nhật kế hoạch tiếp theo của bạn.

5. Có kế hoạch phải làm gì trong trường hợp xảy ra sự cố (và thường xuyên cập nhật và sửa đổi nó theo chu kỳ "Kế hoạch-Làm-Kiểm tra-Đạo luật" của bạn). Nếu bạn đặt câu hỏi về cấu hình an toàn, điều đó có nghĩa là bảo mật hệ thống của bạn trở nên quan trọng đối với bạn. Tuy nhiên, bạn nên làm gì trong trường hợp nếu hệ thống của bạn bị hack bất chấp mọi biện pháp bảo mật? Một lần nữa, tôi không có nghĩa là chỉ có các biện pháp kỹ thuật ở đây như "cài đặt lại hệ điều hành": Bạn nên báo cáo tai nạn theo luật hiện hành ở đâu? Bạn có được phép tắt / ngắt kết nối máy chủ của mình ngay lập tức không (chi phí cho công ty của bạn là bao nhiêu)? Ai nên được liên lạc nếu người có trách nhiệm chính đang trong kỳ nghỉ / ốm?

6. Có một máy chủ sao lưu, lưu trữ và / hoặc thay thế / nhân rộng. Bảo mật cũng có nghĩa là sự sẵn có của dịch vụ của bạn. Kiểm tra sao lưu / lưu trữ / sao chép của bạn thường xuyên và cũng kiểm tra các quy trình khôi phục thường xuyên.

7. Kiểm tra thâm nhập? (một lần nữa, hãy xem chu trình "Lập kế hoạch-Thực hiện-Kiểm tra-Hành động" :) Nếu cảm thấy quá nhiều, ít nhất bạn có thể thử một số công cụ trực tuyến miễn phí, quét các dịch vụ web của bạn để tìm các vấn đề về phần mềm độc hại và bảo mật.

Trường hợp sử dụng của bạn là lý tưởng cho các container docker.

Mỗi vùng chứa có thể đại diện cho một khách hàng hoặc khách hàng, với các ID người dùng duy nhất được gán cho từng nhóm vùng chứa Apache dưới dạng bảo mật được thêm vào. Chìa khóa sẽ là bỏ các đặc quyền gốc khi bắt đầu container, trước khi bắt đầu ngăn xếp apache của bạn. Mỗi khách hàng có dịch vụ DB riêng với mật khẩu riêng, không phải lo lắng về việc đứng lên hàng chục máy ảo, mỗi máy đều yêu cầu hạt nhân bông tuyết đặc biệt của riêng họ và các chi phí khác. Rốt cuộc, tại trung tâm của docker là chroot. Quản lý đúng cách, tôi sẽ đưa nó qua một cụm ảo điển hình bất cứ ngày nào.

Rất nhiều gợi ý tốt ở đây rồi. Có những thứ đã bị bỏ lỡ trong cuộc thảo luận cho đến nay.

Hãy chú ý đến các quy trình bên ngoài những quy trình này như là một phần của việc phục vụ các trang web. tức là đảm bảo rằng tất cả các công việc định kỳ của bạn chạm vào dữ liệu không đáng tin cậy đang chạy với tư cách là người dùng phù hợp và trong nhà tù thích hợp, cho dù những công việc đó có được xác định bởi người dùng hay không.

Theo kinh nghiệm của tôi, những thứ như phân tích nhật ký, khi được cung cấp bởi dịch vụ lưu trữ, được chạy gần như thường xuyên và phần mềm phân tích nhật ký không được kiểm tra bảo mật nhiều như chúng tôi mong muốn. Làm tốt điều này là một chút khó khăn, và thiết lập phụ thuộc. Một mặt, bạn không muốn quá trình apache thuộc sở hữu gốc của mình (tức là quá trình cha) viết vào bất kỳ thư mục nào mà người dùng có thể thỏa hiệp. Điều đó có nghĩa là không viết trực tiếp vào nhà tù. Mặt khác, bạn cần làm cho các tệp đó có sẵn cho các quy trình trong trại giam để phân tích và bạn muốn nó càng gần với thời gian thực càng tốt. Nếu bạn có thể cung cấp cho các nhà tù của bạn quyền truy cập vào một hệ thống tập tin chỉ đọc với các bản ghi, điều đó sẽ tốt.

Các ứng dụng PHP thường không phục vụ các tệp tĩnh của riêng chúng và nếu bạn có quy trình apache được chia sẻ thì tôi đoán rằng quy trình apache của bạn đang đọc nội dung ra khỏi nhà tù từ môi trường máy chủ? Nếu vậy, thì điều đó mở ra một loạt các mối quan tâm.

.htaccesscác tập tin là một điều hiển nhiên, trong đó bạn cần phải rất cẩn thận những gì bạn cho phép. Nhiều ứng dụng php đáng kể nếu không phụ thuộc rất nhiều vào cách sắp xếp tệp .htaccess mà bạn có thể không cho phép mà không phá hỏng sơ đồ theo kế hoạch của mình.

Ít rõ ràng hơn là làm thế nào apache quyết định thế nào là một tệp tĩnh. ví dụ: Nó làm gì với một *.php.gifhoặc *.php.entập tin? Nếu cơ chế này hoặc cơ chế khác đánh lừa sự phân biệt đối với tệp tĩnh là gì, liệu apache có thể chạy php ở bên ngoài nhà tù không? Tôi đã thiết lập một máy chủ web trọng lượng nhẹ riêng cho nội dung tĩnh, không được cấu hình với bất kỳ mô-đun nào để thực hiện nội dung động và có bộ cân bằng tải quyết định yêu cầu gửi đến máy chủ tĩnh và máy chủ động nào.

Về đề xuất Docker của Stefan, có thể có một máy chủ web nằm bên ngoài container và nói chuyện với php daemon trong mỗi container cho nội dung động, đồng thời có một máy chủ web thứ hai, nằm trong một container docker và chia sẻ khối lượng từng sử dụng cho nội dung của họ và do đó có thể phục vụ nội dung tĩnh, tương tự như trong đoạn trước. Tôi khen ngợi docker trong số các cách tiếp cận loại tù khác nhau, nhưng với cách tiếp cận loại tù này hoặc loại tù khác, bạn sẽ có một loạt các vấn đề khác cần giải quyết. Làm thế nào để tải lên tập tin làm việc? Bạn có đặt daemon chuyển tập tin trong mỗi container? Bạn có thực hiện một cách tiếp cận dựa trên git phong cách PAAS? Làm thế nào để bạn có thể tạo các bản ghi được tạo bên trong container, và cuộn chúng lại? Làm thế nào để bạn quản lý và chạy các công việc cron? Bạn sẽ cung cấp cho người dùng bất kỳ loại quyền truy cập shell nào, và nếu vậy, đó có phải là một daemon khác trong container không? Vân vân.

Điều đầu tiên tôi không thấy là quản lý quy trình để một quy trình không thể bỏ đói một quá trình CPU hoặc RAM khác (hoặc I / O cho vấn đề đó, mặc dù hệ thống tệp của bạn có thể được cấu trúc để ngăn chặn điều đó). Một lợi thế lớn của cách tiếp cận "thùng chứa" đối với các cá thể PHP của bạn so với cố gắng chạy tất cả chúng trên một hình ảnh "HĐH" là bạn có thể hạn chế sử dụng tài nguyên tốt hơn theo cách đó. Tôi biết đó không phải là thiết kế của bạn, nhưng đó là điều cần xem xét.

Dù sao, trở lại trường hợp sử dụng PHP chạy đằng sau Apache về cơ bản hoạt động như một proxy. suexec không ngăn thứ gì đó chạy như người dùng apache - nó cung cấp khả năng chạy như một người dùng khác. Vì vậy, một mối quan tâm sẽ là đảm bảo rằng tất cả đã được thực hiện đúng - trang tài liệu cho nó gọi đó là mối nguy hiểm tiềm tàng: https://httpd.apache.org/docs/2.2/suexec.html . Vì vậy, bạn biết, hạt muối và tất cả những thứ đó.

Từ một quan điểm an ninh nó có thể hữu ích để có một bộ hạn chế của mã nhị phân sử dụng để làm việc với (mà cagefs vật tư), đặc biệt là nếu họ được biên dịch khác nhau hoặc chống lại một thư viện khác nhau (ví dụ như một trong đó không bao gồm khả năng mà là không mong muốn) nhưng các nguy hiểm là tại thời điểm đó, bạn không còn theo dõi một bản phân phối đã biết để cập nhật, bạn đang theo một bản phân phối khác (lồng) cho các bản cài đặt PHP của bạn (ít nhất là đối với các công cụ không gian người dùng). Mặc dù có lẽ bạn đã theo dõi một bản phân phối cụ thể với cloudlinux, đó là một rủi ro gia tăng, không nhất thiết phải thú vị.

Tôi sẽ để AllowOverride ở nơi bạn có thể dự định. Ý tưởng cốt lõi đằng sau phòng thủ theo chiều sâu là không dựa vào một lớp duy nhất để bảo vệ toàn bộ ngăn xếp của bạn. Luôn luôn cho rằng một cái gì đó có thể đi sai. Giảm thiểu khi điều đó xảy ra. Lặp lại cho đến khi bạn giảm nhẹ cũng như bạn có thể ngay cả khi bạn chỉ có một hàng rào trước các trang web của mình.

Quản lý nhật ký sẽ là chính. Với nhiều dịch vụ chạy trong các hệ thống tệp bị cô lập, việc tích hợp các hoạt động để tương quan khi có sự cố có thể là một nỗi đau nhỏ nếu bạn không thiết lập điều đó ngay từ đầu.

Đó là bộ não của tôi. Hy vọng có một cái gì đó mơ hồ hữu ích trong đó. :)