WEBVTT 1 00:00:00.240 --> 00:00:03.279 I want to start today with a concept that sounds 2 00:00:03.319 --> 00:00:07.080 fantastic in a marketing brochure but usually creates a massive 3 00:00:07.120 --> 00:00:10.080 headache for the engineers actually doing the work. Oh yeah, 4 00:00:10.119 --> 00:00:14.000 it's convergence. You know that moment when an industry decides 5 00:00:14.039 --> 00:00:18.000 to take two completely different powerful technologies, mash them together 6 00:00:18.600 --> 00:00:21.399 and pray they work as a single unit. 7 00:00:21.600 --> 00:00:25.600 Right, Yeah, it's the whole Frankenstein phase of technology. Sometimes 8 00:00:25.640 --> 00:00:28.120 you get a monster that destroys the village, and sometimes 9 00:00:28.120 --> 00:00:30.600 you get something that actually changes the industry exactly. 10 00:00:30.920 --> 00:00:33.439 And today's deep dive is squarely focused on one of 11 00:00:33.439 --> 00:00:38.240 the most significant and frankly complex convergences in network security history. 12 00:00:38.600 --> 00:00:42.399 We are talking about the marriage of Cisco's legendary ASA. 13 00:00:42.039 --> 00:00:44.039 Firewall, the absolute workhorse, all. 14 00:00:43.960 --> 00:00:46.439 Right, the workhoorse of the two thousands, and source fire, 15 00:00:46.600 --> 00:00:48.920 which is the intelligence engine that brought us snort. 16 00:00:49.240 --> 00:00:52.240 This was a massive moment. You had the sturdy, packet 17 00:00:52.320 --> 00:00:56.079 shuffling brawn of Cisco meeting the deep packet inspection brains 18 00:00:56.119 --> 00:00:58.399 a Source Fire. Yeah. It was a logical match, but 19 00:00:58.479 --> 00:01:01.479 the integration wasn't exactly seamless. 20 00:01:01.719 --> 00:01:04.280 Yeah. Not seamless is a polite way of putting it 21 00:01:04.840 --> 00:01:07.879 as anyone listening who has managed these boxes knows it 22 00:01:08.000 --> 00:01:11.760 wasn't exactly a smooth honeymoon. So to help us navigate this, 23 00:01:11.920 --> 00:01:16.040 we are analyzing a comprehensive technical guide titled Cisco FTD 24 00:01:16.120 --> 00:01:18.599 Configuration and Troubleshooting Best Practices. 25 00:01:19.040 --> 00:01:21.840 And the author there is nasmal rejib. 26 00:01:21.599 --> 00:01:23.359 Right from Cisco Tech's take, and that. 27 00:01:23.319 --> 00:01:26.640 Author credential is key take. The technical assistance center is 28 00:01:26.680 --> 00:01:29.359 where you go when the documentation fails. These guys see 29 00:01:29.359 --> 00:01:31.840 the edge cases, the crashes, the things that aren't supposed 30 00:01:31.840 --> 00:01:34.159 to happen. So you know, this isn't a sales pitch. 31 00:01:34.359 --> 00:01:37.000 It's a survival guide for the Firepower Threat Defense System 32 00:01:37.359 --> 00:01:38.439 or FTD. 33 00:01:39.120 --> 00:01:41.879 Our mission today for you listening is to decode the 34 00:01:42.000 --> 00:01:45.760 architecture of FTD, understand how it actually catches bad actors 35 00:01:45.840 --> 00:01:48.400 using things like sinkholes, and crucially, how to fix it 36 00:01:48.439 --> 00:01:51.159 when the lights turn amber. But we really have to 37 00:01:51.200 --> 00:01:54.000 start with the identity crisis. So the naming, Yeah, the 38 00:01:54.040 --> 00:01:56.920 source material spends a surprising amount of time just clarifying 39 00:01:56.920 --> 00:01:58.239 what this thing is even called. 40 00:01:58.640 --> 00:02:01.840 It sounds trivial, doesn't it. It's just semantics. But in 41 00:02:01.879 --> 00:02:04.799 this case, the name actually tells you the architecture. If 42 00:02:04.840 --> 00:02:07.040 you get a name wrong, you're probably looking at the 43 00:02:07.079 --> 00:02:07.760 wrong manual. 44 00:02:07.879 --> 00:02:10.080 So break that down for us, we have firepower and 45 00:02:10.159 --> 00:02:11.599 firepower right. 46 00:02:11.759 --> 00:02:15.120 So before Cisco acquired source Fire in twenty thirteen, that 47 00:02:15.199 --> 00:02:20.599 technology was branded as Firepower. That's all uppercase power. If 48 00:02:20.639 --> 00:02:23.840 you see that in documentation, you're looking at the legacy era. 49 00:02:24.520 --> 00:02:27.159 Usually that meant running the source Fire services as a 50 00:02:27.199 --> 00:02:31.240 completely separate module on top of an ASA firewall. 51 00:02:30.840 --> 00:02:32.960 Like taping a smartphone to a landline phone. 52 00:02:33.000 --> 00:02:36.280 Exactly two brains, one box. But they didn't really talk 53 00:02:36.319 --> 00:02:39.919 to each other deeply. After the acquisition, Cisco moved to 54 00:02:39.960 --> 00:02:42.719 what they call the unified image. They rebranded it to 55 00:02:42.759 --> 00:02:46.080 Firepower one word lowercase power. Ah okay, So when you 56 00:02:46.080 --> 00:02:49.400 see FTD or Firepower thread defense, you were looking at 57 00:02:49.439 --> 00:02:52.800 a converged operating system. It's no longer an ASA running 58 00:02:52.800 --> 00:02:54.960 a source fire app. It is a single OS that 59 00:02:55.000 --> 00:02:56.960 handles both the routing and the thread inspection. 60 00:02:57.319 --> 00:03:00.280 And that's a critical distinction. If you're trying trying to 61 00:03:00.319 --> 00:03:04.240 troubleshoot an FTD box using command methodologies from the old 62 00:03:04.319 --> 00:03:06.759 upper case power days, you're going to hit a wall 63 00:03:06.919 --> 00:03:07.240 you are. 64 00:03:07.319 --> 00:03:10.919 The architecture is fundamentally different. Yeah, And speaking of architecture, 65 00:03:11.439 --> 00:03:13.960 the guide makes a very strong point about how the 66 00:03:14.039 --> 00:03:18.840 traffic actually flows through this box. It introduces a concept 67 00:03:18.879 --> 00:03:21.680 that I think is the most important mental model for 68 00:03:21.719 --> 00:03:24.879 an ADMIN, which is the strict separation of the data 69 00:03:24.919 --> 00:03:28.319 plane and the management plane. It's the simple deployment topology, 70 00:03:28.800 --> 00:03:29.879 but it's vital. 71 00:03:30.039 --> 00:03:33.199 To a layperson or even a junior admin. A port 72 00:03:33.240 --> 00:03:36.039 is a port. Why does the guide insist on such 73 00:03:36.080 --> 00:03:37.400 a strict separation here? 74 00:03:37.599 --> 00:03:40.199 Think of it like a bank vault. You have the 75 00:03:40.240 --> 00:03:42.960 front door where customers the data packets come in to 76 00:03:43.039 --> 00:03:45.719 do business. That's your data traffic flowing through the inside 77 00:03:45.719 --> 00:03:48.159 and outside interfaces. Okay, but you don't want the bank 78 00:03:48.199 --> 00:03:51.520 manager who holds the combination to the vault, walking through 79 00:03:51.520 --> 00:03:53.919 that same front door with the customers. 80 00:03:53.479 --> 00:03:55.240 Because if a robber is in the lobby, or if 81 00:03:55.240 --> 00:03:57.680 the lobby is just super crowded, the manager gets stuck. 82 00:03:58.000 --> 00:04:03.360 Precisely, in FTD, the guide specifies using a dedicated management 83 00:04:03.400 --> 00:04:06.439 port often ten dot one, dot one dot two in 84 00:04:06.479 --> 00:04:09.439 the examples, that connects strictly to the brain of the operation, 85 00:04:09.800 --> 00:04:11.960 the firepower management center or FMC. 86 00:04:12.199 --> 00:04:15.159 So the FMC is the brain and the FTD device 87 00:04:15.199 --> 00:04:15.800 is the muscle. 88 00:04:15.960 --> 00:04:19.120 Correct, And you do not want your management traffic, which 89 00:04:19.120 --> 00:04:23.399 contains policy pushes, log data and sensitive configurations, mixing with 90 00:04:23.439 --> 00:04:24.600 the dirty internet traffic. 91 00:04:24.720 --> 00:04:25.360 That makes sense. 92 00:04:25.519 --> 00:04:28.040 If your data plane gets flooded by a ddous attack, 93 00:04:28.480 --> 00:04:31.319 you still need that backdoor management port to be accessible 94 00:04:31.360 --> 00:04:33.399 so you can actually fix it. If you mix them, 95 00:04:33.439 --> 00:04:35.519 you lose control exactly when you need it most. 96 00:04:36.079 --> 00:04:39.720 Now, there is a very specific umbilical cord connecting the brain, 97 00:04:40.160 --> 00:04:43.240 the FMC and the muscle, the FDD. The source calls 98 00:04:43.279 --> 00:04:44.800 it the SF tunnel. 99 00:04:44.680 --> 00:04:46.759 The SF tunnel. This is the lifeline. It's an encrypted 100 00:04:46.759 --> 00:04:49.759 tunnel where all the communication happens. Heartbeats to check out 101 00:04:49.759 --> 00:04:52.680 the devices, alive, policy updates, event logs. It all goes 102 00:04:52.720 --> 00:04:53.120 through here. 103 00:04:53.199 --> 00:04:55.439 And there is one detail in the text that felt 104 00:04:55.560 --> 00:04:57.600 like a write this down on a sticky note moment. 105 00:04:58.000 --> 00:05:00.040 TCP port eighty three zero. 106 00:04:59.879 --> 00:05:03.639 FO eighty three zero five. If you take nothing else 107 00:05:03.639 --> 00:05:06.399 away from the architecture section today, remember that number. 108 00:05:06.720 --> 00:05:09.959 Why is that specific port so critical? Walk me through 109 00:05:10.000 --> 00:05:10.519 a scenario. 110 00:05:10.600 --> 00:05:13.639 Okay, imagine you deploy a new firewall at a branch 111 00:05:13.680 --> 00:05:15.959 office you plug it in, you give it an IP, 112 00:05:16.160 --> 00:05:18.959 you can ping it. It seems fine. Sure, but back 113 00:05:19.000 --> 00:05:22.519 at headquarters, the management center shows the devices offline. You 114 00:05:22.560 --> 00:05:24.959 try to push a policy and it fails. 115 00:05:24.839 --> 00:05:26.759 But the internet is working. At the branch. 116 00:05:26.519 --> 00:05:28.920 Office, the internet works fine. The data plane is up, 117 00:05:29.600 --> 00:05:33.519 but the management plane is broken. Why because some intermediate 118 00:05:33.600 --> 00:05:36.839 router or ISP firewall in the middle is blocking Port 119 00:05:36.879 --> 00:05:38.040 eighty three zero five. 120 00:05:38.240 --> 00:05:40.120 So the brain is completely cut off from. 121 00:05:40.000 --> 00:05:43.240 The body exactly. The firewall will keep passing traffic based 122 00:05:43.279 --> 00:05:45.680 on the last known policy. It's designed to fail open 123 00:05:45.759 --> 00:05:48.439 or closed, depending on your config but it's flying blind 124 00:05:48.480 --> 00:05:51.040 regarding new updates. You can't patch it, you can't change rules. 125 00:05:51.079 --> 00:05:54.319 It's basically a zombie, so always check Port eighty three 126 00:05:54.519 --> 00:05:55.399 zero five. First. 127 00:05:55.600 --> 00:05:58.879 That's a nightmare scenario. You think you're protected, but you're 128 00:05:58.920 --> 00:06:03.600 actually stagnant. Let's move to the actual birth of this system. 129 00:06:03.959 --> 00:06:07.800 The guide walks through the reimaging process, basically wiping the 130 00:06:07.839 --> 00:06:11.879 box and installing FTD from scratch. I was expecting a 131 00:06:11.920 --> 00:06:15.879 modern click Next Wizard, but this sounds incredibly old school. 132 00:06:16.240 --> 00:06:19.680 It is surprisingly retro. We're talking about interrupting the boot 133 00:06:19.720 --> 00:06:22.879 sequence at the bios level. It feels like hacking a 134 00:06:22.920 --> 00:06:24.639 computer in a nineties movie. 135 00:06:24.839 --> 00:06:28.199 The guide mentions a specific boot menu called LILO the 136 00:06:28.240 --> 00:06:28.920 Linux loader. 137 00:06:29.240 --> 00:06:32.199 When you are converting an ASA to FTD or recovering 138 00:06:32.199 --> 00:06:34.920 a corrupted system, you have to catch the boot process. 139 00:06:35.399 --> 00:06:37.240 You'll see a prompt, often on a blue or red 140 00:06:37.319 --> 00:06:40.079 screen with blocky text, and the guide warns you you 141 00:06:40.160 --> 00:06:40.879 have to be fast. 142 00:06:41.079 --> 00:06:43.800 It says you have to select systemer store within three seconds. 143 00:06:43.839 --> 00:06:46.600 Three seconds it's a reflex test. If you miss it, 144 00:06:47.000 --> 00:06:49.399 the box boots back into the old broken image or 145 00:06:49.480 --> 00:06:51.519 tries to load and OS it isn't there. Then you 146 00:06:51.560 --> 00:06:53.920 have to power cycle the box, wait for the post 147 00:06:54.199 --> 00:06:54.879 and try again. 148 00:06:55.040 --> 00:06:57.920 It seems odd that a cutting edge security device relies 149 00:06:57.959 --> 00:06:59.519 on a three second reflex test. 150 00:07:00.120 --> 00:07:04.160 Nature of the beast underneath the slick GUI the management center, 151 00:07:04.759 --> 00:07:08.160 this is still a hardened Linux appliance, and sometimes you 152 00:07:08.199 --> 00:07:09.800 have to get your hands dirty in the console. 153 00:07:10.079 --> 00:07:13.040 And you aren't just installing one file, are you. The 154 00:07:13.120 --> 00:07:16.439 guide breaks down the installation into layers. It's not just install. 155 00:07:16.279 --> 00:07:19.480 FTD, right, You can't just slap the software on. You 156 00:07:19.480 --> 00:07:22.639 have the raman that's the firmware, the bottom layer, then 157 00:07:22.680 --> 00:07:25.279 the boot image which essentially teaches the hardware how to 158 00:07:25.319 --> 00:07:28.199 load the OS, and then the system software, which is 159 00:07:28.240 --> 00:07:29.800 the actual FTD application. 160 00:07:30.040 --> 00:07:32.959 It's like building a house foundation before you frame the walls. 161 00:07:33.079 --> 00:07:36.920 Exactly. If your ramen is outdated, the boot image won't load. 162 00:07:37.439 --> 00:07:40.480 If the boot image is wrong, the system software fails. 163 00:07:41.040 --> 00:07:42.360 You have to respect the hierarchy. 164 00:07:42.759 --> 00:07:44.480 Now, a lot of people listening are probably running this 165 00:07:44.519 --> 00:07:48.240 in a virtual environment like VMware ESX, rather than on 166 00:07:48.319 --> 00:07:52.879 physical hardware. The source had a very specific, somewhat controversial 167 00:07:52.879 --> 00:07:58.279 recommendation for disc provisioning. It explicitly recommends thick provision lazy zeroed. 168 00:07:58.040 --> 00:08:01.360 Ah the storage wars. This is a constant debate between 169 00:08:01.360 --> 00:08:03.199 network admins and storage admins. 170 00:08:03.519 --> 00:08:07.680 To the uninitiated, thick provision lazy zeroed sounds like an insult. 171 00:08:08.079 --> 00:08:10.639 You're a thick provision lazy zero It does. 172 00:08:10.439 --> 00:08:13.600 Sound like that, but here's what it actually means. Thick 173 00:08:13.600 --> 00:08:16.279 provision means you claim all the disks based up front. 174 00:08:16.720 --> 00:08:19.040 If the FTD needs one hundred gigs, you take one 175 00:08:19.079 --> 00:08:23.000 hundred gigs from the storage ray immediately. Storage admins hate 176 00:08:23.040 --> 00:08:25.000 this because it eats of capacity. They might want to 177 00:08:25.000 --> 00:08:26.079 oversubscribe right. 178 00:08:26.319 --> 00:08:29.480 They prefer thin provisioning where the disc file starts small 179 00:08:29.600 --> 00:08:30.959 and grows as you add data. 180 00:08:31.279 --> 00:08:34.919 Right, But thin is dangerous for high performance databases like 181 00:08:34.960 --> 00:08:38.159 the one inside FTD. When the database needs to write 182 00:08:38.159 --> 00:08:40.960 a massive amount of logs during an attack and it 183 00:08:41.039 --> 00:08:43.399 has to ask the hypervisor to expand the disc at 184 00:08:43.440 --> 00:08:45.919 that exact moment, you get latency. 185 00:08:46.440 --> 00:08:49.879 And in security logging, latency means dropped events exactly. 186 00:08:50.320 --> 00:08:52.399 The system might just drop the log because it can't 187 00:08:52.399 --> 00:08:55.200 write it fast enough. So thick guarantees the space is there. 188 00:08:55.519 --> 00:08:58.120 What about the lazy zeroed part? Why not eager zeroed? 189 00:08:58.440 --> 00:09:01.919 That's the compromise. Eager zero means the system writs a 190 00:09:02.039 --> 00:09:05.320 zero to every single bit on the drive before it starts. 191 00:09:05.799 --> 00:09:08.759 For a large drive that takes forever to initialize, you're 192 00:09:08.759 --> 00:09:11.279 sitting there for an hour waiting for the disk to format. 193 00:09:12.240 --> 00:09:14.720 Lazy zero reserves the space, but cleans it up on 194 00:09:14.759 --> 00:09:17.279 the fly as it writes data. It's the sweet spot 195 00:09:17.360 --> 00:09:19.120 between performance and set up time. 196 00:09:19.720 --> 00:09:22.600 Okay, so we've navigated the LILA menu, We've provisioned our 197 00:09:22.639 --> 00:09:24.879 thick discs, and the tunnel is up on poort eighty 198 00:09:24.960 --> 00:09:28.759 three zero five. The system is live. Now we get 199 00:09:28.759 --> 00:09:31.600 to the cool stuff catching the bad guys. The guide 200 00:09:31.600 --> 00:09:34.960 talks about Security Intelligence or SI. How is this different 201 00:09:35.000 --> 00:09:36.600 from just a normal firewall rule? 202 00:09:37.000 --> 00:09:39.639 This is the shift from static to dynamic. A normal 203 00:09:39.679 --> 00:09:43.039 firewall rule is static BLOCKIP one dot two, dot three, 204 00:09:43.120 --> 00:09:46.240 dot four, But bad guys change ips every hour. If 205 00:09:46.279 --> 00:09:48.960 you're relying on static rules, you're always a step behind. 206 00:09:49.399 --> 00:09:50.879 Security Intelligence is a feed. 207 00:09:51.159 --> 00:09:53.440 It blocks based on reputation, so it's like a credit 208 00:09:53.519 --> 00:09:55.919 score for IP addresses exactly. 209 00:09:56.440 --> 00:09:59.360 The system downloads a feed from Cisco Tallos that's their 210 00:09:59.440 --> 00:10:03.360 massive Threat intelligence team every thirty minutes. If an IP 211 00:10:03.679 --> 00:10:07.519 was legit yesterday but got hijacked by a botnet this morning, 212 00:10:07.960 --> 00:10:11.679 the feed updates and SI blocks it immediately. It happens 213 00:10:11.799 --> 00:10:14.519 before the traffic even hits the deeper inspection policies. 214 00:10:14.600 --> 00:10:17.960 It's a prefilter which saves processing power huge amounts. 215 00:10:18.440 --> 00:10:22.080 Why waste CPU cycles decrypting and inspecting a packet deep down? 216 00:10:22.559 --> 00:10:25.080 If you know the sender is a known spammer, just 217 00:10:25.200 --> 00:10:25.919 drop it at the door. 218 00:10:26.080 --> 00:10:27.559 But what if you don't want to just drop it? 219 00:10:27.720 --> 00:10:30.480 There's a feature here that I found fascinating called the sinkhole. 220 00:10:30.679 --> 00:10:33.399 This is my absolute favorite feature for internal defense it 221 00:10:33.480 --> 00:10:34.840 turns the tables on the attacker. 222 00:10:35.159 --> 00:10:38.679 Explain how this works because sinkhole implies the data just disappears, 223 00:10:39.080 --> 00:10:41.480 but the guide says it actually does something deceptive. 224 00:10:41.960 --> 00:10:44.519 So imagine you have an infected laptop on your network. 225 00:10:44.919 --> 00:10:47.679 Let's say Bob in accounting clicked a bad link. His 226 00:10:47.799 --> 00:10:49.720 laptop is trying to phone home to a command and 227 00:10:49.759 --> 00:10:51.399 control server to get instructions. 228 00:10:51.840 --> 00:10:54.919 Normally, the firewall would just block that connection. Bob gets 229 00:10:54.960 --> 00:10:57.200 a connection timed out and he just thinks the Wi 230 00:10:57.320 --> 00:10:59.840 fi is bad. He goes to get a coffee right, 231 00:11:00.399 --> 00:11:00.720 and you. 232 00:11:00.919 --> 00:11:03.919 The admin might see a generic block log, but you 233 00:11:04.039 --> 00:11:07.519 have thousands of logs, you might miss the urgency. With 234 00:11:07.679 --> 00:11:11.159 a DNS sinkhole, the FTD intercept to Bob's DNS request 235 00:11:11.559 --> 00:11:14.759 for evilhacker site dot com. Instead of blocking it. 236 00:11:15.000 --> 00:11:17.679 The FTD lies it lies to Bob's computer. 237 00:11:18.039 --> 00:11:20.879 It returns a fake IP address. The guide used the 238 00:11:20.919 --> 00:11:23.559 example one ninety two one sixty eight dot one dot 239 00:11:23.679 --> 00:11:26.559 ninety one. Bob's computer thinks, aha, I found the server 240 00:11:26.960 --> 00:11:29.080 and tries to send it stolen data to that IP. 241 00:11:29.159 --> 00:11:32.399 But that IP is actually a server the admin controls. 242 00:11:32.159 --> 00:11:34.399 Exactly, it's a trap. Now you can look at the 243 00:11:34.440 --> 00:11:37.120 logs of your sinkhole server and see, hey, Bob's IP 244 00:11:37.360 --> 00:11:39.440 is frantically trying to connect to me. It gives you 245 00:11:39.559 --> 00:11:42.399 a positive confirmation of who is infected. It turns the 246 00:11:42.440 --> 00:11:44.240 attack into a beacon for remediation. 247 00:11:44.600 --> 00:11:47.519 That is incredibly smart. It changes the dynamic from I 248 00:11:47.679 --> 00:11:49.879 blocked something to I caught someone. 249 00:11:50.120 --> 00:11:52.840 It enables hunting. That's the key difference. Instead of just 250 00:11:52.879 --> 00:11:56.200 playing defense, you're gathering intelligence on your own compromised hosts. 251 00:11:56.600 --> 00:11:59.639 The system also applies this reputation logic to websites via 252 00:11:59.679 --> 00:12:03.440 the webs Reputation Index or WRI. The source says this 253 00:12:03.600 --> 00:12:05.480 is a score from zero to one hundred. 254 00:12:06.000 --> 00:12:09.519 Simple scale. Zero to twenty is high risk, so malware 255 00:12:09.720 --> 00:12:14.080 phishing exploits twenty one to forty is suspicious. The cool 256 00:12:14.159 --> 00:12:16.759 thing is you can write policies based on the score, 257 00:12:16.919 --> 00:12:17.600 not the URL. 258 00:12:17.840 --> 00:12:20.200 So I can say block anything below a twenty, right, you. 259 00:12:20.200 --> 00:12:22.320 Don't need to know the URL. If a new gambling 260 00:12:22.360 --> 00:12:25.080 site pops up tomorrow and tallows scores at a fifteen, 261 00:12:25.559 --> 00:12:28.519 your policy automatically catches it. It automates the cat and 262 00:12:28.600 --> 00:12:29.039 mouse game. 263 00:12:29.200 --> 00:12:31.600 But, and there is always a lit but to do 264 00:12:31.679 --> 00:12:35.240 all this fancy inspection. You need the right paperwork. We 265 00:12:35.360 --> 00:12:37.879 have to talk about licensing. The guide makes a distinction 266 00:12:38.000 --> 00:12:39.399 here that I think trips a lot of people up 267 00:12:40.039 --> 00:12:42.240 threat license versus malware license. 268 00:12:42.519 --> 00:12:45.039 It is very confusing. You'd think the threat license would 269 00:12:45.080 --> 00:12:47.200 cover malware right. It sounds like the exact same thing. 270 00:12:47.279 --> 00:12:49.759 We really would, but in Cisco speak, they are entirely 271 00:12:49.840 --> 00:12:53.120 different functions. A threat license gives you file type control. 272 00:12:53.399 --> 00:12:55.440 It lets the system see what a file is. This 273 00:12:55.600 --> 00:12:58.440 is a PDF, this is an EXE. You can use 274 00:12:58.480 --> 00:13:00.399 that to say block all ex but it. 275 00:13:00.440 --> 00:13:03.320 Doesn't know if the ex is good or bad, no clue. 276 00:13:03.559 --> 00:13:05.759 It just sees the container to see if the contents 277 00:13:05.799 --> 00:13:09.320 are malicious. You need the malware license that enables AMP 278 00:13:09.559 --> 00:13:10.720 Advanced Malware Protection. 279 00:13:11.279 --> 00:13:12.759 And that's where the cloud comes back in. 280 00:13:13.360 --> 00:13:17.399 Right. AMP calculates a hash, a digital fingerprint of the file, 281 00:13:17.720 --> 00:13:21.000 and asks the tellis cloud, have you seen this fingerprint before? 282 00:13:21.320 --> 00:13:21.799 Is it bad? 283 00:13:22.159 --> 00:13:23.480 And if the cloud has never seen it. 284 00:13:23.799 --> 00:13:27.200 Then they can actually upload the file for dynamic analysis, 285 00:13:27.600 --> 00:13:29.799 running it in a sandbox in the cloud to see 286 00:13:29.840 --> 00:13:32.679 what it does. That's the sparal analysis engine mentioned in 287 00:13:32.759 --> 00:13:33.120 the text. 288 00:13:33.320 --> 00:13:36.720 The guide notes that if you have automatic local malware 289 00:13:36.799 --> 00:13:40.559 detection updates checked. It pulls signatures every thirty minutes. Is 290 00:13:40.600 --> 00:13:42.240 thirty minutes fast enough in today's world. 291 00:13:42.440 --> 00:13:45.559 It's a balance. Real time lookups happen for every file, 292 00:13:46.279 --> 00:13:49.240 but the local signature set the stuff the box knows 293 00:13:49.279 --> 00:13:52.399 without asking. The cloud needs to update frequently to keep 294 00:13:52.480 --> 00:13:55.840 latency down. Thirty minutes is the industry standard for near 295 00:13:55.960 --> 00:13:58.080 real time without crashing your bandwidth. 296 00:13:58.159 --> 00:14:02.159 Okay, so we've got the system our detected, installed, licensed 297 00:14:02.279 --> 00:14:07.399 and sinking holes. But eventually something breaks the dashboard turns red. 298 00:14:07.879 --> 00:14:10.799 The guide's troubleshooting section is extensive, but the author seems 299 00:14:10.840 --> 00:14:11.799 to have a favorite tool. 300 00:14:12.039 --> 00:14:13.919 He's a tack engineer, of course. His favorite tool is 301 00:14:13.960 --> 00:14:17.080 the command line caps traffic, the ultimate source of truth. 302 00:14:17.679 --> 00:14:20.879 The command is capture traffic, but under the hood it's 303 00:14:20.960 --> 00:14:23.440 using TCP dump. It allows you to see the raw 304 00:14:23.519 --> 00:14:24.679 packets hitting the interface. 305 00:14:24.840 --> 00:14:26.799 Why is this better than looking at the nice graphical 306 00:14:26.840 --> 00:14:27.799 logs in the FMC. 307 00:14:28.240 --> 00:14:30.960 The FMC tells you what the policy did. I blocked 308 00:14:31.000 --> 00:14:33.799 this because of rule five, but capture traffic shows you 309 00:14:33.919 --> 00:14:36.759 what is actually on the wire. Are the packets malformed? 310 00:14:37.320 --> 00:14:40.559 Is the three way handshake? Failing is the latency happening 311 00:14:40.639 --> 00:14:42.240 before or after the firewall. 312 00:14:42.639 --> 00:14:45.879 The guide mentions using flags like dash N and dash X, 313 00:14:45.960 --> 00:14:46.720 what are those doing. 314 00:14:47.039 --> 00:14:49.639 Dash in stops the system from trying to resolve DNS 315 00:14:49.799 --> 00:14:53.559 names for every packet, which significantly speeds up the capture. 316 00:14:53.879 --> 00:14:56.080 If you don't use dash N, your capture might lieg 317 00:14:56.240 --> 00:14:57.720 just because it's trying to figure out the name of 318 00:14:57.799 --> 00:15:00.840 every single server. And dash X dash is the power move. 319 00:15:01.480 --> 00:15:04.120 Da X displays the payload in both hex and as. 320 00:15:04.080 --> 00:15:06.000 Key, so you can actually read the data. 321 00:15:06.159 --> 00:15:07.879 You can read the data inside the packet. If an 322 00:15:07.879 --> 00:15:10.240 application is failing, you can see if the server is 323 00:15:10.279 --> 00:15:12.759 sending back a four or four error or access denied 324 00:15:12.919 --> 00:15:15.799 or a SEQL error right inside the packet trace. It 325 00:15:15.919 --> 00:15:19.120 removes the mystery. If computer says no, you can see 326 00:15:19.159 --> 00:15:20.480 exactly why computer says no. 327 00:15:20.840 --> 00:15:23.759 Sometimes, though the problem isn't the traffic, it's the box 328 00:15:23.840 --> 00:15:28.000 itself running out of steam. The guide distinguishes between overruns 329 00:15:28.039 --> 00:15:31.559 and no buffer. These sound completely synonymous to me. 330 00:15:32.200 --> 00:15:35.519 They both mean dropped packets, but the cause is completely different, 331 00:15:35.840 --> 00:15:38.240 and knowing the difference saves you hours of troubleshooting. 332 00:15:38.399 --> 00:15:39.320 Break it down for us. 333 00:15:39.679 --> 00:15:43.200 Overruns happen at the network card level, the NIC is 334 00:15:43.240 --> 00:15:46.000 receiving packets faster than the CPU can take them off 335 00:15:46.039 --> 00:15:50.960 the interface. It's a speed mismatch. The CPU is the bottleneck. 336 00:15:50.840 --> 00:15:53.759 So overrun means CPU is too slow or traffic is 337 00:15:53.799 --> 00:15:55.279 too birsty exactly. 338 00:15:55.840 --> 00:15:57.960 No buffer, on the other hand, means the CPU is 339 00:15:58.039 --> 00:15:59.639 keeping up, but it has nowhere to put the packets 340 00:15:59.679 --> 00:16:01.960 while it processes them the memory. 341 00:16:01.799 --> 00:16:04.759 The RAM is full, so no buffer equals out of RAM. 342 00:16:05.120 --> 00:16:07.720 Generally, yes, if you see overruns, you might need a 343 00:16:07.759 --> 00:16:10.480 faster box, or you need to offload some traffic. If 344 00:16:10.519 --> 00:16:12.639 you see no buffer, you might need to tune your 345 00:16:12.679 --> 00:16:15.159 inspection policies to be less memory intensive. 346 00:16:15.600 --> 00:16:19.600 Finally, the guide covers the Amber led scenario hardware failure, 347 00:16:20.120 --> 00:16:22.120 and it offers a safety tip that I feel applies 348 00:16:22.159 --> 00:16:24.480 to every piece of electronics I own, but I always 349 00:16:24.519 --> 00:16:24.879 ignore it. 350 00:16:25.000 --> 00:16:26.000 The wait five minutes rule. 351 00:16:26.159 --> 00:16:28.320 We all know turn it off and on again, but 352 00:16:28.440 --> 00:16:33.200 the guide explicitly says, unplug the power supply unit and 353 00:16:33.320 --> 00:16:35.159 wait five minutes before plugging it back in. 354 00:16:35.360 --> 00:16:37.440 It's not just superstition or a way to make you 355 00:16:37.480 --> 00:16:40.159 take a coffee break. It's about residual charge. The electricity 356 00:16:40.200 --> 00:16:44.000 stays inside the capacitors inside the power supply hold electricity 357 00:16:44.200 --> 00:16:46.559 even after you unplug it. If you plug it back 358 00:16:46.600 --> 00:16:49.600 in immediately, the memory and controllers might not have fully 359 00:16:49.679 --> 00:16:52.840 reset because they never lost power completely. They were running 360 00:16:52.840 --> 00:16:53.559 on fume. 361 00:16:53.399 --> 00:16:55.639 So the air state persists exactly. 362 00:16:55.720 --> 00:16:57.799 You have to let the box drain completely to get 363 00:16:57.840 --> 00:17:01.600 a true cold boot. Patients is a troubleshooting tool here. 364 00:17:01.720 --> 00:17:04.400 I like that, so let's zoom out. We've gone from 365 00:17:04.440 --> 00:17:07.039 the merger of source Fire and Cisco, through the three 366 00:17:07.160 --> 00:17:10.640 second Lilo boot challenge, down the encrypted s of tunnel 367 00:17:11.000 --> 00:17:13.119 and into the nitty gritty of hex. 368 00:17:13.000 --> 00:17:15.559 Packet captures the beast of a system. It really shows 369 00:17:15.599 --> 00:17:17.960 how far we've come from simple packet filtering. 370 00:17:18.160 --> 00:17:21.200 It really highlights a philosophical shift in our industry. Ten 371 00:17:21.319 --> 00:17:24.640 fifteen years ago, a firewall was just a gatekeeper open 372 00:17:24.720 --> 00:17:27.559 port eighty, close port twenty three. Simple. 373 00:17:27.880 --> 00:17:30.400 It was entirely binary, yes or no. You didn't care 374 00:17:30.480 --> 00:17:32.680 what was inside the packet, just where it was going. 375 00:17:32.920 --> 00:17:36.279 But FTD represents context. It's not just the port, it's 376 00:17:36.839 --> 00:17:39.960 who is this user? What is this file? What is 377 00:17:40.000 --> 00:17:42.680 the reputation of this website? Is this packet part of 378 00:17:42.799 --> 00:17:44.319 a known attack pattern. 379 00:17:44.440 --> 00:17:47.279 It's the difference between a security guard who checks your 380 00:17:47.319 --> 00:17:50.279 ID badge at the door and a detective who follows 381 00:17:50.319 --> 00:17:53.240 you around the building, reads your mail, checks your credit score, 382 00:17:53.519 --> 00:17:54.920 and watches who you talk to. 383 00:17:55.200 --> 00:17:57.960 That is a massive amount of visibility, and that leads 384 00:17:58.000 --> 00:17:59.680 me to the final thought. I want to leave everyone 385 00:17:59.680 --> 00:18:03.880 listening with The guide briefly mentions private IP addresses RFC 386 00:18:04.079 --> 00:18:07.079 nineteen eighteen as a way to conserve public eyeps, But 387 00:18:07.200 --> 00:18:10.759 originally we also viewed GNAT network address translation as a 388 00:18:10.839 --> 00:18:11.680 form of obscurity. 389 00:18:11.880 --> 00:18:14.720 What happens behind the firewall stays behind the farewell exactly. 390 00:18:15.000 --> 00:18:18.240 But with FTD and this move toward total visibility, we 391 00:18:18.319 --> 00:18:21.119 are flipping that on its head. To protect the network, 392 00:18:21.160 --> 00:18:24.960 the admin needs to see everything, every URL, every filed download, 393 00:18:25.039 --> 00:18:28.559 every DNS request. We are even decrypting SSL traffic to 394 00:18:28.599 --> 00:18:29.200 see inside it. 395 00:18:29.440 --> 00:18:32.079 We are removing the obscurity to find the threats hiding 396 00:18:32.119 --> 00:18:32.599 in the noise. 397 00:18:32.880 --> 00:18:35.160 The question this manual leaves me with is not really 398 00:18:35.200 --> 00:18:38.720 about privacy, but about capacity. We have built a machine 399 00:18:38.759 --> 00:18:41.759 that can see absolutely everything. But with all these logs, 400 00:18:41.880 --> 00:18:45.400 all these sinkholes, all these packet captures, do we actually 401 00:18:45.519 --> 00:18:48.920