Mudanças entre as edições de "Gerência de Redes (diário 2011-1)"
(29 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
Linha 95: | Linha 95: | ||
==Método de Avaliação== | ==Método de Avaliação== | ||
([[#Resultado: implementação|Facilitadores]]) * 1 +<br> | ([[#Resultado: implementação|Facilitadores]]) * 1 +<br> | ||
− | + | ([[#Resultado: implementação|Facilitadores]] + Diretórios + Bancos de Dados) * 2 +<br> | |
− | ([[#Resultado: implementação|Facilitadores]] + Diretórios + Bancos de Dados) * | + | ([[#Resultado: implementação|Facilitadores]] + Diretórios + Bancos de Dados + Compartilhamento + Comunicação) * 3 +<br> |
− | + | [[#Projeto Final|Projeto final]] * 4 =<br> | |
− | ([[#Resultado: implementação|Facilitadores]] + Diretórios + Bancos de Dados + Compartilhamento + Comunicação) * | + | Somatório / 10 =<br> |
− | |||
− | Somatório / | ||
Conceito Final (CF): | Conceito Final (CF): | ||
* Se CF < 6 então D. | * Se CF < 6 então D. | ||
Linha 241: | Linha 239: | ||
"Ativos de rede" -> "802.1p" [color=blue] | "Ativos de rede" -> "802.1p" [color=blue] | ||
− | "Armário principal" -> LACP [color=green,fontcolor=green,label=" | + | "Armário principal" -> LACP [color=green,fontcolor=green,label="Servidores"] |
} | } | ||
</graphviz></center> | </graphviz></center> | ||
Linha 796: | Linha 794: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | ==31/05 - | + | ==31/05 - 09/06: Camada de Aplicação: Comunicação== |
* 31/05: visto, em sala de aula, os protocolos SMTP para envio de ''emails'' e POP3 e IMAP para recebimento. | * 31/05: visto, em sala de aula, os protocolos SMTP para envio de ''emails'' e POP3 e IMAP para recebimento. | ||
* 02/06: atividade em laboratório, envolvendo os protocolos SMTP e IMAP para envio e recebimento de ''emails'' utilizando aplicativos específicos (Outlook, Thunderbird, Evolution e outros) e ''webmail'' (adotado o aplicativo [http://roundcube.net/ Roundcube] por questões didáticas). A atividade envolverá: | * 02/06: atividade em laboratório, envolvendo os protocolos SMTP e IMAP para envio e recebimento de ''emails'' utilizando aplicativos específicos (Outlook, Thunderbird, Evolution e outros) e ''webmail'' (adotado o aplicativo [http://roundcube.net/ Roundcube] por questões didáticas). A atividade envolverá: | ||
Linha 852: | Linha 850: | ||
} | } | ||
</graphviz></center> | </graphviz></center> | ||
+ | * 09/06: Prova. | ||
+ | *# Genérico: Crie o domínio <sobrenome>.com.br, onde o servidor principal, além de deter a autoridade sobre o domínio, ainda deverá fazer referência (nome, A, ou apelido, CNAME) aos seus serviços disponibilizados: NTP, SMB, HTTP, SMTP e IMAP. | ||
+ | *# Sistema: Crie usuários de A a M. | ||
+ | *# SMB: Compartilhe o diretório /home/arquivos para os usuários que são vogais. Somente eles podem ter acesso de leitura ou de escrita ao conteúdo. | ||
+ | *# SMB: Compartilhe o diretório /var/www/sites com permissão de leitura+escrita para os usuários de F a M e apenas permissão de leitura para A e B. | ||
+ | *# SMB: Compartilhe o diretório /opt com permissão apenas de leitura para todos os usuários, de A a M. | ||
+ | *# HTTP: compartilhe o diretório /home com permissão de leitura aos usuários de B a F. | ||
+ | *# HTTP: compartilhe o diretório /var/www/arquivos com permissão de leitura e de escrita para todos os usuários (A a M). | ||
+ | *# Publique um serviço de Webmail funcional. Teste-o com o envio local. Não pode ser o serviço Roundcube. | ||
+ | *# Sistema: monitore periodicamente o sistema em busca de arquivos com as seguintes extensões: MP3 e AVI. Liste-os e envie por email ao usuário root e apague-os em seguida. | ||
+ | *# Sistema: monitore periodicamente o espaço em disco nas partições. Caso exceda o limite de 90% de ocupação, envie um email ao usuário root notificando-o. | ||
+ | *# Sistema: monitore periodicamente os diretórios compartilhados em SMB e HTTP por arquivos com as extensões COM e PIF, a fim de identificar algum vírus em potencial. Se achar algum arquivo, mova-os para um diretório de quarentena e avise o usuário root sobre os mesmos para análise posterior. | ||
− | == | + | ==14/06 - 28/06: Camada de Aplicação: Gerência da Rede== |
− | * | + | * 14/06: apresentação das 5 gerências de rede: Monitoramento, Contabilização, Desempenho, Configuração e Segurança. Foi dada ênfase ao protocolo SNMP para Monitoramento e Contabilização - veja publicação da RNP [http://www.rnp.br/newsgen/9708/n3-2.html 1] e [http://www.rnp.br/newsgen/9712/gerencia.html 2]. |
− | * | + | * 16/06: instalação de agente e gerente SNMP para primeiras avaliações do protocolo para monitoramento e contabilização do ambiente de rede. |
===Cenário: Agente e Gerente SNMP em ambiente Linux=== | ===Cenário: Agente e Gerente SNMP em ambiente Linux=== | ||
Linha 911: | Linha 921: | ||
* [http://www.zabbix.com/ Zabbix]; | * [http://www.zabbix.com/ Zabbix]; | ||
* [http://www.zenoss.com/ Zenoss]. | * [http://www.zenoss.com/ Zenoss]. | ||
− | + | Por questões didáticas, e pela facilidade de administração (Web), adotaremos o Cacti, cuja [http://www.cacti.net/downloads/docs/html/unix_configure_cacti.html documentação] é bem objetiva e funcional. Uma vez o sistema no ar, é possível passar direto para o [http://www.cacti.net/downloads/docs/html/graph_howto.html cadastro dos "alvos"] e listar [http://www.cacti.net/downloads/docs/html/new_graphs.html quais informações] serão coletadas periodicamente. | |
Caso o erro "[NOT FOUND] RRDTool Binary Path: The path to the rrdtool binary." apareça durante a configuração do Cacti execute: | Caso o erro "[NOT FOUND] RRDTool Binary Path: The path to the rrdtool binary." apareça durante a configuração do Cacti execute: | ||
Linha 967: | Linha 977: | ||
else | else | ||
echo " Falha geral: interface ${ETH}." | echo " Falha geral: interface ${ETH}." | ||
− | + | exit 2 | |
fi | fi | ||
echo -n " - Roteamento..." | echo -n " - Roteamento..." | ||
Linha 981: | Linha 991: | ||
} | } | ||
− | + | generico_http(){ | |
echo -n "- HTTP..." | echo -n "- HTTP..." | ||
GET=0 | GET=0 | ||
Linha 1 022: | Linha 1 032: | ||
} | } | ||
− | + | ||
− | |||
− | |||
− | |||
# Programa Principal | # Programa Principal | ||
# | # | ||
Linha 1 040: | Linha 1 047: | ||
local_enlace ${ETH} | local_enlace ${ETH} | ||
local_rede ${ETH} | local_rede ${ETH} | ||
− | + | generico_http ${GOOGLE} | |
# | # | ||
# Testes no alvo | # Testes no alvo | ||
Linha 1 047: | Linha 1 054: | ||
alvo_icmp ${1} | alvo_icmp ${1} | ||
alvo_dns ${1} ${2} | alvo_dns ${1} ${2} | ||
− | + | generico_http ${1} | |
# Sugestão: testar as aplicações com netcat :-) | # Sugestão: testar as aplicações com netcat :-) | ||
Linha 1 054: | Linha 1 061: | ||
exit 0 | exit 0 | ||
</syntaxhighlight> | </syntaxhighlight> | ||
+ | |||
+ | =Projeto Final= | ||
+ | Em acordo entre professor e alunos, foi modificado [[#Método de Avaliação|método da avaliação final]] de prova prática para projeto com defesa oral. | ||
+ | ==Sobre o cenário== | ||
+ | O projeto trata da implementação de um cenário hipotético - e bastante comum no Brasil: | ||
+ | <center><graphviz> | ||
+ | graph Empresa | ||
+ | { | ||
+ | Internet [shape=plaintext] | ||
+ | 1 [shape=circle] | ||
+ | 2 [shape=circle] | ||
+ | 3 [shape=circle] | ||
+ | subgraph clusterMatriz | ||
+ | { | ||
+ | label=Matriz | ||
+ | Servidor_M [label=Servidor,shape=Mrecord] | ||
+ | } | ||
+ | subgraph clusterFilial | ||
+ | { | ||
+ | label=Filial | ||
+ | Servidor_F [label=Servidor,shape=Mrecord] | ||
+ | } | ||
+ | Servidor_M -- Internet | ||
+ | Servidor_F -- Internet | ||
+ | Internet -- 1 | ||
+ | Internet -- 2 | ||
+ | Internet -- 3 | ||
+ | } | ||
+ | </graphviz></center> | ||
+ | Na figura acima veem-se, pois, os três eixos que compõem a organização: | ||
+ | * Matriz; | ||
+ | * Filial; | ||
+ | * "n" funcionários em trânsito (representados 3 deles). | ||
+ | |||
+ | ==Requisitos do Sistemas== | ||
+ | * Hora certa: o servidor da matriz deverá alinhar seu relógio com outros da Internet para, em seguida, permitir o alinhamento pelas estações de trabalho na matriz, servidor da filial e esse para as estações da sua localidade. Desejável o uso de criptografia e/ou senha de controle. | ||
+ | * Domínio unificado: hierarquia entre o domínio da matriz e da filial, requerendo para tal delegação de subdomínio entre as duas localidades. | ||
+ | * Cadastro de usuários único: seja na matriz, na filial ou em trânsito, deverá haver apenas um cadastro único de usuários e válido em qualquer localidade para todos os serviços de autenticação. Desejável o uso de serviço em rede como LDAP. | ||
+ | * Compartilhamento de arquivos local e global: tanto na matriz quando na filial devereá haver um repositório local de arquivos, os quais de interesse restrito a essa localidade. Além disso, deverá haver em paralelo, de forma complementar, um repositório global disponível a todos (matriz, filial e em trânsito). Obrigatório o uso de criptografia e esquemas de autenticação e de autorização. | ||
+ | * Sistema de comunicação por texto, voz ou vídeo entre todos os funcionários das localidades. Qualquer um destes sistemas é válido e pode compor a solução final: correio eletrônico, mensagem instantânea e VoIP. Para cada sistema, deverá estar disponível a cada funcionário uma solução utilizando aplicação dedicada e em versão Web (exemplo: aplicação cliente de correio eletrônico e ''webmail''). | ||
+ | * Gerência centralizada de rede: monitoramento e contabilização com interface Web disponível na Internet. Obrigatório o uso de criptografia, autenticação e autorização. | ||
+ | * ''Backup'' local e global, condizente com os serviços de compartilhamento de arquivos e de comunicação, armazenando toda e qualquer informação possível relacionada a esses serviços oferecidos. Além disso, deverão também ser salvaguardados os arquivos de configuração dos servidores das duas localidades. | ||
+ | * Segurança na matriz e na filial em pelo menos duas camadas: Rede (filtro de pacotes) e Aplicação (''proxy''). | ||
+ | |||
+ | ==Implementação== | ||
+ | Em duplas, matriz e filial, no [[#Ambiente de Produção|ambiente de produção]]. | ||
<center><small>[[Gerência de Redes (página)|Página principal da disciplina]]</small></center> | <center><small>[[Gerência de Redes (página)|Página principal da disciplina]]</small></center> |
Edição atual tal como às 11h23min de 12 de julho de 2011
Endereço encurtado: http://bit.ly/ger20111
Planejamento
Planejamento realizado coletivamente e em sala.
Cenário
Infraestrutura de rede do IFSC campus São José:
- Espaço dividido entre público e privado para os diversos usuários:
- Técnicos administrativos.
- Professores.
- Alunos.
- Visitantes.
- Comunicação assíncrona e síncrona (tempo real).
- Espaço para troca de dados em forma de arquivos.
- Disponibilidade.
- Segurança.
Objetivo Geral
Análise de cenário como objeto de estudo com proposta de melhoria em Telecomunicações como veículo mais eficiente de comunicação.
Proposta de Trabalho
Abordagem em camadas, conforme RM-OSI, resgatando conceitos vistos em outras disciplinas do curso:
Camada | O que analisar | Disciplinas de base | Tecnologias e Padrões envolvidos | Produto final | |
Física | Espaço físico; Climatização; Energia elétrica; Conectividade. |
Projeto de Redes Metálicas e Ópticas | NBR14565. | Plano de ação. | |
Enlace | Segmentação da rede física em n lógicas; Redundância lógica e prevenção em software de loops; Prioridade para mídias. |
Redes de Computadores II | Ethernet; 802.11; 802.1p; 802.1q; 802.1X; LACP; STP. |
Plano de ação. | |
Rede | Atual endereçamento e roteamento da rede e transição para IPv6. | Redes de Computadores I Redes de Computadores III |
IPv4; IPv6. |
Plano de ação. | |
Aplicação | Facilitadores | Automatização nas rotinas e atribuição em rede de endereços e nomes de computadores. | Redes de Computadores I | Syslog; NTP; DHCP. |
Implementação em servidor virtualizado. |
Diretórios | Sistemas em rede para armazenamento de informações organizadas em diretórios. | Redes de Computadores I | DNS; LDAP. |
||
Bancos de Dados | |||||
Compartilhamento | |||||
Comunicação | |||||
Gerência de Rede |
Desenvolvimento das Atividades
Ambiente de Teste
- Máquinas virtuais do Lab. de Redes II.
Ambiente de Produção
- Modelos dos arquivos de configuração (/etc).
- Modelo do sistema de arquivos.
- Serviços com redirecionamento de porta: servidor ger20111.sj.ifsc.edu.br.
VM | Aluno | No ar? | Redirecionamento de Porta | ||||
SSH | SMTP | DNS | HTTP | HTTPS | |||
01 | Anderson Felisbino | X | 122 | 125 | 153 | 180 | 1443 |
02 | Eduardo de Mello Garcia | X | 222 | 225 | 253 | 280 | 2443 |
03 | Christiane Fernandes Dias e Silva | X | 322 | 325 | 353 | 380 | 3443 |
04 | Felipe Artur Mariano | X | 422 | 425 | 453 | 480 | 4443 |
05 | Glaucio Bertelli Peres | X | 522 | 525 | 553 | 580 | 5443 |
06 | Guilherme Bilbao Soares da Silva | X | 622 | 625 | 653 | 680 | 6443 |
07 | Jean Cesar Beltrame | X | 722 | 725 | 753 | 780 | 7443 |
08 | Michel Fernandes de Lucena | X | 822 | 825 | 853 | 880 | 8443 |
09 | Paulo Sergio Alves | 922 | 925 | 953 | 980 | 9443 | |
10 | Paulo Vitor de Almeida | X | 1022 | 1025 | 1053 | 1080 | 10443 |
11 | Roicenir Girardi Rostirolla | X | 1122 | 1125 | 1153 | 1180 | 11443 |
12 | Zilmar de Souza Junior | X | 1222 | 1225 | 1253 | 1280 | 12443 |
13 | Liamari de Araujo | X | 1322 | 1325 | 1353 | 1380 | 13443 |
14 | Regiane Paiter | X | 1422 | 1425 | 1453 | 1480 | 14443 |
Método de Avaliação
(Facilitadores) * 1 +
(Facilitadores + Diretórios + Bancos de Dados) * 2 +
(Facilitadores + Diretórios + Bancos de Dados + Compartilhamento + Comunicação) * 3 +
Projeto final * 4 =
Somatório / 10 =
Conceito Final (CF):
- Se CF < 6 então D.
- Se CF >= 6 e CF < 7,5 então C.
- Se CF >= 7,5 e CF < 9 então B.
- Se CF >= 9 então A.
Ver Também
- Papos de Botequim: livro do Júlio Neves sobre shell script, com destaque ao bash.
- Livro Shell Script Profissional: livro do Aurélio Marinho Vargas, segundo ele "complementar ao livro (...) do Júlio".
- Guia Foca Linux: material de referência do Gleydson baseado em Debian GNU/Linux.
Aulas
24/02 - 03/03: Camada Física
- 24/02: Discussão do tema, destacando as seções do cabeamento estruturado no cenário de estudo:
- Entrada de facilidades, cabeamento vertical e cabeamento horizontal: apenas passivos de rede e cabeamento rígido. Não requer climatização ou energização dos componentes.
- Armário principal e armário de telecom: passivos e ativos de rede, requendo obrigatoriamente climatização, energização e controle de acesso físico ao espaço.
- 01/03: Divisão do trabalho em pequenas equipes, para entrega parcial na próxima aula.
Atividade | Responsável | Facilidades |
Verificar documentação dos pontos de rede. | Christiane e Eduardo | Identificação já realizada pelo Rafael (COINF). |
Identificar pontos de rede sem fio e qualidade do sinal. | Michael e Liamari | |
Identificar os ativos de rede para centralizá-los. | Anderson e Paulo Sérgio | |
Dimensionar demanda de pontos de rede. | Zilmar e Glaucio | Consultar Humberto (COINF). |
Analisar a infraestrutura dos espaços que irão receber os armários. | Paulo Vitor e Roicenir | |
Lançamento de novos cabos: cálculo aproximado de material necessário. | Felipe, Guilherme e Jean | |
Elaboração do documento final do plano de ação. | Regiane |
Foi demandado ao professor a planta baixa do prédio, laboratório para confecção de material, acesso físico aos armários e levantamentos já realizados pela equipe da COINF.
- 03/03: Apresentação do produto parcialmente realizado, resgatando a discussão da rede sem fio e localização dos ativos de rede nos espaços adequados.
Resultado: plano de ação
Documento sob análise dos professores (acesso restrito), o qual contém:
- Análise de planta baixa do projeto original e expansões.
- Projeto elétrico, de preferência circuitos redundantes. [Disponibilidade]
- Cabeamento estruturado e seções.
- Entrada de facilidades: passivos de rede.
- Armário principal: passivos e ativos de rede. Requer cuidados quanto a energização e climatização dos ativos. [Segurança]
- Cabeamento vertical: passivos de rede.
- Armário de telecom: passivos e, no caso particular do IFSC, ativos de rede. Requer cuidados quanto a energização e climatização dos ativos. [Segurança]
- Cabeamento horizontal: passivos de rede.
- Área de trabalho: passivos e ativos de rede (terminais). Pode requerer cuidados quanto a energização e climatização dos ativos.
- Manutenção
- Bandejas e dispositivos de suporte do cabeamento.
- Organização física dos cabeamentos rígido (não visível) e flexível (visível).
- Padrão global de identificação de cabos e de pontos.
- Identificação de cabos.
- Identificação de pontos.
- Áreas de cobertura das redes sem fio.
- Sobreposição das áreas com canais/frequências distintas. [Disponibilidade]
- Áreas de cobertura das redes sem fio.
- Posicionamentos dos ativos nos armários.
- Conexões cruzadas aos pares, viabilizando canais físicos alternativos. [Disponibilidade]
- Mapeamento da demanda reprimida de pontos.
- Cálculo de material para lançamento de novos cabos e instalação de novos pontos.
- Verificação de espaços vagos nos armários e possível remanejamento de pontos.
10/03 - 15/03: Camada de Enlace
- 10/03: discussão sobre as tecnologias envolvidas na Camada de Enlace, com foco na identificação dos usuários e isolamento das redes lógicas, sejam essas com ou sem fio. Já aparecem as primeiras relações entre as camadas. Além disso, as tecnologias definiram sub-redes lógicas com características próprias:
- Espaços privados:
- Armários e sala de servidores: sub-rede lógica própria. Todos os servidores devem implementar LACP para aumento de banda com balanceamento de carga e redundância. Entre os ativos de rede, em particular switches, deve-se implementar LACP e STP para prevenção e recuperação automatizada de falhas.
- Salas administrativas: identificação do usuário por porta no switch para associá-lo a uma das sub-redes: técnico e professor.
- Espaços públicos:
- De ensino: identificação do usuário por porta no switch para associá-lo a uma das sub-redes: professor e aluno.
- De uso comum: identificação do usuário por autenticação (802.1x) para uma das sub-redes: técnico, professor, aluno e visitante.
- Espaços privados:
digraph Rede {
subgraph clusterFísica { label="Física"
"Entrada de facilidades" [shape=Mrecord] "Armário principal" [shape=Mrecord] "Cabeamento vertical" [shape=Mrecord] "Armário de telecom" [shape=Mrecord] "Cabeamento horizontal" [shape=Mrecord] "Área de trabalho" [shape=Mrecord]
"Entrada de facilidades" -> "Armário principal" "Armário principal" -> "Cabeamento vertical" "Cabeamento vertical" -> "Armário de telecom" "Armário de telecom" -> "Cabeamento horizontal" "Cabeamento horizontal" -> "Área de trabalho" }
subgraph clusterEnlace { label="Enlace" "Ethernet" [shape=Mrecord] "802.11" [shape=Mrecord] "802.1p" [shape=Mrecord] "802.1q" [shape=Mrecord] LACP [shape=Mrecord] "802.1D" [shape=Mrecord] "802.1x" [shape=Mrecord]
"802.1q" -> "802.1p" "802.1x" -> "802.1q" [label="por usuário"] "802.11" -> "802.1x" "Ethernet" -> LACP LACP -> "802.1q" "Ethernet" -> "802.1x" "802.1q" -> "802.1D" [label="MSTP"] }
"Pares de cabos + canais distintos" [shape=plaintext,fontcolor=red] "Cabeamento vertical" -> "Pares de cabos + canais distintos" [color=red] "Cabeamento horizontal" -> "Pares de cabos + canais distintos" [color=red] "Pares de cabos + canais distintos" -> "LACP" [color=red] "Pares de cabos + canais distintos" -> "802.1D" [color=red]
"Identificação dos cabos e pontos" [shape=plaintext,fontcolor=red] "Armário principal" -> "Identificação dos cabos e pontos" [color=red] "Armário de telecom" -> "Identificação dos cabos e pontos" [color=red] "Área de trabalho" -> "Identificação dos cabos e pontos" [color=red] "Identificação dos cabos e pontos" -> "802.1q" [color=red,fontcolor=red,label="por porta"]
"Ativos de rede" [shape=plaintext,fontcolor=blue] "Armário principal" -> "Ativos de rede" [color=blue] "Armário de telecom" -> "Ativos de rede" [color=blue] "Ativos de rede" -> "802.1D" [color=blue] "Ativos de rede" -> LACP [color=blue] "Ativos de rede" -> "802.1x" [color=blue] "Ativos de rede" -> "802.1q" [color=blue] "Ativos de rede" -> "802.1p" [color=blue]
"Armário principal" -> LACP [color=green,fontcolor=green,label="Servidores"] }
</graphviz>
Resultado: plano de ação
- 802.1q: segmentação da rede.
- VLAN administrativa: 1.
- Guest VLAN: uso temporário, durante o processo de autenticação.
- Padrões de numeração de acordo com o usuário.
- 802.1p: marcação de pacote para qualidade de serviço.
- Altíssima prioridade: VLAN de mídia (VoIP/vídeo).
- Prioridade regular: demais VLANs.
- 802.11: implementação de rede sem fio única (mesmo SSID).
- Em áreas de sobreposição de sinal, adotar alternância dos canais limítrofes(1-6-11).
- Criptografia WPA2-AES.
- AAA: Radius.
- Autenticação centralizada em base de usuários única.
- 802.1x: EAP-TTLS.
- Autorização baseada na VLAN.
- Auditoria de tráfego externo.
- Autenticação centralizada em base de usuários única.
- LACP: balanceamento de carga com redundância de enlace.
- MSTP: Prevenção de loops.
- Definição da hirarquia dos switches.
17/03 - 22/03: Camada de Rede
- 17/03: rápida discussão sobre o uso de IPv4 e IPv6 na instituição - devido a apresentação dos pré-projetos do atual TCC II.
- 22/03: proposto o modelo de dois firewalls para criar duas categorias de rede.
Resultado: plano de ação
- Lan interna com apenas os serviços locais para clientes exclusivamente internos. Trabalhará apenas com IPs internos: faixa 172.16.0.0/12.
- DMZ com os serviços de clientes internos e externos. Usará IPs externos da faixa da RNP: 200.135.37.64/26.
- BDs e Diretórios: rede de acesso controlado, onde apenas os servidores terão acesso aos serviços de diretório e de bancos de dados, ambos utilizados por máquinas da LAN interna e da DMZ.
graph Rede { splines=true rankdir=LR
Internet [shape=plaintext] FW1 [shape=Mrecord,label="1o. Firewall",style=filled, fillcolor="#FFFF66"] DMZ [shape=record,label="<0>DMZ|<1>HTTP|<2>DNS|<3>SIP"] FW2 [shape=Mrecord,label="2o. Firewall",style=filled, fillcolor="#FF6666"] BD [shape=record,label="<0>BDs e Diretórios|<1>LDAP|<2>SQL"] LAN [shape=record,label="<0>LAN interna|<1>DHCP|<2>SMB|<3>CUPS|<4>RADIUS"]
Internet -- FW1 [color=blue] FW1 -- DMZ:0 [color=blue] FW1 -- FW2 [color=blue] FW2 -- BD:0 [color=blue] FW2 -- LAN:0 [color=blue] }
</graphviz>24/03 - 31/03: Camada de Aplicação: Facilitadores
- 24/03: antes de começar a falar sobre serviços propriamente, foram revistos alguns conceitos de sistemas operacionais - alguns com mais de 30 anos e ainda em uso. Depois, focou-se em processos especiais, os daemons, e sua aplicação nos serviços locais e de rede. Particularmente, três tipos serviços foram comentados (e serão vistos em detalhes na próxima aula):
- Rotinas: várias ações podem e devem ser automatizadas em ambientes complexos como sistemas operacionais (multiusuário, multiprocesso e multidados). Portanto, uma condição essencial para o funcionamento desses sistemas modernos são as tarefas periódicas automatizadas: manutenção, atualização, reciclagem, etc.. Uma implementação nos sistemas UNIX é o cron.
- Auditoria: embora ainda seja prematuro usar o termo auditoria em sua plenitude, podemos já entender o sistema multiusuário como um ambiente em que é preciso monitorar o ambiente para evitar sobrecarga e abusos. Uma das soluções para essa demanda é o Syslog.
- Hora certa: agendar tarefas e auditar um sistema são dois exemplos em que a hora certa é condição essencial para o seu bom funcionamento. Historicamente, o protocolo NTP tem sido largamente utilizado para sicronizar relógios em rede. Tem-se, portanto, a primeira relação de dependência entre os serviços:
digraph Serviços { subgraph clusterRede { label="Rede" NTP [shape=Mrecord]
subgraph clusterSO { label="Sistema Operacional" Cron [shape=Mrecord] Syslog [shape=Mrecord] } } NTP -> Cron NTP -> Syslog }
</graphviz>* 29/03: visão mais detalhada dos 3 serviços mencionados na aula anterior, associando pela primeira vez sistemas operacionais e redes de computadores.
- 31/03: visto o protocolo DHCP e suas interrelações com outros protocolos. Atualizada a dependência entre os serviços:
digraph Serviços { subgraph clusterRede { label="Rede" DHCP [shape=Mrecord] NTP [shape=Mrecord]
subgraph clusterSO { label="Sistema Operacional" Cron [shape=Mrecord] Syslog [shape=Mrecord] } } DHCP -> NTP NTP -> Cron NTP -> Syslog }
</graphviz>Resultado: implementação
A primeira tarefa prática da disciplina consiste em implementar, na máquina virtualizada particular:
- Configuração da segunda interface de rede Ethernet para operar no modo trunking, habilitando desde já as VLANs 1 (administrativa) e 100 (Guest VLAN), as quais serão usadas em (futuras) aplicações nesta disciplina.
- Para a VLAN 1, deve-se utilizar a sub-rede 10.0.0.0/28, seguindo a mesma ordem de endereçamento da primeira interface: primeiro IP para a primeira máquina virtualizada e assim por diante.
- Manter sincronizada a hora certa com o servidor ger20111.sj.ifsc.edu.br em regime integral.
- Verificar, periodicamente, se o serviço NTP está rodando. Caso não esteja, deve-se (re)iniciá-lo, gerando em seguida um registro no sistema (log) notificando a ação automatizada. Por fim, deve estar disponível, na linha de comandos, um script shell denominado hora que listará:
- Quantas vezes o relógio foi ajustado no dia corrente;
- Quantas vezes o serviço apresentou problemas e foi (re)iniciado no mês corrente.
Essa tarefa será avaliada durante todo o perído entre os dias 10/04/2011 e 20/04/2011. Poderão ser realizadas várias inspeções, a fim de comprovar a sua disponibilidade. Saiba qual é o peso dessa tarefa no conceito final.
05/04 - 28/04: Camada de Aplicação: Diretórios
- 05/04: vistos os conceitos básicos de diretórios e aplicados em DNS como exemplo de serviço de nomes:
- Estrutura de árvore.
- Domínios e zonas.
- Servidores de nomes.
- Autoridade e delegação de autoridade.
- Registros.
digraph Serviços { subgraph clusterRede { label="Rede" DHCP [shape=Mrecord] DNS [shape=Mrecord] NTP [shape=Mrecord]
subgraph clusterSO { label="Sistema Operacional" Cron [shape=Mrecord] Syslog [shape=Mrecord] } } DHCP -> DNS DHCP -> NTP DNS -> NTP NTP -> Cron NTP -> Syslog }
</graphviz>- 07/04: continuação dos trabalhos sobre DNS, destacando os tempos de vida útil dos registros publicados nos domínios e sua replicação/cache nos outros servidores.
- 12/04: devido a falha elétrica no campus, não houve aula de laboratório.
- 14/04: introdução a LDAP: conceitos de árvore e estrutura de diretório, história do X.500, a tríade esquema, árvore de diretórios e acesso (de controle de acesso usando ACLs a consultas).
digraph Serviços { subgraph clusterRede { label="Rede" DHCP [shape=Mrecord] DNS [shape=Mrecord] NTP [shape=Mrecord] LDAP [shape=Mrecord]
subgraph clusterSO { label="Sistema Operacional" Cron [shape=Mrecord] Syslog [shape=Mrecord] } } DHCP -> DNS DHCP -> NTP DNS -> NTP DNS -> LDAP NTP -> Cron NTP -> Syslog }
</graphviz>- 19/04: conversa com André Luís Gobbi Sanches sobre plano de carreira.
- 26/04: visita ao Seminário de Pesquisa, Ensino e Extensão no campus Florianópolis.
- 28/04: vista a árvore de diretórios do IF-SC São José como estudo de caso.
Atividades Práticas
- Utilizando a ferramena dig ou equivalente, procure pelos valores dos registros SOA e NS dos seguintes domínios:
- sj.ifsc.edu.br.
- ifsc.edu.br.
- mec.gov.br.
- Realize as mesmas consultas de forma iterativa, iniciando nos servidores raiz (root servers).
- Qual é o nome completo dos professores de Tele. Dica: eles pertencem ao grupo (posixGroup) sj-tele.
- É possível utilizar o serviço LDAP ao invés de DNS para associar nomes de computadores a endereços IP? Como isso é possível?
03/05: Camada de Aplicação: Bancos de Dados
Assim como foi visto que nos serviços de diretórios o conceito de organização dos dados em árvore é muito importante, aqui a organização se dá da seguinte maneira:
- Tem-se as base de dados, grandes coleções de dados;
- Em uma base de dados, há tabelas;
- Em uma tabela, há registros de dados;
- Um registro de dados pode conter uma referência para outro registro em outra tabela.
Tem-se, portanto, relações entre os dados armazenados.
<graphviz> digraph BD { rankdir="LR"
subgraph clusterBD { label="Base de Dados" t1 [shape=Mrecord,label="<0>Tabela 1|<1>registro 1|<2>registro 2|<3>...|<4>registro 3"] t2 [shape=Mrecord,label="<0>Tabela 2|<1>registro 1|<2>registro 2|<3>...|<4>registro 3"] t3 [shape=Mrecord,label="<0>Tabela 3|<1>registro 1|<2>registro 2|<3>...|<4>registro 3"] }
t1:2 -> t2:1 [color=red] t2:1 -> t3:4 [color=red] } </graphviz>
Além dos dados e suas relações, é importante também outras funcionalidades agregadas, como controle de acesso, registro de ações críticas e outros elementos que formam, ao final, um SGBD.
digraph Serviços { subgraph clusterRede { label="Rede" DHCP [shape=Mrecord] DNS [shape=Mrecord] NTP [shape=Mrecord] LDAP [shape=Mrecord] SGBD [shape=Mrecord]
subgraph clusterSO { label="Sistema Operacional" Cron [shape=Mrecord] Syslog [shape=Mrecord] } } DHCP -> DNS DHCP -> NTP DNS -> NTP DNS -> LDAP DNS -> SGBD NTP -> Cron NTP -> Syslog }
</graphviz>Estudo de Caso: MySQL
A facilidade de implementação e de configuração tornam o MySQL bastante atrativo para aplicações de pequeno porte. No nosso [#Ambiente de Produção|ambiente de produção], Debian GNU/Linux 6.0, a instalação do servidor é bastante facilitada:
aptitude install mysql-server
Há vários clientes disponíveis, inclusive para CLI:
aptitude install mysql-client
Antes do primeiro acesso, é preciso entender que no MySQL o processo de autenticação se dá pela combinação de três valores:
- Usuário;
- Senha;
- Endereço de máquina ou IP de origem.
Na configuração de fábrica, o super-usuário root possui acesso local (localhost) com uma senha definida no ato da instalação (comando aptitude install mysql-server):
mysql -h localhost -u root -p
Cabe destacar que esse usuário root é um usuário interno da aplicação, não havendo qualquer relação ou privilégio compartilhado com o administrador do sistema Linux.
Uma vez autenticado, passa-se à fase de autorização, que verifica e valida quais ações são permitidas para o usuário com a sessão em curso. Como o usuário root possui amplos privilégios, esse pode listar todas as base de dados:
SHOW DATABASES;
ou mesmo as tabelas de uma base em particular. Abaixo, são listadas as tabelas da base mysql:
USE mysql;
SHOW TABLES;
Essa base é de extrema importância, pois ela é utilizada, entre outras coisas, para armazenar os dados de autenticação e autorização ao próprio serviço - atenção às tabelas mysql.user e mysql.db!
USE mysql;
SELECT * FROM user;
SELECT * from db;
Para quem já está familizarizado com SQL, acima foram apresentados os registros completos das tabelas mysql.user e mysql.db, respectivamente.
Assim, conclui-se que para criar um usuário ou autorizar um para acesso a banco(s) de dados, basta utilizar comandos SQL para manipular tais tabelas. Também é possível, alternativamente, utilizar comandos específicos para autenticação e autorização:
CREATE DATABASE banco;
GRANT ALL PRIVILEGES ON banco.* TO 'joao'@'localhost' IDENTIFIED BY 'codigoSecreto';
FLUSH PRIVILEGES;
Acima, em ordem:
- Criação de um banco de dados denominado banco.
- Criação de um usuário denominado joao, associação a uma senha codigoSecreto e autorizado o acesso à base banco através do endereço localhost.
- Remoção da cache do banco de dados, acelerando a aplicação de autenticação e autorização mencionados anteriormente.
Essas são, portanto, as funções que competem ao administrador de sistema em relação a um SGBD. A gestão do conteúdo fica a cargo do DBA.
05/05 - 26/05: Camada de Aplicação: Compartilhamento
- 05/05: instalação e configuração básica de servidor Web. Como estudo de caso foi utilizado o Apache, com fatia de mercado global superior a 60%. É importante compreender o funcionamento e cabeçalho do HTTP versão 1.1 para configurar devidamente o serviço:
- Endereços virtuais (virtual hosts): uma vez que o cabeçalho HTTP contém o endereço de destino, pode-se criar vários endereços virtuais no Apache, os VirtualHosts. Eles operam de forma independente. Além disso, o Apache também pode discriminar o acesso por IP ou mesmo porta de destino, criando espaços distintos.
- Mapeamentos entre sistema de arquivos e URL (URL mapping): assim como cada endereço virtual tem seu diretório raiz (DocumentRoot), é possível mapear um diretório específico (alias) ou mesmo a diretório pessoal de um usuário (user).
- Expansões com módulos (DSO): além das funções internas do servidor Apache, há as expansões para os mais diversos fins: autenticação, SSL, CGI e integração com aplicações em várias linguagens (C, PHP, Python, Java e outras).
- 10/05: Prova-relâmpago
- Duração: 1h
- Tarefa: instalação de blog no ambiente de produção.
- Requisitos de serviço (blog):
- 1 post novo publicado.
- 1 página nova publicada.
- 1 arquivo carregado (upload) via ferramenta interna (do blog).
- Requisitos de sistema (S.O.):
- O banco de dados pode prover acesso somente a um usuário com senha através de rede interna (loopback).
- Controle de acesso: o código PHP deve ter apenas acesso de leitura ao usuário do servidor Web. Quanto aos diretórios onde é permitida a escrita, somente o usuário do servidor Web pode ler e modificá-los.
- Backups periódicos (mínimo 2 e máximo 7):
- Semanal: código PHP.
- Diário, de: base de dados e arquivos carregados (uploads).
- 12/05: instalação de aplicação Web 2.0.
- 17/05: configuração de uma autenticação básica em HTTP.
- 19/05: configuração de transmissão segura com SSL/TLS, a qual foi posteriormente combinada com a autenticação básica.
digraph Serviços { subgraph clusterRede { label="Rede" DHCP [shape=Mrecord] DNS [shape=Mrecord] NTP [shape=Mrecord] LDAP [shape=Mrecord] SGBD [shape=Mrecord] HTTP [shape=Mrecord,style=filled, fillcolor="#FFFF66"]
subgraph clusterSO { label="Sistema Operacional" Cron [shape=Mrecord] Syslog [shape=Mrecord] } } DHCP -> DNS DHCP -> NTP DNS -> NTP DNS -> LDAP DNS -> SGBD DNS -> HTTP LDAP -> HTTP SGBD -> HTTP NTP -> Cron NTP -> Syslog }
</graphviz>- 24/05: apresentação do serviço Samba no modo grupo de trabalho. Uma experiência interessante já foi documentada neste wiki, tratando na integração entre HTTP (Internet) e SMB (LAN).
- 26/05: adequação do serviço Samba para operar no modo domínio.
digraph Serviços { subgraph clusterRede { label="Rede" DHCP [shape=Mrecord] DNS [shape=Mrecord] NTP [shape=Mrecord] LDAP [shape=Mrecord] SGBD [shape=Mrecord] HTTP [shape=Mrecord,style=filled, fillcolor="#FFFF66"] SMB [shape=Mrecord,style=filled, fillcolor="#FFFF66"]
subgraph clusterSO { label="Sistema Operacional" Cron [shape=Mrecord] Syslog [shape=Mrecord] } } DHCP -> DNS DHCP -> NTP DNS -> NTP DNS -> LDAP DNS -> SGBD DNS -> HTTP DNS -> SMB LDAP -> HTTP LDAP -> SMB SGBD -> HTTP NTP -> Cron NTP -> Syslog }
</graphviz>Estudo de Caso: Joomla
O Joomla é um exemplo de CMS bastante popular, sendo utilizado inclusive no portal do Instituto. Sua estrutura é bastante semelhante à maioria dos CMSs mais populares: linguagem de programação interpretada e armazenamento das informações em banco de dados.
graph ArqWeb { subgraph clusterCliente { label=Cliente Usuário [shape=plaintext] Navegador [shape=Mrecord]
Usuário -- Navegador }
subgraph clusterServidor { label=Servidor "Servidor Web" [shape=Mrecord,style=filled, fillcolor="#FFFF66"] "Interpretador" [shape=Mrecord] "Banco de Dados" [shape=Mrecord]
"Servidor Web" -- "Interpretador" [label="DHTML",color=red,fontcolor=red] "Interpretador" -- "Banco de Dados" [label="Conteúdo",color=red,fontcolor=red] }
Navegador -- "Servidor Web" [label="Conexão HTTP",color=blue,fontcolor=blue] }
</graphviz>A instalação é realizada em duas etapas: sistema e ambiente Web. No sistema, é preciso criar um banco de dados específico, instalar o suporte à linguagem interpretada PHP e integrá-los ao servidor Web, no caso o Apache.
Como já há um banco de dados instalado, basta acessá-lo para criar um novo banco com acesso restrito à aplicação Web local:
mysql -u root -p mysql
usando os comandos SQL:
CREATE DATABASE joomla;
GRANT ALL PRIVILEGES ON joomla.* TO 'usuario'@localhost IDENTIFIED BY 'senha';
FLUSH PRIVILEGES;
QUIT;
Em seguida, a instalação do PHP, hoje na versão 5, e sua integração ao MySQL e Apache:
aptitude install php5 php5-mysql
service apache2 restart
A própria instalação do PHP se encarrega de ativar o módulo dentro do Apache, o qual também pode ser feito da seguinte forma:
a2enmod php5
service apache2 restart
Por último, a configuração de um ambiente reservado ao Joomla com algumas particularidades:
vi /etc/apache2/conf.d/joomla.conf
O arquivo terá o seguinte conteúdo:
<Directory /var/www/cms> # Sem configuração prévia Options None # Porém, permite que a aplicação proteja algum diretório # com diretivas contidas em arquivo com o nome ".htaccess". AllowOverride AuthConfig # Controle de acesso por IP: livre Order allow,deny Allow from all </Directory>
Sempre que modificar a configuração do Apache, é preciso no mínimo aplicar esse valores. O comando reload mantém as conexões abertas e aplica os novos valores:
service apache2 reload
Por último, o código PHP. No sítio do Joomla, a última versão disponível é a 1.6.3. Os passos a seguir descrevem o descarregamento do código até a aplicação de permissões mínimas para operação - considerando que o Apache está rodando com o usuário de sistema www-data (comum nos sistemas baseados em Debian:
cd /var/www
mkdir cms
cd cms
wget http://joomlacode.org/gf/download/frsrelease/14659/64120/Joomla_1.6.3-Stable-Full_Package.zip
unzip Joomla_1.6.3-Stable-Full_Package.zip
rm Joomla_1.6.3-Stable-Full_Package.zip
chown -R www-data:www-data .
find . -type d -exec chmod 500 {} \;
find . -type f -exec chmod 400 {} \;
touch configuration.php
chmod 600 configuration.php
chmod 700 logs
chmod 700 tmp
O restante da configuração segue em ambiente Web: http://<servidor>/cms.
Cenário: Autenticação básica sobre SSL/TLS
A RFC 2617 define a autenticação básica e digest para sessões HTTP. Contudo, como ela ocorre com texto puro, ipsis literis, é preciso proteger tal tráfego. Assim, faz-se necessário utilizar outra porta com transmissão segura via SSL/TLS: HTTPS (443/TCP).
No servidor Web apache 2, a autenticação se dá por diretório mapeado (DocumentRoot, Directory) ou por URL (Location). Abaixo um exemplo do diretório /home/documentos, criado e compartilhado sob autenticação básica. Nos sistemas baseados em Debian, o dono do processo-serviço é www-data e grupo com mesmo nome.
Primeiro, a criação do diretório:
cd /home
mkdir documentos
chmod 700 documentos
chown www-data:www-data documentos
Em seguida, o compartilhamento com autenticação básica. O módulo de autenticação já vem ativado - e pode ser confirmado com: apache2ctl -M.
cd /etc/apache2/conf.d/
vi documentos
O arquivo conterá o seguinte conteúdo:
<Directory /home/documentos/> Options Indexes AllowOverride None Order allow,deny Allow from all AuthType Basic AuthName "Acesso restrito" AuthUserFile /etc/apache2/htpasswd-senhas Require valid-user </Directory>
O arquivo de senhas informando acima, /etc/apache2/htpasswd-senhas, pode ser criado com a ferramenta htpasswd:
htpasswd -c -m /etc/apache2/htpasswd-senhas <usuário>
Depois deve-se, pois, proteger esse arquivo:
chmod 640 /etc/apache2/htpasswd-senhas
chown root:www-data /etc/apache2/htpasswd-senhas
Após reiniciar o serviço Apache 2, o diretório será visível via HTTP somente com o par <usuário>:<senha>.
Agora, a segunda etapa do processo: a autenticação somente com SSL/TLS. Outro facilitador, a2ensite pode ser usado para ativar o site com SSL:
a2ensite default-ssl
Após, cria-se o certificado personalizado e autoassinado (validade: 4 anos) e informado na configuração do Apache 2:
openssl req -new -x509 -days 1460 -nodes -out /etc/ssl/certs/apache2.pem -keyout /etc/ssl/certs/apache2.pem
chown root:www-data /etc/ssl/certs/apache2.pem
chmod 640 /etc/ssl/certs/apache2.pem
vi /etc/apache2/sites-enabled/default-ssl
e modificando somentes as linhas:
SLCertificateFile /etc/ssl/certs/apache2.pem SSLCertificateKeyFile /etc/ssl/certs/apache2.pem
Por fim, ativa-se o módulo ssl:
a2enmod ssl
e força o usuário, quando for utilizar HTTP para acessar tal diretório, a ser encaminhado para HTTPS:
vi /etc/apache2/sites-enabled/000-default
adicionando a seguinte linha dentro do escopo <VirtualHost>:
RedirectMatch ^/documentos(.*)$ https://<servidor>/$1
onde servidor é nome completo (FQDN) do servidor Web. Para terminar, resta apenas reiniciar o serviço:
service apache2 restart
31/05 - 09/06: Camada de Aplicação: Comunicação
- 31/05: visto, em sala de aula, os protocolos SMTP para envio de emails e POP3 e IMAP para recebimento.
- 02/06: atividade em laboratório, envolvendo os protocolos SMTP e IMAP para envio e recebimento de emails utilizando aplicativos específicos (Outlook, Thunderbird, Evolution e outros) e webmail (adotado o aplicativo Roundcube por questões didáticas). A atividade envolverá:
- NTP: para compor a hora certa no cabeçalho SMTP, HTTP e outros;
- DNS: para comunicação interdomínio.
- SGBD: para armazenamento de dados do usuário.
- SMTP: para envio dos emails.
- POP3 ou IMAP: para recebimento e leitura dos emails, seja em aplicativo específico ou webmail.
- HTTP: para veiculação do webmail.
digraph Serviços { subgraph clusterRede { label="Rede" DHCP [shape=Mrecord] DNS [shape=Mrecord] NTP [shape=Mrecord] LDAP [shape=Mrecord] SGBD [shape=Mrecord] HTTP [shape=Mrecord,style=filled, fillcolor="#FFFF66"] SMB [shape=Mrecord,style=filled, fillcolor="#FFFF66"] SMTP [shape=Mrecord] IMAP [shape=Mrecord] Webmail [shape=Mrecord,style=filled,fillcolor="#66FF66"]
subgraph clusterSO { label="Sistema Operacional" Cron [shape=Mrecord] Syslog [shape=Mrecord] } } DHCP -> DNS DHCP -> NTP DNS -> NTP DNS -> LDAP DNS -> SGBD DNS -> HTTP DNS -> SMB DNS -> SMTP DNS -> IMAP LDAP -> HTTP LDAP -> SMB LDAP -> SMTP LDAP -> IMAP SGBD -> HTTP SGBD -> Webmail HTTP -> Webmail SMTP -> Webmail IMAP -> Webmail NTP -> Cron NTP -> Syslog }
</graphviz>- 09/06: Prova.
- Genérico: Crie o domínio <sobrenome>.com.br, onde o servidor principal, além de deter a autoridade sobre o domínio, ainda deverá fazer referência (nome, A, ou apelido, CNAME) aos seus serviços disponibilizados: NTP, SMB, HTTP, SMTP e IMAP.
- Sistema: Crie usuários de A a M.
- SMB: Compartilhe o diretório /home/arquivos para os usuários que são vogais. Somente eles podem ter acesso de leitura ou de escrita ao conteúdo.
- SMB: Compartilhe o diretório /var/www/sites com permissão de leitura+escrita para os usuários de F a M e apenas permissão de leitura para A e B.
- SMB: Compartilhe o diretório /opt com permissão apenas de leitura para todos os usuários, de A a M.
- HTTP: compartilhe o diretório /home com permissão de leitura aos usuários de B a F.
- HTTP: compartilhe o diretório /var/www/arquivos com permissão de leitura e de escrita para todos os usuários (A a M).
- Publique um serviço de Webmail funcional. Teste-o com o envio local. Não pode ser o serviço Roundcube.
- Sistema: monitore periodicamente o sistema em busca de arquivos com as seguintes extensões: MP3 e AVI. Liste-os e envie por email ao usuário root e apague-os em seguida.
- Sistema: monitore periodicamente o espaço em disco nas partições. Caso exceda o limite de 90% de ocupação, envie um email ao usuário root notificando-o.
- Sistema: monitore periodicamente os diretórios compartilhados em SMB e HTTP por arquivos com as extensões COM e PIF, a fim de identificar algum vírus em potencial. Se achar algum arquivo, mova-os para um diretório de quarentena e avise o usuário root sobre os mesmos para análise posterior.
14/06 - 28/06: Camada de Aplicação: Gerência da Rede
- 14/06: apresentação das 5 gerências de rede: Monitoramento, Contabilização, Desempenho, Configuração e Segurança. Foi dada ênfase ao protocolo SNMP para Monitoramento e Contabilização - veja publicação da RNP 1 e 2.
- 16/06: instalação de agente e gerente SNMP para primeiras avaliações do protocolo para monitoramento e contabilização do ambiente de rede.
Cenário: Agente e Gerente SNMP em ambiente Linux
O sistema utilizado é o Debian GNU/Linux 6.0. Algumas modificações foram feitas por questões legais - licenciamento dos documentos, mais especificamente as MIBs (Management Information Base).
Agente
No caso do agente, como esse é bastante simples - fazendo jus ao nome do protocolo - deve-se instalar o pacote e depois configurá-lo:
apt-get install snmpd
vi /etc/snmp/snmpd.conf
Uma configuração bastante sucinta deve conter:
- Comunidade: tipo de acesso (leitura ou leitura+escrita) e nome da comunidade;
- Localização do equipamento: endereço o mais descritivo possível;
- Responsável: nome e formas de contato;
- Funcionalidades: em que camadas o sistema opera.
A seguinte configuração:
rocommunity ger sysLocation Laboratório de Redes de Computadores II - IFSC campus São José SysContact "Ederson Torresini" <etorresini@ifsc.edu.br> sysServices 72
indica um agente da comunidade ger com permissão única de leitura a todos os atributos (rocommunity), localizado no Lab. de Redes II (SysLocation), aos cuidados do prof. Ederson (sysContact) e que opera em todas as camadas do modelo TCP/IP (sysServices). Feito isso, basta reiniciar o serviço:
/etc/init.d/snmpd restart
Gerente
Para o gerente, é extremamente interessante possuir localmente as MIBs e os comandos básicos (CLI), a fim de testar os atributos (localização, tipo e faixa de valores possíveis). Nesse caso, deve-se instalar ambos os pacotes, o primeiro com os comandos e o seguindo o qual descarrega e atualiza as MIBs a partir da Internet:
apt-get install snmp
apt-get install snmp-mibs-downloader
download-mibs
Em seguida, deve-se remover a referência no arquivo de configuração /etc/snmp/snmp.conf para fazer pleno uso das MIBs inclusive em linha de comando, conforme a Wiki do Debian:
sed -i 's/^mibs ://g' /etc/snmp/snmp.conf
Assim, será possível realizar ações em linha de comando, como por exemplo operações GET:
snmpget -c ger -v 2c localhost sysLocation.0
snmpget -c ger -v 2c localhost sysContact.0
snmpget -c ger -v 2c localhost sysServices.0
Ou mesmo uma varredura em toda a árvore de atributos, utilizando para tal a operação GETNEXT (sequencial):
snmpwalk -c ger -v 2c localhost .1
O próximo passo é escolher um gerente SNMP que atenda às necessidades. Em código aberto, há disponíveis:
Por questões didáticas, e pela facilidade de administração (Web), adotaremos o Cacti, cuja documentação é bem objetiva e funcional. Uma vez o sistema no ar, é possível passar direto para o cadastro dos "alvos" e listar quais informações serão coletadas periodicamente.
Caso o erro "[NOT FOUND] RRDTool Binary Path: The path to the rrdtool binary." apareça durante a configuração do Cacti execute:
apt-get install libdbi0 librrd4
Cenário: Gerente de Monitoramento baseado em Shell Script
Para entender a primeira gerência, de monitoramento, construa um shell script que realiza sequencialmente as seguintes operações:
- Leitura, por linha de comando, de um alvo por nome ou endereço IP.
- Teste do próprio gerente:
- Camada de física/enlace: interface Ethernet ativa (up).
- Camada de rede: endereçamento IP e rota-padrão.
- Camada de transporte e de aplicação: download.
- Uma vez garantida a conectividade do gerente, parte-se para o "alvo". Primeiramente, teste de alcançabilidade (camada de rede) com ICMP. Em seguida, parte-se para as aplicações: o programa deverá testar, além do serviço no ar (porta aberta), também a sua eficiência: o serviço deve operar normalmente:
- DNS: serviço rodando e pelo menos 3 consultas a registros com resposta válida (SOA, NS e A).
- SGBD: serviço rodando e consulta (SELECT) com pelo menos 1 registro.
- LDAP: serviço rodando e consulta (search) com pelo menos 1 registro.
- NTP: serviço rodando e sincronização válida de relógio.
- SMB: serviço rodando e listagem dos compartilhamentos.
- HTTP: serviço rodando e pelo menos 2 arquivos descarregados (integralmente e parcialmente via HTTP/1.1) com sucesso.
- SMTP: serviço rodando e teste de envio de email. Dica: comando mail que integra o pacote mailutils.
- Ao final, o programa deverá emitir um relatório com a lista de testes realizados com e sem sucesso.
#!/bin/bash
# Variáveis
ETH="eth0"
GOOGLE="74.125.234.84"
# Funções
local_enlace(){
echo -n "Camada de enlace..."
ifconfig ${1} | grep -q UP
ENLACE=$(echo $?)
if [ "${ENLACE}" = "0" ]
then
echo " OK."
else
echo "Falha geral: camada de enlace."
# Programa falha no primeiro testo. Retorna "1".
exit 1
fi
}
local_rede(){
echo "- Camada de rede:"
echo -n " - Endereçamento..."
IP=""
IP=$(ifconfig ${1} | grep inet | head -n 1 | cut -d : -f 2 | cut -d B -f 1)
if [ "${IP}" != "" ]
then
echo " OK."
else
echo " Falha geral: interface ${ETH}."
exit 2
fi
echo -n " - Roteamento..."
ROTA=0
ROTA=$(route -n | grep -q ^0.0.0.0 && echo 1)
if [ "${ROTA}" = "1" ]
then
echo " OK."
else
echo " Falha geral: rota-padrão."
exit 3
fi
}
generico_http(){
echo -n "- HTTP..."
GET=0
GET=$(wget http://${1}/ -O - 2>&1 |grep -q "200 OK" && echo 1)
if [ "${GET}" = "1" ]
then
echo " OK."
else
echo " Falha geral: requisição HTTP."
exit 4
fi
}
alvo_icmp(){
echo -n "Testando alcançabilidade ao alvo..."
PORCENTAGEM=$(ping -c 2 ${1} | grep received | cut -d , -f 3 | cut -d % -f 1)
if [ "${PORCENTAGEM}" -le "50" ]
then
echo " OK."
else
echo " Falha geral: ICMP (echo request/reply)."
exit 5
fi
}
alvo_dns(){
echo "- Domínio DNS ${dominio}:"
for registro in SOA NS MX A
do
RESPOSTA="0"
echo -n " - Registro ${registro}..."
RESPOSTA=$(dig @${1} ${registro} ${2} | grep -q "ANSWER" && echo 1)
if [ "${RESPOSTA}" = "1" ]
then
echo " OK."
else
echo " falhou."
fi
done
}
# Programa Principal
#
# Validação da entrada de dados
if [ "${2}" = "" ]
then
echo "Use: ${0} (nome ou IP do alvo) (domínio)"
exit 255
fi
# Teste local: enlace, rede e aplicação
echo "Testes locais:"
local_enlace ${ETH}
local_rede ${ETH}
generico_http ${GOOGLE}
#
# Testes no alvo
echo
echo "Testes no alvo:"
alvo_icmp ${1}
alvo_dns ${1} ${2}
generico_http ${1}
# Sugestão: testar as aplicações com netcat :-)
# Programa rodou plenamente com sucesso. Retorna "0".
exit 0
Projeto Final
Em acordo entre professor e alunos, foi modificado método da avaliação final de prova prática para projeto com defesa oral.
Sobre o cenário
O projeto trata da implementação de um cenário hipotético - e bastante comum no Brasil:
graph Empresa { Internet [shape=plaintext] 1 [shape=circle] 2 [shape=circle] 3 [shape=circle] subgraph clusterMatriz { label=Matriz Servidor_M [label=Servidor,shape=Mrecord] } subgraph clusterFilial { label=Filial Servidor_F [label=Servidor,shape=Mrecord] } Servidor_M -- Internet Servidor_F -- Internet Internet -- 1 Internet -- 2 Internet -- 3 }
</graphviz>Na figura acima veem-se, pois, os três eixos que compõem a organização:
- Matriz;
- Filial;
- "n" funcionários em trânsito (representados 3 deles).
Requisitos do Sistemas
- Hora certa: o servidor da matriz deverá alinhar seu relógio com outros da Internet para, em seguida, permitir o alinhamento pelas estações de trabalho na matriz, servidor da filial e esse para as estações da sua localidade. Desejável o uso de criptografia e/ou senha de controle.
- Domínio unificado: hierarquia entre o domínio da matriz e da filial, requerendo para tal delegação de subdomínio entre as duas localidades.
- Cadastro de usuários único: seja na matriz, na filial ou em trânsito, deverá haver apenas um cadastro único de usuários e válido em qualquer localidade para todos os serviços de autenticação. Desejável o uso de serviço em rede como LDAP.
- Compartilhamento de arquivos local e global: tanto na matriz quando na filial devereá haver um repositório local de arquivos, os quais de interesse restrito a essa localidade. Além disso, deverá haver em paralelo, de forma complementar, um repositório global disponível a todos (matriz, filial e em trânsito). Obrigatório o uso de criptografia e esquemas de autenticação e de autorização.
- Sistema de comunicação por texto, voz ou vídeo entre todos os funcionários das localidades. Qualquer um destes sistemas é válido e pode compor a solução final: correio eletrônico, mensagem instantânea e VoIP. Para cada sistema, deverá estar disponível a cada funcionário uma solução utilizando aplicação dedicada e em versão Web (exemplo: aplicação cliente de correio eletrônico e webmail).
- Gerência centralizada de rede: monitoramento e contabilização com interface Web disponível na Internet. Obrigatório o uso de criptografia, autenticação e autorização.
- Backup local e global, condizente com os serviços de compartilhamento de arquivos e de comunicação, armazenando toda e qualquer informação possível relacionada a esses serviços oferecidos. Além disso, deverão também ser salvaguardados os arquivos de configuração dos servidores das duas localidades.
- Segurança na matriz e na filial em pelo menos duas camadas: Rede (filtro de pacotes) e Aplicação (proxy).
Implementação
Em duplas, matriz e filial, no ambiente de produção.