Cách bảo mật máy chủ MySQL / MariaDB

Sau các cuộc tấn công vào cơ sở dữ liệu MongoDB, gần đây chúng ta cũng đã thấy rằng các máy chủ MySQL đang là mục tiêu của ransomware. Điều này không có gì đáng ngạc nhiên vì sự chấp nhận ngày càng tăng của các đám mây công cộng và riêng tư. Chạy một cơ sở dữ liệu được định cấu hình kém trong đám mây có thể trở thành một trách nhiệm chính.

Trong bài đăng trên blog này, chúng tôi sẽ chia sẻ với bạn một số mẹo về cách bảo vệ và bảo mật máy chủ MySQL hoặc MariaDB của bạn.

Hiểu vectơ tấn công

Trích dẫn SCMagazine:
“ Cuộc tấn công bắt đầu bằng việc ép buộc mật khẩu gốc cho cơ sở dữ liệu MySQL. Sau khi đăng nhập, cơ sở dữ liệu và bảng MySQL được tìm nạp. Sau đó, kẻ tấn công tạo một bảng mới có tên là 'WARNING' bao gồm địa chỉ email liên hệ, địa chỉ bitcoin và nhu cầu thanh toán. ”

Dựa trên bài báo, vectơ tấn công bắt đầu bằng cách đoán mật khẩu gốc MySQL thông qua phương thức brute-force. Tấn công vũ lực bao gồm một kẻ tấn công thử nhiều mật khẩu hoặc cụm từ mật khẩu với hy vọng cuối cùng đoán chính xác. Điều này có nghĩa là mật khẩu ngắn thường có thể được phát hiện khá nhanh, nhưng mật khẩu dài hơn có thể mất vài ngày hoặc vài tháng.

Brute-force là một cuộc tấn công phổ biến có thể xảy ra với bất kỳ dịch vụ nào. Thật không may cho MySQL (và nhiều DBMS khác), không có tính năng ngoại vi nào phát hiện và chặn các cuộc tấn công brute-force từ các địa chỉ cụ thể trong quá trình xác thực người dùng. Tuy nhiên, MySQL không nắm bắt được các lỗi xác thực trong nhật ký lỗi.

Xem lại chính sách mật khẩu của bạn

Xem lại chính sách mật khẩu MySQL luôn là bước đầu tiên để bảo vệ máy chủ của bạn. Mật khẩu gốc MySQL phải đủ mạnh với sự kết hợp của các bảng chữ cái, số và ký hiệu (khiến nó khó nhớ hơn) và được lưu trữ ở một nơi an toàn. Thay đổi mật khẩu thường xuyên, ít nhất mỗi quý theo lịch. Dựa trên vector tấn công, đây là điểm yếu nhất mà các hacker nhắm đến. Nếu bạn coi trọng dữ liệu của mình, đừng bỏ qua phần này.

Việc triển khai MySQL do ClusterControl thực hiện sẽ luôn tuân theo các phương pháp hay nhất về bảo mật của nhà cung cấp, chẳng hạn như sẽ không có máy chủ ký tự đại diện nào được xác định trong GRANT và thông tin đăng nhập nhạy cảm được lưu trữ trong tệp cấu hình chỉ được phép cho người dùng gốc của OS. Chúng tôi đặc biệt khuyến nghị người dùng của mình chỉ định một mật khẩu mạnh trong giai đoạn triển khai.

Trong môi trường sản xuất tiêu chuẩn, máy chủ cơ sở dữ liệu thường được đặt ở tầng cấp thấp hơn. Lớp này phải được bảo vệ và chỉ có thể truy cập từ lớp trên, chẳng hạn như ứng dụng hoặc bộ cân bằng tải. Nếu cơ sở dữ liệu được đặt chung với ứng dụng, bạn thậm chí có thể khóa các địa chỉ không phải cục bộ và thay vào đó sử dụng tệp socket MySQL (ít chi phí hơn và an toàn hơn).

Việc định cấu hình tham số "bind-address" là rất quan trọng ở đây. Lưu ý rằng liên kết MySQL được giới hạn cho không, một hoặc tất cả các địa chỉ IP (0.0.0.0) trên máy chủ. Nếu bạn không có lựa chọn nào khác và cần MySQL để lắng nghe tất cả các giao diện mạng, hãy hạn chế quyền truy cập vào dịch vụ MySQL từ các nguồn tốt đã biết. Sử dụng ứng dụng tường lửa hoặc nhóm bảo mật để chỉ quyền truy cập vào danh sách trắng từ các máy chủ cần truy cập trực tiếp vào cơ sở dữ liệu.

