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 Linu x Ubuntu Server: Firewall, Pro xy 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 Linu x Ubuntu Server: Firewall, Pro xy 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 Linu x Ubuntu Server: Firewall, Pro xy 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 Linu x Ubuntu Server: Firewall, Pro xy 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 Linu x Ubuntu Server: Firewall, Pro xy 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 Linu x Ubuntu Server: Firewall, Pro xy 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 Linu x Ubuntu Server: Firewall, Pro xy 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 Linu x Ubuntu Server: Firewall, Pro xy 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 environme nt 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 Linu x Ubuntu Server: Firewall, Pro xy 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.

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.


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

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.

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.

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

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.

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.

2. FIREWALL IP TABLES 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.

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.


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

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.

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 Regra que faz efetivamente o
$conexinternet –j MASQUERADE 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.

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 Condição que bloqueia o acesso a
REJECT conexão proveniente do programa MSN.
iptables -A INPUT -p tcp --dport 10000 -j Condição para pacotes de entrada
ACCEPT destinados à porta TCP 10000, usada


pelo software Webmin para acesso
remoto via web.
iptables -A INPUT -p udp --dport 137 -j ACCEPT Condições para pacotes de entrada
iptables -A INPUT -p udp --dport 138 -j ACCEPT destinados às portas UDP 137 e 138, e
iptables -A INPUT -p tcp --dport 139 -j ACCEPT TCP 139 e 445, usadas pelo servidor
iptables -A INPUT -p tcp --dport 445 -j ACCEPT 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.

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- Condição que ignora ping, dificultando
request –j DROP 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 Regras para ignorar pacotes inválidos.
DROP
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.

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 Endereços dos servidores DNS (neste caso,
208.67.222.222,208.67.220.220; 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;
Seção que possibilita relacionar um endereço
}
IP fixo ao endereço físico (MAC Address) da
host micro2 {
placa de rede de uma estação.
hardware ethernet
00:50:56:C0:00:01;
fixed-address 192.168.0.102;
}
} 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.


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.

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 ACLs para portas que podem ser
acl Safe_ports port 21 80 443 563 70 210 280 488 59 utilizadas pelo Proxy.
777 901 1025-65535
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.

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 Diretório de páginas de erro (em português)
/usr/share/squid/errors/Portuguese 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.

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.

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.

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.

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.

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.

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.

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/s quidguard/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.


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.

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.

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 Opções que fazem com que o Samba salva todos os arquivos
default case = lower em letras minúsculas, evitando possíveis problemas ao
localizar arquivos.
interfaces = eth1 Opções que orientam o Samba a utilizar somente a interface
bind interfaces only = yes 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.

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.

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.


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.

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.

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 As duas opções definem o padrão para criação e
directory mask = 0700 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].
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”.
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.

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 fo rma 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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.


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.

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

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.

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.


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.

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.


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.


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.


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

Mais conteúdo relacionado

Destaque

Semelhante a Implementação de Servidor Linux Ubuntu Server

Mais de Tiago Bezerra Dos Santos

Último

Implementação de Servidor Linux Ubuntu Server