Category Archives: Network Security

Secure Socket Layer – SSL (Phần 3): Giải pháp bảo mật cho website với SSL

Tiếp nối phần 2, ở bài viết tiếp theo này tôi xin giới thiệu đến các bạn các phương pháp xây dựng hệ thống Web Server xác thực bằng SSL.

Secure Socket Layer – SSL (Phần 1): Tổng quan và cấu trúc SSL

Secure Socket Layer – SSL (Phần 2): Các giao thức bảo mật SSL.

Các loại chứng chỉ dùng cho SSL

Khi triển khai SSL, có hai loại chứng chỉ có thể được dùng là:

  • Chứng chỉ cho Web server: một Web server muốn áp dụng SSL thì bắt buộc phải có loại chứng chỉ này. Nó được dùng để mã hóa khóa pre-master được Web client gửi cho Web server và đồng thời giúp xác minh nhận dạng của Web server để Web client có thể tin tưởng rằng đó không phải là Web server giả mạo được kẻ tấn công dựng lên. Chứng chỉ của Web server phải bao gồm Server Authentication OID trong extension Enhanced Key Usage.
  • Chứng chỉ cho Web client: Khi một Website yêu cầu người dùng kết nối tới nó phải được xác thực thì Web client có thể sử dụng loại chứng chỉ này. Tuy các kết nối SSL không ép buộc điều này nhưng nó giúp tăng độ an toàn cho Web server trong trường hợp chỉ cho phép những người dùng được xác thực (Web client của họ được cài loại chứng chỉ này) kết nối tới nó. Chứng chỉ của Web client phải bao gồm Client Authentication OID trong extension Enhanced Key Usage.

Chọn nhà cung cấp chứng chỉ SSL cho Web server

Việc lựa chọn sẽ nhận chứng chỉ cho Web server từ đâu (CA nào) thường dựa trên việc xem xét các Web client thuộc nội bộ hay bên ngoài tổ chức. Các client nội bộ là nhân viên hoặc đối tác mà có thể có hoặc không được cấp các tài khoản dùng trong mạng của tổ chức. Các client bên ngoài thường là các khách hàng mà không được cấp các tài khoản dùng trong mạng của tổ chức.

Thường một CA riêng tư (private CA) được xây dựng để cấp chứng chỉ cho các Web server nội bộ khi:

  • Tổ chức phải tuân thủ các chính sách an ninh và chính sách chứng chỉ do họ đề ra. Trong khi đó, một chứng chỉ do một CA thương mại (như Verisign) cấp yêu cầu tổ chức phải tuân theo tập các chỉ dẫn trong CPS của CA đó.
  • Tổ chức muốn giảm chi phí mua chứng chỉ từ các CA thương mại vì các Web server chỉ cần chấp nhận các kết nối từ các nhân viên và những đối tác được tin cậy khác là đủ. Trong trường hợp này, các nhân viên và đối tác được yêu cầu phải tin cậy và cài đặt chứng chỉ của các CA của tổ chức.

Thường một CA thương mại (commercial CA) được chọn để cấp chứng chỉ cho các Web server của tổ chức khi:

  • Tổ chức không muốn triển khai một hạ tầng PKI nội bộ để giảm chi phí cho việc thiết kế, triển khai và quản lý CA và các chứng chỉ.
  • Tổ chức sử dụng Website để bán hàng hóa và cung cấp các dịch vụ qua Internet cho nhiều đối tượng khách hàng khác nhau, và các CA thương mại mặc định đã được tin cậy bởi hầu hết các Web client. Điều này vì vậy mang lại sự thuận tiện và đảm bảo cho các giao dịch điện tử.
  • Tổ chức muốn triển khai chứng chỉ EV (Extended Validation) để thanh địa chỉ của Web browser sẽ chuyển sang màu xanh và có tên của tổ chức ở bên trái. Điều này nói lên rằng CA thương mại đã bỏ thêm tài nguyên và thời gian để xác minh người sở hữu chứng chỉ SSL của website thực sự là đại diện của tổ chức. Cũng vì vậy mà chứng chỉ EV luôn mắc hơn các chứng chỉ loại thông thường.

