Customer Service and Booking Hotline: +44 (0) 845 672 0175

Search

Protecting Critical Management Protocols From Attack

Several management protocols widely used in networks have little built-in protection, so they must have additional protection provided to avoid compromise of complete systems...

Several key protocols and services used to configure and manage routers and other network devices are fundamentally insecure:

In this article we identify some of these and suitable countermeasures to make them more secure.

Telnet

Telnet operates using a clear-text user-name and password, making it highly insecure when used across an untrusted network, and vulnerable to simple sniffing attacks. It should be replaced by SSH v2 if possible, although unfortunately many base software loads, including Cisco’s IOS, only support SSH in their security versions. If SSH is not a possibility on the device itself, a secure connection to a bastion host should be used, typically IPSec or SSH, coupled with fine-grained access-lists to allow specific to and from addresses only, and the usual anti-spoofing countermeasures

SNMP

SNMP before version 3 uses clear-text community strings to control access to devices, and these are again highly vulnerable to sniffing attacks, or worse still guessing if the default values have been unaltered. SMNP version 3 encrypts community strings in transit, but is not widely supported, in which case a generic approach of implementing IPSec between devices for this traffic, coupled with fine-grained access-lists and anti-spoofing, is a sensible approach

Syslog

Bogus syslog messages can be generated by an attacker to confuse any investigation of security events. A reliable syslog is one of the most important tools available in understanding incidents and protecting against future occurrences. By implementing IPSec directly between clients and the syslog server and fine-grained access-lists to only allow traffic between specific IP addresses, the risk of bogus syslog entries can be substantially reduced.

TFTP

TFTP requires no authentication for file transfers to take place, and sends all traffic as plain-text, so router configuration files, etc can be readily sniffed in transit, and the protocol is vulnerable to attacks which guess filenames and transfer these from TFTP servers. The same countermeasures as for SNMP are sensible

NTP

NTP does not authenticate when updating time to devices unless the latest version (NTPv3) is in use. If an attacker can modify system clocks, then digital certificates can be made to fail causing serious DoS, and also syslog entries are unusable, because their timestamps no longer allow correlation of events. Countermeasures should be IPSec and access-lists, as above. An internal reference clock providing network time to all systems can also allow NTP to be blocked at border routers, largely eliminating this vulnerability

Bookmark this article

Share this article using the following sites:

Courses by category...

Glossary Search

Newsletter Sign-up

Our RSS Feeds...