UNIT-5

Network Management Security: Overview of SNMP architecture, SNMP V2 and V3 communication

facility

What is Simple Network Management Protocol (SNMP)? Simple Network Management Protocol (SNMP) is a way for different devices on a network to share information with one another. It allows devices to communicate even if the devices are different hardware and run different software.

Without a protocol like SNMP, there would be no way for network management tools to identify devices, monitor network performance, keep track of changes to the network, or determine the status of network devices in real time.

At the same time, though, SNMP is a vital tool for effective network management. It’s not perfect, but it’s one of the best solutions available for monitoring and managing devices on the network.

Below, I discuss SNMP’s role in network management, identify the various SNMP versions available, and explain how to use SNMP effectively and securely on your network.

SNMP architecture SNMP has a simple architecture based on a client-server model. The servers, called managers, collect and process information about devices on the network.

The clients, called agents, are any type of device or device component connected to the network. They can include not just computers but also network switches, phones, printers, and so on. Some devices may have multiple device components. For example, a laptop typically contains a wired as well as a wireless network interface.

SNMP data hierarchy While the SNMP architecture is simple, the data hierarchy the protocol uses can seem complicated if you’re not familiar with it. Fortunately, it’s relatively simple once you understand the philosophy behind it.

To provide flexibility and extensibility, SNMP doesn’t require network devices to exchange data in a rigid format of fixed size. Instead, it uses a tree-like format, under which data is always available for managers to collect.

The data tree consists of multiple tables (or branches, if you want to stick with the tree metaphor), which are called Management Information Bases, or MIBs. MIBs group together particular types of devices or device components. Each MIB has a unique identifying number, as well as an identifying string. Numbers and strings can be used interchangeably (just like IP addresses and hostnames).

Photo: Robert Couse-Baker on Flickr

Each MIB consists of one or more nodes, which represent individual devices or device components on the network. In turn, each node has a unique Object Identifier, or OID. The OID for a given node is determined by the identifier of the MIB on which it exists combined with the node’s identifier within its MIB.

This means OIDs take the form of a set of numbers or strings (again, you can use these interchangeably). An example

is 1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3.

Written with strings, that OID would translate to:

iso.org.dod.internet.private.transition.products.chassis.card.

slotCps.

cpsSlotSummary.cpsModuleTable.cpsModuleEntry.cpsModuleModel.35

62.3.

Using the OID, a manager can query an agent to find information about a device on the network. For example, if the manager wants to know whether an interface is up, it would first query the interface MIB (called the IF-MIB), then check the OID value that reflects operational status to determine whether the interface is up.

Why use OIDs? The MIB and OID data hierarchy may seem confusing, but there are several important advantages to a system like this. One is that information can be pulled by the manager without having to send an explicit request for the agent to collect it. That reduces overhead and ensures information about the network’s status is always readily available.

The system also provides an easy, flexible way to organize many devices across a network. It works no matter how large or small the network is, or what kind of devices are on it.

SNMP also makes it possible to collect large amounts of information quickly without clogging the network with traffic. Because information about device status is always available in a simple format and is updated in real-time, managers can pull it without waiting for the data to be collected or requiring large data transfers.

Last but not least, it’s worth noting that some OID values are vendor-specific, which makes it easy to gain some information about a device based simply on its OID. For example, if an OID starts with 1.3.6.1.4.1.9, it applies to a Cisco device. Other vendors have their own OID specifications. (Wireshark, the open source network scanner, offers a handy OID lookup tool.) The standard OID prefix, which can be used for almost any device that supports SNMP, is 1.3.6.1.2.

SNMP versions The final important thing to understand about SNMP is that the features available in different versions of the protocol vary widely, especially when it comes to security.

The first version of SNMP—SNMPv1—offers weak security features. Under SNMPv1, managers can authenticate to agents without encryption when requesting information. That means anyone with access to the network could run “sniffing” software to intercept information about the network. It also means an unauthorized device can easily pretend to be a legitimate manager when controlling the network.

As well, SNMPv1 uses certain default credentials, which admins don’t always update, making it easy for unauthorized parties to gain access to sensitive information about the network. Unfortunately, SNMPv1 is still used on a relatively wide basis today because some networks haven’t yet updated.

SNMPv2, which appeared in 1993, offered some security enhancements but it was supplanted in 1998 by SNMPv3, which remains the most recent version of the protocol and the most secure.

