Segurança da Informação

O pacote virá com 3 programase 1 lib. O Cain(O programa em si!), Abel, um “backdoor” para administração remota do Cain e a lib WinPcap, que permite a análise se redes. Se você não instilá-lo opções como sniffing não irão funcionar e o wintrgen, que é o gerador de rainbow table que explicarei depois.

2. Start/Stop Sniffer e Start/Stop APR

Com este botão você poderá iniciar ou parar o sniffer. Para quem não sabe o sniffer deixa o seu adaptador de rede em modo promiscuo, ou seja, escutando todos os dados que trafegam pela rede mesmo não sendo direcionada para aquela maquina. Quando você clicar pela primeira vez aparecerá uma caixa de diálogo chamada Configurantion Dialog onde você deverá selecionar o adaptador a ser usado(caso sua maquina tenha mais que um) mas o programa configura automaticamente. Vale lembrar que o ato de sniffar é difícil de ser identificado.
Com o botão Star/Stop APR você poderá iniciar ou para o APR. Irei explicar sobre APR mais abaixo.

3. Guia Sniffer

Depois de iniciado o sniffer você poderá ver seus resultados na guia sniffer. Na parte inferior será subdividida em mais guias: Host, APR, Routing, Password, Voip

3.1 Host

Aqui o sniffer irá mostrar quais computadores estão em sua subnet. Para ver os pc’s basta apenas clicar no botão + (Add to list). Ao clicar mostrará uma guia de scaneamento de mac address, você pode pôr uma faixa ou colocar para mostrar todos. Irão mostrar o endereço de ip, endereço MAC e fingerprint do PC.

3.2 APR

Muitas vezes sua rede é segmentada por switchs, fazendo assim você não poder sniffar outros segmentos. Para isso existe o que chamamos de ARP poisoning. o ARP poisoning consiste em você envenenar a tabela ARP do seu switch fazendo ele receber os pacotes do pc que você deseja. Não entrarei em detalhes porque este não é meu objetivo. No guia APR você terá que escolher o tipo de APR: DNS, SSH-1, HTTPS ou RDP. Selecionado você terá que adicionar o host clicando no botão +. Lembre-se que o botão Start/Stop APR deve estar selecionado. Ao clicar no botão + aparecerá uma caixa com os hosts da sua subnet que obtivemos no guia host(Lembra?). Agora é preciso apenas adicionar os host para o APR. Depois de fazer isso você vera o icone e do lado escrito poisoning.
O APR do Cain Também realiza o Homem no meio(man in the middle) em redes locais seguindo os mesmos procedimentos.

3.3 Routing

Esta seção pediria um explicação extensa, e como este é um manual básico, irei pular aqui. Desculpem-me!

3.4 Password

Esta seção, com o sniffer ligado, mostrará todas senhas que passam por você. Não precisa de nenhuma configuração, eles apareceram ali. Fácil não? Ele pega senhas de vários, você já deve ter visto a listinha dele. Mas as vezes as senhas podem vir criptografadas, explicarei isso mais abaixo.

3.5 Voip

Igual ao Password. Todas conexões de voip que aparecerem o cain gravará para você. Semelhante ao grampo de telefone, mas grampeia conversas no Voip.

4. Botões Add to list(+) e Remove from list(lixeira)

Servem para adicionar ou remover alguns itens que são usados em alguns guias.

5. Botão configure

É o mesmo que você selecionar o menu configure. Mostrará um guia para configuração. Não irei explicar aqui, mas só de você olhar você entenderá. Não precisará mexer, afinal o cain ja configura tudo automatimente.

6. Botão Base 64 password decoder

Serve para encontrar senhas criptografadas em Base 64. Baste colocar a senha.

7. Botão Access database password decoder

encontrar senhas de banco de dados Access. Basta selecionar o arquivo e o tipo.

8. Botões da CISCO

O primeiro serve para encontrar senhas do type-7 colocando a senha e outro do VPN Cient, colocando o arquivo. Esses botões não tem muito o que comentar…

9. Outros Botões de Password Decoder

Basta apenas colocar o password ou o arquivo e pronto. Como disse não tem muito o que comentar. A partir daqui irei comentar somente o necessário, ok?

10. Box Revelator

Lembram do programinha chamado revelator que mostrava o conteúdo dos ******* das caixas de senhas? Pois bem, é ele revisado.

11. Hash Calculator

Você digita o que quer e ele mostrará ele em hash. È necessário quando você precisa saber um hash especifico ou fazer um teste.

12. RSA

Também não explicarei este. Pessoal, meu tempo é curto e este item daria muito trabalho. =)

13. Guias

Já expliquei os principais botões. Agora os guias, que é o que falta.

13.1 Protected Storeg

Ele pega no registro senhas dos seguintes programas(se estiverem armazenadas no registro):
- MS Outlook 2002′s passwords(POP3, SMTP, IMAP, HTTP)
- Outlook Express’s passwords(POP3, NNTP, SMTP, IMAP, HTTP, LDAP, HTTP-Mail)
- Outlook Express Identities
- MS Outlook’s passwords (POP3, NNTP, SMTP, IMAP, LDAP, HTTP-Mail)
- MSN Explorer’s Sign In passwords
- MSN Explorer’s Auto Complete passwords
- Internet Explorer’s protected sites passwords
- Internet Explorer’s Auto complete passwords

Basta clicar no botão +.

13.2 Network

Mostra detalhes da rede. Observe você mesmo.

13.3 LSA Secrets

também pega do registro senhas usadas para iniciar serviços como senhas do arquivo SAM. Clique no Botão +.

13.4 programa

Quando você obtem senhas criptografadas você pode clicar com o botão direito e colocar “send to Programa”. Lá ele divide os passwords e faz a encontrar através de alguns tipo de força bruta, ataque de dicionário, criptoanílise(Você verificar em uma rainbow table feita no wintrgen) ou rainbowcrack-online.

13.5 Traceroute

É o tracert do windows ou traceroute do linux com mais opções.

13.6 CCDU (Cisco COnfig Downloader)

Configurações CISCO. Para usuários mais avaçados.

13.7 Wireless

Através de um dispositivo wireless varre por redes sem fio.

Abraços,
Ranieri Marinho de Souza
Segurança da Informação

http://www.segr.com.br/
http://blog.segr.com.br/

Introdução:

Kerberos é um protocolo desenvolvido para fornecer poderosa autenticação em aplicações usuário/servidor, onde ele funciona como a terceira parte neste processo, oferendo autenticação ao usuário.

Para garantir a segurança, ele usa criptografia de chave simétrica, com o DES.

O Kerberos foi desenvolvido como parte do Project Athena, do Massachussets Institute of Technology (MIT). Seu nome vem da mitologia, onde Cerberus (Kerberus para os gregos) é um cão com três cabeças que tem por missão proteger a entrada do inferno de Hades.

O que faz o Kerberos:

Para explicar o que faz o Kerberos, vamos usar algumas analogias baseadas The Moron’s Guide to Kerberos, Version 1.2.2.

Na vida real, usamos rotineiramente uma autenticação, na forma de (por exemplo) uma carteira de motorista. A carteira de motorista é fornecida por uma agência, na qual podemos supor confiável, e contém dados pessoais da pessoa como nome, endereço e data de nascimento. Além disto pode conter algumas restrições, como necessidade de óculos para dirigir, e mesmo algumas restrições implícitas (a data de nascimento pode ser usada para comprovar maioridade). Finalmente, a identificação tem um prazo de validade, a partir do qual é considerada inválida.

Para ser aceita como autenticação, algumas regras devem ser observadas: ao apresentar a carteira, não se pode ocultar parte dela (como foto ou data de nascimento). Além disto, quem verifica a autenticação deve reconhecer a agência que forneceu a autenticação como válida (uma carteira de motorista emitida no Brasil pode não ser aceita fora do território nacional).

Kerberos trabalha basicamente da mesma maneira. Ele é tipicamente usado quando um usuário em uma rede tenta fazer uso de um determinado serviço da rede e o serviço quer se assegurar de que o usuário é realmente quem ele diz que é. Para isto, o usuário apresenta um ticket, fornecido pelo Kerberos authenticator server (AS), assim como a carteira de motorista é fornecida pelo DETRAN. O serviço então examina o ticket para verificar a identidade do usuário. Se tudo estiver ok o usuário é aceito.

O ticket deve conter informações que garantam a identidade do usuário. Como usuário e serviço não ficam face a face uma foto não se aplica. O ticket deve demonstrar que o portador sabe alguma coisa que somente o verdadeiro usuário saberia, como uma senha. Além disto, devem existir mecanismo de segurança contra um atacante que “pegue” um ticket e use mais tarde.

Explicando como funciona:

Vejamos como o Kerberos trabalha. Usuários e serviços que utilizem o Kerberos possuem chaves armazenadas no AS. As chaves dos usuários são derivadas de senhas escolhidas por estes, e as chaves dos serviços são geradas aleatoriamente.

Para esta explicação, imaginemos que as mensagens são escritas em papel, e são criptografadas colocando-as em uma caixa-forte, associada a uma chave.

Primeiro o usuário envia uma mensagem ao AS: “Eu, J. Random User, gostaria de falar com o servidor Foo”.
Quando o AS recebe a mensagem, ele faz duas cópias de uma nova chave registrada. Estas chaves são chamadas de chaves de sessão. Elas serão usadas nas trocas diretas entre serviço e usuário.
Ele coloca uma das chaves de sessão na Caixa 1, junto com um pedaço de papel com o nome “Servidor Foo” escrito. A caixa é trancada com a chave do usuário (o AS conhece todas as chaves de usuário e todas as chaves de serviço).
Por que este papel aqui? Devemos nos lembra que a caixa é na realidade apenas uma mensagem criptografada, e que a chave de sessão é uma seqüência randômica de bytes. Se a Caixa 1 somente contivesse a chave de sessão, o usuário não teria como reconhecer se a resposta veio do AS, ou não saberia se a decriptação teve sucesso. Pela adição da mensagem “Servidor Foo”, o usuário (mais precisamente a aplicação do usuário) poderia saber se a caixa veio do AS, e se a decriptação obteve sucesso.
Ele coloca a outra chave de sessão em uma Caixa 2, junto com um pedaço de papel com o nome “J. Random User”. Esta caixa é fechada com a chave do serviço.
Ele envia ambas as caixas ao usuário.
Na versão 4 do Kerberos, a Caixa 2 era colocada (sem necessidade) dentro da caixa 1, mas na versão 5 isto foi corrigido.
O usuário destranca a Caixa 1 com sua chave, extraindo assim a chave de sessão e o papel com o nome “Servidor Foo” escrito nele.
O usuário não consegue abrir a Caixa 2 (ela foi trancada com a chave do serviço, que só o AS e o serviço conhecem). Então ele coloca um pedaço de papel com a hora corrente numa Caixa 3, e tranca esta com chave de sessão, e envia ambas ao serviço.
O serviço abre a Caixa 2 com sua própria chave, extraindo a chave de sessão e o papel com “J. Random User” escrito nele. Ele abre a Caixa 3 com a chave de sessão para extrair o pedaço de papel com a hora corrente nele. Estes itens demonstram a identidade do usuário.
O timestamp é colocado na Caixa 3 para prevenir que alguém faça uma cópia da Caixa 2 (devemos nos lembrar que as caixas são na verdade mensagens eletrônicas) e a utilize para se passar pelo usuário mais tarde. Como os relógios da rede nunca são perfeitamente sincronizados, uma pequena margem (em geral 5 minutos) é permitida entre o timestamp e a hora atual. Além disto, o serviço mantém um lista das autenticações recebidas recentemente para garantir que elas não foram reenviadas.

A chave de serviço é gerada aleatoriamente e armazenada em um arquivo especial chamado de SECRETE KEY FILE. O Kerberos assume que este é seguro, que ninguém pode copiá-lo e se passar pelo serviço.

No Kerberos, a Caixa 2 é chamada de ticket, e a Caixa 3 de authenticator. O authenticator tipicamente contém mais informações do que as listadas acima. Algumas destas informações são adicionadas em decorrência do fato de que as mensagens são eletrônicas (por exemplo, existem checksum). Pode existir também uma chave secreta usada para criptografar as mensagens que serão trocadas entre usuário e serviço após a autenticação, garantindo assim a privacidade.

Autenticação de serviço:

Algumas vezes o usuário pode querer o serviço seja autenticado no retorno. Para isto, o serviço pega o timestamp do authenticator (Caixa 3), acrescenta um ao seu valor, coloca em uma Caixa 4, junto com um pedaço de papel com o nome “Servidor Foo” escrito nele, tranca esta caixa com a chave de sessão e envia de volta ao usuário. Ao receber a Caixa 4, o usuário abre com a chave de sessão, e verifica o timestamp. Se for maior que o enviado, significa que o serviço conseguiu abrir a Caixa 2 (decriptografar o ticket).

Isto acontece na versão 4 do Kerberos. Na versão 5 o serviço faz mais que somente adicionar uma unidade ao timestamp.

O Ticket Granting Server:

Existe um problema no esquema apresentado acima. Ele será usado toda vez que o usuário requisitar um serviço, e a cada vez que isto acontecer ele terá que entrar com sua senha (destrancar a Caixa 1 com a chave do usuário). Uma primeira solução seria armazenar a chave do usuário gerada a partir da sua senha. Mas armazenar a chave do usuário é muito perigoso, pois com uma cópia desta um invasor se passaria pelo usuário até que sua senha fosse modificada.

O Kerberos resolve este problema introduzindo um novo agente chamado de ticket granting server (TGS). O TGS é logicamente distinto do AS, mas eles podem residir na mesma maquina. A função do TGS é a seguinte: antes de acessar qualquer serviço, o usuário requisita um ticket para contatar o TGS, como se ele fosse um serviço qualquer. Este ticket é chamado de ticket granting ticket (TGT).

Depois de receber o TGT, a qualquer momento que o usuário desejar requisitar um serviço, ele irá requerer um ticket não mais do AS, mais sim do TGS. Além disto, a resposta não será criptografada com a chave secreta do usuário, mas sim com a chave de sessão providenciada pelo AS para ser usada entre usuário e TGS. O conteúdo desta resposta é uma chave de sessão que será usada com o serviço regular. O resto da comunicação continua como descrito acima.

Este mecanismo funciona de maneira semelhante a um visitante num local de trabalho. Você mostra sua identificação( pode ser a carteira de motorista) e recebe uma identificação de visitante. Agora quando quiser entrar numa das várias salas, ao invés de apresentar sua identificação oficial a cada sala (corre-se o risco de ter a identidade perdida ou roubada), basta mostrar a identidade de visitante. Se sua identidade de visitante for perdida ou roubada, você poderá torna-la invalida e substituí-la rapidamente e com facilidade, algo que não acontece com sua carteira de motorista.

A vantagem é que enquanto senhas usualmente são válidas por meses, O TGT é válido somente por um curto período de tempo, tipicamente 8 horas. Depois deste tempo, o TGT não pode ser usado por ninguém, nem usuário nem invasor. Este TGT, como qualquer ticket que o usuário obtém é armazenado no credentials cache. Existe um número de comandos que permitem ao usuário manipular seu próprio credentials cache.

Cross Realm Authentication:

Um único AS e um único TGS funcionam bem se o número de requisições for pequeno, mas com o crescimento da rede, cresce o número de requisições de serviços, e o AS/TGS passa a ser um gargalo no processo de autenticação. Em outras palavras pode-se dizer que o sistema não esta escalado, o que é muito ruim para um sistema distribuído como o Kerberos.

Entretanto o Kerberos oferece a vantagem de se dividir a rede em realms. Esta divisão muitas vezes é feita sobre limites organizacionais. Cada realm tem seu próprio AS e seu TGS.

Para realizar uma cross-realm authenticathion (o usuário em um realm acessa um serviço noutro realm) é necessário primeiro que o realm do usuário registre um remote TGS (RTGS) no realm do serviço.

Note que quando o TGS foi adicionado, uma comunicação a mais foi somada ao protocolo. Aqui uma outra comunicação foi adicionada: primeiro o usuário contata o AS para acessar o TGS, então ele contata o TGS para acessar o RTGS. Finalmente ele contata o RTGS para acessar o serviço.

Em muitos casos, onde coexistem muitos realms, é ineficiente registrar cada realm em cada outro realm. Para evitar isto, a versão 5 do Kerberos permite uma hierarquia de realms, de maneira que para contatar um serviço num outro realm, pode ser necessário contatar RTGS em um ou mais realms imediatos. O nome de cada um destes realms é gravado no ticket.

Como utilizar o Kerberos:

Para o usuário:

Para o usuário utilizar o Kerberos, primeiro ele deve estabelecer um Kerberos principal. Um Kerberos principal é algo parecido com uma conta em uma máquina. O nome do principal é do tipo your_name@YOUR.REALM. A parte antes de @ é uma string você escolhe (normalmente é a mesma coisa que seu login name). A parte posterior é o nome do realm.

Associado a cada principal existe um nome, uma senha e algumas outras informações. Estes dados são armazenados na base de dados do Kerberos. Esta base de dados é criptografada com uma chave mestra do Kerberos, pode ser replicada para servidores escravos, e ela não pode ser examinada por qualquer um.

