it-swarm-vi.tech

Những bước nào bạn thực hiện để bảo mật máy chủ Debian?

Tôi đang cài đặt một máy chủ Debian được kết nối trực tiếp với Internet. Rõ ràng tôi muốn làm cho nó an toàn nhất có thể. Tôi muốn các bạn/các cô gái thêm ý tưởng của bạn để bảo mật nó và những chương trình bạn sử dụng cho nó.

Tôi muốn một phần của câu hỏi này bao gồm những gì bạn sử dụng như một tường lửa? Chỉ iptables được cấu hình thủ công hoặc bạn có sử dụng một số loại phần mềm để hỗ trợ bạn không? Cách tốt nhất là gì? Chặn mọi thứ và chỉ cho phép những gì cần thiết? Có thể có hướng dẫn tốt cho người mới bắt đầu chủ đề này?

Bạn có thay đổi cổng SSH không? Bạn có sử dụng phần mềm như Fail2Ban để ngăn chặn các cuộc tấn công bruteforce không?

66
Thomaschaaf

Bắt buộc:

  • cài đặt hệ thống với chế độ chuyên gia, chỉ các gói mà tôi cần
  • tường lửa viết tay với chính sách mặc định trên iptables'input: thả, cho phép truy cập vào SSH, HTTP hoặc bất cứ thứ gì khác được cung cấp cho máy chủ đang chạy
  • Fail2Ban cho SSH [và đôi khi FTP/HTTP/khác - tùy thuộc vào ngữ cảnh]
  • vô hiệu hóa đăng nhập gốc, buộc sử dụng người dùng bình thường và Sudo
  • kernel tùy chỉnh [thói quen cũ]
  • nâng cấp hệ thống theo lịch trình

Tùy thuộc vào mức độ hoang tưởng bổ sung:

  • thả chính sách đầu ra ngoại trừ một vài điểm đến/cổng được phép
  • integrit để kiểm tra xem một số phần của kho hệ thống tệp không được sửa đổi [với tổng kiểm tra được giữ bên ngoài máy], ví dụ Tripwire
  • quét theo lịch trình ít nhất với nmap của hệ thống từ bên ngoài
  • kiểm tra nhật ký tự động cho các mẫu không xác định [nhưng chủ yếu là để phát hiện sự cố phần cứng hoặc một số sự cố nhỏ]
  • chạy theo lịch trình của chkrootkit
  • thuộc tính bất biến cho /etc/passwd vì vậy việc thêm người dùng mới khó khăn hơn một chút
  • / tmp được gắn với noexec
  • cổng gõ hoặc cách mở cổng SSH không chuẩn khác [ví dụ: truy cập trang web 'bí mật' trên máy chủ web cho phép kết nối SSH đến trong một khoảng thời gian giới hạn từ địa chỉ IP đã xem trang. Nếu bạn được kết nối, -m state --satete ESTABLISHED đảm nhiệm việc cho phép luồng gói miễn là bạn sử dụng một phiên SSH]

Những điều tôi không tự làm nhưng có ý nghĩa:

  • bảo mật cho kernel
  • syslog từ xa để nhật ký không thể bị ghi đè khi hệ thống bị xâm phạm
  • cảnh báo về bất kỳ thông tin đăng nhập SSH nào
  • cấu hình rkhunter và thiết lập nó để chạy theo thời gian
50
pQd

Chỉ cần một lưu ý về tường lửa máy của bạn ...

  • Sử dụng danh sách trắng, không phải danh sách đen - tức là chặn mọi thứ và chỉ cho phép những gì bạn cần, từ chối mọi thứ khác.
  • Không sử dụng GUI/ncurses hoặc bất kỳ phần mềm nào cố gắng thực hiện nhiệm vụ viết tường lửa cho bạn. Nếu bạn làm như vậy, bạn sẽ cho phép phần mềm đưa ra các giả định cho bạn - bạn không cần phải chấp nhận rủi ro đó và không nên. Tự cấu hình nó, nếu bạn không chắc chắn, hãy tắt nó - bạn sẽ sớm tìm ra nếu cần. Nếu nó đã là một hệ thống đang hoạt động và bạn không thể phá vỡ lưu lượng truy cập (do vô tình chặn nó), thì hãy chạy tcpdump (kết xuất tệp) và lấy mẫu - nghiên cứu chúng sau đó, sau đó tìm ra cái gì hợp lệ và cái gì không.
  • Cá nhân tôi không thấy bất kỳ điểm nào khi chạy một dịch vụ trên một cổng không chuẩn, các công cụ ngày nay không quá ngu ngốc để cho rằng vì một cái gì đó đang chạy trên cổng 22 chẳng hạn, thì nó phải là ssh, và không phải là - cho ví dụ amapnmap 's -A Lựa chọn. Như đã nói, bạn có thể (và có lẽ nên lo lắng) sửa đổi các dịch vụ của mình để che giấu bản thân khỏi những con mắt tò mò, ví dụ, những điều sau đây sẽ cho kẻ tấn công biết phiên bản chính xác của OpenSSH mà bạn đang chạy, chúng sau đó có thể tìm kiếm khai thác cho phiên bản chính xác đó. Nếu bạn che giấu những điều như vậy, bạn sẽ làm cho chúng khó khăn hơn.
