[tac_plus] TAC+ and Solarwinds Orion NCM don't play well together

Wed Oct 21 22:23:38 UTC 2015

That's how I use rancid too. I haven't locked down the rancid user
account on Tacacs as well as I could have, mostly because no-one ever
asked and the only way to get the password is to be on the rancid server
itself, and su to rancid. If an auditor ever asks, it's an hour's work
to change it.

The only sensible query I've ever had is the presence of secrets in the
output file, and they are there because Cisco put them there. Redacting
them out along with all other sensitive information has completely
satisfied every auditor thus far.

On 22/10/2015 00:08, Aaron Wasserott wrote:
> We have been using RANCID for years in our PCI/HIPAA service provider network with no issues from either our internal SecOps folks or our auditors. The problem is that you have to perform configuration management/backups, and once you say you use RANCID, it gets included in the scope of the compliant environment.
> 
> There are only a few special things I can think of, beyond the typical hardening of a Linux OS and access restrictions, that should be taken into consideration for RANCID:
> 
> - mask passwords from RANCID pulled configs
> --- particularly important if RANCID is emailing out detected changes
> - make sure .cloginrc has proper/strict permissions
> - use a dedicated account on your network devices for RANCID
> --- only permit login with that account from your RANCID server
> --- restrict authorization for that account to only the necessary show/get commands
> 
> The only thing I have seen security people not like about it, is that since its FLOSS, there are not security alerts provided by a vendor and corresponding patches. Should be able to easily document the explanation for this however by patching the underlying perl and expect packages where necessary, and through the restrictions listed above.
> 
> -----Original Message-----
> From: tac_plus [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon
> Sent: Wednesday, October 21, 2015 3:48 PM
> To: tac_plus at shrubbery.net
> Subject: Re: [tac_plus] TAC+ and Solarwinds Orion NCM don't play well together
> 
> On 21/10/2015 19:32, Daniel Schmidt wrote:
>> Rancid isn't PCI compliant, but TAC+ is?
> 
> 
> 
> And in what way is Rancid not PCI compliant?
> 
> My reading of PCI is that it has a narrow well-defined scope, and rancid is not in it, despite what those with agendas claim.
> 
> 
> 
> 
>>
>> On Tue, Oct 20, 2015 at 6:01 PM, Heasley <heas at shrubbery.net> wrote:
>>
>>>
>>>
>>>> Am 20.10.2015 um 13:12 schrieb Matt Almgren <matta at surveymonkey.com>:
>>>>
>>>> So we moved away from Rancid for something that is more PCI compliant.
>>> So far so good, until very recently we see this problem.
>>>>
>>>> I have 26 juniper devices in a job in Orion NCM.  For some reason,
>>>> for
>>> the last week, the daily backup job reports that 8-10 devices were
>>> “unable to login” or “connection refused”. However, when I switch
>>> Orion NCM to use local Admin logins on the Junipers versus TAC+ accounts, I see no errors.
>>>  Something with the communication between the network devices and
>>> TAC+ isn’t playing nice together.
>>>>
>>>> I’ve tried the following:
>>>>
>>>> Increased the SSH Timeout settings on Orion to 120 seconds.
>>>> Decreased the # of concurrent connections from default 11 to 1.
>>>> Reinstalled Orion Job Engine + other tweaks on the Orion NCM side.
>>>> Tried only Juniper devices, or only Arista devices, or 8 instead of
>>>> 27
>>> devices = all had mixed failures.
>>>>
>>>
>>> How many concurrent jobs did you use eirh rancid?
>>>
>>>> None of the failures are consistent.  Job 1 has 8/27 failures.  Job
>>>> 2
>>> has 10/27 failures with some that failed in the first job passing in
>>> this one.  Etc…
>>>>
>>>> Remember, local NAS accounts setup in Orion work just fine – TAC+
>>>> isn’t
>>> even talked to when this happens.
>>>>
>>>> Is there any tuning I can do to the TAC+ server to make sure its
>>>> able to
>>> handle the connections?   What debug log level should I be looking at to
>>> get the best information?  I’ve tried 24, 60, and even the higher
>>> ones, but they’re too noisy.
>>>>
>>>>
>>>> —
>>>> Matt Almgren, Sr. Network Engineer
>>>> [cid:29988614-ECDA-44BA-8377-ABD3ACFBCD1C]
>>>> 101 Lytton Avenue, Palo Alto, CA 94301
>>>> m: 408.499.9669
>>>> www.surveymonkey.com
>>>> -------------- next part -------------- An HTML attachment was
>>>> scrubbed...
>>>> URL: <
>>> http://www.shrubbery.net/pipermail/tac_plus/attachments/20151020/1db9
>>> bcf7/attachment.html
>>>>
>>>> -------------- next part -------------- A non-text attachment was
>>>> scrubbed...
>>>> Name: 7B2F1B3D-E309-404C-ADEF-2AE84F8259F4[35].png
>>>> Type: image/png
>>>> Size: 8698 bytes
>>>> Desc: 7B2F1B3D-E309-404C-ADEF-2AE84F8259F4[35].png
>>>> URL: <
>>> http://www.shrubbery.net/pipermail/tac_plus/attachments/20151020/1db9
>>> bcf7/attachment.png
>>>>
>>>> _______________________________________________
>>>> 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
> 
> _______________________________________________
> 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
> 

-- 
Alan McKinnon
alan.mckinnon at gmail.com