Security foundations: threats, firewalls and how stateful inspection works

What you will learn in this module. In Start here you met the defender mindset and the security stack at a high level. Now we go one level deeper, into the first two SCOR 350-701 domains: 1.0 Security Concepts (the threats and vulnerabilities you must recognise in on-premises, hybrid and cloud environments) and the basics of 2.0 Network Security (how a firewall actually decides what to allow). By the end you will be able to explain how firewalls evolved from packet filters to NGFWs, describe exactly what a stateful firewall keeps in its connection table for TCP, UDP and ICMP, explain why FTP, DNS and SIP need inspection engines, place interfaces into zones and security levels, choose between routed and transparent mode, read a PAT translation, tell IDS from IPS, place firewalls at the perimeter, DMZ, internal segments and data center, compare ASA with Threat Defense, explain why logging matters, and troubleshoot a firewall with show conn, show xlate and show logging.

Prerequisites. IPv4 addressing and subnetting, the TCP three-way handshake, what a port number is, and basic Cisco CLI (enable, show commands). If the words SYN, ACK and "port 443" make sense to you, you are ready.

An analogy: the security desk of an office tower

Picture a tall office tower. Employees on the inside can walk out to the street whenever they like. When an employee orders lunch, the security desk writes in a register: "Ravi, floor 12, expecting a delivery from Pizza Palace". When the delivery rider arrives and says "for Ravi, floor 12", the guard checks the register, finds the matching line, and lets him up. A stranger who walks in and says "I want to go to floor 12" finds no line in the register and is turned away. When the delivery is done, the guard strikes the line out.

That register is the connection table of a stateful firewall. The guard does not need a rule that says "let pizza riders in"; he lets in only the people who are answers to a request someone inside made. A modern next-generation firewall is a guard who also opens the box and checks that it really is pizza, not something dangerous with a pizza label.

Where the threats come from today

Ten years ago most company data lived in one building behind one firewall. Today it lives in three places at once:

• On-premises: your own offices and data centers. Classic threats: malware on a laptop, phishing emails, an attacker on the LAN doing man-in-the-middle, DoS against your internet edge.
• Cloud: workloads and SaaS applications run by a provider. Classic threats: stolen cloud credentials, insecure APIs, misconfigured storage buckets, data breaches, DDoS against public services.
• Hybrid: both joined by VPNs and direct links. The link itself becomes a path an attacker can use to move from a weak cloud workload into the data center, or the other way round.

A firewall is not the only control, but it is the one that decides who may talk to whom. Every other control in this track (IPS, Secure Endpoint, Secure Access, ISE) either sits in the firewall, sits beside it, or feeds it information.

The road map of this module

The modules that follow go deeper into each tool: the ASA CLI and ACLs, NAT in detail, Threat Defense with Management Center, IPS policies and VPNs. Here you build the mental model that makes all of them easy.

A doctor cannot treat an illness she cannot name. A security engineer is the same: before you pick a control, you must recognise the attack from its symptoms. This chapter covers every threat in SCOR blueprint item 1.1 at the level a defender needs: what happens, why it works, what you would see, and what stops it.

First, the vocabulary

Asset

Anything of value: data, a server, a service, a reputation.

Vulnerability

A weakness in software, configuration or process (chapter 3).

Threat

Someone or something that could use the weakness: a criminal group, an insider, a piece of malware.

Exploit

The method or code that actually uses the vulnerability.

Risk

Likelihood multiplied by impact. You reduce risk; you rarely remove it.

Indicator of compromise (IOC)

Evidence that an attack happened: a bad file hash, a malicious domain, an odd login.

Malicious software (malware)

Almost all modern malware "phones home" to a command-and-control (C2) server. That is great news for network defenders: the firewall, DNS security and IPS can see and block that call even when the endpoint missed the infection.

Social engineering: phishing and its cousins

Phishing is a message that tricks a person into clicking a link, opening an attachment or typing a password on a fake page. Spear phishing targets one person with researched details; whaling targets executives; vishing uses voice calls and smishing uses SMS. It works because it attacks people, not software. Defences: email security with link and attachment analysis, DNS-layer blocking of new or malicious domains, multi-factor authentication so a stolen password alone is useless, and user training.

Denial of service: DoS and DDoS

A DoS attack makes a service unavailable. A DDoS does it from thousands of sources at once, usually a botnet of infected devices. Three families:

• Volumetric: fill the internet link with traffic (often reflected and amplified through open DNS or NTP servers).
• Protocol / state exhaustion: fill the connection table of a server or firewall, for example a SYN flood that opens half-open TCP sessions and never completes them.
• Application layer: expensive requests (searches, logins) that look legitimate but exhaust the application.

A firewall protects itself and the servers behind it against state exhaustion with embryonic connection limits and TCP intercept or SYN cookies. Volumetric attacks bigger than your link must be scrubbed upstream by the ISP or a cloud DDoS service; no box at your edge can fix a full pipe.

Man-in-the-middle (on-path) attacks

The attacker places himself between two parties and reads or changes traffic. On a LAN this is usually ARP spoofing or a rogue DHCP server; on Wi-Fi a fake access point. Symptom: two IP addresses resolving to the same MAC, certificate warnings in browsers. Defences: encryption with certificate validation (TLS, IPsec), Dynamic ARP Inspection and DHCP snooping on switches (module sec-infra), 802.1X.

