Đây là một câu hỏi Canonical về việc bảo vệ ngăn xếp LAMP

Các nguyên tắc tuyệt đối để bảo mật máy chủ LAMP là gì?

Câu trả lời của David là một cơ sở tốt của các nguyên tắc chung của việc làm cứng máy chủ. Như David chỉ ra, đây là một câu hỏi rất lớn. Các kỹ thuật cụ thể bạn thực hiện có thể phụ thuộc nhiều vào môi trường của bạn và cách máy chủ của bạn sẽ được sử dụng. Cảnh báo, điều này có thể mất rất nhiều công việc trong môi trường thử nghiệm để xây dựng và hoàn thành đúng. Tiếp theo là rất nhiều công việc để tích hợp vào môi trường sản xuất của bạn, và quan trọng hơn là quy trình kinh doanh.

Tuy nhiên, trước tiên, hãy kiểm tra xem liệu tổ chức của bạn có bất kỳ chính sách cứng rắn nào không, vì những chính sách này có thể liên quan trực tiếp nhất. Nếu không, tùy thuộc vào vai trò của bạn, đây có thể là thời điểm tuyệt vời để xây dựng chúng. Tôi cũng sẽ khuyên bạn nên giải quyết từng thành phần riêng biệt từ dưới lên.

L
Có rất nhiều hướng dẫn tốt có sẵn để giúp bạn. Danh sách này có thể hoặc không thể giúp bạn tùy thuộc vào phân phối của bạn.

• Trung tâm Điểm chuẩn An ninh Internet - Phân phối cụ thể cho các hương vị chính
• CentOS Hardening HowTo - Theo sát hướng dẫn CIS RHEL5, nhưng dễ đọc hơn nhiều
• NIST SP800-123 - Hướng dẫn bảo mật máy chủ chung
• NSA Hardening Factheets - Không được cập nhật gần đây như CIS, nhưng vẫn chủ yếu áp dụng
• Tiger - Phần mềm kiểm tra bảo mật hệ thống trực tiếp

A
Apache có thể được vui vẻ để bảo đảm. Tôi thấy việc làm cứng hệ điều hành và duy trì khả năng sử dụng dễ dàng hơn cả Apache hoặc PHP.

• Apache Server Hardening - Câu hỏi này trên trang web chị em IT Security có rất nhiều thông tin tốt.
• Trung tâm Điểm chuẩn Bảo mật Internet - Một lần nữa, điểm chuẩn của Apache.
• Mẹo bảo mật của Apache - Trực tiếp từ dự án Apache, có vẻ như nó bao gồm những điều cơ bản
• Danh sách kiểm tra cứng của DISA - Danh sách kiểm tra từ các anh chàng Đảm bảo thông tin DoD

M

• Trung tâm Điểm chuẩn Bảo mật Internet - Một lần nữa, nhưng đối với điểm chuẩn của MySQL
• OWASP MySQL cứng
• Nguyên tắc bảo mật chung - Danh sách kiểm tra cơ bản từ nhà phát triển dự án

Chữ P
này chạy dài vào toàn bộ ý tưởng về Thực tiễn lập trình an toàn, là toàn bộ môn học của chính nó. Sans và OWASP có một lượng thông tin vô lý về chủ đề này, vì vậy tôi sẽ không cố gắng sao chép nó ở đây. Tôi sẽ tập trung vào cấu hình thời gian chạy và để các nhà phát triển của bạn lo lắng về phần còn lại. Đôi khi 'P' trong LAMP đề cập đến Perl, nhưng thường là PHP. Tôi đang giả định sau.

• Cố định PHP - Một số thảo luận nhỏ, cũng trên trang web IT Security SE.
• Dự án PHP cứng - Dự án chính tạo ra Suhosin , một nỗ lực vá ứng dụng PHP để dự án chống lại các loại tấn công nhất định.
• Làm cứng PHP với Suhosin - Một cách ngắn gọn dành riêng cho Suhosin
• Cố định PHP từ php.ini - Thảo luận ngắn, nhưng không tệ về một số tùy chọn thời gian chạy liên quan đến bảo mật

Bạn đã hỏi một câu hỏi, khá thẳng thắn, xứng đáng với một vài cuốn sách về chủ đề này. Nhưng có một số hướng dẫn cơ bản chung hoạt động tốt:

1. Tiếp tục cập nhật. Điều này có nghĩa là HĐH, tất cả các dịch vụ và ĐẶC BIỆT tất cả các ứng dụng web bạn đang chạy.
2. Vô hiệu hóa bất kỳ dịch vụ không cần thiết nào, giới hạn những dịch vụ cần thiết ở mức phơi sáng tối thiểu (nếu bạn không kết nối từ xa với MySQL, thì đừng nghe nó trên TCP) và chạy tường lửa dựa trên máy chủ. (Nếu đó là LAMP, bạn nên làm tốt với 80 và 443, nhưng có lẽ SSH cũng như quản trị.))
3. Sử dụng mật khẩu mạnh. Tốt hơn nữa, nếu bạn sử dụng SSH, chỉ sử dụng auth dựa trên khóa.
4. Hãy chắc chắn rằng bạn không đăng nhập với quyền root. Đăng nhập với tư cách người dùng và sử dụng su & sudo.
5. Mặc dù nó không làm cho mọi thứ an toàn hơn, bạn nên chạy các công cụ như logwatch để bạn biết về những gì đang xảy ra trên máy chủ của mình.

Hy vọng rằng sẽ giúp bạn bắt đầu.

Đây là một danh sách kiểm tra tốt mà tôi muốn bắt đầu.

Bức tường lửa

• Một cách tiếp cận tốt đẹp là không cho phép bất kỳ lưu lượng truy cập nào bắt đầu, sau đó chỉ mở những gì bạn cần , khi bạn cần. Điều này dẫn đến việc mở các cổng / ips tối thiểu để mọi thứ hoạt động và giảm thiểu phơi sáng của bạn.
• Đối với máy chủ LAMP, bạn có thể chỉ cần mở các cổng cho http / https ra thế giới và ssh cho sysadmin.
• Đảm bảo những thứ như lưu lượng ipv6 bị khóa nếu không sử dụng
• AWS cung cấp các nhóm bảo mật, linux có iptables cũng như rất nhiều gói để lựa chọn.

SSH & Người dùng

• Không có mật khẩu để truy cập ssh (sử dụng khóa riêng)
• Không cho phép root để ssh (người dùng thích hợp nên ssh in, sau đó su hoặc sudo)
• Sử dụng sudo cho người dùng để các lệnh được ghi lại
• Ghi nhật ký các nỗ lực đăng nhập trái phép (và xem xét phần mềm để chặn / cấm người dùng cố gắng truy cập máy chủ của bạn quá nhiều lần, như fail2ban)
• ssh trên cổng không chuẩn (điều này có thể hữu ích để đảm bảo bạn không treo trái cây thấp và tránh nhiều lưu lượng gây phiền nhiễu, nhưng sẽ không làm được gì nhiều cho an ninh, đặc biệt là chính nó)
• khóa ssh để chỉ phạm vi ip bạn yêu cầu (một phạm vi lớn tốt hơn không có phạm vi)

Cơ sở dữ liệu

• Vệ sinh dữ liệu người dùng
• Truy vấn tham số
• Xem xét trừu tượng hóa DB với máy của chính nó. Sự tách biệt này có thể khiến kẻ tấn công gặp khó khăn hơn trong việc truy cập vào ngăn xếp web của bạn và ngược lại.
• Giống như bất kỳ phần mềm giữ cho đến nay là quan trọng.
• Một người dùng cho từng mục đích . Khi tạo người dùng bắt đầu không có đặc quyền và chỉ thêm những người họ cần để thể hiện vai trò của họ. Việc có người dùng riêng biệt cho các ứng dụng khác nhau (hoặc đôi khi là các phần khác nhau của ứng dụng) sẽ giúp giảm lợi ích mà kẻ tấn công có được nếu họ thỏa hiệp bất kỳ một tài khoản nào. Ngoài ra, hãy cẩn thận với các đặc quyền đặc biệt như GRANT không nên được chỉ định nhẹ.
• Có một chính sách để thay đổi mật khẩu định kỳ là một ý tưởng tốt. Nếu bạn lo lắng về số lượng nỗ lực cần thiết, hãy nhớ ít thường xuyên hơn là tốt hơn bao giờ hết.
• Hiểu mã hóa mật khẩu. Mật khẩu muối . Đừng sử dụng md5!

