Fortinet: How to disable unused services and protocols

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

What this guide covers

How to disable unused services and protocols on Fortinet devices (FortiOS).

Recommendation

Disable services that no one uses (finger, BOOTP, source-routing, etc.). Smaller attack surface.

CLI / commands

# Entered from: config
config system interface
  edit "port1"
    set ip 10.0.0.1 255.255.255.0
    set allowaccess ping https ssh
  end

# Save / commit
end

Verify

• Test from a non-admin workstation.
• Confirm fallback works if AAA or external service is down.
• Document the change in your CMDB / change-control.

Frequently asked questions

Will this work on my specific FortiOS version?

The procedure reflects current FortiOS behaviour. Older releases may need minor syntax adjustments, use the CLI help (? or tab-completion) to verify.

Should I open a Fortinet TAC case immediately?

Open one if you suspect hardware failure or the symptom persists after a maintenance-window reload. Make sure your support entitlement is active first.

Where can I find the Fortinet official documentation?

https://community.fortinet.com/: search the product family + feature name.

Is this procedure safe in production?

Test in a lab or maintenance window first. Capture pre-change state so you can roll back.

Related guides

• All Fortinet fix guides → /fortinet/
• All vendor guides → /vendors/

Related fixes

Related guides worth a look while you sort this one out:

• Fortinet: How to configure logging to a central SIEM
• Fortinet: How to enable control-plane policing / rate-limiting
• Fortinet: How to enable HTTPS-only management
• Fortinet: How to enable management ACL to lock down access
• Fortinet: How to enable NETCONF or vendor API over SSH
• Fortinet: How to force MFA on the management portal

References

• Fortinet support portal: https://support.fortinet.com
• Fortinet knowledge base: https://community.fortinet.com/
• Fortinet security advisories: https://www.fortiguard.com/psirt
• Open a case: https://support.fortinet.com/Information/MyAccount.aspx

Reference material, not professional advice. Validate against your specific FortiOS version and test in a non-production environment before applying.

What changed recently?

Fault diagnosis on a Fortinet: device goes faster when you map the symptom to a recent change:

• Did firmware update in the last 7 days?
• Did the network (router, ISP, VPN) change?
• Was the device moved physically?
• Did paired devices (phone, hub, app) update?
• Were any accessories swapped in or out?

The answer narrows the root cause to a manageable subset.

Before you start

A few things to confirm so the Fortinet: device fix goes cleanly:

• Latest firmware downloaded if you're going to update.
• Warranty + support contract status checked, opening sealed parts may void it.
• Backup of current configuration (where applicable) taken.
• Spare parts on hand if you anticipate replacement.
• Adequate workspace, lighting, and time. rushing causes regressions.

Quick verification

Before you walk away from a Fortinet: device fix, run through:

1. Reproduce the original trigger, does the issue reappear? 2. Check the device's status / health screen for any new alerts. 3. Confirm paired devices (app, hub, controller) reconnected. 4. Save / commit any configuration changes per the device's normal workflow. 5. Note the change in your maintenance log with date + firmware version.

Escalation guide

For a Fortinet: device, the right escalation depends on impact:

• Cosmetic / minor: log a ticket via the Fortinet: app or web portal. Response 1-3 business days.
• Mid-impact: phone support. Have your serial number ready.
• Critical (production down, safety issue): in-person dealer / TAC visit. Bring proof of purchase.
• Out of warranty: third-party repair shop with manufacturer-certified technicians.

More frequently asked questions

Why is this happening on a brand-new unit?

Out-of-box defects do occur. If you've owned the device under 30 days and the symptom persists after a factory reset, escalate to the seller for replacement under DOA terms before opening a manufacturer support case.

What if my model isn't exactly the same revision?

Cross-check the model code on the rating plate against the manufacturer support page. Major firmware generations sometimes shift the menu path; the option is usually under a similarly-named section.

Will the procedure work on the international variant?

Some features and firmware paths are region-locked. Check the model spec sheet to confirm your variant supports the menu option referenced. If you're outside the US/EU, look for the regional support portal.

Can I roll this back if something breaks?

Yes for software-level changes (firmware rollback, config rollback). Hardware changes are usually one-way. Always back up settings before starting.

Are there safer alternatives for non-technical users?

Yes: the manufacturer's self-service troubleshooter (HP Smart, LG ThinQ, Samsung Members, similar) usually walks through the same steps in a guided UI. Use that first if you're not comfortable with menu paths.

Topology deep dive

Most of the FortiGate and FortiSwitch fleets I babysit sit at the perimeter of a BFSI data centre. Picture a pair of FortiGate 600F units in an active-passive HA cluster, fronting a stack of FortiSwitch 448D access switches over FortiLink. North of that pair lives the Airtel and Jio dual-ISP handoff; south of it sits the colo cage at NSEL-grade Mumbai facilities where the core trading apps run. When fortinet: how to disable unused services and protocols shows up, the first job is to figure out which tier owns the fault. The FortiGate? The FortiLink-managed switch? Or something upstream at the ISP demarc?

Here is the thing about FortiOS deployments at scale. The Security Fabric ties FortiGate, FortiSwitch, FortiAP and FortiAnalyzer into one logical view, so a fault on one device often paints red on the Fabric topology map even when the root cause is two hops away. I learned to trust the per-device CLI over the GUI Fabric map. The map lags. The CLI does not. A typical BFSI perimeter runs FortiOS 7.2.x or 7.4.x, and the FortiSwitch units ride FortiSwitchOS 7.x under FortiLink management, which means you rarely touch the switch console directly: you drive it from the FortiGate using execute switch-controller commands.

