Private Cloud Security via Forefront TMG 2010

Good evening everyone… I need to thank those of you who attended my session in Microsoft TechDays 2011 event called Security Blackbelt Day at Microsoft auditorium. I hope you enjoyed it and it was useful. I shared the slides so that you could use them:

Private Cloud Security via Forefront TMG 2010 [slideshare id=10008891&w=425&h=355&sc=no]

Cheers

Joining Forefront TMG to a Domain or Workgroup…

It’s been always a big question whether the firewall protecting the network should be joined to the Active Directory domain or not? There are so many arguments going on around this topic. In this post, I am focusing more on Forefront Threat Management Gateway 2010 as our firewall and we are going to discuss the pros and cons of adding it to a domain or workgroup.

Type of Installation

PROS

CONS

Domain-Member
  • More control for user access in forward and reverse proxy scenario.
  • Applying Group Policy settings on the TMG server from the central DC and therefore hardening the server running our firewall.
  • Using Kerberos authentication when publishing different servers and therefore increasing the security.
  • Support for authentication using client certificates as the main method of authentication.
  • In case the TMG server is in the perimeter network separated from the internal network by another firewall, there should be more ports open on that firewall to allow the communication between the DC and the TMG.
Workgroup-member
  • If the firewall is compromised, the directory services might not be affected.
  • Even if Active Directory is compromised, the firewall might not be compromised because it isn’t part of the domain.
  • Doesn’t give you the ability to use the domain users and accounts to be used in integration with the TMG.
  • Client certificates can not be used as the main method of authentication.
  • User accounts are created on the firewall itself to allow intra-server communication.
  • Doesn’t support Active Directory Group Policy.
  • TMG client authentication requires account mirroring on TMG

What mentioned above was just a pretty simple comparison which can be found everywhere. But now I want to extend this discussion by first clarifying whether the domain controller and our AD environment will be at risk if we add the TMG to the domain and make it a domain member server. I personally believe in a simple configuration, joining a TMG server to the domain could expose the network to some sort of security risks and depending on the knowledge of the attacker, there could be further attacks on the domain controller and also the other services.

This type of attack usually happens when there is only one layer of TMG firewall between the outside network and the internal network. In a two-level TMG firewall design, we will have more flexibility playing around with the rules inside TMG. In a two-level firewall or what we call as a back-to-back firewall design we can join the front-end TMG firewall to the domain so that we can make use of all the domain features for the clients connecting to the front-end TMG. We also can join our back-end TMG firewall to a workgroup. In this case even if the front-end TMG is owned by an attacker, there still will be a back-end TMG a head of the attacker to get to the main network and the DC.

The question that might come up here is that the back-end TMG still has some ports open so that the front-end TMG can communicate with the DC in the network and you might wonder whether having that back-end TMG is useful at all? And the answer is YES, it is useful since just opening a port on a firewall to let the authentication traffic through doesn’t expose any security risk to the network. A firewall can stop a lot of different types of attacks and therefore that back-end TMG can protect the whole network environment even if the front-end domain-member TMG is owned by the attacker.

In this post I just tried to give you some insights. I suggest whenever you are thinking of integrating any service or software or product with Active Directory, do not panic because of potential security risks but try to analyze the situation and what you want to implement and take every step very carefully and consider even very small risks, then maybe you will realize that the integration of services and products with AD is not that scary…

You want to learn more? Check out my new book below and have access to great and practical tutorials and step-by-step guides all in one book. 

To get more information about the book click on the book below:

1

Cheers


Securing Registry by using Permissions

In this short note, I’d like to talk a little about Windows registry and how you can secure it using permissions. Basically registry is composed of six hives that are described as below:

HKEY_CURRENT_USER = It stores information about the profile of the user who is logged into the system now.

HKEY_USERS = It has subkeys about all the users’ local profiles.

HKEY_CLASSES_ROOT = It contains file associations and information about COM registration

HKEY_LOCAL_MACHINE = It contains the configuration of the operating system and applications

HKEY_CURRENT_CONFIG = It includes the current hardware profile used now

HKEY_PERFORMANCE_DATA = It has information about performance counters

 

When the system is up and running, the registry is loaded into memory and when the system is shut down, the values in the registry are written into the hard disk. Below is the location for some registry hives:

HKEY_LOCAL_MACHINESYSTEM =          %systemroot%system32ConfigSystem

HKEY_LOCAL_MACHINESAM =                %systemroot%system32ConfigSam

HKEY_LOCAL_MACHINESECURITY =      %systemroot%system32ConfigSecurity

