Trước đây thường làm linux là chủ yếu, dạo sang công ty X có làm chút với MS. Trước cứ nghĩ Linux bá chủ thế giới server nhưng suy nghĩ nó lại là “sai lầm”. Đi không dưới mười tổ chức Enterprise hay GOV (bé có, lớn có) chỗ nào cũng có ít thì 10 server nhiều thì 700-800 servers windows. Điểm chung là tổ chức nào dù bé dù to kiểu gì cũng có vài con Active Directory (AD). Ai làm với Windows nhiều hẳn biết con này quan trọng như thế nào rồi (có nó làm gì cũng được) nhưng đôi khi lại ít được chú ý bảo vệ. Thành thử hay bị hack hiếc. Nguyên nhân bị hack đôi khi không hẳn là attacker sử dụng những kỹ thuật quá “cao siêu” mà chỉ là chút cầu thả/sai sót của quản trị viên nên “vẽ đường cho trâu chạy”. Bữa nay lang thang mạng đọc được vài bài viết khá tâm đắc, nhiều lỗi cá nhân nhiều khi cũng gặp phải. Mọi người thử đọc và check lại mình coi có mắc không (Nhiều lỗi cũng không chỉ có ai làm Windows mới mắc đâu nhé :d).

Local Administrator của Server hay Workstation không được quản lý (Dùng chung mật khẩu mặc định)

Chung (Không chỉ Windows): Nhiều đơn vị hay có thói quen đặt mật khẩu quy ước. Ví dụ kiểu: [email protected] (@123). Mật khẩu này rất dễ bị thử khi bruteforce. Cũng có trường hợp ông nhân viên nào vô tình push code dev/fun lên github (nghĩ là vô hại) thế là xong mật khẩu này bị public cho toàn thiên hạ. Chưa kể người mới vào cũ ra, nhiều năm mật khẩu chung vẫn thế nhiều năm không đổi gì. Thành thói quen, anh truyền em tiếp khó mà biết được rồi sẽ đi về đâu.

Riêng (Windows): Các công ty hay có thói quen ghost hoặc clone server. Sau này bung ghost hoặc clone xong, PC/Server join Domain thì chỉ còn dùng user domain nên cũng chả ai quan tâm tới user local Administrator này nữa. Thế là tất cả PC/Server user local Administrator nghiễm nhiên có một mật khẩu mặc định chung muôn kiếp không đổi. Đồng nghĩa với việc một máy bị compromise, mật khẩu local Administrator bị mất (vd bị dump chả hạn). Compromise one =(to)=> Compromise all them.

Mật khẩu yếu (Cái này quá quen thuộc nhưng vẫn phải nhắc lại)

Mật khẩu yếu - cái này ai cũng biết rồi. Chỉ xin nhắc lại với ý là độ dài mật khẩu quá ngắn, nội dung không đủ phức tạp hoặc dễ đoán. Kiểu hay mắc phải là @123, @123, ... Kiểu này spray thực tế thì cả tá gặp phải và rất dễ bị thịt.

Để các Account Domain Admins có Service Principal Name (SPN)

Khái niệm SPN cũng là khá mới đối với mình (nay đọc mới biết). SPN có thể hiểu là một ID cho một object khi sử dụng kerberos authen. Kerberos là phương thức authen/author chủ yếu dùng cho việc cấp quyền sử dụng dịch vụ. Hồi còn đi học suốt ngày làm mấy bài tập đậm chất lý thuyết kiểu thầy đề xuất một kerberos authen flow yêu cầu chỉ ra điểm yếu có thể bị khai thác, kiểu sửa nội dung ticket để nâng quyền (escalate privilege) hoặc tái sử dụng ticket (replay attack). Quay lại vấn đề với các account Admin thông thường chỉ để quản trị, không chạy dịch vụ chả có lý gì sử dụng kerberos authen. Tốt nhất nên tắt đi. Có nhiều kiểu khai thác dựa trên phương thức authen/author này. Thực tế bạn có thể đọc về kiểu tấn công golden ticket attack hay cve ms 14 - 068.

Service account luôn add vào nhóm Privilege group (Domain Admins, Enterpise Admins, Administrators AD)

Privilege group là các nhóm có quyền rất to trên Actice Directory. Service account (User dùng để kết nối dịch vụ với AD) đôi khi cần một số quyền nhất định để có thể hoạt động nhưng nhiều khi quản trị viên không biết xác định nó cần quyền gì nên thường default bỏ nó vào privelege group luôn để khỏi phải suy nghĩ.

Tuy nhiên thực tế cho thấy rằng hiếm khi service account cần nằm trong nhóm privilege account mà chỉ cần một số quyền nhất định. Ví dụ xác thực ldap thông thường chỉ cần quyền query AD là đủ. Ấy vậy mà cá nhân đi làm việc không ít lần gặp ở các tổ chức người ta bỏ user xác thực ldap vào nhóm Domain Admins. Hệ quả là khi một hệ thống bên thứ 3 bị tấn công, account kết nối bị mất thì coi như AD cũng bị mất luôn.

Điều cần ghi nhớ cần gì cấp nấy. Chỉ cố gắng cấp vừa đủ dùng mà thôi.

Password cũ nhiều năm không đổi,

