Implementação de Servidor Linux Ubuntu Server

CENTRO PAULA SOUZA

FACULDADE DE TECNOLOGIA DE TAQUARITINGA

TECNOLOGIA EM PROCESSAMENTO DE DADOS

IMPLEMENTAÇÃO DE SERVIDOR LINUX UBUNTU

SERVER: FIREWALL, PROXY E FILE SERVER

TIAGO BEZERRA DOS SANTOS

Orientador: MARCO ANTONIO ALVES PEREIRA

Taquaritinga

2009

IMPLEMENTAÇÃO DE SERVIDOR LINUX UBUNTU

SERVER: FIREWALL, PROXY E FILE SERVER

TIAGO BEZERRA DOS SANTOS

Monografia apresentada à Faculdade de Tecnologia de Taquaritinga, como parte dos

requisitos para a obtenção do título de Tecnólogo em Processamento de Dados.

Orientador: Marco Antonio Alves Pereira

Taquaritinga

2009

Ninguém chega ao seu paraíso sem antes lutar.

Neil Peart (Rush) – Armor And Sword

Dedico,

Aos meus pais Ivanildo e Lili,

e a minha irmã Talita, que sempre me incentivaram.

AGRADECIMENTOS

Ao Prof. Ramílio Ramalho Reis Filho e sua família, por terem acreditado em mim.

Ao Prof. Marco Antonio Alves Pereira, por sua competência, dedicação e

disponibilidade como orientador. Aos Professores da Fatec, pelos valiosos ensinamentos e experiências.

À minha amiga Josy Diniz, pelo apoio e palavras de incentivo em diversos

momentos. À minha família e amigos, pelo apoio, paciência e amor.

A Deus, por ter colocado pessoas especiais em minha vida.

Implementação de Serv idor Linux Ubuntu Server: Firewall, Proxy e File Server - v

SUMÁRIO

LISTA DE FIGURAS...............................................................................................................vii

LISTA DE QUADROS ............................................................................................................. ix

LISTA DE ABREVIATURAS E SIGLAS ................................................................................ x

RESUMO................................................................................................................................... xi

ABSTRACT .............................................................................................................................xii

INTRODUÇÃO ........................................................................................................................ 13

1. INSTALAÇÃO DO UBUNTU SERVER ............................................................................ 15

1.1 Ubuntu Desktop x Ubuntu Server ................................................................................... 15

1.2 Instalação do Sistema ...................................................................................................... 16

1.2.1 Configuração inicial de rede ..................................................................................... 16

1.2.2 Particionamento ........................................................................................................ 18

1.2.3 Instalação do Sistema Básico .................................................................................... 20

2. FIREWALL IPTABLES E CONFIGURAÇÃO DE REDE ................................................ 23

2.1 Interfaces ......................................................................................................................... 23

2.2 Firewall Iptables .............................................................................................................. 25

2.2.1 Regras de compartilhamento..................................................................................... 25

2.2.2 Configuração de Portas ............................................................................................. 27

2.2.3 Regras de Segurança ................................................................................................. 28

2.3 Servidor DHCP................................................................................................................ 29

2.3.1 Instalação e configuração do servidor....................................................................... 29

3. SERVIDOR PROXY SQUID............................................................................................... 32

3.1 Tipos de Proxy................................................................................................................. 32

3.1.1 Tradicional ................................................................................................................ 32

3.1.2 Transparente.............................................................................................................. 33

3.1.3 Com Autenticação..................................................................................................... 33

3.1.4 PAC ........................................................................................................................... 33

3.1.5 WPAD ....................................................................................................................... 34

3.2 Instalação do Squid.......................................................................................................... 34

3.3 Configuração básica como Proxy Transparente .............................................................. 35

3.4 Definindo o Cache do servidor Proxy ............................................................................. 37

3.5 Regras para Políticas de Acesso (ACLs) ......................................................................... 39

3.5.1 Bloqueio de sites ....................................................................................................... 39

Implementação de Serv idor Linux Ubuntu Server: Firewall, Proxy e File Server - vi

3.5.2 Controle de acesso de máquinas ............................................................................... 40

3.6 SquidGuard ...................................................................................................................... 43

3.6.1 Instalação e Configuração ......................................................................................... 43

3.6.2 Ajustando as permissões de acesso e alterando o Squid ........................................... 45

3.7 Monitorando os acessos com o Sarg ............................................................................... 46

4. SERVIDOR DE ARQUIVOS SAMBA ............................................................................... 48

4.1 Instalação do Samba ........................................................................................................ 48

4.2 Usuários ........................................................................................................................... 48

4.2.1 Cadastro de usuários no sistema ............................................................................... 49

4.2.2 Cadastro de usuários no Samba ................................................................................ 50

4.3 Configuração usando o smb.conf .................................................................................... 51

4.3.1 Configuração global .................................................................................................. 51

4.3.2 Criação dos compartilhamentos ................................................................................ 55

4.4 Ajustes de permissões no sistema.................................................................................... 57

4.4.1 Grupos de usuários.................................................................................................... 58

4.4.2 Permissões de acesso ................................................................................................ 58

5. ACESSO REMOTO ............................................................................................................. 62

5.1 Servidor OpenSSH .......................................................................................................... 62

5.1.1 Instalação e configuração no servidor....................................................................... 63

5.2 Administração remota ..................................................................................................... 65

5.2.1 Usando o no- ip como DNS dinâmico ....................................................................... 65

5.2.2 PuTTY....................................................................................................................... 66

5.2.3 Webmin ..................................................................................................................... 69

CONCLUSÃO .......................................................................................................................... 74

REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................................... 75

BIBLIOGRAFIA ...................................................................................................................... 76

Implementação de Serv idor Linux Ubuntu Server: Firewall, Proxy e File Server - vii

LISTA DE FIGURAS

Figura 1 – Gerenciador de boot egrub. ..................................................................................... 16

Figura 2 – Seleção de qual interface de rede será a primária. .................................................. 17

Figura 3 – Configuração da rede adiada. .................................................................................. 17

Figura 4 – Particionamento do Disco Rígido. .......................................................................... 18

Figura 5 – Escolha de um espaço livre ou partição a ser usada. ............................................... 19

Figura 6 – Esquema de particionamento utilizado. .................................................................. 20

Figura 7 – Configuração de usuário e senha............................................................................. 21

Figura 8 – Instalação de pacotes de softwares. ......................................................................... 21

Figura 9 – Finalização da instalação......................................................................................... 22

Figura 10 – Terminal. ............................................................................................................... 22

Figura 11 – Edição das configurações de rede usando o editor nano. ...................................... 24

Figura 12 – Atualização da lista de pacotes dos repositórios. .................................................. 24

Figura 13 – Atualização dos pacotes já instalados. .................................................................. 25

Figura 14 – Regras para compartilhamento de Internet no Iptables. ........................................ 26

Figura 15 – Regras para portas no Iptables. ............................................................................. 27

Figura 16 – Regras de segurança no Iptables. .......................................................................... 28

Figura 17 – Arquivo dhcpd.conf............................................................................................... 30

Figura 18 – Instalação do Squid. .............................................................................................. 34

Figura 19 – Configuração inicial do squid.conf. ...................................................................... 35

Figura 20 – Configuração parcial do squid.conf. ..................................................................... 38

Figura 21 – Arquivo com lista de endereços bloqueados. ........................................................ 40

Figura 22 – Arquivo com lista de palavras bloqueadas. ........................................................... 40

Figura 23 – Arquivo com lista de endereços MAC de máquinas. ............................................ 41

Figura 24 – Arquivo squid.conf configurado com ACLs. ........................................................ 42

Figura 25 – Acesso negado pelo Squid..................................................................................... 43

Figura 26 – Diretório blacklists. ............................................................................................... 44

Figura 27 – Arquivo squidGuard.conf. ..................................................................................... 45

Figura 28 – Adicionando usuários ao sistema. ......................................................................... 49

Figura 29 – Adicionando usuários ao servidor Samba. ............................................................ 50

Figura 30 – Configuração da seção [global] no smb.conf. ....................................................... 52

Figura 31 – Adicionando endereço do servidor WINS no DHCP. ........................................... 53

Figura 32 – Verificação do smb.conf usando o testparm. ........................................................ 54

Implementação de Serv idor Linux Ubuntu Server: Firewall, Proxy e File Server - viii

Figura 33 – Visualizando o servidor nos Meus locais de rede da estação. ............................... 54

Figura 34 – Criação dos diretórios publico e arquivos. ............................................................ 55

Figura 35 – Seções de compartilhamento no smb.conf. ........................................................... 56

Figura 36 – Visualizando os compartilhamentos nas estações Windows. ................................ 57

Figura 37 – Inclusão de usuários em grupos. ........................................................................... 58

Figura 38 – Gravação negada no compartilhamento. ............................................................... 59

Figura 39 – Alteração da propriedade dos diretórios share. ..................................................... 59

Figura 40 – Gravação autorizada no compartilhamento. .......................................................... 60

Figura 41 – Ajustes de permissões para os grupos e seus diretórios. ....................................... 60

Figura 42 – Acesso aos compartilhamentos “arquivos” e “publico”. ....................................... 61

Figura 43 – Arquivo sshd_config original. ............................................................................... 63

Figura 44 – Arquivo sshd_config configurado. ........................................................................ 64

Figura 45 – Gerenciador de Hosts do serviço DDNS no- ip. .................................................... 66

Figura 46 – Assistente de configuração do no- ip. .................................................................... 66

Figura 47 – Configuração do PuTTY. ...................................................................................... 67

Figura 48 – Alerta sobre a chave e autorização de acesso ao servidor. .................................... 68

Figura 49 – Acesso remoto ao servidor via SSH pelo PuTTY. ................................................ 68

Figura 50 – Tentativa de instalação do pacote “.deb” do Webmin. ......................................... 69

Figura 51 – Resolução de dependências e instalação usando o “apt-get install - f”.................. 70

Figura 52 – Primeiro acesso ao Webmin pelo Firefox. ............................................................ 71

Figura 53 – Adicionando uma exceção de segurança no Firefox. ............................................ 71

Figura 54 – Tela de login do Webmin. ..................................................................................... 72

Figura 55 – Tela inicial do gerenciador Webmin. .................................................................... 72

Figura 56 – Webmin listando relatórios do Sarg. ..................................................................... 73

Implementação de Serv idor Linux Ubuntu Server: Firewall, Proxy e File Server - ix

LISTA DE QUADROS

Quadro 1 – Script de compartilhamento no Iptables. ............................................................... 26

Quadro 2 – Regras para portas no Iptables. .............................................................................. 27

Quadro 3 – Regras de segurança no Iptables. ........................................................................... 29

Quadro 4 – Arquivo dhcpd.conf. .............................................................................................. 30

Quadro 5 – Configuração inicial do squid.conf. ....................................................................... 35

Quadro 6 – Configuração parcial do squid.conf. ...................................................................... 38

Quadro 7 – Configuração da seção [global] do smb.conf. ....................................................... 52

Quadro 8 – Configuração das seções de compartilhamento no smb.conf. ............................... 56

Quadro 9 – Configuração do arquivo sshd_config. .................................................................. 64

Implementação de Serv idor Linux Ubuntu Server: Firewall, Proxy e File Server - x