Web application attacks: SQL injection and XSS

SQL injection happens when an application builds a database query by gluing user input into it. Specially crafted input changes the meaning of the query, so the attacker can read or change data he should never see. Defence: parameterised queries (prepared statements), input validation, least-privilege database accounts, and a WAF or IPS signatures in front. Cross-site scripting (XSS) happens when an application puts user input into a web page without encoding it, so script supplied by the attacker runs in other users' browsers and can steal their session. Defence: output encoding, input validation, Content Security Policy, and WAF rules.

Cloud-specific threats

In the cloud the provider secures the building and hypervisor, but you secure your identities, data and configuration (the shared responsibility model). The big four: compromised credentials (an access key leaked in a code repository), insecure APIs (no authentication, no rate limit, too much data returned), data breaches (usually caused by a misconfigured storage bucket or over-permissive role) and DoS/DDoS against public endpoints, which can also create a huge bill.

A threat needs a way in. That way in is a vulnerability: a door left unlocked, a window with a broken latch. SCOR blueprint item 1.2 asks you to compare the most common ones. You do not need to write attacks; you need to recognise the weakness, know why it is dangerous, spot its traces in logs, and name the fix.

The one idea behind most of them: trusting input

Almost every application vulnerability comes from one mistake: the program treats data from an untrusted source as if it were instructions. A form field, a URL, an API parameter, a file upload, even a header, all come from outside the trust boundary. When the program passes that data to a database, a shell, a file system or a web page without checking it, the attacker's data becomes the attacker's command.

The vulnerabilities you must compare

Buffer overflow, explained with a glass of water

Pour 500 ml into a 300 ml glass and the rest spills onto the table. In memory, the "table" might hold the address the program returns to when the function finishes. If an attacker controls what spills, he may redirect the program. That is why buffer overflows are so serious: they can turn a crash into remote code execution. Modern operating systems add ASLR (random memory layout) and DEP/NX (data areas cannot execute) to make this far harder, but the root fix is correct bounds checking and patching.

XSS versus CSRF: the classic confusion

Both involve a victim's browser and a website. The difference is who is trusted. In XSS the victim's browser trusts the website, and the attacker abuses that by getting his script served by the site. In CSRF the website trusts the victim's browser (it carries a valid session cookie), and the attacker abuses that by making the browser send a forged request to the site. XSS steals or acts inside the page; CSRF only fires a request.

Where the network team fits

You will not fix application code, but you control three things that shrink the damage: exposure (only publish what must be public, and only from a DMZ), detection (IPS signatures and WAF rules catch known patterns and give "virtual patching" until the vendor fix arrives) and encryption (disable Telnet, HTTP management, SNMPv1/v2c, weak TLS on every device you own). OWASP Top 10 and CVSS scoring are covered in depth in the next module, sec-concepts.

Think of how building security grew up. First there was a fence with a gate that checked only the number plate of each car. Then came a guard with a visitor register. Then a reception desk that escorted visitors personally. Today there is a full security team with ID badges, bag scanners and cameras. Firewalls followed exactly the same path. Each generation fixed a weakness of the one before it, and every generation is still in use somewhere.

Generation 1: the stateless packet filter

A packet filter judges each packet on its own, using only header fields: source and destination IP, protocol, and source and destination port. A router ACL is the everyday example. It is fast and cheap, but it has no memory. When PC1 sends a request to a web server, the reply comes back from source port 80 to a random high port on PC1. The filter has no idea this reply belongs to a request, so you must write a rule for the return direction too, and that rule is always wide.

! Stateless router ACL on the internet interface (inbound)
ip access-list extended INET-IN
 permit tcp any 10.0.1.0 0.0.0.255 established
 deny   ip any any log
interface GigabitEthernet0/0
 ip access-group INET-IN in

The established keyword helps a little: it permits TCP packets that have the ACK or RST bit set, which true session-opening SYNs do not. But it only looks at flag bits, not at a real session, so a crafted packet with ACK set still passes, and it does nothing at all for UDP or ICMP. Older IOS add-ons such as reflexive ACLs and CBAC tried to add state to routers; the modern IOS answer is the zone-based firewall.

Generation 2: the stateful firewall

A stateful firewall remembers every allowed conversation in a connection table (also called a state table or session table). The first packet of a flow is checked against the policy; if it is allowed, an entry is created, and every later packet in either direction is matched against that entry instead of the rule base. Replies pass automatically; unsolicited packets do not. It also checks that TCP packets arrive in a sensible order (a SYN-ACK must follow a SYN), which defeats the crafted-ACK trick above. The Cisco ASA is the classic example. Its limit: it trusts the port number. Anything on TCP 443 looks like "HTTPS", whether it is a banking site, a game, or malware talking to its controller.

Generation 3: the proxy or application gateway

An application proxy terminates the client's connection itself and opens a second, separate connection to the server. Because it speaks the application protocol, it can inspect commands and content in full. That is powerful but slow, and each application needs its own proxy. Explicit web proxies and many cloud security gateways work this way today.

Generation 4: the next-generation firewall (NGFW)

An NGFW keeps stateful inspection and adds context and content:

