Muchas veces los administradores de redes, precisamos hacer auditoria por ejemplo de la Navegacion en Internet que pasa por nuestro ISA SERVER. En principio y como regla basica para poder hacer una auditoria de este tipo , todos nuestros clientes deben salir a internet por el ISA ya sea como clientes Web Proxy o Secure Nat. Isa server 2006 trae de por si algunas opciones de reporte las mismas se encuentran en Monitoring - Reports  el problema es que no son muy completos y muy poco flexibles estos reportes , por lo cual podemos utilizar programas de terceros como GFI Web monitor.


Si asi y todo necesitamos hacer una auditoria utilizando la base de datos del ISA SERVER , veremos que la direccion IP aparece cifrada , aqui les dejo una respuesta de un post de Technet , donde se explica como descifrar este numero y pasarla a la lengua de Cervantes.

1. Primera abris la calculadora de Windows y la pones en la vista Cientifica.

2. Asegurate que este seleccionado el modo DEC y pegas tu número 3232236068 .

3. Ahora moves la selección de DEC a HEX eso como resultado te va a dar C0A802224 que son los 4 octetos juntos en HEXA, cada octeto son 2 números hexa.

4. Ahora tomas de a pares del número en HEXA y haces el procedimiento inverso por cada par en la calculadora y te queda conformada tu IP:

CA = 192

A8 = 168

02 = 2

24 = 18

La IP que te muestra es 192.168.2.18 ==> C0.A8.02.24 ==> C0A80224 ==> 3232236068

I watched the Microsoft webinar on the new Server 2008 (formerly Longhorn) certifications last week and came away feeling a little underwhelmed. In case you didn’t know already the MCSE is “dead” for Server 2008 and they are moving on to a “job based” approach to their certifications. Read on for more details.

Windows Server 2008 MCTS Certifications
To begin with, there will be several Microsoft Certified Technology Specialist (MCTS) exams that you can take to certify specific skills on the Server 2008 platform. These are roughly equivalent to becoming a MCP in Windows 2000/2003. You will earn MCTS certification for each different exam that you pass. Here are the initial MCTS exams that will be released:

70-640 MCTS: Configuring Windows Server 2008 Active Directory
70-642 MCTS: Configuring Windows Server 2008 Network Infrastructure
70-643 MCTS: Configuring Windows Server 2008 Application Platforms

70-640 and 70-642 are no surprise but 70-643 is interesting. It will cover Internet Information Services (IIS 7) and Microsoft Virtual Server among other things. Pretty cool. These exams are scheduled to be available 30 days after Server 2008 goes RTM.

Windows Server 2008 MCITP Certifications
There are two different Server 2008 tracks, the Server Administrator and the Enterprise Server Administrator. Both of these are MCITP level certifications, requiring multiple exams. These are the highest level of certification (outside of the MCA program) that you can attain. Here are the requirements for each.

Windows Server 2008 Administrator:
70-640 Active Directory
70-642 Network Infrastructure
70-646 Windows 2008 Server Administrator Exam
***Only 3 exams required; the MCTS exams 70-640 and 70-642 and the main MCITP exam for this track, 70-646

Windows Server 2008 Enterprise Administrator:
70-640 Active Directory
70-642 Network Infrastructure
70-643 Applications Platform
70-620 OR 70-624 Windows Vista Client
70-647 Windows Server 2008 Enterprise Administrator Exam
***5 exams required; the MCTS exams 70-640, 70-642, 70-643, 70-620 (or 70-624) and the main MCITP exam for this track, 70-647

The two MCITP exams are schedlued to be available 60 days after Server 2008 goes RTM.

Do I lose my MCSE/MCSA?
No. You get to keep your MCSE or any credential earned under the Windows 2000/2003 certification track. You essentially have a “MCSE in Windows 2003″ (for example). However, you do not become a “MCSE in Windows 2008″, because the MCSE no longer exists. You will have to upgrade to one of the MCITP certifications referenced above. Your Windows 2000/2003 certifications will not expire and will continue to be valuable as long as Windows 2000/2003 is used on company networks. If you are currently working on your MCSE/MCSA keep working on it…it is still valuable and will provide you with excellent base knowledge that will also apply to Windows 2008.

