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

De MediaWiki do Campus São José
Ir para: navegação, pesquisa

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

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

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.

<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.
  • 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>
  • 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:

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