Tài khoản SA và các tên tài khoản đã biết khác có mối đe dọa bảo mật nào?

Có một tên tài khoản được biết đến như sa, gây ra mối đe dọa bảo mật cho cơ sở dữ liệu? Khi sử dụng xác thực windows trên SQL Server, nó có áp dụng chính sách mật khẩu tương tự không (nếu nó được đặt thành khóa tài khoản sau 5 lần)?

Có một tên tài khoản được biết đến như sa, gây ra mối đe dọa bảo mật cho cơ sở dữ liệu?

Tài khoản người dùng "thượng đế" có tên được biết đến thường được coi là một ý tưởng tồi tệ hơn so với người dùng thần có tên ít được biết đến. Nó làm cho các cuộc tấn công vũ phu dễ dàng hơn một chút vì kẻ tấn công chỉ phải đoán mật khẩu chứ không phải tên người dùng và mật khẩu.

Ngoài ra có một người dùng thần dù sao cũng có thể nguy hiểm. Nói chung, bạn nên có những người dùng cụ thể với các quyền cụ thể cho những gì họ cần làm. Loại bảo mật dựa trên đặc quyền này dễ thực hiện từ đầu hơn là trang bị thêm vào môi trường của bạn sau này.

Vô hiệu hóa sa và cung cấp cho người dùng cụ thể quyền quản trị cụ thể khi cần trong máy chủ SQL về cơ bản là cùng một khuyến nghị như vô hiệu hóa rootvà trao quyền quản trị khi cần thông qua sudoLinux và tương tự. Bạn luôn có thể bật salại một khi được kết nối trực tiếp với máy với các đặc quyền đầy đủ nếu có bất cứ điều gì sai và cuối cùng bạn sẽ bỏ tất cả các quyền mà người dùng của bạn cần để vận hành (và khắc phục sự cố) giống như bạn có thể thiết kế quyền truy cập root vào Linux nếu bạn có quyền truy cập vật lý vào hộp - vì vậy, vô hiệu hóa tài khoản không phải là viên đạn ma thuật (nhưng một khi kẻ tấn công có quyền truy cập vật lý vào máy của bạn hoặc truy cập Quản trị đầy đủ thông qua RDC hoặc SSH, tất cả các cược đều bị tắt).

Khi sử dụng xác thực windows trên SQL Server, nó có áp dụng chính sách mật khẩu tương tự không (nếu nó được đặt thành khóa tài khoản sau 5 lần)?

Khi sử dụng Windows xác thực tích hợp Máy chủ SQL không có quyền kiểm soát khóa tài khoản và như vậy - nó chỉ ánh xạ người dùng Windows sang người dùng SQL và yêu cầu HĐH xác nhận thực tế rằng người dùng đã cung cấp thông tin xác thực phù hợp. Đối với người dùng tương tác, điều này có nghĩa là bất kỳ khóa nào sẽ xảy ra khi người dùng cố gắng xác thực với Windows, chứ không phải khi họ đăng nhập vào SQL Server.

Một ý tưởng không tồi là làm cho nó để người dùng quản trị mặc định (admin / root / postgres / sa / etc) không thực sự tồn tại trong hệ thống của bạn. Bạn luôn có thể tạo một tài khoản đặc quyền dưới một tên khác.

Nếu không có gì khác, mọi người cố gắng khai thác hệ thống của bạn sẽ không dễ dàng như thể họ đang làm việc mù (ví dụ, tiêm sql mà không có vỏ tương tác cũng như không thể thấy đầu ra trực tiếp từ các lệnh của họ)

Đối với khóa tài khoản - nếu ai đó quản lý đủ xa để thậm chí có thể cố gắng đăng nhập vào máy của bạn, trừ khi bạn đặc biệt cho phép đăng nhập trực tiếp từ người dùng, bạn đã thua trận. Cá nhân, tôi không ủng hộ việc khóa phần lớn, vì phần lớn cho phép ai đó tạo ra sự từ chối dịch vụ nếu họ quản lý để có được tên của bất kỳ người dùng nào của bạn. (và có họ khóa siêu người dùng? không vui vẻ).

Tôi khuyên bạn nên xem qua các Điểm chuẩn CIS ... họ không có chúng cho mọi cơ sở dữ liệu, nhưng họ có các đề xuất cho Oracle, MS SQL, DB2 và MySQL. Nếu bạn đang chạy một cái gì đó khác, nó vẫn đáng để xem qua các loại chung mà họ đề xuất.

