IPSec VPN Gateway - MSBS-Controls

Sr
Domain
1 No Network devices must have HTTP service for administrative
access disabled.
2 BOOTP services must be disabled.
3 The Configuration auto-loading feature must be disabled when

connected to an operational network.
4 IP source routing must be disabled.
5 Management connections to a network device must be

established using secure protocols with FIPS 140-2 validated
cryptographic modules.
6 Network devices must authenticate all NTP messages received
from NTP servers and peers.
7 The network device must use its loopback or OOB management

interface address as the source address when originating
authentication services traffic.
8 The network device must use different SNMP community

names or groups for various levels of read and write access.
9 The network device must not allow SSH Version 1 to be used for
administrative access.
interface address as the source address when originating SNMP
traffic.

interface address as the source address when originating IP
Flow/NetFlow traffic.

interface address as the source address when originating TFTP
or FTP traffic.
13 The network device must require authentication for console

access.
14 The network device must log all messages except debugging

and send all log data to a syslog server.
15 The network devices must timeout management connections

for administrative access after 10 minutes or less of inactivity.
16 The VPN gateway must not accept certificates that have been
revoked when using PKI for authentication.
17 The network device must require authentication prior to

establishing a management connection for administrative
access.
18 Network devices must use at least two NTP servers to

synchronize time.
19 Network devices must have TCP and UDP small servers

disabled.
20 Authorized accounts must be assigned the least privilege level

necessary to perform assigned duties.
21 Network devices must authenticate all BGP peers within the
same or between autonomous systems (AS).
22 The VPN gateway must enable anti-replay for all IPSec security
associations.
23 The network device must be configured for a maximum number

of unsuccessful SSH logon attempts set at 3 before resetting the
interface.
24 IP directed broadcast must be disabled on all layer 3 interfaces.
25 IPSec Security Association parameters must be compliant with

all requirements specified for VPN Suite B when transporting
classified traffic across a non-classified network.
26 The VPN gateway must only accept certificates issued by a DoD-
approved Certificate Authority when using PKI for
authentication.
27 The emergency administration account must be set to an

appropriate authorization level to perform necessary
administrative functions when the authentication server is not
online.
28 The VPN gateway server must enforce a policy to the software

client to display a DoD approved warning banner prior to
allowing access to the VPN.
29 Network devices must be running a current and supported
operating system with all IAVMs addressed.
30 Network devices must authenticate all IGP peers.
31 Network devices must use two or more authentication servers

for the purpose of granting administrative access.
32 The VPN gateway must use AES for IPSec cryptographic

encryption operations required to ensure privacy of the IPSec
session.
33 The VPN gateway must use Secure Hash Algorithm for IPSec
cryptographic hashing operations required for authentication
and integrity verification.
34 The network device must drop half-open TCP connections
through filtering thresholds or timeout periods.
35 The VPN gateway must implement IKE Security Associations

that terminate within 24 hours or less.
36 The VPN gateway server must enforce a policy to the remote

software client to check for the presence of a personal firewall
before enabling access to the VPN.
37 The VPN gateway must use a key size from Diffie-Hellman Group
14 or larger during IKE Phase 2.
38 The VPN gateway must specify Perfect Forward Secrecy during

IKE negotiation.
39 The VPN gateway must implement IPSec security associations

that terminate after one hour or less of idle time.
40 The VPN gateway server must enforce a policy to the software

client to disallow the remote client from being able to save the
logon password locally on the remote PC.
41 Network devices must have BSDr commands disabled.

interface address as the source address when originating syslog
traffic.
43 Network devices must have the Finger service disabled.
44 The VPN gateway server must enforce a no split-tunneling

policy to all remote clients.
45 The network devices must be configured to timeout after 60

seconds or less for incomplete or broken SSH sessions.
46 Network devices must only allow SNMP read-only access.
47 Network devices must be configured to ensure passwords are

not viewable when displaying configuration information.
48 Network devices must not have any default manufacturer
passwords.
49 The VPN gateway must use PKI or digital-signature for

authenticating the remote server, peer, or client.
50 Network devices must be configured with rotating keys used for

authenticating IGP peers that have a duration of 180 days or
less.
51 The network device must not use the default or well-known

SNMP community strings public and private.
52 In the event the authentication server is unavailable, the
network device must have a single local account of last resort
defined.
53 Network devices must display the DoD-approved logon banner

warning.
54 Network devices must only allow SNMP access from addresses

belonging to the management network.
55 The network device must have control plane protection
enabled.
56 The network devices OOBM interface must be configured with

an OOBM network address.
57 The network devices management interface must be configured
with both an ingress and egress ACL.
58 Network devices must be password protected.
59 The VPN gateway must authenticate the remote server, peer, or

client prior to establishing an IPSec session.
60 The running configuration must be synchronized with the

startup configuration after changes have been made and
implemented.
61 Group accounts must not be configured for use on the network
device.
62 The management interface must be configured as passive for

the IGP instance deployed in the managed network.

interface address as the source address when originating NTP
traffic.
64 The VPN gateway must use Secure Hash Algorithm for IKE
cryptographic hashing operations required for authentication
and integrity verification.
65 Network devices must have the PAD service disabled.
66 The network devices must only allow management connections

for administrative access from hosts residing in the
management network.
67 The network device must use its loopback interface address as

the source address for all iBGP peering sessions.
68 The VPN gateway must implement IPSec security associations

that terminate within 8 hours or less.
69 The VPN gateway must ensure traffic from a remote client with
an outbound destination does not bypass the enclaves
perimeter defense mechanisms deployed for egress traffic.
70 The VPN gateway must use IKE for negotiating and establishing
all IPSec security associations.
71 The VPN gateway must use a key size from Diffie-Hellman Group
14 or larger during IKE Phase 1.
72 The VPN gateway must use IKE main mode for the purpose of
negotiating an IPSec security association policy when pre-
shared keys are used for authentication
73 Network devices must have identification support disabled.
74 Network devices must have TCP Keep-Alives enabled for TCP

sessions.
75 The VPN gateway must use ESP tunnel mode for establishing
secured paths to transport traffic between the
organizationâ€™s sites or between a gateway and remote end-
stations.
76 The VPN gateway peer at a remote site must receive all ingress
traffic and forward all egress traffic via the IPSec tunnel or other
provisoned WAN links connected to the central or remote site.
77 The VPN gateway must use AES for IKE cryptographic encryption
operations required to ensure privacy of the IKE session.
78 The auxiliary port must be disabled unless it is connected to a

secured modem providing encryption and authentication.
79 Network devices must have DNS servers defined if it is
configured as a client resolver.
80 The network device must use SNMP Version 3 Security Model

with FIPS 140-2 validated cryptography for any SNMP agent
configured on the device.
81 Unauthorized accounts must not be configured for access to the

network device.
82 The network device must log all interface access control lists
(ACL) deny statements.
83 The network devices must time out access to the console port
at 10 minutes or less of inactivity.
84 Network devices must log all attempts to establish a

management connection for administrative access.
85 Gratuitous ARP must be disabled.

Description
The additional services the router is enabled for increases the risk for an
attack since the router will listen for these services. In addition, these
services provide an unsecured method for an attacker to gain access to
the router. Most recent software versions support remote configuration
and monitoring using the World Wide Web's HTTP protocol. In general,
HTTP access is equivalent to interactive access to the router. The
authentication protocol used for HTTP is equivalent to sending a clear-text
password across the network, and, unfortunately, there is no effective
provision in HTTP for challenge-based or one-time passwords. This makes
HTTP a relatively risky choice for use across the public Internet. Any
additional services that are enabled increase the risk for an attack since
the router will listen for these services. The HTTPS server may be enabled
for administrative access.
BOOTP is a user datagram protocol (UDP) that can be used by Cisco