LISTA DE ABREVIATURAS E SIGLAS

ACL – Access Control List

APT-GET – Advanced Packaging Tool DHCP – Dynamic Host Configuration Protocol DDNS – Dynamic Domain Name System

DNS – Domain Name System EXT3 – Third Extended File System

GB – GigaByte GNOME – GNU Network Object Model Environment HD – Hard Disk

HTTP – Hypertext Transfer Protocol HTTPS – HyperText Transfer Protocol Secure

IP – Internet Protocol KDE – K Desktop Environment LTS – Long Term Support

MB – MegaByte MHz – MegaHertz

NAT – Network Address Translation PAC – Proxy Auto-Configuration PDC – Primary Domain Controller

RAM – Random Access Memory SAS – Serial Attached SCSI

SSH – Secure Shell TCP – Transmission Control Protocol) UDP – User Datagram Protocol

WINS – Windows Internet Name Services WPAD – Web Proxy Auto-Discovery protocol

WWW – World Wide Web XFCE – XForms Common Environment

Implementação de Serv idor Linux Ubuntu Server: Firewall, Proxy e File Server - xi

RESUMO

O presente trabalho tem como objetivo demonstrar os procedimentos necessários para a implementação de um servidor Linux com funções de Firewall, Proxy e File Server,

utilizando a distribuição Ubuntu Server. Utilizando o software de virtualização VMware, foi simulado um ambiente de rede de computadores com um servidor virtual com o Ubuntu Server instalado e estações Windows também virtuais. O servidor foi configurado com

funções de roteador e Firewall Iptables, possibilitando um acesso compartilhado e seguro à Internet a partir das estações. Por meio de um serviço DHCP, o servidor também ficou

responsável por distribuir de forma automática os endereços IP que cada estação deveria ter, além de filtrar o conteúdo acessado através do Proxy Squid. Adicionalmente, o servidor foi configurado como um File Server, disponibilizando arquivos por meio de compartilhamentos

configurados no servidor Samba. A administração remota do servidor foi definida através da configuração do servidor OpenSSH, acessível utilizando o cliente PuTTY a partir de qualquer

máquina conectada à rede local ou mesmo à Internet. De forma complementar, o software de gerenciamento web Webmin também foi instalado e configurado, possibilitando a administração do servidor através de uma interface gráfica com acesso a partir de qualquer

navegador.

Palavras-Chaves: Servidores; Linux; Ubuntu; Firewall; Proxy; File.

Implementação de Serv idor Linux Ubuntu Server: Firewall, Proxy e File Server - xii

ABSTRACT

This work aims to demonstrate the necessary procedures for the implementation of a

Linux server with functions of Firewall, Proxy and File Server, using the Ubuntu Server distribution. Using VMware virtualization software, was a simulated network environment for

computers with a virtual server with Ubuntu Server installed and Windows virtual stations. The server was configured with Iptables Firewall and router functions, allowing a shared and secure access to the Internet from the stations. Through a DHCP service, the server was also

responsible for automatically distributing the IP addresses that each station should have, and filter the content accessed through the Squid Proxy. Additionally, the server was configured

as a File Server, providing files via Samba shares configured on the server. The remote administration was defined by the configuration of the OpenSSH server, accessible using the PuTTY client on any machine connected to the LAN or the Internet. In addition, the Webmin

web management software was installed and configured, allowing the administration of the server via a graphical interface to access from any browser.

Keywords: Servers; Linux; Ubuntu; Firewall; Proxy; File.

INTRODUÇÃO

É cada vez mais comum a utilização de uma rede de computadores em qualquer

empresa, independentemente de seu porte ou ramo de atuação. Isso contribui de maneira

significativa na crescente necessidade de se obter um controle e gerenciamento dos recursos

computacionais disponíveis. Este tipo de gerenciamento é possível com a utilização de um

computador servidor.

Basicamente, qualquer máquina com um mínimo de características e funcionalidades

pode ser utilizada como servidor de uma rede de computadores. É possível, por exemplo,

aproveitar uma máquina antiga com 64 MB de memória RAM, processador de 500 MHz e

duas placas de rede rodando (sem ambiente gráfico) qualquer distribuição Linux para executar

funções de roteador e firewall em uma rede de pequeno porte. Ou ainda, utilizar uma máquina

com uma configuração mais completa, com 8 GB de RAM (ou mais), processador dual ou

quad core, um ou vários discos rígidos SAS, placas de rede Gigabit, suporte a redundância e

diversos outros recursos; para funções mais críticas, como um servidor de Banco de Dados de

alta demanda, um servidor de máquinas virtuais, dentre outras aplicações que exijam um

conjunto mais robusto.

Além do hardware da máquina também há a necessidade de se escolher qual sistema

operacional será utilizado no servidor, escolha essa que invariavelmente recai na eterna

discussão: Windows ou Linux?

A grande popularidade do Windows é conhecida por todos que eventualmente usam ou

já usaram um computador, principalmente nos ambientes doméstico e corporativo, onde se

usam computadores comuns (desktops). Sua principal característica é a união de facilidade e

praticidade de uso mesmo por usuários com conhecimento básico em informática.

No entanto, há muitos aspectos que favorecem a escolha de um sistema operacional

Linux para utilização em servidores. O Linux é conhecido originalmente por sua alta

Implementação de Serv idor Linux Ubuntu Server: Firewall, Proxy e File Server - 14

estabilidade e segurança, sendo imune a ameaças comuns ao ambiente Windows (como vírus e

spywares) devido ao seu sistema de permissões e privilégios de acesso. Pode-se dizer que, sob

o ponto de vista teórico, um servidor rodando o Linux com programas e serviços atualizados e

configurados corretamente, atinge um nível quase que perfeito de confiabilidade e segurança

no que se refere a software.

Por características como estas, foi escolhido como foco deste trabalho demonstrar

como implementar e configurar um Servidor Linux com as funções de Proxy, Firewall e

servidor de Arquivos utilizando a distribuição Ubuntu Server. Estas são algumas das funções

mais comuns encontradas em servidores de muitas empresas.

O desenvolvimento do trabalho foi feito com o software de virtualização VMware

Server, utilizando para o servidor uma máquina virtual configurada inicialmente com 128 MB

de memória RAM, disco rígido com 7,5 GB e duas placas de rede, além de máquinas virtuais

com 256 MB de RAM e disco rígido com 4 GB para estações com Windows XP Professional,

simulando virtualmente as características reais de uma rede de computadores. Com exceção

do espaço definido inicialmente para os HDs, praticamente todas as outras configurações de

hardware virtual podem ser modificadas posteriormente através da interface web de

gerenciamento do VMware Server.

Neste trabalho são abordados todos os procedimentos inerentes a instalação da

máquina na rede, como a instalação do Sistema Operacional Ubuntu Server, configuração das

interfaces de rede e do servidor DHCP necessário para distribuição de endereços IP para as

estações, definição de regras para uso de Internet através do Proxy Squid, instalação e

configuração do servidor OpenSSH para acesso remoto, criação de compartilhamentos no

Samba, além de definições de regras de segurança no firewall Iptables e métodos de

administração remota usando os utilitários PuTTY e Webmin.

1. INSTALAÇÃO DO UBUNTU SERVER

É durante a instalação do Sistema Operacional que algumas pré-configurações básicas

deverão ser definidas, determinando a forma como recursos do servidor poderão ser mais bem

utilizados. Neste capítulo serão abordadas as diferenças entre a versão Desktop e Server do

Ubuntu, além de sua instalação e configuração iniciais.

1.1 Ubuntu Desktop x Ubuntu Server

Para Paula Júnior (2007, p.4) “o Ubuntu é um sistema operacional livre e de código

aberto, feito em volta do Kernel do Linux, baseado na distribuição chamada Debian”.

A empresa Canonical apóia o desenvolvimento do Ubuntu, e a lém de versões com

diferentes tipos de ambientes de trabalho (Kubuntu/KDE e Xubuntu/XFCE, por exemplo),

também disponibiliza uma versão destinada a servidores, conhecida como Ubuntu Server.

Atualmente na versão 9.04, o Ubuntu Server é, essencialmente, idêntico ao Ubuntu

Desktop. No entanto, seu ambiente de trabalho GNOME não é instalado por padrão, tornando

seu uso possível mesmo em máquinas com características mais modestas de hardware;

também inclui um conjunto de pacotes específicos para servidores.

O Ubuntu Server, assim como as versões desktop, utiliza repositórios derivados do

repositório unstable do Debian, sendo que as versões LTS (Long Term Support) são as mais

semelhantes às versões estáveis do Debian (MORIMOTO, 2008, p. 38). Para este trabalho foi

utilizada a versão 8.04 LTS. A terminologia LTS indica que seu período de suporte e

atualizações é maior em comparação às versões regulares (como a 9.04). A partir da versão

8.04 LTS, a Canonical estendeu esse período de 18 meses para 5 anos.


1.2 Instalação do Sistema

Antes de proceder com a instalação do Ubuntu Server, algumas configurações como

idioma e layout do teclado podem ser necessárias e feitas por meio do gerenciador de boot

egrub (Figura 1).

Figura 1 – Gerenciador de boot egrub.

FONTE: Arquivo do autor.

Na parte inferior da tela há informações sobre quais teclas utilizar para acessar

determinadas configurações do gerenciador, como por exemplo, F2 para idioma e F3 para o

layout do teclado.

Após a definição dos ajustes iniciais, basta escolher a opção “Install Ubuntu Server” e

pressionar “Enter” para iniciar a instalação.

1.2.1 Configuração inicial de rede

A máquina virtual utilizada possui duas interfaces de rede (eth0 e eth1), característica

identificada automaticamente pelo instalador e onde se deve escolher qual será a interface

primária (Figura 2).


Figura 2 – Seleção de qual interface de rede será a primária. FONTE: Arquivo do autor.

Após a escolha da interface “eth0” como primária, o instalador prossegue com a

configuração de rede tentando obtê-la automaticamente através de um servidor DHCP. Esta

configuração pode ser cancelada neste momento e efetuada manualmente mais tarde (Figura

3).

Figura 3 – Configuração da rede adiada. FONTE: Arquivo do autor.


Posteriormente o instalador pede a definição de um nome para identificação do

servidor na rede, além de configurações de fuso horário.

1.2.2 Particionamento

Particionamento é a tarefa de preparação do disco rígido (HD) em uma ou mais partes

(partições) que receberão um sistema de arquivos para armazenamento de dados. Existem

diversos tipos de sistema de arquivos para partições Linux, sendo o sistema EXT3 um dos

mais utilizados em diversas distribuições. O EXT3 caracteriza-se por possuir suporte ao

recurso de journaling, responsável por manter registros das operações realizadas no sistema

de arquivos da partição.

Após os ajustes inicias da instalação, é necessário executar o particionamento do disco

rígido, escolhendo a opção “Manual” para personalizar a definição das partições (Figura 4).

Figura 4 – Particionamento do Disco Rígido. FONTE: Arquivo do autor.

Após a escolha do espaço vazio o particionador solicita a criação de uma nova tabela

de partições, responsável pela definição das características das partições. Assim o disco rígido

fica pronto para definição de uma ou mais partições a partir de um espaço livre (Figura 5).


Figura 5 – Escolha de um espaço livre ou partição a ser usada. FONTE: Arquivo do autor.

O Ubuntu Server possui como requisito mínimo de instalação pelo menos 1 GB de

espaço em disco. Neste servidor virtual com disco rígido de 7.5 GB, sua instalação foi feita

usando a partição 1 (primária) com espaço de 3 GB para armazenar o diretório raíz (/) e toda a

estrutura do sistema operacional.

O diretório “/home”, local onde ficam os arquivos dos usuários, foi instalado na

partição 2 (lógica) com cerca de 4 GB. Este diretório tende a ter seu espaço ocupado com

mais rapidez, já que armazena tudo relacionado aos arquivos e configurações dos usuários

cadastrados no sistema.

Já a partição 3 é utilizada como uma memória virtual para o sistema, chamada de

SWAP, aproveitando o restante (500 MB) dos 7.5 GB do disco rígido do servidor.

Sendo assim, as partições serão criadas com a seguinte configuração (Figura 6):


Figura 6 – Esquema de particionamento utilizado. FONTE: Arquivo do autor.

Após a definição do esquema para as partições, a opção “Finalizar o particionamento e

gravar as mudanças no disco” é escolhida e o instalador prossegue com a instalação do

sistema.

1.2.3 Instalação do Sistema Básico

Durante o processo de instalação do sistema básico, algumas configurações são

solicitadas pelo instalador como, por exemplo, a definição de uma conta de usuário e senha de

acesso (Figura 7).


Figura 7 – Configuração de usuário e senha. FONTE: Arquivo do autor.

O usuário criado aqui será utilizado para configuração do sistema após o término da

instalação, evitando o uso da conta “root”.

Também é dada a opção de instalar alguns dos pacotes de softwares mais comuns

usados em servidores (Figura 8).

Figura 8 – Instalação de pacotes de softwares. FONTE: Arquivo do autor.

No entanto, a instalação dos pacotes necessários ao Servidor Proxy (Squid), Firewall

(Iptables), File Server (Samba) e OpenSSH para acesso remoto será feita posteriormente

através da ferramenta APT-GET, o que possibilita a utilização de versões mais recentes.


A instalação prossegue e alguns minutos depois é finalizada (Figura 9).

Figura 9 – Finalização da instalação. FONTE: Arquivo do autor.

O instalador reinicia a máquina e o Ubuntu Server é iniciado, solicitando em seguida o

nome de usuário e senha para login. Após preencher os dados, o terminal é apresentado e as

configurações do servidor já podem ser feitas (Figura 10).

Figura 10 – Terminal. FONTE: Arquivo do autor.

2. FIREWALL IPTABLES E CONFIGURAÇÃO DE REDE

Neste capítulo as interfaces de rede do servidor serão configuradas de acordo com o

tipo de conexão à Internet existente e das características da rede onde o servidor será

utilizado. Também será ativado o compartilhamento da Internet usando regras no firewall

Iptables, juntamente com regras de segurança. Por fim, será instalado e configurado um

servidor DHCP, responsável pela distribuição automática das configurações de rede que cada

estação deverá possuir.

2.1 Interfaces

A configuração das interfaces de rede é feita no arquivo “/etc/network/interfaces”,

usando um editor de textos como o nano.

Neste arquivo é possível definir as configurações de endereço IP, máscara, rede,

broadcast e gateway que cada interface ethernet do servidor possui.

Para este trabalho, com um servidor virtual conectado a uma conexão de Internet com

IP dinâmico, foi definida a configuração representada na imagem abaixo (Figura 11).


Figura 11 – Edição das configurações de rede usando o editor nano. FONTE: Arquivo do autor.

Para que as configurações entrem em funcionamento, o conteúdo do arquivo

“/etc/network/interfaces” precisa ser recarregado reiniciando o daemon (serviço) responsável

pelas configurações de rede: “sudo /etc/init.d/networking restart”.

Antes de executar outras tarefas de configuração dos serviços do servidor, é

recomendável atualizar a lista de pacotes dos repositórios do Ubuntu Server através do

comando “sudo apt-get update” (Figura 12), além de efetuar a atualização dos pacotes já

instalados por padrão, utilizando o comando “sudo apt-get upgrade” (Figura 13).

Figura 12 – Atualização da lista de pacotes dos repositórios. FONTE: Arquivo do autor.


Figura 13 – Atualização dos pacotes já instalados. FONTE: Arquivo do autor.

2.2 Firewall Iptables

Para von Hagen (2007, p. 727) “Firewall é um termo usado para descrever um sistema

que fica entre um ou mais sistemas de computadores, e monitora e gerencia o tráfego da

rede”.

O Iptables (também conhecido como netfilter) é um firewall embutido no Kernel do

Linux, caracterizado por ser muito estável e confiável, permitindo grande flexibilidade na

definição de regras. Seu funcionamento é baseado na comparação de regras para saber se um

pacote tem ou não permissão para passar; podendo também ser utilizado para modificar e

monitorar o tráfego da rede, roteamento, compartilhamento (NAT), e proteção contra diversas

formas de ataque. O Iptables ainda pode ter diversas funções adicionadas através de módulos,

o que possibilita inúmeras formas de uso do firewall (SILVA, 2007, p. 107).

2.2.1 Regras de compartilhamento

Após a configuração das interfaces de rede do servidor, é necessário fazer a

configuração que permitirá o compartilhamento da Internet (ligada à eth0) com a rede local

(eth1) através de regras no Iptables.

Os comandos listados na Figura 14 constituem as regras necessárias para o

compartilhamento e para uma proteção básica contra ataques vindos da Internet. Estes

comandos serão colocados em um arquivo chamado “firewall” dentro do diretório


“/usr/local/bin”, e este arquivo será transformado em um script executável (“sudo chmod +x

/usr/local/bin/firewall”). Desta forma, adicionando sua localização ao final do arquivo

“/etc/rc.local” (antes da linha exit0), o script será sempre carregado mesmo que o servidor

seja reiniciado.

Figura 14 – Regras para compartilhamento de Internet no Iptables. FONTE: Arquivo do autor.

O Quadro 1 apresenta a descrição dos comandos usados no script, sem referência aos

comentários:

Quadro 1 – Script de compartilhamento no Iptables.

Comando Função

conexinternet=“eth0” Variável que identifica a interface de rede

conectada à Internet (eth0).

conexlocal=“eth1” Variável que identifica a interface de rede

conectada à rede local (eth1).

modprobe iptable_nat Ativa o módulo iptable_nat para suporte a roteamento de pacotes por NAT.

echo 1 > /proc/sys/net/ipv4/ip_forward Ativa o módulo ip_forward que possibilita o encaminhamento de pacotes.

iptables –t nat –A POSTROUTING –o $conexinternet –j MASQUERADE

Regra que faz efetivamente o compartilhamento.

iptables –A INPUT –p tcp –synn –j DROP Regra geral de segurança, bloqueando o

acesso a partir de conexões externas (Internet).


2.2.2 Configuração de Portas

As regras definidas anteriormente são suficientes apenas para o compartilhamento da

Internet com o restante das estações da rede e uma proteção geral contra acessos provenientes

da Internet. No entanto, também é possível no Iptables definir regras para determinadas portas

no servidor.

A relação de portas que devem ser abertas ou fechadas no firewall depende

inicialmente de se ter em mente quais serão as principais atribuições do servidor. Por

exemplo, para um servidor web são necessárias pelo menos as portas TCP 80 e 443

(protocolos HTTP e HTTPS respectivamente), TCP 53 e UDP 53 (ambas para DNS,

responsável pela resolução de nomes de endereços).

Para o servidor desenvolvido neste trabalho, serão abertas no firewall as portas TCP

22, TCP 10000, UDP 137 e 138 e TCP 139 e 445, e fechada a porta 1863 utilizada pelo

programa de mensagens MSN/Windows Live Messenger (Figura 15).

Figura 15 – Regras para portas no Iptables. FONTE: Arquivo do autor.

O Quadro 2 apresenta a descrição dos comandos adicionados ao script do firewall:

Quadro 2 – Regras para portas no Iptables.

Comando Função

iptables -A INPUT -p tcp --dport 22 -j ACCEPT Condição para pacotes de entrada destinados à porta TCP 22, usada pelo servidor OpenSSH.

iptables -A FORWARD -p tcp --dport 1863 -j REJECT

Condição que bloqueia o acesso a conexão proveniente do programa MSN.

iptables -A INPUT -p tcp --dport 10000 -j ACCEPT

Condição para pacotes de entrada destinados à porta TCP 10000, usada


pelo software Webmin para acesso

remoto via web.

iptables -A INPUT -p udp --dport 137 -j ACCEPT

iptables -A INPUT -p udp --dport 138 -j ACCEPT iptables -A INPUT -p tcp --dport 139 -j ACCEPT iptables -A INPUT -p tcp --dport 445 -j ACCEPT

Condições para pacotes de entrada

destinados às portas UDP 137 e 138, e TCP 139 e 445, usadas pelo servidor Samba para navegação na rede e

resolução de nomes das máquinas da rede.

Estas portas são necessárias para os serviços que posteriormente serão configurados

neste servidor.

2.2.3 Regras de Segurança

Muitos dos problemas relacionados à segurança de uma rede de computadores podem

ser evitados (ou pelo menos minimizados) com um conjunto de regras definidas no firewall

Iptables. Quando combinadas com a atualização dos serviços instalados no servidor,

juntamente a uma política eficiente e clara sobre as condições de uso da rede e da Internet

pelos usuários, estas regras auxiliam o Administrador a ter um controle sobre praticamente

tudo o que deve ocorrer em relação ao acesso à rede e a Internet.

No script configurado anteriormente, foram definidas regras relacionadas ao

compartilhamento e a determinadas portas que são usadas por programas previstos nas

funcionalidades do servidor. Mas, além disso, também é válido adicionar mais algumas regras

visando justamente evitar possíveis brechas de segurança no servidor e na rede (Figura 16).

Figura 16 – Regras de segurança no Iptables. FONTE: Arquivo do autor.

O Quadro 3 apresenta a descrição dos comandos usados no script :


Quadro 3 – Regras de segurança no Iptables.

Comando Função

iptables –A INPUT –i $conexlocal –j ACCEPT Condição que aceita os pacotes

provenientes da rede local.

iptables –A INPUT –p icmp –icmp-type echo-

request –j DROP

Condição que ignora ping, dificultando

ao invasor saber se o servidor está online.

echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

iptables –A INPUT –m state –state INVALID –j DROP

Regras para ignorar pacotes inválidos.

iptables –A INPUT –i lo –j ACCEPT Pacotes vindos do próprio servidor são aceitos.

2.3 Servidor DHCP

O servidor DHCP (Dynamic Host Configuration Protocol) é o serviço responsável por

distribuir para as estações as configurações de endereçamento IP que cada uma deverá possuir

na rede de forma automática. Isto é especialmente útil em redes com uma grande quantidade

de computadores, evitando a necessidade de se configurar manualmente cada uma das

máquinas pertencentes à rede.

O funcionamento do DHCP é baseado em pacotes de broadcast, onde uma estação

configurada para receber um endereço IP automaticamente, envia um pacote de broadcast

tentando encontrar um servidor DHCP na rede que forneça uma configuração válida de IP

