From mmoody at staff.atlantic.net Fri Sep 2 14:20:24 2016 From: mmoody at staff.atlantic.net (Mason Moody) Date: Fri, 2 Sep 2016 10:20:24 -0400 Subject: [tac_plus] tacacs truncating some commands before performing authorization check Message-ID: <4905286b-ea3c-f8f8-8b34-c6b3ef61fa12@staff.atlantic.net> Hi, all, I'm running TACACS+ version 4.0.4.28 on Ubuntu 16.04, and I'm seeing in my testing of command authorization some odd truncation of commands. The relevant portion of my config limits a group of users to certain 'no' commands, in particular, 'no switchport mode access'. The config line looks like this: cmd = no { ... permit "switchport mode access " ... } My TACACS logs show that when I run the 'no switchport mode access' command from a Cisco 3550 (running IOS 12.2(44)SE6), I get an authorization failure result. The relevant log result shows that the command that's being compared against doesn't include the last term: [27071]: line 228 compare no permit 'switchport mode access ' & 'switchport mode ' no match The Cisco logs record the full command: %PARSER-5-CFGLOG_LOGGEDCMD: User:tmonkey logged command:switchport mode access Has anyone seen anything like this before? -- ____________ Mason Moody Network Security Engineer Atlantic.Net Phone: 800-422-2936 x4431 Int'l: +1-321-206-3731 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Anet_logo_side-by-side.gif Type: image/gif Size: 1113 bytes Desc: not available URL: From vadud3 at gmail.com Sun Sep 4 00:59:47 2016 From: vadud3 at gmail.com (Asif Iqbal) Date: Sat, 3 Sep 2016 20:59:47 -0400 Subject: [tac_plus] Revision control for tac_plus config file Message-ID: We have 24 different tacacs config for different instances based on different functionalities. We are 13 of us managing these config files. I like to add these change under revision control. What would be recommended revision control software for this? Some of the requirement for a Revision control software while editing a tacacs config file in our environment: - It can display active editor on a config file when requested - It will notify about the active editor and prevent others from simultaneous editing - It will allow reverting a config file to a previous version when necessary - It will have a clear log of who edited what and when (and why if available) Thanks -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From heas at shrubbery.net Sun Sep 4 09:55:30 2016 From: heas at shrubbery.net (heasley) Date: Sun, 4 Sep 2016 09:55:30 +0000 Subject: [tac_plus] Revision control for tac_plus config file In-Reply-To: References: Message-ID: <20160904095530.GB92223@shrubbery.net> Sat, Sep 03, 2016 at 08:59:47PM -0400, Asif Iqbal: > We have 24 different tacacs config for different instances based on > different functionalities. such as? > I like to add these change under revision control. > > What would be recommended revision control software for this? whatever you want to use. > Some of the requirement for a Revision control software while editing a > tacacs config file in our environment: these questions are all unrealted to tacacs. you're better off asking mail lists related to whatever SCM you would like to use. > - It can display active editor on a config file when requested > > - It will notify about the active editor and prevent others from > simultaneous editing > > - It will allow reverting a config file to a previous version when necessary > > - It will have a clear log of who edited what and when (and why if > available) From heas at shrubbery.net Tue Sep 6 16:16:59 2016 From: heas at shrubbery.net (heasley) Date: Tue, 6 Sep 2016 16:16:59 +0000 Subject: [tac_plus] tacacs truncating some commands before performing authorization check In-Reply-To: <4905286b-ea3c-f8f8-8b34-c6b3ef61fa12@staff.atlantic.net> References: <4905286b-ea3c-f8f8-8b34-c6b3ef61fa12@staff.atlantic.net> Message-ID: <20160906161659.GJ52381@shrubbery.net> Fri, Sep 02, 2016 at 10:20:24AM -0400, Mason Moody: > Hi, all, > > > I'm running TACACS+ version 4.0.4.28 on Ubuntu 16.04, and I'm seeing in > my testing of command authorization some odd truncation of commands. The > relevant portion of my config limits a group of users to certain 'no' > commands, in particular, 'no switchport mode access'. The config line > looks like this: > > cmd = no { > ... > permit "switchport mode access " > ... > } > > My TACACS logs show that when I run the 'no switchport mode access' > command from a Cisco 3550 (running IOS 12.2(44)SE6), I get an > authorization failure result. The relevant log result shows that the > command that's being compared against doesn't include the last term: > > [27071]: line 228 compare no permit 'switchport mode access ' & > 'switchport mode ' no match If you enable packet dumps, I suspect you will find that the device is sending the truncated line. > The Cisco logs record the full command: > > %PARSER-5-CFGLOG_LOGGEDCMD: User:tmonkey logged command:switchport mode > access > > Has anyone seen anything like this before? I have, but do not recall the specific command. There is probably a cisco document somewhere that defines what portion(s) of commands are sent for authorization; but i didnt find anything in a brief search. From heas at shrubbery.net Wed Sep 7 15:23:38 2016 From: heas at shrubbery.net (heasley) Date: Wed, 7 Sep 2016 15:23:38 +0000 Subject: [tac_plus] tacacs+ time restricted login In-Reply-To: References: Message-ID: <20160907152338.GD83245@shrubbery.net> Tue, Aug 30, 2016 at 01:53:42PM +0000, Pete .: > I'm using TACACS+ and I would like to grant user on my devices depending on time. > > 1)I would like a group of users to be authenticated only from 09:00 to 18:00 > > => I tryed using PAM pam_time.so without success PAM configuration can be difficult to do correctly. I suggest googling for configuration examples. > 2) I would like to change the group membership of some users depending on time ... > > Is it possible ? Change the config however you wish and kill -1 the daemon. you might also be able to use an authorization script that returns failures outside when a user is not allowed access. From philipp at redfish-solutions.com Mon Sep 12 04:21:42 2016 From: philipp at redfish-solutions.com (Philip Prindeville) Date: Sun, 11 Sep 2016 22:21:42 -0600 Subject: [tac_plus] [PATCH tac_plus] Avoid unnecessary marshalling when computing MD5 bitstream cipher Message-ID: <1473654102-31938-1-git-send-email-philipp@redfish-solutions.com> From: Philip Prindeville MD5Update() can be called iteratively, so there's no need for the data passed to it to be marshalled into contiguous storage. --- encrypt.c | 33 ++++++--------------------------- 1 file changed, 6 insertions(+), 27 deletions(-) diff --git a/encrypt.c b/encrypt.c index 90d4506..487f304 100644 --- a/encrypt.c +++ b/encrypt.c @@ -39,37 +39,16 @@ void create_md5_hash(int session_id, char *key, u_char version, u_char seq_no, u_char *prev_hash, u_char *hash) { - u_char *md_stream, *mdp; - int md_len; MD5_CTX mdcontext; - md_len = sizeof(session_id) + strlen(key) + sizeof(version) + - sizeof(seq_no); - - if (prev_hash) { - md_len += TAC_MD5_DIGEST_LEN; - } - mdp = md_stream = (u_char *) tac_malloc(md_len); - memcpy(mdp, &session_id, sizeof(session_id)); - mdp += sizeof(session_id); - - memcpy(mdp, key, strlen(key)); - mdp += strlen(key); - - memcpy(mdp, &version, sizeof(version)); - mdp += sizeof(version); - - memcpy(mdp, &seq_no, sizeof(seq_no)); - mdp += sizeof(seq_no); - - if (prev_hash) { - memcpy(mdp, prev_hash, TAC_MD5_DIGEST_LEN); - mdp += TAC_MD5_DIGEST_LEN; - } MD5Init(&mdcontext); - MD5Update(&mdcontext, md_stream, md_len); + MD5Update(&mdcontext, (u_char *)&session_id, sizeof(session_id)); + MD5Update(&mdcontext, key, strlen(key)); + MD5Update(&mdcontext, &version, sizeof(version)); + MD5Update(&mdcontext, &seq_no, sizeof(seq_no)); + if (prev_hash) + MD5Update(&mdcontext, prev_hash, TAC_MD5_DIGEST_LEN); MD5Final(hash, &mdcontext); - free(md_stream); return; } From philipp at redfish-solutions.com Mon Sep 12 04:21:43 2016 From: philipp at redfish-solutions.com (Philip Prindeville) Date: Sun, 11 Sep 2016 22:21:43 -0600 Subject: [tac_plus] [PATCH tac_plus] Improve report() functionality by leveraging standard C libraries Message-ID: <1473654103-31976-1-git-send-email-philipp@redfish-solutions.com> From: Philip Prindeville We don't need to do buffer management and overflow checking when there are libraries which do this for us. Use fmemopen() to format into a fixed-size buffer when using repeated *printf() calls. Make better use of the rich formatting capabilities of vfprintf(). Be consistent in: displaying octets as 2 hex digits; displaying session ids in both hex and decimal; displaying session ids in network-byte order. Make better use of report_hex(). Don't do hex dumps (of packets, buffers, etc) as 1 octet per line... that's just plain tedious. Capturing the return value of vfprintf() (in report()) is of dubious value since it (report()) is a void function. Don't pass a formatted buffer through fprintf() a 2nd time as "%s"... just use fwrite() instead. --- dump.c | 2 +- encrypt.c | 12 ++++----- report.c | 87 +++++++++++++++++++++++++++++++++++++-------------------------- 3 files changed, 57 insertions(+), 44 deletions(-) diff --git a/dump.c b/dump.c index db31e6a..f907bed 100644 --- a/dump.c +++ b/dump.c @@ -102,7 +102,7 @@ dump_header(u_char *pak) report(LOG_DEBUG, "PACKET: key=%s", session.key ? session.key : ""); report(LOG_DEBUG, "version %d (0x%x), type %d, seq no %d, flags 0x%x", hdr->version, hdr->version, hdr->type, hdr->seq_no, hdr->flags); - report(LOG_DEBUG, "session_id %u (0x%x), Data length %d (0x%x)", + report(LOG_DEBUG, "session_id %u (0x%08x), Data length %d (0x%x)", ntohl(hdr->session_id), ntohl(hdr->session_id), ntohl(hdr->datalength), ntohl(hdr->datalength)); diff --git a/encrypt.c b/encrypt.c index 487f304..47b2933 100644 --- a/encrypt.c +++ b/encrypt.c @@ -90,19 +90,17 @@ md5_xor(HDR *hdr, u_char *data, char *key) int k; report(LOG_DEBUG, - "hash: session_id=%u, key=%s, version=%d, seq_no=%d", - session_id, key, version, seq_no); + "hash: session_id=%u (0x%08x), key=%s, version=%d, seq_no=%d", + htonl(session_id), htonl(session_id), key, version, seq_no); if (prev_hashp) { report(LOG_DEBUG, "prev_hash:"); - for (k = 0; k < TAC_MD5_DIGEST_LEN; k++) - report(LOG_DEBUG, "0x%x", prev_hashp[k]); + report_hex(LOG_DEBUG, prev_hashp, TAC_MD5_DIGEST_LEN); } else { report(LOG_DEBUG, "no prev. hash"); } report(LOG_DEBUG, "hash: "); - for (k = 0; k < TAC_MD5_DIGEST_LEN; k++) - report(LOG_DEBUG, "0x%x", hash[k]); + report_hex(LOG_DEBUG, hash, TAC_MD5_DIGEST_LEN); } memcpy(last_hash, hash, TAC_MD5_DIGEST_LEN); prev_hashp = last_hash; @@ -117,7 +115,7 @@ md5_xor(HDR *hdr, u_char *data, char *key) } if (debug & DEBUG_XOR_FLAG) { report(LOG_DEBUG, - "data[%d] = 0x%x, xor'ed with hash[%d] = 0x%x -> 0x%x\n", + "data[%d] = 0x%02x, xor'ed with hash[%d] = 0x%02x -> 0x%02x", i + j, data[i + j], j, diff --git a/report.c b/report.c index 6d10813..a2c86c7 100644 --- a/report.c +++ b/report.c @@ -59,19 +59,24 @@ report(priority, fmt, va_alist) #endif { char msg[4096]; /* temporary string */ + size_t nchars; + FILE *mem; va_list ap; - int ret; + + mem = fmemopen(msg, sizeof(msg), "w"); #ifdef __STDC__ va_start(ap, fmt); #else va_start(ap); #endif - ret = vsnprintf(msg, sizeof(msg), fmt, ap); + vfprintf(mem, fmt, ap); va_end(ap); - if (ret < 0) - msg[0] = '\0'; + fflush(mem); + nchars = ftell(mem); + + fclose(mem); if (console) { if (!ostream) @@ -80,7 +85,8 @@ report(priority, fmt, va_alist) if (ostream) { if (priority == LOG_ERR) fprintf(ostream, "Error "); - fprintf(ostream, "%s\n", msg); + fwrite(msg, nchars, 1, ostream); + fputc('\n', ostream); } else syslog(LOG_ERR, "Cannot open /dev/console errno=%d", errno); } @@ -90,24 +96,27 @@ report(priority, fmt, va_alist) logfd = open(logfile, O_CREAT | O_WRONLY | O_APPEND, 0644); if (logfd >= 0) { - char buf[512]; time_t t = time(NULL); char *ct = ctime(&t); + FILE *flog; ct[24] = '\0'; + tac_lockfd(logfile, logfd); - sprintf(buf, "%s [%ld]: ", ct, (long)getpid()); - write(logfd, buf, strlen(buf)); + flog = fdopen(logfd, "a"); + + fprintf(flog, "%s [%ld]: ", ct, (long)getpid()); if (priority == LOG_ERR) - write(logfd, "Error ", 6); - write(logfd, msg, strlen(msg)); - write(logfd, "\n", 1); - close(logfd); + fputs("Error ", flog); + fwrite(msg, nchars, 1, flog); + fputc('\n', flog); + fclose(flog); } } if (single) { - fprintf(stderr, "%s\n", msg); + fwrite(msg, nchars, 1, stderr); + fputc('\n', stderr); } if (priority == LOG_ERR) @@ -121,32 +130,36 @@ void report_hex(int priority, u_char *p, int len) { char buf[256]; - char digit[10]; - int buflen; - int i; + size_t nchars; + unsigned i; + FILE *mem; if (len <= 0) return; - buf[0] = '\0'; - buflen = 0; - for (i = 0; i < len && i < 255; i++, p++) { + mem = fmemopen(buf, sizeof(buf), "w"); + + if (len > 255) + len = 255; + + for (i = 0; i < len; i++, p++) { - sprintf(digit, "0x%x ", *p); - strcat(buf, digit); - buflen += strlen(digit); + fprintf(mem, "0x%02x ", *p); - if (buflen > 75) { + if (ftell(mem) > 75) { + fflush(mem); report(priority, "%s", buf); - buf[0] = '\0'; - buflen = 0; + rewind(mem); } } - if (buf[0]) { + if (ftell(mem) > 0) { + fflush(mem); report(priority, "%s", buf); } + fclose(mem); + return; } @@ -155,8 +168,9 @@ void report_string(int priority, u_char *p, int len) { char buf[256]; - char *bufp = buf; + size_t nchars; int i, n; + FILE *mem; if (len <= 0) return; @@ -164,20 +178,21 @@ report_string(int priority, u_char *p, int len) if (len > 255) len = 255; - for (i = 0; i < len; i++) { + mem = fmemopen(buf, sizeof(buf), "w"); + + for (i = n = 0; i < len && n < len; i++, p++) { /* ASCII printable, else ... */ if (32 <= *p && *p <= 126) { - *bufp++ = *p++; + fputc(*p, mem); + ++n; } else { - n = snprintf(bufp, len - i, " 0x%x ", *p); - if (n >= len - i) - break; - bufp += n; - i += n - 1; - p++; + fprintf(mem, " 0x%02x ", *p); + n += 6; } } - *bufp = '\0'; + + fclose(mem); + report(priority, "%s", buf); } From philipp at redfish-solutions.com Mon Sep 12 04:47:55 2016 From: philipp at redfish-solutions.com (Philip Prindeville) Date: Sun, 11 Sep 2016 22:47:55 -0600 Subject: [tac_plus] [PATCH tac_plus] Add timestamps to stderr logging when running in foreground mode Message-ID: <1473655675-16199-1-git-send-email-philipp@redfish-solutions.com> From: Philip Prindeville When debugging certain issues (like shutting down idle client connections, etc) it's useful to have timestamps on the logging output, even when running in single-threaded mode (option -g). --- configure.ac | 24 ++++++++++++++++++++++++ report.c | 5 +++++ tac_plus.h | 2 ++ utils.c | 31 +++++++++++++++++++++++++++++++ 4 files changed, 62 insertions(+) diff --git a/configure.ac b/configure.ac index c9ecf95..7ad9083 100644 --- a/configure.ac +++ b/configure.ac @@ -720,6 +720,30 @@ AC_ARG_WITH(prof, AC_SUBST(PROFLAGS) AC_SUBST(PROFLIBS) +dnl +dnl USE_STDERR_TIMESTAMPS - Turn on timestamping on logging to stderr +dnl +AC_MSG_CHECKING(whether to enable foreground logging of timestamps support) +AH_TEMPLATE(USE_STDERR_TIMESTAMPS, [define this to enable support for including timestamps when foreground logging to stderr ]) +AC_ARG_ENABLE(stderr-timestamps, + AS_HELP_STRING([--enable-stderr-timestamps],[Log timestamps in stderr output in foreground mode]), +[ case "$enable_stderr_timestamps" in + no) + AC_MSG_RESULT(no) + ;; + yes) + AC_MSG_RESULT(yes) + AC_DEFINE(USE_STDERR_TIMESTAMPS) + ;; + *) + AC_MSG_RESULT(no) + ;; + esac ], + # ie: no --{enable,disable}-stderr-timestamps option, withval == "" + AC_MSG_RESULT(no) +) +dnl AC_SUBST(USE_STDERR_TIMESTAMPS) + # look for PAM AH_TEMPLATE(HAVE_PAM, [define if your system has libpam]) AC_CHECK_LIB([pam], [pam_start], diff --git a/report.c b/report.c index a2c86c7..dfa582a 100644 --- a/report.c +++ b/report.c @@ -115,6 +115,11 @@ report(priority, fmt, va_alist) } if (single) { +#ifdef USE_STDERR_TIMESTAMPS + const char *ts = tac_timestamp(); + fwrite(ts, strlen(ts), 1, stderr); + fputc(' ', stderr); +#endif fwrite(msg, nchars, 1, stderr); fputc('\n', stderr); } diff --git a/tac_plus.h b/tac_plus.h index 205f632..4bcd1f4 100644 --- a/tac_plus.h +++ b/tac_plus.h @@ -342,6 +342,8 @@ char *tac_strdup(char *); char *tac_make_string(u_char *, int); char *tac_find_substring(char *, char *); char *tac_realloc(char *, int); +const char *tac_timestamp(void); +const char *tac_iso_timestamp(void); /* do_acct.c */ int do_acct_file(struct acct_rec *); diff --git a/utils.c b/utils.c index 3b1ae59..d2919ff 100644 --- a/utils.c +++ b/utils.c @@ -241,3 +241,34 @@ tac_unlockfd(char *filename, int lockfd) } return(0); } + +const char * +tac_timestamp() +{ + static char buf[16]; + time_t now; + struct tm *tm; + static const char format[] = "%b %e %T"; + + time(&now); + tm = localtime(&now); + strftime(buf, sizeof(buf), format, tm); + + return buf; +} + +const char * +tac_iso_timestamp() +{ + static char buf[17]; + time_t now; + struct tm *tm; + static const char format[] = "%Y%m%dT%H%M%SZ"; + + time(&now); + tm = gmtime(&now); + strftime(buf, sizeof(buf), format, tm); + + return buf; +} + From spedersen.lists at gmail.com Mon Sep 12 14:16:45 2016 From: spedersen.lists at gmail.com (Sean) Date: Mon, 12 Sep 2016 07:16:45 -0700 Subject: [tac_plus] Full AAA logging / supported configuration Message-ID: I'm on F4.0.4.26. I've seen a few examples of logging AAA with tac_plus. The most documented is the "accounting" option. accounting syslog; -or- accountig file = /var/log/tac_plus.acct This works fine. I have it set up, logging correctly, logrotate running, etc. It?s also documented just about everywhere I?ve seen, but seems like it?s the only official means to log something. I'd like to log authentication and authorization as well, if possible. I've come across reference to the following configuration: accounting log = /var/log/tac_plus/accounting.log authentication log = /var/log/tac_plus/authentication.log authorization log = /var/log/tac_plus/authorization.log This seems to be either a) outdated or b) poorly referenced as it doesn't work globally. A reference configuration I have from a version so old it's expressed in a date format (201211021744) places it within an "id" container. id = tac_plus { accounting log = /var/log/tac_plus/accounting.log authentication log = /var/log/tac_plus/authentication.log authorization log = /var/log/tac_plus/authorization.log } I haven't tried this in v4 yet since I can't find (presumably) current reference for it, but it?s working in the older version. I've also found reference to setting the appropriate -d flags when running tac_plus and getting this information as more of a "happy accident" (their words) in that the debugged info will hit the syslog daemon and be shuffled to the appropriate log files vs. a means configured specifically in the tac_plus config file. What?s the most appropriate / supported way to log this information, if any? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From heas at shrubbery.net Mon Sep 12 19:42:59 2016 From: heas at shrubbery.net (heasley) Date: Mon, 12 Sep 2016 19:42:59 +0000 Subject: [tac_plus] Full AAA logging / supported configuration In-Reply-To: References: Message-ID: <20160912194259.GF24562@shrubbery.net> Mon, Sep 12, 2016 at 07:16:45AM -0700, Sean: > I'd like to log authentication and authorization as well, if possible. I've come across reference to the following configuration: > > accounting log = /var/log/tac_plus/accounting.log > > authentication log = /var/log/tac_plus/authentication.log > > authorization log = /var/log/tac_plus/authorization.log > > This seems to be either a) outdated or b) poorly referenced as it doesn't work globally. A reference configuration I have from a version so old it's expressed in a date format (201211021744) places it within an "id" container. > > > id = tac_plus { > > accounting log = /var/log/tac_plus/accounting.log > > authentication log = /var/log/tac_plus/authentication.log > > authorization log = /var/log/tac_plus/authorization.log > > } This must be another tacacs daemon. This implementation has never had an id clause that I am aware of. > I haven't tried this in v4 yet since I can't find (presumably) current reference for it, but it?s working in the older version. > > I've also found reference to setting the appropriate -d flags when running tac_plus and getting this information as more of a "happy accident" (their words) in that the debugged info will hit the syslog daemon and be shuffled to the appropriate log files vs. a means configured specifically in the tac_plus config file. > > What?s the most appropriate / supported way to log this information, if any? logging = syslog facility there used to be a logfile option, but it degraded performance for multiple daemons competing for one file. so, it is syslog only now. some syslog daemons allow the matching of messages to determine the logging location (or other actions). From spedersen.lists at gmail.com Mon Sep 12 20:09:57 2016 From: spedersen.lists at gmail.com (Sean) Date: Mon, 12 Sep 2016 13:09:57 -0700 Subject: [tac_plus] Full AAA logging / supported configuration In-Reply-To: <20160912194259.GF24562@shrubbery.net> References: <20160912194259.GF24562@shrubbery.net> Message-ID: <840667EA-7416-42AF-80F6-70EB0C7C7F35@gmail.com> It?s tac_plus, it?s just ancient. I believe it had something to do with MAVIS as well. The system(s) I?m running v4 on are using PAM instead of the MAVIS module. So more or less just enable the right debug levels and route to syslog, expecting to find things in auth.log, etc.? With accounting being the exception. If so, I will look into getting rsyslogd to route the data correctly. Thanks! On 9/12/16, 12:42 PM, "heasley" wrote: Mon, Sep 12, 2016 at 07:16:45AM -0700, Sean: > I'd like to log authentication and authorization as well, if possible. I've come across reference to the following configuration: > > accounting log = /var/log/tac_plus/accounting.log > > authentication log = /var/log/tac_plus/authentication.log > > authorization log = /var/log/tac_plus/authorization.log > > This seems to be either a) outdated or b) poorly referenced as it doesn't work globally. A reference configuration I have from a version so old it's expressed in a date format (201211021744) places it within an "id" container. > > > id = tac_plus { > > accounting log = /var/log/tac_plus/accounting.log > > authentication log = /var/log/tac_plus/authentication.log > > authorization log = /var/log/tac_plus/authorization.log > > } This must be another tacacs daemon. This implementation has never had an id clause that I am aware of. > I haven't tried this in v4 yet since I can't find (presumably) current reference for it, but it?s working in the older version. > > I've also found reference to setting the appropriate -d flags when running tac_plus and getting this information as more of a "happy accident" (their words) in that the debugged info will hit the syslog daemon and be shuffled to the appropriate log files vs. a means configured specifically in the tac_plus config file. > > What?s the most appropriate / supported way to log this information, if any? logging = syslog facility there used to be a logfile option, but it degraded performance for multiple daemons competing for one file. so, it is syslog only now. some syslog daemons allow the matching of messages to determine the logging location (or other actions). From heas at shrubbery.net Mon Sep 12 20:16:15 2016 From: heas at shrubbery.net (heasley) Date: Mon, 12 Sep 2016 20:16:15 +0000 Subject: [tac_plus] Full AAA logging / supported configuration In-Reply-To: <840667EA-7416-42AF-80F6-70EB0C7C7F35@gmail.com> References: <20160912194259.GF24562@shrubbery.net> <840667EA-7416-42AF-80F6-70EB0C7C7F35@gmail.com> Message-ID: <20160912201615.GG24562@shrubbery.net> Mon, Sep 12, 2016 at 01:09:57PM -0700, Sean: > It?s tac_plus, it?s just ancient. I believe it had something to do with MAVIS as well. > > The system(s) I?m running v4 on are using PAM instead of the MAVIS module. > > So more or less just enable the right debug levels and route to syslog, expecting to find things in auth.log, etc.? With accounting being the exception. If so, I will look into getting rsyslogd to route the data correctly. it only uses 1 facility, whichever you specify in the config. otherwise, yes. tacacs is fairly quiet; leaving the auth/auth-failure to the clients. I'd be willing to add an option for tacacs to log these itself, at least for authentication. From heas at shrubbery.net Mon Sep 12 20:43:15 2016 From: heas at shrubbery.net (heasley) Date: Mon, 12 Sep 2016 20:43:15 +0000 Subject: [tac_plus] [rancid] Full AAA logging / supported configuration In-Reply-To: <424c8e00-050c-23a3-788c-b059cc2c1f7f@gmail.com> References: <88666920-2D26-456B-B34D-AE39D6990C72@gmail.com> <424c8e00-050c-23a3-788c-b059cc2c1f7f@gmail.com> Message-ID: <20160912204315.GL24562@shrubbery.net> Sat, Sep 10, 2016 at 08:35:22AM +0200, Alan McKinnon: > The -d option is not happy accident. It's a bit-encoded field where you > tell tac_plus what type of entries to log. btw, the bits are noted in the manpage. From spedersen.lists at gmail.com Mon Sep 12 20:49:13 2016 From: spedersen.lists at gmail.com (Sean) Date: Mon, 12 Sep 2016 13:49:13 -0700 Subject: [tac_plus] Full AAA logging / supported configuration In-Reply-To: <20160912201615.GG24562@shrubbery.net> References: <20160912194259.GF24562@shrubbery.net> <840667EA-7416-42AF-80F6-70EB0C7C7F35@gmail.com> <20160912201615.GG24562@shrubbery.net> Message-ID: <9E66D29F-BE67-4835-8968-AA944E911D26@gmail.com> I have `-d 8 -d 16` running which by default log to /var/log/tac_plus.log; that works for me! I just needed the output of who is logging into what and where on top of the accounting information in /var/log/tac_plus.acct. Speaking of debugs, and a little off-topic, but earlier when I had `-d 256` enabled to look at the output, I noticed the passwords being transmitted and logged in clear text. I know TACACS+ itself is not encrypted, but logging the passwords in clear text via tac_plus debugs seems like a bad idea. Anyone with the necessary permissions, including other sysadmins, can see your TACACS+ password just by bouncing the daemon and restarting it with the right debug level. Not sure if that?s intentional or if there?s a better way to protect it other than file permissions. On 9/12/16, 1:16 PM, "heasley" wrote: Mon, Sep 12, 2016 at 01:09:57PM -0700, Sean: > It?s tac_plus, it?s just ancient. I believe it had something to do with MAVIS as well. > > The system(s) I?m running v4 on are using PAM instead of the MAVIS module. > > So more or less just enable the right debug levels and route to syslog, expecting to find things in auth.log, etc.? With accounting being the exception. If so, I will look into getting rsyslogd to route the data correctly. it only uses 1 facility, whichever you specify in the config. otherwise, yes. tacacs is fairly quiet; leaving the auth/auth-failure to the clients. I'd be willing to add an option for tacacs to log these itself, at least for authentication. From spedersen.lists at gmail.com Mon Sep 12 20:50:32 2016 From: spedersen.lists at gmail.com (Sean) Date: Mon, 12 Sep 2016 13:50:32 -0700 Subject: [tac_plus] [rancid] Full AAA logging / supported configuration In-Reply-To: <20160912204315.GL24562@shrubbery.net> References: <88666920-2D26-456B-B34D-AE39D6990C72@gmail.com> <424c8e00-050c-23a3-788c-b059cc2c1f7f@gmail.com> <20160912204315.GL24562@shrubbery.net> Message-ID: Yep ? I have 8 and 16 enabled. Value Meaning 2 configuration parsing debugging 4 fork(1) debugging 8 authorization debugging 16 authentication debugging 32 password file processing debugging 64 accounting debugging 128 config file parsing & lookup 256 packet transmission/reception 512 encryption/decryption 1024 MD5 hash algorithm debugging 2048 very low level encryption/decryption 32768 max session debugging 65536 lock debugging On 9/12/16, 1:43 PM, "tac_plus on behalf of heasley" wrote: Sat, Sep 10, 2016 at 08:35:22AM +0200, Alan McKinnon: > The -d option is not happy accident. It's a bit-encoded field where you > tell tac_plus what type of entries to log. btw, the bits are noted in the manpage. _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo/tac_plus From heas at shrubbery.net Mon Sep 12 21:01:08 2016 From: heas at shrubbery.net (heasley) Date: Mon, 12 Sep 2016 21:01:08 +0000 Subject: [tac_plus] Full AAA logging / supported configuration In-Reply-To: <9E66D29F-BE67-4835-8968-AA944E911D26@gmail.com> References: <20160912194259.GF24562@shrubbery.net> <840667EA-7416-42AF-80F6-70EB0C7C7F35@gmail.com> <20160912201615.GG24562@shrubbery.net> <9E66D29F-BE67-4835-8968-AA944E911D26@gmail.com> Message-ID: <20160912210108.GN24562@shrubbery.net> Mon, Sep 12, 2016 at 01:49:13PM -0700, Sean: > Speaking of debugs, and a little off-topic, but earlier when I had `-d 256` enabled to look at the output, I noticed the passwords being transmitted and logged in clear text. I know TACACS+ itself is not encrypted, but logging the passwords in clear text via tac_plus debugs seems like a bad idea. Anyone with the necessary permissions, including other sysadmins, can see your TACACS+ password just by bouncing the daemon and restarting it with the right debug level. tacacs can be encrypted if you configure it to be. anyway, -d is for debugging. it can be useful to log the data as it is received, esp for low level debugging. > Not sure if that?s intentional or if there?s a better way to protect it other than file permissions. > > On 9/12/16, 1:16 PM, "heasley" wrote: > > Mon, Sep 12, 2016 at 01:09:57PM -0700, Sean: > > It?s tac_plus, it?s just ancient. I believe it had something to do with MAVIS as well. > > > > The system(s) I?m running v4 on are using PAM instead of the MAVIS module. > > > > So more or less just enable the right debug levels and route to syslog, expecting to find things in auth.log, etc.? With accounting being the exception. If so, I will look into getting rsyslogd to route the data correctly. > > it only uses 1 facility, whichever you specify in the config. otherwise, > yes. tacacs is fairly quiet; leaving the auth/auth-failure to the clients. > I'd be willing to add an option for tacacs to log these itself, at least > for authentication. > > > From spedersen.lists at gmail.com Mon Sep 12 22:03:49 2016 From: spedersen.lists at gmail.com (Sean) Date: Mon, 12 Sep 2016 15:03:49 -0700 Subject: [tac_plus] Full AAA logging / supported configuration In-Reply-To: <20160912210108.GN24562@shrubbery.net> References: <20160912194259.GF24562@shrubbery.net> <840667EA-7416-42AF-80F6-70EB0C7C7F35@gmail.com> <20160912201615.GG24562@shrubbery.net> <9E66D29F-BE67-4835-8968-AA944E911D26@gmail.com> <20160912210108.GN24562@shrubbery.net> Message-ID: <8C23A899-B32B-44F3-B935-6F791FA1CEB9@gmail.com> Then I misspoke. I thought the key was used for authentication; I didn?t realize it was also being used to encrypt the packets. I?ve got a key configured and in use, but the password(s) were still being logged via `-d 256` in cleartext in /var/log/tac_plus.log when it was running with that level of debugging enabled. On 9/12/16, 2:01 PM, "heasley" wrote: Mon, Sep 12, 2016 at 01:49:13PM -0700, Sean: > Speaking of debugs, and a little off-topic, but earlier when I had `-d 256` enabled to look at the output, I noticed the passwords being transmitted and logged in clear text. I know TACACS+ itself is not encrypted, but logging the passwords in clear text via tac_plus debugs seems like a bad idea. Anyone with the necessary permissions, including other sysadmins, can see your TACACS+ password just by bouncing the daemon and restarting it with the right debug level. tacacs can be encrypted if you configure it to be. anyway, -d is for debugging. it can be useful to log the data as it is received, esp for low level debugging. > Not sure if that?s intentional or if there?s a better way to protect it other than file permissions. > > On 9/12/16, 1:16 PM, "heasley" wrote: > > Mon, Sep 12, 2016 at 01:09:57PM -0700, Sean: > > It?s tac_plus, it?s just ancient. I believe it had something to do with MAVIS as well. > > > > The system(s) I?m running v4 on are using PAM instead of the MAVIS module. > > > > So more or less just enable the right debug levels and route to syslog, expecting to find things in auth.log, etc.? With accounting being the exception. If so, I will look into getting rsyslogd to route the data correctly. > > it only uses 1 facility, whichever you specify in the config. otherwise, > yes. tacacs is fairly quiet; leaving the auth/auth-failure to the clients. > I'd be willing to add an option for tacacs to log these itself, at least > for authentication. > > > From heas at shrubbery.net Mon Sep 12 23:41:35 2016 From: heas at shrubbery.net (heasley) Date: Mon, 12 Sep 2016 23:41:35 +0000 Subject: [tac_plus] Full AAA logging / supported configuration In-Reply-To: <8C23A899-B32B-44F3-B935-6F791FA1CEB9@gmail.com> References: <20160912194259.GF24562@shrubbery.net> <840667EA-7416-42AF-80F6-70EB0C7C7F35@gmail.com> <20160912201615.GG24562@shrubbery.net> <9E66D29F-BE67-4835-8968-AA944E911D26@gmail.com> <20160912210108.GN24562@shrubbery.net> <8C23A899-B32B-44F3-B935-6F791FA1CEB9@gmail.com> Message-ID: <20160912234135.GT24562@shrubbery.net> Mon, Sep 12, 2016 at 03:03:49PM -0700, Sean: > Then I misspoke. I thought the key was used for authentication; I didn?t realize it was also being used to encrypt the packets. > > I?ve got a key configured and in use, but the password(s) were still being logged via `-d 256` in cleartext in /var/log/tac_plus.log when it was running with that level of debugging enabled. only data on the wire in encrupted From spedersen.lists at gmail.com Tue Sep 13 13:22:10 2016 From: spedersen.lists at gmail.com (Sean) Date: Tue, 13 Sep 2016 06:22:10 -0700 Subject: [tac_plus] Full AAA logging / supported configuration In-Reply-To: <20160912234135.GT24562@shrubbery.net> References: <20160912194259.GF24562@shrubbery.net> <840667EA-7416-42AF-80F6-70EB0C7C7F35@gmail.com> <20160912201615.GG24562@shrubbery.net> <9E66D29F-BE67-4835-8968-AA944E911D26@gmail.com> <20160912210108.GN24562@shrubbery.net> <8C23A899-B32B-44F3-B935-6F791FA1CEB9@gmail.com> <20160912234135.GT24562@shrubbery.net> Message-ID: <3AB31C0C-1CC1-42FF-90D0-330CC8945971@gmail.com> So the logging occurs once it?s been decrypted. Is there a way to always ensure sensitive data that can be logged during debug, such as the password of the end-user, is encrypted? Or at least omitted? I don?t like the idea that someone else with sudo / root can sniff someone else?s passwords in clear text. ? On 9/12/16, 4:41 PM, "heasley" wrote: Mon, Sep 12, 2016 at 03:03:49PM -0700, Sean: > Then I misspoke. I thought the key was used for authentication; I didn?t realize it was also being used to encrypt the packets. > > I?ve got a key configured and in use, but the password(s) were still being logged via `-d 256` in cleartext in /var/log/tac_plus.log when it was running with that level of debugging enabled. only data on the wire in encrupted From alan.mckinnon at gmail.com Tue Sep 13 22:23:55 2016 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Wed, 14 Sep 2016 00:23:55 +0200 Subject: [tac_plus] Full AAA logging / supported configuration In-Reply-To: <3AB31C0C-1CC1-42FF-90D0-330CC8945971@gmail.com> References: <20160912194259.GF24562@shrubbery.net> <840667EA-7416-42AF-80F6-70EB0C7C7F35@gmail.com> <20160912201615.GG24562@shrubbery.net> <9E66D29F-BE67-4835-8968-AA944E911D26@gmail.com> <20160912210108.GN24562@shrubbery.net> <8C23A899-B32B-44F3-B935-6F791FA1CEB9@gmail.com> <20160912234135.GT24562@shrubbery.net> <3AB31C0C-1CC1-42FF-90D0-330CC8945971@gmail.com> Message-ID: On 13/09/2016 15:22, Sean wrote: > So the logging occurs once it?s been decrypted. Is there a way to always ensure sensitive data that can be logged during debug, such as the password of the end-user, is encrypted? Or at least omitted? > > I don?t like the idea that someone else with sudo / root can sniff someone else?s passwords in clear text. ? What's the point? If the user is root, they can make any user's password be anything they want it to be Rule #1: the root user can always get around any security measure you put in place. Mostly because for root their ARE no security measures in place. Why are you letting untrusted persons have root access anyway? Apart from generally being a bad idea, it also unticks all the check boxes so beloved of auditors. > > On 9/12/16, 4:41 PM, "heasley" wrote: > > Mon, Sep 12, 2016 at 03:03:49PM -0700, Sean: > > Then I misspoke. I thought the key was used for authentication; I didn?t realize it was also being used to encrypt the packets. > > > > I?ve got a key configured and in use, but the password(s) were still being logged via `-d 256` in cleartext in /var/log/tac_plus.log when it was running with that level of debugging enabled. > > only data on the wire in encrupted > > > > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > From spedersen.lists at gmail.com Wed Sep 14 00:04:17 2016 From: spedersen.lists at gmail.com (Sean) Date: Tue, 13 Sep 2016 17:04:17 -0700 Subject: [tac_plus] Full AAA logging / supported configuration In-Reply-To: References: <20160912194259.GF24562@shrubbery.net> <840667EA-7416-42AF-80F6-70EB0C7C7F35@gmail.com> <20160912201615.GG24562@shrubbery.net> <9E66D29F-BE67-4835-8968-AA944E911D26@gmail.com> <20160912210108.GN24562@shrubbery.net> <8C23A899-B32B-44F3-B935-6F791FA1CEB9@gmail.com> <20160912234135.GT24562@shrubbery.net> <3AB31C0C-1CC1-42FF-90D0-330CC8945971@gmail.com> Message-ID: No, different systems and different authentication schemas. Root access on these systems is not tied to the same system as password authentication. Someone who is root on these systems is not necessarily the same people who would have the ability to reset the password(s) of individual users. Even then, they would not see them in clear text. Don?t assume I?m letting untrusted persons have root; I?m not. Someone who is trusted and has root on these systems doesn?t need to see another user?s clear text passwords under any circumstances. With so many ways and means to authenticate and authorize someone, and considering the integration into systems that can provide such (local, LDAP, RADIUS, etc. etc.) a clear text password It should not be in the debug logs. Someone pops one server with tac_plus running on it, bounces the service and enables -d 256, sits pretty while people log into network devices, then has a nice list of usernames and passwords all in clear text to start harming the rest of the network and the systems on it. On 9/13/16, 3:23 PM, "tac_plus on behalf of Alan McKinnon" wrote: On 13/09/2016 15:22, Sean wrote: > So the logging occurs once it?s been decrypted. Is there a way to always ensure sensitive data that can be logged during debug, such as the password of the end-user, is encrypted? Or at least omitted? > > I don?t like the idea that someone else with sudo / root can sniff someone else?s passwords in clear text. ? What's the point? If the user is root, they can make any user's password be anything they want it to be Rule #1: the root user can always get around any security measure you put in place. Mostly because for root their ARE no security measures in place. Why are you letting untrusted persons have root access anyway? Apart from generally being a bad idea, it also unticks all the check boxes so beloved of auditors. > > On 9/12/16, 4:41 PM, "heasley" wrote: > > Mon, Sep 12, 2016 at 03:03:49PM -0700, Sean: > > Then I misspoke. I thought the key was used for authentication; I didn?t realize it was also being used to encrypt the packets. > > > > I?ve got a key configured and in use, but the password(s) were still being logged via `-d 256` in cleartext in /var/log/tac_plus.log when it was running with that level of debugging enabled. > > only data on the wire in encrupted > > > > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > _______________________________________________ tac_plus mailing list tac_plus at shrubbery.net http://www.shrubbery.net/mailman/listinfo/tac_plus From alan.mckinnon at gmail.com Wed Sep 14 09:35:09 2016 From: alan.mckinnon at gmail.com (Alan McKinnon) Date: Wed, 14 Sep 2016 11:35:09 +0200 Subject: [tac_plus] Full AAA logging / supported configuration In-Reply-To: References: <20160912194259.GF24562@shrubbery.net> <840667EA-7416-42AF-80F6-70EB0C7C7F35@gmail.com> <20160912201615.GG24562@shrubbery.net> <9E66D29F-BE67-4835-8968-AA944E911D26@gmail.com> <20160912210108.GN24562@shrubbery.net> <8C23A899-B32B-44F3-B935-6F791FA1CEB9@gmail.com> <20160912234135.GT24562@shrubbery.net> <3AB31C0C-1CC1-42FF-90D0-330CC8945971@gmail.com>

Message-ID: Then you need to modify the code for option 256 to redact the password. Do keep in mind that the tacacs protocol is fatally flawed wrt security - it's a very old protocol without an RFC (the original draft expired and was never renewed) and the protocol reflects the thinking of when it was developed. The password is effectively sent on the wire almost in cleartext anyway; the traffic is encrypted after a fashion but it's trivial to break if you have the key (which root always has access to on the server, and any admin on the network device can see it too). So strictly speaking by modern standards the password ought not to be in the debug logs, but due to the nature of the rest of the system (and especially the network devices themselves) it lowers the security posture of the whole system very little overall. On 14/09/2016 02:04, Sean wrote: > No, different systems and different authentication schemas. Root access on these systems is not tied to the same system as password authentication. Someone who is root on these systems is not necessarily the same people who would have the ability to reset the password(s) of individual users. Even then, they would not see them in clear text. > > Don?t assume I?m letting untrusted persons have root; I?m not. Someone who is trusted and has root on these systems doesn?t need to see another user?s clear text passwords under any circumstances. > > With so many ways and means to authenticate and authorize someone, and considering the integration into systems that can provide such (local, LDAP, RADIUS, etc. etc.) a clear text password It should not be in the debug logs. > > Someone pops one server with tac_plus running on it, bounces the service and enables -d 256, sits pretty while people log into network devices, then has a nice list of usernames and passwords all in clear text to start harming the rest of the network and the systems on it. > > On 9/13/16, 3:23 PM, "tac_plus on behalf of Alan McKinnon" wrote: > > On 13/09/2016 15:22, Sean wrote: > > So the logging occurs once it?s been decrypted. Is there a way to always ensure sensitive data that can be logged during debug, such as the password of the end-user, is encrypted? Or at least omitted? > > > > I don?t like the idea that someone else with sudo / root can sniff someone else?s passwords in clear text. ? > > What's the point? If the user is root, they can make any user's password > be anything they want it to be > > Rule #1: the root user can always get around any security measure you > put in place. Mostly because for root their ARE no security measures in > place. > > Why are you letting untrusted persons have root access anyway? Apart > from generally being a bad idea, it also unticks all the check boxes so > beloved of auditors. > > > > > > On 9/12/16, 4:41 PM, "heasley" wrote: > > > > Mon, Sep 12, 2016 at 03:03:49PM -0700, Sean: > > > Then I misspoke. I thought the key was used for authentication; I didn?t realize it was also being used to encrypt the packets. > > > > > > I?ve got a key configured and in use, but the password(s) were still being logged via `-d 256` in cleartext in /var/log/tac_plus.log when it was running with that level of debugging enabled. > > > > only data on the wire in encrupted > > > > > > > > > > _______________________________________________ > > tac_plus mailing list > > tac_plus at shrubbery.net > > http://www.shrubbery.net/mailman/listinfo/tac_plus > > > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > > > > -- Alan McKinnon alan.mckinnon at gmail.com From spedersen.lists at gmail.com Wed Sep 14 17:39:01 2016 From: spedersen.lists at gmail.com (Sean) Date: Wed, 14 Sep 2016 10:39:01 -0700 Subject: [tac_plus] Full AAA logging / supported configuration In-Reply-To: References: <20160912194259.GF24562@shrubbery.net> <840667EA-7416-42AF-80F6-70EB0C7C7F35@gmail.com> <20160912201615.GG24562@shrubbery.net> <9E66D29F-BE67-4835-8968-AA944E911D26@gmail.com> <20160912210108.GN24562@shrubbery.net> <8C23A899-B32B-44F3-B935-6F791FA1CEB9@gmail.com> <20160912234135.GT24562@shrubbery.net> <3AB31C0C-1CC1-42FF-90D0-330CC8945971@gmail.com>

Message-ID: <35177A15-C0CA-4805-8DA1-592778BD621E@gmail.com> That?s a possibility; it wouldn?t be the first time I?ve needed to tinker with source code to adjust something. I would rather see it officialy, though, so I want to give heasley a chance to comment. Otherwise I?ll try and hunt it down myself. I agree, TACACS+ isn?t the perfect solution. I want to move to SSH key-based authentication soon, but lack the ability to centrally manage it in a convenient manner. On 9/14/16, 2:35 AM, "Alan McKinnon" wrote: Then you need to modify the code for option 256 to redact the password. Do keep in mind that the tacacs protocol is fatally flawed wrt security - it's a very old protocol without an RFC (the original draft expired and was never renewed) and the protocol reflects the thinking of when it was developed. The password is effectively sent on the wire almost in cleartext anyway; the traffic is encrypted after a fashion but it's trivial to break if you have the key (which root always has access to on the server, and any admin on the network device can see it too). So strictly speaking by modern standards the password ought not to be in the debug logs, but due to the nature of the rest of the system (and especially the network devices themselves) it lowers the security posture of the whole system very little overall. On 14/09/2016 02:04, Sean wrote: > No, different systems and different authentication schemas. Root access on these systems is not tied to the same system as password authentication. Someone who is root on these systems is not necessarily the same people who would have the ability to reset the password(s) of individual users. Even then, they would not see them in clear text. > > Don?t assume I?m letting untrusted persons have root; I?m not. Someone who is trusted and has root on these systems doesn?t need to see another user?s clear text passwords under any circumstances. > > With so many ways and means to authenticate and authorize someone, and considering the integration into systems that can provide such (local, LDAP, RADIUS, etc. etc.) a clear text password It should not be in the debug logs. > > Someone pops one server with tac_plus running on it, bounces the service and enables -d 256, sits pretty while people log into network devices, then has a nice list of usernames and passwords all in clear text to start harming the rest of the network and the systems on it. > > On 9/13/16, 3:23 PM, "tac_plus on behalf of Alan McKinnon" wrote: > > On 13/09/2016 15:22, Sean wrote: > > So the logging occurs once it?s been decrypted. Is there a way to always ensure sensitive data that can be logged during debug, such as the password of the end-user, is encrypted? Or at least omitted? > > > > I don?t like the idea that someone else with sudo / root can sniff someone else?s passwords in clear text. ? > > What's the point? If the user is root, they can make any user's password > be anything they want it to be > > Rule #1: the root user can always get around any security measure you > put in place. Mostly because for root their ARE no security measures in > place. > > Why are you letting untrusted persons have root access anyway? Apart > from generally being a bad idea, it also unticks all the check boxes so > beloved of auditors. > > > > > > On 9/12/16, 4:41 PM, "heasley" wrote: > > > > Mon, Sep 12, 2016 at 03:03:49PM -0700, Sean: > > > Then I misspoke. I thought the key was used for authentication; I didn?t realize it was also being used to encrypt the packets. > > > > > > I?ve got a key configured and in use, but the password(s) were still being logged via `-d 256` in cleartext in /var/log/tac_plus.log when it was running with that level of debugging enabled. > > > > only data on the wire in encrupted > > > > > > > > > > _______________________________________________ > > tac_plus mailing list > > tac_plus at shrubbery.net > > http://www.shrubbery.net/mailman/listinfo/tac_plus > > > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > > > > -- Alan McKinnon alan.mckinnon at gmail.com From heas at shrubbery.net Wed Sep 14 23:46:28 2016 From: heas at shrubbery.net (heasley) Date: Wed, 14 Sep 2016 23:46:28 +0000 Subject: [tac_plus] Full AAA logging / supported configuration In-Reply-To: <3AB31C0C-1CC1-42FF-90D0-330CC8945971@gmail.com> References: <20160912194259.GF24562@shrubbery.net> <840667EA-7416-42AF-80F6-70EB0C7C7F35@gmail.com> <20160912201615.GG24562@shrubbery.net> <9E66D29F-BE67-4835-8968-AA944E911D26@gmail.com> <20160912210108.GN24562@shrubbery.net> <8C23A899-B32B-44F3-B935-6F791FA1CEB9@gmail.com> <20160912234135.GT24562@shrubbery.net> <3AB31C0C-1CC1-42FF-90D0-330CC8945971@gmail.com> Message-ID: <20160914234628.GU1075@shrubbery.net> Tue, Sep 13, 2016 at 06:22:10AM -0700, Sean: > So the logging occurs once it?s been decrypted. Is there a way to always ensure sensitive data that can be logged during debug, such as the password of the end-user, is encrypted? Or at least omitted? dont use the debugging option? :) Really, a better solution is probably to add an option that logs authentication success/failure, rather than enabling debugging or altering the debugging to operate differently. I have about 4 patches from various people that I need to review. i'll look at such an option along with those...which honestly have been on my todo list for much too long. > I don?t like the idea that someone else with sudo / root can sniff someone else?s passwords in clear text. ? > > On 9/12/16, 4:41 PM, "heasley" wrote: > > Mon, Sep 12, 2016 at 03:03:49PM -0700, Sean: > > Then I misspoke. I thought the key was used for authentication; I didn?t realize it was also being used to encrypt the packets. > > > > I?ve got a key configured and in use, but the password(s) were still being logged via `-d 256` in cleartext in /var/log/tac_plus.log when it was running with that level of debugging enabled. > > only data on the wire in encrupted > > > From spedersen.lists at gmail.com Thu Sep 15 15:42:32 2016 From: spedersen.lists at gmail.com (Sean) Date: Thu, 15 Sep 2016 08:42:32 -0700 Subject: [tac_plus] Full AAA logging / supported configuration In-Reply-To: <20160914234628.GU1075@shrubbery.net> References: <20160912194259.GF24562@shrubbery.net> <840667EA-7416-42AF-80F6-70EB0C7C7F35@gmail.com> <20160912201615.GG24562@shrubbery.net> <9E66D29F-BE67-4835-8968-AA944E911D26@gmail.com> <20160912210108.GN24562@shrubbery.net> <8C23A899-B32B-44F3-B935-6F791FA1CEB9@gmail.com> <20160912234135.GT24562@shrubbery.net> <3AB31C0C-1CC1-42FF-90D0-330CC8945971@gmail.com> <20160914234628.GU1075@shrubbery.net> Message-ID: Sure, I have that turned off. Definitely. However, it goes back to my original point: if someone has root access to the system running tac_plus they can bounce the daemon and add `-d 256` without issue. I might give someone else on my team root access on these servers so they can administer them, but that doesn?t mean I want them to know their co-worker?s credentials, which are kept on a separate system. That?s assuming the least possibly damaging scenario. Clear text passwords should not show up anywhere; logs, debugging, etc. (Obviously doesn?t account for the key(s) used or if someone leaves plain-text passwords for users defined in tac_plus.conf.) I like the idea of ?official? logging options rather than relying on debugging to get them. On 9/14/16, 4:46 PM, "heasley" wrote: Tue, Sep 13, 2016 at 06:22:10AM -0700, Sean: > So the logging occurs once it?s been decrypted. Is there a way to always ensure sensitive data that can be logged during debug, such as the password of the end-user, is encrypted? Or at least omitted? dont use the debugging option? :) Really, a better solution is probably to add an option that logs authentication success/failure, rather than enabling debugging or altering the debugging to operate differently. I have about 4 patches from various people that I need to review. i'll look at such an option along with those...which honestly have been on my todo list for much too long. > I don?t like the idea that someone else with sudo / root can sniff someone else?s passwords in clear text. ? > > On 9/12/16, 4:41 PM, "heasley" wrote: > > Mon, Sep 12, 2016 at 03:03:49PM -0700, Sean: > > Then I misspoke. I thought the key was used for authentication; I didn?t realize it was also being used to encrypt the packets. > > > > I?ve got a key configured and in use, but the password(s) were still being logged via `-d 256` in cleartext in /var/log/tac_plus.log when it was running with that level of debugging enabled. > > only data on the wire in encrupted > > > From mcostello at netflix.com Wed Sep 21 22:30:26 2016 From: mcostello at netflix.com (Michael Costello) Date: Wed, 21 Sep 2016 15:30:26 -0700 Subject: [tac_plus] DEFAULT user and PAM In-Reply-To: <20160824080726.GC80163@shrubbery.net> References: <20160824080726.GC80163@shrubbery.net> Message-ID: Hi again, I think I figured out the problem. I debugged F4.0.4.28 on an equivalent Ubuntu 14.04 instance with a working PAM/SSSD/LDAP setup. F4.0.4.26 should behave identically. The problem appears to be that config.c's cfg_get_value() returns if a user is not found rather than attempting to lookup the DEFAULT user. I applied the following patch and was able to authenticate as a user defined in LDAP but not explicitly defined in tac_plus.conf. --- config.c.orig 2012-06-06 22:11:30.000000000 +0000 +++ config.c 2016-09-21 22:04:48.734463450 +0000 @@ -1902,7 +1902,11 @@ if (!user) { if (debug & DEBUG_CONFIG_FLAG) report(LOG_DEBUG, "cfg_get_value: no user/group named %s", name); - return(value); + if (isuser && cfg_user_exists(DEFAULT_USERNAME)) { + user = (USER *)hash_lookup(usertable, DEFAULT_USERNAME); + report(LOG_DEBUG, "cfg_get_value: using DEFAULT"); + } else + return(value); } /* found the entry. Lookup value from attr=value */ Please let me know if this is an effective fix or if it has unintended consequences. mc On Wed, Aug 24, 2016 at 1:07 AM, heasley wrote: > Tue, Aug 23, 2016 at 03:20:45PM -0700, Michael Costello: >> Hi tac_plus, >> >> I know this question has been asked before[0], but I have not been >> able to find the answer. >> >> I have an Ubuntu 14.04 machine with tac_plus F4.0.4.26 installed >> through apt. The box is configured correctly for LDAP through SSSD (I >> can ssh into it using LDAP credentials). And I can authenticate to a >> router against tacacs using LDAP credentials iff my username is >> explicitly configured in tac_plus.conf. >> >> user = me { >> login = PAM >> member = admin >> } >> >> User 'me' is not in /etc/passwd. If however I remove the user and >> attempt to use the default user >> >> user = DEFAULT { >> login = PAM >> member = admin >> } >> >> I cannot authenticate: >> >> Tue Aug 23 21:47:53 2016 [10793]: Authenticating ACLs for user >> 'DEFAULT' instead of 'me' >> Tue Aug 23 21:47:53 2016 [10793]: login query for 'me' ssh from 1.2.3.4 rejected >> >> Is there any way to resolve this through configuration or using a >> later version (the changelog from 4.0.4.26 to 4.0.4.28 does not >> mention anything in regards to this)? Or is what I'm after simply not >> supported? > > I do not know of any reason that this should not work and i'd expect it > to be needed, but I'll have to build a test environment to test and debug. > >> mc >> >> [0] >> http://www.shrubbery.net/pipermail/tac_plus/2010-February/000667.html >> http://www.shrubbery.net/pipermail/tac_plus/2010-January/000662.html >> >> _______________________________________________ >> tac_plus mailing list >> tac_plus at shrubbery.net >> http://www.shrubbery.net/mailman/listinfo/tac_plus From xcellula at gmail.com Thu Sep 29 05:43:18 2016 From: xcellula at gmail.com (eric c) Date: Thu, 29 Sep 2016 00:43:18 -0500 Subject: [tac_plus] log to mysql Message-ID: Good evening, I've used tac_plus for so long and it's been great! One thing I've always wanted to know is if it can support mysql for logging instead of the tacacs accounting text file? I have tried using rsyslog->mysql to suck up the file but I can't get it to do it correctly and wanted to know if there's a version of tac_plus that supports this? Thank you for your project! eric -------------- next part -------------- An HTML attachment was scrubbed... URL: