nmap privilégios de pacotes brutos não funcionam (“operação não permitida”, mesmo como root)

Question

Por que estou recebendo a "operação não permitida" com o nmap - mesmo quando executado como 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.

Este não é um problema do iptables - minha cadeia de saída está aberta:

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

Agora, tenho algumas interfaces diferentes aqui, com VLANs e uma ponte. Isso está funcionando em algumas interfaces e não em outras:

• br0 : Ponte acima de eth0 (sem tag) e vbox0 (usando o VirtualBox), tem% IP192.168.1.1 - > Não está funcionando (acima).
  • Para chutes, remover vbox0 da ponte não corrige nada.
• eth0.2 : VLAN 2, com IP 192.168.2.1 . A execução do nmap em endereços nesta sub-rede funciona como esperado - > trabalhando.
  • Isso parece significativo, já que isso resulta no mesmo NIC físico que eth0 (acima).
• vbox1 : tem o IP 192.16.3.1 . A execução do nmap em endereços nesta sub-rede funciona como esperado - > trabalhando.

Esta é uma estação de trabalho física - não sendo operada sob qualquer virtualização ou contêiner que possa impor restrições adicionais aqui.

Bridge:

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

Concedido, posso contornar isso usando uma varredura de conexão TCP menos privilegiada ( -sT ) em vez da varredura TCP SYN padrão ( -sS ) - mas isso não explica porque isso está acontecendo. / p>

Existe alguma limitação conhecida aqui com a ponte Ethernet, ou qualquer outra coisa que eu deveria estar olhando?

Edições (2017-01-14):

• Tentando replicar em uma VM limpa (2 vCPU em um sistema físico i7). Mesmo depois de configurar a ponte, incapaz de reproduzir.
• Desativar todas as opções de transferência de Ethernet (usando ethtool) não ajuda em nada.
• A execução do último Nmap 7.40 compilado a partir da fonte não ajuda em nada.
• Esta parece ser uma questão do kernel? link . Não tenho certeza porque não consegui reproduzir na VM, apesar das mesmas versões. Possivelmente também hardware / driver-specific ...
  • Isso parece ser um problema com o módulo iptable_nat nos kernels 4.8.x atuais: link
• A verificação ainda é executada. Isso só parece afetar o início da verificação - para o qual continuo preocupado, pois posso estar perdendo resultados.
  • Diz que todas as mensagens após os primeiros 10 foram omitidas. No entanto, mesmo depois de repetir com -d2 , conforme solicitado, ainda vejo apenas 10. (Pode ser um bug em si, no entanto.)
  • Se eu repetir a varredura de uma determinada porta conforme listada (por exemplo, com -p 2099 para o exemplo mostrado acima), ela digitalizará com êxito para essa porta - portanto, não é como se determinadas portas estivessem bloqueadas.
• A execução com --max-parallelism=1 reduz drasticamente a ocorrência.
  • A configuração para 50 não parece ajudar.
  • A configuração para 30 parece funcionar na metade do tempo para um único host - mas ainda assim começa a falhar em uma varredura de sub-rede.
  • Valores progressivamente mais baixos aumentam o tempo gasto em uma varredura de sub-rede para que quaisquer falhas sejam observadas - mas até mesmo o uso de 1 falha eventualmente.
  • Isto não parece ser um problema de paralelismo dentro do próprio nmap. A execução de várias verificações nmap simultâneas com parallel e --max-parallelism=1 aumenta novamente a ocorrência do problema.

Informações do host: Ubuntu 16.10, kernel 4.8.0-34-generic # 36-Ubuntu. Intel (R) Core (TM) i7-2600S, 32 GB de RAM.

    

Answer 1

Isto parece ser um problema com o módulo iptable_nat nos atuais kernels Linux 4.8.x (< 4.8.16), conforme link .

O kernel 4.9 inclui uma correção "real" - mas, como para o Ubuntu, acredito que teremos que esperar o Ubuntu 17.04 (Zesty Zapus) para ver isso oficialmente. (4.9 será incluído, conforme as notas de lançamento ).

Quanto ao Ubuntu 16.10 (Yakkety Yak), parece que um kernel 4.8.16 fixo está pendente de lançamento por link , que inclui as seguintes correções:

Revert "netfilter: nat: convert nat bysrc hash to rhashtable"
Revert "netfilter: move nat hlist_head to nf_conn"

Eu atualizei para este kernel usando link e as instruções em link . (Eu confio que será atualizado como de costume, como atualizações adicionais seguem.) Isso não só resolveu o meu problema, mas resultou em uma melhoria maciça no desempenho da digitalização.