Re: MAC - IP - MAC
On 6/3/06, Gaby vanhegan [EMAIL PROTECTED] wrote: On 3 Jun 2006, at 17:03, Clint M. Sand wrote: So all I have to do is *TRY* to login as you on another machine and your original legit connection is dropped? Think about this. Only successful logins would update the IP associated with that login. Failed login attempts would do nothing. Sorry, my wording was a little unclear, what I actually meant was a successful login from a second machine would kick the first login off, as the most recent IP would be the one associated with that client. If the first client successfully logged in again, that would kick the second login off. The best I can do against somebody trying to use a stale IP is to check the MAC address that the successful login came from against what it claims to be at the time. Any mis-match and the IP is kicked off. If people want to go to the effort of spoofing a MAC address and finding a stale IP to use, there's little I can do. Being that this is a service intended for the general public, I'm reckoning that 99.9% of users won't even know that a MAC could be spoofed, or know how to do it. I suppose I could take it one step further and get a tcp OS fingerprint of the client at login time, and use that as a further aid to checking that the person that logged in is the person currently using this IP address. Is there any way to protect against this? I think it's good enough to do what you were already planning. In order for someone to get on they'd need to find someone who has left a stale login, find out their IP and find out their MAC. The chance of them being able to do this (without already having been on the network to snoop traffic, in which case they've gotten in anyway) is astronomical: about 16^6 * 2^32. Just make sure to have a system to detect multiple rapid break in attempts and deal with it. Being more restrictive will just end up being a pain. For example, maybe two friends want to share a connection, so the first gets on and then after a bit passes it off to the second who changes their IP and MAC to match, but then bam, they can't get on. Or maybe someone dualboots. -Nick
Re: MAC - IP - MAC
On 4 Jun 2006, at 15:55, Nick Guenther wrote: Being more restrictive will just end up being a pain. For example, maybe two friends want to share a connection, so the first gets on and then after a bit passes it off to the second who changes their IP and MAC to match, but then bam, they can't get on. Or maybe someone dualboots. I don't know as I've never tried it, but what happens on a network when the same MAC address appears for two devices? The principal is one login = one person at a time. If they dualboot, once they've booted into another OS, either the dhcp server will give them the same address they had last time, or if their MAC is different they'll get a new IP, and will just have to login again to get access. If two people want to share, they can't, unless they have two separate accounts, or are willing to indulge in internet connection sharing. Most of this stuff is beyond the casual user anyhow, which is the intended audience. There's a limit to how many layers of protection I can build in, but I think this is probably far enough. Gaby -- Junkets for bunterish lickspittles since 1998! http://www.playr.co.uk/sudoku/ http://weblog.vanhegan.net/
Re: MAC - IP - MAC
On Sat, Jun 03, 2006 at 12:10:55AM +0100, Gaby vanhegan wrote: From thinking about it more, it's just simpler to track which IP address belongs to which login, and then when that user tries to login on a second client, the first one is barred access. This only allows one IP address per client. It does mean that the the IP tracking software needs to know a little more about the IP address that it created, and requires to be a bit more actively managed. So all I have to do is *TRY* to login as you on another machine and your original legit connection is dropped? Think about this.
Re: MAC - IP - MAC
On 3 Jun 2006, at 17:03, Clint M. Sand wrote: So all I have to do is *TRY* to login as you on another machine and your original legit connection is dropped? Think about this. Only successful logins would update the IP associated with that login. Failed login attempts would do nothing. Sorry, my wording was a little unclear, what I actually meant was a successful login from a second machine would kick the first login off, as the most recent IP would be the one associated with that client. If the first client successfully logged in again, that would kick the second login off. The best I can do against somebody trying to use a stale IP is to check the MAC address that the successful login came from against what it claims to be at the time. Any mis-match and the IP is kicked off. If people want to go to the effort of spoofing a MAC address and finding a stale IP to use, there's little I can do. Being that this is a service intended for the general public, I'm reckoning that 99.9% of users won't even know that a MAC could be spoofed, or know how to do it. I suppose I could take it one step further and get a tcp OS fingerprint of the client at login time, and use that as a further aid to checking that the person that logged in is the person currently using this IP address. Is there any way to protect against this? Gaby -- Junkets for bunterish lickspittles since 1998! http://www.playr.co.uk/sudoku/ http://weblog.vanhegan.net/
MAC - IP - MAC
Hello, good evening and welcome. I'm building a system that allows wireless clients to connect to an AP, authenticate themselves with a login and password, and they're then granted access to the internet, through a pf firewall using tables to control access. The clients are all assigned an address through DHCP (hopefully using dhcpd) so they should have an entry in dhcpd.leases for their MAC. When they authenticate, their MAC address is what is used to identify them, not their IP. I'm using a custom system to authenticate users, authpf is not really suitable here. Authenticated MACs are converted to an IP address, using dhcpd.leases to do the lookup. Then, as a double check, it will use the ARP cache to confirm that the IP and the MAC match up, so users can't steal access from a stale IP somewhere. If a user picks a static IP, they won't have an entry in dhcpd.leases, so they won't get access. What I'm looking for is a simple way to pull an IP/MAC combination out of a dhcpd.leases file, or a reasonably sized dhcpd.leases file that I can test a parser on. Can anybody help out here? Also, does this system sound reasonable or sensible? All comments welcome. Gaby -- Junkets for bunterish lickspittles since 1998! http://www.playr.co.uk/sudoku/ http://weblog.vanhegan.net/
Re: MAC - IP - MAC
From: [EMAIL PROTECTED] Authenticated MACs are converted to an IP address, using dhcpd.leases to do the lookup. Then, as a double check, it will use the ARP cache to confirm that the IP and the MAC match up, so users can't steal access from a stale IP somewhere. If a user picks a static IP, they won't have an entry in dhcpd.leases, so they won't get access. What I'm looking for is a simple way to pull an IP/MAC combination out of a dhcpd.leases file, or a reasonably sized dhcpd.leases file that I can test a parser on. Can anybody help out here? Also, does this system sound reasonable or sensible? All comments welcome. Neither reasonable nor sensible from a security standpoint. Authenticating based on MAC addresses is like authenticating someone on the pretense of them wearing a blue shirt. It's not a strong authenenticator and it can be changed easily. WPA/802.1x handles this sort of thing much better, as does authpf and IPsec and ... and ... DS
Re: MAC - IP - MAC
On 2 Jun 2006, at 23:16, Spruell, Darren-Perot wrote: Neither reasonable nor sensible from a security standpoint. Authenticating based on MAC addresses is like authenticating someone on the pretense of them wearing a blue shirt. It's not a strong authenenticator and it can be changed easily. It's more of an identifier. I'm trying to use it to only allow one client per login/password, and I just figured MAC addresses would be more unique than an IP and easier to track between different sites. The login and password is still independent of the IP address. From thinking about it more, it's just simpler to track which IP address belongs to which login, and then when that user tries to login on a second client, the first one is barred access. This only allows one IP address per client. It does mean that the the IP tracking software needs to know a little more about the IP address that it created, and requires to be a bit more actively managed. Gaby -- Junkets for bunterish lickspittles since 1998! http://www.playr.co.uk/sudoku/ http://weblog.vanhegan.net/
