From kissg at ssg.ki.iif.hu  Sat Sep  1 09:06:34 2007
From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman))
Date: Sat, 1 Sep 2007 11:06:34 +0200 (CEST)
Subject: [tac_plus] Re: Password Bug
Message-ID: <Pine.LNX.4.64.0709011103070.17951@bakacsin.ki.iif.hu>

> If I encrypt the word "password1" I can use just about any variation of
> password* and get in.  password, password1,password2, password45... they
> all will log me in.  That is a big security hole.   

This is not a bug but a fea^H^H^Hlimitation.
Only the first 8 chars of DES encrypted passwords are significant.

However it would be easy to add MD5 password
enryption... I think over it.

Gabor

From kissg at ssg.ki.iif.hu  Wed Sep  5 14:27:05 2007
From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman))
Date: Wed, 5 Sep 2007 16:27:05 +0200 (CEST)
Subject: [tac_plus]   Re: Password Bug
Message-ID: <Pine.LNX.4.64.0709051613370.23859@bakacsin.ki.iif.hu>

> > If I encrypt the word "password1" I can use just about any variation
> > of
> > password* and get in.  password, password1,password2, password45...
> > they
> > all will log me in.  That is a big security hole.   
> 
> This is not a bug but a fea^H^H^Hlimitation.
> Only the first 8 chars of DES encrypted passwords are significant.
> 
> However it would be easy to add MD5 password
> enryption... I think over it.

On Linux systems GNU libcrypt has crypt() function that
transparently handles MD5 encrypted paswords. So if your
tac_plus runs on a host with GNU libc/libcrypt you can write this:

user = harpo {
	login = des $1$F9FIvi0b$oLW5gsIQjQyYNUf4cp0Eb/
}

So you can use passwords of any length.

Gabor

From kissg at ssg.ki.iif.hu  Wed Sep  5 14:56:02 2007
From: kissg at ssg.ki.iif.hu (Kiss Gabor (Bitman))
Date: Wed, 5 Sep 2007 16:56:02 +0200 (CEST)
Subject: [tac_plus] Re: Password Bug
In-Reply-To: <Pine.LNX.4.64.0709051613370.23859@bakacsin.ki.iif.hu>
References: <Pine.LNX.4.64.0709051613370.23859@bakacsin.ki.iif.hu>
Message-ID: <Pine.LNX.4.64.0709051647060.23859@bakacsin.ki.iif.hu>

> On Linux systems GNU libcrypt has crypt() function that
> transparently handles MD5 encrypted paswords. So if your
> tac_plus runs on a host with GNU libc/libcrypt you can write this:
> 
> user = harpo {
> 	login = des $1$TEWuOxgm$eHFn1umfTovC0ukCYovBf1
> }
> 
> So you can use passwords of any length.

BTW. You can generate new passwords with mkpasswd:

$ mkpasswd --hash=md5 mysecret
$1$TEWuOxgm$eHFn1umfTovC0ukCYovBf1
$ 

Gabor

From crecker at viawest.net  Wed Sep  5 16:20:19 2007
From: crecker at viawest.net (Chris Recker)
Date: Wed, 5 Sep 2007 10:20:19 -0600
Subject: [tac_plus]  Patch for better pam_tally support
Message-ID: <28E403E7-F0B0-4C57-9845-4D4436CA2919@viawest.net>

I have a patch for better pam_tally support.  It calls the  
pam_acct_mgmt to reset the failed logins after a successful login.  I  
also added a return of Signon successful which I have a few RANCID  
scripts looking for.

--- pwlib.c     2006-12-13 09:42:57.000000000 -0700
+++ ../../tacacs+-F4.0.4.14/pwlib.c     2007-08-29 10:07:34.733845000  
-0600
@@ -71,8 +71,9 @@
             report(LOG_DEBUG, "Password has not expired %s",
                    exp_date ? exp_date : "<no expiry date set>");
         data->status = TAC_PLUS_AUTHEN_STATUS_PASS;
+       data->server_msg = tac_strdup("Signon successful.");
         return;
      case PW_EXPIRING:
         if (debug & DEBUG_PASSWD_FLAG)
