Gerência de Redes (diário 2011-1)

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:

1. Análise de planta baixa do projeto original e expansões.
   1. Projeto elétrico, de preferência circuitos redundantes. [Disponibilidade]
   2. Cabeamento estruturado e seções.
      1. Entrada de facilidades: passivos de rede.
      2. Armário principal: passivos e ativos de rede. Requer cuidados quanto a energização e climatização dos ativos. [Segurança]
      3. Cabeamento vertical: passivos de rede.
      4. 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]
      5. Cabeamento horizontal: passivos de rede.
      6. Área de trabalho: passivos e ativos de rede (terminais). Pode requerer cuidados quanto a energização e climatização dos ativos.
2. Manutenção
   1. Bandejas e dispositivos de suporte do cabeamento.
   2. Organização física dos cabeamentos rígido (não visível) e flexível (visível).
   3. Padrão global de identificação de cabos e de pontos.
      1. Identificação de cabos.
      2. Identificação de pontos.
         1. Áreas de cobertura das redes sem fio.
            1. Sobreposição das áreas com canais/frequências distintas. [Disponibilidade]
   4. Posicionamentos dos ativos nos armários.
      1. Conexões cruzadas aos pares, viabilizando canais físicos alternativos. [Disponibilidade]
   5. Mapeamento da demanda reprimida de pontos.
      1. Cálculo de material para lançamento de novos cabos e instalação de novos pontos.
      2. 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.

<graphviz>

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

1. 802.1q: segmentação da rede.
   1. VLAN administrativa: 1.
   2. Guest VLAN: uso temporário, durante o processo de autenticação.
   3. Padrões de numeração de acordo com o usuário.
2. 802.1p: marcação de pacote para qualidade de serviço.
   1. Altíssima prioridade: VLAN de mídia (VoIP/vídeo).
   2. Prioridade regular: demais VLANs.
3. 802.11: implementação de rede sem fio única (mesmo SSID).
   1. Em áreas de sobreposição de sinal, adotar alternância dos canais limítrofes(1-6-11).
   2. Criptografia WPA2-AES.
4. AAA: Radius.
   1. Autenticação centralizada em base de usuários única.
      1. 802.1x: EAP-TTLS.
   2. Autorização baseada na VLAN.
   3. Auditoria de tráfego externo.
5. LACP: balanceamento de carga com redundância de enlace.
6. MSTP: Prevenção de loops.
   1. 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.

<graphviz>

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:

<graphviz>

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:

<graphviz>

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.

<graphviz>

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).

<graphviz>

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:

1. Tem-se as base de dados, grandes coleções de dados;
2. Em uma base de dados, há tabelas;
3. Em uma tabela, há registros de dados;
4. 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.

<graphviz>

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:

1. Usuário;
2. Senha;
3. 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:

1. Criação de um banco de dados denominado banco.
2. 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.
3. 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.

<graphviz>

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.

<graphviz>

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.

<graphviz>

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.

<graphviz>

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.
  1. 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.
  2. Sistema: Crie usuários de A a M.
  3. 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.
  4. 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.
  5. SMB: Compartilhe o diretório /opt com permissão apenas de leitura para todos os usuários, de A a M.
  6. HTTP: compartilhe o diretório /home com permissão de leitura aos usuários de B a F.
  7. HTTP: compartilhe o diretório /var/www/arquivos com permissão de leitura e de escrita para todos os usuários (A a M).
  8. Publique um serviço de Webmail funcional. Teste-o com o envio local. Não pode ser o serviço Roundcube.
  9. 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.
  10. 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.
  11. 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:

• Cacti;
• OpenNMS;
• Nagios;
• Zabbix;
• Zenoss.

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:

1. Leitura, por linha de comando, de um alvo por nome ou endereço IP.
2. Teste do próprio gerente:
   1. Camada de física/enlace: interface Ethernet ativa (up).
   2. Camada de rede: endereçamento IP e rota-padrão.
   3. Camada de transporte e de aplicação: download.
3. 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:
   1. DNS: serviço rodando e pelo menos 3 consultas a registros com resposta válida (SOA, NS e A).
   2. SGBD: serviço rodando e consulta (SELECT) com pelo menos 1 registro.
   3. LDAP: serviço rodando e consulta (search) com pelo menos 1 registro.
   4. NTP: serviço rodando e sincronização válida de relógio.
   5. SMB: serviço rodando e listagem dos compartilhamentos.
   6. HTTP: serviço rodando e pelo menos 2 arquivos descarregados (integralmente e parcialmente via HTTP/1.1) com sucesso.
   7. SMTP: serviço rodando e teste de envio de email. Dica: comando mail que integra o pacote mailutils.
4. 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:

<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>

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.

Página principal da disciplina