Làm cách nào để làm cứng máy chủ SSH?


128

Tôi nên thực hiện những biện pháp nào để đảm bảo rằng bảo mật xung quanh máy chủ SSH của tôi hoàn toàn không thấm nước?

Đây sẽ là wiki cộng đồng ngay từ đầu, vì vậy hãy xem mọi người làm gì để bảo mật máy chủ của họ.


44
Không thấm nước tuyệt đối đòi hỏi phải tắt hộp.
Thorbjørn Ravn Andersen

Nếu bạn có Wake-on-LAN thì sao?
rebus

Vấn đề sẽ là phần LAN ... Các gói Wake-on-LAN không được định tuyến, do đó bạn sẽ phải có quyền truy cập vào một máy bên trong mạng LAN để gửi gói WOL ...
LassePoulsen

Để xác thực khóa, bạn có thể giới hạn Mật mã cho các mật mã bạn thực sự cần.

Câu trả lời:


108

Sử dụng cặp khóa công khai / riêng để xác thực thay vì mật khẩu.

  1. Tạo khóa SSH được bảo vệ bằng mật khẩu cho mọi máy tính cần truy cập vào máy chủ:

    ssh-keygen

  2. Cho phép truy cập SSH khóa công khai từ các máy tính được phép:

    Sao chép nội dung ~/.ssh/id_rsa.pubtừ mỗi máy tính vào từng dòng ~/.ssh/authorized_keystrên máy chủ hoặc chạy ssh-copy-id [server IP address]trên mọi máy tính mà bạn đang cấp quyền truy cập (bạn sẽ phải nhập mật khẩu máy chủ tại dấu nhắc).

  3. Vô hiệu hóa truy cập SSH mật khẩu:

    Mở /etc/ssh/sshd_config, tìm dòng nói #PasswordAuthentication yesvà thay đổi nó thành PasswordAuthentication no. Khởi động lại trình nền máy chủ SSH để áp dụng thay đổi ( sudo service ssh restart).

Bây giờ, cách duy nhất có thể để SSH vào máy chủ là sử dụng khóa khớp với một dòng trong đó ~/.ssh/authorized_keys. Sử dụng phương pháp này, tôi không quan tâm đến các cuộc tấn công vũ phu bởi vì ngay cả khi họ đoán mật khẩu của tôi, nó sẽ bị từ chối. Không thể buộc một cặp khóa công khai / riêng tư với công nghệ ngày nay.


5
-1: Thông thường quyền truy cập được cấp cho từng máy tính không phải máy tính, việc tạo khóa cho mỗi máy khách tiềm năng kết nối với máy chủ là không hợp lý. Tuyên bố cuối cùng của bạn là không chính xác, theo sự ngăn chặn của bạn và vì bạn không đề xuất đặt cụm mật khẩu cho các khóa riêng có quyền truy cập / thỏa hiệp của bất kỳ hệ thống máy khách nào sẽ tự động cấp quyền truy cập vào máy chủ SSH. Xác thực khóa SSH được khuyến nghị nhưng các khóa riêng phải được bảo vệ đúng cách và nên được sử dụng trên cơ sở cá nhân, không theo kiểu phân tán như mô tả.
João Pinto

7
"Thông thường quyền truy cập được cấp cho cá nhân không phải máy tính, tạo khóa cho mỗi máy khách tiềm năng kết nối với máy chủ là không hợp lý" Có nhiều tùy chọn và tôi nghĩ mô tả cách chuyển khóa riêng cho mọi khách hàng dường như nằm ngoài phạm vi của câu hỏi này . Tôi không trình bày tất cả các lựa chọn, chỉ là một lựa chọn đơn giản mà tôi nghĩ mọi người có thể hiểu. "... nên được sử dụng trên cơ sở cá nhân, không phải theo kiểu phân tán như mô tả" Điều này dường như mâu thuẫn với tuyên bố trước đây của bạn và tôi không mô tả bất cứ điều gì được phân phối.
Asa Ayers

5
"Không thể" có lẽ là làm quá lên một chút.
Thorbjørn Ravn Andersen

9
Đây là lý do tại sao tôi nói "không thể". Không ai có máy tính nhanh đến mức này nhiều hay nhiều thời gian. "Hãy tưởng tượng một máy tính có kích thước bằng một hạt cát có thể kiểm tra các khóa chống lại một số dữ liệu được mã hóa. Ngoài ra, hãy tưởng tượng rằng nó có thể kiểm tra một khóa trong khoảng thời gian cần thiết để vượt qua nó. Sau đó, hãy xem xét một cụm các máy tính này, nhiều đến nỗi nếu bạn bao phủ trái đất với chúng, chúng sẽ bao phủ toàn bộ hành tinh tới độ cao 1 mét. Cụm máy tính sẽ phá khóa trung bình 128 bit trong 1.000 năm. "
Asa Ayers

@ ThorbjørnRavnAndersen "Không thể" không thực sự cường điệu hóa nó, miễn là bạn sử dụng một phím mạnh. Tôi không thể tìm thấy một trích dẫn ngay bây giờ, nhưng với độ dài khóa hiện tại, các cuộc tấn công vũ phu là không thể thực hiện được "cho đến khi máy tính được tạo thành từ một thứ gì đó ngoài vật chất và chiếm giữ một thứ khác ngoài không gian".
Maximillian Laumeister

72

Tôi muốn đề nghị:

  • Sử dụng fail2ban để ngăn chặn các nỗ lực đăng nhập vũ phu.

  • Vô hiệu hóa đăng nhập bằng root thông qua SSH. Điều này có nghĩa là kẻ tấn công đã phải tìm ra cả tên người dùng và mật khẩu khiến việc tấn công trở nên khó khăn hơn.

    Thêm PermitRootLogin novào của bạn /etc/ssh/sshd_config.

  • Giới hạn người dùng có thể SSH đến máy chủ. Hoặc theo nhóm hoặc chỉ người dùng cụ thể.

    Thêm AllowGroups group1 group2hoặc AllowUsers user1 user2để giới hạn người có thể SSH vào máy chủ.


2
Người cho phépNgười cho phép không chấp nhận dấu phẩy , dưới dạng dấu phân cách. Hãy chắc chắn rằng bạn không thử điều này từ xa. Tôi liên tục bị khóa NAS bằng cách làm điều này không chính xác.
tiếng ồn vô nghĩa

4
Luôn xác thựcsshd cấu hình của bạn là chính xác trước khi bạn khởi động lại sshd, để tránh tự khóa máy. Xem blog này để biết chi tiết - chỉ cần chạy sshd -Tsau khi thay đổi cấu hình trước khi khởi động lại chính sshd. Ngoài ra, hãy mở phiên SSH trên máy khi bạn thực hiện thay đổi cấu hình và không đóng phiên này cho đến khi bạn xác thực cấu hình như đã đề cập và có thể đã thực hiện đăng nhập SSH thử nghiệm.
RichVel

24

Các câu trả lời khác cung cấp bảo mật, nhưng có một điều bạn có thể làm sẽ làm cho nhật ký của bạn yên tĩnh hơn và làm giảm khả năng bạn sẽ bị khóa khỏi tài khoản của mình:

Di chuyển máy chủ từ cổng 22 sang cổng khác. Hoặc tại cổng của bạn, hoặc trên máy chủ.

Nó không tăng tính bảo mật, nhưng điều đó có nghĩa là tất cả các máy quét internet ngẫu nhiên sẽ không làm lộn xộn các tệp nhật ký của bạn.


1
Đối với những người tin vào bảo mật bằng cách che khuất ( en.wikipedia.org/wiki/Security_ENC_obscurity ) sẽ rất có ý nghĩa khi sử dụng một cổng khác. Tôi không mặc dù ..
LassePoulsen

32
Đó không phải là về Bảo mật thông qua che khuất (mặc dù che khuất có thể có tác động tích cực cận biên). Đó là về việc giảm tiếng ồn xung quanh của những nỗ lực vũ phu vô tận. Bạn không thể kiểm tra nhật ký lỗi truy cập của mình một cách hữu ích nếu chúng đầy các cuộc tấn công tự động; fail2ban không giảm âm lượng đủ với số lượng kẻ tấn công và mức độ phổ biến của các cuộc tấn công phân tán (botnet) và điều tiết. Với ssh trên một cổng bất thường, bạn biết các cuộc tấn công bạn thấy trong nhật ký đến từ một kẻ tấn công thực sự quan tâm đến hộp của bạn. Tôi thực sự khuyên bạn nên nó.
bobince

Vì bạn có thể truy vấn các dịch vụ internet như shodan cho các máy chủ ssh đối diện web hoặc sử dụng nmap và chụp banner khiến việc thay đổi cổng mặc định trở nên vô nghĩa. Tôi sẽ khuyên chống lại điều này.
SLow Loris

