Segurança : Cisco Secure Access Control Server para Unix

Melhores prática para a administração do Cisco Secure ACS para UNIX

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento fornece os melhores prática administrando Cisco (CS) ACS seguro para o aplicativo UNIX. As recomendações apresentadas neste documento são baseadas em experiências do projeto e do desenvolvimento pelos coordenadores de desenvolvimento Cisco (DE).

Pré-requisitos

Requisitos

Os leitores deste documento devem estar cientes destes tópicos:

  • configurando e administrando CS ACS para UNIX

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

  • Versão UNIX CS ACS 2.3(5)

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Lista dos melhores prática

Está abaixo uma lista dos melhores prática recomendados.

Etapas

Conclua estes passos:

  1. Certifique-se de que a base de dados de sqlanywhere não excede 5000 perfis de usuário.

  2. Os registros de contabilidade não devem exceder 50,000 registros nas tabelas de relatório.

  3. Execute o diário do utilitário AcctExport.

  4. Se a taxa de transação é muito alta, e há um tráfego enorme da contabilidade tais que há mais de 50,000 registros de contabilidade, a seguir execute o AcctExport duas vezes ou baseado extremamente na carga.

  5. Certifique-se de que há disco adequado e espaço de troca disponíveis na caixa Solaris.

  6. Execute a revista mensal do utilitário de descarga db. Isto ajudará a reduzir o tamanho da base de dados csunix.

  7. O csecure. db deve nunca exceder 1 GB do espaço de disco.

  8. Se o csecure. db excede em tamanho muito rapidamente, a seguir certifique-se de que o dbunload está executado mais frequentemente.

  9. Se o raio AAA não é usado no CS, a seguir este pode ser desabilitado com a ajuda – da bandeira R em /etc/rc2.d/S80Ciscosecure.

  10. No tempo de execução, os erros de Servidor DB, incluindo os erros encontrados na relação ao base de dados, são relatados nos arquivo históricos/no arquivo <date> do csdb_. Todos os erros inesperados ou informação de travamento pela máquina virtual de java são arquivo entrado do log/dbserver.log. Verifique estes arquivos para ver se há todos os erros.

  11. Se o AAAServer causa um crash, os arquivos principais estarão ficados situados no $BASEDIR/corefiles. Verifique para ver se há a existência dos arquivos principais, se exister.

  12. Backup o base de dados regularmente (diário ou semanal), com base nas necessidades dos clientes.

  13. Para o melhor desempenho, desabilite os recursos de registro do csuslog. Isto aumentará drasticamente o desempenho.

  14. O valor do ulimit deve ser 4096 em /etc/system, /etc/rc2.d/S80Ciscosecure $BASEDIR/bin/DBServer.sh

  15. Remova csecure.log regularmente. Antes de remover csecure.log, o CS deve ser parado.

  16. Manualmente não adicionar/altere/supressão as tabelas de base de dados diretamente - use somente os métodos suportados.

  17. Arquive o diretório $BASEDir/logfiles uma vez por mês.

  18. Arquive arquivos de /var/log/csuslog regularmente, e apare o tamanho emitindo o comando cat /dev/null > csuslog. Se o arquivo é suprimido, o Syslog não trabalhará, e daqui o log não será reorientado ao arquivo do csuslog.

  19. Edições do servidor DNS: Se o sistema de destino tem um DNS configurado, ou se o sistema operacional solaris esteve configurado como um servidor DNS, o cuidado especial deve ser tomado para segurar que o desempenho DNS e as operações são plenamente operacionais.

    Se o sistema Solaris do alvo do servidor ACS CS tem o DNS permitido, pôde haver umas edições do desempenho ou da autenticação para CS ACS. O CS ACS não chama diretamente um servidor DNS; contudo, os atendimentos de sistema operacional solaris “gethostbyadd_r” e puderam indiretamente chamar o servidor DNS, se configurado para fazer assim. Verifique o arquivo de /etc/nsswitch.conf para ver se há tal configuração. Se a operação de resolução do Domain Name DNS não trabalha nem é lenta, esta afeta diretamente CS ACS.

  20. Ao executar ferramentas tais como o dbbackup e o dbunload, o PATH deve corretamente ser ajustado. Se não, as ferramentas não podem trabalhar corretamente. $BASEDIR/utils/bin/env_setup pode ser usado ajustando o trajeto. Este arquivo contém todos os variáveis ambientais exigidos e outros detalhes do trajeto.

  21. Os parâmetros da MaxConnection e do ConnectionLicense devem ser ajustados para encontrar as necessidades baseadas no número de autenticações e no número de transações que o CSU pode segurar. A MaxConnection pode ser ajustada a um valor máximo dos 50 pés, se o DB usado é SqlAnyWhere. Aumente o ConnectionLicense em $BASEDIR/config/CSConfig.ini, e aumente correspondentemente o valor da MaxConnection em $BASEDIR/CSU/libdb.conf a um valor dois menos do que o ConnectionLicense baseado na carga.

  22. Ao usar scripts automatizados para entrar ao Roteadores e ao Switches, e para executar comandos, é uma boa prática colocar o roteador regular/comandos switch no meio dos comandos sleep. Isto ajuda espalhou a carga e evitou contenções de recursos no server CS.

  23. Mais, estes scripts automatizados devem corretamente fechar sessões de Telnet (mesmo no caso das falhas do comando any) para assegurar recursos não são travados no server CS.


Informações Relacionadas


Document ID: 63755