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ọ.
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ọ.
Câu trả lời:
Sử dụng cặp khóa công khai / riêng để xác thực thay vì mật khẩu.
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
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.pub
từ mỗi máy tính vào từng dòng ~/.ssh/authorized_keys
trê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).
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 yes
và 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.
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 no
và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 group2
hoặc AllowUsers user1 user2
để giới hạn người có thể SSH vào máy chủ.
sshd
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 -T
sau 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.
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.
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:
sudo apt-get install libpam-google-authenticator
Yêu cầu mỗi người dùng chạy google-authenticator
lệnh, sẽ tạo ~/.google-authenticator
và 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).
Chỉnh sửa /etc/ssh/sshd_config
và thiết lập:
ChallengeResponseAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive
Chạy sudo service ssh reload
để nhận các thay đổi của bạn để /etc/ssh/sshd_config
.
Chỉnh sửa /etc/pam.d/sshd
và 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 .
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.
Đâ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.
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 .
localhost
./etc/tor/torrc
. Đặt HiddenServiceDir /var/lib/tor/ssh
và HiddenServicePort 22 127.0.0.1:22
.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.Mở $HOME/.ssh/config
và 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 myhost
và 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".
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 .
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ủ.
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.
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ứ).
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).
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 ...
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.
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.
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 .
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/
Đố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
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 đó.