Analyze Appliance Monitoring Output

Blue Team

OBJECTIVES COVERED

Given a scenario, analyze data as part of security monitoring activities.

Given a scenario, implement configuration changes to existing controls to improve security.

A large amount of security information derives from network security appliances, such as firewalls and intrusion detection systems. As an analyst, you should be able to extract and interpret the data found in these log files.


FIREWALL LOG REVIEW

Firewalls provide a line of defense at the network’s borders to limit the types of traffic that are permitted to pass in and out of the network based on rules defined in an access control list (ACL). Because firewalls provide such an important line of defense where a network may be most vulnerable, firewall logs can provide a wide range of useful security intelligence, such as:

  • Connections permitted or denied—Patterns within log data can help you identify holes in your security policies. A sudden increase in rates resulting in denied traffic can reveal when attacks were committed against your firewall.
  • Port and protocol usage—Log protocols and port numbers that are used for each connection, which you can analyze statistically for patterns or anomalies.
  • Bandwidth usage—Log each connection with its duration and traffic volume usage, which you can break down by connection, user, department, and other factors.
  • Address translation audit trail—Log network address translation (NAT) or port address translation (PAT) to provide useful forensic data, which can help you trace the IP address of an internal user that was conducting attacks on the outside world from inside your network. PAT forwards requests for services on the external IP address and port on the firewall to an address and port of a server behind the firewall.

Firewall log formats are usually vendor specific. Some can only be displayed through the local console. The Linux iptables firewall configuration utility uses the syslog format. Each log entry is prefixed with a timestamp, a device ID or host name, and a facility (usually kernel). Each log rule can have a –log-prefix value set, which provides a means of matching the log entry to the rule that triggered it, and a –log‑level value, which categorizes the rule severity using syslog-based values from 0 (panic) to 7 (debug). Following these header fields, the log message includes information in attribute=value pairs, delimited by commas. These values record firewall host interfaces involved, source and destination MAC and IP addresses, source and destination port numbers, plus other information from the IP and TCP packet headers. For example, the following two log entries record traffic attempting to connect to port 23 (Telnet) and port 21 (FTP) that has been dropped:

Jan 11 05:52:56 lx1 kernel: iptables INPUT drop IN=eth0 OUT= MAC=00:15:5d:01:ca:55:00:15:5d:01:ca:ad:08:00 SRC=10.1.0.102 DST=10.1.0.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=3988 DF PROTO=TCP SPT=2583 DPT=23 WINDOW=64240 RES=0x00 SYN URGP=0

Jan 11 05:53:09 lx1 kernel: iptables INPUT drop IN=eth0 OUT= MAC=00:15:5d:01:ca:55:00:15:5d:01:ca:ad:08:00 SRC=10.1.0.102 DST=10.1.0.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=4005 DF PROTO=TCP SPT=2584 DPT=21 WINDOW=64240 RES=0x00 SYN URGP=0

By contrast, Windows Firewall logs in the W3C Extended Log File Format. This is self-describing, with a comment at the top of the log listing the fields used. Each log entry contains the values for those fields, in a space delimited format.

Because firewalls collect a large volume of data and do not usually have a lot of local disk space, you should employ a log collection tool to ensure that data is not lost, as logs roll over or are cleared within the firewall. The scope of logging will be driven by how fast the logging system can process the number of events generated. A given system will be able to log so many events per second before becoming overwhelmed. This makes an under-resourced logging system susceptible to “blinding” attacks, where the adversary generates more traffic than the system can handle then initiates the real intrusion, hoping that only an incomplete record will be made of it in the log. Log retention will also be driven by number of events generated and available storage capacity. Long-term retention is important where a network has been successfully attacked some time in the past and the security team needs to identify how the attack was perpetrated.

** There is a large market for firewall and unified threat management (UTM) security appliances and software. Sites such as Gartner (gartner.com/reviews/market/network-firewalls) produce regular reviews of the market leaders. The pfSense UTM (pfsense.org) is an open-source product that makes for a very good learning tool, as well as a capable enterprise security appliance in its own right. **


Squid web proxy cache server logs.
iptable logs
syslog logs

W3C logs === Windows Even Viewer

Level, Date/Time, Source, Task Category


