Ngăn chặn các cuộc tấn công vũ phu vào MySQL?


9

Tôi cần bật mạng cho MySQLd, nhưng mỗi lần tôi làm như vậy, máy chủ sẽ bị ép buộc vào quên lãng. Một số kịch bản đoán mật khẩu có nghĩa là bắt đầu đập vào máy chủ, mở kết nối trên cổng 3306 và thử mật khẩu ngẫu nhiên mãi mãi.

Làm thế nào tôi có thể ngăn chặn điều này xảy ra?

Đối với SSH, tôi sử dụng denyhosts, hoạt động tốt. Có cách nào để làm cho denyhosts hoạt động với MySQLd không?

Tôi cũng đã xem xét việc thay đổi cổng mà MySQL đang chạy, nhưng điều này không lý tưởng và chỉ là giải pháp ngăn chặn (nếu họ phát hiện ra cổng mới thì sao?)

Có ai có ý tưởng nào khác?

Nếu nó khác, tôi đang chạy MySQL 5.x trên FreeBSD 6.x.

Câu trả lời:


9

Tôi không biết về bất kỳ gói phần mềm nào giống như denyhost cho MySQL, nhưng tôi có một vài giải pháp:

  • Giới hạn đăng nhập vào địa chỉ IP cụ thể. Không sử dụng% để cho phép tất cả các máy chủ kết nối với máy chủ.
  • Thậm chí an toàn hơn, thiết lập iptables để chỉ cho phép truy cập 3306 từ các địa chỉ IP được ủy quyền.
  • Đường hầm lưu lượng truy cập của bạn vào hộp với ssh sau đó kết nối qua localhost
  • Sửa đổi tập lệnh Denyhosts hoặc BFD để phân tích nhật ký truy cập mysql và chặn mọi nỗ lực vũ phu tại tường lửa

Chỉnh sửa :

Để trả lời bình luận của bạn, hãy thử điều này :

iptables -A INPUT -p tcp -s 202.54.1.50 --sport 1024:65535 -d 202.54.1.20 --dport 3306 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -s 202.54.1.20 --sport 3306 -d 202.54.1.50 --dport 1024

Trong đó .20 là MySQL của bạn và .50 là địa chỉ IP kết nối từ xa.


Một vài lưu ý: Làm cách nào tôi có thể hạn chế quyền truy cập vào cổng 3306 chỉ một bộ địa chỉ IP nhất định? Chỉ cần hạn chế người dùng MySQL không hoạt động, vì các máy từ xa vẫn có thể kết nối và vũ phu cho mật khẩu. Các đường hầm SSH có vẻ hơi bất tiện khi thiết lập cho người dùng cuối ... Bạn có ví dụ về IPTables khi làm việc này không?
Keith Palmer Jr.

2

1: Thay đổi cổng từ 3306. Không phải vì lý do bảo mật tốt hơn, nhưng để tải máy chủ để xử lý các cuộc tấn công đăng nhập sai

2: Tạo chứng chỉ SSL và kích hoạt nó trên máy chủ MySQL của bạn (dù sao cũng phải mã hóa kết nối máy chủ-máy khách của bạn)

3: Tạo một hoặc nhiều chứng chỉ ứng dụng khách (tất cả các máy khách cần phải có chứng chỉ và phần mềm máy khách cần được cấu hình để sử dụng nó). Nếu khách hàng của bạn là .Net, bạn cần chuyển đổi chứng chỉ ứng dụng khách sang định dạng pkcs12, nhưng điều đó dễ dàng thực hiện, xem hướng dẫn này ..

4: Đặt tài khoản người dùng MySQL để yêu cầu chứng chỉ ứng dụng khách x509, sau đó kẻ tấn công đều cần thông tin đăng nhập VÀ chứng chỉ ứng dụng khách (thậm chí bạn có thể đặt mật khẩu vào chứng chỉ ứng dụng khách, sau đó kẻ tấn công cũng cần phải yêu cầu điều đó).

Tôi đã sử dụng hướng dẫn này để tạo các chứng chỉ và tệp chính nhưng có nhiều hướng dẫn ngoài kia.

Tôi chỉ thích sử dụng kết nối SSH của mình để truy cập vào hộp linux của mình cho mục đích quản trị, không phải cho truy cập máy khách.


