Posts
Microsoft has made some major changes in how the enterprise can license their machines. Particularly the idea of using a Key Management server to dynamically validate windows licenses makes it very easy for IT staff to update or replace faulty hardware without having to go through the hassle of re-licensing windows due to hardware changes. There are two types of licensing models available for Windows Vista and windows 2008 (w2k8). This is also known as Volume Licensing 2.0 by Microsoft.
These are:
1. Using a KMS (Key Management Server): this is automatic and requires minimal user intervention. However, network access is required between KMS and the client host.
2. Using MAK (Multiple Activation Key): this requires the key to be entered manually by the engineer. As MAK does not require any traffic flow between networks, it is a more secure option than KMS. This option won’t be discussed further here.
The traffic flow for using a KMS is as follows:
1. The host that requires licensing, contacts the DNS server for a KMS record to get the IP address for the KMS server.
2. After receiving the IP address of the KMS server, it sends a RPC request on port 1688/tcp (default) to the KMS host to get the licensing keys.
3. The KMS host replies back on a random port to the requesting server using the RPC protocol.
It should be noted that the KMS service is usually installed on the same server as the Domain Controller. The KMS service uses minimal resources and espicially if you want to authenticate your clients and make sure they are part of the domain before validating them, it would make sense to install this on top of the Domain Controller
Security Considerations
There are four main security considerations associated with this:
1. Application layer protocol is Microsoft RPC: This protocol is very complex and has a history of vulnerabilities. There are active exploits for this protocol that target various services built on top of RPC such as SMB, CIFS e.t.c . A recent prominent malware that uses the RPC protocol is the Conficker/Downandup worm.
2. No mature MS-RPC proxyies on firewalls: At present there is no MS-RPC traffic proxy on current generation of Firewalls. Only Microsfot ISA Server has a MS-RPC proxy. Therefore, a generic proxy will have to be used which will only do basic application and TCP/IP layer checks but will not have the ability to inspect MSRPC traffic.
3. Domain Controller vulnerability: If KMS service is on a domain controller, then DCs (as well as the KMS) are both exposed to malicious dmz traffic. Moreover, internal DNS server will also be exposed by the DMZs as licensing traffic requires traffic to be initiated from the requesting host i.e. from the DMZ.
4. Enumerations due to anonymous connections: MS RPC access to the servers might accepts anonymous connections by default. Even if anonymous logons are not allowed, these connections might enumerate user accounts and shares on the KMS host. This can be even more risk if KMS is hosted on a domain controller.
It is probably best to useKMS be used for licensing internal secure LAN workstations and servers only. The MAK method should be used for w2k8 machines in firewalled zones.
Mitigations to be used:
If KMS has to be implemented across the network, the following can help reduce the risk associated:
1. Allow KMS to zones that are considered equally secure or more secure than internal networks (e.g. out-of-band management networks). Use proxy MAK activation for less secure/internet facing dmz.
2. Have KMS service on a separate virtual server so that compromise of KMS will not compromise Domain Controllers.
3. See if the IP address of the KMS server can be hardcoded in the initial install so that access to internal DNS server is not necessary to resolve KMS server IP address.
4. Allow only authenticated hosts in the domain to request for licenses. Disallow anonymous connections as this can be used to enumerate shares and accounts. This might require additional traffic such as Kerberos to traverse the firewall.
5. Firewalls should allow only specific IPs to access the KMS server from the network zones. Where available use the management interface of the server instead of production networks for licensing traffic.
Do you have any comments on how the new licensing mode works? let us know!
You can get more information from the microsoft website here.
Monday, February 23, 2009
Sunday, February 8, 2009
Antivirus on Servers
Many consider having antivirus on servers to be a fundamental of security. Although, having it on the desktop is a must, some have claimed that it isnt that important now for servers. This is true in a sense that if you are up to date with you patching, administrators access is limited and used only when required (means no browsing to the web!) and have a proper firewall and network setup. This would basically negate the need for AV products which are playing catchup to new threats anyways. On top of that, there could be a lot of head aches associated with installing AV on servers due to compatibility issues.
Having said that, I think that although the previous trends of large scale virus attacks have definitely decreased the value of having an AV solution. It still adds value by providing another line of defense. Moreover, most AV companies tend to lincese their product based on the size of the organisation and if an AV product is being used on the desktops you can add that protection at no extra cost. Recently I had worked on coming up with a set of broad guidelines for deploying AV on servers. I have edited the main policy features to reporoduce it below so that you can find it helpful it developing your own AV policy for servers.
1. Implement strict client deployment procedures to avoid service disruption
Installing AV on servers should be done in conjunction with the server management teams for the particular systems. To improve performance and stability care must be taken to exclude files that are under heavy utilizations such as DB files, transaction logs e.t.c. These are based on MS or other vendor recommendations such as recommended directories and files to be excluded on Exchange AD and Database servers. It is imperative that these should be followed carefully to prevent any service disruption. A detailed exclusion list based on Server roles is provided in the Appendix.
2. Enable real-time scanning
Real-time scanning ensures that any viruses are detected and treated as soon as possible. Not having a real-time scanning policy in place defeats the purpose of having AV. However, depending on the AV product selected, real-time scanning might result in a performance hit. Disabling scanning on read access should be used to reduce performance impact.
3. Disable extra AV services
Any features like FW services or Endpoint Security should be disabled. These are useful for home users but on a corporate server environment, it introduces extra complexity. Any firewalling should be done by firewall appliances and the AV product should be used to provide only Anti-virus protection
4. Disaster Recovery of AV management server to be based on VM
A single VM server should be used as a management server. In a disaster situation, the VM management server can be migrated to BRS where it can continue to provide management services without any service disruption.
5. Use automatic update of AV signature and have a rollback plan
Automatic updates of AV components and signatures should be enabled. A rollback plan should be in place if an unstable update is released.
6. Scanning should be implemented on Write access Only
Virus scanning should be implemented on write access only. This will improve performance as any files that are read from the servers will not be scanned by the AV engine. This is appropriate as the possibility of getting infected when files are read from the server is minimal. By disabling virus scanning on read we can improve server performance while not compromising AV protection.
7. Use a Clean/Quarantine policy
The default action should be Clean/Quarantine. This is in case of a false positive we do not want any files being deleted from the system. The Clean/Quarantine policy will first attempt to clean the infection and if that is not possible, it will quarantine the file. If the false positive is confirmed, then the file can be added as exclusion and replaced onto the server. Using this approach will help minimise the chances of deleting files that may result in system failure
8. Have an appropriate scheduled scan policy in place.
A scheduled scan should be run on servers once a day possibly out of business hours. This is similar to the current policy on Desktops. However, care must be taken to schedule scans in a distributed fashion. Particularly as VM servers residing on the SAN can experience performance issues if all virtual images run scheduled scans at the same time.
Having said that, I think that although the previous trends of large scale virus attacks have definitely decreased the value of having an AV solution. It still adds value by providing another line of defense. Moreover, most AV companies tend to lincese their product based on the size of the organisation and if an AV product is being used on the desktops you can add that protection at no extra cost. Recently I had worked on coming up with a set of broad guidelines for deploying AV on servers. I have edited the main policy features to reporoduce it below so that you can find it helpful it developing your own AV policy for servers.
1. Implement strict client deployment procedures to avoid service disruption
Installing AV on servers should be done in conjunction with the server management teams for the particular systems. To improve performance and stability care must be taken to exclude files that are under heavy utilizations such as DB files, transaction logs e.t.c. These are based on MS or other vendor recommendations such as recommended directories and files to be excluded on Exchange AD and Database servers. It is imperative that these should be followed carefully to prevent any service disruption. A detailed exclusion list based on Server roles is provided in the Appendix.
2. Enable real-time scanning
Real-time scanning ensures that any viruses are detected and treated as soon as possible. Not having a real-time scanning policy in place defeats the purpose of having AV. However, depending on the AV product selected, real-time scanning might result in a performance hit. Disabling scanning on read access should be used to reduce performance impact.
3. Disable extra AV services
Any features like FW services or Endpoint Security should be disabled. These are useful for home users but on a corporate server environment, it introduces extra complexity. Any firewalling should be done by firewall appliances and the AV product should be used to provide only Anti-virus protection
4. Disaster Recovery of AV management server to be based on VM
A single VM server should be used as a management server. In a disaster situation, the VM management server can be migrated to BRS where it can continue to provide management services without any service disruption.
5. Use automatic update of AV signature and have a rollback plan
Automatic updates of AV components and signatures should be enabled. A rollback plan should be in place if an unstable update is released.
6. Scanning should be implemented on Write access Only
Virus scanning should be implemented on write access only. This will improve performance as any files that are read from the servers will not be scanned by the AV engine. This is appropriate as the possibility of getting infected when files are read from the server is minimal. By disabling virus scanning on read we can improve server performance while not compromising AV protection.
7. Use a Clean/Quarantine policy
The default action should be Clean/Quarantine. This is in case of a false positive we do not want any files being deleted from the system. The Clean/Quarantine policy will first attempt to clean the infection and if that is not possible, it will quarantine the file. If the false positive is confirmed, then the file can be added as exclusion and replaced onto the server. Using this approach will help minimise the chances of deleting files that may result in system failure
8. Have an appropriate scheduled scan policy in place.
A scheduled scan should be run on servers once a day possibly out of business hours. This is similar to the current policy on Desktops. However, care must be taken to schedule scans in a distributed fashion. Particularly as VM servers residing on the SAN can experience performance issues if all virtual images run scheduled scans at the same time.
Subscribe to:
Posts (Atom)