FIREWALL CONFIGURATION CHANGES

Historically, network security focused on the perimeter, following the assumption that security would be protected if you could prevent adversaries from gaining access. Modern cybersecurity methods cannot focus exclusively on the perimeter, but it remains an important line of defense. Any internet-facing service should be protected by a firewall. The firewall should allow only traffic for authorized ports and hosts to enter and leave the network segment it protects. At the Internet edge, firewalls are often deployed in a demilitarized zone (DMZ) configuration, with an external firewall controlling the interface between the Internet zone and hosts within the DMZ segment, and an internal firewall controlling the interface between the LAN and the DMZ. Services such as web hosting, email transfer (SMTP), VoIP, and remote access/virtual private network (VPN) run on hosts within the DMZ.

Firewall Rulesets

The rules in a firewall’s access control list (ACL) are processed top-to-bottom. If traffic matches one of the rules then it is allowed to pass; consequently, the most important and specific rules are placed at the top. The final default rule is typically to block any traffic that has not matched a rule (implicit deny). Each rule can specify whether to block or allow traffic based on a number of parameters, often referred to as tuples. Some other basic principles include:

  • Block incoming requests from internal or private, loopback, and multicast IP address ranges as these have obviously been spoofed. These are referred to as Martians. Similarly, block source addresses from ranges that have been reserved by IANA or an RIR but not yet allocated, referred to as bogons. Bogons are identified through an intelligence feed (team-cymru.com/bogon-reference).
  • Block incoming requests from protocols that should only be functioning at a local network level, such as ICMP, DHCP, routing protocol traffic, Windows File Sharing/SMB, and so on.
  • Ensure that rules for IPv6 are configured, either to block all IPv6 traffic or to allow authorized hosts and ports. Many hosts run dual-stack TCP/IP implementations with IPv6 enabled by default. Misconfiguration of a router could allow adversaries unfiltered access to the network over IPv6.

Techniques such as threat hunting and penetration testing, as well as ongoing security monitoring and review of incidents, will reveal whether the firewall ruleset and logging configuration are working as intended. Changes need to be fully tested due to the potential for disrupting legitimate traffic.

Drop versus Reject

On most firewalls, a “deny” rule can be implemented either by dropping the packet or by explicitly rejecting it. Dropping the packet means that it is discarded without notifying the client. Rejecting the packet means that a response is sent to the client (either a TCP RST or an ICMP port or protocol unreachable for a UDP request). Dropping traffic makes it harder for an adversary to identify port states accurately but makes troubleshooting connections more difficult for legitimate users.

Egress Filtering

Historically, many organizations focused on ingress filtering rules, designed to prevent local network penetration from the Internet. In the current threat landscape, it is imperative to also apply strict egress filtering rules to prevent malware that has infected internal hosts by other means from communicating out to C&C servers. Egress filtering can be problematic in terms of interrupting authorized network activity, but it is an essential component of modern network defense. Some general guidelines for configuring egress filtering are:

  • Allow only whitelisted application ports and, if possible, restrict the destination addresses to authorized Internet hosts. Where authorized hosts cannot be identified, use URL and content filtering to try to detect malicious traffic over authorized protocols.
  • Restrict DNS lookups to your own or your ISP’s DNS services or authorized public resolvers, such as Google’s or Quad9’s DNS services.
  • Block access to “known bad” IP address ranges, as listed on don’t route or peer (DROP) filter lists.
  • Block access from any IP address space that is not authorized for use on your local network.
  • Block all Internet access from host subnets that do not need to connect to the Internet, such as most types of internal server, workstations used to manage industrial control systems (ICSs), and so on.

Even within these rules, there is a lot of scope for adversaries to perform command signaling and exfiltration. For example, cloud services, such as content delivery networks and social media platforms, can be used to communicate scripts and malware commands and to exfiltrate data over HTTPS (rhinosecuritylabs.com/aws/hiding-cloudcobalt-strike-beacon-c2-using-amazon-apis).

Firewalking

