Tôi có nên hiển thị Active Directory của mình với Internet công cộng cho người dùng từ xa không?


46

Tôi có một khách hàng có lực lượng lao động gồm toàn bộ nhân viên từ xa sử dụng kết hợp PC / máy tính xách tay của Apple và Windows 7.

Người dùng hiện không xác thực đối với một tên miền, nhưng tổ chức muốn di chuyển theo hướng đó vì nhiều lý do. Đây là những máy thuộc sở hữu của công ty và công ty tìm cách kiểm soát việc hủy kích hoạt tài khoản, chính sách nhóm và ngăn ngừa mất dữ liệu nhẹ (vô hiệu hóa phương tiện từ xa, USB, v.v.) Họ lo ngại rằng cần phải xác thực VPN để truy cập AD sẽ cồng kềnh, đặc biệt là ở giao lộ của một nhân viên bị chấm dứt và thông tin đăng nhập được lưu trữ trên một máy từ xa.

Hầu hết các dịch vụ trong tổ chức đều dựa trên Google (thư, tệp, trò chuyện, v.v.) vì vậy các dịch vụ tên miền duy nhất là DNS và xác thực cho Cisco ASA VPN của họ.

Khách hàng muốn hiểu lý do tại sao không thể chấp nhận việc đưa bộ điều khiển miền của họ ra công chúng. Bên cạnh đó, những gì một cấu trúc miền chấp nhận hơn đối với một lực lượng lao động từ xa phân phối?

Biên tập:

Centrify được sử dụng cho một số ít khách hàng Mac.


4
Có một câu hỏi liên quan TẠI ĐÂY . Cho phép các dịch vụ bên ngoài kết nối với AD của bạn để đồng bộ hóa hoặc xác thực không phải là một cách làm tồi tệ nhưng việc đặt các bộ điều khiển miền của bạn trên một DMZ mở, về cơ bản như bạn đã hỏi là rất không an toàn. Không có bảo mật tại chỗ, bạn đang yêu cầu một loạt các cuộc tấn công và các vấn đề tiềm năng. Tôi đặc biệt khuyên bạn nên chống lại nó và đề xuất một máy khách VPN hoặc VPN từ tường lửa như Sonicwall với người dùng thiết bị cục bộ.
Mike Naylor

10
Thiết lập VPN dựa trên chứng chỉ luôn luôn bật, toàn máy, tự động kết nối lại. (OpenVPN, DirectAccess, v.v.) để xác thực VPN không bị ràng buộc với tài khoản người dùng và người dùng không có tương tác trực tiếp với phần mềm VPN.
Zoredache

DA là hoàn hảo, nhưng có các yêu cầu điểm cuối nghiêm trọng mà khách hàng không đáp ứng (chắc chắn là Mac.)
mfinni

1
+10 - Đối với đề xuất của Zoredache.
Evan Anderson

7
Nếu bạn đang sao lưu thiết bị người dùng cuối, bạn đang làm sai. Nếu bạn đang sao lưu thiết bị của người dùng cuối qua USB thì bạn đang thực sự sai.
MDMarra

Câu trả lời:


31

Tôi đang đăng bài này dưới dạng câu trả lời chủ yếu vì mọi người đều có "ý kiến ​​giáo dục" của riêng họ dựa trên kinh nghiệm, thông tin của bên thứ 3, tin đồn và kiến ​​thức bộ lạc trong CNTT, nhưng đây là danh sách các trích dẫn và bài đọc "trực tiếp" từ Microsoft. Tôi đã sử dụng dấu ngoặc kép vì tôi chắc chắn rằng họ không lọc đúng tất cả các ý kiến ​​của nhân viên của mình, nhưng điều này sẽ chứng minh sự hữu ích dù sao bạn là người sau khi authoritativetham khảo trực tiếp từ Microsoft.


BTW, tôi cũng nghĩ rằng RẤT DỄ DÀNG khi nói DOMAIN CONTROLLER == HOẠT ĐỘNG TRỰC TIẾP, điều này không hoàn toàn đúng. Proxy AD AD và các phương tiện khác (biểu mẫu dựa trên auth cho OWA, EAS, v.v.) cung cấp một cách để "phơi bày" chính AD trên web để cho phép khách hàng ít nhất cố gắng xác thực qua AD mà không cần lộ DC. Truy cập trang OWA của ai đó và cố gắng đăng nhập và AD sẽ nhận được yêu cầu xác thực trên DC phụ trợ, do đó, AD bị "lộ" về mặt kỹ thuật ... nhưng được bảo mật thông qua SSL và được ủy quyền thông qua máy chủ Exchange.


