Snmp protocol methods of network attacks and defenses. Protection against DDoS attacks such as SNMP Amplification. List of sources used

This article is devoted to the SNMP protocol (Simple Network Management Protocol) - one of the protocols of the OSI model, which was practically not touched upon in the documentation of the RU-net spaces. The author tried to fill this vacuum by providing the reader with ground for thought and self-improvement regarding this, perhaps new for you, issue. This document does not claim to be “documentation for the developer”, but simply reflects the author’s desire, as far as possible, to highlight aspects of working with this protocol, show its weaknesses, vulnerabilities in the “security” system, the goals pursued by the creators and explain its purpose.

Purpose

The SNMP protocol was developed to test the functioning of network routers and bridges. Subsequently, the scope of the protocol covered other network devices, such as hubs, gateways, terminal servers, LAN Manager servers, computers Windows control NT, etc. In addition, the protocol allows for the possibility of making changes to the functioning of these devices.

Theory

The main interacting parties of the protocol are agents and control systems. If we consider these two concepts in the “client-server” language, then the role of the server is performed by agents, that is, the very devices for polling the status of which the protocol we are considering was developed. Accordingly, the role of clients is assigned to control systems - network applications necessary for collecting information about the functioning of agents. In addition to these two subjects, two more can be distinguished in the protocol model: control information and the data exchange protocol itself.

“Why do you need to poll the equipment at all?” - you ask. I will try to shed some light on this issue. Sometimes during the operation of a network it becomes necessary to determine certain parameters of a certain device, such as, for example, the MTU size, the number of received packets, open ports, the operating system installed on the machine and its version, find out whether the forwarding option is enabled on the machine and much more. SNMP clients are the best way to do this.

In addition to the above, the protocol under consideration has another very important feature, namely the ability to modify data on agents. Of course, it would be stupid to allow modification of absolutely any parameter, but despite this, the number of parameters for which a write operation is allowed is simply frightening. At first glance, this completely refutes the entire theory of network security, but if you delve deeper into the issue, it becomes clear that not everything is as neglected as it seems at first glance. "If you're afraid of wolves, don't go into the forest." After all, with a little effort from the network administrator, the risk of a successful attack can be reduced to a minimum. But we will discuss this aspect later.

Let's dwell on what kind of information a management system can glean from the depths of SNMP. All information about the objects of the agent system is contained in the so-called MIB (management information base), in other words, the MIB is a collection of objects available for write-read operations for each specific client, depending on the structure and purpose of the client itself. After all, it makes no sense to ask the terminal server for the number of dropped packets, since this data has nothing to do with its operation, just like information about the administrator for the router. Therefore, the control system must understand exactly what to request and from whom. On this moment There are four MIBs:

Internet MIB is a database of objects to provide error diagnostics and configurations. Includes 171 objects (including MIB I objects).
LAN manager MIB - a database of 90 objects - passwords, sessions, users, shared resources.
WINS MIB - a database of objects necessary for the functioning of the WINS server (WINSMIB.DLL).
DHCP MIB is a database of objects necessary for the functioning of the DHCP server (DHCPMIB.DLL), which is used for dynamically allocating IP addresses on the network.

All MIB names have hierarchical structure. There are ten root aliases:

System - this MIB II group contains seven objects, each of which serves to store information about the system (OS version, operating time, etc.).
Interfaces - contains 23 objects necessary for maintaining statistics of agent network interfaces (number of interfaces, MTU size, transfer speed, physical addresses, etc.).
AT (3 objects) - responsible for address translation. No longer used. It was included in MIB I. An example of the use of AT objects can be a simple ARP table (more details about the ARP protocol can be read in the article "Non-standard use of the ARP protocol", which can be found on the website www.uinc.ru in the "Articles" section) correspondence of physical (MAC) addresses network cards IP addresses of machines. In SNMP v2, this information has been moved to the MIB for the corresponding protocols.
IP (42 objects) - data on passing IP packets (number of requests, responses, dropped packets).
ICMP (26 objects) - information about control messages (incoming/outgoing messages, errors, etc.).
TCP (19) - everything related to the transport protocol of the same name (algorithms, constants, connections, open ports, etc.).
UDP (6) - similar, only for the UDP protocol (incoming/outgoing datagrams, ports, errors).
EGP (20) - Exterior Gateway Protocol traffic data (used by routers; objects store information about received/sent/discarded cards).
Transmission - reserved for specific MIBs.
SNMP (29) - SNMP statistics - incoming/outgoing packets, packet size limits, errors, data on processed requests and much more.

Let's imagine each of them as a tree growing downwards (the system is painfully reminiscent of the DNS organization). For example, we can access the administrator's address through the following path: system.sysContact.0, system operating time system.sysUpTime.0, system description (version, kernel and other information about the OS): system.sysDescr.0. On the other hand, the same data can be specified in dot notation. So system.sysUpTime.0 corresponds to the value 1.3.0, since system has an index of "1" in the MIB II groups, and sysUpTime has an index of 3 in the system group hierarchy. A zero at the end of the path indicates the scalar type of the stored data. Link to full list(256 MIB II objects) You can find it at the end of the article in the "Appendix" section. During operation, symbolic names of objects are not used, that is, if the manager requests the contents of the system.sysDescr.0 parameter from the agent, then in the request line the reference to the object will be converted to “1.1.0” and will not be transmitted “as is”. Next we will look at the BULK request and then it will become clear why this is so important. With this, we will complete the overview of the MIB II structure and move directly to the description of the interaction of managers (control systems) and agents. In SNMP, the client communicates with the server on a request-response basis. The agent itself is capable of initiating only one action, called an interrupt trap (in some literature, “trap” is a trap). In addition, all actions of agents come down to responding to requests sent by managers. Managers have much more room for creativity; they are able to carry out four types of requests:

GetRequest - request information from the agent about one variable.
GetNextRequest - instructs the agent to return data about the next (in the hierarchy) variable.
GetBulkRequest - a request for receiving a data array. Upon receiving one, the agent checks the data types in the request for compliance with data from its table and fills the structure with parameter values in a loop: for(repeatCount = 1; repeatCount< max_repetitions; repeatCount++) Теперь представьте себе запрос менеджера на получение списка из сотни значений переменных, посланный в символьном виде, и сравните размер такового с размером аналогичного запроса в точечной нотации. Думаю, Вы понимаете, к чему привела бы ситуация, если бы символьные имена не преобразовывались вышеуказанным образом.
SetRequest - an instruction to set a specific value to a variable.

In addition, managers can exchange information about their local MIB with each other. This type of request is called InformRequest.

I will give the values of numerical constants for all types of queries:

#define SNMP_MSG_GET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x0)
#define SNMP_MSG_GETNEXT (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x1)
#define SNMP_MSG_RESPONSE (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x2)
#define SNMP_MSG_SET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x3)
/* PDU for SNMPv1 */
#define SNMP_MSG_TRAP (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x4)
/* PDU for SNMPv2 */
#define SNMP_MSG_GETBULK (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x5)
#define SNMP_MSG_INFORM (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x6)
#define SNMP_MSG_TRAP2 (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x7)

Here we are faced with another interesting detail As you can see, there are 2 numeric constants for the trap. In fact, there are 2 main versions of the SNMP protocol (v1 & v2) and the most important thing is that they are not compatible (in fact, there are many more versions - SNMP v2(p | c | u) etc, but all these modifications are quite minor, since, for example, the introduction of md5 support, etc.). SNMP is a monitoring and diagnostic protocol, and therefore, it is designed for situations where the integrity of routes is violated; in addition, in such a situation, a transport protocol that is as least demanding as possible in terms of equipment is required, which is why the choice was made in the direction of UDP. But this does not mean that no other protocol can carry SNMP packets. This can be the IPX protocol (for example, in NetWare networks); Ethernet cards and ATM cells can also be used as transport. A distinctive feature of the protocol in question is that data transfer is carried out without establishing a connection.

Let's say the manager sent several packets to different agents, how can the management system subsequently determine which of the incoming packets concerns the 1st and 2nd agent? To do this, each package is assigned a specific ID - a numeric value. When the agent receives a request from the manager, it generates a response and inserts into the packet the ID value it received from the request (without modifying it). One of the key concepts in SNMP is the concept of group. The manager authorization procedure is a simple check to see if he belongs to a specific group from the list kept by the agent. If the agent does not find the manager's groups in its list, their further interaction is impossible. Before this, we came across the first and second versions of SNMP several times. Let's pay attention to the difference between them. First of all, we note that SNMP v2 includes support for traffic encryption, for which, depending on the implementation, the DES and MD5 algorithms are used. This leads to the fact that when transmitting data, the most important data is not available for extraction by sniffing, including information about network groups. All this led to an increase in traffic itself and a complication of the package structure. By itself, at the moment, v2 is practically not used anywhere. Windows NT machines use SNMP v1. Thus, we are slowly moving on to perhaps the most interesting part of the article, namely Security issues. Let's talk about this...

Practice and safety

Nowadays, network security issues are of particular importance, especially when it comes to data transfer protocols, especially in corporate networks. Even after a superficial acquaintance with SNMP v1/v2, it becomes clear that the developers of the protocol thought about this last, or they were under strict deadlines for the project %-). It seems that the protocol is designed to work in an environment of so-called “trusted hosts”. Let's imagine some kind of virtual personality. A person, or rather a certain IP address, the owner of which has the intention of obtaining benefits, or simply to annoy the administrator by disrupting the operation of a certain network. Let's take the place of this person. We will reduce this consideration to two points:

a) we are outside the "hostile network". How can we do our dirty deed? First of all, we assume that we know the address of the network gateway. According to the RFC, the control system connects to the agent via port 161 (UDP). Let's remember that for successful work you need knowledge of the group. Here the attacker comes to the aid of the fact that administrators often leave the group values (names) set to default, and by default for SNMP there are two groups - “private” and “public”. If the administrator did not foresee such a development of events, the ill-wisher can cause him a lot of trouble. As you know, the SNMP protocol is part of FingerPrinting. If desired, thanks to the system MIB II group, it is possible to find out a fairly large amount of information about the system. Just look at the read-only parameter sysDescr. After all, knowing exactly the software version, there is a chance, using tools for the corresponding OS, to gain full control over the system. It’s not for nothing that I mentioned the read-only attribute of this parameter. After all, without rummaging through the snmpd source code (in the case of a UNIX-like OS), this parameter cannot be changed, that is, the agent will faithfully give the attacker all the data he needs. But we must not forget that agent implementations for Windows are supplied without source code, and knowledge of the operating system is 50% of the success of an attack. In addition, remember that many parameters have the rw (read-write) attribute, and among these parameters is forwarding! Imagine the consequences of setting it to "notForwarding(2)". For example, in Linux, a software implementation for SNMP called ucd-snmp has the ability to remotely launch scripts on servers by sending an appropriate request. I think everyone understands what “administrator shortcomings” can lead to.
b) the attacker is on the local machine. In this case, the likelihood of the administrator being fired increases sharply. After all, being in one segment of the network makes it possible to simply sniff the names of groups, and with them a lot of system information. Everything said in point (a) also applies to this case.

Let's move on to the "practical exercises". What might you need? First of all software. It can be obtained at . I will give examples for Linux OS, but the command syntax is similar to Windows software.

Installation of the package is standard:

gunzip udc-snmp-3.5.3.tar.gz
tar -xvf udc-snmp-3.5.3.tar
cd udc-snmp-3.5.3
./configure
make
make install

Starting the daemon (agent)

After installation, the following programs are available to you:

snmpget
snmpset
snmpgetnext
snmpwalk
snmpbulkwalk
snmpcheck
snmptest
snmpdelta
snmpnetstat snmpstatus
snmptable
snmptrap
snmptranstat
and demon
snmptrapd

Let's see what the operations described above look like in practice.

The GetRequest request is implemented by the snmpget program of the same name

To obtain the necessary information, run the following command:

root@darkstar:~# snmpget 10.0.0.2 public system.sysDescr.0

To which the server will in good faith tell us:

system.sysDescr.0 = Hardware: x86 Family 6 Model 5 Stepping 0 AT/AT COMPATIBLE - Software: Windows NT Version 4.0 (Build Number: 1381 Uniprocessor Free)

(isn’t it quite meaningful), or

system.sysDescr.0 = Linux darkstar 2.4.5 #1 SMP Fri Aug 17 09:42:17 EEST 2001 i586

Just like a guide to penetration.

Let's say we want to change something in the agent settings. Let's do the following operation:

root@darkstar:~# snmpset 10.0.0.2 public system.sysContact.0 s [email protected]

and we get the answer:

system.sysContact.0 = [email protected]

A list of MIB II objects with attributes can be found by following the link provided in the "Appendix".

I think it's time to look at SNMP at the packet level. This packet was caught by the NetXRay sniffer on the agent's network interface:

As we see, practice is not far from theory. We observe the Request ID and request parameters. In the full screenshot you can see the protocol stack - from Ethernet frames, through UDP we reach the Simple Network Management Protocol itself:

And this package was received from the manager interface:

As you can see, the group name is absolutely not encrypted (which in turn is indicated by Protocol version number: 1). I would like to note that according to the protocol specification, SNMP packets do not have a clearly defined length. There is an upper limit equal to length UDP messages equal to 65507 bytes, in turn, the protocol itself imposes a different maximum value - only 484 bytes. In turn, the length of the packet header (headerLength) has no set value.

Well, we have become familiar with the SNMP protocol in general terms. What else can be added to the above... We can only give a couple of tips to network administrators in order to reduce the risk of network security problems... First of all, due attention should be paid to setting up firewalling. Secondly, change the default group names. It would be reasonable to strictly fix the addresses of the machines (managers) from which agents can be polled. I think this article can end here. I would like to believe that you found it interesting.

However, a recent report by the CERT Coordination Center, which specializes in computer security issues, found that there are many flaws in SNMP implementations that leave more than a hundred vendors' products vulnerable to attack. With skillful use of these flaws, a hacker can get unauthorized access with broad privileges, organize a DoS attack or take other malicious actions.

Rice. 1. Simplified SNMP architecture

The main communication protocol in SNMP is UDP (User Datagram Protocol). While SNMP agents parse data on UDP port 161 when receiving requests from the NMS, the NMS parses the traffic sent on UDP port 162 to receive asynchronous messages. In Fig. Figure 1 shows a simplified SNMP management architecture, where a dynamic port assigns operating system. SNMP supports basic authentication using a community name, which serves as a password to obtain or change data relevant to management tasks.