Can you upgrade your MCSE/MCSA to Windows Server 2008 Certifications?
Yes, there is an upgrade path but only for WINDOWS 2003 MCSEs and MCSAs. If you are certified in Windows 2000, you must upgrade to Windows 2003 first or just take the Windows 2008 exams individually. Here are the upgrade details:

Windows 2003 MCSE - Pass the 70-649 (upgrade) exam and you do not have to take 70-640, 70-642, 70-643. You DO have to take the MCITP: Enterprise Server Administrator exam and the Vista client exam.

Windows 2003 MCSA - Pass the 70-648 (upgrade) exam and you do not have to take 70-640, 70-642. You DO have to take the MCITP: Server Administrator exam.

My Thoughts on the Windows 2008 Certifications
Like I said in the opening, I came away a little underwhelmed. It just seems like the main MCITP certifications do not have enough substance. I am all for simplicity (only 2 or 3 different professional tracks) but I would like to see a few more exams attached to the higher level certs to make them a little tougher to attain. I also think it will be a bit clunky to say (or put on a resume), “I am a MCITIP: Enterprise Administrator, MCTS: ISA Server, MCTS: Exchange Server”, etc. There should be one certification (probably the Enterprise Administator certification) that requires Exchange Server, ISA Server and perhaps SQL Server knowledge, in addition to all of the core Windows Server 2008 requirements. This would be of value to companies and IT professionals alike.

What do you think?

Looking for more information on Windows Server 2008 Certifications? Check out Trika’s Microsoft site; it is loaded with Microsoft certification information and she is very helpful.

Digg Us! If you like this post, please help us out and vote for us at Digg!

Muy frecuentemente preguntan en los foros de Technet como auditar los eventos de Inicio - Cierre de Sesion a lo que normalmente se responde que se puede hacer mediante la politica de Auditoria , aca les dejo un metodo alternativo el cual nos dejara un log , el cual sera mas practico que mirar el Event Viewer :)

Crear los siguientes archivos con el notepad o su editor de texto favorito

------logon.cmd----
echo logon %username% %computername% %date% %time% >> \\dc1\carpeta\logon.log

-----logoff.cmd-----
echo logoff %username% %computername% %date% %time% >> \\dc1\carpeta\logoff.log

Ahora deberemos incluir estos dos archivos dentro de la Default Domain Policy por ejemplo para que se ejecuten al inicio y cierre de sesion
User Configuration-> Windows Settings-> Scripts (Logon/Logoff)-> Logon
User Configuration-> Windows Settings-> Scripts (Logon/Logoff)-> Logoff

Como resultado veremos nuestros dos archivos con los siguientes contenidos , los cuales seran bastante mas facil de consultar en el caso de tener que auditar Inicio - Cierre de Sesion

logon Richard WS01 Tue 22/02/2005 10:39:51.12
logon Peter WS02 Tue 22/02/2005 10:42:01.07

logoff Richard WS01 Tue 22/02/2005 10:41:08.45
logoff Peter WS02 Tue 22/02/2005 10:42:46.81

Espero les sirva

If you missed the first part in this article series please go to Default Deny All Applications (Part 1).

Introduction

Since Windows XP, administrators around the world have had the option to define Software Restriction Policies (SRP) for their client computers to control what software is allowed, or not allowed, to run. So far too few organizations have implemented this functionality despite the fact that it could actually bring a very high level of security, depending on how it is enforced. In this second article about SRP we will look at how to implement what we could also refer to as “software filter policies”.

Danger zone

Before we get too far it is important to point out that, prior to introducing SRP on production computers, you should plan and test them thoroughly. This can be done in Active Directory (AD) by isolating a single test machine or user object in an Organizational Unit (OU) or by setting “Apply Group Policy” permission on the Group Policy Object (GPO) to only that single test-machine or -user account. SRP can even be used on Stand-alone computers if you don’t want to touch the production environment at all. I would recommend you use virtual machines for basic testing and ‘production-like’ machines for the final tests. After heavy testing, the SRP should be implemented on pilot users in groups – it’s better to take small steps than hurrying into disaster!

The overall process

Mistakes in the design or implementation of this can cause considerable user frustration, and even loss of money or productivity, so watch out as you go along. This takes a lot of planning work, testing and probably some maintenance from the day it is introduced in the production environment. From that point on you will be able to sleep tight at night…

The following list gives a quick view of what to have in mind when introducing SRP in a Windows environment.

When designing the SRP setup, different decisions must be made, for example:

• Decide between user and computer GPOs: what AD objects should the SRP policies apply to?
• Decide between a Blacklisting (BL) and a Whitelisting (WL) approach (WL is recommended if possible)
• If using the BL approach, a list of everything that should not run must be made
• If using the WL approach, a list of everything that should run must be made
• Decide what SRP options to use (enforcement, designated file types, administrator exceptions etc.)
• Decide what type of rules to use (path, HASH, certificate or Internet zone)

When testing the SRP setup, different steps must be taken, for example:

• Test the basic functionality in a virtual lab (using Virtual PC/Server, VMware or similar)
• Test the functionality in your environment by using ‘production-like’ machines (and user accounts)
• Test with small groups of pilot users in steps of 5-10 users over a few weeks, then scale up
• Continue to the next pilot group only after successful implementation for the previous pilot users
• Be sure to test all the different user types and machine types you need to secure with SRP
• Be sure to test upgrade scenarios, like patching of the operating system, upgrading third party applications, migrations etc.
• Also focus on performance on the different hardware in your organization. Implementing SRP will in most cases affect system performance a bit, depending on how it is implemented (see the part about Trusted Publishers)
• Sometimes applications launch other applications, make sure this is under full control
• By default Desktop and Start Menu shortcuts (.LNK) are blocked, make sure to modify this as needed
• Be sure that any admin scripts (e.g. login scripts in SYSVOL/NETLOGON shares etc.) are able to run 
  
  

Before introducing SRP in production, some procedures should be in place:

• Introduce a written workflow on how applications, updates etc. should be tested, approved and introduced on the network, so everybody is aware of the procedures required
• Be sure that management knows SRP pros and cons and that they agree on the decision to introduce it
• Have a fallback plan on how to get rid of the SRP GPOs fast, for certain users, groups, computers, sites etc.
• User education: inform users why SRP is important and what the procedure is to acquire new software
• A small tip: Put descriptions on SRP rules, over time a good naming convention will save you some time

Different paths to SRP

Configuring a Software Restriction Policy is basically only a few steps:

1. Creating a User or a Computer GPO and placing it on a Site, Domain or OU (or as a local policy) and enabling SRP within the Group Policy. The SRP settings are located here (see Figure 1):
   
   Computer Configuration| Windows Settings | Security Settings | Software Restriction Policies
   User Configuration | Windows Settings | Security Settings | Software Restriction Policies
   
   The first time SRP is introduced in a GPO, the option “New Software Restriction Policies” will be available.

Figure 1

2. Setting the Default Security Level. Figure 2 shows how the level is set by right-clicking the wanted level and choosing “Set as default”.
   
   • The default level is ‘Unrestricted’ which means that all software can run and that additional rules for disallowed software should be made – this is also known as Blacklisting.
   • The most secure level is ‘Disallowed’ which means that no software can run and that additional rules for allowed software should be made – this is also known as Whitelisting.
   • By default the system creates a few rules that allow the operating system to run without any inconvenient blocking
     NB! If those rules are removed or changed without any thought, the affected system(s) could become unusable.

Figure 2

3. With Windows Vista and Longhorn we have a new level called ‘Basic User’ which allows programs to execute as a user that does not have Administrator access rights, so the user can access resources accessible by normal users only. This level is not addressed any further in this article.
   
   

   File types can be removed and added to fit any environment, but the default file type list includes the most common executables: BAT, CMD, COM, EXE, HTA, LNK, MSI, OCX, PIF, REG & SCR and in addition these extensions: ADE, ADP, BAS, CHM, CPL, CRT, HLP, INF, INS, ISP, MDB, MDE, MSC, MSP, MST, PCD, SHS, URL, VB & WSC.

   Note: As the Designated Files Type Properties dialog states, the list is “in addition to the standard program file types, such as EXE, DLL and VBS” – I haven’t been able to get a complete list of those, but I have confirmed that VBS, VBE, JS and JSE are blocked even though they are not in the list. I would have preferred a single list administrators around the world could change as needed, but that’s how it is.

Figure 3

4. Setting up exceptions to the Default Security Level. These are known as ‘Additional Rules’. Please see the subject “Additional Rules” in this article for further information.
5. Configuring ‘Enforcement Properties’. See Figure 4, this includes:
   • “All software files”: We have the option to check DLL’s (Dynamic Link Libraries) when they are executed too. This is not a default setting and will have some impact on both performance and planning/implementation/maintenance tasks.
   • “All users except local administrators”: Here we can choose whether or not SRP should apply for Local administrators. By default all users are hit by SRP. This policy option is only relevant for computer policies.
   • “Enforce certificate rules”: Option to choose whether or not to use certificate rules should be applied. Note: As stated in the dialog in Figure 4 “Certificate rules will negatively impact the performance of your machine”.

Figure 4

6. Configuring ‘Trusted Publishers Properties’, also known as Authenticode policy options (see Figure 5). In this dialog we can choose who should be able to select Trusted Publishers for certificate rules. We also have an option to verify whether a certificate is revoked or not, and/or to check if the timestamp is valid when it is added.

Figure 5

Additional Rules

When configuring Additional Rules, a method - or a couple of methods - on how to indentify software should be decided. We have 4 different software identification methods available:

1. HASH rules
   
   HASH’es are cryptographic fingerprints that remain regardless of the file name and location. These are especially good when using WL, but not that effective when BL (the reason for this is partly described by the ProduKey example in my first SRP article): An MD5 or SHA-1 HASH gives strong software identification of the ‘ProduKey.exe’ binary file, so allowing a specific HASH value to run makes sure that only that version of the executable can run. However, disallowing a specific HASH only affects one version (or compilation) of the application and a smart user can change the file pretty easily so it is identified as another (unknown) piece of software. The word ‘unknown’ is very important in this matter – it’s really the key to decide between BL or WL – do we want users to be able to execute software we don’t know, yes or no?
   
   If users should not be able to run an old version of a specific application, let’s say it’s ‘buggy’ and causing system crashes, using a ‘deny this HASH value’-rule would be a good decision. Please keep in mind that a new version of a given application will always result in a new HASH value that must be allowed – or disallowed.
2. Certificate rules
   
   Certificate rules uses signed hashes and provides very strong software identification, but as we trust a given certificate we actually trust all software signed with that specific certificate. This could be a good thing or a bad thing. It’s a good thing if we, for instance, get an application from a third party vendor who signed all the significant files in the application (maybe including DLLs), so instead of making a given number of HASH rules we can just create a single rule that trusts the certificate and we are up and running. But, let’s say I trust a digital certificate used to sign some tool from Microsoft (or any other software vendor) – now my users are able to run all applications signed by that specific certificate… Hmm, so the problem is to know exactly what applications were signed by that certificate? Without that knowledge we don’t know what we have allowed. Instead of allowing just the single application we needed for our users, we might have allowed hundreds of applications from the vendor to run on our systems.
   
   Testing of Certificate rules can be done by using these tools: File Signing Tool (Signcode.exe) & Certificate Creation Tool (Makecert.exe).
3. Path rules
   
   Path rules are the most common and “easy-to-use” rules we have. Path rules can deny or allow a file on a specified location (e.g. “C:\Scripts\Script.VBS”), a filename (e.g. “Script.VBS”), a folder (e.g. “C:\Scripts”), a UNC path (e.g.”\\SERVER\SHARE\File.VBS”) or a registry path (e.g. “%[Registry Hive]\[Registry Key Name]\[Value Name]%”). Path rules can use environment variables (e.g. “%WINDIR%”) and the wildcards ‘?’ = one char (e.g. “\\SERVER??\Share\Script.VBS”) and ‘*’ = any number of chars (e.g. “*.VBS”).
   
   If you are using path rules a few things need to be addressed:
   
   
   • If a given folder path is set, this also effects all executables in all subfolders
   • If a user has write access to a folder that is set to Unrestricted, the user can copy any file to that directory and execute it from there. The design should take care of this issue, perhaps by introducing ACL (Access Control List) settings by the use of Group Policies
   • If the user has write access to an executable that is specified as Unrestricted, the user could overwrite that executable with another one to circumvent the SRP
   • If a folder path includes environment variables, like %TEMP%, even a limited user could change the user environment variables by using the SET command to another path (SET TEMP=C:\MyFolder) – and suddenly the user can control what software can be run by copying executables or scripts to that path.
     
     
   As stated above, users may try to rename or move disallowed files – or overwrite unrestricted files to circumvent the SRP – this is why HASH or Certificate rules are normally considered ‘best choice’.