[.__.] [root @ ud-olis-1 uhtbin] # telnet localhost 22 [.__.] Đang thử 127.0.0.1 ... [.__.] Đã kết nối với localhost.localdomain (127.0.0.1). [.___ .] Ký tự thoát là '^]'. [.__.] SSH-2.0-OpenSSH_3.9p1 [.__.]
  • Luôn cập nhật tất cả các dịch vụ công cộng của bạn và được vá bằng các bản vá bảo mật mới nhất.
  • Không lưu trữ bất kỳ DATA nào trên máy chủ cổng, ít nhất bạn sẽ mua thời gian khi họ quản lý để xâm nhập vào máy này và bạn sẽ mất một hoặc hai dịch vụ và đôi khi không phải dữ liệu.

Điểm mấu chốt là bạn sẽ không bao giờ thành công trong việc tạo ra bất cứ điều gì an toàn 100% - điều đó là không thể - vì vậy mục đích là làm cho an toàn nhất có thể - nếu chỉ cần nỗ lực quá nhiều để phá vỡ hệ thống của bạn, thì nó đủ tốt và hầu hết script-kiddies sẽ chuyển sang hệ thống tiếp theo.

  • iptables là cách phù hợp với mọi hệ thống Linux - nhưng hãy tự cấu hình nó.

Đừng bao giờ sử dụng bất kỳ "phần mềm bảo mật" nào không dựa trên các tiêu chuẩn mở - chúng chắc chắn sẽ được viết kém và sẽ bị hack (không phải là vấn đề "nếu", mà là "khi nào"). Nguồn mở và các giao thức mở được mở để xem xét công khai và hội tụ để trở thành một sản phẩm trưởng thành và đáng tin cậy; Phần mềm nguồn đóng chủ yếu dựa vào sự tự tin của các tác giả về mức độ tuyệt vời/an toàn của sản phẩm họ nghĩ rằng đó là - tức là một số ít mắt so với mắt đầy trái đất.

Mong rằng sẽ giúp :)

18
Xerxes
  • vô hiệu hóa đăng nhập root
  • vô hiệu hóa đăng nhập bằng mật khẩu (chỉ cho phép đăng nhập bằng khóa chung)
  • thay đổi cổng SSH
  • sử dụng denyhosts (hoặc tương tự)

  • viết tập lệnh iptble của riêng bạn (để bạn kiểm soát chính xác những gì cho phép và có thể bỏ mọi thứ khác)

  • buộc sử dụng các liên lạc được bảo mật SSL/TLS và đảm bảo có các chứng chỉ hợp lệ, không hết hạn và đã ký

  • bật xác minh chứng chỉ nghiêm ngặt cho tất cả các dịch vụ bên ngoài (ví dụ: khi xác thực người dùng bằng máy chủ LDAP trên máy khác)
12
x-way
9
KPWINC

Là một điểm khởi đầu chung, tôi tuân theo điểm chuẩn/hướng dẫn từ Trung tâm bảo mật Internet , đây là phần tổng hợp toàn diện các thực tiễn tốt nhất về bảo mật. Có vẻ như điểm chuẩn Debian của họ đã được cập nhật trong một thời gian, nhưng tổng quan chung về các bước là:

  • Áp dụng các bản vá/gói hệ điều hành mới nhất
  • Cho phép kế toán hệ thống/kernel/process.
  • Kích hoạt MAC (ví dụ: SELinux hoặc AppArmor).
  • Kích hoạt tường lửa dựa trên máy chủ (iptables).
  • Xác minh APT nguồn.list (khóa chính xác, nguồn đáng tin cậy).
  • Tối thiểu hóa các dịch vụ mạng, vô hiệu hóa mọi thứ không cần thiết và tường lửa là gì.
  • Sử dụng TCPWrappers để tiếp tục hạn chế quyền truy cập hệ thống.
  • Chỉ sử dụng các giao thức mạng được mã hóa, vô hiệu hóa các dịch vụ không được mã hóa (telnet, ftp, v.v.).
  • Chỉ định cấu hình truy cập từ xa vào SSH.
  • Vô hiệu hóa mật khẩu đăng nhập của người dùng và yêu cầu xác thực dựa trên khóa.
  • Vô hiệu hóa chia sẻ hệ thống tập tin (NFS, SMB).
  • Cho phép ghi nhật ký hệ thống từ xa/tập trung (và thường xuyên xem lại nhật ký!).
  • Đặt mật khẩu cấp BIOS/phần sụn.
  • Đặt mật khẩu bộ nạp khởi động.
  • Định cấu hình sao lưu hệ thống, có kế hoạch khắc phục thảm họa và KIỂM TRA rằng các bản sao lưu đó là hợp lệ và nhân viên đó biết các quy trình khắc phục thảm họa!

