UIA4

!
VERSÃO PARA IMPRESSÃO
SEGURANÇA DE REDES DE COMPUTADORES

UIA 4 | FERRAMENTAS E ESTRATÉGIAS DE SEGURANÇA
SEGURANÇA DE REDES DE COMPUTADORES | UIA 4 | 2
Este material é destinado exclusivamente aos alunos e professores do Centro Universitário IESB, contém
informações e conteúdos protegidos e cuja divulgação é proibida por lei. O uso e/ou reprodução total ou
parcial não autorizado deste conteúdo é proibido e está sujeito às penalidades cabíveis, civil e
criminalmente.
Copyright © 2017 Centro Universitário IESB. Todos os direitos reservados.

SUMÁRIO
Aula 19 | Análise de Logs .............................................................................................................5!

19.1. Logs ................................................................................................................................................5!
19.1.1. Geração de Arquivos de Logs ............................................................................................................................. 5!
19.1.2. Logs e sua importância.......................................................................................................................................... 7!
19.1.3. Caracterização e Padrões de Logs ..................................................................................................................... 8!
Marcação temporal (timestamp) .................................................................................................................................................... 8!
Severidade .............................................................................................................................................................................................. 8!
19.1.4. Armazenamento de Logs ..................................................................................................................................... 9!
19.1.5. Sistema de Gerenciamento de Logs ................................................................................................................. 9!
19.2. Arquivos de logs básicos de sistema Unix ................................................................................ 10!
19.2.1. ARQUIVO lastlog .................................................................................................................................................... 10!
19.2.2. ARQUIVO utmp/utmpx ........................................................................................................................................ 10!
19.2.3. ARQUIVO wtmp/wtmpx ...................................................................................................................................... 11!
19.2.4. ARQUIVO sulog ....................................................................................................................................................... 11!
19.2.5. ARQUIVO messages .............................................................................................................................................. 11!
19.2.6. ARQUIVO loginlog ................................................................................................................................................. 11!
19.2.7. ARQUIVOS pacct/acct .......................................................................................................................................... 12!
19.3. Aplicativos .................................................................................................................................. 12!
Aula 20 | Auditoria e Análise de vulnerabilidades com ferramentas automatizadas.......... 13!

20.1. Auditoria ..................................................................................................................................... 13!
20.2. Análise de vulnerabilidades ...................................................................................................... 13!
20.3. Nessus.......................................................................................................................................... 15!
20.3.1. Instalação .................................................................................................................................................................. 16!
20.3.2. Políticas ..................................................................................................................................................................... 17!
Aula 21 | Configurando a segurança de servidores Linux ...................................................... 19!

21.1. Hardening – O que é ................................................................................................................... 19!
21.1.1. Qual a saída, então? .............................................................................................................................................. 22!
21.2. Pós-instalação ............................................................................................................................. 23!
21.3. Arquivos com permissão de Suid bit ........................................................................................ 24!
21.4. Recomendações e boas práticas ............................................................................................... 25!
21.4.1. Remoção de Suid bit ............................................................................................................................................ 25!
21.4.2. Segurança no sistema de arquivos ................................................................................................................. 26!
21.4.3. Execução do procedimento ............................................................................................................................... 27!
21.4.4. Segurança no terminal ........................................................................................................................................ 32!
21.4.5. Desabilitar o uso de ‘CTRL+ALT+DEL’ ............................................................................................................ 33!
21.4.6. Controles de segurança para contas de usuários ...................................................................................... 33!
21.4.7. Controles de autenticação com a utilização do PAM ............................................................................... 34!
21.4.8. Sinalizadores de controle ................................................................................................................................... 35!
21.4.9. Caminho do módulo ............................................................................................................................................ 35!
21.4.10. Pam_time ............................................................................................................................................................... 35!
21.4.11. Pam_limit ............................................................................................................................................................... 36!
21.4.12. Pam_wheel ............................................................................................................................................................ 37!
Aula 22 | Configurando a segurança de servidores Windows ............................................... 38!

22.1. Necessidade de configuração de um bastion host .................................................................. 38!

22.2. Lista de Verificação (Check-list) ................................................................................................ 39!
22.3. Configuração de filtros de pacotes ........................................................................................... 39!
22.4. Criação de uma linha base de segurança (baseline) ................................................................ 42!
22.5. Desabilitando serviços desnecessários .................................................................................... 43!
22.6. Ferramentas de análise da segurança do Windows ................................................................ 45!
22.6.1. Windows Management Instrumentation Console (WMIC) .................................................................... 46!
22.6.2. SYSInternals ............................................................................................................................................................. 46!
22.6.3. Windows Server Update Services (WSUS) .................................................................................................... 47!
22.6.4. Microsoft Baseline Security Analyzer (MBSA) .............................................................................................. 48!
22.6.5. Microsoft Security Compliance Manager ...................................................................................................... 49!
22.7. Sistemas de arquivos e gerenciamento de usuários ............................................................... 50!
22.8. Group Policy Objects .................................................................................................................. 51!
22.9. Diretiva de senhas ...................................................................................................................... 52!
22.10. Diretiva de auditoria ................................................................................................................ 54!
22.11. Atribuição de direitos de usuários .......................................................................................... 54!
Aula 23 | Administrando Segurança de redes ......................................................................... 55!

23.1. Algumas considerações sobre a segurança e seus riscos ........................................................ 56!
23.2. A eterna e indefinida luta da segurança versus a funcionalidades desejadas ...................... 57!
23.3. A produtividade versus a segurança. Como fazer? ................................................................. 58!
23.4. Rede totalmente segura ............................................................................................................ 58!
23.5. Listas de verificação (checklist) ................................................................................................. 60!
Aula 24 | Tendências em Segurança Computacional.............................................................. 60!

24.1. Algumas considerações sobre a segurança e seus riscos ........................................................ 61!
24.2. A eterna e indefinida luta da segurança versus a funcionalidades desejadas ...................... 63!
24.3. A produtividade versus a segurança. Como fazer? ................................................................. 64!
24.4. Rede totalmente segura ............................................................................................................ 65!
24.5. Listas de verificação (checklist) ................................................................................................. 66!
24.6. Segurança em Cloud .................................................................................................................. 67!
Segurança em IoT ............................................................................................................................................................................... 68!
Segurança BYOD................................................................................................................................................................................. 70!
Novas perspectivas da Segurança - Tendências ..................................................................................................................... 71

Aula 19 |!ANÁLISE DE LOGS
Nesta aula veremos a importância dos logs e sua análise. Logs são os registros das atividades geradas
pelo funcionamento e operação dos programas e serviços implementados em um computador.
19.1.!LOGS
São registros de todos os eventos importantes produzidos pelo sistema operacional,
aplicativos e serviços, tornando possível a criação de um histórico de atividades que
permite que se conheça o que aconteceu ou o que está acontecendo.
Os logs são geralmente utilizados para fins de auditorias, solução de problemas e também são
empregados como prova digital, definindo as autorias e responsabilidades das ações em um sistema.
Estes registros são, normalmente armazenados em arquivos ASCII ou texto simples, capazes de
armazenar o que se passa com sistemas computacionais e serviços de rede. A correlação de logs de
eventos, segurança e auditoria são fundamentais para que se possa reconstruir o que efetivamente
ocorreu com um sistema computacional no passado.
É um registro cronológico sistemático de eventos ou atividades que pode ficar

armazenado em arquivos, na memória do computador ou em bases de dados.
Este conjunto de registros tem marcação temporal, que suportam apenas
inserção, e que representam eventos que aconteceram em um computador ou
equipamento de rede.
Os logs relacionados a incidentes de segurança, são normalmente gerados por

firewalls ou por sistemas de detecção de intrusão.
Geralmente é possível definir os logs por variados tipos de registros, tais como registros de eventos do
sistema operacional, de redes, de aplicações e de sistemas específicos, capazes de prover informações
vitais para a notificação de incidentes no ambiente computacional.
Todos os registros de log formam uma fonte essencial e básica de informação tanto para a detecção,
como para o processo de solução de problemas. Através de análises das informações fornecidas pelos
logs é possível detectar e identificar o uso indevido do ambiente de TI, exploração de vulnerabilidades,
ataques, rastrear e auditar as diversas ações executadas pelo usuário e detectar problemas de hardware
ou nos programas e serviços instalados no computador. Com base nestas informações é possível tomar
medidas preventivas para tentar evitar que um problema maior ocorra ou tentar reduzir os danos.
19.1.1.!GERAÇÃO DE ARQUIVOS DE LOGS

A geração de logs é um procedimento no qual os sistemas operacionais ou
aplicativos registram os eventos à medida que eles são gerados e preservam
esses registros para análise posterior.

Os arquivos dos registros de log fornecem a única evidência real de que uma determinada atividade
ilícita realmente aconteceu.
Os arquivos de registros de logs são essenciais para a notificação de incidentes,

pois são capazes de armazenar diversas informações importantes, como a data e o
horário em que uma determinada atividade ocorreu, o fuso horário, o endereço IP
de origem da atividade, os dados completos que foram enviados, alterados ou
excluídos e o resultado da atividade (se ela ocorreu com sucesso ou não).
A geração de logs é um arquivo de registros de eventos ou estatísticas para fornecer

informações sobre a utilização e performance de um sistema, ou seja, são extremamente
importantes para a administração segura de sistemas, pois possuem como objetivo
registrar informações sobre o seu funcionamento e sobre eventos por detectados.
Na grande maioria das vezes, os logs são o único recurso que um administrador possui para descobrir as
causas de um problema ou um comportamento anormal.
Os arquivos de logs se caracterizam por serem flexíveis, onde através de configurações é possível
registrar desde eventos críticos até praticamente todos os eventos de um sistema, desta forma, são
considerados a principal fonte de informação sobre o funcionamento dos programas servindo como
ferramenta para a correção de erros e verificações de rotina.
http://juliobattisti.com.br/artigos/windows/images/tcpip_p17_clip_image008.jpg
Qualquer registro de log gerado por um sistema pode ajudar a descobrir problemas na execução de
softwares, problemas de hardwares, tentativas de invasão, acessos indevidos, entre outras coisas.
Assim, é importante manter estes registros seguros e intactos, pois em uma

eventual auditoria de sistemas estes logs serão importantes.
A integridade e disponibilidade dos logs são fatores vitais para garantir a continuidade dos negócios.
Para tanto destacam-se as ferramentas que unificam a administração destes registros, pois possibilitam
gerenciar redes e sistemas informatizados mais complexos.

Através dos arquivos registros de log é possível registrar ações dos usuários, o que os torna uma ótima
fontes de informação para auditorias futuras. Os logs registram quem acessou os recursos
computacionais, aplicativos, arquivos de dados e utilitários, quando foi feito o acesso e que tipo de
operações foram efetuadas.
Desta forma, é possível identificar um invasor ou usuário não autorizado que realizou acesso a um
determinado sistema, apagou ou alterou dados, acessou aplicativos, mudou configurações do sistema
operacional com o intuito de prejudicar a organização e facilitar futuras invasões. Sem os registros de
logs, estas ações não seriam identificadas fazendo com que o administrador sequer ficasse sabendo que
houve uma invasão.
19.1.2.!LOGS E SUA IMPORTÂNCIA

Os logs para usuários, gerentes e analistas de segurança, técnicos de redes e
especialistas voltados para a área de segurança, é estratégico para a segurança de suas
arquiteturas e sistemas. Quando ocorrem incidentes de segurança como problema
com desktop, parada de um servidor, ataque a uma rede, alterações em banco de
dados entre outras situações de um ambiente tecnológico, os logs se tornam um
ponto comum de informação. Desta forma, o registro, a coleta e análise de logs são
procedimentos vitais em auditorias de segurança dentro de uma organização.
Uma auditoria de segurança bem sucedida depende da existência de registros de logs íntegros e
confiáveis. Independentemente do quão seguro é um computador, uma rede ou um sistema, nunca será
possível confiar totalmente nos registros de um sistema que foi comprometido, pois isso dificulta ou até
mesmo impossibilita uma auditoria de sucesso.
Se os registros de auditoria estão seguros é possível aumentar as chances de sucesso ao se correlacionar
e identificar padrões ou rever os incidentes de segurança ocorridos em um sistema. Para alcançar estes
objetivos é recomendável estabelecer um sistema de logs centralizado e dedicado, ou seja, que tenha
como função exclusiva a coleta, registro e análise de eventos de logs.
Ao armazenar dados gerados pelo sistema, aplicações, rede, atividades dos usuários, entre
outros, os logs fornecem inúmeras informações que se transformam em indicadores
capazes de medir os níveis de segurança e de avaliar se medidas de segurança estão
surtindo o efeito esperado e planejado.
A melhor forma de verificar a extensão de um incidente de segurança, identificando que
ativo foi violado e que a informação foi exposta é por meio dos registros de logs, por isso
eles são vitais para a continuidade dos negócios de uma organização. Neste ponto, é
importante ressaltar quanto ao uso correto dos softwares de análise de logs, pois estes
registros são gerados de diversas formas e devem ser interpretados corretamente,
possibilitando uma compactação e consolidação das informações no sentido de melhorar
a extração do resultado final.
Os logs asseguram, após a ocorrência de um desastre, falha ou violação de acesso, a estabelecer a

situação normal de funcionamento dos sistemas, portanto, o registro de eventos em sistemas
computacionais está ligado diretamente ao “Plano de continuidade de negócios”.

De acordo com o “Código de prática para gestão de segurança da informação – ABNT NBR
ISO/IEC 27002:2013”, é estabelecido que os sistemas sejam monitorados e eventos de
segurança da informação sejam registrados, tendo como principais objetivos:
•! Detectar atividades não autorizadas de processamento da informação;
•! Checar a eficácia dos controles adotados e para verificar a conformidade com o

modelo de política de acesso;
•! Auxiliar as organizações a estarem de acordo com todos os requisitos legais
relevantes aplicáveis para suas atividades (Conformidade).
Para saber mais sobre Logs: O que eles comem, onde vivem e como se
reproduzem, assista ao vídeo:
http://tinyurl.com/gonhgrw
19.1.3.!CARACTERIZAÇÃO E PADRÕES DE LOGS

Devido ao fato de existir uma grande quantidade de aplicações distintas, torna-se inviável haver um
padrão único para todas as mensagens de logs. Cada aplicação específica possui um formato diferente
para estes registros. Mesmo havendo estas particularidades, existem informações básicas que estão
presente na maioria dos logs.
MARCAÇÃO TEMPORAL (TIMESTAMP)
Contém a informação de data e hora que o registro de log foi gerado. É muito importante para que
possamos comparar a ocorrência de um evento com outros registros de log no tempo e, assim,
correlaciona-los;
SEVERIDADE
Caracteriza a importância daquele registro de log tendo em vista a integridade do sistema. É

determinada em escala gradativa contendo, no mínimo, cinco níveis:
a)! Debug ou trace - informações sobre o fluxo de execução do sistema, muito utilizada na fase de
desenvolvimento de um software;
b)! Info ou notice - caracteriza um evento meramente informacional;
c)! Warn - caracteriza um evento sobre o qual se deve ter uma maior atenção e, possivelmente,
executar uma ação para prevenção de um erro;
d)! Erro - caracteriza um evento de erro no sistema;
e)! Fatal - Caracteriza um erro grave, que pode causar danos ao sistema.
Existindo gerenciamento centralizado de logs, outra informação importante que deve estar presente
nestes registros é a fonte que o originou. Esta informação vai identificar o servidor, ou aplicação, que
gerou aquele evento de log.

19.1.4.!ARMAZENAMENTO DE LOGS
Os eventos de logs podem ser armazenados de duas formas: on-line e off-line.

O armazenamento on-line se refere à implantação de um servidor de logs centralizado e
dedicado à coleta e ao armazenamento de logs de outros sistemas em uma rede, servindo
como um repositório redundante de logs.
A principal vantagem desta forma de armazenamento é que um servidor de logs centralizado
facilita a análise dos logs e correlação de eventos ocorridos em sistemas distintos. Sempre que
possível, o uso de servidores de logs centralizados é fortemente recomendado.
O armazenamento off-line se refere ao armazenamento de logs em dispositivos, tais como
fita, HD externo, CD-R ou DVD-R. Na forma off-line é recomendável gerar um checksum
criptográfico, como por exemplo MD5, dos logs que são armazenados. Desta forma é
possível verificar a integridade destes registros.
19.1.5.!SISTEMA DE GERENCIAMENTO DE LOGS

Os logs possibilitam o acompanhamento do que acontece em um ambiente
informatizado.
Desta forma, é importante que eles sejam monitorados com frequência para possibilitar que eventuais
problemas sejam identificados e solucionados. Neste sentido, o gerenciamento de logs envolve um amplo
conjunto de atividades:
Análise Léxica e Processo que analisa as linhas de mensagens de log e produz uma saída
Transformação formatada em um padrão mais adequado para futuro processamento;
Transmissão e É um processo que transmite os eventos de log para um servidor central em

Recepção conjunto com o processo que recebe as mensagens de log no servidor;
Análise Sobre Eventos É o processo, que por meio de algoritmos, regras ou consultas extrai as
de Log informações relevantes sobre mensagens de logs;
Processo que reduz o tamanho de uma informação por meio de algoritmos de

Compactação
compactação de texto;
Armazenamento Compreende guardar os registros de logs por um tempo determinado;
Responsável por estruturar os registros de logs de forma que sejam

Indexação e Busca
posteriormente pesquisados;
Este processo permite a visualização dos registros de logs sejam eles em

Visualização
tempo real ou em registros já armazenados.
Este conjunto de atividades deu origem a uma nova classe de sistemas denominados de Sistemas de
Gerenciamento de Log (Log Management Systems – LMS). Estes sistemas implementam os
procedimentos acima listados e normalmente consistem em utilizar a forma de armazenamento on-line,
ou seja, um servidor de logs centralizado para receber, indexar, analisar e visualizar os eventos de logs.
Um LMS é capaz de suprir a necessidade de uma pequena aplicação até sistemas mais complexos com
grande volume de acessos e distribuídos.
Para Conhecer logs em sistemas Windows acesse o site

http://tinyurl.com/jdye3tc
19.2.!ARQUIVOS DE LOGS BÁSICOS DE SISTEMA UNIX

Os diretórios comumente usados pelo UNIX para armazenar logs são: /usr/adm, /var/adm, /var/log, /etc e
/etc/security. A localização exata depende do tipo e da versão do sistema operacional utilizado.
A seguir, serão apresentados alguns dos arquivos de logs encontrados em tais diretórios. É dado ênfase
aqueles considerados mais importantes no processo de detecção de intrusão.
19.2.1.!ARQUIVO LASTLOG
Arquivo binário que registra o horário da última vez que o usuário tentou acessar o sistema seja com ou
sem sucesso. O seu conteúdo muda a cada login e é reportado toda vez que o usuário entrar no sistema
ou o comando finger for executado. No Linux, estes registros devem ser explicitamente habilitados
configurando a variável LASTLOG_ENAB do arquivo /etc/login.defs.
É recomendável configurar as permissões deste arquivo para 644, tendo como dono o
usuário root.
Exemplos do comando:
lastlog -u nono
Irá informa o dia e a hora que o usuário nono logou no sistema pela última vez.
lastlog -t 3
Exibirá a lista dos usuários que logaram no sistema nos últimos 3 dias e informa o dia e a
hora do último acesso de cada um desses usuários.
19.2.2.!ARQUIVO UTMP/UTMPX
Estes arquivos registram informações relacionadas a usuários locais que encontram-se conectados ao
sistema nesse momento. Os dados contidos nestes arquivos são armazenados em formato binário.
Portanto, deverão ser lidos usando comandos específicos, tais como: who, whodo, write, finger e ps, os
quais reportam as informações contidas neste arquivo.
É recomendável configurar como dono o usuário root e as permissões de acesso

para 644.