Cảm ơn câu trả lời. Tôi đã sử dụng hướng dẫn này để thực hiện # 2, 3 và 4: digitalocean.com/community/tutorials/iêu
ofri cofri

1

Sử dụng MySQL Proxy, bạn có thể viết một tập lệnh LUA nhỏ có kết hợp người dùng / vượt qua nhưng đợi X giây để xử lý đăng nhập nếu yêu cầu kết nối đến từ dải IP không được chấp thuận.

Ngoài ra, bạn có thể thêm một chút logic bổ sung vào tập lệnh LUA vào danh sách đen trong phạm vi IP sau ba lần thử thất bại.

Nói chung, về mặt kỹ thuật là có thể thực hiện được, nhưng tôi sẽ thực hiện các đề xuất khác để chuyển qua SSH hoặc VPN sang một dải IP chung, được liệt kê trong danh sách trắng (thông qua FW hoặc các phương tiện khác).


+1 sử dụng khác cho MySQL Proxy :)
Andy

0

tại sao không cho phép truy cập vào cổng mysqld từ các máy chủ an toàn?


Tôi đã xem xét điều này, nhưng điều đó có nghĩa là tôi phải theo dõi các thay đổi địa chỉ IP cho hơn 1000 khách hàng. Đó sẽ là một cơn đau khổng lồ ở mông ... Làm thế nào tôi có thể làm điều này? Nó không giúp khóa chúng trong MySQL, bởi vì chúng vẫn có thể kết nối với máy chủ MySQL, nhưng thực tế không chọn bất kỳ cơ sở dữ liệu nào ...
Keith Palmer Jr.

1
trích dẫn trình kéo dave ở trên: "Sửa đổi tập lệnh Denyhosts hoặc BFD để phân tích nhật ký truy cập mysql và chặn mọi nỗ lực vũ phu trên tường lửa" có vẻ là ý tưởng tốt nhất hoặc sử dụng một số mật khẩu chữ tượng hình :)
quaie

0

Mặc dù đây không phải là câu trả lời "thực sự" - tôi không biết tại sao bạn cần trực tiếp đưa nó ra thế giới bên ngoài.

Bạn không thể kích hoạt ssh trên hộp đó và sử dụng đường hầm để truy cập công cụ db?

Hoặc bất kỳ giải pháp VPN nào khác để truy cập nó (openvpn hiện lên trong tâm trí).


0

Không phải là một giải pháp thực sự cho vấn đề, nhưng nó có thể hữu ích nếu bạn chỉ chạy máy chủ trên một cổng khác. Hầu hết các bot quét có thể được lập trình để chỉ kiểm tra 3306. Nó sẽ không giải quyết được vấn đề, nhưng có lẽ bạn sẽ nhận được ít lần quét hơn chỉ bằng cách thay đổi cổng.


-1 để bảo mật bằng cách che khuất
thepocketwade

@thepocketwade - Đó là lý do tại sao tôi nói nó không phải là một giải pháp thực sự cho vấn đề. Nhưng nó vẫn có thể hữu ích.
Eric Petroelje

0

Tôi tin rằng các kết nối nên được tường lửa: nhanh chóng và tốt đẹp. Có rất nhiều hướng dẫn cho iptables và bất cứ điều gì :)

Ngoài ra, bạn có thể cài đặt một cronjob trên máy chủ của khách hàng sẽ chạy smth trên máy chủ để ngăn tường lửa chặn các máy chủ đã biết.


0

sử dụng ssh cho các đường hầm sẽ là tốt nhất nhưng bạn có thể thử sử dụng fail2ban thay vì denyhosts vì tôi nghĩ rằng nó nhằm mục đích giám sát các ứng dụng khác nhau hơn nên không nên thêm nhật ký mysql vào đó.


0

Đề xuất xem xét cho phần my.cnf-ini [mysqld] của bạn

max_connect_errors=10  # to limit hacker/cracker attempts to guess a password.

để tránh hàng trăm lần thử trong 90 giây. Cắt chúng ra sau 10 lần thử.

Hãy xem xét một lần một ngày FLIP HOSTS để xóa những người hợp pháp đang cố gắng sử dụng hệ thống của bạn mà KHÔNG THỂ nhớ mật khẩu của họ. Có thể trong một vài ngày, họ sẽ nhận được với nó.

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.