Set up secure SNMP monitoring for Sophos Switch

The SNMP page in Sophos Fusion controls two separate data paths: an SNMP manager polls values from the switch, while the switch can send event notifications to a receiver. For new integrations, use SNMPv3 with Privilege, SHA, and AES_CFB128. A tightly scoped Read view is sufficient for monitoring; do not grant write access.

Quick procedure:

1. Confirm reachability, licensing, change scope, and required OIDs.
2. Under Switches > [Switch, Stack or Site] > SNMP > Global settings, enable SNMP and leave the Engine ID unchanged.
3. Create an SNMPv3 user with Privilege under Users & Communities.
4. Grant only required read permissions under Groups, Views, and Access lists.
5. Import the model MIBs into the SNMP manager and run positive and negative polling tests.
6. Only if notifications are required, configure Target parameters, Notifications, and Target address.
7. Approve polling and notification reception separately.

SNMPv1 and SNMPv2c use a Community String as a password and transmit it in clear text. Keep Enable SNMP v1/v2c for this user disabled unless a justified legacy system has no SNMPv3 support.

Requirements, roles, and reachability

Every centrally managed switch needs a valid Sophos Switch Support and Services Subscription for changes through Sophos Fusion. The switch continues to work locally without it, but Fusion cannot apply changes. See Sophos Fusion licensing.

A Sophos Fusion administrator whose permissions cover the selected switch, stack, or site performs the configuration. The SNMP form documents no dedicated SNMP administrator role. The monitoring owner supplies manager details, imports MIBs, and tests polling and notifications. Exchange credentials through an approved secret channel, never in tickets or screenshots.

Before saving, establish the target switch, stack, or site and its effective scope; switch management IP and manager IP; routing and filters in both directions; the receiver’s UDP port; required MIB branches and OIDs; a unique user name and separate strong authentication and encryption secrets; and whether only polling or also Traps or Informs are needed.

The Access lists here constrain a group’s OID rights. They are not network ACLs and cannot define manager source IPs. Restrict the management network to the intended monitoring systems. Verify the polling port against the real manager and network configuration instead of assuming a product default.

A site or stack change can affect several devices. Start with a pilot switch. Configuration source shows where a setting originates. Not set means that the local switch configuration applies; it does not necessarily mean Off.

Define the SNMPv3 security model

Use Privilege in production. Authentication protocol offers MD5 (HMAC-MD5) and SHA (HMAC-SHA-96); Encryption protocol offers DES_CBC (64-bit DES-CBC) and AES_CFB128 (128-bit AES-CFB). The strongest available combination is SHA with AES_CFB128.

Adapt these names to your standard. Generate both secrets randomly and store them separately. Select OIDs from the deployed model’s MIBs and actual monitoring requirements; there is no universal Sophos OID for this purpose.

1. Set global SNMP settings

1. Open Switches, select the switch, stack, or site, and select SNMP.
2. Under Global settings, set SNMP status to On.
3. Keep the recommended Default option for Engine ID.
4. Save with Update, then verify Configuration source and effective SNMP status.

A manual Engine ID must be hexadecimal and 10–64 characters long. It uniquely identifies the switch and protects against replay, delay, and redirection issues.

Clear resets values entered in the view; it does not restore a previously documented production state.

2. Create the SNMPv3 user

The Users & Communities list shows Name, Protocols, Authentication, and Configuration source.

1. Under Users & Communities, click Add.
2. Enter a 4–20-character Name, for example swmon_v3.
3. Set Privilege mode to Privilege, Authentication protocol to SHA, and enter a new 8–32-character Authentication password.
4. Set Encryption protocol to AES_CFB128 and enter a new 8–40-character Encryption password.
5. Leave Enable SNMP v1/v2c for this user disabled. Click Add and verify the list entry.

The user name and passwords may not contain spaces or ", \, %, &, ?, ', !, ;, |, +.

If v1/v2c is exceptionally enabled, Fusion derives a Community from Name. A Transport tag can associate it with devices and must match the Tag identifier under Notifications > Target address. Without that association the switch may not answer. Put this clear-text legacy exception on a time-limited retirement plan.

3. Build group, view, and access list with least privilege

Create the group

Under Groups, click Add, enter a 1–30-character Group name such as monitor_ro, select only the intended user in v3, save with Add, and open the group to verify membership. The same excluded characters apply. If a user lacks the chosen Security mode privilege or is already in an equivalent group, Fusion creates the group but omits that user; a group name alone is not proof of success.

Restrict the OID view

Under Views, click Add; enter a 1–20-character View name such as monitoring; choose Add new mapping; enter a required MIB branch under Subtree OID and an integer from 1–20 under Subtree mask; select Included or Excluded as View type; add mappings as needed with Add new mapping, then Save. The mask identifies the level in the MIB tree at which it applies. Prefer explicit Included branches. Sophos recommends an overlapping Included entry for an Excluded entry. Never expose the whole tree merely for possible future sensor discovery.

Assign the access list

An Access list requires at least one group. Under Access lists, click Add, select the group, verify Security mode, set v3 Privilege mode to Privilege, and assign the view as Read view. Do not assign a Write view for monitoring. Assign Notify view only for planned notifications, then Save and verify the row. Read view, Write view, and Notify view independently control readable, writable, and notification OIDs. If the firmware forces a write-view selection, clarify the model-specific behavior on a pilot; do not substitute a broad view.

4. Import model MIBs

Open My Environment > Installers, then under Switches select Download SNMP MIB files. Store and extract the archive securely, import the files for the deployed model into the manager, and check all selected OIDs against that version. The archive covers all Sophos Switch models. A MIB is the reference for structured device information; each OID identifies a variable that SNMP can read or set. An OID’s presence does not prove that it is allowed by the Read view or populated on every model.

5. Configure and test polling

The SNMP page does not set the polling interval; the manager schedules polls. Configure the correct management IP, SNMPv3, user, Privilege, SHA with its Authentication Password, and AES_CFB128 with its Encryption Password.

1. Poll an OID from the Read view and obtain a plausible value.
2. Match switch name, management IP, and model to inventory.
3. Poll an intentionally unauthorized OID; it must return no value.
4. Observe several cycles for timeout, loss, and load.
5. Confirm that no Write view is assigned; do not alter a production OID to test this. Check the permission and manager profile, and perform a write test only in an approved lab.
6. Reconcile SNMP status, user, membership, Read view, absence of write rights, and Configuration source with the plan.

One successful poll proves one credential path and OID, not every sensor. A timeout is not automatically a credential error: isolate routing, filters, target IP, port, version, and manager profile first.

6. Configure traps or informs only when needed

Target parameters define version, security context, privilege, and user; Notifications define type and tag; Target address defines receiver, UDP port, tag, and parameter set. Traps are unidirectional and unacknowledged; receipt and delivery are not guaranteed. Informs request acknowledgement and are more reliable but consume more resources; they are available only with SNMPv2c and SNMPv3. An acknowledgement adds neither authentication nor encryption: an SNMPv2c inform is still protected only by its Community String and travels in clear text. For a new SNMPv3 deployment, prefer Informs when the receiver supports them and operational acknowledgement is required; otherwise treat Traps as an explicitly unacknowledged channel.

Target parameters

Under Notifications > Target parameters, click Add. Enter a 1–30-character Name such as notify_v3; set Message processing model and Security mode to v3, Privilege mode to Privilege, select the User, and Save.

Notification

Under Notifications > Notifications, click Add. Enter a 1–32-character Notify name such as ops_inform, a 1–20-character Tag identifier such as ops_nms, select Traps or Informs under Notify type, and Save.

Target address

Under Notifications > Target address, click Add after at least one Target Parameter exists. Enter a 1–32-character Target address name, the receiver IP address (192.0.2.60 in this example), and its exact configured UDP port. For Informs set Timeout and Retry. Enter the identical Tag identifier (ops_nms), select the Target parameter, and Save. Name fields exclude spaces and ", \, %, &, ?, ', !, ;, |, +.

The page documents neither event selection nor a Send test button. Trigger a known safe event during maintenance and decode the received message with the imported MIB. If none exists, record that end-to-end notification remains unconfirmed until the first real event.

End-to-end acceptance

Verify separately: SNMP status: On and correct Configuration source; actual v3 group membership, Privilege, Read view, no write rights, and optional Notify view; repeated success for an allowed OID and failure for a denied one; restricted network paths; receiver display with expected sender, v3 context, timestamp, and decoded fields; acknowledgement and no unexplained retries for Informs (or explicitly no delivery proof for Traps); and documented credential owner, rotation date, OID/sensor list, receiver, and rollback without secrets.

A pending or failed Fusion task means the setting is not effective. See Operate Sophos Switch fleets, sites, and stacks for Configuration source and Task queue.

Troubleshoot by symptom

Polling is unavailable

Check SNMP status, target, and Configuration source; routing and filters; version, user, Privilege, and algorithms; secrets from the credential store without exposing them in logs or command lines; group membership and access list; then retest a known allowed OID. Do not open arbitrary source networks as a shortcut.

Allowed OIDs return no data

Compare Subtree OID, Subtree mask, Included/Excluded, and assigned Read view with the model MIB. Do not expose the entire OID tree.

SNMPv3 fails after an Engine ID change

Changing or deleting Engine ID removes local users. Recreate users and dependencies, then reset and rediscover the manager’s stored SNMPv3 Engine ID and USM state. If the manager cannot refresh it, recreate the affected device or sensor with the current ID and credentials. Do not change the ID again experimentally.

Group exists but user is missing

The user lacks the required Security mode privilege or already belongs to an equivalent group. Correct the values and verify actual membership.

Access list cannot be created

Create at least one user and group first, then select the group and assign views for each enabled version.

Receiver gets no notification

Verify linked Target parameters, Notifications, and Target address, including identical Tag identifier; receiver IP and actual UDP port; route and filters; v3 Privilege mode, user, SHA/AES, and Notify view; and Timeout, Retry, and acknowledgements for Informs. Remember that Traps have no acknowledgement and that an event must actually occur.

Informs cannot be selected

They require SNMPv2c or SNMPv3. Use v3 in Target Parameters and keep version and security mode consistent.

Legacy v1/v2c manager gets no answer

Check Community assignment and Transport tag; it must match Tag identifier under Notifications > Target address. Do not solve this by permanently broadening clear-text v1/v2c access.

Rotate credentials without interruption

Do not change Engine ID. Create a distinctly named replacement SNMPv3 user with Privilege, SHA, AES_CFB128, and new secrets; add it to the existing group and verify membership; test an allowed and denied OID; update the relevant Target parameter and retest notifications; move all manager jobs only after acceptance; remove the old user from groups and unused target mappings; Delete it under Users & Communities; and update the credential store, operating record, and next rotation date.

While the old user exists, rollback means pointing the manager and Target Parameter back to it. Delete it only after the agreed observation window.

Rollback and ongoing operation

Record existing values, Configuration source, object relationships, and manager profile without secrets. Reverse dependencies: stop or revert new manager jobs and notification intake; delete new Target address entries, then related Notifications and unused Target parameters; remove new Access lists, Views, Groups, and Users & Communities if unused. To stop SNMP, set SNMP status: Off under Global settings and Update. To deliberately restore known local configuration, choose Not set and Update. Confirm the removed user cannot poll and the removed destination receives nothing.

Never change Engine ID during rollback. Not set is safe only when the effective local state is known. Regularly review Subscription, firmware, Configuration source, users and groups, minimal views, manager IP, receiver port, and MIB version. Remove obsolete users, v1/v2c exceptions, Write Views, and targets after dependency checks. Repeat positive, negative, and notification tests after manager replacement, credential rotation, switch replacement, firmware change, or OID-view changes.