19.2.3.!ARQUIVO WTMP/WTMPX
Registram dados detalhados sobre uma determinada sessão de usuário. Da mesma forma que os
arquivos descritos anteriormente, os dados contidos nestes arquivos são armazenados em formato
binário e legíveis unicamente através de comandos do tipo: last, acctcom, etc. Recomenda-se configurar
as permissões destes arquivos para 644, tendo como dono o usuário root.
19.2.4.!ARQUIVO SULOG
Registra tentativas de execução do comando su, tenham sido bem sucedidas ou não. Recomenda-se que
este arquivo tenha como dono o usuário root e suas permissões de acesso configuradas para 600.
19.2.5.!ARQUIVO MESSAGES
Fonte: http://tinyurl.com/jkcgtj8
Arquivo que registra qualquer mensagem enviada ao console, tendo sido ela gerada pelo kernel do
sistema ou por algum mecanismo de logging tal como o syslog. Recomenda-se que este arquivo tenha
como dono o usuário root e suas permissões de acesso configuradas para 400.
19.2.6.!ARQUIVO LOGINLOG
Registra tentativas falhas de acesso a um sistema. No Linux, é preciso configurar a variável FAILED_LOG
do arquivo /etc/login.defs. Para gerar logs de entrada neste arquivo, é preciso indicar o número mínimo
de tentativas consecutivas sem sucesso. Por padrão no Linux este número é de cinco, mas ele pode ser
alterado. No Linux isto é feito através do arquivo /etc/login.defs (variável LOGIN RETRIES). Recomenda-se
configurar as permissões deste arquivo como 600, tendo como dono o usuário root.

19.2.7.!ARQUIVOS PACCT/ACCT
Estes arquivos registram comandos executados individualmente pelo usuário.
O mecanismo de logging que utiliza arquivos deste tipo é conhecido como process
accounting e deverá ser inicializado pelo usuário root.
Vale salientar que, usados em conjunto com o arquivo wtmp é possível fazer um rastreamento dos
horários em que tais comandos foram executados. No Linux, o processo de contabilidade poderá ser
ativado conforme descrito no documento: Process-Accounting (mini-HOWTO). Recomenda-se que estes
arquivos tenham como dono o usuário root e suas permissões de acesso configuradas para 600.
Segue uma lista não exaustiva dos arquivos de logs mais importantes (podem variar de
acordo com o sistema operacional);
/etc/mail/maillog = Arquivo que registra os logs do Servidor de E-mails;
/var/log/messages = Contém registros de acesso ao sistema e em alguns casos registros do
IPTABLES;
/var/log/httpd/(access, error ou agent.log) = Logs do Servidor Web Apache;
/var/log/lpr.log = logs de impressoras. Hoje são visadas por atacantes, pois geralmente
não recebem atualizações ou são sistemas embarcados baseados em Linux ou Windows;
/etc/log/daemon.log = Logs de serviços em geral;
/var/log/syslog: log do sistema;
/var/log/auth.log: log de autenticação;
/var/log/kern.log: log do kernel;
/var/log/cron.log: log crond;
/var/log/lighttpd: log de erro e acesso a Lighttpd;
/var/log/boot.log: registro de inicialização do sistema;
/var/log/mysqld.log: registro de banco de dados MySQL;
19.3.!APLICATIVOS
Abaixo citamos alguns aplicativos que auxiliam a leitura e análise de logs:
•! Glogg - http://glogg.bonnefon.org/ - (Linux/Windows)
•! Event Log Explorer - http://eventlogxp.com/ (Windows)
•! Log Expert - http://www.log-expert.de/ (Windows)
•! Snake Tail - http://snakenest.com/ (Linux/Windows)

Aprenda mais assistindo aos vídeos:

http://tinyurl.com/nw9t9bo
http://tinyurl.com/zm9j37d
http://tinyurl.com/hkwcep3
http://tinyurl.com/zzj3ucn
Aula 20 |!AUDITORIA E ANÁLISE DE VULNERABILIDADES COM

FERRAMENTAS AUTOMATIZADAS
Podemos definir auditoria como a medição de algo contra um padrão. Apesar de estarmos tratando de
Segurança da Informação, o conceito de auditoria pode ser aplicado em qualquer área, como qualidade,
ambiental, financeira, de conformidade etc. Quando tratamos especificamente de auditoria de SI,
podemos estar auditando o cumprimento de uma política de segurança, a eficácia de um novo sistema
de segurança (um firewall por exemplo), se um sistema está com todas as correções conhecidas
aplicadas, entre outros. Nesta aula, vamos tratar especificamente de auditoria de segurança, utilizando
ferramentas e técnicas para verificar se as implementações de segurança realizadas estão provendo o
nível de segurança especificado. Entre as técnicas utilizadas em auditorias, as mais comuns são a análise
de vulnerabilidades e os testes de penetração (penetration testing ou pentest).
É importante ressaltar que vamos tratar apenas da auditoria de dispositivos de segurança, sem entrar em
questões de políticas, análise de risco e outros tópicos relacionados à governança e normatização.
20.1.!AUDITORIA
Processo com um conjunto de atividades, formais e controladas, que são realizadas para a avaliação dos
procedimentos de controle e segurança vinculados ao processamento das informações, visando garantir a
qualidade no tratamento das informações e a integridade, confidencialidade e disponibilidade dos dados.
Aprenda mais sobre auditoria nos vídeos

http://tinyurl.com/jefqadq
20.2.!ANÁLISE DE VULNERABILIDADES
Uma vulnerabilidade pode ser definida como uma brecha em um sistema
computacional.
Quando tratamos de programas (software), essas vulnerabilidades são muitas vezes chamadas de
bugs. Um sistema vulnerável pode ser um software, um sistema operacional, um roteador, um
protocolo ou até um hardware.

Essas vulnerabilidades podem ser exploradas com o intuito de subverter o sistema em

questão, causando indisponibilidade, obtendo controle sobre ele, acessando dados
sensíveis ou utilizando o sistema para atacar outros sistemas.
Existem diversos tipos de vulnerabilidades, sendo os mais comuns as vulnerabilidades de software,

causadas muitas vezes por validação insuficiente dos parâmetros recebidos, e as vulnerabilidades em
protocolos ou serviços.Essas vulnerabilidades podem levar a estouros de pilha (buffer overflow), negação
de serviços (DoS e DDoS), e até a acesso irrestrito ao sistema vulnerável.
Essas vulnerabilidades normalmente são descobertas por pesquisadores, que podem ser da própria
empresa que fabrica o produto ou pesquisadores independentes, que costumam notificar as empresas
sobre a falha para que elas possam lançar correções antes da divulgação pública. Infelizmente, muitos
administradores não aplicam as correções de segurança dos fabricantes nos sistemas sob sua
administração, de modo que estes ficam vulneráveis a falhas conhecidas e amplamente divulgadas. Uma
forma eficiente de verificar se uma rede, aplicação ou sistema operacional está suscetível a determinadas
falhas é com o uso de ferramentas de análise de vulnerabilidades. Essas ferramentas utilizam assinaturas
ou regras que simulam falhas conhecidas e produzem um relatório com os problemas encontrados e
possíveis soluções.
É importante, porém, salientar que:
a análise de vulnerabilidade não substitui o controle da aplicação de correções dos

fabricantes dos produtos utilizados em uma organização,
pois confiar na ferramenta pode levar à não aplicação de uma correção caso ela esteja desatualizada ou
mesmo não tenha sido atualizada para verificar uma vulnerabilidade específica.
Os principais objetivos da Análise de Vulnerabilidades são:
• ! Identificar e tratar falhas de softwares que possam comprometer seu desempenho,

funcionalidade e segurança;
•! Providenciar uma nova solução de segurança como, por exemplo, o uso de um bom antivírus,
com possibilidade de update constante;
•! Alterar as configurações de softwares a fim de torná-los mais eficientes e menos suscetíveis a ataques;
•! Utilizar mecanismos para bloquear ataques automatizados (worms, bots, entre outros);
•! Implementar a melhoria constante do controle de segurança;
Documentar os níveis de segurança atingidos para fins de auditoria e conformidade com leis,
regulamentações e políticas.
Como novas falhas são encontradas todos os dias, uma boa ferramenta de análise de vulnerabilidades
deve ser constantemente atualizada, de modo que possa detectar as falhas mais recentes descobertas.
Existe atualmente uma série de ferramentas de análise de vulnerabilidades, gratuitas e comerciais.
Algumas ferramentas gratuitas / open source: Nmap, Nessus, OpenVas, Microsoft MBSA; comerciais:
Rapid7 NeXpose (www.rapid7.com ), eEye Retina (www.beyondtrust.com/products/retina-network-
security-scanner/ ), GFI LANguard (www.languard.com/ ), IBM Internet Scanner.

Aprenda sobre o Retina assistindo aos vídeo:

http://tinyurl.com/zevv88d
A seguir, detalharemos o uso da ferramenta Nessus, que é gratuita para fins não comerciais e pode ser
obtida livremente na internet
20.3.!NESSUS
O Nessus é uma ferramenta de análise de vulnerabilidades, atualmente mantida
pela empresa Tenable Network Security. Apesar de originalmente ser uma
ferramenta open source, hoje a sua licença permite o uso gratuito apenas
residencial e para treinamento.
O uso comercial necessita da aquisição de uma licença específica. Por conta dessas mudanças, foi criado
um novo produto, a partir da última versão livre do Nessus, atualmente conhecido como OpenVAS.
O Nessus tem exatamente a função de encontrar "brechas" na máquina local, na

rede ou em uma rede de computadores.
Ele foi criado em 1998, como uma alternativa open-source aos vários softwares de
segurança comerciais da época, busca ser o mais atualizado possível e simples de usar,
sendo dividido em “Nessusd” (servidor) e “nessus” (cliente), ambos com versões para
sistemas operacionais Linux e Windows.
Possui arquitetura cliente/servidor e baseada em plug-in. Cada plug-in é utilizado em uma
vulnerabilidade de segurança que é enquadrada por órgãos competentes destinados a
lançarem boletins de segurança a respeito de falhas em sistemas de informação.
O Nessus pode ser utilizado para descobrir worms e backdoors instalados em estações de
trabalho e servidores. A ferramenta tem atualização frequente e suas funcionalidades
incluem relatórios completos, scanning de um grupo de hosts e buscas de
vulnerabilidades em tempo real.
O Nessus é software que tem o objetivo de fazer verificação remota e segura de

vulnerabilidades nos servidores de uma rede.
Com sua arquitetura cliente-servidor o Nessus possui do lado servidor compatibilidade com os sistemas
operacionais: Windows, Mac OS, Linux, FreeBSD e Solaris. Do lado cliente o Nessus disponibiliza acesso via https.
Com isso, é possível utilizá-lo em um navegador de qualquer sistema operacional. A Tenable também
disponibiliza clientes para celulares com aplicativos para os sistemas operacionais iOS e Android OS.
Algumas características do Nessus são iguais às características citadas do OpenVAS, pois, como citado
anteriormente, este é uma derivação dos códigos fontes do Nessus.

A verificação de vulnerabilidades feita pelo Nessus também utiliza programas escritos em NASL - Nessus Attack
Scripting Language – conhecidos como plugins. Atualmente o scanner de vulnerabilidades conta com mais de
50.000 plugins como é possível verificar na figura abaixo. A lista de plugins pode ser atualizada através da
inscrição nos serviços ProfessionalFeed (para uso comercial) e HomeFeed (uso doméstico). Na figura está
selecionado o plugin para verificar a vulnerabilidade de SQL Injection em paginas web.
Para instalar o Nessus é necessário baixar o pacote específico para o

Linux. O download do Nessus pode ser feito no seguinte endereço:
http://tinyurl.com/q6buj5d
Para conhecer mais sobre o Nessus leia e estude o seu guia do usuário
em: http://tinyurl.com/jeq5n6u
20.3.1.!INSTALAÇÃO
A instalação se da de forma fácil e rápida, podendo ser realizada a partir de um pacote deb para
distribuições baseadas em Debian.
A ferramenta é instalada em um ambiente virtualizado com Linux Debian.
Apos a instalação, é obrigatória a atualização dos plug-ins de segurança, o que demora um tempo
razoável. Duvidas podem ser consultadas no site do desenvolvedor, onde disponibilizado o
manual completo em português com passos de instalação e configurações.

Aprenda a usar o Nessus assistindo os vídeos:

http://tinyurl.com/hjenkp5
http://tinyurl.com/gppoyo8
http://tinyurl.com/hlj7jdr
http://tinyurl.com/m2ddhg3
Acesse também o site e aprenda mais sobre o Nessus
http://tinyurl.com/hlpsexz
http://tinyurl.com/gqmbh6p
20.3.2.!POLÍTICAS
Política no Nessus consiste em uma série de opções de configurações já relacionadas para realização de
uma varredura para identificação de vulnerabilidades. As opções são, entre outras, as seguintes:
•! Parâmetros que controlam aspectos técnicos da varredura, como intervalos de tempo, número
de hosts, tipo de scanner de porta etc.
•! Credenciais para varreduras locais (por exemplo: Windows, SSH), varreduras autenticadas de
bancos de dados Oracle, HTTP, FTP, POP, IMAP ou autenticação pelo Kerberos.
•! Especificações individualizadas de varreduras por família ou plugin.
•! Verificações de políticas de conformidade de bancos de dados, detalhamento do relatório,

definições de varredura de detecção de serviços, verificações de conformidade de Unix, entre
outras opções.
O Nessus é distribuído com várias políticas padrão criadas pela Tenable Network
Security, Inc. As políticas são fornecidas como modelos para ajudá-lo a criar
políticas adequadas à sua organização ou para serem usadas sem modificações
para varreduras básicas dos seus recursos.
Leia e entenda as políticas padrão antes de utilizá-los em varreduras com os seus recursos.
Nome da política Descrição
Varredura de rede Esta política foi projetada para a verificação de hosts externos e que
externa normalmente apresentam menos serviços à rede. Os plugins relacionados a
vulnerabilidades conhecidas de aplicativos da Web (as famílias de plugins CGI
Abuses e CGI Abuses: XSS) são ativados com a aplicação desta política. Além
disso, todas as 65.536 portas (inclusive a porta 0 por meio de plugin separado)
são examinadas em cada destino.
Varredura de rede Esta política foi projetada levando-se em conta a melhoria do desempenho, pois
interna pode ser usada para verificar redes internas de grande porte com muitos hosts,
vários serviços expostos e sistemas incorporados, como impressoras. As
varreduras de CGI estão desabilitadas e um conjunto de portas padrão é
examinado, mas não todas as 65.535.

Testes de aplicativos Esta política de varredura é usada para verificar os sistemas e fazer com que o
da Web Nessus detecte vulnerabilidades conhecidas e desconhecidas nos aplicativos da
Web. Os recursos de “difusão” do Nessus são ativados com esta política, o que
fará com que o Nessus detecte todos os websites descobertos e verifique as
vulnerabilidades presentes em cada um dos parâmetros, incluindo XSS, SQL,
injeção de comandos e vários outros. Esta política identificará os problemas via
HTTP e HTTPS.
As ferramentas automatizadas são capazes de cruzar informações, analisá-las e testar

as aplicações de uma maneira mais eficiente do que o teste de invasão manual.
Estas ferramentas têm amadurecido e a maioria das vulnerabilidades existentes hoje já está endereçada e
é bem resolvida. Além disso, como os aplicativos web continuam a crescer em tamanho, o teste manual
está ficando cada vez mais difícil. Em muitas organizações ele se torna praticamente impossível de ser
aplicado, pois seria necessária a dedicação de muito tempo, esforço físico e dinheiro.
Embora as ferramentas automatizadas e testadores qualificados possam navegar

em uma aplicação web, somente o testador é capaz de compreender a lógica por
trás do fluxo de trabalho da aplicação. Este entendimento permite ao teste manual
subverter a lógica do negócio.
Por exemplo, um aplicativo pode direcionar o usuário a partir do ponto A ao ponto B e ao ponto C, onde
o ponto B é uma validação de segurança. A revisão manual do aplicativo pode mostrar que é possível ir
diretamente a partir do ponto A ao ponto C, ignorando totalmente a validação de segurança.
Tanto os testes manuais quanto os automatizados são métodos exaustivos de identificação de
vulnerabilidades em aplicações web. Cada método tem suas forças e fraquezas inerentes e ambos podem
ser usados para descobrir vulnerabilidades críticas de segurança.
As ferramentas automatizadas nunca devem substituir completamente os

testes manuais.
gama de técnicas de vulnerabilidades, economizando tempo e dinheiro. Sofisticadas organizações

utilizam a combinação correta de ferramentas automatizadas e ensaios de invasão manual para
proporcionar uma melhor segurança do aplicativo web.
Conheça outras ferramentas a partir do site:

http://tinyurl.com/jgzfl2w

Aula 21 |!CONFIGURANDO A SEGURANÇA DE SERVIDORES LINUX
O coração do sistema Linux é o seu kernel e também seu Sistema Operacional.
Combinados, eles formam a base onde estão todas as suas aplicações que rodam no computador.
Comparativamente falando, o Sistema Operacional Linux e seu kernel são razoavelmente seguros. Um
grande número de opções de segurança estão inclusas no kernel e uma grande variedade de ferramentas
e configurações de segurança open-source já estão inclusas nas mais variadas distribuições.
Adicionalmente, o Linux oferece excepcional controle sobre quem, como e quais recursos e aplicações os
usuários podem ter acesso.
Mas o risco onde está?
Normalmente, “o problema está nos detalhes”. A segurança do sistema depende de uma enorme quantidade
de elementos de configuração em nível, tanto de Sistema Operacional quanto de aplicações. O próprio
Sistema Operacional e seu kernel são bastante complexos, e sua correta configuração não é um processo
trivial. Sistemas Operacionais baseados no kernel Linux possuem infinitas configurações, e cada ajuste pode
causar sérios problemas de segurança. Vulnerabilidades e falhas de segurança não são fáceis de encontrar.
Para estar apto para numerar esses pontos, precisamos adquirir sólidos conhecimentos sobre os
requisitos básicos de segurança do nosso Sistema Operacional e seu núcleo.
Hardening em Linux é um processo de proteção do Sistema Operacional, seu

kernel e suas aplicações contra ameaças conhecidas ou não através da aplicação
de técnicas específicas de controle, minimização de riscos e execução de
atividades corretivas.
21.1.!HARDENING – O QUE É
De acordo com a Wikipedia, “hardening é um processo de mapeamento das ameaças, mitigação dos
riscos e execução das atividades corretivas – com foco na infraestrutura e com o objetivo principal de
torná-la preparada para enfrentar tentativas de ataque”.
Já segundo a ITSecurity.com,
“hardening é o processo de otimizar as configurações de segurança de um

sistema, um termo comumente aplicado a Sistemas Operacionais”.
A palavra “hardening” tem origem no idioma inglês e significa “endurecimento”,

mas no contexto da Segurança Computacional também é o processo de proteger
um sistema através da redução de suas possíveis vulnerabilidades, por meio de
configurações que implementam controles específicos.

Esse processo implica realizar várias configurações, instalação de pacotes destinados a algum
procedimento de segurança e modificação de permissionamento com o objetivo de melhorar e reforçar a
segurança do ambiente.
Antes de iniciar a explanação sobre o tema, é interessante perguntar: o que é

hardening?
Ao considerar a principal tradução de hardening, que significa “endurecer-se”, é

exatamente isso o que desejamos fazer com um Sistema Operacional antes de
colocar um servidor em produção.
Essa ideia fica mais clara se for considerada a tradução como “fortalecimento”, que do ponto de vista
empírico pode ser explicado como um conjunto de configurações e melhoramento, ajustes finos que vão
gerar controles para que o sistema torne-se mais seguro.
Administradores sem muita experiência em segurança preparam seus servidores com uma instalação básica e
depois que suas aplicações já estão funcionando, acabam deixando da maneira que ficou, pois a possibilidade
de fazer com que aplicação pare de funcionar realizando um procedimento de segurança é grande.
Os Sistemas Operacionais modernos trazem muitos “controles” para melhorar a segurança e gerenciar
melhor o uso dos recursos, mas quando se trata de Sistema Operacional moderno, desenhado para
prover serviços de redes, é muito comum que esses controles estejam desabilitados. Uma prova disso é
que a maioria das distribuições são vulneráveis a um ataque de fork bomb (código que tenha a função e
a capacidade de se replicar indefinidamente), ou seja, um ataque simples que consiste em exaurir os
recursos, abrir um processo após o outro até não termos mais recursos e o servidor travar.
Um ataque de fork bomb no Linux é facilmente efetuado executando a seguinte

instrução em uma shell:
$ :(){ :|:& };:
Esse é um exemplo de função que é executada de forma recursiva. É um meio conhecido e

