SY0-501 Section 1.2 Given a scenario, use secures network administration principles.

Rule-based management

Traditional network management systems are implemented in a rules-based environment. Here, the functional areas of network management are performed based on a set of guidelines established by the administrative staff. Fault events, configuration setup, accounting recording, performance thresholds and security rules are all preset, based on best practices.

One advantage of rules-based implementations is that the interaction between the managed device (agent) and the manager can be simplified to a very small set of actions. In the simplest case the agent responds to polls from the manager and sends alarms when certain conditions are met. This disassociation allows rules-based network management to operate easily in a multivendor environment.

Hardware independence is another benefit of rules-based implementations. The manager characterizes the agents by using a set of database (management information base) entries. As long as the hardware manufacturer uses the same naming constructs for the internal design of the agent, the same manager can manage it. The manager need not know how the action is performed, only that it is performed at the agent.

Rules-based management systems manage the devices and connectivity of a network. All links, interconnection devices, and hosts can be part of the management scheme. Two examples of rules-based management rules are: Collect interface utilization once every five months, or apply a filter that filters protocol X.

Firewall rules

You create firewall rules to allow this computer to send traffic to, or receive traffic from, programs, system services, computers, or users. Firewall rules can be created to take one of three actions for all connections that match the rule’s criteria:

Allow the connection.

Allow a connection only if it is secured through the use of Internet Protocol security (IPsec).

Block the connection

Rules can be created for either inbound traffic or outbound traffic. The rule can be configured to specify the computers or users, program, service, or port and protocol. You can specify which type of network adapter the rule will be applied to: local area network (LAN), wireless, remote access, such as a virtual private network (VPN) connection, or all types. You can also configure the rule to be applied when any profile is being used or only when a specified profile is being used.

As your IT environment changes, you might have to change, create, disable, or delete rules.

Firewall rule priority

Because you can make firewall rules that have apparent conflicts, it is important to understand the order in which the rules are processed:

Authenticated bypass. These are rules in which the Override block rules option is selected. These rules allow matching network traffic that would otherwise be blocked. The network traffic must be authenticated by using a separate connection security rule. You can use these rules to permit access to the computer to authorized network administrators and authorized network troubleshooting devices.

Block connection. These rules block all matching inbound network traffic.

Allow connection. These rules allow matching inbound network traffic. Because the default behavior is to block unsolicited inbound network traffic, you must create an allow rule to support any network program or service that must be able to accept inbound connections.

Default profile behavior. The default behavior is to block unsolicited inbound network traffic, but to allow all outbound network traffic. You can change the default behavior on the Domain Profile, Private Profile, and Public Profile tabs of the Windows Firewall with Advanced Security Properties dialog box.

Inbound Rule

Inbound rules explicitly allow, or explicitly block, inbound network traffic that matches the criteria in the rule. For example, you can configure a rule to explicitly allow traffic secured by IPsec for Remote Desktop through the firewall, but block the same traffic if IPsec does not secure it. When Windows is first installed, all unsolicited inbound traffic is blocked. To allow a certain type of unsolicited inbound traffic, you must create an inbound rule that describes that traffic. For example, if you want to run a Web server, then you must create a rule that allows unsolicited inbound network traffic on TCP port 80.

You can also configure the default action that Windows Firewall with Advanced Security takes, whether connections are allowed or blocked, when no inbound rule applies.

Outbound Rule

Outbound rules explicitly allow, or explicitly block, network traffic originating from the computer that matches the criteria in the rule. For example, you can configure a rule to explicitly block outbound traffic to a computer (by IP address) through the firewall, but allow the same traffic for other computers. Because outbound traffic is allowed by default, you typically use outbound rules to block network traffic that you do not want.

You can also configure the default action that Windows Firewall with Advanced Security takes, whether outbound connections are allowed or blocked, when no outbound rule applies.

VLAN management

A VLAN Management Policy Server or “VMPS” is a network switch that contains a mapping of device information to VLAN.

The primary goal of VMPS is VLAN assignment for general network management purposes, but can also be used for providing security through segregating clients with an unknown MAC address, or through further extension of the protocol to provide login for Cisco ACS. This last functionality is now deprecated by Cisco, in favour of 802.1x, and as the VMPS technology is Cisco only, the VLAN assignment can now be carried out in the 802.1x framework.

Client switches query the VMPS server using the VLAN Query Protocol, or VQP. Only Cisco produces hardware with VMPS client functionality, and is currently fully supported across their IOS switching lines. Cisco officially only supports the use of Catalyst 4000, 5000 and 6500 switch platforms (with appropriate firmware) as VMPS servers, but these have limited functionality, and only support a static text file transferred into them with tftp

Secure router configuration

Then it comes to an enterprise’s network, routers are at the top of the food chain. Clients request information, servers provide information, and switches connect clients and servers together. But routers run the network.