Researchers from the Finnish University of Oulu have developed tests that can detect many vulnerabilities in SNMPv1 implementations. Test packets are typically used to analyze the protocol and generate messages that test various architectural constraints.

Researchers have discovered the following SNMP vulnerabilities.

Processing trap messages. Many shortcomings have been identified in the way various NMS (network management stations) decode and process trap messages.
Query Processing. Testing has shown the presence of inaccuracies in the decoding and processing of SNMP requests by various agents.

These vulnerabilities result from poor validation of SNMP messages as they are received and processed by the target system. These defects can lead to DoS attacks, format string vulnerabilities, and buffer overflows.

Some of the vulnerabilities discovered by Protos do not require a valid community name to be present in SNMP messages, making these vulnerabilities very easy to exploit. Additionally, since UDP is a connectionless communication protocol, SNMP and NMS agents that support trap accept incoming requests and trap messages without any pre-configured session. Most SNMP-oriented products are released with default community strings public for read-only access and private for read-write access. The community name string is integrated into the SNMP message and is sent over the network in plain text. Even if this line is specified correctly, it is vulnerable to packet sniffing.

Network access control is also not enough to block attacks that exploit these security flaws, since UDP sender addresses can be easily spoofed. A hacker can send packets using a fake sender address and disable the receiving device. Moreover, some SNMP implementations allow SNMP packets to be broadcast by default. Hackers can easily distribute broadcast packets to target an entire network, even if they don't know the address specific device and SNMP community name.

Threat Assessment

Vulnerabilities could allow a DoS attack or service interruption, and in some cases could allow a hacker to gain access to the device. Specific manifestations vary from product to product. Since SNMP services are not enabled by default in most cases, these defects do not pose a direct threat to home users. However, since SNMPv1 is widely used in critical devices network infrastructure, exploitation of these flaws can lead to instability and interruption of large-scale network operation. In particular, if hackers combine these vulnerabilities with security flaws in Internet routing protocols such as the Border Gateway Protocol, penetration of one backbone router can lead to instability of the entire Internet. If big number network devices has a common SNMP buffer overflow flaw, hackers can write a worm like Code Red that exploits this flaw, which could lead to another wave of worms.

Solutions

Using the data from the CERT bulletin, we list some general solutions capable of protecting the network.

SNMPv1 scanners. Several organizations have released tools that scan the network for devices running SNMP. SNMPing, developed by SANS, is a Windows-based toolkit that looks for SNMP daemons on port 161 or another port. SNScan, a similar utility developed by Foundstone, quickly and accurately identifies SNMP-enabled devices on a network.

Patches. If you find SNMP-enabled devices on your network, it is a good idea to contact the manufacturers of those devices to find out if they have developed the necessary patches.

Disable the SNMP service. If your network does not need the SNMP service, CERT recommends disabling or removing this service. However, OUSPG testing showed that some of the potentially vulnerable products were susceptible to DoS attacks or other network disruptions even when SNMP was disabled.

Inlet filtration. Firewalls and routers can be configured to perform ingress filtering on UDP ports 161 and 162, which can prevent external network attacks on vulnerable devices on the local network. Other ports supporting SNMP related services, including TCP ports and UDP 161, 162, 199, 391, 750, and 1993 may also require input filtering.

Output filtering. Devices that provide public services do not normally initiate outbound traffic to the Internet. To control traffic leaving the network, implement egress filtering. Filtering outgoing traffic on UDP ports 161 and 162 at the network edge can prevent your system from being used as a staging area for attack.

Changing default community strings. As noted, most SNMP-oriented products have the default community strings public for read-only access and private for read-write access. You need to change these default community string values. The new community name will, however, still be vulnerable to packet sniffing.

Updating signatures. Another solution could be to keep IDS signatures up to date. Signatures that directly address the defects discovered by the Protos project are now available from many intrusion detection system vendors. For example, Snort, a community of freely available network intrusion detection solutions, has developed a set of rules designed to handle malformed packets using the Protos package. Cisco Systems has updated the signature for its Secure Intrusion Detection System, which can be obtained anonymously. Internet Security Systems has released a common signature for its RealSecure and BlackICE products.

The simplicity of the popular SNMP protocol results in increased vulnerability. Because SNMP is so widely used, operating networks with vulnerable products can have disastrous consequences. CERT staff, researchers, and vendors offer a number of solutions to help mitigate potential attacks that exploit these vulnerabilities.

Juofei Jiang ( [email protected]) is a senior research engineer at the Institute for Research in Security Technology at Dartmouth College. His research interests include computer networks and security, distributed Information Systems, mobile agents and machine learning.

Literature