Trích dẫn số 1

Hướng dẫn triển khai Windows Server Active Directory trên Windows Azure Virtual Machines

Trước khi bạn đi "Azure không phải là AD" ... bạn CÓ THỂ triển khai ADDS trên máy ảo Azure.

Nhưng để trích dẫn các bit có liên quan:

Không bao giờ phơi nhiễm STS trực tiếp với Internet.

Để thực hành bảo mật tốt nhất, hãy đặt các phiên bản STS phía sau tường lửa và kết nối chúng với mạng công ty của bạn để tránh tiếp xúc với Internet. Điều này rất quan trọng vì vai trò STS phát hành mã thông báo bảo mật. Do đó, chúng phải được xử lý với cùng mức độ bảo vệ như bộ điều khiển miền. Nếu một STS bị xâm phạm, người dùng độc hại có khả năng phát hành các mã thông báo truy cập có khả năng chứa các khiếu nại về việc họ chọn dựa vào các ứng dụng của đảng và các STS khác trong các tổ chức tin cậy.

ergo ... không để bộ điều khiển miền trực tiếp lên internet.

Trích dẫn số 2

Active Directory - Bí ẩn UnicodePwd của AD LDS

Việc tiếp xúc với bộ điều khiển miền với Internet thường là một thực tế tồi tệ, cho dù việc tiếp xúc đó đến trực tiếp từ môi trường sản xuất hay thông qua mạng vành đai. Cách thay thế tự nhiên là đặt máy chủ Windows Server 2008 với vai trò Active Directory Light Directory Services (AD LDS) chạy trong mạng vành đai.

Trích dẫn số 3 - không phải từ MS ... nhưng vẫn hữu ích khi nhìn về phía trước

Active Directory-as-a-Service? Azure, Intune gợi ý về một tương lai AD được lưu trữ trên đám mây

Cuối cùng, không có câu trả lời "ngắn" tuyệt vời nào đáp ứng mục tiêu loại bỏ văn phòng của máy chủ AD để đổi lấy một sự thay thế Azure. Mặc dù Microsoft đang tự mãn trong việc cho phép khách hàng lưu trữ các dịch vụ miền Active Directory trên các máy chủ Server 2012 và 2008 R2 trong Azure, tính hữu dụng của chúng chỉ tốt như kết nối VPN mà bạn có thể tập hợp được cho nhân viên của mình. DirectAccess, trong khi một công nghệ rất hứa hẹn, bị trói tay do những hạn chế đáng tiếc của chính nó.

Trích dẫn số 4

Triển khai AD DS hoặc AD FS và Office 365 với đăng nhập một lần và Windows Azure Virtual Machines

Bộ điều khiển miền và máy chủ AD FS không bao giờ được tiếp xúc trực tiếp với Internet và chỉ có thể truy cập thông qua VPN


Đây là một câu trả lời hợp lý, mặc dù chỉ trích dẫn đầu tiên nói bất cứ điều gì về những điều tồi tệ có thể xảy ra nếu bạn bỏ qua lời khuyên.
Casey

19

Active Directory (AD) không được thiết kế cho loại triển khai đó.

Các mô hình mối đe dọa được sử dụng trong thiết kế của sản phẩm giả định triển khai "phía sau tường lửa" với một số lượng tác nhân thù địch được lọc ở biên giới mạng. Mặc dù bạn chắc chắn có thể làm cứng Windows Server để tiếp xúc với mạng công cộng, nhưng chức năng chính xác của Active Directory đòi hỏi một tư thế bảo mật được quyết định lỏng lẻo hơn so với máy chủ được tăng cường cho các mạng phải đối mặt. Rất nhiều dịch vụ phải được đưa ra từ Bộ điều khiển miền (DC) để AD hoạt động chính xác.

Đề xuất của Zoredache trong các bình luận, đặc biệt là tham khảo một cái gì đó như OpenVPN đang chạy dưới dạng xác thực w / chứng chỉ dịch vụ trên toàn máy, có thể rất phù hợp. DirectAccess, như những người khác đã đề cập, chính xác là những gì bạn cần, ngoại trừ việc nó không có hỗ trợ đa nền tảng mà bạn muốn.

Bên cạnh đó: Tôi đã từng có ý tưởng sử dụng IPSEC ở chế độ vận chuyển dựa trên chứng chỉ để hiển thị AD trực tiếp trên Internet nhưng thực sự không bao giờ có thời gian để thực hiện. Microsoft đã thực hiện các thay đổi trong khung thời gian Windows Server 2008 / Vista được cho là khả thi nhưng tôi chưa bao giờ thực sự thực hiện nó.


2
+1 cho OpenVPN hoạt động như một dịch vụ, tôi đã sử dụng phương pháp này với các chiến binh đường phố thành công trong quá khứ. Mặc dù có nhiều cảm xúc lẫn lộn từ các quản trị viên Sr sys, đặc biệt bởi vì nếu một máy bị xâm nhập thì đó là một cửa hậu tự động vào mạng. Tất nhiên mối quan tâm hợp lệ, đối với từng môi trường mặc dù phải tự hỏi liệu lợi ích có cao hơn rủi ro không ....?
MDMoore313

2
Microsoft điều hành mạng công ty riêng của họ trên Internet công cộng với IPSec. Vì vậy, nó có thể làm được.
Michael Hampton

1
@MichaelHampton nhưng họ sử dụng cách ly miền với Windows Firewall và IPSec nên nó không hoàn toàn là "AD trên Internet", đó là "AD trên internet và trong vùng bảo mật tương tự như tường lửa sẽ cung cấp sử dụng quy tắc tường lửa dựa trên máy chủ"
MDMarra

2
@ MDMoore313 - FTW thu hồi chứng chỉ, mặc dù người dùng cần báo cáo rằng máy bị đánh cắp một cách nhanh chóng.
Evan Anderson

Cũng có nhiều cách với một số máy khách VPN nhất định (ví dụ Juniper) để buộc đăng xuất sau khi kết nối. Nó không đẹp như GINA cũ đã truyền, nhưng nó buộc người dùng phải đăng nhập lại trong khi trên VPN để xác thực với AD và nhận GPO, v.v. Bạn đăng nhập trước bằng thông tin lưu trữ được lưu trữ, khởi chạy VPN nếu cần và nó đăng xuất bạn ngay lập tức và duy trì kết nối trong khi bạn đăng nhập lại.
TheCleaner

15

Những gì mọi người khác nói. Tôi đặc biệt lo lắng về những nỗ lực vũ phu mà Christopher Karel đã đề cập. Một bài thuyết trình tại Def Con cuối cùng là về chủ đề:

Vì vậy, bạn nghĩ rằng bộ điều khiển miền của bạn là an toàn?

JUSTIN HENDRICKS KỸ SƯ AN NINH, MICROSOFT

Bộ kiểm soát miền là viên ngọc quý của một tổ chức. Một khi họ rơi, mọi thứ trong miền rơi xuống. Các tổ chức nỗ lực hết sức để bảo mật bộ điều khiển miền của họ, tuy nhiên họ thường không bảo mật chính xác phần mềm được sử dụng để quản lý các máy chủ này.

Bài trình bày này sẽ đề cập đến các phương pháp độc đáo để có được quản trị viên tên miền bằng cách lạm dụng phần mềm quản lý thường được sử dụng mà các tổ chức triển khai và sử dụng.

Justin Hendricks làm việc trong nhóm bảo mật Office 365, nơi anh tham gia vào nhóm đỏ, thử nghiệm thâm nhập, nghiên cứu bảo mật, xem xét mã và phát triển công cụ.

Tôi chắc rằng bạn có thể tìm thấy rất nhiều ví dụ khác. Tôi đã tìm kiếm các bài viết về bộ điều khiển miền và hack với hy vọng có được một mô tả về việc DC sẽ được tìm thấy nhanh như thế nào, v.v., nhưng tôi nghĩ rằng điều đó sẽ làm ngay bây giờ.


1
Đây là video giới thiệu của ông Hendricks: youtube.com/watch?v=2d_6jAF6OKQ Tôi đã muốn xem video DefCon 21 và tôi nghĩ tôi sẽ bắt đầu với video này.
Evan Anderson

14

Nếu bạn đang cố gắng thuyết phục quản lý, một khởi đầu tốt sẽ là:

It goes against Microsoft's Best Practices for Active Directory Deployment.

Cập nhật : Xem bài viết kỹ thuật này về bảo vệ bộ điều khiển miền chống lại cuộc tấn công và phần có tiêu đề Perimeter Firewall Restrictions:

Perimeter firewalls should be configured to block outbound connections
from domain controllers to the Internet. 

Và phần có tiêu đề Blocking Internet Access for Domain Controllers:

Launching web browsers on domain controllers should be prohibited not only
by policy, but by technical controls, and domain controllers should not be
permitted to access the Internet

Tôi chắc chắn rằng bạn có thể đánh trống một số tài liệu của Microsoft về vấn đề này, vì vậy đó là. Ngoài ra, bạn có thể nêu các mối nguy hiểm của việc di chuyển như vậy, một cái gì đó dọc theo dòng:

A gaping hole would be created, possibly resulting in severe data loss and/or loss of company secrets.

Thông tin lưu trữ được lưu trữ chỉ là - lưu trữ. Chúng hoạt động cho máy cục bộ khi không thể kết nối với miền , nhưng nếu tài khoản đó bị vô hiệu hóa, chúng sẽ không hoạt động cho bất kỳ tài nguyên mạng nào (svn, vpn, smb, fbi, cia, v.v.) nên họ không cần lo lắng về điều đó . Ngoài ra, hãy nhớ rằng người dùng đã có toàn quyền đối với bất kỳ tệp nào trong thư mục hồ sơ của họ trên máy cục bộ (và có thể là phương tiện có thể tháo rời) để thông tin đăng nhập bị vô hiệu hóa hoặc họ không thể làm những gì họ muốn với dữ liệu đó. Chúng cũng không hoạt động cho máy cục bộ khi nó kết nối lại với mạng.

Bạn đang đề cập đến các dịch vụ mà Active Directory hoặc Bộ kiểm soát miền cung cấp, chẳng hạn như LDAP? Nếu vậy, LDAP thường được chia ra một cách an toàn cho mục đích xác thực và truy vấn thư mục, nhưng chỉ cần tắt Tường lửa Windows (hoặc mở tất cả các cổng cần thiết cho công chúng - Điều tương tự trong ví dụ này) có thể gây ra sự cố nghiêm trọng.

AD không thực sự quản lý máy Mac, do đó sẽ cần một giải pháp riêng biệt (nghĩ OS X Server). Bạn có thể tham gia máy Mac vào một tên miền nhưng điều đó không chỉ là để chúng tự động xác thực bằng thông tin mạng, đặt quản trị viên tên miền làm quản trị viên cục bộ trên máy Mac, v.v. Không có chính sách nhóm. MS đang cố gắng vi phạm các phiên bản mới hơn của SCCM, tuyên bố rằng có thể triển khai các ứng dụng cho các hộp mac và * nix, nhưng tôi chưa thấy nó trong môi trường sản xuất. Tôi cũng tin rằng bạn có thể định cấu hình máy Mac để kết nối với Máy chủ OS X sẽ xác thực thư mục dựa trên AD của bạn, nhưng tôi có thể sai.

Điều đó đang được nói, một số giải pháp sáng tạo có thể được đưa ra, chẳng hạn như đề xuất của Evan về việc sử dụng OpenVPN làm dịch vụ và vô hiệu hóa chứng chỉ máy nếu / khi đến lúc để nhân viên đó ra đi.

Nghe có vẻ như mọi thứ đều dựa trên Google, vậy Google có hoạt động như máy chủ ldap của bạn không? Tôi sẽ đề nghị khách hàng của tôi giữ nó theo cách đó nếu có thể. Tôi không biết bản chất công việc của bạn, nhưng đối với các ứng dụng dựa trên web như máy chủ git hoặc redmine, ngay cả khi thiết lập trong nhà có thể xác thực với OAuth, tận dụng tài khoản Google.

Cuối cùng, một thiết lập người đi đường như thế này gần như sẽ yêu cầu VPN để thành công. Khi các máy được đưa vào văn phòng và được định cấu hình (hoặc được định cấu hình từ xa bằng cách sử dụng tập lệnh), chúng cần một cách để nhận bất kỳ thay đổi nào trong cấu hình.

Các máy Mac sẽ cần một cách tiếp cận quản lý riêng ngoài VPN, thật tệ khi chúng không tạo máy chủ mac thực sự nữa, nhưng chúng đã có một số triển khai chính sách tốt trong OS X Server lần trước tôi đã kiểm tra (vài năm trước ).


Trên thực tế, Centrify đang được sử dụng trong môi trường này để quản lý chính sách trên một số ít hệ thống Mac ngay bây giờ.
ewwhite

@ewwhite bạn có ý gì khi quản lý? Dường như không có gì hơn một tiện ích xác thực trung tâm.
MDMoore313

@ MDMoore313 bạn đến trễ vài giờ, tôi thắng: chat.stackexchange.com/transcript/127?m=13626424#13626424 - :)
TheCleaner

@TheCleaner haha nó xuất hiện như vậy, bạn giành chiến thắng thời gian này, bạn đã biết nghệ thuật của Google Fu tốt, nhưng kỹ thuật của bạn vượt quá tầm hiểu bạn Trong Kung Fu tốt nhất của tôi với giọng Lipsync khủng khiếp. Sau khi bạn đăng câu trả lời của mình, tôi đã phải tìm kiếm gấp đôi để tìm ra câu trả lời không phải là bản sao của bạn!
MDMoore313

2
LOL, đừng lo lắng ... lần sau chúng ta gặp chiến thắng có thể là của bạn. (bằng giọng lipync khủng khiếp)
TheCleaner

7

Thật không may khi DirectAccess chỉ khả dụng trên Win7 + Enterprise Edition, vì nó được thiết kế riêng cho yêu cầu của bạn. Nhưng không biết phiên bản của bạn và thấy rằng bạn có MacOS, điều đó sẽ không hoạt động.

/ Chỉnh sửa - có vẻ như một số bên thứ 3 tuyên bố rằng họ có ứng dụng khách DA cho Unices: http://www.centrify.com/bloss/tomkemp/what_is_microsoft_directaccess_and_unix_linux_interoperability.asp

Có các giải pháp MDM có sẵn có thể hoạt động để đáp ứng nhu cầu của bạn; chúng tôi đang giới thiệu một trong số họ (MAAS360) cho một khách hàng ở vị trí tương tự.


5

Đây rõ ràng sẽ là một rủi ro bảo mật đáng kể. Hơn nữa, nó có thể sẽ không hoạt động tốt như bạn muốn. Nếu những người ngẫu nhiên trên Internet có thể thử đăng nhập vào môi trường AD của bạn, tỷ lệ cược là tất cả người dùng của bạn sẽ bị khóa. Mãi mãi. Và loại bỏ các yêu cầu khóa có nghĩa là nó trở nên khá dễ dàng để kiểm tra các mật khẩu đơn giản.

Quan trọng hơn, bạn sẽ không gặp vấn đề gì khi thực hiện mục tiêu của mình (người dùng cuối đăng nhập vào máy tính xách tay có thông tin xác thực tên miền) mà không làm cho máy chủ AD có thể truy cập trực tiếp. Cụ thể, các máy Windows có thể lưu trữ các lần đăng nhập X thành công cuối cùng để các thông tin đăng nhập tương tự hoạt động khi bị ngắt kết nối. Điều này có nghĩa là người dùng cuối có thể đăng nhập và thực hiện công việc hữu ích mà không cần phải chạm vào máy chủ AD của bạn. Rõ ràng họ sẽ cần sử dụng VPN để kết nối với các tài nguyên chính khác của công ty và có thể làm mới các cài đặt AD / GPO cùng một lúc.


2
AD không sử dụng (hoặc ít nhất là phụ thuộc vào) các chương trình phát sóng cho bất cứ điều gì, miễn là nó đã được AD, theo hiểu biết của tôi. Một số công nghệ có thể yêu cầu THẮNG, có thể quay lại yêu cầu phát nếu không có máy chủ WINS, nhưng điều đó không liên quan đến AD nói chung. Nếu nó phụ thuộc vào các chương trình phát sóng, bạn không thể có người dùng từ xa mà không có DC cục bộ.
mfinni

2
Chỉnh sửa dòng đó ra. Cảm ơn các đầu vào. Rõ ràng là một anh chàng Linux như tôi không nên tiếp khách trên Windows.
Christopher Karel

Nếu nó quá "rõ ràng" thì đó không phải là một câu hỏi, phải không?
Casey

2

Tất cả

Câu hỏi của bạn là vô cùng hợp lệ và xứng đáng được xem xét cẩn thận.

Tất cả các chuyên gia bảo mật đề xuất các lớp bảo mật trước bất kỳ tài nguyên mạng nào, bao gồm Tường lửa SPI, IDS, Tường lửa dựa trên máy chủ, v.v. Bạn nên luôn luôn sử dụng tường lửa cổng chu vi proxy như ISA (bây giờ là TMG).

Điều đó nói rằng, Microsoft Active Directory 2003+ không có lỗ hổng lớn được tiết lộ công khai. Công nghệ LDAP và thuật toán băm của nó thường rất an toàn. Nó được cho là an toàn hơn SSL VPN nếu SSL VPN đó chạy OpenSSL và dễ bị tổn thương.

Tôi sẽ thận trọng 5 điều:

  1. Hãy quan tâm đến các dịch vụ khác phải đối mặt với mạng như Terminal Server, DNS Services, CIFS và đặc biệt là IIS với hồ sơ bảo mật khủng khiếp của nó.

  2. Sử dụng LDAPS với chứng chỉ bảo mật để tránh truyền thông tin xác thực tên miền văn bản rõ ràng qua mạng. Điều này tự động xảy ra sau khi cài đặt Dịch vụ chứng chỉ (sử dụng máy riêng cho PKI)

  3. Đặt một gói sniffer trên giao diện và xem lưu lượng của bạn, sửa bất kỳ mật khẩu văn bản rõ ràng nào vì tường lửa hay không, nếu bạn không sử dụng VPN hoặc LDAPS, một số hệ thống cũ sẽ gửi mật khẩu văn bản rõ ràng.

  4. Biết rằng các cuộc tấn công MITM có thể buộc các cơ chế xác thực gốc hạ cấp và lộ mật khẩu thành xác thực NTLM yếu hơn.

  5. Hãy nhận biết một số lỗ hổng liệt kê người dùng vẫn còn tồn tại.

Điều đó nói rằng, Active Directory có một hồ sơ theo dõi tuyệt vời cho bảo mật. Hơn nữa, MS Active Directory không lưu trữ mật khẩu, chỉ băm cũng có thể giảm thiểu mức độ nghiêm trọng của thỏa hiệp.

Bạn có thể hưởng lợi từ cơ sở hạ tầng bảo mật liền mạch hơn, bạn không phải đặt máy chủ DNS đặc biệt hoặc sử dụng domain.local và bạn có thể sử dụng tên miền thực của mình trên internet công cộng như domain.com.

Theo ý kiến ​​chuyên môn của tôi, có một lợi ích đáng kể khi triển khai các công nghệ bảo mật như Active Directory công khai, trong đó các công nghệ khác như Exchange và DNS và Máy chủ web đơn giản không mang lại lợi ích và tất cả rủi ro.

Lưu ý: nếu bạn triển khai Active Directory, nó sẽ bao gồm máy chủ DNS. Hãy CERTAIN để vô hiệu hóa đệ quy trên các máy chủ DNS của bạn (được bật theo mặc định) hoặc bạn hoàn toàn sẽ tham gia vào các cuộc tấn công từ chối dịch vụ.

Chúc mừng

-Brian


-3

Dell (thông qua việc mua Quest (thông qua việc mua Vintela)) có một giải pháp đa nền tảng được triển khai thường xuyên trong các doanh nghiệp F500 cho mục đích rõ ràng này .

Những điều cần cân nhắc...

  1. Người dùng của bạn luôn được kết nối? Nếu vậy, bạn sẽ được phục vụ tốt nhất với môi trường lưu trữ dựa trên VM linh hoạt có thể linh hoạt khi nhiều người dùng đang hoạt động đang cản trở LDAP
  2. Bạn đang chạy trong nhiều trung tâm dữ liệu vật lý? Cân nhắc cân bằng tải địa lý trước các dịch vụ quảng cáo để giảm số bước nhảy giữa người dùng và hệ thống của bạn
  3. Ngoài ra, nếu câu trả lời cho số 2 là có, thì hãy đảm bảo bạn đã thiết lập một số tài nguyên mạng chuyên dụng để tái tạo khu rừng của bạn như được mô tả ở đây

Và hãy chắc chắn rằng giải pháp tường lửa của bạn có thể xử lý tốc độ truyền lại cực cao nếu bạn có người dùng trên các đường dẫn được điều chỉnh, kết nối từ các trung tâm wifi ồn ào, v.v.


Làm thế nào điều này quản lý các máy Windows, hoặc bảo mật bất cứ thứ gì như DC tiếp xúc với internet? Nó không đọc giống như nó, tất cả.
mfinni
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.