From jnathan at salesforce.com Mon Mar 1 21:21:32 2010 From: jnathan at salesforce.com (Jon Nathan) Date: Mon, 1 Mar 2010 13:21:32 -0800 Subject: [tac_plus] PAP authentication in tac_plus F4.0.4.15 overrides ACL restictions Message-ID: Hello, We use tac_plus F4.0.4.15 to manage authentication for our network switches. Our Cisco MDS (San-OS/NX-OS) switches can only use PAP or MSCHAP to authenticate, so we were able to accommodate this by adding pap lines to each user who required access to these switches as follows: user = jon { login = PAM pap = des xxx/jE member = saneng } We wanted to restrict some users to certain Cisco MDS switches, so we built an acl as follows: acl = backups_acl { permit = ^10.22(6|8).13.(20|21)$ permit = ^10.225.10.(98|99)$ permit = ^10.231.(10|11).18$ deny = .* } Where the IPs above correspond to the allowed switches. However, when we set a user to a group that used this acl as follows: user = jon { login = PAM pap = des xxx/jE member = saneng_backups } group = saneng_backups { default service = permit acl = backups_acl service = exec { priv-lvl = 15 cisco-av-pair = "shell:roles=network-admin vsan-admin" } } We were able to log into the explicitly permitted switches, and all other Cisco MDS switches that were not permitted. It looks like tac_plus accepts the pap authentication before trying to confirm against the ACL. Here are log snippets from -d 24: Logging into a host not permitted by the acl: Mon Mar 1 21:04:38 2010 [11255]: session.peerip is 10.228.13.17 Mon Mar 1 21:04:38 2010 [12259]: connect from 10.228.13.17 [10.228.13.17] Mon Mar 1 21:04:38 2010 [12259]: pap-login query for 'jon' 0 from 10.228.13.17 accepted Mon Mar 1 21:04:38 2010 [11255]: session.peerip is 10.228.13.17 Mon Mar 1 21:04:38 2010 [12263]: connect from 10.228.13.17 [10.228.13.17] Mon Mar 1 21:04:38 2010 [12263]: Start authorization request Mon Mar 1 21:04:38 2010 [12263]: cfg_acl_check(backups_acl, 10.228.13.17) Mon Mar 1 21:04:38 2010 [12263]: ip 10.228.13.17 matched deny regex .* of acl filter backups_acl Mon Mar 1 21:04:38 2010 [12263]: authorization query for 'jon' 0 from 10.228.13.17 rejected Logging into a a host permitted by the acl: Mon Mar 1 21:06:03 2010 [14200]: session.peerip is 10.228.13.17 Mon Mar 1 21:06:03 2010 [14202]: connect from 10.228.13.17 [10.228.13.17] Mon Mar 1 21:06:03 2010 [14202]: pap-login query for 'jon' 0 from 10.228.13.17 accepted Mon Mar 1 21:06:03 2010 [14200]: session.peerip is 10.228.13.17 Mon Mar 1 21:06:03 2010 [14203]: connect from 10.228.13.17 [10.228.13.17] Mon Mar 1 21:06:03 2010 [14203]: Start authorization request Mon Mar 1 21:06:03 2010 [14203]: do_author: user='jon' Mon Mar 1 21:06:03 2010 [14203]: user 'jon' found Mon Mar 1 21:06:03 2010 [14203]: exec authorization request for jon Mon Mar 1 21:06:03 2010 [14203]: exec is explicitly permitted by line 290 Mon Mar 1 21:06:03 2010 [14203]: nas:service=shell (passed thru) Mon Mar 1 21:06:03 2010 [14203]: nas:cmd= (passed thru) Mon Mar 1 21:06:03 2010 [14203]: nas:cisco-av-pair* svr:cisco-av-pair=shell:roles=network-admin vsan-admin -> replace with cisco-av-pair=shell:roles=network-admin vsan-admin (f) Mon Mar 1 21:06:03 2010 [14203]: nas:shell:roles* svr:absent/deny -> delete shell:roles* (i) Mon Mar 1 21:06:03 2010 [14203]: nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k) Mon Mar 1 21:06:03 2010 [14203]: replaced 2 args Mon Mar 1 21:06:03 2010 [14203]: authorization query for 'jon' 0 from 10.228.13.17 accepted It looks like a bug in tac_plus. Tac_plus is accepting the user's login before confirming with the ACL that he is logging into a permitted host. What do you think? Thanks, Jon Nathan Salesforce.com From jathan at gmail.com Tue Mar 2 14:17:47 2010 From: jathan at gmail.com (jathan.) Date: Tue, 2 Mar 2010 06:17:47 -0800 Subject: [tac_plus] Re: PAP authentication in tac_plus F4.0.4.15 overrides ACL restictions In-Reply-To: References: Message-ID: <4e0e47491003020617p4193dd3et37fe5d12160deae0@mail.gmail.com> Hey Jon- >From what I know of using the ACL feature is that it is an authorization action (i.e. when exec is launched on the device), not authentication. So if you look a little closer it is performing properly by disallowing authorization to occur on the deny match. If I am wrong, please send all threats to /dev/null. On Mon, Mar 1, 2010 at 1:21 PM, Jon Nathan wrote: > Hello, > > We use tac_plus F4.0.4.15 to manage authentication for our network switches. > Our Cisco MDS (San-OS/NX-OS) switches can only use PAP or MSCHAP to > authenticate, so we were able to accommodate this by adding pap lines to > each user who required access to these switches as follows: > > user = jon { > ? ? ? ?login = PAM > ? ? ? ?pap = des xxx/jE > ? ? ? ?member = saneng > } > > We wanted to restrict some users to certain Cisco MDS switches, so we built > an acl as follows: > > acl = backups_acl { > ? ? ? ?permit = ^10.22(6|8).13.(20|21)$ > ? ? ? ?permit = ^10.225.10.(98|99)$ > ? ? ? ?permit = ^10.231.(10|11).18$ > ? ? ? ?deny = .* > } > > Where the IPs above correspond to the allowed switches. ?However, when we > set a user to a group that used this acl as follows: > > user = jon { > ? ? ? ?login = PAM > ? ? ? ?pap = des xxx/jE > ? ? ? ?member = saneng_backups > } > > group = saneng_backups { > ? ? ? ?default service = permit > ? ? ? ?acl = backups_acl > ? ? ? ?service = exec { > ? ? ? ? ? ? ? ?priv-lvl = 15 > ? ? ? ? ? ? ? ?cisco-av-pair = "shell:roles=network-admin vsan-admin" > ? ? ? ?} > } > > We were able to log into the explicitly permitted switches, and all other > Cisco MDS switches that were not permitted. ?It looks like tac_plus accepts > the pap authentication before trying to confirm against the ACL. ?Here are > log snippets from -d 24: > > Logging into a host not permitted by the acl: > > > Mon Mar ?1 21:04:38 2010 [11255]: session.peerip is 10.228.13.17 > Mon Mar ?1 21:04:38 2010 [12259]: connect from 10.228.13.17 [10.228.13.17] > Mon Mar ?1 21:04:38 2010 [12259]: pap-login query for 'jon' 0 from > 10.228.13.17 accepted > Mon Mar ?1 21:04:38 2010 [11255]: session.peerip is 10.228.13.17 > Mon Mar ?1 21:04:38 2010 [12263]: connect from 10.228.13.17 [10.228.13.17] > Mon Mar ?1 21:04:38 2010 [12263]: Start authorization request > Mon Mar ?1 21:04:38 2010 [12263]: cfg_acl_check(backups_acl, 10.228.13.17) > Mon Mar ?1 21:04:38 2010 [12263]: ip 10.228.13.17 matched deny regex .* of > acl filter backups_acl > Mon Mar ?1 21:04:38 2010 [12263]: authorization query for 'jon' 0 from > 10.228.13.17 rejected > > Logging into a a host permitted by the acl: > > Mon Mar ?1 21:06:03 2010 [14200]: session.peerip is 10.228.13.17 > Mon Mar ?1 21:06:03 2010 [14202]: connect from 10.228.13.17 [10.228.13.17] > Mon Mar ?1 21:06:03 2010 [14202]: pap-login query for 'jon' 0 from > 10.228.13.17 accepted > Mon Mar ?1 21:06:03 2010 [14200]: session.peerip is 10.228.13.17 > Mon Mar ?1 21:06:03 2010 [14203]: connect from 10.228.13.17 [10.228.13.17] > Mon Mar ?1 21:06:03 2010 [14203]: Start authorization request > Mon Mar ?1 21:06:03 2010 [14203]: do_author: user='jon' > Mon Mar ?1 21:06:03 2010 [14203]: user 'jon' found > Mon Mar ?1 21:06:03 2010 [14203]: exec authorization request for jon > Mon Mar ?1 21:06:03 2010 [14203]: exec is explicitly permitted by line 290 > Mon Mar ?1 21:06:03 2010 [14203]: nas:service=shell (passed thru) > Mon Mar ?1 21:06:03 2010 [14203]: nas:cmd= (passed thru) > Mon Mar ?1 21:06:03 2010 [14203]: nas:cisco-av-pair* > svr:cisco-av-pair=shell:roles=network-admin vsan-admin -> replace with > cisco-av-pair=shell:roles=network-admin vsan-admin (f) > Mon Mar ?1 21:06:03 2010 [14203]: nas:shell:roles* svr:absent/deny -> delete > shell:roles* (i) > Mon Mar ?1 21:06:03 2010 [14203]: nas:absent, server:priv-lvl=15 -> add > priv-lvl=15 (k) > Mon Mar ?1 21:06:03 2010 [14203]: replaced 2 args > Mon Mar ?1 21:06:03 2010 [14203]: authorization query for 'jon' 0 from > 10.228.13.17 accepted > > > It looks like a bug in tac_plus. ?Tac_plus is accepting the user's login > before confirming with the ACL that he is logging into a permitted host. > What do you think? > > Thanks, > Jon Nathan > Salesforce.com > > > > > > > > > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > -- Jathan. - From jnathan at salesforce.com Tue Mar 2 14:52:59 2010 From: jnathan at salesforce.com (Jon Nathan) Date: Tue, 2 Mar 2010 06:52:59 -0800 Subject: [tac_plus] Re: PAP authentication in tac_plus F4.0.4.15 overrides ACL restictions In-Reply-To: <4e0e47491003020617p4193dd3et37fe5d12160deae0@mail.gmail.com> Message-ID: Thanks Jathan. Is there any way then to do ACLs or something similar for authorization? Or something more clever I could do in my group definition that would prevent them from doing anything after they logged in to a denied host? -Jon On 3/2/10 9:17 AM, "jathan." wrote: > Hey Jon- > > From what I know of using the ACL feature is that it is an > authorization action (i.e. when exec is launched on the device), not > authentication. So if you look a little closer it is performing > properly by disallowing authorization to occur on the deny match. > > If I am wrong, please send all threats to /dev/null. > > On Mon, Mar 1, 2010 at 1:21 PM, Jon Nathan wrote: >> Hello, >> >> We use tac_plus F4.0.4.15 to manage authentication for our network switches. >> Our Cisco MDS (San-OS/NX-OS) switches can only use PAP or MSCHAP to >> authenticate, so we were able to accommodate this by adding pap lines to >> each user who required access to these switches as follows: >> >> user = jon { >> ? ? ? ?login = PAM >> ? ? ? ?pap = des xxx/jE >> ? ? ? ?member = saneng >> } >> >> We wanted to restrict some users to certain Cisco MDS switches, so we built >> an acl as follows: >> >> acl = backups_acl { >> ? ? ? ?permit = ^10.22(6|8).13.(20|21)$ >> ? ? ? ?permit = ^10.225.10.(98|99)$ >> ? ? ? ?permit = ^10.231.(10|11).18$ >> ? ? ? ?deny = .* >> } >> >> Where the IPs above correspond to the allowed switches. ?However, when we >> set a user to a group that used this acl as follows: >> >> user = jon { >> ? ? ? ?login = PAM >> ? ? ? ?pap = des xxx/jE >> ? ? ? ?member = saneng_backups >> } >> >> group = saneng_backups { >> ? ? ? ?default service = permit >> ? ? ? ?acl = backups_acl >> ? ? ? ?service = exec { >> ? ? ? ? ? ? ? ?priv-lvl = 15 >> ? ? ? ? ? ? ? ?cisco-av-pair = "shell:roles=network-admin vsan-admin" >> ? ? ? ?} >> } >> >> We were able to log into the explicitly permitted switches, and all other >> Cisco MDS switches that were not permitted. ?It looks like tac_plus accepts >> the pap authentication before trying to confirm against the ACL. ?Here are >> log snippets from -d 24: >> >> Logging into a host not permitted by the acl: >> >> >> Mon Mar ?1 21:04:38 2010 [11255]: session.peerip is 10.228.13.17 >> Mon Mar ?1 21:04:38 2010 [12259]: connect from 10.228.13.17 [10.228.13.17] >> Mon Mar ?1 21:04:38 2010 [12259]: pap-login query for 'jon' 0 from >> 10.228.13.17 accepted >> Mon Mar ?1 21:04:38 2010 [11255]: session.peerip is 10.228.13.17 >> Mon Mar ?1 21:04:38 2010 [12263]: connect from 10.228.13.17 [10.228.13.17] >> Mon Mar ?1 21:04:38 2010 [12263]: Start authorization request >> Mon Mar ?1 21:04:38 2010 [12263]: cfg_acl_check(backups_acl, 10.228.13.17) >> Mon Mar ?1 21:04:38 2010 [12263]: ip 10.228.13.17 matched deny regex .* of >> acl filter backups_acl >> Mon Mar ?1 21:04:38 2010 [12263]: authorization query for 'jon' 0 from >> 10.228.13.17 rejected >> >> Logging into a a host permitted by the acl: >> >> Mon Mar ?1 21:06:03 2010 [14200]: session.peerip is 10.228.13.17 >> Mon Mar ?1 21:06:03 2010 [14202]: connect from 10.228.13.17 [10.228.13.17] >> Mon Mar ?1 21:06:03 2010 [14202]: pap-login query for 'jon' 0 from >> 10.228.13.17 accepted >> Mon Mar ?1 21:06:03 2010 [14200]: session.peerip is 10.228.13.17 >> Mon Mar ?1 21:06:03 2010 [14203]: connect from 10.228.13.17 [10.228.13.17] >> Mon Mar ?1 21:06:03 2010 [14203]: Start authorization request >> Mon Mar ?1 21:06:03 2010 [14203]: do_author: user='jon' >> Mon Mar ?1 21:06:03 2010 [14203]: user 'jon' found >> Mon Mar ?1 21:06:03 2010 [14203]: exec authorization request for jon >> Mon Mar ?1 21:06:03 2010 [14203]: exec is explicitly permitted by line 290 >> Mon Mar ?1 21:06:03 2010 [14203]: nas:service=shell (passed thru) >> Mon Mar ?1 21:06:03 2010 [14203]: nas:cmd= (passed thru) >> Mon Mar ?1 21:06:03 2010 [14203]: nas:cisco-av-pair* >> svr:cisco-av-pair=shell:roles=network-admin vsan-admin -> replace with >> cisco-av-pair=shell:roles=network-admin vsan-admin (f) >> Mon Mar ?1 21:06:03 2010 [14203]: nas:shell:roles* svr:absent/deny -> delete >> shell:roles* (i) >> Mon Mar ?1 21:06:03 2010 [14203]: nas:absent, server:priv-lvl=15 -> add >> priv-lvl=15 (k) >> Mon Mar ?1 21:06:03 2010 [14203]: replaced 2 args >> Mon Mar ?1 21:06:03 2010 [14203]: authorization query for 'jon' 0 from >> 10.228.13.17 accepted >> >> >> It looks like a bug in tac_plus. ?Tac_plus is accepting the user's login >> before confirming with the ACL that he is logging into a permitted host. >> What do you think? >> >> Thanks, >> Jon Nathan >> Salesforce.com >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> tac_plus mailing list >> tac_plus at shrubbery.net >> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus >> > > > > -- > Jathan. > - From heas at shrubbery.net Thu Mar 4 16:41:59 2010 From: heas at shrubbery.net (john heasley) Date: Thu, 4 Mar 2010 08:41:59 -0800 Subject: [tac_plus] Re: PAP authentication in tac_plus F4.0.4.15 overrides ACL restictions In-Reply-To: References: <20100304164107.32D68108695@guelah.shrubbery.net> <4e0e47491003020617p4193dd3et37fe5d12160deae0@mail.gmail.com> Message-ID: <20100304164159.GB15548@shrubbery.net> Tue, Mar 02, 2010 at 06:52:59AM -0800, Jon Nathan: > Thanks Jathan. Is there any way then to do ACLs or something similar for > authorization? Or something more clever I could do in my group definition > that would prevent them from doing anything after they logged in to a denied > host? please try the patch below. > -Jon > > > On 3/2/10 9:17 AM, "jathan." wrote: > > > Hey Jon- > > > > From what I know of using the ACL feature is that it is an > > authorization action (i.e. when exec is launched on the device), not > > authentication. So if you look a little closer it is performing > > properly by disallowing authorization to occur on the deny match. > > > > If I am wrong, please send all threats to /dev/null. > > > > On Mon, Mar 1, 2010 at 1:21 PM, Jon Nathan wrote: > >> Hello, > >> > >> We use tac_plus F4.0.4.15 to manage authentication for our network switches. > >> Our Cisco MDS (San-OS/NX-OS) switches can only use PAP or MSCHAP to > >> authenticate, so we were able to accommodate this by adding pap lines to > >> each user who required access to these switches as follows: > >> > >> user = jon { > >> ? ? ? ?login = PAM > >> ? ? ? ?pap = des xxx/jE > >> ? ? ? ?member = saneng > >> } > >> > >> We wanted to restrict some users to certain Cisco MDS switches, so we built > >> an acl as follows: > >> > >> acl = backups_acl { > >> ? ? ? ?permit = ^10.22(6|8).13.(20|21)$ > >> ? ? ? ?permit = ^10.225.10.(98|99)$ > >> ? ? ? ?permit = ^10.231.(10|11).18$ > >> ? ? ? ?deny = .* > >> } > >> > >> Where the IPs above correspond to the allowed switches. ?However, when we > >> set a user to a group that used this acl as follows: > >> > >> user = jon { > >> ? ? ? ?login = PAM > >> ? ? ? ?pap = des xxx/jE > >> ? ? ? ?member = saneng_backups > >> } > >> > >> group = saneng_backups { > >> ? ? ? ?default service = permit > >> ? ? ? ?acl = backups_acl > >> ? ? ? ?service = exec { > >> ? ? ? ? ? ? ? ?priv-lvl = 15 > >> ? ? ? ? ? ? ? ?cisco-av-pair = "shell:roles=network-admin vsan-admin" > >> ? ? ? ?} > >> } > >> > >> We were able to log into the explicitly permitted switches, and all other > >> Cisco MDS switches that were not permitted. ?It looks like tac_plus accepts > >> the pap authentication before trying to confirm against the ACL. ?Here are > >> log snippets from -d 24: > >> > >> Logging into a host not permitted by the acl: > >> > >> > >> Mon Mar ?1 21:04:38 2010 [11255]: session.peerip is 10.228.13.17 > >> Mon Mar ?1 21:04:38 2010 [12259]: connect from 10.228.13.17 [10.228.13.17] > >> Mon Mar ?1 21:04:38 2010 [12259]: pap-login query for 'jon' 0 from > >> 10.228.13.17 accepted > >> Mon Mar ?1 21:04:38 2010 [11255]: session.peerip is 10.228.13.17 > >> Mon Mar ?1 21:04:38 2010 [12263]: connect from 10.228.13.17 [10.228.13.17] > >> Mon Mar ?1 21:04:38 2010 [12263]: Start authorization request > >> Mon Mar ?1 21:04:38 2010 [12263]: cfg_acl_check(backups_acl, 10.228.13.17) > >> Mon Mar ?1 21:04:38 2010 [12263]: ip 10.228.13.17 matched deny regex .* of > >> acl filter backups_acl > >> Mon Mar ?1 21:04:38 2010 [12263]: authorization query for 'jon' 0 from > >> 10.228.13.17 rejected > >> > >> Logging into a a host permitted by the acl: > >> > >> Mon Mar ?1 21:06:03 2010 [14200]: session.peerip is 10.228.13.17 > >> Mon Mar ?1 21:06:03 2010 [14202]: connect from 10.228.13.17 [10.228.13.17] > >> Mon Mar ?1 21:06:03 2010 [14202]: pap-login query for 'jon' 0 from > >> 10.228.13.17 accepted > >> Mon Mar ?1 21:06:03 2010 [14200]: session.peerip is 10.228.13.17 > >> Mon Mar ?1 21:06:03 2010 [14203]: connect from 10.228.13.17 [10.228.13.17] > >> Mon Mar ?1 21:06:03 2010 [14203]: Start authorization request > >> Mon Mar ?1 21:06:03 2010 [14203]: do_author: user='jon' > >> Mon Mar ?1 21:06:03 2010 [14203]: user 'jon' found > >> Mon Mar ?1 21:06:03 2010 [14203]: exec authorization request for jon > >> Mon Mar ?1 21:06:03 2010 [14203]: exec is explicitly permitted by line 290 > >> Mon Mar ?1 21:06:03 2010 [14203]: nas:service=shell (passed thru) > >> Mon Mar ?1 21:06:03 2010 [14203]: nas:cmd= (passed thru) > >> Mon Mar ?1 21:06:03 2010 [14203]: nas:cisco-av-pair* > >> svr:cisco-av-pair=shell:roles=network-admin vsan-admin -> replace with > >> cisco-av-pair=shell:roles=network-admin vsan-admin (f) > >> Mon Mar ?1 21:06:03 2010 [14203]: nas:shell:roles* svr:absent/deny -> delete > >> shell:roles* (i) > >> Mon Mar ?1 21:06:03 2010 [14203]: nas:absent, server:priv-lvl=15 -> add > >> priv-lvl=15 (k) > >> Mon Mar ?1 21:06:03 2010 [14203]: replaced 2 args > >> Mon Mar ?1 21:06:03 2010 [14203]: authorization query for 'jon' 0 from > >> 10.228.13.17 accepted > >> > >> > >> It looks like a bug in tac_plus. ?Tac_plus is accepting the user's login > >> before confirming with the ACL that he is logging into a permitted host. > >> What do you think? > >> > >> Thanks, > >> Jon Nathan > >> Salesforce.com > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> tac_plus mailing list > >> tac_plus at shrubbery.net > >> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > >> > > > > > > > > -- > > Jathan. > > - > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus Index: default_fn.c =================================================================== --- default_fn.c (revision 3276) +++ default_fn.c (working copy) @@ -327,7 +327,12 @@ /* Assume the worst */ data->status = TAC_PLUS_AUTHEN_STATUS_FAIL; verify(name, passwd, data, TAC_PLUS_RECURSE); +#ifdef ACLS + if (verify_host(name, data, S_acl, TAC_PLUS_RECURSE) != S_permit) + data->status = TAC_PLUS_AUTHEN_STATUS_FAIL; +#endif free(passwd); + return; } /* Verify the challenge and id against the response by looking up the @@ -419,8 +424,14 @@ data->status = TAC_PLUS_AUTHEN_STATUS_PASS; } +#ifdef ACLS + if (verify_host(name, data, S_acl, TAC_PLUS_RECURSE) != S_permit) + data->status = TAC_PLUS_AUTHEN_STATUS_FAIL; +#endif + exp_date = cfg_get_expires(name, TAC_PLUS_RECURSE); set_expiration_status(exp_date, data); + return; } /* @@ -528,8 +539,14 @@ data->server_dlen = 8; memcpy(data->server_data, r_chal, 8); +#ifdef ACLS + if (verify_host(name, data, S_acl, TAC_PLUS_RECURSE) != S_permit) + data->status = TAC_PLUS_AUTHEN_STATUS_FAIL; +#endif + exp_date = cfg_get_expires(name, TAC_PLUS_RECURSE); set_expiration_status(exp_date, data); + return; } #ifdef MSCHAP @@ -777,8 +794,14 @@ data->status = TAC_PLUS_AUTHEN_STATUS_PASS; } +#ifdef ACLS + if (verify_host(name, data, S_acl, TAC_PLUS_RECURSE) != S_permit) + data->status = TAC_PLUS_AUTHEN_STATUS_FAIL; +#endif + exp_date = cfg_get_expires(name, TAC_PLUS_RECURSE); set_expiration_status(exp_date, data); + return; } #endif /* MSCHAP */ From jnathan at salesforce.com Thu Mar 4 22:27:05 2010 From: jnathan at salesforce.com (Jon Nathan) Date: Thu, 4 Mar 2010 14:27:05 -0800 Subject: [tac_plus] Re: PAP authentication in tac_plus F4.0.4.15 overrides ACL restictions In-Reply-To: <20100304164159.GB15548@shrubbery.net> Message-ID: Thanks John, that patch works perfectly! Do you think you'll include it in a new release, or should I just use 4.0.4.19+acl_patch? -Jon On 3/4/10 11:41 AM, "john heasley" wrote: > Tue, Mar 02, 2010 at 06:52:59AM -0800, Jon Nathan: >> Thanks Jathan. Is there any way then to do ACLs or something similar for >> authorization? Or something more clever I could do in my group definition >> that would prevent them from doing anything after they logged in to a denied >> host? > > please try the patch below. > >> -Jon >> >> >> On 3/2/10 9:17 AM, "jathan." wrote: >> >>> Hey Jon- >>> >>> From what I know of using the ACL feature is that it is an >>> authorization action (i.e. when exec is launched on the device), not >>> authentication. So if you look a little closer it is performing >>> properly by disallowing authorization to occur on the deny match. >>> >>> If I am wrong, please send all threats to /dev/null. >>> >>> On Mon, Mar 1, 2010 at 1:21 PM, Jon Nathan wrote: >>>> Hello, >>>> >>>> We use tac_plus F4.0.4.15 to manage authentication for our network >>>> switches. >>>> Our Cisco MDS (San-OS/NX-OS) switches can only use PAP or MSCHAP to >>>> authenticate, so we were able to accommodate this by adding pap lines to >>>> each user who required access to these switches as follows: >>>> >>>> user = jon { >>>> ? ? ? ?login = PAM >>>> ? ? ? ?pap = des xxx/jE >>>> ? ? ? ?member = saneng >>>> } >>>> >>>> We wanted to restrict some users to certain Cisco MDS switches, so we built >>>> an acl as follows: >>>> >>>> acl = backups_acl { >>>> ? ? ? ?permit = ^10.22(6|8).13.(20|21)$ >>>> ? ? ? ?permit = ^10.225.10.(98|99)$ >>>> ? ? ? ?permit = ^10.231.(10|11).18$ >>>> ? ? ? ?deny = .* >>>> } >>>> >>>> Where the IPs above correspond to the allowed switches. ?However, when we >>>> set a user to a group that used this acl as follows: >>>> >>>> user = jon { >>>> ? ? ? ?login = PAM >>>> ? ? ? ?pap = des xxx/jE >>>> ? ? ? ?member = saneng_backups >>>> } >>>> >>>> group = saneng_backups { >>>> ? ? ? ?default service = permit >>>> ? ? ? ?acl = backups_acl >>>> ? ? ? ?service = exec { >>>> ? ? ? ? ? ? ? ?priv-lvl = 15 >>>> ? ? ? ? ? ? ? ?cisco-av-pair = "shell:roles=network-admin vsan-admin" >>>> ? ? ? ?} >>>> } >>>> >>>> We were able to log into the explicitly permitted switches, and all other >>>> Cisco MDS switches that were not permitted. ?It looks like tac_plus accepts >>>> the pap authentication before trying to confirm against the ACL. ?Here are >>>> log snippets from -d 24: >>>> >>>> Logging into a host not permitted by the acl: >>>> >>>> >>>> Mon Mar ?1 21:04:38 2010 [11255]: session.peerip is 10.228.13.17 >>>> Mon Mar ?1 21:04:38 2010 [12259]: connect from 10.228.13.17 [10.228.13.17] >>>> Mon Mar ?1 21:04:38 2010 [12259]: pap-login query for 'jon' 0 from >>>> 10.228.13.17 accepted >>>> Mon Mar ?1 21:04:38 2010 [11255]: session.peerip is 10.228.13.17 >>>> Mon Mar ?1 21:04:38 2010 [12263]: connect from 10.228.13.17 [10.228.13.17] >>>> Mon Mar ?1 21:04:38 2010 [12263]: Start authorization request >>>> Mon Mar ?1 21:04:38 2010 [12263]: cfg_acl_check(backups_acl, 10.228.13.17) >>>> Mon Mar ?1 21:04:38 2010 [12263]: ip 10.228.13.17 matched deny regex .* of >>>> acl filter backups_acl >>>> Mon Mar ?1 21:04:38 2010 [12263]: authorization query for 'jon' 0 from >>>> 10.228.13.17 rejected >>>> >>>> Logging into a a host permitted by the acl: >>>> >>>> Mon Mar ?1 21:06:03 2010 [14200]: session.peerip is 10.228.13.17 >>>> Mon Mar ?1 21:06:03 2010 [14202]: connect from 10.228.13.17 [10.228.13.17] >>>> Mon Mar ?1 21:06:03 2010 [14202]: pap-login query for 'jon' 0 from >>>> 10.228.13.17 accepted >>>> Mon Mar ?1 21:06:03 2010 [14200]: session.peerip is 10.228.13.17 >>>> Mon Mar ?1 21:06:03 2010 [14203]: connect from 10.228.13.17 [10.228.13.17] >>>> Mon Mar ?1 21:06:03 2010 [14203]: Start authorization request >>>> Mon Mar ?1 21:06:03 2010 [14203]: do_author: user='jon' >>>> Mon Mar ?1 21:06:03 2010 [14203]: user 'jon' found >>>> Mon Mar ?1 21:06:03 2010 [14203]: exec authorization request for jon >>>> Mon Mar ?1 21:06:03 2010 [14203]: exec is explicitly permitted by line 290 >>>> Mon Mar ?1 21:06:03 2010 [14203]: nas:service=shell (passed thru) >>>> Mon Mar ?1 21:06:03 2010 [14203]: nas:cmd= (passed thru) >>>> Mon Mar ?1 21:06:03 2010 [14203]: nas:cisco-av-pair* >>>> svr:cisco-av-pair=shell:roles=network-admin vsan-admin -> replace with >>>> cisco-av-pair=shell:roles=network-admin vsan-admin (f) >>>> Mon Mar ?1 21:06:03 2010 [14203]: nas:shell:roles* svr:absent/deny -> >>>> delete >>>> shell:roles* (i) >>>> Mon Mar ?1 21:06:03 2010 [14203]: nas:absent, server:priv-lvl=15 -> add >>>> priv-lvl=15 (k) >>>> Mon Mar ?1 21:06:03 2010 [14203]: replaced 2 args >>>> Mon Mar ?1 21:06:03 2010 [14203]: authorization query for 'jon' 0 from >>>> 10.228.13.17 accepted >>>> >>>> >>>> It looks like a bug in tac_plus. ?Tac_plus is accepting the user's login >>>> before confirming with the ACL that he is logging into a permitted host. >>>> What do you think? >>>> >>>> Thanks, >>>> Jon Nathan >>>> Salesforce.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> tac_plus mailing list >>>> tac_plus at shrubbery.net >>>> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus >>>> >>> >>> >>> >>> -- >>> Jathan. >>> - >> >> _______________________________________________ >> tac_plus mailing list >> tac_plus at shrubbery.net >> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > > > Index: default_fn.c > =================================================================== > --- default_fn.c (revision 3276) > +++ default_fn.c (working copy) > @@ -327,7 +327,12 @@ > /* Assume the worst */ > data->status = TAC_PLUS_AUTHEN_STATUS_FAIL; > verify(name, passwd, data, TAC_PLUS_RECURSE); > +#ifdef ACLS > + if (verify_host(name, data, S_acl, TAC_PLUS_RECURSE) != S_permit) > + data->status = TAC_PLUS_AUTHEN_STATUS_FAIL; > +#endif > free(passwd); > + return; > } > > /* Verify the challenge and id against the response by looking up the > @@ -419,8 +424,14 @@ > data->status = TAC_PLUS_AUTHEN_STATUS_PASS; > } > > +#ifdef ACLS > + if (verify_host(name, data, S_acl, TAC_PLUS_RECURSE) != S_permit) > + data->status = TAC_PLUS_AUTHEN_STATUS_FAIL; > +#endif > + > exp_date = cfg_get_expires(name, TAC_PLUS_RECURSE); > set_expiration_status(exp_date, data); > + return; > } > > /* > @@ -528,8 +539,14 @@ > data->server_dlen = 8; > memcpy(data->server_data, r_chal, 8); > > +#ifdef ACLS > + if (verify_host(name, data, S_acl, TAC_PLUS_RECURSE) != S_permit) > + data->status = TAC_PLUS_AUTHEN_STATUS_FAIL; > +#endif > + > exp_date = cfg_get_expires(name, TAC_PLUS_RECURSE); > set_expiration_status(exp_date, data); > + return; > } > > #ifdef MSCHAP > @@ -777,8 +794,14 @@ > data->status = TAC_PLUS_AUTHEN_STATUS_PASS; > } > > +#ifdef ACLS > + if (verify_host(name, data, S_acl, TAC_PLUS_RECURSE) != S_permit) > + data->status = TAC_PLUS_AUTHEN_STATUS_FAIL; > +#endif > + > exp_date = cfg_get_expires(name, TAC_PLUS_RECURSE); > set_expiration_status(exp_date, data); > + return; > } > #endif /* MSCHAP */ > > From heas at shrubbery.net Fri Mar 5 17:00:26 2010 From: heas at shrubbery.net (john heasley) Date: Fri, 5 Mar 2010 09:00:26 -0800 Subject: [tac_plus] Re: PAP authentication in tac_plus F4.0.4.15 overrides ACL restictions In-Reply-To: References: <20100304164159.GB15548@shrubbery.net> Message-ID: <20100305170026.GF27361@shrubbery.net> Thu, Mar 04, 2010 at 02:27:05PM -0800, Jon Nathan: > Thanks John, that patch works perfectly! Do you think you'll include it in > a new release, or should I just use 4.0.4.19+acl_patch? I've committed it, but not sure when i'll cut the next version. From Moshe.Ben-Eliezer at audiocodes.com Mon Mar 8 08:19:17 2010 From: Moshe.Ben-Eliezer at audiocodes.com (Moshe Ben-Eliezer) Date: Mon, 8 Mar 2010 10:19:17 +0200 Subject: [tac_plus] Got error while running Tacacs Server Message-ID: <0F48D07C2D546043B558F069599F53ED0CD86A857F@ACLMAIL01.corp.audiocodes.com> Hi, I`m getting an error while running the Tacacs server. It happens always when "cmd-args" size is 19. 26 [sig] tac_plus 5268 C:\Documents and Settings\moshe\Desktop\Tacacs\tacacs\tac_plus.exe: *** fatal error - called with threadlist_ix -1 Please help BR, Moshe Ben Eliezer. ________________________________ This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20100308/a2e17d44/attachment.html From heas at shrubbery.net Mon Mar 8 19:56:12 2010 From: heas at shrubbery.net (john heasley) Date: Mon, 8 Mar 2010 11:56:12 -0800 Subject: [tac_plus] Re: Got error while running Tacacs Server In-Reply-To: <0F48D07C2D546043B558F069599F53ED0CD86A857F@ACLMAIL01.corp.audiocodes.com> References: <0F48D07C2D546043B558F069599F53ED0CD86A857F@ACLMAIL01.corp.audiocodes.com> Message-ID: <20100308195612.GS19278@shrubbery.net> Mon, Mar 08, 2010 at 10:19:17AM +0200, Moshe Ben-Eliezer: > Hi, > > I`m getting an error while running the Tacacs server. > It happens always when "cmd-args" size is 19. > > 26 [sig] tac_plus 5268 C:\Documents and Settings\moshe\Desktop\Tacacs\tacacs\tac_plus.exe: *** fatal error - called with threadlist_ix -1 > I can't support Windows and there likely is no one on the mail list who uses tacacs on Windows. "cmd-args" appears no where in the code and I have no idea what signal 26 is on Windows (on BSD its an VT alarm); maybe the command-line is too long for Windows? thats all i can suggest. From joe.moore at holidaycompanies.com Tue Mar 16 15:10:13 2010 From: joe.moore at holidaycompanies.com (Joe Moore) Date: Tue, 16 Mar 2010 10:10:13 -0500 Subject: [tac_plus] Auth Fail Lockout Message-ID: I need to implement account lockout after multiple failed password attempts. I know this can lead to a DOS vulnerability for router admin accounts but I have no choice. Our PCI auditor is requiring this, and there's no arguing with him. I see that there was a patch for this from Mark Thomas against 4.0.4.15. Is there a patch for the latest (4.0.4.19)? I am running on FreeBSD 7.2. I tried to achieve this by authenticating against PAM with the pam_abl module but that module doesn't seem to work at this time and it may be an orphaned project and not actively supported. ...jgm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20100316/b6632c0a/attachment.html From mark.thomas at corp.aol.com Tue Mar 16 15:30:52 2010 From: mark.thomas at corp.aol.com (Mark Ellzey Thomas) Date: Tue, 16 Mar 2010 11:30:52 -0400 Subject: [tac_plus] Re: Auth Fail Lockout In-Reply-To: References: Message-ID: <20100316153052.GB2250@corp.aol.com> On Tue, Mar 16, 2010 at 10:10:13AM -0500, Joe Moore wrote: > I need to implement account lockout after multiple failed password > attempts. I know this can lead to a DOS vulnerability for router admin > accounts but I have no choice. Our PCI auditor is requiring this, and > there's no arguing with him. > > > > I see that there was a patch for this from Mark Thomas against 4.0.4.15. > Is there a patch for the latest (4.0.4.19)? > > > > I am running on FreeBSD 7.2. I tried to achieve this by authenticating > against PAM with the pam_abl module but that module doesn't seem to work > at this time and it may be an orphaned project and not actively > supported. > Yep, you can find the patch against F4.0.4.19 here: http://www.shrubbery.net/pipermail/tac_plus/2009-September/000508.html Email me directly if you need any assistance. From mark.thomas at corp.aol.com Tue Mar 16 15:41:15 2010 From: mark.thomas at corp.aol.com (Mark Ellzey Thomas) Date: Tue, 16 Mar 2010 11:41:15 -0400 Subject: [tac_plus] Re: Auth Fail Lockout In-Reply-To: <20100316153052.GB2250@corp.aol.com> References: <20100316153052.GB2250@corp.aol.com> Message-ID: <20100316154115.GC2250@corp.aol.com> On Tue, Mar 16, 2010 at 11:30:52AM -0400, Mark Ellzey Thomas wrote: > Yep, you can find the patch against F4.0.4.19 here: > > http://www.shrubbery.net/pipermail/tac_plus/2009-September/000508.html > > Email me directly if you need any assistance. Just as an FYI, I will continue posting patches here: http://github.com/ellzey/tac_plus_AFL/downloads From kissg at ssg.ki.iif.hu Thu Mar 25 12:28:18 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Thu, 25 Mar 2010 13:28:18 +0100 (CET) Subject: [tac_plus] Re: Different auth per device per user Message-ID: Dear Dan, On Wed Nov 4 21:22:12 UTC 2009 you wrote: > Were you ever able to fix the problems I found in that patch? Unfortunately then I missed your mail and I've just found it in the archive. http://www.shrubbery.net/pipermail/tac_plus/2009-November/000549.html So... What problems you found? Gabor From karen.durinyan at gmail.com Tue Mar 30 07:11:36 2010 From: karen.durinyan at gmail.com (Karen Durinyan) Date: Tue, 30 Mar 2010 12:11:36 +0500 Subject: [tac_plus] Multiple groups, multiple ACL-s Message-ID: <201003301211.36894.karen.durinyan@gmail.com> Hello Dear All, I have tried this patch but seems I cannot solve my problem with this patch also :( The problem is the following: userA can login on nasA but can issue only "show *" cmd userA can login on nasB but can issue only "ping *" cmd userA can login on nasC but can issue only "exit *" cmd It seems ACLs must be applied to cmd somehow but I do not know how. Is this possible with your patch? Is this possible with tac+ at all? Thanks. -- Bests, Karen From kissg at ssg.ki.iif.hu Tue Mar 30 18:47:55 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Tue, 30 Mar 2010 20:47:55 +0200 (CEST) Subject: [tac_plus] Re: Multiple groups, multiple ACL-s In-Reply-To: <201003301211.36894.karen.durinyan@gmail.com> References: <201003301211.36894.karen.durinyan@gmail.com> Message-ID: > The problem is the following: > > userA can login on nasA but can issue only "show *" cmd > userA can login on nasB but can issue only "ping *" cmd > userA can login on nasC but can issue only "exit *" cmd > > It seems ACLs must be applied to cmd somehow but I do not know how. > > Is this possible with your patch? Is this possible with tac+ at all? Do you think this? user = userA { member = nasA_show member = nasB_ping member = nasC_exit ... } group nasA_show { acl = acl_nasA member = cmd_show } acl = acl_nasA { permit = return = .* } group = cmd_show cmd = show { permit .* } } ... Details at http://www.shrubbery.net/pipermail/tac_plus/2007-August/000125.html Gabor From karen.durinyan at gmail.com Wed Mar 31 05:08:46 2010 From: karen.durinyan at gmail.com (Karen Durinyan) Date: Wed, 31 Mar 2010 10:08:46 +0500 Subject: [tac_plus] Re: Multiple groups, multiple ACL-s In-Reply-To: References: <201003301211.36894.karen.durinyan@gmail.com> Message-ID: <201003311008.46904.karen.durinyan@gmail.com> Hello Gabor, First of all thanks for your reply and for patch. I did mean and I did exactly what you say here. Here is my config. ... acl = net-staff-r { permit = ^10\.0\.127\.12$ return = .* } acl = net-staff-u { #If I have 100 of NAS can I use permit = ".*" here? permit = ^10\.0\.127\.1$ return = .* } ... group = net-staff-r { service = exec { priv-lvl = 15 } cmd = show { permit ip permit interface deny ".*" } cmd = exit { permit ".*" } } group = net-staff-u { service = exec { priv-lvl = 15 } cmd = show { permit ".*" } cmd = exit { permit ".*" } } group = net-staff-all-r { acl = net-staff-r member = net-staff-r } group = net-staff-all-u { acl = net-staff-u member = net-staff-u } ... user = karen { login = des member = net-staff-all-r member = net-staff-all-u name = "Karen Durinyan" } ... Result is the following: [karen at srv1 ~]$ ssh racc1 Password: racc1#show run Command authorization failed. racc1#show ip int br ... Loopback0 10.0.127.12 YES manual up up racc1# racc1#exit Connection to racc1 closed. [karen at srv1 ~]$ ssh edge1 Password: edge1#show run Command authorization failed. edge1#show ip int br ... Loopback0 10.0.127.1 YES NVRAM up up edge1#exit Connection to edge1 closed. [karen at srv1 ~]$ It seems ACL match, group match, racc1 working as expected but things are not correct with edge1. For edge1 I am expecting to be able to run any command with "show ..." as it is in group definition. Am I missing anything? Thanks in advance. -- Bests, Karen On Tuesday 30 March 2010 23:47:55 Kiss Gabor (Bitman) wrote: > > The problem is the following: > > > > userA can login on nasA but can issue only "show *" cmd > > userA can login on nasB but can issue only "ping *" cmd > > userA can login on nasC but can issue only "exit *" cmd > > > > It seems ACLs must be applied to cmd somehow but I do not know how. > > > > Is this possible with your patch? Is this possible with tac+ at all? > > Do you think this? > > > user = userA { > member = nasA_show > member = nasB_ping > member = nasC_exit > ... > } > > group nasA_show { > acl = acl_nasA > member = cmd_show > } > > acl = acl_nasA { > permit = > return = .* > } > > group = cmd_show > cmd = show { > permit .* > } > } > > ... > > Details at > http://www.shrubbery.net/pipermail/tac_plus/2007-August/000125.html > > Gabor From kissg at ssg.ki.iif.hu Wed Mar 31 14:17:27 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Wed, 31 Mar 2010 16:17:27 +0200 (CEST) Subject: [tac_plus] Re: Multiple groups, multiple ACL-s In-Reply-To: <201003311008.46904.karen.durinyan@gmail.com> References: <201003301211.36894.karen.durinyan@gmail.com> <201003311008.46904.karen.durinyan@gmail.com> Message-ID: > It seems ACL match, group match, racc1 working as expected but things are not > correct with edge1. For edge1 I am expecting to be able to run any command > with "show ..." as it is in group definition. Am I missing anything? At first sight I cannot figure out what is the problem. What can we see if you run tac_plus with "-d 128" options? BTW. Do you have config line ip tacacs source-interface Loopback0 in edge1? :-) [... after reading some docs ...] Manual writes: acl If compiled with acl support (--enable-acls), Access Control Lists can be defined to limit user's (or group's) login and/or enable access by daemon client IP address or hostname. Actually I don't remember if my patch extends this acl usability or not. If not (i.e. ACLs are effective at exec only) the behavior descibed by you is quite clear. Daemon does not care with ACL when authorizing commands so when searching "cmd = show ..." in the config tree its stops in group net-staff-r. Could you swap your two memberships then run the tests again? I the above theory is correct then both racc1 and edge1 will allow any "show" commands. Within two months I will port my patch to the current tac_plus version. Then I could think over extending ACL effect. Gabor From kissg at ssg.ki.iif.hu Wed Mar 31 14:22:11 2010 From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman)) Date: Wed, 31 Mar 2010 16:22:11 +0200 (CEST) Subject: [tac_plus] Re: Multiple groups, multiple ACL-s In-Reply-To: References: <201003301211.36894.karen.durinyan@gmail.com> <201003311008.46904.karen.durinyan@gmail.com> Message-ID: > Could you swap your two memberships then run the tests again? > I the above theory is correct then both racc1 and edge1 will > allow any "show" commands. Another test: what happens if you omit "return .*" lines from ACL-s? Gabor