• Application visibility and control (AVC): identifies the application (for Cisco, the OpenAppID detectors) whatever the port.
• User identity: rules by user or group from ISE, Active Directory or a captive portal, not only by IP.
• Intrusion prevention (IPS): Snort 3 signatures in Cisco Secure Firewall Threat Defense.
• URL filtering and reputation: category and risk of each site, Security Intelligence feeds from Talos.
• File and malware inspection: file-type control and cloud malware lookups.
• TLS decryption: optional, to see inside encrypted traffic.

A web application firewall (WAF) is a specialist: it sits in front of one web application and understands HTTP deeply to stop SQL injection, XSS and similar attacks. It complements, not replaces, the network firewall.

Go back to the security desk. The register line for a delivery is not just "Ravi". It says who is expected, from which shop, to which floor, when it was written, and whether the rider has arrived yet. A stateful firewall's connection entry is just as detailed, and for TCP it follows the conversation step by step. This chapter opens the register.

What a connection entry contains

The 5-tuple

Protocol, source IP, source port, destination IP, destination port. This uniquely identifies a flow.

Interfaces

Which interface the flow came in on and which it leaves by (for example inside and outside).

NAT information

The real and mapped addresses and ports, linked to the translation table (show xlate).

State and flags

Where the TCP conversation is: waiting for the handshake, up, closing.

Timers and counters

Idle time, uptime, the timeout that applies, and bytes transferred.

The life of a TCP connection through the ASA

1. SYN arrives on inside (PC1 10.0.1.10 port 51544 to 8.8.8.8 port 80). No entry exists, so this packet takes the slow path: route lookup, access check (security levels or the interface ACL), NAT rule lookup, then inspection policy.
2. Allowed. The ASA builds a connection and a PAT translation (10.0.1.10/51544 becomes 203.0.113.2/51544). The connection is embryonic: half-open, waiting for the handshake to finish. The ASA also randomises the initial sequence number by default, so hosts with weak ISN generators are protected.
3. SYN-ACK arrives on outside. It matches the entry. The ASA checks it is a valid reply (right flags, acknowledgment matches the SYN) and forwards it, un-translating the destination back to 10.0.1.10.
4. ACK from PC1. The handshake is complete; the connection is up. From now on every packet takes the fast path: a hash lookup in the connection table, no rule evaluation.
5. Data flows. The TCP normaliser checks each segment is inside the expected sequence window and has sane flags. Counters and idle timers update.
6. Close. FIN from one side makes the connection half-closed; when both FINs are acknowledged the entry is removed. A RST removes it at once. If nothing is seen for the idle timeout (1 hour by default for TCP), it is removed anyway.

Seeing it on the ASA

NK-ASA# show conn
1 in use, 3 most used

TCP outside  8.8.8.8:80 inside  10.0.1.10:51544, idle 0:00:02, bytes 1543, flags UIO

NK-ASA# show conn detail
1 in use, 3 most used
Flags: A - awaiting responder ACK to SYN, a - awaiting initiator ACK to SYN,
       B - TCP probe for server, b - TCP state-bypass or nailed,
       I - initiator data, i - incomplete, O - responder data, U - up, X - inspected by service module

TCP outside: 8.8.8.8/80 inside: 10.0.1.10/51544,
    flags UIO, idle 2s, uptime 4s, timeout 1h0m, bytes 1543

Read the line left to right: the outside end is 8.8.8.8 port 80, the inside end is 10.0.1.10 port 51544. Flags U (up), I (initiator sent data) and O (responder sent data) mean a healthy, two-way session. A connection stuck with "awaiting" flags (A, a) and no I or O means the handshake never finished: the server did not answer or the reply went elsewhere.

The log tells the same story. With logging buffered informational you see a build and a teardown for each connection:

%ASA-6-302013: Built outbound TCP connection 41 for outside:8.8.8.8/80 (8.8.8.8/80) to inside:10.0.1.10/51544 (203.0.113.2/51544)
%ASA-6-302014: Teardown TCP connection 41 for outside:8.8.8.8/80 to inside:10.0.1.10/51544 duration 0:00:01 bytes 1543 TCP FINs

The teardown reason is gold for troubleshooting: TCP FINs is a normal close; TCP Reset-O or Reset-I means the outside or inside host sent a reset; SYN Timeout means the handshake never completed; Conn-timeout means the idle timer expired.

State also protects you

Because the firewall understands TCP, it can defend against abuse of TCP itself. Embryonic connection limits (configured with the Modular Policy Framework using set connection embryonic-conn-max) make the ASA answer SYNs on the server's behalf with TCP intercept during a SYN flood, so the server's table never fills. Packets that do not fit the state (an ACK for a connection that does not exist, a SYN-ACK nobody asked for) are dropped and counted in show asp drop.

TCP is a polite guest: it knocks (SYN), waits to be let in (SYN-ACK), and says goodbye (FIN). UDP just walks in and out with no greeting at all, ICMP is a courier who delivers notes about other conversations, and some applications, like FTP and voice calls, arrange a second meeting in a different room during the first one. A stateful firewall must handle all of them. This chapter shows how.

UDP: pseudo-state

UDP has no handshake and no close. The firewall still creates a connection entry when the first allowed packet passes, keyed on the same 5-tuple. A reply with the source and destination swapped matches the entry and is allowed back. Because there is no FIN, the only way the entry ends is the idle timeout: 2 minutes by default on the ASA. This "remember it until it goes quiet" approach is called pseudo-state or a UDP pseudo-connection.

ICMP: off by default on the ASA

ICMP echo (ping) is a request and a reply, so it can be tracked by identifier and sequence number. But the ASA does not track ICMP statefully by default. The echo request from inside leaves (high to low security), yet the echo reply from outside has no matching entry and is dropped. Two fixes exist; the correct one is to enable ICMP inspection, which is what the lab configuration does:

! Add ICMP to the default inspection class
policy-map global_policy
 class inspection_default
  inspect icmp
  inspect icmp error

inspect icmp creates a short-lived entry per echo so exactly one reply returns. inspect icmp error goes further: it lets ICMP error messages (TTL exceeded, unreachable) back in only when they refer to a real connection, and translates the addresses embedded inside them, which makes traceroute work through NAT. The lazy alternative, an outside ACL that permits all echo-replies, opens a hole for everyone.

Timeouts: how long the register remembers

NK-ASA# show running-config timeout
timeout xlate 3:00:00
timeout pat-xlate 0:00:30
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 sctp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

TCP idle 1 hour, half-closed 10 minutes, UDP 2 minutes, ICMP 2 seconds, PAT translations 30 seconds after their last connection closes. Change them per traffic class with MPF when one application needs it; changing them globally makes the table grow for everyone.

Why some applications need inspection engines

Some protocols break the simple one-connection model. They use a control channel to negotiate a secondary channel on ports that nobody could predict, and some write IP addresses inside the payload, which NAT would otherwise leave wrong. An inspection engine (Cisco also calls it application inspection; on routers, an application layer gateway or ALG) reads the control channel, opens a precise temporary pinhole for the secondary channel, and fixes embedded addresses.

The Modular Policy Framework, briefly

On the ASA, inspection lives in the Modular Policy Framework (MPF): a class-map selects traffic, a policy-map says what to do with it (inspect, set connection limits and timeouts), and a service-policy applies it globally or to one interface. The factory configuration already has class-map inspection_default (matching default-inspection-traffic), a policy-map global_policy with common engines such as dns, ftp, sip, esmtp and tftp, and service-policy global_policy global. ICMP is not in the default list.

NK-ASA# show service-policy
Global policy:
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: icmp, packet 8, lock fail 0, drop 0, reset-drop 0

An airport has areas of different trust: the public hall, the checked-in departure area, and the airside where only crew go. Moving from the public hall into departures needs a security check; moving the other way is easy. Firewalls divide a network in exactly the same way, into zones of different trust, and apply rules at the borders between them.

The classic three zones

• Inside: users and internal servers. Highest trust.
• Outside: the internet. No trust.
• DMZ (demilitarised zone): servers that the internet must reach, such as a public web server. Medium trust. If a DMZ server is compromised, the attacker is still separated from the inside by the firewall policy.

Real designs add more: a management zone, a partner zone, a guest zone, a zone per application tier. The principle stays the same: group things of the same trust, and control every path between groups.

ASA security levels

The ASA expresses trust as a security level from 0 (least trusted) to 100 (most trusted) on each interface. When you name an interface inside, the ASA sets level 100 automatically; any other name gets 0 until you change it. The default rules, with no ACL applied, are simple:

Once you apply an ACL to an interface with access-group, the ACL replaces the security-level behaviour for traffic entering that interface, including an implicit deny at the end. Security levels are a starting point, not a policy.

! The lab ASA interfaces
interface GigabitEthernet0/0
 nameif outside
 security-level 0
 ip address 203.0.113.2 255.255.255.248
interface GigabitEthernet0/1
 nameif inside
 security-level 100
 ip address 10.0.1.1 255.255.255.0
interface GigabitEthernet0/2
 nameif dmz
 security-level 50
 ip address 10.0.2.1 255.255.255.0

NK-ASA# show nameif
Interface                Name                     Security
GigabitEthernet0/0       outside                    0
GigabitEthernet0/1       inside                   100
GigabitEthernet0/2       dmz                       50

Zones on other Cisco firewalls

The IOS zone-based firewall on routers uses named zones with no numbers: traffic between interfaces in the same zone is allowed, traffic between different zones is denied until you create a zone-pair with a policy that inspects, passes or drops it, and the router itself is the special self zone. Secure Firewall Threat Defense uses security zones as objects inside access control rules; there are no security levels, and every allowed path is an explicit rule. The idea is the same everywhere; only the syntax changes.

Deployment modes: routed vs transparent

In routed mode (the default) the ASA is a Layer 3 hop. Each interface has an IP address in a different subnet, hosts use the ASA (or a router behind it) as their gateway, and the ASA can do NAT, static and dynamic routing, DHCP and VPN termination. The lab ASA is in routed mode.

In transparent mode the ASA is a Layer 2 firewall, a bump in the wire. Its interfaces are placed in a bridge group and have no IP addresses; a BVI (bridge virtual interface) holds one management address in the same subnet. Hosts keep their existing gateway. It still does stateful inspection, ACLs and application inspection. You choose it when you must insert a firewall into an existing network without re-addressing anything.

! Transparent mode (changing mode erases the running configuration)
firewall transparent
interface GigabitEthernet0/0
 nameif outside
 bridge-group 1
 security-level 0
interface GigabitEthernet0/1
 nameif inside
 bridge-group 1
 security-level 100
interface BVI1
 ip address 10.0.1.2 255.255.255.0
! Non-IP traffic such as BPDUs needs an EtherType ACL
access-list L2-ALLOW ethertype permit bpdu

Transparent-mode facts to remember: ARP passes (and can be inspected); non-IP traffic is dropped unless an EtherType ACL permits it; routing protocol packets can pass through if permitted, but the ASA does not take part in them. Threat Defense has the same routed and transparent modes plus IPS-only interface modes (inline sets and passive), covered in the sec-fw-deploy module.

A company has one reception phone number. When an employee calls a supplier, the supplier sees the reception number, not the employee's desk extension. When the supplier calls back, the receptionist remembers who made the call and transfers it. Network Address Translation (NAT) does the same for IP addresses, and on the internet edge the firewall is almost always the "receptionist". You met NAT in CCNA on routers; here we look at it through the firewall's eyes.

The words the ASA uses

Real address

The address the host actually has (PC1 is 10.0.1.10).

Mapped address

The address it is translated to (203.0.113.2).

Translation (xlate)

A table entry linking real and mapped, shown with show xlate. Each connection in show conn points to one.

Dynamic PAT

Many real hosts share one mapped IP, told apart by port (also called NAT overload).

Dynamic NAT

Real hosts borrow addresses from a pool of mapped IPs, one-to-one while in use.

Static NAT

A permanent one-to-one mapping, needed for servers the internet must reach.

Identity NAT

Translating an address to itself, used to exempt traffic (for example site-to-site VPN) from other NAT rules.

How the lab translates

! Object (auto) NAT: inside and DMZ hide behind the outside interface
object network INSIDE-NET
 subnet 10.0.1.0 255.255.255.0
 nat (inside,outside) dynamic interface
object network DMZ-NET
 subnet 10.0.2.0 255.255.255.0
 nat (dmz,outside) dynamic interface

dynamic interface means PAT to whatever address the outside interface has (203.0.113.2). When PC1 opens a connection, the ASA keeps the source port if it is free, or picks another, and records the mapping:

NK-ASA# show xlate
1 in use, 2 most used
Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
       s - static, T - twice, N - net-to-net
TCP PAT from inside:10.0.1.10/51544 to outside:203.0.113.2/51544 flags ri idle 0:00:04 timeout 0:00:30

The flags r (portmap, meaning PAT) and i (dynamic) tell you what kind of translation it is. The 30-second timeout starts after the last connection using it closes.

Publishing a server: static NAT plus an ACL

PAT alone only works for connections that start inside. To let the internet reach the DMZ web server, you need a permanent mapping and a rule, because outside (0) to dmz (50) is low to high:

! Static NAT for the web server
object network WEB-SRV
 host 10.0.2.10
 nat (dmz,outside) static 203.0.113.3
! The ACL permits the REAL address, not the mapped one
access-list OUTSIDE-IN extended permit tcp any host 10.0.2.10 eq www
access-group OUTSIDE-IN in interface outside

That comment is the single most tested ASA NAT fact: since ASA 8.3, interface ACLs use the real (untranslated) IP address. The ASA un-translates the destination first, then checks the ACL. Writing the public 203.0.113.3 in the ACL is a classic migration bug; the module sec-asa-acl calls it "the real-IP rule".

Object NAT and twice NAT (a preview)

The ASA has two ways to write NAT. Object NAT (auto NAT) sits inside a network object and translates only the source, as above. Twice NAT (manual NAT) is a separate rule that can match and translate both source and destination, used for policy NAT and VPN exemptions. They are evaluated in order: section 1 (manual rules), section 2 (object rules, statics before dynamics), section 3 (manual rules marked after-auto). Details and practice come in the sec-asa-nat module.

NAT is not a security control

PAT has a side effect that people mistake for security: an unsolicited packet from the internet to 203.0.113.2 has no translation to follow, so it goes nowhere. But the protection actually comes from the stateful policy, not from NAT. IPv6 networks usually use no NAT at all and are just as protected by a stateful firewall. Hiding addresses slows reconnaissance a little; it does not replace access control.

A shop can protect itself in two ways. It can install CCTV cameras that record everything and alert the manager when something looks wrong; the camera cannot stop a thief, but it tells you what happened. Or it can put a guard at the door who checks bags and physically stops anyone carrying stolen goods. The camera is an IDS; the guard is an IPS. Both look inside traffic for attacks, which a stateful firewall alone does not do.

IDS: intrusion detection, passive

An intrusion detection system receives a copy of the traffic, from a switch SPAN port (port mirroring) or a network TAP. It analyses the copy and raises alerts. Because it is out of the path:

• It adds no latency and cannot break traffic if it fails or is overloaded.
• It cannot stop the packet that triggered the alert; by the time it alerts, that packet has already arrived. Some IDS can send TCP resets or ask a firewall to block the source afterwards, but the first packets get through.
• SPAN can drop copies under load, so an IDS may miss things.

IPS: intrusion prevention, inline

An intrusion prevention system sits inline: every packet passes through it. When traffic matches a malicious pattern, it can drop the packet, reset the connection, or block the source for a while, before the attack reaches the target. The costs: it adds some latency, it must be sized for full throughput, and a false positive blocks real business traffic. If the IPS engine fails, the design must choose fail-open (traffic keeps flowing uninspected, favouring availability) or fail-closed (traffic stops, favouring security); hardware bypass interfaces implement fail-open physically.