From a cyber adversary’s point-of-view, the firewall is a barrier to be bypassed. Firewalking is a means of determining a router or firewall’s ACL and mapping the internal network from the outside, or conversely discovering which outbound port and source address combinations are permitted. The attacker first discovers which ports are open on the perimeter firewall, then crafts a packet for the open port with a TTL of one past the firewall. If this packet is received by the host behind the firewall, it will respond with a “TTL exceeded” notification. Firewalking can be mitigated using network address translation (NAT) to prevent the attacker from identifying the address space behind the router and by blocking outgoing ICMP status messages.


BLACK HOLES AND SINKHOLES

To apply ACLs, routers and firewalls need to dedicate CPU and memory resources to processing the rules. If faced with a DDoS attack, this processing requirement makes it easier for the attacker to overload the security device. Other means of filtering malicious traffic have been developed to mitigate this.

Black Holes

In network architecture, a black hole drops traffic before it reaches its intended destination, and without alerting the source. A simple example is traffic that is sent to an IP address that has been mapped to a nonexistent host. Since the destination does not exist (the figurative black hole), the inbound traffic is discarded. A common and effective way to use black holes is by dropping packets at the routing layer to stop a DDoS attack. Using a Cisco router, for example, traffic can be sent to the null0 interface; this interface automatically drops all traffic. If you know the source address range(s) of a DDoS attack, you can silently drop that traffic by configuring the router to send the attacking range to null0.

Black hole routing may be more beneficial than other methods of traffic filtering because it tends to consume fewer router resources. Processing overhead for implementing firewall rules or DNS filtering is much higher, and when you’re trying to mitigate a DDoS attack, every bit of bandwidth helps. It’s extremely important, however, for you to recognize the high potential for collateral damage in routing entire IP ranges into black holes. The most successful DDoS attacks launch from disparate IP addresses—addresses that are in ranges shared with many legitimate users. Blocking an entire range to stop just a handful of sources may, ironically, end up denying your services even more.

Black holes can protect against an attacker using dark nets from within a local network. When looking for an entry point to a network, an attacker will often look for what the network is not using, such as unused physical network ports or unused IP address space. A basic security technique is to make these resources specifically unusable by directing them to a black hole.

Sinkholes

A sinkhole is similar to configuring a black hole, and the terms are often used interchangeably. With sinkholing however, you usually retain some ability to analyze and forward the captured traffic. Sinkhole routing can be used as a DDoS mitigation technique so that the traffic flooding an IP address is routed to a different network where it can be analyzed. Potentially, some legitimate traffic could be allowed through, but the real advantage is to identify the source of the attack and devise rules to filter it. The target can then use low TTL DNS records to change the IP address advertised for the service and try to allow legitimate traffic past the flood.

** There are cloud DDoS mitigation services, such as Cloudflare (cloudflare.com/learning/ddos/ddos-mitigation) that can act as sinkhole network providers and try to “scrub” flooded traffic. **

Black holes and sinkholes can be configured using routing policies, but you can also use DNS-based sinkholing to capture malicious traffic trying to exit from your network. For example, if a bot inside your network is attempting to contact its controller on the outside, and this malicious domain matches your filtering rules, you can set up your perimeter firewall to forge a DNS response to the bot that connects the domain to an IP address you specify. This is the sinkhole, as the malicious botnet traffic cannot escape to the outside world. You could drop any traffic to the IP address, creating a black hole, or direct it to a honeypot host so that the malware behavior can be analyzed.

A sinkhole may also be used to attract malicious traffic to a honeypot or honeynet for analysis. This allows an ISP or CTI provider to analyze attacks and trace their source, creating and updating blacklists to block compromised source IP addresses or ranges.


PROXY LOG REVIEW

A forward proxy acts on behalf of internal hosts by forwarding their HTTP requests to the intended destination. This is often implemented in environments where traffic outbound for the Internet needs to comply with some administrative or security policy. Proxies can be classed as non-transparent or transparent. A nontransparent proxy means that the client must be configured with the server address to use it; a transparent proxy (or “forced” or “intercepting”) intercepts client traffic without the client having to be reconfigured.

Analysis of proxy logs can reveal the exact nature of HTTP requests, including the websites that users visit and the contents of each request. They’re also useful for preventing users from contacting known sources of malware, even if inadvertently. A proxy may use the Common Log Format, which is widely used by web servers. Information is recorded in seven space-delimited fields, with a hyphen (–) used if a field is blank. There are extended versions of this format, such as the W3C format. Whatever the precise format, forwarding proxy log fields can store the same address and protocol information as firewalls, but also application layer details, such as:

  • The user ID of the client when authenticated to the proxy.
  • The request method used by the client—GET or POST, for instance—and the path of the resource requested.
  • The HTTP status code of the server’s response.
  • The size, in bytes, and MIME type of the resource returned to the client.

Proxies that are set up to intercept or block traffic can also record the rule that a request matched. You can use this information to determine an employee’s intent, be it malicious or harmless.

Access log for the Squid proxy running on pfSense. Access to URLs that use IP addresses has been blocked by policy, resulting in 403 (Forbidden) errors. The host 10.1.0.101 was initially permitted access to the URL 515web.net (HTTP 200/OK), but then blocked by a policy update. (Screenshot Netgate pfSense netgate.com/solutions/pfsense.)

A reverse proxy provides for protocol-specific inbound traffic. You can deploy a reverse proxy and configure it to listen for client requests from a public network (the Internet). The proxy then creates the appropriate request to the internal server on the corporate network and passes the response from the server back to the external client. Logs from a reverse proxy can be analyzed for indicators of attack or compromise, such as malicious code in HTTP request headers and URLs. Statistical analysis of response codes can identify suspicious trends or anomalous deviations from baseline traffic.


Blue Coat proxy server and the common log format.

WEB APPLICATION FIREWALL LOG REVIEW

A web application firewall (WAF) is an application-layer security control that can apply a set of rules to HTTP traffic. Where a stateful packet filtering firewall can apply rules to IP and TCP/UDP layer information, a WAF can parse response and request headers and the HTML message body in HTTP packets and apply detection and filtering rules to the contents. These rules address web-based exploits and vulnerabilities, like SQL injection attacks and cross-site scripting (XSS) attacks.

Traffic that matches a suspicious or unwanted signature will typically be logged with the source and destination addresses, why the traffic triggered an alert (what known suspicious behavior it matched), and what action was taken (based on the configured rule). The actual composition of the log will differ between WAF vendors. WAFs can be configured to record extensive log information, which can be tricky to handle in a standard log format such as W3C. Many cloud-based WAFs use JavaScript Object Notation (JSON). Regardless of the precise format, a WAF log entry will include the following useful information:

  • The time of the event.
  • The severity of the event. Not all events that trigger an alert are treated with equal suspicion.
  • URL parameters, such as the local resource path and query strings.
  • The HTTP method(s) used in the event plus request and response headers.
  • Context for the rule, such as a reference to a database of known vulnerabilities and exploit techniques.
Viewing a matched ModSecurity WAF rule for a Nikto scan in Windows Server 2016. (Screenshot used with permission from Microsoft.)

IDS AND IPS CONFIGURATION

An intrusion detection system (IDS) is a packet sniffer (referred to as a sensor) that feeds packets to an analysis engine. The analysis engine uses a ruleset to match suspicious traffic and generate an event log, notification, or alert. Typically, IDS sensors are placed inside a firewall or close to some server of particular importance. The idea is to identify malicious traffic that has managed to get past the firewall. In a switched environment, the sensor must be connected to a spanning port on the switch in order to monitor traffic passing through the switch on other ports (also known as port mirroring). If the switch does not support spanning ports, another option is to install a test access port (TAP). This is a device that connects directly to the network media.

IDS placement. In this topology, TAPs are used to sniff traffic passing to and from DMZ segments. Traffic for important network server groups, performing authentication and database hosting, is monitored using mirror ports on the switches serving the server segments. Traffic for client host VLANs is not monitored. (Image © 123rf.com)

Intrusion Detection Systems versus Intrusion Prevention Systems

The basic functionality of IDS is to provide passive detection; that is, to log intrusion incidents and to display an alert at the management interface or to email the administrator account if the event is high priority. An IDS appliance or software can also usually be configured as an intrusion prevention system (IPS). An IPS uses a data acquisition (DAQ) module to either block traffic using specially configured virtual interfaces (Afpacket) or perform blocking in conjunction with a firewall (NFQ for iptables/NetFilter-based firewalls or IPFW for BSD-based firewalls). Finally, the IPS may be able to run a script or third-party program to perform some other action not supported by the IPS software itself.

