Auditing Network Elements


Auditing Network Elements (NE) could be audited by different ways and from different perspectives.

For deciding the audit strategy always should be considered from which perspective the NE is most exposed and what approach could provide the best results compared to cost/resources needed for audit.


  • Blackbox testing
    • Network, Vulnerability scanning
    • Pentest
  • Whitebox testing
    • Source code review
    • Static analysis
    • Dynamic Analysis
    • Policy compliance checks
    • Reverse engineering


  • Signalling & Media interfaces
  • OAM network interfaces
  • Provisioning, Billing other interfaces

OAM audit strategy:

  • Use nmap for service discovery
  • Use vulnerability scanner from network and also with authentication towards the NE
  • Crawl the Web Interfaces & scan with Web Vulnerability scanners
  • Use matesploit or nmap scripts to try default, easy passwords on common services (ssh, telnet, ftp, ...)
  • Login on the OS over SSH
    • Use unix_privesc_check, linenum or other
    • If you have root take shadow file and try to crack the passwords using e.g. John the Ripper
    • Check history files, check users on system, check sudoers
    • make tcpdump to see what traffic is not encrypted
    • try to find sensitive content or password in files on OS
    • other
  • Run authenticated compliance check from vulnerability scanner to verify OS configuration with template
  • Run static analyzer on the source code if available
  • Other

Signalling audit strategy:

It always depends on the audited interface and protocol. Most time it is required the preparation to prepare the stack, protocol encoder and arrange the interconnection before the audit.

  • Audit appliance protocol stack:
    • State machine requirements:
      • For state machine (to bring the link-up and keep the link-up) it is possible to implement basic state machine in audit appliance, other option is just to send the sequence of initial messages to bring the link up. After this it is possible to inject the messages on the link (e.g. protocols Diameter, Sigtran)
      • If no state machine is required or link setup is simple it is possible to directly inject messages (e.g. GTP, Radius)
      • From auditing from access segment also the authentication and state machine could be required (e.g. SIP)
    • Encoder/Decoder requirements:
      • Messages could be injected by hex/pcap replay, modification of the traffic on different layers
      • Encoded in the code (e.g. ASN.1 encoder) in the audit appliance
      • Decoder is needed only for automatic result analysis of for multiple messages scenarios
  • Interconnection setup:
    • Directly peer-to-peer with NE
      • + But the added value is it is directly facing the NE and no router or other NE on path.
      • - Most time not practical, because the NE will need to be reconfigured for this and dedicated for the audit.
    • Audit appliance connect to the network as real NE (interconnect with STP, DRA or IP router) and configure it as roaming partner or internal element, depends of the perimeter which would like to be audited
      • + NE does not need to be dedicated for audit
      • + Easier/standard configuration of audit appliance
      • + Possible to audit multiple NEs
      • - Possible STP, DRA, other router in path could hide some results or behavior of NE. Also the router could be impacted by the tests.
  • Possible audit phases:
    • Discovery, network scanning (topology discovery)
    • Read-Only/Safe messages according to specification (information gathering, location tracking, other)
    • Write/Modification messages according to specification (fraud testing, integrity modification, DoS scenario)
    • Fuzzing and malformed messages testing on various protocol layers (violating the specification)
    • Advanced/staged attack scenarios combining multiple messages