16 May Securing (E)SAE Environments – IPSec Best Practices Update
In this article on IPSec, we want to pick up our March 2019 article ESAE Series Part 5 – Windows IPSec and add some additional considerations. As written about in this post, IPSec (short for “Internet Protocol Security”) is an extension to the TCP/IP protocol suite designed to enable secure communications over potentially insecure IP networks such as the Internet. The context of this and the linked predecessor article on IPSec is securing communications within a Tier 0 environment.
While the solution described in the previous article requires IPSec for inbound and outbound connections within Tier 0, this article presents a solution that is less restrictive and only requests IPSec, making it somewhat easier to implement and maintain in operation.
Advantages and disadvantages
In this section, we briefly summarize the main advantages and disadvantages of IPSec without going into too much detail.
IPSec offers the following advantages:
- IPSec offers two-way authentication between two communication partners with Kerberos v5 protocol, with x.509 certificates or a preshared key. The last method with a preshared key is not recommended for security reasons and is usually only used in practice for test
- Optional encryption of data at IP
- Since IPSec is implemented at the IP layer, it works independently of the applications
The following disadvantages exist in connection with IPSec:
- The connection security rules for IPSec are usually distributed to the end devices via Group Policy Objects (GPO). This requires the end device to be a member of an Active Directory This is the case in most enterprises anyway, but may prove to be a minor disadvantage in certain environments, such as a DMZ, where not all Windows systems may be AD domain members.
- If x.509 certificates are used for authentication, either an internal PKI is required or certificates must be purchased externally from an appropriate
- Using IPSec adds complexity and can sometimes complicate
- When using IPSec encryption, the CPU load is higher on the systems
Effort vs. benefit
Now we want to compare again the effort for the configuration with the benefit.
The communication partners are authenticated on both sides in IPSec via Kerberos v5 or with certificates. It is possible to specify whether authentication is only requested or whether it is required. In the first case, an IP connection between two end devices will be established even if authentication fails, for example, if no valid certificate is installed on one of the end devices in the case of certificate-based authentication. In the second case, no IP connection to the target system will be possible in the event of an error.
The implementation of rules that only request authentication, but do not require it, only provide a security gain if the IPSec connection is encrypted.
If a two-way connection is mandatory, significantly improved security is achieved because a connection is rejected by the target system. Above all, when certificates are used, a connection is only possible if a valid certificate is installed on the system.
The disadvantage of this configuration is that no connection is possible in the event of a misconfiguration, which results in high complexity and a lot of effort in operation for troubleshooting and fault clearance.
In practice, an internal PKI is probably a prerequisite in most cases when using certificates. The acquisition of certificates from an external certificate provider is only economical if it does not involve a large number of systems, as is the case, for example, with servers in a DMZ which only offers a limited number of public services.
An IPSec connection can be optionally encrypted. When using current operating systems and applications, old protocols in which passwords are transmitted in plain text should generally no longer be used. With currently supported Windows versions, care should be taken to use Kerberos throughout and to disable NTLMv2 if possible. The additional advantage of encryption with IPSec is that the user data is also encrypted. Whether this advantage is worth the additional configuration effort must then be evaluated individually on a case-by-case basis.
Restricting remote administration to authenticated systems
In conjunction with inbound rules in Windows Defender Firewall, IPSec provides the ability for only two-way IPSec authenticated systems to have remote administrative access to Tier 0 systems.
- A connection security rule is created that requests certificate-based
- The inbound rules for the Remote Administration Services RDP (port 3389) and PowerShell Remoting (port 5985) are configured to allow only IPSec authenticated connections.
This ensures that Tier 0 systems can only be administered by systems with a valid certificate. These are then in particular the Privileged Access Workstations (PAW) that are intended for administration.
The procedure is described again below.
Connection Security Rule
Encryption with IPSec is configured and a connection security rule is created in a GPO.
- Create a new GPO.
- Navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Defender Firewall with Advanced Security -> Windows Defender Firewall with Advanced Security – LDAP://CN=<CN>.
- Right-click the child entry for Windows Defender Firewall with Advanced Security – LDAP://CN=<CN> and select Properties.
- On the IPSec Settings tab, select Yes for the Exempt ICMP form IPSec option and then click Customize.
5. Under Key exchange (Main Mode), select Advanced and click Customize.
6. Click on Add.
7. Select the strongest algorithm here. SHA-384 as Integrity algorithm, AES-CBC 256 as Encryption algorithm and Elliptic Curve Diffie-Hehllman P-384 as Key exchange algorithm. Confirm with OK.
8. Move the newly created security method to the first position.
9. Under Data protection (Quick Mode), select Advanced and click Customize.
10. Select the Require encryption for all connection security rules that use these settings option and click Add.
11. Again, select the strongest AES-GCM 256 as encryption algorithm and also as integrity algorithm.
12. And again move the newly created configuration to the first position.
13. Click OK.
14. Click OK.
15. Click OK.
16. Navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Defender Firewall with Advanced Security -> Windows Defender Firewall with Advanced Security – LDAP://CN=<CN> -> Connection Security Rules.
17. Right mouse click on Connection Security Rules -> New Rule.
18. On the Rule Type page, select the Isolation option.
19. On the Requirements page, select Request authentication for inbound and outbound.
20. On the Authentication Method page, select Advanced and click Customize.
21. On the left side under First authentication click Add.
22. Select the Computer certificate from this certification authority (CA) option and click Browse.
23. In this dialog box, select the correct root certificate (if in doubt, check the properties of the certificate and, if necessary, the thumbprint).
24. Confirm configuration with OK.
25. Click OK.
26. On the Authentication Method page, click Next.
27. On the Profiles page, click Next.
28. On the Name page, select a name such as Request certificate authentication for inbound and outbound connections and click Finish.
The inbound rules for RDP and Windows Remote Management are also most easily created via GPO.
- Create a new GPO.
- Navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Defender Firewall with Advanced Security -> Windows Defender Firewall with Advanced Security – LDAP://CN=<CN> -> Inbound Rules.
- Right mouse click on Inbound Rules -> New Rule.
- On the Rule Type page, select Predefined and the Remote Desktop group.
5. On the Predefined Rules page, all rules in the Remote Desktop group are now displayed and all are selected. Accept the selection and click Next.
6. On the Action page, select the Allow the connection if it is secure option.
7. On the Users page, click Next.
8. On the Computers page, click Finish.
Repeat these steps for the inbound rules of the Windows Remote Management group. PowerShell Remoting is based on Windows Remote Management.
Distribute GPO and certificates
All systems in Tier 0 then receive valid certificates and can authenticate each other and communicate with each other in encrypted form. For the certificates, it must be noted that at least the following purposes are entered in the Enhanced Key Usage Extension:
- Server Authentication (22.214.171.124.126.96.36.199)
- Client Authentication (188.8.131.52.184.108.40.206)
- IP security IKE intermediate (220.127.116.11.18.104.22.168)
The GPOs with the connection security and inbound rules are then distributed to all systems in Tier 0, i.e., they are linked to all OUs containing computer accounts of Tier 0 systems.
When Tier 0 systems receive the inbound rules via GPO, they are duplicated in Windows Defender Firewall, with the rules from the GPO locked.
If there are multiple rules for a service or port, the more specific rule is applied. In this case, the more specific rule is the one with the restriction to secure authentication that we created earlier in the GPO. This means that the locally existing default rule is thus ignored for RDP and PowerShell Remoting.
Recommendation / Opinion
In the configuration presented above, systems in Tier 0 can only be administered by other Tier 0 or privileged access workstations with a valid certificate via RDP and PowerShell remoting. In addition, all connections between Tier 0 systems are encrypted via IPSec. Since the connection security rule for IPSec only requires authentication, but does not make it necessary, systems without a valid certificate from Tier 1 and 2 can still communicate with the Tier 0 systems as usual.
From our point of view, this is a sensible way to secure a Tier 0 environment, since important protocols for administration (RDP, PowerSell Remoting) can only be accessed from defined systems. If an attacker takes over a poorly secured Tier 2 system, for example, it is not possible to gain administrative access to a Tier 0 system from there. At the same time, the additional administrative effort remains manageable. Application-specific communication is only secured if a valid certificate is available. Tier 2 clients, however, can communicate with the server system as usual. This is not critical, since the vast majority of modern applications communicate in encrypted form anyway, and the IPSec tunnel is only a useful addition.
With the current article, we have slightly adjusted our initial approach of introducing IPSec and proceeding as restrictively as possible, thus achieving the best from a cost/benefit perspective. Nevertheless, the initial article may still have its raison d’être. If you are thinking about very regulated or high-security environments, it may make sense to continue to proceed as strictly as possible and to accept administrative complications in return.
Sieh dir diesen Beitrag auf Instagram an
Sieh dir diesen Beitrag auf Instagram an
ChatGPT 2/3: AI crux
No, in the second part we will not have another interview with ChatGPT and admire at its capabilities. This time we will look at the development and possibilities of AI in general and venture a glimpse into the future, which in the IT world will be...16 March, 2023
Interview with Microsoft Trainer Torsten Fischer
In this interview, we offer you the opportunity to get to know an experienced Microsoft trainer and benefit from his expertise. In the interview with Lisa Werner from Teal, Torsten Fischer talks about his professional roots ...15 February, 2023
ChatGPT 1/3: Revolution in AI technology? – Asking a chat AI questions about cybersecurity
Artificial Intelligence (AI) is a fascinating and always much discussed topic in today's technology and information society. Whether in science, industry or everyday life, the possibilities of AI can be unlimited...16 January, 2023