The security you add when managing routers can make the difference between providing a functional and responsive network or an isolated intranet that provides services to no one. Let’s look at some steps you can take to maintain router security.

Managing your routers starts with how you configure them. If you don’t have a baseline document that details your routers’ configurations, you need to create one.

Establishing and documenting a router’s configuration brings you to the first crucial step in securely managing that configuration: Loading and storing the initial baseline configuration in a secure manner is essential.

Ideally, you should perform the initial configuration from the console and store it on a network drive. Most important, do not store it on the local drive of a laptop! Portable computing devices (i.e., laptops, PDAs, memory sticks, etc.) have a way of getting lost or stolen, which can compromise the integrity and functionality of your entire network.

After you’ve loaded the configuration, your next step is to synchronize the running configuration with the startup configuration. But don’t think you’re finished once the router is up and running on the network — you need to maintain that configuration and make changes periodically.

Some administrators like to make changes online, while others prefer making changes offline and then uploading the configuration. Both have their benefits.

When making online changes, you can get immediate feedback as well as syntax checking. For example, the router will alert you if you misspell a command. In addition, if you make a change that causes problems with your network, you’ll generally know right away.

On the other hand, if you make offline changes, you have the opportunity to add comments and use router configuration editors. However, this method provides no syntax checking or feedback on changes.

If you decide to use the offline approach, make sure you use a secure method of configuration delivery. Trivial File Transfer Protocol (TFTP) is not a recommended method for delivery, as it provides no security for connection or delivery of your configuration. File Transfer Protocol (FTP) — as long as you configure a username and password — or Secure Copy Protocol (SCP) are the most secure methods of delivering a new configuration.

Regardless of how you manage the updates of your router configurations, it’s essential that you save each configuration change and document all modifications. This enables you and others to better understand the changes and review them if something goes awry.

Access control lists

An access control list (ACL) is a list of access control entries (ACE). Each ACE in an ACL identifies a trustee and specifies the access rights allowed, denied, or audited for that trustee. The security descriptor for a securable object can contain two types of ACLs: a DACL and a SACL.

A discretionary access control list (DACL) identifies the trustees that are allowed or denied access to a securable object. When a process tries to access a securable object, the system checks the ACEs in the object’s DACL to determine whether to grant access to it. If the object does not have a DACL, the system grants full access to everyone. If the object’s DACL has no ACEs, the system denies all attempts to access the object because the DACL does not allow any access rights. The system checks the ACEs in sequence until it finds one or more ACEs that allow all the requested access rights, or until any of the requested access rights are denied.

A system access control list (SACL) enables administrators to log attempts to access a secured object. Each ACE specifies the types of access attempts by a specified trustee that cause the system to generate a record in the security event log. An ACE in a SACL can generate audit records when an access attempt fails, when it succeeds, or both. In future releases, a SACL will also be able to raise an alarm when an unauthorized user attempts to gain access to an object.

Do not try to work directly with the contents of an ACL. To ensure that ACLs are semantically correct, use the appropriate functions to create and manipulate ACLs.

ACLs also provide access control to Microsoft Active Directory directory service objects. Active Directory Service Interfaces (ADSI) includes routines to create and modify the contents of these ACLs.

How DACLs control an object

When a thread tries to access a securable object, the system either grants or denies access. If the object does not have a discretionary access control list (DACL), the system grants access; otherwise, the system looks for Access Control Entries (ACEs) in the object’s DACL that apply to the thread. Each ACE in the object’s DACL specifies the access rights allowed or denied for a trustee, which can be a user account, a group account, or a logon session.

The system compares the trustee in each ACE to the trustees identified in the thread’s access token. An access token contains security identifiers (SIDs) that identify the user and the group accounts to which the user belongs. A token also contains a logon SID that identifies the current logon session. During an access check, the system ignores group SIDs that are not enabled.

Typically, the system uses the primary access token of the thread that is requesting access. However, if the thread is impersonating another user, the system uses the thread’s impersonation token.

The system examines each ACE in sequence until one of the following events occurs:

An access-denied ACE explicitly denies any of the requested access rights to one of the trustees listed in the thread’s access token.

One or more access-allowed ACEs for trustees listed in the thread’s access token explicitly grant all the requested access rights.

All ACEs have been checked and there is still at least one requested access right that has not been explicitly allowed, in which case, access is implicitly denied.

The following illustration shows how an object’s DACL can allow access to one thread while denying access to another.

For Thread A, the system reads ACE 1 and immediately denies access because the accessdenied ACE applies to the user in the thread’s access token. In this case, the system does not check ACEs 2 and 3. For Thread B, ACE 1 does not apply, so the system proceeds to ACE 2, which allow™s write access, and ACE 3 which allows read and execute access.

Because the system stops checking ACEs when the requested access is explicitly granted or denied, the order of ACEs in a DACL is important. The ACE order were different in the example, the system might have granted access to Thread A. For system objects, the operating system defines a preferred order of ACEs in a DACL.

Port Security

You can use the port security feature to restrict input to an interface by limiting and identifying MAC addresses of the workstations that are allowed to access the port. When you assign secure MAC addresses to a secure port, the port does not forward packets with source addresses outside the group of defined addresses. If you limit the number of secure MAC addresses to one and assign a single secure MAC address, the workstation attached to that port is assured the full bandwidth of the port.

If a port is configured as a secure port and the maximum number of secure MAC addresses is reached, when the MAC address of a workstation attempting to access the port is different from any of the identified secure MAC addresses, a security violation occurs.

After you have set the maximum number of secure MAC addresses on a port, the secure addresses are included in an address table in one of these ways:

You can configure all secure MAC addresses by using the switchport port-security mac-address mac_address interface configuration command.

You can allow the port to dynamically configure secure MAC addresses with the MAC addresses of connected devices.

You can configure a number of addresses and allow the rest to be dynamically configured.

After the maximum number of secure MAC addresses is configured, they are stored in an address table. To ensure that an attached device has the full bandwidth of the port, configure the MAC address of the attached device and set the maximum number of addresses to one, which is the default.

A security violation occurs if the maximum number of secure MAC addresses has been added to the address table and a workstation whose MAC address is not in the address table attempts to access the interface.

You can configure the interface for one of these violation modes, based on the action to be taken if a violation occurs:

Restrict—A port security violation restricts data, causes the SecurityViolation counter to increment, and causes an SNMP Notification to be generated. The rate at which SNMP traps are generated can be controlled by the snmp-server enable traps port-security trap-rate command. The default value (“0”) causes an SNMP trap to be generated for every security violation.

Shutdown—A port security violation causes the interface to shut down immediately. When a secure port is in the error-disabled state, you can bring it out of this state by entering the errdisable recovery cause psecure_violation global configuration command or you can manually reenable it by entering the shutdown and no shut down interface configuration commands. This is the default mode.

You can also customize the time to recover from the specified error disable cause (default is 300 seconds) by entering the err-disable recovery interval command.

802.1x

The IEEE 802.1x standard manages port-based network access. It authenticates devices attached to a LAN port by initiating a connection and requesting login details. Access is prevented if authentication fails.

As well as being valuable for authenticating and controlling user traffic to a protected network, 802.1x is effective for dynamically varying encryption keys. 802.1x attaches the Extensible Authentication

Protocol (EAP) to both wired and wireless LAN media, and supports multiple authentication methods, such as token cards, one-time passwords, certificates, and public key authentication.

The Main Elements of the 802.1x System

Supplicant – The supplicant is the client that wishes to access services offered by the authenticator’s system.The supplicant is responsible for answering any requests from the authenticator for informationthat establishes the supplicant’s identity.

Port – A port is where a device is attached to the LAN, either directly into the switch or a wirelessaccess point.

Authenticator – The authenticator challenges the supplicant for appropriate authentication before it allowsaccess to the services available via the port. The authenticator communicates with thesupplicant and submits the information received from the supplicant to a suitable authenticationserver. This allows the verification of user credentials to determine the consequent portauthorization state.The authenticator’s functionality is independent of the authenticationmethod. It acts as a go-between for the supplicant and authentication server.

Extensible Authentication Protocol – 802.1X uses Extensible Authentication Protocol (EAP) as an authentication tool. EAP carries out the authentication exchange between the supplicant and the authentication server. Noother devices such as access points and proxy servers take part in this exchange.

Extensible Authentication Protocol Over LAN – The Extensible Authentication Protocol Over LAN (EAPOL) captures the EAP messages sothey can be managed directly by a LAN MAC service. Management functions such as start,logoff, and key distribution are also provided by EAPOL.

Remote Access Dial In User Service – The Remote Authentication Dial In User Service (RADIUS) server:

Manages a database of users.

Provides authentication by verifying username and password.

Optionally, provides authorization such as dynamic VLAN assignment.

Optionally, provides accounting information about how long a user was connected, and how much data they transferred.

Unified Threat Management

In the broadest sense of the term, any freestanding device that operates in a largely selfcontained manner is considered to be an appliance. An all-in-one appliance, also known as Unified Threat Management (UTM) and Next Generation Firewall (NGFW), is one that provides a good foundation for security. When you combine a firewall with other abilities (intrusion prevention, antivirus, content filtering, etc.), what used to be called an all-in-one appliance is now known as a UTM. The advantages of combining everything into one include a reduced learning curve (you only have one product to learn), a single vendor to deal with, and—typically—reduced complexity. The disadvantages of combining everything into one include a potential single point of failure, and the dependence on the one vendor.