Shodan không lấy tất cả các cổng 65 nghìn nên việc đổi sang cổng cao sẽ có khả năng xóa nó khỏi quét. Ngoài ra, nếu bạn di chuyển đến một cổng cao ngẫu nhiên, kẻ tấn công có thể sẽ cần thực hiện quét 65K TCP (rất ồn) để tìm dịch vụ của bạn để bắt đầu tấn công nó. Cả hai đều là chiến thắng từ góc độ bảo mật, do đó, di chuyển đến một cổng cao nói chung là một kế hoạch tốt. Một điều nữa là bằng cách di chuyển đến một cổng cao, bạn có thể biết rõ hơn rằng ai đó đang tấn công bạn đang nhắm mục tiêu vào các hệ thống của bạn chứ không phải là tiếng ồn nền chung chung
R®ry McCune

23

Cho phép xác thực hai yếu tố với HOTP hoặc TOTP . Điều này có sẵn từ 13.10 trở đi.

Điều này bao gồm sử dụng xác thực khóa công khai qua xác thực mật khẩu như trong một câu trả lời khác ở đây, nhưng cũng yêu cầu người dùng chứng minh rằng anh ta giữ thiết bị yếu tố thứ hai bên cạnh khóa riêng của mình.

Tóm lược:

  1. sudo apt-get install libpam-google-authenticator

  2. Yêu cầu mỗi người dùng chạy google-authenticatorlệnh, sẽ tạo ~/.google-authenticatorvà giúp họ định cấu hình hai thiết bị yếu tố của họ (ví dụ: ứng dụng Google Authenticator Android).

  3. Chỉnh sửa /etc/ssh/sshd_configvà thiết lập:

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. Chạy sudo service ssh reloadđể nhận các thay đổi của bạn để /etc/ssh/sshd_config.

  5. Chỉnh sửa /etc/pam.d/sshdvà thay thế dòng:

    @include common-auth
    

    với:

    auth required pam_google_authenticator.so
    

Thông tin chi tiết về các tùy chọn cấu hình khác nhau là bài đăng trên blog của tôi từ năm ngoái: Xác thực ssh hai yếu tố tốt hơn trên Ubuntu .


21

Làm cho IP của khách hàng chặn sshd không cung cấp thông tin đăng nhập chính xác " DenyHØsts " có thể thực hiện công việc này khá hiệu quả. Tôi đã cài đặt cái này trên tất cả các hộp Linux của mình theo cách nào đó có thể tiếp cận được từ bên ngoài.

Điều này sẽ đảm bảo rằng các cuộc tấn công bắt buộc vào SSHD sẽ không hiệu quả, nhưng hãy nhớ (!) Bằng cách này bạn có thể tự khóa mình nếu quên mật khẩu. Đây có thể là một vấn đề trên một máy chủ từ xa mà bạn không có quyền truy cập.


2
Có một số tùy chọn như 10 lần đăng nhập thất bại trước khi cấm địa chỉ IP không?
sayantankhan

20

Đây là một điều dễ dàng để làm: cài đặt ufw ("tường lửa không phức tạp") và sử dụng nó để xếp hạng giới hạn các kết nối đến.

Từ một dấu nhắc lệnh, gõ:

$ sudo ufw limit OpenSSH 

Nếu ufw chưa được cài đặt, hãy làm điều này và thử lại:

$ sudo aptitude install ufw 

Nhiều kẻ tấn công sẽ cố gắng sử dụng máy chủ SSH của bạn để kiểm tra mật khẩu. Điều này sẽ chỉ cho phép 6 kết nối cứ sau 30 giây từ cùng một địa chỉ IP.


+1 Sử dụng giới hạn có thể là tốt. Tuy nhiên nên chỉ ra rằng tôi đã gặp phải sự cố khi sử dụng máy chủ sftp tích hợp vì nó cũng hạn chế các kết nối cho việc này.
Đánh dấu Davidson

2
@Mark - điểm tốt, nhưng không có vẻ như là một khách hàng SFTP được viết kém? Tại sao họ cứ kết nối lại với cổng SSH khi họ chỉ có thể mở thêm các kênh SSH?
mpontillo

12

