Mudanças entre as edições de "Gerência de Redes (diário 2011-1)"
(337 revisões intermediárias por 2 usuários não estão sendo mostradas) | |||
Linha 12: | Linha 12: | ||
* Comunicação assíncrona e síncrona (tempo real). | * Comunicação assíncrona e síncrona (tempo real). | ||
* Espaço para troca de dados em forma de arquivos. | * Espaço para troca de dados em forma de arquivos. | ||
− | * Disponibilidade. | + | * '''Disponibilidade'''. |
− | * Segurança. | + | * '''Segurança'''. |
==Objetivo Geral== | ==Objetivo Geral== | ||
Linha 28: | Linha 28: | ||
| colspan="2" | Física || Espaço físico;<br>Climatização;<br>Energia elétrica;<br>Conectividade. || [[Projeto de Redes Metálicas e Ópticas]] || [http://www.abntcatalogo.com.br/norma.aspx?ID=993 NBR14565]. || [[#Resultado: plano de ação|Plano de ação]]. | | colspan="2" | Física || Espaço físico;<br>Climatização;<br>Energia elétrica;<br>Conectividade. || [[Projeto de Redes Metálicas e Ópticas]] || [http://www.abntcatalogo.com.br/norma.aspx?ID=993 NBR14565]. || [[#Resultado: plano de ação|Plano de ação]]. | ||
|- | |- | ||
− | | colspan="2" | Enlace || Segmentação da rede física em ''n'' lógicas;<br> | + | | colspan="2" | Enlace || Segmentação da rede física em ''n'' lógicas;<br>Redundância lógica e prevenção em ''software'' de ''loops'';<br>Prioridade para mídias. || [[Redes de Computadores II (página)|Redes de Computadores II]] || Ethernet;<br>802.11;<br>802.1p;<br>802.1q;<br>802.1X;<br>LACP;<br>STP. || [[#Resultado: plano de ação 2|Plano de ação]]. |
|- | |- | ||
− | | colspan="2" | Rede || || [[Redes de Computadores I (página)|Redes de Computadores I]]<br>[[Redes de Computadores III (página)|Redes de Computadores III]] || || | + | | colspan="2" | Rede || Atual endereçamento e roteamento da rede e transição para IPv6. || [[Redes de Computadores I (página)|Redes de Computadores I]]<br>[[Redes de Computadores III (página)|Redes de Computadores III]] || IPv4;<br>IPv6. ||[[#Resultado: plano de ação 3|Plano de ação]]. |
|- | |- | ||
− | | | + | | rowspan="6" | Aplicação || Facilitadores || Automatização nas rotinas e atribuição em rede de endereços e nomes de computadores.|| [[Redes de Computadores I (página)|Redes de Computadores I]] || Syslog;<br>NTP;<br>DHCP. || [[#Resultado: implementação|Implementação em servidor virtualizado]]. |
|- | |- | ||
− | | | + | | Diretórios || Sistemas em rede para armazenamento de informações organizadas em diretórios.|| [[Redes de Computadores I (página)|Redes de Computadores I]] || DNS;<br>LDAP. || |
|- | |- | ||
− | | | + | | Bancos de Dados || || || || |
|- | |- | ||
− | | | + | | Compartilhamento || || || || |
|- | |- | ||
− | | | + | | Comunicação || || || || |
|- | |- | ||
− | + | | Gerência de Rede || || || || | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
|} | |} | ||
</center> | </center> | ||
Linha 55: | Linha 49: | ||
===Ambiente de Teste=== | ===Ambiente de Teste=== | ||
− | * Máquinas virtuais do Lab. de Redes | + | * Máquinas virtuais do Lab. de Redes II. |
===Ambiente de Produção=== | ===Ambiente de Produção=== | ||
Linha 98: | Linha 92: | ||
|} | |} | ||
</center> | </center> | ||
+ | |||
+ | ==Método de Avaliação== | ||
+ | ([[#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 + Compartilhamento + Comunicação) * 3 +<br> | ||
+ | [[#Projeto Final|Projeto final]] * 4 =<br> | ||
+ | Somatório / 10 =<br> | ||
+ | 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== | ||
+ | * [http://wiki.softwarelivre.org/TWikiBar/WebHome Papos de Botequim]: livro do Júlio Neves sobre ''shell script'', com destaque ao bash. | ||
+ | * [http://www.shellscript.com.br/ Livro ''Shell Script'' Profissional]: livro do Aurélio Marinho Vargas, segundo ele "complementar ao livro (...) do Júlio". | ||
+ | * [http://www.guiafoca.org/ Guia Foca Linux]: material de referência do Gleydson baseado em Debian GNU/Linux. | ||
=Aulas= | =Aulas= | ||
Linha 103: | Linha 114: | ||
==24/02 - 03/03: Camada Física== | ==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: | * 24/02: Discussão do tema, destacando as seções do cabeamento estruturado no cenário de estudo: | ||
− | ** Entrada de facilidades: apenas passivos de rede e cabeamento rígido. Não requer climatização ou energização dos componentes. | + | ** 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: | + | ** 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. | * 01/03: Divisão do trabalho em pequenas equipes, para entrega parcial na próxima aula. | ||
Linha 128: | Linha 139: | ||
|} | |} | ||
</center> | </center> | ||
− | * 03/03: | + | 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 [[Portal da Coordenadoria de Informática|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=== | ===Resultado: plano de ação=== | ||
+ | Documento sob [https://tele.sj.ifsc.edu.br/arquivos/tele/GER-2011.1/Fisica.doc 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]''' | ||
+ | ## 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 - 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: | + | * 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. | ||
+ | |||
<center><graphviz> | <center><graphviz> | ||
digraph Rede | digraph Rede | ||
Linha 159: | Linha 201: | ||
{ | { | ||
label="Enlace" | label="Enlace" | ||
− | + | "Ethernet" [shape=Mrecord] | |
− | + | "802.11" [shape=Mrecord] | |
+ | "802.1p" [shape=Mrecord] | ||
+ | "802.1q" [shape=Mrecord] | ||
LACP [shape=Mrecord] | LACP [shape=Mrecord] | ||
− | + | "802.1D" [shape=Mrecord] | |
"802.1x" [shape=Mrecord] | "802.1x" [shape=Mrecord] | ||
− | "802.1x" -> | + | "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" -> " | + | "Cabeamento vertical" -> "Pares de cabos + canais distintos" [color=red] |
− | "Cabeamento horizontal" -> " | + | "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] | + | "Identificação dos cabos e pontos" [shape=plaintext,fontcolor=red] |
"Armário principal" -> "Identificação dos cabos e pontos" [color=red] | "Armário principal" -> "Identificação dos cabos e pontos" [color=red] | ||
"Armário de telecom" -> "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] | "Área de trabalho" -> "Identificação dos cabos e pontos" [color=red] | ||
− | "Identificação dos cabos e pontos" -> " | + | "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" -> " | + | "Armário principal" -> "Ativos de rede" [color=blue] |
− | "Armário de telecom" -> " | + | "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= | + | "Armário principal" -> LACP [color=green,fontcolor=green,label="Servidores"] |
} | } | ||
</graphviz></center> | </graphviz></center> | ||
+ | |||
+ | |||
+ | ===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. | ||
+ | # 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 - 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 [http://en.wikipedia.org/wiki/DMZ_(computing)#Dual_firewalls 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 <tt>172.16.0.0/12</tt>. | ||
+ | ** DMZ com os serviços de clientes internos e externos. Usará IPs externos da faixa da RNP: <tt>200.135.37.64/26</tt>. | ||
+ | ** 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. | ||
+ | |||
+ | <center><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></center> | ||
+ | |||
==24/03 - 31/03: Camada de Aplicação: Facilitadores== | ==24/03 - 31/03: Camada de Aplicação: Facilitadores== | ||
− | ==05/04 - | + | * 24/03: antes de começar a falar sobre serviços propriamente, foram revistos alguns conceitos de '''sistemas operacionais''' - alguns com [http://cm.bell-labs.com/cm/cs/who/dmr/cacm.pdf 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): |
− | ==19/04 - | + | ** 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 [http://en.wikipedia.org/wiki/Cron 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 [http://tools.ietf.org/rfc/rfc5424.txt 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 [http://ntp.br/ 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: |
− | == | + | |
+ | |||
+ | <center><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></center>* 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 [http://tools.ietf.org/rfc/rfc2131.txt DHCP] e suas [http://www.bind9.net/rfc-dhcp interrelações com outros protocolos]. Atualizada a dependência entre os serviços: | ||
+ | |||
+ | <center><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></center> | ||
+ | |||
+ | ===Resultado: implementação=== | ||
+ | A primeira tarefa prática da disciplina consiste em implementar, na [[#Ambiente de Produção|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 <tt>10.0.0.0/28</tt>, seguindo a [[#Ambiente de Produção|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 <tt>ger20111.sj.ifsc.edu.br</tt> 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 '''<tt>hora</tt>''' 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. [[#Método de Avaliação|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 [http://tools.ietf.org/rfc/rfc1034.txt 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. | ||
+ | |||
+ | <center><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></center> | ||
+ | |||
+ | * 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 [http://www.ifsc.edu.br/index.php?option=com_content&view=article&id=1590:1204--campus-sao-jose-cancela-atividades-da-manha-desta-terca-feira&catid=2:ultimas falha elétrica no campus], não houve aula de laboratório. | ||
+ | |||
+ | * 14/04: introdução a [http://tools.ietf.org/rfc/rfc4511.txt 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). | ||
+ | |||
+ | |||
+ | <center><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></center> | ||
+ | |||
+ | * 19/04: conversa com [http://buscatextual.cnpq.br/buscatextual/visualizacv.jsp?id=K4751516E2 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 <tt>dig</tt> ou equivalente, procure pelos valores dos registros <tt>SOA</tt> e <tt>NS</tt> 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) <tt>sj-tele</tt>. | ||
+ | * É 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, [http://en.wikipedia.org/wiki/Relational_model relações entre os dados] armazenados. | ||
+ | <center> | ||
+ | <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> | ||
+ | </center> | ||
+ | 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 [http://en.wikipedia.org/wiki/Database_management_system SGBD]. | ||
+ | |||
+ | <center><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></center> | ||
+ | |||
+ | ===Estudo de Caso: MySQL=== | ||
+ | A facilidade de implementação e de configuração tornam o [http://www.mysql.org 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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | aptitude install mysql-server | ||
+ | </syntaxhighlight> | ||
+ | Há vários [http://dev.mysql.com/downloads/gui-tools/ clientes disponíveis], inclusive para CLI: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | aptitude install mysql-client | ||
+ | </syntaxhighlight> | ||
+ | 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 <tt>root</tt> possui acesso local (<tt>localhost</tt>) com uma senha definida no ato da instalação (comando <tt>aptitude install mysql-server</tt>): | ||
+ | <syntaxhighlight lang=bash> | ||
+ | mysql -h localhost -u root -p | ||
+ | </syntaxhighlight> | ||
+ | Cabe destacar que esse usuário <tt>root</tt> é 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 <tt>root</tt> possui amplos privilégios, esse pode listar todas as base de dados: | ||
+ | <syntaxhighlight lang=mysql> | ||
+ | SHOW DATABASES; | ||
+ | </syntaxhighlight> | ||
+ | ou mesmo as tabelas de uma base em particular. Abaixo, são listadas as tabelas da base <tt>mysql</tt>: | ||
+ | <syntaxhighlight lang=mysql> | ||
+ | USE mysql; | ||
+ | SHOW TABLES; | ||
+ | </syntaxhighlight> | ||
+ | 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 <tt>mysql.user</tt> e <tt>mysql.db</tt>! | ||
+ | <syntaxhighlight lang=mysql> | ||
+ | USE mysql; | ||
+ | SELECT * FROM user; | ||
+ | SELECT * from db; | ||
+ | </syntaxhighlight> | ||
+ | Para quem já está familizarizado com [http://en.wikipedia.org/wiki/SQL SQL], acima foram apresentados os registros completos das tabelas <tt>mysql.user</tt> e <tt>mysql.db</tt>, 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: | ||
+ | <syntaxhighlight lang=mysql> | ||
+ | CREATE DATABASE banco; | ||
+ | GRANT ALL PRIVILEGES ON banco.* TO 'joao'@'localhost' IDENTIFIED BY 'codigoSecreto'; | ||
+ | FLUSH PRIVILEGES; | ||
+ | </syntaxhighlight> | ||
+ | Acima, em ordem: | ||
+ | # Criação de um banco de dados denominado <tt>banco</tt>. | ||
+ | # Criação de um usuário denominado <tt>joao</tt>, associação a uma senha <tt>codigoSecreto</tt> e autorizado o acesso à base <tt>banco</tt> através do endereço <tt>localhost</tt>. | ||
+ | # 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 [http://en.wikipedia.org/wiki/Database_administrator 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 [http://news.netcraft.com/archives/2011/05/02/may-2011-web-server-survey.html fatia de mercado global superior a 60%]. É importante compreender o funcionamento e cabeçalho do [http://www.ietf.org/rfc/rfc2616.txt HTTP versão 1.1] para [http://httpd.apache.org/docs/2.2/configuring.html configurar devidamente o serviço]: | ||
+ | ** Endereços virtuais (''[http://httpd.apache.org/docs/2.2/vhosts/ 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 <tt>VirtualHosts</tt>. 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 (''[http://httpd.apache.org/docs/2.2/urlmapping.html URL mapping]''): assim como cada endereço virtual tem seu diretório raiz ([http://httpd.apache.org/docs/2.2/urlmapping.html#documentroot DocumentRoot]), é possível mapear um diretório específico ([http://httpd.apache.org/docs/2.2/urlmapping.html#outside alias]) ou mesmo a diretório pessoal de um usuário ([http://httpd.apache.org/docs/2.2/urlmapping.html#user user]). | ||
+ | ** Expansões com módulos ([http://httpd.apache.org/docs/2.2/dso.html 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|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. | ||
+ | |||
+ | <center><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></center> | ||
+ | |||
+ | * 24/05: apresentação do serviço Samba no modo grupo de trabalho. Uma experiência interessante já foi [[Gerência de Redes de Computadores (técnico) (diário 2010-1)#Atividade-problema|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. | ||
+ | <center><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></center> | ||
+ | |||
+ | ===Estudo de Caso: Joomla=== | ||
+ | O [http://www.joomla.org Joomla] é um exemplo de [http://en.wikipedia.org/wiki/Content_Management_System CMS] bastante popular, sendo utilizado inclusive no [http://www.ifsc.edu.br 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. | ||
+ | |||
+ | <center><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></center> | ||
+ | |||
+ | 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 [http://php.net PHP] e integrá-los ao servidor Web, no caso o Apache. | ||
+ | |||
+ | Como já há um [[#Estudo de Caso: MySQL|banco de dados instalado]], basta acessá-lo para criar um novo banco com acesso restrito à aplicação Web local: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | mysql -u root -p mysql | ||
+ | </syntaxhighlight> | ||
+ | usando os comandos SQL: | ||
+ | <syntaxhighlight lang=mysql> | ||
+ | CREATE DATABASE joomla; | ||
+ | GRANT ALL PRIVILEGES ON joomla.* TO 'usuario'@localhost IDENTIFIED BY 'senha'; | ||
+ | FLUSH PRIVILEGES; | ||
+ | QUIT; | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Em seguida, a instalação do PHP, hoje na versão 5, e sua integração ao MySQL e Apache: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | aptitude install php5 php5-mysql | ||
+ | service apache2 restart | ||
+ | </syntaxhighlight> | ||
+ | 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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | a2enmod php5 | ||
+ | service apache2 restart | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Por último, a configuração de um ambiente reservado ao Joomla com algumas particularidades: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | vi /etc/apache2/conf.d/joomla.conf | ||
+ | </syntaxhighlight> | ||
+ | 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 <tt>reload</tt> mantém as conexões abertas e aplica os novos valores: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | service apache2 reload | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Por último, o código PHP. No sítio do [http://www.joomla.org/download.html 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 <tt>www-data</tt> (comum nos sistemas baseados em [http://www.debian.org Debian]: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | 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 | ||
+ | </syntaxhighlight> | ||
+ | O restante da configuração segue em ambiente Web: <nowiki>http://<servidor>/cms</nowiki>. | ||
+ | |||
+ | ===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 <tt>/home/documentos</tt>, criado e compartilhado sob autenticação básica. Nos sistemas baseados em Debian, o dono do processo-serviço é <tt>www-data</tt> e grupo com mesmo nome. | ||
+ | |||
+ | Primeiro, a criação do diretório: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | cd /home | ||
+ | mkdir documentos | ||
+ | chmod 700 documentos | ||
+ | chown www-data:www-data documentos | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Em seguida, o compartilhamento com autenticação básica. O módulo de autenticação já vem ativado - e pode ser confirmado com: <tt>apache2ctl -M</tt>. | ||
+ | <syntaxhighlight lang=bash> | ||
+ | cd /etc/apache2/conf.d/ | ||
+ | vi documentos | ||
+ | </syntaxhighlight> | ||
+ | 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, <tt>/etc/apache2/htpasswd-senhas</tt>, pode ser criado com a ferramenta <tt>htpasswd</tt>: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | htpasswd -c -m /etc/apache2/htpasswd-senhas <usuário> | ||
+ | </syntaxhighlight> | ||
+ | Depois deve-se, pois, proteger esse arquivo: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | chmod 640 /etc/apache2/htpasswd-senhas | ||
+ | chown root:www-data /etc/apache2/htpasswd-senhas | ||
+ | </syntaxhighlight> | ||
+ | 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, <tt>a2ensite</tt> pode ser usado para ativar o ''site'' com SSL: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | a2ensite default-ssl | ||
+ | </syntaxhighlight> | ||
+ | Após, cria-se o certificado personalizado e autoassinado (validade: 4 anos) e informado na configuração do Apache 2: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | 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 | ||
+ | </syntaxhighlight> | ||
+ | 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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | a2enmod ssl | ||
+ | </syntaxhighlight> | ||
+ | e força o usuário, quando for utilizar HTTP para acessar tal diretório, a ser encaminhado para HTTPS: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | vi /etc/apache2/sites-enabled/000-default | ||
+ | </syntaxhighlight> | ||
+ | adicionando a seguinte linha dentro do escopo <tt><nowiki><VirtualHost></nowiki></tt>: | ||
+ | RedirectMatch ^/documentos(.*)$ https://<servidor>/$1 | ||
+ | onde <tt>servidor</tt> é nome completo (FQDN) do servidor Web. Para terminar, resta apenas reiniciar o serviço: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | service apache2 restart | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ==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 [http://roundcube.net/ 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''. | ||
+ | |||
+ | <center><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></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=== | ||
+ | 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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | apt-get install snmpd | ||
+ | vi /etc/snmp/snmpd.conf | ||
+ | </syntaxhighlight> | ||
+ | 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 <tt>ger</tt> com permissão única de leitura a todos os atributos (<tt>rocommunity</tt>), localizado no Lab. de Redes II (<tt>SysLocation</tt>), aos cuidados do prof. Ederson (<tt>sysContact</tt>) e que opera em todas as camadas do modelo TCP/IP (<tt>sysServices</tt>). | ||
+ | Feito isso, basta reiniciar o serviço: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | /etc/init.d/snmpd restart | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ====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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | apt-get install snmp | ||
+ | apt-get install snmp-mibs-downloader | ||
+ | download-mibs | ||
+ | </syntaxhighlight> | ||
+ | Em seguida, deve-se remover a referência no arquivo de configuração <tt>/etc/snmp/snmp.conf</tt> para fazer pleno uso das MIBs inclusive em linha de comando, conforme a [http://wiki.debian.org/SNMP Wiki do Debian]: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | sed -i 's/^mibs ://g' /etc/snmp/snmp.conf | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | Assim, será possível realizar ações em linha de comando, como por exemplo operações GET: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | snmpget -c ger -v 2c localhost sysLocation.0 | ||
+ | snmpget -c ger -v 2c localhost sysContact.0 | ||
+ | snmpget -c ger -v 2c localhost sysServices.0 | ||
+ | </syntaxhighlight> | ||
+ | Ou mesmo uma varredura em toda a árvore de atributos, utilizando para tal a operação GETNEXT (sequencial): | ||
+ | <syntaxhighlight lang=bash> | ||
+ | snmpwalk -c ger -v 2c localhost .1 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | O próximo passo é escolher um gerente SNMP que atenda às necessidades. Em código aberto, há disponíveis: | ||
+ | * [http://cacti.net Cacti]; | ||
+ | * [http://www.opennms.org OpenNMS]; | ||
+ | * [http://www.nagios.org/ Nagios]; | ||
+ | * [http://www.zabbix.com/ Zabbix]; | ||
+ | * [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: | ||
+ | <syntaxhighlight lang=bash> | ||
+ | apt-get install libdbi0 librrd4 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ===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 (<tt>SOA</tt>, <tt>NS</tt> e <tt>A</tt>). | ||
+ | ## SGBD: serviço rodando e consulta (<tt>SELECT</tt>) 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 <tt>mail</tt> que integra o pacote [http://packages.debian.org/squeeze/mailutils mailutils]. | ||
+ | # Ao final, o programa deverá emitir um relatório com a lista de testes realizados com e sem sucesso. | ||
+ | <syntaxhighlight lang=bash> | ||
+ | #!/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 | ||
+ | </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.