KEMBAR78
Port Security 2 | PDF | Ip Address | Computer Standards
0% found this document useful (0 votes)
10 views10 pages

Port Security 2

Uploaded by

lynnunderwater
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views10 pages

Port Security 2

Uploaded by

lynnunderwater
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

PORT SECURITY

STP port security features

• BPDU protection

• Loop Protection

• Root Protection

BPDU Protection

You can enable BPDU protection on switch interfaces on which no BPDUs are expected. If a protected
interface receives BPDUs, the switch disables the interface and stops forwarding frames by transitioning
the interface to a blocking state. You can configure BPDU protection on a switch with a spanning tree as
well as on a switch that is not running STP.

You can configure BPDU protection on edge ports to block incoming BPDUs.

Loop Protection

Loop Protection When loop protection is enabled, the spanning-tree topology detects root ports and
blocked ports and ensures that both are receiving BPDUs. If an interface with the loop protection
feature enabled stops receiving BPDUs from its designated port, it reacts as it would react to a problem
with the physical connection on this interface. It does not transition the interface to a forwarding state.
Instead, it transitions the interface to a loop-prevention state. The interface recovers and then it
transitions back to the spanning-tree blocking state when it receives a BPDU.

Juniper Business Use Only


We recommend that if you enable loop protection, you enable it on all switch interfaces that have a
chance of becoming root or designated ports. Loop protection is most effective when it is enabled on all
switches within a network.

Root protection

Port Security Features

Default settings By default, all installed interfaces in an Juniper switch are configured for Layer 2
operations. These Layer 2 interfaces do not have a defined limit on the number of MAC addresses that
can be learned. In some environments, this default implementation can be problematic and prone to
security risks. Once a physical connection is passed to an end-user, that user can, if proactive measures
are not taken, connect a rogue switch or wireless device to the network allowing access for
unauthorized devices to the network and its resources. We discuss several port security features
throughout this chapter that combat the potential security risks that are inherent with the default
configuration settings.

Juniper port security features

• MAC Limiting

• Persistent MAC learning

• DHCP Snooping

• Dynamic ARP Inspection (DAI)

• IP Source Guard

MAC Limiting

MAC limiting protects Ethernet switches, as well as other network resources, against attacks that use
MAC addresses. Some examples of attacks that use MAC addresses to disrupt network operations
include MAC flooding and MAC spoofing. Both MAC flooding and MAC spoofing can be quite harmful
because they facilitate a denial-of-service (DoS) attack, which renders users, systems, or entire networks
useless. MAC limiting can be implemented using two different methods. The first method allows you to
specify the maximum number of MAC addresses that can be learned on a single Layer 2 access port.
Once the switch reaches the MAC limit, all traffic sourced from new MAC addresses is subject to being
dropped based on the configured action. The second method allows you to define allowed MAC
addresses for a specific access port. Any MAC address that is not listed will not be learned or permitted
network access. You can also enable MAC move limiting which allows the switch to track the number of
times a MAC address can move to a new interface (port) within a VLAN.

To achieve goals, MAC Limiting is divided in tree possible configurations based on needs:

 MAC address limit

 Allowed MAC address

Juniper Business Use Only


 MAC Move limit

MAC Address Limit MAC limiting protects the MAC forwarding table against flooding. You enable this
feature on individual interfaces. The MAC limit is user defined and varies depending on the needs within
each environment. In environments that use IP telephony, the limit specified should be two when an IP
phone and a user’s PC are attached to the same switch port. In data-only environments, you can
typically specify a limit of one to account for the user’s PC connection.

Allowed MAC Address With the allowed MAC address option, a switch permits or denies hosts network
access through their attached network ports based on their MAC addresses. This requires knowledge of
the node’s MAC address and is not ideal in environments where end-users move from switch port to
switch port.

MAC Move Limiting MAC move limiting is used to limit the number of times a MAC address can move to
a new interface. This feature is used to prevent MAC spoofing attacks as well as Layer 2 loops. You
enable MAC move limiting on a per-VLAN basis rather than on a per-interface basis like the allowed MAC
and MAC limit options. Once enabled, the switch tracks the number of times a MAC address moves to a
new interface. If the number of moves within one second exceeds the defined limit, the switch performs
the configured action.

MAC Limiting Actions

When a MAC limiting violation occurs, the switch performs one of the following actions:

• none: Does nothing. If you set a MAC limit to apply to all interfaces or a MAC move limit to
apply to all VLANs on the EX Series switch, you can override that setting for a particular interface
or VLAN by specifying an action of none.
• drop: Drops the packet and generates an alarm, an SNMP trap, or a system log entry. This is
the default action for a MAC limiting violation (MAC limit or MAC move limit).
• log: Does not drop the packet but generates a system log entry.
• drop-and-log: Drop the packet and generate an alarm, an SNMP trap or a system log entry.
• shutdown: Disables the port, blocks data traffic, and generates a system log entry

Persistent MAC learning, also known as sticky MAC, is a port security feature that allows retention of
dynamically learned MAC addresses on an interface across reboots of the switch and interface-down
events. Persistent MAC address learning is disabled by default. By enabling persistent MAC learning
along with MAC limiting, you can enable interfaces to learn MAC addresses of trusted workstations and
servers during the period from when you connect the interface to your network until the limit for MAC
addresses is reached, and ensure that after this initial period with the limit reached, new devices are not
allowed even if the switch reboots. The alternatives to using persistent MAC learning with MAC limiting
are to statically configure each MAC address on each port or to allow the port to continuously learn new
MAC addresses after restarts or interface-down events. If you move a device within your network that
has a persistent MAC address entry on the switch, use the clear ethernet-switching table persistent-
learning command to clear the persistent MAC address entry from the interface. If you move the device
and do not clear the persistent MAC address from the original port it was learned on, then the new port
will not learn the MAC address and the device will not be able to connect. If the original port is down
when you move the device, then the new port will learn the MAC address and the device can connect.

Juniper Business Use Only


However, if you do not clear the MAC address on the original port, then when the port comes back up,
the system reinstalls the persistent MAC address in the forwarding table for that port. If this occurs, the
address is removed from the new port and the device loses connectivity

Guidelines for Implementing Persistent MAC Learning Consider the following configuration guidelines
when configuring persistent MAC learning:

• Interfaces must be configured in access mode (use the interface-mode configuration statement).
• You cannot enable persistent MAC learning on an interface that is part of a redundant trunk group.
• You cannot enable persistent MAC learning on an interface on which 802.1x authentication is
configured.
• You cannot enable persistent MAC learning on an interface on which no-mac-learning is enabled

DHCP
DHCP Review The Dynamic Host Configuration Protocol (DHCP) is used to dynamically configure hosts
on a network. An administrator defines network parameters on a DHCP server. Based on individual
requests from the DHCP clients, the DHCP server dynamically assigns network parameters that facilitate
network access for the individual hosts, or DHCP clients.

A Dynamic Host Configuration Protocol (DHCP) server can automatically allocate IP addresses and also
deliver configuration settings to client hosts on a subnet. DHCP lets network administrators centrally
manage a pool of IP addresses among hosts and automate the assignment of IP addresses in a network.
An IP address can be leased to a host for a limited period of time, allowing the DHCP server to share a
limited number of IP addresses among a group of hosts that do not need permanent IP addresses. DHCP
is based on BOOTP, a bootstrap protocol that allows a client to discover its own IP address, the IP
address of a server host, and the name of a bootstrap file. DHCP servers can handle requests from
BOOTP clients, but provide additional capabilities beyond BOOTP, such as the automatic allocation of
reusable IP addresses and additional configuration options.

DHCP provides two primary functions:

• Allocate temporary or permanent IP addresses to clients.


• Store, manage, and provide client configuration parameters.

DHCP Client, DHCP Local Server, and Address-Assignment Pool Interaction

In a typical branch network configuration, the DHCP client is on the subscriber’s computer, and the
DHCP local server is configured on the device. The following steps provide a high-level description of the
interaction among the DHCP client, DHCP local server, and address-assignment pools.

The DHCP client sends a discover packet to one or more DHCP local servers in the network to obtain
configuration parameters and an IP address for the subscriber.