Đôi khi, máy chủ MySQL phải được tiếp xúc với mạng công cộng cho các mục đích tích hợp (ví dụ:giám sát, kiểm tra, sao lưu, v.v.). Điều đó ổn miễn là bạn vẽ một đường viền xung quanh nó. Đừng để các nguồn không mong muốn “nhìn thấy” máy chủ MySQL. Bạn có thể đặt cược rằng có bao nhiêu người trên thế giới biết 3306 là cổng mặc định cho dịch vụ MySQL và chỉ cần thực hiện quét cổng đối với địa chỉ mạng, kẻ tấn công có thể tạo danh sách các máy chủ MySQL bị lộ trong mạng con trong vòng chưa đầy một phút. Khuyên bạn nên sử dụng cổng MySQL tùy chỉnh bằng cách định cấu hình tham số "cổng" trong tệp cấu hình MySQL để giảm thiểu rủi ro phơi nhiễm.

Xem lại Chính sách Người dùng

Giới hạn một số người dùng nhất định nắm giữ các quyền quản trị quan trọng, đặc biệt là GRANT, SUPER và PROCESS. Bạn cũng có thể bật super_read_only nếu máy chủ là máy chủ, chỉ khả dụng trên MySQL 5.7.8 và Percona Server 5.6.21 trở lên (đáng tiếc là không có với MariaDB). Khi được kích hoạt, máy chủ sẽ không cho phép bất kỳ cập nhật nào, bên cạnh việc cập nhật kho lưu trữ nhân bản nếu nhật ký trạng thái nô lệ là bảng, ngay cả đối với người dùng có đặc quyền SUPER. Loại bỏ cơ sở dữ liệu thử nghiệm mặc định và bất kỳ người dùng nào có mật khẩu trống để thu hẹp phạm vi thâm nhập. Đây là một trong những hoạt động kiểm tra bảo mật do ClusterControl thực hiện, được triển khai như một cố vấn cơ sở dữ liệu.

Bạn cũng nên hạn chế số lượng kết nối được phép cho một tài khoản. Bạn có thể làm như vậy bằng cách đặt biến max_user_connections trong mysqld (mặc định là 0, bằng không giới hạn) hoặc sử dụng các tùy chọn kiểm soát tài nguyên trong câu lệnh GRANT / CREATE USER / ALTER USER. Câu lệnh GRANT hỗ trợ giới hạn số lượng kết nối đồng thời tới máy chủ bởi một tài khoản, ví dụ:

mysql> GRANT ALL PRIVILEGES ON db.* TO 'db_user'@'localhost' WITH MAX_USER_CONNECTIONS 2;

Tên người dùng quản trị viên mặc định trên máy chủ MySQL là "root". Tin tặc thường cố gắng giành quyền truy cập vào các quyền của nó. Để làm cho nhiệm vụ này khó hơn nhiều, hãy đổi tên "root" thành một cái gì đó khác. Tên người dùng MySQL có thể dài tối đa 32 ký tự (16 ký tự trước MySQL 5.7.8). Có thể sử dụng tên người dùng dài hơn cho người dùng quản trị cấp cao bằng cách sử dụng câu lệnh RENAME như được hiển thị bên dưới:

mysql> RENAME USER root TO new_super_administrator_username;

Một lưu ý nhỏ cho người dùng ClusterControl, ClusterControl cần biết người dùng gốc và mật khẩu MySQL để tự động hóa và quản lý máy chủ cơ sở dữ liệu cho bạn. Theo mặc định, nó sẽ tìm kiếm ‘root’. Nếu bạn đổi tên người dùng gốc thành một thứ khác, hãy chỉ định “monitor_mysql_root_user ={new_user}” bên trong cmon_X.cnf (trong đó X là ID cụm) và khởi động lại dịch vụ CMON để áp dụng thay đổi.

Chính sách sao lưu

Mặc dù các tin tặc tuyên bố rằng bạn sẽ lấy lại dữ liệu của mình sau khi tiền chuộc được trả, nhưng trường hợp này thường không xảy ra. Tăng tần suất sao lưu sẽ làm tăng khả năng khôi phục dữ liệu đã xóa của bạn. Ví dụ:thay vì sao lưu đầy đủ mỗi tuần một lần với sao lưu gia tăng hàng ngày, bạn có thể lập lịch sao lưu đầy đủ mỗi ngày một lần với sao lưu gia tăng hàng giờ. Bạn có thể thực hiện việc này một cách dễ dàng với tính năng quản lý sao lưu của ClusterControl và khôi phục dữ liệu của bạn nếu có sự cố.

