Download IAS Router Common Criteria Operator Guidance

IAS Router
Common Criteria
Operator Guidance
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Table of Contents
Table of Contents .......................................................................................................................................... 2
1
Guidance Overview ............................................................................................................................... 4
2
Introduction .......................................................................................................................................... 5
3
Getting Started...................................................................................................................................... 6
4
3.1
Identification ................................................................................................................................. 6
3.2
Environment.................................................................................................................................. 6
3.2.1
Technical Requirements ........................................................................................................ 6
3.2.2
Procedural Requirements ..................................................................................................... 7
Installation ............................................................................................................................................ 9
4.1
User Accounts ............................................................................................................................... 9
4.2
Firewall ........................................................................................................................................ 12
4.2.1
Firewall Introduction ........................................................................................................... 12
4.2.2
Rules .................................................................................................................................... 14
4.2.3
Global Rules ........................................................................................................................ 19
4.2.4
Zones ................................................................................................................................... 20
4.2.5
Forwarding Rules ................................................................................................................ 21
4.2.6
Port Forwarding (Redirects) ................................................................................................ 21
4.3
5
IPsec ............................................................................................................................................ 22
4.3.1
BYPASS and DROP SPD Policies ........................................................................................... 23
4.3.2
IPSec VPN: Implementing PROTECT SPD Policies................................................................ 23
4.3.3
Protecting Syslog Audit Traffic ............................................................................................ 27
4.4
TLS ............................................................................................................................................... 28
4.5
Cryptographic Operations ........................................................................................................... 28
4.5.1
Certificate Generation and Loading .................................................................................... 28
4.5.2
Certificate Validation .......................................................................................................... 31
Security Functions ............................................................................................................................... 33
5.1
Security Audit .............................................................................................................................. 33
5.2
Key Generation ........................................................................................................................... 33
5.3
Administration ............................................................................................................................ 34
5.3.1
Administration Authentication Rules .................................................................................. 34
5.3.2
Administration Access Control ............................................................................................ 34
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
5.4
Time ............................................................................................................................................ 36
5.5
Firmware Updates....................................................................................................................... 37
5.6
Welcome Banner......................................................................................................................... 37
6
Troubleshooting .................................................................................................................................. 39
7
Appendix A: Audit Records ................................................................................................................. 40
8
Appendix B: Processes ........................................................................................................................ 46
8.1
Privileges ..................................................................................................................................... 46
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
1 Guidance Overview
The goal of this guidance document is to:
1.
2.
3.
4.
5.
6.
Uniquely Identify the IAS Router and all of its parts.
Describe how to verify IAS Router upgrades.
Describe how to configure the IAS Router in a manner consistent with the NDPP and VPN EP.
Describe all of the CC Evaluated security functions.
Describe the format of the audit records.
List the processes running on the IAS Router that are capable of processing network traffic.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
2 Introduction
This document describes the Common Criteria evaluated security features of the IAS Router. The IAS
Router was evaluated against the Network Device Protection Profile (NDPP) Extended Package VPN
Gateway, Version 1.1, April 12, 2013; Protection Profile for Network Devices, Version 1.1, June 8, 2012;
and Security Requirements for Network Devices Errata #3. These documents are referred to as VPNEP
and NDPP thought this document.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
3 Getting Started
3.1 Identification
The Evaluated Device, the IAS Router, consists of the following components:
•
•
•
•
IAS Router HW, one of: IAS STEW Rev. 1.0, IAS Router Micro Rev 1.0, or IAS KG-RU Rev 1.0
IAS Router Software:
IASRouter-2015-11-24_50e8756_Release-x86-fips_cc.firmware
IAS Router Common Criteria Operator Guidance, and the IAS STEW Hardware Manual, IAS
Router Micro Hardware Manual, or IAS KG-RU Hardware Manual as applicable
The IAS STEW and IAS KG-RU contain a separate Cisco 5915 Embedded Service Router
component. This component is not covered under this Protection Profile. Documentation for
this component can be obtained from Cisco at the following
URL: http://www.cisco.com/c/en/us/support/routers/5915-embedded-servicerouter/model.html.
3.2 Environment
The administrator must ensure the guidance items within this document are enforced.
3.2.1 Technical Requirements
The IAS Router is compatible with the following devices, servers, and protocol versions:
•
•
•
•
VPN Client
o IKEv1
 See Table 1 for a complete listing of modes and ciphers
o IKEv2
 See Table 1 for a complete listing of modes and ciphers
o IPsec
 See Table 1 for a complete listing of modes and ciphers
Syslog
o Version 1 - RFC 5424
NTP
o NTPv4 Server
o NTPv4 Client
HTTPS
o TLS1.0/1.2
o See Table 1 for a complete listing of modes and ciphers
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Figure 1: IAS Router Simplified Networking Diagram
The IAS Router includes the following protocols whose effectiveness is not evaluated as a part of the
NIAP Common Criteria validation: HTTPS/TLS. Whereas these protocols may provide authentication,
integrity, and confidentiality there is no assurance assigned to their use within this evaluation.
Instructions within this guidance document will guide the administrator how to use those protocols
which are evaluated to create an assured configuration.
The IAS Router provides the following features and protocols which are outside of the scope of the NIAP
Common Criteria validation: PIMv2, GRE, OSPF, and NHRP.
3.2.2 Procedural Requirements
The following protections must be provided by the operational environment the IAS Router is deployed
in.
The Administrator must not install any additional software on the IAS Router. The IAS Router is intended
to only be operated with the software provided by IA Specialists.
The IAS Router is physically protected from unauthorized access. These countermeasures should be
commensurate with the value of the data being protected by the IAS Router.
The Administrators must be trusted, and they must follow and apply all administrator guidance.
The IAS Router must be installed in the network in a manner that will allow the IAS Router to effectively
enforce its policies on network traffic flowing among attached networks. See the network diagram in
Section 3.2.1. More specifically, the IAS Router must be the only network entity that interconnects the
trusted network(s) and the untrusted network(s).
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
The IAS Router must be set to CSfC mode in order to operate in a VPN Protection Profile compliant
mode. This is done through the “Validated Mode of Operation” dialog in the System Settings page as
Figure 2: Validated Mode of Operation Dialog
seen in Figure 2.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
4 Installation
This section describes the steps to configure the IAS Router in a manner that is consistent with the
requirements in the NDPP and VPNEP.
Before beginning, verify that the hardware and documentation matches Section 3.1.
Connect the power and network interfaces of the IAS Router according to the IAS Router STEW, Router
Micro, or KG-RU Hardware Manual, Section 3.2.1, and Section 3.2.2.
4.1 User Accounts
The IAS Router ships with a default username of admin and a default password of password123. These
default credentials can be used to access the device via the management web interface, which can be
found by default at on a lan interface which by default includes eth0, eth1, eth2, eth3, or eth4. Web
browsers that are supported include: Internet Explorer 11, Chrome 46, Firefox 22, and Safari 6.
Upon initially connecting to the IAS Router the security administrator should first select the Validated
Mode of Operation to match the desired validation environment. With the CSfC mode selected many of
the NDPP and VPNEP requirements are automatically enforced. The Validated Mode of Operation is
found under System->Validated Mode of Operation. Details of which configuration selections are
available in each mode are shown below in Table 1.
After the Validated Mode of Operation is set the IAS Router will reboot and all settings other than the
Validated Mode of Operation will be reset to their factory default settings. After this reboot the
administrator should either modify the password for the default account or create a new user account
and delete the default user account. Both operations can be completed via the System->Users page.
All account passwords must be chosen to include a combination of capital and lower case letters,
numbers, and special characters. Easily guessed and common language (dictionary) words should be
avoided. Password strength is a function of length and complexity. Longer passwords provide more
protection against brute-force attacks. We recommend to use as long and as complex of a password
that can be remembered.
In CSfC mode, the minimum requirement is for a fifteen character password containing at least one
lower case character, upper case character, digit, and special character from the set !@#$%^&*(). The
minimum password length can be increased by an administrator to up to twenty-two characters.
The password minimum length and other authentication settings for the system are found under the
System->System Authentication options. They should be modified to the level of complexity that most
appropriately matches the value of data protected by the IAS Router.
Table 1: Cryptographic Mode Supported Algorithms
Protocol/Operation
Password Complexity
Algorithm
Minimum password length
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Standard
Mode
8-22
FIPS
Mode
8-22
CSFC
Mode
15-22
Protocol/Operation
Password Complexity
Standard
Mode
8-22
FIPS
Mode
8-22
CSFC
Mode
15-22
x
x
x
IKEv1 Main Mode
IKEv1 Aggressive Mode
IKEv2
3des
AES128CBC
AES256CBC
md5
sha
sha256
sha384
sha512
dh1 - modp768
dh2 – modp1024
dh5 – modp1536
dh14 – modp2048
dh15 – modp3072
dh16 – modp4096
dh17 – modp6144
dh18 – modp8192
dh19 – ecp256
dh20 – ecp384
dh21 – ecp512
matches selected IKE integrity algo
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
3des
AES128CBC
AES256CBC
AES128CTR
AES256CTR
AES128GCM16
AES256GCM16
md5
sha
sha256
sha384
sha512
dh1 - modp768
dh2 – modp1024
dh5 – modp1536
dh14 – modp2048
dh15 – modp3072
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Algorithm
Minimum password length
Lowercase, uppercase, number, and
a special character [!@#$%^&*()]
IKE
Encryption
Integrity
Key Exchange
PRF
ESP
Encryption
Integrity
Key Exchange
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Protocol/Operation
Password Complexity
IKE Authentication
PSK
Certificate signature
algorithms
Certificate private key types
Standard
Mode
8-22
x
x
x
x
x
x
FIPS
Mode
8-22
x
x
x
x
x
x
CSFC
Mode
15-22
adhere to password complexity rules
x
x
x
rsa_with_sha1
rsa_with_sha256
rsa_with_sha384
rsa_with_sha512
ecdsa_with_sha1
ecdsa_with_sha256
ecdsa_with_sha384
x
x
x
x
x
x
x
ecdsa_with_sha512
x
x
RSA 1024
RSA 2048
RSA 4096
EC on p256
EC on p384
x
x
x
x
x
x
x
x
x
x
x
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256
DHE-RSA-AES128-SHA256
AES256-SHA256
AES128-SHA256
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Algorithm
Minimum password length
dh16 – modp4096
dh17 – modp6144
dh18 – modp8192
dh19 – ecp256
dh20 – ecp384
dh21 – ecp512
x
x
x
x
x
x
x
x
x
x
TLS Ciphers
web server SSL
AES256-SHA
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Standard
Mode
8-22
x
FIPS
Mode
8-22
x
CSFC
Mode
15-22
x
ECDHE
DHE
RSA
x
x
x
x
x
x
x
x
x
Authentication
ECDSA
RSA
x
x
x
x
x
x
Bulk Ciphers
AES256
AES128
x
x
x
x
x
x
Message Authentication
SHA384
SHA256
SHA
x
x
x
x
x
x
x
x
x
Protocol/Operation
Password Complexity
Algorithm
Minimum password length
AES128-SHA
Key exchange/agreement
4.2 Firewall
4.2.1 Firewall Introduction
A firewall Zone is a collection of Networks and a Network is a collection of Interfaces. Interfaces are
mapped to Networks on the Network page via manipulation of a network’s definition. Networks can
have one or more Interfaces. Networks are then assigned to Zones using the Network or Firewall page.
Zones can have one or more Networks. Each Zone has a default packet handling behavior, and there is a
Global Rules default traffic handling setting for any interfaces not assigned to a zone.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Figure 3: Firewall Page
The firewall configuration has a hierarchy. The configuration is processed in the following order until a
target is reached. First, Rules and Port Forwardings are processed in their configured order. Next, the
Forwarding configuration is considered. Then, the Zone configuration is processed. Finally, Global Rules
are applied. Global Rules is the final catch all for traffic processing. Once a packet has been reduced to
a target (ACCEPT, DROP, REJECT, LOG) then firewall processing has concluded for that packet.
The default configuration of Zones, Networks, and Interfaces is visualized in the figure below including
the default Forwardings and ALLOW rules that are applied to the wan Zone.
Figure 4: Default Firewall Configuration
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
4.2.2 Rules
Rules can be crafted to allow traffic to move into, out of, or between Zones at a very granular level
including IPv4 source and destination address, protocol, and for TCP/UDP source and destination port.
Rules are ordered and processed by priority. Rules are crafted with either a source and/or a destination
zone. Depending on how the source and destination zones are assigned a rule applies to traffic flowing
to the router, through the router, or from the router. Rules are processed against traffic based on
source and destination zones as depicted in Table 2. NOTE: Generally, source and destination zones
should be specified on firewall rules, UNLESS the rule is to match traffic specifically sourced or destined
for the router itself.
Table 2: IAS Router Firewall Rule Zone Usage
Source Zone
(empty)
Destination Zone
(empty)
Interpretation/Applies to
Creates an Output rule – Applies to all traffic sourced from the
IAS router, with a destination to any zone
(empty)
wan
Creates an Output rule—Applies to all traffic sourced from the
IAS router, with a destination to zone “wan”.
wan
(empty)
Creates an Input rule—Applies to all traffic sourced from the zone
“wan”, with a destination to the IAS router.
lan
wan
Creates a Forward rule—Applies to all traffic sourced from zone
“lan”, with a destination to zone “wan”.
NOTE: Any forwarding configuration, including Rules, Forwardings, or Port Forwardings (Redirections),
require that the IP routing rules also permit the traffic to flow. In other words, routing defines how
traffic flows, and the firewall rules simply restrict the available routes.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Figure 5: Firewall Rule Creation Form
Figure 6: Firewall Rules Table
4.2.2.1 Packet Filtering Setup
This note shows one of the configurations and sample rules used by IAS to test packet filtering
functionality.
That functionality has been tested on multiple devices and network arrangements, but this document
has been developed via an emulated network as follows:
This configuration has three networks:
•
•
lan (192.168.3.0)
test1 (192.168.4.0)
Management connection for configuring the IAS router
Client network containing test host
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
•
test2 (192.168.5.0)
Client network containing test host
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
The global default rules are set to reject traffic not otherwise accepted by a given rule. Three zones are
configured to correspond to the three networks; the VPN zone cannot be removed but is not used in
these tests. No default forwarding between zones is enabled.
The test zones here default to rejecting all, and cannot ping or otherwise contact each other. The lan
zone with the management laptop accepts traffic to and from the router for configuration purposes, but
without additional rules it cannot reach the test nodes. To, e.g., enable the laptop specifically to ping--and only ping---the test1 network, create a rule as follows:
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Note in the above rule that the test1 destination is required. Otherwise the rule would apply between
the laptop and the router itself (an unnamed implicit zone). A wildcard IP could be given for the
destination, but is not necessary.
For the test nodes to communicate in this configuration, explicit forwarding rules must be applied, e.g.,
to enable nodes on the test1 network to contact nodes on the test2 network:
Note again that a source and destination zone are required, as an empty zone is interpreted as the
router itself. Wildcard IP addresses could be applied but are not necessary.
The IAS Router Firewall has a basic understanding of connections and with just this rule will also accept
responses to accepted messages, e.g., permitting an ICMP ping to return.
To permit and deny specific hosts, particular IP addresses can be applied. In this rule, only Node 1
(192.168.4.10) from the test1 network is permitted to contact the test2 network, but it may
communicate to any node in that network (a wildcard has been applied but is again not necessary):
Conversely, the following pair of rules specifically excludes Node 1 (192.168.4.10) from contacting the
test2 network, but permits other hosts from test1 to do so (tested, e.g., by changing the IP of Node 1):
Note that this is a specific scenario of the packet filtering tests, denying a specific IP address from
messaging a wildcard address. All such combinations of specific and wildcard addresses are permitted
and functional, as is acceptance or rejection by protocol or port number.S
4.2.2.2 Logging Packets
Firewall rules can be created in order to meet the requirements of logging entire packet contents for
IPsec session establishment (FCS_IPSEC_EXT.1), connecting to a CA (FIA_X509_EXT.1), or logging any
arbitrary connections (FPF_RUL_EXT.1). The LOG, LOG CONN, ULOG, and ULOG CONN rules can be
combined to have granular packet logging rules. See Appendix A for examples of logging output.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
•
•
•
•
LOG: Logs basic information about the first matched packet of a connection.
LOG CONN: Logs basic information about all following packets of a connection. NOTE: This does
not capture the initial packet of the connection. Use a LOG rule for that.
ULOG: Logs the entire packet contents (as a hexdump) of the first packet of a connection.
ULOG CONN: Logs the entire packet contents (as a hexdump) of all following packets of a
connection. NOTE: This does not capture the initial packet of the connection. Use a ULOG rule
for that.
The packet captures generated by ULOG rules can be converted to PCAP files through the use of the
“text2pcap” utility. The ULOG output requires some reformatting to satisfy the requirements of
“text2pcap”. A shell command to do so is:
grep -e 'FIREWALL_ULOG:[[:space:]]*0x' LOG.txt \
| awk -F 'FIREWALL_ULOG: \t' '{print $2}' \
| awk -F: '{gsub(/[0-9a-f]{2}/,"& ",$2);print $1 $2}' \
| sed 's/0x/00/' \
| text2pcap -l 101 – LOG.pcap
Replace “LOG” with the name of the input file.
The following table provides some guidance on achieving the level of detail required by protection
profile requirements.
Process/feature requiring additional detail
IPSec CA interactions (CRL/OCSP)
IPSec SA interactions (IKE)
NTP interactions
Protocol Destination Port
TCP
Typically 80 for HTTP and 443 for HTTPS
NOTE: The destination port of the CRL/OCSP
URI is NOT GUARANTEED! This port is
determined by the URI present in a peer’s
provided identity certificate.
UDP
500 and 4500
UDP
123
4.2.3 Global Rules
Global Rules serve as a final catch-all for packets that pass all other rules. There are several Global
Rules:
•
•
•
•
Input: Followed if an incoming packet does not match any more specific rule. Available options
are ACCEPT, DROP, or REJECT.
Output: Followed if an outgoing packet does not match any more specific rule. Available
options are ACCEPT, DROP, or REJECT.
Forward: Followed if a forwarded packet does not match any more specific rule. Available
options are ACCEPT, DROP, or REJECT.
Masq Output Traffic: Whether to perform IP Masquerading on outgoing traffic. Available
options are Enabled or Disabled.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
•
MSS Clamping: Change the maximum segment size (MSS) of outgoing TCP connections to handle
links with lower MTUs. Available options are Enabled or Disabled.
To edit these fields, click the Edit button on the right hand side of the Global Rules table of the Firewall
page.
Figure 7: Global Rule Edit Dialog
4.2.4 Zones
A firewall Zone is a collection of networks. New networks can be created on the Networks tab. Creating
a new Zone is done by clicking the "Add Zone" button in the Zones table of the Firewall page. Editing or
deleting an existing zone is done by clicking the corresponding buttons on each Zone's row in the Zones
table.
The options available for Zones are the same as the options for Global Rules specified above.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Figure 8: Firewall Zone Edit Dialog
4.2.5 Forwarding Rules
Forwarding rules define traffic flows between Zones. Forwarding rules are not symmetrical, so if a rule
is defined to forward LAN traffic to the WAN, which does not automatically forward WAN traffic back,
unless there is an explicit rule. Create a new Forwarding Rule by clicking the "Add Forward" button on
the Forwarding table of the Firewall page. Editing or deleting an existing Forwarding Rule is done by
clicking the corresponding buttons on each rule's row in the Forwarding table.
Figure 9: Firewall Forwarding Rule Dialog
4.2.6 Port Forwarding (Redirects)
Port Forwarding rules redirect traffic from a particular source IP / source port combination to an
alternate destination IP / destination port.
The available fields for Port Forwarding rules are:
•
Name: A required identifier for the rule.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
•
•
•
•
•
•
•
•
•
•
Type: DNAT (Classic Port Forwarding) or SNAT (Reverse Port Forwarding).
Protocol: Any available IP protocol number.
Source Zone: Specifies the traffic source zone. Must refer to one of the defined zone names. For
typical port forwards this usually is wan.
Destination Zone: Specifies the traffic destination zone. Must refer to one of the defined zone
names. For DNAT target on Attitude Adjustment, NAT reflection works only if this is equal to lan.
Source IP: Match incoming traffic from the specified source ip address.
Destination IP: For DNAT, redirect matched incoming traffic to the specified internal host. For
SNAT, match traffic directed at the given address.
Source Port Number: Match incoming traffic originating from the given source port or port
range on the client host.
Destination Port Number: For DNAT, redirect matched incoming traffic to the given port on the
internal host. For SNAT, match traffic directed at the given ports.
Incoming Destination Port: For DNAT, match incoming traffic directed at the given destination
port or port range on this host. For SNAT rewrite the source ports to the given value.
Incoming Destination IP: For DNAT, match incoming traffic directed at the given destination ip
address. For SNAT rewrite the source address to the given address.
To create a new Port Forwarding rule, click the "Add Port Forwarding" button on the Port Forwarding
table of the Firewall page. Editing or deleting an existing Forwarding Rule is done by clicking the
corresponding buttons on each rule's row in the Forwarding table.
Figure 10: Firewall Redirect Rule Dialog
4.3 IPsec
IPSec DISCARD and BYPASS policies are configured in the IAS Router via the Firewall page. DISCARD and
BYPASS policies exist in the IAS Router as firewall Forwardings and Firewall Rules. Forwardings and
Rules are applied to traffic based on the structure of the firewall’s “Zones”.
IPSec PROTECT policies are configured as IPSec VPN definitions via the IPSec page.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
4.3.1 BYPASS and DROP SPD Policies
Default BYPASS policies that allow an entire Zone to forward traffic to another Zone are called
Forwardings. By default there are only Forwardings in place that allow traffic to flow to the VPN
process, which has its own firewall Zone. The default Forwardings can be seen in Figure 2 above. This
default configuration inhibits the per-packet bypass capabilities of the router.
Granular BYPASS policies are implemented by Rules that have an ACCEPT target. Firewall Rules can also
be crafted to drop traffic. Drop rules are how the IAS Router implements DISCARD policies. A REJECT
rule is a special type of drop that enables the IAS Router to return an ICMP destination unreachable
packet to the original packet sender.
4.3.2
IPSec VPN: Implementing PROTECT SPD Policies
4.3.2.1 IPSec Introduction
The VPN process applies PROTECT policies to traffic entering the VPN firewall Zone. Only PROTECT
policies can output traffic from the VPN Zone. PROTECT policies are defined in the IAS Router by
defining VPN rules on the IPSec page.
When the IAS Router is in the CSfC mode, as described in Section 4.1, the options for generating VPN
policies are restricted to only those values that are allowed under the IAS Router’s Common Criteria
validation. It is possible to configure the IAS Router to perform in a Common Criteria compliant manner
without utilizing the CSfC mode, but additional care must be taken when configuring the router as the
configuration defaults and configuration enforcement rules will allow the device to operate outside the
acceptable Common Criteria settings. Consult section 4.1 for more detail on the algorithms permitted in
CSfC mode.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
In accordance with Common Criteria requirements, IPSec protection is required for otherwise
unprotected traffic. In the case of the IAS Router, IPSec must be configured to provide protection for
Figure 11: System Services Dialog
the NTP client and syslog features when they are used. NTP is sent/received on UDP port 123 and syslog
traffic is sent to TCP port 514 but is configurable. Alternatively, both NTP client and syslog can be
disabled using their respective configuration locations. Syslog can be disabled through the System
Services Dialog, shown in Figure 11. Setting “syslog-ng” to “Disabled” will disable the Syslog client
entirely. Disabling the NTP client can be done via the System Time dialog, seen in Figure 20.
4.3.2.2 PROTECT Policy Configuration
The IPSec VPN page allows the user to create a new VPN definition. The VPN definition form includes
fields allowing the user to select IKEv1 or IKEv2. The VPN form also allows for the selection of the
desired Phase 1/IKE SA and Phase 2/CHILD SA encryption methods. The VPN form allows the selection
of SA lifetimes, by default they are set to 24 hours for Phase 1/IKE and 8 hours for Phase 2/CHILD SAs.
The VPN configuration form allows the user to define how the VPN will be authenticated by either a PSK
or the specified certificate.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Figure 12: VPN Creation Form
Each item shown in the form figure above is detailed below in Table 3.
Table 3: IPSec VPN Form Detail
Configuration
Item
VPN Name
Status
IKE Version
Transforms
IKE Lifetime
ESP Lifetime
Description
Administrative tunnel name. This
configuration item is relevant only
locally and the endpoints need not
agree on its value.
Administratively disable the tunnel
configuration
The version of IKE used for this VPN.
The use of IKEv1 aggressive mode is
not recommended, but is required for
interoperability in certain applications.
The cryptographic algorithms that are
used for this VPN. Multiple values can
be selected for each drop down.
These values must match or overlap
those values configured on the other
VPN endpoint.
IKE Lifetime is the maximum amount
of time that an IKE SA is permitted to
pass traffic prior to key renegotiation.
ESP Lifetime is the maximum amount
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Range
Default
Required
Yes
Enabled or
Disabled
See Table 1
Enabled
IKEv2
See Table 1
Yes
Yes
1-24 hours
3 hour
Yes
1-8 hours
1 hours
Yes
Configuration
Item
ESP Packet
Limit
Local Entry
Point IP
Local ID
Local Traffic
Selector
Remote Entry
Point IP
Remote ID
Description
of time that an IKEv1 Phase 2 or IKEv2
CHILD_SA is permitted to pass traffic
prior to key renegotiation.
ESP Packet Limit is the maximum
number of packets that an IKEv1 Phase
2 or IKEv2 CHILD_SA is permitted to
pass prior to key renegotiation.
The IP Address of this router that is
used to participate in IPSec processing.
The default value (%any) is a wildcard
value that refers to all currently
configured networks on the router.
The identifying string to be used during
IKE authentication. This value
corresponds to the “group name”
when used with Cisco EZVPN
concentrators. When used with
certificate authentication this value
automatically defaults to the Subject
Name of the certificate.
This traffic selector specifies the traffic
(group of IP addresses, protocols, and
ports) that are to be protected by the
VPN. The Local selector identifies the
source fields of outbound traffic or the
destination fields of inbound traffic.
This value automatically populates as
the entire LAN subnet.
The IP Address of the remote router.
This should be the public network
routable address of the IPSec
concentrator or entry point.
This value is typically left blank for PSK
VPNs.
For Certificate VPNs this value is
compared to the remote end point’s
certificate subjectName field (AKA
Subject). This field supports *
wildcards for each subject subfield or
for the entire field. For example:
“CN=*, C=US, ST=*, O=IAS,
OU=IAS_Test_Bed” or to allow all just
use “*”. Alternatively, the field is also
compared with any subjectAltName
values of the remote, subjectAltName
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Range
Default
Required
%any
Yes
Number greater
than 1
IP or %any
Yes
IP, FQDN, or %any
Yes
Configuration
Item
Remote Traffic
Selector
Start
Connection
Dead Peer
Detection
Authentication
By
XAUTH
XAUTH
Username
4.3.3
Description
values typically contain email
addresses, FQDNs, or IP addresses. For
example “vpn.iaspecialists.com”
This traffic selector specifies the traffic
(group of IP addresses, protocols, and
ports) that is to be protected by the
VPN. The Remote selector identifies
the source fields of inbound traffic or
the destination fields of outbound
traffic.
This item selects when the VPN should
be initiated. For most cases Traffic is
best option. This configuration item is
relevant only locally and the endpoints
need not agree on its value.
This item configures how the router
should monitor the VPN for failure and
what the router should do in the event
of a failure. For most initiator cases
Retry on Traffic is the best option. For
most head-end cases Clear is the best
option. The interval value is the
frequency with which the VPN is
tested. This configuration item is
relevant only locally and the endpoints
need not agree on its value.
Select the authentication mode. PSK
and certificates are supported. If
certificate is selected, then the
certificate must be specified/uploaded.
If IKEv1 is selected then this option
appears. Selecting this option enables
XAUTH authentication.
If IKEv1 is selected then this option
appears. The XAUTH username to use
when authenticating with an entry
point.
Protecting Syslog Audit Traffic
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Range
Default
Required
Yes
Traffic, Manual,
Boot
Boot
Yes
Disable, Enable –
Retry on Traffic,
enable, Clear,
Enable – Retry on
Fail
Disable
Yes
PSK, Certificate
Enabled or
Disabled
Yes
Disabled
Syslog audit records sent to a remote server must be protected via an IPsec VPN. Ensure that the VPN
configuration’s Local Traffic Selector includes the IP address of the syslog server endpoint, and includes
the port number the syslog server and client run on (defaults to port 514). Figure 13 shows the System
Figure 13: Syslog Destination Configuration Dialog
Configuration dialog for setting the Syslog server endpoint.
4.4 TLS
There are no operator configurable TLS options. The IAS Router supports only those ciphersuites
permitted by Common Criteria requirements.
4.5 Cryptographic Operations
4.5.1 Certificate Generation and Loading
When certificates are used to authenticate with a VPN peer the contents of the certificate dictate the
method of authentication used. In order to validate a peer with RSA or ECDSA signatures both the local
and the peer router’s certificates must have been correctly generated with the appropriate strength and
type of credentials.
Complete Certificate Authority configuration and use is outside the scope of this document and is
dependent on the Certificate Authority product chosen. However, there are pieces of the certificate
generation process that are performed on the IAS Router and they are outlined below.
Prior to certificate generation an IAS Router must generate a private key and a Certificate Signing
Request. The Private Key dictates the method of authentication used with the certificate and must be
chosen to match the desired authentication method/strength. Private Key generation is performed
using the Generate Private Key button on the VPN page.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Figure 14: Private Key Generation
Once a Private Key has been generated then the IAS Router can begin the certificate enrollment process
with a Certificate Authority by creating a Certificate Signing Request. This is performed using the
Generate CSR button on the VPN page. On the Generate CSR form the fields must be completed in
accordance with guidance from the Certificate Authority and the desired Private Key and signature hash
algorithm must be selected.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Figure 15: CSR Generation Form
Once the CSR is generated within the IAS Router it is downloaded for out-of-band delivery to the
Certificate Authority (CA). The CA will enroll the request and return a certificate for the device to use for
VPN authentication as well as any certificates required to validate the authenticity of the certificate.
The returned certificate(s) are loaded into the IAS Router using the Upload Certificate button on the VPN
page. This button is used to load both the device certificate as well as any Certificate Authority
certificates and any other intermediate CA certificates.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Figure 16: Upload Certificate Dialog
4.5.2 Certificate Validation
Certificates can optionally specify a Certificate Revocation List (CRL) server or Online Certificate Status
Protocol (OCSP) server URI to be used in certificate validation checking. If a certificate provided for
validation includes a CRL or OCSP server URI then the IAS Router attempts to contact the server to check
the revocation status of the certificate. CRL URIs are provided by specifying a “CRL Distribution Points”
extension on the X509 certificate (RFC3280). Similarly, an OCSP server URI can be specified by adding an
“AuthorityInfoAccess” extension.
The IAS Router has a certificate validation strictness setting. The setting is on the VPN page and is called
Certificate Validation.
Figure 17: VPN Certificate Validation Strictness
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
If the revocation status URL is specified in a certificate and the Certificate Validation setting is set to YES
then the IAS Router will consider the certificate to be revoked if the revocation status URL is
unreachable. If the validation setting is set to NO and the revocation status URL is unreachable then the
IAS Router will not consider the certificate status to be revoked.
In all cases the revocation status mechanism must be IPSec protected, as per Common Criteria
requirements. This is accomplished by generating a VPN policy to protect the CRL or OCSP traffic.
The exact parameters required to create a protecting VPN are dependent upon the configuration of the
CA and its fronting VPN gateway. However, if the Certificate Validation setting is desired to be set to YES
then a separate certificate chain will be required to authenticate the CRL/OCSP VPN that does NOT
enforce certificate status checking. This is a chicken-or-the-egg scenario where the CRL or OCSP server
must be reachable to check VPN certificate revocation status, but the revocation server must first be
reachable over a VPN.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
5 Security Functions
This section describe the security functions that were evaluated against the NDPP and VPNEP, but were
not discussed in Section 4.
5.1 Security Audit
The IAS Router stores at least 4 MB of audit log data locally. The audit logs are immediately forwarded
to the Syslog server, if one is configured. In the event that the Syslog server is unavailable, the IAS
Router caches a maximum of 256 messages. Once the message delivery cache is full then any additional
messages will be dropped.
5.2 Key Generation
The IAS Router automatically generates ECDH and DH keys used for key establishment when IKE
connections are initiated by the server or by a remote device.
Private Key and CSR generation is explained above in Section 4.5.1.
Pre-shared key input by the user must meet the same complexity and minimum length requirements
enforced against user passwords, see Section 4.1. Their selection should also follow the guidance given
in that section for password complexity, that is: minimum of fifteen characters, use at least one capital
letter, one lower case letter, one number, and one symbol of the set !@#$%^&*() additionally all preshared keys should avoid the use of dictionary words. PSK input is performed on the VPN page using the
Add PSK button/form.
Figure 18: Add PSK Form
In addition to text based keys the IAS Router also supports the input of bit-based keys. Bit-based keys
can be entered by changing the “PSK Type” field to either Hexadecimal or Base64. In Hexadecimal
mode, omit any starting “0x” prefix, simply enter plain hexadecimal digits (0-9, a-f).
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
5.3 Administration
5.3.1 Administration Authentication Rules
User authentication is configurable via the System->System Authentication Settings form. From here
the user can modify the successive unsuccessful authentication attempts, which is called “Permitted
failed authentication attempts before lockout.” Additionally the lockout time is configurable via the
“Lockout time in minutes” item. The same authentication attempt restrictions are placed against both
the web page and the console login mechanisms.
5.3.2 Administration Access Control
The IAS Router supports a granular user access control capability. Each user is individually configurable
to be able to configure, view only, or have no access to each button or actionable table within the web
management interface. This level of detail can be seen below in Figure 16.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Figure 19: User Permission Settings
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
5.4 Time
Time is manually configurable from the IAS Router Status page. If the router’s time is different from the
system time of the management terminal by more than 25 hours then the Set System Time button
flashes to help notify the administrator that the time setting requires attention. The Set System Time
button opens the Set System Time dialog window and allows the user to manually manipulate the time
or to configure the router’s NTP settings. The Set System Time dialog window is also reachable from the
System page.
The IAS Router can act as either an NTP client or as an NTP server. Each feature is individually
configurable and they both operate using industry standard UDP port 123. The only Protection Profile
evaluated configuration is for the router to act as an NTP client. Using the NTP server functionality is
not Protection Profile compliant.
There is no applied or inherent security in NTP communications. If security for NTP traffic is desired
then the administrator must manually setup IPSec VPN(s) to protect NTP traffic flows.
Figure 20: System Time on the Status Page
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Figure 21: Set System Time Dialog
5.5 Firmware Updates
The IAS Router supports processing trusted firmware updates. Firmware updates may be acquired
directly from IAS via product support channels. Firmware images for the IAS Router include a digital
signature that is automatically validated prior to applying the firmware. To validate the digital signature
the operator must execute the firmware upgrade process via the System page. Within that process the
upgrade is confirmed as an authorized release from IAS via a certificate packaged in the router software.
Executing the firmware upgrade process requires the user to select the firmware file for use/uploading
via the browser. Once selected the firmware image is uploaded and the validation process begins. If the
signature validation fails then the update is not be applied, a “Firmware Validation Error” error is
presented to the user on the webpage (see below), and an audit log entry is generated (see Appendix A
for details). If the signature is validated and the upgrade is processed the user is presented with a
please wait dialog/timer (see below), an audit log entry is generated (see Appendix A for details), and
the router automatically reboots upon completion.
Figure 22: Firmware Validation Error
Figure 23: Firmware Validation Success
5.6 Welcome Banner
The system Welcome Banner can be modified from the System Settings page. Click the System tab from
the main menu on the left hand side of the page, then click the Edit button next to "Welcome Banner
Text". Enter the desired text into the dialog box that appears. Once complete, click the Save button.
The figures below illustrate this process.
The Welcome Banner will appear on the Login page of the web interface, and also when connecting to
the serial console.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
Figure 24: Welcome Banner Text Edit Button
Figure 25: Welcome Banner Edit Dialog
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
6 Troubleshooting
It is possible to misconfigure the IAS Router in such a way that the administrator no longer has access to
the management web page. In this scenario the user should ensure the IAS Router is powered on and
fully booted. The administrator should wait for 4 minutes to ensure the device is fully booted. Then the
administrator should press the front panel Reset to Defaults button and hold it for at least 13 seconds.
Upon releasing the button the IAS Router will restore the factory configuration and reboot.
In addition to the Reset to Defaults button, the serial console CLI provides visibility to the system logs
and the ability to perform the Reset to Defaults operation. The CLI is reachable with a standard blue
RJ45 console cable and a terminal emulator running 9600 baud, 8 data bits, no parity, 1 stop bit, and no
flow control. The administrator must login with valid credentials to access the CLI.
If the IAS Router fails in such a way that the device cannot successfully perform the power on self-test
suite then the unit will reboot. It is possible for the error to clear on its own, however if the error does
not or cannot self-clear then the IAS Router will continually reboot as can be observed by watching the
status indicator which flashes 1-second on 1-second off during power on self-tests.
The bypass self-test is performed whenever the IAS Router network/firewall configuration is modified.
If the configuration has been modified in an unauthorized manner then the self-test will fail. When this
happens the IAS Router is inhibited from forwarding traffic. As an example, this means that traffic can
flow on the LAN between the management workstation/browser and the IAS Router, but not from the
LAN to the IPSec VPN or to the WAN. In order to clear the error condition the user must click the “clear”
button on the bypass error indication window. If the window is inadvertently closed or does not initially
display then the user can navigate to the firewall page, open any configuration dialog and click the save
button. This forces the bypass rule test to re-execute and the indication window will appear if an error
is found. NOTE: It is common operating procedure for the firewall bypass error indication dialog to
appear the first time the network or firewall is modified after a reset to defaults or software upgrade is
performed.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
7 Appendix A: Audit Records
•
Startup of the audit function.
o Example: Mar 13 08:58:41 IASRouter syslog-ng[1631]: syslog-ng starting
up; version='3.0.5'
Format: [DATE] [HOSTNAME] syslog-ng[PID]: syslog-ng starting up; version=’3.0.5’
Shutdown of the audit function.
o There is no nominal shutdown procedure for the audit log function.
Success and failure for each command used (or attempted to be used) to configure the IAS
Router. This includes all commands in Section 4 and Section 5. Each of these audit records must
include the username of the administrator running the command. Including setting the time.
o Example: Mar 13 09:13:27 IASRouter GUI: [email protected],
o
•
•
action=self_test, target=bypass.checksum.CHECKSUM_MATCH
o
o
Format: [DATE] [HOSTNAME] [PROCESS]: user=[user identifier], action=[ACTION],
target=[SECTION].[SUBSECTION].[NAME]
Operator actions can have the following ACTION, SECTION, SUBSECTION, NAME
combinations
Table 4: Administrative Action Audit Log Format
SECTION
backup
Bypass
Bypass
Bypass
CLI
CLI
CLI
CLI
Dhcp
Dhcp
firewall
firewall
firewall
firewall
firewall
firewall
firewall
firewall
GUI
SUBSECTION
NAME
checksum
checksum
checksum
success
failed
timeout
User_action
[network name]
[network name]
defaults
rule
zone
rule
[object type]
redirect
forwarding
redirect
success
[result]
Checksum updated
Bypass reset
[user]@console
console
20 LOGIN
GUI
failed
21 LOGOUT
22 LOGOUT
23 RESTART
GUI
GUI
IPSEC
timeout
User_action
VPN
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
ACTION
system
self_test
self_test
self_test
LOGIN
LOGIN
LOGOUT
LOGOUT
MODIFY
DELETE
MODIFY
MODIFY
MODIFY
MODIFY
DELETE
MODIFY
MODIFY
MODIFY
LOGIN
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
dhcp_pool
dhcp_pool
Global_rules
[rule number]
[zone name]
Reorder list
[object number]
Reorder list
[forwarding number]
[redirect number]
[user]@[IP
ADDRESS]
[user]@[IP
ADDRESS]
SERVICE
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
ACTION
MODIFY
RESET_LOGOUT_TIMER
MODIFY
MODIFY
MODIFY
NEW
EDIT
NEW
EDIT
DELETE
DELETE
system
MODIFY
MODIFY
MODIFY
MODIFY
FACTORY_RESET
SECTION
Kernel
Logout
multiwan
multiwan
network
network
network
network
network
network
network
restore
system
system
system
System time settings
System_manager
41 MODIFY
System_manager
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
update
update
usb_modem
usb_modem
usb_modem
usb_modem
usb_modem
users
users
users
vpn
vpn
vpn
vpn
vpn
vpn
vpn
vpn
vpn
vpn
VPN IPSec
wireless
wireless
wireless
wireless
firmware
firmware
MODIFY
ADD
DELETE
MODIFY
MODIFY
NEW
EDIT
DELETE
MODIFY
DELETE
MODIFY
generate
generate
upload
upload
Save
Save
DELETE - SHRED
MODIFY
WIFI_SITE_SURVEY
MODIFY
MODIFY
DELETE
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
SUBSECTION
Firewall forwarding
timer
interface
order
route
gre_interface
gre_interface
Interface
interface
route
interface
NAME
released
User
[network name]
syslog
Access banner
Auto_logout_time
[Old time]
Mode of operation change
to
System Authentication
settings
applying
signature
Selected APN
interface
interface
auto_config
[device name]
user
user
user
Strict_crl_policy
tunnel
tunnel
Private key
csr
certificate
Private key
psk
xauth
credential
[operation]
scan0
Radio[number]
Wifi-iface_[index]
Wifi_iface_[index]
[destination]
[route name]
[interface name]
[interface name]
[interface name]
[interface name]
[name]
[name]
[New time]
[mode]
[valid/invalid]
APN
[interface name]
[interface name]
[on/off]
[interface name]
[user name]
[user name]
[user name]
[value]
[vpn name]
[vpn name]
[private key name]
[file name]
[file name]
[file name]
[file name]
[name]
[vpn name]
WLAN0
[on/off]
[on/off]
67
68
69
70
71
72
ACTION
SECTION
SUBSECTION
NAME
MODIFY
wireless
Wifi_iface_[index]
AP
MODIFY
wireless
Wifi_iface_[index]
STA
SAVE
XAUTH
CREDENTIAL
MODIFY
network
routing
pim
MODIFY
network
routing
ospf
STATUS
interface
dropped_packets
[interface name]
•
Failure to establish an IPsec SA. Username associated with the connection.
o Example:
Mar 13 11:21:30 IASRouter IPSec:
test[1] to 50.78.156.51
Mar 13 11:21:34 IASRouter IPSec:
with message ID 0
Mar 13 11:21:42 IASRouter IPSec:
with message ID 0
Mar 13 11:21:54 IASRouter IPSec:
with message ID 0
Mar 13 11:22:18 IASRouter IPSec:
with message ID 0
Mar 13 11:23:00 IASRouter IPSec:
with message ID 0
Mar 13 11:24:15 IASRouter IPSec:
retransmits
Mar 13 11:24:15 IASRouter IPSec:
failed, peer not responding
o
Example:
06[IKE] <test|1> initiating IKE_SA
03[IKE] <test|1> retransmit 1 of request
10[IKE] <test|1> retransmit 2 of request
07[IKE] <test|1> retransmit 3 of request
16[IKE] <test|1> retransmit 4 of request
05[IKE] <test|1> retransmit 5 of request
02[IKE] <test|1> giving up after 5
02[IKE] <test|1> establishing IKE_SA
Mar 13 11:33:35 IASRouter IPSec: 08[IKE]
test[2] to 50.78.156.51
Mar 13 11:33:35 IASRouter IPSec: 04[IKE]
NAT, sending keep alives
Mar 13 11:33:35 IASRouter IPSec: 04[IKE]
requests for an unknown ca
Mar 13 11:33:35 IASRouter IPSec: 04[IKE]
'192.168.2.205' (myself) with pre-shared
Mar 13 11:33:35 IASRouter IPSec: 04[IKE]
test
Mar 13 11:33:36 IASRouter IPSec: 06[IKE]
AUTHENTICATION_FAILED notify error
o
<test|2> initiating IKE_SA
<test|2> local host is behind
<test|2> received 1 cert
<test|2> authentication of
key
<test|2> establishing CHILD_SA
<test|2> received
Example:
Mar 13 11:40:35 IASRouter IPSec: 13[IKE] <test|8> initiating IKE_SA
test[8] to 50.78.156.51
Mar 13 11:40:35 IASRouter IPSec: 09[IKE] <test|8> received
NO_PROPOSAL_CHOSEN notify error
o
Status Message format:
[DATE] [HOSTNAME] [PROCESS]: [IKE_ INSTANCE][IKE] <[VPN_NAME]|[VPN_NAME_
INSTANCE]> [status message content]
o
Initialization Message format:
[DATE] [HOSTNAME] [PROCESS]: [IKE_ INSTANCE][IKE] <[VPN_NAME]|[VPN_NAME_
INSTANCE]> initiating IKE_SA [VPN_NAME][[VPN_NAME_ INSTANCE]] to
[REMOTE_IP]
•
Establishment of an IPsec SA with a Peer.
o Example:
Mar 13 11:29:34 IASRouter IPSec:
test[1] to 50.78.156.51
Mar 13 11:29:34 IASRouter IPSec:
NAT, sending keep alives
Mar 13 11:29:34 IASRouter IPSec:
requests for an unknown ca
Mar 13 11:29:34 IASRouter IPSec:
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
08[IKE] <test|1> initiating IKE_SA
04[IKE] <test|1> local host is behind
04[IKE] <test|1> received 1 cert
04[IKE] <test|1> authentication of
'192.168.2.205' (myself) with pre-shared key
Mar 13 11:29:34 IASRouter IPSec: 04[IKE] <test|1> establishing CHILD_SA
test
Mar 13 11:29:34 IASRouter IPSec: 09[IKE] <test|1> authentication of
'50.78.156.51' with pre-shared key successful
Mar 13 11:29:34 IASRouter IPSec: 09[IKE] <test|1> IKE_SA test[1]
established between
192.168.2.205[192.168.2.205]...50.78.156.51[50.78.156.51]
Mar 13 11:29:34 IASRouter IPSec: 09[IKE] <test|1> scheduling
reauthentication in 10170s
Mar 13 11:29:34 IASRouter IPSec: 09[IKE] <test|1> maximum IKE_SA lifetime
10710s
Mar 13 11:29:34 IASRouter IPSec: 09[IKE] <test|1> CHILD_SA test{1}
established with SPIs b1e64b7f_i ca2100fe_o and TS 192.168.1.0/24 ===
192.168.102.0/24
o
Initialization format:
[DATE] [HOSTNAME] [PROCESS]: [IKE_ INSTANCE][IKE] <[VPN_NAME]|[VPN_NAME_
INSTANCE]> [status message content]
o
Status messages format:
[DATE] [HOSTNAME] [PROCESS]: [IKE_ INSTANCE][IKE] <[VPN_NAME]|[VPN_NAME_
INSTANCE]> initiating IKE_SA [VPN_NAME][[VPN_NAME_INDEX]] to [REMOTE_IP]
o
IKE_SA Establishment Format:
[DATE] [HOSTNAME] [PROCESS]: [IKE_ INSTANCE][IKE] <[VPN_NAME]|[VPN_NAME_
INSTANCE]> IKE_SA [VPN_NAME]{[VPN_NAME_INDEX]} established between
[LOCAL_IP][[LOCAL_ID]]…[REMOTE_IP][[REMOTE_ID]]
o
CHILD_SA Establishment Format:
[DATE] [HOSTNAME] [PROCESS]: [IKE_ INSTANCE][IKE] <[VPN_NAME]|[VPN_NAME_
INSTANCE]> CHILD_SA [VPN_NAME]{[VPN_NAME_ INSTANCE]} established with
SPIs [SPI VALIES] and TS [LOCAL TS] === [REMOTE_TS]
•
Termination of an IPsec SA with a Peer. Username associated with the connection. Source and
destination IP addresses and source and destination ports. IAS Router Interface.
o Locally initiated termination of establishing SA example:
Mar 13 11:15:57 IASRouter IPSec: 00[IKE] <test|1> destroying IKE_SA in
state CONNECTING without notification
o
Locally initiated termination of establishing SA message format:
[DATE] [HOSTNAME] IPSec: [IKE_ INSTANCE][IKE]
<[VPN_NAME]|[VPN_NAME_INSTANCE]> destroying IKE_SA in state [state]
[termination action]
o
Locally initiated termination of established SA example:
Mar 13 11:29:31 IASRouter IPSec: 00[IKE] <test|2> deleting IKE_SA test[2]
between 192.168.2.205[192.168.2.205]...50.78.156.51[50.78.156.51]
o
Locally initiated termination of established SA format:
[DATE] [HOSTNAME] IPSec: [IKE_ INSTANCE][IKE]
<[VPN_NAME]|[VPN_NAME_INSTANCE]> deleting IKE_SA [VPN_NAME][[IKE_SA
INSTANCE]] between
[LOCAL_IP][[LOCAL_IDENTITY]]…[PEER_IP][[PEER_IDENTITY]]
o
Remotely initiated termination of established SA example:
Mar 13 11:40:13 IASRouter IPSec: 09[IKE] <test|7> received DELETE for
IKE_SA test[7]
Mar 13 11:40:13 IASRouter IPSec: 09[IKE] <test|7> deleting IKE_SA test[7]
between 192.168.2.205[192.168.2.205]...50.78.156.51[50.78.156.51]
o
Remotely initiated termination of established SA format:
[DATE] [HOSTNAME] IPSec: [IKE_ INSTANCE][IKE]
<[VPN_NAME]|[VPN_NAME_INSTANCE]> received DELETE for IKE_SA
[VPN_NAME][[IKE_SA INSTANCE]]
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
o
Remotely initiated termination of established SA format:
[DATE] [HOSTNAME] IPSec: [IKE_ INSTANCE][IKE]
<[VPN_NAME]|[VPN_NAME_INSTANCE]> deleting IKE_SA [VPN_NAME][[IKE_SA
INSTANCE]] between
[LOCAL_IP][[LOCAL_IDENTITY]]…[PEER_IP][[PEER_IDENTITY]]
•
•
Failure/termination of an established IPsec SA due to an error. IP address of the non-IAS Router
endpoint. Reason for the failure in a human readable format (i.e. not an error code).
o “Error” terminations look the same as user induced terminations.
Application of ‘log’ packet filter rules, including the source and destination IP addresses, source
and destination ports, transport layer protocol, IAS Router interface.
o Example:
Mar 13 12:02:07 IASRouter firewall: [11023.355722] FIREWALL_LOG:IN=br-lan
OUT=ipsec0 MAC=00:30:18:c3:86:c5:00:23:55:6c:48:70:08:00
SRC=192.168.1.238 DST=192.168.102.102 LEN=60 TOS=0x00 PREC=0x00 TTL=127
ID=975 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16
o
Example:
Mar 13 12:13:08 IASRouter firewall: [11685.086809] FIREWALL_LOG:IN=br-lan
OUT=ipsec0 MAC=00:30:18:c3:86:c5:00:23:55:6c:48:70:08:00
SRC=192.168.1.238 DST=192.168.102.102 LEN=52 TOS=0x00 PREC=0x00 TTL=127
ID=2588 DF PROTO=TCP SPT=57833 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
o
Format:
[DATE] [HOSTNAME] firewall: [[uptime stamp]] FIREWALL_LOG: IN=[input
interface] OUT=[output interface] MAC=[MAC frame (SRC, DST, Type)]
SRC=[source IP address] DST=[destination IP address] LEN=[IP packet
length] TOS=[type of service “type” field] PREC=[type of service
“precedence” field] TTL=[time to live value] ID=[unique id]
PROTO=[protocol name or number] [additional packet details, protocol
specific, see for more detail]
Application of ‘ULOG’ packet filter rules.
o Example:
Sep 20 22:43:05 IASRouter FIREWALL_ULOG:
ICMP echo reply, id 28857, seq 4, length 64
Sep 20 22:43:43 IASRouter FIREWALL_ULOG:
0000 4001 36bf c0a8 0301 [email protected].....
Sep 20 22:43:43 IASRouter FIREWALL_ULOG:
041c 70b9 0004 b96e ff55 ........p....n.U
Sep 20 22:43:43 IASRouter FIREWALL_ULOG:
0700 0000 0000 cdef abcd .....+..........
Sep 20 22:43:43 IASRouter FIREWALL_ULOG:
efab cdef abcd efab cdef ................
Sep 20 22:43:43 IASRouter FIREWALL_ULOG:
abcd efab cdef abcd efab ................
Sep 20 22:43:43 IASRouter FIREWALL_ULOG:
....
o
192.168.3.1 > 192.168.3.10:
0x0000:
4500 0054 bc8e
0x0010:
c0a8 030a 0000
0x0020:
0000 0000 d92b
0x0030:
efab cdef abcd
0x0040:
abcd efab cdef
0x0050:
cdef abcd
Format:
[DATE] [HOSTNAME] FIREWALL_ULOG: [SRC IP] > [DST IP]: [Packet details]
[DATE] [HOSTNAME] FIREWALL_ULOG: [tab][hexdump of packet contents]
Note that when using syslog, depending on the receiver (notably including rsyslog) and
its settings, the [tab] control character at the start of the hexdump may be rendered by
the receiver as its octal encoding, “#011”, i.e., the output format will be:
[DATE] [HOSTNAME] FIREWALL_ULOG: [SRC IP] > [DST IP]: [Packet details]
[DATE] [HOSTNAME] FIREWALL_ULOG: #011[hexdump of packet contents]
•
Changes to the time caused by the NTP server.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
o
Example:
Nov 22 12:11:00 IASRouter GUI [email protected], action=MODIFY,
target=System time settings.OLD=11/22/2015 08:09 .NEW=11/22/2015 12:11
o
Format:
[DATE] [HOSTNAME] ntpd[[PID]] action=MODIFY, target=System time
settings.OLD=[DATE] .NEW=[DATE]
•
Establishing session with CA to validate certificate
o Example:
May 5 15:13:51 IASRouter IPSec: 01[CFG] <test|1>
'http://192.168.2.44/home/Downloads/crl.pem' ...
o
fetching crl from
Format:
[DATE] [HOSTNAME] IPSec: [IKE_ INSTANCE][CFG]
<[VPN_NAME]|[VPN_NAME_INSTANCE]> fetching crl from ‘[CRL_or_OCSP_URI]’
...
NOTE: If more detail is desired, such as source interface, address, and port then firewall LOG/ULOG rules
must be generated to trigger on the interesting traffic. In order to create a firewall LOG rule that
captures traffic from the management plane the rule must have source zone = ANY and destination zone
= ANY. Depending on the additional detail of interest, the protocol and ports can be curtailed to limit
the number of audit events. See Section 4.2.2.1 for more details.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.
8 Appendix B: Processes
Processes that process network traffic.
Process
kernel
HW Privilege
Ring 0
SW Privilege
root
syslog-ng
Ring 3
root
odhcpd
Ring 3
root
lighttpd
Ring 3
root
charon
Ring 3
root
ntpd
Ring 3
root
dnsmasq
Ring 3
root
pimd
Ring 3
root
quagga
Ring 3
opennhrp Ring 3
root
root
Description
Provides the IP network stack. Includes Ethernet, IP, TCP, UDP,
ARP, GRE
Generates logging messages and sends them to the configured
server
DHCP server provides DHCP addresses to network clients as
configured
Web server operating on port 443 with TLS serves the
management web page
IPsec process: perform/process IKE protocol and IPSec SA
establishment
Serves and retrieves time as configured using standard UDP
port 123
DNS redirection daemon provides name resolution for network
clients
PIMv2 routing daemon implementing the PIMv2 routing
protocol management
OSPF routing daemon implementing the OSPF routing protocol
NHRP routing daemon implementing the NHRP routing
protocol
8.1 Privileges
root – the root software privilege has access rights to the entire system.
Ring 0 – The most privileged level of an x86 processor. Reserved for the kernel.
Ring 3 – The least privileged level of an x86 processor. Generally defined for use by applications.
Version 1.0.8, December 21, 2015
©2015 Information Assurance Specialists, Inc.