Each DHCP local server that receives the discover packet then searches its address-assignment pool for
the client address and configuration options. Each local server creates an entry in its internal client table
to keep track of the client state, then sends a DHCP offer packet to the client.

Juniper Business Use Only


On receipt of the offer packet, the DHCP client selects the DHCP local server from which to obtain
configuration information and sends a request packet indicating the DHCP local server selected to grant
the address and configuration information.

The selected DHCP local server sends an acknowledgement packet to the client that contains the client
address lease and configuration parameters. The server and client install the host route and ARP entry,
and then monitors the lease state.

DHCP Local Server and Address-Assignment Pools

In a DHCP local server operation, the client address and configuration information reside in centralized
address-assignment pools, that are managed independently from the DHCP local server and they can be
shared by different client applications.

Configuring a DHCP environment that includes a DHCP local server requires two independent
configuration operations, which you can complete in any order. In one operation, you configure the
DHCP local server on the device and specify how the DHCP local server determines which address-
assignment pool to use. In the other operation, you configure the address-assignment pools used by the
DHCP local server. The address-assignment pools contain the IP addresses, named address ranges, and
configuration information for DHCP clients.

DHCP Client

DHCP configuration consists of configuring DHCP clients and a DHCP local server. A client configuration
determines how clients send a message requesting an IP address, while a server configuration enables
the server to send an IP address back to the client.

For the device to operate as a DHCP client, you configure a logical interface on the device to obtain an IP
address from the DHCP local server in the network. You set the vendor class ID, lease time, DHCP server
address, retransmission attempts, and retry interval.

DHCP Relay Agent


You can configure DHCP relay options on the device and enable the device to function as a DHCP relay
agent. A DHCP relay agent forwards DHCP request and reply packets between a DHCP client and a DHCP
local server.

A DHCP relay agent is any host that forwards DHCP packets between clients and servers. Relay agents
are used to forward requests and replies between clients and servers when they are not on the same
physical subnet. Relay agent forwarding is distinct from the normal forwarding of an IP router, where IP
datagrams are switched between networks somewhat transparently. By contrast, relay agents receive
DHCP messages and then generate a new DHCP message to send on another interface.

Juniper Business Use Only


DHCP Client, DHCP Relay Agent, and DHCP Local Servers

In a typical branch network configuration, the DHCP client is on the subscriber’s computer, and the
DHCP relay agent is configured on the device between the DHCP client and one or more DHCP local
servers.

The following steps describe, at a high level, how the DHCP client, DHCP relay agent, and DHCP local
server interact in a configuration that includes two DHCP local servers.

1. The DHCP client sends a discover packet to find a DHCP local server in the network from which
to obtain configuration parameters for the subscriber, including an IP address.
2. The DHCP relay agent receives the discover packet and forwards copies to each of the two DHCP
local servers. The DHCP relay agent then creates an entry in its internal client table to keep track
of the client’s state.
3. In response to receiving the discover packet, each DHCP local server sends an offer packet to the
client. The DHCP relay agent receives the offer packets and forwards them to the DHCP client.
4. On receipt of the offer packets, the DHCP client selects the DHCP local server from which to
obtain configuration information. Typically, the client selects the server that offers the longest
lease time on the IP address.
5. The DHCP client sends a request packet that specifies the DHCP local server from which to
obtain configuration information.
6. The DHCP local server requested by the client sends an acknowledgement (ACK) packet that
contains the client’s configuration parameters.
7. The DHCP relay agent receives the ACK packet and forwards it to the client.
8. The DHCP client receives the ACK packet and stores the configuration information.
9. If configured to do so, the DHCP relay agent installs a host route and Address Resolution
Protocol (ARP) entry for this client.
10. After establishing the initial lease on the IP address, the DHCP client and the DHCP local server
use unicast transmission to negotiate lease renewal or release.

DORA process packet overview


Discover

The DHCP client broadcasts a DHCPDISCOVER message on the network subnet using the destination
address 255.255.255.255 (limited broadcast) or the specific subnet broadcast address (directed
broadcast). A DHCP client may also request its last known IP address. If the client remains connected to
the same network, the server may grant the request. Otherwise, it depends whether the server is set up
as authoritative or not. An authoritative server denies the request, causing the client to issue a new
request.

Offer

Juniper Business Use Only


When a DHCP server receives a DHCPDISCOVER message from a client, which is an IP address lease
request, the DHCP server reserves an IP address for the client and makes a lease offer by sending a
DHCPOFFER message to the client. This message contains the client's client id (traditionally a MAC
address), the IP address that the server is offering, the subnet mask, the lease duration, and the IP
address of the DHCP server making the offer. The DHCP server may also take notice of the hardware-
level MAC address in the underlying transport layer: according to current RFCs the transport layer MAC
address may be used if no client ID is provided in the DHCP packet.

Request

In response to the DHCP offer, the client replies with a DHCPREQUEST message, broadcast to the server,
requesting the offered address. A client can receive DHCP offers from multiple servers, but it will accept
only one DHCP offer. Based on required server identification option in the request and broadcast
messaging, servers are informed whose offer the client has accepted. Item 3 When other DHCP servers
receive this message, they withdraw any offers that they have made to the client and return the offered
IP address to the pool of available addresses.

Acknowledge

When the DHCP server receives the DHCPREQUEST message from the client, the configuration process
enters its final phase. The acknowledgement phase involves sending a DHCPACK packet to the client.
This packet includes the lease duration and any other configuration information that the client might
have requested. At this point, the IP configuration process is completed.

The protocol expects the DHCP client to configure its network interface with the negotiated parameters.

After the client obtains an IP address, it should probe the newly received address (e.g. with ARP Address
Resolution Protocol) to prevent address conflicts caused by overlapping address pools of DHCP servers.

DHCP Vulnerabilities.
DHCP, like many other protocols, has inherent vulnerabilities, which can be exploited either intentionally
or unintentionally. When a client sends a DHCP request, it is sent as a broadcast packet and is seen by all
other devices participating on the subnet.

Who Is Calling? Because all DHCP requests can be viewed by any other device participating on the same
subnet, it makes sense that any device on that subnet can also respond to that DHCP request. This
inherent DHCP behavior facilitates opportunities for attackers to disrupt normal network operations and
effectively launch a DoS attack. One such attack might include the use of a rogue DHCP server that
responds to legitimate requests from authorized clients and provides bogus network parameters to
those clients.

DHCP Snooping
You can use DHCP snooping to combat some of the inherent DHCP vulnerabilities and protect your
network and its resources. DHCP snooping builds and maintains a database of valid IP addresses
assigned to downstream network devices by a trusted DHCP server. DHCP snooping reads the lease
information, which is sent from the DHCP server to the individual DHCP clients. From this information it
creates the DHCP snooping database. This database is a mapping between IP address, MAC address, and

Juniper Business Use Only


the associated VLAN. When a DHCP client releases an IP address (by sending a DHCPRELEASE message),
the associated mapping entry is deleted from the database. The switch also tracks the lease time, as
assigned by the DHCP server, and purges all expired entries.

DHCP snooping protects the switch, as well as other network components, by inspecting all DHCP
packets on untrusted ports. By default, the Junos OS treats access ports as untrusted and trunk ports as
trusted. If a server is connected to a local access port, you must configure that port as a trusted port to
accommodate the DHCP server traffic it receives. Note that DHCP snooping occurs only on interfaces for
which an entry exists. If a switch port is connected to a device with a statically defined IP address, no
inspection occurs.

DHCP Option 82

DHCP snooping includes support for DHCP option 82, also known as the DHCP relay agent information
option. DHCP option 82 helps protect the switch against attacks such as spoofing (forging) of IP
addresses and MAC addresses, as well as DHCP IP address pool exhaustion. When a DHCP client that is
connected to the switch on an untrusted interface sends a DHCP request, the switch inserts information
about the client’s network location into the packet header of that request. The switch then sends the
request to the DHCP server. The DHCP server reads the option 82 information contained in the packet
header and uses it to implement the IP address or another parameter for the client. The DHCP server
sends this information back toward the switch with the same option 82 information in the header. The
switch removes the option 82 information in the header before sending the response packet to the
client.

