web-dev-qa-db-ja.com

nmap rawパケット権限が機能しない（rootであっても「操作は許可されていません」）

Rootとして実行されている場合でも、nmapで「許可されていない操作」が発生するのはなぜですか？

_$ Sudo nmap 192.168.1.2

Starting Nmap 7.12 ( https://nmap.org ) at 2017-01-13 02:12 CST
sendto in send_ip_packet_sd: sendto(5, packet, 44, 0, 192.168.1.2, 16) => Operation not permitted
Offending packet: TCP 192.168.1.1:53769 > 192.168.1.2:2099 S ttl=47 id=47294 iplen=44  seq=2821662280 win=1024 <mss 1460>
...
Omitting future Sendto error messages now that 10 have been shown.  Use -d2 if you really want to see them.
_

これはiptablesの問題ではありません-私のOUTPUTチェーンは広く開かれています：

_$ Sudo iptables -L OUTPUT
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
_

ここに、VLANとブリッジを備えた、いくつかの異なるインターフェースがあります。これは一部のインターフェイスでのみ機能し、他では機能しません。

  • _br0_：_eth0_（タグなし）および_vbox0_（VirtualBoxを使用）をブリッジし、IPを持っています_192.168.1.1_->機能していません（上記）。
    • キックの場合、ブリッジから_vbox0_を削除しても何も修正されません。
  • _eth0.2_：VLAN 2、IP付き_192.168.2.1_。このサブネットのアドレスでnmapを実行すると、期待どおりに機能します->機能します。
    • これは、_eth0_（上記）と同じ物理NICになるため、重要なようです。
  • _vbox1_：IPあり__192.16.3.1_。このサブネットのアドレスでnmapを実行すると、期待どおりに機能します->機能します。

これは物理的なワークステーションです。ここで追加の制限を課す可能性のある仮想化またはコンテナの下で操作されていません。

ブリッジ：

_$ brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0015171970fc       no              eth0
                                                        vbox0
_

確かに、デフォルトのTCP SYNスキャン（_-sT_）ではなく、権限の少ないTCP接続スキャン（_-sS_）を使用することで、これを回避できます-しかし、これはなぜこれが起こっているのかを説明していません。

イーサネットブリッジングに関する既知の制限はありますか、または他に注意すべき点はありますか？

編集（2017-01-14）：

  • クリーンVM（i7物理システム上の2つのvCPU）で複製しようとしています。ブリッジを設置しても再現できません。
  • （ethtoolを使用して）すべてのイーサネットオフロードオプションを無効にしても、効果はありません。
  • ソースからコンパイルされた最新のNmap 7.40を実行しても、役に立ちません。
  • これはカーネルの問題のようです？http://seclists.org/nmap-dev/2016/q4/131 。同じバージョンにもかかわらず、なぜVMで再現できなかったのかわかりません。おそらくハードウェア/ドライバ固有...
  • スキャンはまだ実行されています。これはスキャンの開始に影響を与えるだけのようです-結果が欠落している可能性があるので、私は心配し続けます。
    • 最初の10件以降のすべてのメッセージが省略されていることを示しています。ただし、プロンプトで_-d2_を使用して繰り返した後でも、10しか表示されません（ただし、それ自体がバグである可能性があります）。
    • リストにあるように特定のポートのスキャンを繰り返すと（たとえば、上記の例では_-p 2099_を使用して）、そのポートが正常にスキャンされるため、特定のポートがブロックされているようには見えません。
  • _--max-parallelism=1_で実行すると、発生が大幅に減少します。
    • 50に設定しても効果がないようです。
    • 30に設定すると、単一のホストの約半分の時間で動作するように見えますが、最終的にはサブネットスキャンの失敗が始まります。
    • 値を徐々に小さくすると、障害が観察されるまでサブネットスキャンにかかる時間が長くなりますが、1を使用しても最終的には失敗します。
    • これは、nmap自体の並列処理の問題ではないようです。 parallelおよび_--max-parallelism=1_で複数のnmapスキャンを同時に実行すると、問題の発生が増加します。

ホスト情報：Ubuntu 16.10、カーネル4.8.0-34-generic＃36-Ubuntu。 Intel（R）Core（TM）i7-2600S、32 GB RAM。

linuxubuntunetworkingethernetnmap
3
ziesemer

https://bugzilla.redhat.com/show_bug.cgi?idによると、これは現在の4.8.x Linuxカーネル（<4.8.16）のiptable_natモジュールに問題があるようです。 = 1402695 。

4.9カーネルには「実際の」修正が含まれていますが、Ubuntuについては、Ubuntu 17.04（Zesty Zapus）が公式にこれを確認できるまで待つ必要があると思います。 （4.9は リリースノート のようにそこに含まれます）。

Ubuntu 16.10（Yakkety Yak）に関しては、修正された4.8.16カーネルがリリース保留中のようです https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1654584 、次の修正が含まれています。

「netfilter：nat：nat bysrcハッシュをrhashtableに変換」を元に戻します
「netfilter：nat hlist_headをnf_connに移動」を元に戻します

http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8.16/ と https：//wiki.ubuntu。 com/Kernel/MainlineBuilds 。 （追加の更新が行われると、通常どおりさらにアップグレードされると確信しています。）これにより、問題が解決しただけでなく、スキャンのパフォーマンスが大幅に向上しました。

1
ziesemer