Para o usuário, o Kerberos é quase transparente. Existe um número de serviços setados para requerer autenticação via Kerberos. Para usar um destes serviços, o usuário precisa obter um TGT primeiro. O comando para isto é kinit:

% kinit
Password for your_name@YOUR.RELAM
Quando o usuário entrar sua senha, o programa kinit fará uma requisição ao AS para contatar o TGS. A senha será usada para computar a chave secreta do usuário (observe que a senha será digitada apenas uma vez e não trafegará pela rede), que será usada para decriptar parte da resposta do AS (a parte que contém a confirmação da requisição e a chave de sessão). Se a senha estiver correta, o usuário terá um TGT. Pode-se verificar isto usando o comando klist:

% klist
Ticket cache: /var/tmp/krb5cc_1234
Default principal: your_name@YOUR.REALM
Valid starting
Expires
Service principal
24-Jul-95 12:58:02
24-Jul-95 20:58:02
krbtgt/YOUR.REALM @YOUR.REAL
O campo Ticekt cache mostra qual arquivo contém as credenciais do usuário. O principal default é aquele fornecido pelo TGT. A saída é uma lista dos ticket existentes, Assim se o usuário apenas requisitou o TGT, este será o único ticket e o único principal será do serviço o do TGS (krbtgt). Pode-se observar que os ticket são válidos por um determinado período de tempo, neste caso 8 horas.

Se o usuário estiver usando uma versão kerberizada do rlogin, este programa irá usar o TGT do credentials cache para requisitar um ticket para o rlogin daemon na máquina em que está logado. Isto acontece automaticamente como pode-se notar abaixo:

% rlogin newhost.domain
last login: Fri 21 12:04:40 from …
A única maneira de se notar a diferença é listando o credentials cache:

% klist
Ticket cache: /var/tmp/krb5cc_1234
Default principal: your_name@YOUR.REALM
Valid starting
Expires
Service principal
24-Jul-95 12:58:02
24-Jul-95 20:58:02
krbtgt/YOUR.REALM @YOUR.REALM
24-Jul-95 13:03:33
24-Jul-95 21:03:33
host/newhost.domain @YOUR.REALM
O significado do Service principal é o seguinte: A primeira parte, antes da barra, é o nome do principal. A Segunda parte, entre a barra e o @ é chamado de instance. Para serviços é normalmente o hostname da máquina onde o serviço está sendo executado, no caso de serviços do Kerberos (como kinit) ele é o nome do realm. Para usuários, normalmente é nulo (neste caso não existe nem a barra), ou quando o usuário acessa algum serviço privilegiado, existe uma indicação disto ( como your_name/admin ou your_name/secure). O último componente, após o @ é o nome do realm.

Por default, o rlogin deixa qualquer ticket que ele tenha obtido no cache. Isto não é um problema de segurança, a menos que alguém tenha acesso ao terminal em que o usuário esteja logado,

Caso o usuário não deseje deixar os credentials no cache, ele pode destruí-los usando o comando kdestroy:

% kdestroy
% klist
klist: No credentials cache file found while setting cache flags
(ticket cache /var/temp/krbrcc_1234)
O comando kdestroy remove todos os ticket (incluindo o TGT) do cache.

Para o administrador:

Para o administrador a coisa é um pouco mais complexa. O AS e o TGS (normalmente o mesmo executável) devem ser configurados e iniciados. Principals devem ser registrados, e o mais importante, os serviços devem ser disponibilizados para uso do Kerberos.

Inicializando o servidor Kerberos: Tipicamente, o administrador deve seguir os seguintes passos para inicializar o servidor Kerberos:

Instalar os arquivos binários. Clientes podem ser colocados em um diretório comum. Certos binários (como ksu e todos os root processes) devem instalados pelo root para funcionarem corretamente. Em geral, make install da fonte de instalação fará tudo para o administrador.
Editar o arquivo krb5.conf. Este arquivo contém as opções de configuração para os clientes, como onde estão todos os KDC’s, qual KDC é local, quais maquinas pertencem a quais realms, etc..
Editar o arquivo /.k5login. Cada linha consiste de um único nome de principal, que indica os direitos para o ksu. Ele é apenas uma lista de controle de acesso.
Editar o arquivo /etc/services.
Editar o arquivo /etc/inetd.conf. Idealmente todos os serviços devem estar fora do ar. Existem algumas versões Kerberizadas de comandos BSD que podem ser incluídos. Para fazer com que o daemon passe a responder esta nova versão deste arquivo, o administrador pode encontrar o inetd do processo e enviar o comando kill –HUP para o processo.
Editar o arquivo /etc/rc., adicionando linhas para fazer com que os daemons krb5kdc e kadmin sejam iniciados quando a máquina é bootada.
Criar a base de dados
Adicionar entradas para usuários e serviços.
Executar os servidores krb5kdc e kadmin em background. Eles farão isto por default a partir disto.
Registrando principals: Uma vez inicializada a base de dados, pode-se executar o kadmin para adicionar principals.

Kerberizando aplicações: Esta é a parte mais difícil do uso do Kerberos. Reconstruir uma aplicação para que ela passe a usar o Kerberos é chamado de kerberizar a aplicação. A aplicação kerberizada deve:

Encontrar a identidade do usuário.
Localizar o cache de credentials do usuário.
Checar para ver se existe um ticket para o serviço requisitado.
Se não existir, usar o TGT e a chave de sessão para enviar uma requisição para obter um.
Isto nem sempre é uma programação trivial. Entretanto existem aplicações pré-kerberizadas como POP e R-comandos Berkeley (por exemplo rlogin).

Limitações do Kerberos:

O Kerberos é bastante adequado para aplicações usuário/servidor e não ponto a ponto.
Como o cachemento das chaves, ticket e principals são feitos no diretório /tmp, é necessário que as estações de trabalho sejam seguras.
Apresenta problemas com multi-homed hosts, que utilizam mais de um endereço IP.
Os relógios devem estar sincronizados (em geral a diferença não pode ultrapassar cinco minutos) devido ao timestamp.
É vulnerável contra senhas fracas, possibilitando que um invasor intercepte uma mensagem e utilize um ataque dicionário para descobrir a senha do usuário.
Existe a possibilidade de modificação, por um atacante, das aplicações kerberizadas.
Bibliografia

TUNG, BRYAN – “The Moron’s Guide to Kerberos, Version 1.2.2″ .
NEUMAN, B. CLIFFORD e TS’O, THEODORE – “Keberos: An Authentication Service For Computer Networks” IEEE Communications Magazine, Volume 32, No 9, pag. 33-38, Set 1994.
NEUMAN, B. CLIFFORD e STUBBLEBINE, G. STUART – “A Note on the use of Timestamps as Nonces”.
NEUMAN, B. CLIFFORD – “Protection and Security Inssues for Future Systems”.
RFC 1510.
NUNES, ANTÔNIO CARLOS NUNES e CARLE, EMERSON – “RSA: um método seguro de criptografia?”.
RIVEST, R. L. e SHAMIR, A. e ADLEMAN, L. – “A methode of obtaining digital signatures and public-key criptosystems”.
BELLOVIN, M. STEVEN e MERRITT, MICHAEL – “Limitations of the Kerberos Authentication System”.
NAKAMURA, EMILIO T. – “Kerberos Um seviço de Autenticação para redes de computadores”. UNICAMP Trabalho para a disciplina Tópicos de Computadores II.

Abraços,
Ranieri Marinho de Souza
http://www.segr.com.br

O que é o Nagios?
Nagios é um sistema de monitoração das aplicações de rede. Ele vigia hosts e serviços que você especificar, alertando quando o serviço ou host ficar em “down” e também quando os mesmos ficarem em “up”. Uma ação pró-ativa.

Está ferramenta é a evolução do NetSaint. Mesmo o site do NetSaint estando ainda no ar, todos os novos desenvolvimentos serão feitos para o Nagios.

Lista de características do Nagios:

- Monitoração de serviços de rede como HTTP, SMTP, SSH, Telnet, etc. – Monitoração dos recursos dos servidores, como espaço em disco. – Notificações de falhas por e-mail, pager, etc, em tempo real. – Interface Web informativa, que podemos identificar de maneira fácil os problemas.

Nagios roda no Unix e seus variantes, opcionalmente requer um servidor web to ser instalado (para a interface web de monitoração)

[editar] Instalação e Configuração do Nagios
1° – Faça o download do último pacote do Nagios e o último pacote dos Plugins, para um diretório temporário. Nesse tutorial usaremos /tmp/nagios.

root@nagios:/tmp/nagios# ls
nagios-1.0b6.tar.gz nagiosplug-1.3.0-beta3.tar.gz
Primeiro nós iremos instalar o gerenciador de aplicações Nagios. Vamos descomprimir o arquivo tar.gz

root@nagios:/tmp/nagios# tar xvzf nagios-1.0b6.tar.gz
Depois de descomprimido o arquivo tar.gz, iremos para o diretório nagios-1.0b6.

root@nagios:/tmp/nagios# cd nagios-1.0b6
root@nagios:/tmp/nagios/nagios-1.0b6#
Agora precisamos decidir a onde iremos instalar o nosso sistema. Você pode instalar o Nagios em qualquer lugar, mas o melhor é instalar na localização padrão (/usr/local/nagios), porque a documentação original sempre se refere para ele. Dessa forma será fácil resolver problemas que possam acontecer.

Crie o diretório a onde você gostaria de instalar o Nagios.

root@nagios:/tmp/nagios/nagios-1.0b6# mkdir /usr/local/nagios
Neste ponto, precisamos criar um usuário e grupo que o Nagios irá usar para carregar o serviço. Você pode usar o “root” para isto, mas não é recomendado como segurança. Em geral para uma fácil manutenção, decidi dedicar um novo usuário e grupo para essa função. O usuário e grupo terão o nome de “nagios”.

root@nagios:/tmp/nagios/nagios-1.0b6# useradd nagios
root@nagios:/tmp/nagios/nagios-1.0b6# groupadd nagios
Uma vez criado o usuário e o grupo, nos podemos iniciar o processo de instalação. Primeiro precisamos especificar alguns parâmetros e criar o Makefile que será usado para compilar e instalar o software.

root@nagios:/tmp/nagios/nagios-1.0b6# ./configure –prefix=/usr/local/nagios –with-cgiurl=/nagios/cgi-bin –with-htmurl=/nagios/ –with-nagios-user=nagios –with-nagios-grp=nagios
Geralmente quando instalamos o Nagios no diretório padrão (/usr/local/nagios) não precisamos utilizar todos os parâmetros acima, mas é sempre bom direcionar para o lugar correto.

Uma vez a configuração completa, irá aparecer um sumário de todos os parâmetros que foram usados durante a configuração. Tenha certeza que tudo está OK, senão execute o “configure” novamente com as opções corretas.