HKEY_LOCAL_MACHINESOFTWARE =   %systemroot%system32ConfigSoftware

HKEY_CURRENT_USER =               %systemdrive%Documents and Settings<username>Ntuser.dat

HKEY_USERS =  %systemdrive%Documents and Settings<username>Local SettingsApplication DataMicrosoftWindowsUsrclass.dat

HKEY_USERSDEFAULT =              %systemroot%system32ConfigDefault

 

Just like NTFS permissions on files and folders, we also have permissions on registry container objects. Individual registry value inherits its security permissions from its parent object. We generally have two types of permissions for registry objects: Read and Full-Control permissions. Apart from that, we also have special permissions on registry objects which are as follows:

Permission Description
Query Value Allows the value of the registry key to be read
Set Value Allows the value of an existing key to be written
Create Subkey Allows the creation of subkeys
Enumerate Subkeys Allows the enumeration of subkeys
Notify Required to request change notifications for a registry key or for subkeys of a registry key
Create Link Reserved for use by the operating system
Delete Allows the key to be deleted
Write DACL Allows the modification of the DACL
Write Owner Allows the modification of the owner
Read Control Allows the SACL to be read

In order to set permissions on a container in registry, you just need to right click on that and click Permissions:

That’s it for today friends 🙂

All the best 🙂

Securing Branch Office Networks using RODCs

Nowadays networks are not anymore limited to only one single LAN connecting computers together. Companies are growing and so are the networks. Companies have branch offices in remote locations all connecting together through different types of network mediums. So, network are expanding at the speed of the light.

Talking about branch offices, there are so many challenges when configuring a network environment in a branch office and a lot of things need to be considered. I would like to briefly describe three of these challenges here:

Cost Control: Reduce the cost of managing and supporting remote offices (including making most efficient use of network links).

Security: Improve Security of Data and Access.

Agility: Providing a flexible infrastructure that maximizes IT investment.

In this blog post I am only going to talk about security as one of the most important concerns when implementing branch offices and this note will mostly revolve around the network environments implemented and configured on Microsoft systems.

One major component of Windows Server 2008 R2 that has a direct impact on securing your branch offices is Read-Only Domain Controller (RODC).

As the name suggests, RODCs are read-only databases of the AD DS meaning that they require only unidirectional replication for Active Directory, as well for the File Replication Service (FRS) and Distributed File System Replication (DFSR).

This one-way replication brings along a security benefit. Any compromise or other issue that introduces poisoned data into the RODC’s local copy of the AD DS database cannot be replicated back to the rest of the domain controllers in the other locations from the affected RODC. This is certainly a mitigation that can help stop a local problem from becoming a global problem.

One-way replication brings benefits in terms of designing your replication topology and controlling replication traffic, as well. Bridgeheads and hubs do not have to poll the RODC for changes. The RODC performs normal inbound replication for AD DS and FRS and any DFSR changes.

Because the RODC is a member of the domain, sometimes it has a need to write to Active Directory. However, it does not write to the local database, but will instead connect to a writable domain controller, just like a workstation. The RODC computer account is a workstation account, so it has very limited rights to write to AD DS—again to minimize any damage to the enterprise AD DS if the RODC is compromised. Because they are “workstations” in this sense, RODC computer accounts are not members of the Enterprise Domain Controllers (EDC) or Domain Domain Controllers groups.

Administrative Role Seperation:

With Role Separation you can delegate the local administrator role of an RODC computer to any domain user without granting that user any rights to the domain itself or to other domain controllers. In Windows Server 2003, DCs didn’t have a local administrator; if you could administer a DC, you could administer the whole domain.

Administrative Role Separation can allow a local branch user to log on to an RODC and perform maintenance work on the server, such as upgrading a driver, without allowing that user to log on to any other domain controller or manage the domain.

All in all, RODCs provide a way to deploy domain controllers more securely in a branch office location because they are designed to be placed in locations that require rapid, reliable, and robust authentication services but that might also have a security limitation that limits or prevents deployment of a writable domain controller. With an RODC, organizations can mitigate risks with deploying a domain controller in locations where physical security cannot be guaranteed.

Microsoft Attack Surface Analyzer

I’m back with a great tool released by Microsoft which is still in the beta version. It is called Attack surface analyzer. This tool is used when you want to know to what extent your system is exposed to attacks after installing so many software and applications on it.

In order to make use of this tool, you need to scan the system using it once when the system is clean and before the installation of any software or application and get a baseline scan report. The sec

ond time you run a scan is when you have installed applications and softwares on your system and you want to know how much exposure to attacks they have given to your system after their installation. After the second scan is run, it will give you a report of the security vulnerabilities found on your system.

You can download the tool from here.

I hope you can use it for good.

Cheers

Step-By-Step Guide on Configuring Applocker in the Domain…

As a systems admin, you might have probably wanted to deny your users to use a particular software application. This is pretty common since using some applications in some network environments is illegal.

In order to block an application, we can make user of a great feature called AppLocker available in Windows 7 and Windows Server 2008 R2. Here is a step by step guide on how to configure AppLocker in the domain or on computers in a special OU or site.

Let’s assume in this exercise you want to block the Chess game on all the computers in your domain.

First of all, on your DC you need to go to Administrative Tools and open up Group Policy Management console and then right click on the Default Domain Policy and click Edit to open Group Policy Management Editor.

Then here, under Computer Configuration go to Windows Settings -> Security Settings -> Application Control Policies -> AppLocker

Before anything right-click on AppLocker and click on Properties and then under Executable Rules, click on Configured and choose Enforce rules:

And then as shown in the below photo right click on Executable Rules and choose Create New Rule:

Once you click on Create New Rule, this window will open up and you just need to click on Next:

On the next Window, you will need to select which users or groups this rule applies to and whether you want the rule to allow users or deny them to use that application. Once Configured, click Next:

On the next window choose File Hash and then click Next:

On the next windows click on Browse Files and choose the program file and then click Next:

Give the new rule a name and then click Create:

Now the new rule must have been added under Executable Rules as shown below:

Now if anyone in the domain tries to open Chess from their computer, they will receive this message, meaning that Chess game has been blocked by a policy:

You want to learn more? Check out my new book below and have access to great and practical tutorials and step-by-step guides all in one book:

To get more information about the book click on the book below:

1

Good luck for the weekend

Cheers

Forefront Endpoint Protection 2012 Beta is out…

It’s been a while Microsoft has been working on its Forefront products and they have been really successful in offering products that are of great help to increase the security of the network environment and systems both on the server-side and client-side.

I personally love them all and have more experience working with Forefront Threat Management Gateway 2010 and truly enjoyed all the better features it has in comparison with ISA Server 2006. When you have the experience of working with a product for quite a long time and wish for some added functionalities, once the new product is out and gives you all of them, that’s when you have a really good feeling. I guess Forefront products give you exactly the same kind of feeling.

Now Forefront Endpoint Protection 2012 Beta is out. Before we go a little bit further with the features, let me give you an overview on what it is. FEP helps businesses efficiently improve endpoint protection while decreasing the costs. It is built on System Center Configuration Manager allowing businesses to use their existing client management infrastructure to manage the endpoint protection. Right now this beta version is compatible with System Center Configuration Manager 2012.

But let’s see what’s new in this new beta release of FEP:

  • Supporting System Center Configuration Manager 2012
  • Improved real time alerts and reports
  • Role-based management
  • User-centric reports (post beta)
  • Easy migration from FEP 2010/ConfigMgr 2007
  • Support for FEP 2010 client agents
FEP 2012 provides protection against known and unknown threats using advanced techniques such as behavior monitoring, network inspection system and heuristics. It also has a real-time cloud-based update system through Spynet service helping it to stay up-to-date.
If you need more information on FEP you can click here and here.
I hope you will be among the early adopters of FEP 2012.
Cheers

The Enhanced Mitigation Experience Toolkit (EMET)

In the previous posts of my blog we talked a little bit about security exploits and how they function and how to prevent from attacks using security exploits. In this post I am so excited to introduce a great toolkit offered by Microsoft to defense against the exploitation of the system.

The tool is called Enhanced Mitigation Experience Toolkit (EMET) which uses exploitation mitigation techniques making it very difficult for exploits to defeat the system. However the protection applied by EMET does not guarantee that the system will not be exploited but it just makes it as difficult as possible to exploit the system even using a 0-Day vulnerability exploits. 

Working with EMET is pretty simple and you just need to download it from here  and then install it on your machine and simply choose the software that you want it to protect and you believe is more probable to have a security vulnerability and then you are all done. It is possible through the GUI interface of the tool.

EMET is compatible with any software and it does not really matter whether the software you want to protect is a Microsoft software or not. Below is a screenshot of the GUI interface of the toolkit:

You should for sure try this tool as it’s a must for every security engineer worrying about the security of their environment with all those softwares installed on their servers which each could have possible security vulnerabilities putting the whole network and system at risk.

You want to learn more? Check out my new book below and have access to great and practical tutorials and step-by-step guides all in one book: 

To get more information about the book click on the book below:

1

Cheers

Possible Attacks on Windows and Countermeasures – Part 1

It’s been a great week with so much news in the world of security. Of course Security both in the real world and the virtual world. Today I decided to begin writing a series of articles about possible attacks and their countermeasures on Windows operating systems whether client or server including the latest ones such as Windows 7 and Windows Server 2008 R2.

In this series I will try to put a little bit of my experiences into words and in easy words explain to you different types of hacking techniques used by attackers to penetrate into your network. I will try to get it started with the most common ones to the most advanced like those causing millions of dollars loss; and then I will dig into different ways of defense against such hacking techniques and will show you how to keep your network services and servers secure against them.

Password Cracking Attacks:

This is one of the most common types of attacks used at least once by every attacker. It always seems the dummiest but honestly this has shown to be one of the most effective way to find a way into somebody’s computer if not protected against such attacks.

This type of cracking has a pretty long history and I really cannot count the number of softwares developed to crack password by different hacking groups or even security companies. The only difference between these two is that the second one believe their software is only purposed for a so-called act of Ethical Hacking but who knows what is being done by those tools and softwares.

There are different ways to perform password cracking among which Brute Force attacks are the most popular. Brute Forcing is simply finding a computer’s password by trying different combinations of letters, numbers and even characters. The time required for it to work depends on the complexity of passwords. However more complex the password, the longer it takes to be cracked.

A single computer can try from one to fifteen million passwords per second against a password hash (That is true) for weaker algorithms like DES (Which is very commonly used nowadays) using a fairly good password cracking tool and if let’s say you choose an 8-character password of letters (both cases), numbers and symbols, we could say that it would take something like 16 minutes for it to be cracked. So you feel pretty unsafe.. huh???

Attackers nowadays could easily find pre-computed password hashes for different algorithms stored in database files called Rainbow Tables and it would take a matter of minutes to crack almost any passwords in a network.

There are other techniques used as well such as dictionary or words-list attacks that are usually tried before the Brute Force to kind of guess the user’s password if the user has used common dictionary words or things like 123456 or anything like that as passwords.

L0pht Crack:

One of the most famous password cracking tools is l0pht Crack developed by a famous group of expert hackers called l0pht who officially joined @stake which itself was later on announced to be an acquisition of Symantec corporation. You can download the latest version of L0pht Crack from their website. Below is a screenshot of this tool:

Any operating system could be the target of this tool even Windows Server 2008 R2 and could really well work on almost any operating system to target the other hosts on the network. You can get more information on their website.

John the Ripper:

John the Ripper is another well-known name among password cracking tools. This is a tool firstly developed to be run on Unix-based operating system but now it supports Windows as well. You can download this tool from their website.

John the Ripper truly is one of the fastest password cracking tools I have ever seen. It is being used by a lot of penetration testers and of course hackers every day.

Countermeasures:

Protecting your network against password cracking is completely dependent on the policies on your network and your servers and clients. Whether you have a very small environment and operating a workgroup of computers or you have a big domain network you should have policies and more specifically account and password policies.

Password policies can be defined in Group Policies in Windows and Active Directory. So if you open up the Group Policy Editor either locally (By typing gpedit.msc in thr Run) or on the domain using the Group Policy Management console, you need to go to:

Computer Configuration -> Windows Settings -> Security Settings -> Account Policies -> Password Policy

Below you can see a screenshot of the password policies settings:

Now let’s go one by one with what they mean:

Enforce Password History: You can set how many passwords for each user is stored in the history. If we set this number to 10, it means the user is not able to choose any of the past 10 passwords for his new password.

Maximum Password Age: The maximum time a user can keep a password and after it comes to an end, they should change it.You could use it to force the users to change their passwords every now and then.

Minimum Password Age: The minimum time a password must be used before a user changes that. You can use it to stop users from changing their passwords every hour.

Minimum Password Length: The number of characters that a user must have in a password. Do not let it be less than 8.

Password must meet complexity requirements: You can decide whether or not you want to force the user to choose a password including letters (Both cases), numbers and symbols. You must definitely enable it.

Store passwords using reversible encryption: Let it be disabled as it is used by some protocols rarely used and enabling it is equal to storing the passwords plain-text.

The other settings that you need to configure is Account Lockout policies which are more important if you want to protect against the brute force attacks:

So in order to access the policies you need to open the Group Policy Editor and go to this address:

Computer Configuration -> Windows Settings -> Security Settings -> Account Policies -> Account Lockout Policies

Account Lockout Duration: How long do you want the account to be locked out after a number of invalid logon attempts.

Account Lockout Threshold: How many invalid logon attempts are needed to lock the account. If you set it to a number, then the password cracking tools can not try millions of passwords on your computer since the account is going to get locked.

Reset Account Lockout Counter After: If you set it to 30 minutes for example, in 30 minutes if there are more than 4 invalid logon attempts are made, then the account gets locked. If it takes more than 30 minutes for the number of invalid logon attempts specified in the previous settings, then the account does not get locked and the policy will not apply so you must be really careful when defining your policies.

Usually 30 minutes will be the best since it can block all kinds of password cracking tools even the slowest ones.

Here we come to the end of this first article and I hope you liked it. If you had any question, please leave me a comment and I will answer that almost in no time.

You want to learn more? Check out my new book below and have access to great and practical tutorials and step-by-step guides all in one book: 

To get more information about the book click on the book below:

1

Cheers

Active Directory Domain Services in the Perimeter Network – Part 2

Let’s start this post with a question about RODCs (Read-Only Domain Controllers) because this post is all dedicated to placing an RODC in the DMZ (perimeter network):

Notes: From now on I will use the term DMZ instead of the perimeter network just to help my laziness.

Q: What are the benefits of RODCs in the DMZ?

Reducing the attack surface by placing an RODC instead of a writable domain controller.

-Giving directory service to applications that require access to Active Directory and are located in the perimeter network

Decrease the type of the traffic passing from the DMZ to the LAN and vice versa


You have to keep in mind that the clients and member server running in the perimeter network need to be Windows Vista and Windows Server 2008 and above, Otherwise a hotfix called RODC compatibility pack needs to be applied to them. You can download the hotfix from here. However you might not need to have the hotfix even but just to be on the safe side, do patch the clients and member servers using the hotfix.

Other recommendations about placing RODCs in the DMZ:

-Promote the server to an RODC on a Server Core edition of Windows Server 2008 R2

-If you have IPSec policies in your environment, make sure those IPSec policies are applied to the RODC so that it will be able to communicate with the rest of the members in the DMZ. There is something very important about IPSec policies on a DC:

Since all the member servers and possibly clients are going to communicate with the RODC using IPSec, bear in mind that the type of authentication used between the clients or servers and the RODC must not be Kerberos. There is one reason for that becasue the kerberos authentication is verified by the Domain Controller and if the client or server is not allowed to talk to the Domain Controller in the first place, how is it going to approve its authentication request? 

Therefore we need to use pre-shared keys or make use of Certificates (We need a CA Server) in order to authenticate the client. The use of certificates is preferable and is more secure than the pre-shared key.

-There is another question that comes up here and that’s if we have clients or serves that require dynamic updates on the DNS Zones in the DMZ, how are we going to handle that since we do not have a writable Domain Controller?

First of all apparently we hardly ever place a client in the perimeter network and if we do, the best security practice is to do a manual DNS update on the DNZ zone inside the LAN and then have it replicated to the RODC in the DMZ and you also need to disable dynamic updates on the client and servers in the DMZ.

Ports to be open on the firewalls:

Ports to be open on the firewall between the RODC in the perimeter network and the writable Domain Controller in the LAN:

Port Type of traffic
TCP 57344 DRSUAPI, LsaRpc, NetLgonR
TCP Static 53248 FrsRpc
TCP 135 EPM
TCP 389 LDAP
TCP 3268 GC, LDAP
TCP 445 DFS, LsaRpc, NbtSS, NetLogonR, SamR, SMB, SrvSvc
TCP 53 DNS
TCP 88 Kerberos
UDP 123 NTP
UDP 389 C-LDAP
UDP 53 DNS
TCP and UDP 464 Kerberos Change/Set Password

Ports to be open on any host or network firewall between a member server in the perimeter network and the RODC in the perimeter network:

Port Type of traffic
TCP 135 EPM
TCP 389 LDAP
TCP 445 DFS, LsaRpc, NbtSS, NetLogonR, SamR, SMB, SrvSvc
TCP 88 Kerberos
TCP Dynamic DNS, DRSUAPI, NetLogonR, SamR
UDP 389 C-LDAP
UDP 53 DNS

That’s it for today with RODCs. I just tried to put things in a nutshell so that you can get the main points.

You want to learn more about this topic? Check out my new book below and have access to great and practical tutorials and step-by-step guides all in one book:

To get more information about the book click on the book below:

1

Cheers