Key takeaway
Disable services you do not need; for the rest, verify encryption, restricted access, patching and logging.
FTP: transfer channels and protected alternatives
FTP uses separate control and data connections to transfer files. Traditional FTP does not encrypt credentials or content: in active mode the server opens the data connection; in passive mode the client connects to a port the server advertises. Firewall rules must account for both connection patterns. FTP may remain in legacy workflows such as website uploads to hosting, nightly system exports or batch file exchange with a supplier; identify those dependencies first. FTPS adds TLS protection to FTP, while SFTP is a separate protocol over SSH. Verify the certificate or SSH host key through a trusted channel, allow anonymous access only for intentional public distribution, and limit each account’s directory permissions.
Plain FTP
Credentials and files travel without protection; it is a poor choice for new systems.
FTPS
Keeps the FTP workflow and adds TLS; verify the certificate and data-channel protection.
SFTP
Runs over SSH and is not the same protocol as FTP; verify the host key through a trusted channel.
RDP: remote access with limited privileges
RDP lets a user control the desktop of a remote Windows computer; applications run on the remote host. Its default port is TCP/UDP 3389, but changing the port only reduces scanning noise and does not provide core protection. Enable RDP only where needed, do not expose it directly to the public internet, and protect it through a VPN, Remote Desktop Gateway or an organization-approved resource-specific access path. Keep NLA enabled and require MFA through the approved access gateway or a supported integration, grant RDP rights to few accounts, patch hosts and monitor successful and failed logons. Restrict clipboard, drive and device redirection to what the session requires.
Define who can connect
Grant RDP only to users who need it for their work and only on the required hosts.
Protect the access path
Avoid public port forwarding; use an approved gateway or VPN with MFA.
Limit the session
Apply NLA, patching, account lockout and redirection policies; keep session logs.
SNMP: monitoring access is still privileged
An SNMP manager can read MIB/OID values from agents on routers, switches, firewalls, servers, printers and UPS units; if allowed, SET can change device settings. Polling commonly uses UDP 161 and traps UDP 162. SNMPv1 and v2c use a community string without encryption. Where supported, use SNMPv3 authPriv with currently supported authentication, integrity and privacy algorithms. Restrict access to the management network and required OIDs and operations, disable SET where it is unnecessary, and inventory older versions.
Read access
Interface, load, inventory and health data can also reveal network topology.
Write access
SNMP SET can change configuration; prefer read-only access unless write access is justified.
What TLS and a certificate establish
TLS protects the confidentiality and integrity of a connection; a correctly validated certificate helps confirm the server name. “SSL” remains common shorthand, but SSLv2/v3 and TLS 1.0/1.1 are obsolete. Use versions supported by your organization, such as TLS 1.2 and 1.3. Validate the CA chain, hostname and expiry. The HTTPS indicator does not prove a site is harmless, a login form is legitimate or a device is clean. Automate certificate renewal, restrict private-key access and check the service’s actual TLS configuration.
Confidentiality
Makes traffic harder to read while it travels across the network.
Integrity
Helps detect covert modification of data within the connection.
Server validation
Validate the hostname and certificate chain; bypassing warnings weakens protection.