Phần mềm

• Luôn cập nhật phần mềm (os, máy chủ web, ngôn ngữ kịch bản, CMS). Nhiều người ngoài kia sẽ quét các lỗ hổng đã biết trong các phiên bản cũ (chưa được vá)
• Xóa mọi phần mềm bạn không cần (lý tưởng là không giữ gói cần thiết để biên dịch phần mềm trên các máy chủ sản xuất, tốt hơn là nên biên dịch trước phần mềm và cung cấp dưới dạng gói cho máy sản xuất của bạn)
• Đảm bảo quyền truy cập tệp bị khóa (đặc biệt đối với những thứ như người dùng tải lên và tệp cấu hình)
• Mật khẩu bảo vệ khu vực quản trị viên cho CMS ở cấp máy chủ web ( xác thực http có thể ngồi trước một CMS dễ bị tổn thương và giúp chặn truy cập, đây là một cách tốt để ngăn chặn các cuộc tấn công)
• Sử dụng SSL cho khu vực quản trị và dữ liệu nhạy cảm khác
• Tự động hóa việc quản lý máy chủ và cơ sở hạ tầng của bạn (Một cái gì đó như Puppet, Chef hoặc SaltStack. Nếu sử dụng AWS CloudFormation nữa). Điều này sẽ giúp bạn vá mọi thứ trên nhiều máy chủ và cắt giảm các tình huống như sửa quyền trên Máy chủ A nhưng quên thực hiện trên Máy chủ B
• Nếu có thể, đừng cho đi phiên bản cụ thể của CMS, PHP hoặc WebServer của bạn. Trong khi che khuất thông tin này không phải là bảo mật, có rất nhiều người đang quét các phiên bản phần mềm khác nhau và càng ít thông tin bạn tự do đưa ra thì kẻ tấn công càng phải làm việc. Đây là một cách tốt để đảm bảo bạn không phải là một trong những trái cây treo thấp. Tất nhiên điều này sẽ không làm gì với người muốn dành thêm một chút nỗ lực để vào
• Giới hạn những người có quyền truy cập vào máy chủ

Thêm vào những gì David gợi ý, cài đặt của bạn càng nhiều mô-đun, nghĩa là tôi hạn chế quyền truy cập vào một số người dùng / nhóm nhất định được tạo riêng cho một tác vụ và giới hạn phạm vi của họ, ngăn xếp LAMP của bạn càng an toàn: Một ví dụ về điều này là có người dùng Apache đối với các tệp / thư mục Apache có quyền được đặt tương ứng và không thuộc bất kỳ nhóm nào có thể truy cập các tệp / thư mục hệ thống quan trọng. Người dùng có thể truy cập các bảng MySql được liên kết với các trang web của bạn mà bạn sẽ phục vụ và chỉ những bảng đó. Ngoài ra, bạn có thể hạn chế quyền truy cập của họ để cung cấp lượng truy cập tối thiểu từ cuộc gọi PHP. Ngoài ra, hãy đảm bảo rằng tên người dùng MySQL được sử dụng / hiển thị thông qua tệp PHP không phải là cùng tên người dùng hoặc mật khẩu được sử dụng cho người dùng khác.

Điều này có nghĩa là gì: nếu người dùng apache hoặc người dùng MySql bị xâm phạm, họ không thể gây hại gì ngoài phạm vi của thư mục apache có quyền truy cập (trong trường hợp người dùng apache) và bên ngoài bảng ( s) / cơ sở dữ liệu (trong trường hợp người dùng cho cơ sở dữ liệu MySQL).

Nếu bằng cách nào đó, người dùng MySQL bị xâm phạm, chẳng hạn, họ không thể truy cập cơ sở dữ liệu và bỏ tất cả các cơ sở dữ liệu khỏi MySQL và phá hỏng tất cả dữ liệu của bạn. Họ MIGHT trong một số trường hợp có thể bỏ bảng hoặc chèn thông tin vào một số bảng trong cơ sở dữ liệu bị cô lập, đó là lý do tại sao chỉ cấp quyền truy cập bảng khi thực sự cần thiết và chỉ cấp quyền cần thiết ... nếu bạn không ' Không cần phải có đặc quyền bảng thả hoặc cập nhật đặc quyền, sau đó không cung cấp cho người dùng đó.