Nếu bạn đã bật nhật ký nhị phân (binlog), điều đó thậm chí còn tốt hơn. Bạn có thể tạo một bản sao lưu đầy đủ mỗi ngày và sao lưu các bản ghi nhị phân. Binlog rất quan trọng đối với việc khôi phục tại thời điểm và nên được sao lưu thường xuyên như một phần của quy trình sao lưu của bạn. Các DBA có xu hướng bỏ lỡ phương pháp đơn giản này, có giá trị đến từng xu. Trong trường hợp nếu bạn bị tấn công, bạn luôn có thể khôi phục đến điểm cuối cùng trước khi nó xảy ra, miễn là tin tặc không xóa các bản ghi nhị phân. Lưu ý rằng chỉ có thể xóa nhật ký nhị phân khi kẻ tấn công có SUPER đặc quyền.

Một điều quan trọng nữa là các tập tin sao lưu phải được phục hồi. Xác minh các bản sao lưu mọi lúc, mọi nơi và tránh những bất ngờ xấu khi bạn cần khôi phục.

Bảo vệ máy chủ web / ứng dụng của bạn

Chà, nếu bạn đã cô lập các máy chủ MySQL của mình, vẫn có cơ hội cho những kẻ tấn công truy cập chúng thông qua máy chủ web hoặc ứng dụng. Bằng cách đưa một tập lệnh độc hại (ví dụ:Cross-Site Scripting, SQL injection) vào trang web mục tiêu, người ta có thể vào thư mục ứng dụng và có khả năng đọc các tệp ứng dụng. Chúng có thể chứa thông tin nhạy cảm, chẳng hạn, thông tin đăng nhập cơ sở dữ liệu. Bằng cách nhìn vào điều này, kẻ tấn công có thể chỉ cần đăng nhập vào cơ sở dữ liệu, xóa tất cả các bảng và để lại một bảng “đòi tiền chuộc” bên trong. Không nhất thiết phải là người dùng gốc MySQL để đòi tiền chuộc nạn nhân.

Có hàng nghìn cách để xâm phạm máy chủ web và bạn không thể thực sự đóng cổng gửi đến 80 hoặc 443 cho mục đích này. Một lớp bảo vệ khác là cần thiết để bảo vệ máy chủ web của bạn khỏi việc đưa vào dựa trên HTTP. Bạn có thể sử dụng Tường lửa ứng dụng web (WAF) như Apache ModSecurity, NAXSI (WAF cho nginx), WebKnight (WAF cho IIS) hoặc chỉ cần chạy các máy chủ web của bạn trong Mạng phân phối nội dung an toàn (CDN) như CloudFlare, Akamai hoặc Amazon CloudFront.

Luôn cập nhật

Bạn có thể đã nghe nói về khai thác MySQL zero-day quan trọng, nơi một người dùng không có đặc quyền có thể tự nâng cấp lên super user? Nghe có vẻ đáng sợ. May mắn thay, tất cả các nhà cung cấp được biết đến đều đã cập nhật kho lưu trữ của họ để bao gồm bản sửa lỗi cho vấn đề này.

Để sử dụng trong sản xuất, bạn nên cài đặt các gói MySQL / MariaDB từ kho lưu trữ của nhà cung cấp. Đừng dựa vào kho lưu trữ hệ điều hành mặc định, nơi các gói thường đã lỗi thời. Nếu bạn đang chạy trong môi trường cụm như Galera Cluster hoặc thậm chí MySQL Replication, bạn luôn có lựa chọn vá hệ thống với thời gian chết tối thiểu. Hãy biến việc này thành một thói quen và cố gắng tự động hóa quy trình nâng cấp nhiều nhất có thể.

ClusterControl hỗ trợ nâng cấp luân phiên phiên bản nhỏ (mỗi lần một nút) cho MySQL / MariaDB chỉ với một cú nhấp chuột. Việc nâng cấp các phiên bản chính (ví dụ:từ MySQL 5.6 lên MySQL 5.7) thường yêu cầu gỡ cài đặt các gói hiện có và việc tự động hóa là một nhiệm vụ rủi ro. Việc lập kế hoạch và kiểm tra cẩn thận là cần thiết cho loại nâng cấp như vậy.

Kết luận

Ransomware là một nồi vàng dễ kiếm. Chúng ta có thể sẽ thấy nhiều vi phạm bảo mật hơn trong tương lai và tốt hơn là bạn nên hành động trước khi điều gì đó xảy ra. Tin tặc đang nhắm mục tiêu vào nhiều máy chủ dễ bị tấn công ngoài kia, và rất có thể cuộc tấn công này cũng sẽ lây lan sang các công nghệ cơ sở dữ liệu khác. Bảo vệ dữ liệu của bạn là một thách thức thường xuyên đối với các quản trị viên cơ sở dữ liệu. Kẻ thù thực sự không phải là kẻ phạm tội mà là thái độ của chúng ta đối với việc bảo vệ tài sản quan trọng của mình.