Assumed users by MAC address
Jul 17 07 4:43 am
Hi,
I currently have a couple of users configured as "Assumed" by specifying their IP address. The problem is that anybody can change their IP address to be that, so anybody can pose as being that user.
I was wondering if there is anyway to specify MAC addresses instead of IP addresses, since these are a bit more difficult to spoof.
Or perhaps achieve the same effect through policies?
Thanks in advance!
I currently have a couple of users configured as "Assumed" by specifying their IP address. The problem is that anybody can change their IP address to be that, so anybody can pose as being that user.
I was wondering if there is anyway to specify MAC addresses instead of IP addresses, since these are a bit more difficult to spoof.
Or perhaps achieve the same effect through policies?
Thanks in advance!
Jul 18 07 9:43 am
I did an answer in a support ticket that should help; I have pasted it below (p.s. MAC addresses can be changed too on some hardware)
"I really need to know how to assume the user based on the mac Address."
I can only suggest Assuming by ip address and then have a System Policy checking the MAC address against the user to allow access. So you would have your authentication done via the System Policies, and have each server / service check the Default Rights as "Must also be granted".
An example policy in could look like this:
1. Create the User Assumptions based off their ip addresses.
2. Modify the System Policies so to only accept the correct MAC Addresses associated to the user (As shown in image attached):
System Policies:
Everyone, User may be assumed
Advanced tab:
Filter 1
This criterion is met if MAC Address equals 00-11-2F-DC-53-4E
This criterion is met if User: Username equals Jamesc
Filter 2
This criterion is met if MAC Address equals 00-11-2F-DC-53-4E
This criterion is met if User: Username equals Pedro
Filter 3
This criterion is met if MAC Address equals 00-11-2F-DC-53-4E
This criterion is met if User: Username equals Terry
3. Set the other services / servers you use in WinGate to have their Default Rights (System Policies) set to "Must also be granted". In the email that will follow you will see an example image of the WWW Proxy Service with a "white list" of allowed sites, and using the "Must also be granted" Default Rights.
Tips:
1. Don't forget to make a MAC policy for the actual WinGate server as well.
2. Within the Advanced tab of a policy separate Filters are OR'd and multiple Criterions within Filters are AND'd
3. The Policy with the most access will always override the policy with the least access. So for example if we added a second Everyone group to the System Policies with no restrictions, then it would override those MAC addresses/User policies we setup in the first Everyone group.
4. There are quite a few ways to authenticate a user in WinGate depending on what user database is being used:
WinGate User Database.
WWW Proxy Java Authentication - Secure method - Needs Java (www.java.com)
WGIC Authentication - Secure method - Client install.
QbikAuth Authentication - Secure method - Client install.
GateKeeper Authentication - Secure method - Client install.
Basic Authentication - Insecure method.
Assumed by IP Address - Insecure method.
Assumed by Computer name - Insecure method and WinGate must be DHCP Server.
Unauthenticated Access - Can be set for different criterions.
Local Windows User Database
WWW Proxy NTLM Authentication - Secure Method - Application must be NTLM compatible.
WGIC NTLM Authentication - Secure method - Client install.
QbikAuth NTLM Authentication - Secure method - Client install.
GateKeeper NTLM Authentication - Secure method - Client install.
Basic Authentication - Insecure method.
Assumed by IP Address - Insecure method.
Assumed by Computer name - Insecure method and WinGate must be DHCP Server.
Unauthenticated Access - Can be set for different criterions.
Domain User Database.
WWW Proxy NTLM Authentication - Secure Method - Application must be NTLM compatible.
WGIC NTLM Authentication - Secure method - Client install.
QbikAuth NTLM Authentication - Secure method - Client install.
GateKeeper NTLM Authentication - Secure method - Client install.
Basic Authentication - Insecure method.
Assumed by IP Address - Insecure method.
Assumed by Computer name - Insecure method and WinGate must be DHCP Server.
Unauthenticated Access - Can be set for different criterions.
*Secure: Then the authentication level of the policy needs to be set to "User must be authenticated"
*Insecure: Then the authentication level of the policy needs to be set to "User may be assumed"
*Unauthenticated: Then the authentication level of the policy needs to be set to "User may be unknown"
5. In my suggestion above I said to make the WWW Proxy Service to interact with the Default Rights with the "Must also be granted" option; here are some concepts of how to use this option:
*"Must also be granted": If the e.g. WWW Proxy Server policy allows access to this service, then it must also be checked in the System Polices before it is allowed. (So in my suggestion, the WWW Proxy looks after the access for web pages and the System Policies makes sure the user has the correct MAC address).
*"May be used instead": If the e.g. WWW Proxy Server policy denies the request, then check if the System Policies allow it; if it does, allow the user to access.
*"Are ignored": Do not check the System Policies to check if this user is allowed/denied to access to the WWW Proxy Server.
"I really need to know how to assume the user based on the mac Address."
I can only suggest Assuming by ip address and then have a System Policy checking the MAC address against the user to allow access. So you would have your authentication done via the System Policies, and have each server / service check the Default Rights as "Must also be granted".
An example policy in could look like this:
1. Create the User Assumptions based off their ip addresses.
2. Modify the System Policies so to only accept the correct MAC Addresses associated to the user (As shown in image attached):
System Policies:
Everyone, User may be assumed
Advanced tab:
Filter 1
This criterion is met if MAC Address equals 00-11-2F-DC-53-4E
This criterion is met if User: Username equals Jamesc
Filter 2
This criterion is met if MAC Address equals 00-11-2F-DC-53-4E
This criterion is met if User: Username equals Pedro
Filter 3
This criterion is met if MAC Address equals 00-11-2F-DC-53-4E
This criterion is met if User: Username equals Terry
3. Set the other services / servers you use in WinGate to have their Default Rights (System Policies) set to "Must also be granted". In the email that will follow you will see an example image of the WWW Proxy Service with a "white list" of allowed sites, and using the "Must also be granted" Default Rights.
Tips:
1. Don't forget to make a MAC policy for the actual WinGate server as well.
2. Within the Advanced tab of a policy separate Filters are OR'd and multiple Criterions within Filters are AND'd
3. The Policy with the most access will always override the policy with the least access. So for example if we added a second Everyone group to the System Policies with no restrictions, then it would override those MAC addresses/User policies we setup in the first Everyone group.
4. There are quite a few ways to authenticate a user in WinGate depending on what user database is being used:
WinGate User Database.
WWW Proxy Java Authentication - Secure method - Needs Java (www.java.com)
WGIC Authentication - Secure method - Client install.
QbikAuth Authentication - Secure method - Client install.
GateKeeper Authentication - Secure method - Client install.
Basic Authentication - Insecure method.
Assumed by IP Address - Insecure method.
Assumed by Computer name - Insecure method and WinGate must be DHCP Server.
Unauthenticated Access - Can be set for different criterions.
Local Windows User Database
WWW Proxy NTLM Authentication - Secure Method - Application must be NTLM compatible.
WGIC NTLM Authentication - Secure method - Client install.
QbikAuth NTLM Authentication - Secure method - Client install.
GateKeeper NTLM Authentication - Secure method - Client install.
Basic Authentication - Insecure method.
Assumed by IP Address - Insecure method.
Assumed by Computer name - Insecure method and WinGate must be DHCP Server.
Unauthenticated Access - Can be set for different criterions.
Domain User Database.
WWW Proxy NTLM Authentication - Secure Method - Application must be NTLM compatible.
WGIC NTLM Authentication - Secure method - Client install.
QbikAuth NTLM Authentication - Secure method - Client install.
GateKeeper NTLM Authentication - Secure method - Client install.
Basic Authentication - Insecure method.
Assumed by IP Address - Insecure method.
Assumed by Computer name - Insecure method and WinGate must be DHCP Server.
Unauthenticated Access - Can be set for different criterions.
*Secure: Then the authentication level of the policy needs to be set to "User must be authenticated"
*Insecure: Then the authentication level of the policy needs to be set to "User may be assumed"
*Unauthenticated: Then the authentication level of the policy needs to be set to "User may be unknown"
5. In my suggestion above I said to make the WWW Proxy Service to interact with the Default Rights with the "Must also be granted" option; here are some concepts of how to use this option:
*"Must also be granted": If the e.g. WWW Proxy Server policy allows access to this service, then it must also be checked in the System Polices before it is allowed. (So in my suggestion, the WWW Proxy looks after the access for web pages and the System Policies makes sure the user has the correct MAC address).
*"May be used instead": If the e.g. WWW Proxy Server policy denies the request, then check if the System Policies allow it; if it does, allow the user to access.
*"Are ignored": Do not check the System Policies to check if this user is allowed/denied to access to the WWW Proxy Server.
Aug 17 07 7:20 pm
I got another Idea
If he make one rule say "This criterion is met if client is a DHCP client is True" instaead of rule to every user. it will work also because no one will change his IP to spoof in the DHCP mode.
i hope it is right :)
If he make one rule say "This criterion is met if client is a DHCP client is True" instaead of rule to every user. it will work also because no one will change his IP to spoof in the DHCP mode.
i hope it is right :)
Aug 17 07 7:26 pm
"This criterion is met if client is a DHCP client is True" actually means
This criterion is met if the IP Address is one that the DHCP Server has previously given out - it does not matter if it was the same computer that got the IP Address or a different computer - I have critiqued this to my colleagues before about changing this because it is misleading.
This criterion is met if the IP Address is one that the DHCP Server has previously given out - it does not matter if it was the same computer that got the IP Address or a different computer - I have critiqued this to my colleagues before about changing this because it is misleading.
Aug 17 07 9:32 pm
Ok
i have a question about the mac address method. When the Gatekeeper check the client MAC address then? because i tried it but it is some time work and another don't work
i mean if i want wingate to recheck the Mac what i have to do?
i have a question about the mac address method. When the Gatekeeper check the client MAC address then? because i tried it but it is some time work and another don't work
i mean if i want wingate to recheck the Mac what i have to do?
Aug 17 07 10:11 pm
I would speculate this is a misconfiguration error - did you try my example above? And notice in the double brown box in the image I have the Default Rights set to "Must also be granted"
Aug 28 07 12:21 am
Hi,
thanks James for your very complete answer above - it was very useful and clear.
I've been trying this setup and I have to say it's mostly working.
One problem I have, though, is with the way Wingate caches the information about computers accessing it. Sometimes, I've had users with problems getting authorized, and when I check Wingate I see that the user's computer is showing up with the wrong computer name and MAC address (thus failing my MAC address verification), and I realize it is because Wingate is taking into consideration a computer name and MAC address that previously connected from that same IP address.
I solved this by deleting DNS leases from the registry and restarting Wingate, but I would love to have nicer ways of solving (or avoiding) this issue. Any ideas?
Thanks.
thanks James for your very complete answer above - it was very useful and clear.
I've been trying this setup and I have to say it's mostly working.
One problem I have, though, is with the way Wingate caches the information about computers accessing it. Sometimes, I've had users with problems getting authorized, and when I check Wingate I see that the user's computer is showing up with the wrong computer name and MAC address (thus failing my MAC address verification), and I realize it is because Wingate is taking into consideration a computer name and MAC address that previously connected from that same IP address.
I solved this by deleting DNS leases from the registry and restarting Wingate, but I would love to have nicer ways of solving (or avoiding) this issue. Any ideas?
Thanks.
Aug 28 07 7:31 pm
Thanks for your comments.
Regarding your current issue, are you using "Assume by computer name"? And then using the NetBIOS name and MAC in the System Policies?
I wonder if finalising this with a MAC address reservation in WinGate's DHCP Server will resolve it; i.e. only computers with the correct MAC address can get that specific ip address.
Regarding your current issue, are you using "Assume by computer name"? And then using the NetBIOS name and MAC in the System Policies?
I wonder if finalising this with a MAC address reservation in WinGate's DHCP Server will resolve it; i.e. only computers with the correct MAC address can get that specific ip address.
Aug 28 07 11:01 pm
Hi,
I'm not using "Assume by computer name", I use "assume by IP address".
Then my criteria in System Policies only checks for a bunch of possible MAC addresses. I don't think I need to make sure a specific user only connects from a specific MAC. It's enough for me to make sure whoever is connecting, is connecting from an authorized MAC.
About that "MAC address reservation" DHCP option you mention, it seems interesting, but I can't seem to find them. I have Wingate's DHCP server running in Fully Automatic mode. Is that what I need to change?
I'd appreciate some instructions. Thanks.
I'm not using "Assume by computer name", I use "assume by IP address".
Then my criteria in System Policies only checks for a bunch of possible MAC addresses. I don't think I need to make sure a specific user only connects from a specific MAC. It's enough for me to make sure whoever is connecting, is connecting from an authorized MAC.
About that "MAC address reservation" DHCP option you mention, it seems interesting, but I can't seem to find them. I have Wingate's DHCP server running in Fully Automatic mode. Is that what I need to change?
I'd appreciate some instructions. Thanks.
Aug 28 07 11:35 pm
Scenario:
192.168.0.1 - 192.168.0.20 has already been given out to computers on your network from WinGate's DHCP Server.
Disclaimer:
It is hard to give advice when there is no context to the size of this network – if it was a small network I would probably not need to disclaim. So be careful, think this procedure through, and the questions I would be asking myself before doing this is:
"How long are my current IP Addresses leases?"
"If I add a reservation for 192.168.0.5 with the MAC xxxxxxxxxx - then if there is another computer out there with that IP Address already - when am I going to run the "ipconfig/renew" command? So to avoid ip address conflicts"
“Do I need to do anything special to be able to renew the ip address on the LAN Client – i.e. log in as an administrator to be able to renew ip address details.”
1. DHCP --> DHCP Settings
- I believe there will be no scope there with a "Light bulb" icon next to it - so you need to create it - as follows.
- Right Click the adapter icon showing your ip address.
- "New Scope"
- Enter the ip range 192.168.0.1 - 192.168.0.20 then click ok.
- Right click the scope with the light bulb icon.
- Select "New Reservation"
- Enter the ip address and MAC (I did not use '-' in MAC address) and then ok.
- Repeat previous step if needed.
- OK back to GateKeeper.
2. Go to each LAN Client and enter the following command.
(Windows) Start menu --> Run --> cmd --> ipconfig/renew
192.168.0.1 - 192.168.0.20 has already been given out to computers on your network from WinGate's DHCP Server.
Disclaimer:
It is hard to give advice when there is no context to the size of this network – if it was a small network I would probably not need to disclaim. So be careful, think this procedure through, and the questions I would be asking myself before doing this is:
"How long are my current IP Addresses leases?"
"If I add a reservation for 192.168.0.5 with the MAC xxxxxxxxxx - then if there is another computer out there with that IP Address already - when am I going to run the "ipconfig/renew" command? So to avoid ip address conflicts"
“Do I need to do anything special to be able to renew the ip address on the LAN Client – i.e. log in as an administrator to be able to renew ip address details.”
1. DHCP --> DHCP Settings
- I believe there will be no scope there with a "Light bulb" icon next to it - so you need to create it - as follows.
- Right Click the adapter icon showing your ip address.
- "New Scope"
- Enter the ip range 192.168.0.1 - 192.168.0.20 then click ok.
- Right click the scope with the light bulb icon.
- Select "New Reservation"
- Enter the ip address and MAC (I did not use '-' in MAC address) and then ok.
- Repeat previous step if needed.
- OK back to GateKeeper.
2. Go to each LAN Client and enter the following command.
(Windows) Start menu --> Run --> cmd --> ipconfig/renew
Aug 29 07 4:16 am
- Right click the scope with the light bulb icon.
- Select "New Reservation"
Ah, that was the part I wasn't seeing.
It's going to give me some work, but I think I can set everything up correctly with this option.
Basically, I have 2 subnets, one is more public and I require authentication. The other is more private and more trusted, I will have about 8 or 9 computers working with assumed users and MAC address verification there.
If I have to, I can go to each computer and configure it as an administrator. But these clients are set up to obtain IP from Wingate's DHCP, so with a bit of luck I won't even have to renew the IP locally on each of them.
Thanks for your help!
Aug 29 07 11:52 pm
I have a question: this DHCP reservation does not that guarantee a certain IP will only be used by a certain MAC, right? It just configures the way the DHCP attributes IP's, but if the client is configured for a specific IP address, even if it is not the one that matches his MAC address in Wingate, it can get access to Wingate, right?
I ask this just to make sure that I have to keep the MAC restrictions in policies, or can I throw them away and keep just the DHCP reservations?
I ask this just to make sure that I have to keep the MAC restrictions in policies, or can I throw them away and keep just the DHCP reservations?
Aug 30 07 1:21 am
I have a question: this DHCP reservation does not that guarantee a certain IP will only be used by a certain MAC, right? It just configures the way the DHCP attributes IP's, but if the client is configured for a specific IP address, even if it is not the one that matches his MAC address in Wingate, it can get access to Wingate, right?
Correct - I would have only advised that "Reservation" scenario if the criterion in WinGate called "Is a DHCP Client" meant what most of us may expect. This solution is also a copy and paste from a support ticket where the scenario had to have MAC address checking to fulfill their security requirements.
I ask this just to make sure that I have to keep the MAC restrictions in policies, or can I throw them away and keep just the DHCP reservations?
I hear ya. To have the MAC address restrictions on your network you should be keeping those system policies in place – I see it as a trade off between security and future administrative overheads.
Aug 31 07 10:57 pm
Hi again,
I tried mapping several assumed IP's to the same username, but it seems that Wingate won't let the same user access from more than one computer at the same time... is there any way around this? Or do I really have to have N users to access from N computers concurrently?
I tried mapping several assumed IP's to the same username, but it seems that Wingate won't let the same user access from more than one computer at the same time... is there any way around this? Or do I really have to have N users to access from N computers concurrently?
Sep 02 07 9:07 am
pgr wrote:Hi again,
I tried mapping several assumed IP's to the same username, but it seems that Wingate won't let the same user access from more than one computer at the same time... is there any way around this? Or do I really have to have N users to access from N computers concurrently?
I have only seen this if under System Polices on the Right drop down box Users have simultaneous access from multiple computers is selected and there is a user restriction in the policy. Normally by default Everyone has Unrestricted rights. Could this be the issue here?
Sep 03 07 8:03 am
Yep, I think you nailed it... I didn't get a chance to test it, but from what I saw there it seems to make sense - there were rights only for some groups, and the user I had used when I noticed the problem wasn't part of these groups. I put this back to "Everyone - Unrestricted rights", I don't think I have a requirement for restrictions here.
Thanks!
Thanks!
Sep 13 07 11:59 am
sorry i discovered a problem here.
I use the same configration to be sure that the computer access the net is the same one witch i allowed before. every thing was going ok. but i discovered that wingate assume the accessed user name for the ip without checking the mac address.
and this case happened with some ip not all. while the others is controled well.
ex:
wingate user "A" 192.168.1.2 MAC: aaa DHCP reversed before
wingate user "B" 192.168.1.3 MAC: bbb DHCP reversed before
unknown user "X" Mac: ccc take the ip 192.168.1.2 manualy configured
= wingate see him as user A and he access every thing normaly
but if he try to:
unknown user "X" Mac: ccc take the ip 192.168.1.3 manualy configured
= wingate block him.
while wingate system polices have those two rulz:
Filter 1
This criterion is met if MAC Address equals aaa
This criterion is met if User: Username equals A
Filter 2
This criterion is met if MAC Address equals bbb
This criterion is met if User: Username equals B
the question is how user x passes those two rulz with ip 192.168.1.2 while his mac is not met with the rule. at the other side wingate block him when he try to enter with 192.168.1.3 i stay mor than 5 hours try to solve but failed.
my configration:
DHCP reversed by mac
assumed users by ip
every service have :system polices: Must also be granted
user must be assumed
really want help in this case?
I use the same configration to be sure that the computer access the net is the same one witch i allowed before. every thing was going ok. but i discovered that wingate assume the accessed user name for the ip without checking the mac address.
and this case happened with some ip not all. while the others is controled well.
ex:
wingate user "A" 192.168.1.2 MAC: aaa DHCP reversed before
wingate user "B" 192.168.1.3 MAC: bbb DHCP reversed before
unknown user "X" Mac: ccc take the ip 192.168.1.2 manualy configured
= wingate see him as user A and he access every thing normaly
but if he try to:
unknown user "X" Mac: ccc take the ip 192.168.1.3 manualy configured
= wingate block him.
while wingate system polices have those two rulz:
Filter 1
This criterion is met if MAC Address equals aaa
This criterion is met if User: Username equals A
Filter 2
This criterion is met if MAC Address equals bbb
This criterion is met if User: Username equals B
the question is how user x passes those two rulz with ip 192.168.1.2 while his mac is not met with the rule. at the other side wingate block him when he try to enter with 192.168.1.3 i stay mor than 5 hours try to solve but failed.
my configration:
DHCP reversed by mac
assumed users by ip
every service have :system polices: Must also be granted
user must be assumed
really want help in this case?
Sep 14 07 1:59 pm
The MAC address record is obtained from the DHCP information stored in WinGate. It isn't checked from the client computer. WinGate would see the IP address and then check it's DHCP records against that IP to find the MAC.
This means, even if you were to make a filter that checks both the mac and the ip, a client computer would still be able to impersonate a different computer that already has a DHCP record with WinGate.
If you are concerned that your users have the knowledge to and will be attempting to get around your user assumptions, you may want to consider using a more secure authentication method.
This means, even if you were to make a filter that checks both the mac and the ip, a client computer would still be able to impersonate a different computer that already has a DHCP record with WinGate.
If you are concerned that your users have the knowledge to and will be attempting to get around your user assumptions, you may want to consider using a more secure authentication method.
Sep 15 07 12:31 am
i got what u r saying well. thanks alot.
but there is still one thing. why when:
"unknown user "X" Mac: ccc take the ip 192.168.1.3 manualy configured
= wingate block him."
While the other one is allowed to access the services. that is the point. if we reach this point i could solve it as i think.
in another way how can i configure wingate server to recheck the mac address again every time it treat with any pc? how can i make the cache time for mac short in wingate options?
i hope to find a way because it is a big network i can't use wgic in my case.
but there is still one thing. why when:
"unknown user "X" Mac: ccc take the ip 192.168.1.3 manualy configured
= wingate block him."
While the other one is allowed to access the services. that is the point. if we reach this point i could solve it as i think.
in another way how can i configure wingate server to recheck the mac address again every time it treat with any pc? how can i make the cache time for mac short in wingate options?
i hope to find a way because it is a big network i can't use wgic in my case.