ARP review
Sending IP packets on a multiaccess network requires mapping an IP address to an Ethernet MAC
address. Ethernet LANs use the Address Resolution Protocol (ARP) to map MAC addresses to IP
addresses.

All devices participating on an Ethernet LAN in a Layer 3 capacity maintain an ARP table with these IP
address to Ethernet MAC address mappings. Each Layer 3 device participating on an Ethernet LAN
maintains its ARP table in cache and consults the stored information when forwarding packets to other
Layer 3 devices on the same LAN.

If the ARP cache does not contain an entry for the destination device, the host broadcasts an ARP
request for that device's

Ethernet MAC address and stores the response in the ARP table. An example of an ARP table follows:

user@switch> show arp

MAC Address Address Name Interface Flags

00:26:88:02:74:86 172.28.1.2 172.28.1.2 ge-0/0/8.0 none

00:26:88:02:74:87 172.28.1.3 172.28.1.3 ge-0/0/8.0 none

00:26:88:02:74:89 172.28.1.4 172.28.1.4 ge-0/0/8.0 none

Juniper Business Use Only


Total entries: 3

ARP Spoofing

ARP spoofing, also known as ARP poisoning, is commonly used to initiate man-in-the-middle attacks. In
these types of attacks, the attacker sends an ARP packet that spoofs the MAC address of another device
on the LAN such as a gateway device or server. Instead of the switch sending traffic to the proper
network device, it sends the traffic to the impersonating device with the spoofed address. The result is
that traffic from the switch is diverted from the proper destination and received by the impersonating
device

Dynamic Arp Inspection (DAI)


Dynamic ARP Inspection (DAI) examines ARP requests and responses on the LAN. Each ARP packet
received on an untrusted access port is validated against the DHCP snooping database. By validating
each ARP packet received on untrusted access ports, DAI can prevent ARP spoofing. If the DHCP
snooping database does not contain an IP address-to-MAC address entry for the information within the
ARP packet, DAI drops the ARP packet, thus preventing the propagation of invalid host address
information. DAI also drops ARP packets when the IP address in the packet is invalid. Because DAI
depends on the entries found within the DHCP snooping database, DHCP snooping must also be
enabled. DAI inspects ARP packets received on untrusted interfaces. Access ports are untrusted by
default but can be changed to trusted ports through user configuration. ARP packets bypass DAI on
trusted interfaces. Trunk ports are trusted by default.

IP address spoofing
IP Address Spoofing Users can change or spoof source IP addresses and/or source MAC addresses by
flooding the switch with packets containing invalid addresses. Combined with other techniques, such as
TCP SYN flood attacks, address spoofing can deny legitimate service and render a network useless.
Identifying the source of an attack that uses source IP address or source MAC address spoofing can be
difficult for system administrators. As illustrated on the slide, attackers can spoof addresses on the same
subnet or on a different subnet.

IP Source Guard
A switch, with the IP source guard feature enabled, checks the source IP and MAC addresses in a packet
entering untrusted access interfaces against the entries stored in the DHCP snooping database. If IP
source guard determines that the packet header contains an invalid source IP or MAC address, the
switch does not forward the packet—that is, the packet is discarded. You can enable IP source guard on
one or more VLANs. IP source guard applies its checking rules to packets sent from untrusted access
interfaces on those VLANs. By default, on EX Series switches, access interfaces are untrusted and trunk
interfaces are trusted. IP source guard does not check packets that have been sent to the switch by

Juniper Business Use Only


devices connected to either trunk interfaces or trusted access interfaces. IP source guard obtains
information about IP-address/MAC-address/VLAN bindings from the DHCP snooping database. It causes
the switch to validate incoming IP packets against the entries in that database.

After the DHCP snooping database has been populated either through dynamic DHCP snooping or
through configuration of specific static IP address/MAC address bindings, the IP source guard feature
builds its database. It then checks incoming packets from access interfaces on the VLANs on which it is
enabled. If the source IP addresses and source MAC addresses match the IP source guard binding
entries, the switch forwards the packets to their specified destination addresses. If no matches are
found, the switch discards the packets.

Juniper Business Use Only

You might also like