Speaker 1: I want to start today with a concept that sounds
Speaker 1: fantastic in a marketing brochure but usually creates a massive
Speaker 1: headache for the engineers actually doing the work. Oh yeah,
Speaker 1: it's convergence. You know that moment when an industry decides
Speaker 1: to take two completely different powerful technologies, mash them together
Speaker 1: and pray they work as a single unit.
Speaker 2: Right, Yeah, it's the whole Frankenstein phase of technology. Sometimes
Speaker 2: you get a monster that destroys the village, and sometimes
Speaker 2: you get something that actually changes the industry exactly.
Speaker 1: And today's deep dive is squarely focused on one of
Speaker 1: the most significant and frankly complex convergences in network security history.
Speaker 1: We are talking about the marriage of Cisco's legendary ASA.
Speaker 2: Firewall, the absolute workhorse, all.
Speaker 1: Right, the workhoorse of the two thousands, and source fire,
Speaker 1: which is the intelligence engine that brought us snort.
Speaker 2: This was a massive moment. You had the sturdy, packet
Speaker 2: shuffling brawn of Cisco meeting the deep packet inspection brains
Speaker 2: a Source Fire. Yeah. It was a logical match, but
Speaker 2: the integration wasn't exactly seamless.
Speaker 1: Yeah. Not seamless is a polite way of putting it
Speaker 1: as anyone listening who has managed these boxes knows it
Speaker 1: wasn't exactly a smooth honeymoon. So to help us navigate this,
Speaker 1: we are analyzing a comprehensive technical guide titled Cisco FTD
Speaker 1: Configuration and Troubleshooting Best Practices.
Speaker 2: And the author there is nasmal rejib.
Speaker 1: Right from Cisco Tech's take, and that.
Speaker 2: Author credential is key take. The technical assistance center is
Speaker 2: where you go when the documentation fails. These guys see
Speaker 2: the edge cases, the crashes, the things that aren't supposed
Speaker 2: to happen. So you know, this isn't a sales pitch.
Speaker 2: It's a survival guide for the Firepower Threat Defense System
Speaker 2: or FTD.
Speaker 1: Our mission today for you listening is to decode the
Speaker 1: architecture of FTD, understand how it actually catches bad actors
Speaker 1: using things like sinkholes, and crucially, how to fix it
Speaker 1: when the lights turn amber. But we really have to
Speaker 1: start with the identity crisis. So the naming, Yeah, the
Speaker 1: source material spends a surprising amount of time just clarifying
Speaker 1: what this thing is even called.
Speaker 2: It sounds trivial, doesn't it. It's just semantics. But in
Speaker 2: this case, the name actually tells you the architecture. If
Speaker 2: you get a name wrong, you're probably looking at the
Speaker 2: wrong manual.
Speaker 1: So break that down for us, we have firepower and
Speaker 1: firepower right.
Speaker 2: So before Cisco acquired source Fire in twenty thirteen, that
Speaker 2: technology was branded as Firepower. That's all uppercase power. If
Speaker 2: you see that in documentation, you're looking at the legacy era.
Speaker 2: Usually that meant running the source Fire services as a
Speaker 2: completely separate module on top of an ASA firewall.
Speaker 1: Like taping a smartphone to a landline phone.
Speaker 2: Exactly two brains, one box. But they didn't really talk
Speaker 2: to each other deeply. After the acquisition, Cisco moved to
Speaker 2: what they call the unified image. They rebranded it to
Speaker 2: Firepower one word lowercase power. Ah okay, So when you
Speaker 2: see FTD or Firepower thread defense, you were looking at
Speaker 2: a converged operating system. It's no longer an ASA running
Speaker 2: a source fire app. It is a single OS that
Speaker 2: handles both the routing and the thread inspection.
Speaker 1: And that's a critical distinction. If you're trying trying to
Speaker 1: troubleshoot an FTD box using command methodologies from the old
Speaker 1: upper case power days, you're going to hit a wall
Speaker 1: you are.
Speaker 2: The architecture is fundamentally different. Yeah, And speaking of architecture,
Speaker 2: the guide makes a very strong point about how the
Speaker 2: traffic actually flows through this box. It introduces a concept
Speaker 2: that I think is the most important mental model for
Speaker 2: an ADMIN, which is the strict separation of the data
Speaker 2: plane and the management plane. It's the simple deployment topology,
Speaker 2: but it's vital.
Speaker 1: To a layperson or even a junior admin. A port
Speaker 1: is a port. Why does the guide insist on such
Speaker 1: a strict separation here?
Speaker 2: Think of it like a bank vault. You have the
Speaker 2: front door where customers the data packets come in to
Speaker 2: do business. That's your data traffic flowing through the inside
Speaker 2: and outside interfaces. Okay, but you don't want the bank
Speaker 2: manager who holds the combination to the vault, walking through
Speaker 2: that same front door with the customers.
Speaker 1: Because if a robber is in the lobby, or if
Speaker 1: the lobby is just super crowded, the manager gets stuck.
Speaker 2: Precisely, in FTD, the guide specifies using a dedicated management
Speaker 2: port often ten dot one, dot one dot two in
Speaker 2: the examples, that connects strictly to the brain of the operation,
Speaker 2: the firepower management center or FMC.
Speaker 1: So the FMC is the brain and the FTD device
Speaker 1: is the muscle.
Speaker 2: Correct, And you do not want your management traffic, which
Speaker 2: contains policy pushes, log data and sensitive configurations, mixing with
Speaker 2: the dirty internet traffic.
Speaker 1: That makes sense.
Speaker 2: If your data plane gets flooded by a ddous attack,
Speaker 2: you still need that backdoor management port to be accessible
Speaker 2: so you can actually fix it. If you mix them,
Speaker 2: you lose control exactly when you need it most.
Speaker 1: Now, there is a very specific umbilical cord connecting the brain,
Speaker 1: the FMC and the muscle, the FDD. The source calls
Speaker 1: it the SF tunnel.
Speaker 2: The SF tunnel. This is the lifeline. It's an encrypted
Speaker 2: tunnel where all the communication happens. Heartbeats to check out
Speaker 2: the devices, alive, policy updates, event logs. It all goes
Speaker 2: through here.
Speaker 1: And there is one detail in the text that felt
Speaker 1: like a write this down on a sticky note moment.
Speaker 1: TCP port eighty three zero.
Speaker 2: FO eighty three zero five. If you take nothing else
Speaker 2: away from the architecture section today, remember that number.
Speaker 1: Why is that specific port so critical? Walk me through
Speaker 1: a scenario.
Speaker 2: Okay, imagine you deploy a new firewall at a branch
Speaker 2: office you plug it in, you give it an IP,
Speaker 2: you can ping it. It seems fine. Sure, but back
Speaker 2: at headquarters, the management center shows the devices offline. You
Speaker 2: try to push a policy and it fails.
Speaker 1: But the internet is working. At the branch.
Speaker 2: Office, the internet works fine. The data plane is up,
Speaker 2: but the management plane is broken. Why because some intermediate
Speaker 2: router or ISP firewall in the middle is blocking Port
Speaker 2: eighty three zero five.
Speaker 1: So the brain is completely cut off from.
Speaker 2: The body exactly. The firewall will keep passing traffic based
Speaker 2: on the last known policy. It's designed to fail open
Speaker 2: or closed, depending on your config but it's flying blind
Speaker 2: regarding new updates. You can't patch it, you can't change rules.
Speaker 2: It's basically a zombie, so always check Port eighty three
Speaker 2: zero five. First.
Speaker 1: That's a nightmare scenario. You think you're protected, but you're
Speaker 1: actually stagnant. Let's move to the actual birth of this system.
Speaker 1: The guide walks through the reimaging process, basically wiping the
Speaker 1: box and installing FTD from scratch. I was expecting a
Speaker 1: modern click Next Wizard, but this sounds incredibly old school.
Speaker 2: It is surprisingly retro. We're talking about interrupting the boot
Speaker 2: sequence at the bios level. It feels like hacking a
Speaker 2: computer in a nineties movie.
Speaker 1: The guide mentions a specific boot menu called LILO the
Speaker 1: Linux loader.
Speaker 2: When you are converting an ASA to FTD or recovering
Speaker 2: a corrupted system, you have to catch the boot process.
Speaker 2: You'll see a prompt, often on a blue or red
Speaker 2: screen with blocky text, and the guide warns you you
Speaker 2: have to be fast.
Speaker 1: It says you have to select systemer store within three seconds.
Speaker 2: Three seconds it's a reflex test. If you miss it,
Speaker 2: the box boots back into the old broken image or
Speaker 2: tries to load and OS it isn't there. Then you
Speaker 2: have to power cycle the box, wait for the post
Speaker 2: and try again.
Speaker 1: It seems odd that a cutting edge security device relies
Speaker 1: on a three second reflex test.
Speaker 2: Nature of the beast underneath the slick GUI the management center,
Speaker 2: this is still a hardened Linux appliance, and sometimes you
Speaker 2: have to get your hands dirty in the console.
Speaker 1: And you aren't just installing one file, are you. The
Speaker 1: guide breaks down the installation into layers. It's not just install.
Speaker 2: FTD, right, You can't just slap the software on. You
Speaker 2: have the raman that's the firmware, the bottom layer, then
Speaker 2: the boot image which essentially teaches the hardware how to
Speaker 2: load the OS, and then the system software, which is
Speaker 2: the actual FTD application.
Speaker 1: It's like building a house foundation before you frame the walls.
Speaker 2: Exactly. If your ramen is outdated, the boot image won't load.
Speaker 2: If the boot image is wrong, the system software fails.
Speaker 2: You have to respect the hierarchy.
Speaker 1: Now, a lot of people listening are probably running this
Speaker 1: in a virtual environment like VMware ESX, rather than on
Speaker 1: physical hardware. The source had a very specific, somewhat controversial
Speaker 1: recommendation for disc provisioning. It explicitly recommends thick provision lazy zeroed.
Speaker 2: Ah the storage wars. This is a constant debate between
Speaker 2: network admins and storage admins.
Speaker 1: To the uninitiated, thick provision lazy zeroed sounds like an insult.
Speaker 1: You're a thick provision lazy zero It does.
Speaker 2: Sound like that, but here's what it actually means. Thick
Speaker 2: provision means you claim all the disks based up front.
Speaker 2: If the FTD needs one hundred gigs, you take one
Speaker 2: hundred gigs from the storage ray immediately. Storage admins hate
Speaker 2: this because it eats of capacity. They might want to
Speaker 2: oversubscribe right.
Speaker 1: They prefer thin provisioning where the disc file starts small
Speaker 1: and grows as you add data.
Speaker 2: Right, But thin is dangerous for high performance databases like
Speaker 2: the one inside FTD. When the database needs to write
Speaker 2: a massive amount of logs during an attack and it
Speaker 2: has to ask the hypervisor to expand the disc at
Speaker 2: that exact moment, you get latency.
Speaker 1: And in security logging, latency means dropped events exactly.
Speaker 2: The system might just drop the log because it can't
Speaker 2: write it fast enough. So thick guarantees the space is there.
Speaker 1: What about the lazy zeroed part? Why not eager zeroed?
Speaker 2: That's the compromise. Eager zero means the system writs a
Speaker 2: zero to every single bit on the drive before it starts.
Speaker 2: For a large drive that takes forever to initialize, you're
Speaker 2: sitting there for an hour waiting for the disk to format.
Speaker 2: Lazy zero reserves the space, but cleans it up on
Speaker 2: the fly as it writes data. It's the sweet spot
Speaker 2: between performance and set up time.
Speaker 1: Okay, so we've navigated the LILA menu, We've provisioned our
Speaker 1: thick discs, and the tunnel is up on poort eighty
Speaker 1: three zero five. The system is live. Now we get
Speaker 1: to the cool stuff catching the bad guys. The guide
Speaker 1: talks about Security Intelligence or SI. How is this different
Speaker 1: from just a normal firewall rule?
Speaker 2: This is the shift from static to dynamic. A normal
Speaker 2: firewall rule is static BLOCKIP one dot two, dot three,
Speaker 2: dot four, But bad guys change ips every hour. If
Speaker 2: you're relying on static rules, you're always a step behind.
Speaker 2: Security Intelligence is a feed.
Speaker 1: It blocks based on reputation, so it's like a credit
Speaker 1: score for IP addresses exactly.
Speaker 2: The system downloads a feed from Cisco Tallos that's their
Speaker 2: massive Threat intelligence team every thirty minutes. If an IP
Speaker 2: was legit yesterday but got hijacked by a botnet this morning,
Speaker 2: the feed updates and SI blocks it immediately. It happens
Speaker 2: before the traffic even hits the deeper inspection policies.
Speaker 1: It's a prefilter which saves processing power huge amounts.
Speaker 2: Why waste CPU cycles decrypting and inspecting a packet deep down?
Speaker 2: If you know the sender is a known spammer, just
Speaker 2: drop it at the door.
Speaker 1: But what if you don't want to just drop it?
Speaker 1: There's a feature here that I found fascinating called the sinkhole.
Speaker 2: This is my absolute favorite feature for internal defense it
Speaker 2: turns the tables on the attacker.
Speaker 1: Explain how this works because sinkhole implies the data just disappears,
Speaker 1: but the guide says it actually does something deceptive.
Speaker 2: So imagine you have an infected laptop on your network.
Speaker 2: Let's say Bob in accounting clicked a bad link. His
Speaker 2: laptop is trying to phone home to a command and
Speaker 2: control server to get instructions.
Speaker 1: Normally, the firewall would just block that connection. Bob gets
Speaker 1: a connection timed out and he just thinks the Wi
Speaker 1: fi is bad. He goes to get a coffee right,
Speaker 1: and you.
Speaker 2: The admin might see a generic block log, but you
Speaker 2: have thousands of logs, you might miss the urgency. With
Speaker 2: a DNS sinkhole, the FTD intercept to Bob's DNS request
Speaker 2: for evilhacker site dot com. Instead of blocking it.
Speaker 1: The FTD lies it lies to Bob's computer.
Speaker 2: It returns a fake IP address. The guide used the
Speaker 2: example one ninety two one sixty eight dot one dot
Speaker 2: ninety one. Bob's computer thinks, aha, I found the server
Speaker 2: and tries to send it stolen data to that IP.
Speaker 1: But that IP is actually a server the admin controls.
Speaker 2: Exactly, it's a trap. Now you can look at the
Speaker 2: logs of your sinkhole server and see, hey, Bob's IP
Speaker 2: is frantically trying to connect to me. It gives you
Speaker 2: a positive confirmation of who is infected. It turns the
Speaker 2: attack into a beacon for remediation.
Speaker 1: That is incredibly smart. It changes the dynamic from I
Speaker 1: blocked something to I caught someone.
Speaker 2: It enables hunting. That's the key difference. Instead of just
Speaker 2: playing defense, you're gathering intelligence on your own compromised hosts.
Speaker 1: The system also applies this reputation logic to websites via
Speaker 1: the webs Reputation Index or WRI. The source says this
Speaker 1: is a score from zero to one hundred.
Speaker 2: Simple scale. Zero to twenty is high risk, so malware
Speaker 2: phishing exploits twenty one to forty is suspicious. The cool
Speaker 2: thing is you can write policies based on the score,
Speaker 2: not the URL.
Speaker 1: So I can say block anything below a twenty, right, you.
Speaker 2: Don't need to know the URL. If a new gambling
Speaker 2: site pops up tomorrow and tallows scores at a fifteen,
Speaker 2: your policy automatically catches it. It automates the cat and
Speaker 2: mouse game.
Speaker 1: But, and there is always a lit but to do
Speaker 1: all this fancy inspection. You need the right paperwork. We
Speaker 1: have to talk about licensing. The guide makes a distinction
Speaker 1: here that I think trips a lot of people up
Speaker 1: threat license versus malware license.
Speaker 2: It is very confusing. You'd think the threat license would
Speaker 2: cover malware right. It sounds like the exact same thing.
Speaker 2: We really would, but in Cisco speak, they are entirely
Speaker 2: different functions. A threat license gives you file type control.
Speaker 2: It lets the system see what a file is. This
Speaker 2: is a PDF, this is an EXE. You can use
Speaker 2: that to say block all ex but it.
Speaker 1: Doesn't know if the ex is good or bad, no clue.
Speaker 2: It just sees the container to see if the contents
Speaker 2: are malicious. You need the malware license that enables AMP
Speaker 2: Advanced Malware Protection.
Speaker 1: And that's where the cloud comes back in.
Speaker 2: Right. AMP calculates a hash, a digital fingerprint of the file,
Speaker 2: and asks the tellis cloud, have you seen this fingerprint before?
Speaker 2: Is it bad?
Speaker 1: And if the cloud has never seen it.
Speaker 2: Then they can actually upload the file for dynamic analysis,
Speaker 2: running it in a sandbox in the cloud to see
Speaker 2: what it does. That's the sparal analysis engine mentioned in
Speaker 2: the text.
Speaker 1: The guide notes that if you have automatic local malware
Speaker 1: detection updates checked. It pulls signatures every thirty minutes. Is
Speaker 1: thirty minutes fast enough in today's world.
Speaker 2: It's a balance. Real time lookups happen for every file,
Speaker 2: but the local signature set the stuff the box knows
Speaker 2: without asking. The cloud needs to update frequently to keep
Speaker 2: latency down. Thirty minutes is the industry standard for near
Speaker 2: real time without crashing your bandwidth.
Speaker 1: Okay, so we've got the system our detected, installed, licensed
Speaker 1: and sinking holes. But eventually something breaks the dashboard turns red.
Speaker 1: The guide's troubleshooting section is extensive, but the author seems
Speaker 1: to have a favorite tool.
Speaker 2: He's a tack engineer, of course. His favorite tool is
Speaker 2: the command line caps traffic, the ultimate source of truth.
Speaker 2: The command is capture traffic, but under the hood it's
Speaker 2: using TCP dump. It allows you to see the raw
Speaker 2: packets hitting the interface.
Speaker 1: Why is this better than looking at the nice graphical
Speaker 1: logs in the FMC.
Speaker 2: The FMC tells you what the policy did. I blocked
Speaker 2: this because of rule five, but capture traffic shows you
Speaker 2: what is actually on the wire. Are the packets malformed?
Speaker 2: Is the three way handshake? Failing is the latency happening
Speaker 2: before or after the firewall.
Speaker 1: The guide mentions using flags like dash N and dash X,
Speaker 1: what are those doing.
Speaker 2: Dash in stops the system from trying to resolve DNS
Speaker 2: names for every packet, which significantly speeds up the capture.
Speaker 2: If you don't use dash N, your capture might lieg
Speaker 2: just because it's trying to figure out the name of
Speaker 2: every single server. And dash X dash is the power move.
Speaker 2: Da X displays the payload in both hex and as.
Speaker 1: Key, so you can actually read the data.
Speaker 2: You can read the data inside the packet. If an
Speaker 2: application is failing, you can see if the server is
Speaker 2: sending back a four or four error or access denied
Speaker 2: or a SEQL error right inside the packet trace. It
Speaker 2: removes the mystery. If computer says no, you can see
Speaker 2: exactly why computer says no.
Speaker 1: Sometimes, though the problem isn't the traffic, it's the box
Speaker 1: itself running out of steam. The guide distinguishes between overruns
Speaker 1: and no buffer. These sound completely synonymous to me.
Speaker 2: They both mean dropped packets, but the cause is completely different,
Speaker 2: and knowing the difference saves you hours of troubleshooting.
Speaker 1: Break it down for us.
Speaker 2: Overruns happen at the network card level, the NIC is
Speaker 2: receiving packets faster than the CPU can take them off
Speaker 2: the interface. It's a speed mismatch. The CPU is the bottleneck.
Speaker 1: So overrun means CPU is too slow or traffic is
Speaker 1: too birsty exactly.
Speaker 2: No buffer, on the other hand, means the CPU is
Speaker 2: keeping up, but it has nowhere to put the packets
Speaker 2: while it processes them the memory.
Speaker 1: The RAM is full, so no buffer equals out of RAM.
Speaker 2: Generally, yes, if you see overruns, you might need a
Speaker 2: faster box, or you need to offload some traffic. If
Speaker 2: you see no buffer, you might need to tune your
Speaker 2: inspection policies to be less memory intensive.
Speaker 1: Finally, the guide covers the Amber led scenario hardware failure,
Speaker 1: and it offers a safety tip that I feel applies
Speaker 1: to every piece of electronics I own, but I always
Speaker 1: ignore it.
Speaker 2: The wait five minutes rule.
Speaker 1: We all know turn it off and on again, but
Speaker 1: the guide explicitly says, unplug the power supply unit and
Speaker 1: wait five minutes before plugging it back in.
Speaker 2: It's not just superstition or a way to make you
Speaker 2: take a coffee break. It's about residual charge. The electricity
Speaker 2: stays inside the capacitors inside the power supply hold electricity
Speaker 2: even after you unplug it. If you plug it back
Speaker 2: in immediately, the memory and controllers might not have fully
Speaker 2: reset because they never lost power completely. They were running
Speaker 2: on fume.
Speaker 1: So the air state persists exactly.
Speaker 2: You have to let the box drain completely to get
Speaker 2: a true cold boot. Patients is a troubleshooting tool here.
Speaker 1: I like that, so let's zoom out. We've gone from
Speaker 1: the merger of source Fire and Cisco, through the three
Speaker 1: second Lilo boot challenge, down the encrypted s of tunnel
Speaker 1: and into the nitty gritty of hex.
Speaker 2: Packet captures the beast of a system. It really shows
Speaker 2: how far we've come from simple packet filtering.
Speaker 1: It really highlights a philosophical shift in our industry. Ten
Speaker 1: fifteen years ago, a firewall was just a gatekeeper open
Speaker 1: port eighty, close port twenty three. Simple.
Speaker 2: It was entirely binary, yes or no. You didn't care
Speaker 2: what was inside the packet, just where it was going.
Speaker 1: But FTD represents context. It's not just the port, it's
Speaker 1: who is this user? What is this file? What is
Speaker 1: the reputation of this website? Is this packet part of
Speaker 1: a known attack pattern.
Speaker 2: It's the difference between a security guard who checks your
Speaker 2: ID badge at the door and a detective who follows
Speaker 2: you around the building, reads your mail, checks your credit score,
Speaker 2: and watches who you talk to.
Speaker 1: That is a massive amount of visibility, and that leads
Speaker 1: me to the final thought. I want to leave everyone
Speaker 1: listening with The guide briefly mentions private IP addresses RFC
Speaker 1: nineteen eighteen as a way to conserve public eyeps, But
Speaker 1: originally we also viewed GNAT network address translation as a
Speaker 1: form of obscurity.
Speaker 2: What happens behind the firewall stays behind the farewell exactly.
Speaker 1: But with FTD and this move toward total visibility, we
Speaker 1: are flipping that on its head. To protect the network,
Speaker 1: the admin needs to see everything, every URL, every filed download,
Speaker 1: every DNS request. We are even decrypting SSL traffic to
Speaker 1: see inside it.
Speaker 2: We are removing the obscurity to find the threats hiding
Speaker 2: in the noise.
Speaker 1: The question this manual leaves me with is not really
Speaker 1: about privacy, but about capacity. We have built a machine
Speaker 1: that can see absolutely everything. But with all these logs,
Speaker 1: all these sinkholes, all these packet captures, do we actually
Speaker 1: have the human bandwidth to understand what we're looking at,
Speaker 1: or are we just building a haystack so big we'll
Speaker 1: never find the needle.
Speaker 2: That is the operational challenge of the next decade. We
Speaker 2: have the data, now we need the wisdom to use it.
Speaker 1: Thanks for diving deep with us today. Check your port
Speaker 1: eighty three zero five, wait your five minutes, and we'll
Speaker 1: see you on the next one.