RE: Duplicate IPs for Radius Clients with different secrets - allow any client IP?
Thanks for the info, Anders. Yes, I'm considering security issues. Just would be really great if I could make everything work as I want...with still being secure.
Why bother doing the SQL stuff, if you're going to let anyone use your service anyway? The way I thought it up, it would allow any IP to TRY to run its request to the server...whereas if real client IPs are given, requests are denied before the sever does any work if the client IP isn't on the list.
Say I did open up to any IP, the AP's MAC must match one from my list; moreover the hacker must have the shared secret. Plus if I can add to the example SQL statement, I would add to the WHERE clause "and domain =(domain pulled from what's after the username's @ sign). Then the hacker must know a username and domain that matches an acceptable AP, the user's password, that acceptable AP's MAC address, and then finally the shared secret for the AP. What could a hacker do to the server if he can't even get passed returning a correct shared secret? cause DoS attacks? If so, I can try to find something that blocks requests from originating IPs for 5mins after so many requests. What do you think? Thanks for your input, Eric From: freeradius-users-bounces+me=egeier.com@lists.freeradius.org [mailto:freeradius-users-bounces+me=egeier.com@lists.freeradius.org] On Behalf Of Anders Holm Sent: Wednesday, December 17, 2008 2:55 PM To: FreeRadius users mailing list Subject: Re: Duplicate IPs for Radius Clients with different secrets - allow any client IP? Eric Geier wrote: Thank you for the info, David. I think the following is an example of how this could work, which I googled: client 212.37.57.2 { secret = "%{sql:SELECT secret FROM accesspoints WHERE id = %{raw:NAS-Identifier}}" shortname = "just one of our example networks" } I'm thinking I could even just have one client entry like this...but set to allow any IP. Is that possible? clients.conf client 0.0.0.0/0, shared secret = "open" ... Why bother doing the SQL stuff, if you're going to let anyone use your service anyway? Think about it ... clients.conf controls which APs/NAS' are allowed to send you stuff to process. If your intention is to open it for anyone that can reach your service, why then do the above? The end clients are not what will send you requests, the APs are ....... I think you've missed the point of the IP addressing for the end clients versus how you wish to handle the APs ... And for a service which allows or denies access for your internal users, I wouldn't personally allow anyone from the outside world even get close to that service. You want to understand basic networking and security considerations before seriously contemplating this. Start looking at getting a VPN solution between your offices, or simply just put one FreeRADIUS box in each office. Continue on this path and fairly soon someone will have found your wireless setup and the service which allows clients to authenticate sitting out in the open. You might as well not have anything in place at all then... //anders This would prevent me from having to track Internet IP changes among the multiple offices and locations where these separate WPA-Enterprise networks will be located at. Thanks! Eric -----Original Message----- From: freeradius-users-bounces+me=egeier.com@lists.freeradius.org [mailto:freeradius-users-bounces+me=egeier.com@lists.freeradius.org] On Behalf Of wlanmac Sent: Wednesday, December 17, 2008 8:42 AM To: freeradius-users@lists.freeradius.org Subject: Re: Duplicate IPs for Radius Clients with different secrets It's easy! Just google for rlm_raw and use it with a SQL xlat rule to pick out the shared secret from a database. I have been doing this way for years... in FreeRADIUS v1 and v2. David coova.org Date: Wed, 17 Dec 2008 10:16:17 +0200 From: Johan Meiring <jmeiring@pcservices.co.za> Subject: Re: Duplicate IPs for Radius Clients with different secrets To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Message-ID: <4948B551.6030406@pcservices.co.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Eric Geier wrote: If I understand what you said, I would only need one IP entry (the Internet IP) in the config file for each location, right? Most of these locations will be using dynamic Internet IPs; I'm not sure how'd I keep the config updated. Plus this would make each location/network use the same shared secret among all their APs, which I want to prevent. Alan, The Nas-Identifier being available to dynamic clients will also solve Eric's problem. Any update on when it might be available? Thanks! No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.19/1853 - Release Date: 12/17/2008 8:31 AM
What could a hacker do to the server if he can't even get passed returning a correct shared secret?
Get the usernames and passwords of your users and gain access to your network at will. Publish them and let anybody use your network. Ivan Kalik Kalik Informatika ISP
tnt@kalik.net wrote:
What could a hacker do to the server if he can't even get passed returning a correct shared secret?
Get the usernames and passwords of your users and gain access to your network at will. Publish them and let anybody use your network.
Internet for free. Sounds great. Here's one example, is this you? Geier, Eric me@egeier.com 297 Marchmont Drive Fairborn, Ohio 45324 United States +1.9372600286 First Google hit: http://www.informit.com/authors/bio.aspx?a=AFEDE263-5156-4C97-AD8E-5E4473511... Interesting list of books on your site. "Say I did open up to any IP, the AP's MAC must match one from my list; moreover the hacker must have the shared secret. Plus if I can add to the example SQL statement, I would add to the WHERE clause "and domain =(domain pulled from what's after the username's @ sign). Then the hacker must know a username and domain that matches an acceptable AP, the user's password, that acceptable AP's MAC address, and then finally the shared secret for the AP. " So, because a lot of hurdles are put in front of someone that should stop them? If so, I would never be where I am today. All that does is challenges your adversaries intellect, and let us face reality a bit, the ones that knows what they do would take that challenge on any day. Put a carrot in front of a donkey, and it'll get eaten. Put a lot of carrots in front of the donkey and they'll still get eaten, it'll just take slightly longer. I can't see how putting your authentication and authorization system in the wild will help you, other than saving a buck on setting up VPNs between your sites. Which can also be done cheaply if cost is the motivator. Don't put an infrastructure piece like this sit in the open if you use it for your internal purposes. Wouldn't you agree? //anders
participants (3)
-
Anders Holm -
Eric Geier -
tnt@kalik.net