@@ -590,8 +591,9 @@
      }
      switch((err = pam_authenticate(pamh, PAM_SILENT))) {
      case PAM_SUCCESS:
+       pam_acct_mgmt(pamh, PAM_SILENT);
         pam_end(pamh, err);
         if (debug & DEBUG_PASSWD_FLAG)
             report(LOG_DEBUG, "pam_verify returns 1");
         return(1);

Chris Recker
Network Engineer
ViaWest, Inc.
Office: 303.874.5227
Fax: 303.885.4999
www.viawest.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20070905/26403ac1/attachment.html 

From dan.schmidt at uplinkdata.com  Wed Sep  5 19:43:09 2007
From: dan.schmidt at uplinkdata.com (Dan Schmidt)
Date: Wed, 5 Sep 2007 13:43:09 -0600
Subject: [tac_plus]  enable = file /etc/passwd
Message-ID: <390DD3915314C044A2B6D54FF84E872B29EA75@che-exch-001.uplinkdata.com>

I am having the same problem as this user:

http://www.shrubbery.net/pipermail/tac_plus/2007-February/000078.html

 

Is this a bug?  Terribly sorry if this has been talked about before - I
could not seem to google it. 

 

Thanks, 

-Dan 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20070905/fd30a19b/attachment.html 

From antoninvitecek at seznam.cz  Tue Sep 11 09:00:18 2007
From: antoninvitecek at seznam.cz (Antonin Vitecek)
Date: Tue, 11 Sep 2007 11:00:18 +0200
Subject: [tac_plus] Re: enable = file /etc/passwd
In-Reply-To: <390DD3915314C044A2B6D54FF84E872B29EA75@che-exch-001.uplinkdata.com>
References: <390DD3915314C044A2B6D54FF84E872B29EA75@che-exch-001.uplinkdata.com>
Message-ID: <46E65922.9080708@seznam.cz>

Dan Schmidt wrote:
> I am having the same problem as this user:
>
> http://www.shrubbery.net/pipermail/tac_plus/2007-February/000078.html
>
>  
>
> Is this a bug?  Terribly sorry if this has been talked about before - I
> could not seem to google it. 
>
>  
>
> Thanks, 
>
> -Dan 
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20070905/fd30a19b/attachment.html 
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
>
>   
Hi,

Jeff Gehlbach sent me a patch solving this problem, but format of his
patch didn't work to me, so I created new. There is mail from Jeff:

=================================================================================================

Hi!

I just ran across this same issue.  Sorry if my reply doesn't get
properly threaded, I'm pasting your message from the mailman archive as
I was not subscribed to the list at the time you sent it.

On Wed Feb 14 14:40:16 UTC 2007, Antonin Vitecek <AntoninVitecek at seznam.cz> wrote:


> > I have a little question. Is it possible authenticate enable password
> > using passwd(5) file? Because I found it on Shrubbery
> > page(http://www.shrubbery.net/tac_plus/) at the bottom:
> > 
> >  user = bar {
> >         enable = file /etc/tac_enable_pwd
> > }
> > 
> > But, if I try it, I get this message: 
> > 
> > 192.168.0.1: Error cannot identify password type file /etc/passwd for
> > john
> > 
> > For login it is ok. In pwlib.c I found: 
> > 
> >     /* Oops. No idea what kind of password this is. This should never
> >      * happen as the parser should never create such passwords. */
> > 
> > What I want is to have same login and enable password.
>   

I believe this may be a bug in the Shrubbery code.  I applied the
attached patch to the source as obtained by extracting
tacacs+-F4.0.4.14.tar.gz from ftp.shrubbery.net.  I can now use 'enable
= file /path/foo' with no issues.  I don't have a sufficiently deep
understanding of the TACACS+ protocol to know whether this will work in
every situation, but it got me running.  If anybody sees a problem with
this patch, please let me know.

The patch also adds single quotes around the parameterized strings in
the "Error cannot identify password type" messages, so that they read
e.g.:

Error cannot identify password type 'file' for 'john'

-jeff

*** pwlib.c.orig        2007-03-08 09:58:36.000000000 -0500
--- pwlib.c     2007-03-08 09:04:07.000000000 -0500
***************
*** 207,213 ****
      /* Oops. No idea what kind of password this is. This should never
       * happen as the parser should never create such passwords.
       */
!     report(LOG_ERR, "%s: Error cannot identify password type %s for %s",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");
--- 207,213 ----
      /* Oops. No idea what kind of password this is. This should never
       * happen as the parser should never create such passwords.
       */
!     report(LOG_ERR, "%s: Error cannot identify password type '%s' for '%s'",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");
***************
*** 261,270 ****
        return(data->status == TAC_PLUS_AUTHEN_STATUS_PASS);
      }
  
      /* Oops. No idea what kind of password this is. This should never
       * happen as the parser should never create such passwords. */
  
!     report(LOG_ERR, "%s: Error cannot identify password type %s for %s",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");
--- 261,281 ----
        return(data->status == TAC_PLUS_AUTHEN_STATUS_PASS);
      }
  
+     p = tac_find_substring("file ", cfg_passwd);
+     if (p) {
+       if (!passwd_file_verify(name, passwd, data, p)) {
+           data->status = TAC_PLUS_AUTHEN_STATUS_FAIL;
+           return(0);
+       } else {
+           data->status = TAC_PLUS_AUTHEN_STATUS_PASS;
+       }
+       return(data->status == TAC_PLUS_AUTHEN_STATUS_PASS);
+     }
+ 
      /* Oops. No idea what kind of password this is. This should never
       * happen as the parser should never create such passwords. */
  
!     report(LOG_ERR, "%s: Error cannot identify password type '%'s for '%s'",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");


=================================================================================================



-------------- next part --------------
A non-text attachment was scrubbed...
Name: tac_plus_enable_passwdfile_new.patch
Type: text/x-patch
Size: 1472 bytes
Desc: not available
Url : http://www.shrubbery.net/pipermail/tac_plus/attachments/20070911/999a7086/attachment.bin 

From i.anfrage at gmx.de  Tue Sep 11 09:05:11 2007
From: i.anfrage at gmx.de (i.anfrage)
Date: Tue, 11 Sep 2007 11:05:11 +0200
Subject: [tac_plus]  tacacs+ newbi
Message-ID: <200709111105.11840.i.anfrage@gmx.de>

hi @all,

i?m just doing my first "tacacs steps" and i wonder if there?s a tool 
like "radclient" for tacacs?

any suggestions?

tia

tom

From heas at shrubbery.net  Tue Sep 11 15:52:07 2007
From: heas at shrubbery.net (john heasley)
Date: Tue, 11 Sep 2007 15:52:07 +0000
Subject: [tac_plus] Re: tacacs+ newbi
In-Reply-To: <200709111105.11840.i.anfrage@gmx.de>
References: <200709111105.11840.i.anfrage@gmx.de>
Message-ID: <20070911155207.GC12334@shrubbery.net>

Sorry, there isn't, but thats a very good idea.  A proper client library
and a client would be very useful.

Tue, Sep 11, 2007 at 11:05:11AM +0200, i.anfrage:
> hi @all,
> 
> i?m just doing my first "tacacs steps" and i wonder if there?s a tool 
> like "radclient" for tacacs?
> 
> any suggestions?
> 
> tia
> 
> tom
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus

From dan.schmidt at uplinkdata.com  Wed Sep 12 21:33:46 2007
From: dan.schmidt at uplinkdata.com (Dan Schmidt)
Date: Wed, 12 Sep 2007 15:33:46 -0600
Subject: [tac_plus] Re: enable = file /etc/passwd
References: <390DD3915314C044A2B6D54FF84E872B29EA75@che-exch-001.uplinkdata.com>
	<46E65922.9080708@seznam.cz>
Message-ID: <390DD3915314C044A2B6D54FF84E872B29EA91@che-exch-001.uplinkdata.com>

Thanks - this appears to have worked great, I hope it makes it into the
next release.  Thanks also to Bitman for the help with the passwords.

-----Original Message-----
From: Antonin Vitecek [mailto:antoninvitecek at seznam.cz] 
Sent: Tuesday, September 11, 2007 3:00 AM
To: Dan Schmidt
Cc: tac_plus at shrubbery.net
Subject: Re: [tac_plus] enable = file /etc/passwd

Dan Schmidt wrote:
> I am having the same problem as this user:
>
> http://www.shrubbery.net/pipermail/tac_plus/2007-February/000078.html
>
>  
>
> Is this a bug?  Terribly sorry if this has been talked about before -
I
> could not seem to google it. 
>
>  
>
> Thanks, 
>
> -Dan 
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://www.shrubbery.net/pipermail/tac_plus/attachments/20070905/fd30a19
b/attachment.html 
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
>
>   
Hi,

Jeff Gehlbach sent me a patch solving this problem, but format of his
patch didn't work to me, so I created new. There is mail from Jeff:

========================================================================
=========================

Hi!

I just ran across this same issue.  Sorry if my reply doesn't get
properly threaded, I'm pasting your message from the mailman archive as
I was not subscribed to the list at the time you sent it.

On Wed Feb 14 14:40:16 UTC 2007, Antonin Vitecek
<AntoninVitecek at seznam.cz> wrote:


> > I have a little question. Is it possible authenticate enable
password
> > using passwd(5) file? Because I found it on Shrubbery
> > page(http://www.shrubbery.net/tac_plus/) at the bottom:
> > 
> >  user = bar {
> >         enable = file /etc/tac_enable_pwd
> > }
> > 
> > But, if I try it, I get this message: 
> > 
> > 192.168.0.1: Error cannot identify password type file /etc/passwd
for
> > john
> > 
> > For login it is ok. In pwlib.c I found: 
> > 
> >     /* Oops. No idea what kind of password this is. This should
never
> >      * happen as the parser should never create such passwords. */
> > 
> > What I want is to have same login and enable password.
>   

I believe this may be a bug in the Shrubbery code.  I applied the
attached patch to the source as obtained by extracting
tacacs+-F4.0.4.14.tar.gz from ftp.shrubbery.net.  I can now use 'enable
= file /path/foo' with no issues.  I don't have a sufficiently deep
understanding of the TACACS+ protocol to know whether this will work in
every situation, but it got me running.  If anybody sees a problem with
this patch, please let me know.

The patch also adds single quotes around the parameterized strings in
the "Error cannot identify password type" messages, so that they read
e.g.:

Error cannot identify password type 'file' for 'john'

-jeff

*** pwlib.c.orig        2007-03-08 09:58:36.000000000 -0500
--- pwlib.c     2007-03-08 09:04:07.000000000 -0500
***************
*** 207,213 ****
      /* Oops. No idea what kind of password this is. This should never
       * happen as the parser should never create such passwords.
       */
!     report(LOG_ERR, "%s: Error cannot identify password type %s for
%s",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");
--- 207,213 ----
      /* Oops. No idea what kind of password this is. This should never
       * happen as the parser should never create such passwords.
       */
!     report(LOG_ERR, "%s: Error cannot identify password type '%s' for
'%s'",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");
***************
*** 261,270 ****
        return(data->status == TAC_PLUS_AUTHEN_STATUS_PASS);
      }
  
      /* Oops. No idea what kind of password this is. This should never
       * happen as the parser should never create such passwords. */
  
!     report(LOG_ERR, "%s: Error cannot identify password type %s for
%s",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");
--- 261,281 ----
        return(data->status == TAC_PLUS_AUTHEN_STATUS_PASS);
      }
  
+     p = tac_find_substring("file ", cfg_passwd);
+     if (p) {
+       if (!passwd_file_verify(name, passwd, data, p)) {
+           data->status = TAC_PLUS_AUTHEN_STATUS_FAIL;
+           return(0);
+       } else {
+           data->status = TAC_PLUS_AUTHEN_STATUS_PASS;
+       }
+       return(data->status == TAC_PLUS_AUTHEN_STATUS_PASS);
+     }
+ 
      /* Oops. No idea what kind of password this is. This should never
       * happen as the parser should never create such passwords. */
  
!     report(LOG_ERR, "%s: Error cannot identify password type '%'s for
'%s'",
           session.peer,
           cfg_passwd && cfg_passwd[0] ? cfg_passwd : "<NULL>",
           name ? name : "<unknown>");


========================================================================
=========================




From dan.schmidt at uplinkdata.com  Thu Sep 13 18:52:38 2007
From: dan.schmidt at uplinkdata.com (Dan Schmidt)
Date: Thu, 13 Sep 2007 12:52:38 -0600
Subject: [tac_plus]  DOS attack
Message-ID: <390DD3915314C044A2B6D54FF84E872B29EA93@che-exch-001.uplinkdata.com>

I was wondering if anybody was aware of any possible DOS attacks against
tac_plus.  One of my coworkers expressed great concern that a DOS attack
could confuse authentication or authorization to the point that the
switch could not properly communicate with tac_plus and would not
default to local.  (ie aaa authentication default group tacacs line)
For this reason, he believes line con 0 should not use tacacs so that it
can be a backup.  

 

I am aware that this may be a bad forum to ask such a question, but I
thought that because the answer could relate directly to tac_plus I
would ask this question here.  If there is a more appropriate place to
inquire, please inform me. 

 

Thanks for your comments, 

-Dan 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20070913/448bdc82/attachment.html 

From i.anfrage at gmx.de  Sat Sep 15 11:06:22 2007
From: i.anfrage at gmx.de (i.anfrage)
Date: Sat, 15 Sep 2007 13:06:22 +0200
Subject: [tac_plus]  authorization
Message-ID: <200709151306.22880.i.anfrage@gmx.de>

hi @all,

i?m trying to do some authorization stuff, but it doesn?t work in the way i thought it should.

if i?ve got the following entry:

on tacacs+:

user = test {
login = cleartext test
cmd = show { permit ver }
cmd = traceroute { permit .* }
cmd = logout { permit .* }
}

on router:

aaa authentication login tac_list group tacacs+ local
aaa authorization exec auth1 group tacacs+

line vty 0 4
access-class 2 in
authorization exec auth1
login authentication tac_list
transport input ssh

vty 5 => 
are disabled

the user shouldn?t be able to do a "show ip interface brief", right?
tia

cheers 
tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20070915/6d97786e/attachment.html 

From i.anfrage at gmx.de  Sat Sep 15 15:37:27 2007
From: i.anfrage at gmx.de (i.anfrage)
Date: Sat, 15 Sep 2007 17:37:27 +0200
Subject: [tac_plus]  bug?
Message-ID: <200709151737.27795.i.anfrage@gmx.de>

hi,

i?m trying to start tac_plus with

user = fred {
        login = cleartext abcdef
        service = shell {
                cmd = write  { permit terminal }
                cmd = configure { permit .* }
        }
}

as shown on many different websites. but i always get

Error: expecting 'string' but found 'cmd' on line 34

what?s wrong?
i?m using tac_plus version F4.0.4.14

tia

tom

From heas at shrubbery.net  Sun Sep 16 22:05:59 2007
From: heas at shrubbery.net (john heasley)
Date: Sun, 16 Sep 2007 22:05:59 +0000
Subject: [tac_plus] Re: bug?
In-Reply-To: <200709151737.27795.i.anfrage@gmx.de>
References: <200709151737.27795.i.anfrage@gmx.de>
Message-ID: <20070916220559.GA15474@shrubbery.net>

Sat, Sep 15, 2007 at 05:37:27PM +0200, i.anfrage:
> hi,
> 
> i?m trying to start tac_plus with
> 
> user = fred {
>         login = cleartext abcdef
>         service = shell {
>                 cmd = write  { permit terminal }
>                 cmd = configure { permit .* }
>         }
> }
> 
user = fred {
login = cleartext abcdef
service = shell {
}
cmd = write  { permit terminal }
cmd = configure { permit .* }

> as shown on many different websites. but i always get
> 
> Error: expecting 'string' but found 'cmd' on line 34
> 
> what?s wrong?
> i?m using tac_plus version F4.0.4.14
> 
> tia
> 
> tom
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus

From heas at shrubbery.net  Sun Sep 16 22:56:43 2007
From: heas at shrubbery.net (john heasley)
Date: Sun, 16 Sep 2007 22:56:43 +0000
Subject: [tac_plus] Re: authorization
In-Reply-To: <200709151306.22880.i.anfrage@gmx.de>
References: <200709151306.22880.i.anfrage@gmx.de>
Message-ID: <20070916225643.GC15474@shrubbery.net>

see user DEFAULT in tac_plus.conf(5), iirc.

Sat, Sep 15, 2007 at 01:06:22PM +0200, i.anfrage:
> hi @all,
> 
> i?m trying to do some authorization stuff, but it doesn?t work in the way i thought it should.
> 
> if i?ve got the following entry:
> 
> on tacacs+:
> 
> user = test {
> login = cleartext test
> cmd = show { permit ver }
> cmd = traceroute { permit .* }
> cmd = logout { permit .* }
> }
> 
> on router:
> 
> aaa authentication login tac_list group tacacs+ local
> aaa authorization exec auth1 group tacacs+
> 
> line vty 0 4
> access-class 2 in
> authorization exec auth1
> login authentication tac_list
> transport input ssh
> 
> vty 5 => 
> are disabled
> 
> the user shouldn?t be able to do a "show ip interface brief", right?
> tia
> 
> cheers 
> tom
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20070915/6d97786e/attachment.html 
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus

From erik.neuwirth at gmx.de  Mon Sep 17 10:14:29 2007
From: erik.neuwirth at gmx.de (Erik Neuwirth)
Date: Mon, 17 Sep 2007 12:14:29 +0200
Subject: [tac_plus] Re: authorization - solved for my purpose
In-Reply-To: <200709151306.22880.i.anfrage@gmx.de>
References: <200709151306.22880.i.anfrage@gmx.de>
Message-ID: <200709171214.34869.erik.neuwirth@gmx.de>

hi @all,

first of all:

thanks to everybody for any given advice!

this is the solution that fetches my purpose:

######
on nas:
######

aaa new-model

aaa authentication login tac_list group tacacs+ local
aaa authentication enable default group tacacs+ enable
aaa authorization commands 5 en5 group tacacs+ 


line vty 0 *
authorization commands 5 en5
login authentication tac_list


##########
on tac_plus
##########

? ? user = test {

? ? ? login = cleartext test

? ? ? ? service = shell { priv_level = 5 }
? ? ? ? cmd = enable { deny .* }
? ? ? ? cmd = show { permit ver deny .* }
? ? ? ? cmd = traceroute { permit .* }
? ? ? ? cmd = logout { permit .* }
? ? ? ? }


br

tom


> hi @all,
>
> i?m trying to do some authorization stuff, but it doesn?t work in the way i
> thought it should.
>
> if i?ve got the following entry:
>
> on tacacs+:
>
> user = test {
> login = cleartext test
> cmd = show { permit ver }
> cmd = traceroute { permit .* }
> cmd = logout { permit .* }
> }
>
> on router:
>
> aaa authentication login tac_list group tacacs+ local
> aaa authorization exec auth1 group tacacs+
>
> line vty 0 4
> access-class 2 in
> authorization exec auth1
> login authentication tac_list
> transport input ssh
>
> vty 5 =>
> are disabled
>
> the user shouldn?t be able to do a "show ip interface brief", right?
> tia
>
> cheers
> tom
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://www.shrubbery.net/pipermail/tac_plus/attachments/20070915/6d97786e/a
>ttachment.html _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus

-- 



#######################
Skype me: erik.neuwirth

********************************************************

There?s no patch for stupidity
----------
Das Zitat hat nichts mit dem Empf?nger der Mail zu tun
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://www.shrubbery.net/pipermail/tac_plus/attachments/20070917/89ba4684/attachment.bin 

From heas at shrubbery.net  Fri Sep 28 23:40:12 2007
From: heas at shrubbery.net (john heasley)
Date: Fri, 28 Sep 2007 23:40:12 +0000
Subject: [tac_plus] Re: DOS attack
In-Reply-To: <390DD3915314C044A2B6D54FF84E872B29EA93@che-exch-001.uplinkdata.com>
References: <390DD3915314C044A2B6D54FF84E872B29EA93@che-exch-001.uplinkdata.com>
Message-ID: <20070928234012.GA23950@shrubbery.net>

Thu, Sep 13, 2007 at 12:52:38PM -0600, Dan Schmidt:
> I was wondering if anybody was aware of any possible DOS attacks against
> tac_plus.  One of my coworkers expressed great concern that a DOS attack
> could confuse authentication or authorization to the point that the
> switch could not properly communicate with tac_plus and would not
> default to local.  (ie aaa authentication default group tacacs line)

Any AAA could have this problem.  exposure could be greatly reduced by
filtering properly on the server, limiting accounts on the server, and
possibly other ways.

> For this reason, he believes line con 0 should not use tacacs so that it
> can be a backup.  

that is one possible approach.  doesn't help your console server though and
now anyone who must use the console must have the password.

> I am aware that this may be a bad forum to ask such a question, but I
> thought that because the answer could relate directly to tac_plus I
> would ask this question here.  If there is a more appropriate place to
> inquire, please inform me. 

There are some lists about that deal specifically with DOS and/or security.