(VAN VUGT, 2008, p. 279). Além do endereço IP a estação também recebe as configurações

de máscara de rede, gateway e DNS utilizados na rede.

2.3.1 Instalação e configuração do servidor

A instalação do servidor DHCP no Ubuntu é feita através do pacote “dhcp3-server”

usando o comando “sudo apt-get install dhcp3-server”.

Sua configuração é definida no arquivo “/etc/dhcp3/dhcpd.conf”. Este arquivo é um

modelo de configuração com comentários, o que o deixa bastante extenso. Para simplificar o

procedimento de configuração do servidor, o arquivo original “dhcpd.conf” é renomeado para

“dhcpd.conf.old”, e então é criado um novo arquivo “dhcpd.conf” com apenas as

configurações necessárias para o servidor que está sendo implementado (Figura 17).


Figura 17 – Arquivo dhcpd.conf. FONTE: Arquivo do autor.

O Quadro 4 apresenta a descrição das linhas utilizadas na configuração do arquivo

dhcpd.conf:

Quadro 4 – Arquivo dhcpd.conf.

Linha Função

ddns-update-style none; Define que o DHCP não tentará interagir com um servidor de nomes (DNS).

default- lease-time 600; Controla o tempo (em segundos) de renovação dos endereços IP disponibilizados.

max-lease-time 7200; Tempo máximo que uma estação pode ficar com um endereço IP.

authoritative; Determina que este seja o principal servidor

DHCP da rede local.

subnet 192.168.0.0 netmask 255.255.255.0 { Define que faixa de endereços e máscara a

rede local utilizará.

range 192.168.0.1 192.168.0.100; Faixa de endereços que serão distribuídos automaticamente entre as estações.

option routers 192.168.0.250; Roteador (Gateway) da rede.

option domain-name-servers

208.67.222.222,208.67.220.220;

Endereços dos servidores DNS (neste caso,

usando endereços dos servidores públicos OpenDNS)

option broadcast-address 192.168.0.255; Endereço para pacotes broadcast.


host micro1 {

hardware ethernet 00:0C:29:A1:78:DA;

fixed-address 192.168.0.101; } host micro2 {

hardware ethernet 00:50:56:C0:00:01;

fixed-address 192.168.0.102; }

Seção que possibilita relacionar um endereço IP fixo ao endereço físico (MAC Address) da

placa de rede de uma estação.

} Finaliza as configurações do arquivo

dhcpd.conf.

Fora a configuração do dhcpd.conf, como o servidor possui duas placas de rede

também é importante configurar o DHCP para escutar somente a placa da rede local, já que é

somente às estações conectadas a esta interface que o servidor DHCP deverá responder. Esta

configuração é feita no arquivo “/etc/default/dhcp3-server”, alterando a linha

INTERFACES=“” por INTERFACES=“eth1” (MORIMOTO, 2008, p. 129).

Para que as alterações entrem em funcionamento, o serviço dhcp3-server é reiniciado

com o comando “sudo /etc/init.d/dhcp3-server restart”.

3. SERVIDOR PROXY SQUID

Um servidor Proxy como o Squid tem como principal finalidade servir como um

intermediário entre as máquinas da rede local e a Internet. É através dele que podemos definir

restrições baseadas em políticas de acesso (chamadas de ACLs) e um uso mais racional e

controlado da Internet; tendo também a vantagem de funcionar como um cache de páginas e

arquivos já acessados, economizando assim o uso da banda disponível e melhorando a

velocidade de acesso. Neste capítulo será demonstrado como implementar um servidor Proxy

transparente com o Squid.

3.1 Tipos de Proxy

O Squid pode ser configurado para atuar de diferentes formas de acordo com a

necessidade de uso da Internet na rede local. É possível usá- lo como um Proxy Tradicional,

configurando manualmente cada estação da rede; como um Proxy Transparente, com

redirecionamento automático de pacotes para o Squid; como Proxy com Autenticação,

exigindo usuário e senha para acesso; como um Proxy com Configuração Automática (PAC),

baseado em um script disponível em um servidor Web; e como Proxy WPAD, possibilitando

que os clientes localizem o script de configuração automaticamente.

3.1.1 Tradicional

O Proxy dito como tradicional ou comum é o tipo mais básico de configuração de um

Proxy como o Squid. Neste tipo de uso há a necessidade obrigatória de se configurar

manualmente cada uma das máquinas da rede, alterando as configurações dos navegadores

utilizados (como o Internet Explorer e Mozilla Firefox) para que acessem a Internet somente


pelo endereço do servidor Proxy. Sua principal desvantagem é justamente a pouca praticidade

de implementação.

3.1.2 Transparente

O Proxy Transparente atua a partir de uma regra de firewall, onde é configurado o

compartilhamento via NAT de modo que os acessos destinados à porta 80 possam ser

interceptados e direcionados ao Squid. Desta forma tudo passa obrigatoriamente por suas

regras de controle. Uma grande vantagem no uso de um Proxy Transparente reside no fato de

que as estações passam a receber esta configuração automaticamente a partir do gateway da

rede.

No entanto, esta solução também possui algumas restrições como, por exemplo, a

impossibilidade de se utilizar um sistema de autenticação juntamente com o Proxy

Transparente. Além disso, somente os dados trafegados na porta 80 são controlados.

3.1.3 Com Autenticação

Nesta modalidade de configuração é possível utilizar um sistema de autenticação para

que o usuário possa acessar a Internet com base em alguns critérios. O Squid passa a utilizar

um módulo de autenticação baseado em um arquivo de senhas para definição de quais

usuários poderão acessar a Internet. Também é possível fazer com que o Squid se autentique

em um servidor configurado como PDC (como o Samba ou mesmo o Active Directory).

3.1.4 PAC

Neste tipo de aplicação é utilizado um script PAC (Proxy Auto Configuration)

disponibilizado na rede local por meio de um servidor web como o Apache. Este arquivo é

criado em “/var/www/wpad.dat” com um pequeno conteúdo escrito em Javascript :

Function FindProxyForUrl(url, host)

{ Return “PROXY 192.168.0.250:3128”;

}


Este método ainda exige a configuração manual em cada estação para que o script seja

recebido e processado, fazendo com que utilizem o endereço do Proxy como forma de saída

para a Internet. No entanto, caso seja necessário efetuar alguma mudança na configuração de

Proxy nas estações, bastará mudar o script.

3.1.5 WPAD

O WPAD (Web Proxy Auto Discovery protocol) é uma forma de implementação que

usa como base o Proxy com script PAC juntamente com configurações nos servidores DHCP

e DNS da rede. Assim as estações são orientadas a buscar de forma automática o arquivo com

o script, bastando ativar nos navegadores das máquinas a opção que permita detectar

automaticamente as configurações de Proxy e Rede.

3.2 Instalação do Squid

Definido o tipo de Proxy que será utilizado na rede, é hora de iniciar sua

implementação no servidor Ubuntu Server.

A instalação do Squid segue o padrão comum a outros pacotes instalados no Ubuntu,

usando o comando “sudo apt-get install squid” (Figura 18).

Figura 18 – Instalação do Squid. FONTE: Arquivo do autor.


Sua configuração é feita no arquivo “/etc/squid/squid.conf”, que originalmente possui

uma série de comentários e exemplos para diversas configurações e é interpretado

sequencialmente pelo aplicativo.

3.3 Configuração básica como Proxy Transparente

Para simplificar o procedimento de configuração do Squid, o arquivo original

“squid.conf” é renomeado para “squid.conf.old”, e então é criado um novo arquivo

“/etc/squid/squid.conf”.

O novo arquivo terá inicialmente a configuração demonstrada na Figura 19:

Figura 19 – Configuração inicial do squid.conf. FONTE: Arquivo do autor.

O Quadro 5 apresenta a descrição das linhas utilizadas na configuração inicial do

arquivo squid.conf:

Quadro 5 – Configuração inicial do squid.conf.

Linha Função

http_port 3128 transparent Porta padrão utilizada pelo Squid e parâmetro que define o Proxy como


transparente.

visible_hostname konoha Nome do servidor.

acl all src 0.0.0.0/0.0.0.0 ACL com todos os endereços de rede

possíveis.

acl manager proto cache_object ACL para o protocolo cache_object (protocolo pertencente ao Squid).

acl localhost src 127.0.0.1/255.255.255.255 ACL para o endereço localhost do próprio servidor.

acl SSL_ports port 443 563 acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535

ACLs para portas que podem ser utilizadas pelo Proxy.

acl purge method PURGE ACL para o método PURGE (responsável por limpar objetos do

cache).

acl CONNECT method CONNECT ACL para o método CONNECT.

http_access allow manager localhost Regra que libera o acesso das ACLs

manager e localhost combinadas.

http_access deny manager Regra que nega a ACL manager.

http_access allow purge localhost Regra que libera o acesso das ACLs purge e localhost combinadas.

http_access deny purge Regra que nega a ACL purge.

http_access deny !Safe_ports Regra que nega as portas não especificadas na ACL Safe_ports.

http_access deny CONNECT !SSL_ports Regra que nega conectividade às portas não especificadas na ACL SSL_ports.

acl redelocal src 192.168.0.0/24 ACL para os endereços da rede local

http_access allow localhost Regra que libera o acesso vindo do

localhost (servidor).

http_access allow redelocal Regra que libera o acesso vindo da rede local.

http_access deny all Regra geral que nega o acesso a tudo que não foi especificado nas regras

anteriores.

Como o Proxy será usado de forma transparente, também é necessário adicionar ao

firewall Iptables (logo após a regra de compartilhamento NAT) uma regra que intercepte e

direcione o tráfego da porta 80 para o Squid:

iptables -t nat -A PREROUTING -i $conexlocal -p tcp --dport 80 -j REDIRECT --to- \ port 3128

Após estas configurações, as regras do Iptables são limpas (“sudo iptables -F”) e o

script do firewall é carregado novamente (“sudo firewall”). As novas configurações do Squid

também precisam ser carregadas usando o comando “sudo /etc/init.d/squid restart”.


Estas configurações são suficientes para que o Proxy funcione com um conjunto

mínimo de restrições de portas e de acesso local, permitindo que as estações já tenham acesso

à Internet.

3.4 Definindo o Cache do servidor Proxy

Depois de ativar o Squid com algumas funções básicas, é possível definir suas

configurações mais avançadas, como ajustes relacionados ao Cache.

O Squid utiliza as formas de cache em memória RAM (com pouco espaço e

velocidade maior) e em disco (com grande espaço de armazenamento, mas com acesso mais

lento).

A quantidade de espaço reservado na memória RAM e no disco rígido depende

principalmente do quanto de capacidade estes dispositivos de hardware possuem no servidor.

Para Morimoto (2008, p. 140) “como regra geral, você pode reservar 32 ou 64 MB para o

cache em um servidor dedicado, que atende a apenas alguns micros, e até 1/3 da memória

RAM total em um servidor Proxy dedicado, que atende a um volume maior de usuários”.

Em relação ao espaço reservado em disco, pode-se usar um valor alto caso haja

bastante espaço no disco rígido do servidor e se quiser que o Squid armazene os downloads

por um longo período (MORIMOTO, 2008, p. 141).

Considerando o servidor virtual implementado neste trabalho, uma máquina com 128

MB de memória RAM e HD de 7,5 GB, podem ser usados os seguintes ajustes para o Cache

do servidor:

Cache em memória RAM: 50 MB

Cache em disco (HD): 2 GB

Tamanho máximo de objeto na memória: 64 KB

Tamanho máximo de objeto no disco: 512 MB

Tamanho mínimo de objeto no disco: 0 KB

Também são especificados o arquivo que armazenará os logs de acesso do Squid e o

diretório que contém as páginas de erro em Português. Posteriormente, o Sarg (utilitário para

relatórios) utilizará o arquivo de log para gerar relatórios com informações sobre as páginas

acessadas pelas estações.

Depois de feitas as alterações, destacadas na imagem, o arquivo squid.conf terá a

configuração demonstrada na Figura 20:


Figura 20 – Configuração parcial do squid.conf. FONTE: Arquivo do autor.

O Quadro 6 apresenta a descrição das linhas acrescentadas na configuração parcial do

arquivo squid.conf:

Quadro 6 – Configuração parcial do squid.conf.

Linha Função

cache_mem 50 MB Quantidade reservada para o cache na memória RAM.

maximum_object_size_in_memory 64 KB Tamanho máximo dos arquivos armazenados no cache em memória.

maximum_object_size 512 MB Tamanho máximo dos arquivos armazenados no cache em disco.

minimum_object_size 0 KB Tamanho mínimo dos arquivos armazenados

no cache em disco.

cache_dir ufs /var/spool/squid 2048 16 256 Diretório onde o Squid armazenará os

arquivos, espaço reservado no disco rígido em MB, quantidade de pastas e subpastas que serão criadas dentro do diretório.

cache_access_log /var/log/squid/access.log Diretório e arquivo onde os logs do Squid


serão armazenados.

error_directory /usr/share/squid/errors/Portuguese

Diretório de páginas de erro (em português) usadas pelo Squid.

3.5 Regras para Políticas de Acesso (ACLs)

Além de funcionar como um cache para armazenar as páginas e arquivos já acessados,

o Squid também é normalmente utilizado como um meio de organizar e restringir o uso da

Internet de acordo com determinar regras.

Estas regras são definidas através de um conjunto de ACLs (Access Control List),

onde por meio de regras e parâmetros é possível criar configurações que restrinjam ou liberem

o acesso a domínios, palavras e IPs; que impeçam o download de arquivos com determinadas

extensões; dentre outras possibilidades.

Para este trabalho, serão criadas políticas de acesso baseadas em:

Bloqueio de sites (de acordo com domínios e palavras na URL);

Acesso livre para determinadas máquinas (de acordo com o MAC Address).

3.5.1 Bloqueio de sites

O bloqueio de sites no Squid é feito usando ACLs com as seguintes regras:

dstdomain: verifica os domínios, necessitando que se especifique os endereços

com e sem “www”;

url_regex: verifica os domínios, mas não bloqueia endereços dinâmicos passados

como parâmetro da URL;

dstdom_regex: verifica todas as palavras existentes na URL.

Estas regras podem ser combinadas ao mesmo tempo nas ACLs para obter um melhor

resultado no controle de acesso.

Sendo assim, o bloqueio dos domínios restritos será especificado com o auxílio de

uma lista de endereços num arquivo de texto comum, armazenado em um diretório como, por

exemplo, “/etc/squid/controle-de-acesso/sites-bloqueados”. O conteúdo do arquivo segue um

modelo simples, com cada endereço em uma linha como demonstrado na Figura 21:


Figura 21 – Arquivo com lista de endereços bloqueados. FONTE: Arquivo do autor.

Com a lista definida, basta apenas escrever a ACL usando “url_regex” e a referência

ao arquivo, além da regra “http_access deny” para negar o acesso.

acl bloqueados url_regex -i “/etc/squid/controle-de-acesso/sites-bloqueados” http_access deny bloqueados

De forma complementar, também é possível utilizar uma lista (“/etc/squid/controle-de-

acesso/palavras”) com palavras que serão verificadas pela regra “dstdom_regex” (Figura 22).

Figura 22 – Arquivo com lista de palavras bloqueadas. FONTE: Arquivo do autor.

Em seguida, definimos a ACL:

acl palavras dstdom_regex “/etc/squid/controle-de-acesso/palavras” http_access deny palavras

3.5.2 Controle de acesso de máquinas

As ACLs podem ser usadas também para definir o controle de acesso de determinadas

estações da rede local.

É possível definir uma lista dos MAC Addresses das máquinas que poderão ter acesso

irrestrito (Figura 23):


Figura 23 – Arquivo com lista de endereços MAC de máquinas. FONTE: Arquivo do autor.

Com o parâmetro “arp” e a regra “http_access allow” configuramos a ACL para

permitir o acesso destes endereços MAC:

acl diretoria arp “/etc/squid/admin/diretoria” http_access allow diretoria

Como o squid.conf é lido sequencialmente pelo Squid, as regras que abrem o acesso

devem vir antes de regras de restrição para que funcionem corretamente.

Depois de definir as ACLs, o arquivo squid.conf estará com as configurações

mostradas na Figura 24:


Figura 24 – Arquivo squid.conf configurado com ACLs. FONTE: Arquivo do autor.

Para que as regras entrem em funcionamento, é necessário que o Squid recarregue as

novas configurações, tarefa que pode ser feita com o comando “sudo /etc/init.d/squid reload”.

Feito isso, ao tentar acessar uma dos domínios bloqueados ou endereços com alguma

palavra proibida na URL, o usuário encontra uma página de erro informando q ue o acesso foi

negado (Figura 25).


Figura 25 – Acesso negado pelo Squid. FONTE: Arquivo do autor.

3.6 SquidGuard

O SquidGuard é um aplicativo que permite usar longas listas com milhões de URLs de

sites impróprios (pornográficos, downloads ilegais, cracks, drogas etc), auxiliando o Squid na

tarefa de bloquear o acesso a estes endereços sem com isso prejudicar o desempenho do Proxy

(MORIMOTO, 2008, p. 168).

Regras como “url_regex” e “dstdom_regex” são úteis na tarefa de bloquear endereços

ou termos específicos. No entanto, para bloquear a maior parte dos milhões de endereços de

sites impróprios existentes na Internet, há a necessidade de se utilizar uma grande lista de

URLs mantida por grupos como o MESD Blacklists e Shalla’s Blacklists. O uso de listas a

partir do SquidGuard torna as tarefas de restrição muito mais eficientes e práticas para o

Squid, já que a necessidade de ficar constantemente atualizando as listas originalmente usadas

pelo squid.conf acaba sendo drasticamente reduzida.

3.6.1 Instalação e Configuração

A instalação do SquidGuard é feita usando o comando “sudo apt-get install

squidguard”.


Também é necessário baixar pelo menos uma das listas que será usada pelo programa.

No servidor implementado neste trabalho, será utilizada a lista do MESD que pode ser

baixada usando o comando “wget –c http://squidguard.mesd.k12.or.us/blacklists.tgz”.

Usando agora o usuário root do sistema, após o download a lista é copiada com o

comando “cp blacklists.tgz /var/lib/squidguard/db” para o diretório “/var/lib/squidguard/db” e

em seguida é descompactada usando o comando “tar -zxvf blacklists.tgz”.

Ao acessar o diretório “/var/lib/squidguard/db/blacklists” é possível visualizar uma

lista de diretórios divididos por assuntos (Figura 26).

Figura 26 – Diretório blacklists. FONTE: Arquivo do autor.

O conteúdo da lista inclui domínios e URLs relacionadas a sites de entretenimento

como o Youtube e MSN Web Messenger, passando por sites inerentes a redes sociais (como

Orkut), sites com endereços de servidores Proxy públicos, rádios online, além de sites

pornográficos e muitos outros.

Com o SquidGuard instalado e a lista MESD disponível, é necessário editar o arquivo

“/etc/squid/squidGuard.conf” para especificar as seções da lista que serão usadas.

Para o bloqueio de sites com conteúdo pornográfico, drogas, violência, softwares

piratas e servidores de Proxy público, o arquivo pode ser configurado da forma mostrada na

Figura 27:


Figura 27 – Arquivo squidGuard.conf. FONTE: Arquivo do autor.

As classes “dest” indicam o nome da seção e a localização dos endereços de domínio

(domainlist) e das URLs (urllist) da blacklist. A última ACL, por meio do parâmetro “pass”,

indica a forma como as classes “dest” serão tratadas, sendo que os itens com o sinal de

exclamação (“!”) antes do nome terão o acesso bloqueado com redirecionamento (redirect)

automático para uma outra página ou site (no caso o site Google, na configuração

demonstrada na figura anterior).

Por fim, é necessário também converter a lista para o formato Berkeley DB usando o

comando “squidGuard -C all”. Esta conversão possibilita que o acesso ao conteúdo da lista

seja feito de forma mais rápida do que como um arquivo de texto comum.

3.6.2 Ajustando as permissões de acesso e alterando o Squid

Após a instalação e configuração inicial do SquidGuard, há ainda a necessidade de

ajustar as permissões de acesso aos arquivos do aplicativo para que o Squid possa acessá- los.

O ajuste de permissões é feito em três etapas:


chown -R proxy:proxy /var/lib/squidguard/db/* : com este comando, o usuário e

grupo proxy (pertencentes ao Squid) passam a ter acesso aos arquivos do diretório

do SquidGuard;

find /var/lib/squidguard/db –type f | xargs chmod 644 : usando o comando

“find” e o parâmetro “-type f”, todos os arquivos do diretório

/var/lib/squidguard/db são localizados. Logo em seguida são direcionados pelo

“xargs” como parâmetros para o comando “chmod 644”.

find /var/lib/squidguard/db –type d | xargs chmod 755: novamente usando o

“find” com o parâmetro “-type d”, todos os diretórios do diretório

/var/lib/squidguard/db são localizados e em seguida direcionados pelo “xargs”

como parâmetros para o comando “chmod 755”.

Com todos os ajustes de permissões feitos, agora é necessário adicionar a linha

“redirect_program /usr/bin/squidGuard” antes das regras que liberam o acesso da rede local

(http_access allow localhost e http_access allow redelocal). Com esta linha o SquidGuard

passa a ser ativado fazendo com que as requisições passem por ele.

Para que todas as alterações entrem em funcionamento, basta apenas reiniciar o Squid

com o comando “/etc/init.d/squid restart”.

3.7 Monitorando os acessos com o Sarg

O Sarg (Squid Analysis Report Generator) é um aplicativo que interpreta os logs do

Squid e gera relatórios com informações sobre as páginas acessadas a partir de qualquer

máquina da rede. Com esses relatórios é possível monitorar quais sites estão sendo acessados

pelos usuários e, gradativamente, ir adaptando os filtros do Squid.

A instalação do pacote é feita usando o comando “sudo apt-get install sarg”, e sua

configuração principal é definida no arquivo “/etc/squid/sarg.conf”. Usando o nano para editá-

lo, as seguintes configurações serão feitas:

Idioma – Language Portuguese

Formato de data (dd-mm-yy): date_format e

Para usar o Sarg basta chamá-lo com o comando “sudo sarg”, e os relatórios serão

gerados e gravados automaticamente no diretório “/var/www/squid-reports”. Caso seja

necessário gerar um relatório de algum período específico, pode-se usar o comando “sudo

sarg -d dd/mm/yyyy-dd/mm/yyyy”. Exemplo: “sudo sarg –d 20/02/2009-28/02/2009”.


Com o tempo os relatórios vão ocupando muito espaço em disco, sendo necessário

eventualmente movê- los para outra mídia ou apagá- los conforme ficam antigos.

Posteriormente, estes relatórios poderão ser visualizados em qualquer navegador na

rede local com a utilização de um gerenciador web, como Webmin, que será abordado no

capítulo 5 deste trabalho.

4. SERVIDOR DE ARQUIVOS SAMBA

Um servidor de arquivos (File Server) como o Samba possibilita aos usuários

armazenar seus arquivos em um local centralizado na rede, podendo compartilhá- los

facilmente com outros usuários e acessá- los a partir de outras máquinas da rede com

segurança e praticidade (VAN VUGT, 2008, p. 299).

Para Morimoto (2008, p. 245) “hoje, além de ser quase 100% compatível com os

recursos de rede do Windows 98, NT, 2000 e XP, o Samba é reconhecido por ser mais rápido

que o próprio Windows na tarefa de servidor de arquivos”.

Neste capítulo será demonstrada a implementação do Samba como servidor de

arquivos, desde sua instalação, cadastro de usuários, configuração dos compartilhamentos de

diretórios editando o arquivo smb.conf, além de ajustes de permissão para acesso.

4.1 Instalação do Samba

O Samba possui originalmente os módulos de instalação como servidor e como cliente

(smbclient). O módulo cliente tem somente a finalidade de permitir o acesso a

compartilhamentos em outras máquinas ou servidores. Já o módulo servidor, é o necessário

para configuração do Samba como um servidor de arquivos na rede.

O pacote do servidor Samba com módulo servidor é instalado no Ubuntu Server

utilizando o comando “sudo apt-get install samba”.

4.2 Usuários

Após instalar o Samba, é necessário cadastrar os usuários (login e senha) que farão

acesso aos compartilhamentos do servidor. Como o Samba roda sobre o sistema operacional,


os usuários que irão acessar o servidor precisam estar necessariamente cadastrados no

sistema.

A quantidade de usuários que devem ser cadastrados no sistema e no Samba, além das

características e privilégios que cada um deve ter, varia de acordo com o que foi planejado em

relação ao uso do Servidor na rede. Para o servidor virtual desenvolvido neste trabalho, serão

cadastrados no sistema (e depois no Samba) mais três usuários: “neil”, “geddy”, e “alex”. O

usuário administrativo “tiago” já existe no sistema e posteriormente também será adicionado

ao servidor Samba.

4.2.1 Cadastro de usuários no sistema

O cadastro de usuários no Ubuntu Server é feito através do comando “sudo adduser

nomedousuario”, especificando obrigatoriamente pelo menos o nome de usuário ( login) que

se deseja criar e uma senha (password).

Os usuários “tiago”, “neil”, “geddy” e “alex” terão acesso livre aos seus próprios

diretórios compartilhados, além de acesso controlado à outros que serão definidos em seguida

configurando as seções de compartilhamento do “smb.conf”.

Ao usar o comando “sudo adduser neil” o utilitário solicita as informações que serão

cadastradas para o novo usuário chamado “neil”, (Figura 28).

Figura 28 – Adicionando usuários ao sistema. FONTE: Arquivo do autor.


Os usuários “geddy” e “alex” também devem ser adicionados ao sistema usando o

mesmo comando utilizado para adicionar o usuário “neil”.

Usando o comando “sudo adduser nomedousuario” sem nenhum parâmetro é criado

um usuário real no sistema, ou seja, um usuário que realmente pode acessar o servidor e

possui seu próprio diretório de arquivos e configurações, o que de certa forma pode dar

margem a alguma brecha de segurança.

Uma alternativa é criar o usuário sem permissão de acesso ao servidor (com o login

desabilitado) e sem o diretório “/home” (que possui seus arquivos e configurações). Por

exemplo, para criar um usuário chamado teste, seria utilizado o comando “sudo adduser --

disabled- login --no-create-home teste”. Este usuário passaria a ter acesso somente ao

compartilhamento configurado no Samba pelo Administrador, sem qualquer possibilidade de

acessar o terminal do servidor.

4.2.2 Cadastro de usuários no Samba

Com os usuários cadastrados no sistema operacional, agora é necessário adicioná- los

ao servidor Samba. Esta tarefa é executada para cada usuário usando o comando “sudo

smbpasswd -a nomedousuario”, especificando em seguida uma senha (que não precisa ser

necessariamente a mesma senha usada no sistema) para acesso ao servidor Samba.

Desta forma, para adicionar o usuário “tiago” se utiliza o comando na forma mostrada

na Figura 29.

Figura 29 – Adicionando usuários ao servidor Samba. FONTE: Arquivo do autor.

Os usuários “neil”, “geddy” e “alex” usados no desenvolvimento deste trabalho

também são adicionados usando o mesmo comando utilizado para adicionar o usuário “tiago”.

O comando smbpasswd também pode ser utilizado com outros parâmetros, como

“smbpasswd -d nomedousuario” para desativar um usuário cadastrado no Samba,

“smbpasswd -e nomedousuario” para habilitar um usuário inativo e “smbpasswd -x


nomedousuario” para remover um usuário do servidor Samba, sendo esta última opção

normalmente combinada posteriormente com o uso do comando “deluser nomedousuario”

para removê-lo também do sistema.

4.3 Configuração usando o smb.conf

A configuração do servidor Samba pode ser feita editando diretamente o arquivo

“/etc/samba/smb.conf” ou com o auxílio de aplicativos de administração via web, como o

Swat e o Webmin. Para o servidor de Arquivos desenvolvido neste trabalho, será demonstrada

a configuração feita manualmente no smb.conf usando um editor de texto como o nano.

O arquivo “smb.conf” disponível após a instalação do pacote samba é bastante

extenso, possuindo dezenas de linhas comentadas com explicações sobre seus parâmetros.

Assim como feito em relação ao “squid.conf” (arquivo de configuração do Squid), é

recomendável renomear o arquivo original “smb.conf” para “smb.conf.old” usando o

comando “sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.old”, e então criar um novo

arquivo “smb.conf” usando o comando “sudo nano /etc/samba/smb.conf” e escrever sua

configuração desde o início.

Desta forma, é possível configurar um arquivo mais simples contendo somente as

opções e parâmetros necessários para o funcionamento do servidor de Arquivos.

4.3.1 Configuração global

O arquivo “smb.conf” é dividido em seções, sendo que a primeira seção de

configuração é a [global]. Nesta seção é definida a configuração geral do servidor, onde

podemos especificar diversas opções tais como nome do servidor, grupo de trabalho, nível de

segurança, faixa de endereços que terão ou não acesso aos compartilhamentos, definição da

interface de rede que o servidor usará, dentre outras opções.

Para o desenvolvimento do servidor Samba deste trabalho, usando o comando “sudo

nano /etc/samba/smb.conf”, a seção [global] será configurada com as opções e parâmetros

mostrados na Figura 30:


Figura 30 – Configuração da seção [global] no smb.conf. FONTE: Arquivo do autor.

Muitas opções possíveis no “smb.conf” são o padrão nativo de configuração do

Samba. Por exemplo, a opção “security = user”, que define o nível de segurança do Samba

como sendo baseado em usuário, não precisa ser colocada no arquivo, já que ela é uma

configuração padrão global para o servidor.

O Quadro 7 apresenta a descrição das linhas utilizadas na configuração da seção

[global] do arquivo smb.conf:

Quadro 7 – Configuração da seção [global] do smb.conf.

Linha Função

netbios name = Konoha Opção que define o nome do servidor Samba.

server string = Samba Server Opção que define uma descrição para o servidor.

workgroup = REDELOCAL Grupo de trabalho no qual o servidor aparecerá.

username level = 2 Opção que verifica em até dois níveis as possíveis combinações entre letras maiúsculas e minúsculas digitadas

em nomes de logins.

preserve case = no default case = lower

Opções que fazem com que o Samba salva todos os arquivos em letras minúsculas, evitando possíveis problemas ao

localizar arquivos.

interfaces = eth1

bind interfaces only = yes Opções que orientam o Samba a utilizar somente a interface

conectada à rede local (no caso, a eth1).

local master = yes Opção que possibilita ao Samba convocar (quando necessário) uma eleição para manter-se como servidor

preferencial na rede.

os level = 100 Opção para credenciar o Samba como servidor preferencial

da rede, utilizando para isso um nível (de 0 a 255). Usando qualquer valor alto (acima de 32), o Samba vence a eleição


se utilizado em uma rede com outros servidores Windows.

preferred master = yes Com esta opção ativada, o servidor terá preferência caso exista outra máquina com o mesmo nível (“os level”) na

rede.

wins support = yes Opção que faz o Samba atuar também como um servidor WINS, auxiliando as estações Windows em tarefas como

navegação na rede e listagem de compartilhamentos.

Com o servidor WINS ativado, é necessário que as estações sejam configuradas para

utilizá- lo. Esta tarefa pode ser automatizada adicionando a linha “option netbios-name-servers

192.168.0.250;” às configurações de rede do servidor DHCP através do arquivo

“/etc/dhcp3/dhcpd.conf” (Figura 31), e em seguida reiniciando-o.

Figura 31 – Adicionando endereço do servidor WINS no DHCP. FONTE: Arquivo do autor.

O Samba possui um utilitário chamado “testparm” utilizado para analisar o arquivo

smb.conf. Digitando “sudo testparm” o programa é iniciado e começa a analisar o arquivo,

verificando se há alguma configuração incorreta, informando ao Administrador os parâmetros

a serem corrigidos (caso existam) no “smb.conf” (Figura 32).


Figura 32 – Verificação do smb.conf usando o testparm. FONTE: Arquivo do autor.

A linha “Loaded services file OK” indica que a configuração não possui erros.

Após verificar o “smb.conf”, é necessário reiniciar o Samba usando o comando “sudo

/etc/init.d/samba restart” para que as configurações entrem em funcionamento. Ainda não há

compartilhamentos, mas esta configuração é suficiente para que o Samba fique disponível

através dos “Meus locais de rede” nas estações Windows (Figura 33):

Figura 33 – Visualizando o servidor nos Meus locais de rede da estação. FONTE: Arquivo do autor.


4.3.2 Criação dos compartilhamentos

A criação dos compartilhamentos é feita por meio de seções com o nome do

compartilhamento que se deseja criar configuradas logo após a seção [global] do “smb.conf”.

Neste servidor, serão criadas seções de compartilhamento para o diretório de cada

usuário cadastrado no sistema e no Samba (no caso, os usuários “tiago”, “neil”, “geddy”, e

“alex”), além de compartilhamentos para acesso geral e restrito, chamados respectivamente de

“publico” e “arquivos”. Os diretórios para estes dois compartilhamentos são criados usando o

comando “sudo mkdir /home/publico /home/arquivos” (Figura 34).

Figura 34 – Criação dos diretórios publico e arquivos. FONTE: Arquivo do autor.

Antes de definir as seções de compartilhamento no “smb.conf”, é possível criar um

diretório vazio dentro do “/home” de cada usuário e usá- lo como diretório de

compartilhamento. Esta prática evita que, ao compartilhar o diretório “/home” inteiro do

usuário, os arquivos e diretórios de configuração de programas fiquem expostos ao acessar o

compartilhamento na rede, o que pode dificultar a organização e visualização dos arquivos

realmente importantes daquele usuário.

Sendo assim, após acessar o diretório /home, criaremos um diretório chamado “share”

dentro dos diretórios dos usuários “tiago”, “neil”, “geddy”, e “alex”, utilizando o comando

“sudo mkdir tiago/share neil/share geddy/share alex/share”. Para que o diretório “share” seja

criado automaticamente caso outros usuários sejam cadastrados no sistema, basta adicioná- lo

ao diretório modelo “/etc/skel” com o comando “sudo mkdir /etc/skel/share”.

Após a definição dos diretórios, as seções de compartilhamentos são configuradas no

“smb.conf”, como mostrado na Figura 35:


Figura 35 – Seções de compartilhamento no smb.conf. FONTE: Arquivo do autor.

O Quadro 8 apresenta a descrição das linhas acrescentadas para a configuração das

seções de compartilhamento no arquivo “smb.conf”:

Quadro 8 – Configuração das seções de compartilhamento no smb.conf.

Linha Função

[homes] Usando “homes” como nome de seção, o Samba faz o

compartilhamento de todos os usuários cadastrados no sistema de forma automática.

path = /home/%u/share Caminho para o diretório que será compartilhado.

valid users = %S Usuários válidos. Configurado com a variável %S, faz com que a pasta fique disponível somente para o próprio

usuário.

writable = yes Define que o compartilhamento possui permissão de

escrita.

create mask = 0700 directory mask = 0700

As duas opções definem o padrão para criação e remoção de arquivos e diretórios no compartilhamento,

neste caso, restringindo estas tarefas a somente o próprio usuário.

browseable = no O compartilhamento não será visível por outros usuários.

[arquivos] Nome do compartilhamento.

path = /home/arquivos/ Caminho para o diretório que será compartilhado.

valid users = +arquivos, +publico Usuários válidos, podendo ser especificado uma lista de

nomes de usuários e/ou um ou vários nomes de grupos de usuários do sistema precedidos do sinal “+”. Neste caso, os grupos “arquivos” e “publico” podem acessar o

compartilhamento [arquivos].

writable = yes Define que o compartilhamento possui permissão de

escrita.


read list = +publico Opção que define que os usuários participantes do grupo

“publico” poderão somente ler o conteúdo do compartilhamento [arquivos].

[publico] Nome do compartilhamento.

path = /home/publico/ Caminho para o diretório que será compartilhado.

valid users = +publico, +arquivos Usuários válidos. Neste caso, todos os usuários dos grupos “publico” e “arquivos”.

writable = yes Define que o compartilhamento possui permissão de escrita.

read list = +arquivos Os usuários participantes do grupo “arquivos” poderão

somente ler o conteúdo do compartilhamento [publico].

Com as configurações feitas, o Samba deve ser reiniciado (“sudo /etc/init.d/samba

restart”) e em seguida já será possível visualizar os compartilhamentos nos “Meus locais de

rede” das estações Windows (Figura 36):

Figura 36 – Visualizando os compartilhamentos nas estações Windows. FONTE: Arquivo do autor.

4.4 Ajustes de permissões no sistema

A organização dos privilégios de acesso aos compartilhamentos pode ser facilitada

com o uso de grupos de usuários no sistema e com a definição de permissões para estes

grupos. Utilizando este método é possível fazer a administração sobre quais usuários poderão

acessar os compartilhamentos definidos no Samba de uma forma prática e centralizada.


4.4.1 Grupos de usuários

Para os usuários utilizados neste servidor serão criados dois grupos, chamados de

“arquivos” e “publico”. Os usuários pertencentes ao grupo “arquivos” terão acesso livre para

leitura e escrita ao compartilhamento “arquivos”, e acesso para somente leitura no

compartilhamento “publico”. Já os usuários que pertencem ao grupo “publico”, terão acesso

livre a somente este compartilhamento, no entanto, poderão visualizar o conteúdo do

compartilhamento “arquivos”. A criação dos grupos é feita utilizando os comandos “sudo

groupadd arquivos” e “sudo groupadd publico”. A inclusão dos usuários é feita utilizando o

comando “sudo adduser nomedousuario nomedogrupo”.

A Figura 37 mostra a inclusão dos usuários “tiago” e “neil” ao grupo “arquivos”; e dos

usuários “geddy” e “alex” ao grupo “publico”.

Figura 37 – Inclusão de usuários em grupos. FONTE: Arquivo do autor.

4.4.2 Permissões de acesso

Depois de cadastrar os usuários no sistema e no Samba, configurar os

compartilhamentos no “smb.conf” e gerenciar os grupos de usuários, ainda há a necessidade

de ajustar as permissões de acesso dos diretórios utilizados pelos usuários cadastrados, além

dos grupos “arquivos” e “publico” e de seus diretórios. Sem estes ajustes, os usuários poderão

acessar os compartilhamentos, mas as permissões definidas somente pelo Samba não serão

suficientes para autorizar a escrita nos diretórios onde possuem acesso (Figura 38).


Figura 38 – Gravação negada no compartilhamento. FONTE: Arquivo do autor.

Mesmo que nas configurações do Samba exista a permissão de escrita nos

compartilhamentos, se os diretórios foram criados como root (usando o comando sudo) então

o padrão é que apenas ele possa gravar arquivos no diretório. (MORIMOTO, 2008, p. 267).

A Figura 39 mostra como alterar a propriedade dos diretórios “share” dos usuários

configurados no servidor utilizando o comando “sudo chown -R”, fazendo com que cada

usuário seja dono de seu respectivo diretório.

Figura 39 – Alteração da propriedade dos diretórios share. FONTE: Arquivo do autor.

Após as alterações, os usuários já podem gravar em seus próprios compartilhamentos

(Figura 40).


Figura 40 – Gravação autorizada no compartilhamento. FONTE: Arquivo do autor.

Quanto aos compartilhamentos “arquivos” e “publico”, também é necessário permitir

o acesso aos diretórios “/home/arquivos” e “/home/publico” a partir dos grupos “arquivos” e

“publico”, respectivamente, utilizando para isso os comandos “sudo chgrp -R”, responsável

por trocar o grupo dono do diretório e “sudo chmod 775”, que permite o acesso irrestrito do

dono do diretório e do grupo (Figura 41).

Figura 41 – Ajustes de permissões para os grupos e seus diretórios. FONTE: Arquivo do autor.

Depois dos ajustes, os usuários já podem acessar corretamente os compartilhamentos

“arquivos” e “publico”, podendo ler e/ou escrever de acordo com suas permissões de acesso

controladas pelo servidor Samba (Figura 42).


Figura 42 – Acesso aos compartilhamentos “arquivos” e “publico”. FONTE: Arquivo do autor.

5. ACESSO REMOTO

A implementação de um servidor de rede sempre envolve também a tarefa de

administrá-lo, não só para alterar suas configurações quando necessário, mas também para

atualizar seus programas e monitorar seu funcionamento. Tarefas como estas poderiam exigir

a presença do Administrador à frente da máquina, executando as ações necessárias

localmente. No entanto, com a utilização de algumas ferramentas e aplicativos, é possível

acessar o servidor remotamente e executar estas mesmas tarefas a partir de qualquer outra

máquina da rede local ou mesmo da Internet.

Neste capítulo serão demonstradas as tarefas de instalação de um servidor OpenSSH

combinado com a utilização do serviço de DNS dinâmico “no-ip”, tornando possível o acesso

remoto ao servidor de uma forma prática e segura utilizando o software PuTTY, além da

utilização do gerenciador Webmin, responsável por permitir a administração remota do

servidor através de uma interface gráfica acessível pelo navegador de Internet de qualquer

computador.

5.1 Servidor OpenSSH

O SSH é um serviço que possibilita o acesso remoto seguro ao servidor utilizando

chaves de encriptação em toda a comunicação feita entre cliente/servidor (SILVA, 2007, p.

249).

Segundo Morimoto (2008, p. 512), “o SSH utiliza um conjunto de técnicas de

criptografia para assegurar que apenas as pessoas autorizadas tenham acesso ao servidor, que

todos os dados transmitidos sejam impossíveis de decifrar e que a integridade da conexão seja

mantida”.

Para Barret e Silverman (2001, p. 130) “o OpenSSH é uma implementação livre do

SSH”.


5.1.1 Instalação e configuração no servidor

O OpenSSH é dividido em dois módulos, chamados de “openssh-server” (para o

servidor) e “openssh-client” (para clientes Linux). Para clientes Windows é utilizado um

software compatível com o SSH, como é o caso do PuTTY (que será abordado mais adiante).

A instalação do OpenSSH no servidor segue o mesmo procedimento utilizado na

instalação de outros pacotes de software no Ubuntu Server, utilizando o comando “sudo apt-

get install openssh-server”. Sua configuração é feita editando o arquivo “/etc/ssh/sshd_config”

(Figura 43).

Figura 43 – Arquivo sshd_config original. FONTE: Arquivo do autor.

O arquivo sshd_config possui diversas linhas com a configuração padrão do SSH.

Como feito anteriormente em relação aos outros serviços instalados, é possível renomear o

arquivo original “sshd_config” para “sshd_config.old” e criar um novo arquivo sshd_config

usando o comando “sudo nano /etc/ssh/sshd_config”, escrevendo em seguida sua

configuração de uma forma simplificada. Os parâmetros que não forem especificados no

arquivo serão carregados pelo servidor com suas opções padrão.


A Figura 44 mostra a configuração adotada para o servidor desenvolvido neste

trabalho.

Figura 44 – Arquivo sshd_config configurado. FONTE: Arquivo do autor.

O Quadro 9 apresenta a descrição das linhas configuradas no arquivo sshd_config:

Quadro 9 – Configuração do arquivo sshd_config.

Linha Função

Port 22 Porta padrão utilizada pelo servidor SSH, já aberta no Firewall Iptables anteriormente.

Protocol 2 Versão do protocolo SSH, atualmente na versão 2.

PermitRootLogin no Opção que nega o acesso remoto ao servidor pelo

usuário root do sistema.

AllowUsers tiago Opção que restringe o acesso a somente os usuários especificados. Neste caso, apenas ao usuário

administrativo “tiago”.

PermitEmptyPasswords no Opção que nega o acesso remoto aos usuários que não

possuam senha.

X11Forwarding no Quando ativada (“yes”), esta opção ativa o suporte a execução remota de aplicativos gráficos.

Subsystem sftp /usr/lib/sftp-server Módulo SFTP, responsável pelo suporte a transferência de arquivos.

Com as configurações feitas, o SSH deve ser reiniciado (“sudo /etc/init.d/ssh restart”)

para que as alterações entrem em funcionamento.


5.2 Administração remota

Com o SSH em funcionamento, já é possível acessar o servidor a partir de qualquer

outra máquina da rede local ou mesmo a partir da Internet.

O acesso e a administração remota apenas ficam condicionados ao usuário

administrativo saber o endereço IP do servidor, o nome de usuário (login) e a senha

(password) autorizados para acessar o servidor via SSH.

Para o acesso a partir de qualquer máquina dentro da rede local esta tarefa é mais

simples, já que a informação sobre o número IP privado do servidor normalmente já é

conhecida pelo usuário administrativo, ou facilmente descoberta consultando as propriedades

da conexão de rede de qualquer estação conectada à rede local. Mas para o acesso externo via

Internet, onde se usa um endereço IP público e dinâmico no caso deste servidor, existe a

necessidade de se descobrir qual o endereço IP que o servidor estará utilizando em

determinado momento. Ou, como alternativa mais prática, utilizar um serviço de DNS

dinâmico como o “no- ip”.

5.2.1 Usando o no-ip como DNS dinâmico

Um serviço de DNS dinâmico (DDNS) atua por meio de um software responsável por

monitorar as informações sobre o endereço IP que o servidor possui enquanto está conectado

à Internet, enviando estas informações para um servidor externo do serviço. Assim, a partir

deste serviço é possível utilizar um subdomínio ligado ao endereço IP atual do servidor.

Mesmo que o servidor seja reiniciado ou a conexão mude de endereço IP, o software instalado

no servidor continuará se comunicando com o servidor externo do serviço DDNS e,

conseqüentemente, atualizando o subdomínio para o endereço IP corrente do servidor.

Desta forma, para acessar o servidor remotamente bastará utilizar o endereço do

subdomínio referente ao serviço DDNS, além das informações de login e senha autorizados

para acesso.

Existem diversos serviços DDNS gratuitos, como é o caso do “no- ip” (http://www.no-

ip.com/newUser.php), utilizado com o servidor desenvolvido neste trabalho a partir do

cadastro do subdomínio “konoha-server.no-ip.info” (Figura 45).


Figura 45 – Gerenciador de Hosts do serviço DDNS no- ip. FONTE: Arquivo do autor.

No servidor é necessário instalar e configurar o pacote “no-ip” utilizando o comando

“sudo apt-get install no- ip”. Depois de instalado no sistema, o software carrega

automaticamente um assistente de configuração que solicita os dados cadastrados no site do

serviço, além do domínio registrado para o DDNS, sendo para este servidor o endereço

konoha-server.no-ip.info (Figura 46).

Figura 46 – Assistente de configuração do no- ip. FONTE: Arquivo do autor.

5.2.2 PuTTY

Para Silva (2007, p. 255) “O PuTTY é um cliente SSH Win32 que possui suporte aos

protocolos versão 1 e 2 do SSH, aceita compactação além de funcionar também como cliente

telnet”. O PuTTY possui muitas funções e tem uma utilização bastante simples não

precisando sequer ser instalado. Ele pode ser obtido no site http://www.putty.org/.


Ao executar o programa a partir de qualquer máquina na rede, é necessário definir o

endereço IP do servidor (ou o endereço no- ip criado anteriormente, no caso de acesso pela

Internet) no campo “Host Name [or IP address]” e a porta utilizada pelo SSH, por padrão a

porta 22 (Figura 47), já aberta anteriormente no firewall Iptables (Capítulo 2). No campo

“Saved Sessions” é possível também definir um nome para a sessão e salvá- la, facilitando o

acesso nas próximas vezes.

Figura 47 – Configuração do PuTTY. FONTE: Arquivo do autor.

Ao abrir pela primeira vez uma sessão com o servidor, o PuTTY exibe uma janela de

alerta informando que a chave pública do servidor ainda não está armazenada na máquina, e

pergunta se o usuário deseja adicionar esta chave ao cache do PuTTY para autorizar a

conexão (Figura 48).


Figura 48 – Alerta sobre a chave e autorização de acesso ao servidor. FONTE: Arquivo do autor.

Respondendo “Sim” o acesso é liberado para esta e para outras vezes, e em seguida é

apresentada uma tela solicitando login e senha para acesso. Após digitar os dados do usuário

administrativo tiago, o terminal de comandos do servidor surge e o usuário já pode utilizá- lo

remotamente (Figura 49).

Figura 49 – Acesso remoto ao servidor via SSH pelo PuTTY. FONTE: Arquivo do autor.


5.2.3 Webmin

Para Cameron (2004, p. 1), “Webmin é um programa que simplifica o processo de

administração de sistema Linux ou Unix”.

O programa está disponível no site http://www.webmin.com em versões para várias

distribuições Linux.

No caso do Ubuntu, é necessário baixar o pacote em formato “.deb”, usando o

comando “wget -c http://prdownloads.sourceforge.net/webadmin/webmin_1.470_all.deb”.

Como mostrado na Figura 50, a instalação do pacote “.deb” do Webmim é feita

utilizando o comando “sudo dpkg - i”.

Figura 50 – Tentativa de instalação do pacote “.deb” do Webmin. FONTE: Arquivo do autor.

No entanto, ao tentar fazer a instalação pela primeira vez surgem algumas mensagens

de erro relacionadas a dependências de instalação, ou seja, o sistema não possui alguns dos

módulos necessários para instalação e execução do Webmin. Este problema é solucionado

utilizando o comando “sudo apt-get install -f” (Figura 51).


Figura 51 – Resolução de dependências e instalação usando o “apt-get install - f”. FONTE: Arquivo do autor.

O comando resolve as dependências e em seguida instala automaticamente o pacote

“deb” do Webmin. Logo depois o Webmin está pronto para ser utilizado em um navegador

usando o endereço “https://konoha:10000” a partir de qualquer estação da rede. Para acesso

externo via Internet, bastaria usar o endereço “https://konoha-server.no-ip.info:10000”. O

número 10000 é referente à porta utilizada por padrão para acesso ao Webmin. Esta porta já

foi aberta anteriormente no firewall Iptables (Capítulo 2).

Ao acessar o Webmin pela primeira vez em um navegador como o Firefox, surge uma

mensagem informando que o certificado de segurança utilizado pelo aplicativo é inválido

(Figura 52).


Figura 52 – Primeiro acesso ao Webmin pelo Firefox. FONTE: Arquivo do autor.

No entanto, o certificado de segurança do Webmin é do tipo self-signed (auto-

assinado), e podemos adicionar uma exceção ao navegador para que seu acesso seja

autorizado. A Figura 53 mostra a janela que permite adicionar uma exceção de segurança no

Firefox.

Figura 53 – Adicionando uma exceção de segurança no Firefox. FONTE: Arquivo do autor.


Assim que a exceção é criada, o acesso ao endereço do servidor e Webmin é

autorizado e a tela de login do sistema é exibida (Figura 54).

Figura 54 – Tela de login do Webmin. FONTE: Arquivo do autor.

Logo após colocar o nome de usuário administrativo do sistema e a senha de acesso e

clicar em “Login”, a tela inicial do Webmin é exibida com informações sobre as

configurações gerais do servidor, e do lado esquerdo os módulos de acesso às suas funções

(Figura 55).

Figura 55 – Tela inicial do gerenciador Webmin. FONTE: Arquivo do autor.


A utilização do Webmin para tarefas de gerenciamento do servidor é bem simples.

Todo o acesso aos diversos serviços instalados na máquina é feito pelos módulos localizados

do lado esquerdo da tela do sistema.

Por exemplo, para utilizar o Sarg para gerar re latórios de acesso feitos a partir do log

do Proxy Squid, é necessário clicar em “Servers” e em “Squid Report Generator”. Em

seguida, no campo “Generate report for date range”, escolhemos “All records in log file” ou

“Those from”, especificando nos campos seguintes um período de dias a ser verificado. Por

fim, após clicar no botão “View Generated Report”, o Webmin apresenta uma lista de

relatórios do Sarg (Figura 56).

Figura 56 – Webmin listando relatórios do Sarg. FONTE: Arquivo do autor.


CONCLUSÃO

Com a implementação de um servidor com as funções de Firewall, Proxy e File

Server neste trabalho, foi possível exercer na prática as tarefas que muitos profissionais da

área de Redes de Computadores e Sistemas Operacionais, em especial Linux, desempenham

no dia-a-dia, prestando serviço em diversas organizações ou mesmo como profissiona is

autônomos no mercado. De fato, a utilização do Linux como sistema base para um servidor

dedicado para diversas funções é bastante vantajosa, levando em consideração suas

qualidades principalmente no que se refere à segurança, versatilidade, estabilidade e

desempenho. Talvez com a cada vez maior popularização da distribuição Ubuntu, os olhares

para sua versão Server também cresçam e façam o sistema mais popular também entre os

Administradores de Rede, tornando-se assim mais uma boa opção para a implementação

como sistema operacional Linux de servidores.


REFERÊNCIAS BIBLIOGRÁFICAS

BARRET, D. J.; SILVERMAN, R. E. SSH, the Secure Shell - The Definitive Guide. Sebastopol: O’Reilly & Associates, 2001.

CAMERON, J. Managing Linux Systems with Webmin. New Jersey: Pearson Education, Inc., 2004.

MAZIOLI DA SILVA, G. Guia Foca GNU/Linux Capítulo 10 - Firewall iptables.

Disponível em: <http://www.guiafoca.org/guia/avancado/ch-fw-iptables.html/>. Acesso em: 09 fev. 2009.

MAZIOLI DA SILVA, G. Guia Foca GNU/Linux Capítulo 18 - Samba. Disponível em: <http://www.guiafoca.org/guia/avancado/ch-s-samba.html/>. Acesso em: 27

mar. 2009. MAZIOLI DA SILVA, G. Guia Foca GNU/Linux Capítulo 15 – Servidor ssh.

Disponível em: <http://focalinux.cipsga.org.br/guia/avancado/ch-s-ssh.htm/>. Acesso em: 29 mar. 2009.

MORIMOTO, C. E. Redes – Guia Prático. Porto Alegre: Sul Editores, 2008.

MORIMOTO, C. E. Servidores Linux – Guia Prático. Porto Alegre: Sul Editores, 2008.

PAULA JÚNIOR, M. F. de. Ubuntu – Guia Prático para Iniciantes. Rio de Janeiro: Editora Ciência Moderna, 2007.

PEARSON, O. Squid Users Guide. Disponível em: <http://old.squid-cache.org/Doc/Users-Guide/detail/acl.html>. Acesso em: 23 mar. 2009.

RICHMOND, G. Webmin: substituindo o terminal na administração do sistema. Disponível em: <http://www.guiadohardware.net/tutoriais/webmin/>. Acesso em: 30 mar. 2009.

VON HAGEN, W. Ubuntu Linux Bible. Indianapolis: Wiley Publishing, Inc., 2007.


BIBLIOGRAFIA

ARUMUGAM, B. Ubuntu Server Guide. Disponível em: <https://help.ubuntu.com/6.10/ubuntu/serverguide/C/index.html/>. Acesso em: 02 fev. 2009.

CARMONA, T. Treinamento Prático em Linux . São Paulo: Digerati Books, 2005.

KUROSE, J. F.; ROSS, K. W. Redes de Computadores e a Internet – Uma abordagem top-down. São Paulo: Pearson / Addison-Wesley, 2007.

PERKINS, C.; STREBE, M. Firewalls. São Paulo: Makron Books, 2002.

Implementação de Servidor Linux Ubuntu Server

Education

Transcript of Implementação de Servidor Linux Ubuntu Server