Immediate Solutions


Setting the Boot Timeout

Allowing users to choose other operating systems (OS) at bootup is a security risk because the other operating systems can be used to bypass or defeat Windows security.

Setting the Boot Timeout Using Bootcfg

To set the boot timeout using Bootcfg from a Windows XP/2003 system, start a command prompt and enter the following:

 Bootcfg /timeout 0 

Related solution:

Found on page:

Displaying the Boot.ini using Bootcfg

28

Setting the Boot Timeout Using KiXtart

To set the boot timeout using KiXtart, proceed as follows :

  1. Create a new directory to store all files included in this example.

  2. Download and extract the latest version of KiXtart, from http://www.kixtart.org, to the new directory.

  3. Select StartRun and enter "kix32 scriptfile. "

Here, scriptfile is the full path of the new directory from step 1 and file name of a script file that contains the following:

  $File  = "C:\boot.ini"  $RCode  = SetFileAttr($File,128) WriteProfileString(  $File  , "boot loader", "timeout", "0")  $RCode  = SetFileAttr(  $File  ,1) 

This script first clears any file attributes on BOOT.INI, modifies the boot timeout, and then marks the file as read-only.

Related solution:

Found on page:

Setting File or Folder Attributes

60

Setting the Boot Timeout Using WMI

To set the boot timeout to zero using WMI, proceed as follows:

  1. Create a new directory to store all files included in this example.

  2. Download and install the latest version of Windows Script Host, from http://www.microsoft.com, to the new directory.

  3. Select StartRun and enter "cscript scriptfile .vbs."

Here, scriptfile is the full path and file name of a script file that contains the following:

 On Error Resume Next   Computer  = InputBox("Enter the computer name", "Boot Timeout" , "localhost")   Set  Boot  = GetObject("winmgmts:{impersonationLevel= impersonate}!\" &  Computer  & "\root\cimv2"). ExecQuery("select * from Win32_ComputerSystem")  For each  Item  in  Boot   Item  .SystemStartupDelay = 0  Item  .Put_() Next 
Note  

The highlighted code above must be placed on one line.

Removing POSIX and OS/2 Subsystems

By default, Windows 2000 includes three environment subsystems: OS/2, POSIX, and Win32 subsystems. Originally developed by Microsoft, OS/2 is IBM's operating system for the personal computer. POSIX stands for Portable Operating System Interface for Unix and is a set of interface standards used by developers to design applications and operating systems.

Win32 is the main subsystem used by Windows, whereas the others are merely present for compatibility with other operating systems and applications. To remove the POSIX and OS/2 subsystems from the command line, proceed as follows:

  1. Create a new directory to store all files included in this example.

  2. Start a command prompt and enter " scriptfile. bat."

Here, scriptfile is the full path of the new directory from step 1 and file name of a script file that contains the following:

 @ECHO OFF RMDIR /Q /S "  %WINDIR%  \System32\OS2" DEL /F /Q "  %WINDIR%  \SYSTEM32\PSXDLL.DLL" DEL /F /Q "  %WINDIR%  \SYSTEM32\PSXSS.EXE" DEL /F /Q "  %WINDIR%  \SYSTEM32\POSIX.EXE" DEL /F /Q "  %WINDIR%  \SYSTEM32\PSXSS.EXE" DEL /F /Q "  %WINDIR%  \SYSTEM32\OS2.EXE" DEL /F /Q "  %WINDIR%  \SYSTEM32\OS2SRV.EXE" DEL /F /Q "  %WINDIR%  \SYSTEM32\OS2SS.EXE" ECHO REGEDIT4 > C:\OS2.REG  ECHO [-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ OS/2 Subsystem for NT] >>  C:\OS2.REG   REGEDIT /S  C:\OS2.REG  DEL /F /Q  C:\OS2.REG  
Note  

The highlighted code above must be placed on one line.

Removing Administrative Shares

Administrative shares are hidden shares created by the system to allow administrators to access files remotely. Although these shares are hidden, they are no secret to the savvy user and should be removed for maximum security. To remove administrative shares, proceed as follows:

  1. Create a new directory to store all files included in this example.

  2. Download and install the latest version of Windows Script Host, from http://www.microsoft.com, to the new directory.

  3. Select StartRun and enter "cscript scriptfile .vbs."

Here, scriptfile is the full path and file name of a script file that contains the following:

 On Error Resume Next Set  SHELL  = CreateObject("WScript.Shell") Set  Drives  = FSO.Drives For Each  Drive  in  Drives   SHELL  .Run "NET SHARE " &  Drive  & "\ /D", 0, False  SHELL  .Run "NET SHARE " &  Drive  & "\WINNT /D", 0, False Next 
Warning  

Certain programs use administrative shares and might not work if they are removed.

Related solution:

Found on page:

Removing Shares

159

Locking Down Administrative Tools

Administrative tools, such as User Manager and REGEDT32, should be locked down for administrative access only. To lock down various administrative tools, proceed as follows:

  1. Create a new directory to store all files included in this example.

  2. Copy XCACLS.EXE from the Windows 2000 resource kit to the new directory.

  3. Start a command prompt and enter " scriptfile. bat."

Here, scriptfile is the full path of the new directory from step 1 and file name of a script file that contains the following:

 @ECHO OFF XCACLS "  %WINDIR%  \POLEDIT.EXE" /G Administrators:F;F /Y XCACLS "  %WINDIR%  \REGEDIT.EXE" /G Administrators:F;F /Y XCACLS "  %WINDIR%  \SYSTEM32\CACLS.EXE" /G Administrators:F;F /Y  XCACLS "  %WINDIR%  \SYSTEM32\CLIPBRD.EXE" /G Administrators:F;F /Y   XCACLS "  %WINDIR%  \SYSTEM32\NCADMIN.EXE" /G Administrators:F;F /Y   XCACLS "  %WINDIR%  \SYSTEM32\NTBACKUP.EXE" /G Administrators:F;F /Y   XCACLS "  %WINDIR%  \SYSTEM32\REGEDT32.EXE" /G Administrators:F;F /Y   XCACLS "  %WINDIR%  \SYSTEM32\RASADMIN.EXE" /G Administrators:F;F /Y   XCACLS "  %WINDIR%  \SYSTEM32\RDISK.EXE" /G Administrators:F;F /Y  XCACLS "  %WINDIR%  \SYSTEM32\SYSKEY.EXE" /G Administrators:F;F /Y  XCACLS "  %WINDIR%  \SYSTEM32\USRMGR.EXE" /G Administrators:F;F /Y   XCACLS "  %WINDIR%  \SYSTEM32\WINDISK.EXE" /G Administrators:F;F /Y  
Note  

The highlighted code above must be placed on one line. Although this script prevents an ordinary user from accessing these tools, they could always bring them in and run them from an alternate source, such as a floppy disk.

Related solution:

Found on page:

Modifying NTFS Permissions

157

Running Commands under Different Security Contexts

Every time someone logs on to the network with an administrator account, it creates a big security risk. Malicious ActiveX components from the Web, Trojan horses, or even a hidden batch file can wipe out an entire server, database, and more when run under administrative privileges. If you think about it, you don't really need administrative privileges when you are checking your mail or surfing the Net. A common solution to this security problem is to log on with a regular user account and use a utility to run trusted applications under the security context of an administrative account.

A security context specifies all the rights and privileges granted to a user. For administrators, this security context allows them to manage users, groups, trusts, and domains. The process of switching to the security context of another user is known as impersonation. Impersonation is mostly used by system services.

Using the RunAs Command

Windows 2000/XP/2003 includes the utility RUNAS.EXE, which allows users to run applications under the security context of a different user. This utility is integrated into the Windows shell, which allows you to set up shortcuts to utilize the RUNAS utility. The basic syntax of the RUNAS utility is:

 RUNAS /  commands program  

Here, program is the shortcut, Control Panel applet, MMC console, or application to run. The available commands are:

  • /ENV ”Keep the current environment

  • /NETONLY ”Specifies for remote access only

  • /PROFILE ”Loads the specified user's profile

  • /USER: username ”Specifies the username to run application as. Valid name formats are domain\user or user@domain

Note  

Once you have entered the command, you will be prompted for the password associated with the account.

To start an instance of User Manager using an administrator account called ADMIN@MYDOMAIN.COM, enter the following:

 RUNAS /USERNAME:ADMIN@MYDOMAIN.COM USRMGR 

Using the SECEDIT Utility

The SECEDIT.EXE utility is the command-line version of the Microsoft security configuration editor that allows you to run security configuration and analysis from the command line.

Running a Security Analysis

The basic syntax to run an analysis using SECEDIT is as follows:

 secedit /analyze /  commands  

Here, the available commands are:

  • /DB filename ”Required, specifies the database to compare against

  • /CFG filename ”Valid with /DB , specifies the security template to be imported

  • /LOG logpath ”Specifies the log file to use

  • /VERBOSE ”Specifies to include more detail to the log or output

  • /QUIET ”Runs the analysis with no screen or log output

Here is an example to run a system analysis against the high security template for a domain controller:

 Secedit /analyze /DB "  %WINDIR%  \Security\Database\hisecdc.sdb" /CFG "  %WINDIR%  \Security\Templates\hisecdc.inf" /LOG "  %WINDIR%  \Security\Logs\hisecdc.log" /VERBOSE 
Note  

The code above must be placed on one line.

Reapplying a Group Policy

To reapply a local or user policy, start a command prompt and enter the following:

 SECEDIT /REFRESHPOLICY policy/ENFORCE 

Here, /ENFORCE forces the policy to be reapplied, even if no security changes were found.

Note  

For Windows XP/2003, the GPUpdate command is the preferred method to reapply a group policy.

Applying a Security Template

The basic syntax to apply a security template using SECEDIT is as follows:

 secedit /configure /  commands  

Here, the available commands are:

  • /AREAS name ”Specifies the specific security areas to apply, where name is:

    • FILESTORE ”Local file security

    • GROUP_MGMT ”Group settings

    • REGKEYS ”Local registry security

    • SECURITYPOLICY ”Local or domain policy

    • SERVICES ”Local services security

    • USER_RIGHTS ”User's rights and privileges

  • / CFG filename ”Valid with /DB ; specifies the security template to be imported

  • / DB filename ”Required; specifies the database containing the template to be applied

  • / OVERWRITE ”Valid with /CFG ; specifies to overwrite templates in the database

  • /LOG logpath ”Specifies the log file to use

  • /VERBOSE ”Specifies to include more detail to the log or output

  • /QUIET ”Runs the analysis with no screen or log output

Fixing Security on a Windows NT to Windows 2000 Upgrade

When you upgrade from Windows NT to Windows 2000, the security settings on the system are not modified. This means none of the intended Windows 2000 security settings are implemented. To apply the Windows 2000 basic security settings, start a command prompt and enter the following:

 Secedit /configure /db "  %WINDIR%  \Security\Database\basicwk.sdb" /cfg "  %WINDIR%  \Security\Templates\basicwk.inf" /log "  %WINDIR%  \Security\Logs\basicwk.log" /verbose 
Note  

The code above must be placed on one line.

Exporting Security Settings

The basic syntax to export security settings using SECEDIT is as follows:

 secedit /export /  commands  

Here, the available commands are:

  • /AREAS name ”Specifies the specific security areas to export, where name is:

    • FILESTORE ”Local file security

    • GROUP_MGMT ”Group settings

    • REGKEYS ”Local registry security

    • SECURITYPOLICY ”Local or domain policy

    • SERVICES ”Local services security

    • USER_RIGHTS ”User's rights and privileges

  • /DB filename ”Required; specifies the database containing the template to be exported

  • /CFG filename ”Valid with /DB ; specifies the security template to export to

  • /MERGEDPOLICY ”Valid with /CFG ; specifies to overwrite templates in the database

  • /LOG logpath ”Specifies the log file to use

  • /VERBOSE ”Specifies to include more detail to the log or output

  • /QUIET ”Runs the analysis with no screen or log output

Here is an example of how to export the local registry security area to the registry template:

 Secedit /export /mergedpolicy /db "  %WINDIR%  \Security\Database\security.sdb" /cfg "  %WINDIR%  \Security\Templates\registry.inf" /log "  %WINDIR%  \Security\Logs\registry.log" /verbose 

Using the NET ACCOUNTS Command

The built-in NET command has an ACCOUNTS parameter to modify the password and logon requirements for the local computer or a specified domain. The basic syntax of the NET ACCOUNTS utility is:

 NET ACCOUNTS /  commands  

Here, the available commands are:

  • /DOMAIN ”If used, performs the specified operations on the primary domain controller of the current domain; otherwise , performs the operations on the local computer.

  • /FORCELOGOFF: min ”Sets the number of minutes before a user session is terminated where min is either the number of minutes or NO to specify no forced logoff .

  • /MAXPWAGE: days ”Specifies the maximum duration a password is valid where days is either the number of days (1 through 49,710) or UNLIMITED to set no maximum time.

  • / MINPWAGE: days ”Specifies the minimum duration before a user can change his or her password, where days is either the number of days (1 through 49,710) or UNLIMITED to set no time limit. This value must be less than the MAXPWAGE .

  • / MINPWLEN: length ”Specifies the minimum password length.

  • / SYNC ”Forces backup domain controllers to synchronize their password and logon requirements with those set on the primary domain controller.

  • /UNIQUEPW: changes ”Specifies that users cannot repeat the same password for the specified amount of password changes (0 through 24).

For example, to modify the logon and password requirements using the NET ACCOUNTS command, you would enter the following command:

  NET ACCOUNTS /DOMAIN /MAXPWAGE:30 /MINPWAGE:UNLIMITED /MINPWLEN:14  
Note  

The highlighted code above must be placed on one line.

Tip  

When the administrator has specified a forced logoff, the user receives a warning that a domain controller will force a logoff shortly.

Managing Security through ADSI

Active Directory Services Interfaces provides another medium to control security. In Chapter 9, you learned how to manage shares, groups, and user accounts through ADSI. In the following section, you will learn how to manage security through ADSI.

Setting the Minimum Password Length

For maximum security, you should set your domain password minimum length to the maximum value, 14. To set the minimum password length for the domain using ADSI, proceed as follows:

  1. Create a new directory to store all files included in this example.

  2. Download and install the latest version of ADSI and Windows Script Host, from http://www.microsoft.com, to the new directory.

  3. Select StartRun and enter "cscript scriptfile .vbs."

Here, scriptfile is the full path and file name of a script file that contains the following:

 On Error Resume Next Set  objDomain  = GetObject("WinNT://  Domain  ")  objDomain  .Put "MinPasswordLength",  max   objDomain  .SetInfo 

Here, domain is the name of the domain, and max is the maximum password length to set. Again, you should set max equal to 14 for maximum security.

Setting the Password Age

For maximum security, you should implement a policy to force users to change their password regularly. To set the password age for the domain using ADSI, proceed as follows:

  1. Create a new directory to store all files included in this example.

  2. Download and install the latest version of ADSI and Windows Script Host, from http://www.microsoft.com, to the new directory.

  3. Select StartRun and enter "cscript scriptfile .vbs."

Here, scriptfile is the full path and file name of a script file that contains the following:

 On Error Resume Next Set  objDomain  = GetObject("WinNT://  Domain  ")  objDomain  .Put "MinPasswordAge", Min * (60*60*24)  objDomain  .Put "MaxPasswordAge", Max * (60*60*24)  objDomain  .SetInfo 

Here, domain is the name of the domain; min is the minimum duration in days before a user can change his or her password; and max is the maximum duration in days a password is valid. The formula 60 x 60 x 24 is the calculation from seconds to days (60 seconds x 60 minutes x 24 hours).

Setting Unique Password Changes

For maximum security, you should implement a policy to force users to select passwords different from their previous passwords. To set the unique password duration for the domain using ADSI, proceed as follows:

  1. Create a new directory to store all files included in this example.

  2. Download and install the latest version of ADSI and Windows Script Host, from http://www.microsoft.com, to the new directory.

  3. Select StartRun and enter "cscript scriptfile .vbs."

Here, scriptfile is the full path and file name of a script file that contains the following:

 On Error Resume Next Set  objDomain  = GetObject("WinNT://  Domain  ")  objDomain  .Put "PasswordHistoryLength",  min   objDomain  .SetInfo 

Here, domain is the name of the domain, and min is the minimum number of passwords used before a user can repeat that previous password. The formula 60 x 60 x 24 is the calculation from seconds to days (60 seconds x 60 minutes x 24 hours).

Setting the Account Lockout Policy

For maximum security, you should implement a policy to lock out accounts after a certain number of bad attempts. To implement an account lockout policy using ADSI, proceed as follows:

  1. Create a new directory to store all files included in this example.

  2. Download and install the latest version of ADSI and Windows Script Host, from http://www.microsoft.com, to the new directory.

  3. Select StartRun and enter "cscript scriptfile .vbs."

Here, scriptfile is the full path and file name of a script file that contains the following:

 On Error Resume Next Set  objDomain  = GetObject("WinNT://  Domain  ")  objDomain  .Put "MaxBadPasswordAllowed",  Max   objDomain  .SetInfo 

Here, domain is the name of the domain. The formula 60 x 60 x 24 is the calculation from seconds to days (60 seconds x 60 minutes x 24 hours).

Searching for Locked-Out Accounts

It's good practice to regularly search the domain for locked-out accounts. To search for locked-out accounts using ADSI, proceed as follows:

  1. Create a new directory to store all files included in this example.

  2. Download and install the latest version of ADSI and Windows Script Host, from http://www.microsoft.com, to the new directory.

  3. Select StartRun and enter "cscript scriptfile .vbs."

Here, scriptfile is the full path and file name of a script file that contains the following:

 On Error Resume Next Set  objDomain  = GetObject("WinNT://  Domain  ") For Each  Item  in  objDomain  If  Item  .Class = "User" Then    If  Item  .IsAccountLocked = "True" Then     Wscript.Echo "Name: " &  Item  .Name & VBlf & _     "Bad Password Attempts: " & _  Item  .BadPasswordAttempts & VBlf & _     "Last Login: " &  Item  .LastLogin    End If   End If Next 

Here, domain is the name of the domain.

Related solution:

Found on page:

Unlocking a User Account

219

Renaming the Administrator Account

Windows creates a default administrative account called "Administrator" to be the master account for that system. This account cannot be deleted, but should be renamed to foil hackers attempting to gain access through this account. To rename the administrator account using ADSI, proceed as follows:

  1. Create a new directory to store all files included in this example.

  2. Download and install the latest version of ADSI and Windows Script Host, from http://www.microsoft.com, to the new directory.

  3. Select StartRun and enter "cscript scriptfile .vbs."

Here, scriptfile is the full path and file name of a script file that contains the following:

 On Error Resume Next Set  objDomain  = GetObject("WinNT://  Computer  ") Set  objUser  = ObjDomain.GetObject("User", "Administrator")  objDomain  .MoveHere  objUser  .AdsPath, Name 

Here, computer is the name of the computer holding the account, and name is the new name to give the account.

Tip  

You can use this script to rename any account simply by replacing the word ADMINISTRATOR with the user account name desired.

Searching for Unused Accounts

It's good practice to regularly search the domain for accounts that have either been logged on for a long duration of time or have not logged on in a long time. To search for unused accounts using ADSI, proceed as follows:

  1. Create a new directory to store all files included in this example.

  2. Download and install the latest version of ADSI and Windows Script Host, from http://www.microsoft.com, to the new directory.

  3. Select StartRun and enter "cscript scriptfile .vbs."

Here, scriptfile is the full path and file name of a script file that contains the following:

 On Error Resume Next  Days  =  amount  Set  objDomain  = GetObject("WinNT://  Domain  ") For Each  Item  in  objDomain  If  Item  .Class="User" Then  DUR  = DateDiff("D", Item.LastLogin, Date)     If  DUR  > Days Then       Wscript.Echo "Name: " &  Item  .Name & VBlf & _       "Account Disabled: " &  Item  .AccountDisabled & VBlf & _       "Last Login: " &  Item  .LastLogin & VBlf & _       "Amount of days: " &  DUR  End If   End If Next 

Here, domain is the name of the domain to search, and amount is the least number of days since the last logon.

Using the Microsoft Script Encoder

The Microsoft Script Encoder allows you to protect your scripts using a simple encoding scheme. This encoding scheme is not intended to prevent advanced cracking techniques, but to merely make your scripts unreadable to the average user. The default supported file types are asa, asp, cdx, htm, html, js, sct, and vbs. The basic syntax of the script encoder is as follows:

 SCRENC  inputfile outputfile  

Here, inputfile is the file to encode and outputfile is the encoded result. Microsoft Script Encoder supports many command-line parameters, as shown in Table 11.1.

Table 11.1: Microsoft Script Encoder parameters.

Parameter

Description

/E extension

Specifies a known extension for unrecognized input file types

/F

Specifies to overwrite the input file with the encoded version

/L language

Specifies to use the scripting language Jscript or VBScript

/S

Specifies to work in silent mode

/X1

Specifies not to include to @language directive to ASP files

Warning  

Always back up your scripts before encoding them. Once a script is overwritten with an encoded version, there is no way to return it to its original state.

Previous Security Scripts

Some of the scripts included in previous chapters can increase your system security. These scripts are shown in Table 11.2.

Table 11.2: Security scripts.

Chapter

Script

Chapter 6

Disabling 8.3 File Naming

Chapter 6

Disabling the Lock Workstation Button

Chapter 6

Disabling the Change Password Button

Chapter 6

Disabling the Logoff Button

Chapter 6

Modifying the Registry with REGINI.EXE

Chapter 7

Managing NTFS Encryption

Chapter 7

Modifying NTFS Permissions

Chapter 9

Changing the Local Administrator Password




Windows Admin Scripting Little Black Book
Windows Admin Scripting Little Black Book (Little Black Books (Paraglyph Press))
ISBN: 1933097108
EAN: 2147483647
Year: 2004
Pages: 89

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net