SNMPv3 makes data encryption possible. It also allows admins to specify different authentication requirements on a granular basis for managers and agents. This prevents unauthorized authentication and can optionally be used to require encryption for data transfers.

The bottom line is that, while the security issues in SNMPv1 earned SNMP a bad name in some circles, SNMPv2 and especially SNMPv3 solved those problems. The newer versions of SNMP provide an up-to-date, secure way to monitor the network.

For further detail, see the document below

http://www.hit.bme.hu/~jakab/edu/litr/SNMP/IEEE__00663326.pdf

UNIT-6

System Security: Intruders, viruses and related threats, Firewall design principles, Comprehensive

examples using available software platforms/ case tools, Configuration management

For reference, watch the following NPTEL video on system security ( various threats to system)

https://nptel.ac.in/courses/106105031/

FIREWALL:

For firewall , watch the following NPTEL Video ( firewall and intrusion detection system)

https://nptel.ac.in/courses/106105031/

CONFIGURATION MANAGEMENT:

Configuration management (CM) is a systems engineering process for establishing

and maintaining consistency of a product's performance, functional, and physical

attributes with its requirements, design, and operational information throughout its

life.

Configuration management is a form of IT service management (ITSM) as defined by

ITIL( ITIL an acronym for Information Technology Infrastructure Library, is a set of detailed

practices for IT service management (ITSM) that focuses on aligning IT services with the needs

of business) that ensures the configuration of system resources, computer systems,

servers and other assets are known, good and trusted. It's sometimes referred to as

IT automation.

Most configuration management involves a high degree of automation to achieve

these goals. This is why teams use different tools like Puppet, Ansible, Terraform and

other configuration management tools.

By using automation, it's easier to build in checks and redundancies, improving the

potential for omissions due to human error and the accuracy for keeping assets in

the desired state.

Without automation, a single engineer forgetting to update a piece of software can

leave a system with an outdated version of the software that has a

known vulnerability . This vulnerability could be exploited to spread computer

worms, install ransomware or another type of malware.

Automation is valuable for another reason, it greatly improves the efficiency and

makes configuration management of large systems manageable.

Configuration management applies to a variety of systems, but most often, you’ll be

concerned with these:

Servers

Databases and other storage systems

Operating systems

Networking

Applications

Software

What are popular configuration management tools?

There are many popular configuration management tools, which makes it hard to

find a tool or stack of tools that meet the system configuration needs of your

organization.

The essential features and tradeoffs you need to consider include performance,

always key for scaling a data center, compatibility with existing systems, ease of use,

enterprise support and cybersecurity.

When it comes to market share, tools like Ansible, Puppet and Microsoft System

Center Configuration Manager have sizable communities but there are only great

alternatives in the CM space.

Here are some of the most popular tools you could consider, or at least be aware of:

Ansible: The leader by market share, with around 27% share of the market,

Ansible is an agentless orchestration and configuration system that uses

playbooks written in YAML to manage your servers.

HashiCorp Terraform: Focusing more on server provisioning rather than

server configuration, Terraform uses an immutable configuration approach to

keep all servers perfectly synced to the desired state, avoiding configuration

drift.

CFEngine: An older tool in the space, CFEngine is a configuration

management tool that runs lightweight agents on the managed resources and

converges their configuration to the desired state.

Microsoft System Center Configuration Manager: With around 22% of the

market, MSCCM is Microsoft’s system configuration and monitoring tool,

which manages the configuration of Windows-based assets from a single

central admin machine.

Puppet: A configuration management tool with almost 12% market share,

Puppet uses a Master-Slave architecture to keep resources in the desired

state. Along with Chef, it’s one of the CM systems that rely on Ruby domain

specific languages (DSLs) for configuration management.

Chef: Chef allows you to store configuration management routines in

“recipes” and “cookbooks” that can be easily shared across teams, with

support for a plethora of operating systems, including Windows and Linux.

AWS OpsWorks: This is one of AWS’s multiple solutions aimed at easing

configuration management for enterprises hosting their applications on

Amazon’s cloud platform. OpsWorks automates patching, updating, and

configuration of servers using Chef and Puppet.

Saltstack: Salt lets you use the Python programming language to create

configuration templates that can be pushed out to clients from a central

master or run with a decentralized model.

These tools have many commonalities and overlapping features that provide

advantages over managing configuration management by hand, including

infrastructure-as-code approaches that make it easy to rollout updates and change

infrastructure.

In addition, these configuration management tools help you keep a record of your

assets and understand the exact state across all your servers and other networked

assets.