From mehrdad at ippacket.org Tue Jun 2 00:47:43 2009 From: mehrdad at ippacket.org (Mehrdad) Date: Mon, 1 Jun 2009 17:47:43 -0700 Subject: [tac_plus] bad password/ban Message-ID: <97c663810906011747i3de9be9u7a7b438bb163bfd7@mail.gmail.com> Hello, I'm using the Tacacs+ 4.0.4.16 and I'm looking for logging bad password or ban IP address after specified bad password is there any feature in this regard? That's my suggestion if there isn't Thanks, Mehrdad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20090601/2349b4a7/attachment.html From rishat at melt.ru Tue Jun 2 16:39:45 2009 From: rishat at melt.ru (rishat) Date: Tue, 2 Jun 2009 20:39:45 +0400 Subject: [tac_plus] tac_plus problem Message-ID: <1018146459.20090602203945@melt.ru> Good Day I am system administrator in ISP And encountered problem with tac_plus I use complex user configuration like this one group = unlim2048_promo { default service = deny service = exec { autocmd = "ppp" } service = ppp protocol = lcp { interface-config#1="service-policy output UNLIM2048_PROMO" interface-config#2="service-policy input UNLIM_2_IN" } service = ppp protocol = multilink { max-links = 1 } after authorization "/usr/melt/tacacs+/unlim $user $name $port $address $priv $method $type $service $status" } user = rish { member = unlim2048_promo global = cleartext "1234" service=ppp protocol=ip { addr-pool="PROMO" outacl="141" }} Authentication and authorization works fine. Accounting is a problem. The problem appeered after I added these lines in group config: service = ppp protocol = lcp { interface-config#1="service-policy output UNLIM2048_PROMO" interface-config#2="service-policy input UNLIM_2_IN" } Here is what I see in the log and debug When Cisco NAS sends START record there are errors as follows in output of cisco debug: Jun 2 14:44:46.969: TPLUS: Queuing AAA Accounting request 347933 for processing 5w6d: %LINK-3-UPDOWN: Interface Virtual-Access62, changed state to up Jun 2 14:44:46.973: TPLUS: processing accounting request id 347933 Jun 2 14:44:46.973: TPLUS: Using directed server 89.184.0.24 Jun 2 14:44:46.973: TPLUS: Sending AV task_id=404050 Jun 2 14:44:46.973: TPLUS: Sending AV timezone=MSD Jun 2 14:44:46.973: TPLUS: Sending AV service=ppp Jun 2 14:44:46.973: TPLUS: Sending AV start_time=1243939485 Jun 2 14:44:46.973: TPLUS: Sending AV clid-mac-addr=0015.e941.1fe0 Jun 2 14:44:46.973: TPLUS: Sending AV sub-policy-In=UNLIM_2_IN Jun 2 14:44:46.973: TPLUS: Sending AV sub-policy-Out=UNLIM2048_PROMO Jun 2 14:44:46.973: TPLUS: Sending AV Framed-Protocol=1 Jun 2 14:44:46.973: TPLUS: Sending AV client-mac-address=0015.e941.1fe0 Jun 2 14:44:46.973: TPLUS: Accounting request created for 347933(rish) Jun 2 14:44:46.973: TPLUS(00054F1D)/0/NB_WAIT/66461874: Started 5 sec timeout Jun 2 14:44:46.981: TPLUS(00054F1D)/0/NB_WAIT: socket event 2 Jun 2 14:44:46.981: TPLUS(00054F1D)/0/NB_WAIT: wrote entire 231 bytes request Jun 2 14:44:46.981: TPLUS(00054F1D)/0/READ: socket event 1 Jun 2 14:44:46.981: TPLUS(00054F1D)/0/READ: Would block while reading Jun 2 14:44:47.005: TPLUS(00054F1D)/0/READ: socket event 1 Jun 2 14:44:47.005: TPLUS(00054F1D)/0/READ: read entire 12 header bytes (expect 5 bytes data) Jun 2 14:44:47.005: TPLUS(00054F1D)/0/READ: socket event 1 Jun 2 14:44:47.005: TPLUS(00054F1D)/0/READ: read entire 17 bytes response Jun 2 14:44:47.005: TPLUS(00054F1D)/0/66461874: Processing the reply packet Jun 2 14:44:47.005: TPLUS: Received accounting response with status PASS And here is what we get in log of tac_plus: Tue Jun 2 15:28:28 2009 [10015]: Read ACCT size=231 Tue Jun 2 15:28:28 2009 [10015]: validation request from 89.184.0.121 Tue Jun 2 15:28:28 2009 [10015]: PACKET: key=xxxx Tue Jun 2 15:28:28 2009 [10015]: version 192 (0xc0), type 3, seq no 1, flags 0x1 Tue Jun 2 15:28:28 2009 [10015]: session_id 149227973 (0x8e509c5), Data length 219 (0xdb) Tue Jun 2 15:28:28 2009 [10015]: End header Tue Jun 2 15:28:28 2009 [10015]: Packet body hex dump: Tue Jun 2 15:28:28 2009 [10015]: 0x2 0x6 0x1 0x3 0x3 0x4 0x7 0x0 0x9 0xe 0xc 0xb 0x15 0x1c 0x18 0x1e 0x11 0x21 Tue Jun 2 15:28:28 2009 [10015]: 0x72 0x69 0x73 0x68 0x30 0x2f 0x30 0x2f 0x30 0x2f 0x33 0x74 0x61 0x73 0x6b 0x5f Tue Jun 2 15:28:28 2009 [10015]: 0x69 0x64 0x3d 0x34 0x30 0x34 0x32 0x36 0x36 0x74 0x69 0x6d 0x65 0x7a 0x6f 0x6e Tue Jun 2 15:28:28 2009 [10015]: 0x65 0x3d 0x4d 0x53 0x44 0x73 0x65 0x72 0x76 0x69 0x63 0x65 0x3d 0x70 0x70 0x70 Tue Jun 2 15:28:28 2009 [10015]: 0x73 0x74 0x61 0x72 0x74 0x5f 0x74 0x69 0x6d 0x65 0x3d 0x31 0x32 0x34 0x33 0x39 Tue Jun 2 15:28:28 2009 [10015]: 0x34 0x32 0x31 0x30 0x37 0x63 0x6c 0x69 0x64 0x2d 0x6d 0x61 0x63 0x2d 0x61 0x64 Tue Jun 2 15:28:28 2009 [10015]: 0x64 0x72 0x3d 0x30 0x30 0x31 0x35 0x2e 0x65 0x39 0x34 0x31 0x2e 0x31 0x66 0x65 Tue Jun 2 15:28:28 2009 [10015]: 0x30 0x73 0x75 0x62 0x2d 0x70 0x6f 0x6c 0x69 0x63 0x79 0x2d 0x49 0x6e 0x3d 0x55 Tue Jun 2 15:28:28 2009 [10015]: 0x4e 0x4c 0x49 0x4d 0x5f 0x32 0x5f 0x49 0x4e 0x73 0x75 0x62 0x2d 0x70 0x6f 0x6c Tue Jun 2 15:28:28 2009 [10015]: 0x69 0x63 0x79 0x2d 0x4f 0x75 0x74 0x3d 0x55 0x4e 0x4c 0x49 0x4d 0x32 0x30 0x34 Tue Jun 2 15:28:28 2009 [10015]: 0x38 0x5f 0x50 0x52 0x4f 0x4d 0x4f 0x46 0x72 0x61 0x6d 0x65 0x64 0x2d 0x50 0x72 Tue Jun 2 15:28:28 2009 [10015]: 0x6f 0x74 0x6f 0x63 0x6f 0x6c 0x3d 0x31 0x63 0x6c 0x69 0x65 0x6e 0x74 0x2d 0x6d Tue Jun 2 15:28:28 2009 [10015]: 0x61 0x63 0x2d 0x61 0x64 0x64 0x72 0x65 0x73 0x73 0x3d 0x30 0x30 0x31 0x35 0x2e Tue Jun 2 15:28:28 2009 [10015]: 0x65 0x39 0x34 0x31 0x2e 0x31 0x66 0x65 0x30 Tue Jun 2 15:28:28 2009 [10015]: ACCT, flags=0x2 method=6 priv_lvl=1 Tue Jun 2 15:28:28 2009 [10015]: type=3 svc=3 Tue Jun 2 15:28:28 2009 [10015]: Bad ACCT packet length -620756992 Tue Jun 2 15:28:28 2009 [10015]: Start accounting request Tue Jun 2 15:28:28 2009 [10015]: 'Tue Jun 2 15:28:28 2009' Tue Jun 2 15:28:28 2009 [10015]: ' ' Tue Jun 2 15:28:28 2009 [10015]: '89.184.0.121' Tue Jun 2 15:28:28 2009 [10015]: ' ' Tue Jun 2 15:28:28 2009 [10015]: 'rish' Tue Jun 2 15:28:28 2009 [10015]: ' ' Tue Jun 2 15:28:28 2009 [10015]: '0/0/0/3' Tue Jun 2 15:28:28 2009 [10015]: ' ' Tue Jun 2 15:28:28 2009 [10015]: 'unknown' Tue Jun 2 15:28:28 2009 [10015]: ' ' Tue Jun 2 15:28:28 2009 [10015]: 'start ' Tue Jun 2 15:28:28 2009 [10015]: 'task_id=404266' Tue Jun 2 15:28:28 2009 [10015]: ' ' Tue Jun 2 15:28:28 2009 [10015]: 'timezone=MSD' Tue Jun 2 15:28:28 2009 [10015]: ' ' Tue Jun 2 15:28:28 2009 [10015]: 'service=ppp' Tue Jun 2 15:28:28 2009 [10015]: ' ' Tue Jun 2 15:28:28 2009 [10015]: 'start_time=1243942107' Tue Jun 2 15:28:28 2009 [10015]: ' ' Tue Jun 2 15:28:28 2009 [10015]: 'clid-mac-addr=0015.e941.1fe0' Tue Jun 2 15:28:28 2009 [10015]: ' ' Tue Jun 2 15:28:28 2009 [10015]: 'sub-policy-In=UNLIM_2_IN' Tue Jun 2 15:28:28 2009 [10015]: ' ' Tue Jun 2 15:28:28 2009 [10015]: 'sub-policy-Out=UNLIM2048_PROMO' Tue Jun 2 15:28:28 2009 [10015]: ' ' Tue Jun 2 15:28:28 2009 [10015]: 'Framed-Protocol=1' Tue Jun 2 15:28:28 2009 [10015]: ' ' Tue Jun 2 15:28:28 2009 [10015]: 'client-mac-address=0015.e941.1fe0' Tue Jun 2 15:28:28 2009 [10015]: ' ' Tue Jun 2 15:28:28 2009 [10015]: Writing ACCT size=17 Tue Jun 2 15:28:28 2009 [10015]: PACKET: key=xxx Tue Jun 2 15:28:28 2009 [10015]: version 192 (0xc0), type 3, seq no 2, flags 0x1 Tue Jun 2 15:28:28 2009 [10015]: session_id 149227973 (0x8e509c5), Data length 5 (0x5) Tue Jun 2 15:28:28 2009 [10015]: End header Tue Jun 2 15:28:28 2009 [10015]: Packet body hex dump: Tue Jun 2 15:28:28 2009 [10015]: 0x0 0x0 0x0 0x0 0x1 Tue Jun 2 15:28:28 2009 [10015]: ACCT/REPLY status=1 Tue Jun 2 15:28:28 2009 [10015]: msg_len=0 data_len=0 Tue Jun 2 15:28:28 2009 [10015]: msg: Tue Jun 2 15:28:28 2009 [10015]: data: Tue Jun 2 15:28:28 2009 [10015]: End packet Nevertheless tac_plus logs START record in a log file: Tue Jun 2 14:44:46 2009 89.184.0.121 rish 0/0/0/3 unknown start task_id=404050 timezone=MSD service=ppp start_time=1243939485 clid-mac-addr=0015.e941.1fe0 sub-policy-In=UNLIM_2_IN sub-policy-Out=UNLIM2048_PROMO Framed-Protocol=1 client-mac-address=0015.e941.1fe0 The real problem is when NAS sends STOP record. Here is what I see in the output of cisco debug Jun 2 14:44:59.061: TPLUS: Queuing AAA Accounting request 347933 for processing Jun 2 14:44:59.061: TPLUS: processing accounting request id 347933 Jun 2 14:44:59.061: TPLUS: Using directed server 89.184.0.24 Jun 2 14:44:59.061: TPLUS: Sending AV task_id=404050 Jun 2 14:44:59.061: TPLUS: Sending AV timezone=MSD Jun 2 14:44:59.061: TPLUS: Sending AV service=ppp Jun 2 14:44:59.061: TPLUS: Sending AV start_time=1243939485 Jun 2 14:44:59.061: TPLUS: Sending AV clid-mac-addr=0015.e941.1fe0 Jun 2 14:44:59.061: TPLUS: Sending AV sub-policy-In=UNLIM_2_IN Jun 2 14:44:59.061: TPLUS: Sending AV sub-policy-Out=UNLIM2048_PROMO Jun 2 14:44:59.061: TPLUS: Sending AV Framed-Protocol=1 Jun 2 14:44:59.061: TPLUS: Sending AV protocol=ip Jun 2 14:44:59.065: TPLUS: Sending AV addr=89.184.30.31 Jun 2 14:44:59.065: TPLUS: Sending AV ppp-disconnect-cause=Received LCP TERMREQ from peer Jun 2 14:44:59.065: TPLUS: Sending AV pre-session-time=1 Jun 2 14:44:59.065: TPLUS: Sending AV nas-tx-speed=100000000 Jun 2 14:44:59.065: TPLUS: Sending AV nas-rx-speed=100000000 Jun 2 14:44:59.065: TPLUS: Sending AV elapsed_time=13 Jun 2 14:44:59.065: TPLUS: Sending AV stop_time=1243939499 Jun 2 14:44:59.065: TPLUS: Sending AV bytes_in=1133 Jun 2 14:44:59.065: TPLUS: Sending AV bytes_out=364 Jun 2 14:44:59.065: TPLUS: Sending AV pre-bytes-in=183 Jun 2 14:44:59.065: TPLUS: Sending AV pre-bytes-out=118 Jun 2 14:44:59.065: TPLUS: Sending AV paks_in=15 Jun 2 14:44:59.065: TPLUS: Sending AV paks_out=9 Jun 2 14:44:59.065: TPLUS: Sending AV pre-paks-in=7 Jun 2 14:44:59.065: TPLUS: Sending AV pre-paks-out=6 Jun 2 14:44:59.065: TPLUS: Sending AV disc-cause=1 Jun 2 14:44:59.065: TPLUS: Sending AV disc-cause-ext=28 Jun 2 14:44:59.065: TPLUS: Sending AV client-mac-address=0015.e941.1fe0 Jun 2 14:44:59.065: TPLUS: Accounting request created for 347933(rish) Jun 2 14:44:59.065: TPLUS(00054F1D)/0/NB_WAIT/66461874: Started 5 sec timeout Jun 2 14:44:59.069: TPLUS(00054F1D)/0/NB_WAIT: socket event 2 Jun 2 14:44:59.069: TPLUS(00054F1D)/0/NB_WAIT: wrote 536 bytes 5w6d: %LINK-3-UPDOWN: Interface Virtual-Access62, changed state to down 5w6d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access62, changed state to down And here is what we get in log of tac_plus: Tue Jun 2 17:42:06 2009 [10010]: session.peerip is 89.184.0.121 Tue Jun 2 17:42:06 2009 [10010]: session request from 89.184.0.121 sock=2 Tue Jun 2 17:42:06 2009 [46296]: connect from 89.184.0.121 [89.184.0.121] Tue Jun 2 17:42:06 2009 [46296]: Waiting for packet Tue Jun 2 17:42:11 2009 [46296]: 89.184.0.121 : fd 2 eof (connection closed) Tue Jun 2 17:42:11 2009 [46296]: Error 89.184.0.121: start_session: bad socket read This time tac_plus logs nothing in accounting log Could you please look at my case and saggest some decision With respect Rishat N Agzamov, CCNP, HP-AIS, MCP Leading system engineer MELT LLC ph. (843) 299-50-43 mailto:rishat at melt.ru From mark.thomas at corp.aol.com Tue Jun 2 18:04:53 2009 From: mark.thomas at corp.aol.com (Mark Ellzey Thomas) Date: Tue, 2 Jun 2009 14:04:53 -0400 Subject: [tac_plus] Re: bad password/ban In-Reply-To: <97c663810906011747i3de9be9u7a7b438bb163bfd7@mail.gmail.com> References: <97c663810906011747i3de9be9u7a7b438bb163bfd7@mail.gmail.com> Message-ID: <20090602180453.GJ23025@corp.aol.com> On Mon, Jun 01, 2009 at 05:47:43PM -0700, Mehrdad wrote: > Hello, > > I'm using the Tacacs+ 4.0.4.16 and I'm looking for logging bad password or > ban IP address after specified bad password is there any feature in this > regard? > That's my suggestion if there isn't > > Greetings Mehrdad, I wrote a patch to lock an account after the daemon notices a bunch of auth failures from one user. Giving a quick glance to recent releases it does not look as if this was accepted. You can find the original post/patch here: http://www.shrubbery.net/pipermail/tac_plus/2008-June/000248.html From mark.thomas at corp.aol.com Tue Jun 2 20:53:42 2009 From: mark.thomas at corp.aol.com (Mark Ellzey Thomas) Date: Tue, 2 Jun 2009 16:53:42 -0400 Subject: [tac_plus] Re: bad password/ban In-Reply-To: <20090602180453.GJ23025@corp.aol.com> References: <97c663810906011747i3de9be9u7a7b438bb163bfd7@mail.gmail.com> <20090602180453.GJ23025@corp.aol.com> Message-ID: <20090602205342.GU23025@corp.aol.com> On Tue, Jun 02, 2009 at 02:04:53PM -0400, Mark Ellzey Thomas wrote: > On Mon, Jun 01, 2009 at 05:47:43PM -0700, Mehrdad wrote: > > Hello, > > > > I'm using the Tacacs+ 4.0.4.16 and I'm looking for logging bad password or > > ban IP address after specified bad password is there any feature in this > > regard? > > That's my suggestion if there isn't > > > > > > Greetings Mehrdad, > > I wrote a patch to lock an account after the daemon notices a bunch of > auth failures from one user. Giving a quick glance to recent releases > it does not look as if this was accepted. > > You can find the original post/patch here: > http://www.shrubbery.net/pipermail/tac_plus/2008-June/000248.html > FYI, I have attached the code patched against the latest tac_plus release. -------------- next part -------------- diff -Naur ../tacacs+-F4.0.4.18/authen.c ./authen.c --- ../tacacs+-F4.0.4.18/authen.c 2009-03-18 17:11:36.000000000 -0400 +++ ./authen.c 2009-06-02 14:55:06.000000000 -0400 @@ -324,10 +324,21 @@ return; } - if ((*func) (datap)) { +#ifdef AFL + if ((session.afl_cfg) && + cfg_is_user_disabled(datap->NAS_id->username) == 1) + datap->status = TAC_PLUS_AUTHEN_STATUS_FAIL; + else if ((*func) (datap)) { send_authen_error("Unexpected authentication function failure"); return; } +#else + if((*func) (datap)) + { + send_authen_error("Unexpected authentication function failure"); + return; + } +#endif switch (datap->status) { @@ -357,6 +368,10 @@ case TAC_PLUS_AUTHEN_STATUS_FAIL: /* An invalid user/password combination */ +#ifdef AFL + if(session.afl_cfg) + cfg_increment_failure(datap->NAS_id->username); +#endif send_authen_reply(TAC_PLUS_AUTHEN_STATUS_FAIL, datap->server_msg, datap->server_msg ? strlen(datap->server_msg) : 0, diff -Naur ../tacacs+-F4.0.4.18/config.c ./config.c --- ../tacacs+-F4.0.4.18/config.c 2009-03-18 19:24:54.000000000 -0400 +++ ./config.c 2009-06-02 14:56:39.000000000 -0400 @@ -113,6 +113,11 @@ static int no_user_dflt = 0; /* default if user doesn't exist */ static char *authen_default = NULL; /* top level authentication default */ static char *nopasswd_str = "nopassword"; +#ifdef AFL +static unsigned int user_count = 0; /* the number of users in the config */ +static key_t failed_key; /* the shm key for AFL */ +#endif + /* * A host definition structure. @@ -177,6 +182,9 @@ #ifdef MAXSESS int maxsess; /* Max sessions/user */ #endif /* MAXSESS */ +#ifdef AFL + int shm_offset; +#endif } USER; #ifdef ACLS @@ -212,6 +220,16 @@ typedef union hash HASH; +#ifdef AFL +struct failed_node { + char username[65]; + unsigned int failures; + time_t first_failure; + time_t locked_time; /* the time the lock was set */ + char disabled; +}; +#endif + void *grouptable[HASH_TAB_SIZE];/* Table of group declarations */ void *usertable[HASH_TAB_SIZE]; /* Table of user declarations */ #ifdef ACLS @@ -519,6 +537,14 @@ session.acctfile = NULL; } +#ifdef AFL + if (session.afl_cfg) { + cfg_destroy_failure_shm(); + free(session.afl_cfg); + session.afl_cfg = NULL; + } +#endif + #ifdef ACLS /* clean the acltable */ for (i = 0; i < HASH_TAB_SIZE; i++) { @@ -744,7 +770,23 @@ switch (sym_code) { case S_eof: return(0); - +#ifdef AFL + case S_auth_fail_lock: + /* faillock a b c + * a = number of failures + * b = in this many seconds + * c = lock for this many seconds */ + session.afl_cfg = (struct afl_cfg *)tac_malloc(sizeof(struct afl_cfg)); + bzero(session.afl_cfg, sizeof(struct afl_cfg)); + sym_get(); + session.afl_cfg->num_failures = atoi(sym_buf); + sym_get(); + session.afl_cfg->seconds = atoi(sym_buf); + sym_get(); + session.afl_cfg->lock_time = atoi(sym_buf); + sym_get(); + break; +#endif case S_accounting: sym_get(); @@ -2427,6 +2469,306 @@ return(authen_default); } +#ifdef AFL +static unsigned int fetch_user_count(void) +{ + int i; + unsigned int count; + USER *entry; + + count = 0; + + for (i=0; i < HASH_TAB_SIZE; i++) + { + entry = (USER *)usertable[i]; + while (entry) + { + count++; + entry = entry->hash; + } + } + return count; +} + +/* + * Create a user-table in shared memory for AFL. + */ +void cfg_create_failure_shm(const char *path, int id) +{ + unsigned int shm_sz; + int offset; + int i, shmid; + char *shm = NULL; + + user_count = shm_sz = offset = 0; + + user_count = fetch_user_count(); + shm_sz = user_count * sizeof(struct failed_node); + + if((failed_key = ftok(path, id))<0) + { + report(LOG_ERR, "ftok unable to create key: %s", + strerror(errno)); + tac_exit(1); + } + + if ((shmid = shmget(failed_key, shm_sz, IPC_CREAT|0666)) < 0) + { + report(LOG_ERR, "shmget unable to get memory: %s", + strerror(errno)); + tac_exit(1); + } + + if ((shm = (char *)shmat(shmid, NULL, 0)) == (char *)-1) + { + report(LOG_ERR, "shmat: %s", strerror(errno)); + tac_exit(1); + } + + /* iterate over all the users and add them a failed_node + * structure to the shared memory */ + for (i=0; i < HASH_TAB_SIZE; i++) + { + struct failed_node *failed_node; + USER *entry = (USER *)usertable[i]; + + while(entry) + { + entry->shm_offset = offset; + failed_node = (struct failed_node *)&shm[offset]; + bzero(failed_node, sizeof(struct failed_node)); + + if (strlen(entry->name) > 64) + { + report(LOG_ERR, "username %s > length of 64", + entry->name); + tac_exit(1); + } + + strncpy(failed_node->username, entry->name, 64); + offset += sizeof(struct failed_node); + + if (offset > user_count * sizeof(struct failed_node)) + { + report(LOG_ERR, "More users than previously allocated"); + tac_exit(1); + } + + entry = entry->hash; + } + } + + /* now create a semaphore for locking */ + if(semget(failed_key, 1, 0666 | IPC_CREAT) < 0) + { + report(LOG_ERR, "Unable to create semaphore: %s", strerror(errno)); + tac_exit(1); + } +} + +char *shm_fetch_and_lock(key_t key, unsigned int sz) +{ + int shmid, semid; + struct sembuf sem[2]; + char *shm = NULL; + + if((semid = semget(key, 1, 0666)) < 0) + { + report(LOG_ERR, "unable to fetch semaphore: %s", strerror(errno)); + tac_exit(1); + } + + sem[0].sem_num = 0; + sem[1].sem_num = 0; + sem[0].sem_flg = SEM_UNDO; + sem[1].sem_flg = SEM_UNDO; + sem[0].sem_op = 0; + sem[1].sem_op = 1; + + semop(semid, sem, 2); + + if((shmid = shmget(key, sz, 0666)) < 0) + { + report(LOG_ERR, "shm_fetchnlock unable to get shmid: %s", + strerror(errno)); + tac_exit(1); + } + + if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) + { + report(LOG_ERR, "shm_fetchnlock Unable to find shm segment: %s", + strerror(errno)); + tac_exit(1); + } + + return shm; +} + +static void shm_unlock(key_t key) +{ + int semid; + struct sembuf sem; + + if ((semid = semget(key, 1, 0666)) < 0) + tac_exit(1); + + sem.sem_num = 0; + sem.sem_flg = SEM_UNDO; + sem.sem_op = -1; + + semop(semid, &sem, 1); +} + +static void destroy_semaphore(key_t key) +{ + int semid; + semid = semget(key, 0, 0666); + semctl(semid, 0, IPC_RMID, NULL); +} + +static void destroy_shm(key_t key) +{ + int shmid; + shmid = shmget(key, 1, 0666); + shmctl(shmid, IPC_RMID, NULL); +} + + +void cfg_destroy_failure_shm(void) +{ + destroy_semaphore(failed_key); + destroy_shm(failed_key); +} + +static int shm_failed_offset(char *username, void *arg) +{ + USER *user; + + if (arg == NULL) + user = (USER *)hash_lookup(usertable, username); + else + user = (USER *)arg; + + return (user ? user->shm_offset:-1); +} + +void cfg_increment_failure(char *username) +{ + USER *user; + int offset; + char *data; + struct failed_node *node; + time_t now; + + user = hash_lookup(usertable, username); + + if (user == NULL) + return; + + if ((offset = shm_failed_offset(username, user)) < 0) + return; + + data = shm_fetch_and_lock(failed_key, + user_count * sizeof(struct failed_node)); + + node = (struct failed_node *)&data[user->shm_offset]; + + if (strcmp(node->username, username) != 0) + { + report(LOG_ERR, "Shared memory has something amiss (%s!=%s)", + node->username, username); + shm_unlock(failed_key); + return; + } + + time(&now); + + if (!node->first_failure) + node->first_failure = now; + + /* determine if this fail has exceeded the number of failures within + * the time window. If it has then lock the account. + */ + if((!node->disabled) && ++node->failures >= session.afl_cfg->num_failures) + { + report(LOG_WARNING, "User %s has been disabled for %d seconds", + username, session.afl_cfg->lock_time); + node->locked_time = now; + node->disabled = 1; + } + + shm_unlock(failed_key); +} + +/* + * Attempt to determine whether a user is locked out or not, + * this function also does timer expiration. + */ +int cfg_is_user_disabled(char *username) +{ + USER *user; + int offset; + char *data; + struct failed_node *node; + int ret = 0; + time_t now; + + user = hash_lookup(usertable, username); + + if (user == NULL) + return -1; + + if ((offset = shm_failed_offset(username, user))<0) + return -1; + + data = shm_fetch_and_lock(failed_key, + user_count * sizeof(struct failed_node)); + + node = (struct failed_node *)&data[user->shm_offset]; + + /* check to make sure what we have is true */ + if (strcmp(node->username, username) != 0) + { + report(LOG_ERR, "Shared memory has something amiss (%s!=%s)", + node->username, username); + shm_unlock(failed_key); + return -1; + } + + ret = node->disabled?1:0; + time(&now); + + if (ret) + { + /* Check locked account expiration. Unlock if expired. */ + if (difftime(now, node->locked_time) > session.afl_cfg->lock_time) + { + report(LOG_WARNING, "Re-enabling account: %s", username); + node->first_failure = 0; + node->disabled = 0; + node->failures = 0; + node->locked_time = 0; + ret = 0; + } + } + else { + /* Check to see if the auth-fail window has expired. */ + if ((node->first_failure) && + difftime(now, node->first_failure) > session.afl_cfg->seconds) + { + report(LOG_INFO,"Resetting failure clock for user: %s\n", username); + node->first_failure = 0; + node->disabled = 0; + node->failures = 0; + node->locked_time = 0; + } + } + + shm_unlock(failed_key); + return ret; +} +#endif /* AFL */ + /* * Return 1 if this user has any ppp services configured. Used for * authorizing ppp/lcp requests diff -Naur ../tacacs+-F4.0.4.18/config.h.in ./config.h.in --- ../tacacs+-F4.0.4.18/config.h.in 2009-03-18 15:07:21.000000000 -0400 +++ ./config.h.in 2009-06-02 14:37:54.000000000 -0400 @@ -253,5 +253,7 @@ # define socklen_t int #endif +#undef AFL + #endif /* CONFIG_H */ diff -Naur ../tacacs+-F4.0.4.18/configure.in ./configure.in --- ../tacacs+-F4.0.4.18/configure.in 2009-03-18 15:07:21.000000000 -0400 +++ ./configure.in 2009-06-02 14:53:29.000000000 -0400 @@ -559,6 +559,37 @@ AC_SUBST(PROFLAGS) AC_SUBST(PROFLIBS) +dnl +dnl DISABLE AFL Support (Authentication Failure Locking) +dnl +AC_MSG_CHECKING(whether to enable AFL support) +AH_TEMPLATE(AFL, [define this to disable Authentication Failure Locking support]) +AC_ARG_ENABLE(afl, +[ --enable-afl Enable AFL support (default)], +[ case "$enable_afl" in + no) + AC_MSG_RESULT(no) + use_afl=0 + ;; + yes) + AC_MSG_RESULT(yes) + AC_DEFINE(AFL) + use_afl=1 + ;; + *) + AC_MSG_RESULT(yes) + AC_DEFINE(AFL) + use_afl=1 + ;; + esac ], + AC_MSG_RESULT(yes) + AC_DEFINE(AFL) + use_afl=1 +) +AC_SUBST(AFL) + + + # look for PAM AH_TEMPLATE(HAVE_PAM, [define if your system has libpam]) AC_CHECK_LIB([pam], [pam_start], diff -Naur ../tacacs+-F4.0.4.18/parse.c ./parse.c --- ../tacacs+-F4.0.4.18/parse.c 2009-03-17 14:40:29.000000000 -0400 +++ ./parse.c 2009-06-02 14:37:54.000000000 -0400 @@ -118,6 +118,9 @@ declare("PAM", S_pam); #endif declare("syslog", S_syslog); +#ifdef AFL + declare("auth-fail-lock", S_auth_fail_lock); +#endif } /* Return a keyword code if a keyword is recognized. 0 otherwise */ diff -Naur ../tacacs+-F4.0.4.18/parse.h ./parse.h --- ../tacacs+-F4.0.4.18/parse.h 2009-03-18 19:24:54.000000000 -0400 +++ ./parse.h 2009-06-02 14:51:39.000000000 -0400 @@ -90,3 +90,6 @@ # define S_pam 49 #endif #define S_syslog 50 +#ifdef AFL +#define S_auth_fail_lock 51 +#endif diff -Naur ../tacacs+-F4.0.4.18/tac_plus.c ./tac_plus.c --- ../tacacs+-F4.0.4.18/tac_plus.c 2009-03-18 17:04:29.000000000 -0400 +++ ./tac_plus.c 2009-06-02 15:18:58.000000000 -0400 @@ -99,6 +99,10 @@ report(LOG_NOTICE, "Received signal %d, shutting down", signum); if (childpid > 0) unlink(pidfilebuf); + +#ifdef AFL + cfg_destroy_failure_shm(); +#endif tac_exit(0); } @@ -115,6 +119,10 @@ tac_exit(1); } +#ifdef AFL + session.afl_cfg = NULL; +#endif + /* read the config file */ if (cfg_read_config(session.cfgfile)) { report(LOG_ERR, "Parsing %s", session.cfgfile); @@ -124,6 +132,11 @@ if (session.acctfile == NULL && !(session.flags & SESS_FLAG_ACCTSYSL)) session.acctfile = tac_strdup(TACPLUS_ACCTFILE); +#ifdef AFL + if(session.afl_cfg) + cfg_create_failure_shm(session.cfgfile, 'A'); +#endif + initialised++; report(LOG_NOTICE, "Version %s Initialized %d", version, initialised); @@ -332,6 +345,9 @@ signal(SIGUSR1, handler); signal(SIGHUP, handler); signal(SIGTERM, die); +#ifdef AFL + signal(SIGINT, die); +#endif signal(SIGPIPE, SIG_IGN); if (parse_only) @@ -883,6 +899,9 @@ #if __STDC__ fprintf(stdout, "__STDC__\n"); #endif +#if AFL + fprintf(stdout, "AFL\n"); +#endif return; } diff -Naur ../tacacs+-F4.0.4.18/tac_plus.h ./tac_plus.h --- ../tacacs+-F4.0.4.18/tac_plus.h 2009-03-18 19:24:54.000000000 -0400 +++ ./tac_plus.h 2009-06-02 14:55:49.000000000 -0400 @@ -149,6 +149,12 @@ # include #endif +#ifdef AFL +#include +#include +#include +#endif + #include "pathsl.h" #include "md5.h" @@ -278,6 +284,14 @@ #define NAS_PORT_MAX_LEN 255 +#ifdef AFL +struct afl_cfg { + int num_failures; + int seconds; + int lock_time; +}; +#endif + struct session { int session_id; /* host specific unique session id */ int aborted; /* have we received an abort flag? */ @@ -294,6 +308,9 @@ char *acctfile; /* name of accounting file */ char port[NAS_PORT_MAX_LEN+1]; /* For error reporting */ u_char version; /* version of last packet read */ +#ifdef AFL + struct afl_cfg *afl_cfg; /* authentication failure lock cfg */ +#endif }; extern struct session session; /* the session */ @@ -652,6 +669,12 @@ int cfg_read_config(char *); int cfg_user_exists(char *); int cfg_user_svc_default_is_permit(char *); +#ifdef AFL +void cfg_create_failure_shm(const char *, int); +void cfg_destroy_failure_shm(void); +void cfg_increment_failure(char *); +int cfg_is_user_disabled(char *); +#endif /* default_fn.c */ int default_fn(struct authen_data *); From dan.schmidt at uplinkdata.com Tue Jun 2 21:12:25 2009 From: dan.schmidt at uplinkdata.com (Schmidt, Daniel) Date: Tue, 2 Jun 2009 15:12:25 -0600 Subject: [tac_plus] Re: bad password/ban In-Reply-To: <20090602205342.GU23025@corp.aol.com> References: <97c663810906011747i3de9be9u7a7b438bb163bfd7@mail.gmail.com><20090602180453.GJ23025@corp.aol.com> <20090602205342.GU23025@corp.aol.com> Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D5F7@che-exch-003.uplinkdata.com> As a side note, I believe running autoconf is required after patching. Seems to work very well. A very useful feature; I would be very interested in seeing it adopted in the next release. -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Mark Ellzey Thomas Sent: Tuesday, June 02, 2009 2:54 PM To: Mehrdad Cc: tac_plus at shrubbery.net Subject: [tac_plus] Re: bad password/ban On Tue, Jun 02, 2009 at 02:04:53PM -0400, Mark Ellzey Thomas wrote: > On Mon, Jun 01, 2009 at 05:47:43PM -0700, Mehrdad wrote: > > Hello, > > > > I'm using the Tacacs+ 4.0.4.16 and I'm looking for logging bad password or > > ban IP address after specified bad password is there any feature in this > > regard? > > That's my suggestion if there isn't > > > > > > Greetings Mehrdad, > > I wrote a patch to lock an account after the daemon notices a bunch of > auth failures from one user. Giving a quick glance to recent releases > it does not look as if this was accepted. > > You can find the original post/patch here: > http://www.shrubbery.net/pipermail/tac_plus/2008-June/000248.html > FYI, I have attached the code patched against the latest tac_plus release. -------------- next part -------------- diff -Naur ../tacacs+-F4.0.4.18/authen.c ./authen.c --- ../tacacs+-F4.0.4.18/authen.c 2009-03-18 17:11:36.000000000 -0400 +++ ./authen.c 2009-06-02 14:55:06.000000000 -0400 @@ -324,10 +324,21 @@ return; } - if ((*func) (datap)) { +#ifdef AFL + if ((session.afl_cfg) && + cfg_is_user_disabled(datap->NAS_id->username) == 1) + datap->status = TAC_PLUS_AUTHEN_STATUS_FAIL; + else if ((*func) (datap)) { send_authen_error("Unexpected authentication function failure"); return; } +#else + if((*func) (datap)) + { + send_authen_error("Unexpected authentication function failure"); + return; + } +#endif switch (datap->status) { @@ -357,6 +368,10 @@ case TAC_PLUS_AUTHEN_STATUS_FAIL: /* An invalid user/password combination */ +#ifdef AFL + if(session.afl_cfg) + cfg_increment_failure(datap->NAS_id->username); +#endif send_authen_reply(TAC_PLUS_AUTHEN_STATUS_FAIL, datap->server_msg, datap->server_msg ? strlen(datap->server_msg) : 0, diff -Naur ../tacacs+-F4.0.4.18/config.c ./config.c --- ../tacacs+-F4.0.4.18/config.c 2009-03-18 19:24:54.000000000 -0400 +++ ./config.c 2009-06-02 14:56:39.000000000 -0400 @@ -113,6 +113,11 @@ static int no_user_dflt = 0; /* default if user doesn't exist */ static char *authen_default = NULL; /* top level authentication default */ static char *nopasswd_str = "nopassword"; +#ifdef AFL +static unsigned int user_count = 0; /* the number of users in the config */ +static key_t failed_key; /* the shm key for AFL */ +#endif + /* * A host definition structure. @@ -177,6 +182,9 @@ #ifdef MAXSESS int maxsess; /* Max sessions/user */ #endif /* MAXSESS */ +#ifdef AFL + int shm_offset; +#endif } USER; #ifdef ACLS @@ -212,6 +220,16 @@ typedef union hash HASH; +#ifdef AFL +struct failed_node { + char username[65]; + unsigned int failures; + time_t first_failure; + time_t locked_time; /* the time the lock was set */ + char disabled; +}; +#endif + void *grouptable[HASH_TAB_SIZE];/* Table of group declarations */ void *usertable[HASH_TAB_SIZE]; /* Table of user declarations */ #ifdef ACLS @@ -519,6 +537,14 @@ session.acctfile = NULL; } +#ifdef AFL + if (session.afl_cfg) { + cfg_destroy_failure_shm(); + free(session.afl_cfg); + session.afl_cfg = NULL; + } +#endif + #ifdef ACLS /* clean the acltable */ for (i = 0; i < HASH_TAB_SIZE; i++) { @@ -744,7 +770,23 @@ switch (sym_code) { case S_eof: return(0); - +#ifdef AFL + case S_auth_fail_lock: + /* faillock a b c + * a = number of failures + * b = in this many seconds + * c = lock for this many seconds */ + session.afl_cfg = (struct afl_cfg *)tac_malloc(sizeof(struct afl_cfg)); + bzero(session.afl_cfg, sizeof(struct afl_cfg)); + sym_get(); + session.afl_cfg->num_failures = atoi(sym_buf); + sym_get(); + session.afl_cfg->seconds = atoi(sym_buf); + sym_get(); + session.afl_cfg->lock_time = atoi(sym_buf); + sym_get(); + break; +#endif case S_accounting: sym_get(); @@ -2427,6 +2469,306 @@ return(authen_default); } +#ifdef AFL +static unsigned int fetch_user_count(void) +{ + int i; + unsigned int count; + USER *entry; + + count = 0; + + for (i=0; i < HASH_TAB_SIZE; i++) + { + entry = (USER *)usertable[i]; + while (entry) + { + count++; + entry = entry->hash; + } + } + return count; +} + +/* + * Create a user-table in shared memory for AFL. + */ +void cfg_create_failure_shm(const char *path, int id) +{ + unsigned int shm_sz; + int offset; + int i, shmid; + char *shm = NULL; + + user_count = shm_sz = offset = 0; + + user_count = fetch_user_count(); + shm_sz = user_count * sizeof(struct failed_node); + + if((failed_key = ftok(path, id))<0) + { + report(LOG_ERR, "ftok unable to create key: %s", + strerror(errno)); + tac_exit(1); + } + + if ((shmid = shmget(failed_key, shm_sz, IPC_CREAT|0666)) < 0) + { + report(LOG_ERR, "shmget unable to get memory: %s", + strerror(errno)); + tac_exit(1); + } + + if ((shm = (char *)shmat(shmid, NULL, 0)) == (char *)-1) + { + report(LOG_ERR, "shmat: %s", strerror(errno)); + tac_exit(1); + } + + /* iterate over all the users and add them a failed_node + * structure to the shared memory */ + for (i=0; i < HASH_TAB_SIZE; i++) + { + struct failed_node *failed_node; + USER *entry = (USER *)usertable[i]; + + while(entry) + { + entry->shm_offset = offset; + failed_node = (struct failed_node *)&shm[offset]; + bzero(failed_node, sizeof(struct failed_node)); + + if (strlen(entry->name) > 64) + { + report(LOG_ERR, "username %s > length of 64", + entry->name); + tac_exit(1); + } + + strncpy(failed_node->username, entry->name, 64); + offset += sizeof(struct failed_node); + + if (offset > user_count * sizeof(struct failed_node)) + { + report(LOG_ERR, "More users than previously allocated"); + tac_exit(1); + } + + entry = entry->hash; + } + } + + /* now create a semaphore for locking */ + if(semget(failed_key, 1, 0666 | IPC_CREAT) < 0) + { + report(LOG_ERR, "Unable to create semaphore: %s", strerror(errno)); + tac_exit(1); + } +} + +char *shm_fetch_and_lock(key_t key, unsigned int sz) +{ + int shmid, semid; + struct sembuf sem[2]; + char *shm = NULL; + + if((semid = semget(key, 1, 0666)) < 0) + { + report(LOG_ERR, "unable to fetch semaphore: %s", strerror(errno)); + tac_exit(1); + } + + sem[0].sem_num = 0; + sem[1].sem_num = 0; + sem[0].sem_flg = SEM_UNDO; + sem[1].sem_flg = SEM_UNDO; + sem[0].sem_op = 0; + sem[1].sem_op = 1; + + semop(semid, sem, 2); + + if((shmid = shmget(key, sz, 0666)) < 0) + { + report(LOG_ERR, "shm_fetchnlock unable to get shmid: %s", + strerror(errno)); + tac_exit(1); + } + + if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) + { + report(LOG_ERR, "shm_fetchnlock Unable to find shm segment: %s", + strerror(errno)); + tac_exit(1); + } + + return shm; +} + +static void shm_unlock(key_t key) +{ + int semid; + struct sembuf sem; + + if ((semid = semget(key, 1, 0666)) < 0) + tac_exit(1); + + sem.sem_num = 0; + sem.sem_flg = SEM_UNDO; + sem.sem_op = -1; + + semop(semid, &sem, 1); +} + +static void destroy_semaphore(key_t key) +{ + int semid; + semid = semget(key, 0, 0666); + semctl(semid, 0, IPC_RMID, NULL); +} + +static void destroy_shm(key_t key) +{ + int shmid; + shmid = shmget(key, 1, 0666); + shmctl(shmid, IPC_RMID, NULL); +} + + +void cfg_destroy_failure_shm(void) +{ + destroy_semaphore(failed_key); + destroy_shm(failed_key); +} + +static int shm_failed_offset(char *username, void *arg) +{ + USER *user; + + if (arg == NULL) + user = (USER *)hash_lookup(usertable, username); + else + user = (USER *)arg; + + return (user ? user->shm_offset:-1); +} + +void cfg_increment_failure(char *username) +{ + USER *user; + int offset; + char *data; + struct failed_node *node; + time_t now; + + user = hash_lookup(usertable, username); + + if (user == NULL) + return; + + if ((offset = shm_failed_offset(username, user)) < 0) + return; + + data = shm_fetch_and_lock(failed_key, + user_count * sizeof(struct failed_node)); + + node = (struct failed_node *)&data[user->shm_offset]; + + if (strcmp(node->username, username) != 0) + { + report(LOG_ERR, "Shared memory has something amiss (%s!=%s)", + node->username, username); + shm_unlock(failed_key); + return; + } + + time(&now); + + if (!node->first_failure) + node->first_failure = now; + + /* determine if this fail has exceeded the number of failures within + * the time window. If it has then lock the account. + */ + if((!node->disabled) && ++node->failures >= session.afl_cfg->num_failures) + { + report(LOG_WARNING, "User %s has been disabled for %d seconds", + username, session.afl_cfg->lock_time); + node->locked_time = now; + node->disabled = 1; + } + + shm_unlock(failed_key); +} + +/* + * Attempt to determine whether a user is locked out or not, + * this function also does timer expiration. + */ +int cfg_is_user_disabled(char *username) +{ + USER *user; + int offset; + char *data; + struct failed_node *node; + int ret = 0; + time_t now; + + user = hash_lookup(usertable, username); + + if (user == NULL) + return -1; + + if ((offset = shm_failed_offset(username, user))<0) + return -1; + + data = shm_fetch_and_lock(failed_key, + user_count * sizeof(struct failed_node)); + + node = (struct failed_node *)&data[user->shm_offset]; + + /* check to make sure what we have is true */ + if (strcmp(node->username, username) != 0) + { + report(LOG_ERR, "Shared memory has something amiss (%s!=%s)", + node->username, username); + shm_unlock(failed_key); + return -1; + } + + ret = node->disabled?1:0; + time(&now); + + if (ret) + { + /* Check locked account expiration. Unlock if expired. */ + if (difftime(now, node->locked_time) > session.afl_cfg->lock_time) + { + report(LOG_WARNING, "Re-enabling account: %s", username); + node->first_failure = 0; + node->disabled = 0; + node->failures = 0; + node->locked_time = 0; + ret = 0; + } + } + else { + /* Check to see if the auth-fail window has expired. */ + if ((node->first_failure) && + difftime(now, node->first_failure) > session.afl_cfg->seconds) + { + report(LOG_INFO,"Resetting failure clock for user: %s\n", username); + node->first_failure = 0; + node->disabled = 0; + node->failures = 0; + node->locked_time = 0; + } + } + + shm_unlock(failed_key); + return ret; +} +#endif /* AFL */ + /* * Return 1 if this user has any ppp services configured. Used for * authorizing ppp/lcp requests diff -Naur ../tacacs+-F4.0.4.18/config.h.in ./config.h.in --- ../tacacs+-F4.0.4.18/config.h.in 2009-03-18 15:07:21.000000000 -0400 +++ ./config.h.in 2009-06-02 14:37:54.000000000 -0400 @@ -253,5 +253,7 @@ # define socklen_t int #endif +#undef AFL + #endif /* CONFIG_H */ diff -Naur ../tacacs+-F4.0.4.18/configure.in ./configure.in --- ../tacacs+-F4.0.4.18/configure.in 2009-03-18 15:07:21.000000000 -0400 +++ ./configure.in 2009-06-02 14:53:29.000000000 -0400 @@ -559,6 +559,37 @@ AC_SUBST(PROFLAGS) AC_SUBST(PROFLIBS) +dnl +dnl DISABLE AFL Support (Authentication Failure Locking) +dnl +AC_MSG_CHECKING(whether to enable AFL support) +AH_TEMPLATE(AFL, [define this to disable Authentication Failure Locking support]) +AC_ARG_ENABLE(afl, +[ --enable-afl Enable AFL support (default)], +[ case "$enable_afl" in + no) + AC_MSG_RESULT(no) + use_afl=0 + ;; + yes) + AC_MSG_RESULT(yes) + AC_DEFINE(AFL) + use_afl=1 + ;; + *) + AC_MSG_RESULT(yes) + AC_DEFINE(AFL) + use_afl=1 + ;; + esac ], + AC_MSG_RESULT(yes) + AC_DEFINE(AFL) + use_afl=1 +) +AC_SUBST(AFL) + + + # look for PAM AH_TEMPLATE(HAVE_PAM, [define if your system has libpam]) AC_CHECK_LIB([pam], [pam_start], diff -Naur ../tacacs+-F4.0.4.18/parse.c ./parse.c --- ../tacacs+-F4.0.4.18/parse.c 2009-03-17 14:40:29.000000000 -0400 +++ ./parse.c 2009-06-02 14:37:54.000000000 -0400 @@ -118,6 +118,9 @@ declare("PAM", S_pam); #endif declare("syslog", S_syslog); +#ifdef AFL + declare("auth-fail-lock", S_auth_fail_lock); +#endif } /* Return a keyword code if a keyword is recognized. 0 otherwise */ diff -Naur ../tacacs+-F4.0.4.18/parse.h ./parse.h --- ../tacacs+-F4.0.4.18/parse.h 2009-03-18 19:24:54.000000000 -0400 +++ ./parse.h 2009-06-02 14:51:39.000000000 -0400 @@ -90,3 +90,6 @@ # define S_pam 49 #endif #define S_syslog 50 +#ifdef AFL +#define S_auth_fail_lock 51 +#endif diff -Naur ../tacacs+-F4.0.4.18/tac_plus.c ./tac_plus.c --- ../tacacs+-F4.0.4.18/tac_plus.c 2009-03-18 17:04:29.000000000 -0400 +++ ./tac_plus.c 2009-06-02 15:18:58.000000000 -0400 @@ -99,6 +99,10 @@ report(LOG_NOTICE, "Received signal %d, shutting down", signum); if (childpid > 0) unlink(pidfilebuf); + +#ifdef AFL + cfg_destroy_failure_shm(); +#endif tac_exit(0); } @@ -115,6 +119,10 @@ tac_exit(1); } +#ifdef AFL + session.afl_cfg = NULL; +#endif + /* read the config file */ if (cfg_read_config(session.cfgfile)) { report(LOG_ERR, "Parsing %s", session.cfgfile); @@ -124,6 +132,11 @@ if (session.acctfile == NULL && !(session.flags & SESS_FLAG_ACCTSYSL)) session.acctfile = tac_strdup(TACPLUS_ACCTFILE); +#ifdef AFL + if(session.afl_cfg) + cfg_create_failure_shm(session.cfgfile, 'A'); +#endif + initialised++; report(LOG_NOTICE, "Version %s Initialized %d", version, initialised); @@ -332,6 +345,9 @@ signal(SIGUSR1, handler); signal(SIGHUP, handler); signal(SIGTERM, die); +#ifdef AFL + signal(SIGINT, die); +#endif signal(SIGPIPE, SIG_IGN); if (parse_only) @@ -883,6 +899,9 @@ #if __STDC__ fprintf(stdout, "__STDC__\n"); #endif +#if AFL + fprintf(stdout, "AFL\n"); +#endif return; } diff -Naur ../tacacs+-F4.0.4.18/tac_plus.h ./tac_plus.h --- ../tacacs+-F4.0.4.18/tac_plus.h 2009-03-18 19:24:54.000000000 -0400 +++ ./tac_plus.h 2009-06-02 14:55:49.000000000 -0400 @@ -149,6 +149,12 @@ # include #endif +#ifdef AFL +#include +#include +#include +#endif + #include "pathsl.h" #include "md5.h" @@ -278,6 +284,14 @@ #define NAS_PORT_MAX_LEN 255 +#ifdef AFL +struct afl_cfg { + int num_failures; + int seconds; + int lock_time; +}; +#endif + struct session { int session_id; /* host specific unique session id */ int aborted; /* have we received an abort flag? */ @@ -294,6 +308,9 @@ char *acctfile; /* name of accounting file */ char port[NAS_PORT_MAX_LEN+1]; /* For error reporting */ u_char version; /* version of last packet read */ +#ifdef AFL + struct afl_cfg *afl_cfg; /* authentication failure lock cfg */ +#endif }; extern struct session session; /* the session */ @@ -652,6 +669,12 @@ int cfg_read_config(char *); int cfg_user_exists(char *); int cfg_user_svc_default_is_permit(char *); +#ifdef AFL +void cfg_create_failure_shm(const char *, int); +void cfg_destroy_failure_shm(void); +void cfg_increment_failure(char *); +int cfg_is_user_disabled(char *); +#endif /* default_fn.c */ int default_fn(struct authen_data *); _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From heas at shrubbery.net Wed Jun 3 19:13:16 2009 From: heas at shrubbery.net (john heasley) Date: Wed, 3 Jun 2009 12:13:16 -0700 Subject: [tac_plus] Re: tac_plus problem In-Reply-To: <1018146459.20090602203945@melt.ru> References: <1018146459.20090602203945@melt.ru> Message-ID: <20090603191315.GT19268@shrubbery.net> > Jun 2 14:44:59.065: TPLUS: Accounting request created for 347933(rish) > Jun 2 14:44:59.065: TPLUS(00054F1D)/0/NB_WAIT/66461874: Started 5 sec timeout > Jun 2 14:44:59.069: TPLUS(00054F1D)/0/NB_WAIT: socket event 2 > Jun 2 14:44:59.069: TPLUS(00054F1D)/0/NB_WAIT: wrote 536 bytes > 5w6d: %LINK-3-UPDOWN: Interface Virtual-Access62, changed state to down > 5w6d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access62, changed state to down > > > And here is what we get in log of tac_plus: > > Tue Jun 2 17:42:06 2009 [10010]: session.peerip is 89.184.0.121 > Tue Jun 2 17:42:06 2009 [10010]: session request from 89.184.0.121 sock=2 > Tue Jun 2 17:42:06 2009 [46296]: connect from 89.184.0.121 [89.184.0.121] > Tue Jun 2 17:42:06 2009 [46296]: Waiting for packet > Tue Jun 2 17:42:11 2009 [46296]: 89.184.0.121 : fd 2 eof (connection closed) > Tue Jun 2 17:42:11 2009 [46296]: Error 89.184.0.121: start_session: > bad socket read > > This time tac_plus logs nothing in accounting log I suspect that this is not a tac_plus problem, rather router bug. It would seem that the router abruptly closes the connection before the accounting record is received. You could verify this with tcpdump to collect the packets and look for the FIN relative to the others. It should wait for an acknowledgement from the server. From Vasanthi.Raghuram at motorola.com Wed Jun 3 19:42:25 2009 From: Vasanthi.Raghuram at motorola.com (Raghuram Vasanthi-VRAGHUR1) Date: Wed, 3 Jun 2009 15:42:25 -0400 Subject: [tac_plus] TACACS+ server support for RSA SecurID Authentication Message-ID: Hi Does this TACACS+ server support RSA SecurID Authentication? also what operating systems does it support? thanks, VR --- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20090603/1502e5fa/attachment.html From heas at shrubbery.net Wed Jun 3 19:55:00 2009 From: heas at shrubbery.net (john heasley) Date: Wed, 3 Jun 2009 12:55:00 -0700 Subject: [tac_plus] Re: TACACS+ server support for RSA SecurID Authentication In-Reply-To: References: Message-ID: <20090603195500.GX19268@shrubbery.net> Wed, Jun 03, 2009 at 03:42:25PM -0400, Raghuram Vasanthi-VRAGHUR1: > Hi > > Does this TACACS+ server support RSA SecurID Authentication? also what > operating systems does it support? The only way to do this, because of RSA business policies, is with PAM. You must contact RSA for their PAM module. From heas at shrubbery.net Tue Jun 9 00:12:46 2009 From: heas at shrubbery.net (john heasley) Date: Tue, 9 Jun 2009 00:12:46 +0000 Subject: [tac_plus] Re: bad password/ban In-Reply-To: <20090602180453.GJ23025@corp.aol.com> References: <97c663810906011747i3de9be9u7a7b438bb163bfd7@mail.gmail.com> <20090602180453.GJ23025@corp.aol.com> Message-ID: <20090609001246.GE27694@shrubbery.net> Tue, Jun 02, 2009 at 02:04:53PM -0400, Mark Ellzey Thomas: > On Mon, Jun 01, 2009 at 05:47:43PM -0700, Mehrdad wrote: > > Hello, > > > > I'm using the Tacacs+ 4.0.4.16 and I'm looking for logging bad password or > > ban IP address after specified bad password is there any feature in this > > regard? > > That's my suggestion if there isn't > > > > > > Greetings Mehrdad, > > I wrote a patch to lock an account after the daemon notices a bunch of > auth failures from one user. Giving a quick glance to recent releases > it does not look as if this was accepted. > > You can find the original post/patch here: > http://www.shrubbery.net/pipermail/tac_plus/2008-June/000248.html As I mentioned before, my problem with this is that it can be used as a DOS. your co-worker could lock you out. right? i have no suggestions of how to deal with that problem properly. From heas at shrubbery.net Tue Jun 9 00:16:11 2009 From: heas at shrubbery.net (john heasley) Date: Tue, 9 Jun 2009 00:16:11 +0000 Subject: [tac_plus] Re: bad password/ban In-Reply-To: <97c663810906011747i3de9be9u7a7b438bb163bfd7@mail.gmail.com> References: <97c663810906011747i3de9be9u7a7b438bb163bfd7@mail.gmail.com> Message-ID: <20090609001611.GA10163@shrubbery.net> Mon, Jun 01, 2009 at 05:47:43PM -0700, Mehrdad: > Hello, > > I'm using the Tacacs+ 4.0.4.16 and I'm looking for logging bad password or recent versions should syslog failed logins: Jun 8 17:14:58 guelah tac_plus[22383]: login failure: hasdf 198.58.5.127 (198.58.5.127) tty2 > ban IP address after specified bad password is there any feature in this > regard? > That's my suggestion if there isn't > > > Thanks, > Mehrdad > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20090601/2349b4a7/attachment.html > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From mark.thomas at corp.aol.com Tue Jun 9 04:18:59 2009 From: mark.thomas at corp.aol.com (Mark Ellzey Thomas) Date: Tue, 9 Jun 2009 00:18:59 -0400 Subject: [tac_plus] Re: bad password/ban In-Reply-To: <20090609001246.GE27694@shrubbery.net> References: <97c663810906011747i3de9be9u7a7b438bb163bfd7@mail.gmail.com> <20090602180453.GJ23025@corp.aol.com> <20090609001246.GE27694@shrubbery.net> Message-ID: <20090609041859.GA410@corp.aol.com> On Mon, Jun 08, 2009 at 08:12:46PM -0400, john heasley wrote: > As I mentioned before, my problem with this is that it can be used as a DOS. > your co-worker could lock you out. right? i have no suggestions of how to > deal with that problem properly. Yeah, I totally see where you are coming from. In my mind the risk is a trade-off. Office antics like locking out your coworkers account would result in even more evil retaliation at our place of work :) >From the perspective of a security engineer - it is much better to have a single user be a little annoyed that their account is locked temporarily than to have their account compromised due to a brute force. Still, the concept of temporarily disabling accounts due to excessive failures is not a new idea. Many authentication systems implement such mechanisms, and many industry type audits require such features. It's also a nice failsafe when all of your staff who monitor such events are home and in bed. Maybe a more solid approach is to further modify this patch so that you can optionally disable account based on user/client-addr (as suggested by others in this thread). The extra space is negligible and probably a good idea in the long run. From mehrdad at ippacket.org Tue Jun 9 02:19:09 2009 From: mehrdad at ippacket.org (Mehrdad) Date: Mon, 8 Jun 2009 19:19:09 -0700 Subject: [tac_plus] Re: bad password/ban In-Reply-To: <20090609001611.GA10163@shrubbery.net> References: <97c663810906011747i3de9be9u7a7b438bb163bfd7@mail.gmail.com> <20090609001611.GA10163@shrubbery.net> Message-ID: <97c663810906081919h6263f8d9rddad1bc5af2dc24a@mail.gmail.com> I can't see anything at syslog for login failure, I'm using 4.0.4.16 , how can i enable syslog for it? On Mon, Jun 8, 2009 at 5:16 PM, john heasley wrote: > Mon, Jun 01, 2009 at 05:47:43PM -0700, Mehrdad: > > Hello, > > > > I'm using the Tacacs+ 4.0.4.16 and I'm looking for logging bad password > or > > recent versions should syslog failed logins: > > Jun 8 17:14:58 guelah tac_plus[22383]: login failure: hasdf 198.58.5.127 > (198.58.5.127) tty2 > > > ban IP address after specified bad password is there any feature in this > > regard? > > That's my suggestion if there isn't > > > > > > Thanks, > > Mehrdad > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > http://www.shrubbery.net/pipermail/tac_plus/attachments/20090601/2349b4a7/attachment.html > > _______________________________________________ > > tac_plus mailing list > > tac_plus at shrubbery.net > > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20090608/b8a53631/attachment.html From dan.schmidt at uplinkdata.com Tue Jun 9 14:41:40 2009 From: dan.schmidt at uplinkdata.com (Schmidt, Daniel) Date: Tue, 9 Jun 2009 08:41:40 -0600 Subject: [tac_plus] Re: bad password/ban In-Reply-To: <20090609041859.GA410@corp.aol.com> References: <97c663810906011747i3de9be9u7a7b438bb163bfd7@mail.gmail.com><20090602180453.GJ23025@corp.aol.com><20090609001246.GE27694@shrubbery.net> <20090609041859.GA410@corp.aol.com> Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D691@che-exch-003.uplinkdata.com> I was also concerned with this, yet was satisfied with the trade off. It is also a feather in the cap against those who rail, "We need to dump this open source thing and get a real Cisco Tacacs server!" As for a coworker doing a DOS attack, would that not result in immediate dismissal at most places of employment? Perhaps banning by IP, instead of username, as fail2ban does would prevent this. There are a hundred ways you can accidentally get locked out with tac_plus. This would merely be one more, and it is an option that is off by default. Have a look at the code, it *looks* to be well thought out. -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Mark Ellzey Thomas Sent: Monday, June 08, 2009 10:19 PM To: john heasley Cc: Mehrdad; tac_plus at shrubbery.net Subject: [tac_plus] Re: bad password/ban On Mon, Jun 08, 2009 at 08:12:46PM -0400, john heasley wrote: > As I mentioned before, my problem with this is that it can be used as a DOS. > your co-worker could lock you out. right? i have no suggestions of how to > deal with that problem properly. Yeah, I totally see where you are coming from. In my mind the risk is a trade-off. Office antics like locking out your coworkers account would result in even more evil retaliation at our place of work :) >From the perspective of a security engineer - it is much better to have a single user be a little annoyed that their account is locked temporarily than to have their account compromised due to a brute force. Still, the concept of temporarily disabling accounts due to excessive failures is not a new idea. Many authentication systems implement such mechanisms, and many industry type audits require such features. It's also a nice failsafe when all of your staff who monitor such events are home and in bed. Maybe a more solid approach is to further modify this patch so that you can optionally disable account based on user/client-addr (as suggested by others in this thread). The extra space is negligible and probably a good idea in the long run. _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From dan.schmidt at uplinkdata.com Tue Jun 9 15:58:50 2009 From: dan.schmidt at uplinkdata.com (Schmidt, Daniel) Date: Tue, 9 Jun 2009 09:58:50 -0600 Subject: [tac_plus] firewall 0.0.0.0?? Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D695@che-exch-003.uplinkdata.com> Hum... Anybody ever noticed that, when you try to enable on a PIX, your source ip is given as 0.0.0.0? As of yet, I am unsure whether to blame tac_plus or the pix. 2009-06-09 09:26:06: User 'homer' not allowed from source '0.0.0.0' in 'BN'->'host_allow' 2009-06-09 09:26:09: User 'homer' not allowed from source '0.0.0.0' in 'BN'->'host_allow' If I allow 0.0.0.0 as a source and look at the tac_pairs I get: service=shell cmd* priv-lvl=15 idletime=10 2009-06-09 09:36:33: User 'homer' granted access to device '192.168.168.168' in group 'BN' from '172.16.25.17' service=shell cmd=enable 2009-06-09 09:37:00: User 'homer' allowed command 'enable' to device '192.168.168.168' in 'BN'->'command_permit' service=shell cmd=enable 2009-06-09 09:37:00: User 'homer' allowed command 'enable' to device '192.168.168.168' in 'BN'->'command_permit' service=shell cmd* priv-lvl=15 idletime=10 2009-06-09 09:37:02: User 'homer' granted access to device '192.168.168.168' in group 'BN' from '172.16.25.17' (Notice also, firewall doesn't give a cmd-arg= at the end. Odd.) From dan.schmidt at uplinkdata.com Tue Jun 9 16:25:09 2009 From: dan.schmidt at uplinkdata.com (Schmidt, Daniel) Date: Tue, 9 Jun 2009 10:25:09 -0600 Subject: [tac_plus] More firewall grief Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D698@che-exch-003.uplinkdata.com> My apologies for filling up your inboxes, but I thought this was noteworthy. Anybody ever noticed this? Tac_pairs are returned for login, enable, and disable. However, for the second enable I get no tac_pairs returned - it is like the connection suddenly died. In fact, this login below was completely open - I'm not using an after authorization script and everything is allowed. I regret, I do not have a spare firewall to debug on. (Spare switches & routers, plenty, but no spare pix or asa) FW> FW> en Password: ******** FW# disa FW> en Command authorization failed FW> en Command authorization failed FW> From heas at shrubbery.net Tue Jun 9 16:55:04 2009 From: heas at shrubbery.net (john heasley) Date: Tue, 9 Jun 2009 09:55:04 -0700 Subject: [tac_plus] Re: firewall 0.0.0.0?? In-Reply-To: <05CC562AFB5A9446A1BC3F66AD04A3BC70D695@che-exch-003.uplinkdata.com> References: <05CC562AFB5A9446A1BC3F66AD04A3BC70D695@che-exch-003.uplinkdata.com> Message-ID: <20090609165504.GF25281@shrubbery.net> Tue, Jun 09, 2009 at 09:58:50AM -0600, Schmidt, Daniel: > Hum... Anybody ever noticed that, when you try to enable on a PIX, your > source ip is given as 0.0.0.0? As of yet, I am unsure whether to blame > tac_plus or the pix. > > 2009-06-09 09:26:06: User 'homer' not allowed from source '0.0.0.0' in > 'BN'->'host_allow' > 2009-06-09 09:26:09: User 'homer' not allowed from source '0.0.0.0' in > 'BN'->'host_allow' i'd lean toward your script. tacacs gets the ip from the tcp socket. > If I allow 0.0.0.0 as a source and look at the tac_pairs I get: > > service=shell > cmd* > priv-lvl=15 > idletime=10 > 2009-06-09 09:36:33: User 'homer' granted access to device > '192.168.168.168' in group 'BN' from '172.16.25.17' > service=shell > cmd=enable > 2009-06-09 09:37:00: User 'homer' allowed command 'enable' to device > '192.168.168.168' in 'BN'->'command_permit' > service=shell > cmd=enable > 2009-06-09 09:37:00: User 'homer' allowed command 'enable' to device > '192.168.168.168' in 'BN'->'command_permit' > service=shell > cmd* > priv-lvl=15 > idletime=10 > 2009-06-09 09:37:02: User 'homer' granted access to device > '192.168.168.168' in group 'BN' from '172.16.25.17' > > (Notice also, firewall doesn't give a cmd-arg= at the end. Odd.) > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From heas at shrubbery.net Tue Jun 9 16:58:06 2009 From: heas at shrubbery.net (john heasley) Date: Tue, 9 Jun 2009 09:58:06 -0700 Subject: [tac_plus] Re: More firewall grief In-Reply-To: <05CC562AFB5A9446A1BC3F66AD04A3BC70D698@che-exch-003.uplinkdata.com> References: <05CC562AFB5A9446A1BC3F66AD04A3BC70D698@che-exch-003.uplinkdata.com> Message-ID: <20090609165806.GH25281@shrubbery.net> Tue, Jun 09, 2009 at 10:25:09AM -0600, Schmidt, Daniel: > My apologies for filling up your inboxes, but I thought this was > noteworthy. > > Anybody ever noticed this? Tac_pairs are returned for login, enable, > and disable. However, for the second enable I get no tac_pairs returned > - it is like the connection suddenly died. In fact, this login below > was completely open - I'm not using an after authorization script and > everything is allowed. thats a device bug. each tacacs transaction is autonomous. > I regret, I do not have a spare firewall to debug on. (Spare switches & > routers, plenty, but no spare pix or asa) > > FW> > FW> en > Password: ******** > FW# disa > FW> en > Command authorization failed > FW> en > Command authorization failed > FW> > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From dan.schmidt at uplinkdata.com Tue Jun 9 17:40:47 2009 From: dan.schmidt at uplinkdata.com (Schmidt, Daniel) Date: Tue, 9 Jun 2009 11:40:47 -0600 Subject: [tac_plus] Re: firewall 0.0.0.0?? In-Reply-To: <20090609165504.GF25281@shrubbery.net> References: <05CC562AFB5A9446A1BC3F66AD04A3BC70D695@che-exch-003.uplinkdata.com> <20090609165504.GF25281@shrubbery.net> Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D69D@che-exch-003.uplinkdata.com> Rather unlikely seeing as how a router/switch never yields a 0.0.0.0. In other words, if it was a bug I would see it on other places and I do not. Also, there is no 0.0.0.0 anywhere in my script, and mind that variable is just a string! If the problem was in my script, the variable would be empty, or it would just plain crash, it's impossible for the script to set 0.0.0.0 as it had to come from somewhere. http://pastie.org/506002 The firewall does not send a cmd-arg=, which was not expected. That will be fixed. -----Original Message----- From: john heasley [mailto:heas at shrubbery.net] Sent: Tuesday, June 09, 2009 10:55 AM To: Schmidt, Daniel Cc: tac_plus at shrubbery.net Subject: Re: [tac_plus] firewall 0.0.0.0?? Tue, Jun 09, 2009 at 09:58:50AM -0600, Schmidt, Daniel: > Hum... Anybody ever noticed that, when you try to enable on a PIX, your > source ip is given as 0.0.0.0? As of yet, I am unsure whether to blame > tac_plus or the pix. > > 2009-06-09 09:26:06: User 'homer' not allowed from source '0.0.0.0' in > 'BN'->'host_allow' > 2009-06-09 09:26:09: User 'homer' not allowed from source '0.0.0.0' in > 'BN'->'host_allow' i'd lean toward your script. tacacs gets the ip from the tcp socket. > If I allow 0.0.0.0 as a source and look at the tac_pairs I get: > > service=shell > cmd* > priv-lvl=15 > idletime=10 > 2009-06-09 09:36:33: User 'homer' granted access to device > '192.168.168.168' in group 'BN' from '172.16.25.17' > service=shell > cmd=enable > 2009-06-09 09:37:00: User 'homer' allowed command 'enable' to device > '192.168.168.168' in 'BN'->'command_permit' > service=shell > cmd=enable > 2009-06-09 09:37:00: User 'homer' allowed command 'enable' to device > '192.168.168.168' in 'BN'->'command_permit' > service=shell > cmd* > priv-lvl=15 > idletime=10 > 2009-06-09 09:37:02: User 'homer' granted access to device > '192.168.168.168' in group 'BN' from '172.16.25.17' > > (Notice also, firewall doesn't give a cmd-arg= at the end. Odd.) > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From heas at shrubbery.net Tue Jun 9 18:04:51 2009 From: heas at shrubbery.net (john heasley) Date: Tue, 9 Jun 2009 11:04:51 -0700 Subject: [tac_plus] Re: firewall 0.0.0.0?? In-Reply-To: <05CC562AFB5A9446A1BC3F66AD04A3BC70D69D@che-exch-003.uplinkdata.com> References: <05CC562AFB5A9446A1BC3F66AD04A3BC70D695@che-exch-003.uplinkdata.com> <20090609165504.GF25281@shrubbery.net> <05CC562AFB5A9446A1BC3F66AD04A3BC70D69D@che-exch-003.uplinkdata.com> Message-ID: <20090609180451.GL25281@shrubbery.net> Tue, Jun 09, 2009 at 11:40:47AM -0600, Schmidt, Daniel: > Rather unlikely seeing as how a router/switch never yields a 0.0.0.0. > In other words, if it was a bug I would see it on other places and I do > not. Also, there is no 0.0.0.0 anywhere in my script, and mind that > variable is just a string! If the problem was in my script, the > variable would be empty, or it would just plain crash, it's impossible > for the script to set 0.0.0.0 as it had to come from somewhere. > > http://pastie.org/506002 I think that you're passing $address to your script. $address is rem_addr, which is: An ASCII string that describes the user's remote location. This field is optional (since the information may not be available). It is intended to hold a network address if the user is connected via a network, a caller ID is the user is connected via ISDN or a POTS, or any other remote location information that is available. This field value is client specified. i think you really want $ip, the IP of PIX? if you really want $address, then you're at the mercy of the PIX to fill that field in the tacacs request. > The firewall does not send a cmd-arg=, which was not expected. That > will be fixed. that is the PIX's fault. > -----Original Message----- > From: john heasley [mailto:heas at shrubbery.net] > Sent: Tuesday, June 09, 2009 10:55 AM > To: Schmidt, Daniel > Cc: tac_plus at shrubbery.net > Subject: Re: [tac_plus] firewall 0.0.0.0?? > > Tue, Jun 09, 2009 at 09:58:50AM -0600, Schmidt, Daniel: > > Hum... Anybody ever noticed that, when you try to enable on a PIX, > your > > source ip is given as 0.0.0.0? As of yet, I am unsure whether to > blame > > tac_plus or the pix. > > > > 2009-06-09 09:26:06: User 'homer' not allowed from source '0.0.0.0' in > > 'BN'->'host_allow' > > 2009-06-09 09:26:09: User 'homer' not allowed from source '0.0.0.0' in > > 'BN'->'host_allow' > > i'd lean toward your script. tacacs gets the ip from the tcp socket. > > > If I allow 0.0.0.0 as a source and look at the tac_pairs I get: > > > > service=shell > > cmd* > > priv-lvl=15 > > idletime=10 > > 2009-06-09 09:36:33: User 'homer' granted access to device > > '192.168.168.168' in group 'BN' from '172.16.25.17' > > service=shell > > cmd=enable > > 2009-06-09 09:37:00: User 'homer' allowed command 'enable' to device > > '192.168.168.168' in 'BN'->'command_permit' > > service=shell > > cmd=enable > > 2009-06-09 09:37:00: User 'homer' allowed command 'enable' to device > > '192.168.168.168' in 'BN'->'command_permit' > > service=shell > > cmd* > > priv-lvl=15 > > idletime=10 > > 2009-06-09 09:37:02: User 'homer' granted access to device > > '192.168.168.168' in group 'BN' from '172.16.25.17' > > > > (Notice also, firewall doesn't give a cmd-arg= at the end. Odd.) > > _______________________________________________ > > tac_plus mailing list > > tac_plus at shrubbery.net > > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From dan.schmidt at uplinkdata.com Tue Jun 9 18:13:31 2009 From: dan.schmidt at uplinkdata.com (Schmidt, Daniel) Date: Tue, 9 Jun 2009 12:13:31 -0600 Subject: [tac_plus] Re: firewall 0.0.0.0?? In-Reply-To: <20090609180451.GL25281@shrubbery.net> References: <05CC562AFB5A9446A1BC3F66AD04A3BC70D695@che-exch-003.uplinkdata.com> <20090609165504.GF25281@shrubbery.net> <05CC562AFB5A9446A1BC3F66AD04A3BC70D69D@che-exch-003.uplinkdata.com> <20090609180451.GL25281@shrubbery.net> Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D6A2@che-exch-003.uplinkdata.com> That is exactly what I want. So, we see the user coming from 0.0.0.0 instead of a valid IP. The initial login is successful, so we see that the PIX does at least that right. After that, it returns 0.0.0.0. Gar... do I really want to open a tac case and argue with those guys? It would take at least a week to get them to even FIND the problem. Maybe I'll just put 0.0.0.0 in all my "host_allow" lists. -----Original Message----- From: john heasley [mailto:heas at shrubbery.net] Sent: Tuesday, June 09, 2009 12:05 PM To: Schmidt, Daniel Cc: john heasley; tac_plus at shrubbery.net Subject: Re: [tac_plus] firewall 0.0.0.0?? Tue, Jun 09, 2009 at 11:40:47AM -0600, Schmidt, Daniel: > Rather unlikely seeing as how a router/switch never yields a 0.0.0.0. > In other words, if it was a bug I would see it on other places and I do > not. Also, there is no 0.0.0.0 anywhere in my script, and mind that > variable is just a string! If the problem was in my script, the > variable would be empty, or it would just plain crash, it's impossible > for the script to set 0.0.0.0 as it had to come from somewhere. > > http://pastie.org/506002 I think that you're passing $address to your script. $address is rem_addr, which is: An ASCII string that describes the user's remote location. This field is optional (since the information may not be available). It is intended to hold a network address if the user is connected via a network, a caller ID is the user is connected via ISDN or a POTS, or any other remote location information that is available. This field value is client specified. i think you really want $ip, the IP of PIX? if you really want $address, then you're at the mercy of the PIX to fill that field in the tacacs request. > The firewall does not send a cmd-arg=, which was not expected. That > will be fixed. that is the PIX's fault. > -----Original Message----- > From: john heasley [mailto:heas at shrubbery.net] > Sent: Tuesday, June 09, 2009 10:55 AM > To: Schmidt, Daniel > Cc: tac_plus at shrubbery.net > Subject: Re: [tac_plus] firewall 0.0.0.0?? > > Tue, Jun 09, 2009 at 09:58:50AM -0600, Schmidt, Daniel: > > Hum... Anybody ever noticed that, when you try to enable on a PIX, > your > > source ip is given as 0.0.0.0? As of yet, I am unsure whether to > blame > > tac_plus or the pix. > > > > 2009-06-09 09:26:06: User 'homer' not allowed from source '0.0.0.0' in > > 'BN'->'host_allow' > > 2009-06-09 09:26:09: User 'homer' not allowed from source '0.0.0.0' in > > 'BN'->'host_allow' > > i'd lean toward your script. tacacs gets the ip from the tcp socket. > > > If I allow 0.0.0.0 as a source and look at the tac_pairs I get: > > > > service=shell > > cmd* > > priv-lvl=15 > > idletime=10 > > 2009-06-09 09:36:33: User 'homer' granted access to device > > '192.168.168.168' in group 'BN' from '172.16.25.17' > > service=shell > > cmd=enable > > 2009-06-09 09:37:00: User 'homer' allowed command 'enable' to device > > '192.168.168.168' in 'BN'->'command_permit' > > service=shell > > cmd=enable > > 2009-06-09 09:37:00: User 'homer' allowed command 'enable' to device > > '192.168.168.168' in 'BN'->'command_permit' > > service=shell > > cmd* > > priv-lvl=15 > > idletime=10 > > 2009-06-09 09:37:02: User 'homer' granted access to device > > '192.168.168.168' in group 'BN' from '172.16.25.17' > > > > (Notice also, firewall doesn't give a cmd-arg= at the end. Odd.) > > _______________________________________________ > > tac_plus mailing list > > tac_plus at shrubbery.net > > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From heas at shrubbery.net Tue Jun 9 18:15:34 2009 From: heas at shrubbery.net (john heasley) Date: Tue, 9 Jun 2009 11:15:34 -0700 Subject: [tac_plus] Re: firewall 0.0.0.0?? In-Reply-To: <05CC562AFB5A9446A1BC3F66AD04A3BC70D6A2@che-exch-003.uplinkdata.com> References: <05CC562AFB5A9446A1BC3F66AD04A3BC70D695@che-exch-003.uplinkdata.com> <20090609165504.GF25281@shrubbery.net> <05CC562AFB5A9446A1BC3F66AD04A3BC70D69D@che-exch-003.uplinkdata.com> <20090609180451.GL25281@shrubbery.net> <05CC562AFB5A9446A1BC3F66AD04A3BC70D6A2@che-exch-003.uplinkdata.com> Message-ID: <20090609181534.GM25281@shrubbery.net> Tue, Jun 09, 2009 at 12:13:31PM -0600, Schmidt, Daniel: > That is exactly what I want. So, we see the user coming from 0.0.0.0 > instead of a valid IP. The initial login is successful, so we see that > the PIX does at least that right. After that, it returns 0.0.0.0. > > Gar... do I really want to open a tac case and argue with those guys? SOL, I'm afraid. From mgibbs at verisign.com Tue Jun 9 18:33:58 2009 From: mgibbs at verisign.com (Gibbs, Michael) Date: Tue, 9 Jun 2009 14:33:58 -0400 Subject: [tac_plus] Re: Working Command Authorization Script In-Reply-To: <05CC562AFB5A9446A1BC3F66AD04A3BC70D6A2@che-exch-003.uplinkdata.com> Message-ID: Greetings, I have been playing with after authorization using Barry's script as an example. What I have seen is that TACACS never calls the script after the initial authentication and authorization is done during login. This means that the command control feature used in the script or for after authorization can't work. Is this expected or am I missing a configuration? Tacacs 4.0.18: group = LimitedAccess { default service = permit service = exec { priv-lvl=15 idletime=15 timeout=0 } after authorization "/app/tacacs/etc/auth.pl $user $name $address /app/tacacs/etc/allow" } aaa new-model aaa authentication login default group tacacs+ line aaa authorization exec default group tacacs+ if-authenticated Thanks, Mike Fri, Apr 03, 2009 at 05:58:32PM +0100, Barry Stephen (YDD08) Derwent Shared Services: > I posted the other day about providing some users different levels of > access depending on the specific device they logged onto, in my case > Access versus Distribution & Core switches. > > Having read previous responses from various people I have managed to > create a working authorization script which checks what NAS a user > logged onto and if the NAS/Switch is in a specific list the commands are > checked against a list and only those commands are permitted. For all > other NASes (those not in the list) all commands are allowed. > > It took me a while to realise that the script is effectively taking on > the role of the tacacs+ deamon to some extent, that is to say that it is > not returning config/options to the tac_plus deamon in config file > format but direct to the NAS/switch. In any case, in this example we > simply say allow or deny rather than passing any AV pairs back to the > NAS. > > It is important to parse STDIN to see what command the NAS is requesting > auth for. > > I am using the after authorization method as the before authorization > method seemed a little harder to get working. > > This is my tac_plus.conf definition for these group of people: > > # Read/Write Access to non distribution devices - All commands > authorised > group = rw-except-distribution { > default service = permit > service = exec { > priv-lvl=15 > idletime=15 > timeout=0 > } > after authorization "/usr/bin/perl /etc/tac_plus_auth.pl $user > $name $address" > } > > I pass username, nas ip address and client ip address to my script but > only use nas address ($name) in my script. In my case $name is the NAS > IP address but possibly may not be in all cases. From mgibbs at verisign.com Tue Jun 9 18:46:16 2009 From: mgibbs at verisign.com (Gibbs, Michael) Date: Tue, 9 Jun 2009 14:46:16 -0400 Subject: [tac_plus] Re: Working Command Authorization Script In-Reply-To: <05CC562AFB5A9446A1BC3F66AD04A3BC70D6A7@che-exch-003.uplinkdata.com> Message-ID: Your right. I can't believe I missed that and tested on the only pair without those commands on. Thanks for the quick correction. Mike > -----Original Message----- > From: Schmidt, Daniel [mailto:dan.schmidt at uplinkdata.com] > Sent: Tuesday, June 09, 2009 2:39 PM > To: Gibbs, Michael; tac_plus at shrubbery.net > Subject: RE: [tac_plus] Re: Working Command Authorization Script > > Works fine for me. Haven't seen your script though. You > could just use mine on tacacs.org. > > Or, one thing I am noticing, you aren't authorizing commands. > > aaa authorization config-commands > aaa authorization commands 1 default group tacacs+ none aaa > authorization commands 15 default group tacacs+ none > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Gibbs, Michael > Sent: Tuesday, June 09, 2009 12:34 PM > To: tac_plus at shrubbery.net > Subject: [tac_plus] Re: Working Command Authorization Script > > Greetings, > > I have been playing with after authorization using Barry's > script as an example. What I have seen is that TACACS never > calls the script after the initial authentication and > authorization is done during login. This means that the > command control feature used in the script or for after > authorization can't work. Is this expected or am I missing a > configuration? > > Tacacs 4.0.18: > group = LimitedAccess { > default service = permit > service = exec { > priv-lvl=15 > idletime=15 > timeout=0 > } > after authorization "/app/tacacs/etc/auth.pl $user > $name $address /app/tacacs/etc/allow" > } > > aaa new-model > aaa authentication login default group tacacs+ line aaa > authorization exec default group tacacs+ if-authenticated > > Thanks, > Mike > > Fri, Apr 03, 2009 at 05:58:32PM +0100, Barry Stephen (YDD08) > Derwent Shared Services: > > I posted the other day about providing some users different > levels of > > access depending on the specific device they logged onto, > in my case > > Access versus Distribution & Core switches. > > > > Having read previous responses from various people I have > managed to > > create a working authorization script which checks what NAS a user > > logged onto and if the NAS/Switch is in a specific list the commands > are > > checked against a list and only those commands are > permitted. For all > > other NASes (those not in the list) all commands are allowed. > > > > It took me a while to realise that the script is > effectively taking on > > the role of the tacacs+ deamon to some extent, that is to > say that it > is > > not returning config/options to the tac_plus deamon in config file > > format but direct to the NAS/switch. In any case, in this > example we > > simply say allow or deny rather than passing any AV pairs > back to the > > NAS. > > > > It is important to parse STDIN to see what command the NAS is > requesting > > auth for. > > > > I am using the after authorization method as the before > authorization > > method seemed a little harder to get working. > > > > This is my tac_plus.conf definition for these group of people: > > > > # Read/Write Access to non distribution devices - All commands > > authorised group = rw-except-distribution { > > default service = permit > > service = exec { > > priv-lvl=15 > > idletime=15 > > timeout=0 > > } > > after authorization "/usr/bin/perl > /etc/tac_plus_auth.pl $user > > $name $address" > > } > > > > I pass username, nas ip address and client ip address to my > script but > > only use nas address ($name) in my script. In my case $name > is the NAS > > IP address but possibly may not be in all cases. > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > From dan.schmidt at uplinkdata.com Tue Jun 9 18:39:08 2009 From: dan.schmidt at uplinkdata.com (Schmidt, Daniel) Date: Tue, 9 Jun 2009 12:39:08 -0600 Subject: [tac_plus] Re: Working Command Authorization Script In-Reply-To: References: <05CC562AFB5A9446A1BC3F66AD04A3BC70D6A2@che-exch-003.uplinkdata.com> Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D6A7@che-exch-003.uplinkdata.com> Works fine for me. Haven't seen your script though. You could just use mine on tacacs.org. Or, one thing I am noticing, you aren't authorizing commands. aaa authorization config-commands aaa authorization commands 1 default group tacacs+ none aaa authorization commands 15 default group tacacs+ none -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Gibbs, Michael Sent: Tuesday, June 09, 2009 12:34 PM To: tac_plus at shrubbery.net Subject: [tac_plus] Re: Working Command Authorization Script Greetings, I have been playing with after authorization using Barry's script as an example. What I have seen is that TACACS never calls the script after the initial authentication and authorization is done during login. This means that the command control feature used in the script or for after authorization can't work. Is this expected or am I missing a configuration? Tacacs 4.0.18: group = LimitedAccess { default service = permit service = exec { priv-lvl=15 idletime=15 timeout=0 } after authorization "/app/tacacs/etc/auth.pl $user $name $address /app/tacacs/etc/allow" } aaa new-model aaa authentication login default group tacacs+ line aaa authorization exec default group tacacs+ if-authenticated Thanks, Mike Fri, Apr 03, 2009 at 05:58:32PM +0100, Barry Stephen (YDD08) Derwent Shared Services: > I posted the other day about providing some users different levels of > access depending on the specific device they logged onto, in my case > Access versus Distribution & Core switches. > > Having read previous responses from various people I have managed to > create a working authorization script which checks what NAS a user > logged onto and if the NAS/Switch is in a specific list the commands are > checked against a list and only those commands are permitted. For all > other NASes (those not in the list) all commands are allowed. > > It took me a while to realise that the script is effectively taking on > the role of the tacacs+ deamon to some extent, that is to say that it is > not returning config/options to the tac_plus deamon in config file > format but direct to the NAS/switch. In any case, in this example we > simply say allow or deny rather than passing any AV pairs back to the > NAS. > > It is important to parse STDIN to see what command the NAS is requesting > auth for. > > I am using the after authorization method as the before authorization > method seemed a little harder to get working. > > This is my tac_plus.conf definition for these group of people: > > # Read/Write Access to non distribution devices - All commands > authorised > group = rw-except-distribution { > default service = permit > service = exec { > priv-lvl=15 > idletime=15 > timeout=0 > } > after authorization "/usr/bin/perl /etc/tac_plus_auth.pl $user > $name $address" > } > > I pass username, nas ip address and client ip address to my script but > only use nas address ($name) in my script. In my case $name is the NAS > IP address but possibly may not be in all cases. _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From michael at michaelwm.com Tue Jun 16 04:11:56 2009 From: michael at michaelwm.com (Michael M.) Date: Mon, 15 Jun 2009 21:11:56 -0700 Subject: [tac_plus] ACL Message-ID: <26dc97ba-72c2-43c6-a92d-8ec9a6a86c61@michaelwm.com> Hello, I have a working configuration that I need to add ACL by host names. In the release F4.0.4.18 is that possible to use permit or deny based upon then ending portion of a host name? Example I connect from different locations from one ISP that has a common PTR of san.rr.com or dc.rr.com. What do I need to add to my config to have it resolve IPs and verify the host name in the allow? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.shrubbery.net/pipermail/tac_plus/attachments/20090615/3b7d63ed/attachment.html From heas at shrubbery.net Tue Jun 16 05:50:03 2009 From: heas at shrubbery.net (john heasley) Date: Tue, 16 Jun 2009 05:50:03 +0000 Subject: [tac_plus] Re: ACL In-Reply-To: <26dc97ba-72c2-43c6-a92d-8ec9a6a86c61@michaelwm.com> References: <26dc97ba-72c2-43c6-a92d-8ec9a6a86c61@michaelwm.com> Message-ID: <20090616055003.GF7023@shrubbery.net> Mon, Jun 15, 2009 at 09:11:56PM -0700, Michael M.: > Hello, > I have a working configuration that I need to add ACL by host names. In the release F4.0.4.18 is that possible to use permit or deny based upon then ending portion of a host name? Example I connect from different locations from one ISP that has a common PTR of san.rr.com or dc.rr.com. What do I need to add to my config to have it resolve IPs and verify the host name in the allow? it'd have to be coded, which I never added because I didnt want to have timeouts due to resolver problems. From dan.schmidt at uplinkdata.com Tue Jun 16 18:05:49 2009 From: dan.schmidt at uplinkdata.com (Schmidt, Daniel) Date: Tue, 16 Jun 2009 12:05:49 -0600 Subject: [tac_plus] Re: ACL In-Reply-To: <20090616055003.GF7023@shrubbery.net> References: <26dc97ba-72c2-43c6-a92d-8ec9a6a86c61@michaelwm.com> <20090616055003.GF7023@shrubbery.net> Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D728@che-exch-003.uplinkdata.com> Possibly could be done with authorization scripts, but I'm a little unclear as your definition of host. Is the device the host or are you the host? Don't san.rr.com and dc.rr.com resolve to different ranges that you could key on? -----Original Message----- From: tac_plus-bounces at shrubbery.net [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of john heasley Sent: Monday, June 15, 2009 11:50 PM To: Michael M. Cc: tac_plus at shrubbery.net Subject: [tac_plus] Re: ACL Mon, Jun 15, 2009 at 09:11:56PM -0700, Michael M.: > Hello, > I have a working configuration that I need to add ACL by host names. In the release F4.0.4.18 is that possible to use permit or deny based upon then ending portion of a host name? Example I connect from different locations from one ISP that has a common PTR of san.rr.com or dc.rr.com. What do I need to add to my config to have it resolve IPs and verify the host name in the allow? it'd have to be coded, which I never added because I didnt want to have timeouts due to resolver problems. _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From dan.schmidt at uplinkdata.com Tue Jun 16 18:33:53 2009 From: dan.schmidt at uplinkdata.com (Schmidt, Daniel) Date: Tue, 16 Jun 2009 12:33:53 -0600 Subject: [tac_plus] Re: ACL In-Reply-To: <6788ADE4-D21D-4385-9358-EA09897DD6F9@michaelwm.com> References: <26dc97ba-72c2-43c6-a92d-8ec9a6a86c61@michaelwm.com> <20090616055003.GF7023@shrubbery.net> <05CC562AFB5A9446A1BC3F66AD04A3BC70D728@che-exch-003.uplinkdata.com> <6788ADE4-D21D-4385-9358-EA09897DD6F9@michaelwm.com> Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D729@che-exch-003.uplinkdata.com> You can do it with my after authorization script on tacacs.com *IF* you can summarize those ranges as IP ranges in regular expressions. Surely, they don't have overlapping IP's. -----Original Message----- From: Michael M. [mailto:michael at michaelwm.com] Sent: Tuesday, June 16, 2009 12:19 PM To: Schmidt, Daniel Subject: Re: [tac_plus] Re: ACL I mean host or the pc doing the telnet in to a cisco router. I only want to be able to telnet from IPs that have DNS record of *.San.rr.com or *.DC.rr.com Thank you for your help. Sent from my iPhone On Jun 16, 2009, at 11:06 AM, "Schmidt, Daniel" wrote: > Possibly could be done with authorization scripts, but I'm a little > unclear as your definition of host. Is the device the host or are you > the host? Don't san.rr.com and dc.rr.com resolve to different ranges > that you could key on? > > -----Original Message----- > From: tac_plus-bounces at shrubbery.net > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of john heasley > Sent: Monday, June 15, 2009 11:50 PM > To: Michael M. > Cc: tac_plus at shrubbery.net > Subject: [tac_plus] Re: ACL > > Mon, Jun 15, 2009 at 09:11:56PM -0700, Michael M.: >> Hello, >> I have a working configuration that I need to add ACL by host names. > In the release F4.0.4.18 is that possible to use permit or deny based > upon then ending portion of a host name? Example I connect from > different locations from one ISP that has a common PTR of san.rr.com > or > dc.rr.com. What do I need to add to my config to have it resolve IPs > and > verify the host name in the allow? > > it'd have to be coded, which I never added because I didnt want to > have > timeouts due to resolver problems. > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From heas at shrubbery.net Tue Jun 16 20:36:49 2009 From: heas at shrubbery.net (john heasley) Date: Tue, 16 Jun 2009 20:36:49 +0000 Subject: [tac_plus] Re: ACL In-Reply-To: <05CC562AFB5A9446A1BC3F66AD04A3BC70D729@che-exch-003.uplinkdata.com> References: <26dc97ba-72c2-43c6-a92d-8ec9a6a86c61@michaelwm.com> <20090616055003.GF7023@shrubbery.net> <05CC562AFB5A9446A1BC3F66AD04A3BC70D728@che-exch-003.uplinkdata.com> <6788ADE4-D21D-4385-9358-EA09897DD6F9@michaelwm.com> <05CC562AFB5A9446A1BC3F66AD04A3BC70D729@che-exch-003.uplinkdata.com> Message-ID: <20090616203649.GS19405@shrubbery.net> Tue, Jun 16, 2009 at 12:33:53PM -0600, Schmidt, Daniel: > You can do it with my after authorization script on tacacs.com *IF* you > can summarize those ranges as IP ranges in regular expressions. Surely, > they don't have overlapping IP's. > > -----Original Message----- > From: Michael M. [mailto:michael at michaelwm.com] > Sent: Tuesday, June 16, 2009 12:19 PM > To: Schmidt, Daniel > Subject: Re: [tac_plus] Re: ACL > > I mean host or the pc doing the telnet in to a cisco router. I only > want to be able to telnet from IPs that have DNS record of > *.San.rr.com or *.DC.rr.com > > Thank you for your help. > > > Sent from my iPhone > > On Jun 16, 2009, at 11:06 AM, "Schmidt, > Daniel" > wrote: > > > Possibly could be done with authorization scripts, but I'm a little i'm thinking that an authentication script mechanism might be useful, though not certain how that might work. not to suggest that a knob allowing the name resolution might be unacceptable. > > unclear as your definition of host. Is the device the host or are you > > the host? Don't san.rr.com and dc.rr.com resolve to different ranges > > that you could key on? > > > > -----Original Message----- > > From: tac_plus-bounces at shrubbery.net > > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of john heasley > > Sent: Monday, June 15, 2009 11:50 PM > > To: Michael M. > > Cc: tac_plus at shrubbery.net > > Subject: [tac_plus] Re: ACL > > > > Mon, Jun 15, 2009 at 09:11:56PM -0700, Michael M.: > >> Hello, > >> I have a working configuration that I need to add ACL by host names. > > In the release F4.0.4.18 is that possible to use permit or deny based > > upon then ending portion of a host name? Example I connect from > > different locations from one ISP that has a common PTR of san.rr.com > > or > > dc.rr.com. What do I need to add to my config to have it resolve IPs > > and > > verify the host name in the allow? > > > > it'd have to be coded, which I never added because I didnt want to > > have > > timeouts due to resolver problems. > > _______________________________________________ > > tac_plus mailing list > > tac_plus at shrubbery.net > > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From dan.schmidt at uplinkdata.com Tue Jun 16 21:36:53 2009 From: dan.schmidt at uplinkdata.com (Schmidt, Daniel) Date: Tue, 16 Jun 2009 15:36:53 -0600 Subject: [tac_plus] Re: ACL In-Reply-To: <20090616203649.GS19405@shrubbery.net> References: <26dc97ba-72c2-43c6-a92d-8ec9a6a86c61@michaelwm.com> <20090616055003.GF7023@shrubbery.net> <05CC562AFB5A9446A1BC3F66AD04A3BC70D728@che-exch-003.uplinkdata.com> <6788ADE4-D21D-4385-9358-EA09897DD6F9@michaelwm.com> <05CC562AFB5A9446A1BC3F66AD04A3BC70D729@che-exch-003.uplinkdata.com> <20090616203649.GS19405@shrubbery.net> Message-ID: <05CC562AFB5A9446A1BC3F66AD04A3BC70D737@che-exch-003.uplinkdata.com> Hum... yeah, I could do that. Authorization script would be a good place to do it, reverse lookup the host address passed IF you are comparing it to string of chars instead of digits. Logic is easy: for item in host_addr, if item.isalpha and not '.', get nslookup(passed_host_addr). Then, match a regular expression. Would be easy, even for me. But, I can't do it today. Too busy. -----Original Message----- From: john heasley [mailto:heas at shrubbery.net] Sent: Tuesday, June 16, 2009 2:37 PM To: Schmidt, Daniel Cc: michael at michaelwm.com; tac_plus at shrubbery.net Subject: Re: [tac_plus] Re: ACL Tue, Jun 16, 2009 at 12:33:53PM -0600, Schmidt, Daniel: > You can do it with my after authorization script on tacacs.com *IF* you > can summarize those ranges as IP ranges in regular expressions. Surely, > they don't have overlapping IP's. > > -----Original Message----- > From: Michael M. [mailto:michael at michaelwm.com] > Sent: Tuesday, June 16, 2009 12:19 PM > To: Schmidt, Daniel > Subject: Re: [tac_plus] Re: ACL > > I mean host or the pc doing the telnet in to a cisco router. I only > want to be able to telnet from IPs that have DNS record of > *.San.rr.com or *.DC.rr.com > > Thank you for your help. > > > Sent from my iPhone > > On Jun 16, 2009, at 11:06 AM, "Schmidt, > Daniel" > wrote: > > > Possibly could be done with authorization scripts, but I'm a little i'm thinking that an authentication script mechanism might be useful, though not certain how that might work. not to suggest that a knob allowing the name resolution might be unacceptable. > > unclear as your definition of host. Is the device the host or are you > > the host? Don't san.rr.com and dc.rr.com resolve to different ranges > > that you could key on? > > > > -----Original Message----- > > From: tac_plus-bounces at shrubbery.net > > [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of john heasley > > Sent: Monday, June 15, 2009 11:50 PM > > To: Michael M. > > Cc: tac_plus at shrubbery.net > > Subject: [tac_plus] Re: ACL > > > > Mon, Jun 15, 2009 at 09:11:56PM -0700, Michael M.: > >> Hello, > >> I have a working configuration that I need to add ACL by host names. > > In the release F4.0.4.18 is that possible to use permit or deny based > > upon then ending portion of a host name? Example I connect from > > different locations from one ISP that has a common PTR of san.rr.com > > or > > dc.rr.com. What do I need to add to my config to have it resolve IPs > > and > > verify the host name in the allow? > > > > it'd have to be coded, which I never added because I didnt want to > > have > > timeouts due to resolver problems. > > _______________________________________________ > > tac_plus mailing list > > tac_plus at shrubbery.net > > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus From schilling2006 at gmail.com Fri Jun 26 15:41:37 2009 From: schilling2006 at gmail.com (schilling) Date: Fri, 26 Jun 2009 11:41:37 -0400 Subject: [tac_plus] tac_plus with pam->ldap authentication ldap server failure scenario Message-ID: Hi All, We get tac_plus working with pam for auth, which then consult ldap for authentication. Everything is working as expected. We put user name in tacacs.conf with login pam. Now we are trying to test the ldap failure scenario. If ldap is not available. The switch will still be able to communicate with tac_plus, then local username/passwd defined on the switch will not work since tac_plus is still available. Any configuration in tacacs to change this behavior? Thanks. Schilling From heas at shrubbery.net Sat Jun 27 20:41:39 2009 From: heas at shrubbery.net (john heasley) Date: Sat, 27 Jun 2009 13:41:39 -0700 Subject: [tac_plus] Re: tac_plus with pam->ldap authentication ldap server failure scenario In-Reply-To: References: Message-ID: <20090627204139.GB6342@shrubbery.net> Fri, Jun 26, 2009 at 11:41:37AM -0400, schilling: > Hi All, > > We get tac_plus working with pam for auth, which then consult ldap for > authentication. Everything is working as expected. We put user name > in tacacs.conf with login pam. > > Now we are trying to test the ldap failure scenario. If ldap is not > available. The switch will still be able to communicate with tac_plus, > then local username/passwd defined on the switch will not work since > tac_plus is still available. Any configuration in tacacs to change > this behavior? I wouldnt expect it to succeed if ldap is unavailable. i'd expect that either the ldap or pam aren't returning an error properly, or tacacs is not properly interpretting the error, or your device's configuration is incorrect.