frequentemente usado por administradores de sistemas para testar as limitações dos processos de
usuário, embora os limites de execução de processos de usuário em um sistema Linux possa ser
configurado via / etc / security / limits.conf e PAM. É comum não ter nenhuma definição estabelecida em
um sistema Linux. Dessa forma, um usuário comum pode causa uma Denial of Service (DoS) através de
um fork bomb.
Uma vez que um fork bomb é executado em um sistema, pode não ser possível mais retomar o
funcionamento normal sem reiniciar o sistema como a única solução. Isso acontece porque a única
solução é destruir todas as instâncias do sistema, mas a ação é tão rápida que raramente haverá uma
oportunidade para interromper o ataque.
Entendendo o Fork Bomb via /bin/bash:
•! “:()” é a definição da função chamada “:”, uma função que não aceita
argumentos.
A sintaxe para a função via Bash é:
:(){ :|: & };:

•! “:|:” em seguida, dentro do corpo da função, é feita uma chamada usando a

técnica de programação chamada “recursão”, motivando a gradual alocação de
recurso do Sistema Operacional, tendo por consequência um travamento do
sistema;
•! “&” coloca a chamada de função em segundo plano para que cada processo-
filho criado não morra e fique consumindo recursos do sistema;
•! “;” finaliza a definição da função;
•! “:” faz a chamada para execução novamente.
Um exemplo mais prático poderia ser:

fork_bomb() {
fork_bomb | fork_bomb &
}; fork_bomb
Um ataque de fork bomb é motivo suficiente para se pensar em um hardening. Entretanto, no momento
que se inicia a implementação das técnicas de hardening, é necessário pensar em três fatores: segurança,
risco e flexibilidade, como observado na figura a seguir:
O desafio é saber dosar muito bem esses três fatores para definir um conjunto de controles que possam
proporcionar ao sistema equilíbrio entre produtividade e segurança. Muitas perguntas podem ocorrer
durante o processo, como:
“Qual o nível de segurança desejado? Quanto o sistema vai ficar em conformidade

com a políticas de segurança definidas? Quão editável deverá ficar o sistema?”
Outro grande desafio é que os fatores “segurança” e “flexibilidade” ou mesmo “segurança” e “risco” são
inversamente proporcionais e consequentemente impactam diretamente no risco. É um fato que não é possível
ter segurança 100%, mas, por outro lado, quanto mais segurança, menores serão o risco e a flexibilidade.
Uma vez que não é possível ter 100% de segurança, deve-se elaborar o maior número possível de
controles para tornar um Sistema Operacional mais seguro. Dessa forma, o hardening permite mitigar
possíveis vulnerabilidades.

21.1.1.!QUAL A SAÍDA, ENTÃO?
!! Com metodologia
É notório que, quando são implementados controles, o sistema passa a prover um

ambiente mais rígido, possibilitando pouca flexibilidade. Por outro lado, se em um
sistema damos grande flexibilidade ao usuário, é fato que a segurança será diminuída
e os riscos vão aumentar. Por exemplo: um cenário de Sistema Operacional onde não
exista qualquer diretriz de segurança e se permita que qualquer tipo de programa
possa ser executado por qualquer usuário. Somando-se a isso ainda existem
complicadores, que podem ser divididos em dois grupos:
- Vulnerabilidade conhecida: servidor com um sistema legado que naquele momento
não pode ser desligado, por exemplo;
- Vulnerabilidade desconhecida: uma vulnerabilidade do Sistema Operacional que
ainda não foi reportada pelo fabricante ou uma correção não publicada.
Não existe regra direta devido ao fato de que depende de cada situação e de acordo com o tipo de necessidade.
Por isso, toda implementação de um servidor deve ter seu planejamento de segurança bem definido antes de
sua instalação, ou seja, a elaboração do baseline que formalizará o hardening é fundamental.
Deve-se lembrar que o conjunto de técnicas e ferramentas para implementação de um hardening,
normalmente utilizadas em um Sistema Operacional Linux sejam interessantes do ponto de vista de
garantia dos serviços e realmente agreguem à segurança. Não será incomum o fato de que um conjunto
de ações pré-estabelecidos em uma baseline não se apliquem em todas as situações. Cada caso é um
caso. É preciso analisar e descobrir que controles serão mais adequados para a necessidade em questão e
também qualificar o quanto de segurança foi estabelecido no respectivo contexto.
A segurança na camada do Sistema Operacional é iniciada no hardening, mas não termina nele. E deve
ser aderente, ou seja, estar em conformidade com as políticas das empresas.
Diante disso, é conveniente lembrar que ferramentas são importantes, mas não são
o fim e sim o meio para a execução dos procedimentos do processo, que, somados
a outras ações, como a capacitação das pessoas envolvidas, é fator determinante
de sucesso, pois a imperícia é um inimigo de qualquer trabalho. Explicando de um
ponto de vista prático, esse processo envolve:
•! A remoção ou desativação de serviços desnecessários;
•! Remoção de contas de usuários-padrão;

•! Desinstalação de pacotes desnecessários;
•! Definição do processo de atualização;
•! Definição de controles para auditoria;
•! Definir controles para limites do uso dos recursos pelas aplicações e/ou usuários;
•! Instalação de pacotes de ferramentas de segurança e auditoria.

21.2.!PÓS-INSTALAÇÃO
Após o planejamento da instalação e sua execução, o sysadmin vai iniciar a execução do hardening, que
também foi previamente planejado no Baseline. É fato que um bom processo de hardening tem como
princípio “menor recurso e menor privilégio”.
Um bom exemplo da aplicação desse princípio é verificar a lista de pacotes instalados, pois serão
identificados possíveis pacotes que não são necessários para a finalidade do servidor ou aplicações que
demandarão ter o permissionamento revisto.
Os comandos a seguir podem ser utilizados:

No Debian:
# dpkg -l | awk ‘{print $2,$3}’ | sed ‘1,7d’

gravando o resultado em um arquivo
# dpkg -l | awk ‘{print $2,$3}’ | sed ‘1,7d’ > /root/pacotes
No Red Hat:
# rpm –qa
gravando o resultado em um arquivo
# rpm –qa > /root/pacotes
A CIS Security também cita a remoção de programas que não estão em uso e ressalta que tais programas
podem ser usados por um exploit (código que explora a vulnerabilidade de um programa para ganhar um
acesso não autorizado ao sistema) para um ataque tanto local quanto remoto, dependendo do programa.
Exemplos de programas que podem ser desnecessários, dependendo do tipo de servidor:
•! lynx: cliente http/ftp que possibilita transferência de malware;
•! wget: cliente http/ftp que possibilita transferência de malware;
•! netcat (nc): “canivete suíço” que possibilita transferência de malware ou até mesmo criar backdoors;
•! hping: montador de pacotes que possibilita criar backdoors via rawsocket.

Por outro lado, existe também a questão dos pacotes básicos que devem ser instalados em um servidor,
como, por exemplo, um bom sistema de registro de eventos (logs), um serviço de sincronização de
relógio (NTP) e ferramentas que auxiliem o administrador a uma resposta inicial de incidente.
Outro ponto importante: que os comandos sejam testados em duas máquinas virtuais (uma Debian e
outra Ubuntu). No caso das exceções, no momento oportuno será informado. Isso também é importante
para lembrar que, embora as sugestões recomendadas sejam aplicadas de qualquer distribuição Linux,
deverá o sysadmin avaliar como fazer em sua distribuição. O fato de ser Debian não limita ou mesmo
tornam exclusivos os conceitos e recursos a esse cenário, pois administradores mais experientes deverão
saber interpretar as diferenças entre as distribuições, além do fato de os procedimentos serem baseados
no modo Command Line (CLI), o que torna a reprodução praticamente universal, pois fica vinculado
apenas à shell usada, que foi /bin/bash.
Muitos outros aplicativos podem entrar nessa lista, como: nmap, tcpdump, telnet (client), ftp (client) e
shred, pois, devido aos recursos que proporcionam, devem ser devidamente avaliados.
Caso a remoção do pacote seja a melhor decisão, esta pode ser realizada da seguinte
forma:
# apt-get remove --purge wget
Uma alternativa é rever o permissionamento dos binaries com o comando chmod, deixando-os apenas
com direitos para o root e em casos extremos definir regras via sudo para utilização desse aplicativos,
considerando sempre as questões de segurança. O sudo é um recurso que pode ser útil, embora deva ser
usando sempre com cautela.
A gestão de atualização de pacotes é uma tarefa necessária, pois é vital à

segurança. Diante disso, é preciso ter controles definidos para habilitar recursos no
Sistema Operacional que facilitem essa tarefa importante.
Em distribuições Like Debian com Ubuntu, um aplicativo interessante é o apticron, que

informa por e-mail pacotes que devem ser atualizados. O apticron é um shell script que
usa as informações do apt-listchanges. Para instalar o apticron:
# apt-get install -y apticron
Durante a instalação é inserida uma entrada no /etc/cron.d, similar a esta:
# cat /etc/cron.d/apticron
15 * * * * root if test -x /usr/sbin/apticron; then /usr/sbin/apticron --cron; else true; fi
As configurações do apticron ficam no /etc/apticron. Normalmente basta inserir o e-mail
do administrador. Segue um exemplo de configuração:
# cat /etc/apticron/apticron.conf | grep -v ˆ#
EMAIL=”teste.pafuncio@seila.com.br”
DIFF_ONLY=”1”
LISTCHANGES_PROFILE=”apticron”
!"#$%&'!()*+,+-./#"0'/.12(-#*+0$345(6789:5; /9<=8>?@A; BC>:D; E9; 5?=5F>G5HID; E9;
75<D?9:
21.3.!ARQUIVOS COM PERMISSÃO DE SUID BIT

A permissão de Suid bit possibilita que um determinado binário possa ser executado por outros ou por
membros do grupo com os mesmos direitos do “usuário efetivo”, ou seja, usuário dono. Isso cria a
possibilidade se o usuário dono de um determinado binário for o usuário root, com a atribuição do
direito especial de suidbit a esse binário, o binário poderá ser executado por outro usuário comum do
sistema com o mesmo poder do root.
Muitos binários no sistema já vêm com a permissão de Suid bit, devido ao fato de que alguns desses
binários cujo dono é o usuário root necessitam em algum contexto serem usados por um usuário
comum. Exemplos clássicos desses comandos são o su, o ping, e o passwd, entre muitos outros.

Mas uma coisa deve ser avaliada: será que todos esses binários que já estão com a
permissão de Suid bit serão usados por algum usuário comum do sistema? Será
que os usuários comuns do sistema precisam de todos esses comandos à
disposição? Será que no servidor em questão usuários comuns terão shell válida?
Demanda-se que o administrador fique atento para esses detalhes.
Como o sistema possui muitos binários com Suid bit, problemas como a combinação de shells com Suid
bit podem passar despercebidos. Dessa forma, o conceito de “menor privilégio e menor recurso” deve
sempre ser um balizador para decisões.
Então, o que pode ser feito? Retirar todas as permissões de Suid bit do sistema e somente deixar as
permissões para os binários que sejam fundamentais para operações de um determinado usuário. No
entanto, não existe regra geral: haverá casos diferentes, pois os binários que julgam-se importantes para
um servidor firewall, por exemplo, podem não ser para um servidor de e-mail.
21.4.!RECOMENDAÇÕES E BOAS PRÁTICAS

É uma boa prática que o acesso à informação e às funções dos sistemas de aplicações por usuário e
pessoal de suporte seja restrito de acordo com o definido na política de controle de acesso.
Dessa forma, a remoção da permissão de Suid bit dos diversos binários que a possuem deve ser mais um
procedimento de hardening.
A CIS SECURITY também recomenda a remoção da permissão de Suid bit dos diversos binários que a possuem.
21.4.1.!REMOÇÃO DE SUID BIT
Para a remoção de todas as permissões de Suid bit dos binários, é necessário fazer uma
pesquisa no sistema e gerar lista com todos para melhor análise. Nesta exemplificação será
criado um diretório chamado “teste”, dentro do /root para que seja gravada a lista de
arquivos com Suid bit, que será gerada pelo comando find.
# cd /root
# mkdir teste
# find / -perm -04000 > /root/teste/lista.suid
O número 4000 representa a permissão de Suid bit. Embora seja passado o parâmetro -04000, a parte
importante são os quatro últimos dígitos. Os três zeros são as permissões-padrão do sistema (0 para
usuário, 0 para grupo e 0 para outros), e o 4 representa a permissão Suid bit. Podemos ter no lugar do 4 o
número 2, que é o direito especial denominado Sgid bit, ou 1, que representa stick bit.
Vamos fazer uma listagem detalhada em um desses binários para ver como a permissão de
Suid bit é representada:
# ls -l /bin/su
Nas permissões do usuário, é representado um s no lugar do x para indicar Suit bit. Isso
representa que a permissão de Suid bit está ativada, mas a permissão de execução (x) é
intrínseca ao Suid bit.

Com a lista gerada com todos os binários, podemos avaliar quais binários realmente
necessitam continuar com a permissão de Suid bit. Considere um exemplo de um Bastion
Host, que é o firewall da uma rede. Podemos deixar dois binários com o Suid bit definidos para
os binários passwd e su. Deixar o passwd para que um usuário comum possa mudar a sua
senha de acesso caso seja um administrador e acesse essa máquina remotamente assumindo
que em um contexto como esse o root não faz login diretamente, tanto local ou remotamente.
Já o comando su vai ser de vital importância, pois caso o usuário root não tenha acesso direto,
o administrador então terá de efetuar o login com seu usuário comum e poderá usar o su para
se tornar o usuário root. Como retirar todas as permissões de Suid bit dos binários:
# chmod -s -Rv /
Onde:
•! -s: retira a permissão de Suid bit;
•! -R: é recursivo, do / (barra) para baixo;
•! -v: é o modo verbose (mostra o que está sendo feito pelo comando).
# ls -l /bin/su
Logo após remover o Suid bit de todo o sistema, basta definir a permissão de Suid bit
somente para os dois binários que julgarmos realmente necessário.
# chmod +s /usr/bin/passwd
# chmod +s /bin/su
# ls -l /usr/bin/passwd
# ls -l /bin/passwd
Pode ser que para um determinado servidor só o passwd e o su não sejam suficientes. Provavelmente
outros binários precisem estar com o Suid bit ativado. Cabe ao administrador analisar o que será
necessário para cada tipo de serviço. Uma solução alternativa ao Suid bit é a adoção do comando sudo.
21.4.2.!SEGURANÇA NO SISTEMA DE ARQUIVOS

Na instalação de um sistema Linux, as boas práticas nas instalações aconselham a particionar o disco e
colocar os principais diretórios em partições separadas. Isso pode proporcionar maior segurança, pois
cada partição tem sua tabela separada e pode ter regras de montagem melhor elaboradas.
Logo, se toda instalação está concentrada em uma única partição, já se inicia um servidor com grande
limitação. Mas se temos um exemplo onde o diretório “/” (barra) está em uma partição e o “/home” em
outra, no caso de algum problema no sistema ou até em uma reinstalação, pode-se atuar na partição
“/home” sem interferir, em um primeiro momento, nas informações vinculadas ao diretório “/home”. As
definições de montagem que devem ser avaliadas para esse contexto são:
•! Nodev: tira o suporte a arquivos de dispositivos;
•! Noexec: desabilita o suporte à execução dos arquivos;
•! Nosuid: deixa desabilitado o suporte ao direito especial de suidbit;

•! Noatime: desativa o registro de tempo/data de acesso dos arquivos (denominado atime);
•! Ro: define que será somente leitura.

Entretanto, é relevante destacar que a segurança de um particionamento não se resume a isso.
Todas essas partições são montadas nos diretórios, e um erro que muitos administradores de sistemas
Linux cometem é não ler a documentação para conhecer melhor os recursos e descobrir que o comando
mount possibilita a utilização de algumas opções muito interessantes, que permitem melhorar muito a
segurança nas partições. Caso todos os diretórios estivessem na mesma partição – no “/” (barra) –, não
seria possível ter essas opções e usufruir desses recursos.
Mostramos assim que é possível retirar a permissão de Suid bit dos binários, mas só isso não resolveria.
“Pode-se cortar o mal pela raiz” com as opções do mount, dizendo que na partição em questão os
binários com permissão de Suid bit não terão efeito, ou seja, esse é um recurso muito interessante para
montagem: desabilitar a execução de binários com suitbit em uma partição definida, aumentando a
segurança do sistema através da limitação de um recurso poderoso.
21.4.3.!EXECUÇÃO DO PROCEDIMENTO
A primeira opção do mount que será mostrada é o nosuid, que faz com que binários com
permissão de Suid bit não tenham efeito na partição na qual estão definidos. Para um exemplo
prático, adicione um usuário:
# adduser teste
Faça uma cópia das shells do seu sistema para o diretório “home” desse usuário e atribua
às shells a permissão de Suid bit.
# cp /bin/*sh* /home/teste
# chmod 4755 /home/teste/*sh*
Efetue login em outro terminal com um usuário comum que foi criado anteriormente e
tente executar uma dessas shells.
$ cd /home/teste
$ ./sh
# id
Na saída do comando id, pode-se ver que esse usuário conseguiu permissões de root.
É recomendável, para fins de melhor conhecimento do sistema, que esse teste seja feito em todas as shells
disponíveis. Assim, é possível estimar melhor o poder de uma ameaça em um contexto similar a esse.
Para resolver isso, basta remontar a partição onde está montado o “/home”, mas
com a opção de nosuid.
# mount -o remount,rw,nosuid /home
# mount

O comando mount sem parâmetros nos mostra quais as partições estão montadas e suas respectivas opções.
Com a partição remontada com nosuid, faça o teste novamente e veja que as shells continuam com o Suid bit
ativado. Entretanto, quando forem executadas, não vão mais possibilitar o acesso no nível de root.
Outra opção interessante de montagem que pode ser usada é o noexec, que impossibilita a execução de
qualquer binário ou arquivo executável dentro da partição na qual essa opção está ativada. Essa opção
pode ser aplicada a todos os diretórios que contenham binários necessários às funções do sistema. Um
clássico exemplo é aplicá-la a diretórios como “/home” e “/tmp”. Crackers podem se aproveitar do
diretório “/tmp”, onde por padrão qualquer usuário pode escrever, para introduzir backdoors ou qualquer
outro programa malicioso para tentar ter acesso completo a um sistema comprometido.
Para melhor entendimento, pode-se fazer o mesmo o que feito com o nosuid. Basta
remontar a partição com a opção noexec e tentar executar umas das shells que
foram copiadas para o “/home”.
# mount -o remount,rw,noexec /home
# mount
# ./sh
Essa simulação mostra que não é possível executar a shell. Na tentativa de executá-la, recebemos a
mensagem de “permissão negada”, ou seja, nessa partição, nada poderemos executar.
A terceira opção que podemos usar é a noatime, que não é especificamente uma opção para aumentar a
segurança, mas sim para melhorar a performance, pois faz com que o kernel do Linux execute uma rotina
a menos quando o noatime está definido e destinado à atualização do tempo de acesso de arquivo. Veja
um exemplo para entender como funciona:
O comando stat, usado para verificar informações de metadados de sistema de arquivos

de um arquivo:
# stat /etc/passwd
A saída desse comando nos retorna informações importantes, nas quais destacam-se as informações do
Access (atime), do Modify (mtime) e do Change (ctime).
São criados dois arquivos, um no diretório “/root” e outro no “/tmp”, assumindo que o “/root” e o “/tmp”
estão em partições diferentes.
# touch /root/teste1
Depois da criação dos dois arquivos, são consultadas as informações de metadados, mas com foco nas
informações do Access, do Modify e do Change.
# stat /root/teste1
# stat /tmp/teste2
Agora que as informações já foram coletas, basta fazer os testes e ver o que será mudado. O próximo
procedimento consiste em visualizar o conteúdo dos arquivos com o comando cat, supondo que eles
tenham algum conteúdo, e logo em seguida vamos verificar novamente o status dos arquivos.
# cat /root/teste1
# cat /tmp/teste2

