NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. Add a user: /user add name=netadmin group=full password=<strong> — then remove or disable the default: /user disable admin
2. Restrict per-user by source: /user set netadmin address=10.0.0.0/24
3. Turn off unused services and scope the rest: /ip service disable telnet,ftp,api,www and /ip service set ssh address=10.0.0.0/24 port=22
4. Add a firewall backstop: /ip firewall filter add chain=input action=drop in-interface-list=WAN place-before=0
5. GUI: System → Users, and IP → Services.

Gotchas & notes

• Do three things, not one: per-user address=, per-service address= in /ip service, and an input chain firewall rule. Any one alone leaves a gap — for example a scoped SSH service still exposes WinBox on 8291 if you did not disable or scope it.
• WinBox (TCP/8291) is the port people forget. It is not covered by disabling www or ssh, and MikroTik boxes are actively scanned for it.
• Also disable the MAC-server (/tool mac-server set allowed-interface-list=none and the same for mac-winbox), or anyone on the same L2 segment can manage the router with no IP at all.
• The default admin user historically had a blank password. If you inherit a device, assume it is still there and check /user print.
• Locking yourself out of a remote MikroTik is easy and there is no candidate/commit safety net. Test from a second session before closing the first.

Steps

1. Add an admin: System → Administrators → Create New → set username, password, and an *Administrator Profile* (super_admin or a scoped profile).
2. Restrict the source: on that admin, enable Restrict login to trusted hosts and add the subnets.
3. Restrict per-interface protocols: Network → Interfaces → edit → *Administrative Access* checkboxes (set allowaccess ...).
4. CLI: config system admin → edit "netadmin" → set accprofile "super_admin" → set trusthost1 10.0.0.0 255.255.255.0 → set password <x> → next → end

Gotchas & notes

• trusthost is the real lock and it defaults to 0.0.0.0/0 (anywhere). Setting allowaccess on interfaces limits which protocols and interfaces respond, but any source IP that can reach them can still attempt login until trusted hosts are set.
• Once you set trusthost1, everything else is implicitly denied for that account. Add every subnet you manage from — including your VPN pool — or you lock yourself out on the next login.
• Firewall policies do not control access to the FortiGate itself. Writing a policy to block management is a no-op; use allowaccess, trusted hosts, and local-in policies.
• Change the admin HTTPS/SSH ports under System → Settings if the GUI is exposed at all, and disable HTTP entirely.
• Give the default admin account a password and consider disabling it in favour of named accounts, ideally backed by RADIUS/LDAP so departures are handled centrally.

Steps

1. Controller admins: Settings → Admins & Users (or *System → Admins*) → *Add Admin*, choose role (Owner/Admin/Viewer) and scope (all sites or one).
2. Device SSH credentials: Settings → System → Advanced → Device SSH Authentication (username + password or key).
3. For a UniFi OS console, also manage local users and 2FA in the UniFi OS settings, separately from the Network app.
4. Restrict remote access: disable Remote Access in UniFi OS settings if you do not want ui.com-brokered access.

Gotchas & notes

• There are two separate credential systems: controller/UniFi OS accounts (the web UI) and device SSH credentials (the switches and APs). Rotating one does not rotate the other.
• Remote Access via the Ubiquiti cloud is often enabled by default, meaning your controller is reachable through ui.com with an SSO account. Decide deliberately whether you want that, and enforce 2FA on the Ubiquiti account if you do.
• Enable 2FA on all admin accounts — this is where UniFi is genuinely better than the CLI platforms, which mostly need external RADIUS for MFA.
• There is no source-IP restriction for controller access in the Network app; do that at the network layer (firewall rules on the WAN, or keep the controller off the internet).
• Local device SSH access bypasses controller roles entirely — treat those credentials as full administrative access.

Steps

1. Local user: username netadmin privilege 15 secret <strong> (use secret, never password).
2. Enable SSH: hostname R1 → ip domain name example.com → crypto key generate rsa modulus 2048 → ip ssh version 2
3. Restrict the VTY lines: ip access-list standard MGMT → permit 10.0.0.0 0.0.0.255, then line vty 0 15 → access-class MGMT in → transport input ssh → login local → exec-timeout 10 0
4. no ip http server / no ip http secure-server unless you use the WebUI.
5. Save: copy running-config startup-config

Gotchas & notes

• transport input ssh on the VTY lines is what actually disables telnet. Configuring SSH without it leaves telnet listening and accepting your credentials in cleartext.
• username x password y stores a reversible type-7 string; always use secret (type 5/8/9 hash). Also set service password-encryption for the remaining legacy fields.
• SSH key generation requires a hostname and domain name to be set first, and it fails with a confusing error if either is missing.
• access-class MGMT in on VTY is the source restriction. An interface ACL is a blunter tool that also affects transit traffic.
• Set exec-timeout and login block-for ... attempts ... within ... to blunt brute-forcing; the defaults are permissive.

Steps

1. Add an admin: Device → Administrators → Add → username, authentication profile or password, and *Administrator Type* / role.
2. Restrict management-plane access: Device → Setup → Management → Management Interface Settings → Permitted IP Addresses, and untick unused services (HTTP, Telnet).
3. For dataplane interfaces, attach an Interface Management Profile (Network → Network Profiles → Interface Mgmt) with tight *Permitted IP Addresses*.
4. Commit.

Gotchas & notes