Nếu tôi muốn có thêm một số bảo mật hoặc cần truy cập vào các máy chủ SSH nằm sâu bên trong một số mạng công ty, tôi sẽ thiết lập một dịch vụ ẩn bằng cách sử dụng phần mềm ẩn danh Tor .

  1. Cài đặt Tor và thiết lập máy chủ SSH.
  2. Hãy chắc chắn rằng sshd chỉ lắng nghe tại localhost.
  3. Mở /etc/tor/torrc. Đặt HiddenServiceDir /var/lib/tor/sshHiddenServicePort 22 127.0.0.1:22.
  4. Nhìn vào var/lib/tor/ssh/hostname. Có một cái tên như thế d6frsudqtx123vxf.onion. Đây là địa chỉ của dịch vụ ẩn.
  5. Mở $HOME/.ssh/configvà thêm một số dòng:

    Host myhost
    HostName d6frsudqtx123vxf.onion
    ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
    

Hơn nữa tôi cần Tor trên máy chủ địa phương của tôi. Nếu nó được cài đặt, tôi có thể nhập ssh myhostvà SSH sẽ mở kết nối qua Tor. Máy chủ SSH ở phía bên kia chỉ mở cổng của nó trên localhost. Vì vậy, không ai có thể kết nối nó thông qua "internet bình thường".


10
Bảo mật bằng cách tối nghĩa tiên tiến, nhưng rất thú vị.
Julian

8

Có một bài viết Quản trị Debian về chủ đề này. Nó bao gồm cấu hình máy chủ SSH cơ bản và các quy tắc tường lửa. Điều này cũng có thể được quan tâm để làm cứng máy chủ SSH.

Xem bài viết: Giữ quyền truy cập SSH an toàn .


3
Bit muộn, nhưng xin vui lòng, khi trả lời câu hỏi, sao chép các phần quan trọng từ một liên kết để nếu liên kết phân rã thông tin vẫn còn ở đây.
umop aplsdn

1
Ý tưởng tốt. Mặc dù tôi đang trải qua một khoảng thời gian ít tham gia hơn. Câu trả lời của tôi là một "wiki cộng đồng" vì vậy hãy thoải mái thêm thông tin liên kết nếu bạn có thời gian.
Huygens

6

Cách tiếp cận của tôi để làm cứng SSH là ... phức tạp. Các mục sau đây là về cách tôi thực hiện, từ đường viền cạnh nhất của (các) mạng của tôi đến chính các máy chủ.

  1. Lọc lưu lượng ở cấp biên giới thông qua IDS / IPS với các máy quét dịch vụ và chữ ký đã biết trong danh sách chặn. Tôi đạt được điều này với Snort thông qua tường lửa biên giới của tôi (đây là cách tiếp cận của tôi, một thiết bị pfSense). Đôi khi, tôi không thể làm điều này, chẳng hạn như với các VPS của tôi.

  2. Tường lửa / Lọc mạng của (các) cổng SSH. Tôi rõ ràng chỉ cho phép một số hệ thống nhất định tiếp cận với các máy chủ SSH của tôi. Điều này được thực hiện thông qua tường lửa pfSense ở biên của mạng của tôi hoặc tường lửa trên mỗi máy chủ được định cấu hình rõ ràng. Tuy nhiên, có những trường hợp tôi không thể làm điều này (điều này gần như không bao giờ xảy ra, ngoại trừ trong môi trường phòng thí nghiệm kiểm tra bút riêng hoặc kiểm tra bảo mật nơi tường lửa sẽ không giúp kiểm tra mọi thứ).

  3. Kết hợp với pfSense của tôi hoặc tường lửa biên giới NAT vào mạng bên trong và tách khỏi Internet và các hệ thống, chỉ truy cập VPN vào máy chủ . Phải đưa VPN vào các mạng của tôi để đến các máy chủ, vì không có cổng truy cập Internet như vậy. Điều này chắc chắn không hoạt động đối với tất cả các VPS của tôi, nhưng kết hợp với # 2, tôi có thể có một VPS là 'cổng' bằng cách VPN vào máy chủ đó và sau đó cho phép IP của nó vào các hộp khác. Bằng cách đó, tôi biết chính xác những gì có thể hoặc không thể SSH trong - một hộp của tôi đó là VPN. (Hoặc, trong mạng gia đình của tôi phía sau pfSense, kết nối VPN của tôi và tôi là người duy nhất có quyền truy cập VPN).

  4. Trong đó # 3 không thể thực hiện được, fail2ban, được định cấu hình để chặn sau 4 lần thất bại và chặn IP trong một giờ trở lên là một sự bảo vệ tốt đối với những người liên tục tấn công bằng bruteforcing - chỉ cần tự động chặn chúng tại tường lửa bằng fail2ban và meh. Cấu hình fail2ban là một điều khó khăn ...

  5. Cổng obfuscation bằng cách thay đổi cổng SSH. Tuy nhiên, đây KHÔNG phải là một ý tưởng tốt để thực hiện mà không có bất kỳ biện pháp bảo mật bổ sung nào - câu thần chú của "Bảo mật thông qua che khuất" đã bị bác bỏ và tranh chấp trong nhiều trường hợp. Tôi đã thực hiện việc này cùng với IDS / IPS và lọc mạng, nhưng nó vẫn là một điều RẤT kém để tự làm.

  6. MANDATORY Xác thực hai yếu tố, thông qua các giải pháp Xác thực hai yếu tố của Duo Security . Mỗi một máy chủ SSH của tôi đều có Duo được cấu hình trên đó, để thậm chí có thể đăng nhập, 2 nhắc nhở xảy ra và tôi phải xác nhận mỗi lần truy cập. (Đây là tính năng hữu ích cuối cùng - bởi vì ngay cả khi ai đó có cụm mật khẩu của tôi hoặc đột nhập, họ cũng không thể vượt qua các plugin Duo PAM). Đây là một trong những biện pháp bảo vệ lớn nhất trên các máy chủ SSH của tôi khỏi sự truy cập trái phép - mỗi người dùng đăng nhập PHẢI liên kết lại với người dùng được định cấu hình trong Duo và vì tôi có một bộ hạn chế, không có người dùng mới nào có thể đăng ký trong hệ thống.

