Wireless Networking and Guest Ineternet access

Nowadays, wireless is increasingly being viewed as a ncessity than a luxury and in many places including several government organisations, a push to wireless is evident. I wanted to provide a brief overview of wireless terminology used in ACSI33 standards and the ISM manual. The ACSI 33 and ISM together form the Australian federal IT standards that are used to enforce compliance on govermental organisations. I have focussed primarily on a Cisco-based solution to provide guest wireless access. According to the latest ISM manual released by the DSD, agencies can use wireless infrastructure provided they secure their network using WPA2 and EAP-TLS. If EAP-TLS is not used, they should use an EAP mechanism that authenticates both ends of the wireless link (i.e. the client and the access point).

WPA2 refers to the security protocol of the wireless link that implements 802.11i standards. The encryption is done using an AES cipher. This standard provides integrity and confidentiality of information over the wireless link. Compliance of WPA2 is very easy to deliver and only requires compatible WPA2 clients.

Extensible Authentication Protocol (EAP) is a framework for protocols to provide authentication services. In practice, choosing the right EAP mechanism is the most difficult part a wireless implementation. The following EAP methods are the most commonly used:

EAP-TLS: This is the most secure EAP method approved under ACSI33 and DSD guidelines. The main drawback (which is also its strength) is that it requires both server and client side certificates which requires a PKI infrastructure.

EAP-FAST: This is an open Cisco-developed protocol. However, it is not natively deployed on all OS platforms. It needs an authentication server (Active Directory or a standalone AAA server) but does not require client side certificates and is easier to deploy than EAP-TLS.

EAP-PSK: This uses shared keys to be entered by the user. The main advantage is that this does not require any separate authentication infrastructure. However, the use of shared keys make it easier to crack and susceptible to offline dictionary attacks. This makes the use of strong keys necessary. Although, long passphrases might result in users writing them down and defeating security.

..

.

GUEST WLAN ACCESS DESIGN
Scenario 1: Guest access using physically separate infrastructure
This design requires a physically separate infrastructure for the wireless network. Guest users will have direct access to the Internet, while enterprise users can use VPN to access corporate services over the wireless network.

Figure 1 Guest Access using physically separate infrastructure

The main benefit of this design is that it is inherently secure by providing a physically separate network for guest access. Moreover, as a stand-alone network, we may not have to comply with ACSI33 standards as this would be external to our network. However, we may be required to provide some sort of monitoring and bandwidth policing. Another major drawback is that cost could be quiet high for the infrastructure build to scale it across floors.

Scenario 2: Guest access using existing infrastructure
The Guest access is separated by a layer 2 LWAPP tunnel. All guest traffic is directly transported to the guest wireless controller which is located in a DMZ network. In fact, the default gateway of the guest laptop would be the firewall interface of the wireless DMZ network.

Figure 2 Guest Access using existing infrastructure

Advantages are that this would allow us to use existing switching infrastructure and be more economical. It also provides more functionality and is more scalable and economical in the long run. It will allow the deployment of centrally managed wireless network to branch networks as well. However, although LWAPP tunnels do provide secure separation for guest traffic acting as “layer 3 VLANS” that terminate on the guest wireless controller, it might not be suitable for some. This is mainly because some environments do not have proper segregation between “Floor networks” where the wireless devices will be connected and the “Server networks”. Another point of concern could be end point security for Corporate users that connect directly into the corporate network and wether a NAC solution is in place.

What are you're thoughts / opinions?

Windows server 2008 and Vista licensing model

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.

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.