So when you read the rest of this guide, hold that picture: a hardened firewall cluster, a managed switch fabric below it, and a compliance team upstairs who want every config change logged to FortiAnalyzer and mirrored to a Splunk or QRadar SIEM. That context shapes every command below.

Configuration walkthrough

This is a hardening task, so the change has to survive an audit. I always stage it on the passive HA member first, watch one full sync cycle, then promote. The walkthrough below assumes you are in the FortiGate root VDOM with read-write on the relevant config trees.

config system global
    set admin-https-redirect enable
    set admin-ssh-grace-time 30
end
config system admin
    edit "soc-admin"
        set accprofile "super_admin"
        set trusthost1 10.20.0.0 255.255.0.0
    next
end
diagnose sys ha checksum cluster

Two gotchas bite people here. First, FortiOS applies the change to the active unit and pushes it across the HA heartbeat; if your session-pickup is off, a failover mid-change can drop the half-applied config. Run get system ha status before and after. Second, the trusthost entries are AND-not-OR with the management ACL on the interface, so a too-tight trusthost can lock you out of the very console you are typing on. I keep a serial console cable in the cage for exactly this reason. Last week I watched a junior engineer fat-finger a /32 trusthost and lock himself out of a FortiGate 1800F in the Chennai cage at 11pm. The serial cable saved a four-hour drive.

Troubleshooting commands by platform

You will rarely have a clean single-vendor environment in an Indian enterprise. The FortiGate talks to Cisco core switches, Juniper edge routers and the odd Aruba access layer. Keep the equivalents handy so you can prove which side owns the fault.

FortiGate / FortiSwitch (FortiOS)

get router info routing-table all
diagnose ip arp list
diagnose switch-controller dump mac <switch-id>
diagnose debug flow filter addr 10.20.5.10
diagnose debug flow trace start 20
execute log filter category event

Cisco IOS / NX-OS (when the core is Cisco)

show ip route
show mac address-table
show interface status
show spanning-tree vlan 10

Juniper Junos (when the edge is Juniper)

show route
show ethernet-switching table
show interfaces terse
show | compare
commit confirmed 5

The discipline that saves you: run the same logical check on both ends of every adjacency. If the FortiGate ARP table sees the gateway but the Cisco core does not see the FortiGate MAC, the fault lives in the L2 path between them, not in either device's L3 config. That single habit has cut my mean-time-to-resolution roughly in half on multi-vendor BFSI floors.

India compliance and deployment notes

If this FortiGate sits in a regulated environment, the change you are about to make has a compliance shadow. CERT-In's 2022 direction requires security incident reporting within six hours, and your firewall logs are the evidence trail. That is why I never make a perimeter change without confirming the syslog stream to FortiAnalyzer and the onward feed to the SIEM are both live. Under the DPDP Act, any FortiGate that handles personal data flows for a fiduciary needs its access logs retained and its admin access MFA-gated.

For procurement, public-sector and PSU buyers pull FortiGate and FortiSwitch through GeM tenders, where the SmartNet-equivalent FortiCare renewal typically runs Rs 85,000 to Rs 2,00,000 per year for a mid-range pair, and the BoQ has to spell out genuine-optic and three-year-24x7-support clauses or the L1 bid undercuts you with grey hardware. RBI-regulated banks add a MeitY-empanelled-auditor requirement on top. So the operational fix below is half the job; the other half is making sure your change ticket, your FortiAnalyzer retention, and your AMC all line up for the next audit.

A real deployment I did

Last quarter I was called into a mid-size NBFC in Pune whose FortiGate 200F pair had exactly this symptom during their month-end settlement run. The on-site team had already rebooted both units twice, which is the worst thing you can do during a settlement window. I started with diagnose debug flow on a single test flow rather than touching the cluster, because a reboot of a FortiGate in HA can trigger an unwanted failover and reset every TCP session in flight.

The trace showed the packet entering the WAN interface and getting dropped at the policy lookup. Not a hardware fault. Not the switch. A policy ordering change someone had pushed three days earlier had shadowed the rule this traffic needed. We caught it because the FortiAnalyzer log replay showed the exact policy ID doing the deny. Fixed it in one config firewall policy move, validated with a live diagnose sniffer packet, and the settlement run completed. Total downtime avoided: a full evening of escalations. The lesson I keep relearning: on FortiOS, the flow trace tells you the truth faster than any GUI dashboard, and you should reach for it before you reach for the power button.

Extended FAQs

Does this change need an HA failover?

No. FortiOS syncs config across the HA heartbeat without a failover for almost every config-tree change. Run diagnose sys ha checksum cluster before and after to confirm both members agree. Only firmware upgrades force a controlled failover, and FortiOS handles that gracefully if uninterruptible-upgrade is enabled.

How do I roll this back cleanly?

Take a config backup first with execute backup config flash or to a TFTP/SCP target. FortiOS has a revision store: execute revision list config and execute restore config flash <rev> roll you to any saved point. I save a revision before every audit-touching change.

Will FortiGuard or FortiCare lapse affect this fix?

The core CLI fix works regardless of entitlement. But IPS, AV and web-filter signature updates stop if FortiGuard lapses, and TAC will not engage without active FortiCare. Check get system fortiguard-service status before you assume the box is fully covered.

Is the FortiSwitch managed or standalone here?

If FortiLink is up, treat the switch as managed and drive it from the FortiGate. get switch-controller managed-switch tells you. A standalone FortiSwitch takes its config on the switch CLI directly, which is a different workflow entirely. Mixing the two is the most common self-inflicted outage I see.

What if the symptom returns after a reload?

A symptom that survives a reload points at config or hardware, not a transient. Check whether a FortiManager or config-sync source is overwriting your local change. If hardware is suspect, pull diagnose hardware sysinfo and the crashlog, then raise a FortiCare RMA with the tech-support bundle attached.