Tôi có mật khẩu của mình an toàn, nhưng tôi nghe thấy mọi người phàn nàn về sự bất ổn của một máy chủ sẽ bị giảm mạnh khi một cuộc tấn công tàn bạo đang diễn ra. Làm cách nào tôi có thể bảo mật máy chủ Ubuntu 10.10 của mình khỏi các cuộc tấn công như vậy? Có một hồ sơ apparmor cho điều này? Hoặc một số cách khác để giải quyết nó?
Câu trả lời:
Có nhiều giải pháp khác nhau. Cách tốt nhất là sử dụng xác thực RSA sử dụng khóa chung / riêng để xác thực người dùng.
Kiểm tra hướng dẫn tuyệt vời này để biết các cách tiếp cận khác nhau (bao gồm xác thực RSA): http://www.la-samhna.de/l Library / bressessh.html
Tôi đang sử dụng giải pháp thứ 3 trên máy chủ của mình vì tôi không muốn làm cho nó trở nên phức tạp đối với những người dùng không có kỹ thuật của tôi: sử dụng iptablesđể hạn chế số lượng kết nối mỗi phút khiến các cuộc tấn công bruteforce không hiệu quả và không hiệu quả.
Đây là giải pháp tôi đang sử dụng:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Như đã đề cập ở đây : điều này sẽ cho phép ba kết nối cổng 22 từ bất kỳ địa chỉ IP cụ thể nào trong khoảng thời gian 60 giây và yêu cầu 60 giây không có nỗ lực kết nối tiếp theo trước khi tiếp tục cho phép kết nối lại. Tùy chọn --rttl cũng tính đến TTL của datagram khi khớp các gói, để nỗ lực giảm thiểu chống lại các địa chỉ nguồn giả mạo.
Như đã nêu trong hướng dẫn đã đề cập, tốt hơn là sử dụng danh sách trắng để tách người dùng đáng tin cậy khỏi các quy tắc sau:
iptables -N SSH_WHITELIST
sau đó thêm các máy chủ đáng tin cậy:
iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT
và sau đó thực hiện các quy tắc:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Tôi nhận được các cuộc tấn công ssh brute-force trên các máy chủ của mình với tỷ lệ 1 đến 2 mỗi ngày. Tôi đã cài đặt denyhosts (gói ubfox: denyhosts). Đây là một công cụ rất đơn giản nhưng hiệu quả cho mục đích đó: về cơ bản, nó quét định kỳ nhật ký của bạn để phát hiện các cuộc tấn công vũ phu và đặt IP từ nơi các cuộc tấn công này bắt nguồn vào tệp /etc/hosts.deny của bạn. Bạn sẽ không nghe thấy gì từ họ nữa và tải của bạn sẽ giảm đáng kể. Nó rất có thể cấu hình thông qua tập tin cấu hình /etc/denyhosts.conf để điều chỉnh các vấn đề như có bao nhiêu lần thử sai gây ra một cuộc tấn công, v.v.
Do hoạt động minh bạch của nó, bạn có thể dễ dàng nhìn thấy những gì đang diễn ra (thông báo qua email: 'aha, một cuộc tấn công khủng khiếp khác đã cản trở!') Và hoàn tác các lỗi do người dùng của bạn nhầm lẫn mật khẩu của họ.
Tất nhiên, mọi thứ trước đây đã nói về việc chuyển sang các phương thức xác thực khác nhưng đôi khi các yêu cầu của bạn không đồng ý với những người dùng của bạn.
Ngoài ra, giới hạn tốc độ kết nối mới trong iptables có thể là lựa chọn tốt hơn sau đó từ chối truy cập qua hosts.deny. Vì vậy, có một cái nhìn tại fail2ban là tốt. Nhưng nếu bạn biết rằng ssh brute-force là mối quan tâm chính của bạn (hãy xem qua /var/log/auth.log để xác định điều này), hãy sử dụng công cụ tác động thấp và rất dễ dàng này.
Mar 27 10:28:43 smartfood sshd[17017]: Failed password for root from 218.15.136.38 port 33119 ssh2 Mar 27 10:28:47 smartfood sshd[17019]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.15.136.38 user=rootchỉ ra một cuộc tấn công?
knockdđể thực hiện một hệ thống gõ cổngrecentvà hashlimitkết hợp để hạn chế các lần thử SSH liên tiếpTrước hết bạn nên cân nhắc việc không sử dụng mật khẩu và sử dụng khóa thay thế. Không cần sử dụng mật khẩu. Nếu điều này phù hợp với bạn, bạn có thể định cấu hình máy chủ OpenSSH không phản ứng khi đăng nhập mật khẩu.
https://help.ubfox.com/10.04/serverguide/C/openssh-server.html
Sử dụng fail2ban, cũng có thể là một tùy chọn.
Làm thế nào rộng rãi là máy chủ tiếp xúc trên mạng? Có lẽ bạn có thể nói chuyện với quản trị viên mạng và kiểm tra xem có thể giám sát và hạn chế truy cập mạng vào máy chủ không. Ngay cả khi thông tin đăng nhập tài khoản an toàn, có vẻ như máy chủ có thể bị tấn công DoS / DDoS đơn giản.
Một thay thế cho fail2ban là CSF: ConfigServer Security & Firewall .
Nó đi kèm với LFD: Daemon đăng nhập thất bại có thể phát hiện nhiều lần đăng nhập thất bại trên các dịch vụ khác nhau và sẽ chặn địa chỉ IP vi phạm (tạm thời hoặc vĩnh viễn).
Nó có một số tùy chọn khác có thể giúp chống lại các cuộc tấn công lũ lụt, và có thể phát hiện sự xâm nhập.
Nhược điểm:
Bạn có ý định cho phép dịch vụ SSH ra thế giới không? Hay chỉ để các thành viên trong nhóm ở những nơi cụ thể? Câu trả lời của tôi phụ thuộc một chút vào mức độ nghiêm trọng của thử thách của bạn.
Trong cả hai trường hợp, một điều bạn nên làm là đảm bảo rằng máy chủ SSH không cho phép đăng nhập mật khẩu cho người dùng root.
Trong các hệ thống của tôi, tôi đã có cài đặt này
PermitRootLogin without-password
nhưng tôi nhận thấy trong Ubuntu mới hơn họ có
PermitRootLogin prohibit-password
Nếu bạn đọc "man sshd_config" tôi nghĩ nó có nghĩa là "mật khẩu cấm" mới hơn này có nghĩa tương tự và chắc chắn rõ ràng hơn về ý nghĩa. Điều đó KHÔNG mặc định trên một số hệ thống Linux, nhưng có lẽ nên như vậy.
Bây giờ, về vấn đề của bạn. Có phải máy chủ hệ thống của bạn chỉ có một số người dùng ở những nơi cụ thể? Làm cái này!
chỉnh sửa /etc/hosts.deny và chèn
TẤT CẢ
Sau đó chỉnh sửa /etc/hosts.allow và liệt kê số IP hoặc phạm vi muốn cho phép sử dụng SSH. Ký hiệu có một chút khó hiểu vì nếu bạn muốn cho phép tất cả các hệ thống có số IP như 111.222,65.101 đến 111.222,65.255, bạn hãy đặt một mục như thế này trong hosts.allow
ALL: 127.0.0.1
sshd: 111.222.65.
sshdfwd-X11: 111.222.65.
Đó là một giải pháp mạnh mẽ, mạnh mẽ. Nếu người dùng của bạn có thể được liệt kê theo phạm vi IP, hãy làm điều đó!
Giải pháp này tồn tại trước khi các bảng IP được tạo, nó (tôi nghĩ) dễ quản trị hơn rất nhiều, nhưng nó không tốt bằng giải pháp bảng IP vì các thói quen của bảng IP sẽ phát hiện kẻ thù sớm hơn các chương trình được lưu trữ bởi host.allow và máy chủ lưu trữ .deny. Nhưng đây là một cách chắc chắn, cách đơn giản để giải quyết rất nhiều vấn đề, không chỉ từ SSH.
Lưu ý vấn đề bạn tạo ra cho chính mình. Nếu bạn muốn mở một máy chủ FTP, máy chủ web hoặc không có gì, bạn sẽ phải cho phép các mục trong máy chủ cho phép.
Bạn có thể đạt được mục đích cơ bản tương tự bằng cách đấu tranh với iptables và tường lửa. Theo một nghĩa nào đó, đây là một giải pháp ưa thích vì bạn đang chặn kẻ thù ở ranh giới bên ngoài. Ubuntu có "ufw" (tường lửa không phức tạp) và "man ufw" có rất nhiều ví dụ. Tôi muốn có một GUI đẹp để lội qua điều này, tôi không phải làm điều này mọi lúc. Có lẽ những người khác có thể cho chúng tôi biết nếu có một bây giờ.
Một nguồn thất vọng khác sẽ xảy ra khi một số người dùng tích lũy các khóa ssh khác nhau cho các máy chủ khác nhau. Vì tôi có khóa SSH cho khoảng 12 dự án khác nhau, hiện tại ssh không thành công vì tôi có quá nhiều khóa công khai (Yêu cầu "ssh -o PubkeyAuthentication = false" hoặc tạo một mục trong tệp .ssh / config. Đó là PITA)
Trong các hệ thống Centos Linux của chúng tôi, tôi nhận thấy họ đã bỏ gói denyhosts và chỉ cung cấp fail2ban. Tôi thích denyhosts vì nó đã xây dựng một danh sách các phạm vi người dùng / ip rắc rối và sau đó trong hosts.deny, danh sách đó đã được ghi chú. Chúng tôi đã cài đặt fail2ban thay vào đó và nó vẫn ổn. Tôi hiểu rằng bạn muốn chặn những người dùng xấu này ở rìa ngoài của máy chủ, vì vậy các trình chặn dựa trên bảng ip, như fail2ban, thực sự tốt hơn. Denyhosts hoạt động ở cấp độ thứ cấp, sau khi kẻ thù đã vượt qua iptables, chúng sẽ bị sshd từ chối.
Trong cả hai chương trình này, sẽ hơi tẻ nhạt khi đưa người dùng ra khỏi tù nếu họ quên mật khẩu và thử một vài lần để đăng nhập. Thật khó khăn để khiến mọi người quay lại khi họ mắc lỗi đăng nhập. Bạn đã đoán rằng sẽ có một GUI điểm và nhấp, nơi bạn có thể chỉ và cho phép mọi người quay lại, nhưng thực tế không phải vậy. Tôi chỉ phải làm điều này vài tháng một lần và quên đi giữa các lần, vì vậy tôi đã viết hướng dẫn cho chính mình trên trang web của mình http: //pj.freefacemony.org/blog/?p=602