Thanh địa chỉ của các Web browser cho biết Website sử dụng một EV certificate

Xác định vị trí đặt chứng chỉ của Web server

Việc lựa chọn vị trí triển khai chứng chỉ cho Web server phụ thuộc vào cấu hình mạng của tổ chức. Dưới đây là hai trường hợp thường gặp.

  • Với một Web server

Nếu chỉ có một Web server hoạt động thì hiển nhiên chứng chỉ phải được đặt tại Web server đó như được thể hiện trong Hình dưới đây:

  • Với một nhóm các Web server

Ở cấu hình gom nhóm này, website có thể nằm trên ổ đĩa dùng chung bởi nhiều máy chủ hoặc mỗi máy chủ có ổ đĩa riêng để lưu trữ bản sao của website. Trong mỗi trường hợp thì khi người dùng kết nối tới một URL nào đó thì họ được chuyển hướng tới bất kỳ máy chủ nào trong cụm các máy chủ (cluster). Đây là cơ chế căn bằng tải cho lưu lượng mạng (Network Load Balancing) như được thể hiện trong Hình dưới đây:

Khi đó mỗi Web server trong cluster sẽ phải có một chứng chỉ SSL của riêng nó. Yêu cầu duy nhất là trường subject name của chứng chỉ cần trùng với tên miền mà Web client sử dụng để kết nối tới website.

Một sự hiểu nhầm thường gặp là cho rằng các Web server trong cluster phải có một chứng chỉ SSL cùng với khóa bí mật giống nhau. Thực ra nếu mua các chứng chỉ cho từ các tổ chức thương mại như VeriSign hay RSA thì rất có thể họ yêu cầu khách hàng cần các chứng chỉ khác nhau cho mỗi Web server.

  • Web Server được bảo vệ bởi ISA Server với cấu hình Server Publishing

Khi áp dụng cấu hình Server Publishing trong ISA Server thì tất cả các lưu lượng kết nối tới cổng TCP 443 mà ISA Server đang lắng nghe trên đó sẽ được chuyển hướng tới Web server nằm đằng sau firewall này:

Trong cấu hình này, chứng chỉ SSL phải được cài đặt tại Web server. Tên miền trong trường Subject của chứng chỉ phải khớp với tên miền mà Web client dùng để kết nối tới giao tiếp mạng ngoài (external interface) của ISA Server. Nói cách khác, tên miền này phải được phân giải thành địa chỉ IP được gán cho card giao tiếp mạng ngoài của ISA Server. Dạng cấu hình này được cũng được hỗ trợ bởi nhiều firewall phổ biến khác của Cisco hay Checkpoint. Như vậy, yêu cầu được thỏa mãn là triển khai mã hóa dữ liệu được truyền giữa giữa hai điểm đầu cuối là Web server và Web client.

  • Web Server được bảo vệ bởi ISA Server với cấu hình Web Publishing

Khi áp dụng cấu hình Web Publishing, dữ liệu mà ISA Server tiếp nhận từ Web client sẽ được giải mã và kiểm duyệt bằng các bộ lọc ở tầng ứng dụng (ví dụ, URL Scanning) để phát hiện những lưu lượng Web có thể là mã độc hoặc các dạng tấn công Web khác. Có hai lựa chọn để sử dụng SSL với cấu hình Web Publishing là:

a.Triển khai SSL cho kết nối giữa hai điểm đầu cuối (End-to-End SSL)

Ở đây, SSL được thực hiện giữa Web client và ISA Server cũng như là giữa ISA Server và Web server.

Hai chứng chỉ SSL khác nhau phải được cài đặt ở cả ISA Server và Web server và hai kết nối SSL tách biệt được thiết lập là:

  1. Kết nối SSL đầu tiên xảy ra giữa Web client và ISA Server. Trường Subject của chứng chỉ được cài tại ISA Server phải chứa tên miền mà Web client sử dụng để kết nối tới Web server, và tên miền này phải được phân giải thành địa chỉ IP mặt ngoài của ISA Server.
  2. Kết nối SSL thứ hai xảy ra giữa ISA Server và Web server. Trường Subject của chứng chỉ được cài tại Web server phải chứa tên miền hoặc địa chỉ IP giống với thiết lập Web Publishing tại ISA Server.