# stat /root/teste1
# stat /tmp/teste2
Olhando com atenção, será verificado que o tempo do Access (atime) dos arquivos estão diferentes, ou
seja, quando foi visualizado o conteúdo dos arquivos, evidentemente foi feito um acesso a ele, mas
somente de leitura do seu conteúdo. Por consequência, o seu tempo de acesso (Access) foi modificado.
O experimento ilustra um teste de modificação de permissão com o comando chmod e a consulta das
informações de metadados com o comando stat, para verificar como e sistema guarda esse tipo de
informação.
# chmod 777 /root/teste1
# chmod 777 /tmp/teste2
# stat /root/teste1
# stat /tmp/teste2
É percebido que o tempo Access não foi modificado, mas o Change (ctime) foi alterado. Assim sendo,
quando for mudada uma informação de metadados, como, por exemplo, uma permissão de um arquivo,
o Change será mudado, registrando a última data e a hora da mudança.
Outro experimento para avaliar o que é modificado ao inserir um conteúdo nesses arquivos, ou seja, que
tipo de metadados são modificados considerando as informações do experimento anterior.
# echo abc > /root/teste1
# echo abc > /tmp/teste2
# stat /root/teste1
# stat /tmp/teste2
É observado que o Change foi alterado novamente, mas não alterado sozinho: o Modify (mtime) também
foi, pois agora não ocorreu só uma mudança de metadados (no caso o tamanho), mas uma alteração no
conteúdo do arquivo.
Com esses experimentos foi possível exemplificar a diferença entre o Access, o Modify e o Change. Agora
já conseguimos fazer a alteração na partição e ver o que será melhorado.
Para essa exemplificação, a partição vinculada ao diretório “/tmp”, que será usada para demonstrar que
basta remontar a partição com a opção noatime para desligar esse controle do sistema.
# mount -o remount,rw,noatime /tmp
# mount
Com a partição remontada com a opção noatime, deve-se listar o conteúdo dos arquivos e em seguida
verificar o que foi modificado em relação às informações de metadados dos arquivos.
# cat /root/teste1
# cat /tmp/teste2
# stat /root/teste1
# stat /tmp/teste2
Será observado que o Access (atime) do arquivo teste2 dentro do “/tmp” não será modificado,
justamente por causa da opção noatime, que foi parametrizada na remontagem da partição.
Isso pode ser muito útil para diretórios de logs, onde o acesso é feito constantemente pelo sistema, uma
vez que arquivos de logs são atualizados constantemente.
Dessa forma, com “noatime” parametrizado em uma partição, o kernel deixa de executar uma rotina de
atualização dos metadados de tempo de acesso, o que ajuda na performance do sistema. Outro ponto
relevante é que o tempo de Access (atime) de um arquivo em uma partição com noatime sempre será o
primeiro tempo registrado, ou seja, a data de acesso no momento da criação do arquivo. Nesse contexto,
mesmo com a mudança do tempo de modificação (mtime), o administrador terá o tempo de Access (atime)
como data efetiva da criação, e o tempo de modificação (mtime) como tempo da última modificação.
A tabela da figura a seguir é um bom exemplo da maneira com a qual um administrador pode planejar a
aplicação dessas opções especiais de montagem separando de forma estratégica diretórios importantes
com regras de montagens diferentes.
Para que as regras de montagem fiquem definitivas no sistema, devem ser feitos ajustes no “/etc/fstab”.
Para validar, é interessante que se reinicie o sistema, para que todas as modificações entrem em vigor e
tenhamos a certeza de que nenhum erro foi cometido durante a parametrização do “/etc/fstab”. Isso, é
claro, se as regras de montagem não são efetuadas durante a instalação.
Com essas opções ativadas, é importante lembrar que podemos ter um pequeno problema quando
formos instalar um novo pacote com o apt-get ou dpkg. Esses utilitários, em muitos casos, executam e
gravam informações nos diretórios “/var” e “/tmp” e, caso estejam parametrizados com a opção noexec,
nada poderá ser instalado corretamente, gerando erros na gestão de pacotes. Então, podemos habilitar
as regras de montagem no momento em que formos colocar o servidor em produção. Uma alternativa é
criar um script bem simples com os comandos para remontar essas partições e poder instalar os pacotes.
# vi /root/noexec#!/bin/bash
case $1 in
start)
mount -o remount,rw,noexec /var
mount -o remount,rw,noexec /tmp
mount
echo “Partições SEM permissão de execução”
;;
stop)
mount -o remount,rw,exec /var
mount -o remount,rw,exec /tmp
mount
echo “Partições COM permissão de execução”
;;
*) echo “erro use $0 {start|stop}”
exit 0
;;
esac
exit 1
Para ativar a regra de noexec na partição:
# ./noexec start
O script vai deixar as partições sem permissão de execução, o que será útil quando formos instalar os
outros pacotes. Para voltar à partição a noexec, basta digitar:
# ./noexec stop
O script vai permitir novamente que possa ser executado algo dentro dessas partições, possibilitando a
instalação de novos pacotes. Para melhorar, pode-se copiar esse script para um diretório do PATH do root. Por
exemplo, o “/sbin”. Dessa maneira, será possível executar o script de qualquer diretório do sistema.
Para que as regras de montagem fiquem definitivas no sistema, devem ser feitos ajustes no “/etc/fstab”.
Para validar, é interessante que se reinicie o sistema, para que todas as modificações entrem em vigor e
tenhamos a certeza de que nenhum erro foi cometido durante a parametrização do “/etc/fstab”. Isso, é
claro, se as regras de montagem não são efetuadas durante a instalação.
Com essas opções ativadas, é importante lembrar que podemos ter um pequeno problema quando
formos instalar um novo pacote com o apt-get ou dpkg. Esses utilitários, em muitos casos, executam e
gravam informações nos diretórios “/var” e “/tmp” e, caso estejam parametrizados com a opção noexec,
nada poderá ser instalado corretamente, gerando erros na gestão de pacotes. Então, podemos habilitar
as regras de montagem no momento em que formos colocar o servidor em produção. Uma alternativa é
criar um script bem simples com os comandos para remontar essas partições e poder instalar os pacotes.
# vi /root/noexec#!/bin/bash
case $1 in
start)
mount -o remount,rw,noexec /var
mount -o remount,rw,noexec /tmp
mount

echo “Partições SEM permissão de execução”

;;
stop)
mount -o remount,rw,exec /var
mount -o remount,rw,exec /tmp
mount
echo “Partições COM permissão de execução”
;;
*) echo “erro use $0 {start|stop}”
exit 0
;;
18
Hardening em Linux
esac
exit 1
Para ativar a regra de noexec na partição:
# ./noexec start
O script vai deixar as partições sem permissão de execução, o que será útil quando formos instalar os
outros pacotes. Para voltar à partição a noexec, basta digitar:
# ./noexec stop
O script vai permitir novamente que possa ser executado algo dentro dessas partições, possibilitando a
instalação de novos pacotes. Para melhorar, pode-se copiar esse script para um diretório do PATH do root. Por
exemplo, o “/sbin”. Dessa maneira, será possível executar o script de qualquer diretório do sistema.
21.4.4.!SEGURANÇA NO TERMINAL
Em muitos momentos, um administrador pode inicialmente concentrar seus esforços para mitigar a
possibilidade de ameaças remotas. Mas se o esforço for exclusivo para esse ponto de vista, deve-se
assumir que o todo não é mitigado, pois servidores que não estão conectados diretamente à internet
também correm riscos.
Existem vários tipos diferentes de vulnerabilidades que possibilitam ameaças, um exemplo é a
possibilidade de um cracker conseguir passar pela segurança de perímetro definida por firewalls através
de um ataque a uma vulnerabilidade de um navegador (ataque do tipo side client) e, através da estação
de trabalho comprometida, chegar até outros servidores.
Outra preocupação importante é com a ameaça interna. Por exemplo, quando um funcionário mal-
intencionado tem acesso local (físico) a um servidor. Isso pode acontecer durante a ausência do administrador
que, ao sair de sua sala, se esquece e deixa o terminal do servidor com o login ativo como usuário de root.

Para esse tipo de situação, pode-se aplicar alguns procedimentos para atribuir um grau de “segurança
física” ao servidor, sejam eles destinados a serviços que estarão disponíveis na internet ou dedicados à
rede local. Mas em momento algum parametrizações no sistema podem substituir um aparato de
segurança física, como uma sala de CPD/Datacenter com controle biométrico, apenas vão agregar mais
segurança ao todo.
21.4.5.!DESABILITAR O USO DE ‘CTRL+ALT+DEL’

Deixar o “CTRL+ALT+DEL” desabilitado no sistema Linux pode ser uma boa ideia, pois não permitirá que
alguém pressione essa sequência de teclas e faça com que o servidor reinicie. Isso é bom principalmente
quando o servidor Linux está no mesmo armário que um servidor com o sistema Windows. Assim,
evitamos que em algum momento alguém pressione “CTRL+ALT+DEL” no teclado de um servidor Linux e
cause uma reinicialização desnecessária do sistema.
Em algumas distribuições Linux que ainda usam o /etc/inittab, essa parametrização pode
ser feita editando o /etc/inittab e comentando a linha a seguir:
# ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Pode-se também mapear as teclas para executar um outro comando qualquer, por
exemplo:
# ca:12345:ctrlaltdel:/bin/echo “Esse recurso foi desabilitado”
Depois das alterações, deve-se ativar as mudanças realizadas no arquivo /etc/inittab.
Isso é feito com o comando:
# init q
No entanto, existem exceções: um bom exemplo são as versões mais recentes do Ubuntu,
que embora seja uma distribuição Like Debian, possui configuração diferente para esse
procedimento. É necessário editar o arquivo # vi /etc/init/control-alt-delete.conf. Comente a
linha a seguir:
#exec shutdown -r now “Control-Alt-Delete pressed”
Para essa mudança ser efetivada, execute este comando:
# initctl reload-configuration
21.4.6.!CONTROLES DE SEGURANÇA PARA CONTAS DE USUÁRIOS

A criação de usuários e grupos em sistemas Linux é importante para definir que recursos podem ser
acessados por quais usuários e/ou grupos e ainda permite ao Sistema Operacional gerenciar a execução
dos processos de cada usuário de forma adequada.
Manter o controle do que seus usuários estão fazendo é uma parte fundamental para o gerenciamento
de usuários. O Sistema Operacional Linux possui vários módulos que ampliam a segurança e a gerência
sobre seus utilizadores. Administradores sem experiência em segurança normalmente preparam seus
servidores com uma instalação básica e, depois que suas aplicações estão disponíveis, nenhum
procedimento é feito para manter a integridade do sistema e estabelecer sua trilha de auditoria.

21.4.7.!CONTROLES DE AUTENTICAÇÃO COM A UTILIZAÇÃO DO PAM

Módulos de Autenticação Plugáveis (PAM) são uma interface de módulo que corresponde ao tipo de
autorização baseada em um módulo. Um módulo PAM pode usar apenas uma ou todas as quatro
interfaces possíveis. Essas interfaces são: account, auth, password e session.
Cada uma delas será especificada no arquivo de configuração de um serviço, se for apropriada para o
módulo e o administrador desejar usar essa interface:
•! account: essa interface verifica se uma conta tem autorização para usar o sistema, o que pode
significar verificar se existe, se está vencida ou se tem acesso permitido em determinado horário,
vinculada a um grupo ou através de determinado serviço;
•! auth: interface que serve para autenticar usuários. Isso pode ocorrer através de senhas, banco de
dados ou outro mecanismo. Além disso, esses módulos também têm permissão para definir
credenciais, como membros de grupo ou mesmo baseados em tokens Kerberos;
•! password: a interface password é usada para verificar e definir a autenticação de senha ou o

critério de definição de senha;
•! session: é responsável pela configuração e gerenciamento de sessões de usuário.

Pode incluir tarefas de organização, como montar diretórios, criar arquivos etc.
Com esse recurso, é possível auxiliar os métodos de autenticação tradicionais, possibilitando que
executem novas funções. Um bom exemplo é o programa de login, que se baseia no /etc/passwd e no
/etc/shadow do sistema.
Mas será que esses dois arquivos possibilitariam a criação de um controle definindo
o horário em que um determinado usuário pode realizar um login? Ou o número
de terminais simultâneos que um usuário pode fazer o login?
A resposta para essas perguntas é: não! Mas o PAM pode fazer isso com os seus módulos que são
plugados ao programa de login. O PAM não faz só isso: ele possui muitos módulos com funções bem
diferentes, e não é somente ao programa de login que se aplica; o PAM já tem suporte a muitos
programas. Dessa forma, o uso do PAM em um processo de Hardening deve sempre ser considerado.
Para certifica-se se um determinado programa tem suporte a PAM, é possível consultar se este foi
compilado com suporte a libpam.so.
# ldd /bin/su
# ldd /bin/login
# ldd /usr/sbin/sshd
Como é possível saber se um determinado programa tem suporte ao PAM? Outra forma é acessar o
diretório /etc/pam.d. Dentro desse diretório, deve existir um arquivo com o nome do programa. No
entanto, essa não é uma regra absoluta.
Por exemplo, vejamos se existe um arquivo chamado login dentro do /etc/pam.d.
# ls -l /etc/pam.d
Veja como exemplo o arquivo login. Existem muitos outros também.

21.4.8.!SINALIZADORES DE CONTROLE
Para cada interface, o arquivo de configuração especifica um sinalizador de controle, que determina o
que o PAM fará em seguida, com base no resultado da verificação realizada. Existem quatro sinalizadores
de controle: optional, required, requisite e sufficient:
•! optional: os módulos opcionais não afetam o sucesso nem a falha da autenticação, a menos que
não haja outros módulos para determinada interface;
•! required: para que o usuário possa continuar, deverá ser retornado um resultado de sucesso. A
notificação de usuário não ocorre até todos os módulos para uma interface estarem satisfeitos;
•! requisite: o usuário só poderá continuar se o módulo resultar com sucesso. A notificação do

usuário acontece imediatamente em caso de falha no primeiro módulo requisite ou required de
uma interface;
•! sufficient: um resultado de sucesso combinado sem falhas do módulo required ou requisite
viabiliza uma boa autenticação, pressupondo que nenhum outro módulo virá a seguir. A falha de
um módulo sufficient é ignorada.
21.4.9.!CAMINHO DO MÓDULO
O caminho do módulo informa ao PAM a localização do módulo. Normalmente, é um nome de caminho
completo, que contém o nome e a extensão do módulo, como /lib/security/pam_unix.so. Se não for
especificado um caminho, o PAM assume como padrão /lib/security para poder localizar o módulo.
Além de ser parte da maioria das distribuições Linux, esse recurso também é encontrado em outros
sistemas, como Solaris.
21.4.10.!PAM_TIME
É uma boa prática em sistema Like Unix não deixar o login como root habilitado para conexão direta. O
ideal é a execução do “login” com um usuário comum inicialmente, e depois obter acesso como root
quando precisar executar alguma tarefa administrativa. Usando um conceito de autenticação em duas
camadas, o que gera uma contramedida contra ataques de força bruta, destinado ao usuário root.
É possível travar o login de root em todos os terminais comentando as linhas dos

terminais no arquivo /etc/securetty.
Outra forma interessante para criar um controle para a conta do usuário root é “descomentar” a linha que
refere-se a pam_time.so para bloquear o login de root utilizando o conceito baseado horário de acesso.
Edite o arquivo /etc/pam.d/login e “descomente” a seguinte linha:

# vi /etc/pam.d/login
account requisite pam_time.so
Essa linha está tratando da conta dos usuários (account) com o módulo pam_time.so. Até aqui essa linha não
está fazendo nada, pois a maioria dos módulos do PAM depende de um arquivo de configuração adicional.

O módulo pam_time.so trabalha em conjunto com o arquivo /etc/security/time.conf pelo

nome do módulo e do arquivo de configuração.
Para definir o horário de acesso, deve-se editar o arquivo /etc/security/time.conf e
acrescentar a seguinte linha no final do arquivo:
# vi /etc/security/time.conf
login;tty*;root;!Al0000-2359
Onde:
•! login: indica o serviço;
•! tty*: indica os terminais onde a política será aplicada;
•! root: determina que a política será aplicada para o usuário root.
•! !Al0000-2359: indica o horário permitido. O caractere “!” estabelece que aquele horário não é
permitido.
Sintaxe: services;ttys;users;times
Com essa configuração, está definido que o root não pode efetuar login em nenhum terminal, em
nenhum dia ou horário. Dessa maneira, cria-se um controle que bloqueia a usuário root para que este
não tenha acesso direto ao “login” do sistema.
Para validar o controle, basta tentar realizar um login em outro terminal como root, o que não deverá
ocorrer. Todavia, essa proposta imagina que haverá um usuário definido que terá acesso ao recurso login
e, a partir dele, será permitido usar o comando su ou sudo para usar a conta do root.
21.4.11.!PAM_LIMIT
A seguir será mostrado como definir uma política para não permitir que um usuário faça login em mais
de um console, consecutivamente com a utilização da biblioteca pam_limits.so.
Primeiro é preciso habilitar o módulo que vai possibilitar a utilização desse recurso. Para
isso, é necessário editar o /etc/pam.d/login e inserir a linha a seguir:
# vi /etc/pam.d/login
session required pam_limits.so
Com o módulo habilitado, temos de editar o arquivo de configuração adicional desse
módulo. Na sequência, deve-se ir até o diretório /etc/security, editar o arquivo limits.conf e
inserir a seguinte linha:
# vi /etc/security/limits.conf
usuário hard maxlogins 1
Com isso, é criado um controle que limita o usuário para que utilize somente um terminal. Para testar,
basta executar o “login” em um terminal com o usuário e tentar efetuar login em outro simultaneamente.

Outra utilização da biblioteca pam_limits.so é a parametrização para limitar os processos dos usuários ou
um grupo, o que é importante para a execução de um sistema estável.
Exemplificação para coibir um forkbomb:

testeadmin hard nproc 300
@systelcom hard nproc 150
@ sysprinters soft nproc 100
@sysop hard nproc 200
Nessa parametrização, ficou definido que membros de um grupo de estudantes poderão abrir 150
processos; membros do grupo sysprinters, 100; e sysop, 200 processos. Já o usuário testeadmin poderá
criar até 300 processos. Todavia, esse tipo de configuração deve ser bem avaliado, para que seja
dimensionado o número de processo ideal.
21.4.12.!PAM_WHEEL
Nessa exemplificação, será usado como exemplo um usuário denominado toor e um grupo denominado
“administradores”, feitos para criar mais uma camada de controle com o objetivo de aumentar ainda mais
a segurança na autenticação:
# adduser toor
# groupadd administradores
# usermod –G toor administradores
A proposta é somar ao procedimento de limitação de “logins”, já mencionado, uma política que não
permita o uso do comando su por qualquer usuário, possibilitando o uso do su somente para os usuários
do grupo administradores.
Essa configuração vai será pouco diferente das outras, pois não precisa de um arquivo de configuração
adicional. Basta limitar a utilização do programa su, com a edição do arquivo su, que está dentro do
diretório /etc/pam.d.
# vi /etc/pam.d/su
auth required pam_wheel.so group=administradores
Essa configuração trata a autenticação do usuário (auth) com o módulo pam_wheel.so, utilizando o
grupo administradores. Uma vez parametrizado, somente usuários que pertencerem ao grupo
administradores é que poderão usar o comando su.
Para testar, execute o “login” com o usuário toor em um terminal e com o tux em outro. Então é necessário
tentar fazer o su com os dois usuários. Caso as configurações tenho sido feitas de forma correta, será observado
que somente o usuário toor conseguirá, pois só ele pertence ao grupo administradores.
Por questões de segurança, toda a atividade do comando su deve ser monitorada. Os procedimentos a
seguir servem para registrar em arquivo de log o uso do comando su pelos usuários.
Modifique o arquivo /etc/login.defs e “descomente” a seguinte linha:

SULOG_FILE /var/log/sulog
Logo em seguida, é necessário criar o arquivo sulog em /var/log.
# touch /var/log/sulog
Para validação, deve-se fazer um teste e usar em paralelo o comando tail para melhor visualização do log,
podendo-se desviar a saída padrão do arquivo para ver o conteúdo do arquivo de log em tempo real,
para um determinado terminal. No exemplo foi escolhido o terminal 12.
# tail -f /var/log/sulog > /dev/tty12 &
Na sequência, devemos efetuar login com o usuário toor e usar o comando su para alternar para o
usuário root.
$ su
Feito isso, visualize os registros do log no terminal 12.
Com alguns ajustes nos arquivos de configuração do PAM, é possível limitar bastante os privilégios
comuns e até mesmo limitar o próprio root, o que em muitas situações pode ser útil. Sendo também
possível fazer essas e outras configurações utilizando o PAM, o que ajuda um sysadmin a ter grande
controle e mostra que o uso do recurso PAM é uma grande ferramenta para gerenciar privilégios.
Para conhecer mais sobre Hardening Linux e como fazer assista aos vídeos:
http://tinyurl.com/z2btjtf
http://tinyurl.com/jdkzv5h
http://tinyurl.com/j44zsoq
http://tinyurl.com/hspcpgx
http://tinyurl.com/jdwo4p6
Aula 22 |!CONFIGURANDO A SEGURANÇA DE SERVIDORES WINDOWS
Prevenir acesso não autorizado a dados sensíveis é essencial em qualquer ambiente em que múltiplos
usuários têm acesso aos recursos físicos ou via rede. Um sistema operacional deve ser configurado de
forma segura antes de ser exposto em uma rede pública não controlada, como o caso da internet. Este
processo de reforçar a segurança é chamado de hardening.
Apesar de muito importante, o administrador de segurança não deve confiar inteiramente na segurança
do servidor após o hardening, pois alguma configuração insegura pode ter passado despercebida, ou
alguma nova vulnerabilidade, desconhecida quando o hardening foi implantado, podendo ter afetado o
servidor em questão. Seguindo o princípio da defesa em profundidade, recomenda-se que o servidor seja
ainda protegido por outros recursos, como firewalls, proxies reversos, IDS (HIDS e NIDS) e IPS.
22.1.!NECESSIDADE DE CONFIGURAÇÃO DE UM BASTION HOST

Em um ambiente Microsoft Windows, publicado na internet, é vital utilizar o conceito de bastion host
para garantir a integridade do sistema. Existem inúmeras falhas de segurança documentadas que
permitem ao invasor acesso total à máquina-alvo, quando esta é disponibilizada em uma rede pública e
com a instalação padrão do sistema operacional.
Atualmente, esse valor é bem inferior a 10 minutos, de modo que uma máquina conectada à internet por
um tempo superior provavelmente já está infectada por algum worm ou foi invadida.
O bastion host será uma máquina exposta na rede pública disponibilizando

recursos e serviços.
Por ser uma máquina com serviços públicos, essa será a primeira barreira a ser vencida por um invasor
para tentar obter acesso aos sistemas da rede privada. q Existem várias implementações possíveis de
bastion hosts, de acordo com os serviços que ele oferece. Alguns exemplos:
•! Firewall gateways
•! Servidores web
•! Servidores FTP
•! Servidores de nome DNS
•! Transportadores de e-mail.
No caso, um bastion host pode oferecer mais de um serviço, conforme as topologias já discutidas.
22.2.!LISTA DE VERIFICAÇÃO (CHECK-LIST)

É recomendado planejar a instalação e escrever um check-list das atividades a serem realizadas e
auditadas nos servidores públicos:
•! Remover ou desabilitar todos os serviços não necessários no host.
•! Remover ou desabilitar todas as contas de usuário não necessárias.
•! Remover ou desabilitar todos os protocolos de rede não utilizados.
•! Configurar adequadamente os registros de log do sistema para que possam identificar possíveis
ataques ou atividade suspeita.
•! Implantar um sistema de detecção de intrusão de host.

•! Atualizar o sistema operacional com as últimas correções de segurança disponibilizadas
pelo fabricante.
•! Filtrar todas as portas que não são necessárias para o host. Utilizar conexão criptografada para
conectar no host.
•! Evitar a instalação de aplicativos não necessários e/ou notadamente vulneráveis como Flash, PDF
Viewers, Java, entre outros.
22.3.!CONFIGURAÇÃO DE FILTROS DE PACOTES

O Windows XP, 2003, 2008 e 7 trazem no próprio sistema operacional um aplicativo para controlar
o filtro de pacotes.
No XP e 2003, o filtro de pacote é simples, o que justifica o uso de aplicativo de terceiros para melhor
controle do filtro, como por exemplo o Zone Alarm, da Check Point.
No Windows 7 e Windows Server 2008, o aplicativo recebeu atualizações significativas, permitindo a
configuração de perfis e a importação e exportação de regras, entre outras funcionalidades.

Podemos utilizar uma ferramenta que acompanha o sistema operacional: netstat, ou ferramentas adicionais
como o TCPview da suíte Sysinternals. Através do netstat e do TCPview, verificamos as portas abertas no
servidor para localizar e desabilitar o serviço em questão, ou filtrar a porta. Cada serviço de rede presente em
um servidor pode escutar uma porta, TCP ou UDP, para receber conexões de outros servidores ou clientes.
Alguns desses serviços são importantes para o bom funcionamento do servidor, e nem sempre podem ser
desabilitados. Quando verificamos as portas abertas em uma configuração padrão de um servidor Windows,
vemos que existe uma série de portas que são abertas por padrão no sistema.
Colocar um sistema de forma pública na internet, sem a devida filtragem dos

serviços que não estão em uso, é arriscado e pode comprometer a segurança do
servidor.
Felizmente, muitos sistemas operacionais permitem que seja configurado um filtro de pacotes para controlar
as portas que estarão disponíveis para serem conectadas por hosts externos. A versão padrão do Windows XP,
2003, 2008 e 7 trazem no próprio sistema operacional um aplicativo para controlar o filtro de pacotes. No caso
específico do XP e do 2003, o filtro de pacote é mais simples, o que justifica o uso de aplicativo de terceiros
para melhor controle do filtro, como por exemplo o Zone Alarm, da Check Point.
Lembre-se de que essa filtragem é local, e não deve ser utilizada para substituir uma filtragem de
perímetro, propriamente feita através de um firewall, mas apenas como um mecanismo adicional de
segurança (defesa em profundidade). Devemos observar também que caso haja muitos servidores
disponibilizando serviços públicos, a configuração de filtros de pacotes locais em cada servidor pode
tornar o gerenciamento do ambiente complexo, de modo que o uso de filtros em cada servidor deve ser
feito com parcimônia.
Para listar as portas que estão aguardando conexão de rede ou as conexões estabelecidas, podemos usar
uma ferramenta do próprio sistema operacional, neste caso com o comando netstat.
Fonte: http://tinyurl.com/hv3sgry
A suíte de ferramentas SYSInternals oferece outra ferramenta para listar com mais detalhes as conexões
de rede estabelecidas e seus respectivos processos, além de também listar as portas que estão
aguardando por conexões de rede.

Através do netstat e do TCPview, podemos verificar as portas que estão abertas no servidor, de modo a
localizar e desabilitar o serviço em questão ou filtrar a porta. Outra forma de verificar as portas abertas é
utilizando o Nmap. Desabilitar serviços em sistemas Windows é um processo que demanda certa
paciência. Caso um serviço essencial seja desabilitado,
algum comportamento inesperado pode acontecer. Recomenda-se que seja utilizada uma máquina de
testes, para se criar familiaridade com o processo, antes de desabilitar serviços em servidores em
produção. Mais à frente, serão vistos com mais detalhes o modo de desabilitar serviços no Windows.
O Windows Firewall é o aplicativo que acompanha o sistema operacional para

controle de conexões de rede, que normalmente vem configurado por padrão
na instalação padrão do Windows.
Fonte: http://tinyurl.com/j8x7fgq

Nas versões Windows 7 e Windows Server 2008, o aplicativo recebeu atualizações significantes,
permitindo a configuração de perfis, importação e exportação de regras, entre outras funcionalidades.
Fonte: http://tinyurl.com/jtxx8ap
Abaixo, seguem os passos para criar uma regra no firewall:
•! Clique na opção desejada de acordo com a necessidade de criar uma regra de entrada (pacotes
que entram no servidor) ou regra de saída (pacotes que saem do servidor).
•! No painel de ações, no lado direito, clique em “Nova Regra” (New Rule).
•! Selecione que deseja criar uma regra para uma porta.
•! Selecione o protocolo (TCP ou UDP).
•! Selecione as portas que deseja incluir nesta regra, separadas por vírgula.
•! Selecione a ação desejada (permitir, permitir com IPsec ou bloquear).
•! Selecione os perfis aos quais esta regra vai se aplicar.
•! Defina um nome e uma descrição para a regra.

Por fim, verifique a regra criada no painel da ferramenta. Você pode testar as suas regras com os
comandos já apresentados.
22.4.!CRIAÇÃO DE UMA LINHA BASE DE SEGURANÇA (BASELINE)

Uma baseline consiste em uma referência inicial de segurança, um ponto inicial, a partir do qual se evolui
para uma configuração segura. Os servidores Windows possuem alguns perfis padrão de segurança, de
acordo com o papel que aquele servidor irá desempenhar. Mais adiante, serão vistas algumas
ferramentas que permitem a criação de uma baseline e a posterior auditoria para verificar se a
configuração atual atende ao mínimo necessário de segurança.
Além da baseline, é preciso criar um mapa do tempo (timeline) dos servidores da rede, registrando a data de
instalação do sistema operacional, das principais correções e da instalação de aplicativos. Essa linha do tempo
será útil para manter atualizado o inventário dos sistemas e principalmente para uma eventual auditoria.
22.5.!DESABILITANDO SERVIÇOS DESNECESSÁRIOS

O Windows 2008 Server traz alguns avanços de segurança que auxiliam na criação de um bastion host: os
papéis. O conceito de papéis (roles) ajuda no processo de habilitar somente programas necessários e
evitar comprometer a segurança do sistema.
O sistema de papéis, quando aplicado, irá:
•! Iniciar somente os serviços necessários.
•! Liberar exceções nos filtros de pacotes nas interfaces de rede que forem necessárias.
Logo após a instalação do sistema operacional, depois do primeiro acesso ao sistema, a ferramenta de
configuração de papéis é apresentada. Com a escolha de um determinado role, o aplicativo iniciará
somente os serviços e liberará exceções nos filtros de pacotes nas interfaces de rede em que isso for
necessário. Essa é uma grande evolução, que facilita o processo de desabilitar serviços desnecessários e
liberar regras de acesso para os serviços que estão sendo usados.
Nos sistemas operacionais que possuem o recurso de roles, é importante verificar se os roles realmente
disponibilizam somente os serviços necessários. Nos sistemas operacionais mais antigos da Microsoft
(Windows XP e 2003 Server), os serviços se tornam o principal controle de recursos disponíveis no
sistema, de modo que devem ser desabilitados de forma manual. A ferramenta Services MMC, que
acompanha o sistema operacional, ajuda nessa tarefa. Ela pode ser encontrada no Painel de Controle, no
item “Ferramentas Administrativas”. Ao iniciar a ferramenta Services, obtemos a tela a seguir.
Fonte: http://tinyurl.com/gnvrypw

Através da ferramenta, podemos iniciar, encerrar e desabilitar serviços. Para iniciar e encerrar um serviço,
basta clicar em cima do serviço e escolher uma das opções, que se assemelham aos controles de um
programa tocador de música. Note que alguns serviços não podem ser encerrados, pois são serviços
essenciais para o funcionamento do sistema operacional. Para desabilitar um serviço, basta clicar no
serviço desejado e mudar o startup type para disabled.
Uma tarefa importante para a configuração segura de servidores consiste em saber a porta TCP ou UDP
associada a um determinado serviço, de modo que possamos desabilitar os serviços desnecessários que
abrem portas de rede no servidor. Essa tarefa pode ser realizada
utilizando alguns utilitários disponíveis na internet. Abaixo, um exemplo de como podemos descobrir um
serviço que corresponda a uma porta específica.
a)! Através do netstat –ano ou do TCPview, verificamos uma porta da qual desejamos saber o serviço
correspondente. No exemplo abaixo, a porta UDP 1900, que corresponde ao processo de número
1216 (svchost.exe). Geralmente um serviço é executado por esse programa.
b)! A partir do número do processo, verificamos no Process Explorer as propriedades do processo em

questão. Na aba Services, encontramos os serviços associados ao processo svchost.exe em questão.
c)! No caso, um dos serviços apresentados é o serviço que procuramos. O próximo passo é
desabilitar os serviços em questão, um a um, até que a porta em questão desapareça do netstat
ou do TCPview. No exemplo acima, o serviço responsável pela porta 1900 UDP é o SSDP
Discovery Service.

d)! Na Wikipedia (List of TCP and UDP port numbers) há uma lista de portas conhecidas e os
processos correspondentes, onde podemos confirmar que a porta 1900 UDP corresponde de fato
ao serviço SSDP, que possui relação com a descoberta de dispositivos UPnP.
Aprenda mais assistindo aos vídeos

http://tinyurl.com/gr6a6k6
http://tinyurl.com/zz3al3z
http://tinyurl.com/gupbgyo
22.6.!FERRAMENTAS DE ANÁLISE DA SEGURANÇA DO WINDOWS

Existem várias ferramentas que auxiliam na administração de segurança de servidores Windows. As
ferramentas que acompanham o sistema operacional são preteridas por normalmente continuarem
funcionando mesmo após grandes atualizações, como no caso de um Service Pack.
Porém, ferramentas terceiras normalmente trazem informações mais detalhadas e com relatórios úteis na
gestão dos servidores. Vamos ver exemplos de ferramentas úteis para a análise de segurança de
servidores Windows.

22.6.1.!WINDOWS MANAGEMENT INSTRUMENTATION CONSOLE (WMIC)

WMIC é também conhecida como “canivete suíço do Windows”. Essa ferramenta é executada em linha de
comando e pode ser executada no servidor local ou remoto pela rede de dados. Essa ferramenta está
disponível em todas as versões do Windows a partir do Windows NT.
Fonte: http://tinyurl.com/je6eg3j
A sintaxe do WMIC é sempre: wmic <objeto> <ação>.

Principais objetos no auxílio de auditoria de segurança:
•! startup: lista todos os processos que são iniciados junto com o sistema operacional.
•! process: lista dos processos executados pelo sistema.
•! cpu: informações sobre o processador físico.
•! group: lista de grupos cadastrados no sistema.
•! useraccount: lista dos usuários cadastrados no sistema.

O WMIC é capaz de gerar relatórios em vários formatos, como CSV, XML, HTML, através da diretiva
/FORMAT:<formato>.
Aprenda mais assistindo aos vídeos

http://tinyurl.com/hg3tt9k
http://tinyurl.com/z6jevu5
22.6.2.!SYSINTERNALS
A suíte de ferramentas desenvolvidas inicialmente por Mark Russinavich e Bryce Cogswell oferece a
possibilidade de uma verificação mais detalhada do funcionamento do sistema operacional. As
ferramentas podem ser baixadas gratuitamente do site da Microsoft:
http://technet.microsoft.com/en-us/sysinternals/
Algumas já foram apresentadas, como o TCPview e o Process Explorer.
Com o objetivo de auxiliar o analista a gerenciar o host, resolver problemas e diagnosticar o sistema
operacional e aplicativos, a Microsoft adquiriu em 2006 a suíte de ferramentas SYSInternals e contratou
Mark Russinavich para continuar na equipe de desenvolvimento da suíte de ferramentas. q A seguir
algumas ferramentas importantes da suíte do SysInternals:
•! Autoruns: mostra os programas que inicializam automaticamente com o sistema.
•! Diskmon: captura toda a atividade do disco rígido.

•! EFSDump: verifica informações sobre arquivos cifrados.
•! ProcDump: captura área de memória de processos.
•! PsService: visualiza e controla serviços.
•! RootkitRevealer: verifica o sistema em busca de programas maliciosos do tipo rootkit.
•! Process Monitor: monitora diversas informações sobre processos, incluindo alterações do registry
e do sistema de arquivos. Muito útil para verificar o comportamento de certos programas.
Outra ferramenta bastante útil é o dumpsec, da SystemTools:

http://tinyurl.com/37dnrre
Com ela você poderá gerar um arquivo de texto contendo todas as permissões de acesso dos usuários
referentes a arquivos, pastas, registros e compartilhamentos. Tal relatório permite identificar se todas as
permissões estão configuradas de acordo com a política da organização.
22.6.3.!WINDOWS SERVER UPDATE SERVICES (WSUS)

WSUS é uma ferramenta da Microsoft que auxilia no processo de atualizações dos sistemas e aplicativos
Microsoft. É um serviço que pode ser executado em versões do Windows Server 2000, 2003 e 2008. Esse
serviço é responsável por baixar as atualizações dos servidores da Microsoft e distribuí-las para as
estações de trabalho e servidores da rede. Essa distribuição pode ser realizada automaticamente de
forma pré-aprovada pelo administrador do sistema ou com aprovações manuais para cada atualização,
em casos mais críticos.
O WSUS também é capaz de gerar relatórios personalizados da situação de cada host da rede, exibindo
detalhes da atualização do sistema operacional e aplicativos Microsoft. A instalação do WSUS, pela sua
complexidade, não será coberta por esse curso, porém existem
diversos guias na internet que explicam em detalhes a instalação da ferramenta. A seguir, uma tela inicial
do WSUS em execução.

Fonte: http://tinyurl.com/htsbo4a
22.6.4.!MICROSOFT BASELINE SECURITY ANALYZER (MBSA)

MBSA é uma ferramenta capaz de verificar se servidores – com Windows Server, e estações de trabalho
com Windows XP, Vista e 7 – estão de acordo com as recomendações de segurança da Microsoft e ainda
se estão com as últimas versões das correções de segurança instaladas. Para utilizar o MBSA, será
necessário ter conta no sistema com privilégio de administrador.
Fonte: http://tinyurl.com/hfocrhb
Além de verificar a instalação de correções de segurança, o MBSA também verifica falhas comuns na
configuração dos servidores, como o serviço de atualização desligado, contas de usuário que nunca
expiram, contas sem senhas, configurações com fragilidade de segurança

do Internet Explorer, entre outras. O MBSA é gratuito para usuários Windows.
Para aprender mais assista aos vídeos:

http://tinyurl.com/ztlg5hh
http://tinyurl.com/gm7qw4g
http://tinyurl.com/zn3doqg
22.6.5.!MICROSOFT SECURITY COMPLIANCE MANAGER

A ferramenta Microsoft Security Compliance Manager é completa para a segurança de servidores e
estações Windows. Tem por objetivo concentrar uma série de conhecimentos sobre a segurança de
servidores e facilitar o processo de hardening de servidores e estações. Ela permite aplicar uma série de
parâmetros de segurança, a customização de baselines e a exportação em formatos fáceis de aplicar em
um ambiente. Recursos presentes na ferramenta:
•! Gerenciamento centralizado de baselines.

!! Provê uma interface centralizada de gerenciamento para prover, planejar e customizar
baselines, incluindo as recomendadas para os sistemas operacionais Windows.
•! Customização de baselines.
!! Permite customizar, comparar, juntar e revisar as baselines.
•! Exportação para múltiplos formatos.

!! Permite a exportação das configurações em diversos formatos, incluindo XLS, GPO, DCM
e SCAP, para permitir a automação da implantação e o monitoramento da aderência às
baselines definidas.
Ele requer o .NET runtime e o SQL Server Express. Os seguintes passos são necessários para a instalação
da ferramenta:
a)! Baixe a ferramenta no seguinte link: http://go.microsoft.com/fwlink/?LinkId=14840.
b)! Execute a instalação. O User Account Control (UAC) vai pedir permissões para executar o
instalador como administrador. Autorize as permissões.
c)! Na tela seguinte, marque a opção: “Automatically check for application and baseline updates
from microsoft.com during application usage for current user”.
d)! Aceite os termos da licença. Instale a ferramenta no diretório padrão e escolha um nome para
identificar as baselines criadas (ex.: ESR).
e)! Na página referente ao SQL Server Express, escolha a opção “Download and Install”.
f)! Aceite os termos da licença do SQL Server Express.
g)! Aguarde a instalação da ferramenta e seus pré-requisitos. Dependendo da conexão de internet,
pode demorar um tempo.
Durante a instalação, caso o .NET Runtime não esteja instalado, o MSCM não será instalado e será
necessário baixar e instalar esse componente.

Ao iniciarmos o MSCM pela primeira vez, o aplicativo automaticamente busca e instala as versões mais
recentes dos templates de segurança para as plataformas suportadas por ele. Essa atualização é
importante para garantir que as últimas versões dos templates estão sendo utilizadas. Essa atualização
pode também ser realizada através do menu “Tools”, opção “Check for baselines”. Na tela principal,
temos então os seguintes componentes:
Baseline Library
•! Lista todas as baselines numa estrutura hierárquica.
•! Ao clicar em uma baseline com o botão direito, um menu apresenta alguns comandos que
podem ser aplicados.
Baseline Information Pane
•! Apresenta informações sobre a baseline selecionada.

Actions
•! Apresenta comandos para a gerência das baselines.
22.7.!SISTEMAS DE ARQUIVOS E GERENCIAMENTO DE USUÁRIOS

