SSL perde status de protocolo com criptografia eficaz

System

Devido às recentes falhas de segurança no protocolo de segurança SSL, a mais notável nomeada como POODLE, o PCI Security Standards Council ( Conselho de Padrões de Segurança ), responsável pelo desenvolvimento, gerenciamento, treinamento, e conscientização a respeito dos Padrões de Segurança PCI, que incluem o PCI DSS ( Padrão de segurança de Dados ), o PA-DSS ( Padrão de segurança de Dados em Aplicações de pagamento ), entre outros, resolveu implementar modificações em seus padrões de segurança na transmissão de dados.

A mudança de maior impacto foi declarar esta semana que nenhuma das versões do protocolo SSL atende aos requerimentos de uma criptografia forte, logo depois do NIST ( Instituto Nacional de Padrões e Tecnologia ) ter divulgado que o SSL 3.0 não é mais aceitável para a proteção de dados devido a falhas inerentes ao protocolo.

Depois de trabalhar vários dos últimos meses com diversos interessados, buscando entender o impacto dessas modificações para a indústria como um todo, o Conselho publicará em breve a versão 3.1 dos padrões PCI DSS e PA-DSS visando corrigir esse problema, além de prover outras atualizações menores e explicações.

Quando publicada, a PCI DSS 3.1 será efetivada imediatamente como padrão, porém as companhias terão tempo para adequarem-se e implementar as mudanças que impactem seus negócios. Para a PA-DSS 3.1, o Conselho também estudo como lidar com as futuras submissões e a atual lista de aplicações. Um resumo com as mudanças, assim como uma FAQ, irá acompanhar a versão revisada de cada padrão, para ajudar a esclarecer o impacto dessas mudanças.

Nas palavras da própria organização, “neste ínterim, como não há formas de remediar as vulnerabilidades inerentes ao protocolo SSL, o PCI Security Standards Council recomenda fortemente que as organizações trabalhem com suas equipes de TI e/ou parceiros para compreender se estão usando SSL e determinar as opções disponíveis para atualizarem para um protocolo de criptografia forte o mais rápido possível”. Alguns dos possíveis poderiam ser o TLS, ou o IPSec, dependendo do tipo de tecnologia utilizada por cada companhia.

Para consultar o anúncio original, consulte o artigo disponível no site do PCI Security Standards Council.

Anúncios

Slackware Linux e… o gerenciamento de pacotes – parte 1

Slackware logo

Fui questionado a respeito do modo como a Slackware Linux lida com a instalação de seus aplicativos, ou seja, a forma como é feito o gerenciamento de pacotes na distribuição, e como sempre, o questionamento estava relacionado a resolução de dependências. A resposta é simples, não há resolução de dependências, por padrão, no gerenciamento de pacotes da distribuição. Mas, veja bem, eu disse por padrão, não disse que não era possível dispôr do recurso quando se usa a Slackware Linux.

Para tentar esclarecer o assunto, começo agora uma nova série de artigos chamada “Slackware Linux e…”, que tratará não só sobre este tópico, mas vários outros que virão em seguida, e que geralmente são dúvida de usuários de outros sistemas GNU/Linux, não derivados desta distribuição, ou de outros sistemas operacionais, interessados em começar a usar uma distribuição GNU/Linux. Portanto, vamos lá! E para começar, vamos ver o que dizem os desenvolvedores da distribuição sobre este primeiro assunto da série.

Consultando a documentação disponível no projeto SlackDocs, mantida por colaboradores, e administrada por membros da equipe de desenvolvimento da Slackware Linux, encontramos a seção que trata sobre o assunto gerenciamento de pacotes, onde há registros sobre como a equipe aborda esse tópico.

Na opinião dos desenvolvedores, embora a grande maioria das distribuições implemente a resolução automática de dependências, algumas das razões pelas quais a Slackware Linux não disponibiliza esse recurso são:

  • A resolução automática de dependências requer que a manutenção relacionada a este recurso tenha desenvolvimento constante, e adiciona potencial para um “tormento em dependências”;

  • A distribuição oficial da Slackware Linux é intencionada para atuar como um todo coeso. Assim, o gerenciamento de dependências é um tanto irrelevante já que a instalação de toda a distribuição (a forma recomendada) cuida da maioria dos problemas de dependências;

  • Diversas aplicações de Código Aberto podem ser compiladas com diferentes dependências baseadas em mudanças de configuração em tempo de compilação. Isso faz com que a manipulação de dependências se torne mais difícil e a redistribuição de binários de softwares de terceiros mais suscetível a erros.

  • A distribuição oficial da Slackware Linux não dispõe de recursos ou mão de obra suficiente para gerir a manipulação de dependências para softwares de terceiros, o que é uma tarefa complexa, que exige uma série de testes, e é propensa a erros, como mencionado acima.

