Part 3 of this series will go over the preparation work required to utilize IPSec in the future. This work will allow for the creation of firewall rules that either require authentication, or require authentication and encryption, for greater access control and security. A new top-level GPO will define all of the specific parameters, for ease of changes later. This GPO will only set the domain baseline; the configuration can still be modified further on a case by case basis by using more policies applied closer to the specific endpoint if necessary.
Note: This post assumes a basic knowledge of IPSec functionality, including how the various protocols work together, various algorithms used for encryption and hashing, etc. For more information, please see the following links:
- https://www.rapid7.com/blog/post/2017/02/13/basics-of-ipsec/
- https://en.wikipedia.org/wiki/IPsec
- https://en.wikipedia.org/wiki/Internet_Key_Exchange
GPO Creation
Start by creating a new GPO linked to the domain root named “Domain IPSec Configuration. In this policy, head to the Windows Firewall section, view the properties, and look at the IPSec Settings tab.
From here, customize the IPSec defaults by clicking Customize. This will lead to a new dialog, where the ideal default settings can be configured.
Key Exchange (Main Mode) Configuration
Relevant MS Docs: Configure Key Exchange (Main Mode) Settings
Under the Key Exchange (Main Mode) section, select Advanced, and click Customize. The following two screenshots show the default configuration, and the configuration I have decided to utilize in my lab environment. There’s a number of possible combinations than can be configured here; what I have configured is extremely secure for a modern environment. If you have older operating systems in your environment, you may need to include alternative combinations.
After configuring settings as desired, click OK here to save the Key Exchange configuration and return to the Customize IPSec Defaults dialog.
Data Protection (Quick Mode) Configuration
Relevant MS Docs: Configure Data Protection (Quick Mode) Settings
Under the Data Protection (Quick Mode) section, select Advanced, and click Customize. The following two screenshots show the default configuration, and the configuration I have decided to utilize in my lab environment. There’s a number of possible combinations than can be configured here; what I have configured is extremely secure for a modern environment. If you have older operating systems in your environment, you may need to include alternative combinations.
After configuring settings as desired, click OK here to save the Data Protection configuration and return to the Customize IPSec Defaults dialog.
Authentication Method
Relevant MS Docs: Configure Authentication Methods
Finally, configure the default Authentication Method by selecting Advanced and Customize. Here, the default configuration will appear empty, but for reference, the default configuration is to utilize Computer Kerberos and User Kerberos. In my configuration I’ll configure it to be the same as what the default configuration actually, but explicitly defined.
Once configured, click OK to save the Authentication Method settings, return to the Customize IPSec Defaults dialog, and click OK here as well.
IPSec Exemptions
Now back in the Windows Firewall properties IPSec Settings tab, configure ICMP to be exempted from IPSec, as this will make simple troubleshooting such as using ping easier.
After clicking OK here, the domain-wide IPSec configuration is complete, and it’s now ready to be utilized.
Summary
At this point, a baseline IPSec configuration has been applied to all domain endpoints, but no changes ave been made as to how endpoints communicate with each other. This baseline will be used in conjunction with later created policies to secure communication between endpoints.
In this article I’d like to show how administrators can use IPSec to protect the most valuable “assets” in their networks – for example, servers that runs HR or financial databases. Lots of articles on msdn/technet offer one of the following methods to secure the traffic – domain isolation or/and server isolation. The first one is supposed to restrict traffic flow only to the domain members while the latter is often regarded as the extra security layer to the domain isolation that further restricts access to some host(s) only to member of certain computer or user groups. My point is that sometimes we may deploy some form of server isolation by not restricting already established security policies (domain isolation) with the additional computer/user checking but simply by applying the connection security rules to the respective organizational units (OUs).
Consider the following task: only specific clients (say HR department users) should have access to the host with HR database. The easiest way to achieve this is to create a server GPO with the connection security rules which would require IPSec protection for all inbound traffic (and only request the protection for outbound traffic) and a client GPO which would request protection for both inbound and outbound traffic. Applying the server GPO to the OU containing the server computer account (or accounts) and the client GPO to the OU with the needed client computer accounts will result in the required server isolation – in this case grouping the server and client computer accounts into specific OUs will serve the same purpose as resticting access based on the computer/use group membership.
Suppose the server that hosts the database with sensitive information is SQL1 –
so the first step is to create a new OU – Devices\SECURE – and move the server into it:
SecureSERVER is a new GPO for which we’ll create the new connection security rule that will require authentication for the inbound connections.
Now let’s create the new rule:
On the Rule Type page choose the type of the rule – Isolation and Require authentication for inbound connections and request authentication for outbound connections on the Requirements page:
Since the new rule will use Kerberos authentication there’s no need to choose anything except Domain here.
Again, since the target for this policy (and the rule) is defined by applying this GPO only to the specific OU, I won’t configure any endpoints for this rule.
After running gpupdate /force on SQL1:
The server-side policy is created – the next step is to create a GPO for users that should be able to connect to the SQL1 and create the client GPO – I’ll create the SecureCONNECTIONS GPO and link it to the Tier2\Devices OU. It means any (client) computer which has its computer account placed in this GPO will be allowed to access the secure server (SQL1). In the production network it may be an OU at the deeper level but currently there’s only one client computer account in my test network so I’ll keep using this OU.
The new client connection security rule differs from the server one just in the Requirements tab (not speaking of the Name tab):
Clients should not require inbound connections to be authenticated – they just must be able to initiate a secure outbound connections (servers that require inbound authentication will respond with ipsec while all other hosts will reply as usually), so we select the first option here:
Here’s the client rule:
After running gpupdate /force on Client1:
Now let’s test it: computers in the Tier2\Devices (currently only Client1) should have access to SQL1 while any computers that are not in the Tier2\Devices OU should NOT. All connection attempts will be traced in Network Monitor.
Test 1: Connecting to SQL1 from Tier1\Devices\SQL2
1.1 Pinging SQL1 (the ip of SQL2 – 10.1.1.23):
The result: ping failed as expected – please note the trace does not contain the SQL1’s authentication requests (AuthIP).
2.2 Connecting to SQL1 in SSMS
The result: the connection failed as expected and the trace does contain the SQL1’s authentication requests (AuthIP) coming from SQL1 to SQL2. As SQL2 does not have any connection security rules applied it can’t respond to the authentication requests that result in the failed connection.
Test 2: Connecting to SQL1 from Tier2\Devices\Client1
2.1 Pinging SQL1
Please note the first packet’s response time – it’s due to the ipsec negotiation phase:
The trace:
The result: ping succeeds as expected. Please note that the host with the connection security rule applied makes the second connection using AuthIP protocol right after the first unsuccessful echo request. After successful ipsec authentication we can see icmp request/reply packets.
2.2 Connecting to SQL1 in SSMS
The trace:
The result: connection succeeded – once ipsec authentication is completed SSMS establishes TDS session with the database server.
You may have already noted that both succeeded secure connections still display all their network-related information in the network parser – that’s because by default no encryption is applied to the packets:
Here’s how the default IPSec settings correlate with the connection security rules applied (I’ll move on to the IPSec defaults right after this screenshot).
By default the “Require encryption…” checkbox is not checked so no encryption algorithms apply.
What if you want to disclose as little information as possible? It means ESP encryption must be enabled – this can be done either in the Windows Firewall’s IPSec defaults – and thus all connections that satisfy the ipsec rules on this host will be encrypted – or create the main mode rules with different encryption settings using netsh advfirewall mainmode add rule command. In this article I will enable encryption using Windows Firewall.
You can enable encryption in any GPO – server, client, or both (the best option, I think) – for example, I’ll edit the SecureSERVER gpo – navigate to Secure Settings\Windows Defender Firewall with Advanced Security, right-click it and select Properties:
Change to the IPsec Settings and click Customize in the IPsec defaults section:
It is the Quick Mode settings that define whether the encryption is enabled and if yes which encryption (as well as integrity) algorithms are to be used:
After setting the Quick mode to the Advanced configuration depicted above we can repeat Test 2 (after gpupdate /force on SQL1, of course) and see how network connections will be displayed in Network Monitor with ESP in place:
2.1 Pinging SQL1 from Client1
The trace:
2.2 Connecting to SQL1 in SSMS from Client1
As you see enabling ESP encryption helps disclose only ip-related information, hiding the higher-level packet information from potential network sniffer user.
And the last test: how will the traffic from a secure client to a non-secure host look like?
Test 3: Connecting to Exch1 from Client1
The trace:
The result: Client1 first tries authenticated connection and then falls back to the plain session.
In part 2 we’ll see how we can further restrict access to the secure servers.
First published on TechNet on Dec 14, 2014
Hi folks, Lakshman Hariharan and Martin Solis here with a post on how to secure domain controller to domain controller communications using Windows Firewall with Advanced Security (WFAS) Connection Security Rules. Be forewarned that this is a long post, much of it taken up by screenshots.
A common example of an implementation is the securing of communications between domain controllers deployed in the perimeter network (DMZ) and the secure network. Firstly, why do we even need to secure communications between domain controllers using IPsec? One of the most common scenarios is when an organization deploys Read Only Domain Controllers (RODCs) in the DMZ segment of a network. This means that the domain controllers in the DMZ segment have to communicate with other domain controllers in the secure network segment(s), and therein lies our problem (if one were to call it that). Active Directory and DFS replication use a Remote Procedure Call (RPC) and RPC uses dynamic ports in the range of 49152-65535 in up-level (read Windows Server 2008 and above). Which means that to facilitate communications between the two domain controllers separated by firewalls a whole range of ports must be opened between these domain controllers by “swiss-cheesing” or poking metaphoric holes through the firewall.
Some firewalls are RPC aware and can dynamically open the required ports based on the different UUIDs being presented but many are not, and even with RPC aware firewalls many organizations’ network teams are understandably wary of doing so for reasons of network security and the cumbersome nature of maintaining such a setup.
Explanation of the concepts of RPC are beyond the scope of this post. Refer to this post for a good understanding of RPC concepts such as UUIDs, OpNums and such.
This is where using IPsec to encapsulate all communications between the domain controllers comes handy so instead of opening a whole range of ports only two UDP ports for ISAKMP (500 and 501) and one IP protocol for GRE (protocol 47) need to be allowed through the firewall.
Now that we have described why one may want to use IPsec to secure communications between domain controllers let’s move on to discussing the “how”. The rest of the post is intended as a step by step to walk through securing communications between two domain controllers using IPsec and optionally*, if desired encrypt such communications.
Following is the setup used for this demo that includes two domain controllers, one Windows client and one member server. The following table summarizes the roles, IP addresses and operating system running on these machines.
|
Machine Name |
Machine Role |
Operating System |
IP Address |
|
Contoso2012R2DC1 |
Domain Controller |
Windows Server 2012 R2 |
10.0.0.1 |
|
Contoso2102R2DC2 |
Domain Controller |
Windows Server 2012 R2 |
10.0.0.2 |
|
APP1 |
Application Server |
Windows Server 2102 R2 |
10.0.03 |
|
ContosoWin81 |
Windows Client |
Windows 8.1 Enterprise |
10.0.0.4 |
To perform this we will use six big steps sense that are further broken down into detailed individual steps. These six steps are:
1. Create a Group Policy Object
2. Create the Connection Security Rules
3. Create IPsec exclusions for DNS, ICMP and DHCP (optional) traffic since it is better to exclude name resolution, DHCP and ICMP traffic from IPsec.
4. Link the group policy object to the appropriate OU
5. Verify Communications are successfully secured.
6. Optionally encrypt the data being secured.*
Step 1: Create the group policy object
1. Logon to the domain controller and launch Group Policy Management Console (GPMC)
2. Create a new Group Policy Object (GPO) and name it DC to DC IPSec using WFAS
Step 2: Create the Connection Security Rules to Request Inbound and Outbound Security
1. Edit the GPO created in previous step by navigating to Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Windows Firewall With Advanced Security
2. Under Windows Firewall with Advanced Security select Connection Security Rules
3. Right click on Connection Security Rules and select New Rule
4. In the Rule Type screen select Server to Server and click Next
5. In the Endpoints screen select These IP Addresses under Which Computers are in Endpoint 1, select These IP Addresses and click Add
6. Under This IP address or subnet enter the IP addresses of the first domain controller and click OK
7. In the Endpoints screen select These IP Addresses under Which Computers are in Endpoint 2, select These IP Addresses and click Add.
8. Under This IP address or subnet enter the IP address of the second domain controller and click OK
Verify the IP addresses entered are accurate and click Next . Note that in any production scenario the Connection Security Rules created will most likely span subnets instead of individual IP addresses as demonstrated in this document. The subnets can be specified instead of actual IP addresses as described in the Examples of the screenshot above.
9. On the Requirements screen select Request authentication for inbound and outbound connections and click Next
10. On the Authentication Method screen select Computer certificate**, select the appropriate Certification Authority and click Next . Note that both endpoints must trust the same Certification Authority.
11. On the Profile screen select Domain, Private and Public and click Next
12. On the Name screen give the Connection Security Rule an appropriate name and click Finish
13. Locate the Connection Security Rule created in the previous steps, right click and click Copy and then Paste to make a copy of the rule, as shown in the following two screenshots.
14. Right click on one of the rules and click Properties and then select the Remote Computers tab
15. Select each of the IP address under Endpoint 1 and Endpoint 2 and click Edit
16. Reverse the IP address ranges or addresses as shown and click Ok, so connections initiated from either endpoint are secured via IPsec
Step 3 Create IPSec Exclusions for, DNS, ICMP and DHCP*** Traffic
1. Open Group Policy Management Console (GPMC), navigate to the policy created in Step 2, right click on it and Click Edit
2. Navigate to Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Windows Firewall With Advanced Security –> Connection Security Rules
3. Right click Connection Security Rules and click New Rule
4. On the Rule Type screen select Custom and click Next
5. On the Endpoints screen select These IP Addresses and enter the IP addresses for Endpoint 1 and Endpoint 2.
6. On the Requirements screen select Do not authenticate and click Next
7. On the Protocols and Ports screen Enter and/or select the following and click Next
Protocol Type: UDP
Endpoint 1 port: Specific Ports
Port number: 53
Endpoint 2 port: All Ports
8. On the Profile screen make sure Domain, Private and Public are selected under When does this rule apply? And click Next
9. On the Name screen type UDP 53 Exclusion for the Name and click Finish
10. Right click on the UDP 53 Exclusion rule created in the previous step and select Copy and then Paste as shown in the following three screenshots.
11. Right click on one of the two UDP 53 Exclusion rules, click on Properties and select the Remote Computers tab
12. Under Endpoint 1 and Endpoint 2 reverse the IP addresses for connections initiated from the other endpoint and click Ok
13. Repeat steps 1 through 9 to create an exemption for port TCP 53
14. Repeat steps 10 through 12 to clone the rule for TCP port 53 connections initiated from the other endpoint.
15. Repeat steps 1 through 9 to create an exclusion for ICMP. While creating the rule choose the following in the Protocols and Ports screen
16. If the domain controllers are running DHCP then create an exclusion for UDP ports 67 as outlined in steps 1 through 9.
Step 4 Link the Group Policy Object to the appropriate Organizational Units (OU)
1. Open Group Policy Management Console (GPMC), right click on the Domain Controllers OU and click Link and Existing GPO…
2. Select the GPO created in Step 2, in our case DC to DC IPSec using WFAS and click OK
3. Force group policy update on the domain controllers by executing the gpudate /force command
Step 5 Verify Communications are secure and successful
1. Capture a network trace when initiating communications between the two domain controllers whose communications have been secured using IPSec. This can be done several different ways. An easy way is to, say open the Event Viewer or the Services console and connect to the other domain controller. Or one could open a file share on the other domain controller from the first one.
2. Open the network trace in Microsoft Message Analyzer or Network Monitor 3.4. The screenshot below is using Network Monitor 3.4
3. Apply a display filter to only display traffic between the two domain controllers. In this case a display filter of ipv4.Address==10.0.0.2 has been applied, as seen in the screenshot below
4. Select any frame in the Frame Summary pane and observe the details in the Frame Details pane
5. Upon further inspecting each frame in the Frame Details pane one will observe that every frame has an additional ESP header indicating that the frame is encapsulated in ESP.
6. Spot check and inspect as many frames as possible to ensure that they contain the ESP header indicating that the data is encapsulated using ESP.
Step 6 (Optional) Encrypt Data Being Secured
1. Using Group Policy Management Console (GPMC), open the Group Policy Object created in the previuos steps and navigate to Computer Configuration –> Windows Settings –> Security Settings –> Windows Firewall with Advanced Security –>
2. Once at Windows Firewall With Advanced Security – LDAP://<Policy GUID>, DC=<domain name>, dc=<domain suffix>, right click on the policy and click on properties.
3. In the Properties window, click on the IPsec Settings tab
4. Click on the Customize button under IPsec defaults. This will bring up the Customize IPsec Defaults window.
5. Under Data Protection (Quick Mode), select Advanced and click on Customize. This will bring up the Customize Data Protection Settings as shown in the second screenshot.
6. Select the Require encryption for all connection security rules that use these settings checkbox.
7. Click OK three times.
Once group policy has refreshed on both domain controllers all communications will now be encrypted. Two screenshots of a network trace of encrypted communications are shown below. Note the frame details pane in the second screenshot where all the data is encrypted instead of only being encapsulated in ESP.
* There are two primary reasons where an organization may choose to secure but not encrypt the communications between domain controllers. The first being that in many organizations network teams may want to be able to still “sniff” the data using network monitoring tools and encryption renders such sniffing impossible. The second reason is performance. The encryption and subsequent decryption of data consumes additional CPU cycles on a server and adds to the load of what is in all likelihood an already busy domain controller.
**Note that the options available for authentication are Computer Certificate, Kerberos or Pre-shared key. We recommend using certificates because using Kerberos means another set of ports (UDP and TCP 88) having to be opened on the firewall(s). Plus using Kerberos for authentication has the potential of a «chicken and egg» scenario where IPsec depends on Kerberos but Kerberos issues could prevent IPsec. As for pre-shared key, because it is inherently insecure we recommend not using it for anything except for, say testing quickly a basic lab setup.
*** The DHCP exclusion is required only if the domain controllers are running DHCP. In this setup there are two domain controllers.
-Lakshman Hariharan and Martin Solis
Главное назначение IPsec — защищать содержимое и целостность сетевого трафика с помощью таких технологий, как цифровая подпись и шифрование. Но когда возникает необходимость ограничить доступ к определенным ресурсам, в поисках средств для решения этой задачи, многие обращаются к спискам управления доступом Access Control Lists (ACL) или к виртуальным локальным сетям (VLAN).
Однако использование списков ACL, формируемых на уровне приложения, рискованно с точки зрения безопасности. В действительности мы можем использовать IPsec с целью изоляции тех или иных главных систем либо доменов от угроз, которые исходят от не имеющих санкции на доступ (или неуправляемых) компьютеров.
В частности, прекрасным инструментом для изоляции серверов являются правила безопасности подключения на базе Ipsec; они реализуются в Windows 7, Windows Server 2008 и Windows Vista и настраиваются с помощью брандмауэра Windows Firewall с консолью Advanced Security и с использованием групповой политики. Давайте начнем с небольшой справки по общей концепции изоляции серверов, а затем углубимся в процесс настройки изоляции серверов в конкретной среде.
Что такое изоляция серверов?
Реализуя изоляцию серверов и доменов, мы проводим сетевую политику, в соответствии с которой определенные серверы — члены домена вступают во взаимодействие (после выполнения процедуры аутентификации и с соблюдением правил безопасности) только с другими компьютерами — членами домена. Такая сетевая политика изолирует определенные серверы от компьютеров, которые не являются членами домена, или от систем, которые, будучи членами домена, не соответствуют тем или иным критериям. Так, администратор может сформулировать политику, предписывающую серверу баз данных принимать соединения только от серверов, которые входят в указанную группу безопасности, или от серверов, на которых установлен определенный компьютерный сертификат.
При осуществлении изоляции описанным образом нет необходимости в перенастройке сети или в использовании каких-либо программных средств от независимых поставщиков. Все необходимое уже есть в операционной системе. Главные системы или домены, изолированные таким образом, не требуют обслуживания в случае внесения изменений в структуру сети или при миграции в другое место либо на другое сетевое устройство. И поскольку изоляция реализуется на уровне операционной системы, она не оказывает влияния на другие уровни защиты.
В системе Windows Server 2003 изоляция серверов осуществлялась с использованием настройки групповой политики Access this computer from network, но возможности этого средства были ограниченны. Можно было только предоставить пользователям или компьютерам право обращаться к указанной главной системе; возможность определять дополнительные параметры, например метод аутентификации, предусмотрена не была. Кроме того, можно было форсировать использование того или иного протокола аутентификации с помощью групповой политики (скажем, применять только протокол NTLMv2, а применение протокола Kerberos исключалось, как и возможность потребовать, чтобы другая сторона предъявила сертификат для аутентификации).
В системах Windows 7, Server 2008 и Vista реализованы новые средства для изоляции серверов с помощью брандмауэра Windows Firewall, оснащенного консолью Advanced Security. Наряду с дополнительными возможностями настройки брандмауэра эта консоль позволяет применять правила безопасности подключения. В реализации технологии изоляции серверов данные правила играют исключительно важную роль. Хотя изоляция на базе IPsec была возможна в более ранних версиях операционной системы, таких как Windows XP и Windows 2003, в системах Server 2008 и Vista впервые реализована интеграция набора стандартов IPsec и средств брандмауэра.
Запрос или требование?
Первоочередная задача состоит в том, чтобы идентифицировать систему, которую нужно изолировать, а затем следует определить уровень предстоящей изоляции. В некоторых случаях изоляция серверов будет осуществлена на всех системах домена, что, в сущности, равнозначно изоляции домена. Однако чаще осуществляется изоляция отдельных (клиентских или серверных) систем, которым требуется дополнительный уровень защиты. Поэтому давайте сосредоточим внимание на изоляции отдельной системы. Поскольку правила безопасности подключения действуют как в системе Vista, так и в системе Server 2008 и настраиваются единым образом, я не буду говорить о них в контексте той или иной операционной системы.
Обратиться к брандмауэру Windows Firewall с консолью Advanced Security можно через оснастку Administrative Tools панели управления. Открыв окно консоли (экран 1), щелкните правой кнопкой мыши на узле Connection Security Rules и в контекстном меню выберите пункт New Rule. В результате будет запущен мастер New Connection Security Rule Wizard, который предложит на выбор несколько параметров.
Выберите первый параметр, Isolation. Другие параметры дают возможность устанавливать для заданных систем правила изъятия, реализовывать аутентификацию между двумя указанными компьютерами (параметр Server-to-Server), формировать аутентификацию в режиме тунеллирования (что полезно при работе с соединениями «сайт-сайт») или формулировать собственное правило.
После того как вы выберете параметр Isolation и нажмете кнопку Next, нужно будет выбрать одно из предлагаемых требований аутентификации, как показано на экране 2. В сущности, выбирать придется между запросом и требованием. Если вы выберете параметр Request, аутентификация будет запрошена (то есть предложена) для входящего или исходящего трафика (либо для трафика в обе стороны), но она не будет выполняться принудительно.
Если другая сторона не сможет должным образом выполнить процедуру аутентификации, трафик тем не менее будет разрешен. Но когда вы выбираете параметр Require, операционная система форсирует выполнение процедуры аутентификации, и, если эта процедура заканчивается с ошибкой, соединение сбрасывается. В зависимости от необходимого уровня безопасности вы можете выбрать параметр Require для процедуры аутентификации входящих соединений и Request — для исходящих. Это приемлемо в тех случаях, когда вы хотите форсировать аутентификацию только для входящих подключений (для ситуаций, когда другие компьютеры пытаются обратиться к данной изолированной системе) или выбрать параметр Require как для входящих, так и для исходящих подключений. В этом случае достигается максимальный уровень безопасности, поскольку аутентификация осуществляется для трафика в обоих направлениях.
В случае выбора первого параметра, Request authentication for inbound and outbound connections, аутентификация не будет принудительно применяться ни в том, ни в другом направлении, так что говорить о подлинной изоляции не приходится. При выборе второго варианта, Require authentication for inbound connections and request authentication for outbound connections, обеспечивается достаточный уровень защиты изолированной системы, и при этом она имеет возможность вступать во взаимодействие со всеми другими системами (расположенными как внутри, так и вне домена). По этой причине второй вариант представляет собой оптимальное решение; выбирайте его и нажимайте кнопку Next.
Настройка параметров аутентификации
Далее следует настроить метод аутентификации, как показано на экране 3. На данном этапе вы фактически можете принудительно реализовать аутентификацию с применением протокола Kerberos для пользователя, компьютера или для того и другого, потребовать предъявления сертификата или реализовать специализированный метод аутентификации.
Но следует иметь в виду, что эти механизмы аутентификации являются обязательными на уровне IPsec (то есть на сетевом уровне). Если некоторое приложение применяет иной метод аутентификации (скажем, NTLM), аутентификация опять-таки будет осуществляться на уровне приложения. Если вы используете метод, предлагаемый по умолчанию, аутентификация будет реализована в соответствии с настройками брандмауэра Windows Firewall, установленными на вкладке IPsec Settings диалогового окна Security Properties. Чтобы получить доступ к этим настройкам, правой кнопкой мыши щелкните на элементе Windows Firewall with Advanced Security узла Local Computer и в контекстном меню выберите пункт Properties. На вкладке IPsec Settings можно выбрать элемент Customize, чтобы указать значения, которые будут применяться по умолчанию при создании новых правил безопасности подключения (экран 4).
Компьютер и пользователь. Если вы выберете второй параметр Authentication Method — Computer and User (using Kerberos V5), при любой попытке установить соединение с изолированной системой компьютер будет требовать аутентификации по протоколу Kerberos. Если как пользователь, так и компьютер являются членами домена, аутентификация будет выполнена в автоматическом режиме, без вмешательства со стороны пользователя. Этот метод аутентификации легко реализуется и обеспечивает высокий уровень безопасности, поэтому я рекомендую в большинстве случаев применять его.
Компьютер. Если вы выберете параметр Computer (using Kerberos V5), аутентификация потребуется только со стороны компьютера. Иными словами, если компьютер, инициирующий подключение к изолированной системе, является членом домена, подключение будет разрешено без требования аутентификации со стороны пользователя.
Сертификат компьютера. Параметр Computer certificate — налагающий самые строгие ограничения — дает возможность указывать, что обращаться к изолированной системе могут только те компьютеры, которые обладают сертификатом, выданным определенным удостоверяющим центром Certification Authority (CA).
Сертификаты работоспособности. В нижней части диалогового окна Customize IPsec Settings расположена любопытная кнопка-флажок Accept only health certificates; с ее помощью можно установить дополнительный уровень безопасности.
Если IPsec используется в сочетании со средствами NAP для изоляции неработоспособной системы, изолируемая система будет принимать только компьютерные сертификаты, выданные центром регистрации работоспособности соответствующего NAP-решения. Дополнительные сведения о настройке NAP с IPsec можно найти в подготовленной специалистами Microsoft статье «Step-by-Step Guide: Demonstrate NAP IPsec Enforcement in a Test Lab» (www.microsoft.com/Downloads/details. aspx? FamilyID=298ff956-1e6c-4d97?a3ed-7e7ffc4bed32).
Дополнительно. В нижней части диалогового окна вы увидите параметр Advanced, который позволяет выбирать различные методы аутентификации, выполняемой на этапах согласования и сопоставления безопасности IPsec. Сопоставление безопасности — это сочетание согласованного ключа, протокола безопасности, а также индекса параметров безопасности, которые в совокупности определяют уровень безопасности, выбранный для защиты канала связи между системами. Когда вы нажмете кнопку Customize, на экране появится пара идентичных диалоговых окон First authentication и Second authentication, как показано на экране 5.
Первый метод аутентификации применяется в ходе первой фазы согласований IPsec. Во время этой фазы два компьютера устанавливают защищенный канал связи с использованием аутентификации. Для этого осуществляется согласование политик, обмен ключами Диффи-Хеллмана и процедура аутентификации. При использовании второго метода аутентификации можно указать, как выполняет процедуру аутентификации пользователь, работающий на другом компьютере. Варианты выбора: протокол аутентификации Kerberos V5, пользовательские сертификаты и сертификат работоспособности компьютера. Оба метода применяются по усмотрению пользователя, но для обеспечения безопасности среды вы должны требовать аутентификации, по крайней мере по первому методу. Для целей данной статьи следовало бы выбрать метод аутентификации Computer and User (using Kerberos V5) и нажать кнопку Next.
Какой сетевой профиль?
На странице мастера Profile, представленной на экране 6, можно указать, к какому сетевому профилю применяется данное правило. Выбирайте значения Domain, Private и Public (все они предлагаются по умолчанию). Однако следует подумать об изменении этих значений, особенно если вы часто изменяете местоположение изолированной системы (например, ноутбуков).
Сетевой профиль Domain относится к сети, которая дает возможность подключаться к контроллерам доменов DC и регистрироваться в этом домене. Профиль Private относится к сетям, которые пользователь определяет как частные (например, к домашним сетям). Профиль Public относится к сетям, которые пользователь относит к общедоступным после того, как подключается к ним (речь идет о сетях с высоким риском для безопасности, скажем о сетях в гостиницах и о точках доступа, расположенных в общественных местах).
В некоторых случаях флажок Private целесообразно сбросить. Например, если вы применяете правило безопасного подключения для своего ноутбука, возможно, вы захотите изолировать его в домене или в общедоступной среде, но сохранить доступ к своей домашней (частной) сети. Разумеется, для обеспечения максимального уровня безопасности необходимо установить все флажки.
На последнем этапе работы с мастером правилу присваивается имя. Я рекомендую выбирать описательные имена. После того как вы нажмете кнопку Finish, правило будет автоматически активировано и отобразится в списке правил.
Реализация правил брандмауэра для входящих подключений
Если вы хотите наложить на обмен данными с изолированной системой более жесткие ограничения, можете создать дополнительные правила брандмауэра для входящих подключений — например, указать порты, открытые для коммуникации, и IP-адреса, с которых возможен обмен данными. Вы можете принять эти меры с помощью набора стандартов IPsec или с использованием чисто сетевых технологий, но дело в том, что новый брандмауэр Windows Firewall with Advanced Security Console позволяет осуществлять управление с одного места. Кроме того, вы можете требовать применения шифрования для обеспечения безопасности трафика с использованием протокола ESP (Encapsulating Security Payload) через брандмауэр Windows Firewall with Advanced Security Console.
Правой кнопкой мыши щелкните на узле Inbound Rules и в контекстном меню выберите элемент New Rule. На экране откроется окно мастера New Inbound Rule Wizard. Выберите пункт Port, нажмите кнопку Next, выделите пункт TCP или UDP и укажите порт, который хотите открыть (к примеру, вы можете открыть только порты для веб-трафика — 80 и 443). Нажмите кнопку Next. На следующем экране выберите вариант Allow the connection if it is secure, как показано на экране 7.
Тем самым вы свяжете данное правило с правилом безопасности подключения, которое уже создали. Подключения через указанные порты будут выполняться только в тех случаях, если они успешно пройдут процедуру аутентификации в соответствии с правилом безопасности подключения. Для применения функции шифрования вы можете также установить настройку Require the connections to be encrypted. Нажмите кнопку Next, и вы сможете указать компьютеры и пользователей (членов домена), к которым применяется данное правило. Наконец, вы можете выбрать сетевой профиль и присвоить правилу имя.
Более подробные сведения о настройке правил брандмауэра можно найти в статье Microsoft «Windows Firewall with Advanced Security and IPsec for Windows Server 2008» (technet.microsoft.com/en-us/library/dd44 8524.aspx).
Настройка исключений
В некоторых случаях возникает потребность освободить компьютеры, группы или диапазоны IP-адресов, присвоенных компьютерам, от необходимости проходить процедуру аутентификации при установлении соединения с изолированной системой — вне зависимости от положений других правил безопасности подключения. Например, вы можете с помощью исключения предоставить доступ к тем компьютерам инфраструктуры (например, к контроллерам доменов AD, к серверам DHCP или CA), с которыми изолированная система должна вступать во взаимодействие еще до того, как будет выполнена процедура аутентификации.
Здесь надо сделать одно предупреждение: будьте очень осторожны при формулировании правил изоляции, которые могут оказать влияние на работу серверов инфраструктуры. Серверам CA, DC, DHCP, DNS и другим серверам инфраструктуры не должны предъявляться требования в плане обмена данными по стандартам IPsec при установлении как входящих, так и исходящих подключений.
Если правила создаются, их нужно формулировать с исключительным вниманием, чтобы не прошедшие аутентификацию компьютеры могли пройти процедуру аутентификации и получить доступ к этим службам.
Рядовые серверы и рабочие станции нужно настраивать так, чтобы они не запрашивали и не требовали разрешения на подключение к этим серверам, и для этого следует применять правила исключения.
Для настройки исключений вновь запустите мастер New Inbound Rule Wizard щелчком правой кнопкой мыши на правилах Connection Security Rules, затем выделите пункт Authentication Exemption и нажмите кнопку Next. На следующем экране нажмите кнопку Add, чтобы добавить компьютеры, диапазоны IP-адресов или определенные типы компьютеров, на которые не будет распространяться требование о прохождении аутентификации. Выбрав необходимые позиции, нажмите кнопку Next и выделите сетевой профиль, к которому будет применяться это правило. Затем присвойте правилу имя и нажмите кнопку Finish.
Использование групповых политик
Самый удобный способ реализовать изоляцию на нескольких компьютерах — воспользоваться групповой политикой. Для этого потребуется, чтобы на контроллерах доменов была установлена система Server 2008, поскольку объекты групповой политики системы Windows 2003 не имеют такой возможности. Впрочем, если ваши контроллеры доменов работают под управлением Windows 2003, вы сможете воспользоваться политикой IPsec.
Перед созданием и связыванием объекта групповой политики Group Policy Object (GPO) нужно сгруппировать системы с аналогичными требованиями по изоляции и распределить их по отдельным организационным единицам OU. После того как вы создадите структуру организационных единиц и переместите серверы в соответствующие OU, в меню Administrative Tools запустите консоль Group Policy Management Console. В контейнере Group Policy Objects создайте новый объект GPO, щелкните на нем правой кнопкой мыши и откройте этот объект, выбрав в контекстном меню пункт Edit. Перейдите на узел Computer Configuration и распахните Policies, Windows Settings, Security Settings, Windows Firewall with Advanced Security. На правой панели редактора Group Policy Management Editor вы увидите те же элементы пользовательского интерфейса, которые отображаются, когда вы работаете с этой консолью локально. Щелкните на элементе Connection Security Rules, запустите мастер New Inbound Rule Wizard и реализуйте желательные настройки в соответствии с инструкциями, которые я изложил выше.
Когда эти действия будут выполнены, внутри объекта GPO будет создано правило безопасности подключения. Если вы щелкните на нем правой кнопкой мыши, в контекстном меню выберете пункт Properties и перейдете на вкладку Computers, то сможете указать конечные точки правила — компьютеры, к которым оно будет применяться. В качестве любой из двух конечных точек можно указать один или несколько компьютеров. Можно указать конкретный IP-адрес, подсеть, заранее определенный адрес или диапазон IP-адресов. Имейте в виду, что правила безопасного подключения будут применяться к обменам между любым компьютером — конечной точкой 1 и любым компьютером — конечной точкой 2. После установки всех необходимых настроек можно связать GPO с организационной единицей, которая содержит системы, подлежащие изоляции.
Дополнительная безопасность
Технология изоляции серверов обеспечивает еще один уровень безопасности и управления доступом, дополняющий другие технологии защиты данных, такие как средства для борьбы с вирусами и шпионским программным обеспечением, брандмауэры и системы обнаружения вторжений.
Она дает возможность использовать настройки групповых политик для создания, распределения и централизованного управления правилами безопасного подключения с целью изоляции отдельных систем.
Кроме того, это решение функционирует незаметно: конечные пользователи продолжают работать, как и прежде.
Дополнительная подготовка пользователей не нужна, а администраторам не приходится устанавливать новые программные средства или обходить все компьютеры в процессе развертывания — в этом состоит важное преимущество данной технологии.
Дамир Диздаревич (ddamir@logosoft.ba) — менеджер центра подготовки Logosoft в Сараево, Босния. Имеет звание MVP for Windows Server Infrastructure Management и сертификаты MCSE, MCTS, MCITP и MCT
Written on . Posted in Windows Server 2008
Страница 5 из 10
Введение в изоляцию домена
В этой части мы рассмотрим процесс использования групповой политики для внедрения изоляции домена через использование IPsec. Windows Firewall с расширенной безопасностью интегрирован с групповой политикой Windows Server 2008, что позволяет использовать консоль управления групповыми политиками и редактора групповых политик для создания политики брандмауэра на машинах всего домена в организационной единице (OU) или на сайте.
Конфигурация изоляции домена (Domain Isolation) (через интерфейс Windows Firewall с расширенной безопасностью) позволяет вам защищать все ваши машины в домене от потенциально опасных машин, которые не входят в домен. Члены домена настроены так, что они должны аутентифицироваться друг с другом, прежде чем между ними будет разрешено подключение. Машины, которые не являются членами домена, не могут аутентифицироваться с членами домена, поэтому соединение для таких машин работать не будет.
Хотя это можно было делать и на предыдущих версиях Windows, интерфейс настройки для конфигурации IPsec политик был слишком сложным, его было так трудно понять, что не многие администраторы безопасности и Windows желали создавать себе трудности с изоляцией домена. Однако с появлением брандмауэра Windows с расширенной безопасностью в Windows Server 2008 и Vista, стало очень просто осуществлять настройки изоляции домена. А его интеграция с групповой политикой Windows Server 2008 Group Policy позволяет с легкостью централизовать процесс настройки так, что в результате вы получаете решение с ‘одним касанием’.
В этой части (которая будет разделена на две отдельные части) об изоляции домена я покажу вам, как создавать решение по изоляции домена для простой сети из трех машин. Эти машины представляют собой следующее:
- Контроллер домена, который будет требовать безопасность. Вы не можете в принудительном порядке внедрить безопасность, так как машины не могут получить групповую политику, если вы принудительно внедряете безопасность. Однако если вы запрашиваете безопасность при подключении к контроллеру домена, члены домена могут подключаться к контроллеру домена для получения групповой политики, после чего они могут защищать остальную часть взаимодействия с помощью контроллера домена. IP адрес в этом примере будет 10.0.0.2
- Сервер, требующий безопасности. Это может быть любой тип сервера ‘ файловый сервер, сервер баз данных, веб сервер. Когда мы покажем подключения в конце статьи, мы просто включим эхо запросы (pings) на сервере, чтобы посмотреть, что правило безопасности подключения работает. IP адрес в этом примере будет 10.0.0.3
- Клиент Windows Vista. Эта машина будет подключена к серверу и контроллеру домена. IP адрес в этом примере будет 10.0.0.100
Серверы представляют собой Windows Server 2008 машины, и все три машины принадлежат одному домену.
Не нужно устанавливать специальные роли, службы или функции, чтобы изоляция домена работала.
Обратите внимание, что это очень простой сценарий, и он не включает исключений, которые вам нужны на серверах в инфраструктуре вашей сети, такие как DNS, DHCP или WINS серверах, а также для стандартного шлюза.
Очень важно в производственной сети, чтобы вы создали эти исключения для внедрения политики IPsec с тем, чтобы машины, не принадлежащие домену, все же имели возможность взаимодействовать с этими серверами инфраструктуры. В конце я предоставлю ссылки, которыми вы сможете воспользоваться, чтобы получить дополнительную информацию о планировании изоляции домена для вашей производственной сети.