Por fim, porém não menos importante, um sistema seguro deve utilizar um sistema de arquivos que
suporte a criação de permissões, de modo a limitar o acesso dos usuários, limitando um potencial estrago
em caso de comprometimento de uma conta de usuário, além de incluir o mínimo de usuários possíveis.
O sistema de arquivos padrão do Windows, a partir da versão NT, é o NTFS. Apesar de suportar outros
sistemas, como o FAT32, recomenda-se que seja usado sempre o NTFS por questões de segurança, pois
ele possui a capacidade de ajuste de permissões por usuário (ACL), para que o sistema de arquivos possa
ser configurado de modo que os usuários só tenham acesso ao que realmente for necessário para a
utilização do sistema (princípio do menor privilégio).

Podemos verificar as permissões de um determinado arquivo ou pasta no sistema, através das

propriedades, na aba Segurança:
Aqui podemos editar as propriedades de segurança desse objeto, adicionando ou removendo
permissões. É importante lembrar que os servidores que utilizam NTFS como sistema de arquivos já
possuem uma configuração inicial razoavelmente restritiva, de modo que um usuário não administrador
tenha poucos privilégios no ambiente, não conseguindo instalar novos programas e com permissão de
gravação apenas na sua pasta de trabalho.
Ao configurar o sistema, devemos verificar ainda as contas de usuário, removendo todas as contas que
não estão em uso, especialmente contas de convidado (guest), e definindo senhas complexas para os
usuários e para a conta de administração. Outra prática comum é renomear a conta de administrador, de
modo que dificulte a ação de ataques de força bruta, com o objetivo de encontrar a senha dessa conta.
22.8.!GROUP POLICY OBJECTS

Uma das grandes tarefas de um administrador de redes é o gerenciamento de usuários, grupos e
computadores de uma rede e, dependendo do tamanho da estrutura da organização, essa tarefa pode
demandar horas e mais horas de planejamento e execução. Uma ferramenta de vital importância para
suprir essa demanda é sem dúvida o Group Policy Objects (GPO), presente nos sistemas operacionais de
rede da Microsoft desde a versão 2000. Com ele podemos controlar boa parte do comportamento tanto
das estações de trabalho que compõem nosso parque de máquinas quanto do próprio servidor.
Essas políticas facilitam a configuração de várias máquinas ao mesmo tempo, bastando apenas escolher
qual política utilizar para toda a empresa, para um grupo específico ou mesmo para apenas uma estação
de trabalho.
Com o GPO podemos:
•! Restringir ícones e botões da área de trabalho ou do menu Iniciar.
•! Limitar o número de programas a serem executados.
•! Restringir opções do Active Desktop.
•! Remover programas desnecessários.
•! Programar instalações remotas de programas.
•! Configurações do Internet Explorer.

As configurações executadas via GPOs são aplicadas para usuários, computadores, member servers,
Domain Controlers, mas apenas para computadores rodando Windows 2000 (Server u Professional),
Windows XP, Windows Vista, Windows Server 2003 e Windows Server 2008.
A primeira aproximação que a Microsoft fez com políticas de grupos foi introduzida no Windows NT 4
através do Police Editor, mas foi com o lançamento do Windows 2000 Server que foi introduzido ao
mundo Windows o Group Policy Editor, que incluía:
•! Configuração dos principais componentes do Windows.
•! Configuração dos principais recursos dos Active Desktop.
•! Configuração das regras de segurança.

•! Instalação de Softwares do tipo Windows Installer.
•! Configurações por computador ou usuário.
•! Herança, bloqueio de herança e regras mandatórias.

A partir do lançamento do Windows 2003 Server, a implementação de GPOs ficou ainda mais fácil,
principalmente com o Group Policy Management Console.
Podemos atribuir diretivas em uma GPO. Essa GPO com essas regras podem ser atribuídas a um:
•! Site: é o mais alto nível e normalmente atribuído a GPOs mais genéricas, válidas para qualquer
usuário/computador/domínio nesse site.
•! Domínio: vem em segundo nível. Configurações feitas nesse nível afetaram

usuários/computadores dentro do domínio.
•! OU: o que se aplica nas OUs afetarão todos os usuários/computadores dentro dela.
Dependendo da estrutura da organização, podemos utilizar várias GPOs para as mais diversas tarefas e,
muitas vezes, essas GPOs podem ser aplicadas a um mesmo objeto, seja diretamente ou por herança.
Nesse caso, as GPOs possuem uma hierarquia para serem aplicadas:
•! GPO local.
•! GPO de site.
•! GPO de domínio.
•! GPO de OU.
As GPOs são baseadas em modelos que possuem uma lista de opções configuráveis de forma bastante
intuitiva. Em sua maioria oferecem a opção de:
•! Habilitada: especifica o item que será ativado.
•! Desabilitada: especifica o item que será desativado.
•! Não configurada: deixa a opção neutra: não está ativada nem desativada, essa é a opção padrão.
Assista aos vídeos:

http://tinyurl.com/jf3cekk
http://tinyurl.com/h9t6sc2
22.9.!DIRETIVA DE SENHAS
Sempre é bom lembrar que uma boa política de senhas é fundamental para uma organização, mas, antes
de mais nada, é um controle de segurança, e antes de defini-lo o administrador precisa entender
exatamente quais os riscos envolvidos em se definir como o usuário vai trabalhar com suas senhas, o
valor do que está sendo protegido com essa senha e os demais controles de acesso que existem
adicionalmente além da própria senha.
A organização deve estar preocupada não somente com ataques de força bruta ou por dicionário, mas
também evitar que o usuário esqueça a senha e tenha de redefini-la diversas vezes. Porém, uma fraca
política de autenticação invalida todas as outras barreiras implementadas, tais como firewalls,
criptografia etc. Para se defender contra essas vulnerabilidades, faz-se necessário uma correta aplicação

de diretivas de senha utilizando o console Diretiva de segurança local ou do domínio, se o servidor for
um controlador de domínio.
Opções:
•! A senha deve satisfazer a requisitos de complexidade: se essa diretiva estiver habilitada, as senhas
deverão atender aos itens abaixo informados.
•! Aplicar histórico de senhas: configuração de segurança que determina o número de novas
senhas exclusivas que devem ser associadas a uma conta de usuário, para que uma senha antiga
possa ser utilizada. Valor entre 0 e 24 senhas.
•! Armazenar senhas usando criptografia reversível: diretiva que oferece suporte a aplicativos que
necessitam armazenar a senha original do usuário, essa opção só deve ser utilizada se realmente
for necessário.
•! Comprimento mínimo de senha: configuração de segurança que determina o tamanho mínimo

de caracteres que uma conta de usuário pode conter. Valor entre 0 (desativa) e 14.
•! Tempo de vida máximo da senha: configuração que determina o período de tempo em dias em
que uma senha pode ser utilizada antes de o sistema solicitar sua alteração. Valor 0 desativa o
tempo máximo. De 1 a 999 define o espaço de tempo.
•! Tempo de vida mínimo da senha: configuração que determina o período de tempo em dias em
que uma senha deve ser utilizada antes de o usuário poder alterá-la. Valor 0 habilita o usuário a
trocar a senha imediatamente.
Aprenda mais nos vídeos:

http://tinyurl.com/h4w5yzq
http://tinyurl.com/zkveom6
http://tinyurl.com/hzjwekf

22.10.!DIRETIVA DE AUDITORIA
A auditoria de segurança é uma das ferramentas mais poderosas para ajudar a manter a segurança do
sistema. A auditoria deve identificar ataques, bem sucedidos ou não, que representam algum tipo de
ameaça a sua rede ou ataques contra os recursos determinados em sua avaliação de riscos.
Principais opções:
•! Acesso aos serviços de diretório de auditoria: determina se o sistema operacional fará a auditoria
das tentativas dos usuários de acessar os objetos do Active Directory.
•! Auditoria de alteração de diretivas: determina se o sistema operacional fará a auditoria de cada
instância de tentativas de alteração da diretiva de atribuição de direitos, diretivas de auditoria,
diretivas de contas ou diretivas de confiança do usuário.
•! Auditoria de eventos de logon: determina a necessidade de o sistema operacional fazer auditoria

de cada instância de tentativa de logon ou logoff de um usuário no computador.
•! Auditoria de eventos de sistema: determina a necessidade de o sistema operacional fazer

auditoria dos seguintes itens:
!! Alteração do horário do sistema.
!! Inicialização ou desligamento do sistema.
!! Carregamento de componentes de autenticação extensível.
!! Perda de eventos que passaram por auditoria, devido a falha no sistema de auditoria.
!! Se o tamanho do log de segurança exceder o nível de limite de aviso configurável.
•! Auditoria de gerenciamento de conta: determina a necessidade de o sistema operacional auditar

eventos de gerenciamento de contas, tais como criação, alteração e exclusão de contas de
usuário e grupos, definição de senhas, entre outros.
22.11.!ATRIBUIÇÃO DE DIREITOS DE USUÁRIOS

Em determinadas situações, não basta apenas ativar ou desativar certas diretivas de segurança. É
necessário, em algumas situações, informar quais usuários devem ou não ter acesso às opções de
segurança de um sistema. A atribuição de direitos de usuário determina quais contas ou grupos têm
direitos ou privilégios no computador. Principais opções:
•! Acesso a este computador pela rede: esse direito de usuário determina quais usuários e grupos
têm permissão para se conectar com o computador pela rede.
•! Adicionar estações de trabalho ao domínio: essa configuração de segurança determina quais

grupos ou usuários podem adicionar estações de trabalho a um domínio.
•! Permitir logon pelos serviços de terminal: essa configuração de segurança determina quais
usuários ou grupos têm permissão para fazer logon como um cliente de serviços de terminal.
•! Alterar a hora do sistema: permite informar quais usuários têm permissão para alterar a data e a
hora do computador.
•! Apropriar-se de arquivos ou de outros objetos: determina quais usuários podem apropriar-se de

objetos protegidos do sistema, incluindo objetos do Active Directory, arquivos ou pastas,
impressoras, chaves do registro, processos e segmentos. Por padrão, apenas os administradores

possuem essa opção.
•! Fazer backup de arquivos e pastas: direito do usuário que determina os usuários que podem
ignorar permissões de diretório, registro e outros objetos persistentes, com a finalidade de fazer
backup do sistema. Especificamente esse direito de usuário é semelhante a conceder permissões
a usuários e grupos para todos os arquivos e pastas do sistema, mesmo que essas pastas tenham
permissões diferentes.
Aula 23 |!ADMINISTRANDO SEGURANÇA DE REDES
Quando falamos de segurança, devemos pensar num conjunto de fatores, que acabam acarretando o
aumento das vulnerabilidades e a crescente preocupação com a proteção:
•! competitividade e a pressa no lançamento de novos produtos;
•! alto nível de conectividade;
•! aumento do número de potenciais atacantes;
•! avanço tecnológico, que resulta em novas vulnerabilidades existentes;
•! aumento da interação entre organizações, resultando nos ambientes cooperativos;
•! integração entre diferentes tecnologias, que multiplica as vulnerabilidades;
•! Era da Informação, onde o conhecimento é o maior valor.
A evolução do mercado, da concorrência, dos negócios e da tecnologia continua comprovando a

importância da segurança. Podemos citar como exemplo as redes sem fio (wireless) que trouxeram
inúmeros benefícios para os usuários, mas também muitas mudanças nos aspectos de segurança.
Por a isso faz-se necessário que tenhamos dentro de nossas organizações uma constante preocupação
com a segurança, criando uma área ou setor focada neste tema.
A preocupação constante com a segurança ainda é relativamente nova, e muitos ainda não conseguem
enxergar sua importância, imaginando apenas que as soluções são caras e não trazem nenhum retorno
financeiro. Apesar dessa visão estar evoluindo com o decorrer dos anos, ela faz com que os executivos
prefiram aplicar seus recursos em novas soluções que possam trazer vantagens visíveis aos olhos de todos.
Esse é o maior desafio da segurança: uma solução de segurança é imensurável e

não resulta em melhorias nas quais todos podem notar que alguma coisa foi feita.
Pelo contrário, a segurança tem justamente o papel de evitar que alguém perceba que alguma coisa está
errada. O fato é que ninguém percebe a existência da segurança, apenas a inexistência dela, quando um
incidente acontece e resulta em prejuízos gigantescos.
Sobre a segurança, ainda hoje se tem esse conceito de que ela é um artigo
caro e dispensável, necessário somente quando algum ataque acontece e traz
prejuízos à organização.

Apesar dessa visão reativa, algumas organizações já vêem a segurança com outros olhos, passando a
considerá-la como parte essencial do negócio.
23.1.!ALGUMAS CONSIDERAÇÕES SOBRE A SEGURANÇA E SEUS RISCOS

Muitos aspectos precisam ser levados em consideração quando uma rede passa a constituir uma parte
importante da organização. Alguns dos riscos existentes e algumas considerações a serem feitas são:
•! falta de uma classificação das informações quanto ao seu valor e à sua confiabilidade, que serve de
base para a definição de uma estratégia de segurança adequada. Isso resulta em um fator de risco
para a organização, além de dificultar o dimensionamento das perdas resultantes de um ataque;
•! controle de acesso mal definido faz com que os usuários, que são autenticados no início da
conexão, tenham acesso irrestrito a quaisquer partes da rede interna, até mesmo a partes do
sistema que não são necessárias para a realização de suas tarefas;
•! dificuldade de controle do administrador sobre todos os sistemas da rede interna faz com que estes
não possam ser considerados confiáveis. Os ‘bugs’ nos sistemas operacionais ou nos softwares
utilizados por esses equipamentos podem abrir ‘brechas’ (vulnerabilidades) na rede interna;
•! Internet deve ser considerada um ambiente hostil e, portanto, não confiável. Assim, todos os seus
usuários devem ser considerados não confiáveis e potenciais atacantes;
•! informações que trafegam pela rede estão sujeitas a serem capturadas;
•! senhas que trafegam pela rede estão sujeitas a serem capturadas;
•! e-mails podem ser capturados, lidos, modificados e falsificados;
•! qualquer conexão entre a rede interna e qualquer outro ponto pode ser utilizada para ataques à
rede interna;
•! telefones podem ser grampeados e as informações que trafegam pela linha, seja por voz ou
dados, gravadas;
•! firewalls protegem contra acessos explicitamente proibidos, mas ainda não quanto a ataques
contra serviços legítimos;
•! quando se adota a ‘segurança pela obscuridade’, situação em que a organização pensa que sua
rede nunca será invadida porque não é conhecida, os responsáveis ‘torcem’ para que o invasor
não saiba dos problemas com segurança e dos valores disponíveis na rede interna;
•! novas tecnologias significam novas vulnerabilidades;
•! interação entre diferentes ambientes resulta na multiplicação dos pontos vulneráveis;
•! segurança envolve aspectos de negócios, tecnológicos, humanos, processuais e jurídicos

(lembre-se sempre disso);
•! segurança é complexa.
Essas considerações mostram o quanto a segurança é abrangente e multidisciplinar.

Cuidar de alguns pontos e negligenciar outros pode comprometer totalmente a organização, pois os
incidentes sempre ocorrem no elo mais fraco da corrente, ou seja, no ponto mais vulnerável do ambiente.

Todos os níveis devem ser considerados para que a informação, que é o maior bem da organização, seja
protegida. Partindo do sistema operacional, devem ser avaliados e considerados, ainda, os serviços, os
protocolos, as redes, as aplicações, os usuários e as instalações físicas envolvidas com a informação.
23.2.!A ETERNA E INDEFINIDA LUTA DA SEGURANÇA VERSUS A FUNCIONALIDADES

DESEJADAS
Até pouco tempo atrás, as organizações implementavam suas redes apenas com o objetivo de prover
funcionalidades que permitiam promover a evolução de seus processos organizacionais internos. A
preocupação com a segurança praticamente não existia, pois o contato com o mundo exterior era
limitado. Atualmente, porém, o mundo exige que as redes das organizações sejam voltadas para o seu
próprio negócio, com a formação de um ambiente cooperativo, requerendo, assim, a segurança.
Uma característica que pode ser vista é que, em um primeiro momento, a falta de um planejamento em
segurança pode parecer uma boa situação, pois tudo funciona adequadamente. No entanto, os
problemas de segurança invariavelmente aparecem depois, o que pode resultar em custos
estratosféricos para que sejam resolvidos, principalmente, em grandes ambientes.
A importância da segurança cresce ainda mais rapidamente, quando se leva em consideração o rápido
aumento da complexidade das conexões, característico dos ambientes cooperativos.
Um ponto fundamental, quando se discute o assunto, é que a segurança é

inversamente proporcional às funcionalidades, ou seja, quanto maiores as
funcionalidades, como serviços, aplicativos e demais facilidades, menor é a
segurança desse ambiente.
Isso pode ser explicado, porque a segurança pode ser comprometida pelos seguintes
fatores:
•! exploração da vulnerabilidade em sistemas operacionais, aplicativos, protocolos e
serviços;
•! exploração dos aspectos humanos das pessoas envolvidas;
•! falha no desenvolvimento e implementação da política de segurança;
•! falha na configuração de serviços e de sistemas de segurança;
•! desenvolvimento de ataques mais sofisticados.
Quando as vulnerabilidades que podem existir em sistemas operacionais, aplicativos, protocolos e

serviços são analisadas, pode-se considerar que elas são resultantes de ‘bugs’, que são decorrentes de
falhas em seu código, em seu projeto ou em sua configuração.
Assim, quanto maior for o número de sistemas, maior é a responsabilidade dos

administradores e maior é a probabilidade de existência de ‘bugs’ que podem
ser explorados.

Um estudo propôs uma fórmula para determinar os pontos de vulnerabilidade de

uma rede: o número de pontos de vulnerabilidade é igual ao número de recursos
críticos da organização, multiplicado pelo número de usuários que têm acesso a
esses recursos.
Assim, se um servidor Windows 2012 tem dez mil arquivos e cem usuários, existe um milhão de possíveis
pontos de acesso vulneráveis. A previsão de todas as brechas é impraticável, principalmente porque o fator
humano está envolvido, o que significa, por exemplo, que a escolha das senhas por cada um dos usuários
influi diretamente no nível de segurança do ambiente. Além disso, existe ainda a complexidade, que aumenta
com as interações, e o perigo das triangulações, que influem diretamente na segurança do ambiente.
O objetivo, portanto, é equilibrar a segurança com os riscos, minimizando os impactos que uma falha de
segurança pode causar à organização. As obrigações dos administradores quanto à manutenção da segurança
devem estar claramente definidas na política de segurança da organização. Ela especifica as responsabilidades
do acompanhamento das novidades e dos boletins sobre os sistemas que estão sendo utilizados na
organização, principalmente quanto a relatórios de segurança e instalação de patches de correção.
23.3.!A PRODUTIVIDADE VERSUS A SEGURANÇA. COMO FAZER?

A administração da segurança de uma organização é uma tarefa complexa, na medida em que ela deve
ser dimensionada, sem que a produtividade dos usuários seja afetada.
Normalmente, a segurança é antagônica à produtividade dos usuários, no sentido

de que, quanto maiores as funcionalidades, maiores as vulnerabilidades existentes.
Isso leva os administradores a restringirem ao máximo os serviços que os usuários
podem acessar, de modo a minimizar os riscos existentes.
O problema é que uma política de segurança muito restritiva geralmente afeta a produtividade do
usuário. Se o FTP for bloqueado com o objetivo de prevenir a entrada de ‘cavalos de Tróia’, e o usuário
necessita utilizar esse serviço para o seu trabalho, ele certamente buscará maneiras de ‘driblar’ essa
restrição do firewall. O usuário poderá instalar um modem em seu equipamento ou tentar achar ‘brechas’
no bloqueio do firewall. Quando isso acontece, os objetivos não são alcançados, pois a segurança é
comprometida pelas ações dos usuários, e sua produtividade é prejudicada, pois eles perdem tempo
tentando encontrar maneiras de ‘driblar’ o firewall.
Por isso, é importante ter uma política de segurança bem definida e bem balanceada, tanto com relação
aos serviços externos quanto aos serviços internos que os usuários, internos e externos, podem acessar. O
objetivo é criar uma política que defina, de forma ideal, apenas os serviços realmente necessários. Outro
ponto a ser considerado na definição desses serviços que serão permitidos é quanto a serviços como
youtube e sessões de bate-papo, que constituem um problema, pois comprometem o nível de
produtividade da organização, além de consumir grande largura de banda da rede. Alguns deles ainda
podem introduzir novas vulnerabilidades à rede interna da organização.
23.4.!REDE TOTALMENTE SEGURA

A segurança é complexa, envolvendo aspectos de negócios, processos humanos, jurídicos, tecnológicos,
e outros. Portanto, afirmar que uma organização está 100% segura é, na realidade, um grande erro.
Simplesmente não existe um modelo de segurança à prova de hackers.
Os hackers podem atuar de diversas maneiras, e mesmo os próprios funcionários

maliciosos podem fazer esse papel de hacker (insiders).
Uma vez que a segurança envolve aspectos tecnológicos (o melhor sistema de autenticação), aspectos
técnicos (um bom administrador de segurança), aspectos sociais (funcionários inescrupulosos que
roubam informações confidenciais da própria organização), aspectos humanos (funcionários inocentes
que sofrem com a engenharia social) e aspectos educacionais (funcionários que devem saber, pelo
menos, como escolher senhas seguras), com toda essa complexidade, o objetivo das organizações deve
ser tentar proteger ao máximo os recursos da organização e não tentar protegê-los totalmente.
Diversos aspectos contribuem para medir essa ‘máxima proteção’. Entre eles, está:
•! definir os recursos que devem ser protegidos;
•! especificar quem irá administrar a segurança; e
•! determinar o valor que será utilizado como investimento em segurança.
No mínimo, essa segurança inclui:
•! uma política e procedimentos abrangentes;
•! o controle dos usuários e
•! autenticação de todos os meios de acesso ao sistema, transações e comunicações;
•! Inclui também a proteção dos dados, além do constante monitoramento e a

evolução do nível de segurança geral.
Outro ponto importante é que as novas técnicas e tecnologias devem ser utilizadas antes que os hackers
as utilizem contra a organização.
A segurança de perímetro e a abordagem em camadas, nas quais vários

mecanismos de segurança são adotados de forma encadeada, também são
importantes. Dessa forma, as camadas de segurança funcionariam como os
catafilos da cebola, que protegem o seu interior.
Cada uma dessas camadas tem de ser transposta pelo hacker para que ele chegue ao seu objetivo, que é
o acesso à informação. Quanto maior o número de camadas, maior a dificuldade de atacar o recurso.
Assim, a tentativa de estabelecer uma segurança total pode ‘levar à loucura’; a segurança parcial, por
definição, assume os riscos. As organizações, portanto, devem definir o nível de segurança, de acordo
com suas necessidades, já assumindo esses riscos. Isso faz com que o plano de contingência seja um dos
pontos essenciais dentro do esquema de segurança de uma organização.
O objetivo não é construir uma rede totalmente segura, mas sim um sistema
altamente confiável, que seja capaz de anular os ataques mais casuais de hackers e
também de tolerar acidentes, como a possibilidade de um tubarão romper os
cabos de transmissão localizados no mar.
As falhas benignas devem ser toleradas pelos sistemas. Essas vulnerabilidades devem ser colocadas em
um lugar no qual não possam causar problemas. Uma rede nunca será totalmente segura, mas deve-se
procurar meios de torná-la, no mínimo, mais confiável.
23.5.!LISTAS DE VERIFICAÇÃO (CHECKLIST)

Com a rápida evolução que pode ser acompanhada no mundo dos negócios, no qual as conexões entre
organizações significam vantagens competitivas, a segurança de redes passa a ser mais do que fundamental;
ela passa a ser o habilitador dos negócios. Porém, captar investimentos para a implementação de uma
estratégia de segurança envolve diversos desafios, nos quais os riscos e os mitos de segurança devem ser
combatidos. As funcionalidades envolvidas com o andamento dos negócios, bem como a produtividade dos
usuários, são afetadas com as medidas de segurança adotadas, de modo que elas devem ser bem avaliadas e
estudadas para que não causem impactos significativos para os envolvidos.
A segurança é necessária, porém sua estratégia de implementação deve ser bem definida,
medindo-se custos e benefícios e assumindo-se riscos, pois a segurança total não é
possível.
Um caminho possível é a criação de listas de verificação com as atividades que devem ser realizadas
continuamente e a partir delas criar procedimentos padrão para o trabalho diário.
Como referencia citamos os links a seguir: http://tinyurl.com/gslnply e

http://tinyurl.com/gv3gupe
Aula 24 |!TENDÊNCIAS EM SEGURANÇA COMPUTACIONAL
Durante todo o curso apresentamos conceitos, procedimentos básicos e ferramentas que permitem a
melhoria do processo segurança, seja ela segurança computacional ou segurança da informação.
Entretanto como podemos ver no nosso dia-a-dia, amplamente divulgado pelos meios de comunicação,
isto somente não é suficiente.
Faz-se necessário uma mudança de consciência sobre a forma que enxergamos e trabalhamos a
segurança no ambiente de TI das nossas organizações. Quando falamos de segurança, devemos pensar
num conjunto de fatores, que acabam acarretando o aumento das vulnerabilidades e a crescente
preocupação com a proteção:
•! Novas tecnologias;
•! Facilidades e necessidades de acesso;
•! Uso de novos serviços e aplicações web;
•! Competitividade e a pressa no lançamento de novos produtos;
•! Alto nível de conectividade;
•! E muitas outras...
Tudo isso acarreta o surgimento de novas vulnerabilidades e em consequência uma mudança diária da
nossa forma de pensarmos a segurança.
Nesta seção buscamos apresentar uma visão ampla de futuras tendências de segurança e que nos
obrigam a uma mudança de postura para que possamos acompanhar e fazer frente a este novo mundo.
A evolução do mercado, da concorrência, dos negócios e da tecnologia continua

comprovando a importância da segurança. Podemos citar como exemplo as redes sem fio
(wireless) que trouxeram inúmeros benefícios para os usuários, mas também muitas
mudanças nos aspectos de segurança.
Por a isso faz-se necessário que tenhamos dentro de nossas organizações uma constante preocupação
com a segurança, criando uma área ou setor focada neste tema.
A preocupação constante com a segurança ainda é relativamente nova, e muitos ainda não conseguem
enxergar sua importância, imaginando apenas que as soluções são caras e não trazem nenhum retorno
financeiro. Apesar dessa visão evoluir com o decorrer dos anos, ela faz com que os executivos preferiram
aplicar seus recursos em novas soluções que possam trazer vantagens visíveis aos olhos de todos.
Esse é o maior desafio da segurança: uma solução de segurança é imensurável e

não resulta em melhorias nas quais todos podem notar que alguma coisa foi feita.
Pelo contrário, a segurança tem justamente o

papel de evitar que alguém perceba que alguma
coisa está errada. O fato é que ninguém percebe a
existência da segurança, apenas a inexistência
dela, quando um incidente acontece e resulta em
prejuízos gigantescos. Ai todos percebem. Sobre a
segurança, ainda hoje se tem esse conceito de que
ela é um artigo caro e dispensável, necessário
somente quando algum ataque acontece e traz
prejuízos à organização. Apesar dessa visão
reativa, algumas organizações já vêem a
segurança com outros olhos, passando a
considerá-la como parte essencial do negócio.
Fonte: http://tinyurl.com/y8mruttu
24.1.!ALGUMAS CONSIDERAÇÕES SOBRE A SEGURANÇA E SEUS RISCOS

Muitos aspectos precisam ser levados em consideração quando uma rede passa a constituir uma parte
importante da organização. Alguns dos riscos existentes e algumas considerações a serem feitas são:
•! falta de uma classificação das informações quanto ao seu valor e à sua confiabilidade, que serve de base
para a definição de uma estratégia de segurança adequada. Isso resulta em um fator de risco para a
organização, além de dificultar o dimensionamento das perdas resultantes de um ataque;
•! controle de acesso mal definido faz com que os usuários, que são autenticados no início da
conexão, tenham acesso irrestrito a quaisquer partes da rede interna, até mesmo a partes do
sistema que não são necessárias para a realização de suas tarefas;

•! dificuldade de controle do administrador sobre todos os sistemas da rede interna faz com que estes
não possam ser considerados confiáveis. Os erros e/ou incidentes nos sistemas operacionais ou nos
softwares utilizados por esses equipamentos podem criar e abrir vulnerabilidades na rede interna;
•! Internet deve ser considerada um ambiente hostil e, portanto, não confiável. Assim, todos os seus
usuários devem ser considerados não confiáveis e potenciais atacantes;
•! informações que trafegam pela rede estão sujeitas a serem capturadas;
•! senhas que trafegam pela rede estão sujeitas a serem capturadas;
•! e-mails podem ser capturados, lidos, modificados e falsificados;
•! qualquer conexão entre a rede interna e qualquer outro ponto pode ser utilizada para ataques à
rede interna;
•! telefones podem ser grampeados e as informações que trafegam pela linha, seja por voz ou
dados, gravadas (atenção com smartphones);
•! firewalls protegem contra acessos explicitamente proibidos, mas ainda não quanto a ataques
contra serviços legítimos;
•! quando se adota a ‘segurança pela obscuridade’, situação em que a organização pensa que sua
rede nunca será invadida porque não é conhecida, os responsáveis ‘torcem’ para que o invasor
não saiba dos problemas com segurança e dos valores disponíveis na rede interna;
•! novas tecnologias significam novas vulnerabilidades;
•! interação entre diferentes ambientes resulta na multiplicação dos pontos vulneráveis;
•! segurança envolve aspectos de negócios, tecnológicos, humanos, processuais e jurídicos

(lembre-se sempre disso);
•! segurança é complexa.
Essas considerações mostram o quanto a segurança é abrangente e multidisciplinar.
Cuidar de alguns pontos e negligenciar outros pode comprometer totalmente a organização, pois os incidentes
sempre ocorrem no elo mais fraco da corrente, ou seja, no ponto mais vulnerável do ambiente.
Todos os níveis devem ser considerados para que a informação, que é o maior bem da
organização, seja protegida. Partindo do sistema operacional, devem ser avaliados e
considerados, ainda, os serviços, os protocolos, as redes, as aplicações, os usuários e as
instalações físicas envolvidas com a informação.

24.2.!A ETERNA E INDEFINIDA LUTA DA SEGURANÇA VERSUS A FUNCIONALIDADES

DESEJADAS
Até recentemente, as organizações desenvolviam suas redes apenas com o objetivo de prover
funcionalidades que permitissem promover a evolução de seus processos organizacionais internos.
A preocupação com a segurança praticamente inexistia, pelo limitado contato com o

mundo exterior. Hoje em dia, o mundo exige que as redes das organizações sejam
voltadas para o seu próprio negócio, com a formação de um ambiente cooperativo e
colaborativo, necessitando, assim, de segurança.
Uma característica que pode ser vista é que, em um primeiro momento, a falta de um planejamento em
segurança pode parecer uma boa situação, pois tudo funciona adequadamente. No entanto, os
problemas de segurança invariavelmente aparecem depois, o que pode resultar em custos
estratosféricos para que sejam resolvidos, principalmente, em grandes ambientes.
A importância da segurança cresce ainda mais rapidamente, quando se leva em consideração o rápido
aumento da complexidade das conexões, característico dos ambientes cooperativos.
Um ponto fundamental, quando se discute o assunto, é que a segurança é

inversamente proporcional às funcionalidades.
Ou seja, quanto maiores as funcionalidades, como serviços, aplicativos e demais facilidades, menor é a
segurança desse ambiente. Isso pode ser explicado, porque a segurança pode ser comprometida pelos
seguintes fatores:
•! exploração da vulnerabilidade em sistemas operacionais, aplicativos, protocolos e serviços;
•! exploração dos aspectos humanos das pessoas envolvidas;
•! falha no desenvolvimento e implementação da política de segurança;
•! falha na configuração de serviços e de sistemas de segurança;
•! desenvolvimento de ataques mais sofisticados.
Quando as vulnerabilidades que podem existir em sistemas operacionais, aplicativos, protocolos e

serviços são analisadas, pode-se considerar que elas são resultantes de ‘bugs’, que são decorrentes de
falhas em seu código, em seu projeto ou em sua configuração.
Assim, quanto maior for o número de sistemas, maior é a responsabilidade dos administradores e maior é
a probabilidade de existência de ‘bugs’ que podem ser explorados. Um estudo propôs uma fórmula para
determinar os pontos de vulnerabilidade de uma rede: o número de pontos de vulnerabilidade é igual ao
número de recursos críticos da organização, multiplicado pelo número de usuários que têm acesso a
esses recursos. Assim, se um servidor Windows tem dez mil arquivos e cem usuários, existe um milhão de
possíveis pontos de acesso vulneráveis.
A previsão de todas as brechas é impraticável, principalmente porque o fator

humano está envolvido, o que significa, por exemplo, que a escolha das senhas por
cada um dos usuários influi diretamente no nível de segurança do ambiente.

Além disso, existe ainda a complexidade, que aumenta com as interações, e o perigo das triangulações,
que influem diretamente na segurança do ambiente.
O objetivo, portanto, é equilibrar a segurança com os riscos, minimizando os impactos que uma falha de
segurança pode causar à organização. As obrigações dos administradores quanto à manutenção da segurança
devem estar claramente definidas na política de segurança da organização. Ela especifica as responsabilidades
do acompanhamento das novidades e dos boletins sobre os sistemas que estão sendo utilizados na
organização, principalmente quanto a relatórios de segurança e instalação de patches de correção.
24.3.!A PRODUTIVIDADE VERSUS A SEGURANÇA. COMO FAZER?

A administração da segurança de uma organização é uma tarefa complexa, na
medida em que ela deve ser dimensionada, sem que a produtividade dos usuários
seja afetada.
Normalmente, a segurança é antagônica à

produtividade dos usuários, no sentidode que,
quanto maiores as funcionalidades, maiores as
vulnerabilidades existentes. Isso leva os
administradores a restringirem ao máximo os
serviços que os usuários podem acessar, de
modo a minimizar os riscos existentes.
O problema é que uma política de
segurança muito restritiva geralmente afeta
a produtividade do usuário. Se o FTP for
bloqueado com o objetivo de prevenir a
entrada de ‘cavalos de Tróia’, e o usuário
necessita utilizar esse serviço para o seu
Fonte: http://tinyurl.com/ycml4x8c trabalho, ele certamente buscará maneiras
de ‘driblar’ essa restrição do firewall.
O usuário poderá instalar um modem em seu equipamento ou tentar achar ‘brechas’ no

bloqueio do firewall. Quando isso acontece, os objetivos não são alcançados, pois a
segurança é comprometida pelas ações dos usuários, e sua produtividade é prejudicada,
pois eles perdem tempo tentando encontrar maneiras de ‘driblar’ o firewall.
Por isso, é importante ter uma política de segurança bem definida e bem balanceada, tanto com relação
aos serviços externos quanto aos serviços internos que os usuários, internos e externos, podem acessar.
O objetivo é criar uma política que defina, de forma ideal, apenas os serviços
realmente necessários.
Outro ponto a ser considerado na definição desses serviços que serão permitidos é quanto a serviços
como youtube e sessões de bate-papo, que constituem um problema, pois comprometem o nível de
produtividade da organização, além de consumir grande largura de banda da rede. Alguns deles ainda
podem introduzir novas vulnerabilidades à rede interna da organização.

24.4.!REDE TOTALMENTE SEGURA

A segurança é complexa,
envolvendo aspectos de
negócios, processos humanos,
jurídicos, tecnológicos, e outros.
Portanto, afirmar que uma
organização está 100% segura é,
na realidade, um grande erro.
Simplesmente não existe um
modelo de segurança à prova de
hackers. Os hackers podem atuar
de diversas maneiras, e mesmo
os próprios funcionários Fonte: http://tinyurl.com/c4gvskb
maliciosos podem fazer esse
papel de hacker (insiders). Uma
vez que a segurança envolve aspectos tecnológicos (o melhor sistema de autenticação), aspectos
técnicos (um bom administrador de segurança), aspectos sociais (funcionários inescrupulosos que
roubam informações confiden ciais da própria organização), aspectos humanos (funcionários inocentes
que sofrem com a engenharia social) e aspectos educacionais (funcionários que devem saber, pelo
menos, como escolher senhas seguras), com toda essa complexidade, o objetivo das organizações deve
ser tentar proteger ao máximo os recursos da organização e não tentar protegê-los totalmente.
Diversos aspectos contribuem para medir essa ‘máxima proteção’. Entre eles, está:
•! definir os recursos que devem ser protegidos;
•! especificar quem irá administrar a segurança; e
•! determinar o valor que será utilizado como investimento em segurança.
No mínimo, essa segurança inclui:

•! uma política de segurança conhecida e procedimentos abrangentes;
•! o controle dos usuários e
•! autenticação de todos os meios de acesso ao sistema, transações e comunicações;
•! Inclui também a proteção dos dados, além do constante monitoramento e a

evolução do nível de segurança geral.
Outro ponto importante é que as novas técnicas e tecnologias devem ser utilizadas
antes que os hackers as utilizem contra a organização.
A segurança de perímetro e a abordagem em camadas, nas quais vários mecanismos de segurança são
adotados de forma encadeada, também são importantes. Dessa forma, as camadas de segurança
funcionariam como os catafilos da cebola, que protegem o seu interior. Cada uma dessas camadas tem
de ser transposta pelo hacker para que ele chegue ao seu objetivo, que é o acesso à informação.
Quanto maior o número de camadas, maior a dificuldade de atacar o recurso.

Assim, a tentativa de estabelecer uma segurança total pode ‘levar à loucura’; a segurança parcial, por
definição, assume os riscos. As organizações, portanto, devem definir o nível de segurança, de acordo
com suas necessidades, já assumindo esses riscos. Isso faz com que o plano de contingência seja um dos
pontos essenciais dentro do esquema de segurança de uma organização.
O objetivo não é construir uma rede totalmente segura, mas sim um sistema altamente
confiável, que seja capaz de anular os ataques mais casuais de hackers e também de
tolerar acidentes, como a possibilidade de um tubarão romper os cabos de transmissão
localizados no mar.
As falhas benignas devem ser toleradas pelos sistemas. Essas vulnerabilidades devem ser colocadas em
um lugar no qual não possam causar problemas. Uma rede nunca será totalmente segura, mas deve-se
procurar meios de torná-la, no mínimo, mais confiável.
24.5.!LISTAS DE VERIFICAÇÃO (CHECKLIST)

Com a rápida evolução que pode ser acompanhada no mundo dos negócios, no qual as conexões entre
organizações significam vantagens competitivas, a segurança de redes passa a ser mais do que
fundamental; ela passa a ser o habilitador dos negócios. Porém, captar investimentos para a
implementação de uma estratégia de segurança envolve diversos desafios, nos quais os riscos e os mitos
de segurança devem ser combatidos. As funcionalidades envolvidas com o andamento dos negócios,
bem como a produtividade dos usuários, são afetadas com as medidas de segurança adotadas, de modo
que elas devem ser bem avaliadas e estudadas para que não causem impactos significativos para os
envolvidos. A segurança é necessária, porém sua estratégia de implementação deve ser bem definida,
medindo-se custos e benefícios e assumindo-se riscos, pois a segurança total não é possível.
Um caminho possível é a criação de listas de verificação com as atividades que

devem ser realizadas continuamente e a partir delas criar procedimentos padrão
para o trabalho diário.
Como referencia citamos os links:

http://tinyurl.com/gslnply
http://tinyurl.com/gv3gupe
Estes links permite que criemos uma lista que permite estabelecer uma
sequência de atividades ou verificações de acordo com suas
necessidades e seu tipo de negócio. Crie a sua para o seu ambiente de
trabalho e vá aperfeiçoando a cada dia.

