nmap rawパケット権限が機能しません(rootユーザーでも「操作は許可されていません」)

nmap rawパケット権限が機能しません(rootユーザーでも「操作は許可されていません」)

nmapを使用しているときにrootとして実行しても、「操作が許可されていません」というメッセージが表示されるのはなぜですか?

$ 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これは(上記)と同じ物理ネットワークカードを使用しているため重要です。
  • vbox1:IPがあります192.16.3.1。このサブネットのアドレスからnmapを実行すると、期待どおりに機能します。 ->動作します。

これは物理ワークステーションであり、ここに追加の制限を課すことができる仮想化またはコンテナでは実行されません。

足:

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

-sTもちろん、デフォルトのTCP SYNスキャン()の代わりに低権限のTCP接続スキャン()を使用してこの問題を解決できますが、-sSこれがなぜこれが起こるのか説明しません。

イーサネットブリッジに関する既知の制限事項や考慮すべきその他の問題はありますか?

編集者(2017-01-14):

  • クリーンな仮想マシン(i7物理マシンに2つのvCPU)から複製しようとしました。ブリッジを設置した後も再現できません。
  • すべてのイーサネットオフロードオプションを無効に(ethtoolを使用)しても役に立ちませんでした。
  • ソースでコンパイルされた最新のNmap 7.40を実行しても役に立ちませんでした。
  • カーネルの問題だと思いますか? http://seclists.org/nmap-dev/2016/q4/131。同じバージョンにもかかわらず、なぜ仮想マシンで再現できないのかわかりません。ハードウェア/ドライバによって異なる場合があります。
  • 検査はまだ実行中です。これはスキャンの開始にのみ影響するようです。結果が失われる可能性があるため、まだ心配です。
    • これは、最初の10件以降のすべてのメッセージが省略されたことを意味します。ただし、-d2プロンプトを繰り返した後でも、まだ10個しか表示されません。 (ただし、それ自体がエラーかもしれません。)
    • リストされている特定のポート(例:-p 2099上記の例)を繰り返しスキャンすると、ポートは正常にスキャンされるため、一部のポートはブロックされません。
  • 実行すると--max-parallelism=1、この状態の発生を大幅に減らすことができます。
    • 50に設定してもあまり役に立たないようです。
    • 30 に設定すると、1 つのホストでは半分程度動作するように見えますが、最終的にはサブネットスキャンが失敗し始めます。
    • 値を徐々に下げると、サブネットをスキャンしてエラーを観察するのに必要な時間が長くなります。しかし、1を使っても結局は失敗します。
    • これはnmap自体の並列性の問題ではないようです。parallel複数の同時nmapスキャンを再利用して実行すると、--max-parallelism=1問題が発生する可能性が高くなります。

ホスト情報:Ubuntu 16.10、カーネル4.8.0-34-一般#36-Ubuntu。 Intel(R)Core(TM)i7-2600S、32GB RAM。

ベストアンサー1

iptable_natこれは現在、4.8.x Linuxカーネル(< 4.8.16)のモジュールの問題のようです。https://bugzilla.redhat.com/show_bug.cgi?id=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。 (通常と同様に、他のアップデートが出るとさらにアップグレードされると確信しています。)これは問題が解決しただけでなく、スキャンパフォーマンスも大幅に向上しました。

おすすめ記事