Dito isto, a página ainda trás a recomendação para a utilização de uma ferramenta que pode ser instalada na distribuição, e que pode lidar com a resolução automática de dependências para softwares de terceiros, e à qual fiz apenas menção no início deste texto, além de sugerir a utilização de uma distribuição GNU/Linux, chamada Salix OS, derivada da Slackware Linux, e que disponibiliza a resolução de dependências por padrão. Falaremos sobre a ferramenta citada em um post dedicado a ela, em um novo texto da série “Slackware Linux e…”.

Agora que já sabemos a opinião, e os motivos, pelos quais os desenvolvedores da Slackware Linux não implementaram o recurso de resolução automática de dependências, vejamos então como é feito o gerenciamento de pacotes nesta distribuição.

Bem, a princípio, a Slackware Linux dispõe, por padrão, de algumas ferramentas que compõem a base do gerenciamento de pacotes na distribuição. Entre estas encontramos a installpkg, a upgragepkg, a removepkg, além da pkgtool, que concentra um menu em que as ferramentas citadas anteriormente também são utilizadas. Todas elas necessitam que o usuário esteja acessando o sistema com poderes de administrador, e sejam executadas em um terminal.

Cada uma das ferramentas tem sua funcionalidade bem definida, instalando, atualizando, ou removendo pacotes. Já a pkgtool realiza diversas funções, sendo inclusive invocada durante a instalação do sistema, podendo citar como exemplos a instalação de pacotes utilizando o diretório corrente, a partir de um diretório diferente, ou de uma mídia específica, a remoção de pacotes que estejam atualmente instalados no sistema, mostrar uma visão geral dos pacotes instalados com suas descrições, além da opção de escolha de scripts executados durante a instalação, para serem novamente executados, alterando opções anteriormente selecionadas.

Para executar a ferramenta pkgtool, basta digitar o comando no terminal, sem a necessidade de opções adicionais, como no exemplo a seguir:

# pkgtool

Para apenas instalar pacotes na Slackware Linux, utilizamos o comando installpkg, juntamente com algumas opções, como mostram os exemplos a seguir:

Instalando um pacote a partir do diretório corrente

# installpkg -opções nome.do.arquivo-versão-arquitetura.txz

Instalando vários pacotes a partir de um diretório diferente

# installpkg -opções /local/onde/estão/os/arquivos/*.txz

Remover pacotes do sistema é tão fácil quanto instalá-los, e para isso utilizamos o comando removepkg, juntamente com algumas opções, conforme observamos no exemplo a seguir:

 # removepkg -opções nome.do.arquivo-versão-arquitetura.txz

Da mesma forma, atualizar um pacote já instalado é um procedimento simples, bastando para isso utilizar o comando upgradepkg, que atualiza o pacote instalado, e em seguida remove quaisquer outros arquivos e diretórios remanescentes que tenham restado do pacote anterior. Para tanto, basta digitar o comando, juntamente com algumas opções, como no seguinte exemplo:

# upgradepkg -opções nome.do.arquivo-versão-arquitetura.txz

Uma informação útil é que o comando upgradepkg não verifica previamente se a versão do pacote já instalado é superior à do “novo” pacote, portanto o mesmo comando pode ser utilizado também para realizar o downgrade de versões.

Bem, estas são as ferramentas básicas para o gerenciamento de pacotes, disponibilizadas por padrão na Slackware Linux. No próximo artigo desta série, veremos a ferramenta slackpkg, desenvolvida e mantida por um brasileiro. Para obter maiores informações a respeito de cada uma das ferramentas citadas, bem como verificar as opções aceitas por cada uma delas, basta acessar a man page referente à ferramenta que deseja consultar, também através do terminal.

Espero que tenham gostado deste primeiro artigo, mas caso tenham alguma correção, sugestão ou mesmo crítica, não deixem de deixar seus comentários aqui abaixo. Tão logo eu os revise ( ou seja, apagar um bocado de spams que vem junto a eles ) eu os liberarei e responderei quando necessário ou possível. Até breve!

Dividir para proteger!

Desgin_a_VLAN_based_network

Um artigo interessante me foi indicado, e trata de um assunto que é pouco comentado fora das salas de aula, ou mesmo implementado nas empresas com a devida manutenção posterior, que é a segmentação de redes. Ele afirma que, em uma pesquisa recente realizada com a participação de administradores de redes, aos quais foi pedido que descrevessem a segmentação das redes sob a administração destes, apenas trinta por cento destes revelaram que utilizam a técnica para a proteção contra as ameaças mais recentes. Outra terça parte informou que “implementaram e esqueceram” a segmentação, e outra parcela equivalente afirmou que a revisam de tempos em tempos, particularmente quando em momentos de auditoria. Corajosos seis por cento responderam com outra pergunta: “Descrever a minha o quê?”