24.6.!SEGURANÇA EM CLOUD
Computação em Nuvem (Cloud Computing) é a utilização de recursos
computacionais (memória, dispositivos de armazenamento e capacidade de
cálculo (processamento) de computadores e servidores interligados por meio da
rede internet de forma transparente para o usuário.
Com a Computação em Nuvem, um usuário pode ter acesso a recursos que se fossem executados na
máquina do mesmo, demandariam maior capacidade de hardware do equipamento do usuário,
instalação de softwares que geralmente tem licenças caras, além de maior gasto de energia, aumentando
desta forma os custos.
Fonte: http://tinyurl.com/y85zrft9
Assim, a Computação em Nuvem, permite alguns modelos de serviço, explicados de forma resumida a seguir:
Software como Serviço (Software as a Service - SaaS): Compreende o uso de aplicações que
são executadas na nuvem, como por exemplo um cliente web de e-mail, o Google Docs, que
permite criação e edição de documentos, planilhas e apresentações de slides via navegador.
Plataforma como Serviço (Platform as a Service - PaaS): Permite ao usuário submeter
aplicações desenvolvidas em linguagem de programação ou ferramentas de acordo com o a
plataforma e executá-la dentro de um sistema operacional virtual. O usuário não tem controle
sobre nada além de suas aplicações, como sistema operacional, rede e armazenamento.

Infraestrutura como Serviço (Infrastructure as a Service - IaaS): O usuário tem domínio

sobre sistema operacional, rede (de forma limitada), armazenamento além do controle
sobre suas aplicações submetidas. O usuário apenas não tem controle sobre a camada
infraestrutura mais interior da nuvem (core).
Você sabe o que é Cloud Computing, ou Computação na Nuvem?

http://tinyurl.com/ybkpf4u6
Como pode ser observado a segurança nessas plataformas é algo extremamente crítico.
A entidade CSA (Cloud Security Alliance) possui um detalhado guia para

segurança em nuvem que pode ser encontrado na sua versão em
português em:
http://tinyurl.com/y89myu9w
É importante uma análise constante dos aspectos de segurança em nuvem.
Leiam os seguintes artigos:
http://tinyurl.com/y8ta5h46
http://tinyurl.com/yb2qb25m
http://tinyurl.com/yc2lbgmr
Para saber mais assista aos vídeos:
http://tinyurl.com/yc78e5xy
http://tinyurl.com/y79l9r24
SEGURANÇA EM IOT
Internet das Coisas (Internet of Things ou IoT) significa apenas um ambiente que reúne informações de
vários dispositivos (computadores, veículos, smartphones, semáforos, e quase qualquer coisa com um
sensor) e de aplicações (qualquer coisa desde uma aplicação de mídia social como o Twitter a uma
plataforma de comércio eletrônico, de um sistema de produção a um sistema de controlo de tráfego).
Basicamente, são precisos dados e meios para acessar – que é de onde surge o rótulo de “Internet”,
embora, naturalmente, não seja necessária a própria internet, ou até mesmo uma ligação sempre
disponível de rede.
Uma coisa, no contexto da Internet das Coisas, é um objeto conectado que pode ser, por exemplo, uma
pessoa com um monitor cardíaco, um animal rastreado em uma fazenda, um tanque industrial com sensores
de nível, um carro com sensores que avisam a pressão dos pneus, uma lâmpada de iluminação pública de
uma cidade, uma tomada em sua casa ou qualquer outro objeto natural ou construído pelo homem.

Fonte: http://tinyurl.com/yafa2alb
Atualmente as tecnologias de Internet das Coisas

envolvem dispositivos conectados à aplicações por meio
da Internet.
A Internet das Coisas possui várias tecnologias em comum
com as tecnologias de comunicação machine-to-machine
(M2M), usual em produtos industriais, de medição de
energia, água, gás e óleo. Entretanto, o conceito de
Internet das Coisas vai além da comunicação M2M pois
propõe um futuro no qual todos os objetos estão
conectados e comunicando-se de forma inteligente. Em
outras palavras, o mundo físico com a Internet das Coisas
dá origem a um grande sistema de informações.
Fonte: http://tinyurl.com/y9kb79h6

Leiam:
http://tinyurl.com/yawqxp7b
Assistam aos vídeos:
http://tinyurl.com/y7yay2yp
http://tinyurl.com/y78n27s4
http://tinyurl.com/ybnghep5
http://tinyurl.com/ya23kovl
http://tinyurl.com/yavrkuwp
http://tinyurl.com/y7c4mkth
SEGURANÇA BYOD
O BYOD (Bring Your Own Device) significa “traga

o seu próprio dispositivo” e dá aos funcionários
da empresa a oportunidade de utilizar os seus
próprios aparelhos para acessar dados e
informações da companhia. Com isso, o
funcionário tem liberdade para utilizar a
tecnologia que mais lhe convém,
proporcionando um ambiente de trabalho mais
confortável.
Fonte: http://tinyurl.com/y8x7sqax Existem três possibilidades de incorporar o

BYOD à cultura da empresa. A primeira é
estabelecer que se os dados da empresa serão acessados por um dispositivo pessoal, então a companhia
tem o direito de controlar e bloquear o aparelho.
A segunda opção é que os custos da tecnologia utilizada sejam arcadas pela própria empresa, desde que
caso os funcionários que não se sintam confortáveis com o aparelho comprado, eles tenham a alternativa
de trazer os seus próprios dispositivos pessoais.
A última alternativa é a transferência legal do dispositivo para o funcionário. As três opções oferecem
suas vantagens e desvantagens e devem ser minuciosamente avaliadas antes que a política seja aplicada.
A verdade é que a inserção do BYOD no mercado de trabalho é cada dia mais inevitável e deve ser vista
como futuro da cultura empresarial.

O BYOD é uma realidade crescente nas organizações. É fundamental compreender que, essa não é uma
questão que deva ser tratada exclusivamente pela área de TI, apesar dos aspectos tecnológicos. A
interseção com o os departamentos Jurídico e de Recursos Humanos é grande e o trabalho colaborativo
entre as áreas é fundamental para se estabelecer uma política sólida e consistente de BYOD.
Fonte: http://tinyurl.com/y9qagmyr
Assistam aos vídeos:

http://tinyurl.com/ybp2k7dy
http://tinyurl.com/y9fy9zqy
http://tinyurl.com/y7zpegbk
http://tinyurl.com/yc4x2gsh
NOVAS PERSPECTIVAS DA SEGURANÇA - TENDÊNCIAS
Acompanhar as tendências de segurança da informação, requer do profissional uma atenção no que é

publicado e também a assinatura e participação de diversas listas e grupos existentes no Twitter,
WhatsApp e no próprio Facebook. Além disso requer também uma constante atualização através de
cursos e leituras técnicas.
! !

Assim recomendamos que acompanhe e faça a leitura dos seguintes sites:

http://tinyurl.com/y7nxbv25
http://tinyurl.com/jnodtgn
http://tinyurl.com/ycdutahx
http://tinyurl.com/y85owje9
http://tinyurl.com/y8z8xkcd
http://tinyurl.com/ybn9af92
Complemente este conhecimento assistindo aos vídeos:
http://tinyurl.com/yapybnho
http://tinyurl.com/y8qpkszz
http://tinyurl.com/y7k5qhbp
Você terminou o estudo desta unidade. Chegou o momento de verificar sua aprendizagem.
Ficou com alguma dúvida? Retome a leitura.
Quando se sentir preparado, acesse a Verificação de Aprendizagem da unidade no menu
lateral das aulas ou na sala de aula da disciplina. Fique atento, essas questões valem nota!
Você terá uma única tentativa antes de receber o feedback das suas respostas, com
comentários das questões que você acertou e errou.
Vamos lá?!
! !

REFERÊNCIAS
ALERTASECURITY. A importância da Análise de vulnerabilidade. 2016.
http://www.alertasecurity.com.br/blog/82-a-importancia-da-analise-de-vulnerabilidadeAcesso 20 out 2016.
Beaver, Kevin. Hacking Para Leigos. Alta Books. Rio. 2014.

BLOG.TEMPEST. Uma Breve Introdução Didática à Análise de Logs. 2010. Disponível em <
http://blog.tempest.com.br/marco-carnut/uma-breve-introducao-didatica-analise-logs.html>. Acesso 20
out 2016.
BRUNOANTUNESS. Como instalar o Nessus. 2013. Disponível em <

https://brunoantuness.wordpress.com/2013/06/23/como-instalar-o-nessus/>. Acesso 20 out 2016.
CERT.BR. Análise e Interpretação de logs. Disponível em < http://www.cert.br/docs/palestras/nbso-

gter15-tutorial2003.pdf>. Acesso 20 out 2016.
COMPUTERWORLD. Oito ferramentas de teste de invasão para reforçar a segurança de sua empresa.
2015. Disponível em < http://computerworld.com.br/oito-ferramentas-de-teste-de-invasao-para-reforcar-
seguranca-de-sua-empresa>. Acesso 20 out 2016.
CONVISO. Análise X gestão de vulnerabilidades: entenda a diferença. 2016. Disponível em <

http://blog.conviso.com.br/analise-x-gestao-de-vulnerabilidades-entenda-a-diferenca/>. Acesso 20 out 2016.
CSIRT, Unicamp. Log: O aliado do administrador. 2014. Disponível em <

https://www.security.unicamp.br/58-log-o-aliado-do-administrador.html>. Acesso 20 out 2016.
DATASAFE. Análise de Vulnerabilidades. Disponível em < http://www.datasafe.srv.br/va.html>. Acesso
20 out 2016.
DECISIONREPORT. Segurança: testes manuais X testes automatizados. 2009. Disponível em <

http://www.decisionreport.com.br/publique/cgi/cgilua.exe/sys/start.htm?infoid=4141&sid=15&tpl=print
erview>. Acesso 20 out 2016.
DOCPLAYER. Guia do usuário do Nessus 5.0 flash. 2012. http://docplayer.com.br/5646553-Guia-do-

usuario-do-nessus-5-0-flash-4-de-dezembro-de-2012-revisao-18.htmlAcesso 20 out 2016.
EMQUESTÃO. A análise de logs como estratégia para a realização da garantia do usuário. 2015. Disponível
em < http://www.seer.ufrgs.br/index.php/EmQuestao/article/view/59806/36047>. Acesso 20 out 2016.
FETCH. Avaliação de Ferramentas de Análise de Segurança: Nessus – OpenVAS. 2013. Disponível em <
http://187.7.106.14/wiki2013_2/lib/exe/fetch.php?media=projeto03:artigo_projeto_integrador_1_tiago_
pasa.pdf>. Acesso 20 out 2016.
FLAVIOMICHELETTI. Análise das principais vulnerabilidades de aplicações web tendo como base a
arquitetura lamp e as top 10 vulnerabilidades da owasp. 2011. Disponível em <
https://flaviomicheletti.github.io/tcc-flavio-alexandre-micheletti.pdf>. Acesso 20 out 2016.
GFI. GFI Languard. Disponível em < http://languard.gfi.com/>. Acesso 20 out 2016.
GRANBERY. Scanners de vulnerabilidades aplicados a ambientes organizacionais. Disponível em <

http://re.granbery.edu.br/artigos/Mjgz>. Acesso 20 out 2016.
HACKERSEC. As melhores ferramentas hacker e forense. 2016. Disponível em <

https://hackersec.com/melhores-ferramentas-hacker-forense/>. Acesso 20 out 2016.

HARDWARE. Redes, Guia Prático. 2ª Ed. 2008. http://www.hardware.com.br/livros/redes/usando-

nessus.htmlAcesso 20 out 2016.
IBM. Testes de segurança manuais versus testes de automatizado. 2009. Disponível em <
http://www.ibm.com/developerworks/br/rational/local/security_test/>. Acesso 20 out 2016.
IDGNOW. Teste: Produtos para análise de segurança da rede de sua empresa. 2011. Disponível em <
http://idgnow.com.br/ti-corporativa/2011/07/01/idgnoticia.teste-seguranca-corporativa/#&panel1-1>.
Acesso 20 out 2016.
ILLIX. Análise de Vulnerabilidades. Disponível em < http://www.illix.com.br/vuln.html>. Acesso 20 out 2016.
IMASTERS. Análise Forense Computacional de Logs em Sistemas Linux: as testemunhas da rede. 2008.
Disponível em < http://imasters.com.br/artigo/10207/gerencia-de-ti/analise-forense-computacional-de-logs-
em-sistemas-linux-as-testemunhas-da-rede?trace=1519021197&source=single>. Acesso 20 out 2016.
INFOCRIME. Análise de logs. 2013. Disponível em < http://www.infocrime.com.br/2013/07/analise-de-

logs/>. Acesso 20 out 2016.
INFOQ. Análise do Livro LogStash: Gerenciamento de logs de forma simples. 2013. Disponível em <
https://www.infoq.com/br/articles/review-the-logstash-book>. Acesso 20 out 2016.
JEIKS.NET. Auditoria e segurança de redes de computadores. 2011. Disponível em <

http://jeiks.net/wp-content/uploads/2011/05/slide.pdf>. Acesso 20 out 2016.
LINHADECODIGO. Perícia Computacional: Análise e Integridade de Logs em Sistemas Windows.

Disponível em < http://www.linhadecodigo.com.br/artigo/1998/pericia-computacional-analise-e-
integridade-de-logs-em-sistemas-windows.aspx >. Acesso 20 out 2016.
LINHADEFENSIVA. Análise de Logs. 2016. Disponível em <

http://www.linhadefensiva.org/forum/topic/167448-an%C3%A1lise-de-logs/>. Acesso 20 out 2016.
MAIATI. Você sabe onde estão as brechas de segurança da sua rede? 2011. Disponível em <
http://www.maiati.com.br/blog/2011/07/01/voce-sabe-onde-estao-as-brechas-de-seguranca-da-sua-
rede/>. Acesso 20 out 2016.
MARCELORAMOS. Análise de métricas e dados de log. Disponível em <

http://www.marceloramos.com.br/publicacao/66/analise-de-metricas-e-dados-de-log>. Acesso 20 out 2016.
MELO, Sandro. Exploração de Vulnerabilidade em Redes TCP/IP. Editora Alta Books.

MEMORIA.RNP. Os Logs como Ferramenta de Detecção de Intrusão. 1999. Disponível em <
https://memoria.rnp.br/newsgen/9905/logs.html>. Acesso 20 out 2016.
MICROSOFT. Análise de logs: Microsoft Operations Management Suit. Disponível em <

https://www.microsoft.com/pt-br/server-cloud/solutions/log-analytics.aspx>. Acesso 20 out 2016.
NAKAMURA, Emilio Tissato; GEUS, Paulo Licio de. Segurança de redes em ambientes cooperativos. São
Paulo: Novatec, 2010.
OLIVEIRA, Wilson. Técnicas para hackers e soluções para segurança: versão 2 – Editora
Centroatlantico.pt – Portugal – 2003
REPOSITORIO.UCB. A importância da análise de vulnerabilidades para uma organização. 2013.

Disponível em <

http://repositorio.ucb.br/jspui/bitstream/10869/2687/1/Rodrigo%20Sim%C3%A3o%20Teixeira.pdf>.
Acesso 20 out 2016.
RESPIRANDOLINUX. Linux e Logs: A necessidade de auditar: Parte 1. 2015. Disponível em <

https://respirandolinux.wordpress.com/2015/08/15/linux-e-logs-a-necessidade-de-auditar-parte-1/>.
Acesso 20 out 2016.
REVISTATIS. Análise de Vulnerabilidades com OpenVAS e Nessus. 2014. Disponível em <

http://revistatis.dc.ufscar.br/index.php/revista/article/viewFile/74/68>. Acesso 20 out 2016.
SCARFONE, Karen. Guidelines on Firewalls and Firewall Policy: Revision 1 – NIST
SEGURANÇADAINFORMAÇÃO. Análise de Vulnerabilidades: O que é e para que serve? Disponível em <
http://segurancadainformacao.modulo.com.br/que-e-analise-de-vulnerabilidades>. Acesso 20 out 2016.
SERVNET. Gerenciamento de vulnerabilidades corporativas Retina CS. Disponível em <

https://www.servnet.inf.br/fabricante//beyondtrust/pdf//DS_Retina_EVM%20-por.pdf>. Acesso 20 out 2016.
TENABLE. Proteja sua rede localmente e na nuvem com Nessu Vulnerability Scanner. Disponível em
< http://www.tenable.com/pt-br/nessus/>. Acesso 20 out 2016.
TENABLE. Verificações de conformidade Nessus. 2012. Disponível em <

http://static.tenable.com/documentation/nessus_compliance_checks_PTB.pdf>. Acesso 20 out 2016.
TRTEC. Eeye digital security anuncia nova versão do retina network security scanner. Disponível em
< http://www.trtec.com.br/pages/retina5.html>. Acesso 20 out 2016.
VIVAOLINUX. Usando e instalando o Nessus no Linux. 2008. Disponível em <

https://www.vivaolinux.com.br/artigo/Usando-e-instalando-o-Nessus-no-Linux>. Acesso 20 out 2016.
Weidman, Georgia. Testes de Invasão: Uma introdução prática ao hacking. NovaTec – São Paulo - 2014

UIA4

Enviado por

Direitos autorais:

Formatos disponíveis

UIA4

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

UIA4

Enviado por

Direitos autorais:

Formatos disponíveis

!

VERSÃO PARA IMPRESSÃO

SEGURANÇA DE REDES DE COMPUTADORES

Copyright © 2017 Centro Universitário IESB. Todos os direitos reservados.

Aula 19 | Análise de Logs .............................................................................................................5!

Aula 20 | Auditoria e Análise de vulnerabilidades com ferramentas automatizadas.......... 13!

Aula 21 | Configurando a segurança de servidores Linux ...................................................... 19!

Aula 22 | Configurando a segurança de servidores Windows ............................................... 38!

22.1. Necessidade de configuração de um bastion host .................................................................. 38!

Aula 23 | Administrando Segurança de redes ......................................................................... 55!

Aula 24 | Tendências em Segurança Computacional.............................................................. 60!

Copyright © 2017 Centro Universitário IESB. Todos os direitos reservados.

Aula 19 |!ANÁLISE DE LOGS

É um registro cronológico sistemático de eventos ou atividades que pode ficar

Os logs relacionados a incidentes de segurança, são normalmente gerados por

19.1.1.!GERAÇÃO DE ARQUIVOS DE LOGS

Copyright © 2017 Centro Universitário IESB. Todos os direitos reservados.

Os arquivos de registros de logs são essenciais para a notificação de incidentes,

A geração de logs é um arquivo de registros de eventos ou estatísticas para fornecer

Assim, é importante manter estes registros seguros e intactos, pois em uma

Copyright © 2017 Centro Universitário IESB. Todos os direitos reservados.

19.1.2.!LOGS E SUA IMPORTÂNCIA

Os logs asseguram, após a ocorrência de um desastre, falha ou violação de acesso, a estabelecer a

Copyright © 2017 Centro Universitário IESB. Todos os direitos reservados.

•! Checar a eficácia dos controles adotados e para verificar a conformidade com o

19.1.3.!CARACTERIZAÇÃO E PADRÕES DE LOGS

MARCAÇÃO TEMPORAL (TIMESTAMP)

Caracteriza a importância daquele registro de log tendo em vista a integridade do sistema. É

Copyright © 2017 Centro Universitário IESB. Todos os direitos reservados.

Os eventos de logs podem ser armazenados de duas formas: on-line e off-line.

19.1.5.!SISTEMA DE GERENCIAMENTO DE LOGS

Transmissão e É um processo que transmite os eventos de log para um servidor central em

Processo que reduz o tamanho de uma informação por meio de algoritmos de

Armazenamento Compreende guardar os registros de logs por um tempo determinado;

Responsável por estruturar os registros de logs de forma que sejam

Este processo permite a visualização dos registros de logs sejam eles em

Para Conhecer logs em sistemas Windows acesse o site

19.2.!ARQUIVOS DE LOGS BÁSICOS DE SISTEMA UNIX

É recomendável configurar como dono o usuário root e as permissões de acesso

Copyright © 2017 Centro Universitário IESB. Todos os direitos reservados.

Copyright © 2017 Centro Universitário IESB. Todos os direitos reservados.

•! Event Log Explorer - http://eventlogxp.com/ (Windows)

•! Log Expert - http://www.log-expert.de/ (Windows)

•! Snake Tail - http://snakenest.com/ (Linux/Windows)

Copyright © 2017 Centro Universitário IESB. Todos os direitos reservados.

Aprenda mais assistindo aos vídeos:

Aula 20 |!AUDITORIA E ANÁLISE DE VULNERABILIDADES COM

Aprenda mais sobre auditoria nos vídeos

Copyright © 2017 Centro Universitário IESB. Todos os direitos reservados.

Essas vulnerabilidades podem ser exploradas com o intuito de subverter o sistema em

Existem diversos tipos de vulnerabilidades, sendo os mais comuns as vulnerabilidades de software,

a análise de vulnerabilidade não substitui o controle da aplicação de correções dos

• ! Identificar e tratar falhas de softwares que possam comprometer seu desempenho,

•! Implementar a melhoria constante do controle de segurança;

Copyright © 2017 Centro Universitário IESB. Todos os direitos reservados.

Aprenda sobre o Retina assistindo aos vídeo:

O Nessus tem exatamente a função de encontrar "brechas" na máquina local, na

O Nessus é software que tem o objetivo de fazer verificação remota e segura de

Copyright © 2017 Centro Universitário IESB. Todos os direitos reservados.

Para instalar o Nessus é necessário baixar o pacote específico para o