Ngoài ra, nếu vì lý do nào đó, tên người dùng và mật khẩu tài khoản quản trị của bạn bị phát hiện vì MySQL, nếu bạn sử dụng tên người dùng khác với bất kỳ tên người dùng nào trên hệ thống của bạn, trước tiên họ phải phá vỡ bảo mật hệ thống của bạn trước khi xâm nhập vào cơ sở dữ liệu của bạn. Điều tương tự cũng đúng về người dùng apache và quyền truy cập vào các tệp.

Ví dụ thời gian! Tôi sẽ đưa ra một ví dụ hệ thống để đơn giản hóa ý tưởng.

nói rằng bạn có người dùng trên hệ thống của mình (root nên bị vô hiệu hóa để bảo mật thông qua một cái gì đó như umod -l hoặc passwd -l, v.v.): john, barney, terence và lisa.

bạn có thể tạo một người dùng trong MySQL với tên của bigbird (đảm bảo bạn sử dụng mật khẩu băm). Bigbird chỉ có các đặc quyền chọn và cập nhật đặc quyền, nhưng không bỏ hoặc tạo, và chắc chắn là không . Ngoài ra, bạn tạo một người dùng MySQL quản trị khác có tên garfield để làm việc trên cơ sở dữ liệu MySQL và bạn xóa người dùng root khỏi cơ sở dữ liệu MySQL để không bị bắt buộc. garfield đã được cấp . đặc quyền trên toàn MySQL (hiệu quả, đây chỉ là đổi tên root).

bây giờ, bạn tạo một nhóm apache hoặc người dùng và chúng tôi sẽ gọi nó là apweb2. Appweb2 không phải là thành viên của các nhóm khác và tất cả các tệp / thư mục cho apache được lưu trữ trong / home / apweb2 /. Mỗi máy chủ ảo sẽ có thư mục con riêng và mỗi máy chủ này sẽ có bộ gốc tài liệu được đặt thành thư mục con đó. Symlinks sẽ bị vô hiệu hóa để không vô tình cung cấp quyền truy cập vào phần còn lại của hệ thống.

Ngoài ra, bạn có thể hạn chế quyền truy cập ssh chỉ với một số người dùng nhất định (hoặc một số nhóm nhất định, tôi muốn đưa họ vào nhóm ssh và làm cho điều duy nhất có thể sử dụng ssh).

Ngoài ra, bạn có thể chọn người dùng nào có đặc quyền sudo để hạn chế mọi thứ hơn nữa. Một bước nữa bạn có thể tiến xa hơn là làm cho bất kỳ người dùng ssh nào không thể sudo, bạn có thể tạo người dùng đặc biệt có thể sử dụng sudo mà không thể sử dụng ssh, để khi bạn đăng nhập, bạn phải đăng nhập vào người dùng khác để có truy cập vào sudo.

Vì vậy, bằng cách mô đun hóa từng phân đoạn, nếu một phân đoạn bị xâm phạm, toàn bộ ngăn xếp sẽ không bị xâm phạm và bạn có thể khắc phục sự cố 1 thay vì phải bắt đầu lại từ đầu.

Tôi tìm thấy tài liệu này từ SANS.org thực sự hữu ích http://www.sans.org/score/checklists/linuxchecklist.pdf

Tại thời điểm hiện tại, đừng bỏ qua ảo hóa container, cụ thể là Docker, systemd-nspawn và các cơ chế ảo hóa container mà chúng được xây dựng (không gian tên, cgroups). Sử dụng ảo hóa container cho phép bạn cách ly các tiến trình, ví dụ, nếu một trong các dịch vụ bị xâm phạm, kẻ tấn công sẽ không có quyền truy cập vào các dịch vụ khác.

Trong trường hợp LAMP, có thể sử dụng, ví dụ, bốn container Docker với SSH-server, Apache, MySQL, PHP-FPM / Python / Perl / etc.