[tac_plus] enable additional commands centrally for IOS privilege levels other than 15
John Fraizer
john at op-sec.us
Thu Apr 16 20:08:14 UTC 2015
do_auth.py is a great tool which has given so much more flexibility to our
TACACS+ infrastructure.
I've modified it to log to a MySQL database and have also modified tac_plus
to allow accounting to a script "after authorization" style. I pass the
accounting pairs out and read them into STDIN and log those to the MySQL
database too. It makes searching through the logs so much more flexible
because I'm able to make Arista / Cisco / Juniper accounting records have a
consistent format in the database. I can also tell the difference between
the three vendors based only on the pairs they send in their accounting
records.
New tac_plus directive:
accounting script = "/usr/bin/python /someplace/do_accounting.py -f
/someplace/do_auth.ini"
And I've added the following directives to do_auth.ini which both scripts
use to set up their MySQL config:
[mysql]
user = tacacs
password = somepassword
host = 10.172.192.1
database = somedatabase
Thanks for all the hard work on do_auth.py! Once I've put my changes
through enough testing, I'm planning on providing patches to the community
for both do_auth.py and tac_plus in case someone else wants to leverage
MySQL for logging TACACS stuff.
--
John Fraizer
LinkedIn profile: http://www.linkedin.com/in/johnfraizer/
On Thu, Apr 16, 2015 at 10:53 AM, Daniel Schmidt <daniel.schmidt at wyo.gov>
wrote:
> Jathan and I are planning to improve the JUNOS support. I'm always glad
> to hear that this little python snippet I started a few years ago has made
> people's lives easier.
>
> On Thu, Apr 16, 2015 at 11:34 AM, John Fraizer <john at op-sec.us> wrote:
>
>> Here is an example:
>>
>> tac_plus.conf:
>>
>> key = "blah-blah-blah"
>> accounting file = /some/location/tacplus.acct
>>
>> default authentication = file /etc/passwd
>>
>> #
>> # Default group to run all command authentication through do_auth.
>> #
>> group = doauthaccess {
>> default service = permit
>>
>> service = exec {
>> priv-lvl = 1
>> optional idletime = 30
>> optional acl = 2
>> shell:roles="\"network-operator vdc-operator\""
>> }
>>
>> service = junos-exec {
>> bug-fix = "first pair is lost"
>> local-user-name = "remote"
>> allow-commands = "(.*exit)|(show cli auth.*)"
>> deny-commands = ".*"
>> allow-configuration = ""
>> deny-configuration = ".*"
>> }
>> after authorization "/usr/bin/python /some-location/do_auth.py -i
>> $address -u $user -d $name -l /some-location/do_auth.log -f
>> /some-location/do_auth.ini"
>> }
>>
>>
>> #
>> # Default user - Used when no user specific stanza exists in
>> tac_plus.conf.
>> #
>> user = DEFAULT {
>> member = doauthaccess
>> login = PAM
>> }
>>
>>
>> And then, in do_auth.ini:
>>
>> [users]
>> default =
>> no_authority
>>
>> ren =
>> lab
>> no_authority
>>
>> stimpy =
>> lab
>> production_readonly
>> no_authority
>>
>> # Groups start here
>>
>> # Default group. Can only log out and check
>> # privilege level (JUNOS)
>> [no_authority]
>> host_deny =
>> host_allow =
>> .*
>> device_deny =
>> device_permit =
>> .*
>> command_deny =
>> .*
>> command_permit =
>> exit.*
>> av_pairs =
>> priv-lvl=0
>> shell:roles="network-operator vdc-operator"
>> local-user-name = test
>> allow-commands = (.*exit)|(show cli auth.*)
>> deny-commands = .*
>> allow-configuration =
>> deny-configuration =
>>
>> # LAB group can do anything - as long as the device
>> # they're logging into is in 192.168.56.0/24 which is
>> # the IP address space used for management in the LAB.
>> [lab]
>> host_deny =
>> host_allow =
>> .*
>> device_deny =
>> device_permit =
>> 192.168.56.*
>> command_deny =
>> command_permit =
>> .*
>> av_pairs =
>> priv-lvl=15
>> shell:roles="network-admin vdc-admin"
>> local-user-name = remote
>> allow-commands = .*
>> deny-commands =
>> allow-configuration = .*
>> deny-configuration =
>>
>>
>> # This group provides read-only access to ANY device.
>> [production_readonly]
>> host_deny =
>> host_allow =
>> .*
>> device_deny =
>> device_permit =
>> .*
>> command_deny =
>> command_permit =
>> ping.*
>> traceroute.*
>> terminal.*
>> write terminal.*
>> copy running-config terminal.*
>> copy running-config tftp.*
>> copy startup-config terminal.*
>> copy startup-config tftp.*
>> show.*
>> av_pairs =
>> priv-lvl=15
>> shell:roles="network-admin vdc-admin"
>> local-user-name = remote
>> allow-commands =
>> deny-commands = (.*edit)|(.*configure)
>> allow-configuration =
>> deny-configuration =
>>
>>
>>
>>
>> With the above configuration, user "joe" does not have a user stanza in
>> do_auth.ini so, he will fall through to the "default" group (no_authority)
>> no matter which device he logs into. He will only be able to log out. ;-)
>> User ren is a member of "lab" and "no_authority" so, if he logs into any
>> devices in 192.168.56.0/24, he can do anything. For anything else, he
>> will
>> fall through to the "no_authority" group and only be able to log out.
>> User stimpy is a member of all three groups: lab, production_readonly and
>> no_authority. If he logs into a device in 192.168.56.0/24, he can do
>> anything. If he logs in ANYWHERE else, he will receive the
>> "production_readonly" privileges since it matches on .* for
>> "device_permit".
>>
>> If you look in group "production_readonly", I'm setting priv-lvl=15 or
>> giving "network-admin vdc-admin" or "local-user-name = remote" (depending
>> on which AV pair(s) the device sent to tac_plus. On my Junipers, user
>> "remote" is "super-user" which is basically the same as priv-lvl=15.
>>
>> On anything that does command authorization, I'm only permitting:
>> ping.*
>> traceroute.*
>> terminal.*
>> write terminal.*
>> copy running-config terminal.*
>> copy running-config tftp.*
>> copy startup-config terminal.*
>> copy startup-config tftp.*
>> show.*
>>
>> Anything else will be denied.
>>
>> On the Junipers, since they do RBAC and don't ask to authorize individual
>> commands, I'm simply denying "edit" and "configure" in the "deny-commands"
>> regular expression so, they can't make config changes.
>>
>> Note that ALL users are members of "no_authority" as their "last resort"
>> group. This is because, without that group membership, Cisco's and Arista
>> would get a "denied" authorization for the shell. Junipers flat-out
>> IGNORE
>> that though and the user would get uninhibited "super-user". Silly JUNOS!
>> Placing everyone in "no_authority" makes sure that even if no other groups
>> match, they will at least match on the no_authority group and be granted
>> just enough access to log out of the device (and look at their authority
>> on
>> Junipers):
>>
>> command_deny =
>> .*
>> command_permit =
>> exit.*
>> av_pairs =
>> priv-lvl=0
>> shell:roles="network-operator vdc-operator"
>> local-user-name = test
>> allow-commands = (.*exit)|(show cli auth.*)
>> deny-commands = .*
>> allow-configuration =
>> deny-configuration =
>>
>> There you go... a quick tutorial on using do_auth.py via the "after
>> authorization" function in tac_plus. You'll never believe you lived
>> without it once you set it up. Just be sure to TEST the configurations.
>> You might find a corner-case like I did with silly JUNOS doing the
>> opposite
>> of what you would expect.
>>
>>
>> --
>> John Fraizer
>> LinkedIn profile: http://www.linkedin.com/in/johnfraizer/
>>
>>
>>
>> On Thu, Apr 16, 2015 at 9:09 AM, Aaron Wasserott <
>> aaron.wasserott at viawest.com> wrote:
>>
>> > Look into the do_auth.pyc script to control command authorization.
>> >
>> > http://www.tacacs.org/
>> >
>> > -----Original Message-----
>> > From: tac_plus [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of
>> > Martin T
>> > Sent: Thursday, April 16, 2015 9:55 AM
>> > To: tac_plus at shrubbery.net
>> > Subject: [tac_plus] enable additional commands centrally for IOS
>> privilege
>> > levels other than 15
>> >
>> > Hi,
>> >
>> > privilege level 15 in IOS has all the possible commands for particular
>> IOS
>> > release enabled. However, for example privilege level 1 has only few
>> dozens
>> > of commands available. Now if I want to allow some of the privilege
>> level
>> > 15 commands also for privilege level 1, then I could use the "privilege
>> > exec level 1 <command>" command. For example "privilege exec level 1
>> > traceroute". However, is there a way to do this centrally in TACACS+
>> server?
>> >
>> >
>> > thanks,
>> > Martin
>> > _______________________________________________
>> > tac_plus mailing list
>> > tac_plus at shrubbery.net
>> > http://www.shrubbery.net/mailman/listinfo/tac_plus
>> > This message contains information that may be confidential, privileged
>> or
>> > otherwise protected by law from disclosure. It is intended for the
>> > exclusive use of the addressee(s). Unless you are the addressee or
>> > authorized agent of the addressee, you may not review, copy, distribute
>> or
>> > disclose to anyone the message or any information contained within. If
>> you
>> > have received this message in error, please contact the sender by
>> > electronic reply and immediately delete all copies of the message.
>> > _______________________________________________
>> > tac_plus mailing list
>> > tac_plus at shrubbery.net
>> > http://www.shrubbery.net/mailman/listinfo/tac_plus
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://www.shrubbery.net/pipermail/tac_plus/attachments/20150416/02e9a147/attachment.html
>> >
>> _______________________________________________
>> tac_plus mailing list
>> tac_plus at shrubbery.net
>> http://www.shrubbery.net/mailman/listinfo/tac_plus
>>
>
> E-Mail to and from me, in connection with the transaction
> of public business, is subject to the Wyoming Public Records
> Act and may be disclosed to third parties.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150416/8c8bda19/attachment.html>
More information about the tac_plus
mailing list