Cisco Secure Firewall (FTD) Configuration Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

Where Cisco Secure Firewall Threat Defense sits

FTD is usually driven by a manager. The device CLI is for bootstrap, troubleshooting, and the cases your operating model still does locally. Hostname and management reachability are device-level. Policy is the manager's job unless you have deliberately chosen local management. A change in the manager is not installed until the deploy finishes. A deploy that fails leaves the previous policy, and you should read the result before you test.

Do not treat this as an ASA with a new coat of paint. An ASA paste is the wrong language. If the manager owns the policy, a local edit is a future outage when the manager pushes. Decide the owner in the ticket.

Use a lab or the first closet, not the core, for the first week you touch Cisco Secure Firewall Threat Defense. The change window still needs a ticket, a test host, and the rollback above. Automation comes after you can do the boring change by hand and get back. The automation guide is that sequence. This page is the dialect.

Management belongs on a prefix you named, over SSH or the platform's equivalent, from a jump host. The hardening guide is the standard. This page does not open Telnet, does not permit the world, and does not put a password in the clear for you to copy. If a generator shows a placeholder password, replace it before the device is reachable.

A lab change, one step at a time

Step 1 on Cisco Secure Firewall Threat Defense is about the hostname. The lab text is: Set the hostname to edge-01 in the platform's own command or screen. Logs and VPN peers use this name. This is a starter for a firewall you change in a window with a console path. It uses documentation addresses where an address appears, and it uses the token prompt-for-this wherever a secret would go. Replace that token. Do not save a secret from a guide. After the step, check: The login banner or the prompt shows edge-01.. If the check fails, stop. The way back is: the previous policy you exported, or the platform rollback you have used in a lab. Do not type the next step on top of a failed one. Cisco Secure Firewall Threat Defense only keeps a change the way its own save model describes: the platform's commit or save, practised, and not a Cisco write memory unless this platform is the one that uses it. A neighbouring vendor's save command is not this one. The generators linked from this page draft the same kind of starter in the browser. They do not log in. Read their banner, then read this step, then decide. A line that looks familiar from Cisco IOS is not a reason to paste it into Cisco Secure Firewall Threat Defense.

Step 2 on Cisco Secure Firewall Threat Defense is about management from one prefix. The lab text is: Allow SSH or the admin UI only from 192.0.2.0/24 in this lab, and from your real management prefix in production. A firewall you can administer from the Internet is a firewall you will lose. This is a starter for a firewall you change in a window with a console path. It uses documentation addresses where an address appears, and it uses the token prompt-for-this wherever a secret would go. Replace that token. Do not save a secret from a guide. After the step, check: A test from outside that prefix is refused.. If the check fails, stop. The way back is: the previous policy you exported, or the platform rollback you have used in a lab. Do not type the next step on top of a failed one. Cisco Secure Firewall Threat Defense only keeps a change the way its own save model describes: the platform's commit or save, practised, and not a Cisco write memory unless this platform is the one that uses it. A neighbouring vendor's save command is not this one. The generators linked from this page draft the same kind of starter in the browser. They do not log in. Read their banner, then read this step, then decide. A line that looks familiar from Cisco IOS is not a reason to paste it into Cisco Secure Firewall Threat Defense.

Step 3 on Cisco Secure Firewall Threat Defense is about zones or interfaces. The lab text is: Name the inside and the outside. Do not leave an interface in a zone you did not choose. Policy attaches to zones on the platforms that use zones. A nameless interface is an accident. This is a starter for a firewall you change in a window with a console path. It uses documentation addresses where an address appears, and it uses the token prompt-for-this wherever a secret would go. Replace that token. Do not save a secret from a guide. After the step, check: Each interface is in the zone the ticket names.. If the check fails, stop. The way back is: the previous policy you exported, or the platform rollback you have used in a lab. Do not type the next step on top of a failed one. Cisco Secure Firewall Threat Defense only keeps a change the way its own save model describes: the platform's commit or save, practised, and not a Cisco write memory unless this platform is the one that uses it. A neighbouring vendor's save command is not this one. The generators linked from this page draft the same kind of starter in the browser. They do not log in. Read their banner, then read this step, then decide. A line that looks familiar from Cisco IOS is not a reason to paste it into Cisco Secure Firewall Threat Defense.

Step 4 on Cisco Secure Firewall Threat Defense is about a narrow policy. The lab text is: Permit one inside prefix to one destination and one port. Deny the rest. Any-to-any is not a lab success. It is the absence of a policy. This is a starter for a firewall you change in a window with a console path. It uses documentation addresses where an address appears, and it uses the token prompt-for-this wherever a secret would go. Replace that token. Do not save a secret from a guide. After the step, check: A host outside the rule cannot pass, and a host inside the rule can pass to that one destination.. If the check fails, stop. The way back is: the previous policy you exported, or the platform rollback you have used in a lab. Do not type the next step on top of a failed one. Cisco Secure Firewall Threat Defense only keeps a change the way its own save model describes: the platform's commit or save, practised, and not a Cisco write memory unless this platform is the one that uses it. A neighbouring vendor's save command is not this one. The generators linked from this page draft the same kind of starter in the browser. They do not log in. Read their banner, then read this step, then decide. A line that looks familiar from Cisco IOS is not a reason to paste it into Cisco Secure Firewall Threat Defense.

Step 5 on Cisco Secure Firewall Threat Defense is about a route. The lab text is: Route the inside prefix and a default, or the specific prefix the ticket names, via the next hop you can ping. A policy that permits a prefix you do not route is a policy that never fires. This is a starter for a firewall you change in a window with a console path. It uses documentation addresses where an address appears, and it uses the token prompt-for-this wherever a secret would go. Replace that token. Do not save a secret from a guide. After the step, check: The route matches a test address.. If the check fails, stop. The way back is: the previous policy you exported, or the platform rollback you have used in a lab. Do not type the next step on top of a failed one. Cisco Secure Firewall Threat Defense only keeps a change the way its own save model describes: the platform's commit or save, practised, and not a Cisco write memory unless this platform is the one that uses it. A neighbouring vendor's save command is not this one. The generators linked from this page draft the same kind of starter in the browser. They do not log in. Read their banner, then read this step, then decide. A line that looks familiar from Cisco IOS is not a reason to paste it into Cisco Secure Firewall Threat Defense.

Step 6 on Cisco Secure Firewall Threat Defense is about logs. The lab text is: Log the denies you care about to a server that is not the firewall. A deny you cannot see will be called a routing bug. This is a starter for a firewall you change in a window with a console path. It uses documentation addresses where an address appears, and it uses the token prompt-for-this wherever a secret would go. Replace that token. Do not save a secret from a guide. After the step, check: A test deny produced a log line.. If the check fails, stop. The way back is: the previous policy you exported, or the platform rollback you have used in a lab. Do not type the next step on top of a failed one. Cisco Secure Firewall Threat Defense only keeps a change the way its own save model describes: the platform's commit or save, practised, and not a Cisco write memory unless this platform is the one that uses it. A neighbouring vendor's save command is not this one. The generators linked from this page draft the same kind of starter in the browser. They do not log in. Read their banner, then read this step, then decide. A line that looks familiar from Cisco IOS is not a reason to paste it into Cisco Secure Firewall Threat Defense.

Step 7 on Cisco Secure Firewall Threat Defense is about the save. The lab text is: Commit or save with the platform's command, then export a backup. An uncommitted candidate is not a change. A committed change you cannot restore is a trap. This is a starter for a firewall you change in a window with a console path. It uses documentation addresses where an address appears, and it uses the token prompt-for-this wherever a secret would go. Replace that token. Do not save a secret from a guide. After the step, check: The backup opens on another machine.. If the check fails, stop. The way back is: the previous policy you exported, or the platform rollback you have used in a lab. Do not type the next step on top of a failed one. Cisco Secure Firewall Threat Defense only keeps a change the way its own save model describes: the platform's commit or save, practised, and not a Cisco write memory unless this platform is the one that uses it. A neighbouring vendor's save command is not this one. The generators linked from this page draft the same kind of starter in the browser. They do not log in. Read their banner, then read this step, then decide. A line that looks familiar from Cisco IOS is not a reason to paste it into Cisco Secure Firewall Threat Defense.

# FTD lab shape. Prefer the manager for policy.
# Device hostname edge-01
# Manager or local management, one owner
# Policy: one inside prefix, one destination, one port
# Deploy, then test. Review before you deploy.

After the lab is boring

When the lab hostname, the management address, one user VLAN, and one route or one policy all behave, write the rollback and the save command on a card next to the console. The on-call will not reread this pillar at 2 a.m. They will read the card. If the card disagrees with this page, fix the card after you confirm which one matches the software version you run. Versions drift. A command that worked on the previous train may be refused or may mean something narrower.

Back up the configuration once you have saved it the platform's way. Keep that backup off the device. A device you can rebuild from a backup is a device you can harden without fear. A device whose only configuration is the running memory is a device people are afraid to secure, so they leave extra services on. The hardening pass comes after the backup exists, not before.

Compare the generator's draft to this lab before you point the generator at a real site. The draft should be smaller than your wish list. A VLAN, a management restriction, and a route are enough for a first production use. A draft that also turns on every feature the form offered is a draft to trim. The diff is the change. The vendor guide is not a reason to apply every example in one window.

Document the software version, the save command, and the out-of-band path in the same inventory line as the hostname. Migrations fail when that line is missing. The migration guide assumes you can still reach the box when the new path is wrong. Cisco Secure Firewall Threat Defense does not suspend that rule.

Cisco Secure Firewall Threat Defense checks before the first production save

Confirm this before you call the change done: The lab is not the production core. prompt-for-this was replaced and the secret is not in the ticket. Management is limited to a named prefix. The save command on the card matches Cisco Secure Firewall Threat Defense, not a different vendor. A backup exists off the device before you harden it. The test host is in the VLAN you built, and a host outside it was not accidentally included. The rollback was used once in the lab. The generator draft was trimmed to the ticket. No route or policy permits the world as a convenience. Documentation prefixes are gone before production cutover. The software version is written next to the hostname. Out-of-band access was tested. A second person read the allowed VLAN or the policy aloud. And telnet and any wide web management stay off. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.