ネットワーク上の2台のコンピューター(AとB)にアクセスできます。どちらも、サブネットマスクが255.255.255.128の静的IPアドレスを持っています(I チェック済み DHCPサーバーが使用されていなかったことを示します)。同じマシンに複数のIPアドレスを構成したいので、サブネットですでに使用されているすべてのIPアドレスを知りたい。
以前の質問 から、nmap -sP -PR 172.16.128.*
コマンドを試してみましたが、同じコマンドで2台のコンピューター(AとB)で異なる結果が得られるため、その結果には懐疑的です。 Aの結果は、(おそらく)既に使用されている8つのIPアドレスのリストで、AとBのリストを含みます。
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の結果には、AのIPアドレスだけでなく、自身のIPアドレスも表示されていません!
ここで何が間違っているのですか? Red Hat Linux(RHEL)で、自分のコンピューターが属しているサブネットで使用されているすべてのIPアドレスを発見するための絶対的な方法はありますか?
RHEL: 6.5
Nmap version: 5.51
イーサネットLAN上の正常に動作するデバイスは、ほぼすべてのトラフィックを自由に無視できるため、PING、ポートスキャンなどはすべて信頼できません。ただし、デバイスは自由に無視できません ARP要求 、afaik。ローカルネットワークをスキャンしていることを指定すると、リモートアドレスへの接続を試みて、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
の1行で構成され、無視するallトラフィック):
[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
この方法は間違いがないわけではありません-1つには、電源がオフになっているデバイスを見逃すことですが、これは私が試した中で最も恐ろしい方法です。
編集:Eric Duminil、はい、ローカルネットワークでのみ機能します。パラグラフ1を参照してください。
Vishal、方法は機能的に同じです。レオの回答で引用されているnmap
に関するテキストに注意してください。
特権ユーザーがローカルイーサネットネットワーク上のターゲットをスキャンしようとすると、
--send-ip
が指定されていない限り、ARP要求が使用されます。
彼の方法はタイピングを少なくします。鉱山は特権なしで行うことができ、mayは実際に何が起こっているかについての理解を深めます。しかし、どちらの場合も同じことがネットワーク上で行われます。
デバイスは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
を実行してください。
Red Hat 6.5で実行しているnmapのバージョンはわかりませんが、最近のリリースでは、正しい(より高速な)方法であると思います。
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ホストスクリプトの実行をリクエストすることもできます。これはデフォルトでリストスキャンよりも煩わしい1ステップであり、多くの場合同じ目的で使用できます。これにより、あまり注意を引くことなく、ターゲットネットワークの軽い偵察が可能になります。稼働しているホストの数は、すべての単一のIPとホスト名のリストスキャンによって提供されるリストよりも攻撃者にとって価値があります。
システム管理者は、多くの場合、このオプションも価値があると考えています。ネットワーク上で使用可能なマシンを数えたり、サーバーの可用性を監視するために簡単に使用できます。これはpingスイープと呼ばれることが多く、ブロードキャストクエリに応答しないホストが多いため、ブロードキャストアドレスにpingするよりも信頼性が高くなります。
-snで実行されるデフォルトのホスト検出は、ICMPエコー要求、TCPポート443へのSYN、TCPポート80へのACK、およびICMPタイムスタンプ要求で構成されますデフォルトでは、権限のないユーザーが実行すると、SYNパケットのみが(接続呼び出しを使用して)ターゲットのポート80と443に送信されます。権限のあるユーザーがローカルイーサネットネットワーク上のターゲットをスキャンしようとすると、ARPリクエストが使用されます- -send-ipが指定されました。-snオプションを任意の検出プローブタイプ(-Pnを除く-P *オプション)と組み合わせると、柔軟性が向上します。これらのプローブタイプとポート番号のオプションのいずれかを使用する場合、デフォルトのプローブは上書きされます。Nmapを実行しているソースホストとターゲットネットワークの間に厳格なファイアウォールが設置されている場合は、これらの高度な手法を使用することをお勧めします。そうしないと、ファイアウォールがプローブまたはその反応。
Nmapの以前のリリースでは、-snは-sPと呼ばれていました。
-n
は、クライアントのDNS解決を回避するためのものです(スキャンを高速化します)。
-n(DNS解決なし)
Nmapは、検出したアクティブなIPアドレスに対して逆DNS解決を絶対に行わないように指示します。Nmapの組み込み並列スタブリゾルバーを使用してもDNSが遅くなる可能性があるため、このオプションはスキャン時間を削減できます。
他の組み合わせを使用してスキャンまたはサービスを深めることができますが、ホストが自分自身をマスキングしたり、すべてをドロップしたりしない限り、探しているもので十分です。
パート1-fping
このツールは、指定されたネットワーク範囲内のすべてをpingし、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-arp
FpingはLAN上のすべてのものと通信したため、システムの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が唯一の選択肢であると想定しないでください。 ISPがV6接続を提供していない場合でも、最新のオペレーティングシステムの多くはIPv6を適切に処理します。
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
悪い答えは、ブロードキャストアドレスをpingすることです。
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!)
そのネットワーク上には/ 16のネットマスクを持つ〜50のIPアドレスがあり、7つだけが応答しました。したがって、これは良い解決策ではありません。
MadHatterの回答に加えて、最初にネットワークパケットを送信しようとせずにarpルックアップを行うツールがあります: arping 。
2つの実装があるようです。
あなたの目的のために、私はあなたのLinuxディストリビューションからパッケージを取り出します。違いはおそらく詳細にあるだけだからです。
恐竜が地球を歩き回ったとき、原型オタクが使用した arpwatch
arpwatchは、コンピューターネットワーク上のアドレス解決プロトコルトラフィックを監視するためのコンピューターソフトウェアツールです。[1]ペアリングがネットワークに現れたときのタイムスタンプとともに、IPアドレスとMACアドレスの観察されたペアリングのログを生成します。また、ペアリングが変更または追加されたときに管理者にメールを送信するオプションもあります。
スイッチにログインし、show mac-address
または同様のコマンドを発行します(メーカーとモデルによって異なります)。これにより、アクティブなデバイス(スイッチ自体を除く)のすべてのMACアドレスが提供されます。これらのMACのいずれかが、pingまたは他の回答のその他の方法で検出されたMACの中で発生しない場合は、どのデバイスであるかをさらに調査することができます。それはIPを話さないか別のVLANに属しているのでそれは問題ではないかもしれませんが、少なくとも他のプローブが正確であるかどうかの概要を得ることができます。