- Freeradius-Users - lists.freeradius.org

RE: AVPair question
by Guy Davies 15 Jul '05

15 Jul '05

You should not edit the main dictionary file. You should create this as a separate file (called dictionary.colubris) with all the other dictionary.foo files (normally in /usr/local/share/freeradius/). Then look in the file called dictionary in the same directory and make sure (as it says in the comments at the top of the file you've sent) to put the line $INCLUDE dictionary.colubris NOTE: There is already a dictionary.colubris file in my installation of FreeRADIUS 1.0.4. However, it doesn't have the second attribute. If you also have that file, you could simply edit it and insert the second line beginning with "ATTRIBUTE". Once you've done all that, you'll need to restart the server to get it to reread the config files. Guy > -----Original Message----- > From: freeradius-users-bounces(a)lists.freeradius.org > [mailto:freeradius-users-bounces@lists.freeradius.org] On > Behalf Of Andrey > Sent: 15 July 2005 16:52 > To: freeradius-users(a)lists.freeradius.org > Subject: AVPair question > > > Hey List, > > Quick question about AVPair. I have a Colubris Access Point > which wants me to use the Colubris-AVPair attribute. The > attribute is defined in a dictionary file, which is included > in the main dictionary. This is what it looks like: > > # Colubris dictionary - dictionary.colubris > # > # Enable by putting the line "$INCLUDE dictionary.colubris" into > # the main dictionary file. > # > # > > VENDOR Colubris 8744 > > # > # Vendor-specific attributes > # > ATTRIBUTE Colubris-AVPair 0 string > Colubris > ATTRIBUTE Colubris-Intercept 1 integer > Colubris > > When I try to authenticate, I get "unknown-vendor 8744, size > 30 = '' " for my attributes dump. What am I missing? Is there > a separate file for defining vendors? > > Any help appreciated. > > - Andrey > > > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavours to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

1 0

RE: Server Suggestion
by King, Michael 15 Jul '05

15 Jul '05

> > If the AP's are wireless, then CPU is more important, as > EAP uses SSL, which has a large CPU impact. > Would FreeRADIUS take advantage of a Dual CPU system?

2 1

Allowing any NAS to connect to my radiusd.
by Marcin Jessa 15 Jul '05

15 Jul '05

Hi. I would like to allow any NAS IP to connect to my radius server restricting connections from NAS only with shared secret - username and password. Is it possible to use 0.0.0.0 or ANY in clients.conf/SQL nas table ? What are the security issues having an open setup like that ? Cheers Marcin Jessa.

3 3

ippool problem
by abernabe＠mutua-mad.es 15 Jul '05

15 Jul '05

Hello, I´m trying to configure a FreeRadius 1.0.4 in Red Hat 8.0. Everything works OK until I add the ippool in the "post-auth" and "accounting" section. When I start the server I get always the error "Segmentation Fault" after loading radutmp, just when it tries to load the ippool in the "accounting" section I have the following configuration in the ippool module: ippool 2 { range-start = 172.20.1.1 range-stop = 172.20.1.254 netmask = 255.255.255.0 cache-size = 254 session-db = ${raddbdir}/db.ippool ip-index = ${raddbdir}/db.ipindex override = yes maximum-timeout = 0 } Do you know if I´m doing something wrong? Thanks

4 5

Access-Challenge
by Srinivasa Rao Chigurupati 15 Jul '05

15 Jul '05

Hi When will Radius Server will challenge with Access-Challenge packet during authentication? Is it depends on any configuration? -- Thanks & Regards Srinivasa Rao Chigurupati

2 3

External authentication and Reply-Message
by Velikanov 15 Jul '05

15 Jul '05

GOOD DAY. I use freeradius-snapshot-20050624. I want to use External authentication My radiusd.conf: ........................ exec echo { wait = yes program = "/usr/local/etc/raddb/radius.auth" input_pairs = request output_pairs = reply } ......................... authorize { ............. files echo sql } ......................... My users file: DEFAULT Auth-Type := Accept Reply-Message = "`%{echo:/usr/local/etc/raddb/radius.auth}` My test programm with name /usr/local/etc/raddb/radius.auth: #!/bin/sh echo "Reply-Message += You are already logged in" exit 0 # end of programm The aim is to authenticate users under sertain conditions, return "0" for Accept, "1" for Reject end return certain value of Reply-Message. When programm return "0" - I DO see the value "You are already logged in", BUT when programm return "1" - I DO NOT see the value "You are already logged in". I see Reply-Message = "``" It is the OUTPUT of radiusd -X for exit 0 rad_recv: Access-Request packet from host 192.168.98.100 port 1030, id=48, lengt h=58 User-Name = "morgan" User-Password = "test" NAS-IP-Address = 213.NNN.12.17 Framed-Protocol = PPP Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 rlm_realm: No '@' in User-Name = "morgan", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 users: Matched entry DEFAULT at line 1 radius_xlat: Running registered xlat function of module echo for string '/usr/lo cal/etc/raddb/radius.auth' rlm_exec (echo): Executing /usr/local/etc/raddb/radius.auth Exec-Program output: Reply-Message += You are already logged in Exec-Program-Wait: plaintext: Reply-Message += You are already logged in Exec-Program: returned: 0 rlm_exec (echo): result 0 radius_xlat: '`Reply-Message += You are already logged in `' modcall[authorize]: module "files" returns ok for request 0 Exec-Program output: Reply-Message += You are already logged in Exec-Program-Wait: plaintext: Reply-Message += You are already logged in Exec-Program: returned: 0 modcall[authorize]: module "echo" returns ok for request 0 radius_xlat: 'morgan' rlm_sql (sql): sql_set_user escaped user --> 'morgan' rlm_sql (sql): Reserving sql socket id: 13 radius_xlat: 'SELECT * FROM TABLE(CAST(INTERNET_SECURITY.CHECK_USER ?('morgan', ?'213.130.12.17','','') AS RAD_ROWS)) ' rlm_sql (sql): User found in radcheck table radius_xlat: 'SELECT * FROM ?TABLE(CAST(INTERNET_SECURITY.REPLY_USER('morgan',' 213.130.12.17','PPP','Framed-User','', ?'','') AS RAD_ROWS)) ' rlm_sql (sql): Released sql socket id: 13 modcall[authorize]: module "sql" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type PAP auth: type "PAP" Processing the authenticate section of radiusd.conf modcall: entering group PAP for request 0 rlm_pap: login attempt with password test rlm_pap: Using clear text password. rlm_pap: User authenticated succesfully modcall[authenticate]: module "pap" returns ok for request 0 modcall: leaving group PAP (returns ok) for request 0 Processing the session section of radiusd.conf modcall: entering group session for request 0 ....................................................................... modcall[post-auth]: module "sql" returns ok for request 0 modcall: leaving group post-auth (returns ok) for request 0 Sending Access-Accept of id 48 to 192.168.98.100 port 1030 Reply-Message = "`Reply-Message += You are already logged in\n`" Framed-Compression = Van-Jacobson-TCP-IP ......................................................................... I DO SEE the VALUE of ATTRIBUTE "Reply-Message" It is the OUTPUT of radiusd -X for exit 1 rad_recv: Access-Request packet from host 192.168.98.100 port 1030, id=58, lengt h=58 User-Name = "morgan" User-Password = "test" NAS-IP-Address = 213.NNN.12.17 Framed-Protocol = PPP Processing the authorize section of radiusd.conf modcall: entering group authorize for request 2 modcall[authorize]: module "preprocess" returns ok for request 2 modcall[authorize]: module "chap" returns noop for request 2 rlm_realm: No '@' in User-Name = "morgan", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 2 users: Matched entry DEFAULT at line 1 radius_xlat: Running registered xlat function of module echo for string '/usr/lo cal/etc/raddb/radius.auth' rlm_exec (echo): Executing /usr/local/etc/raddb/radius.auth Exec-Program output: Reply-Message += You are already logged in Exec-Program-Wait: plaintext: Reply-Message += You are already logged in Exec-Program: returned: 1 rlm_exec (echo): result 1 radius_xlat: '``' modcall[authorize]: module "files" returns ok for request 2 Exec-Program output: Reply-Message += You are already logged in Exec-Program-Wait: plaintext: Reply-Message += You are already logged in Exec-Program: returned: 1 modcall[authorize]: module "echo" returns reject for request 2 modcall: leaving group authorize (returns reject) for request 2 Invalid user: [morgan/test] (from client apus_old port 0) Delaying request 2 for 1 seconds Finished request 2 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 58 to 192.168.98.100 port 1030 Reply-Message = "``" Waking up in 4 seconds... I DO NOT SEE the VALUE of ATTRIBUTE "Reply-Message" WHERE IS MY MISTAKE(S). THANKS.

1 0

AW: Allowing any NAS to connect to my radiusd.
by Marc.Werner＠t-systems.com 15 Jul '05

15 Jul '05

>From the security point of it would be easier to launch some type of non-repudiation attacks without the need of spoofing I think. The shared secret can easily be recovered by sniffing some RADIUS traffic and decrypting it. I think this is even mentioned in the RFC. So removing one lock and only leaving an unsecure lock isn't a good idea I think... Rgds Marc -----Ursprüngliche Nachricht----- Von: freeradius-users-bounces(a)lists.freeradius.org [mailto:freeradius-users-bounces@lists.freeradius.org] Im Auftrag von Marcin Jessa Gesendet: Freitag, 15. Juli 2005 13:10 An: FreeRadius users mailing list Cc: Guy.Davies(a)telindus.co.uk Betreff: Re: Allowing any NAS to connect to my radiusd. On Fri, 15 Jul 2005 11:42:57 +0100 "Guy Davies" <Guy.Davies(a)telindus.co.uk> wrote: > Hi Marcin, > > You can create a subnet in clients.conf (e.g. 10.10.10.0/24) that can > use the same key. I think that doing 0.0.0.0/0 would be a very bad plan > since it only requires that an attacker know the shared key to be able > to send valid requests. Since all your devices are matched by a single > entry then *all* your devices by definition must use the same key Good point, they'd need the same key. >and it > becomes more likely that the knowledge of that key will "get out" and > you'll have the tedious task (if you even notice) of changing the secret > key on every single NAS. > > If you can constrain it to a small subnet, then that's slightly better > (although still somewhat risky). > > The best method is to have individual clients listed with *unique* keys > per client (yes, I know this is a real pain but if you want security > this is about the best you can do with the limited security afforded by > the shared key). I know how things work, I was just wondering about the approach since that would make some things easier for me. What other risks does one run when others to query your radiusd ? I dont think dictionary checks are that useful since passwords and username are all pretty long and use special characters. Could this have a more serious impact on the server like DOS or such ? > Rgds, > > Guy > > > -----Original Message----- > > From: freeradius-users-bounces(a)lists.freeradius.org > > [mailto:freeradius-users-bounces@lists.freeradius.org] On > > Behalf Of Marcin Jessa > > Sent: 15 July 2005 11:29 > > To: FreeRadius > > Subject: Allowing any NAS to connect to my radiusd. > > > > > > Hi. > > > > I would like to allow any NAS IP to connect to my radius > > server restricting connections from NAS only with shared > > secret - username and password. Is it possible to use 0.0.0.0 > > or ANY in clients.conf/SQL nas table ? What are the security > > issues having an open setup like that ? > > > > Cheers > > Marcin Jessa. > > - > > List info/subscribe/unsubscribe? See > > http://www.freeradius.org/list/users.html > > > > This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavours to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us. > > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

1 0

RE: Allowing any NAS to connect to my radiusd.
by Guy Davies 15 Jul '05

15 Jul '05

> > The best method is to have individual clients listed with *unique* > > keys per client (yes, I know this is a real pain but if you want > > security this is about the best you can do with the limited > security > > afforded by the shared key). > > I know how things work, I was just wondering about the > approach since that would make some things easier for me. > What other risks does one run when others to query your > radiusd ? I dont think dictionary checks are that useful > since passwords and username are all pretty long and use > special characters. Could this have a more serious impact on > the server like DOS or such ? Yes, I believe it would make DoS easier. Since a server can reject *any* request that comes from an "unknown" client, so long as the server can run the authentication check (calculate an MD5 hash) quickly enough, then a DoS will be less effective. If the calculation of an MD5 hash reveals an "authenticated" client, then the server must allocate resource to actually carry out the requested action. If sufficient requests are targetted at your server, it will have no resource to handle valid requests. The secret key per client is far from ideal (see some of the discussions about the benefits of DIAMETER over the last few days) but opening up your server like this is very unwise. I'd also say that while you may have excellent username and password selection criteria, opening up your system like this would simply remove one extra hurdle an attacker would have to scale to start obtaining information on your network. Rgds, Guy This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavours to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

1 0

RE: Allowing any NAS to connect to my radiusd.
by Guy Davies 15 Jul '05

15 Jul '05

Hi Marcin, You can create a subnet in clients.conf (e.g. 10.10.10.0/24) that can use the same key. I think that doing 0.0.0.0/0 would be a very bad plan since it only requires that an attacker know the shared key to be able to send valid requests. Since all your devices are matched by a single entry then *all* your devices by definition must use the same key and it becomes more likely that the knowledge of that key will "get out" and you'll have the tedious task (if you even notice) of changing the secret key on every single NAS. If you can constrain it to a small subnet, then that's slightly better (although still somewhat risky). The best method is to have individual clients listed with *unique* keys per client (yes, I know this is a real pain but if you want security this is about the best you can do with the limited security afforded by the shared key). Rgds, Guy > -----Original Message----- > From: freeradius-users-bounces(a)lists.freeradius.org > [mailto:freeradius-users-bounces@lists.freeradius.org] On > Behalf Of Marcin Jessa > Sent: 15 July 2005 11:29 > To: FreeRadius > Subject: Allowing any NAS to connect to my radiusd. > > > Hi. > > I would like to allow any NAS IP to connect to my radius > server restricting connections from NAS only with shared > secret - username and password. Is it possible to use 0.0.0.0 > or ANY in clients.conf/SQL nas table ? What are the security > issues having an open setup like that ? > > Cheers > Marcin Jessa. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavours to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

2 1

Silly question - secure Radius?
by Shawn Kennedy 14 Jul '05

14 Jul '05

I am just getting started with setting up Radius, and with the reading I've done (mostly with the O'Reilly book), it seems that Radius in itself is insecure. Sure, you can use a Shared Secret and the password is sent with a MD5 hash, but is there anything better? Sorry for the dumb question, Shawn

6 18