b. Triển khai SSL giữa Web client và ISA Server

Kết nối SSL chỉ được thực hiện giữa Web client và ISA Server.

Chỉ cần một chứng chỉ SSL được cài đặt tại ISA Server. Lưu lượng HTTPS từ Web client sau khi được giải mã và kiểm duyệt bởi bộ lọc tầng ứng dụng của ISA Server sẽ được chuyển tới Web server dưới dạng HTTP (không được mã hóa) thông thường.

Ở đây, trường Subject của chứng chỉ của Web server phải chứa tên miền mà Web client dùng để kết nối tới Web server và tên miền này phải được phân giải thành địa chỉ IP mặt ngoài của ISA Server.

Lựa chọn mẫu chứng chỉ

Mẫu chứng chỉ Web Server mặc định sẽ đáp ứng nhu cầu của hầu hết các tổ chức muốn triển khai SSL cho các máy chủ Web nội bộ. Thay đổi duy nhất phải được thực hiện là chỉnh lại quyền hạn của mẫu chứng chỉ này để cho phép quyền Read và Enroll được gán cho universal hoặc global group mà chứa các tài khoản người dùng quản trị Web server.

Cấp phát chứng chỉ cho máy chủ Web

Các lựa chọn để cấp chứng chỉ từ một Windows Server-based Enterprise CA là:

  • Cấp chứng chỉ cho các máy chủ web chạy IIS nằm trong domain.
  • Cấp chứng chỉ cho các máy chủ web chạy IIS không nằm trong domain.
  • Cấp chứng chỉ cho các máy chủ web không phải IIS như Apache, Lighthttpd, v.v..
Advertisements

VPN và SSH: Đâu là sự lựa chọn tối ưu???

Cả VPN và SSH đều cho phép truyền lưu lượng mạng qua một kết nối bảo mật. Chúng có những điểm tương tự nhưng cũng có những điểm khác nhau. Nếu bạn đang phân vân nên sử dụng kỹ thuật nào thì bài viết sẽ giúp bạn hiểu rõ phương thức hoạt động của từng công nghệ.

Một đường hầm SSH thường giống như một VPN đơn giản do giao thức cũng có thể mang đến một số tính năng giống như VPN mà không cần quá trình thiết lập server quá phức tạp. Tuy vậy, SSH vẫn có một vài hạn chế.

VPN

VPN hay mạng riêng ảo, được dùng để kết nối các mạng riêng tư qua mạng công cộng. Trường hợp điển hình dùng VPN là một doanh nghiệp có thể có một mạng riêng có dữ liệu chia sẻ, những máy in nối mạng và những thứ quan trọng khác trên đó. Một số nhân viên có thể đi du lịch và thường xuyên phải truy cập những tài nguyên này từ xa. Tuy vậy, doanh nghiệp không muốn để lộ các tài nguyên quan trọng của công ty một cách công khai trên Internet. Thay vào đó, doanh nghiệp có thể thiết lập một VPN server để nhân viên ở xa có thể kết nối vào VPN công ty. Khi một nhân viên được kết nối tới VPN server, máy tính của họ trở thành một bộ phận của mạng doanh nghiệp. Họ có thể truy cập lấy dữ liệu và những tài nguyên khác giống như có kết nối vật lý trực tiếp tới mạng cục bộ.

 

Máy khách VPN kết nối tới VPN server thông qua mạng Internet và truyền toàn bộ lưu lượng mạng của máy qua một kết nối an toàn, nghĩa là các đối thủ cạnh tranh không thể can thiệp vào kết nối và xem những thông tin kinh doanh nhạy cảm. Tùy thuộc vào VPN mà toàn bộ lưu lượng mạng được gửi qua VPN hay chỉ một phần lưu lượng nào đó có thể được gửi (tuy vậy, thường thì tất cả lưu lượng mạng được thiết lập đi qua VPN). Nếu toàn bộ lưu lượng duyệt web được truyền qua VPN, những người ở phía giữa máy khách VPN và VPN server không thể can thiệp vào lưu lượng duyệt web. Điều này mang đến sự bảo vệ thông tin khi sử dụng các mạng Wi-Fi công cộng và cho phép người dùng truy cập về mặt địa lý các dịch vụ bị hạn chế, chẳng hạn như, nhân viên có thể vượt qua kiểm duyệt Internet nếu họ đang làm việc từ một quốc gia kiểm duyệt web. Với những website mà nhân viên truy cập thông qua VPN thì lưu lượng duyệt web sẽ trả về máy khách VPN như thể được xuất phát từ VPN server.

 

Một điều quan trọng nữa là, VPN hoạt động nhiều ở mức hệ điều hành hơn là mức ứng dụng. Nói cách khác, khi người dùng thiết lập một kết nối VPN, hệ điều hành có thể định tuyến tất cả lưu lượng mạng qua nó từ tất cả các ứng dụng (mặc dù điều này có thể thay đổi từ VPN tới VPN, phụ thuộc vào cách VPN được cấu hình). Họ sẽ không phải cấu hình cho mỗi ứng dụng một cách riêng biệt.

SSH

SSH hay secure shell không chỉ được thiết kế để chuyển tiếp lưu lượng mạng. Thường thì SSH được dùng để nhận dữ liệu một cách an toàn và sử dụng một phiên đầu cuối từ xa, nhưng SSH còn có những chức năng khác. SSH cũng sử dụng phương pháp mã hóa có tính bảo mật cao và người dùng có thể thiết lập máy khách SSH thành một SOCKS proxy. Sau đó, ta có thể cấu hình ứng dụng trên máy tính như trình duyệt web chẳng hạn để sử dụng SOCKS proxy. Lưu lượng đi vào SOCKS proxy đang chạy trên hệ thống cục bộ và máy khách SSH chuyển tiếp nó qua kết nối SSH. Quá trình này được gọi là SSH Tunneling. Nó hoạt động tương tự như quá trình duyệt web qua VPN tức, lưu lượng web trả về như là đến từ SSH server. Lưu lượng truyền giữa máy tính và SSH server được mã hóa bảo mật vì vậy người dùng có thể duyệt web qua một kết nối mã hóa bảo mật như là với VPN.

 

Tuy nhiên, một đường hầm SSH không mang lại nhiều lợi ích như một kết nối VPN. Không giống với VPN, người dùng phải cấu hình cho mỗi một ứng dụng để sử dụng proxy của đường hầm SSH. Với VPN, toàn bộ lưu lượng sẽ được gửi thông qua VPN nhưng điều này chưa chắc đúng với một đường hầm SSH. Hệ điều hành sẽ hành xử như thể người dùng nằm trên mạng đầu xa trong trường hợp sử dụng VPN, nghĩa là việc kết nối dữ liệu chia sẻ trên Windows sẽ dễ dàng. Việc này tương đối khó hơn với một đường hầm SSH.

Kỹ thuật nào bảo mật hơn?

Nếu bạn lo lắng về kỹ thuật nào bảo mật hơn để áp dụng cho doanh nghiệp thì câu trả lời rõ ràng là VPN. Bạn có thể đẩy toàn bộ lưu lượng mạng trên hệ thống qua nó. Tuy nhiên, nếu chỉ muốn một kết nối được mã hóa bảo mật để lướt web từ các mạng Wi-Fi công cộng trong quán cafe, sân bay… thì cả VPN và SSH khả dĩ do chúng đều có phương pháp mã hóa có tính bảo mật cao.

Ở một khía cạnh khác, người dùng mới có thể dễ dàng kết nối tới một VPN nhưng việc thiết lập VPN server thì phức tạp hơn. SSH mặt khác là thiết lập đơn giản hơn. Trên thực tế, rất nhiều người sẽ có một SSH server để họ truy cập từ xa. Nếu bạn đã truy cập vào một SSH server thì việc thiết lập một đường hầm SSH đơn giản hơn nhiều so với thiết lập cho một VPN server. Vì lý do này mà SSH được gọi là VPN “nghèo”.