Existe também uma alta probabilidade de aparecer um aviso que a biblioteca GD está faltando. Consulte o site da Boutell (http://www.boutell.com/) para instalar essa biblioteca, e execute o “configure” novamente com a opção –with-gd-lib e –with-gd-inc para especificar o exato diretório da biblioteca GD. Caso não funcione não se preocupe, o Nagios funcionará mesmo sem essa biblioteca. Essa biblioteca é somente usada em alguns CGI´s que criam imagens dinâmicas para a estatística de serviço. A aplicação é ainda muito útil sem estes gráficos.

Agora iremos compilar o software. Usaremos as seguintes opções (se você não estiver logado com o root, se logue agora).

root@nagios:/tmp/nagios/nagios-1.0b6# make all
Se durante o longo processo de compilação não acontecer nenhum erro, receberemos a mensagem “Compile Finished” no final da compilação.

Iremos executar três comandos para instalar vários componentes nos seus devidos lugares. Primeiro iremos instalar o programa principal, arquivos e diretórios no /usr/local/nagios.

root@nagios:/tmp/nagios/nagios-1.0b6# make install
Vamos agora instalar o script de inicialização para que o Nagios seja carregado automaticamente durante o boot.

Esse script permite também que utilizemos a opção start, stop, restart e reload. Exemplo: service nagios start

root@nagios:/tmp/nagios/nagios-1.0b6# make install-init
No meu sistema (Red Hat 8.0) eu coloquei o script no diretório /etc/rc.d/init.d

Se você der uma olhada dentro do diretório /usr/local/nagios você verá que existem quatro diretórios.

root@nagios:/tmp/nagios/nagios-1.0b6# ls /usr/local/nagios
bin sbin share var
O diretório bin contém um simples arquivo chamado nagios, que é o centro dos pacotes. Este aplicação não é atualmente monitorada. O diretório sbin contém o CGI script que será usado na interface web. Dentro do diretório share você encontrará o HTML a documentação. E finalmente o diretório var é onde o Nagios armazenará informações quando iniciado.

Em geral para você habilitar o uso do Nagios, você precisa de um conjunto de arquivos de configuração. Estes arquivos estão dentro do diretório etc no qual será criado quando você executar o seguinte comando.

root@nagios:/tmp/nagios/nagios-1.0b6# make install-config
[editar] Instalação dos Plugins
Nesse ponto a instalação do Nagios está completa, mas ele não está com suas totais funções, falta a monitoração das aplicações. Esta função é responsável por checar se um particular serviço está funcionando. Para habilitarmos essa função é necessário instalar os Plugins separadamente. Faça o download da última versão dos Plugins no site do Nagios www.nagios.org.

Depois do download, faça a descompactação do arquivo e entre no diretório criado pelo comando “tar”.

root@nagios:/tmp/nagios/nagiosplug-1.3-beta3# ./configure –prefix=/usr/local/nagios –with-nagios-user=nagios –with-nagios-group=nagios
Você talvez notificações sobre a perda de problemas ou módulos Per enquanto esteja executando o configure.

Não tem problema, a menos que você especifique uma aplicação que necessite desses módulos.

Uma vez terminado a configuração, compile todos os Plugins.

root@nagios:/tmp/nagios/nagiosplug-1.3-beta3# make all
Se nenhum erro for reportado, você pode instalar os Plugins.

root@nagios:/tmp/nagios/nagiosplug-1.3-beta3# make install
Os Plugins serão instalados no diretório “ibexec” dentro do diretório do Nagios /usr/local/nagios/libexec.

Entre nesse diretório, depois execute ./check_ssh -h para saber como o “check_ssh” trabalha.

Usando esses comandos você pode rodar manualmente a checagem de qualquer serviço, mas iremos automatizar o nosso processo.

Por exemplo: root@nagios:/usr/local/nagios/libexec# ./check_ssh 200.146.2.1 (IP ilustrativo)
SSH ok – protocol version 1.99 – server version
[editar]Configuração do Nagios
Depois da instalação do Nagios e dos Plugins nós estamos quase prontos para iniciar a monitoração dos nossos servidores, mas antes precisamos configurar alguns arquivos.

root@nagios:/tmp/nagios/nagiosplug-1.3-beta3# cd /usr/local/nagios/etc
root@nagios:/usr/local/nagios/etc# ls
O comando “ls” irá mostrar todos os arquivos *.cfg-sample, precisamos renomear esses arquivos para *.cfg

Criem um diretório “sample” e copie todos os arquivos *.cfg-sample para esse diretório, uma cópia de segurança, em seguida renomeie todos os arquivos *.cfg-sample para *.cfg

Como a nossa configuração é simples e não iremos entrar em maiores detalhes, apague os arquivos “dependencies.cfg e escalation.cfg” e iremos criar dois arquivos em branco para substituir os mesmos.

root@nagios:/usr/local/nagios/etc# touch dependencies.cfg
root@nagios:/usr/local/nagios/etc# touch escalations.cfg
Conteúdo do arquivo hosts.cfg

No arquivo hosts.cfg devemos colocar os servidores que desejamos monitorar. Edite o arquivo hosts.cfg com o seu editor preferido.

Exemplo:

root@nagios:/usr/local/nagios/etc# vi hosts.cfg
# ‘servidor1′ host definition
define host{
use generic-host ; Name of host template to use
host_name 9; servidor1
alias 9; Web Server #1
address 192.168.0.1
check_command check-host-alive
max_check_attempts 5
notification_interval 1
notification_period 24×7
notification_options d,u,r
}
Para cada “host” você irá criar um conjunto das linhas acima, identificando o “hostname” do servidor e o “IP address”

Conteúdo do arquivo “hostgroup.cfg”

Edite o arquivo hostgroup.cfg, uso o seu editor preferido.

Exemplo:

root@nagios:/usr/local/nagios/etc# vi hostgroup.cfg
# ‘email-servers’ host group definition
define hostgroup{
hostgroup_name http-servers
alias 9; Web Servers
contact_groups http-admins
members servidor1, servidor2
}
Agora necessitamos adicionar os hosts para o hostgroup usando o arquivo acima.

Acima nós definimos um novo “hostgroup” e associamos o “http-admins” grupo de contato para ele. Agora iremos ver o arquivo “contactgroup.

Conteúdo do arquivo “contactgroup.cfg”

# ‘http-admins’ contact group definition
define contactgroup{
contactgroup_name http-admins
alias 9; Web Administrators
members User,leonardo
}
Nós definimos o grupo de contato “http-admins” e adicionamos dois members “jose” e “leonardo” para este grupo. Estas configurações asseguram que ambos os usuários serão notificados quando alguma coisa errada acontecer com os servidores que as pessoas do grupo “http-admins” são responsáveis.

A próxima etapa será configurarmos as informações dos contatos e notificações para estes usuários.

Conteúdo do arquivo “contacts.cfg”

# ‘User’ contact definition
define contact{
contact_name User
alias 9; User Rebello
service_notification_period 24×7
host_notification_period 24×7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email 9; User@nssecurity.com.br
}

# ‘leonardo’ contact definition
define contact{
contact_name leonardo
alias 9; Leonardo
service_notification_period 24×7
host_notification_period 24×7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email 9; leonardo@nssecurity.com.br
}
Para criarmos os detalhes dos usuários o arquivo é o contacts.cfg, conforme exemplo acima.

Depois de criado os hosts, grupo dos hosts, contatos e grupos dos contatos, iremos identificar qual o serviço que queremos gerenciar em cada host.

No exemplo abaixo, estamos habilitando o gerenciamento através do PING, para saber se o servidor está no ar, e do serviço HTTP para sabermos se o serviço Web está funcionando corretamente.

Conteúdo do arquivo “services.cfg”

# Service definition
define service{
use generic-service ; Name of service template to use
host_name 9; servidor1
service_description HTTP
is_volatile 0
check_period 24×7
max_check_attempts 3
normal_check_interval 1
retry_check_interval 1
contact_groups http-admins
notification_interval 2
notification_period 24×7
notification_options w,u,c,r
check_command check_http
}

# Service definition
define service{
use generic-service ; Name of service template to use
host_name 9; servidor1
service_description PING
is_volatile 0
check_period 24×7
max_check_attempts 5
normal_check_interval 1
retry_check_interval 1
contact_groups http-admins
notification_interval 2
notification_period 24×7
notification_options c,r
check_command check_ping!100.0,20%!500.0,60%
}

Agora que terminamos a configuração dos hosts, contatos e serviços, podemos iniciar o serviço do Nagios para iniciarmos a monitoração dos nossos servidores.

Por experiência própria com o Red Hat 8.0, carregue o serviço com a opção “reload” e não “start”. Ainda não sei porque, mas a opção “start” quando carregada a primeira vez acontece alguns erros que não permiti carregar o serviço.

[editar]Interface Web
Bem, embora o Nagios esteja iniciado e monitorando os nossos servidores e enviando notificações por e-mail (O seu MTA deverá estar configurado corretamente para enviar mensagens) quando ocorrer algum problema, é muito válido configurarmos a interface web para uma melhor interação com essa monitoração.

Para isso precisamos ter um Web Server instalado na máquina que o Nagios esteja instalado. O nosso exemplo será utilizando o Apache, pois é um dos mais utilizados Web Servers no mundo inteiro.

Arquivo /etc/httpd/conf/httpd.conf

Adicione as linhas abaixo no final do seu arquivo httpd.conf

ScriptAlias /nagios/cgi-bin/ /usr/local/nagios/sbin
AllowOverride AuthConfig
Options ExecCGI
Order allow,deny
Allow from all
Alias /nagios/ /usr/local/nagios/share/
Options None
AllowOverride AuthConfig
Order allow,deny
Allow from all
Está configuração cria um alias “/nagios/cgi-bin/” e direciona ele para um script CGI no diretório “sbin” do Nagios. Dessa forma podemos carregar a interface web do Nagios, assumindo que a página principal do seu web server está em http://localhost, digitando no nosso browser http://localhost/nagios.

Mas ainda não carrega a página do Nagios, pois ainda não criamos os usuários que podem acessa-lo.

Crie um arquivo “.htaccess” no diretório “/usr/local/nagios/sbin” com o seguinte conteúdo:

AuthName “Nagios Access”
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
require valid-user
Não esqueça de criar o arquivo com atributo de oculto, com um “ponto” antes do nome do arquivo.

Agora precisamos criar os usuários e as suas respectivas senhas, execute o seguinte comando:

htpasswd –c /usr/local/nagios/etc/htpasswd.user User
New password: *****
Re-type new password: *****
Adding password for user jose

Para criar outros usuários você não deve utilizar o parâmetro “-c”, pois ele é utilizado para criar o arquivo htpasswd.user se o mesmo não existir. Se você utilizar o parâmetro “-c” e o arquivo já existir, o mesmo será substituido.

Ótimo, agora você poderá entrar na interface web do Nagios para monitorar online todos os serviços dos seus servidores.

Uma dica muito importante, todos os acessos aos scripts CGI, são controlados pelo arquivo “/usr/local/nagios/etc/cgi.cfg”. Lá você determina o que cada usuário pode acessar.

Pronto o seu software de monitoração de hosts e serviços está funcionando, para controle de mais serviços, aconselho você entrar no diretório “/usr/local/nagios/libexec” e testar os scripts (./check_ftp -h).

Site Oficial Nagios – http://www.nagios.org

Site Oficial NetSaint – http://www.netsaint.org

Nagios Plugins – http://nagiosplug.sourceforge.net

Abraços,
Ranieri Marinho de Souza
Segurança da Informação

http://www.segr.com.br/
http://blog.segr.com.br/

Autor: Gabriel Torres e Cássio Lima

Introdução

O TCP/IP é o protocolo de rede mais usado atualmente. Neste tutorial explicaremos como este protocolo funciona em uma linguagem fácil de entender.
Mas, afinal, o que é um protocolo de rede? Um protocolo é uma linguagem usada para permitir que dois ou mais computadores se comuniquem. Assim como acontece no mundo real, se eles não falarem a mesma língua eles não podem se comunicar.

O TCP/IP não é na verdade um protocolo, mas sim um conjunto de protocolos – uma pilha de protocolos, como ele é mais chamado. Seu nome, por exemplo, já faz referência a dois protocolos diferentes, o TCP (Transmission Control Protocol, Protocolo de Controle de Transmissão) e o IP (Internet Protocol, Protocolo de Internet). Existem muitos outros protocolos que compõem a pilha TCP/IP, como o FTP, o HTTP, o SMTP e o UDP – só para citarmos alguns. Não se preocupe por enquanto pois explicaremos tudo o que você precisa saber sobre esses protocolos.

O TCP/IP tem quatro camadas. Os programas se comunicam com a camada de Aplicação. Na camada de Aplicação você encontrará os protocolos de aplicação tais como o SMTP (para e-mail), o FTP (para a transferência de arquivos) e o HTTP (para navegação web). Cada tipo de programa se comunica com um protocolo de aplicação diferente, dependendo da finalidade do programa.

Após processar a requisição do programa, o protocolo na camada de Aplicação se comunicará com um outro protocolo na camada de Transporte, normalmente o TCP. Esta camada é responsável por pegar os dados enviados pela camada superior, dividi-los em pacotes e enviá-los para a camada imediatamente inferior, a camada Internet. Além disso, durante a recepção dos dados, esta camada é responsável por colocar os pacotes recebidos da rede em ordem (já que eles podem chegar fora de ordem) e também verificam se o conteúdo dos pacotes está intacto.

Na camada Internet nós temos o IP (Internet Protocol, Protocolo Internet), que pega os pacotes recebidos da camada de Transporte e adiciona informações de endereçamento virtual, isto é, adiciona o endereço do computador que está enviando os dados e o endereço do computador que receberá os dados. Esses endereços virtuais são chamados endereços IP. Em seguida os pacotes são enviados para a camada imediatamente inferior, a camada Interface com a Rede. Nesta camada os pacotes são chamados datagramas.

A camada Interface com a Rede receberá os pacotes enviados pela camada Internet e os enviará para a rede (ou receberá os dados da rede, caso o computador esteja recebendo dados). O que está dentro desta camada dependerá do tipo de rede que seu computador estiver usando. Atualmente praticamente todos os computadores utilizam um tipo de rede chamado Ethernet (que está disponível em diferentes velocidades; as redes sem fio também são redes Ethernet) e, portanto, você deve encontrar na camada Interface com a Rede as camadas do Ethernet, que são Controle do Link Lógico (LLC), Controle de Acesso ao Meio (MAC) e Física, listadas de cima para baixo. Os pacotes transmitidos pela rede são chamados quadros.
Vamos falar agora em mais detalhes sobre as camadas e os protocolos do TCP/IP.

Camada de Aplicação
Esta camada faz a comunicação entre os programas e os protocolos de transporte. Existem vários protocolos que operam na camada de aplicação. Os mais conhecidos são o HTTP (HyperText Transfer Protocol, Protocolo de Transferência Hipertexto), o SMTP (Simple Mail Transfer Protocol, Protocolo Simples de Transferência de Correspondência), o FTP (File Transfer Protocol, Protoloco de Transferência de Arquivos), o SNMP (Simple Network Management Protocol, Protocolo Simples de Gerenciamento de Redes), o DNS (Domain Name System, Sistema de Nome de Domínio) e o Telnet. Você já deve ter ouvido falar nesses nomes antes.

Quando um programa cliente de e-mail quer baixar os e-mails que estão armazenados no servidor de e-mail, ele efetuará esse pedido para a camada de aplicação do TCP/IP, sendo atendido pelo protocolo SMTP. Quando você entra um endereço www em seu navegador para visualizar uma página na Internet, ele se comunicará com a camada de aplicação do TCP/IP, sendo atendido pelo protocolo HTTP (é por isso que as páginas da Internet começam com http://). E assim por diante.

A camada de aplicação comunica-se com a camada de transporte através de uma porta. As portas são numeradas e as aplicações padrão usam sempre uma mesma porta. Por exemplo, o protocolo SMTP utiliza sempre a porta 25, o protocolo HTTP utiliza sempre a porta 80 e o FTP as portas 20 (para transmissão de dados) e 21 (para transmissão de informações de controle).

O uso de um número de porta permite ao protocolo de transporte (tipicamente o TCP) saber qual é o tipo de conteúdo do pacote de dados (por exemplo, saber que o dado que ele está transportando é um e-mail) e, no receptor, saber para qual protocolo de aplicação ele deverá entregar o pacote de dados, já que, como estamos vendo, existem inúmeros. Assim, ao receber um pacote destinado à porta 25, o protocolo TCP irá entregá-lo ao protocolo que estiver conectado a esta porta, tipicamente o SMTP, que por sua vez entregará o dado à aplicação que o solicitou (o programa de e-mail).

Camada de Transporte
Na transmissão de dados, a camada de transporte é responsável por pegar os dados passados pela camada de aplicação e transformá-los em pacotes. O TCP (Transmission Control Protocol, Protocolo de Controle da Transmissão) é o protocolo mais usado na camada de Transporte. Na recepção de dados, o protocolo TCP pega os pacotes passados pela camada Internet e trata de colocá-los em ordem, já que os pacotes podem chegar ao destino fora de ordem, confere se os dados dentro dos pacotes estão íntegros e envia um sinal de confirmação chamado “acknowledge” (“ack”) ao transmissor, avisando que o pacote foi recebido corretamente e que os dados estão íntegros. Se nenhum sinal de confirmação (acknowledge) for recebido (ou porque o dado não chegou ao destino ou porque o
TCP descobriu que o dado estava corrompido), o transmissor enviará novamente o pacote perdido.

Enquanto que o TCP reordena os pacotes e usa mecanismo de confirmação de recebimento – o que é desejável na transmissão de dados – existe um outro protocolo que opera nesta camada que não tem esses recursos. Este protocolo é o UDP (User Datagram Protocol, Protocolo de Datagrama do Usuário).
Por essa razão o TCP é considerado um protocolo confiável, enquanto que o UDP é considerado um protocolo não confiável. O UDP é tipicamente usado quando nenhum dado importante está sendo transmitido, como requisições DNS (Domain Name System, Sistema de Nome de Domínio). Como o UDP não reordena os pacotes e nem usa mecanismo de confirmação, ele é mais rápido do que o TCP.

Quando o UDP é usado, a aplicação que solicita a transmissão será a responsável por verificar se os dados recebidos estão intactos ou não e também de reordenar os pacotes recebidos, isto é, a aplicação fará o trabalho do TCP.

Durante a transmissão de dados, tanto o UDP quanto o TCP receberão os dados passados da camada de Aplicação e adicionarão a esses dados um cabeçalho. Na recepção de dados, o cabeçalho será removido antes de os dados serem enviados para a porta apropriada. Neste cabeçalho estão várias informações de controle, em particular o número da porta de origem, o número da porta de destino, um número de seqüência (para a confirmação de recebimento e mecanismos de reordenamento usado pelo TCP) e uma soma de verificação (chamada checksum ou CRC, que é um cálculo usado para verificar se o dado foi recebido intacto no destino). O cabeçalho UDP tem 8 bytes, enquanto que o cabeçalho TCP tem entre 20 e 24 bytes (dependendo se o campo opções estiver sendo ou não usado).

Camada Internet
Em redes TCP/IP cada computador é identificado com um endereço virtual único, chamado endereço IP. A camada Internet é responsável por adicionar um cabeçalho ao pacote de dados recebidos da camada de Transporte onde, entre outros dados de controle, será adicionado também o endereço IP de origem e o endereço IP de destino – isto é, o endereço IP do computador que está enviando os dados e o endereço IP do computador que deverá recebê-los.

A placa de rede de cada computador tem um endereço físico. Este endereço está gravado na memória ROM da placa de rede e é chamado endereço MAC. Dessa forma, em uma rede local se o computador A quiser enviar dados para o computador B, ele precisará saber o endereço MAC do computador B. Enquanto que em uma pequena rede local os computadores podem facilmente descobrir o endereço MAC de todos os PCs, esta não é uma tarefa tão simples em uma rede global como a Internet.

Se nenhum esquema de endereçamento virtual for usado, você precisa saber o endereço MAC do computador de destino, o que não é apenas uma tarefa complicada, mas também não ajuda no roteamento dos pacotes, já que este endereço não usa uma estrutura em árvore (em outras palavras, enquanto o endereçamento virtual usado na mesma rede terá endereços seqüenciais, com o endereçamento MAC o computador com o endereço MAC seguinte ao seu pode estar na Rússia).

Roteamento é o caminho que os dados devem usar para chegar ao destino. Quando você solicita dados de um servidor da Internet, por exemplo, este dado passa por vários locais (chamados roteadores) antes de chegar ao seu computador. Se você quiser ver com isto funciona, faça o seguinte: clique no menu Iniciar, Executar e digite Cmd. No prompt de comando digite tracert www.google.com. O resultados será o caminho entre seu computador e o servidor web do Google. Veja como os pacotes de dados passam através de diferentes roteadores antes de chegar ao destino. Cada roteador no meio do caminho é também conhecido como “salto” (“hop”).

Em todas as redes conectadas à Internet existe um dispositivo chamado roteador, que faz a ponte entre os computadores na sua rede local e a Internet. Todo roteador tem uma tabela contendo as redes conhecidas e também uma configuração chamada gateway padrão apontando para outro roteador na Internet. Quando seu computador envia um pacote de dados para a Internet, o roteador conectado à sua rede primeiro verifica se ele conhece o computador de destino – em outras palavras, o roteador verifica se o computador de destino está localizado na mesma rede ou em uma rede que ele conhece a rota. Se ele não conhecer a rota para o computador de destino, ele enviará o pacote para seu gateway padrão, que é outro roteador. Este processo é repetido até que o pacote de dados chegue ao seu destino.

Há vários protocolos que operam na camada Internet: IP (Internet Protocol, Protocolo de Internet), ICMP (Internet Control Message Protocol, Protocolo de Controle de Mensagens Internet), ARP (Address Resolution Protocol, Protocolo de Resolução de Endereços) e RARP (Reverse Address Resolution Protocol, Protocolo de Resolução de Endereços Reversos). Os pacotes de dados são enviados usando o protocolo IP, e por isso que explicaremos o seu funcionamento.

O IP pega os pacotes de dados recebidos da camada de Transporte (do protocolo TCP se você está transmitindo dados como e-mails ou arquivos) e os divide em datagramas. O datagrama é um pacote que não contém nenhum tipo de confirmação de recebimento (acknowledge), o que significa que o IP não implementa nenhum mecanismo de confirmação de recebimento, isto é, ele é um protocolo não confiável.

Você deve notar que durante a transferência de dados o protocolo TCP será usado acima da camada Internet (ou seja, acima do IP) e o TCP implementa mecanismo de confirmação de recebimento. Portanto apesar de o protocolo IP não verificar se o datagrama chegou ao destino, o protocolo TCP fará esta verificação. A conexão será então confiável, apesar do IP sozinho ser um protocolo não confiável.

Cada datagrama IP pode ter um tamanho máximo de 65.535 bytes, incluindo seu cabeçalho, que pode usar 20 ou 24 bytes, dependendo se um campo chamado “opções” for usado ou não. Dessa forma os datagramas IP podem transportar até 65.515 ou 65.511 bytes de dados. Se o pacote de dados recebidos da camada de Transporte for maior do que 65.515 ou 65.511 bytes, o protocolo IP fragmentará os pacotes em quantos datagramas forem necessários

Como mencionamos anteriormente, o cabeçalho adicionado pelo protocolo IP inclui o endereço IP de origem, o endereço IP de destino e várias outras informações de controle.

Se você prestar atenção, nós não dissemos que o datagrama IP tem 65.535 bytes, mas ele pode ter até 65.535 bytes. Isto significa que o campo de dados do datagrama não tem um tamanho fixo. Como os datagramas serão transmitidos pela rede dentro de quadros produzidos pela camada Interface com a Rede, normalmente o sistema operacional configurará o tamanho do datagrama IP para ter o tamanho máximo da área de dados do quadro de dados usado em sua rede. O tamanho máximo do campo de dados dos quadros que são transmitidos pela rede é chamado MTU, Maximum Transfer Unit, ou Unidade de Transferência Máxima.

As redes Ethernet – que são o tipo de rede mais comum hoje em dia, incluindo sua encarnação sem fio – pode transportar até 1.500 bytes de dados, ou seja, seu MTU é de 1.500 bytes. Por isso o sistema operacional configura automaticamente o protocolo IP para criar datagramas IP com 1.500 bytes em vez de 65.535 (que não caberia no quadro). Na próxima página veremos que o seu tamanho real é de 1.497 ou 1.492 bytes, já que a camada LLC “come” 3 ou 5 bytes para adicionar seu cabeçalho.

Só para esclarecer, você pode estar confuso como uma rede pode ser classificada como TCP/IP e Ethernet ao mesmo tempo. O TCP/IP é um conjunto de protocolos que lida com as camadas 3 a 7 do modelo de referência OSI. O Ethernet é um conjunto de protocolos que lida com as camadas 1 e 2 do modelo de referência OSI – o que significa que o Ethernet se preocupa com o aspecto físico da transmissão de dados. Por isso eles se complementam, já que precisamos das sete camadas completas (ou suas equivalentes) para estabelecer uma conexão de rede. Nós explicaremos mais sobre este relacionamento na próxima página.

Outra característica que o protocolo IP permite é a fragmentação. Como mencionamos, até chegar a seu destino o datagrama IP provavelmente passará por várias outras redes no meio do caminho. Se todas as redes no caminho entre o computador transmissor e o receptor usarem o mesmo tipo de rede (por exemplo Ethernet), maravilha, já que todos os roteadores trabalharão com a mesma estrutura do quadro (isto é, o mesmo tamanho de MTU).

No entanto, se aquelas outras redes não forem redes Ethernet, elas podem usar um tamanho diferente de MTU. Se isto acontecer, o roteador que está recebendo os quadros com o MTU configurado com 1.500 bytes dividirá o datagrama IP em quantos quadros forem necessários para atravessar a rede com o tamanho de MTU menor. Ao chegar no roteador que tem sua saída conectada a uma rede Ethernet, este roteador remontará o datagrama original.

O quadro original usa um MTU de 1.500 bytes. Quando o datagrama chega a uma rede com o tamanho de MTU de 620 bytes, cada quadro tem de ser dividido em três quadros (dois com 600 bytes e um com 300 bytes). Em seguida o roteador na saída desta rede (roteador 2) remonta o datagrama original.
Claro que o cabeçalho IP tem um cabo para controlar a fragmentação.

Camada Interface com a Rede
Os datagramas gerados na camada Internet serão passados para a camada Interface com a Rede, durante a transmissão de dados, ou a camada de Interface com a Rede pegará os dados da rede e os enviará para a camada de Internet, na recepção dos dados.

Esta camada é definida pelo tipo de rede física a qual seu computador está conectado. Quase sempre seu computador estará conectado a uma rede Ethernet (redes sem fio também são redes Ethernet como explicaremos).

Com dissemos anteriormente, o TCP/IP é um conjunto de protocolos que lida com as camadas 3 a 7 do modelo de referência OSI, enquanto que o Ethernet é um conjunto de protocolos que lida com as camadas 1 e 2 do modelo de referência OSI – o que significa que o Ethernet lida com os aspectos físicos da transmissão de dados. Por isso um complementa o outro, já que precisamos das sete camadas completas (ou suas equivalentes) para estabelecer uma conexão de rede.

O Ethernet tem três camadas: LLC (Controle do Link Lógico), MAC (Controle de Acesso ao Meio) e Física. O LLC e o MAC correspondem, juntas, a segunda camada do modelo de referência OSI.

A camada LLC é a responsável por adicionar informações de que protocolo na camada Internet foi o responsável por gerar os dados. Dessa forma, durante a recepção de dados da rede esta camada no computador receptor tem que saber que protocolo da camada de Internet ele deve entregar os dados. Esta camada é definida pelo protocolo IEEE 802.2.

A camada de Controle de Acesso ao Meio (MAC) é a responsável por montar o quadro que será enviado para a rede. Esta camada é responsável por adicionar o endereço MAC de origem e de destino – como explicamos anteriormente, o endereço MAC é um endereço físico de uma placa de rede. Os quadros que são destinados a outras redes utilizarão o endereço MAC do roteador da rede como endereço de destino. Esta camada é definida pelo protocolo IEEE 802.3, se uma rede com cabos estiver sendo usada, ou pelo protocolo IEEE 802.11, se uma rede sem fio estiver sendo usada.

A camada Física é a responsável por converter o quadro gerado pela camada MAC em sinais elétricos (se for uma rede cabeada) ou eletromagnéticos (se for uma rede sem fio). Esta camada é também definida pelo protocolo IEEE 802.3, se for uma rede com cabos estiver sendo usada, ou pelo IEEE 802.11, se uma rede sem fio estiver sendo usada.

As camadas LLC e MAC adicionam suas informações de cabeçalho ao datagrama recebido da camada Internet. Note que os cabeçalhos adicionados pelas camadas superiores são vistos como “dados” pela camada LLC. A mesma coisa acontece com o cabeçalho inserido pela camada LLC, que será visto como dado pela camada MAC.

A camada LLC adiciona um cabeçalho de 3 ou 5 bytes e seus datagrama tem um tamanho total máximo de 1.500 bytes, deixando um máximo de 1.497 ou 1.492 bytes para dados. A camada MAC adiciona um cabeçalho de 22 bytes e um CRC (soma dos dados para identificação de erros) de 4 bytes ao final do datagrama recebido da camada LLC, formando o quadro Ethernet. Portanto o tamanho máximo de um quadro Ethernet é de 1.526 bytes.

Abraços,
Ranieri Marinho de Souza
Segurança da Informação

http://www.segr.com.br/
http://blog.segr.com.br/

Tipos de Ataques
- Negação de Serviço
- Vazamento de Informações
- Acesso a arquivos comuns
- Informação Falsa
- Acesso a arquivos ou bancos de dados especiais
- Execução remota de código arbitrário
- Elevação de Privilégios

Negação de Serviço – (Denial of Service)
Quando a disponibilidade de um recurso é intencionalmente bloqueada ou prejudicada.
O ataque impede a disponibilidade do recurso para seus usuários autorizados regulares.
Dificultar processos.
Diminuir a capacidade de armazenamento.
Destruir arquivos para tornar o recurso inutilizável.
Desativar partes do sistema ou processos.
O ataque é local. São comuns.
Muitos casos inevitáveis.
São mais fáceis de detectar.
Desde que a infra-estrutura de segurança esteja correta, são facilmente rastreados e o atacante é facilmente identificado.
Degradação de processo.
Esgotamento de espaço em disco.
Esgotamento de nó de índice.

Degradação de processo
No kernel Linux até a versão 2.4.12 … … … O scheduler de processos podia ser bloqueado, impedindo que quaisquer outros processos no sistema recebessem tempo de CPU.
Ataque local.
Afetando outros sistemas operacionais, existe o fork bomb.
Diminui o desempenho de processos com efeitos variáveis.
O efeito pode ser tão pequeno quanto fazer o sistema operacional funcionar lentamente …
Ou podem ser tão extremos quanto monopolizar recursos do sistema operacional, causando sua queda.
O código para shell: $ 0 & $ 0 &
O código para C:
(main() {for( ; ; ) fork () ; } )
#include
#include
#include
void main(void)
{ malloc(9999);
fork();
main();
}

Esgotamento do espaço em disco
Ataque local.
O espaço em disco é um recurso finito.
Consumir o espaço em disco até sua capacidade máxima.
O espaço em disco era um recurso extremamente caro.
A indústria atual tem diminuído o preço do armazenamento em disco.
Pode-se resolver muitos problemas de armazenamento com soluções como arrays de disco e software que monitora o excesso de armazenamento.
O espaço em disco continua sendo um entrave para todos os sistemas. As soluções baseadas em software, com cotas de armazenamento por usuário, visam amenizar este problema.
O ataque impede a criação de novos arquivos e o crescimento dos arquivos existentes.
Alguns sistemas UNIX cairão quando a partição raiz atingir a capacidade de armazenamento.
Incluir uma partição separada para os recursos de log, como o /var, e uma partição separada para os usuários como o diretório /home no LINUX ou /export/home nos sistemas SUN.
Objetivo do ataque: derrubar sistemas, quando o layout de disco não for feito com partições de log e de usuários em separado.
Outro objetivo: obscurecer as atividades de um usuário, gerando grande quantidade de eventos que são registrados via syslog, enchendo a partição onde os logs são armazenados e impossibilitando o syslog de qualquer outra atividade.
Outro objetivo: obscurecer as atividades de um usuário, gerando grande quantidade de eventos que são registrados via syslog, enchendo a partição onde os logs são armazenados e impossibilitando o syslog de qualquer outra atividade.
O ataque: um usuário local executa o comando
cat /dev/zero > ~maliciousfile
O comando concatena dados do arquivo de dispositivo /dev/zero (que simplesmente gera zeros) com o arquivo malicioso, continuando até que o usuário suspenda o processo ou que a partição seja atingida.

Esgotamento de inode
O ataque é local.
Concentra-se no sistema de arquivos.
inode = index node (nó de índice).
Os nós de índice são parte essencial do sistema de arquivos do UNIX.
Contém informações vitais ao gerenciamento do sistema de arquivos: proprietário do arquivo, associação de grupo do arquivo, tipo de arquivo, as permissões, o tamanho e os endereços de bloco contendo os dados do arquivo.
Quando um sistema de arquivos é formatado, um número finito de inodes é criado para manipular a indexação dos arquivos.
O ataque visa usar todos os inodes disponíveis para uma partição.
O sistema é incapaz de criar novos arquivos.
Objetivos do ataque: impedir o registro dos eventos de sistema, especialmente, as atividades do próprio hacker.

INODE
Em UNIX, pode-se verificar quantos inodes estão livres sobre um disco por emitir o comando df com a opção –i:
% df -o i /usr

Negação de Serviço – (Ataque Remoto)
Ataques de negação de serviço lançados através de uma rede.
Duas categorias:
- um ataque que afeta um serviço específico;
- um ataque que visa um sistema inteiro.
Ferramentas disponíveis conferem anonimato e capacidade de causar um problema exigindo pouco conhecimento técnico.
A gravidade desses ataques varia significativamente.
São destinados a produzir transtornos.
Lançados como uma ação retaliatória.
Lado do Cliente
Baseado em Serviço
Direcionada a Sistema

DoS direcionada a sistema – Ataques de Flooding
Usado para prejudicar o desempenho ou tornar o sistema completamente indisponível.
Forma de ataque: usar uma exploração para atacar um sistema por meio de outro, deixando o sistema alvo inoperante.
O conceito de inundação (flooding) de SYN (.
Ataque lançado de qualquer sistema em uma rede mais rápida que o sistema-alvo, para múltiplos sistemas.
É usado para degradar desempenho de sistema.
A inundação de SYN (sincronização) é realizada enviando requisições de conexão IP mais rápido do que um sistema pode processar.
Como o sistema-alvo consome recursos para cuidar de cada conexão, um grande número de SYNs chegando, pode levar o sistema-alvo a ficar sem recursos para novas conexões legítimas.
O endereço IP de origem é falsificado, para quando o sistema-alvo tentar responder com um SYN-ACK (sincronização-confirmação), o atacante não recebe resposta alguma.
O código de exploração para o flooder de SYN, syn4k.c foi escrito por Zakath.
Este flooder de SYN permite selecionar as portas e um endereço, a inundar no sistema-alvo.
O código pode ser obtido em:
www.cotse.com/sw/dos/syn/synk4.c
Pode-se detectar uma inundação de SYN feito pelo código synk4.c usando-se o comando netstat (Windows).
C:WINNTSystem32cmd.exe
C:>netstat -n -p tcp
C:>netstat -all
C:WINNTSystem32cmd.exe
C:>netstat -n -p tcp
-n exibe o (Local Address) atingido e o endereço remoto (Foreign Address) de onde vem a inundação.
-p seleciona o protocolo desejado.
C:>netstat -n -p udp
São mostradas as conexões que interessam para o ataque em particular.

DoS de rede direcionada a sistema – Ataques Smurfing
Geralmente lançados pelos scripts kiddiots (script do atacante), com poder de anonimato.
O ataque de smurf realiza um DoS através de rede contra um host-alvo.
O ataque se baseia na ajuda de um intermediário, um roteador.
O atacante falsificando o endereço IP de origem, gera uma grande quantidade de tráfego de echo ICMP (Internet Control Message Protocol) direcionado aos endereços de broadcast IP, no roteador.
O roteador, chamado de amplificador de smurf, converte o broadcast IP em um broadcast da camada 2 (enlace) e a passa adiante.
Cada host que recebe o broadcast, responde para o endereço IP falsificado, com uma resposta de echo.
Dependendo do número de hosts na rede, tanto o roteador, tanto o host-alvo podem ser inundados com tráfego.
Isto pode resultar na queda de desempenho na rede, do host-alvo sendo atacado e, dependendo do número de redes com roteadores amplificadores usados, a rede com o host-alvo, se torna saturada até a sua capacidade.

DoS direcionada a sistema – Ataques DDoS
Atacante – Quem efetivamente coordena o ataque.
Master – Máquina que recebe os parâmetros para o ataque e comanda os agentes.
Agente – Máquina que efetivamente concretiza o ataque DoS contra um ou mais alvos, conforme especificado pelo atacante.
Alvo do ataque – Máquina que é “inundada” por um volume grande de pacotes, ocasionando um congestionamento extremo da rede e resultando na paralização dos serviços oferecidos pela mesma.
Cliente – Aplicação que reside no Master e que efetivamente controla os ataques enviando comandos aos daemons.
Daemons – Processos que roda nos agentes, responsável por receber e executar os comandos enviados pelo cliente.
Resulta de conjugar os dois conceitos:
- negação de serviço
- intrusão distribuída.
Ataques DoS partindo de várias origens, disparados simultaneamente e coordenadamente sobre um ou mais alvos.

O ataque é dado em três fases:
- Uma fase de intrusão, na qual ferramentas automáticas são usadas para comprometer máquinas e obter acesso privilegiado (acesso de root).
- o atacante instala software DDoS (agentes) na máquinas invadidas, para montar a rede de ataque.
- fase da inundação, consolidando o ataque.

Fase 1: Intrusão em Massa
É realizada uma varredura de portas e vulnerabilidades em redes consideradas “interessantes”.
Explorar as vulnerabilidades reportadas para a obtenção de acesso privilegiado nessas máquinas.

Sniffers e Rootkits
Um Sniffer é um programa ou ferramenta que monitora uma rede em busca de informações em que o atacante possa estar interessado.
Informações de autenticação, como nomes de usuários e senhas.
Sniffers são incluídos na maior parte dos Rootkits.
É criada uma lista de IPs das máquinas que foram invadidas e que serão utilizadas na montagem da rede.

Fase 2: Instalação de Software DDoS
Uma conta de usuário qualquer é usada como repositório das versões compiladas de todas as ferramentas de ataque DDoS.
Uma vez que a máquina seja invadida, os binários das ferramentas DDoS são instalados nessas máquinas para permitir que sejam controladas remotamente.

Masters ou Agentes.
Masters, não devem ser máquinas manuseadas cosntantemente pelos administradores.

Agentes devem estar em máquinas conectadas à Internet por links relativamente rápidos.

Rodados os daemons que rodam nos agentes, esses se anunciam para os masters e ficam à espera de comandos.
A aplicação DDoS que roda nos masters, registra em uma lista IP das máquinas agentes ativas.
Essa lista pode ser acessada pela máquina atacante.
A partir da comunicação automatizada entre masters e agentes, organizam-se os ataques.
Rootkits poderão ser instalados para ocultar o comprometimento das máquinas.

Fase 3: O ataque
a) O atacante controla um ou mais máquinas masters, as quais por sua vez podem controlar um grande número de máquinas agentes.
b) A partir dos agentes é disparado o “flood” de pacotes que consolida o ataque.
c) Quando o atacante ordena o ataque, uma ou mais máquinas-alvo são inundadas por um volume considerável de pacotes, resultando na saturação do link de rede e paralização dos seus serviços.

Ferramentas de DDoS
- Fapi
- Blitznet
- Trin00
- TFN
- Stacheldraht
- Shaft
- TFN2K
- Trank
- Trin00 win version

Abraços,
Ranieri Marinho de Souza
Segurança da Informação

http://www.segr.com.br/
http://blog.segr.com.br/