Controllerless Networks

Reply
Occasional Contributor II

IAP ARP Spoofing/ ARP Poisoning Question

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

Aruba Employee

Re: IAP ARP Spoofing/ ARP Poisoning Question

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

New Contributor

Re: IAP ARP Spoofing/ ARP Poisoning Question

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.

Occasional Contributor II

Re: IAP ARP Spoofing/ ARP Poisoning Question

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.

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: