Jak korzystać z Linuksa, aby znaleźć nieużywane adresy IP w mojej sieci?

Mam dostęp do dwóch komputerów (A i B) w sieci. Oba mają statyczny adres IP z maską podsieci 255.255.255.128 ( sprawdziłem, że serwer DHCP nie jest używany). Chcę skonfigurować wiele adresów IP na tym samym komputerze, a zatem chcę wiedzieć, jakie wszystkie adresy IP są już używane w podsieci.

Z wcześniejszego pytania wypróbowałem nmap -sP -PR 172.16.128.*polecenie, ale jestem sceptyczny co do jego wyniku, ponieważ to samo polecenie daje różne wyniki na moich dwóch komputerach (A i B). A, na pokazach rezultacie listy adresów IP, które są 8 (podobno) już używany, łącznie z A i B .

Nmap done: 256 IP addresses (8 hosts up) scanned in 1.23 seconds

Ale na B wynik jest inny, tj.

Nmap done: 256 IP addresses (0 hosts up) scanned in 0.00 seconds

Wynik na B nie pokazuje nawet własnego adresu IP, a także adresu IP A!

Co dokładnie robię tutaj źle? Czy w Red Hat Linux (RHEL) istnieje jakiś niezawodny sposób na wykrycie wszystkich adresów IP używanych w podsieci, której częścią jest mój komputer?

RHEL: 6.5
Nmap version: 5.51

Każde dobrze wychowane urządzenie w sieci Ethernet LAN może zignorować prawie każdy ruch, więc PING, skanowanie portów i tym podobne są niewiarygodne. Urządzenia nie mogą jednak ignorować żądań ARP , afaik. Biorąc pod uwagę, że określasz, że skanujesz sieć lokalną, znajduję najmniej delikatną metodę robienia tego, co chcesz, to próby połączenia się ze zdalnym adresem, a następnie zajrzenia do mojej pamięci podręcznej ARP.

Oto proste, niefiltrujące urządzenie (tj. Takie, które nie jest skonfigurowane do ignorowania niektórych klas ruchu 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

Oto urządzenie filtrujące (skonfigurowane z jednym wierszem iptablesdo ignorowania całego ruchu):

[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

Oto urządzenie, które właśnie działa; zauważ brak adresu 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

Ta metoda nie jest niezawodna - z jednej strony brakuje urządzeń, które są wyłączone - ale jest to najmniej przerażająca metoda, jaką kiedykolwiek próbowałem.

Edycja : Eric Duminil, tak, działa tylko w sieci lokalnej; patrz akapit pierwszy.

Vishal, metody są funkcjonalnie identyczne. Zwróć uwagę na tekst cytowany w odpowiedzi Leo na temat nmap:

Gdy uprzywilejowany użytkownik próbuje skanować obiekty docelowe w lokalnej sieci Ethernet, żądania ARP są używane, chyba że --send-ipokreślono inaczej .

Jego metoda wymaga mniej pisania. Moje może być wykonane bez przywilejów i może dać ci lepsze zrozumienie tego, co się właściwie dzieje. Ale w obu przypadkach to samo dzieje się na drucie.

Ponieważ urządzenie nie może ignorować żądań ARP, lubię używać narzędzia o nazwie arp-scan. Jest dostępny w większości repozytoriów.

Po uruchomieniu polecenia za pomocą --localnetprzełącznika uzyskasz przegląd całej sieci wewnętrznej.

sudo arp-scan --localnet

Daje mi listę wszystkich adresów IP i MAC w mojej sieci. Możliwe jest również określenie zakresu sieci do skanowania.

sudo arp-scan 172.16.128.0/25

Jeśli masz skonfigurowanych wiele interfejsów sieciowych, możesz określić ten, którego chcesz używać z przełącznikiem -I.

sudo arp-scan -I eth0 172.16.128.0/25

Więcej informacji na temat możliwych przełączników można znaleźć na stronie https://linux.die.net/man/1/arp-scan lub przez uruchomienie man arp-scan.

Nie wiem, którą wersję nmap używasz w swoim Red Hat 6.5, ale dla ostatnich wydań poprawny (i szybszy) sposób, jak sądzę, byłby to:

nmap -sn -n 172.16.128.0/25

Spowoduje to wyświetlenie listy wszystkich hostów w Twojej sieci (więc możesz użyć dowolnego innego adresu IP z tej podsieci, ponieważ powinna być dostępna).

Edytuj i zanotuj: Podsieć, o której wspominasz, to 255.255.255.128, ale następnie wyświetlasz wynik jako skanowanie 254 hostów. Chyba że coś mi brakuje, powinna to być maska ​​/ 25 i 126 hostów dostępnych. Jeśli chcesz przeskanować a / 24, zmień powyższe polecenie, aby wysłać zapytanie do wszystkich 254 hostów.

Z książki nmap -sPzostał wycofany i zastąpiony przez -sn:

-sn (bez skanowania portów)

Ta opcja mówi Nmapowi, aby nie skanował portów po wykryciu hosta i wydrukował tylko dostępne hosty, które odpowiedziały na sondy wykrywające hosta. Jest to często nazywane „skanowaniem ping”, ale można również zażądać uruchomienia skryptów hosta traceroute i NSE. Jest to domyślnie o jeden krok bardziej uciążliwe niż skanowanie listy i często można go używać do tych samych celów. Umożliwia lekki rozpoznanie sieci docelowej bez przyciągania dużej uwagi. Wiedza o liczbie hostów jest dla atakujących bardziej cenna niż lista dostarczona przez skanowanie listy każdego adresu IP i nazwy hosta.

Administratorzy systemów często uważają tę opcję za wartościową. Można go łatwo wykorzystać do zliczania dostępnych komputerów w sieci lub monitorowania dostępności serwera. Jest to często nazywane przeglądaniem pingów i jest bardziej niezawodne niż pingowanie adresu rozgłoszeniowego, ponieważ wiele hostów nie odpowiada na zapytania rozgłoszeniowe.

Domyślne wykrywanie hosta za pomocą opcji -sn składa się z żądania echa ICMP, TCP SYN do portu 443, TCP ACK do portu 80 i domyślnie żądania znacznika czasu ICMP. W przypadku wykonania przez nieuprzywilejowanego użytkownika tylko pakiety SYN są wysyłane (za pomocą wywołania połączenia) na porty 80 i 443 w systemie docelowym. Gdy uprzywilejowany użytkownik próbuje skanować cele w lokalnej sieci Ethernet, żądania ARP są używane, chyba że podano --send-ip. Opcja -sn może być łączona z dowolnym typem sondy wykrywającej (opcje -P *, z wyłączeniem -Pn) dla większej elastyczności. Jeśli zostanie użyta dowolna z tych opcji typu sondy i numeru portu, domyślne sondy zostaną zastąpione. W przypadku istnienia ścisłych zapór ogniowych między hostem źródłowym z uruchomionym Nmap a siecią docelową, zalecane jest użycie tych zaawansowanych technik.

W poprzednich wersjach Nmap -sn było znane jako -sP.

Ma -nto na celu uniknięcie rozpoznawania nazw DNS klientów (przyspiesza skanowanie):

-n (brak rozdzielczości DNS)

Informuje Nmap, aby nigdy nie odwracał rozdzielczości DNS dla aktywnych adresów IP, które znajdzie. Ponieważ DNS może być powolny nawet z wbudowanym równoległym mechanizmem rozpoznawania kodów pośredniczących Nmapa, ta opcja może skrócić czas skanowania.

Możesz użyć innych kombinacji, aby pogłębić skanowanie lub usługi, ale to powinno wystarczyć do tego, czego szukasz, chyba że hosty same się maskują lub upuszczają wszystko.

Źródło: https://nmap.org/book/man-host-discovery.html

Część 1 - fping

To narzędzie pinguje wszystko w określonym zakresie sieci i pokazuje te, które odpowiadają przez 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.....

Część 2 - arp

Ponieważ fping rozmawiał ze wszystkim w sieci LAN, spowodowałoby to dodanie wpisu do tablicy ARP systemu. Przeczytaj to w ciągu kilku minut, ponieważ tabela arp opróżnia stare wpisy.

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

Zauważ też, że tabela ARP ma maksymalny rozmiar, a jądro będzie wyświetlać stare i mało używane wpisy.

Połącz to wszystko z

 fping -a -g 10.28.1.0/24 && arp -a | grep -v incomplete > arp.txt

następnie w wolnym czasie przejrzyj plik arp.txt.

IPv6

Nie zakładaj, że IPv4 jest twoją jedyną opcją. Wiele nowoczesnych systemów operacyjnych dobrze radzi sobie z IPv6, nawet jeśli twój dostawca usług internetowych nie zapewnia łączności V6.

Mogą nawet istnieć urządzenia, które są osiągalne tylko przez IPv6 lub nawet inne protokoły.

Istnieje kilka przydatnych adresów multiemisji udokumentowanych w https://en.wikipedia.org/wiki/Multicast_address#IPv6 Ale interesujący jest dla ciebie 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

Złą odpowiedzią jest pingowanie adresu rozgłoszeniowego

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!)

W tej sieci jest ~ 50 adresów IP z maską sieciową / 16 i tylko siedem odpowiedziało. To nie jest dobre rozwiązanie.

Oprócz odpowiedzi MadHattera istnieje narzędzie, które wyszukuje arp bez próby wysłania najpierw pakietu sieciowego: arping .

Wydaje się, że istnieją dwie implementacje:

• arping (wersja Thomas Habets) .
• arping (wersja iputils)

Dla twojego celu po prostu wziąłbym pakiet z twojej dystrybucji linuksa, ponieważ różnice są prawdopodobnie tylko w szczegółach.

Kiedy dinozaury wędrowały po ziemi, proto- nerdowie używali arpwatch

arpwatch to oprogramowanie komputerowe do monitorowania ruchu protokołu rozpoznawania adresów w sieci komputerowej. [1] Generuje dziennik zaobserwowanego parowania adresów IP z adresami MAC wraz ze znacznikiem czasu, gdy parowanie pojawiło się w sieci. Ma również opcję wysłania wiadomości e-mail do administratora, gdy powiązanie zmieni się lub zostanie dodane.

Strona podręcznika użytkownika arpwatch

Zaloguj się do przełącznika (-ów) i wydawaj show mac-address lub podobne polecenia (w zależności od marki i modelu). To da ci wszystkie adresy MAC aktywnych urządzeń (oprócz samego przełącznika). Jeśli któryś z tych adresów MAC nie występuje wśród adresów MAC znalezionych za pomocą polecenia ping lub innych metod w innych odpowiedziach, możesz chcieć dokładniej zbadać, jakie to urządzenie. Może to nie ma znaczenia, ponieważ nawet nie mówi IP lub należy do innej sieci VLAN, ale przynajmniej możesz uzyskać przegląd, czy twoje inne sondy są dokładne.