4. Internet Zone
   
   Internet Explorer security zones can be used to control software installation and applies to only Windows Installer packages (.MSI) that are run from one of the default Internet zones. These rules are not that common to use.
   
   When multiple rules are used they are evaluated in the order mentioned above, the default rule will be evaluated as the last rule – the most specific match will take precedence.

SRP Limitations

Some limitations of SRP must be taken into consideration. The scope of Software Restriction Policies is not the entire operating system as you might expect. SRP do not apply to the following code:

• Drivers or other kernel mode software installed
• Any program executed by the local SYSTEM account
• Macros inside of Microsoft Office documents (we have other ways to block those by using group policies)
• Programs written for the common language runtime (these programs use the Code Access Security Policy)

Conclusion

Software Restriction Policies demands a special, and time consuming, workflow when introducing new software and updates in the environment, but besides from that it brings a level of security so much higher than with the “default allow all” setup. Some environments might not be suited for SRP, but my guess is that most networks have computers and/or users for which the SRP technology is ‘spot on’.

It takes dedication, understanding and hard work to implement a “Default Deny” policy – which might be why it is seldom done… One thing is certain, implementing such policies in the correct way will make sure the network administrators can sleep much better at night.

Over the next couple of years it will be interesting to see if Microsoft will continue to develop this part of the Group Policy environment - or if something even better arrives, who knows…

External links

KB 324036 How To Use Software Restriction Policies in Windows Server 2003

Technet: Using Software Restriction Policies to Protect Against Unauthorized Software (Vista/Longhorn)

Technet: Software Restriction Policy for Windows XP Clients

If you missed the first part in this article series please go to Default Deny All Applications (Part 1).

One of the new features in ISA 2004 SP2 is Diffserv. Diffserv is a method of packet prioritization that applies to all web traffic passing through an ISA 2004 SP2 Server. Using the Diffserv Web filter, the ISA server can scan the Uniform Resource Locator (URL) or domain name and apply packet priority using DiffServ bits.

The Diffserv web filter has been given a high priority, and is near the top in the list of Web filters. The Diffserv web filter must be made aware of the size of the request/response being sent and has to inspect the data when it is being sent/recieved by the ISA server. It is crucial that you do not change the priority of the Diffserv web filter. Before we get started configuring this, you should be aware of the following: - Diffserv prioritization only applys to HTTP and HTTPS traffic - ISA may strip Diffserv bits for traffic using other protocols - First packet priority is not assigned to responses coming from the cache - By default, the size of the first chunk is not taken into account for first packet priority To begin, open the ISA Management MMC and expand the Configuration node and then click on General. Click on Specify Diffserv Preferences.

On the General tab, ensure the box next to "Allow the setting of Diffserv bits according to URLs and domain names" is checked.

On the Priorities tab, click Add to create a priority. Enter the name for the priority and the Diffserv Codepoint. The Codepoint is a 6-digit binary value which specifies the priority level. There is more information about the different Diffserv Codepoints at the end of this article. For this example we will use 100110 which is one of the high priority Codepoints.

Add another priority called Low and give it a value of 001010.

Next select the URLs tab and click Add. Enter the URL (wildcards are supported) and choose one of the priorities you created in the previous steps.

Here I have added two URLs, one with high priority and one with low.

URL Diffserv settings only apply to HTTP traffic. If you wish to set priorities to HTTPS traffic you must use the Domains setting.

Finally, under the Networks tab, you can choose which Network Sets to apply the Diffserv filter to.

Once you are done configuring the Diffserv preferences, apply the configuration to the ISA server and you are good to go!

For more information see: