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


66

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ỉ cần 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?


1
Có rất nhiều sự trùng lặp với serverfault.com/questions/42/securing-a-fresh-ub Ubuntu
Zoredache

1
Ubuntu không có Debian, nhưng tôi không biết liệu mọi người có định cấu hình iptables cho họ hay sử dụng một số phần mềm như fireHOL
Thomaschaaf

Tôi luôn có xu hướng tự viết các quy tắc iptables. Tôi có một tấm nồi hơi làm những thứ như thả tất cả các mảnh, gói xmas, v.v ... Bất cứ thứ gì ngoài hệ thống cụ thể, và thường khá nhỏ. Tôi không thể nhấn mạnh đủ các mảnh vỡ khi sử dụng iptables, btw. Vì một số lý do tôi chưa nghiên cứu, iptables chỉ kiểm tra đoạn đầu tiên và mù quáng vượt qua phần còn lại mà không kiểm tra. Theo suy nghĩ của tôi, điều đó làm cho các mảnh vỡ trở thành một trách nhiệm.
Scott Pack

3
Uhm ... Debian có ufw. packages.debian.org/ufw
womble

Câu trả lời:


50

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ụ như 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 /etc/passwdđể thêm người dùng mới là 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, hãy -m state --satete ESTABLISHEDquan tâm đến 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 để chạy theo thời gian

4
Sau khi thực hiện tất cả những điều này, hãy chạy BASTille chống lại hệ thống để tìm kiếm bất cứ điều gì khác. Tôi cũng sẽ khuyên bạn nên thực hiện kiểm tra đầy đủ, không an toàn khi quét Nessus của hệ thống; sau đó sửa bất cứ thứ gì nó cảnh báo.
Scott Pack

13
Biên dịch kernel tùy chỉnh không cung cấp lợi thế bảo mật trừ khi bạn thực sự biết bạn đang làm gì. Bạn cũng sẽ bỏ qua việc cập nhật thông tin trừ khi bạn đặt nó trong hệ thống quản lý gói, điều này sẽ dẫn đến tình trạng mất an ninh tồi tệ hơn.
Adam Gibbins

3
-1 để bảo mật thông qua che khuất. Nếu không thì trả lời đàng hoàng.
dwc

@Adam - vâng, tôi biết điều đó, tôi vẫn thích có nhân nguyên khối chỉ bao gồm các phần mà tôi cần. đó có lẽ là rất lạc hậu, nhưng tôi làm điều đó. @dwc - đó chỉ là một bước bổ sung mà chỉ là một đóng băng hoặc như chúng ta nói anh đào trên đỉnh của những thứ có mùi khó chịu.
pQd

1
Và bạn có nghĩa là sudo không su -
LapTop006

18

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 Chẳng hạn amap, và nmap's -Alựa chọn. Có nói rằng, 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 OpenSSHbạn đang chạy, sau đó chúng có thể tìm kiếm khai thác 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).
    Nhân vậ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à để đảm bảo 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, điều đó đủ tốt và đáng sợ nhấ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 sẽ bị viết kém và sẽ bị hack (không phải là "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 mà họ nghĩ 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 :)


"... một số lượng nhỏ mắt và một đôi mắt đầy đất." - Tôi muốn đủ "tập đoàn" nhận ra điều này, nhưng bảo mật thông qua che khuất dường như là xu hướng được theo dõi nhiều nhất. Có, chạy một dịch vụ, như ssh, trên một cổng không chuẩn sẽ không tránh được kẻ tấn công quyết tâm. Tuy nhiên, nó sẽ giữ các tập lệnh kiddies đi - ai đó đang chạy một cuộc tấn công từ điển vào một loạt các địa chỉ IP trên cổng 22.
L0neRanger

12
  • 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 thông tin 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)

Bạn nhận được một upvote để vô hiệu hóa mật khẩu auth.
derobert


6

Là một điểm khởi đầu chung, tôi theo dõi đ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 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 là chính xác, nguồn đáng tin cậy).
  • Giảm thiểu 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.


5

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ì việc trở thành mục tiêu khó khăn hơn những kẻ khác là điều hữu ích.


+1 cho câu trả lời hay. Tôi phải chỉ ra rằng từ chối mặc định không gây khó chịu để quản lý nếu bạn tiếp cận đúng. Chắc chắn bạn phải biết những gì bạn đang cho phép, phải không? Trong thực tế, điều này nên được viết bằng ngôn ngữ đơn giản như một tuyên bố chính sách. Nếu bạn không làm việc đó như thường lệ thì bạn sẽ không làm quản trị viên. Nếu là bạn, việc cập nhật các quy tắc tường lửa là một vấn đề đơn giản.
dwc

Điểm rất tốt. Mỗi tổ chức nên có một tuyên bố chính sách bảo mật ngôn ngữ đơn giản. Khi nhu cầu của tổ chức thay đổi, tuyên bố chính sách cần được cập nhật. Nếu chỉ để quản trị viên lập kế hoạch thực hiện quy tắc tường lửa và CYA, quản trị viên thông minh sẽ duy trì tuyên bố chính sách như vậy ngay cả khi ban quản lý tổ chức không thể bận tâm để nghĩ về bảo mật.
pcapademia

4

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 , nó chỉ gây phiền nhiễu cho quản trị viên khác và hoàn toàn áp 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 thực sự 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 (theo cấu hình của 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à memcachedvì 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 mật khẩu tốt, được tạo ngẫu nhiên cho các tài khoản của mình 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. fail2banchỉ dành cho những người có không gian hạn chế cho các tệp nhật ký, IMO. (Bạn nên có mật khẩu đủ tốt để có thể tin tưởng chúng.)


3

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.


4
Ừ Bạn đã cho tôi đến "thay đổi cổng SSH". Không có điểm nào. Đặc biệt là không khi bất kỳ schmoe joe nào có đủ thời gian trên tay anh ta có thể quét cổng bạn và ngay lập tức tìm ra cổng SSH nào đang chạy. Nó tuyên bố tên dịch vụ (và phiên bản máy chủ) ngay khi bạn kết nối.
Matt Simmons

3
Vâng, tôi biết bất cứ ai cũng có thể quét cổng của bạn và tìm ra cổng phù hợp. Nhưng hầu hết các cuộc tấn công là trên cổng mặc định. Chỉ cần cố gắng để có được một số thống kê bằng cách thay đổi cổng.
Vihang D
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.