MacNotes1

Category:Sasecurity
back to http://scratchpad.wikia.com/wiki/Sasecurity
TableOfContents
=== problem ===
Last week I installed a high end Linux box between a T1 router and a Mesh AP Gateway node that services over 150 customers with 9 mesh repeater nodes. The mesh network has been running for more then two years. Recently I had been noticing unusual traffic spikes, and high cpu temperatures sporadically showing up in the wiana charts.
 
So, I implemented a bridge on the linux box and run Iptraf on the bridge to monitor all traffic going in and out of the network. I also plan to implement squid on this box as a transparant proxy cache server and filtering mechanism using acl lists.
 
Last night I noticed high traffic to google on two IP sessions with Iptraf. 
* I went to each node in the network running tcpdump to find the computer originating this traffic. 
* I have to do this because the originating IP address is always that of my AP gateway as reported by Iptraf. 
* I found the AP that originated the traffic, and it came form an IP address that I looked up in /var/state/dhcp/dhcpd.leases. 
* The associated mac address is not in my /etc/AutoAccess list. Nor is it in wiana's radius realm, obvioiusly.
* I use mac address authentication.
 
An unauthenticated computer gets an IP address for the AP's dhcp service, but supposedly the AP will not forward packets for this mac address without RaDius authentication. This is not totally true. I am assuming this is a DOS attack, but I do not know how the packets are forwarded by the AP without the associated MAC address not being authenticated.
If anyone can shed some light in this, I think it is important. There was huge bandwidth usage when this activity was present. If this was mac address SpooFing the mac would be an authenticated mac. That is not the case. This is a computer that is circumventing mac address authentication, somehow. The originating port was 80.
 
=== Solution ===
It is not a SpooFed mac. If so it would be in /etc/autoaccess. The 
mac is not in /etc/autoaccess. It shows up in 
/var/state/dhcp/dhcpd.leases: 00:14:A5:1F:79:4F - Unknown - 
Many macs show up in dhcpd.leases because any radio card gets an ip address from an ap when it associates with the ap. 
The authentication is guided by IpTables. This mac was not in IpTables rules. The mac looks like HP laptop macs.
I have 5 CB3s whose macs are authenticated. The macs behind the CB3 will not show up. It is not one of them. They are all on different APs. Although the CB3s will need their own MACs authenticated, the MAC addresses of the PCs behind them will still show up in wiana, as they will be allocated an IP address - the PC shows up in the dhcpd.leases even though it is not authenticated on that MAC address.
It is not a spoofed mac. If so it would be in /etc/autoaccess. The mac is not in /etc/autoaccess. It shows up in /var/state/dhcp/dhcpd.leases: >00:14:A5:1F:79:4F - Unknown - (marshall). Many macs show up in dhcpd.leases because any radio card gets an ip address from an ap when it associates with the ap. The authentication is guided by iptables. This mac was not in iptables rules. The mac looks like HP laptop macs.
 
I have 5 CB3s whose macs are authenticated. The macs behind the CB3 will not show up. It is not one of them. They are all on different APs. While running Iptraf on my network monitor/proxy server before the T1 line it was pounding google. DOS attack? I think the guy - marshall?? - doesn't know what is going on, and he has a virus on his computer that somehow is getting around authentication. Again, this is a 55 and older rv park. They are not sophisticated. 
But, I wonder how it is getting around iptables on the AP? At the linux bridge on the proxy box, I entered a Drop on the mac address, and I haven't seen it since. I'm running the latest release of Locustworld on the via motherboard. I have about 280 users in the realm. One thing I will add to Clark's problem - hopefully to make him feel better:
I have a friend that is very proficient with Linux setup and admin. Before the walled garden feature was available, I had him look at the LocustWorld code and figure out why walled gardens would not work. He found the problem, and we got it added to the code. However, he assured me after looking over the firewall rules (this was on dev76) that there was no way an unauthenticated user could bypass the captive portal.
That makes me think that Clark's issue is more than likely someone that has spoofed an authenticated MAC. If they were smart, they'd have done this using a MAC address logged onto another node. First, go through your nodes and run sigspy (or maxispy if they are Pro). Pipe the output(s) to a file. Then take the file and open it with a spreadsheet program (Excel or something similar). Open it as a fixed width file and then sort by MAC address. You will not need any of the extra data - so it can be trashed. Next, look in Wiana and get the MAC of all of your AP's. If you are using sigspy, you will need this to remove the AP's from the list. If you are using maxispy - you can just list client MAC addresses and skip this step.
At this point, you should have a file of unique MAC addresses. If anything shows up twice, that would be the one(s) I would look at. Once that is found, you can set the compromised account up to authenticate by user/pass/MAC, or better yet, make them a VPN authenticated client. Of course, if the guy is really determined to steal service, he's just going to spoof another MAC. The ideal thing will be to locate him in some manner.
=== Mac MiniMgtTools ref ===
 
Re unknown users authentication I have tried to keep our protocol simple:
We only authenticate users by MAC, after initial log on, to identify them we issue a Username and Password and insist on a identifiable 'ident' so they can make the initial connection and we can spot them in the MeshBoxes current DhCp – Leases file:
 ["SSH"] - SshMeshin and issue: cat /var/state/dhcp/dhcpd.leases
Then add the MAC address to their realm details and scramble the password so only MAC authentication is working and password pair is effectively blocked but their name comes up in traffic stats.
 
If they are hiding behind a router then it is pretty obvious and any MAC addresses we see that are not known we block and await a phone call ?