Snort, Zeek, and Security Onion

Examples of IDS/IPS solutions include:

  • Snort (snort.org) is an open-source IDS, with installation packages available for selected Linux distributions and for Windows. While the installation packages are free, a subscription (“oinkcode”) is required to obtain up-to-date rulesets, which are required for the detection engine to identify the latest threats. Non-subscribers can obtain community-authored rulesets. Snort can operate in sniffer-only or log-only modes or can work in a prevention mode (active response) to shut down anomalous traffic using TCP resets and ICMP unreachable messages.
  • The Zeek Network Monitor (zeek.org), formerly called Bro, is an open-source IDS for UNIX/Linux platforms. Zeek’s scripting engine can be used to act on significant events (notices) by generating an alert or implementing some sort of shunning mechanism.
  • Security Onion (securityonion.net) is an open-source platform for security monitoring, incident response, and threat hunting. It bundles Snort, Suricata (suricata.io), Zeek, Wireshark, and NetworkMiner. It also includes log management tools such as Elasticsearch, Logstash, and Kibana (elastic.co), and incident management tools such as Sguil (bammv.github.io/sguil/index.html) and Squert (squertproject.org).

To reconfigure an IDS like Zeek, you would update main.zek with the new rules ( adding/removing ports/services ) and then restart Zeek from within:

[ZeekControl] > status
[ZeekControl] > install
[ZeekControl] > deploy
[ZeekControl] > status

IDS AND IPS LOG REVIEW

An IDS/IPS creates a log entry each time a rule is matched. Depending on the configuration, the rule might also trigger an alert action or perform active notification, via email for instance. One of the most significant challenges in deploying an IDS is tuning the system to avoid overalerting, without reducing sensitivity so much that genuine incidents are missed. Most IDS software will provide numerous options for output. To take Snort as an example, some of the output formats include:

  • Unified output—This creates machine-readable binary files. This is fast but requires an interpreter for a human to read.
  • Syslog—This uses the syslog format to record event details, such as IP addresses, port numbers, and the rule or signature that was matched.
  • Comma-separated values (CSV)—This uses character delimiters for fields and contents, making it easier to import into third-party applications or parse using regular expressions.
  • Tcpdump—This uses the pcap file format to record the packets underlying the event.

These can also be directed to a file or to a database log server, such as a security information and event management (SIEM) system. IDS logs are not often analyzed directly as source files. Alerts should be monitored in real time using a console app or dashboard, with analysts determining whether each alert requires escalation to incident status.

Managing IDS alerts using the Sguil tool in Security Onion. For each alert, you can view the triggering rule and the underlying packet data. As an analyst, you must decide whether to dismiss the alert as low priority or false positive or to investigate the alert as an incident case. (Screenshot: Sguil bammv.github.io/sguil/index.html)

IDS AND IPS RULE CHANGES

Intrusion detection/prevention systems use predefined rule signatures to match traffic that security researchers have identified as malicious. Most rule changes are initiated to tune the rules delivered by a feed to reduce false negatives. If a rule continually produces alerts that do not warrant investigation, the rule can be disabled.

There may be some circumstances where you want to add new rules or customized versions of existing rules. In very general terms, a Snort rule uses the following header and payload structure:

Action Protocol SourceIP SourcePort Direction DestinationIP DestinationPort (RuleOption; RuleOption; …)

The action is usually set to alert, but other options include log, pass (ignore), drop, and reject. The source and destination addresses and ports can use static values, but are more commonly defined as a keyword, such as any, or a variable set in the Snort configuration file, such as $EXTERNAL_NET and %HOME_NET . Direction can be either one way (-> or <-) or bidirectional (<>). The rule can be configured with numerous options. Some common options include:

  • msg—Text to inform the responder what triggered the rule.
  • flow—Match a new or existing TCP connection, or match regardless of TCP connection state.
  • flags—Match whether flags in the packet have been set, such as TCP SYN and FIN both set.
  • track—Apply a rate limiter to the rule by only triggering it if a threshold of events is passed over a particular duration.
  • reference—Match an entry in an attack database, such as CAPEC or ATT&CK.
  • classtype—Categorize the attack.
  • sid and rev—Give the rule a unique ID and provide version information.

As an example, the following rule from the Snort community ruleset checks for brute force attempts against IMAP mailbox accounts, referencing a TTP in the ATT&CK knowledge base:

alert tcp $EXTERNAL_NET any -> $HOME_NET 143 (msg:"PROTOCOL-IMAP logon brute force attempt"; flow:to_server,established,no_stream; content:"LOGON"; fast_pattern:only; detection_filter:track by_dst, count 30, seconds 30; metadata:ruleset community, service imap; reference:url,attack.mitre.org/techniques/T1110; classtype:suspicious-logon; sid:2273; rev:12;)

Custom rule for Zeek in SMTP processing file to check if the originator’s IP address is in the message.

Then restart Zeek from within:

[ZeekControl] > status[ZeekControl] > install[ZeekControl] > deploy[ZeekControl] > status

PORT SECURITY CONFIGURATION CHANGES

Port security can refer to blocking unauthorized application service ports on hosts and at firewalls, but can also mean the physical and remote access ports used to allow a host to communicate on the local network.

Network Appliance Security

Compromising network appliances is a way for an adversary to perform reconnaissance and extend an attack from an initial entry point to the wider network. They may also be the target of DoS attacks. Appliances such as switches, routers, and firewalls are subject to software vulnerabilities and patching regimes in the same way as servers. The procedures for securing and auditing administrative access are also similar. Ensure that the appliance vendor has vulnerability reporting and patching baked into their support procedures. Researchers have discovered multiple vulnerabilities in products based on outdated or unpatched Linux kernels and distributions.

The web administrative interfaces of these products are also often subject to multiple software vulnerabilities, including cross-site scripting and cross-site request forgery. In most cases it is better to operate the appliances via secure command line (SSH) shells instead. Alternatively, ensure that the management stations used to configure these appliances are denied Internet access to reduce the risk of the appliances being compromised through browser security issues.

** Use ACLs to restrict access to management interfaces to designated host devices. Monitor the number of designated interfaces. If the number is continually revised upward, revisit procedures. Security must balance availability with integrity. Admins may say “I need access to that admin interface from my laptop because if I didn’t have it, that outage last week would have lasted hours, not minutes.” There might be a case there, but when you have tens of laptops, all with management access and all used for Internet access or even shared domestic use, your network is exposed to a much larger attack surface. **

Physical Port Security and MAC Filtering

If firewall, proxy, and IDS logs show that rogue devices are connecting to the network, you will need to review port security mechanisms. Network access can be controlled by configuring physical port security, MAC filtering, or a fully-featured network access control (NAC) solution.

With wired ports, access to the physical switch ports and switch hardware should be restricted to authorized staff, using a secure server room and/or lockable hardware cabinets. To prevent the attachment of unauthorized client devices, a switch port can be disabled using the management software, or the patch cable can be physically removed from the port. Completely disabling ports in this way can introduce a lot of administrative overhead and scope for error. Also, it doesn’t provide complete protection as an attacker could unplug a device from an enabled port and connect a rogue device. Consequently, more sophisticated methods of ensuring port security have been developed.

MAC filtering means specifying which MAC addresses are permitted to connect to a particular switch port. This can be done by specifying a list of valid MAC addresses, but this “static” method is difficult to keep up-to-date and relatively error prone. Some switch models allow you to specify a limit to the number of permitted addresses and automatically learn a set number of valid MAC addresses. For example, if port security is enabled with a maximum of two MAC addresses, the switch will record the first two MACs to connect to that port but then drop any traffic from machines with different network adapter IDs that try to connect.


NETWORK ACCESS CONTROL (NAC) CONFIGURATION CHANGES

If security monitoring identifies substantial threats from rogue devices operating within the network, physical port security and MAC filtering may not meet an organization’s security requirement. Network access control (NAC) provides the means to authenticate users and evaluate device integrity before a network connection is permitted.

IEEE 802.1X Port-based NAC (PNAC)