Tôi đã không thấy ai khác đề cập đến điều này vì vậy tôi sẽ thêm nó. Với SQL Server 2005+ nếu máy chủ của bạn là một phần của tên miền và tên miền có chính sách mật khẩu, bạn có thể cho phép chính sách mật khẩu được thi hành trên thông tin đăng nhập SQL. Điều này bao gồm các yêu cầu phức tạp về mật khẩu và khả năng buộc thay đổi mật khẩu khi đăng nhập.

Lưu ý rằng đôi khi điều này có thể gây ra sự cố với một số trình cài đặt phần mềm chưa được cập nhật để hoạt động với SQL 2005+ và tạo thông tin đăng nhập SQL bằng mật khẩu không an toàn.

Có hai chế độ xác thực được sử dụng trong SQL Server: xác thực Windows và chế độ hỗn hợp (cho phép cả xác thực Windows và xác thực SQL Server)

Chế độ đầu tiên ít bị tổn thương hơn trước các cuộc tấn công vũ phu vì kẻ tấn công có khả năng chạy vào khóa đăng nhập (tính năng Chính sách khóa tài khoản) sau một số lần tấn công hữu hạn. Mọi môi trường sản xuất, nếu sử dụng chế độ Xác thực Windows, nên sử dụng tính năng chính sách khóa, vì nó khiến các cuộc tấn công vũ phu không thể thực hiện được

Khi nói đến lỗ hổng tấn công brute-force xác thực SQL Server, tình hình không mấy thuận lợi. Xác thực Máy chủ SQL không có tính năng nào cho phép phát hiện khi hệ thống bị tấn công vũ phu. Hơn nữa, SQL Server rất nhạy khi xác thực thông tin xác thực SQL Server. Nó có thể dễ dàng xử lý các nỗ lực đăng nhập lặp đi lặp lại, hung hăng, mạnh mẽ mà không có hiệu suất tổng thể tiêu cực có thể chỉ ra các cuộc tấn công như vậy. Điều này có nghĩa là Xác thực Máy chủ SQL là một mục tiêu hoàn hảo để bẻ khóa mật khẩu thông qua các cuộc tấn công vũ phu

Ngoài ra, các phương thức brute-force đang phát triển với mỗi phương thức mã hóa và mật khẩu phức tạp mới được giới thiệu. Ví dụ: những kẻ tấn công sử dụng các bảng cầu vồng (các bảng được tính toán trước để đảo ngược các giá trị băm mật mã cho mọi tổ hợp ký tự có thể) có thể dễ dàng và nhanh chóng bẻ khóa bất kỳ mật khẩu băm nào

Để bảo vệ Máy chủ SQL của bạn khỏi các cuộc tấn công vũ phu, bạn nên xem xét các điều sau:

• Không sử dụng chế độ Xác thực Máy chủ SQL - buộc kẻ tấn công nhấn khóa đăng nhập thông qua Xác thực Windows
• Trong trường hợp bạn cần sử dụng chế độ Xác thực Máy chủ SQL, hãy tắt hoặc xóa thông tin đăng nhập SA - theo cách đó, kẻ tấn công phải đoán và ghép cả tên người dùng và mật khẩu

Tài khoản sa, khi được kích hoạt có thể làm bất cứ điều gì trên SQL Server. Nếu kẻ tấn công xâm nhập vào tài khoản này, họ có thể làm bất cứ điều gì trên phiên bản SQL Server (và có thể là hệ điều hành máy chủ) mà họ muốn.

SA (và các tên tài khoản nổi tiếng khác) là những điểm nổi tiếng mà tin tặc có thể tấn công. Một số mật khẩu của Oracle được ghi lại kém và do đó mật khẩu mặc định không phải lúc nào cũng thay đổi. Khi bạn đã kiểm soát tài khoản SA trong SQL Server, bạn sẽ kiểm soát máy chủ mà nó đang chạy và có thể chạy bất kỳ mã nào hoặc cài đặt bất cứ thứ gì bạn muốn. Trong những ngày cao bồi hơn, tôi nhớ là không được phép (cần giấy tờ tôi sẽ không điền) để cài đặt điều khiển ActiveX trên máy chủ web cũng lưu trữ SQL Server - vì vậy tôi đã sử dụng xp_cmdshell để sao chép và cài đặt điều khiển .