Câu chuyện có thể là một user thuộc nhóm quản trị tồn tại rất lâu mà không ai dám chạm vào vì ai cũng nghĩ chả biết ông admin trước có dùng nó để làm gì đó đặc biệt không ( vd: tiện tay dùng luôn nó kết nối dịch vụ chả hạn). Dẫn tới việc nó cứ tồn tại năm này qua năm khác trên hệ thống mà không hề được thay đổi mật khẩu. Dĩ nhiên cho đến khi nó bị lợi dụng để tấn công hệ thống mới chịu đổi.

Đặc biệt trên AD có một user là krbtgt. User này mặc định bị disable trên hệ thống AD. Khi user này được tạo nó sẽ có một mật khẩu sinh ngẫu nhiên và mật khẩu này tồn tại mãi mãi (nếu ta không đổi). Theo MS mật khẩu của nó coi như là info scret chung để các bên encrypt các keberos ticket khi giao tiếp. Trường hợp mật khẩu này bị lộ có thể bị lợi dụng để sửa kerberos ticket để nâng quyền - Mà bảo nghe đâu mật khẩu này thường khá đơn giản và hay bị lợi dụng. Nó xảy ra thường xuyên tới mức mà người ta đặt hẳn một kiểu tấn công (khá phổ biến) là golden ticket.

Domain controller setup auditing ở mức “minimum”

Thông thường nếu bạn để GPO ở dạng Default, các cấu hình audit của AD ở mức tối thiểu. Việc để nó ở dạng tối thiểu sẽ làm bạn dễ dàng bị miss các event quan trọng trong hệ thống. Điều này đồng nghĩa với việc bạn có thể bỏ lỡ cơ hội phát hiện được các hành vi nguy hại trên hệ thống. Giảm khả năng phát hiên sớm và miss các thông tin quan trọng khi forensic khi sự cố xảy ra.

Thói quen sửa Default GPO mức global

Có nhiều bạn hay sửa GPO mặc định (Default GPO). Điều này là hoàn toàn không nên. Các GPO mặc định có các cấu hình chuẩn phục vụ cho hoạt động của AD. Việc sửa nó sẽ làm hệ thống rối tinh rối mù. Trong trường hợp cấu hình không như ý muốn, khi bạn muốn rollback cấu hình thì việc trở nên khó khăn vì bạn không thể nhớ nổi bạn đã edit cái nào và mặc định nó thế nào. Chưa kể việc edit này sẽ apply các cấu hình rộng quá ở mức cần thiết gây ra các nguy cơ về security.

Cách làm khôn khéo là không sờ gì vào GPO mặc định, luôn tạo ra các GPO của riêng bạn. Như vậy khi có nhỡ tay gì đó muốn rollback thì chỉ cần disable hoặc unlink GPO của mình là xong. Gần như chả phải suy nghĩ gì cả việc làm thay đổi hệ thống.

Cho phép user được phép Edit GPO trên DC

Lỗi này khá hiếm gặp, tuy nhiên không phải là không có. Bạn phải luôn nhớ rằng các server Domain Controller (DC) trên hệ thống AD là vô cùng quan trọng, chỉ duy nhất Admin mới được phép Edit GPO trên DC mà thôi, ngoài ra không một ai khác được phép có quyền đó cả. Nghĩa là không được phép gán quyền này cho bất cứ ai. Vì có quyền edit GPO thì có thể làm được rất nhiều thứ từ việc add người dùng vào server, thay đổi cấu hình toàn bộ hệ thống AD.

Delegate quyền bừa bãi

Delegate quyền quản lý OU trên AD là một task thường gặp với hầu hết quản trị viên AD để thực hiện share một số quyền quản lý OU cho một user. Tuy nhiên rất hiếm khi ta có thói quen kiểm tra lại đã delegate quyền gì và delegate này cho ai, xem có thừa hay thiếu gì không. Kết quả là một khi đã delegate thì chả mấy khi kiểm tra lại và rule đó cứ tồn tại ngày này qua ngày khác. Hãy nhớ rằng đừng quên định kỳ kiểm tra lại việc delegate trên hệ thống AD của bạn.

Một hình thức tấn công khá phổ biến là AdminSDHolder để persistance perm trên hệ thống AD. Việc kiểm tra lại perm định kỳ ngoài ra sẽ giúp bạn tránh được nguy cơ bị tấn công loại này.

Dùng GPO hoặc log on/out scrip để change mật khẩu local Admin

Nhiều sysadmin hay có thói quen dùng GPO hoặc logon script để change local Admin. Việc này tiềm ẩn nguy cơ rất lớn vì tất cả các user trong miền đều có thể đọc được thông tin này. Một khi mật khẩu này bị mất thì hầu như toàn bộ các máy đều bị chiếm quyền (Vì rất nhiều máy ăn GPO này). Do vậy không bao giờ được phép thực hiện việc này.

Microsoft có public một giải pháp LAPS. Có thể sử dụng nó để quản lý local Admin. Các bản có thể tham khảo solution này.

Trên đây là các vấn đề mà khá nhiều Sysadmin gặp phải. Theo tôi đó là những thói quen không tốt cần phải thay đổi. Hãy nhớ rằng chỉ sơ ý chút thôi là hệ thống của bạn đã có thể bị chiếm quyền rồi, hacker đôi khi chả cần những kỹ thuật gì cao siêu cả mà chỉ nắm thóp dựa vào chút sơ hở của bạn thôi.