routers to access copies of Cisco IOS Software on another Cisco router
running the BOOTP service. In this scenario, one Cisco router acts as a
Cisco IOS Software server that can download the software to other Cisco
routers acting as BOOTP clients. In reality, this service is rarely used and
can allow an attacker to download a copy of a router's Cisco IOS Software.
Devices can find their startup configuration either in their own NVRAM or
access it over the network via TFTP or Remote Copy (rcp). Loading the
image from the network is taking a security risk since the image could be
intercepted by an attacker who could corrupt the image resulting in a
denial of service. Configuration auto-loading can be enabled when the
device is connected to a non-operational network. Once the device is
connected to an operational (i.e. production) network, configuration auto-
loading must be disabled.
Source routing is a feature of IP, whereby individual packets can specify

routes. This feature is used in several different network attacks by
bypassing perimeter and internal defense mechanisms.
Administration and management connections performed across a network
are inherently dangerous because anyone with a packet sniffer and access
to the right LAN segment can acquire the network device account and
password information. With this intercepted information they could gain
access to the router and cause denial of service attacks, intercept sensitive
information, or perform other destructive actions.
Since NTP is used to ensure accurate log file time stamp information, NTP
could pose a security risk if a malicious user were able to falsify NTP
information. To launch an attack on the NTP infrastructure, a hacker could
inject time that would be accepted by NTP clients by spoofing the IP
address of a valid NTP server. To mitigate this risk, the time messages must
be authenticated by the client before accepting them as a time source.
Two NTP-enabled devices can communicate in either client-server mode

or peer-to-peer mode (aka "symmetric mode"). The peering mode is
configured manually on the device and indicated in the outgoing NTP
packets. The fundamental difference is the synchronization behavior: an
NTP server can synchronize to a peer with better stratum, whereas it will
never synchronize to its client regardless of the client's stratum. From a
protocol perspective, NTP clients are no different from the NTP servers.
The NTP client can synchronize to multiple NTP servers, select the best
server and synchronize with it, or synchronize to the averaged value
returned by the servers.
A hierarchical model can be used to improve scalability. With this

implementation, an NTP client can also become an NTP server providing
time to downstream clients at a higher stratum level and of decreasing
accuracy than that of its upstream server. To increase availability, NTP
peering can be used between NTP servers. In the event the device loses
connectivity to its upstream NTP server, it will be able to choose time from
one of its peers.
The NTP authentication model is opposite of the typical client-server

authentication model. NTP authentication enables an NTP client or peer to
authenticate time received from their servers and peers. It is not used to
authenticate NTP clients because NTP servers do not care about the
authenticity of their clients, as they never accept any time from them.
Using a loopback address as the source address offers a multitude of uses

for security, access, management, and scalability of routers. It is easier to
construct appropriate ingress filters for router management plane traffic
destined to the network management subnet since the source addresses
will be from the range used for loopback interfaces instead of a larger
range of addresses used for physical interfaces. Log information recorded
by authentication and syslog servers will record the router's loopback
address instead of the numerous physical interface addresses. TACACS+,
RADIUS messages sent to management servers should use the loopback
address as the source address.
Numerous vulnerabilities exist with SNMP; therefore, without unique

SNMP community names, the risk of compromise is dramatically
increased. This is especially true with vendors default community names
which are widely known by hackers and other networking experts. If a
hacker gains access to these devices and can easily guess the name, this
could result in denial of service, interception of sensitive information, or
other destructive actions.
SSH Version 1 is a protocol that has never been defined in a standard.

Since SSH-1 has inherent design flaws which make it vulnerable to attacks,
e.g., man-in-the-middle attacks, it is now generally considered obsolete
and should be avoided by explicitly disabling fallback to SSH-1.
address instead of the numerous physical interface addresses. SNMP
messages sent to management servers should use the loopback address
as the source address.

address instead of the numerous physical interface addresses. NetFlow

for security, access, management, and scalability of network devices. It is
easier to construct appropriate ingress filters for management plane traffic
address instead of the numerous physical interface addresses. TFTP and
FTP messages sent to management servers should use the loopback
address as the source address.
Network devices with no password for administrative access via the

console provide the opportunity for anyone with physical access to the
device to make configuration changes enabling them to disrupt network
operations resulting in a network outage.
Logging is a critical part of router security. Maintaining an audit trail of

system activity logs (syslog) can help identify configuration errors,
understand past intrusions, troubleshoot service disruptions, and react to
probes and scans of the network. Syslog levels 0-6 are the levels required
to collect the necessary information to help in the recovery process.
Terminating an idle session within a short time period reduces the window
of opportunity for unauthorized personnel to take control of a
management session enabled between the managed network device and
a PC or terminal server when the later has been left unattended. In
addition quickly terminating an idle session will also free up resources
committed by the managed network device as well as reduce the risk of a
management session from being hijacked. Setting the timeout of the
session to 10 minutes or less increases the level of protection afforded
critical network components.
Situations may arise in which the certificate issued by a Certificate
Authority (CA) may need to be revoked before the lifetime of the
certificate expires. For example, the certificate is known to have been
compromised. To achieve this, a list of certificates that have been revoked,
known as a Certificate Revocation List (CRL), is sent periodically from the
CA to the IPSec gateway. When an incoming Internet Key Exchange (IKE)
session is initiated for a remote client or peer whose certificate is revoked,
the CRL will be checked to see if the certificate is valid; if the certificate is
revoked, IKE will fail and an IPSec security association will not be
established for the remote end-point.
Network devices with no password for administrative access via a

management connection provide the opportunity for anyone with
network access to the device to make configuration changes enabling
them to disrupt network operations resulting in a network outage.
Without synchronized time, accurately correlating information between

devices becomes difficult, if not impossible. If logs cannot be successfully
compared between each of the routers, switches, and firewalls, it will be
very difficult to determine the exact events that resulted in a network
breach incident. NTP provides an efficient and scalable method for
network devices to synchronize to an accurate time source.
Cisco IOS provides the "small services" that include echo, chargen, and
discard. These services, especially their User Datagram Protocol (UDP)
versions, are infrequently used for legitimate purposes. However, they
have been used to launch denial of service attacks that would otherwise
be prevented by packet filtering. For example, an attacker might send a
DNS packet, falsifying the source address to be a DNS server that would
otherwise be unreachable, and falsifying the source port to be the DNS
service port (port 53). If such a packet were sent to the Cisco's UDP echo
port, the result would be Cisco sending a DNS packet to the server in
question. No outgoing access list checks would be applied to this packet,
since it would be considered locally generated by the router itself. The
small services are disabled by default in Cisco IOS 12.0 and later software.
In earlier software, they may be disabled using the commands no service
tcp-small-servers and no service udp-small-servers.
By not restricting authorized accounts to their proper privilege level,

access to restricted functions may be allowed before authorized personnel
are trained or experienced enough to use those functions. Network
disruptions or outages may occur due to mistakes made by inexperienced
persons using accounts with greater privileges than necessary.
As specified in RFC 793, TCP utilizes sequence checking to ensure proper
ordering of received packets. RFC 793 also specifies that RST (reset)
control flags should be processed immediately, without waiting for out of
sequence packets to arrive. RFC 793 also requires that sequence numbers
are checked against the window size before accepting data or control flags
as valid. A router receiving an RST segment will close the TCP session with
the BGP peer that is being spoofed; thereby, purging all routes learned
from that BGP neighbor. A RST segment is valid as long as the sequence
number is within the window. The TCP reset attack is made possible due
to the requirements that Reset flags should be processed immediately and
that a TCP endpoint must accept out of order packets that are within the
range of a window size. This reduces the number of sequence number
guesses the attack must make by a factor equivalent to the active window
size. Each sequence number guess made by the attacker can be simply
incremented by the receiving connections window size. The BGP peering
session can protect itself against such an attack by authenticating each
TCP segment. The TCP header options include an MD5 signature in every
packet and are checked prior to the acceptance and processing of any TCP
packet--including RST flags.
One way to create havoc in a network is to advertise bogus routes to a

network. A rogue router could send a fictitious routing update to convince
a BGP router to send traffic to an incorrect or rogue destination. This
diverted traffic could be analyzed to learn confidential information of the
site's network, or merely used to disrupt the network's ability to
effectively communicate with other networks. An autonomous system can
advertise incorrect information by sending BGP updates messages to
routers in a neighboring AS. A malicious AS can advertise a prefix
originated from another AS and claim that it is the originator (prefix
hijacking). Neighboring autonomous systems receiving this announcement
will believe that the malicious AS is the prefix owner and route packets to
it.
Replay attack is a type of injection attack when an IPSec packet is captured

by an attacker and re-inserts it into the legitimate flow to disrupt service
or create undesired behavior. IPSec anti-replay service can mitigate a
replay attack by running sequence numbers for each end of the tunnel
and incrementing it for each packet sent. If a packet that is received does
not have the expected sequence number, it is dropped.
An attacker may attempt to connect to the device using SSH by guessing

the authentication method and authentication key or shared secret.
Setting the authentication retry to 3 or less strengthens against a Brute
Force attack.
An IP directed broadcast is a datagram sent to the broadcast address of a
subnet that is not directly attached to the sending machine. The directed
broadcast is routed through the network as a unicast packet until it arrives
at the target subnet, where it is converted into a link-layer broadcast.
Because of the nature of the IP addressing architecture, only the last
router in the chain, which is connected directly to the target subnet, can
conclusively identify a directed broadcast.
IP directed broadcasts are used in the extremely common and popular

smurf, or Denial of Service (DoS), attacks. In a smurf attack, the attacker
sends ICMP echo requests from a falsified source address to a directed
broadcast address, causing all the hosts on the target subnet to send
replies to the falsified source. By sending a continuous stream of such
requests, the attacker can create a much larger stream of replies, which
can completely inundate the host whose address is being falsified. This
service should be disabled on all interfaces when not needed to prevent
smurf and DoS attacks. Directed broadcast can be enabled on internal
facing interfaces to support services such as Wake-On-LAN. Case scenario
may also include support for legacy applications where the content server
and the clients do not support multicast. The content servers send
streaming data using UDP broadcast. Used in conjunction with the ip
multicast helper-map feature, broadcast data can be sent across a
multicast topology. The broadcast streams are converted to multicast and
vice versa at the first-hop routers and last-hop routers before entering
leaving the multicast transit area respectively. The last-hop router must
convert the multicast to broadcast. Hence, this interface must be
configured to forward a broadcast packet (i.e. a directed broadcast
address is converted to the all nodes broadcast address).
RFC 6379 Suite B Cryptographic Suites for IPSec defines four cryptographic
user interface suites for deploying IPSec. Each suite provides choices for
Encapsulating Security Payload (ESP) and Internet Key Exchange (IKE). The
four suites are differentiated by the choice of IKE authentication and key
exchange, cryptographic algorithm strengths, and whether ESP is to
provide both confidentiality and integrity or integrity only. The suite
names are based on the Advanced Encryption Standard (AES) mode and
AES key length specified for ESP. Two suites are defined for transporting
classified information up to SECRET levelâ€”one for both confidentiality
and integrity and one for integrity only. There are also two suites defined
for transporting classified information up to TOP SECRET level.
When using digital certificates, Internet Key Exchange (IKE) negotiation
between peers is restricted by either manually configuring each peer with
the public key for each peer to which it is allowed to connect, or enrolling
each peer with a Certificate Authority (CA). All peers to which the peer is
allowed to connect must enroll with the same CA server and belong to the
same organization.
Certificates are issued and signed by a CA. Hence, the signature on a

certificate identifies the particular CA that issued a certificate. The CA in
turn has a certificate that binds its identity to its public key, so the CAâ€™s
identity can be verified. The primary role of the CA is to digitally sign and
publish the public key bound to a given user or device via a digital
certificate. This is done using the CA's own private key, so that trust in the
userâ€™s key relies on trust in the validity of the CA's key. Hence, to
establish trust in the certificate of the remote client or peer, the VPN
gateway must be configured to validate the peerâ€™s certificate with the
DoD-approved CA, as well as validate the identity of the DoD-approved
CA. If the peerâ€™s certificate is not validated, there is a risk of
establishing an IPSec Security Association with a malicious user or a
remote client that is not authorized.
The emergency administration account is to be configured as a local

account on the network devices. It is to be used only when the
authentication server is offline or not reachable via the network. The
emergency account must be set to an appropriate authorization level to
perform necessary administrative functions during this time.
All software remote clients must present a DoD approved warning banner
prior allowing access to VPN. The banner should warn any unauthorized
user not to proceed. It also should provide clear and unequivocal notice to
both authorized and unauthorized personnel that access to the network is
subject to monitoring to detect unauthorized usage. Failure to display the
required warning banner prior to logon attempts will limit the ability to
prosecute unauthorized access and also presents the potential to give rise
to criminal and civil liability for systems administrators and information
systems managers.
DoD CIO has issued new, mandatory policy standardizing the wording of
â€œnotice and consentâ€ banners and matching user agreements for all
Secret and below DoD information systems, including stand-alone systems
by releasing DoD CIO Memo, â€œPolicy on Use of Department of Defense
(DoD) Information Systems Standard Consent Banner and User
Agreementâ€, dated 9 May 2008. The banner is mandatory and
deviations are not permitted except as authorized in writing by the Deputy
Assistant Secretary of Defense for Information and Identity Assurance.
Implementation of this banner verbiage is further directed to all DoD
components for all DoD assets via USCYBERCOM CTO 08-008A.
Network devices not running the latest tested and approved versions of
software are vulnerable to network attacks. Running the most current,
approved version of system and device software helps the site maintain a
stable base of security fixes and patches, as well as enhancements to IP
security. Viruses, denial of service attacks, system weaknesses, back doors
and other potentially harmful situations could render a system vulnerable,
allowing unauthorized access to DoD assets.
A rogue router could send a fictitious routing update to convince a site's

premise router to send traffic to an incorrect or even a rogue destination.
This diverted traffic could be analyzed to learn confidential information of
the site's network, or merely used to disrupt the network's ability to
effectively communicate with other networks.
The use of Authentication, Authorization, and Accounting (AAA) affords

the best methods for controlling user access, authorization levels, and
activity logging. By enabling AAA on the routers in conjunction with an
authentication server such as TACACS+ or RADIUS, the administrators can
easily add or remove user accounts, add or remove command
authorizations, and maintain a log of user activity.
The use of an authentication server provides the capability to assign

router administrators to tiered groups that contain their privilege level
that is used for authorization of specific commands. For example, user
mode would be authorized for all authenticated administrators while
configuration or edit mode should only be granted to those administrators
that are permitted to implement router configuration changes.
While there is much debate about the security and performance of

Advance Encryption Standard (AES), there is a consensus it is significantly
more secure than any of the algorithms supported by IPSec
implementations today. AES is available in three key sizes: 128, 192 and
256 bits, versus the 56 bit DES. Therefore, there are approximately 1021
times more AES 128-bit keys than DES 56-bit keys. In addition, AES uses a
block size of 128 bitsâ€”twice the size of DES or 3DES. Hence, AES must be
used to ensure the privacy of the IPSec tunnel.
Because hash algorithms create a short fixed-length hash value to

represent data of any size, there are far more possible input values than
there are unique hash values. Hence, multiple input values exist that will
produce the same hash value. This is known as a collision. For a hash
function to be deemed cryptographically secure and collision resistant, it
has to be hard to find two inputs that hash to the same output. Various
methods have been published stating that an MD5 collision has been
found in less than a minute. Therefore MD5 is considered
cryptographically broken and should not be usedâ€”and certainly not for
security-based services relying on collision resistance. Hence Secure Hash
Algorithm (SHA) must be used for IPSec cryptographic hashing operations
required for authentication and integrity verification.
A TCP connection consists of a three-way handshake message sequence. A
connection request is transmitted by the originator, an acknowledgement
is returned from the receiver, and then an acceptance of that
acknowledgement is sent by the originator.
An attacker's goal in this scenario is to cause a denial of service to the

network or device by initiating a high volume of TCP packets, then never
sending an acknowledgement, leaving connections in a half-opened state.
Without the device having a connection or time threshold for these half-
opened sessions, the device risks being a victim of a denial of service
attack. Setting a TCP timeout threshold will instruct the device to shut
down any incomplete connections. Services such as SSH, BGP, SNMP, LDP,
etc. are some services that may be prone to these types of denial of
service attacks. If the router does not have any BGP connections with BGP
neighbors across WAN links, values could be set to even tighter
constraints.
The Security Association (SA) and its corresponding key will expire after
the number of seconds has exceeded the configured limit. A new SA is
negotiated before the lifetime threshold of the existing SA is reached to
ensure a new SA is ready for use when the old one expires. The longer the
life time of the Internet Key Exchange (IKE) Security Association, the
longer the life time of the key used for the IKE session, which is the control
plane for establishing IPSec Security Associations. The SA is less secure
with a longer lifetime because an attacker has a greater opportunity to
collect traffic encrypted by the same key and subject it to cryptanalysis.
However, a shorter IKE lifetime causes IPSec peers to have to renegotiate
IKE more often resulting in the expenditure of additional resources.
Nevertheless, it is imperative the IKE SA lifetime terminates within 24
hours or less.
The security posture of the remote PC connecting to the enclave via VPN
is vital to the overall security of the enclave. While on-site hosts are
behind the enclaveâ€™s perimeter defense, a remote PC is not and
therefore is exposed to many vulnerabilities existing in the Internet when
connected to a service provider via dial-up or broadband connection.
Though it is policy to have a firewall installed on the remote PC according
to the Secure Remote Computing Endpoint STIG (SRC-EPT-405), it is
imperative the VPN gateway enforce the policy to the software client to
verify the firewall is active prior to enabling access to the VPN.
Diffie-Hellman (DH) is a public -key cryptography scheme allowing two
parties to establish a shared secret over an insecure communications
channel. IKE uses Diffie-Hellman to create keys used to encrypt both the
Internet Key Exchange (IKE) and IPsec communication channels. The
process works by two peers both generating a private and a public key and
then exchanging their public keys with each other. The peers produce the
same shared secret by using each otherâ€™s public key and their own
private key using the DH algorithm.
With Perfect Forward Secrecy (PFS), every time a new IPsec SA is

negotiated during the Quick Mode, a new DH exchange occurs. The new
DH shared secret will be included with original keying material (SYKEID_d,
initiator nonce, and responder nonce from Phase 1) for generating a new
IPsec session key. If PFS is not used, the IPsec session key will always be
completely dependent on the original keying material from the Phase-1.
Hence, if an older key is compromised at any time, it is possible that all
new keys may be compromised.
The Internet Key Exchange (IKE) Phase-2 (Quick Mode) Security

Association (SA) is used to create an IPSec session key. Hence, its rekey or
key regeneration procedure is very important. The Phase-2 rekey can be
performed with or without Perfect Forward Secrecy (PFS). With PFS, every
time a new IPSec Security Association is negotiated during the Quick
Mode, a new Diffie-Hellman (DH) exchange occurs. The new DH shared
secret will be included with original keying material (SYKEID_d, initiator
nonce, and responder nonce from Phase 1) for generating a new IPSec
session key. If PFS is not used, the IPSec session key will always be
completely dependent on the original keying material from the Phase-1.
Hence, if an older key is compromised at any time, it is possible that all
new keys may be compromised.
The DH exchange is performed in the same manner as was done in Phase
1 (Main or Aggressive Mode). However, the Phase-2 exchange is protected
by encrypting the Phase-2 packets with the key derived from the Phase-1
negotiation. Because DH negotiations during Phase-2 are encrypted, the
new IPSec session key has an added element of secrecy.
When a VPN gateway creates an IPSec Security Association (SA), resources

must be allocated to maintain the SA. These resources are wasted during
periods of IPSec endpoint inactivity which could result in the gatewayâ€™s
inability to create new SAs for other endpoints; thereby, preventing new
sessions from connecting. The IPSec SA idle timer allows SAs associated
with inactive endpoints to be deleted before the SA lifetime has expired.
Enabling the password save function requires users to only enter their
password once when establishing the VPN tunnel. After that the software
client will automatically re-enter the password when prompted for
credentials by the VPN gateway.
Berkeley Software Distribution (BSD) "r" commands allow users to execute
commands on remote systems using a variety of protocols. The BSD "r"
commands (e.g., rsh, rlogin, rcp, rdump, rrestore, and rdist) are designed
to provide convenient remote access without passwords to services such
as remote command execution (rsh), remote login (rlogin), and remote file
copy (rcp and rdist). The difficulty with these commands is they use
address-based authentication. An attacker who convinces a server that he
is coming from a "trusted" machine can essentially get complete and
unrestricted access to a system. The attacker can convince the server by
impersonating a trusted machine and using IP address, by confusing DNS
so that DNS thinks that the attacker's IP address maps to a trusted
machine's name, or by any of a number of other methods.

address instead of the numerous physical interface addresses. Syslog
The Finger service supports the UNIX Finger protocol, which is used for
querying a host about the users that are logged on. This service is not
necessary for generic users. If an attacker were to find out who is using
the network, they may use social engineering practices to try to elicit
classified DoD information.
A VPN hardware or software client with split tunneling enabled provides

an unsecured backdoor to the enclave from the Internet. With split
tunneling enabled, a remote client has access to the Internet while at the
same time has established a secured path to the enclave via an IPSec
tunnel. A remote client connected to the Internet that has been
compromised by an attacker in the Internet, provides an attack base to the
enclaveâ€™s private network via the IPSec tunnel. Hence, it is imperative
that the VPN gateway enforces a no split-tunneling policy to all remote
clients.
An attacker may attempt to connect to the device using SSH by guessing

the authentication method, encryption algorithm, and keys. Limiting the
amount of time allowed for authenticating and negotiating the SSH
session reduces the window of opportunity for the malicious user
attempting to make a connection to the network device.
Enabling write access to the device via SNMP provides a mechanism that
can be exploited by an attacker to set configuration variables that can
disrupt network operations.
Many attacks on information systems and network devices are launched

from within the network. Hence, it is imperative that all passwords are
encrypted so they cannot be intercepted by viewing the console or
printout of the configuration.
Network devices not protected with strong password schemes provide the
opportunity for anyone to crack the password thus gaining access to the
device and causing network outage or denial of service. Many default
vendor passwords are well-known; hence, not removing them prior to
deploying the network devices into production provides an opportunity
for a malicious user to gain unauthorized access to the device.
Using shared secrets between two IPSec endpoints is easy to implement

but are also easy to compromise. Regardless of the strength of the
password, they can be cracked using software tools that are readily
available. Furthermore, implementation using shared secrets is not
scalable since all VPN gateways and software clients would need to be
configured with the shared secrets. In addition, there cannot be a
preshared key for every user because the VPN gateway server does not
know the clientâ€™s identity (the IP address is commonly used). Hence,
remote users must use a group-based preshared key for authentication.
When an individual leaves the group, changing the key must be
coordinated with the other users of the group. PKI mitigates the risk
involved with group passwords because each user has a certificate.
PKI offers a scalable way to authenticate all IPSec endpoints in a secure

manner. Every VPN gateway or remote client that needs to participate in
IPSec VPN is issued a digital certificate by the Certification Authority (CA).
The digital certificate binds the identity information of a VPN gateway
(e.g., hostname or IP address) to the deviceâ€™s public key by means of
digital signature. This involves the use of public key cryptography
algorithms, such as RSA. Based on this binding, any device that trusts the
CA certificate, i.e., trusts the signature of the CA, would accept the
identity inside the signed certificate. This model enables all VPN gateways
and clients that trust the same CA to authenticate each other.
If the keys used for routing protocol authentication are guessed, the
malicious user could create havoc within the network by advertising
incorrect routes and redirecting traffic. Changing the keys frequently
reduces the risk of them eventually being guessed. When configuring
authentication for routing protocols that provide key chains, configure two
rotating keys with overlapping expiration dates, both with 180-day or less
expirations.
Network devices may be distributed by the vendor pre-configured with an

SNMP agent using the well-known SNMP community strings public for
read only and private for read and write authorization. An attacker can
obtain information about a network device using the read community
string "public". In addition, an attacker can change a system configuration
using the write community string "private".
Authentication for administrative access to the device is required at all
times. A single account of last resort can be created on the device's local
database for use in an emergency such as when the authentication server
is down or connectivity between the device and the authentication server
is not operable. The console or local account of last resort logon
credentials must be stored in a sealed envelope and kept in a safe.
All network devices must present a DoD-approved warning banner prior to

a system administrator logging on. The banner should warn any
unauthorized user not to proceed. It also should provide clear and
unequivocal notice to both authorized and unauthorized personnel that
access to the device is subject to monitoring to detect unauthorized
usage. Failure to display the required logon warning banner prior to logon
attempts will limit DoD's ability to prosecute unauthorized access and also
presents the potential to give rise to criminal and civil liability for systems
administrators and information systems managers. In addition, DISA's
ability to monitor the device's usage is limited unless a proper warning
banner is displayed.
DoD CIO has issued new, mandatory policy standardizing the wording of
"notice and consent" banners and matching user agreements for all Secret
and below DoD information systems, including stand-alone systems by
releasing DoD CIO Memo, "Policy on Use of Department of Defense (DoD)
Information Systems Standard Consent Banner and User Agreement",
dated 9 May 2008. The banner is mandatory and deviations are not
permitted except as authorized in writing by the Deputy Assistant
Secretary of Defense for Information and Identity Assurance.
Implementation of this banner verbiage is further directed to all DoD
components for all DoD assets via USCYBERCOM CTO 08-008A.
Detailed information about the network is sent across the network via
SNMP. If this information is discovered by attackers it could be used to
trace the network, show the networks topology, and possibly gain access
to network devices.
The Route Processor (RP) is critical to all network operations as it is the
component used to build all forwarding paths for the data plane via
control plane processes. It is also instrumental with ongoing network
management functions that keep the routers and links available for
providing network services. Hence, any disruption to the RP or the control
and management planes can result in mission critical network outages.
In addition to control plane and management plane traffic that is in the

router's receive path, the RP must also handle other traffic that must be
punted to the RP--that is, the traffic must be fast or process switched. This
is the result of packets that must be fragmented, require an ICMP
response (TTL expiration, unreachable, etc.) have IP options, etc. A DoS
attack targeting the RP can be perpetrated either inadvertently or
maliciously involving high rates of punted traffic resulting in excessive RP
CPU and memory utilization. To maintain network stability, the router
must be able to securely handle specific control plane and management
plane traffic that is destined to it, as well as other punted traffic.
Using the ingress filter on forwarding interfaces is a method that has been
used in the past to filter both forwarding path and receiving path traffic.
However, this method does not scale well as the number of interfaces
grows and the size of the ingress filters grow. Control plane policing can be
used to increase security of routers and multilayer switches by protecting
the RP from unnecessary or malicious traffic. Filtering and rate limiting the
traffic flow of control plane packets can be implemented to protect
routers against reconnaissance and DoS attacks allowing the control plane
to maintain packet forwarding and protocol states despite an attack or
heavy load on the router or multilayer switch.
The OOBM access switch will connect to the management interface of the
managed network device. The management interface of the managed
network device will be directly connected to the OOBM network. An
OOBM interface does not forward transit traffic; thereby, providing
complete separation of production and management traffic. Since all
management traffic is immediately forwarded into the management
network, it is not exposed to possible tampering. The separation also
ensures that congestion or failures in the managed network do not affect
the management of the device. If the OOBM interface does not have an IP
address from the managed network address space, it will not have
reachability from the NOC using scalable and normal control plane and
forwarding mechanisms.
managed network device. The management interface can be a true OOBM
interface or a standard interface functioning as the management interface.
In either case, the management interface of the managed network device
will be directly connected to the OOBM network.
An OOBM interface does not forward transit traffic; thereby, providing

the management of the device. If the device does not have an OOBM
port, the interface functioning as the management interface must be
configured so that management traffic does not leak into the managed
network and that production traffic does not leak into the management
network.
Network access control mechanisms interoperate to prevent unauthorized

access and to enforce the organization's security policy. Access to the
network must be categorized as administrator, user, or guest so the
appropriate authorization can be assigned to the user requesting access to
the network or a network device. Authorization requires an individual
account identifier that has been approved, assigned, and configured on an
authentication server. Authentication of user identities is accomplished
through the use of passwords, tokens, biometrics, or in the case of multi-
factor authentication, some combination thereof. Lack of authentication
enables anyone to gain access to the network or possibly a network device
providing opportunity for intruders to compromise resources within the
network infrastructure.
Both IPSec endpoints must authenticate each other to ensure the identity
of each by additional means besides an IP address which can easily be
spoofed. The objective of IPSec is to establish a secured tunnel with
privacy between the two endpoints traversing an IP backbone network. In
the case of teleworkers accessing the enclave using a laptop configured
with an IPSec software client, the secured path will also traverse the
Internet. The secured path will grant the remote site or client access to
resources within the private network; thereby establishing a level of trust.
Hence, it is imperative that some form of authentication is used prior to
establishing an IPSec session for transporting data to and from the enclave
from a remote site.
If the running and startup router configurations are not synchronized

properly and a router malfunctions, it will not restart with all of the recent
changes incorporated. If the recent changes were security related, then
the routers would be vulnerable to attack.
Group accounts configured for use on a network device do not allow for
accountability or repudiation of individuals using the shared account. If
group accounts are not changed when someone leaves the group, that
person could possibly gain control of the network device. Having group
accounts does not allow for proper auditing of who is accessing or
changing the network.
managed network devices. The management interface can be a true
OOBM interface or a standard interface functioning as the management
interface. In either case, the management interface of the managed
network devices will be directly connected to the OOBM network.
An OOBM interface does not forward transit traffic; thereby, providing

the management of the device. If the device does not have an OOBM
port, the interface functioning as the management interface must be
configured so that management traffic, both data plane and control plane,
does not leak into the managed network and that production traffic does
not leak into the management network.

address instead of the numerous physical interface addresses. NTP
Because hash algorithms create a short fixed-length hash value to

represent data of any size, there are far more possible input values than
there are unique hash values. Hence, multiple input values exist that will
produce the same hash value. This is known as a collision and for a hash
function to be deemed cryptographically secure and collision resistant, it
has to be hard to find two inputs that hash to the same output. Various
methods have been published stating that an MD5 collision has been
found in less than a minute. Therefore, MD5 is considered
cryptographically broken and should be not be usedâ€”and certainly not
for security-based services relying on collision resistance. Using a weak
hash algorithm such as MD5 could enable a rogue device to discover the
authentication key enabling it to establish an Internet Key Exchange (IKE)
Security Association with either of the VPN end points. Hence, Secure
Hash Algorithm (SHA) must be used for IKE cryptographic hashing
operations required for authentication and integrity verification.
Packet Assembler Disassembler (PAD) is an X.25 component seldom used.
It collects the data transmissions from the terminals and gathers them into
a X.25 data stream and vice versa. PAD acts like a multiplexer for the
terminals. If enabled, it can render the device open to attacks. Some voice
vendors use PAD on internal routers.
Remote administration is inherently dangerous because anyone with a

sniffer and access to the right LAN segment could acquire the device
account and password information. With this intercepted information they
could gain access to the infrastructure and cause denial of service attacks,
intercept sensitive information, or perform other destructive actions.

for security, access, management, and scalability. It is easier to construct
appropriate filters for control plane traffic. Log information recorded by
authentication and syslog servers will record the router's loopback address
instead of the numerous physical interface addresses.
The IPSec SA and its corresponding key will expire either after the number
of seconds or amount of traffic volume has exceeded the configured limit.
A new SA is negotiated before the lifetime threshold of the existing SA is
reached to ensure that a new SA is ready for use when the old one
expires. The longer the life time of the IPSec Security Association, the
longer the life time of the session key used to protect IP traffic. The SA is
less secure with a longer lifetime because an attacker has a greater
opportunity to collect traffic encrypted by the same key and subject it to
cryptanalysis. However, a shorter lifetime causes IPSec peers to have to
renegotiate IKE Phase II more often resulting in the expenditure of
additional resources. Nevertheless, it is imperative the IPSec SA lifetime
terminates within 8 hours.
Packets from a remote client destined outbound must be inspected and

proxied the same as any other traffic that will egress the enclave.
Otherwise, there is the risk that the return traffic that will ingress the
IPSec tunnel could compromise the remote client and possibly the remote
LAN. This scenario can exist with a VPN-on-a-stick implementation that
allows traffic to u-turnâ€”that is, traffic from the remote site that traverses
the IPSec tunnel is immediately forwarded out the same interface towards
the NIPRNet and Internet with no upstream firewall. If a remote LAN is
breached, the entire enclave could be exposed via the secured tunnel or
any other provisioned link between the compromised remote LAN and
other remote sites and the central site. Hence, it is imperative that traffic
from the remote site that is destined outbound does not bypass the
applicable inspection and proxy services deployed for the enclaveâ€™s
perimeter defense.
An IPSec Security Associations (SA) is established using either Internet Key
Exchange (IKE) or manual configuration. When using IKE, the security
associations are established when needed and expire after a period of
time or volume of traffic threshold. If manually configured, they are
established as soon as the configuration is complete at both end points
and they do not expire. When using IKE, the Security Parameter Index
(SPI) for each security association is a pseudo-randomly derived number.
Without IKE, the SPI is manually specified for each security association.
IKE peers will negotiate the encryption algorithm and authentication or
hashing methods as well as generate the encryption keys.
With manual configuration of the IPSec security association, both the

cipher key and authentication key are static. Hence, if the keys are
compromised, the traffic being protected by the current IPSec tunnel can
be decrypted as well as traffic in any future tunnels established by this SA.
Furthermore, the peers are not authenticated prior to establishing the SA
which could result in a rouge device establishing an IPSec SA with either of
the VPN end points.
IKE provides primary authentication to verify the identity of the remote

system before negotiation begins. IKE also enables anti-replay services and
will establish a lifetime for each IPSec session. These features are lost
when the IPSec security associations are manually configured which
results in a non-terminating session using static pre-shared keys.
Diffie-Hellman (DH) is a public-key cryptography scheme that allows two

parties to establish a shared secret over an insecure communications
channel. IKE uses DH to create keys used to encrypt both the Internet Key
Exchange (IKE) and IPsec communication channels. The process works by
two peers both generating a private and a public key and then exchanging
their public keys with each other. The peers produce the same shared
secret by using each otherâ€™s public key and their own private key using
the DH algorithm.
The DH group is configured as part of the IKE Phase 1 key exchange

settings. DH public key cryptography is used by all major VPN gateways.
DH group 1 consists of a 768 bit modulus, group 2 consists of 1024 bit
modulus, group 5 uses a 1536 bit modulus, and group 14 uses a 2048 bit
modulus. The security of the DH key exchange is based on the difficulty of
solving the discrete logarithm in which the key was derived from. Hence,
the larger the modulus, the more secure the generated key is considered
to be.
Aggressive mode is completed using only three messages instead of the
six used in main mode. Essentially, all the information needed to generate
the Diffie-Hellman secret is exchanged in the first two messages
exchanged between the two peers. The identity of the peer is also
exchanged in the first two packets which have been sent in the clear.
There are risks to configurations that use pre-shared keys which are
exaggerated when aggressive mode is used. The entire session may be
intercepted and manipulated. An adversary can either use a pre-shared
key to impersonate a trusted end-point or client and connect to the
protected network, or it can mount a Man-in-the-Middle attack on any
new session.
Identification support allows one to query a TCP port for identification.

This feature enables an unsecured protocol to report the identity of a
client initiating a TCP connection and a host responding to the connection.
Identification support can connect a TCP port on a host, issue a simple
text string to request information, and receive a simple text-string reply.
This is another mechanism to learn the router vendor, model number, and
software version being run.
Idle TCP sessions can be susceptible to unauthorized access and hijacking

attacks. By default, routers do not continually test whether a previously
connected TCP endpoint is still reachable. If one end of a TCP connection
idles out or terminates abnormally, the opposite end of the connection
may still believe the session is available. These "orphaned" sessions use up
valuable router resources and can also be hijacked by an attacker. To
mitigate this risk, routers must be configured to send periodic keepalive
messages to check that the remote end of a session is still connected. If
the remote device fails to respond to the keepalive message, the sending
router will clear the connection and free resources allocated to the
session.
Encapsulating Security Payload (ESP) is the feature in the IPSec

architecture providing confidentiality, data origin authentication, integrity,
and anti-replay services. ESP can be deployed in either transport or tunnel
mode. Transport mode is used to create a secured session between two
hosts. It can also be used when two hosts simply want to authenticate
each IP packet with IPSec authentication header (AH). With ESP transport
mode, only the payload (transport layer) is encrypted; whereas with
tunnel mode, the entire IP packet is encrypted and encapsulated with a
new IP header. Tunnel mode is used to encrypt traffic between secure
IPSec gateways, or between an IPSec gateway and an end-station running
IPSec software. Hence, it is the only method to provide secured path to
transport traffic between remote sites or end-stations and the central site.
A VPN gateway peer at the remote site provides connectivity to the central
or other remote sites belonging to the enclave via an IPSec tunnel across
an IP backbone network such as the NIPRNet. This creates an extension or
Intranet for the enclave using IPSec tunnels in lieu of traditional or legacy
WAN services (T carrier, ATM, frame relay, etc). Unless the remote site has
the required enclave perimeter defense (firewall, IPS, deny by default,
etc), it is imperative that all inbound and outbound traffic traverse only
the IPSec tunnels or other provisioned WAN links connecting the remote
site to other sites belonging to the enclave.
In other words, no packets can leak out an external-facing interface as
â€œnativeâ€ IP traffic into an IP backbone (i.e. NIPRNet, Internet). In
addition, the external interface must not receive any traffic that is not
secured by an IPSec tunnel or other provisioned WAN links connected to
the central or remote site. This not only ensures that inbound and
outbound traffic does not bypass the enclaveâ€™s perimeter defense, but
also eliminates any backdoor connection.
While there is much debate about the security and performance of

