Friday, March 25, 2016

server reboot loop - 2008r2



·         The 2008R2 Enterprise database server part of a two node cluster was in a reboot loop.
·         The server would boot up to the “Configuring Windows” screen and reboot.
·         A pending.xml and reboot.xml was present in C:\Windows\WinSxS
·         Ran dism.exe /image:C:\ /cleanup-image /revertpendingactions in WinPE
·         Deleted pending.xml and reboot.xml
·         Changed the Start type of Windows Modules Installer to 4.
·         Machine was able to boot up.

Wednesday, March 23, 2016

Windows Server Security Checklist

Procedure

Rationale

Physical Security Procedures

* Keep systems in a secure office or preferably a dedicated room.No-one but system administrators should have direct access to your servers. Dedicated server rooms are generally necessary for larger infrastructures for proper air conditioned environments.
Disable booting from diskette, optical drives, &  USB devices.Prevents the booting of the system with another OS and attacking the file system (e.g. password changers). NB this is less of an issue if a secure server room is used.
Password System CMOS/BIOSPrevents reversal of step immediately above.
Consider disabling unused hardware device ports.Can be used to attach unauthorised devices. 
* Review backup policies and proceduresHardware (and software) can fail, ALWAYS make backups of important data and store the tapes in a fireproof safe and preferably not in the same location as the server.
* Check and review restore procedures.Backups are useless if you cannot restore the data and restore it in a timely manner. Make sure that you can restore all data and in sensible sized segments.
* Use Separate Discs for system and data.The system should be installed on a separate disc from your data - if the system fails (it will eventually) the data should not be affected in any way. Allows restoration of system without having to restore data which is normally much more time consuming.
* Provide redundancy.You should be prepared for the worst, always! Expect a server to fail and have a plan for what you will so when it does. See; Disaster Planning and Strategy for Windows Domains
* Ensure a UPS is on all critical Servers and make sure that they can shutdown cleanly.If there is a power failure it will enable you to perform a normal shutdown, rather than a rough (and possibly damaging) shutdown. If at all possible the system should be capable of shutting down automatically before the UPS runs out if power has not been restored.

Operating System Procedures

* Apply the latest Service PackService packs contain or enable security (and bug) fixes
* Apply the latest post-service pack hotfixes
Hotfixes address security issues - Currently Microsoft release these on the second Tuesday of every month and can also release additional emergency patches.
There are very few reasons to not update your systems.
* Use Group Policy and Domain security polices to secure the Domain and your systems.There are a large number of possible security enhancements and restrictions you can make using Group Policy and the Domain Security Policys, including using complex passwords and minimum password length, restricting anonymous access to user & share names etc. Some examples are listed below for recommended settings
* Security Options - Network AccessAllow anonymous SID/Name translation [Disabled] : Do not allow anonymous enumeration of SAM accounts and shares [Enabled] : (Now default on modern versions of Windows Server)
* Security Options - Network Security
Do not store LAN Manager hash value on next password change [Enabled] : NOTE : This setting will require all existing passwords to be changed to take effect.
(Now default on modern versions of Windows Server)
Security Options - Recovery ConsoleAllow floppycopy and access to all drives [Enabled]
Disable Autorun
Malware which spreads by the autorun feature is still prevalent. Seehttp://support.microsoft.com/kb/967715/ to disable.
Limit the number of running Services and if possible make them run under a less privileged account than the 'system' account.
Reduce the number of exploitable services. If a service is compromised a hacker will have the same level of privilege as the service, you can limit the immediate damage if a service is compromised and it is running in a less privileged account as it also requires the hacker to escalate their rights.  This is particularly important for applications which should not need full system privileges.

Account Related Procedures

* Set account lockout after X number of failed attempts (3-5 recommended)Helps prevent dictionary attacks on all acounts (including Administrator), you can still logon as Administrator locally when the account is locked out, just not remotely
* Make Administrative passwords very complex and minimum length 15Slows dictionary attacks and makes brute force attacks harder.
* Keep guest account disabledGuest is one of the two built-in accounts which cannot be deleted. The Guest account provides a known, unprivileged account which can be attacked. Disabling the account removes this vulnerability (Windows 2000 and later all come with this account disabled by default)
* Create Global Groups for all classes of user privilege, and assign users to groups. Never assign a right or permission to an individual user - always use a group, even if it is for one account onlyRights assigned to individual users can be overlooked. It is easier to review group membership than to audit every single user's rights.
* Set Account/Group PoliciesEnsure strict control over what users can do on a system
Password RestrictionsMake sure passwords are enforced to a good standard (see below)
* Minimum Password Age (14)Passwords should not be changed frequently, can cover hacking activity and encourages users to use simple and easy to remember passwords.
* Minimum Password Length (8)Longer passwords are harder to crack (and guess). For users with more access increase password length
* Users should be encouraged to use complex passwords, but allow them to write it down and don't implement frequent changes. Just make sure passwords are not left on open display.Users will try to use as simple a password as possible which should be discouraged. Forcing users to change complex passwords frequently is normally very unhelpful. The strength of the password is more important that a frequently changed weak password. Passwords can be written down so long as they are not left on a post-it note on the monitor. Storage in a locked draw is suitable.
*Password Uniqueness (5)Do not allow the same password to be used for five consecutive changes.
* Enable Account Lockout: Lockout after x bad logon attempts (3-5)Helps prevent or slow down  high-speed dictionary/brute attacks
Reset Count after x minutes (60 minimum)Helps prevent or slow down high-speed dictionary/brute attacks
Lockout duration field (60 minimum)Helps prevent or slow down high-speed dictionary/brute attacks
Set logon hours.Systems should be idle over night, and most users do not need to login at midnight.  This makes hacker activity easier to spot and limit accessible accounts. Preferably encourage shutdown of desktop systems.
Other: Forcibly disconnects remote users from server when logon hours expireEnabled hacker activity to be seen clearly, prevents compromised accounts being used out of hours when direct observation is not possible.

Set User Rights Policies

Set Auditing Policies (Success/Failure) for the following:Lots of failed logon attempts can indicate a hacking attack
Logon and LogoffImportant for tracking user logons look for strange logon times in the log (is 3 am a common working time?)
File and Object AccessLets you check to see if users NOT authorised to use applications and access files are doing so
* Remove any old/unused/unnecessary user accountsOld accounts should be disabled as soon as is practical after someone leaves.
* Check user accounts for any disabled accounts (why are they disabled, and can they be deleted?)
Check logon hoursRestrict logon hours to reasonable working hours.
* Check Profile Directory (Delete profiles for old users)No need to store or have available on network
Check the Logon ToDoes user need access to all computers or only a few? If limited access required make sure this is the case.
Set account expirations for graduating students, temp employees or any temporary accountHelps ensure that accounts are not active once a user has left.
Periodically evaluate Operator and Administrator Group membersMakes sure that correct users have access, additional or unexpected users can indicate security issues.
All Administrators should have 2 accounts, one for administrative and one for normal usage. Only use Administrative when necessaryFor day to day use its not necessary to use Administrator privileges.
* When taking over a system or when a member of IT staff leaves change administrative password immediatelyPasswords should be changed for any common accounts if a member of staff leaves.

File System Procedures

* Format all volumes as NTFSYou can only set file system permissions on NTFS volumes, FAT systems have no security.
* Set ACLs on file systemControl access to folders and files as necessary, do not just give blanket access to a whole shared area with full control rights.
* Set User RightsEnsure users only have access to the shares files and folders they need.
Set Audits - Enable individual Directory auditing if necessary.Useful for tracking access and usage of files and resources. Can cause a lot of logging.
* On Application servers, Programs and Data should be in different locations.Data should always be isolated from OS and Applications and be backed up and restorable as such.
* Never share the root directory of a drive, except for CD-ROMSAccess should be restricted, VERY dangerous if you share the root of the drive where the OS is installed, otherwise just dangerous!
* Periodically check all file share permissions for correctnessUseful for tracking possible compromise internally and externally.

Notes for Internet Information Server (IIS)

* If using Active X controls make sure they are correctly secured. It is very easy to write insecure IIS and IE Active X (and other) components.Badly written Active X components are a very common source of entry to IIS systems.
Set appropriate virtual directory permissions
Do not accept defaults for data directoryStore the web site on a different volume from the OS

Other Updates and Maintenance

* Keep up to date with patches!All software will (probably) need updating for security and bug fixes. This means allsoftware. Browser plug-ins are especially susceptable to security problems, as are the web browsers, but all software you have should be updated. Most vendors have email alerts and similar options for being alerted to updates, use them.
* Update BIOS and Firmware*System BIOS and associated firmwares (such as for SCSI cards) often have updates and fixes. You should keep these up to date

Network & Infrastructure

Use Private IP addresses.If a system doesnt need to be contactable from outside your own network or the CUDN use a private IP address to restrict access.
Keep externally accessible services isolated from the general network (Create a DMZ).Also known as defending in depth. If a server or service is accessible from outside the CUDN, put it on an IP range separate from your internal machines. If the external service machine is compromised the machine will not be on the same network as your other machines. In practice this is easier to achieve by putting your internal devices on a private IP range and making them less accessible from outside the CUDN.
*Use a firewall/portblocking on exposed servers to protect non service ports.There is no point in exposing ports such as 445 (Windows Logon) to systems which do not need it. Any server which is exposed (to the internet especially but even within the CUDN) should be isolated to your own IP ranges only






http://www.ucs.cam.ac.uk/support/windows-support/winsuptech/srvrsecchk

Wednesday, March 16, 2016

cross domain login takes longer time than expected ( Approximately 15mins )



Issue : Trying to login to a server from a trusting domain to trusted domain and (cross domain login ) and it takes longer time than expected

 Checked and found that the ephemeral ports blocking between source to destination.

Issue has been resolved after opening the below mentioned ports on firewall between the source and destination 

Ports list:






Client Port(s)                                          Server Port                            Service
49152 -65535/UDP                                      123/UDP                          W32Time
49152 -65535/TCP                                      135/TCP                            RPC Endpoint Mapper
49152 -65535/TCP                                       464/TCP/UDP                Kerberos password change
49152 -65535/TCP                                    49152-65535/TCP             RPC for LSA, SAM, Netlogon (*)
49152 -65535/TCP/UDP                         389/TCP/UDP                  LDAP
49152 -65535/TCP                                 636/TCP                                 LDAP SSL
49152 -65535/TCP                                   3268/TCP                           LDAP GC
49152 -65535/TCP                                   3269/TCP                           LDAP GC SSL
53,49152 -65535/TCP/UDP                    53/TCP/UDP                  DNS
49152 -65535/TCP                                    49152 -65535/TCP            FRS RPC (*)
49152 -65535/TCP/UDP                       88/TCP/UDP                    Kerberos
49152 -65535/TCP/UDP                  445/TCP                                 SMB
49152 -65535/TCP                                 49152-65535/TCP             DFSR RPC (*)