Những doanh nghiệp đang trông đợi vào kỹ thuật mạng mạnh mẽ hơn sẽ muốn đầu tư vào VPN. Mặt khác, SSH tunnel là một cách dễ dàng để mã hóa lưu lượng cho người dùng đơn lẻ có truy cập SSH server. Và phương pháp mã hóa bảo mật của nó cũng tốt như ở VPN.

Kết luận, VPN sẽ là giải pháp hoàn hảo cho những doanh nghiệp đang tìm kiếm một kỹ thuật mạng an toàn trong khi SSH lại phù hợp với người dùng cá nhân có quyền truy cập SSH server. Tuy vậy, hai kỹ thuật này đều sử dụng phương pháp mã hóa có tính bảo mật dữ liệu rất cao.

Null Session – Phương thức tấn công và cách phòng chống

Khi đăng nhập vào hệ điều hành, quá trình chứng thực xẩy ra, nó yêu cầu người dung cung cấp username và password để tiến hành chứng thực. Sau quá trình chứng thực, một danh sách truy cập – ACL – được tải về để xác định quyền hạn của user đăng nhập. Nó một cách khác, quá trình đó tạo cho user một phiên làm việc rõ ràng. Tuy nhiên, có những dịch trong hệ điều hành được kích hoạt tự chạy, với một user ẩn danh nào đó, chẳng hạn như SYSTEM USER. Loại user này không cần có password, và nó được dùng để khởi chạy các dịch vụ. Nó không được dùng để đăng nhập, nhưng được dùng để sử dụng một số dịch vụ. Khi bạn dùng loại user này để đăng nhập, bạn bị rơi vào trạng thái Null Session.

Null Session, hay được gọi là IPC$ trên máy chủ nền tảng Windows, là một dạng kết nối nặc danh tới một mạng chia sẻ cho phép người dùng trong mạng truy cập tự do.

Tấn công Null Session đã xuất hiện kể từ khi Windows 2000 được sử dụng rộng rãi. Tuy nhiên, hình thức tấn công này không được các quản trị viên hệ thống chú ý khi áp dụng các biện pháp bảo mật mạng. Điều này có thể dẫn đến kết cục khôn lường vì tin tặc có thể sử dụng hình thức tấn công này để lấy mọi thông tin hữu dụng cần thiết để giành quyền truy cập từ xa vào hệ thống. Mặc dù không còn mới mẻ, nhưng tấn công Null Session vẫn phổ biến và nguy hiểm như những năm trước đây. Xét về một khía cạnh nào đó, mặc dù khả năng bảo mật của các hệ thống hiện đại không phải quá yếu nhưng khi thực hiện các cuộc thử nghiệm xâm nhập trên máy tính Windows thì kết quả cho thấy Null Session vẫn là một trong những hình thức cần lưu ý.

Phương thức hoạt động của Null Session

Một phiên truy cập từ xa được tạo lập khi người dùng đăng nhập từ xa vào một máy tính sử dụng một tên người dùng và mật khẩu có quyền truy cập vào tài nguyên hệ thống. Tiến trình đăng nhập này được thực hiện qua giao thức SMB (Server Message Block) và dịch vụ Windows Server. Những kết nối này hoàn toàn hợp pháp khi những thông tin đăng nhập chính xác được sử dụng.

Một Null Session xảy ra khi người dùng thực hiện kết nối tới một hệ thống Windows mà không sử dụng tên người dùng hay mật khẩu. Hình thức kết nối này không thể thực hiện trên bất kỳ hình thức chia sẻ Windows thông thường nào, tuy nhiên lại có thể thực hiện trên chia sẻ quản trị IPC (Interprocess Communication). Chia sẻ IPC được các tiến trình của Windows sử dụng (với tên người dùng là SYSTEM) để giao tiếp với các tiến trình khác qua mạng này. Chia sẻ IPC chỉ được giao thức SMB sử dụng.

Chia sẻ không yêu cầu thông tin đăng nhập IPC thường được sử dụng cho những chương trình giao tiếp với một chương trình khác, tuy nhiên không có gì đảm bảo rằng người dùng không thể kết nối tới một máy tính bằng kết nối IPC này. Kết nối IPC không chỉ cho phép truy cập không giới hạn vào máy tính, mà còn trao quyền truy cập vào tất cả các máy tính trên mạng, và đây là những gì mà tin tặc cần để xâm nhập hệ thống.

Phương thức tấn công sử dụng Null Session

Giờ đây chúng ta đã biết cách thức hoạt động của Null Session, tuy nhiên ‘liệu tin tặc có thể sử dụng hình thức tấn công này dễ dàng hay không?’ Câu trả lời là ‘khá dễ dàng’. Kết nối Null Session có thể được thiết lập trực tiếp từ một lệnh Windows mà không cần sử dụng công cụ bổ sung, đó chính là lệnh NET. Lệnh NET có thể thực hiện nhiều chức năng quản trị, khi sử dụng lệnh này chúng ta có thể tạo một kết nối tới một chia sẻ tiêu chuẩn trên máy chủ đích, tuy nhiên kết nối này sẽ thất bại do những thông tin đăng nhập không chính xác.

Kết nối thất bại vào một mạng chia sẻ sử dụng lệnh NET.

Khi sử dụng lệnh NET, chúng ta có thể thay đổi tên chia sẻ kết nối tới chia sẻ quản trị IPC$. Khi đó kết quả sẽ khả quan hơn.

Kết nối Null Session thành công với lệnh NET.

Lúc này, chúng ta đã thiết lập một kết nối Null Session tới máy tính nạn nhân. Tuy nhiên, chúng ta vẫn chưa có quyền truy cập quản trị trên máy tính này do đó chưa thể bắt đầu duyệt tìm ổ cứng hay lấy mật khẩu. Cần nhớ rằng, chia sẻ IPC được sử dụng để giao tiếp giữa các tiến trình, do đó quyền truy cập của chúng ta sẽ bị giới hạn xuống quyền truy cập của tên người dùng SYSTEM. Chúng ta có thể sử dụng lệnh NET để lấy nhiều thông tin hơn từ máy tính mục tiêu, tuy nhiên có nhiều công cụ tự động hóa sẽ thực hiện các công việc rắc rối này.

Hacking Tool

Null Session có thể dễ dàng tấn công với công cụ có sẵn trong windows như Net, Netview.

Tuy nhiên, như đã trình bày ở trên, chúng ta cần một quá trình phúc tập hơn để làm được nhiều việc, như liệt kê thư mục, user…Công cụ Nbtstat và NBTEnum sẽ giúp chúng ta thực hiện hàng loạt các công việc phức tạp, để cuối cùng chúng ta xâp nhập được vào hệ thống. Dumpsec Superscan là hai công cụ đồ họa hổ trợ thực hiện các công việc này.

Chống tấn công bằng Null Session

Khi nghĩ đến tin tặc và các cuộc tấn công, có lẽ câu hỏi đầu tiên thường được nghĩ đến đó là ‘liệu hệ thống của chúng ta có điểm yếu hay không?’ Câu trả lời phụ thuộc vào hệ điều hành trên môi trường mạng. Nếu đang sử dụng hệ điều hành Windows XP, Windows Server 2003 hay Windows 2000, thì ở một mức độ nào đó câu trả lời là “có”. Hình thức tấn công này khó có thể thực hiện khi người dùng sử dụng các phiên bản hệ điều hành cao hơn, tuy nhiên Windows XP và Windows Server 2003 vẫn là những hệ điều hành được ưa chuộng nhất. Có một số phương pháp khác mà chúng ta có thể thực hiện để chặn Null Session.

Chặn Null Session trong Registry

Khả năng tương thích của những phần mềm hợp pháp cùng với thực tế rằng hầu hết doanh nhiệp phải gắn bó với các hệ điều hành cũ để thắt chặt ngân sách là hai lý do chính khiến máy trạm và máy chủ Windows 2000 vẫn tồn tại. Nếu vẫn sử dụng Windows 2000, chúng ta chỉ cần thực hiện một thay đổi nhỏ trong Registry là có thể chặn khả năng lấy thông tin sử dụng Null Session.

Khi truy cập vào Regedit và duyệt tìm tới key HKLM/System/CurrentControlSet/Control/LSA/RestrictAnonymous, chúng ta có thể cấu hình 3 tùy chọn bao gồm:

  • 0 – Cài đặt mặc định. Truy cập Null Session không giới hạn.
  • 1 – Không những loại bỏ Null Session mà còn chặn hiển thị tên người dùng và các chia sẻ.
  • 2 – Loại bỏ mọi giá trị tới Null Session bằng cách chặn mọi truy cập.

Như chúng ta thấy, Null Session không thể bị loại bỏ hoàn toàn, tuy nhiên, khả năng truy cập của nó sẽ bị giới hạn nếu lựa chọn tùy chọn cài đặt là 2. Cần thận trọng khi cấu hình tùy chọn này trên máy chủ Windows 2000 vì có thể làm hỏng Clustering.

Trên Windows XP và Windows Server 2003, chúng ta có thể thực hiện tác vụ tương tự trong ba Registry Key:

HKLMSystemCurrentControlSetControlLsaRestrictAnonymous

HKLMSystemCurrentControlSetControlLsaRestrictAnonymousSAM

HKLMSystemCurrentControlSetControlLsaEveryoneIncludesAnonymous

Khóa các port truy cập

Nếu không thể thực hiện các thay đổi trong các Registry Key được nhắc đến ở trên, thì chúng ta có thể chặn mọi truy cập với Windows Firewall hay Network Firewall. Tiến trình này có thể được thực hiện bằng cách chặn truy cập tới các cổng liên quan tới NetBIOS và SMB thông qua TCP/IP. Những cổng này bao gồm:

  • Cổng TCP 135.
  • Cổng UDP 137.
  • Cổng UDP 138.
  • Cổng UDP 139.
  • Cổng TCP và UDP 445.

Những cổng này được sử dụng cho mọi chức năng kết nối mạng của Windows, bao gồm chia sẻ File, in ấn qua mạng, Clustering, và quản trị từ xa.

Lưu ý: Tiến trình chặn truy cập tới cổng cần được cân nhắc kỹ trước khi thực hiện trên nhiều cổng.

Xác định Null Session với IDS

Nếu những thay đổi trong Registry hay Firewall loại bỏ chức năng của các ứng dụng mạng thì chúng ta phải sử dụng một phương pháp khác. Thay vì chặn thống kê qua Null Session, một trong những biện pháp hữu hiệu nhất đó là phát hiện ra tấn công Null Session một cách sớm nhất để có thể triển khai những biện pháp khắc phục kịp thời như khi thực hiện một sự kiện bảo mật mạng thông thường.

Nếu đang sử dụng Snort, một IDS/IPS (Hệ thống phát hiện và chặn xâm nhập mạng) phổ biến nhất hiện nay trong môi trường sản xuất, thì rule sau đây sẽ phát hiện thống kê Null Session:

alert tcp $EXTERNAL_NET any -> $HOME_NET 139 (msg:”NETBIOS NT NULL session”; flow:to_server.establshed;

content: ‘|00 00 00 00 57 00 69 00 6E 00 64 00 6F 00 77 00 73 00 20 00 4E 00 54 00 20 00 31 00 33 00 38 00 31|’; classtype:attempted-recon;)

Rule này sẽ không ngăn chặn các kết nối Null Session, tuy nhiên nó sẽ thông báo khi Null Session xảy ra.

Nâng cấp hệ điều hành

Giải pháp cuối cùng như đã đề cập ở trên là nâng cấp hệ điều hành. Null Session chỉ dễ dàng thực hiện với hệ điều hành đời cũ trước năm 2000. Còn sau đó như Windows XP, Windows 2003 thì việc này đã được Microsoft tích hợp trong sản phẩm. Do đó, nâng cấp hệ điều hành làm chúng ta yên tâm hơn.

%d bloggers like this: