Controllerless Networks

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

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

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.

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.

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:

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.

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.