Advance Encryption Standard (AES), there is a consensus that it is
significantly more secure than any of the algorithms supported by IPSec
implementations today. AES is available in three key sizes: 128, 192 and
256 bits, versus the 56 bit DES. Therefore, there are approximately 1021
times more AES 128-bit keys than DES 56-bit keys. In addition, AES uses a
block size of 128 bitsâ€”twice the size of DES or 3DES. To ensure the
privacy of the IKE session responsible for establishing the security
association and key exchange for an IPSec tunnel, it is imperative that AES
is used for encryption operations.
The use of POTS lines to modems connecting to network devices provides

clear text of authentication traffic over commercial circuits that could be
captured and used to compromise the network. Additional war dial
attacks on the device could degrade the device and the production
network.
Secured modem devices must be able to authenticate users and must

negotiate a key exchange before full encryption takes place. The modem
will provide full encryption capability (Triple DES) or stronger. The
technician who manages these devices will be authenticated using a key
fob and granted access to the appropriate maintenance port, thus the
technician will gain access to the managed device (router, switch, etc.).
The token provides a method of strong (two-factor) user authentication.
The token works in conjunction with a server to generate one-time user
passwords that will change values at second intervals. The user must
know a personal identification number (PIN) and possess the token to be
allowed access to the device.
The susceptibility of IP addresses to spoofing translates to DNS host name
and IP address mapping vulnerabilities. For example, suppose a source
host wishes to establish a connection with a destination host and queries
a DNS server for the IP address of the destination host name. If the
response to this query is the IP address of a host operated by an attacker,
the source host will establish a connection with the attacker's host, rather
than the intended target. The user on the source host might then provide
logon, authentication, and other sensitive data.
SNMP Versions 1 and 2 are not considered secure. Without the strong
authentication and privacy that is provided by the SNMP Version 3 User-
based Security Model (USM), an unauthorized user can gain access to
network management information used to launch an attack against the
network.
A malicious user attempting to gain access to the network device may

compromise an account that may be unauthorized for use. The
unauthorized account may be a temporary or inactive account that is no
longer needed to access the device. Denial of Service, interception of
sensitive information, or other destructive actions could potentially take
place if an unauthorized account is configured to access the network
device.
Auditing and logging are key components of any security architecture. It is

essential for security personnel to know what is being done, attempted to
be done, and by whom in order to compile an accurate risk assessment.
Auditing the actions on network devices provides a means to recreate an
attack, or identify a configuration mistake on the device.
Terminating an idle session within a short time period reduces the window
of opportunity for unauthorized personnel to take control of a
management session enabled on the console or console port that has
been left unattended. In addition quickly terminating an idle session will
also free up resources committed by the managed network device. Setting
the timeout of the session to 10 minutes or less increases the level of
protection afforded critical network components.
Audit logs are necessary to provide a trail of evidence in case the network
is compromised. Without an audit trail that provides a when, where, who
and how set of information, repeat offenders could continue attacks
against the network indefinitely. With this information, the network
administrator can devise ways to block the attack and possibly identify and
prosecute the attacker.
A gratuitous ARP is an ARP broadcast in which the source and destination

MAC addresses are the same. It is used to inform the network about a
host IP address. A spoofed gratuitous ARP message can cause network
mapping information to be stored incorrectly, causing network
malfunction.
Recommendation
Configure the device to disable using HTTP (port 80) for
administrative access.
Configure the device to disable all BOOTP services.
Disable the configuration auto-loading feature, when connected

to an operational network.
Configure the router to disable IP source routing.
Configure the network device to use secure protocols with FIPS

140-2 validated cryptographic modules.
Configure the device to authenticate all received NTP messages
using a FIPS-approved message authentication code algorithm.
Configure the device to use its loopback or OOB management

interface address as the source address when originating
authentication services traffic.
Configure the SNMP community strings on the network device

and change them from the default values. SNMP community
strings and user passwords must be unique and not match any
other network device passwords. Different community strings
(V1/2) or groups (V3) must be configured for various levels of read
and write access.
Configure the network device to use SSH version 2.

interface address as the source address when originating SNMP
traffic.

interface address as the source address when originating IP
Flow/NetFlow traffic.
Configure the network device to use a loopback or OOB

management interface address as the source address when
originating TFTP or FTP traffic.
Configure authentication for console access on the network

device.
Configure the network device to log all messages except

debugging and send all log data to a syslog server.
Configure the network devices to ensure the timeout for

unattended administrative access connections is no longer than
10 minutes.
Configure the CA trust point to enable certificate revocation check
by referencing a CRL or via OCSP.
Configure authentication for all management connections.
Configure the device to use two separate NTP servers.
Change the device configuration to include the following IOS

commands: no service tcp-small-servers and no service udp-small-
servers for each device running an IOS version prior to 12.0. This
is the default for IOS versions 12.0 and later (i.e., these commands
will not appear in the running configuration.)
Configure authorized accounts with the least privilege rule. Each

user will have access to only the privileges they require to perform
their assigned duties.
Configure the device to authenticate all BGP peers.
Enable anti-replay on all IPSec security associations either within

IPSec profiles or as a global command.
Configure the network device to require a maximum number of

unsuccessful SSH logon attempts at 3.
Disable IP directed broadcasts on all layer 3 interfaces.
Configure transform sets used for transporting classified packets

to be compliant with Suite B requirements.
Configure the VPN gateway to enroll with a DoD-approved
Certificate Authority.
Assign a privilege level to the emergency administration account

to allow the administrator to perform necessary administrative
functions when the authentication server is not online.
Configure the ISAKMP client configuration groups used to push

policy to remote software clients to display a DoD approved
warning banner prior to allowing access to the VPN.
Update operating system to a supported version that addresses all
related IAVMs.
Configure authentication for all IGP peers.
Configure the device to use two separate authentication servers.
Configure all IPSec transform sets to use AES for performing

cryptographic encryption operations.
Configure all IPSec transform sets to use SHA for performing

cryptographic hashing operations.
Configure the device to drop half-open TCP connections through
threshold filtering or timeout periods.
Configure a lifetime value of 24 hours or less for all ISAKMP

polices.

policy to remote software clients to check for the presence of a
personal firewall before enabling access to the VPN.
Configure the VPN gateway to ensure Diffie-Hellman Group 14 or
larger is used when enabling PFS.
Configure the VPN gateway to ensure PFS is enabled.
Configure an idle time value of 1 hour or less for all IPSec security
associations either within IPSec profiles or as a global command.

policy to remote software clients to disable the ability for users to
save their logon password locally on the remote PC.
Configure the device to disable BSDr command services.

interface address as the source address when originating syslog
traffic.
Configure the device to disable the Finger service.
Disable split tunneling on all ISAKMP client configuration groups.
Configure the network devices so it will require a secure shell

timeout of 60 seconds or less.
Configure the network device to allow for read-only SNMP access

when using SNMPv1, v2c, or basic v3 (no authentication or
privacy). Write access may be used if authentication is configured
when using SNMPv3.
Configure the network devices to ensure passwords are not

viewable when displaying configuration information.
Remove any vendor default passwords from the network devices
configuration.
Configure the VPN gateway to use certificate-based authentication

for IPSec peers and clients. The authentication method will be
defined on the ISAKMP policy used to establish an IKE security
association.
Configure the device so rotating keys expire at 180 days or less.
Configure unique SNMP community strings replacing the default

community strings.
Configure the device to only allow one local account of last resort
for emergency access and store the credentials in a secure
manner.
Configure all management interfaces to the network device to

display the DoD-mandated warning banner verbiage at logon
regardless of the means of connection or communication. The
required banner verbiage that must be displayed verbatim is as
follows:
Option A
You are accessing a U.S. Government (USG) Information System

(IS) that is provided for USG-authorized use only. By using this IS
(which includes any device attached to this IS), you consent to the
following conditions:
-The USG routinely intercepts and monitors communications on

this IS for purposes including, but not limited to, penetration
testing, COMSEC monitoring, network operations and defense,
personnel misconduct (PM), law enforcement (LE), and
counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private,
are subject to routine monitoring, interception, and search, and
may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and
access controls) to protect USG interests--not for your personal
benefit or privacy.
-Notwithstanding the above, using this IS does not constitute
consent to PM, LE or CI investigative searching or monitoring of
the content of privileged communications, or work product,
related to personal representation or services by attorneys,
psychotherapists, or clergy, and their assistants. Such
communications and work product are private and confidential.
See User Agreement for details.
Option B
If the system is incapable of displaying the required banner

verbiage due to its size, a smaller banner must be used. The
mandatory verbiage
Configure the networkfollows: "I've
devices readallow
to only & consent
SNMPtoaccess
termsfrom
in IS
only addresses belonging to the management network.
Implement control plane protection by classifying traffic types
based on importance levels and configure filters to restrict and
rate limit the traffic punted to the route processor as according to
each class.
Configure the OOB management interface with an IP address from

the address space belonging to the OOBM network.
If the management interface is a routed interface, it must be
configured with both an ingress and egress ACL. The ingress ACL
should block any transit traffic, while the egress ACL should block
any traffic that was not originated by the managed network
device.
Configure the network devices so it will require a password to gain

administrative access to the device.
Configure the VPN gateway to authenticate the remote end-point

prior to establishing an IPSec session. The authentication method
will be defined on the ISAKMP policy used to establish an IKE
security association.
Add procedures to the standard operating procedure to keep the

running configuration synchronized with the startup configuration.
Configure individual user accounts for each authorized person
then remove any group accounts.
Configure the management interface as passive for the IGP

instance configured for the managed network. Depending on the
platform and routing protocol, this may simply require that the
interface or its IP address is not included in the IGP configuration.

interface address as the source address when originating NTP
traffic.
Configure all ISAKMP policies to use SHA for IKE cryptographic

hashing operations.
Configure the device to disable the PAD service.
Configure an ACL or filter to restrict management access to the

device from only the management network.
Configure the network device's loopback address as the source

address for iBGP peering.
Configure a lifetime value of 8 hours or less for all IPSec security

associations either within IPSec profiles or as a global command.
Deploy the VPN gateway within a DMZ or configure the device to

not permit u-turn traffic. If it must allow u-turn traffic, then
deploy a firewall upstream to inspect the outbound traffic.
Configure the VPN gateway to use IKE for establishing all IPSec
security associations. An ISAKMP policy must be configured to
define the IKE security association which will include the peer, the
authentication method, encryption suite, and Diffie-Hellman
group.
Configure the VPN gateway to ensure Diffie-Hellman Group 14 or

larger is used.
Configure the VPN gateway to ensure aggressive mode is disabled
for all IKE Phase 1 security associations.
Configure the device to disable identification support.
Configure the device to enable TCP Keep-Alives.
Configure all IPSec transform sets to use ESP tunnel mode.

Configure the VPN gateway at the remote site to ensure it receives
all ingress traffic and forward all egress traffic via the IPSec tunnel.
All inbound and outbound traffic must be considered interesting
traffic for the IPSec crypto maps bound to the external interfaces.
If IPSec-protected virtual tunnel interfaces are configured, all
traffic must flow through them or other provisioned WAN links
connecting the remote site to other sites belonging to the
enclave.
Configure all ISAKMP policies to use AES for IKE cryptographic

encryption operations.
Disable the auxiliary port. If used for out-of-band administrative

access, the port must be connected to a secured modem
providing encryption and authentication.
Configure the device to include DNS servers or disable domain
lookup.
If SNMP is enabled, configure the network device to use SNMP

Version 3 Security Model with FIPS 140-2 validated cryptography
(i.e., SHA authentication and AES encryption).
Remove any account configured for access to the network device

that is not defined in the organization's responsibilities list.
Configure interface ACLs to log all deny statements.
Configure the timeout for idle console connection to 10 minutes

or less.
Configure the device to log all access attempts to the device to

establish a management connection for administrative access.
Disable gratuitous ARP on the device.

IPSec VPN Gateway - MSBS-Controls

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IPSec VPN Gateway - MSBS-Controls

Uploaded by

Copyright:

Available Formats

Sr

2 BOOTP services must be disabled.

3 The Configuration auto-loading feature must be disabled when

4 IP source routing must be disabled.

5 Management connections to a network device must be

7 The network device must use its loopback or OOB management

8 The network device must use different SNMP community

11 The network device must use its loopback or OOB management

12 The network device must use its loopback or OOB management

13 The network device must require authentication for console

14 The network device must log all messages except debugging

15 The network devices must timeout management connections

17 The network device must require authentication prior to

18 Network devices must use at least two NTP servers to

19 Network devices must have TCP and UDP small servers

20 Authorized accounts must be assigned the least privilege level

23 The network device must be configured for a maximum number

25 IPSec Security Association parameters must be compliant with

27 The emergency administration account must be set to an

28 The VPN gateway server must enforce a policy to the software

30 Network devices must authenticate all IGP peers.

31 Network devices must use two or more authentication servers

32 The VPN gateway must use AES for IPSec cryptographic

35 The VPN gateway must implement IKE Security Associations

36 The VPN gateway server must enforce a policy to the remote

38 The VPN gateway must specify Perfect Forward Secrecy during

39 The VPN gateway must implement IPSec security associations

40 The VPN gateway server must enforce a policy to the software

42 The network device must use its loopback or OOB management

43 Network devices must have the Finger service disabled.

44 The VPN gateway server must enforce a no split-tunneling

45 The network devices must be configured to timeout after 60

46 Network devices must only allow SNMP read-only access.

47 Network devices must be configured to ensure passwords are

49 The VPN gateway must use PKI or digital-signature for

50 Network devices must be configured with rotating keys used for

51 The network device must not use the default or well-known

53 Network devices must display the DoD-approved logon banner

54 Network devices must only allow SNMP access from addresses

56 The network devices OOBM interface must be configured with

58 Network devices must be password protected.

59 The VPN gateway must authenticate the remote server, peer, or

60 The running configuration must be synchronized with the

62 The management interface must be configured as passive for

63 The network device must use its loopback or OOB management

66 The network devices must only allow management connections

67 The network device must use its loopback interface address as

68 The VPN gateway must implement IPSec security associations

73 Network devices must have identification support disabled.

74 Network devices must have TCP Keep-Alives enabled for TCP

78 The auxiliary port must be disabled unless it is connected to a

80 The network device must use SNMP Version 3 Security Model

81 Unauthorized accounts must not be configured for access to the

84 Network devices must log all attempts to establish a

85 Gratuitous ARP must be disabled.

BOOTP is a user datagram protocol (UDP) that can be used by Cisco

Source routing is a feature of IP, whereby individual packets can specify

Two NTP-enabled devices can communicate in either client-server mode

A hierarchical model can be used to improve scalability. With this

The NTP authentication model is opposite of the typical client-server

Using a loopback address as the source address offers a multitude of uses

Numerous vulnerabilities exist with SNMP; therefore, without unique

SSH Version 1 is a protocol that has never been defined in a standard.