How attacks are detected

In Cisco Secure Firewall Threat Defense, the IPS engine is Snort 3, fed with rules from Talos. Reputation blocking is Security Intelligence. You will build these policies in the sec-ftd-ips module.

True, false, positive, negative

True positive

An attack happened and the IPS alerted. Good.

False positive

Normal traffic triggered an alert (or a block). Wastes analyst time; inline, it breaks applications.

True negative

Normal traffic, no alert. Good.

False negative

An attack happened and nothing alerted. The most dangerous outcome.

Tuning is the ongoing work of reducing false positives (disable rules that do not apply to your systems, add precise exceptions) without creating false negatives.

Intrusion event (nk-sim)
Priority     1
Message      SERVER-WEB directory traversal attempt
Source       198.51.100.44:53112  zone outside
Destination  10.0.2.10:80         zone dmz
Inline result  Dropped

Think of an airport. There is a fence and a check-in gate at the edge (the perimeter). There is a public arrivals hall that anyone may enter but that leads nowhere important (the DMZ). Inside, security gates separate the terminals, the staff areas and the baggage hall (internal segmentation). And the cargo vault has its own guards, built for heavy traffic (the data center). A firewall is only as useful as where you put it. This chapter is about placement: which design fits which problem.

Two directions of traffic

North-south traffic crosses the boundary of your network: users to the internet, customers to your website. East-west traffic stays inside: a laptop to a file server, a web server to a database. The classic perimeter firewall sees only north-south traffic. Attackers who get in (chapter 2: phishing, a vulnerable web server) move east-west, host to host. This is lateral movement, and the internal and data center designs below exist to stop it.

Design 1: the perimeter (internet edge)

The simplest design: one firewall between inside and outside. Users browse out, nothing comes in unless it is a reply (chapter 5). This is what every small office has, and it is where most people start. In production you deploy the edge as a high-availability pair (active/standby with stateful failover, covered in sec-asa-ha), because the edge firewall is a single point of failure for the whole company.

Design 2: the DMZ, or screened subnet

A DMZ (demilitarised zone), also called a screened subnet, holds the servers the internet must reach: the public website, the mail gateway, a reverse proxy, the VPN portal. Two ways to build it:

Our lab ASA, NK-ASA, is a three-legged design: outside 203.0.113.2 (level 0), inside 10.0.1.0/24 (level 100) and dmz 10.0.2.0/24 (level 50) with the web server WEB at 10.0.2.10. The golden rules: the internet may reach only the published DMZ service; the DMZ may not start connections to the inside; the inside may manage the DMZ.

NK-ASA# show nameif
Interface                Name                     Security
GigabitEthernet0/0       outside                    0
GigabitEthernet0/1       inside                   100
GigabitEthernet0/2       dmz                       50

Design 3: internal segmentation

An internal segmentation firewall sits between groups of internal systems: users and servers, the payment (PCI) network and everything else, the camera and building-control (OT) network and the office. Macro-segmentation uses VLANs, firewall zones and VRFs so every path between groups crosses a policy point. A single ASA trunk can carry many segments:

! Servers and cameras as separate firewall interfaces on one trunk
interface GigabitEthernet0/3.20
 vlan 20
 nameif servers
 security-level 70
 ip address 10.0.20.1 255.255.255.0
interface GigabitEthernet0/3.30
 vlan 30
 nameif cameras
 security-level 20
 ip address 10.0.30.1 255.255.255.0

Micro-segmentation goes further: policy per workload or application tier, by tag or group instead of IP address. Cisco examples: TrustSec Security Group Tags (assigned by ISE, enforced with SGACLs), ACI endpoint groups with contracts, Secure Workload host-based policy, and in the cloud, security groups per instance. It is a building block of zero trust, which sec-concepts covers.

Design 4: the data center and cloud

Data center firewalls see huge east-west volumes: server to server, app to database, backup streams. Design priorities change: throughput, low latency and scale. Common patterns:

• Clustering several firewalls into one logical device for throughput (preview of sec-asa-ha).
• Transparent mode (chapter 7) to insert a firewall between the server VLAN and its gateway without re-addressing.
• Service insertion in a fabric (for example an ACI service graph) so only selected flows are redirected through the firewall.
• Virtual firewalls (ASA Virtual, Threat Defense Virtual) in private and public clouds, plus the cloud's native security groups, for hybrid designs where the same policy follows the workload.

Picture two security guards. The first is a veteran with a register: he checks every visitor against the rules, writes allowed visitors in the book and lets their replies back in. That is the Cisco ASA. The second guard has the same register, plus an X-ray machine, an ID scanner and a radio to headquarters, where one supervisor writes the rules for every building. That is Cisco Secure Firewall Threat Defense (FTD) managed by Management Center (FMC). Both guards also keep a diary. Without the diary, nobody can prove what happened at the door. That diary is logging, the second half of this chapter.

Cisco ASA: the stateful firewall you will configure first

The Adaptive Security Appliance software is a mature stateful firewall and VPN headend. It runs on Cisco Secure Firewall hardware and as ASA Virtual in private and public clouds. Everything in chapters 5 to 8 is ASA behaviour: the connection table, security levels, nameif, inspection engines in the Modular Policy Framework, and NAT. You manage it with the CLI, with ASDM (a GUI for one device), or centrally with Security Cloud Control. Typical uses today: remote-access and site-to-site VPN headend, pure Layer 3/4 stateful filtering, and multiple context mode (several virtual firewalls in one box).

