Tech Insights 2011 SEA

Tech Insights is a 3-year old conference happening on 16th and 17th of November which focuses on the most recent technologies (mostly on Microsoft actually) in the market. Like the previous year, I am speaking at this conference this year and I will be presenting two topics which are as below:

Security from the ground up to the cloud which is going to be about security in cloud computing and generally those security implications that people would like to know about when moving to the cloud. a lot of things related to cloud computing and its security will be talked about in this session of mine.

Hey you… Stay away from my network is going to be my next session on the second day of Tech Insights SEA 2011… I once had a similar session to this at ELITE annual event but this one is supposed to be more technical and I’m going to show people real live demos of tips and tricks hackers use to get into your network and then I will show you how to stay firm against them.

I hope I will see you at Tech Insights this year. If you are attending the event, do come to me and say Hi and I would be more than happy to have a cup of tea (not coffee seriously) with you. Right now we are less than a week away from the event but the registration is still in progress. This year’s conference will be held at Monash university in Sunway city in Malaysia. During the two days of the event, you will be able to meet and talk to the speakers and professionals speaking at Tech Insights and I promise it will be a great experience.

If you need more information about Tech Insights 2011 SEA please visit their website at this link.

Wish you a great weekend

Detecting Common Attacks using TMG Intrusion Detection

Apart from those complicated and advanced-level attacks that are targeted against every network every once in a while, there are common attacks that could be really troublesome. A lot of time this happens when people believe that their network does not contain any important data to even go under attack and when the attack occurs, they panic because they don’t expect it and in fact they have nothing to even stop this type of attacks.

Forefront Threat Management Gateway 2010 has an IDS (Intrusion Detection System) inside as one of its features that can detect many of these attacks. To access and configure this feature in TMG you need to go to Intrusion Prevention System and then click on Behavioral Intrusion Detection and first click on Configure Detection Settings for Common Network Attacks:

Here you can see a list of different types of attacks that if checked will be detected and a log will be created for them in the Monitoring section of the TMG. For instance if you check the Port Scan, you can specify the number of ports to be scanned before the TMG considers the traffic as a port scanning attack and can log it.

In the other tab, we can also detect different types of attacks against the DNS service:

Coming back to the Behavioral Intrusion Detection tab in TMG, you can also click on Configure IP Options Filtering to filter specific IP options that may be included in the IP packet’s header. Most IP options in the packer header are harmless but there are some of them that could indicate malicious traffic and must be checked. They are shown below in the picture. If there is any traffic containing these options in the packet header, they will be dropped if you select Deny packets with the selected IP options.

Under the other tab called IP Fragment, you can block IP fragments to block the type of traffic generated from those applications that fragment the packets so that they will not be detected by the firewall but you have to keep in mind that if you enable blocking of IP fragments, you may also block other types of traffic such as L2TP which is pretty common in every network having remote users.

Again under Behavioral Intrusion Detection in TMG, if you click on Configure Flood Mitigation Settings, you will be able to detect and block flood attacks towards the TMG and facing the network. Using this feature you will be able to specify the number of allowed different types of connections to a host and if there are more requests than that, it will be detected as a flood attack and will be denied. You can click on Edit to configure the settings for any of the connection types:

After all this configuration, if there is any traffic detected as attack, it will be logged under the Monitoring section in TMG and will be visible under Alerts. After knowing the source of the attack you will be able to easily block it using the firewall feature if it is not by default blocked.

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:



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]


General Rules of Security

Today in this post I want to talk a little bit about some general rules when it comes to network security. There are so many different running services in every network and securing every each and one of them is such a big pain in the neck but following some general efficient rules and applying them in every portion of your design can assure some really good, if not ultimate, level of security in your network.

Rule #1:

Begin your security from the weakest part. This is very important to know that your network is only as secure as the weakest portion of it. If you have the greatest firewalls and VPN servers placed at the edge of your network but the client infected by a malware, can easily connect to the network, then your network could be at risk. So start small. Start from the clients first and then go bigger.

