Controllerless Networks

last person joined: yesterday 

Aruba Instant Wi-Fi: Meet the controllerless Wi-Fi solution that's easy to set-up, is loaded with security and smarts, and won't break your budget.
Expand all | Collapse all

IAP ARP Spoofing/ ARP Poisoning Question

  • 1.  IAP ARP Spoofing/ ARP Poisoning Question

    Posted Jan 31, 2017 07:31 AM

    Hi all,
    Regarding this topic i have some questions that i hope some guru can help me.
    I have enabled in my test IAP the following:

    attack
    drop-bad-arp-enable
    fix-dhcp-enable
    poison-check-enable

    From what i have read this should stop arp poisoning in a SSID.
    The problem is that i have done some tests (using arpspoof in kali linux) and although i cant spoof a connected client in a SSID i can spoof the Default-gateway to the other clients.

    Example: (clients on same SSID, Default GW a router)

             DefaultGW
                     |
    client X --IAP;----- Client Y
                      |
                Client Z

    Client X cant "tell" client Y or the gateway via arp spoof that client z ip is at his mac.
    BUT Client X can tell client Y and Z that the ip of the gateway is at his mac , so he can receive packets from client Y,Z (half mitd ???)

    So the big question is if this is normal behaviour and i should just check somewhere the the snmp traps generated by "poison-check-enable" or there is another way to do this or a bug ??

    ps - "I tested and deny inter user traffic stops this, but it also stops all traffic :) "
     
    Regards,
    Vss



  • 2.  RE: IAP ARP Spoofing/ ARP Poisoning Question

    Posted Mar 03, 2017 08:10 AM

    I assume that you are not seeing anything in "show attack stats"?  Do you see the ARP packet counter increasing?

     

    # show attack stats
    attack counters
    --------------------------------------
    Counter Value
    ------- -------
    arp packet counter 152
    drop bad arp packet counter 0
    dhcp response packet counter 0
    fixed bad dhcp packet counter 0
    send arp attack alert counter 0
    send dhcp attack alert counter 0
    arp poison check counter 0
    garp send check counter 0

     

    To be honest, whether you are spoofing the GW or another client, then (IMHO) the effect for a MITM attack should be the same.

     

    I have tested this in the lab and I see something that strikes me as strange:

     

    # show arp
    IP address HW type Flags HW address Mask Device
    10.10.51.5 0x1 0x2 24:a0:74:xx:xx:xx * br0
    10.10.51.1 0x1 0x2 24:a0:74:xx:xx:xx * br0

     

    I have obfuscated the last bytes of the test PC's MAC@, but as you can see the client IP is 10.10.51.5 and is spoofing the def. GW's address (10.10.51.1 = upstream router) and the IAP has updated its ARP table with the test PC's MAC@.  On another test PC connected to the same WiFi network and subnet, the def. GW is also seen as 24:a0:74:xx:xx:xx, so by definition, the ARP poisoning can be considered to have worked.

     

    As the test PC is a WiFi client, I would have thought that should be enough to trigger alarm bells in the IAP i.e. IAP should think "how is my def. GW coming from a WiFi client?"   A pkt debug on the IAP confirms this:

     

    Received packet from bond0 (timestamp (117-2-3 12:52:35:455531))
    [asap_firewall_forward(5457):firewall entry] len 60, vlan 0, egress CP, ingress bond0:
    #mac: etype 0806 smac 24:a0:74:xx:xx:xx dmac ff:ff:ff:ff:ff:ff
    #arp: opcode response(2), sip 10.10.51.1, tip 0.0.0.0, smac 24:a0:74:xx:xx:xx, tmac ff:ff:ff:ff:ff:ff
    [asap_firewall_forward(5633):vlan decision] len 60, vlan 1, egress CP, ingress bond0:
    [asap_firewall_forward(6142):looking up pkt ingress/src bridge entry 24:a0:74:xx:xx:xx] len 60, vlan 1, egress CP, ingress bond0:
    [asap_firewall_forward(6182):Found ingress/src bridge entry 24:a0:74:xx:xx:xx rechable via bond0] len 60, vlan 1, egress CP, ingress bond0:
    [asap_firewall_forward(6473):bridge section, looking for dst bridge entry ff:ff:ff:ff:ff:ff] len 60, vlan 1, egress CP, ingress bond0:
    [asap_firewall_forward(6569):Unable to find dst bridge entry ff:ff:ff:ff:ff:ff, flood to VLAN 1] len 60, vlan 1, egress vlan 1, ingress bond0:
    [asap_firewall_forward(6604):session section] len 60, vlan 1, egress vlan 1, ingress bond0:
    [asap_firewall_forward(6851):fastpath session returned 0 opcode 0] len 60, vlan 1, egress vlan 1, ingress bond0:
    [asap_firewall_forward(7421):route section] len 60, vlan 1, egress vlan 1, ingress bond0:
    [asap_firewall_forward(7471):cp route section] len 60, vlan 1, egress vlan 1, ingress bond0:
    [asap_firewall_forward(7789):forward section] len 60, vlan 1, egress vlan 1, ingress bond0:
    [asap_firewall_flood(9215):flooding] len 60, vlan 1, egress vlan 1, ingress bond0:
    [asap_firewall_flood(9419):checking dev2 bond0] len 60, vlan 1, egress vlan 1, ingress bond0:
    [asap_firewall_flood(9988):stack section protocol=0x806, type=1] len 60, vlan 1, egress vlan 1, ingress bond0:
    [asap_firewall_send_up_stack(3697):going to stack protocol:0x806 type:1] len 46, vlan 1, egress vlan 1, ingress br0:

     

    This needs some further testing, because here the test PC's and IAP are all using the same subnet (def. VLAN 1).  

     

    Do you have a TAC case open for this?

     

    David



  • 3.  RE: IAP ARP Spoofing/ ARP Poisoning Question

    Posted Jul 24, 2017 03:25 AM

    Hello,

    Can you let me know if this is resolved and what the resolution is please?

    I am thinking if recommending enabling:

    • Drop bad ARP
    • Fix malformed DHCP
    • ARP poison check

    on our Aruba instant network, but your article has raise some concerns.

    Thanks.



  • 4.  RE: IAP ARP Spoofing/ ARP Poisoning Question

    Posted Jul 24, 2017 05:33 AM

    Hi, There is no problem in enabling them. Just know that the "anti-spoof" mechanism will only work if the attacker spoofs ip´s of connected clients to the IAP, so in my view it only "half" works.

     

    Example : Clients: A,B,C

    B spoofs A to C -> The IAP will drop this spoof packets

    B spoofs A to default-GW -> The IAP will drop this spoof packets

    B spoofs Default-GW to A -> this will work and A will send packets that should go to the DG to B (so spoof was sucessfull )

     

    So in this scenario the attacker would be able to receive packets from A to the GW but not sent to A from the GW (half spoof???).

     

    Workaround -> If you enable "deny-inter-user-bridging" spoof wont work (i have done this in our guest network)

     

    PS - I have requested full anti-spoof as a feature (it works ok in the controller based solution) so i guess sometime in the future IAP will able to do it.



  • 5.  RE: IAP ARP Spoofing/ ARP Poisoning Question

    Posted Nov 26, 2019 09:03 AM

    Hi guys,

     

    I encounter the same problem.

    Regularly the IP address is not distributed to the final user.

    On the master IAP, we see the DHCP give IP address to :

    dmac ff:ff:ff:ff:ff:ff

     

    with same messages :

    [asap_firewall_forward(6665):bridge section, looking for dst bridge entry ff:ff:ff:ff:ff:ff] len 361, vlan ---, egress CP, ingress gre0:
    [asap_firewall_forward(6777):Unable to find dst bridge entry ff:ff:ff:ff:ff:ff, flood to VLAN ---] len 361, vlan ---, egress vlan , ingress gre0:

     

    (PS :  I have volontary hidden the vlan number)

     

    The only solution we found is to reboot the Master IAP.

     

    I see on the Master IAP the different counters incrementing:

    #show attack stats
    attack counters
    --------------------------------------
    Counter Value
    ------- -------
    arp packet counter 101368079
    drop bad arp packet counter 494
    dhcp response packet counter 17642
    fixed bad dhcp packet counter 0
    send arp attack alert counter 0
    send dhcp attack alert counter 0
    arp poison check counter 0
    garp send check counter 0

     

     

    With that default configuration:

    Capture.JPG

    I am wondering if it could be good to disable "Drop bad ARP" and maybe "ARP poison check" too.

    What can you advice me please?

     

    Thanks for your answers.



  • 6.  RE: IAP ARP Spoofing/ ARP Poisoning Question

    Posted Nov 29, 2019 05:05 AM

    Hello bdealaville,

    its not the same problem, what i said is that the anti-spoofing on the IAPs was (is???) not working in same scenarios (like spoofing the gateway).

    From what you wrote you have some strange dhcp problem that increments the counters.

    I would check the dhcp lease timers and if someone doesnt have static ips or something like that.