Có nhiều tài nguyên trên tất cả các cài đặt khác nhau này, bao gồm các lệnh và tệp cấu hình cụ thể để triển khai trên hệ thống trong các điểm chuẩn CISecurity.

6
jtimberman

Tôi đề nghị không gắn máy trực tiếp vào Internet. Đặt một số loại tường lửa giữa máy và Internet. Điều này cho phép bạn thực hiện bảo mật và giám sát mạng mà không cần tải thêm máy chủ. Cá nhân, tôi thấy việc phân chia mạng và chức năng thường đơn giản hóa việc khắc phục sự cố mạng, mặc dù đôi khi, sự phức tạp bổ sung làm cho việc phân tích trở nên khó khăn hơn.

Chính sách tường lửa an toàn nhất, nhưng khó chịu nhất để quản lý là từ chối tất cả và chỉ cho phép rõ ràng lưu lượng truy cập bạn phải cho phép. Điều này gây khó chịu, bởi vì người ta thường xuyên cần cập nhật chính sách tường lửa khi mạng cần thay đổi.

Tôi cũng sẽ đề nghị sử dụng một số loại tường lửa giao diện trên máy chủ - phòng thủ theo chiều sâu là chìa khóa. Sử dụng các cổng không chuẩn cho các dịch vụ liên quan đến quản trị sẽ không gây hại. fail2ban vẫn ổn Theo đuổi các câu hỏi cụ thể hơn về các ứng dụng bảo mật trên Serverfault để tìm thêm ý tưởng.

Bảo mật giống như trò đùa về hai người đi bộ và gấu - trong khi một người không bao giờ có thể đạt được bảo mật hoàn hảo, thì thật hữu ích khi trở thành mục tiêu khó khăn hơn những kẻ khác.

5
pcapademic

Một số người đã chỉ vào Hướng dẫn bảo mật Debian . Điều này cần phải hoàn toàn đầy đủ cho tất cả mọi thứ trừ các yêu cầu quân sự.

Nhiều người nghĩ rằng bị hoang tưởng một cách lố bịch là mát mẻ hoặc chuyên nghiệp hoặc một cái gì đó. Đó là không phải , nó chỉ gây phiền nhiễu cho các quản trị viên khác và hoàn toàn kìm nén cho người dùng của bạn. Hầu hết những thứ bạn thấy được đề xuất chỉ là công việc bận rộn giả tạo để cảm thấy hữu ích cho quản trị viên hoang tưởng, nhưng không thực sự hữu ích, vì vi phạm bảo mật thực sự có thể do hệ thống không được cập nhật đầy đủ và/hoặc từ nguồn bên trong.

Điều đó nói rằng, tôi coi đó là một trong những nguyên lý của mình để không tin tưởng bất cứ điều gì trên mạng cục bộ hơn bất kỳ thứ gì từ Internet. Do đó, tôi định cấu hình mọi thứ để yêu cầu xác thực ngay cả trên mạng cục bộ. Tôi mã hóa và xác thực tất cả lưu lượng giữa mỗi máy tính bằng IPsec.

Tôi đang trong quá trình chuyển đổi sang mã hóa toàn bộ đĩa cho tất cả các máy chủ của mình.

Tôi chỉ cài đặt dịch vụ tôi sử dụng. Tôi không có tường lửa; Tôi định cấu hình các dịch vụ tôi phải yêu cầu xác thực hoặc giới hạn chúng (bằng cấu hình của chính chương trình hoặc bởi các trình bao bọc TCP) đối với các IP nhất định. Điều duy nhất tôi cần chặn bằng iptables là memcached, vì nó không có tệp cấu hình và không sử dụng các trình bao bọc TCP.

Tôi sử dụng tốt, mật khẩu được tạo ngẫu nhiên cho tài khoản của tôi và tin tưởng máy chủ SSH của tôi (và tất cả các dịch vụ khác) để tránh những người không biết mật khẩu. fail2ban chỉ dành cho những người có không gian giới hạn cho tệp nhật ký, IMO. (Bạn nên có mật khẩu đủ tốt để có thể tin tưởng chúng.)

4
Teddy

Xem qua cách làm hay này tại www.debian.org/doc/manuals/securing-debian-howto/

Cá nhân tôi thay đổi cổng ssh và sử dụng fail2ban + denyhosts. Và tôi chặn mọi thứ không cần thiết. Bạn càng chặn bạn càng ít phải lo lắng.

3
Vihang D