A simplified ASA packet walk, the one you will prove with packet-tracer in sec-asa-tshoot:

1. The packet arrives. Is there an existing connection? If yes, fast path: forward it (with its NAT) and skip the policy checks.
2. If not: route lookup and un-NAT (find the real destination), then the interface ACL or security-level check.
3. Inspection engines, then NAT, then a new connection entry is created.
4. Egress interface, next hop, transmit, and a syslog message such as 302013.

Threat Defense: an NGFW with two engines

Threat Defense is Cisco's NGFW image. Inside it are two engines working together:

• LINA, derived from ASA code: interfaces, routing, NAT, Layer 3/4 access rules, VPN and the connection table. So show conn, show xlate, packet-tracer and capture still work on the FTD CLI.
• Snort 3: the deep inspection engine for application identification, URL filtering, user identity, Security Intelligence, intrusion prevention and file/malware policy.

There is no configuration mode on the FTD CLI for policy. You build policy in Management Center (on-premises, virtual, or cloud-delivered) or in Device Manager (on-box, one device), then press Deploy. The central object is the access control policy: an ordered list of rules that can match zones, networks, ports, applications, URLs and users, with an intrusion policy and a file policy attached to allow rules.

Why logging matters

A firewall that does not log is a guard with no diary. Logs give you five things: troubleshooting (which rule dropped the packet), detection (a burst of denies is a scan), incident response (a timeline of who talked to whom), compliance (standards such as PCI DSS require logging and regular review), and policy tuning (rules that never match can be removed). The segmentation story in chapter 10 was solved by deny logs.

ASA messages have the form %ASA-severity-ID: text. Severity runs from 0 to 7: 0 emergencies, 1 alerts, 2 critical, 3 errors, 4 warnings, 5 notifications, 6 informational, 7 debugging. A lower number is more severe, and choosing a level includes every level below it.

! Sensible ASA logging baseline
logging enable
logging timestamp
logging device-id hostname
logging buffer-size 524288
logging buffered informational
! Send a copy to the central syslog/SIEM server
logging trap informational
logging host inside 10.0.1.200

NK-ASA# show logging
Syslog logging: enabled
    Timestamp logging: enabled
    Buffer logging: level informational, 128 messages logged
    Trap logging: level informational, facility 20, 128 messages logged
        Logging to inside 10.0.1.200
    Device ID: hostname "NK-ASA"

On Threat Defense you choose logging per access rule: at the beginning and/or end of the connection. End-of-connection gives the full picture (bytes, duration, application); a block rule can log only at the beginning, because the connection never gets an end.

When a parcel goes missing, a good courier company does not guess. It checks the tracking record: was it picked up, which hub scanned it, was it held at customs, and why. A firewall keeps exactly that kind of record for every flow. This chapter gives you a repeatable workflow, then walks through the lab Watch a stateful firewall at work step by step, so you know what every output means before you type it.

The five-question workflow

1. Define the flow. Source IP, destination IP, protocol, destination port, and the interface it enters. "The internet is down" is not a flow; "PC1 10.0.1.10 to 8.8.8.8 TCP 80, entering inside" is.
2. Did a connection get built? show conn address 10.0.1.10. An entry with flags UIO means the firewall did its job; look elsewhere. An entry stuck with awaiting flags means the reply is not coming back.
3. Is it translated correctly? show xlate. No entry for an outbound flow usually means a missing NAT rule.
4. What did the log say? show logging: 302013/302014 for built and torn down, 106001 or 106023 for denied, 305011 for translations, and the teardown reason.
5. What would the firewall do, and what did the wire see? packet-tracer simulates a packet through every phase; capture shows real packets on an interface; show asp drop counts why packets were dropped.

Lab walk-through, task 1: generate inside traffic

On PC1 run curl 8.8.8.8 and ping 8.8.8.8. Both succeed. The web request works because inside (100) to outside (0) is high to low. The ping works only because the lab ASA has inspect icmp in global_policy (chapter 6); without it the echo replies would be denied.

Task 2: read the connection and translation tables

On ASA1, type enable (the lab has no enable password; just press Enter), then:

NK-ASA# show conn
2 in use, 3 most used

TCP outside  8.8.8.8:80 inside  10.0.1.10:51544, idle 0:00:05, bytes 1543, flags UIO
ICMP outside  8.8.8.8:0 inside  10.0.1.10:1, idle 0:00:00, bytes 64, flags

NK-ASA# show xlate
2 in use, 3 most used
Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
       s - static, T - twice, N - net-to-net
TCP PAT from inside:10.0.1.10/51544 to outside:203.0.113.2/51544 flags ri idle 0:00:05 timeout 0:00:30
ICMP PAT from inside:10.0.1.10/1 to outside:203.0.113.2/1 flags ri idle 0:00:00 timeout 0:00:30

The question in the lab is: which address does the internet server see as the source? Read the "to outside:" part of the PAT entry: 203.0.113.2, the ASA's outside interface, because INSIDE-NET uses dynamic interface PAT. Your ports and counters will differ; the pattern will not. If the connections have already closed, run the traffic again and look quickly, because PAT entries expire 30 seconds after their last connection.

