Всем привет. Эксперименты с эмуляцией сети продолжаются. В этот раз, как и обещал, будем делать вид, что в нашей виртуальной сети завелась машина с честным snmp-агентом.
SNMP — довольно старый протокол и знаком каждому сисадмину. На этот протокол в своё время возлагали весьма большие надежды, но в последнее время его использование сильно ограничено — как правило, это чтение переменных стандартных mib-ов на железках, не имеющих нормальных операционок (читай linux, ios и т.д.). А вот с хостов, соответственно — под управлением нормальных операционных систем, предпочитают забирать информацию с помощью cli или агентов на python/perl/bash, которые могут залезть в интимные места файловой системы /proc, парсить логи, запускать вспомогательные процессы и отдавать результаты в json/xml в неограниченных объёмах по защищённым ssl каналам.
С точки зрения системного администратора протокол действительно Simple. Всего-то пара типов запросов — get/getnext да оперативное информирование — trap. Есть ещё set, но про него в основном все знают только в теории, т.к. из-за слабой безопасности практиковать даже не пытаются. Ну и вишенка на торте — стандартные mib немного не успевают за жизнью, а в .enterprises уже никто не хочет ковыряться, даже производители.
Однако, несмотря на свои недостатки, данный протокол ещё остаётся безотказной «рабочей лошадкой» для большинства систем мониторинга. Да, стандартные MIB не позволяют в полной мере отразить топологию сети содержащей различные криптошлюзы, туннели, виртуальные роутеры, асимметричные маршруты и т.д., но базовую структуру сети собрать можно даже на коленке — утилитами командной строки snmpget и snmpwalk. Также некоторым достоинством является использование протокола UDP и кодирование ASN1 позволяющие передать всю необходимую информацию в объёме одного крохотного пакета без установки сессии. Плюс реализация snmp-агента может быть весьма небольшой по размеру и встраиваться в системы с очень ограниченными ресурсами.
Разумеется, вышеприведённой информации недостаточно, чтобы создать рукотворный «мираж» в виде фантомного хоста сети, который будет корректно отзываться на snmp-запросы. Попытаемся погрузиться в теорию — сначала лайтовенько «SNMP: Simple? Network Management Protocol», потом чуток поглубже «ASN.1 простыми словами». Мы уже в полушаге от создания собственной реализации net-snmp. Впрочем, кого я обманываю? В первой части я уже написал, что использовал библиотеку csnmp :), значит, идём на гитхаб и берём её там. Но статьи всё же прочитайте.
▍ Подготовка
Достаём из архивов исходники предыдущей части, будем их дописывать.
Скачиваем csnmp (Copyright © 2019 Nikifor Seryakov) и распаковываем рядом с каталогом, где ведутся эксперименты. Для нашего проекта будут задействованы
asn1.h, asn1.c, snmp.h, snmp.c. Возникает вопрос — почему не скопировать их в наш каталог, как мы поступили с LaBrea, и таким образом облегчить объём исходников? Дело в том, что все исходные файлы LaBrea в самом начале имеют обширнейшие комментарии с реквизитами и ссылками на создателей, лицензионные ограничения и т.д., а вот csnmp прекрасно обходится без всего вот этого :). Единственным источником идентификации автора и правил использования является файл LICENSE. Поэтому я и предлагаю сохранить исходники csnmp в полном объёме.Компиляция немного меняется:
$ gcc -o netemu -ldnet -lpcap netemu.c pkt.c bget.c ../csnmp/asn1.c ../csnmp/snmp.c
И кажется пора рисовать Makefile…
▍ Обрабатываем snmpget
В данном примере будет показан самый минимум — ответ на SNMP_GET по OID system.sysDescr.0. Для существенного облегчения задачи будем использовать протокол SNMPv1 UDP/161. Безопасность и раньше в snmp была не очень, а здесь я даже не смотрю в поле community :). Конечно, данную проверку прикрутить несложно, но для демонстрации работы с пакетами snmp это избыточно.
В начало файла добавляем ссылки на заголовочные файлы, пути должны соответствовать реальному размещению исходников csnmp:
#include "../csnmp/asn1.h"
#include "../csnmp/snmp.h"
Немного корректируем функцию ip_handler — находим в области обработки протокола ICMP объявление
struct addr a; и переносим в самое начало функции. Это необходимочтобы мы могли воспользоваться этой переменной при обработке пакета UDP.
Там, где мы выводим заголовки пакета UDP, добавляем следующий код:
addr_aton("10.0.0.5", &a);
if ((pkt->pkt_ip->ip_dst == a.addr_ip)
&& (ntohs(pkt->pkt_udp->uh_dport) == 161)) send_snmp_reply(pkt);
Здесь я думаю всё понятно — по прилёту пакета snmp (udp/161) будем отзываться, только если в качестве приёмника там фигурирует адрес
10.0.0.5.Готовим функцию send_snmp_reply. Но предварительно необходимо объявить пару функций из csnmp. Дело в том, что мы не планируем отправку пакетов средствами csnmp, нам от неё необходим только разбор пакетов, манипуляции с переменными и формирование пакета в буфер. И как раз работа с буфером скрыта в недрах snmp.c и не задекларирована в snmp.h. Вносить какие-либо изменения в snmp.h не будем, а просто объявим их у себя:
extern int snmp_dec_pdu(const char *buf, int buf_len, snmp_pdu_t *p);
extern int snmp_enc_pdu(char **buf, int *i, int *buf_len, snmp_pdu_t *p);
void send_snmp_reply(struct pkt *pkt)
{
snmp_pdu_t p = {};
snmp_dec_pdu(pkt->pkt_udp_data, ntohs(pkt->pkt_udp->uh_ulen) - UDP_HDR_LEN, &p);
/* show snmp request */
snmp_dump_pdu(NULL, &p);
snmp_var_t *v;
switch (p.command) {
case SNMP_CMD_GET:
p.command = SNMP_CMD_RESPONSE;
for (int i = 0; i < p.vars_len; i++) {
v = &p.vars[i];
snmp_free_var_value(v);
if (asn1_cmp_oids(v->oid, asn1_crt_oid((int[9]){1,3,6,1,2,1,1,1,0}, 9)) == 0) {
v->type = SNMP_TP_OCT_STR;
v->value = asn1_new_str("APC Web/SNMP Management Card", 0);
}
else
v->type = SNMP_TP_NO_SUCH_OBJ;
}
break;
case SNMP_CMD_GET_NEXT:
break;
default:
break;
}
if (p.command == SNMP_CMD_RESPONSE) {
p.error = (asn1_error_t){0};
int buf_len = 20 * (1<<10);
char *buf = malloc(buf_len);
int pdu_len = 0;
snmp_enc_pdu(&buf, &pdu_len, &buf_len, &p);
/* show snmp reply */
snmp_dump_pdu(NULL, &p);
struct pkt *new = NULL;
if ((new = pkt_new()) == NULL) return;
eth_pack_hdr(new->pkt_eth,
pkt->pkt_eth->eth_src, /* orig src MAC becomes new dest MAC */
io.mymac, /* my own mac becomes new src MAC */
ETH_TYPE_IP);
ip_pack_hdr(new->pkt_ip,
0, /* tos */
(IP_HDR_LEN + UDP_HDR_LEN + pdu_len), /* IP hdr length */
rand_uint16( io.rnd ), /* ipid */
0, /* frag offset */
IP_TTL_DEFAULT,
IP_PROTO_UDP, /* ip protocol of original pkt */
pkt->pkt_ip->ip_dst, /* orig dst becomes new src addr */
pkt->pkt_ip->ip_src);
new->pkt_udp_data = (u_char *)(new->pkt_ip_data + UDP_HDR_LEN);
new->pkt_end = (u_char *)new->pkt_eth_data + ntohs(new->pkt_ip->ip_len);
udp_pack_hdr(new->pkt_udp,
htons(pkt->pkt_udp->uh_dport),
htons(pkt->pkt_udp->uh_sport),
UDP_HDR_LEN + pdu_len);
memcpy(new->pkt_udp_data, buf, pdu_len);
free(buf);
ip_checksum(new->pkt_ip, new->pkt_end - new->pkt_eth_data);
int ret_code = eth_send(io.eth, new->pkt_eth, new->pkt_end - (u_char *)new->pkt_eth);
if (ret_code < 0)
printf("*** Problem sending packet\n");
}
snmp_free_pdu_vars(&p);
snmp_free_pdu(&p);
}
Какая длинная функция получилась, попробую объяснить (если захотите, нарубите её на кусочки самостоятельно).
Вначале объявляем переменную
p типа snmp_pdu_t и парсим в неё информацию из полученного пакета. Делаем это как раз функцией snmp_dec_pdu спрятанной от пользователей csnmp.Далее на консоль показываем — что именно мы получили и приступаем непосредственно к формированию ответа. Ответ мы будем формировать корректируя уже готовую переменную p — почти также, как мы ранее обращались с пакетом icmp echo request.
Условный оператор switch на основании значений
p.command раскидывает логику обработки запроса по нескольким веткам. Допустимые варианты данном контексте: SNMP_CMD_GET, SNMP_CMD_GET_NEXT, SNMP_CMD_SET, SNMP_CMD_GET_BULK. Мы пока что реализуем SNMP_CMD_GET, а также оставим заготовку для SNMP_CMD_GET_NEXT — всё остальное идёт в default.Как уже писал выше, сначала сменим тип snmp-пакета — он теперь должен стать
SNMP_CMD_RESPONSE. Далее в цикле пробежимся по переменным в данном запросе, почистим их значения, и если запрашиваемый oid равен .1.3.6.1.2.1.1.1.0 (system.sysDescr.0) то готовим ответ типа Octet String. Как видно исходники — это всё вставляется в поля type и value.Значения
OID, их типы, описания можно посмотреть в вашей локальной системе (/usr/share/snmp/mibs/SNMPv2-MIB.txt) или поискать в интернете по ключам: «SNMPv2 MIB», «RFC 3418:12/2002».Цикл с пробежкой по переменным я честно скопипастил из демо-кода csnmp. На мой взгляд, было бы достаточно поработать только с переменной имеющей индекс 0, но, кажется, автор csnmp более продвинут в этом вопросе, поэтому пока оставил так.
Сама переменная типа
snmp_var_t это структура из 3-х полей: oid — структура типа snmp_oid_t (точнее, ans1_oid_t) хранящая «имя» snmp-переменной; type — целое число, определяющее тип значения; value — указатель на само значение, т.е. адрес в памяти, где оно располагается.В случае если желаемый
oid не совпал с нашими возможностями, мы просто ставим тип переменной SNMP_TP_NO_SUCH_OBJ и следуем к формированию пакета и возврату его обратно.Отправку пакета завернул в условие
if (p.command == SNMP_CMD_RESPONSE). Это логично и правильно — если мы не заинтересовались пакетом, то не сменили его тип на ответ, а следовательно — и отвечать на него не считаем нужным.Формирование пакета также производим с помощью «скрытой» функции
snmp_enc_pdu. Далее кропотливая сборка пакета, вычисление размеров на каждом уровне и отправка — всё это было описано в предыдущей статье, здесь только отличие в протоколе UDP.Ну и в финале мы очищаем переменные — если глянуть декларацию
asn1_new_str (мы с её помощью формировали значение для отправки ответа), то становится понятно, что внутри этой функции выделяется память, которую нужно в итоге освободить и, кстати, в следующем разделе это будет видно более явно. Также необходимо очистить и саму pdu — там тоже достаточно компонентов с динамически выделяемой памятью.Код написан, пора пробовать.
Отлично! Всё работает как и ожидалось. Было точное совпадение OID — получите искомое, не совпало — ну нет, значит нет. Переходим на следующий этап.
▍ Обрабатываем snmpgetnext
Обработка запросов типа snmpgetnext будет также вписана в нашу мегафункцию
void send_snmp_reply(struct pkt *pkt) — помнится, для этого там было зарезервировано местечко.Вставляем:
case SNMP_CMD_GET_NEXT:
p.command = SNMP_CMD_RESPONSE;
v = &p.vars[0];
// спрашивают, что у нас идёт за system.sysDescr.0
if (asn1_cmp_oids(v->oid, asn1_crt_oid((int[9]){1,3,6,1,2,1,1,1,0}, 9)) == 0) {
snmp_free_var(v);
// возвращаем system.sysObjectID.0
v->oid = asn1_crt_oid((int[9]){1,3,6,1,2,1,1,2,0}, 9);
v->type = SNMP_TP_OID;
v->value = asn1_new_oid((int[10]){1,3,6,1,4,1,318,1,3,7}, 10);
}
// запрос system.sysObjectID.0
else if (asn1_cmp_oids(v->oid, asn1_crt_oid((int[9]){1,3,6,1,2,1,1,2,0}, 9)) == 0) {
snmp_free_var(v);
// возвращаем system.sysUpTime.0
v->oid = asn1_crt_oid((int[9]){1,3,6,1,2,1,1,3,0}, 9);
v->type = SNMP_TP_TIMETICKS;
v->value = malloc(sizeof(int));
*(int *)v->value = ((((5*24) + 11)*60 + 35)*60 + 24)*100 + 22; // 5 days, 11:35:24.22
}
// запрос system.sysUpTime.0
else if (asn1_cmp_oids(v->oid, asn1_crt_oid((int[9]){1,3,6,1,2,1,1,3,0}, 9)) == 0) {
snmp_free_var(v);
// возвращаем system.sysContact.0
v->oid = asn1_crt_oid((int[9]){1,3,6,1,2,1,1,4,0}, 9);
v->type = SNMP_TP_OCT_STR;
v->value = asn1_new_str("Comparitech", 0);
}
// запрос system.sysContact.0
else if (asn1_cmp_oids(v->oid, asn1_crt_oid((int[9]){1,3,6,1,2,1,1,4,0}, 9)) == 0) {
snmp_free_var(v);
// возвращаем system.sysName.0
v->oid = asn1_crt_oid((int[9]){1,3,6,1,2,1,1,5,0}, 9);
v->type = SNMP_TP_OCT_STR;
v->value = asn1_new_str("APC-3425", 0);
}
// запрос system.sysName.0
else if (asn1_cmp_oids(v->oid, asn1_crt_oid((int[9]){1,3,6,1,2,1,1,5,0}, 9)) == 0) {
snmp_free_var(v);
// возвращаем system.sysLocation.0
v->oid = asn1_crt_oid((int[9]){1,3,6,1,2,1,1,6,0}, 9);
v->type = SNMP_TP_OCT_STR;
v->value = asn1_new_str("3425EDISON", 0);
}
// запрос system.sysLocation.0
else if (asn1_cmp_oids(v->oid, asn1_crt_oid((int[9]){1,3,6,1,2,1,1,6,0}, 9)) == 0) {
snmp_free_var(v);
// возвращаем system.sysServices.0
v->oid = asn1_crt_oid((int[9]){1,3,6,1,2,1,1,7,0}, 9);
v->type = SNMP_TP_INT;
v->value = malloc(sizeof(int));
*(int *)v->value = 72;
}
// запрос system.sysServices.0
else if (asn1_cmp_oids(v->oid, asn1_crt_oid((int[9]){1,3,6,1,2,1,1,7,0}, 9)) == 0) {
snmp_free_var(v);
// возвращаем inerfaces.ifTable.ifEntry.ifIndex.1
v->oid = asn1_crt_oid((int[9]){1,3,6,1,2,1,2,1,0}, 9);
v->type = SNMP_TP_INT;
v->value = malloc(sizeof(int));
*(int *)v->value = 1;
}
// запрос что-нибудь начинающееся с system
else if (asn1_oid_has_prefix(v->oid, asn1_crt_oid((int[7]){1,3,6,1,2,1,1}, 7))) {
snmp_free_var(v);
// возвращаем system.sysDescr.0
v->oid = asn1_crt_oid((int[9]){1,3,6,1,2,1,1,1,0}, 9);
v->type = SNMP_TP_OCT_STR;
v->value = asn1_new_str("APC Web/SNMP Management Card", 0);
}
else
v->type = SNMP_TP_NO_SUCH_OBJ;
break;
default:
Пробежимся по коду. С ходу меняем значение
p.command на SNMP_CMD_RESPONSE — это уже знакомо. Далее берём только значение переменной с индексом 0 — решил тут сильно не загромождать код, думаю для тестового прототипа это допустимо.Ну а дальше муторная и монотонная (конкретно в данной демонстрашке — разумеется, боевой код так писать нельзя) работа по сверке запрошенного
oid и подготовке ответа: освобождение памяти от переменной, формирование oid следующего элемента, его тип и значение. Тут хорошо видно как обрабатывать значения различных типов, а также фигурирует более явное выделение памяти посредством malloc.На освобождение памяти хочу обратить особое внимание. Если помните, в прошлый раз чистили только значения (
snmp_free_var_value), а сейчас переменную целиком (snmp_free_var). Всё дело в протоколе snmp — при вызове snmpget мы просим дать значение конкретного oid, т.е. он не меняется, а при snmpgetnext нужно дать значение следующего элемента. Соответственно, в ответе у нас будет изменены не только тип и значение, но также будет совсем другой oid. Именно это и требует от нас тотальной зачистки.Также особого внимания заслуживают два последних условия:
Когда мы обрабатываем последний
oid на нашем уровне, в данном случае .1.3.6.1.2.1.1.7.0, мы не возвращаем в качестве следующего элемента SNMP_TP_NO_SUCH_OBJ, что кажется вполне логичным, а возвращаем первый элемент из соседней веточки. На самом деле мы с помощью snmpwalk можем пройтись по любому уровню дерева snmp как ближе к корню, так и почти на конце какой-либо ветки — он не будет выходить за пределы запроса — при получении ответа с oid вне запрошенного уровня он завершает опрос. А вот если бы мы вернули SNMP_TP_NO_SUCH_OBJ, то запрос snmpwalk с более высокого уровня прервался на нашей веточке и не пробежался по соседним. Также этот oid должен вернуться при обращении к oid большим чем .1.3.6.1.2.1.1.7.0В последнем условии производится сравнение запроса только на префикс. Это тоже особое поведение snmp-демона — при обращении в начальные области нашей ветки должен вернуться
oid первого элемента — это .1.3.6.1.2.1.1.1.0. Другими словами, все запросы к system(.1.3.6.1.2.1.1) или system.sysDescr(.1.3.6.1.2.1.1.1) должны вернуть нам ссылку и значение system.sysDescr.0(.1.3.6.1.2.1.1.1.0), а вот обращение реально существующей system.sysDescr.0(.1.3.6.1.2.1.1.1.0) вернёт следующий элемент — system.SysObjectID.0(.1.3.6.1.2.1.1.2.0)Приступаем к тестированию:
Длинный вывод я подрезал, но уже видно, что snmpwalk ничего не заподозрил!
Следующая проверка
Результат, на первый взгляд, не совсем корректный, однако если сравнить
oid запроса и oid элемента, который был возвращён в последний раз, то становится понятно — элемент вышел за уровень запроса и snmpwalk остальное перестало интересовать.Ну а напоследок один каверзный запрос:
Внимательно изучаем отладочный вывод: snmpwalk умный парень — хоть и получил сразу ответ идти в соседнюю ветку, но на этом не успокоился, а произвёл контрольный вопрос через snmpget — так есть кто живой с этим
oid или нет? Кстати, если сейчас попробуете на других oid, то получите совсем другой результат, это потому что в первой части статьи написана обработка snmpget только для system.sysDescr.0 :)▍ Финал
На этом достаточно знакомства с богатым внутренним миром такого «простого» протокола как SNMP. А для решения моей основной задачи осталось совсем немного — определится с различными структурами хранения oid и их значений, привязка к базе ip-адресов, сделать чтобы всё это извлекалось и обрабатывалось в разумные временные рамки. Это реализуется простыми и понятными алгоритмами — хэши/деревья/ключи-значения и пр. но уже не в рамках данной статьи.
Всем приятных pet-проектов :)