• Two different mechanisms for two different paths: *Permitted IP Addresses* under Management Interface Settings protects the dedicated MGT port, while an Interface Management Profile governs management access via a dataplane interface. Securing one and forgetting the other is the standard mistake.
• Never attach a management profile permitting HTTPS/SSH to an internet-facing interface without *Permitted IP Addresses* set — this is a well-known route to a compromised firewall.
• Because everything is candidate-config, a Commit that locks you out still commits. Use *Commit → Preview Changes*, and consider set deviceconfig setting management commit-lock discipline on shared boxes.
• Disable Telnet and HTTP explicitly; they are separate checkboxes and at least one is often left on from initial setup.
• Prefer an authentication profile (RADIUS/TACACS+/SAML) over local accounts so leavers are handled centrally, and keep exactly one break-glass local admin.

Steps

1. Add a user: System → User Manager → Users → Add → set the password and add them to the admins group (or a custom group with scoped privileges).
2. GUI protocol/port: System → Advanced → Admin Access — set HTTPS, change the port, enable SSH (key-only recommended).
3. Restrict by source with firewall rules on the interface the GUI is reachable from; WAN is blocked by default.
4. Consider unticking *Disable webConfigurator anti-lockout rule* only once you have a working rule.

Gotchas & notes

• The anti-lockout rule silently permits GUI access from the entire LAN, overriding your carefully written management rules. Until you disable it in System → Advanced → Admin Access, restricting GUI access on LAN does nothing.
• Disabling the anti-lockout rule without first having a correct pass rule locks you out of the GUI; recovery is via console option 8 or option 11 to reset the webConfigurator.
• Set SSH to key-only (*Authentication Method: Public Key Only*) rather than password, and add keys per user in User Manager.
• WAN GUI access is closed by default. If you have deliberately opened it, put it behind a VPN instead — this is the most common serious pfSense misconfiguration.
• The console is unauthenticated by default; set a console password in System → Advanced → Admin Access for physically accessible units.

Steps

1. Create the account: Device → Users → Local Users & Groups → Add User, set a username/password, and assign it to the Administrators group (or a custom group scoped to limited rights — SonicOS supports partial-admin/read-only roles here).
2. Restrict where management can even be reached: Network → Interfaces, edit each interface, and uncheck HTTPS Management / SSH Management / Ping for any interface (especially WAN) that shouldn't accept it at all.
3. If WAN management genuinely must be enabled, go to Policy → Rules and Policies → Access Rules and add an explicit rule permitting HTTPS/SSH management only from specific source IPs, rather than leaving the open-ended allow that the management checkbox creates by default.
4. Optionally harden further under Device → Settings → Administration (login lockout thresholds, two-factor auth, idle timeout).

Gotchas & notes

• There is no per-account trusted-host list like Palo Alto's. Access control on SonicOS is layered across (1) the per-interface management-service checkboxes and (2) firewall Access Rules — not attached to the admin account itself. Someone expecting a single 'restrict this admin to these IPs' field will not find one.
• The classic SonicWall footgun: ticking the HTTPS/SSH management checkbox on the WAN interface opens management to any source address until you separately add a restricting Access Rule. Plenty of internet-facing SonicWalls have been found exposed exactly this way — enabling the checkbox alone looks 'configured' but isn't locked down.
• Full admin-account creation and privilege-group assignment is GUI-only — E-CLI doesn't expose local user/administrator management, only basic interface and system setup.
• Custom administrator roles can be scoped to specific feature areas (e.g., read-only, or VPN-only), which is useful for delegating without granting full Administrator rights.

Steps

1. Insight cloud identity (routers, Orbi Pro APs, and Insight-managed switches): Insight Cloud Portal → Organization (or, for Insight Pro, the org's Manage Users) → Invite User → set the role (Admin, Manager read/write, or User read-only) → send invite to their NETGEAR account email. There is no separate 'local' admin account on the device itself for these — Insight identity is the only multi-user model.
2. Restricting management access on cloud-managed devices is not an IP-allow-list on the device; it's done at the Insight account layer (per-user role scoping, and enabling MFA on the NETGEAR account) plus, on the router's own LAN-facing firewall page, rules limiting which subnets can reach the device's local recovery GUI.
3. Smart Switches: only one built-in local account exists (username admin, password only) — there is no way to add additional named administrators in the local GUI or the Lite CLI. Restrict access instead by disabling insecure services (HTTP/Telnet) under Security → Management Security, leaving only HTTPS/SSH reachable, and putting management on its own VLAN.
4. M4200/M4300 (real local AAA — the only tier with true named accounts): CLI: username <name> password <password> then username <name> level 15 for admin privilege (or a lower level for read-only). GUI equivalent: Security → Management Security → User Accounts.
5. M4200/M4300 access restriction: build a management ACL and apply it to the mgmt plane — CLI: management access-list <name> → permit <source-ip> rules → deny any (implicit or explicit) → exit → management access-class <name>. GUI: Security → Management Access List.

Gotchas & notes

• This is the task where the 'three separate surfaces' problem bites hardest: only the M4200/M4300 line has anything resembling a real multi-admin, per-source-IP-restricted management model. Everything else has either cloud-account roles (routers/APs/managed switches) or a single shared local password (Smart Switches).
• On a Smart Switch, do not go looking for a 'create additional admin' option — it does not exist. If you need per-person accountability, that has to come from Insight cloud user roles, not the switch itself.
• Consumer-style 'Remote Management' with an allowed-IP field, which older standalone NETGEAR routers had, is being phased out by NETGEAR entirely and was never really the model for Insight-managed business routers — don't expect to find it.
• Exact management access-list permit/deny syntax (service qualifiers for HTTP/HTTPS/SSH/SNMP/Telnet) varies a bit by M4200/M4300 firmware branch — confirm against the CLI reference for your exact firmware before relying on it, rather than assuming Cisco access-class syntax carries over verbatim.
• Because routers/Orbi Pro APs have no CLI and no local multi-user accounts, there is no way to lock down 'who can SSH in' on those — the entire trust boundary is the Insight cloud login, so MFA on that NETGEAR account is effectively your whole access-control story for those devices.