"CERT Advisory CA-2002-03: Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP)", 12 Feb. 2002, (current March 11, 2002)
"PROTOS: Security Testing of Protocol Implementations", 19 July 2001 (current 11 2002 March)
"PROTOS Test-Suite: c06-snmpv1", 12 Feb. 2002 (current March 11, 2002)
"M-042: Multiple Vulnerabilities in Multiple Implementations of SNMP", 12 Feb. 2002 (current March 11, 2002)

SNMP is an application-level protocol designed for the TCP/IP stack, although there are implementations for other stacks, such as IPX/SPX. The SNMP protocol is used to obtain information from network devices about their status, performance and other characteristics, which are stored in the Management Information Base (MIB). The simplicity of SNMP is largely due to the simplicity of the SNMP MIBs, especially their first versions, MIB I and MIB II. In addition, the SNMP protocol itself is also very simple.

An agent in the SNMP protocol is a processing element that provides managers located at network management stations with access to the values of MIB variables and thereby enables them to implement functions for managing and monitoring the device.

The main management operations are carried out in the manager, and the SNMP agent most often performs a passive role, transferring to the manager upon request the values of accumulated statistical variables. In this case, the device operates with minimal overhead for maintaining the control protocol. It uses almost all of its processing power to perform its basic functions as a router, bridge, or hub, and the agent collects statistics and device state variable values and reports them to the management system manager.

SNMP - this is a protocol like "request-response", that is, for every request received from the manager, the agent must send a response. A special feature of the protocol is its extreme simplicity - it includes only a few commands.

The Get-request command is used by the manager to obtain from the agent the value of an object by its name.

The GetNext-request command is used by the manager to retrieve the value of the next object (without specifying its name) by sequentially scanning the object table.

Using the Get-response command, the SNMP agent sends the manager a response to the Get-request or GetNext-request commands.

The Set command is used by the manager to change the value of an object. The Set command is used to actually control the device. The agent must understand the meaning of the values of the object that is used for device control, and based on these values perform real control actions - disable a port, assign a port to a specific VLAN, etc. The Set command is also suitable for setting a condition under which the SNMP agent must send a corresponding message to the manager. Reactions to events such as agent initialization, agent restart, connection loss, connection restoration, incorrect authentication, and loss of the nearest router can be defined. If any of these events occur, the agent issues an interrupt.

The Trap command is used by the agent to notify the manager that an exception has occurred.

SNMP v.2 adds the GetBulk command to this set, which allows the manager to obtain multiple variable values in one request.

CONCLUSION
The study is devoted to the issues of ensuring the security of network interaction using the SNMP protocol. In the process of work, the features of the named protocol were identified and possible problems its use. To substantiate the problem, statistical data are provided confirming the high probability of network attacks. In addition, the theoretical part contains information about the structure of the protocol, the request/response scheme and the stages of obtaining responses to requests.
As part of the course work, an analysis of possible attacks on the SNMP protocol was carried out, among which are Dos attacks, Buffer Overflow attacks and those using format string vulnerabilities. Of course, there are many more potential threats, but their review requires a more in-depth and comprehensive study aniye.
To build a system for protecting the network interaction of network subscribers, methods for preventing attacks on the SNMP protocol were considered and it was noted that the use of a set of tools would be effective.
Based on the analysis, it was revealed that the SNMP protocol is quite vulnerable and, if you still decide to use it, you should develop a security policy and adhere to all its principles.
Thus, we can conclude that the goal has been achieved and the tasks defined in the introduction have been solved.

INTRODUCTION
The modern rapid development of information technology places new demands on the storage, processing and distribution of data. From traditional storage media and dedicated servers, companies and individuals are gradually moving to remote technologies implemented through global network Internet. Internet services can become indispensable tools functioning of a modern, dynamically developing company, which include email; exchange of files, voice messages and data using video applications; development of your own Web resources.
According to many experts, the widespread use of Internet technologies requires the construction of a system for effective management of network devices, one of the tools of which can be become the SNMP protocol. However, organizing the management and monitoring of network devices through this protocol makes network elements vulnerable to attacks. Thus, issues of technology for preventing network attacks in the light of the development of Internet services come to the fore and require comprehensive analysis. That is why the research topic is relevant.
The questions of many authors have been devoted to the issues of building a system for protecting against attacks on the SNMP protocol, but there is no consensus on the advisability of using SNMP due to the complexity of ensuring security. Thus, Flenov M. in his book “Linux through the eyes of a Hacker” highlighted the disadvantages of this protocol and does not recommend its use. Smirnova E. B. In the textbook “Switching and routing technologies in local computer networks» provides information on multicast data transmission schemes and effective management of network equipment using the SNMP protocol, and also separately highlights the security issues of its use. A further review of specialized literature and Internet sources confirmed the need to study the issues of secure use of the SNMP protocol in order to decide on the advisability of its use. basis for this decision will be an analysis of possible attacks and the effectiveness of methods to prevent them.
The purpose of the study is to conduct a comprehensive analysis of possible attacks on the SNMP protocol and countermeasures.
To achieve the goal, it is necessary to solve a number of problems:
1. Conduct a review of literature and Internet sources on the organization of secure network interaction based on the use of the SNMP protocol.
2. Justify the need to study methods of attacks on the SNMP protocol and ways to prevent them.
3. Highlight the features of management based on the SNMP protocol.
4. Conduct an analysis of techniques for the SNMP protocol.
5. Describe methods for preventing attacks on the SNMP protocol.
The object of study is the SNMP protocol.
The subject of the research is methods of network attacks on the SNMP protocol and ways to prevent them.
Research methods: analysis, synthesis, study of information sources.
The course work consists of an introduction, two chapters and a conclusion. The first chapter is devoted theoretical justification Problems. The second chapter contains an analysis of possible attacks and ways to prevent them

CONTENT
INTRODUCTION 3
1. THEORETICAL BASIS OF THE PROBLEM OF RESEARCHING METHODS OF ATTACKS ON THE SNMP PROTOCOL
1.1 THE NEED FOR STUDYING METHODS OF ATTACKS ON SNMP 5 PROTOCOL
1.2 SNMP PROTOCOL: DESCRIPTION, PURPOSE 7
2. ANALYSIS OF ATTACKS ON THE SNMP PROTOCOL AND COUNTERMEASURES
2.1 TECHNIQUES FOR ATTACKS ON THE SNMP PROTOCOL AND WAYS TO PREVENT THEM 11
2.2 WAYS TO COUNTER ATTACKS ON SNMP 15 PROTOCOL
CONCLUSION 20
LIST OF SOURCES USED 21

LIST OF SOURCES USED
Regulations
1. Federal Law of the Russian Federation dated July 27, 2006 N 149-FZ On information, information technology and information protection
List of specialized and scientific literature
2. Blank-Edelman D. Perl for system administration, M.: symbol-Plus, 2009.- 478 p.
3. Borodakiy V.Yu. Practice and prospects for creating a secure information and computing cloud based on MSS OGV / V.Yu. Borodakiy, A.Yu. Dobrodeev, P.A. Nashchekin // Current problems of development of technological systems of state security, special communications and special information support: VIII All-Russian interdepartmental scientific conference: materials and reports (Orel, February 13-14, 2013). - At 10 o'clock. Part 4 / Generally ed. V.V. Mizerova. - Eagle: Akade Mission of the Federal Security Service of Russia, 2013.
4. Grishina N.V. Organization of a comprehensive information security system. - M.: Helios ARV, 2009. - 256 p.
5. Douglas R. Mauro SNMP Basics, 2nd edition / Douglas R. Mauro, Kevin J. Schmidt - M.: Symbol-Plus, 2012.-725p.
6. Kulgin M.V. Computer networks. Construction practice. For professionals, St. Petersburg: Peter, 2003.-462 p.
7. Mulyukha V.A. Methods and means of protecting computer information. Firewall: Textbook / Mulyukha V.A., Novopashenny A.G., Podgursky Yu.E. - St. Petersburg: SPbSPU Publishing House, 2010. - 91 p.
8. Olifer V. G., Olifer N. P. Computer networks. Principles, technologies, protocols. - 4th. - St. Petersburg: Peter, 2010. -902 p.
9. Switching and routing technologies in local computer networks: textbook / SmirnovaE. V. et al.; ed. A.V. Proletarsky. - M.: Publishing house of MSTU im. N.E. Bauman, 2013. - 389 p.
10. Flenov M. Linux through the eyes of a Hacker, St. Petersburg: BHV-St. Petersburg, 2005. - 544 p.
11. Khoreyev P.V. Methods and means of protecting information in computer systems. - M.: publishing center "Academy", 2005. -205 p.
12. Khoroshko V. A., Chekatkov A. A. Methods and means of information protection, K.: Junior, 2003. - 504 p.
Internet sources
13. IDS/IPS - Intrusion detection and prevention systems [Electronic resource] URL: http://netconfig.ru/server/ids-ips/.
14. Analysis of Internet threats in 2014. DDoS attacks. Hacking websites. [Electronic resource]. URL: http://onsec.ru/resources/Internet%20threats%20in%202014.%20Overview%20by%20Qrator-Wallarm.pdf
15. Kolischak A. Format string vulnerability [Electronic resource]. URL: https://securityvulns.ru/articles/fsbug.asp
16. First Mile, No. 04, 2013 [Electronic resource]. URL: http://www.lastmile.su/journal/article/3823
17. SNMP family of standards [Electronic resource]. URL: https://ru.wikibooks.org/wiki /SNMP_standards_family
Foreign literature
18. "CERT Advisory CA-2002-03: Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP)", 12 Feb. 2002, (current March 11, 2002

Description of work

The question of reliability and maximum operational efficiency arises especially acutely. computer networks. Huge losses from network problems leading to data loss, a sharp drop in performance, server blocking and other troubles are suffered by banks, financial, transport and telecommunications companies. Consequently, the problem of network management is of particular relevance.
Network management is a set of measures and activities aimed at increasing the efficiency of the network, detecting and eliminating failures in its operation, its proper development and modernization, and ultimately reducing costs.

INTRODUCTION………………………………………………………………………………..3

1.2 Logic of the SNMP protocol………………………………………………………..….12

2.1 Security of the SNMP protocol (or version of the SNMP protocol)……….21
2.2 Principles of configuring the SNMP protocol…………………………………23
CONCLUSION…………………………………………………………….....26
REFERENCES………………………..…………………………...…27

Files: 1 file

Ministry of Education and Science of the Russian Federation

FSBEI HPE "Chelyabinsk State University"

Institute of Information Technologies

Department of Information Technologies

COURSE WORK

SNMP protocol. Network attack and defense methods

Completed by a student

Galiullina Oksana Kuntuarovna

IIT Faculty, BIS-201 Group

Scientific adviser:

Kosenko Maxim Yurievich

Lecturer of the department

information technologies

Submission date:_______________

Defense date:___________

Grade:__________________

Chelyabinsk

INTRODUCTION………………………………………………………………..3

CHAPTER I. SNMP DEFINITION……………………………………………5

1.1 SNMP protocol architecture……………………………………………………….6

1.2 Logic of the SNMP protocol………………………………………………………..….12

CHAPTER II. MIB……………………………………………………………………………….16

CHAPTER III. SECURITY AND SNMP CONFIGURATION………………..…….21

2.1 Security of the SNMP protocol (or version of the SNMP protocol)……….21

2.2 Principles of setting up the SNMP protocol…………………………………23

CONCLUSION……………………………………………………………………26

REFERENCES……………………..………………………… ...…27

INTRODUCTION

The activities of modern organizations are closely related to the use of information technology, be it a computer at the workplace of a manager of a small company or the corporate network of a large company - a system integrator. And the larger the organization and the more important its functions, the higher the requirements for computer systems that ensure the performance of these functions, and the higher the price of each failure. The performance of a company is becoming more and more dependent on the quality of its computer and telecommunications equipment.

The question of reliability and maximum efficiency of the functioning of computer networks arises especially acutely. Huge losses from network problems leading to data loss, a sharp drop in performance, server blocking and other troubles are suffered by banks, financial, transport and telecommunications companies. Consequently, the problem of network management is of particular relevance.

Network management is a set of measures and activities aimed at increasing the efficiency of the network, detecting and eliminating failures in its operation, its proper development and modernization, and ultimately reducing costs.

Currently, applications running on network management platforms such as HP OpenView from Hewlett-Packard, NetView for AIX (IBM), SunNet Manager (Sun), Spectrum (Cabletron Systems), NetWare Management Systems (Novell) are used to manage networks. ) and various other cross-platform controls.

