У меня есть доступ к двум компьютерам (A и B) в сети. Оба имеют статический IP-адрес с маской подсети 255.255.255.128 (я проверил что DHCP-сервер не использовался). Я хочу настроить несколько IP-адресов на одном компьютере и, следовательно, хочу знать, какие все IP-адреса уже используются в подсети.
Из предыдущий вопрос, Я попытался nmap -sP -PR 172.16.128.* команда, но я скептически отношусь к ее результату, поскольку одна и та же команда дает разные результаты на двух моих компьютерах (A и B). На A результат показывает список из 8 IP-адресов, которые (предположительно) уже используются, в том числе А и Б.
Nmap done: 256 IP addresses (8 hosts up) scanned in 1.23 seconds
Но на B результат другой, т.е.
Nmap done: 256 IP addresses (0 hosts up) scanned in 0.00 seconds
Результат на B даже не показывает его собственный IP-адрес, а также IP-адрес A!
Что именно я здесь делаю не так? Есть ли в Red Hat Linux (RHEL) надежный способ обнаружения всех IP-адресов, используемых в подсети, частью которой является мой компьютер?
RHEL: 6.5
Nmap version: 5.51
Любое исправное устройство в локальной сети Ethernet может игнорировать практически любой трафик, поэтому PING, сканирование портов и тому подобное ненадежны. Однако устройства не могут игнорировать ARP запросы, Насколько мне известно. Учитывая, что вы указали, что сканируете локальную сеть, я считаю, что наименее уязвимый способ сделать то, что вы хотите, - это попытаться подключиться к удаленному адресу, а затем заглянуть в мой кеш ARP.
Вот простое устройство без фильтрации (то есть устройство, которое не настроено для игнорирования некоторых классов IP-трафика):
[me@risby tmp]$ ping -c 1 -W 1 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=0.351 ms
[...]
[me@risby tmp]$ arp -a -n|grep -w 192.168.3.1
? (192.168.3.1) at b8:27:eb:05:f5:71 [ether] on p1p1
Вот фильтрующее устройство (сконфигурированное с одной строкой iptables игнорировать все трафик):
[me@risby tmp]$ ping -c 1 -W 1 192.168.3.31
[...]
1 packets transmitted, 0 received, 100% packet loss, time 0ms
[me@risby tmp]$ arp -a -n|grep -w 192.168.3.31
? (192.168.3.31) at b8:27:eb:02:e4:46 [ether] on p1p1
Вот устройство, которое только что вышло из строя; обратите внимание на отсутствие MAC-адреса:
[me@risby tmp]$ ping -c 1 -W 1 192.168.3.241
[...]
1 packets transmitted, 0 received, 100% packet loss, time 0ms
[me@risby tmp]$ arp -a -n|grep -w 192.168.3.241
? (192.168.3.241) at <incomplete> on p1p1
Этот метод не безошибочен - он, во-первых, пропускает выключенные устройства - но это наименее ужасный метод, который я когда-либо пробовал.
редактировать: Eric Duminil, да, работает только в локальной сети; см. абзац первый.
Вишала, методы функционально идентичны. Обратите внимание на текст, цитируемый в ответе Льва о nmap:
Когда привилегированный пользователь пытается просканировать цели в локальной сети Ethernet, используются запросы ARP, если только
--send-ipбыло указано.
Его метод требует меньше печатать. Мой можно сделать без привилегий, и может дать вам лучшее понимание того, что на самом деле происходит. Но в обоих случаях с проводом выполняется одно и то же.
Поскольку устройство не может игнорировать запросы ARP, мне нравится использовать инструмент под названием arp-scan. Он доступен в большинстве репозиториев.
Когда вы запускаете команду с --localnet Включите его, чтобы получить обзор всей вашей внутренней сети.
sudo arp-scan --localnet
Предоставляет мне список всех IP- и MAC-адресов в моей сети. Также можно указать диапазон сети для сканирования.
sudo arp-scan 172.16.128.0/25
Если у вас настроено несколько сетевых интерфейсов, вы можете указать тот, который хотите использовать с коммутатором. -I.
sudo arp-scan -I eth0 172.16.128.0/25
Более подробную информацию о возможных переключателях можно найти на сайте https://linux.die.net/man/1/arp-scan или запустив man arp-scan.
Я не знаю, какую версию nmap вы используете в Red Hat 6.5, но для последних выпусков правильным (и более быстрым) способом, я думаю, было бы:
nmap -sn -n 172.16.128.0/25
В нем будут перечислены все хосты в вашей сети (так что вы можете использовать любой другой IP-адрес из этой подсети, если он должен быть доступен).
Отредактируйте и обратите внимание: Вы упомянули подсеть 255.255.255.128, но затем вы показываете вывод как сканирование 254 хостов. Если я чего-то не упускаю, это должна быть маска / 25 и 126 хостов. Если вы хотите сканировать / 24, измените приведенную выше команду, чтобы запросить все 254 хоста.
Из книги nmap, -sP прекращено и заменено -sn:
-sn (Без сканирования портов)
Эта опция указывает Nmap не выполнять сканирование портов после обнаружения хоста, а распечатывать только те доступные хосты, которые ответили на зонды обнаружения хоста. Это часто известно как «сканирование ping», но вы также можете запросить запуск сценариев traceroute и NSE. По умолчанию это на один шаг более навязчиво, чем сканирование списка, и часто может использоваться для тех же целей. Это позволяет вести легкую разведку сети целей, не привлекая особого внимания. Знание, сколько хостов работает, более ценно для злоумышленников, чем список, полученный при сканировании списка каждого IP-адреса и имени хоста.
Системные администраторы также часто считают эту возможность полезной. Его можно легко использовать для подсчета доступных машин в сети или мониторинга доступности сервера. Это часто называют проверкой связи, и она более надежна, чем проверка связи широковещательного адреса, поскольку многие хосты не отвечают на широковещательные запросы.
Обнаружение хоста по умолчанию, выполняемое с помощью -sn, по умолчанию состоит из эхо-запроса ICMP, TCP SYN для порта 443, TCP ACK для порта 80 и запроса отметки времени ICMP по умолчанию. Когда выполняется непривилегированным пользователем, только пакеты SYN отправляются (с использованием вызова подключения) на порты 80 и 443 на цели. Когда привилегированный пользователь пытается сканировать цели в локальной сети Ethernet, используются запросы ARP, если не указан параметр --send-ip. Опцию -sn можно комбинировать с любыми типами проб обнаружения (опции -P *, кроме -Pn) для большей гибкости. Если используются какие-либо из этих параметров типа зонда и номера порта, зонды по умолчанию отменяются. Если между исходным хостом, на котором запущен Nmap, и целевой сетью установлены строгие брандмауэры, рекомендуется использовать эти расширенные методы. В противном случае хосты могут быть пропущены, когда брандмауэр отбрасывает зонды или их ответы.
В предыдущих выпусках Nmap -sn назывался -sP.
В -n состоит в том, чтобы избежать разрешения DNS клиентов (ускоряет сканирование):
-n (без разрешения DNS)
Указывает Nmap никогда не выполнять обратное разрешение DNS на обнаруженных активных IP-адресах. Поскольку DNS может быть медленным даже со встроенным параллельным преобразователем заглушек Nmap, эта опция может сократить время сканирования.
Вы можете использовать другие комбинации, чтобы углубить сканирование или услуги, но этого должно хватить для того, что вы ищете, если только хосты не маскируются или не удаляют все.
Часть 1 - fping
Этот инструмент проверяет все в указанном сетевом диапазоне и показывает те, которые отвечают через ICMP.
root@thionite:~# fping -a -g 10.28.1.0/24
10.28.1.1
10.28.1.2
10.28.1.3
10.28.1.4
10.28.1.5
10.28.1.12.....
Часть 2 -- арп
Поскольку fping общается со всем в локальной сети, это приведет к добавлению записи в таблицу ARP системы. Прочтите это в течение нескольких минут, потому что таблица arp сбрасывает старые записи.
root@thionite:~# arp -a | grep -v incomplete
? (10.28.1.1) at 00:0d:b9:35:29:c4 [ether] on eth0
? (10.28.1.2) at 68:05:ca:10:53:5f [ether] on eth0
? (10.28.1.3) at d2:f1:6e:54:05:22 [ether] on eth0
? (10.28.1.4) at 00:1a:4d:26:85:ee [ether] on eth0
? (10.28.1.5) at 6e:a6:e5:78:da:ca [ether] on eth0
? (10.28.1.12) at 3c:4a:92:76:85:d8 [ether] on eth0
Также обратите внимание, что таблица ARP имеет максимальный размер, и ядро удалит старые и редко используемые записи.
Сложите все вместе с
fping -a -g 10.28.1.0/24 && arp -a | grep -v incomplete > arp.txt
затем просмотрите arp.txt на досуге.
Не думайте, что IPv4 - ваш единственный вариант. Многие современные операционные системы отлично справляются с IPv6, даже если ваш интернет-провайдер не предоставляет возможность подключения V6.
Могут быть даже устройства, которые доступны только по IPv6 или даже по другим протоколам.
Есть множество удобных адресов многоадресной рассылки, задокументированных в https://en.wikipedia.org/wiki/Multicast_address#IPv6 Но для вас интереснее ff02 :: 1
root@thionite:~# ping6 -I eth0 ff02::1
PING ff02::1(ff02::1) from fe80::4261:86ff:fec4:cbaa%eth0 eth0: 56 data bytes
64 bytes from fe80::4261:86ff:fec4:cbaa%eth0: icmp_seq=1 ttl=64 time=0.047 ms
64 bytes from fe80::21a:4dff:fe26:85ee%eth0: icmp_seq=1 ttl=64 time=0.215 ms (DUP!)
64 bytes from fe80::6a05:caff:fe10:535f%eth0: icmp_seq=1 ttl=64 time=0.233 ms (DUP!)
64 bytes from fe80::226:55ff:feda:299c%eth0: icmp_seq=1 ttl=64 time=0.334 ms (DUP!)
64 bytes from fe80::20d:b9ff:fe35:29c4%eth0: icmp_seq=1 ttl=64 time=0.501 ms (DUP!)
64 bytes from fe80::21e:c2ff:fe13:36bf%eth0: icmp_seq=1 ttl=64 time=0.512 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:85d8%eth0: icmp_seq=1 ttl=1 time=0.518 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:8506%eth0: icmp_seq=1 ttl=1 time=0.757 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:e550%eth0: icmp_seq=1 ttl=1 time=0.772 ms (DUP!)
64 bytes from fe80::60cc:69ff:fe4f:7db0%eth0: icmp_seq=1 ttl=64 time=0.992 ms (DUP!)
64 bytes from fe80::90e4:77ff:fe32:3232%eth0: icmp_seq=1 ttl=64 time=1.00 ms (DUP!)
64 bytes from fe80::90e4:77ff:fe30:3030%eth0: icmp_seq=1 ttl=64 time=1.24 ms (DUP!)
64 bytes from fe80::90e4:77ff:fe31:3131%eth0: icmp_seq=1 ttl=64 time=1.34 ms (DUP!)
64 bytes from fe80::6ca6:e5ff:fe78:daca%eth0: icmp_seq=1 ttl=64 time=2.35 ms (DUP!)
64 bytes from fe80::b639:d6ff:feab:1000%eth0: icmp_seq=1 ttl=64 time=7.04 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:85d8%eth0: icmp_seq=1 ttl=1 time=8.02 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:8506%eth0: icmp_seq=1 ttl=1 time=8.03 ms (DUP!)
64 bytes from fe80::3e4a:92ff:fe76:e550%eth0: icmp_seq=1 ttl=1 time=8.06 ms (DUP!)
64 bytes from fe80::212:12ff:fef7:8044%eth0: icmp_seq=1 ttl=64 time=8.24 ms (DUP!)
64 bytes from fe80::8edc:d4ff:fef2:67e0%eth0: icmp_seq=1 ttl=64 time=18.3 ms (DUP!)
64 bytes from fe80::21e:c2ff:fea9:6d71%eth0: icmp_seq=1 ttl=64 time=295 ms (DUP!)
...repeats
Плохой ответ - пинговать широковещательный адрес с помощью
root@thionite:~# ping -b 10.28.255.255
WARNING: pinging broadcast address
PING 10.28.255.255 (10.28.255.255) 56(84) bytes of data.
64 bytes from 10.28.2.7: icmp_seq=1 ttl=64 time=0.220 ms
64 bytes from 10.28.3.12: icmp_seq=1 ttl=255 time=0.594 ms (DUP!)
64 bytes from 10.28.9.4: icmp_seq=1 ttl=64 time=1.03 ms (DUP!)
64 bytes from 10.28.1.151: icmp_seq=1 ttl=255 time=1.04 ms (DUP!)
64 bytes from 10.28.3.13: icmp_seq=1 ttl=255 time=2.22 ms (DUP!)
64 bytes from 10.28.3.11: icmp_seq=1 ttl=255 time=2.43 ms (DUP!)
В этой сети ~ 50 IP-адресов с сетевой маской / 16, и только семь ответили. Так что это не лучшее решение.
В дополнение к ответу MadHatter существует инструмент, выполняющий поиск arp без попытки сначала отправить сетевой пакет: арпинг.
Кажется, есть две реализации:
Для вашей цели я бы просто взял пакет из вашего дистрибутива Linux, поскольку различия, вероятно, только в деталях.
Когда по Земле бродили динозавры, протонерды использовали arpwatch
arpwatch - это компьютерный программный инструмент для мониторинга трафика протокола разрешения адресов в компьютерной сети. [1] Он генерирует журнал наблюдаемого связывания IP-адресов с MAC-адресами вместе с отметкой времени, когда соединение появилось в сети. Он также имеет возможность отправить электронное письмо администратору при изменении или добавлении пары.
Войдите в свой коммутатор (-ы) и выдайте show mac-address или аналогичные команды (в зависимости от марки и модели). Это даст вам все MAC-адреса активных устройств (кроме самого коммутатора). Если какой-либо из этих MAC-адресов не встречается среди MAC-адресов, найденных с помощью любого из ping или других методов в других ответах, вы можете захотеть дополнительно изучить, что это за устройство. Возможно, это не имеет значения, потому что он даже не говорит по IP или принадлежит к другой VLAN, но, по крайней мере, вы можете получить представление о том, точны ли другие ваши зонды.