Hai xu của tôi để bảo mật SSH. Hoặc, ít nhất, suy nghĩ của tôi về cách tiếp cận.


1

Bạn có thể muốn kiểm tra ứng dụng FreeOTP từ RedHat thay vì sử dụng Google Authenticator. Đôi khi khi cập nhật ứng dụng, họ sẽ khóa bạn! ;-)

Nếu bạn muốn sử dụng các mã thông báo phần cứng khác như Yubikey hoặc eToken PASS hoặc NG hoặc nếu bạn có nhiều người dùng hoặc nhiều máy chủ, bạn có thể muốn sử dụng phụ trợ xác thực hai yếu tố mã nguồn mở.

Gần đây tôi đã viết một hướng dẫn về điều này .


0

Tôi đã viết một hướng dẫn nhỏ về việc này gần đây. Về cơ bản, bạn cần sử dụng PKI và hướng dẫn của tôi cũng chỉ ra cách sử dụng Xác thực hai yếu tố để bảo mật hơn nữa. Ngay cả khi bạn không sử dụng bất kỳ thứ gì trong số đó, cũng có một số thông tin về việc bảo mật máy chủ bằng cách loại bỏ các bộ mật mã yếu và các vấn đề cơ bản khác. https://joscor.com/blog/hardening-openssh-server-ubfox-14-04/


0

Đối với số lượng lớn người dùng / chứng chỉ, hãy xem xét tích hợp LDAP. Các tổ chức lớn sử dụng LDAP làm kho lưu trữ thông tin xác thực và chứng chỉ người dùng được lưu trữ trên huy hiệu hoặc fob, cho dù chứng chỉ được sử dụng để xác thực hoặc ký email. Ví dụ bao gồm openLDAP, openDJ, Active Directory, Oracle Universal Directory, IBM Directory Server, snareWorks ...

Máy tính và nhóm cũng có thể được quản lý trong LDAP cho phép quản lý thông tin trung tâm. Bằng cách đó, bàn trợ giúp có thể có một cửa hàng để đối phó với dân số lớn.

Đây là một liên kết đến tích hợp centOS: http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to-fetch-public.html


0

Bạn cũng có thể chặn dựa trên quốc gia xuất xứ bằng cơ sở dữ liệu GeoIP.

Về cơ bản nếu bạn sống ở Mỹ thì không có lý do gì để ai đó ở Nga kết nối với SSH của bạn để họ sẽ tự động bị chặn.

Kịch bản có thể được tìm thấy ở đây: https://www.axllent.org/docs/view/ssh-geoip/

Bạn cũng có thể thêm các lệnh iptables vào nó (tôi đã làm cho các giọt của mình) để tự động thả tất cả lưu lượng truy cập đến / từ các IP đó.


1
Đôi khi, cơ sở dữ liệu GeoIP có thể sai - Tôi được hỏi là tôi đã ở Moscow ngày hôm qua ... eh không! :)
Sean
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.