These tools are based on the use of the SNMP (Simple Network Management Protocol) protocol. The SNMP protocol is designed to collect and transmit service information (status information) between different computers.

CHAPTER I. SNMP DEFINITION

SNMP is a protocol from the TCP/IP family (The SNMP protocol is described in RFC 1157). It was originally developed by the Internet community to monitor and troubleshoot routers and bridges. SNMP allows you to monitor and transmit status information:

computers running Windows NT;
LAN Manager servers;
routers and gateways;
minicomputers or mainframes;
terminal servers;
concentrators.

SNMP uses a distributed architecture consisting of management systems and agents. Using the Microsoft SNMP service, a computer running Windows NT can report its status to an SNMP management system on a network that uses the TCP/IP protocol.

The SNMP service sends status information to one or more computers upon request or when an important event occurs, such as a computer running low on hard drive space.

1.1 SNMP protocol architecture

A network that uses SNMP for management contains three main components:

SNMP manager - software installed on the administrator’s PC (monitoring system)
SNMP agent is software running on the network node that is being monitored.
SNMP MIB - MIB is Management information base. This component of the system provides structured data exchanged between agents and managers. In essence, it is a kind of database in the form of text files.

SNMP manager and SNMP agent

To understand the purpose of the components, we can say that the SNMP manager is a layer (interface) between the operator administrator and the network node running the SNMP agent. We can also say that an SNMP agent is an interface between the SNMP manager and the hardware on a network node. If we compare the SNMP protocol with a client-server architecture (for example, a web server), then the web server runs as a service on a certain port, and the user uses the browser to access the web server as a client. It is a clearly defined architecture with a distinct client and server. In the case of SNMP, the roles of client and server are somewhat blurred. For example, an SNMP agent is a kind of service that runs on a device (which is being monitored) and processes requests on a specific udp/161 port, that is, it is actually a server. And the SNMP manager is a kind of client that accesses the SNMP agent server. In SNMP there is a so-called. Trap. This is a request from an agent to a manager. More precisely, not even a request, but a notification. When this notification is sent, the agent and manager “switch roles.” That is, in this case the manager must be a server running on port udp/162, and the agent must be a client. IN latest versions An SNMP trap may be referred to as a notification.

SNMP operates at layer 7 of the OSI model, that is, it is an application layer service. The interaction between the agent and the manager at the SNMP protocol level is organized through the so-called. packets of PDU (Protocol Data Unit) objects that are encapsulated in the transport protocol. Although SNMP supports various types of transport, in 99% of cases UDP is used. In this case, each PDU message contains a specific command (to read a variable, write the value of a variable, or respond to a trap agent). In general, the interaction of nodes via SNMP can be represented by the following sequence: manager->SNMP(PDU)-UDP-IP-Ethernet-IP-UDP-SNMP(PDU)->agent.

When using SNMP encryption, the default port for requests/responses is udp/10161, and Traps are sent to udp/10162.

Agents running on hosts collect information about devices and write the collected counters to variable values in the MIB database. Thus making it accessible to managers.

Rice. 1. Scheme of interaction between SNMP agent and SNMP manager

The SNMP manager sends requests to the agent on port udp/161 (if another port is not configured in the agent) from an arbitrary port from the ephemeral range. The SNMP manager request specifies the port and source address. Next, the agent receives the packet and processes it (if the conditions described below are met). During processing, a response is generated and sent to the port taken from the original request. The response is sent from udp/161 port. We can say that the SNMP agent thus provides the SNMP manager with access to the data stored in the MIB. At the same time, at the time of sending, the SNMP manager inserts a certain ID (RequestID) into the PDU, and the agent inserts this ID without changing in the response PDU, so that the manager does not confuse packets from different agents. The SNMP agent can be configured to send Trap notifications, which it does from an ephemeral port to the udp/162 port of the SNMP manager.

SNMP PDU (or SNMP protocol messages)

Above I mentioned the unit of exchange between SNMP nodes - PDU (Protocol Data Unit), let's look at this concept. A specific set of PDU command messages is used for exchange between the agent and the manager:

Trap is a one-way notification from the SNMP agent -> manager about an event.
GetReponse - a response from an agent to a manager, returning the requested variable values.
GetRequest - a request to the agent from the manager, used to obtain the value of one or more variables.
GetNextRequest - a request to the agent from the manager, used to obtain the next variable value in the hierarchy.
SetRequest - a request to the agent to set the value of one or more variables.
GetBulkRequest – a request to the agent to receive an array of data (tuned GetNextRequest). (This PDU was introduced in SNMPv2.)
InformRequest – one-way notification between managers. Can be used, for example, to exchange information about the MIB (correspondence between symbolic OIDs and digital ones). In response, the manager generates a similar package to confirm that the initial data has been received. (This PDU was introduced in SNMPv2.)

As you can see, depending on the version of the protocol, the set of commands is different (for example, InformRequest and GetB ulkRequest fully appeared only in the second version of SNMP).

PDU structure

Looking at the PDU structure is not necessary, but it will help you gain a deeper understanding of the SNMP logic. All PDUs (except Trap) consist of a specific set of fields in which the necessary information is recorded:

Rice. 2. Format of five SNMP messages encapsulated in a UDP datagram

What do these fields mean:

Version - contains the SNMP version;
Password (community) - contains a sequence of characters describing membership in the group;
The PDU type has a numeric request identifier (Get, GetNext, Set, Responde, Trap...);
The request identifier is the same set of characters that links the request/response into a single whole;
Error status is a number characterizing the nature of the error:

For requests (Get, Set, GetNExt, etc.) - 0
For answers:

0 (NoError) – No errors;
1 (TooBig) - The object does not fit into one Response message;
2 (NoSuchName) – non-existent variable;
3 (BadValue) – when trying to set the value, an invalid value was specified or a syntax error was made;
4 (ReadOnly) – during a Set request, there was an attempt to change a read-only variable;
5 (GenErr) – other errors.

Error index – contains a certain index of the variable to which the error relates;
The associated variables field can contain one or more variables (for Get requests this is only the name of the variables, for Set - the name and the value to be set, for Response - the name and the requested value).

At the same time, the contents of the Trap PDU contain some additional fields (instead of the request header):

Company – characterizing the host manufacturer;
The type of trap notification can be as follows:

0 (Coldstart) and 1 (Warmstart) – the object is returned to its initial state (there is some difference between them, but what?..);
2 (Linkdown) – the interface is omitted, while the variable field contains the interface in question;
3 (Linkup) – the interface has risen, and the variable field contains the interface in question;
4 (Authenticationfailure) – the manager sent a message with an incorrect community string;
5 (EGPneighborloss) – find it difficult to say anything);
6 (Entrprisespecific) – this type Trap indicates that the following field contains a vendor-specific trap type.

Specialized Trap type;
Timestamp – contains a timestamp from the moment of the event (it is not clear what this label is relative to...).