Rule #2:

Known vulnerabilities are the first to be patched. There are hundreds of security vulnerabilities published everyday on different security websites by security researchers. If you as the security engineer want to check every single one of them and patch the network, it could be a big waste of time, so try to concentrate on the known vulnerabilities and patch the system against the threats threatening those weaknesses.

Rule #3:

A false sense of security is always worse than a true sense of insecurity. I have seen tens of engineers in this field who are always so confident about their infrastructure and they believe their network is fully secure against any attack while they have absolutely done nothing to keep it secure. You know they just keep convincing themselves and the others about the security of their systems and network… But that’s only keeping a blind eye to the reality. The reality is that if someone at least knows that they have an insecure network and environment or at least they know which part is more vulnerable to attacks, then in case of an attack they will know which part they are hit at and taking action is always more easily done.

Rule #4:

Keep the security design as simple as you can. The more complex your systems, the less secure it is. I have seen a great number of really complicated systems that even the system designer was not able to understand some parts of it and in such network do you think security can be totally accomplished? Don’t you think there will be always some ways hackers will be able to find a way into that very complicated system even without anyone realizing.

Rule #5:

The more secure the system, the less usable it is for the user somehow, so know the limits. What is the main objective of a service? To serve users right? Right… So, it first of all needs to be usable and usability must never be sacrificed by security. Remember security and usability are always inversely proportional.

I hope they were some good and useful tips for you. I thought they could help you have a better understanding on what a pretty good and secure design is and how you can accomplish that…


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



  • 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.
  • 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:



Security Dependencies

To me, systems security is not all about the configuration but it is mostly about design. Staying away from attacks and keeping the environment safe pretty much depends on how the security engineer designs a system. There are a lot of things that play very important roles in bringing security to systems. One of the most important things that should be paid a great amount of attention to is security dependencies.

A security dependency occurs when the security of a system is dependent on the security of another system. This is the case in almost all networks with all these unified systems deployed in each of them. Take Active Directory for instance. In an AD environment there are so many different services which get authenticated and authorized with the Domain Controller. What does it mean? This simply means that the security of all those systems running those services are dependent on the security of the Domain Controller. Once the DC is hacked, the whole network with all those services which are dependent on the DC will be in danger.

This way of thinking will give the security designer a very good view on their design. They pretty much know what they need to begin their design with. They know exactly what kind of data must be stored on each server and how this data is going to be used by the other servers. This way of clarifying things will give the designer a better view on how to relate services and servers.

We generally have two types of dependencies:

Acceptable dependency: In this type of dependency, a less sensitive service or server is dependent on a more sensitive server or service. For example the security of a client PC is dependent on the security of a DC in an AD network.

Unacceptable dependency: In this type of dependency, a more sensitive service or server is dependent on a less sensitive server or service. As a simple example, you can take a DC running Windows Server 2008 R2 in a part of a network being protected by another server running Windows Server 2003 running Routing and Remote Access Service with a basic firewall. This is where we should think again about our design:

Should we run the AD database on a Windows Server 2008 R2 server and protect it from the outside attacks using a Windows Server 2003 or the other way around???!!!

Or maybe we should go a head with a totally different design by adding another Windows Server 2008 R2 to the network.

Thinking about virtualization technologies we get to the same point. The point here is that all the virtual machines (VMs) are dependent on the security of the Hypervisor. With a basic configuration of Hyper-V the whole virtualized environment could be exposed to attacks and once the host is hacked, the other VMs will be at risk but yet again there are ways to make some changes in this kind of dependency and mitigate the attacks. In this post I have explained one of those ways.

All in all, security dependency always exists in our network and systems but what really matters is the level of this dependency and seeing exactly what is dependent on what? In those situations that we have to make a choice, it’s very important to analyze different choices that we have and then choose the one which makes the less sensitive server dependent on the more sensitive one if there is no way to eliminate the whole dependency.


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.


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:


Good luck for the weekend