The IEEE 802.1X standard defines a port-based NAC (PNAC) mechanism. PNAC means that the network access device (switch, router, or VPN concentrator, for instance) requests authentication of the connecting host before activating the port. The host requesting access is the supplicant. The network access device, referred to as the authenticator, enables the Extensible Authentication Protocol over LAN (EAPoL) protocol only and waits for the device to supply authentication data. The authenticator passes the supplicant credentials to an authenticating server. The authenticating server checks the credentials and grants or denies access. If access is granted, the network access device will configure the port or VPN tunnel to use the appropriate VLAN and subnet on the local network and enable the port for ordinary network traffic.

NAC Policies and Admission Control

Where 802.1X provides an authentication mechanism, a broader NAC solution allows administrators to devise policies or profiles describing a minimum security configuration that devices must meet to be granted network access. This is called a health policy. Typical policies check things such as malware infection, firmware and OS patch level, host firewall/IDS status, and the presence of up-to-date virus definitions. A solution may also be able to scan the Registry or perform file signature verification. Some of the key features of NAC solutions are:

  • Posture assessment—This is the process of assessing the endpoint for compliance with the health policy. Information can be collected from a device, either by installing an agent or by polling the device.
  • Remediation—This refers to what happens if the device does not meet the security profile. A non-compliant device may be refused connection completely or put in a captive portal from which general network access is prevented, but there is the option to install the required patches or malware definitions.
  • Pre- and post-admission control—Most NAC solutions work on the basis of pre-admission control—that is, the device must meet the policy to gain access. Post-admission control involves subsequently polling the device to check that it remains compliant. Some solutions only perform post-admission control; some do both.

An endpoint health policy is just one of the rule-based methods of granting or denying access. NAC solutions may support diverse types of policies and different criteria to use:

  • Time-based—A time-based ACL can define access periods for given hosts. This can be used to prevent out-of-hours access or allow only a limited window in which sessions are allowed. Another feature of some access control solutions is to limit concurrent log-ons. For example, a user might be able to connect a PC and smartphone to the network at the same time, but any other devices would be blocked.
  • Location-based—This type of policy evaluates the location of the endpoint requesting access. This could use location-based services to determine the device’s geographic location. It could use IP reputation lists to block access from Internet hosts or subnets known to be suspect. It could also be used to police internal network zones—to prevent an attempt to circumvent a firewall when accessing one part of a network from another, for instance.
  • Role-based—This means that NAC re-evaluates a device’s authorization when it is used to do something (adaptive NAC). For example, if a device tries to join the subnet used for server management and the user account and/or device is authorized to be used for switch or domain controller administration, access is permitted. If the function is unauthorized, NAC may shut down the port or take some other action, such as issuing an alert.
  • Rule-based—A complex admission policy might enforce a series of rules, written as logical statements (IF …. AND …. OR).

Front of Flashcard 1 of 4

Your company has suffered a data breach to an IP address subsequently found to appear on several threat reputation blacklists. What configuration change can you make to reduce the risk of further events of this type?

Back of Flashcard 1 of 4

At a minimum, configure outbound filtering on the firewall to block connections to “known-bad” IP addresses. You could also consider denying outbound connections to destinations that have not been approved on a whitelist. This configuration is more secure, but will generate more support incidents.


Front of Flashcard 2 of 4

You are reviewing a router configuration and notice a route to the null() interface. Is this a configuration weakness and IoC or does it support a secure configuration?

Back of Flashcard 2 of 4

This supports a secure configuration to mitigate DDoS. A route to a null interface is a means of dropping traffic (a black hole) without using as much resource on the router to process the unwanted connection.


Front of Flashcard 3 of 4

You are investigating a data exfiltration event and have obtained the web server logs of the host that data was exported to over the Internet from the hosting provider. The logs contain only the external IP address of your company’s router/firewall and a high-level TCP port number. How can you use the log to identify the local host on your network that was used to perform the exfiltration?

Back of Flashcard 3 of 4

The router/firewall is performing port address translation. You can use the local router/firewall log to identify the local host from the port mapping recorded by the remote host.


Front of Flashcard 4 of 4

What type of threat is NAC designed to mitigate?

Back of Flashcard 4 of 4

Attaching devices that are vulnerable to exploits, such as unpatched systems, systems without up-to-date intrusion detection, unsupported operating systems or applications software, and so on.

Leave a Reply

Your email address will not be published. Required fields are marked *