Как найти все коммутаторы в сети

Я понимаю, что и как делается в реальных сетях. У меня нигде нет телнета — ни на девайсах, ни на серверах

А эту приблуду хочется сделать для препода. Что-то вроде тестера для сетей: подошёл, подключился к порту, указал IP-адрес (или получил по dhcp, если это предусмотрено в лабораторной), нажал кнопочку — нарисовалась топология; на девайс тыцнул — получил основные характеристики, может, running-config. Думаю использовать telnet и snmp

Писать определитель типа устройства, работающий на самом устройстве, незачем, ибо:

1. как быть с тупыми коммутаторами?

2. как быть с не совсем тупыми коммутаторами?

3. на умных коммутаторах и линуксах есть cdp/lldp

Делать какие-то предзашитые настройки на управляемых девайсах тоже не получится — студенты могут как угодно переворотить конфиг. В методе проще указать, что обязательно должен быть доступен телнет (3 строчки в конфиге) и snmp (1 строчка в конфиге). Можно телнет поменять на ssh и стандартный пароль, но это тоже приучение к плохому (и ещё неясно, что хуже)

hc ★

(20.08.10 08:04:47 MSD)

Обнаружение сетевых устройств

Сканирование сети с построением списка устройств и их свойств, таких как перечень сетевых интерфейсов, с последующим снятием данных в системах мониторинга, если не вникать в происходящее, может показаться особой, компьютерной, магией. Как же это работает — под катом.

Disclaimer
Автор не имеет профильного образования, связанного с администрированием сетей, поэтому наверняка имеются неточности и упомянуто не всё, что можно.

Обнаружение

Для обнаружения устройства, т.е. определения есть ли на выбранном ip-адресе что-либо, можно применить следующие методы:

• ping сканирование
  Как ни странно, это самый простой и распространенный способ.
• Проверка открытых TCP-портов
  Если на устройстве отключен ответ на ping, то можно попробовать установить соединение по какому-либо TCP-порту. В виду того, что портов много и проверка каждого занимает значительное время, обычно проверяются только самые распространенные, напр. 80 или 443, используемые для веб-интерфейса устройства.
• Проверка работы UDP служб
  UDP протокол не отправляет подтверждения о получении запроса и поэтому в общем виде сканирование UDP-портов невозможно. Однако можно попробовать опросить службы, прослушивающие UDP-порт и отправляющие ответ на запрос, напр. SNMP (порт 161) или IPMI (порт 623). В случае, если получен ответ, отличный от таймаута, то устройство обнаружено.
• ARP сканирование
  Помимо обычных ICMP запросов, которые используют утилиты ping, для устройств в том же широковещательном L2-домене можно воспользоваться более быстрым arping: по диапазону ip-адресов рассылаются широковещательные ARP пакеты вида «компьютер с IP-адресом XXX, сообщите свой MAC-адрес компьютеру с МАС-адресом запросившего», и если ответ получен, то устройство считается обнаруженным.
• CDP/LLDP
  Если в сети используется протокол LLDP (или аналог CDP), то устройства могут собирать сведения о своих соседях, которые можно считать обнаруженными. Эти данные доступны по SNMP.

  Отмечу, что информация о соседях совместно с результатами traceroute может служить основой для построения физической карты сети.

• NetBIOS сканирование
  Протокол NetBIOS может быть использован для поиска Windows-машин, например при помощи утилиты nbtscan.
• Журналы DHCP (предложено alexanster)
  В журналах DHCP-серверов есть информация о выдачи ip-адресов по MAC-адресам. Для недавних записей в журнале можно считать, что эти устройства обнаружены.
• ARPWatch (предложено alexanster, описано TaHKucT)
  Arpwatch отслеживает пары IP-адрес — MAC-адрес, записывая в лог новые, пропавшие и изменившиеся пары. Устройства, попавшие в лог, можно считать обнаруженными.
• Анализ FDB-таблиц коммутаторов(предложено mickvav)
  FDB-таблицы (Forwarding DataBase) управляемых коммутаторов содержат данные о коммутации MAC-адресов абонентов и устройств, т.е. соответствии MAC-адрес устройства — порт коммутатора.

  Данные доступны по SNMP и telnet, и могут быть использованы при построении физической карты сети.

Сбор сведений

После того, как устройство обнаружено, можно переходить к сбору сведений о нем.
Используя ARP протокол, по ip можно получить MAC-адрес, а по нему вероятного производителя (часть оборудования допускает смену адреса, так что метод не очень надежен). Далее можно воспользоваться утилитой nmap, которая сканируя открытые порты, сверяется со своей базой отпечатков и делает предположение об используемой операционной системе, её версии и типе устройства.

nmap -O -v 192.168.0.1

Starting Nmap 7.60 ( https://nmap.org ) at 2018-03-04 01:17 RTZ 2 (ceia)
Initiating ARP Ping Scan at 01:17
Scanning 192.168.0.1 [1 port]
Completed ARP Ping Scan at 01:17, 0.70s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 01:17
Completed Parallel DNS resolution of 1 host. at 01:17, 0.00s elapsed
Initiating SYN Stealth Scan at 01:17
Scanning 192.168.0.1 [1000 ports]
Discovered open port 80/tcp on 192.168.0.1
Discovered open port 49152/tcp on 192.168.0.1
Discovered open port 1900/tcp on 192.168.0.1
Completed SYN Stealth Scan at 01:17, 0.13s elapsed (1000 total ports)
Initiating OS detection (try #1) against 192.168.0.1
Retrying OS detection (try #2) against 192.168.0.1
WARNING: OS didn't match until try #2
Nmap scan report for 192.168.0.1
Host is up (0.00s latency).
Not shown: 997 closed ports
PORT      STATE SERVICE
80/tcp    open  http
1900/tcp  open  upnp
49152/tcp open  unknown
MAC Address: A0:F3:C1:35:21:58 (Tp-link Technologies)
Device type: WAP
Running: Linux 2.4.X
OS CPE: cpe:/o:linux:linux_kernel:2.4.36
OS details: DD-WRT v24-sp1 (Linux 2.4.36)
Network Distance: 1 hop

Чтобы получить более подробные сведения по устройству потребуется один из следующих способов:

• SNMP
  Протокол SNMP почти всегда поддерживаем маршрутизаторами и коммутаторами; имеется в Windows (соответствующая служба по умолчанию отключена); для Linux требуется установка демона snmpd. По всей видимости последняя третья версия достаточно сложна в реализации, поэтому предыдущая версия 2с до сих пор актуальна, хотя и не рекомендуема из-за отсутсвия шифрования при передаче данных. Протолок работает на 161 UDP-порту устройства.

  Для работы с SNMP можно использовать пакет утилит Net-SNMP. Чтобы получить, к примеру, описание устройства, надо указать версию протокола, пароль на чтение (community read, по умолчанию public) и адрес, в нотации SNMP называемый OID (object identificator) и состоящий из чисел и точек. Все адреса устройства можно представить в виде дерева, где адреса отсортированы в лексикографическом порядке. Протокол позволяет запросить текущее значение по адресу, а также адреса следующие за текущим.

  Получение описания устройства при помощи snmpget

  snmpget -v 2c -c public 192.168.0.102 1.3.6.1.2.1.1.1.0
  
  SNMPv2-MIB::sysDescr.0 = STRING: Linux debian 3.16.0-4-586 #1 Debian 3.16.43-2+deb8u2 (2017-06-26) i686 

  Стандартный набор адресов весьма ограничен и содержит описание устройства, контакты, расположение и время работы (uptime). Остальные адреса зависят от производителя устройства и могут быть получены сканированием, например, утилитой snmpwalk. К счастью, Linux и Windows имеют типовые адреса для сетевых интерфейсов и загруженности процессоров/памяти, поэтому для них лишь знать (или уметь определить) используемую операционную систему.

  Получение описания дисков Linux при помощи snmpwalk

  snmpwalk -v 2c -c public 192.168.0.102 1.3.6.1.4.1.2021.9.1.2
  
  UCD-SNMP-MIB::dskPath.1 = STRING: /
  UCD-SNMP-MIB::dskPath.2 = STRING: /var
  UCD-SNMP-MIB::dskPath.3 = STRING: /
  UCD-SNMP-MIB::dskPath.4 = STRING: /run
  UCD-SNMP-MIB::dskPath.5 = STRING: /dev/shm
  UCD-SNMP-MIB::dskPath.6 = STRING: /run/lock
  UCD-SNMP-MIB::dskPath.7 = STRING: /sys/fs/cgroup

  Получение описания дисков Windows при помощи snmpwalk

  snmpwalk -v 2c -c public localhost 1.3.6.1.2.1.25.2.3.1.3
  
  HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: C: Label:  Serial Number a65ceb77
  HOST-RESOURCES-MIB::hrStorageDescr.2 = STRING: D: Label:  Serial Number ded9f83e
  HOST-RESOURCES-MIB::hrStorageDescr.3 = STRING: E: Label:  Serial Number 8e764a1
  HOST-RESOURCES-MIB::hrStorageDescr.4 = STRING: I:
  HOST-RESOURCES-MIB::hrStorageDescr.5 = STRING: Virtual Memory
  HOST-RESOURCES-MIB::hrStorageDescr.6 = STRING: Physical Memory

• WMI
  Технология WMI — это расширенная и адаптированная под Windows реализация стандарта WBEM, позволяющая удаленно не только считывать параметры, но и управлять устройством. WMI работает поверх RPC (TCP порт 135) и DCOM (на произвольном TCP порту выше 1024), активно используется в скриптах Power Shell (ранее Windows Script Host).

  Данные можно запрашивать, разумеется, только с Windows машин.

  Получение информации об оперативной памяти в PowerShell

  Get-WmiObject win32_OperatingSystem |%{"Total Physical Memory: {0}KB`nFree Physical Memory : {1}KB`nTotal Virtual Memory : {2}KB`nFree Virtual Memory  : {3}KB" -f $_.totalvisiblememorysize, $_.freephysicalmemory, $_.totalvirtualmemorysize, $_.freevirtualmemory}
  
  Total Physical Memory: 2882040KB
  Free Physical Memory : 612912KB
  Total Virtual Memory : 5762364KB
  Free Virtual Memory  : 1778140KB

  Также имеется консольная утилита wmic и ее Linux-порт

  Получение производителя устройства при помощи wmic

  wmic /USER:admin /PASSWORD:mypassword /NODE:"192.168.0.100" computersystem get Manufacturer
  
  Manufacturer
  Gigabyte Technology Co., Ltd.

• Агент системы мониторинга, напр. Zabbix или Check_MK
  Если имеется возможность, то на устройстве устанавливается небольшая программа, работающая в фоне и собирающая данные. Преимущество использования агентов в том, что получение данных унифицировано вне зависимости от используемого устройством оборудования и операционной системы, а также возможно собирать данные доступные только локально (к примеру результат работы консольной программы).
• SSH
  Исходно данные по SSH можно получать с Linux и iOS устройств. Для Windows и Android потребуется установка SSH-сервера.

  Получение информации о CPU по SSH

  cat /proc/cpuinfo
  
  processor       : 0
  Processor       : AArch64 Processor rev 4 (aarch64)
  Hardware        : sun50iw1p1
  BogoMIPS        : 48.00
  Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
  CPU implementer : 0x41
  CPU architecture: 8
  CPU variant     : 0x0
  CPU part        : 0xd03
  CPU revision    : 4
  
  processor       : 1
  ...

• Запрос данных у управляющего сервиса, такого как гипервизор виртуальных машин

Как это работает на примере Zabbix

Как известно Zabbix может самостоятельно обнаруживать новые устройства в сети и автоматически опрашивать некоторые их параметры. Называется это — Low Level Discovery.

Обнаружение устройств задается правилами сетевого обнаружения, которые комбинируют перечисленные ранее методы обнаружения, определяют доступно ли устройство и какой шаблон к нему применить (обычно исследуется описание устройства). Шаблон содержит список свойств, которые можно получить с устройства, а также правила для обнаружения и создания новых, выполняемые по таймеру.

В случае с SNMP такое правило может выглядеть примерно так: перебрать все дочерние элементы узла 1.3.6.1.2.1.2.2.1.8 (правило обнаружения) и для каждого найденного элемента (число, помещаемое в {#SNMPINDEX}) добавить новые метрики, задаваемые через прототипы элементов данных, 1.3.6.1.2.1.2.2.1.10.{#SNMPINDEX} и 1.3.6.1.2.1.2.2.1.16.{#SNMPINDEX}, если их еще нет. Подробнее здесь.

В случае агента правило будет выглядеть немного иначе: запросить у агента одно из discovery-свойств, к примеру system.cpu.discovery, получить список процессоров в виде json

[
	{"NUMBER": 0, "STATUS": "online"},
	{"NUMBER": 1, "STATUS": "online"}
] 

и для каждого элемента добавить system.cpu.load[{#CPU.NUMBER}], если такой метрики еще нет. Стоит отметить, что Zabbix-агент позволяет создавать свои элементы (UserParameter), которые могут быть запрошены, и поэтому легко можно реализовать, например, обнаружение файлов и отслеживание их размера в заданной папке. Подробнее здесь.

Заключение

Как видно всё достаточно просто и никакой магии нет. Если вы знаете еще какие-либо способы обнаружения устройств или получения их свойств, то просьба сообщить о них.

	Поиск не настроенных коммутаторов в сети 12.01.2015, 19:51
12/01/15 3	Доброго времени суток! Ребят, нужна помощь не опытному админу в решении такой задачки. Лирика: Даже не спрашивайте чем руководствовались админы, когда решили сделать так, как описано ниже — ибо не знаю. Бывших админов уже и след простыл, контактов нет. Так что уповать на возможность узнать что-то от организации, или бывших работников — никак. Суть дела: В организации имеется пачка коммутаторов D-link 1210-48 (минимум 6 — точно пока не установлено). Все они поддерживают управление через snmp, web-интерфейс, имеют на борту tftp клиент. Сразу оговорюсь — ничего из вышеперечисленного не организовано — никакого управления. Спрятаны в стенах — физически к ним никак не подобраться. Соответственно к консольным портам для настройки — тоже. Нужно их найти и попасть на них для настройки. Подозрение, что их в принципе не настраивали. Пробовал найти их по mac-адресам (известен диапазон маков выделенный D-link’у, но не самих коммутаторов) — ни одного совпадения. Не пойму почему — маки то должны быть видны, или я заблуждаюсь? Пробовал найти по ip — на dhcp информации никакой нет, на всякий случай ручками все ip в сети проверил. Естественно ничего не нашел, они же не настроены Уже мозг кипит, не могу понять — как мне найти их в сети? Может подскажете чего дельного? П.С.:Если нужна подробная информация, могу описать всю свою деятельность — что и как искал. Пока не стал — простыня получится.

Pphantom	Re: Поиск не настроенных коммутаторов в сети 12.01.2015, 20:02
Заслуженный участник 09/05/12 25191	А к ним «снизу» что-нибудь подключить можно? Если да, то с вероятностью 99% в получившейся сетке коммутатор будет доступен по 192.168.0.1

novalit	Re: Поиск не настроенных коммутаторов в сети 12.01.2015, 20:13
12/01/15 3	Не совсем пойму, что значит «снизу»? Если речь о физическом доступе — то нет, физического доступа нет. Я бы уже у них стоял с ноутом и через консольный порт ломился =) D-Link заявляют, что эти коммутаторы меняют дефолтный ip, при наличии dhcp сервера. Погуглил — не раз наткнулся на информацию, что по каким-то причинам, этого не происходит. Видать они все на дефолтном адресе и возникают конфликты. От этого не достучаться. Положить коммутаторы в серверной, отрезав им доступ к серверам и ребутнуть их не могу по нескольким причинам — от банального отсутствия маркировки на патч-панелях, до запрета руководством прерывать работу.

Pphantom	Re: Поиск не настроенных коммутаторов в сети 12.01.2015, 20:30
Заслуженный участник 09/05/12 25191	Не совсем пойму, что значит «снизу»? Какие-то подсети к коммутаторам подключены? Иначе неясно, как их вообще предполагается использовать…

Red_Herring	Re: Поиск не настроенных коммутаторов в сети 12.01.2015, 20:31
Заслуженный участник 31/01/14 10818 Hogtown	Если да, то с вероятностью 99% в получившейся сетке коммутатор будет доступен по 192.168.0.1 192.168 будет если это класс C нетворк (чтобы я пробовал). но вот вместо 0.1 я бы еще проверил 1.1, 2.1, 0.254, 0.128 и т.д. А как насчет package sniffer? Шансов немного, но всё-таки

Pphantom	Re: Поиск не настроенных коммутаторов в сети 12.01.2015, 20:31
Заслуженный участник 09/05/12 25191	D-Link заявляют, что эти коммутаторы меняют дефолтный ip, при наличии dhcp сервера. Погуглил — не раз наткнулся на информацию, что по каким-то причинам, этого не происходит. Видать они все на дефолтном адресе и возникают конфликты. М-да, тогда, боюсь, это не лечится.

novalit	Re: Поиск не настроенных коммутаторов в сети 12.01.2015, 21:18
12/01/15 3	Не совсем пойму, что значит «снизу»? Какие-то подсети к коммутаторам подключены? Иначе неясно, как их вообще предполагается использовать… Подсети все проверил, доступа нет. Вся прелесть ситуации в том, что сеть вообще никак не организована, за исключением шлюза и днс — они в отдельной подсети, и назначения маски. Все свалено в одну большую кучу. И коммутаторы, судя по всему, использовали как неуправляемые. Когда их не настраиваешь и ставишь в сеть, они работают как неуправляемые (насколько мне известно). Однако мне не понятно, почему я не вижу ни мак адреса коммутаторов, ни мак адресов их портов. Не возьму в толк, что может мешать увидеть маки? Цитата: но вот вместо 0.1 я бы еще проверил 1.1, 2.1, 0.254, 0.128 и т.д. Проверил все доступные адреса — коммутаторов среди них нет. Цитата: А как насчет package sniffer? А вот это мысль — буду пробовать. По результату отпишусь.

Cynic	Re: Поиск не настроенных коммутаторов в сети 17.11.2015, 18:18
15/10/15 75	Цитата: ПРИМЕЧАНИЕ: На коммутаторах по умолчанию используется IP-адрес 10.90.90.90 с маской подсети — 255.0.0.0 и шлюзом по умолчанию — 0.0.0.0 см. инструкцию http://ftp.dlink.ru/pub/Switch/DGS-1210-48/Description/DGS-1210_series_QIG_RUS_01.pdf Пишут что есть ещё утиль для управления SmartConsole Utility, попробуй его, возможно там есть функция автоматического поиска. Сниффер пакетов тебе не поможет, т.к. коммутатор не будет слать пакеты со своим MAC-адресом на тот порт к которому ты отключится, т.к. для этого сначала с этого порта должен прилететь пакет на его MAC. Я сомневаюсь, что D-Link даст тебе отключить вообще всё управление. Так что скорее всего тебе поможет какой нибудь утиль который сканирует IP-адреса и порты. При этом надо иметь ввиду, что возможна ситуация когда например коммутатор будет отвечать на запросы только на какой нибудь конкретный порт и протокол. Например, на TCP/10.90.90.90:8080, так что сканируй всё (это очень долго). Также рекомендую тебе это делать ночью, при этом написав всем чтоб выключили свои компы, так тебе проще будет найти свой коммутатор. К слову, диапазонов MAC-адресов у D-Link’a может быть несколько, не факт что все MAC-адрес имеют одинаковый OUI.

Модераторы: Karan, Toucan, PAV, maxal, Супермодераторы