[tac_plus] Full AAA logging / supported configuration

[Sean]

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" <alan.mckinnon at gmail.com> 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" <tac_plus-bounces at shrubbery.net on behalf of alan.mckinnon at gmail.com> 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" <heas at shrubbery.net> 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