Windows 8 Picture Password

One of the new features of Windows 8 is the ability of the user to create a picture password which is quite interesting in its kind. Never before had we seen such functionality in an operating system and Microsoft seems to be very keen in improving the consumer security with such new features in its new operating system coming soon to the market.

Picture password allows you to use a picture instead of text to log in but how? It’s pretty easy and you just need to choose a picture from your computer for your user and then specify which parts of the picture would you like to tap and how many times, before the Windows will allow you to log in.

So every time you want to log in, you will see that picture asking you to tap for example three times on it so that you can log in provided that you have tapped the right places on the picture. Of course tapping is not only restricted to tapping your fingers simply on the screen surface but it will also allow you to draw shapes like lines, circles and etc. on the screen with every tap.

This is a great improvement in Windows and I quite loved the idea. This will make it way more difficult for malicious users to break in by cracking the password. The level of the difficulty in this type of password of course to a large extent depends on the number of taps on the picture and the gestures you have drawn and also some other factors.

Here is a great link through which you can get more information about this new feature.

How people look at your profile page ?!!

I don’t want to talk so much as the picture I have posted below talks enough about itself… This is how people look at your Facebook profile page. This information is based on a study conducted by eyetrackshop.com and it pretty much shows how people unwantedly care about your personal information.

If you want to see the result of the study on the profile pages of the other social networking websites, you can go to this link.

Cheers

Techinsights 2011 SEA – Hey you… Stay away from my network…

Hi everyone,

This is right after my second session on the second day of Techinsights 2011 South East Asia here in Kuala Lumpur, Malaysia. The title of this session was Hey You.. Stay away from my network…

I uploaded the slides for you to download:

Cheers

Techinsights 2011 SEA – Security from the Ground up to the Cloud

Hello folks,

A few hours ago I finished my presentation in Techinsights 2011 South East Asia and here I left the slides for you. I hope you will enjoy it

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:

1

Cheers

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

Security Blackbelt Day 2011

I’d like to announce that I’ll be speaking in Security Blackbelt Day 2011 held in Microsoft auditorium in Kuala Lumpur, Malaysia. This event which is to be held in two tracks for both developers and IT pros, is revolving all around security topics and technologies.

In my session which is called “Private Cloud Security via Microsoft Forefront TMG 2010” I’ll be talking about securing the private cloud infrastructure using Microsoft Forefront Threat Management Gateway 2010. In this session I will be mostly talking about different scenarios and how to place TMG in the network to better and more efficiently protect the private cloud. A lot of other topics like how to secure the connection between the public and private clouds will also be covered.

This is the Facebook link to the event. On this page you can also get more information about the topics and the speakers in this event.

Hope to see you there…

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.