Em tempos como estes, onde os ataques realizados com sucesso a redes privadas estão causando grandes danos, como o caso recente em que a Sony foi vítima de chantagem e teve considerável prejuízo com a divulgação de várias de suas produções através da Internet, a importância de segmentar e proteger as redes internas com várias camadas de segurança fica mais evidente. Para tanto, o artigo oferece algumas dicas para que a implementação da segmentação seja bem planejada:

Entenda os fatores organizacionais e de negócios. Para saber o que proteger, você precisa entender como são auferidas as receitas da organização, além de quais são os componentes que suportam a base do negócio. Então deve identificar os ativos, dados e pessoal crítico para garantir a continuidade dos negócios.

Crie um plano. Você quer classificar, isolar e proteger os componentes mais importantes. Agrupe componentes relacionados, por exemplo, todos os seus servidores Windows, em uma única rede virtual (VLAN). Outros grupos de ativos podem incluir componentes de infraestrutura, como roteadores, switches, VPNs e VoIPs, em outra VLAN e componentes de segurança, como IDS, firewalls, filtros web e escaners em outra.

Servidores dos setores financeiro ou de recursos humanos necessitam de suas próprias VLANs, devido a natureza confidencial dos dados que processam e armazenam. Você também pode separar grupos de pessoas em suas próprias VLANs, assim possuindo uma para administradores de servidores Windows, outra para o pessoal que cuida da segurança destes e outra para os executivos. Dados que requeiram proteção especial, para atendimento a normas regulatórias também devem trafegar em uma VLAN separada, como informações de cartões de crédito ou prontuários médicos.

Determine quem pode acessar quais dados. Isso resume-se às necessidades do negócio: Quem precisa administrar os roteadores e switches? Quem precisa acessar os sistemas de recursos humanos ou financeiros? Quantas pessoas deveriam poder controlar remotamente as câmeras de segurança? Seja impiedoso. Se não há necessidade de negócio então não deve ter acesso.

Organizações que operem inteiramente em nível regional doméstico ou local podem inclusive querem implementar bloqueio total a regiões geográficas remotas na camada IP. em geral, adote a negação de acesso por padrão para cada uma das VLANs. Seu objetivo é limitar o acesso a informações sensíveis para aqueles que precisam na organização e criar bloqueios que possam impedir, ou atrasar, a continuidade de danos potenciais de intrusos que possam ter ultrapassado uma camada de segurança.

Implemente a segmentação. Em uma organização de grande porte, a segmentação é um projeto significante e de longo prazo, mas cada passo nesse sentido aumenta a segurança. Comece em algum ponto, talvez com os administradores de redes, ou os servidores Windows. Nesse momento você poderia configurar VLANs chamadas administradores-redes (para as estações de trabalho deles) e dispositivos-rede (para roteadores e switches).

Registre em logs todo o tráfego entre os segmentos para determinar o que é neormal e necessário para o funcionamento efetivo. Uma vez que conheça o que é necessário, comece a bloquear o acesso às VLANs para todos os outros, com o objetivo final de negação por padrão. Tenha certeza de ter implementados os controles necessários para reforçar a segmentação e monitorar quaisquer mudanças requeridas posteriormente que possam vir a comprometer a segmentação. Continue o processo para cada grupo de ativos pessoal e informação.

Mantenha o ambiente. A segmentação de rede não pode ser abordada de modo a “implementar e esquecer”. A política de acesso às redes, definida nos firewalls, roteadores e dispositivos relacionados, muda constantemente para atender a novos requisitos de negócios. Assegurar que novas mudanças não violem sua estratégia de segmentação requer um bom nível de visibilidade e automação (essa visibilidade também é útil para evitar as interrupções ou a ruptura de negócios devido a má configuração destes acessos). A potencial sobrecarga no gerenciamento, necessária para a manutenção de uma boa segmentação, é uma das razões pelas quais as organizações fogem dela. Mas, a apropriada segmentação é crítica. Uma solução de segurança de redes ciente de topologia que possa automatizar o processo de segmentação é vital.

A segmentação de redes é um componente efetivamente inquestionável em uma estratégia de defesa em profundidade. Organizações que a implementam devem estar preparadas para gerenciar pontuações de firewalls, roteadores, switches, cada um com centenas de regras, cada uma delas sendo afetada por um processo de segmentação de redes e potencialmente por atualizações e mudanças, mesmo depois de estar implantada. Uma abordagem rigorosa é essencial, e um investimento significante de tempo e pessoal também é necessário. Mas independente disso, é muito mais fácil equipar a sua organização com uma defesa segura através de uma segmentação de redes apropriada, do que explicar a acionistas e a imprensa como hackers foram capazes de acessar milhões de registros em seu sistema.

Para acessar e conferir o artigo original, clique neste link.