Task 3: be the stranger

On PARTNER (198.51.100.10) run curl 203.0.113.2. It fails. Nothing on the inside started this conversation, so there is no connection entry, no static NAT publishes anything on 203.0.113.2 port 80, and outside (0) cannot open connections to a higher level without an ACL.

Task 4: find the evidence

NK-ASA# show logging
Syslog logging: enabled
    Buffer logging: level informational, 9 messages logged
%ASA-6-305011: Built dynamic TCP translation from inside:10.0.1.10/51544 to outside:203.0.113.2/51544
%ASA-6-302013: Built outbound TCP connection 41 for outside:8.8.8.8/80 (8.8.8.8/80) to inside:10.0.1.10/51544 (203.0.113.2/51544)
%ASA-6-302014: Teardown TCP connection 41 for outside:8.8.8.8/80 to inside:10.0.1.10/51544 duration 0:00:01 bytes 1543 TCP FINs
%ASA-2-106001: Inbound TCP connection denied from 198.51.100.10/40001 to 203.0.113.2/80 flags SYN  on interface outside

The lab asks for the message ID of the drop: 106001 (severity 2, critical). Read it aloud: an inbound TCP SYN from PARTNER to the public address was denied on the outside interface. That single line is stateful inspection proving itself.

Going further: packet-tracer, capture and ASP drops

! Simulate PC1's web flow through every phase
packet-tracer input inside tcp 10.0.1.10 51544 8.8.8.8 80
! Capture real packets on the outside interface
capture CAP-OUT interface outside match tcp host 198.51.100.10 host 203.0.113.2
show capture CAP-OUT
! Count why packets were dropped in the data path
show asp drop

NK-ASA# packet-tracer input inside tcp 10.0.1.10 51544 8.8.8.8 80
...
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
Action: allow

packet-tracer lists each phase (route lookup, access list, NAT, inspection, flow creation) and shows exactly which one allows or drops. A capture proves whether a packet actually arrived; no packet in the capture means the problem is upstream, not on the firewall.

You started with a security guard and a register. You now know what the register holds for TCP, UDP and ICMP, how the guard handles tricky visitors like FTP and SIP, how the building is divided into zones, how the reception number (NAT) works, when to use a camera (IDS) or a door guard (IPS), where to place firewalls so one breach does not sink the ship, how the ASA and Threat Defense differ, and why the guard's diary (logging) matters. Use this chapter as your revision sheet before the lab, the exam and the interview.

Can-do checklist

• I can describe viruses, worms, trojans, rootkits, ransomware, phishing, DoS/DDoS, MITM, SQL injection and XSS, with one indicator and one defence each.
• I can name the SCOR cloud threats: data breaches, insecure APIs, compromised credentials, DoS/DDoS.
• I can compare software bugs, weak or hard-coded passwords, missing encryption, OS command injection, buffer overflow, path traversal, XSS and CSRF.
• I can explain packet filter vs stateful vs proxy vs NGFW vs WAF.
• I can walk a TCP connection through a stateful firewall and read show conn flags.
• I can explain UDP pseudo-state, ASA ICMP behaviour, default timeouts and why FTP, DNS and SIP need inspection.
• I can apply ASA security-level rules and choose routed or transparent mode.
• I can read show xlate, explain PAT vs static NAT and the real-IP ACL rule.
• I can compare IDS and IPS, and signature, anomaly, policy and reputation detection.
• I can choose a firewall placement: perimeter, three-legged or back-to-back DMZ, internal segmentation and data center, and explain north-south vs east-west.
• I can compare the ASA with Threat Defense (LINA plus Snort 3, managed by Management Center or Device Manager).
• I can explain why logging matters, the syslog severities 0–7, and configure a logging baseline.
• I can complete the lab and find message 106001 in the log.

Mini glossary

Connection table

The stateful firewall's memory of allowed flows (5-tuple, interfaces, NAT, state, timers).

Embryonic connection

A TCP connection whose handshake has not completed.

Pseudo-state

Tracking connectionless UDP by 5-tuple and idle timeout.

Inspection engine / ALG

Reads an application's control channel to open pinholes and fix embedded addresses.

Pinhole

A temporary, exact opening for one secondary connection.

Security level

ASA trust value 0–100 per interface.

BVI

Bridge virtual interface holding the management IP in transparent mode.

Xlate

A NAT translation entry.

False negative

An attack that produced no alert.

Lateral movement

An attacker moving east-west from host to host.

Screened subnet

Another name for a DMZ.

LINA / Snort 3

The two Threat Defense engines: L3/L4, NAT and VPN, and Layer 7 inspection.

Most tested facts

Command cheat-sheet

! Sessions, translations and logs
show conn
show conn detail
show conn count
show xlate
show logging
! Logging baseline
logging enable
logging timestamp
logging buffered informational
logging trap informational
logging host inside 10.0.1.200
! Policy and inspection
show nameif
show service-policy
show running-config timeout
! Deep troubleshooting
packet-tracer input inside tcp 10.0.1.10 51544 8.8.8.8 80
capture CAP-OUT interface outside match tcp host 198.51.100.10 host 203.0.113.2
show capture CAP-OUT
show asp drop
clear conn address 10.0.1.10