Uma das principais características que tínhamos observado na versão anterior era a grande quantidade de conexões HTTPS com servidores externos, na ocasião verificamos que o UltraSurf realizava em média 10 conexões simultâneas na porta 443. Utilizamos essa sua peculiaridade para criar o script stopUltraSurf.sh, que, até à versão anterior do UltraSurf, funcionava perfeitamente bloqueando as conexões.

Agora tudo mudou. Na versão 9.6, o UltraSurf tenta inicialmente se conectar a um servidor pertencente à rede 65.49.2.0/24, caso consiga, o acesso será estabelecido e a estação acessará livremente a Internet. Aliás, verificamos que conectado dessa maneira o acesso será bem mais rápido se comparado às versões anteriores do UltraSurf. Como os IPs dessa rede não respondem ao DNS reverso, não têm como serem verificados pelo script stopUltraSurfe.sh, logo a conexão não será bloqueada pelo script.

Uma forma elegante de quebrar essa conexão seria bloqueando o acesso HTTPS a endereços IP que não respondessem ao DNS reverso, fizemos até uma versão do script com essa característica, mas a quantidade de falsos positivos foi bastante grande, pois, infelizmente, vários sites não seguem a recomendação do Comitê Gestor Internet Brasil (CGI.br) que diz: “Todas as redes conectadas à Internet brasileira devem operar com registros direto e reverso de DNS corretamente configurados.”, se assim fizessem, teríamos como diferenciar IPs idôneos de IPs supostamente maliciosos. O pior é que sites como o do Banco do Brasil, do Banco Real, do Banco Itaú, do Hotmail etc., que deveriam ser exemplos, não têm o DNS Reverso configurado para os IPs que respondem às conexões HTTPS. Uma pena.

Qual a solução então? Bloquear esses endereços no firewall, o problema é que, se os mantenedores do UltraSurf mudarem a sua range de IPs, o bloqueio falhará. Para efetivar o bloqueio na solução OpçãoLinux PDC, acesse as regras do firewall (opl > Firewall > Editar Regras de Firewall) e altere a linha:

HTTPS/ACCEPT     loc     net
para:

HTTPS/ACCEPT     loc     net:!65.49.2.0/24
Problema resolvido? Ainda não, caso não consiga acesso aos IPs da rede 65.49.2.0/24, o UltraSurf 9.6 tentará acessar os servidores remotos da mesma maneira que fazia nas versões anteriores, só que dessa vez não abrirá diversas conexões HTTPS, fará apenas uma única conexão. Para fazer com que o script stopUltraSurf.sh consiga detectar essa conexão, edite o arquivo /usr/local/bin/stopUltraSurf e altere a variável limitServersHttps=8 para limitServersHttps=1, ou baixe a nova versão do script stopUltraSurf.sh (veja como mais adiante).

Pronto, com o bloqueio da rede 65.49.2.0/24 no firewall e com esse ajuste na variável limitServersHttps, o script stopUltraSurf.sh deverá voltar a funcionar. Bem, pelo menos em nossos testes voltou…

Prefira utilizar a nova versão do script stopUltraSurf.sh, pois, além de estar mais rápido devido a otimizações feitas no código, será informado também qual nome do servidor que provocou o bloqueio da estação e a data e hora do bloqueio em opl > Firewall > Configurações Avançadas… > BlackList.

Caso esteja utilizando a versão mais recente da solução OpçãoLinux PDC, que já vem com o script stopUltraSurf.sh nativamente, atualize para a versão mais recente do script através dos comandos abaixo:

# wget http://www.opcaolinux.com.br/download/scripts/stopUltraSurf.sh.gz
# gunzip stopUltraSurf.sh.gz
# cat stopUltraSurf.sh > /usr/local/bin/stopUltraSurf
# rm stopUltraSurf.sh

Fonte: http://www.opcaolinux.com.br/gnulinux/tutoriais/27-seguranca/126-ultrasurf-96-como-bloquear.html

Traduzindo isso para o TCP/IP ficaria:

Suponha que

  rede 1 = 192.168.1.0 / 255.255.255.0
  rede 2 = 192.168.0.0 / 255.255.0.0
  rede 3 = 10.100.1.0 / 255.255.255.0
  rede 4 = 10.100.2.0 / 255.255.255.0
  rede 5 = 10.100.3.0 / 255.255.255.0
  ….
  ubuntu#> route add -net 192.168.0.0/16 gw 192.168.10.1
  ubuntu#> route add -net 10.100.0.0/16 gw 192.168.10.10

Com isso a tabela de roteamento da máquina que estamos configurando ficaria assim:

  ubuntu#> route
  Tabela de Roteamento IP do Kernel
  Destino         Roteador        MáscaraGen.    Opções Métrica Ref   Uso Iface
  192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
  192.168.0.0     192.168.10.1    255.255.0.0     UG    0      0        0 eth0
  10.100.0.0      192.168.10.10   255.255.0.0     UG    0      0        0 eth0
Note que a primeira linha foi adicionada automaticamente quando configuramos o endereço IP da própria máquina.

Uma maneira de melhorarmos isso é trabalhando com default gateway, ou seja, ao adicionarmos um gateway default, ele será adicionado na última linha da tabela de roteamento, de forma que todo IP com destino a uma rede que não se encaixa nas definições iniciais da tabela de roteamento serão mandadas para o default gateway (que por isso está na última linha).

Mas o escopo dessa dica é como transformar as rotas estáticas, que até aqui foram adicionadas manualmente, em configurações adicionadas automaticamente sempre que ligamos a máquina.

Já vi várias formas de adicionarmos estas rotas, desde comandos adicionados no script de inicialização do usuário, o /etc/init.d/rc.local até scripts executados ao iniciar o ambiente gráfico (arghhhh!!!), porém o mais adequado é utilizarmos os recursos que o sistema oferece para isso que são:

No Ubuntu (debian em geral): basta adicionarmos no arquivo /etc/network/interfaces as seguintes linhas:

  post-up route add -net 192.168.0.0/16 gw 192.168.10.1
  post-up route add -net 10.100.0.0/16 gw 192.168.10.10

Já em sistemas como o RedHat devemos criar o arquivo /etc/sysconfig/network-scripts/route-eth0 contendo:

  GATEWAY0=192.168.10.1
  NETMASK0=255.255.0.0
  ADDRESS0=192.168.0.0
 
  GATEWAY1=10.100.0.0
  NETMASK1=255.255.0.0
  ADDRESS1=192.168.10.10

Sendo assim toda vez que o serviço de rede subir estas rotas estáticas serão adicionadas automaticamente na tabela de roteamento de sua máquina.

Fonte: http://www.dicas-l.com.br/dicas-l/20061010.php

Instale o pacote “debmirror” disponível em testing ou unstable:

# apt-get install debmirror

Crie um usuário e um grupo que será dono do processo que iremos automatizar para o uso do debmirror:

# groupadd mirror
# useradd -g mirror -d /mirror -c “Debian Mirror” mirror

Crie os diretórios necessários para o repositório.

# mkdir -p /mirror/debian # mkdir /mirror/non-US # chown -R mirror:mirror /mirror

Criando os scripts para a sincronização

Iremos criar agora os script para a sincronização dos repositórios:

Repositório US:

# emacs /usr/local/bin/mirror1.sh

#!/bin/bash
su mirror -c “debmirror /mirror/debian –method=http –progress –nosource –host=ftp.br.debian.org –root=/debian –dist=woody,sarge,sid –section=main,contrib,non-free –arch=i386 –cleanup –getcontents”

Repositório non-US:

# emacs /usr/local/bin/mirror2.sh

#!/bin/bash
su mirror -c “debmirror /mirror/non-US –method=http –progress –nosource –host=ftp.br.debian.org –root=/debian-non-US –dist=woody/non-US,sarge/non-US,sid/non-US –section=main,contrib,non-free –arch=i386 –cleanup ?getcontents”

Você pode alterar a opção –method por ftp, http ou rsync -e. Leia o manual do debmirror para maiores detalhes.

# man debmirror

Permitindo a leitura escrita e execução somente para o usuário root:

# chmod 700 /usr/local/bin/mirror*.sh

Repositório local, http e ftp na sua LAN
Para uso local, em seu /etc/apt/sources.list coloque as linhas:

deb file:/mirror/debian sid main non-free contrib
deb file:/mirror/non-US sid/non-US main contrib non-free

Você pode alterar a versão conforme a sua necessidade trocando onde esta sid por woody ou sarge.

Vamos agora configurar para que você possa ter o repositório disponível para outras máquinas.

Configurando o Apache:

Edite o arquivo de configuração /etc/apache/httpd.conf:

# emacs /etc/apache/httpd.conf

Troque “<Directory /var/www>” por “<Directory /mirror>”.

Reinicie o Apache:

# /etc/init.d/apache restart

Edite o arquivo /etc/apt/sources.list nos clientes para configurar o repositório no protocolo HTTP:

# emacs /etc/apt/sources.list

deb http://(ip_ou_host_do_servidor)/debian/ sid main non-free contrib
deb http://(ip_ou_host_do_servidor)/non_US/ sid/non-US main contrib non-free

Configurando o proftpd:

Para ter o repositório disponível por ftp, edite o arquivo de configuração do proftpd:

# emacs /etc/proftpd.conf

Altere as TAGS da configuração compreendidas entre <Anonymous …> </Anonymous> por:

<Anonymous ~mirror>
User                     ftp
Group                    nogroup
UserAlias                anonymous ftp
RequireValidSh           off
# Limit the maximum number of anonymous logins
MaxClients               20
DisplayLogin             welcome.msg
DisplayFirstChdir        .message
# Limit WRITE everywhere in the anonymous chroot
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
</Anonymous>

Edite o arquivo /etc/apt/sources.list nos clientes para configurar o repositório no protocolo FTP:

deb ftp://(ip_ou_host_do_servidor)/debian/ sid main non-free contrib
deb ftp://(ip_ou_host_do_servidor)/non_US/ sid/non-US main contrib non-free

Automatizando o processo
Com o crontab podemos se aproveitar das horas de menor uso da rede para fazer a sincronização:

# crontab -e

insira a linha:

0 22 * * * /usr/local/mirror1.sh 2>&1 > /dev/null;/usr/local/mirror2.sh 2>&1 > /dev/null

Salve e feche.

# /etc/init.d/cron restart

No crontab configurei para que todos os dias a partir das 22:00hs o servidor atualize o repositório.

Primeiramente, você deve começar pela parte que chuta: examine o hardware do seu novo servidor, e dimensione-o para suas necessidades. Ou seja, não configure um P100 com 16MB de RAM para servir uma empresa com 200 funcionários, nem compre um P4 de última geração e 1GB RAM para servir aquele escritório com 6 funcionários.

Leve em conta também que serão instalados vários serviços adicionais (e opcionais) além do squid que tomarão conta dos recursos da máquina. Memória é essencial aqui. No meu caso, peguei um Sempron 2600+ com 512MB num PCChips A31g que tinha acabado de chegar. Isso, para distribuir internet para 50 computadores, dá e sobra, mas a idéia é justamente essa, ter uma boa folga no uso. Lembre-se também que serão necessárias duas placas de rede. Pessoalmente, não recomendo o uso da placa onboard, mas fica ao critério de vocês.

Agora, antes de começar a instalar o sistema, entre no SETUP e desabilite TUDO aquilo que não será usado: som onboard, usb, modem, portas seriais e paralelas, e o que mais for possível. Com isso, conseguimos um pouco mais de segurança (através de qualquer porta usb ou equivalente), confiabilidade (com menos recursos habilitados, menor será a chance de uma falha de hardware, e menor será o seu trabalho para identificar uma possível falha futura) e velocidade (menos coisas para levantar no boot, menos serviços rodando desnecessariamente). Configure o boot pelo CD, coloque uma senha para o setup e saia, para começarmos a instalação de verdade.

Passo 2 – Instalando o sistema

Nenhum segredo aqui, se você já fez isso antes: configure o idioma, o teclado, crie um usuário, defina uma senha, formate as partições necessárias (ou deixe o Ubuntu cuidar disso), e aguarde a instalação. Dois pontos importantes:

1 – Será útil já ter uma conexão com a internet durante a instalação (diretamente ligada à máquina ou através de um outro proxy), pois o Ubuntu já fará uns ‘apt-get update’ durante a instalação.
2 – Em dado momento, o instalador perguntará se você deseja instalar dois perfis pré-configurados: DNS Server e LAMP Server. A instalação fica a critério de vocês, já que boa parte dos pacotes desses perfis serão instalados mais pra frente. No meu caso, não instalei nada por enquanto.

Ao término, o sistema irá reiniciar o sistema.

Passo 3 – Configurações iniciais

Primeiramente, vamos configurar a rede. No meu caso, como eu já tenho um servidor DHCP em outro servidor, o Ubuntu já configurou automaticamente a primeira placa de rede. Mas o que queremos é um endereço estático, então vamos editar o arquivo /etc/network/interfaces

sudo vi /etc/network/interfaces

Seu arquivo deve estar qualquer coisa parecida com isso:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
#The primary network interface
auto eth0
iface eth0 inet dhcp

Altere as informações para algo parecido com:

auto lo eth0 eth1
iface lo inet loopback
#The primary network interface
iface eth0 inet static
address 192.168.1.254
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
#segunda interface. Outras podem ser adicionadas segundo a mesma lógica
iface eth1 inet static
address xxx.xxx.xxx.xxx
netmask xxx.xxx.xxx.xxx
network xxx.xxx.xxx.xxx
broadcast xxx.xxx.xxx.xxx
gateway xxx.xxx.xxx.xxx

Nesse caso, considerei que a primeira placa de rede ficará ligada à rede local, e a segunda é que ficará ligada à internet. Nesse caso, tudo dependerá de como é a sua conexão. Para Speedy Businnes, é bem fácil, a Telefônica já te passa todas as informações logo no começo. Outros serviços não devem ser diferente.

Altere também o /etc/resolv.conf , inserindo os endereços DNS que o provedor utiliza:
sudo vi /etc/resolv.conf

nameserver xxx.xxx.xxx.xxx
nameserver xxx.xxx.xxx.xxx
nameserver xxx.xxx.xxx.xxx

Novamente, os dados deverão ser obtidos com seu provedor. A partir daqui, o computador já deverá estar conectado à internet. Tente um ping www.ubuntu.org e veja se está tudo OK. Mas ainda não está pronto, precisamos instalar e configurar os pacotes necessários para que o proxy funcione e os outros usuários também acessem a internet.

É agora que a parte legal começa. Você com certeza já deve ter percebido isso, mas o CD do Ubuntu Server já traz vários pacotes de serviços prontos para o uso. Se você quiser, pode usar esse repositório, o que diminuiria e muito o tempo de download pelo APT-GET. No meu caso, como eu queria me livrar do drive de CD, copiei os pacotes para minha máquina, com os comandos abaixo:

sudo mount /media/cdrom/
sudo cp -r /media/cdrom/dists /edgy
sudo cp -r /media/cdrom/pool /edgy
Logo depois, editem o arquivo de repositórios do apt, com um sudo vi /etc/sources.list

Comentem a linha

deb cdrom:(…)

Colocando um # na frente. Adicionem as linhas:

deb file:/edgy edgy main
deb file:/edgy edgy restricted

Aproveitem e descomentem as linhas dos repositórios ‘Universe‘, retirando o # da frente delas. Salvem, e executem o apt:

sudo apt-get update
sudo apt-get upgrade

Se tudo der certo, vocês terão o sistema pronto para a instalação dos pacotes. Percebam que esse passo é totalmente opcional. No meu caso, eu pude liberar o CD do Ubuntu (assim como o drive) e acelerar bastante as instalações. Se você quiser continuar com o CD, ou se todas as versões do mesmo já estiverem obsoletas, pule essa parte, apenas configurando para aceitar o repositório Universe.

Passo 4 – Instalando e Configurando o ‘Pacote básico do Administrador Feliz‘

Agora, vamos tratar de instalar e configurar alguns programas que irão nos ajudar a administrar o sistema: a trinca MC (Midnight Commander), OpenSSH e Webmin. Muitos experts que estejam lendo isso provavelmente irão querer me bater, mas considero o MC um ótimo navegador de arquivos/editor de textos, ainda mais quando estou com pressa. Se você prefere o VI, simplesmente não instale o MC.

sudo apt-get install mc openssh-server libmd5-perl libnet-ssleay-perl libauthen-pam-perl libio-pty-perl
sudo wget http://prdownloads.sourceforge.net/webadmin/webmin_1.320_all.deb
sudo dpkg -i webmin_1.320_all.deb
Com isso, já podemos acessar o servidor via SSH e via Browser. Mas… já que queremos um mínimo de segurança, porque não alterarmos algumas coisinhas?

sudo mcedit /etc/ssh/sshd_config

Altere as seguintes opções:

Port 2756 #Altera a porta padrão do SSH, diminuindo a possibilidade de um port scan
ListenAddress 192.168.1.254 # Somente poderá ser acessado por esse endereço de rede
PermitRootLogin no # Precisa explicar?
AllowUsers <seu usuário padrão no Ubuntu> #somente o usuário criado na instalação poderá se logar.

Assim já temos algo mais seguro. O mesmo pode ser feito com o Webmin, alterando o /etc/webmin/miniserv.conf. Nesse caso, alterar a opção “port” para 4044 ou qualquer outro número já é uma boa.

Agora, já podemos mexer no servidor pela rede, e sem muito medo de uma invasão. Que tal pararmos de enrolar e instalar logo o bendito do proxy, hein?

Passo 5 – Instalando o Squid, o Sarg e o Dansguardian

Apenas para entender: o Squid será o responsável por compartilhar o acesso à internet com todas as máquinas, o Dansguardian irá habilitar alguns filtros de acesso, e o Sarg será o ‘dedo-duro’ do sistema, gerando arquivos HTML com os ‘logs’ de navegação do Squid.

E aqui começa uma parte da configuração onde ‘cada caso é um caso’. O Squid permite um sem fim de combinações de restrições, permitindo que eu simplesmente compartilhe a internet, ou que eu compartilhe apenas para alguns IPs, ou que eu exija uma autenticação para o uso, ou que eu bloqueie algumas páginas de acordo com o horário.

A configuração das ACLs (regras que controlam o acesso) dependerá exclusivamente de como a empresa vê o acesso à internet pelos funcionários, e do quão odiado você quer ser pelos seus colegas de trabalho que não podem mais acessar o orkut.

Se a empresa para o qual você está instalando o proxy não se importa com restrições de acesso, a configuração padrão do squid já está perfeita. Caso contrário, sugiro que você leia a documentação do mesmo e encontre quais regras se adaptam melhor à sua situação. O exemplo aqui é bem restrito, mas já montei um servidor para um escritório de contabilidade onde TUDO era bloqueado, menos uma meia dúzia de páginas….

Vamos às configurações: Comece instalando os pacotes:

sudo apt-get install squid squid-common bind sarg dansguardian

E depois dê um

sudo mcedit /etc/squid/squid.conf

Comece alterando as primeiras linhas, antes das ACL’s:
#Inicio
http_port 192.168.1.254:3129 transparent
visible_hostname proxyspeedy2
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
cache_mem 48 MB
#Opções para otimização do sistema
maximum_object_size 1024 MB
minimum_object_size 0 KB
cache_swap_low 50
cache_swap_high 90
cache_access_log /var/log/squid/access.log

Vamos às explicações, pra quem não conhece o squid:

http_port – qual porta o squid estará escutando. Ao colocar o endereço IP, eu impeço que alguém tente acessar pelas outras interfaces. O ‘transparent’ será explicado em breve.
visible_hostname – Hostname do servidor
cache_mem – Quantidade de memória RAM que o squid estará utilizando para guardar as páginas acessadas, aumentando a velocidade de acesso posterior.
maximum_object_size e minimum_object_size – Qual o tamanho máximo e mínimo dos arquivos que ficarão armazenados no cache em disco.
cache_swap_low e cache_swap_high – Com o cache_swap_high você define qual a porcentagem máxima que o cache deverá atingir para começar a apagar arquivos antigos. O cache_swap_low define qual a porcentagem deverá ser atingida durante a remoção desses arquivos.

Caso você queira que os usuários se autentiquem para usar a internet, insira esses dados no squid.conf:

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm

Agora, as ACL’s. Novamente, cada caso é um caso, e vou colocar as minhas aqui apenas para exemplo. Se você quiser entender mais sobre ACL’s do Squid e como usá-las, recomendo uma leitura desse texto .

# ACLs normais
acl all src 192.168.1.0/255.255.255.0
delay_pools 1
delay_class 1 2
delay_parameters 1 114688/114688 32768/32768
delay_access 1 allow all
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl SSL_ports port 873
acl Safe_ports port 80
acl Safe_ports port 21
acl Safe_ports port 443 563
acl Safe_ports port 70
acl Safe_ports port 210
acl Safe_ports port 1025-65535
acl Safe_ports port 280
acl Safe_ports port 488
acl Safe_ports port 591
acl Safe_ports port 777
acl Safe_ports port 631
acl Safe_ports port 873
acl Safe_ports port 901
acl purge method PURGE
acl CONNECT method CONNECT
no_cache deny QUERY
# ACLs paulo
acl Diretoria proxy_auth “/etc/squid/users/diretoria.acl”
acl administracao proxy_auth “/etc/squid/users/administracao.acl”
acl producao proxy_auth “/etc/squid/users/producao.acl”
acl castigo proxy_auth “/etc/squid/users/castigo.acl”
acl PornoURLs url_regex “/etc/squid/users/porno.acl”
acl ProducaoURLs url_regex “/etc/squid/users/producaoURLs.acl”
acl AdministracaoURLs url_regex “/etc/squid/users/administracaoURLs.acl”
acl almoco time MTWHF 12:00-14:00
acl executaveis url_regex -i “/etc/squid/users/executaveis.acl”
acl castigo_ip src “/etc/squid/users/castigo_ip.acl”
#Aplicação das ACL’s
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow purge localhost
http_access deny purge
http_access allow localhost
http_access deny administracao PornoURLs
http_access deny producao PornoURLs
http_access deny castigo PornoURLs
http_access deny Diretoria PornoURLs
http_access deny administracao AdministracaoURLs !almoco
http_access deny producao ProducaoURLs !almoco
http_access deny castigo AdministracaoURLs
http_access deny administracao executaveis
http_access deny producao executaveis
http_access allow Diretoria
http_access allow producao
http_access allow administracao
http_access allow castigo
http_access deny all
http_reply_access allow all

Basicamente, existem três níveis de acesso diferentes, com várias restrições baseado em cada nível, mas com a possibilidade de liberar alguns sites no horário de almoço, a menos que você esteja na ACL ‘castigo’ (sacou? hein?). Pode parecer castrante, mas são normas da empresa, não me odeiem por configurar isso.

Salve o arquivo e saia. Agora que já temos o básico configurado, vamos configurar o firewall para compartilhar conexões. No terminal, digite os comandos abaixo:

sudo modprobe iptable_nat
sudo modprobe ip_nat_ftp
sudo echo 1 > /proc/sys/net/ipv4/ip_forward
sudo iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j REDIRECT –to-port 3128

Na verdade, apenas os quatro primeiros comandos são necessários. Nesse caso, substitua o ‘eth1′ pela interface que está conectada à internet. O último comando gera o que chamamos de ‘proxy transparente’. Com ela habilitada, qualquer um que queira acessar a internet deverá obrigatoriamente passar pelo Squid (vocês lembram daquele ‘transparent’ logo na primeira linha do squid.conf, né?).

Uma ótima idéia é inserir esses comandos de firewall no arquivo /etc/init.d/boomisc.sh. Assim, caso o computador seja reiniciado, as regras passarão a funcionar automaticamente….

Aqui, já podemos testar o Squid. Primeiro, dê o comando:

sudo /etc/init.d/squid restart

E verifique se não apareceu nenhum erro. Uma lida nos arquivos em /var/log pode ser útil, caso apareça algo estranho. Agora, numa máquina qualquer, abre o seu browser e configure o proxy. No Firefox2, vá em Ferramentas > Opções > Avançado > Rede > Configurações e insira o endereço IP do servidor e a porta do squid. Tente acessar alguma página. Se der tudo certo, parabéns. O grosso do trabalho já foi, agora é cuidar da segurança.

Nota: Percebam que até o momento não é possível usar o Squid com transparência E autenticação ao mesmo tempo. Ao usar os dois você no máximo não terá acesso se não configurar o proxy nas máquinas locais. O que já ajuda em alguma coisas….

Nota2: Para criar um usuário no Squid, você pode usar o comando

sudo htpasswd /etc/squid/passwd <usuário>

E depois cadastrá-lo em uma das regras do squid. OU você pode usar o Webmin, o que eu considero um pouco mais prático…

O Sarg não exige muita configuração, podendo ser executado via Webmin mesmo, ou através do crontab, caso você queira automatizar a tarefa. Uma lida no /etc/squid/sarg.conf pode dar boas dicas do tipo de configuração que o Sarg permite. Para acessar os relatórios, acesse http://192.168.1.254/squid-reports/ que eles deverão estar lá.

Agora, vamos ao Danguardian. Antes, uma observação importante: o DanGuardian é um super-filtro de conteúdo, conseguindo barrar vários tipos de conteúdos diferentes, sejam sites, frase, ou até mesmo tipos de arquivos. A configuração padrão é bem restrita, e você pode penar um pouco até ter uma configuração que lhe permita acessar tudo o que você precisa, e bloqueie o resto. Sempre que possível, utilize os arquivos de exceção para liberar apenas o necessário (exemplo, incluir o endereço da Caixa Econômica Federal como exceção, ao invés de liberar o acesso a arquivos .zip).

Outro ponto é que você pode precisar configurar bastante o DG no quesito performance. Ele utiliza o Clamav para fazer uma varredura antí-virus no que passa pelo proxy, o que pode ser bem ruim se você está usando um Pentium 100 como proxy para 100 máquinas… O Dansguardian é recomendado para ambientes corporativos preocupados com a segurança, e PRINCIPALMENTE em escolas ou universidades.

Comece com um:

sudo mcedit /etc/dansguardian/dansguardian.conf

Para uma configuração simples, comente a linha ‘UNCONFIGURED’ e altere as linhas:

language = ‘portuguese’
loglocation = ‘/var/log/dansguardian/access.log’
filterport = 3128
proxyip = 127.0.0.1
proxyport = 3129

Nota: muitos devem estar achando estranho eu ter configurado o Dansguardian na porta padrão do Squid. O motivo é simples: preguiça. Assim eu não preciso reconfigurar todos os outros computadores… 

No ‘/etc/dansguardian/dansguardianf1.conf‘ verifique a opção ‘naughtynesslimit. Ele é o ‘medidor de putaria’ do Dansguardian. Quanto menor esse valor, maior será a possibilidade da página ser bloqueada. Para adultos, um bom valor é 200. Para crianças, pense em valores por volta de 40…

Agora, precisamos baixar as definições em português. Execute os comandos:

sudo wget http://dansguardian.org/downloads/grosvenor/languages.tar.gz
sudo tar -zxvf languages.tar.gz
sudo cp -r languages/* /etc/dansguardian/languages/portuguese/

Agora, insira no arquivo ‘/etc/dansguardian/weightedphraselist’ as linhas:

.Include</etc/dansguardian/languages/portuguese/weightedphraselist.pornsites.portuguese>
.Include</etc/dansguardian/languages/portuguese/weightedphraselist.pornwords.portuguese>

E, no ‘/etc/dansguardian/bannedphraselist’

.Include</etc/dansguardian/languages/portuguese/bannedphraselist.portuguese>

Salve tudo, e reinicie o Dans:

sudo /etc/init.d/dansguardian restart

Se tudo correu bem, você provavelmente é o cara mais odiado pelos funcionários que enrolam no serviço…..

Há um extra para acelerar um pouco a navegação, que é instalar um servidor DNS na máquina. Com isso, as resoluções de nome ficarão mais rápidas, pois haverá um cache de endereços na sua máquina. Até onde eu sei, não é necessário alterar algum arquivo, apenas instalar o bind

Passo 6 – Incrementando o Firewall e instalando o Snort e o Guardian

A parfir daqui, tudo o que será feito é instalar sistemas que bloqueiem ataques externos, ou evitem problemas que um vírus possa causar internamente. As regras de Firewall servem para fechar portas e evitar ataques. O Snort é uma ferramenta de detecção de intrusos, ótima para ficar vigiando a sua rede e verificando se há algo errado. O Guardian trabalha junto com o Snort, criando regras de firewall de acordo com os alertas do Snort.

Para o firewall, vamos utilizar o kurumin-firewall mesmo (disponível no GuiadoHardware), mas com algumas modificações. Novamente, as portas que você irá abrir ou fechar dependerão exclusivamente das necessidades da empresa ou local onde você instalando o servidor.

sudo mcedit /etc/init.d/kurumin-firewall

E edite o arquivo:

#!/bin/bash

# Script de configuração do iptables gerado pelo configurador do Kurumin
# Este script pode ser usado em outras distribuições Linux que utilizam o Kernel 2.4 em diante
# Por Carlos E. Morimoto

firewall_start(){

# Abre para uma faixa de endereços da rede local
iptables -A INPUT -p tcp –syn -s 192.168.1.0/255.255.255.0 -j ACCEPT

# Abre uma porta (inclusive para a Internet)
iptables -A INPUT -p tcp –destination-port 21 -j ACCEPT
iptables -A INPUT -p tcp –destination-port 110 -j ACCEPT
iptables -A INPUT -p tcp –destination-port 2535 -j DROP
iptables -A INPUT -p tcp –destination-port 139 -j DROP
iptables -A OUTPUT -p tcp –destination-port 139 -j DROP

# Fechando as portas do SSH pra fora
iptables -A INPUT -p tcp –dport 2756 -m iprange –src-range 192.168.1.0-192.168.1.255 -j ACCEPT
iptables -A INPUT -p tcp –dport 2756 -j DENY
# Ignora pings
echo “1″ > /proc/sys/net/ipv4/icmp_echo_ignore_all

# Protege contra synflood
echo “1″ > /proc/sys/net/ipv4/tcp_syncookies

# Desabilita o suporte a source routed packets
# Esta recurso funciona como um NAT ao contrário, que em certas circunstancias pode permitir que alguem de fora envie pacotes para micros dentro da rede local.
echo “0″ > /proc/sys/net/ipv4/conf/eth0/accept_source_route
echo “0″ > /proc/sys/net/ipv4/conf/eth1/accept_source_route
# Proteção contra ICMP Broadcasting
echo “1″ > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# Proteções diversas contra portscanners, ping of death, ataques DoS, etc.
iptables -A FORWARD -p icmp –icmp-type echo-request -m limit –limit 1/s -j ACCEPT
iptables -A FORWARD -p tcp -m limit –limit 1/s -j ACCEPT
iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp –tcp-flags SYN,ACK,FIN,RST RST -m limit –limit 1/s -j ACCEPT
iptables -A FORWARD –protocol tcp –tcp-flags ALL SYN,ACK -j DROP
iptables -A FORWARD -m unclean -j DROP
iptables -A INPUT -m state –state INVALID -j DROP
iptables -N VALID_CHECK
iptables -A VALID_CHECK -p tcp –tcp-flags ALL FIN,URG,PSH -j DROP
iptables -A VALID_CHECK -p tcp –tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
iptables -A VALID_CHECK -p tcp –tcp-flags ALL ALL -j DROP
iptables -A VALID_CHECK -p tcp –tcp-flags ALL FIN -j DROP
iptables -A VALID_CHECK -p tcp –tcp-flags SYN,RST SYN,RST -j DROP
iptables -A VALID_CHECK -p tcp –tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A VALID_CHECK -p tcp –tcp-flags ALL NONE -j DROP

# Abre para a interface de loopback.
# Esta regra é essencial para o KDE e outros programas gráficos funcionarem adequadamente.
iptables -A INPUT -p tcp –syn -s 127.0.0.1/255.0.0.0 -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

# Esta regra é o coração do firewall do Kurumin,
# ela bloqueia qualquer conexão que não tenha sido permitida acima, justamente por isso ela é a última da cadeia.
iptables -A INPUT -p tcp –syn -j DROP

}
firewall_stop(){
iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
}
case “$1″ in
“start”)
firewall_start
;;
“stop”)
firewall_stop
echo “O kurumin-firewall está sendo desativado”
sleep 2
echo “ok.”
;;
“restart”)
echo “O kurumin-firewall está sendo desativado”
sleep 1
echo “ok.”
firewall_stop; firewall_start
;;
*)
iptables -L -n
esac

Salve, e configure para rodar no boot. Você pode testar as configurações do iptables dando um

sudo iptables -L

e verificando se ele lista todas as regras criadas.

Para o Snort e o Guardian, o procedimento é exatamente o encontrado na página do Ubuntu Brasil portanto eu não pretendo me repetir. Como dica adicional, insiram as linhas abaixo no bootmisc.sh, para que os serviços sempre rodem ao reinicar o servidor:

snort -c /etc/snort/snort.conf &
guardian.pl /etc/guandian.conf

Faça alguns testes finais, reinicie a máquina, e pronto. Você terá um servidor proxy leve, seguro, e que permite adicionar novos serviços (DHCP, SAMBA, Cups, LDAP, Postfix) facilmente. E tudo em menos de duas horas!

Nota final:
- Caso algum passo descrito aqui não funcione, sempre veja as mensagens de erro e os arquivos de log. Boa parte das soluções podem ser encontradas vendo qual é exatamente o problema.

      A segurança da informação é, sem dúvida, um dos assuntos mais importantes dentre as pautas de reunião de tecnologia em qualquer entidade.

      Autenticidade, confidencialidade em manter as informações a salvo de acesso e divulgação não autorizadas, confiabilidade, compartilhamento de dados, disponibilidade e integridade da informação estão diretamente ligados à segurança. Segurança da informação são mecanismos que promovem a integridade de uma estrutura de rede que se aplicam nos conceitos mais simples, que vão desde políticas de troca periódica de senhas até a trituração de documentos impressos.

      Mobilidade e facilidade já fazem parte do nosso dia-a-dia, comprar e configurar um roteador Wi-Fi tornou-se trivial, já com as mais diversas distribuições de Linux, instalar e configurar um servidor como proxy acaba sendo tarefa de 15 minutos. É exatamente neste tipo de facilidade que pessoas mal intencionadas aplicam as mais diversas formas comumente utilizadas para explorar estas “vulnerabilidades”, com o simples uso de ferramentas desenvolvidas especialmente para esta finalidade, a invasão.

     Ataques direcionados às redes além de comprometer os recursos e a disponibilidade comprometem o principal: as informações. Como os ataques podem ser originados de qualquer posição dentro ou fora da área da rede em questão, acaba dificultando a tarefa de localização precisa da origem do ataque e do atacante. O intruso que consiga entrar em uma rede ficará com um acesso privilegiado para lançar ataques aos elementos constituintes dessa rede havendo risco acrescido para ocorrência das situações exemplificadas a seguir:

• Furto ou violação da informação e dos serviços da rede;
• Abuso da conexão com à Internet;
• Utilização dessa conexão “ponte” para prática de atos ilícitos, o que, em caso de posterior investigação policial, envolverá o utilizador titular do link invadido;
• Vandalismo – destruição de dados, interferência ao normal funcionamento da rede, etc.

A contra medida simples configurada em separado ou em conjunto não devem ser consideradas medidas de segurança suficientes para impedir um indivíduo motivado a entrar na rede.

2 Mecanismos de segurança

Contamos com os mecanismos de segurança físicos e lógicos:

• os métodos físicos são barreiras que limitam o contato ou acesso à informação ou a infra-estrutura de dados que contém as informações, podem ser exemplificados como: portas, trancas, acesso por identificação biométrica, blindagem, entre outros.
• os métodos lógicos destacam-se por controles eletrônicos que impedem ou limitam o acesso à informação.

Adicionalmente, agregamos aos mecanismos lógicos:

- Criptografia: É a forma de cifrar dados, utilizando algoritmos altamente complexos, ou não, para tornar a informação ininteligível à terceiros. A decriptografia é utilizada pela parte autorizada a receber esta informação e devidamente com o algoritmo de decriptação é realizado o processo inverso.

- Assinatura digital: Código utilizado para verificar a integridade de um documento, porém, não garante sua confidencialidade.

- Garantia da integridade da informação: Conseguimos facilmente utilizando funções de “Hashing”, seria como tirar uma “foto” do documento antes de enviar, e então para o receptor verificar sua integridade ele tiraria outra “foto” do documento e realizava a comparação.

- Controle de acesso: destacam-se por senhas, sistemas biométricos, controle de acesso explícito, como por exemplo, um firewall…
3 Conceitos de Firewall

     Firewall, não é nada mais do que um porteiro ou um segurança com sua árdua função de verificar quem pode entrar e sair, além de manter a consonância das coisas, atualmente, já se tornou imprescindível sua utilização.
     Existem firewalls comerciais, muitos; também existe um método de construção onde podemos definir as próprias regras, onde você define o que quer controlar; praticidade? Nem tanto para uma corporação com mais de 5 mil regras. De qualquer forma, com um pouco de organização, conseguimos trabalhar, e muito bem, com o iptables.
     No Linux, o iptables é embutido no kernel, o que o torna, sem dúvida, superior em relação aos seus concorrentes. Obviamente nenhum firewall irá corrigir os erros de sua rede, mas ele poderá limitar o uso destes serviços à certos computadores. Não faz sentido disponibilizar um serviço de FTP a toda a internet sendo que apenas a filial necessita deste acesso, muito menos manter um serviço web ativo no seu servidor, se nem ao menos você necessita dele lá. Então, como definir políticas de acesso aos serviços em que eu realmente necessito mante-los?

Iptables
Para entendermos o iptables, veremos como ele trabalha para então conhecermos o quê ele pode nos proporcionar. Teremos agora, um método bem didático de explicação. Preparado??

O iptables está organizado por 3 tabelas, a saber:

Filter: Onde é controlado o de filtro de pacotes, basicamente, quem entra e quem sai da sua rede. É composta por três funções:

• INPUT: Controla o que entra no servidor.
• FORWARD: Controla o que entra no servidor mas deve ser redirecionado a uma outra máquina.
• OUTPUT: Controla o que sai do servidor.

NAT: Ela trabalha com funções de NAT (Network Address Translation), seria uma troca do endereço de rede. As funções dela são:
• PREROUTING: Utilizada quando necessitamos tomar ações ANTES do datagrama ser roteado.
• POSTROUTING: Utilizada quando necessitamos tomar ações APÓS o roteamento do datagrama.
• OUTPUT: Utilizada quando necessitamos realizar alterações nos datagramas após eles serem roteados.

Mangle: Trabalha com alterações especiais nos pacotes, por exemplo alterar a prioridade de um datagrama IP, ou marcar um determinado datagrama para que ele seja trabalhado por um roteamento especial, como sair por outro gateway. As funções dela são:
• PREROUTING: Utilizada quando necessitamos modificar os datagramas dando um tratamento especial antes que eles sejam roteados.
• OUTPUT: Modifica especialmente os datagramas gerados pelo servidor antes que eles sejam roteados.
Veja um exemplo didático:

 
Agora que já sabemos tudo sobre as situações das tabelas, vamos conhecer alguns comandos:

Comandos do iptables

iptables: o binário
iptables-save: binário que salva as regras em memória.
ip6tables: iptables para IPv6.
iptables-restore: binário responsável carregar em memória as regras que foram salvas pelo ‘iptables-save’.

Forma de utilização:
# iptables –t nat
diz ao iptables que será usado a tabela nat

# iptables –t filter
diz ao iptables que será usado a tabela filter

# iptables –t mangle
diz ao iptables que será usado a tabela mangle
iptables -<comando> [cadeia]
Ex: iptables -A INPUT

 
Controles a serem tomados:

 
DICA: Tanto para –sport quanto para –dport podemos utilizar range de portas:
Ex: –dport 6881:6889
Ou multiportas:
Ex: -m multiport –dport 5190,4000,53

Ações a serem tomadas quando alguma regra combina ou casa (para os íntimos)

      Nossa! Quanta coisa hein? Se você conseguiu chegar até aqui, é sinal de que apenas passou os olhos pelas tabelas, não!? Tome notas, leia, imprima, releia e tenha as tabelas no bolso, se entendê-las dominará o iptables facilmente!
Agora chega de “bla bla bla” e vamos as reais situações.

A maioria das situações abaixo foram retiradas da lista linux-board do YahooGroups, a qual sempre presto uma ajuda nas horas vagas.

Vamos tomar como exemplo a situação de rede, a quase padrão na maioria dos casos:

Rede: eth0 interna
Rede: eth1 externa

Trabalhando com NAT em sua rede

Mascarar conexão

Devemos habilitar, antes, o nat em seu kernel:

echo 1 > /proc/sys/net/ipv4/ip_forward

E então:

iptables -t nat -A POSTROUTING -s 192.168.0.0/255.255.255.0 -j MASQUERADE
Iptables, adicione na tabela nat (-t nat), após ser roteado (-A POSTROUTING):
• O que for de origem da minha rede (-s 192.168.0.0/24)
Qual o alvo, o que fazer?
• -j MASQUERADE (mascarar a conexão)
SNAT: modificação do endereço de origem das máquinas para um único IP ou faixa de IP’s.
Qualquer regra que utilize SNAT deve ser aplicada a chain POSTROUTING.

DNAT: modificação do endereço de destino das máquinas para um único IP ou fixa de IP’s.
Qualquer regra que utilize DNAT deve ser aplicada a chain PREROUTING.
E então, fácil? Calma, veremos muitos exemplos, até você decorá-los. Vejamos uma regra:

iptables –t nat –A POSTROUTING –s 192.168.0.1 –o eth0 –j SNAT -–to 192.168.2.12
Iptables, adicione na tabela POSTROUTING (-t nat –A POSTROUTING):
• o que vier com origem do host (-s 192.168.0.1)
• e especificamente o que sai pela rede eth0 (-o eth0)
• deverá ter seu endereço alterado (-j SNAT) para 192.168.2.12

Tá ficando bom, vejamos uma com DNAT:

Redirecionar conexões que entrem na porta 7155 para a porta 3389 (Terminal Service) de uma máquina interna de sua rede.

iptables -t nat -A PREROUTING -p tcp -m tcp –dport 7152 -j DNAT –to 192.168.0.126:3389
iptables como vai? Adicione na tabela PREROUTING (-t nat –A PREROUTING):
• O que for TCP e que vier com destino à porta 7152 (–dport 7152)
terá seu destino de rede alterado para 192.168.0.126 (-j DNAT –-to 192.168.0.126:3389)
Quando não especificamos uma origem ou um destino (-s <IP>, -d <IP>) o iptables segue o padrão que é ANY, ou seja, qualquer (0/0). É redundante colocarmos algo como –s 0/0 ou –d 0/0. Note que na regra acima, deixamos explícito a porta destino do pacote, já que ele viria pela 7152 e além de alterarmos o IP de destino, alteramos também a porta para 3389.
Redirecionar conexões da porta 80 para 3128

iptables -t nat -A PREROUTING -s 192.168.0.0/24 -p tcp -i eth0 –dport 80 -j REDIRECT –to-port 3128
iptables, adicione na tabela nat (-t nat), antes de ser roteado (-A PREROUTING) :
• O que for de origem (-s, de source) 192.168.0.0./24
• E que seja do protocolo tcp (-p tcp)
• E que entre pela interface eth0 (-i de input, eth0)
• Com destino a porta 80 (–dport 80)
Qual o alvo, o que fazer? :
• Redirecionar para a porta 3128 (-j REDIRECT –to-port 3128)

 
Trabalhando com filtros de pacote

      Há pessoas que trabalham, de cara, bloqueando tudo e liberando apenas o necessário. Há outras que trabalham liberando tudo o que necessita e bloqueia o resto, veja, é diferente…

Note que quando se lista uma tabela do iptables (iptables –t filter –L), você vê que a política padrão é ACCEPT:

# iptables -t filter -L
Chain INPUT (policy ACCEPT)

Então, vamos montar a política de que, por padrão o pacote é bloqueado.

iptables –P INPUT DROP
iptables –P OUTPUT DROP
iptables –P FORWARD DROP

Bloquear tudo com destino ao site www.pornografia.com

iptables –A FORWARD –s 192.168.0.0/24 –d www.pornografia.com –j DROP

iptables, adicione na tabela de encaminhamento de pacotes (iptables –A FORWARD):
• Tudo o que for de origem (-s, de source, origem ) 192.168.0.0/24
• e com destino a (-d, de destination, destino) www.pornografia.com
• seja bloqueado (-j alvo, “o que fazer?”) DROP (bloquear, negar)
Liberar tudo o que vier do site www.empresa.com.br

iptables –A FORWARD –s www.empresa.com.br –d 192.168.0.0/24 –j ACCEPT
iptables, adicione na tabela de encaminhamento (iptables –A FORWARD):
• O que vier da origem (-s www.empresa.com.br)
• Com destino a minha rede interna (-d 192.168.0.0/24)
• Será liberado (-j ACCEPT)
Bloquear totalmente aquele cara que esta consumindo sua banda:

iptables –A FORWARD –s 192.168.0.15 –d 192.168.0.1 –j DROP
Adicionar na tabela de encaminhamento (-A FORWARD):
• o que for de origem (-s) do IP 192.168.0.15 e com destino ao gateway de internet (-d) 192.168.0.1 será bloqueado (-j DROP).
Já deu um susto? Então você pode excluir a regra:

iptabes –D FORWARD –s 192.168.0.15 –d 192.168.0.1 –j DROP

Há uma forma de excluir a regra pelo seu número, para listar as regras e sua ordem fazemos:

# iptables -t filter -nL –line-numbers
26 DROP 0 — 192.168.0.15 192.168.0.1

E então, excluímos:

# iptables -D FORWARD 26

Tratamentos especiais em pacotes, TOS

      “O tipo de serviço é um campo existente no cabeçalho de pacotes do protocolo ipv4 que tem a função especificar qual é a prioridade daquele pacote. A prioridade é definida usando o algoritmo FIFO do próprio kernel, sendo uma das alternativas de controle/priorização de tráfego das mais simples e rápidas.
Uma das vantagens da utilização do tipo de serviço é dar prioridade ao tráfego de pacotes interativos (como os do ICQ, IRC, servidores de chat), etc. Com o TOS especificado, mesmo que esteja fazendo um download consumindo toda a banda de sua interface de rede, o tráfego com prioridade interativa será enviado antes, aumentando a eficiência do uso de serviços em sua máquina.” – Guia Foca Linux.
Antes de começar, algumas definições:

Prioridade máxima para conexões SSH:

iptables –t mangle –A PREROUTING –i eth1 –p tcp –-sport 22 –j TOS –-set-tos 16
iptables, adicione na tabela mangle (-t mangle) antes de ser roteado (-A PREROUTING):
• o que entrar pela interface eth1 (-i eth1) que for tcp (-p tcp)
• com origem da porta 22 (–sport 22) dar o máximo de processamento (-j TOS –-set-tos 16)

Você deve ter notado, na regra de DNAT láaa em cima, há uma coisinha estranha (-p tcp -m tcp) –m tcp… o que seria isto? Módulos!

Módulos

Os módulos ampliam o poder do iptables, é uma forma de explandir ainda mais suas regras, afinal, já somos expert em iptables!

Veja alguns módulos:

 
A opção limit limita a quantidade de vezes que a regra deve ser executada em um intervalo de tempo, estremamente útil para trabalhar com tentativas de ataques. Ataque DoS (Denial of Service), entende?

iptables –A INPUT –p icmp –icmp-type echo-request –m limit –limit 1/s –j ACCEPT
Definimos que aceitaremos pacotes de icmp (-p icmp) tipo do ping (–icmp-type echo-request) se eles forem recebidos apenas no limite de um segundo (-m limit –limit 1/s). Podemos ter s, m, h, d (segundo, minuto, hora e dia).

Certo, se eu desejar bloquear estes tipos de requisições, afinal, ninguém precisa saber se estamos vivos ou não, a regra seria … ?

iptables –A INPUT –p icmp –j DROP

Bloquear tudo o que entrar e que seja do tipo icmp. Esta ficou fácil, não?

Mas… Como ele controla isto, a quantidade de vezes… é memória, banco de dados?

Não, ele utiliza as flags de inicialização de um datagrama IP, elas são:

Para um melhor entendimento, veja:

- O Cliente envia um datagrama com a flag SYN, para o firewall, é uma nova conexão;
- O servidor recebe a requisição, e responde com a dupla SYN+ACK;
- Para o firewall, há uma conversa, estabilizou!

Fechamento de uma conexão:

 
“Imagine o que aconteceria se enviássemos vários pacotes SYN forjando a origem para um Host B, este host B enviaria um pacote SYN+ACK de volta para o Host A e ficaria aguardando o estabelecimento de conexão (ora se forjamos a origem, é óbvio que nunca o receberá), este é o tipo de conexão three-way e várias requisições neste estado de ‘half-connection’ geram o famoso Syn-flood, muitas conexões abertas aguardando um pacotinho ACK de confirmação que nunca chegará.”
A opção state trabalha com o estado da conexão:

NEW: nova conexão
ESTABLISHED: conexão já pertencente e estabilizada entre as duas pontas.
RELATED: conexão que se relaciona com um outro pacote, por exemplo mensagens de erro.
INVALID: Conexões inválidas, pacotes com problemas ou não formados corretamente.
iptables –A INPUT –m state –state INVALID –i eth1 –j DROP

Bloqueia o que entrar (-A INPUT) pela interface eth1 (-i eth1) e com estado inválido (–state INVALID).

A opção mac permite-nos trabalhar por este tipo de endereçamento:

iptables –A INPUT –m mac –mac-source 00:50:04:EE:3D:FD –j DROP

Bloqueia o que for do endereço mac de origem (–mac-source)

A opção multiport permite-nos trabalhar com várias portas, por exemplo:

iptables -A FORWARD -p udp -m multiport –dport 5190,4000 -j DROP

Bloqueia o encaminhamento de mensagens udp das portas 5190 e 4000

iptables -A FORWARD -s 192.168.0.0/24 -p tcp -m multiport –dports domain,ftp-data,ftp,https,pop3,smtp,21 -j ACCEPT

Libera o encaminhamento de mensagens das portas de destino domain,ftp-data,ftp,https,pop3,smtp,21. Uma relação de portas está disponível em /etc/services

Se você quer liberar um range de portas, pode fazer:

iptables -A INPUT -p udp -i eth+ –dport 33435:33525 -j DROP

Bloquear tudo o que for udp e que entrar por qualquer interface (-i eth+) para as portas de 33435 até 33525. Bloqueia o traceroute =)

A opção string permite-nos vasculhar o conteúdo do pacote, por exemplo, bloquear o que contém a string Kazaa.

iptables –A INPUT –m string –string “X-Kazaa” –j DROP

Hum… vamos ver o que está acontecendo? Log nele!

iptables –A INPUT –m string –string “sexo” –j LOG –log-prefix “IPTABLES: Log da string sexo, masculino ou feminino? =)”
Dicas

Não esqueça de sempre logar e depois bloquear, sempre liberar o chefe e depois bloquear o restante da empresa, e assim por diante, pois o iptables irá ler suas regras de cima para baixo, sempre.

O seu arquivo de firewall nada mais é que um “shell script”, permitindo, então você fazer:

# Redireciona VPN e TS para o PDC
PORTS=”1723 3306”
PROTOCOLOS=”tcp udp”
IFACEWEB=”eth1”
      for PORTA in $PORTS;do
            for PROTO in $PROTOCOLOS;do
                  $IPTABLES -t nat -A PREROUTING -p $PROTO -m $PROTO –dport $PORTA -i $IFACEWEB -j DNAT –to 192.168.0.3
      done
done

Resumão

# Ativando o NAT e definindo variáveis.

echo 1 > /proc/sys/net/ipv4/ip_forward
IPTABLES=”/sbin/iptables”
LAN=”192.168.0.0/24”
IFACEWEB=”eth1”

# Apagando as regras anteriores

$IPTABLES -t nat -F
$IPTABLES -t nat -X
$IPTABLES -t nat -Z
$IPTABLES -t filter -F
$IPTABLES -t filter -Z
$IPTABLES -t filter –X
# Configurando NAT e redirecionamento para SQUID, NINGUEM SAI PELA
# porta 80
$IPTABLES -t nat -A POSTROUTING -s 192.168.0.0/255.255.255.0 -j MASQUERADE
$IPTABLES -t nat -A PREROUTING -p tcp -m tcp –dport 80 -j REDIRECT –to-ports 3128
$IPTABLES -t nat -A PREROUTING -p tcp -m tcp –dport 80 -j DROP

# Liberando acesso remoto Terminal Service a uma máquina da rede.
# Lembre-se, tudo o que entrar pela porta 7150 será redirecionado para
# a máquina interna 192.168.0.117 na porta 3389.

$IPTABLES -t nat -A PREROUTING -p tcp -m tcp –dport 7150 -j DNAT –to 192.168.0.117:3389

# Liberando acesso a uma determinada porta de um programa especifico
# (ERP) vindas da Filial (200.200.200.200)

$IPTABLES -A FORWARD -s 200.200.200.200 -p tcp -m tcp –dport 1494 -j ACCEPT

#Bloqueando ping com resposta unreachable

$IPTABLES -I INPUT -i $IFACEWEB -p icmp -j REJECT –reject-with icmp-host-unreachable

# Bloquear Bittorrent, ou outras portas, SQUID, Samba, DNS, etc…

$IPTABLES -I INPUT -p tcp -m tcp –dport 6881:6889 -j DROP
$IPTABLES -I OUTPUT -p tcp -m tcp –dport 6881:6889 -j DROP

# Bloquear conexões de algum programa que utilize algum destino ou
# alguma porta de destino, KAZAA, Emule

$IPTABLES -A FORWARD -d 216.35.208.0/24 -j DROP
$IPTABLES -A FORWARD -p tcp –dport 6346 -j DROP
$IPTABLES -A FORWARD -d 209.61.186.0/24 -j DROP

 Fonte: http://www.flaviotorres.com.br/fnt/artigos/firewall_iptables.php

Fonte: http://www.brunorusso.eti.br/dicas/diversos/fazer-o-crontab-no-enviar-e-mail/

A chamada (slogan publicitário) do Norton 2009 tocando exatamente o dedo na ferida do passado, sua velocidade e morosidade soou para mim como muito provocativa. Por outro lado só propaganda não torna um produto melhor (e mais rápido). Deveria ter um fundo de verdade nestas audaciosas afirmações, caso contrário a Symantec estaria “dando um tiro no próprio pé”!!!

No lançamento algumas informações obtidas foram surpreendentes. O produto foi refeito, é um novo produto, exatamente para resolver em definitivo o ponto mais criticado, sua velocidade. Foram feitas 300 melhorias objetivando somente melhor desempenho. A começar pela instalação que por definição de projeto não poderia demorar mais de um minuto para ser efetuada. Usando PCs (notebooks) comuns, fizemos uma sessão para comprovar. Demorou de 38 a 52 segundos. Neste quesito, promessa cumprida.

Mais algumas afirmações fortes foram comparativos feitos com outros produtos de mercado. Os dados apresentados pela Symantec foram de testes feitos pela empresa PASSMARK LTDA, empresa com expertise em benchmarks. Estes foram testes efetuados em um PC com processador Core 2 Duo E6300 (1.86 Ghz), Vista Home 32 bits, 1 Gbyte de RAM. Este PC, esta configuração, não é nada sofisticada e foi o ambiente que os dados abaixo foram obtidos pela PASSMARK.

Atenção o segundo gráfico não está na escala correta – fato apontado pelo colega Felipe Pessoto

Se não bastasse tudo isso, Windows iniciando mais rápido e tempo de “scan” bem menor que os concorrentes, a memória gasta pelo NIS 2009 (Norton Internet Security) é de apenas 7 Mbytes enquanto KAPERSKY, o produto mais leve até então ocupava apenas 23 Mbytes. EU PRECISAVA CONFERIR ISSO TUDO!!! Obtive o produto para testes e no primeiro dia de novembro eu o instalei em um de meus PCs e desde então venho utilizando para poder agora, mais e um mês depois, dividir a minha experiência com os leitores do ForumPCs.

Porém preciso destacar que neste PC estava usando a ótima suíte de segurança ESET (NOD 32) que tinha transformado meu notebook, muito mais ágil, em relação ao Norton 360 2008 que estava usando antes. De fato ESET era bem mais leve que o Norton 360 2008. Mas para ter uma base de comparação ainda mais “radical”, usei este notebook por quase três dias SEM ANTIVÍRUS ALGUM, para ter um referencial ainda mais rigoroso. Claro que fui extremamente cuidadoso nestes dias.

Após instalá-lo em meu notebook (em 50 segundos) a interface completamente renovada é o que chama a atenção. Eu sempre preferi usar um antivírus e não um pacote de segurança completo (antivírus, firewall, antispam, etc.) exatamente por ser mais leve. A segunda percepção que tive foi que surpreendentemente o notebook estava com o mesmo comportamento, agilidade, que experimentara quando estive sem antivírus no PC. A terceira descoberta foi perceber que a forma como as atualizações das vacinas acontece é totalmente diferente agora. As atualizações ocorrem várias vezes por dia!! Raras foram as vezes que vi na tela do produto que ocorrera atualização há mais de uma hora (na tela abaixo apenas 4 minutos haviam se passado desde a última atualização). Esta estratégia já vinha sendo usada por alguns produtos de segurança. Com Internet melhor, fazer várias vezes por dia implica em downloads muito pequenos e processamento do pacote de vacinas muito mais leve e imperceptível. Sem contar que se uma ameaça é descoberta e a vacina criada, agora é muito mais rápido a proteção ser instalada no PC do usuário. Isso é muito bom. Veja também na tela abaixo que há na interface do Norton um medidor de consumo de CPU (que apresenta o mesmo resultado do Task Manager) e um medidor somente do uso de CPU do próprio Norton. Isso também serve para que o usuário possa conferir em um momento de uso mais intenso do PC o quanto o Norton está usando em relação ao resto do sistema. Até para provar que em momento de lentidão não é ele o culpado!

Está desvendado o segredo das atualizações mais leves. Mas como o NIS 2009 consegue ser dramaticamente tão mais rápido na varredura (scan) de vírus no computador? Isso se deve ao NORTON INSIGHT, uma tecnologia que pode ser descrita da seguinte forma (usando a própria explicação do produto):

Norton Insight aumenta o desempenho do computador ao identificar arquivos confiáveis que não requerem verificação. A verificação repetida de arquivos conhecidos é eliminada permitindo a execução mais rápida do computador.

Este meu notebook, que é absolutamente lotado de programas, vários feitos por mim mesmo, que não pode ser classificado como “típico”, obtive um índice de CONFIANÇA de 25%, ou seja, 75% dos arquivos são verificados. Mas obter de 50% a 80% de índice de confiança é o esperado em um PC típico (não o PC de um colunista do ForumPCs).

Mas o que mais me surpreendeu foi que na primeira varredura (scan) da minha máquina foi achado um arquivo com vírus. Menos mal que o vírus não estava ativo (era só o arquivo), mas os dois antivírus que tivera antes (Norton 360 2008 e ESET) não conseguiram achar este arquivo infectado.

E se não bastasse isso, logo no primeiro dia que levei meu notebook um uma empresa, após alguns minutos usando a rede da mesma, fui brindado com uma “surpresa”, a tentativa de infecção de meu pendrive, também protegido pelo NIS, que deteve a ameaça prontamente.

E era um vírus dos mais “chatos” e de alto risco!

A eficácia na detecção de vírus é crítica para o usuário. A entidade AV-Comparatives.org realizou testes comparativos que indicaram números interessantes. Embora o Norton 2009 não seja o produto que mais ameaças encontrou, foi o mais preciso. Um dos produtos apresentou 63 falsos positivos, que é algo muito ruim para o usuário. E velocidade de varredura do Norton 2009 foi a mais rápida.

Além de toda a competência no NIS 2009 para achar e proteger contra vírus, o firewall foi muito aprimorado, principalmente na sua administração que pode ser feita em vários níveis. O usuário leigo jamais irá alterar suas configurações. Os usuários intermediários e os avançados têm telas progressivamente mais abrangentes para adequar o comportamento do produto às suas necessidades.

O NIS também tem o gerenciador de identidade para que não sejam gravados cookies de rastreamento de dados no PC e ele faz a inserção de dados em formulários como usuário, senha, logins, etc. em determinados sites.

Apesar de eu ter o assunto SPAM bem resolvido em meu Outlook (eu uso o recurso do Outlook que só aceita a lista de confiança – só cai na minha caixa de entrada e-mails de pessoas que eu autorizei alguma vez) resolvi testar o AntiSpam do NIS 2009. Desliguei o recurso do Outlook e deleguei esta tarefa para o NIS. Existe um processo interessante chamado “TREINAR o NIS” que analisa sua caixa postal (as pastas que você escolher) e usa os remetentes destes e-mails para alimentar uma lista de confiança do NIS e também para avaliar o perfil dos e-mails que você recebe habitualmente e interpretar no futuro quais ele deve bloquear.

Eu esperava que o NIS 2009 resolvesse um dos meus problemas que ainda persiste em relação aos SPAMs. Ainda caem lixos na minha caixa de entrada, pois são e-mails cujo remetente sou “eu mesmo”. Claro que é um remetente forjado pelo diabólico spammer. Imaginei que bastaria eu bloquear a mim mesmo, colocar-me na lista “negra” para que e-mails que recebo enviados por mim mesmo sejam considerado spam. Mas não foi bem isso que o NIS 2009 entendeu.

O NIS me desaconselhou a me colocar na lista negra pois eu já estava na lista branca… Infelizmente vou ter que continuar a receber propaganda de medicamentos de origem suspeita em minha caixa postal. De toda forma vou seguir usando este recurso, pois pelo que entendi há a necessidade de certo tempo de “aprendizagem” do produto. Se isso se resolver eu retorno e atualizarei o texto.

Eu vejo que a Symantec, usando um termo bem popular, “deu a cara para bater” e foi bastante provocativa com a chamada para a versão nova de seu produto. De fato é um produto NOVO, nova engenharia, novos algoritmos, que se mostra realmente, até agora o mais rápido e eficiente do mercado. Espera-se que a concorrência se mexa e tente superar o Norton 2009. Isso é bom e muito positivo. Este segmento é muito complicado. Pensar que em 1988 havia apenas DOIS vírus, em 2000 eram 11.000 e que em 2008 estima-se que no final do ano serão mais de 1.2 milhões de vírus conhecidos, os produtos PRECISAM evoluir tecnologicamente. A própria Symantec já sinalizou que para 2010 terá novos mecanismos e tecnologias para poder atender a esta explosão da quantidade de ameaças. Afinal conferir assinaturas (as tais “vacinas”) para milhões de ameaças será cada vez mais difícil. Aos “incrédulos” de plantão, aqueles que sempre criticaram o Norton no passado, mesmo sem testá-lo, fica a minha sugestão e o convite para que experimentem o produto (há no site da Symantec uma versão para testes que funciona por quinze dias sem registro). Dessa vez, até que a concorrência responda, e como é BOA esta competição, a Symantec tem o antivírus mais rápido do mundo!!

PS : Eu me esqueci de contar que o assunto velocidade é mesmo o mote desta versão. Quem compra a versão de caixinha do produto (varejo) ganha uma cópia do jogo NEED FOR SPEED UNDERGROUND!![i]

Fonte: forumpcs

Através do Quota é possível limitar a quantidade de espaço em disco disponível para cada usuário, reservando 50 MB para cada aluno, por exemplo. O uso mais comum do Quota é utilizar uma partição “/home” separada e ativar o Quota para ela. Isso faz todo o sentido, pois, por default, os usuários podem gravar arquivos apenas dentro da pasta home. Entretanto, é possível usar o Quota em qualquer partição, como, por exemplo, em um servidor web compartilhado entre vários virtual hosts, onde a partição de dados está montada no diretório “/var/www”.

Ao ser ativado, o Quota procura por todos os arquivos de cada usuário dentro da partição, não por uma pasta específica. O sistema de Quotas funciona mesmo que os arquivos de um determinado usuário estejam espalhados por várias pastas.

Originalmente, apenas os sistemas de arquivos EXT2 e EXT3 ofereciam suporte ao Quota nativamente, mas, a partir do Kernel 2.6 (usado nas distribuições atuais), foi incluído também suporte para o ReiserFS. É possível instalar o suporte a Quota no ReiserFS em distribuições antigas, baseadas no Kernel 2.4, através de um patch para o Kernel.

Para usar o Quota, o ideal é dividir o HD em três partições: uma partição menor (de 10 ou 20 GB) para a instalação do sistema, a partição swap e outra partição maior (englobando o restante do espaço do HD) para o diretório “/var/www”, “/home” ou outra pasta onde ficarão armazenados os arquivos dos usuários, para a qual o quota será ativado.

No Quota existem dois limites que podem ser estabelecidos, o soft limit e o hard limit. O hard limit é o limite de espaço em si, digamos, 1000 MB para cada usuário. Quando o hard limit é atingido, a gravação de novos arquivos é bloqueada, se necessário interrompendo a transferência:

O soft limit é um limite de advertência, um pouco inferior ao valor do hard limit. Se o hard limit é de 1000 MB, o soft limit poderia ser 500 ou 800 MB, por exemplo. Sempre que superar o soft limit, o usuário receberá uma mensagem de alerta, mas ainda poderá gravar mais dados até que atinja o hard limit. Você pode especificar também um grace period, que será o tempo máximo em que o usuário poderá ficar acima do soft limit (uma semana, por exemplo).

Passado o período, o usuário será obrigado a apagar alguma coisa e voltar a ocupar menos que o valor estabelecido no soft limit antes de poder gravar qualquer novo arquivo. Nesse caso, a conta fica apenas temporariamente bloqueada para a gravação de novos arquivos, nenhum arquivo do usuário é deletado pelo Quota.

Um problema comum relacionado ao uso do Quota em servidores de terminais é que o KDE deixa de abrir quando o limite de espaço do usuário é atingido; ele precisa sempre de algum espaço disponível para criar os arquivos temporários que armazenam as informações da sessão. Nesses casos, você (administrador) vai precisar deletar manualmente alguns arquivos ou aumentar a quota do usuário para que ele possa voltar a usar a conta.

Você pode estabelecer os mesmos limites também para os grupos e inclusive combinar as duas limitações. Você pode, por exemplo, permitir que cada usuário do grupo “alunos” use 5 GB de espaço em disco, desde que o grupo todo não use mais do que 50 GB.

Configuração inicial

Para que o Quota funcione, é necessário instalar os pacotes “quota” e “quotatool“, que contêm um conjunto de utilitários usados para configurar e verificar as quotas de disco. No Debian, os dois podem ser instalados via apt-get:

# apt-get install quota
# apt-get install quotatool

No Fedora, você precisa apenas instalar o pacote “quota” usando o yum:

# yum install quota

Em seguida, é necessário carregar o módulo “quota_v2“, que ativa o suporte necessário no Kernel:

# modprobe quota_v2

Para que ele seja carregado automaticamente durante o boot, adicione a linha “quota_v2” no final do arquivo “/etc/modules“, ou adicione o próprio comando “modprobe quota_v2″ no final do arquivo “/etc/rc.d/rc.local” ou “/etc/init.d/bootmisc.sh” (esse passo não é necessário nas versões recentes do Fedora, onde o suporte a Quota vem compilado no executável principal do Kernel).

Com o módulo carregado, o primeiro passo da configuração é alterar a entrada no fstab referente à partição, de modo que o suporte a quotas de disco seja ativado. Abra o arquivo “/etc/fstab“, localize a linha referente à partição e adicione os parâmetros “usrquota,grpquota” logo após o “defaults”. Se você está ativando o Quota para a partição “/home”, por exemplo, a linha seria parecida com:

/dev/hda2 /home ext3 defaults 0 2

Depois da alteração, a linha ficaria:

/dev/hda2 /home ext3 defaults,usrquota,grpquota 0 2

Ao usar uma partição formatada em ReiserFS, a linha ficaria:

/dev/hda2 /home reiserfs defaults,usrquota,grpquota 0 2

No caso de um servidor web, onde os diretórios dos sites são concentrados na pasta “/var/www/”, a configuração seria exatamente a mesma, mudando apenas a pasta onde a partição (onde as quotas serão aplicadas) será montada.

Se o diretório home (ou qualquer outro diretório onde você deseja aplicar as quotas) faz parte do diretório raiz e você deseja primeiro migrá-lo para uma partição separada, o processo é o seguinte:

a) Instale o novo HD, particione-o e formate a partição de destino.

b) Monte a partição de destino em um diretório temporário usando o comando mount, como em:

# mount /dev/sdb2 /mnt/sdb2

c) Certifique-se de que nenhum usuário ou processo está usando o servidor. Se necessário, reinicie a máquina e desconecte-a da rede.

d) Copie todos os arquivos do diretório que está sendo movido para o raiz da nova partição, usando o comando “cp -a” (que copia recursivamente e mantém as permissões de acesso), como em:

# cp -a /home/* /mnt/sdb2/

e) Desmonte a partição e monte-a novamente no diretório de destino, como em:

# umount /mnt/sdb2
# mount /dev/sdb2 /home

f) Verifique se todos os arquivos e diretórios foram copiados para os locais corretos. Montar a partição sobre o diretório antigo não subscreve os arquivos antigos, que ficam apenas ocultos. Se algo der errado, você pode restaurar o diretório anterior simplesmente desmontando a nova partição.

g) Com tudo verificado, adicione a entrada no “/etc/fstab”, especificando a partição, o diretório onde ela ficará montada, o sistema de arquivos e os parâmetros do Quota, como em:

/dev/sdb2 /home ext3 defaults,usrquota,grpquota 0 2

h) Reinicie o micro (ou remonte a partição) e continue com a configuração do Quota, seguindo os passos a seguir.

Em seguida, você deve criar os arquivos “aquota.user” e “aquota.group” (onde ficam armazenadas as configurações do Quota) no diretório raiz da partição. Se você está ativando o Quota para a partição montada no /home, então os dois arquivos serão “/home/aquota.user” e “/home/aquota.group”.

Por enquanto, vamos apenas criar dois arquivos vazios, usando o comando touch. É importante que ambos fiquem com permissão de acesso “600″, de modo que apenas o root possa acessá-los ou fazer modificações. Os comandos são executados com a partição montada:

# touch /home/aquota.user
# chmod 600 /home/aquota.user
# touch /home/aquota.group
# chmod 600 /home/aquota.group

Depois da configuração inicial, é recomendável reiniciar o servidor, para que os scripts de inicialização se encarreguem de formatar os dois arquivos, montar a partição usando os parâmetros corretos e outros passos necessários.

Naturalmente, é possível também aplicar as alterações sem reiniciar o servidor. Nesse caso, é necessário fechar todos os programas e serviços que estejam acessando arquivos dentro da partição e remontá-la (para que sejam aplicados os parâmetros incluídos no fstab) usando o parâmetro “-o remount” do mount, como em:

# mount -o remount /home

Para verificar se a partição foi montada corretamente, usando os parâmetros do quota, execute o comando “mount” (sem parâmetros) e veja se o ” usrquota,grpquota” adicionados ao fstab aparecem nas propriedades da partição:

# mount

/dev/hda1 on / type ext3 (rw)
…
/dev/hda2 on /home type ext3 (rw,usrquota,grpquota)

Os arquivos “aquota.user” e “aquota.group” devem ser formatados em um formato especial antes de poderem ser usados pelo quota. Se você reiniciou o sistema depois de criar os arquivos, provavelmente o script de inicialização do quota já deve ter feito isso, caso contrário, é necessário rodar o comando “quotacheck” para que ele faça seu trabalho:

# quotacheck -vagum

O quotacheck faz a verificação inicial dos arquivos e usuários, gerando uma tabela oculta que lista os arquivos de posse de cada usuário. Essa tabela é usada pelo Quota para checar o espaço ocupado por cada um e é atualizada em tempo real conforme novos arquivos são gravados.

Da primeira vez que ele é executado, exibe uma mensagem de erro avisando que os arquivos “aquota.user” e “aquota.group” estão danificados (afinal, eles são arquivos vazios), mas isso é esperado. A função dele é justamente corrigir o problema:

quotacheck: WARNING – Quotafile /home/aquota.user was probably truncated. Cannot save quota settings…
quotacheck: WARNING – Quotafile /home/aquota.group was probably truncated. Cannot save quota settings…
quotacheck: Scanning /dev/hda2 [/home] done
quotacheck: Checked 36 directories and 331 files

Depois de executá-lo, você perceberá que os arquivos “aquota.user” e “aquota.group” aumentaram de tamanho, indo dos zero bytes iniciais para alguns kbytes, sinal de que o quotacheck fez seu trabalho:

# ls -lh /home

-rw——- 1 root root 7,0K 2008–01-25 08:24 aquota.group
-rw——- 1 root root 7,0K 2008–01-25 08:24 aquota.user
…

Com tudo pronto, ative o uso das quotas usando o comando “quotaon”, seguido da pasta onde está montada a partição, como em:

# quotaon /home

Se precisar desativar temporariamente o uso das quotas, use o comando “quotaoff”, como em:

# quotaoff /home

Definindo as quotas com o Webmin

Em seguida, falta apenas definir as quotas. A forma mais prática é utilizar o Webmin, que oferece módulos para configurar os mais diversos servidores. Alguns são desnecessariamente complicados, mas outros (como no caso do Quota) são simples de usar e realmente facilitam o trabalho de configuração.

O webmin não faz parte dos repositórios oficiais do Debian (a partir do Etch), do Fedora nem do CentOS, mas isso não é um grande problema, já que você pode encontrar pacotes para as três distribuições no http://webmin.com, o site oficial do projeto.

Ao usar uma distribuição derivada do Debian, baixe o pacote .deb e instale-o usando o dpkg, não esquecendo de rodar o “apt-get -f install” em seguida para resolver qualquer eventual problema de dependências, como em:

# dpkg -i webmin_1.420_all.deb
# apt-get -f install

Depois de instalado, inicie o Webmin com o comando:

# /etc/init.d/webmin start

No caso do Fedora e do CentOS, baixe o pacote usando o link “Download: RPM”, instale-o usando o “rpm -Uvh” e, em seguida, inicie o serviço, como em:

# rpm -Uvh webmin-1.420-1.noarch.rpm
# service webmin start

O Webmin não é um programa gráfico no sentido tradicional, mas sim uma interface de configuração que você acessa usando o navegador. Isso permite que ele seja usado remotamente ou mesmo usado em servidores sem o ambiente gráfico instalado. Para acessá-lo, abra o navegador e acesse o endereço: https://127.0.0.1:10000

O navegador exibe um aviso sobre a autenticidade do certificado. Isso é normal, pois o Webmin utiliza uma conexão criptografada (https) e gera um certificado self-signed durante a instalação, daí o aviso.

Na tela de login do Webmin, logue-se usando o login “root” e a senha de root da máquina. Se preferir, você pode trocar a senha de root do Webmin (de forma que as duas senhas sejam diferentes) na opção “Webmin > Webmin Users”.

Por padrão, o Webmin só pode ser acessado localmente. Para acessar a partir de outras máquinas da rede, inclua os endereços autorizados dentro da opção “Webmin > Webmin Configuration > IP Access Control”. Você pode também fazer com que a interface fique em português no “Webmin > Webmin Configuration > Language”.

Depois de logado, acesse a seção “System > Disk Quotas“. Comece clicando no “Enable Quotas”, isso faz com que ele realize uma varredura inicial, calculando o espaço ocupado por cada usuário, o que pode demorar alguns minutos em partições com muitos arquivos. Depois de tudo ativado, chegamos finalmente à tela inicial de configuração:

Aqui você tem a opção de configurar quotas individuais para cada usuário (/home users) ou quotas para grupos de usuários (/home groups). Os valores são informados em blocos; o mais comum é que cada bloco tenha 1 KB, mas o tamanho pode variar de 512 a 4096 bytes, de acordo com o tamanho da partição e do sistema de arquivos usado. Do lado direito você tem a opção de limitar também o número de arquivos que o usuário pode criar, opção menos usada.

O espaço ocupado por cada usuário é recalculado periodicamente, mas você pode atualizar as informações a qualquer momento clicando no “Check Quotas”. Uma vez configurado, o Quota fica residente e é reativado automaticamente durante o boot, no momento em que a partição é montada. Não estranhe caso o sistema fique alguns minutos parado durante o “Checking quotas” a cada boot; isso é normal, pois é necessário refazer a busca de arquivos.

No caso do Fedora, o SSL não é habilitado por padrão. Por isso, você deve acessar usando http, como em: http://127.0.0.1:10000

O script de instalação do pacote .rpm não define a senha de acesso automaticamente, como no caso do pacote para o Debian, por isso é necessário definir a senha manualmente logo depois da instalação usando o script “/usr/libexec/webmin/changepass.pl”, que deve ser executado como root, especificando a localização da configuração do webmin, o usuário (do webmin) e a senha a ser definida, como em:

# /usr/libexec/webmin/changepass.pl /etc/webmin admin KWVYiJ5U

Não existem muitos problemas em acessar o Webmin sem encriptação localmente, mas se você pretende acessá-lo a partir de outros micros, crie um túnel usando o SSH (veja detalhes no capítulo 10). Se preferir ativar o SSL no Webmin (de forma a poder acessar via https), você pode seguir as instruções do link: http://webmin.com/ssl.html.

Definindo as quotas manualmente

É possível também definir as quotas via linha de comando, usando o comando “edquota”. Ele é uma ferramenta bastante rudimentar, mas funcional, que usa um editor de texto pré-definido para exibir e permitir a alteração das quotas.

O primeiro passo é escolher o editor que será usado, definindo a variável “EDITOR”, que pode conter o nome de qualquer editor de linha de comando (que esteja instalado), como o joe, mcedit, pico, nano ou vi, como em:

# EDITOR=joe

Para editar a quota para um usuário use a opção “-u”, como em:

# edquota -u gdh

Ele exibe um arquivo de texto, usando o editor escolhido, contendo campos com a utilização atual, os limites para blocos e os limites para o número de arquivos:

O que você faz aqui é editar os valores dos campos referentes aos limites, salvar o arquivo e sair do editor. Ao fazer isso, o edquota checa as mudanças feitas e as aplica. Note que os dois primeiros campos “soft” e “hard” da esquerda para a direita contêm os limites de blocos (ou seja, o espaço em disco que pode ser usado), enquanto os campos seguintes indicam os limites para o número de arquivos.

Os únicos valores editáveis dentro do arquivo são os 4 campos com os limites. Os demais (como o número de blocos usados) são exibidos apenas a título de informação. Você até pode alterar estes campos (afinal, trata-se de um arquivo de texto simples), mas as alterações são ignoradas pelo edquota.

Por default, cada bloco corresponde a 1 KB, de forma que o valor “2000000″ corresponde a 2 GB, mas isso pode variar de acordo com as opções usadas ao formatar a partição. Se quiser checar, use o comando “fdisk -l” (como root). Ele mostra detalhes sobre as partições, incluindo o tamanho e o número de blocos.

Continuando, você pode editar também as quotas para os grupos, usando o parâmetro “-g”, como em:

# edquota -g alunos

Para alterar o grace period, use o parâmetro “-t” (sem argumentos), como em:

# edquota -t

Ele exibe outro arquivo de texto, dessa vez oferecendo as opções “Block grace period” (referente ao soft limit para blocos) e o Inode grace period (que se aplica ao soft limit para o número de arquivos, caso usado). O tempo pode ser especificado em dias (days), horas (hours), minutos (minutes), ou segundos (seconds), como em “7days”, “12hours” ou “5minutes” (sempre sem espaço):

Para ver um relatório com as quotas definidas para cada usuário e o espaço atualmente ocupado por cada um, use o comando “repquota”, seguido pela pasta (e não o device) onde as quotas foram ativadas, como em:

# repquota /home

O relatório é exibido no próprio terminal, usando uma formatação simples, com um usuário por linha:

Como pode ver, o webmin facilita bastante a configuração, eliminando parte do trabalho manual, mas é perfeitamente possível se virar com os comandos de modo texto quando ele não estiver disponível.

A principal limitação do protocolo FTP é que todas as informações são transmitidas de forma não encriptada, como texto puro, incluindo os logins e senhas. Ou seja, alguém capaz de sniffar a conexão, usando um programa como o Ethereal, veria tudo que está sendo transmitido. Para aplicações onde é necessário ter segurança na transmissão dos arquivos, é recomendável usar o SFTP, o módulo do SSH que permite transferir arquivos de forma encriptada. Apesar disso, se você quiser apenas criar um repositório com alguns arquivos para download ou manter um servidor público como o Ibiblio.org, então o FTP é mais interessante, por ser mais simples de usar.

O servidor aceita conexões remotas usando os logins dos usuários cadastrados na máquina. Lembre-se de que, para adicionar novos usuários, você pode usar o comando adduser ou algum utilitário de administração incluído na distribuição, como o system-config-users, o users-admin ou o kuser.

Não é difícil instalar o Proftpd, basta procurar pelo pacote “proftpd” na distribuição usada, como em:

# apt-get install proftpd
# yum install proftpd
ou:
# urpmi proftpd

No Debian, durante a instalação do pacote do Proftpd, geralmente são feitas algumas perguntas. A primeira é se você deseja deixar o servidor FTP ativo em modo standalone ou em modo inetd.

O standalone é mais seguro e mais rápido, enquanto o inetd faz com que ele fique ativo apenas quando acessado, economizando cerca de 400 KB de memória RAM (que fazem pouca diferença hoje em dia). O modo standalone é a opção recomendada.

Você terá também a opção de ativar o acesso anônimo, que permite acessos anônimos (somente leitura) na pasta “/home/ftp”, onde você pode disponibilizar alguns arquivos para acesso público. Nesse caso, os usuários fazem login no servidor usando a conta “anonymous” e um endereço de e-mail como senha. Caso prefira desativar o acesso anônimo, apenas usuários com login válido na máquina poderão acessar o FTP.

Depois de concluída a instalação, o servidor fica ativo por default, é inicializado automaticamente durante o boot e pode ser controlado manualmente através do serviço “proftpd”, como em “/etc/init.d/proftpd start”.

A configuração manual do servidor FTP é feita através do arquivo “/etc/proftpd/proftpd.conf“. Um arquivo configurado no CentOS pode ser usado no Mandriva (por exemplo), ou vice-versa; afinal, independentemente de estar usando o Debian, Fedora ou o Mandriva, o proftpd será sempre o mesmo.

Sempre que fizer alterações no arquivo, reinicie o servidor para que elas entrem em vigor. Para isso, use o comando “/etc/init.d/proftpd restart“.

No caso do Debian Etch e do Ubuntu 6.10 em diante, o servidor é configurado para utilizar endereços IPV6 por padrão, o que faz com que ele exiba uma mensagem de erro e aborte a inicialização caso você não tenha configurado a rede IPV6.

Para solucionar o problema, abra o arquivo “/etc/proftpd.conf” e substitua a linha:

UseIPv6 on

por:

UseIPv6 off

Uma das primeiras opções do arquivo é a opção Port, que permite alterar a porta usada pelo FTP. O padrão é usar a porta 21, mas muitos serviços de banda larga bloqueiam as portas 21 e 80 para que os usuários não rodem servidores. Nesse caso, você pode mudar para a porta 2121, por exemplo:

# Port 21 is the standard FTP port.
Port 2121

Ao mudar a porta padrão do servidor, os usuários precisarão indicar manualmente a porta no cliente de ftp ou navegador, como em: ftp://200.234.213.23:2121.

Em seguida, vem a opção MaxClients, que limita o número de conexões simultâneas ao servidor FTP. Esta opção trabalha em conjunto com a limitação de banda (veja a seguir). Você pode limitar os downloads de cada usuário a um máximo de 10 KB/s e limitar o servidor a 3 usuários simultâneos, por exemplo. Assim, o FTP consumirá um máximo de 30 KB/s do link do servidor.

MaxClients 30

Se você quiser limitar o acesso dos usuários, prendendo-os em seus respectivos diretórios home, adicione a linha “DefaultRoot ~” no final do arquivo. Lembre-se de que no Linux o “~” é um curinga, que é automaticamente substituído pela pasta home do usuário que está logado:

DefaultRoot ~

Para ativar a limitação de banda, adicione a linha “TransferRate RETR 8:10″, onde o “8″ pode ser substituído pela taxa desejada, em KB/s, por usuário:

TransferRate RETR 8:10

A princípio, apenas os usuários que tiverem logins válidos no servidor poderão acessar o FTP. Caso você queira abrir um FTP público, adicione estas linhas no arquivo de configuração. Elas ficam comentadas no arquivo original:

<Anonymous ~ftp>
User ftp
Group nogroup
UserAlias anonymous ftp
DirFakeUser on ftp
DirFakeGroup on ftp
RequireValidShell off
MaxClients 20
DisplayLogin welcome.msg
DisplayFirstChdir .message
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>

<Directory incoming>
Umask 022 022
<Limit READ WRITE>
DenyAll
</Limit>

<Limit STOR>
AllowAll
</Limit>
</Directory>
</Anonymous>

A linha “MaxClients” determina o número máximo de usuários anônimos que poderão se logar simultaneamente no servidor. Essa opção é separada da MaxClients principal, que limita o número de usuários com login válido. Você pode permitir 30 usuários válidos e mais 20 anônimos, por exemplo.

A opção “DisplayLogin welcome.msg” indica a mensagem de boas-vindas que é mostrada quando os usuários fazem login no FTP. Por padrão, é exibido o conteúdo do arquivo “/home/ftp/welcome.msg“.

Os usuários anônimos têm acesso apenas aos arquivos dentro da pasta “/home/ftp“, que é visto pelo cliente FTP como o diretório raiz do servidor. Graças a isso, eles não têm como ver, muito menos alterar outros arquivos do sistema.

A seção “Directory incoming” mais abaixo cria uma pasta de upload (por padrão a “/home/ftp/incoming”), onde os anônimos poderão dar upload de arquivos. A idéia é que você veja periodicamente o conteúdo da pasta e mova o que for útil para a pasta “/home/ftp”, para que o arquivo fique disponível para download.

Por padrão, os anônimos não podem ver o conteúdo da pasta incoming, podem apenas dar upload. Se necessário, crie a pasta incoming usando os comandos:

# mkdir /home/ftp/incoming
# chown nobody:nogroup /home/ftp/incoming

Para acessar o seu servidor, os clientes devem usar o login “anonymous” ou “ftp”, usando um endereço de e-mail qualquer como senha.

Uma medida comum ao ativar o upload para os usuários anônimos é usar uma partição separada para o FTP, para evitar que algum engraçadinho fique dando upload durante a madrugada até lotar o HD do servidor. Nesse caso, você precisa apenas adicionar uma linha no arquivo “/etc/fstab” para que a partição desejada seja montada durante o boot. Esta linha de exemplo montaria a partição /dev/hda3, formatada em ReiserFS na pasta /home/ftp:

/dev/hda3 /home/ftp reiserfs defaults 0 2

Criando usuários e ajustando as permissões de acesso

Imagine agora que você quer uma configuração um pouco mais complexa, com vários usuários, cada um tendo acesso a apenas uma pasta específica. Esta configuração pode ser usada em conjunto com os virtual hosts do Apache (permitindo que os responsáveis possam atualizar os arquivos do site), ou em situações em que seu servidor hospeda arquivos de diversos usuários ou projetos diferentes.

O responsável pelo projeto1 pode dar upload para a pasta “/home/ftp/projeto1” (por exemplo), mas não deve ter acesso a outras pastas nem a outros arquivos do sistema. Os usuários anônimos terão acesso às pastas de todos os projetos, mas, naturalmente, apenas para leitura.

A forma mais simples de fazer isso é criar os usuários que terão acesso ao FTP, colocando a pasta a que terão acesso como seu diretório home e bloqueando o uso do shell, para que eles não possam acessar o servidor remotamente através de outros meios (via ssh, por exemplo).

Vamos começar adicionando no arquivo a opção que prende os usuários nos seus diretórios home. Abra o arquivo “/etc/proftpd.conf” e adicione (no final do arquivo) a linha:

DefaultRoot ~

Você vai precisar adicionar também a seção para liberar o acesso anônimo ao ftp, que vimos acima. Como queremos apenas que os mantenedores dos projetos possam dar upload de arquivos, remova a seção “<Directory incoming>”. A seção vai ficar:

<Anonymous ~ftp>
User ftp
Group nogroup
UserAlias anonymous ftp
DirFakeUser on ftp
DirFakeGroup on ftp
RequireValidShell off
MaxClients 20
DisplayLogin welcome.msg
DisplayFirstChdir .message
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
</Anonymous>

O diretório padrão do FTP, onde os usuários anônimos terão acesso aos arquivos, é a “/home/ftp“. Em outras distribuições pode ser usada a pasta “/var/ftp“; dê uma olhada em como o arquivo vem configurado por padrão.

De volta à configuração, vamos começar criando subpastas para cada projeto:

# mkdir /home/ftp/projeto1
# mkdir /home/ftp/projeto2
# mkdir /home/ftp/projeto3
etc…

O próximo passo é ir adicionando os usuários no sistema, tendo o cuidado de fazer as alterações no diretório home e no shell padrão, para que eles tenham acesso somente via FTP e apenas à pasta desejada.

Para adicionar os usuários, use o comando “adduser“, como se estivesse criando uma conta normal:

# adduser projeto1

Acrescentando usuário projeto1…
Acrescentando novo grupo projeto1 (1005).
Acrescentando novo usuário projeto1 (1005) com grupo projeto1.
Criando diretório pessoal /home/projeto1.
Copiando arquivos de /etc/skel

Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Veja que por padrão ele cria a pasta “/home/projeto1″, que passa a ser o diretório home do usuário criado. Entretanto, neste caso queremos que o home seja a pasta “/home/ftp/projeto1“, onde ele dará upload dos arquivos.

Para alterar isso, abra o arquivo “/etc/passwd“, onde ficam guardadas as informações dos usuários. Na última linha do arquivo você verá:

projeto1:x:1005:1005:,,,:/home/projeto1:/bin/bash

Vamos alterar o “/home/projeto1” para “/home/ftp/projeto1” (para trocar o home) e o “/bin/bash” para “/bin/false“, de forma a impedir que usuário tenha acesso ao shell do servidor e possa executar comandos (fazendo o que não deve no servidor). Se você preferir que, além do acesso via ftp, os usuários tenham acesso via ssh, então mantenha o “/bin/bash”. Depois das alterações, a linha ficará:

projeto1:x:1005:1005:,,,:/home/ftp/projeto1:/bin/false

Você pode aproveitar para remover a pasta /home/projeto1, já que não precisaremos mais dela:

# rm -rf /home/projeto1/

Na verdade, esse processo serve para que você entenda melhor o procedimento de criação destes usuários “falsos” no Linux. Estas alterações podem ser especificadas ao criar o usuário. Não é preciso sair editando todos os arquivos manualmente. O comando para criar o usuário “projeto1″, usando a pasta “/home/ftp/projeto1″ como home e o “/bin/false” como shell, seria:

# adduser –home /home/ftp/projeto1 –shell /bin/false –no-create-home projeto1

Não esqueça de acertar as permissões da pasta /home/ftp/projeto1:

# chown -R projeto1:projeto1 /home/ftp/projeto1/

Depois de concluir a configuração, falta só reiniciar o servidor FTP para que as configurações entrem em vigor:

# /etc/init.d/proftpd restart

Em distribuições derivadas do Debian, você vai precisar adicionar a linha “/bin/false” no final do arquivo /etc/shells para que ele possa ser usado:

# echo “/bin/false” >> /etc/shells

Feito isso, você já conseguirá se logar no servidor usando o login criado. O usuário não enxerga nada fora da pasta “/home/ftp/projeto1″ e todos os arquivos que ele der upload vão para lá.

A senha de acesso ao FTP é a mesma definida na hora de criar o usuário. O Proftpd simplesmente aproveita o sistema de autenticação do sistema. Se você precisar alterar a senha do usuário, use o comando “passwd projeto1“.

Para usar o Proftpd em conjunto com os virtual hosts do Apache, a configuração é a mesma, com exceção de que você não precisaria habilitar o acesso anônimo, já que o FTP seria usado apenas pelos webmasters dos sites hospedados.

Nesse caso, ao criar os usuários, use a pasta com os arquivos do site como home, como em:

# adduser –home /var/www/joao –shell /bin/false –no-create-home joao

A opção “–no-create-home” evita que o sistema copie os arquivos do diretório “/etc/skel” (como os arquivos .bashrc, .bash_history e outros) para dentro da pasta de arquivos, “sujando” o diretório. Ao terminar, não se esqueça de alterar as permissões da pasta, de forma que o usuário tenha permissão de escrita:

# chown -R joao:joao /var/www/joao

Graças ao uso da opção “DefaultRoot ~”, os usuários terão acesso apenas à pasta com os arquivos do site, sem acesso às pastas dos outros usuários ou às demais pastas do sistema. Esta é justamente a configuração usada na maioria dos serviços de shared hosting onde o acesso é feito via FTP. O sistema não é nada seguro e de vez em quando algumas das senhas são roubadas, mas, como ele é fácil de implementar e poucos usuários tem dificuldades em acessar as contas, a tradição continua.

Conforme o tempo foi passando, mais e mais módulos foram portados, sem falar de novos módulos desenvolvidos diretamente para uso em conjunto com o Apache 2. Hoje em dia, o Apache 1.3 ainda sobrevive em muitas instalações devido à inércia natural que temos dentro do ramo de servidores, mas não existe nenhum bom motivo para usá-lo em uma nova instalação. O Apache 2 é simplesmente melhor em todos os quesitos.

Apesar disso, ainda existem casos de distribuições que continuam oferecendo as duas versões, de forma a satisfazer os dois públicos. No Debian Etch, por exemplo, o Apache 1.3 é instalado através do pacote “apache”, enquanto o Apache 2 (a versão recomendada) é instalado através do “apache2″. Entretanto, no Debian Lenny já está disponível apenas o Apache 2, assim como no CentOS, no Fedora e em outras distribuições.

Ao instalar o Apache 2, o suporte a SSL é instalado automaticamente junto com o pacote principal (mas ainda é preciso ativá-lo na configuração, como veremos a seguir). Instale também o pacote apache2-utils, que contém diversos utilitários de gerenciamento que usaremos a seguir:

# apt-get install apache2 apache2-utils

Se desejar ativar o suporte a páginas seguras, você vai precisar também do pacote “ssl-cert”, necessário para ativar o suporte a SSL e gerar os certificados. Ele não é instalado por padrão ao fazer uma instalação enxuta do Debian ou do Ubuntu:

# apt-get install ssl-cert

Se você estiver utilizando o CentOS ou o Fedora, instale o pacote “httpd”, que contém o Apache 2 e os utilitários:

# yum install httpd

Diferente do Debian, o serviço não será configurado para ser ativado no boot por padrão e nem mesmo inicializado automaticamente após a instalação. Para ativá-lo, é necessário ativar o serviço e, em seguida, criar os links para início automático usando o chkconfig

# service httpd start
# chkconfig httpd on

Seguindo os nomes dos pacotes, no Debian o serviço se chama “apache2″, enquanto no Fedora e no CentOS ele se chama “httpd”. Para reiniciar o servidor você usa, respectivamente, os comandos “/etc/init.d/apache2 restart” e “service httpd restart”.

Acessando o endereço “http://127.0.0.1″, você verá uma página de boas-vindas, que indica que o servidor está funcionando. Se não houver nenhum firewall no caminho, ele já estará acessível a partir de outros micros da rede local ou da internet:

Por enquanto, temos apenas uma versão básica do Apache, que simplesmente exibe arquivos html e executa scripts CGI. Por padrão, o diretório raiz do servidor Web é “/var/www” (no Debian) ou “/var/www/html” (no Fedora). Com isso, a página “http://seu.servidor/index.html” é, na verdade, o arquivo “/var/www/index.html” ou “/var/www/html/index.html”.

Como de praxe, o diretório raiz é definido através de uma opção dentro do arquivo principal de configuração (a opção “DocumentRoot”) e pode ser alterado caso desejado. Ao hospedar diversos sites no mesmo servidor, você define uma pasta raiz diferente para cada um. Como pode ver, a instalação do Apache propriamente dita é bastante simples, o grande desafio é configurar e otimizar o servidor, como veremos ao longo do restante deste capítulo.

Instalação a partir do código fonte: Muitos administradores preferem instalar o Apache a partir dos fontes, o que oferece um controle maior sobre os recursos que ficarão ou não ativos.

De uma forma geral, instalar a partir do código fonte só é uma boa idéia se você conhece muito bem o software e não está satisfeito com as opções de compilação usadas nos pacotes incluídos na distribuição. Além da instalação e da configuração inicial, você precisará também se preocupar com patches e atualizações de segurança, já que você não poderá contar com as atualizações disponibilizadas através do apt-get ou do yum. Ou seja, se você não está confiante de que vai ter o tempo e o conhecimento necessários para realizar um trabalho de manutenção melhor do que o realizado pelos mantenedores do Debian, Ubuntu, CentOS ou do Fedora, você estará melhor servido simplesmente usado os pacotes pré-compilados.

De qualquer forma, se você quer encarar o desafio, pode baixar o código fonte no: http://httpd.apache.org/. Lembre-se de que para instalar qualquer aplicativo a partir dos fontes, você precisa ter instalados os compiladores e bibliotecas de desenvolvimento.

Os passos básicos são descompactar o pacote, acessar a pasta que será criada e executar o trio “./configure”, “make” e “make install”, este último como root. Isso resultará em uma instalação padrão, onde todos os arquivos são instalados no diretório “/usr/local/apache2″. Para personalizar as opções (que seria o principal motivo de instalar a partir dos fontes, afinal), você deve passar as opções desejadas ao executar o “./configure”, como em:

$ ./configure –prefix=/etc/apache2 –exec-prefix=/usr –bindir=/usr/bin \
–sbindir=/usr/sbin –mandir=/usr/share/man –sysconfdir=/etc/apache2/conf \
–includedir=/usr/include/httpd –libexecdir=/usr/lib/httpd/modules \
–datadir=/var/www/ –with-mpm=prefork –enable-mods-shared=”rewrite”

Como pode ver, as opções incluem não apenas os diretórios de instalação, mas também os módulos que serão ativados e diversas outras opções de configuração. Ao instalar a partir do código fonte, a ativação e a desativação do servidor é feita usando o script “apachectl”, que substitui o “/etc/init.d/apache2″ ou o “service httpd”, como em:

# apachectl start

ou:
# apachectl restart

Nas distribuições derivadas do Debian, a arquitetura modular do Apache é extendida também aos arquivos de configuração. Tradicionalmente, a configuração do Apache é centralizada em um único arquivo, o “httpd.conf“, que pode opcionalmente incluir referências a arquivos externos (includes) que permitem segmentar e organizar a configuração. Aproveitando esta possibilidade, a equipe do Debian desenvolveu uma organização bastante prática, que é usada também no Ubuntu e em outras distribuições derivadas dele.

À primeira vista, a organização do Apache 2 nas distribuições derivadas do Debian parece muito mais complicada, mas, depois de entender, a coisa se revela bastante simples e lógica:

Todos os arquivos de configuração estão organizados dentro do diretório “/etc/apache2″. Dentro dele, temos as pastas “sites-available” e “sites-enabled”, que contêm a configuração dos sites hospedados; as pastas “mods-available” e “mods-enabled”, que armazenam a configuração dos módulos; o arquivo “ports.conf”, onde vai a configuração das portas TCP que o servidor vai escutar; o arquivo “apache2.conf”, que armazena configurações diversas relacionadas ao funcionamento do servidor e a pasta “conf.d”, que armazena arquivos com configurações adicionais.

O Apache é capaz de hospedar simultaneamente vários sites, cada um representado por um arquivo de configuração diferente. Imagine o caso de uma empresa de hosting que mantém um servidor com 2.000 pequenos sites. Quando cada cliente registra seu site e assina o plano de hospedagem, você cria um novo arquivo dentro da pasta “sites-available” com as configurações necessárias e um link para ele na pasta “sites-enabled”.

Como os nomes sugerem, a primeira pasta armazena a configuração de todos os sites (virtual hosts) hospedados no servidor, mas apenas os sites que estiverem presentes na pasta “sites-enabled” ficam disponíveis. Quando é necessário suspender temporariamente um site por falta de pagamento, por exemplo, você simplesmente remove o link na pasta “sites-enabled”, sem precisar mexer na configuração.

Ao invés de criar e remover os links manualmente, você pode usar os comandos “a2ensite” e “a2dissite“, que fazem isso para você. Para ativar e desativar um site configurado no arquivo “/etc/apache2/sites-available/gdhn”, por exemplo, os comandos seriam:

# a2ensite gdhn
(ativa)

# a2dissite gdhn
(desativa)

Quando o Apache é instalado, é criado por padrão o arquivo “/etc/apache2/sites-available/default”, que contém a configuração de um site “raiz”, que usa (por padrão) a pasta “/var/www” como diretório de páginas. Se o seu servidor web vai hospedar um único site, então essa configuração é suficiente, mas, caso você queira hospedar vários sites no mesmo servidor, é necessário criar uma pasta e um arquivo de configuração para cada site adicional.

Seu servidor pode, por exemplo, hospedar o “joao.com.br” e o “maria.com.br”. Um servidor DNS, mantido por você, é configurado para responder pelos dois domínios, em ambos os casos fornecendo o endereço IP do seu servidor web aos clientes. Na configuração do apache, criamos os arquivos “/etc/apache2/sites-available/joao” e “/etc/apache2/sites-available/maria”, cada um configurado para utilizar uma pasta diferente. De acordo com sua preferência, podem ser usadas pastas dentro do diretório home de cada usuário, como em “/home/joao/html” e “/home/maria/html”, ou subpastas dentro do diretório “/var/www”, como em “/var/www/joao” e “/var/www/maria”.

Quando um visitante digita “http://joao.com.br”, o servidor do Registro.br (que responde pelos domínios .br) vai passar a requisição para seu servidor DNS, que responde com o endereço do seu servidor web. Ao acessar o servidor, o navegador solicita o site “joao.com.br” e o servidor responde enviando o arquivo “/var/www/joao/index.html” ou “index.php” ao cliente.

Esta configuração parece bem complicada à primeira vista, mas na prática é relativamente simples. Veremos mais detalhes sobre a configuração de servidores Apache com vários domínios mais adiante.

Continuando, a mesma idéia das duas pastas separadas se aplica aos módulos. A pasta “mods-available” contém a configuração e scripts de inicialização para todos os módulos disponíveis, mas apenas os módulos referenciados (através de um link) na pasta “mods-enabled” são realmente carregados.

Muita gente simplesmente cria e deleta os links manualmente, mas isso pode ser feito mais rapidamente usando os comandos “a2enmod” e “a2dismod”, que ativam e desativam módulos específicos. Para desativar o suporte a PHP, por exemplo, você usaria o comando:

# a2dismod php5

Para ativá-lo novamente, usaria:

# a2enmod php5

Uma vez que um determinado módulo é ativado, ele fica automaticamente disponível para todos os sites hospedados no servidor.

Para que a alteração entre em vigor, é necessário reiniciar o serviço, usando o comando “/etc/init.d/apache2 force-reload” ou o “/etc/init.d/apache2 restart” (no Debian os dois comandos fazem exatamente a mesma coisa):

# /etc/init.d/apache2 force-reload

Por outro lado, ao ativar ou desativar sites, ou ao fazer alterações simples na configuração, você pode utilizar o comando “/etc/init.d/apache2 reload” (sem o “force”), que apenas atualiza a configuração, sem reiniciar o serviço:

# /etc/init.d/apache2 reload

A vantagem de usar o reload em vez do force-reload é que ele não precisa finalizar os processos do Apache, o que evita que o servidor fique indisponível durante a reinicialização do serviço. Em um servidor movimentado, com um grande volume de sites hospedados e um grande volume de acessos, reiniciar o servidor web é um processo caro, que causa interrupção do serviço e perda de acessos, daí as duas opções.

Outra configuração que foi desmembrada é a configuração de portas, que foi para o arquivo “ports.conf“. Originalmente o arquivo vem com uma única linha:

Listen 80

É aqui que você altera a porta padrão do seu servidor ou adiciona novas portas, como faremos mais adiante ao ativar o SSL, por exemplo.

Você pode também usar portas diferentes caso precise manter mais de um servidor web ativo na mesma máquina (muitos administradores usam este truque para testar novas versões do Apache, ou para combiná-lo com um segundo servidor web, como o lighttpd, configurado para servir arquivos e páginas estáticas). Outro uso comum para a opção é (em casos em que você quer disponibilizar um servidor web doméstico) para burlar as restrições das operadoras de planos de acesso, que geralmente bloqueiam conexões na porta 80, de forma a dificultar o uso de servidores web nas conexões domésticas.

Para fazer com que seu servidor escute também na porta 443 (a porta do HTTPS) e na porta 8080, por exemplo, você adicionaria duas novas linhas, como em:

Listen 80
Listen 443
Listen 8080

Finalmente, chegamos ao arquivo “apache2.conf“, que agrupa o “resto” das configurações. É ele que você vai alterar quando, por exemplo, precisar ajustar o número de processos usados pelo Apache ou aumentar o número de conexões simultâneas permitidas pelo servidor, como veremos em detalhes mais adiante.

Instalando o suporte a PHP

No início, existiam apenas páginas html estáticas, com links atualizados manualmente. Depois, surgiram os scripts CGI (geralmente escritos em Perl), que permitiram criar vários tipos de formulários e automatizar funções. Finalmente, surgiu o PHP, adotado rapidamente como a linguagem padrão para criação de todo tipo de página dinâmica, fórum ou gerenciador de conteúdo.

Além da linguagem ser bastante flexível, um script em PHP chega a ser mais de 100 vezes mais rápido que um script CGI equivalente, além de mais seguro. Em resumo, um script CGI é um executável, que precisa ser carregado na memória, executado e descarregado cada vez que é feita uma requisição. No caso do PHP, o interpretador fica carregado continuamente e simplesmente vai executando de forma contínua os comandos recebidos dos scripts incluídos nas páginas.

Para quem programa em Perl, existe a possibilidade de utilizar o mod-perl, instalável através do pacote “apache-mod-perl” ou “libapache2-mod-perl2″. Assim como o PHP, o mod-perl é um módulo do Apache que fica continuamente carregado na memória, executando os scripts Perl de uma forma bem mais rápida e segura que os scripts CGI.

Voltando ao assunto principal, no Debian o suporte a PHP é instalado através do pacote “php5” (ou “php4″, de acordo com a versão escolhida). Para instalá-lo, basta usar o gerenciador de pacotes da distribuição em uso, como em:

# apt-get install php5

No caso do CentOS e do Fedora, é usado um pacote unificado, o “php”, que inclui a versão mais recente do interpretador, eliminando a confusão:

# yum install php

Com o interpretador PHP instalado, falta instalar o módulo do Apache 2, que no Debian está disponível através do pacote “libapache2-mod-php5″ (ou “libapache2-mod-php4″, de acordo com a versão desejada):

# apt-get install libapache2-mod-php5

O módulo “libapache2-mod-php5″ é instalado dentro da pasta “/usr/lib/apache2/modules/” e é ativado de uma forma diferente que no Apache 1.3. Ao invés de adicionar as linhas que ativam o módulo e criam as associações de arquivos no final do arquivo httpd.conf, são criados dois arquivos dentro da pasta “/etc/apache2/mods-available/”, com, respectivamente, a ativação do módulo e as associações de arquivos. Os links são criados automaticamente ao instalar o pacote, mas você pode tirar qualquer dúvida usando o comando a2enmod:

# a2enmod php5

Não esqueça de reiniciar o serviço para que o módulo seja carregado e a configuração entre em vigor:

# /etc/init.d/apache2 force-reload

ou:
# service httpd restart

Com o suporte a PHP ativado, o Apache continua exibindo diretamente páginas com extensão .htm ou .html, mas passa a entregar as páginas .php ou .phps ao interpretador php, que faz o processamento necessário e devolve uma página html simples ao Apache, que se encarrega de enviá-la ao cliente.

Estas páginas processadas são “descartáveis”: cada vez que um cliente acessa a página, ela é processada novamente, mesmo que as informações não tenham sido alteradas. Dependendo do número de funções usadas e da complexidade do código, as páginas em PHP podem ser bastante pesadas. Não é incomum que um site com 100.000 pageviews diários (o que corresponde a umas 5 a 8 requisições por segundo nos horários de pico) precise de um servidor dedicado, de configuração razoável.

Quase sempre, os sistemas desenvolvidos em PHP utilizam também um banco de dados MySQL ou Postgre SQL. Naturalmente, é perfeitamente possível que os scripts simplesmente salvem as informações em arquivos de texto dentro do diretório do site, mas isso resultaria em um desempenho muito ruim, sem falar em eventuais brechas de segurança. Utilizar um banco de dados permite armazenar um volume muito maior de informações, acessíveis de forma mais segura.

Para que o interpretador PHP seja capaz de acessar o banco de dados, é necessário ter instalado (além do servidor MySQL propriamente dito) o módulo “php5-mysql” (ou “php4-mysql”), que faz a junção entre os dois componentes:

# apt-get install php5-mysql

No caso do PostgreSQL, é utilizado o módulo “php5-pgsql”, que tem a mesma função:

# apt-get install php5-pgsql

Não se esqueça de reiniciar o Apache, para que as alterações entrem em vigor:

# /etc/init.d/apache force-reload

No caso do Fedora e do CentOS, muda apenas o nome do pacote, que passa a se chamar simplesmente “php-mysql”:

# yum install php-mysql

Para verificar se o suporte a PHP está realmente ativo, crie um arquivo de texto chamado “info.php” (ou outro nome qualquer, seguido da extensão .php) dentro da pasta do servidor web, contendo apenas a linha abaixo:

<?php phpinfo( ); ?>

Salve o arquivo e abra a página através do navegador. A função “phpinfo”, que usamos no arquivo, faz com que o servidor exiba uma página com detalhes da configuração do PHP e dos módulos ativos:

Depois de verificar, remova o arquivo, pois não é interessante que essas informações fiquem disponíveis ao público.

Dicas de segurança

O interpretador php é configurado através do arquivo “php.ini“, um longo arquivo de configuração que permite ativar ou desativar opções diversas da linguagem como, por exemplo, a possibilidade de fazer upload de arquivos através de scripts colocados nas páginas.

A localização do arquivo pode variar de acordo com a distribuição, mas você pode encontrá-lo rapidamente usando o comando “locate”. No caso do CentOS, o arquivo é o “/etc/php.ini“, enquanto nas distribuições derivadas do Debian é usado o arquivo “/etc/php5/apache2/php.ini“.

Para melhorar a segurança, é recomendável desativar as funções “show_source”, “system”, “shell_exec”, “passthru”, “exec”, “popen”, “proc_open”, “symlink”, o que pode ser feito através da opção “disable_functions =”, disponível (no Debian Etch) na linha 224 do arquivo. Basta adicionar a lista das funções, como em:

disable_functions = show_source, system, shell_exec, passthru, exec, popen, proc_open, symlink

Outras opções que é recomendável manter desativadas dentro do arquivo são:

expose_php = Off
register_globals = Off
allow_url_fopen = Off
allow_url_include = Off

A opção “allow_url_fopen” permite abrir ou processar uma página ou arquivo externo dentro do script php. Embora ela seja uma função útil, usada por scripts que geram uma lista de links a partir de um feed, por exemplo, ela pode ser usada para diversos tipos de abusos, o que faz com que seja desativada em diversos serviços de hospedagem, como no caso do Dreamhost.

Ao tentar executar algum script em PHP que dependa da função, você receberá um erro similar a:

Warning: file_get_contents() [function.file-get-contents]: URL file-access is disabled in the server configuration in /var/ww/site/rss.php on line 59

Nesse caso, você tem duas opções. Ou volta a ativar a opção dentro do arquivo, substituindo a linha “allow_url_fopen = Off” por “allow_url_fopen = On” (é necessário reiniciar o serviço do Apache para que a alteração entre em vigor) ou reescreve o script usando a função “cURL”, para que o script baixe o arquivo antes de processá-lo.

Outra dica é que além do pacote básico, existem diversos módulos e add-ons para o PHP, disponíveis através de pacotes complementares, como o “php5-gd” (usado por diversos scripts de CAPTCHA, os verificadores onde o usuário precisa digitar o texto contido na imagem) e o “php5-mcrypt” (uma biblioteca com funções de encriptação e desencriptação). Você pode começar com o pacote básico e ir instalando os pacotes adicionais conforme for precisando deles.

Instalando o MySQL

O MySQL é um banco de dados extremamente versátil, usado para os mais diversos fins. Você pode acessar o banco de dados a partir de um script em PHP, através de um aplicativo desenvolvido em C ou C++, ou praticamente qualquer outra linguagem (até mesmo através de um shell script! .

Existem vários livros publicados sobre ele, por isso vou me limitar a falar sobre a instalação e a configuração necessária para utilizá-lo em um servidor LAMP, em conjunto com o Apache e o PHP.

O primeiro passo é instalar o servidor MySQL propriamente dito. Nas distribuições derivadas do Debian precisamos instalar apenas o pacote “mysql-server” usando o apt-get:

# apt-get install mysql-server

No CentOS ou Fedora, instalamos os pacotes “mysql” e “mysql-server”, usando o yum:

# yum install mysql mysql-server

Você pode instalar também os pacotes “mysql-client” (o cliente que permite acessar os dados e fazer modificações no banco de dados) e o “mysql-navigator” (uma interface gráfica para ele).

Para que o serviço seja configurado para ser carregado durante o boot, ative-o usando o chkconfig:

# chkconfig mysqld on

Antes de iniciar o serviço, rode o comando “mysql_install_db“. Ele prepara o terreno, criando a base de dados “mysql” (usada para armazenar a configuração do servidor MySQL, incluindo informações sobre os usuários e sobre as demais bases de dados) e também uma base de dados chamada “test”, que pode ser usada para testar o servidor:

# mysql_install_db

O passo seguinte é ativar o servidor MySQL:

# /etc/init.d/mysql start

No caso do Fedora e do CentOS, o serviço se chama “mysqld”, ao invés de simplesmente “mysql”, como no caso do Debian:

# service mysqld start

O MySQL possui um usuário padrão chamado “root”, que, assim como o root do sistema, tem acesso completo a todas as bases de dados e é usado para fazer a configuração inicial do sistema, assim como tarefas de manutenção. Esta conta inicialmente não tem senha, por isso você deve definir uma logo depois de iniciar o serviço, usando o comando “mysqladmin -u root password senha”, incluindo a senha desejada diretamente no comando, como em:

# mysqladmin -u root password psUT7wq01

Se você precisar trocar a senha posteriormente, é necessário acrescentar o parâmetro “-p” antes do “password” e, em seguida, especificar a nova senha, como em:

# mysqladmin -u root -p password psUT7wq01

Enter password: ********

Veja que nesse caso é necessário incluir a senha antiga ao executar o comando, antes de continuar, já que do contrário teríamos uma brecha óbvia de segurança.

Continuando, depois de definir a senha, o próximo passo é criar uma base de dados. Você pode instalar vários scripts diferentes (um fórum, um chat e um gestor de conteúdo, por exemplo) no mesmo servidor e, inclusive, várias cópias de cada um. Isso é cada vez mais utilizado, tanto dentro de sites que oferecem diversos serviços, quanto em servidores compartilhados, onde os responsáveis por cada site têm a liberdade de instalar os sistemas de sua preferência.

Administração básica do banco de dados

Existem muitas interfaces de administração para o MySQL, mas a forma mais elementar é usar o prompt de comando. Para acessá-lo, use o comando:

# mysql -u root -p <enter>

Enter password: <senha>

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 43 to server version: 4.0.15-log
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.
mysql>

Veja que o cabeçalho normal do bash foi substituído por um “mysql>”, que lembra onde você está. Para sair, pressione “Ctrl+C” ou execute o comando “quit“.

Dentro do prompt do MySQL, use o comando “CREATE DATABASE” (criar base de dados), seguido pelo nome desejado. Neste exemplo, estou criando uma base de dados para usar na instalação do phpBB, que veremos a seguir. Um detalhe importante é que todos os comandos dados dentro do prompt do MySQL devem terminar com ponto-e-vírgula:

mysql> CREATE DATABASE phpbb;
Query OK, 1 row affected (0.04 sec)

Para confirmar, use o comando “SHOW DATABASES”, que lista as bases de dados criadas no servidor, como em:

mysql> SHOW DATABASES;

+——————–+ | Database | +——————–+ | information_schema | | mysql | | phpbb | | test | +——————–+

Note que além da base “phpbb” que criamos, existem mais três bases de dados, criadas durante a instalação. As bases “mysql” e “information_schema” são para uso interno do MySQL, incluindo o armazenamento das configurações (sendo um banco de dados, o MySQL usa a si mesmo para armazenar suas configurações , enquanto a base “test” é uma DB vazia, que pode ser usada para fins de teste.

Temos em seguida a questão das permissões de acesso. Nada impede que você sempre utilize a conta “root” do MySQL e inclusive configure os scripts instalados para a utilizarem. Entretanto, isso é extremamente inseguro, principalmente se você pretende instalar vários scripts e aplicativos no mesmo servidor, ou se as bases de dados serão acessadas por vários usuários.

O ideal é que cada base de dados tenha um usuário próprio e seja acessível apenas por ele. Se você vai instalar o phpBB (fórum) e o WordPress (gerenciador de conteúdo), por exemplo, crie duas bases de dados (“phpbb” e “wordpress”, por exemplo) e dois usuários separados, cada um com permissão para acessar uma das duas bases.

Na configuração de cada um dos gestores, informe a base de dados que será usada e o usuário e senha correspondente. Isso evita que eventuais problemas de segurança em um coloquem em risco também os dados referentes ao outro.

Outra situação comum é ao configurar um servidor com vários virtual hosts. Nesse caso, o webmaster de cada site vai precisar de uma ou mais bases de dados e, naturalmente, cada um vai precisar de um login próprio, com acesso apenas às suas próprias bases de dados.

Para criar um usuário “phpbb”, com senha “nDPIcqq9″ e dar a ele acesso à base de dados “phpbb” que criamos, use (dentro do prompt do MySQL) o comando:

mysql> GRANT ALL ON phpbb.* TO phpbb IDENTIFIED BY ‘nDPIcqq9‘;
(permita tudo na base phpbb para o usuário phpbb, identificado pela senha nDPIcqq9)

mysql> FLUSH PRIVILEGES;

O comando “FLUSH PRIVILEGES” faz com que o servidor MySQL atualize as tabelas de permissões, fazendo com que a alteração entre em vigor automaticamente, ao invés de apenas na próxima vez que o servidor for reinicializado. Na verdade, ele não é necessário ao adicionar usuários usando o comando “GRANT” (como no nosso caso), mas é saudável se acostumar a utilizá-lo sempre que usar comandos que modifiquem as permissões de acesso. Você vai notar que a maioria dos tutoriais inclui o comando depois das operações relacionadas a alterações nas permissões de acesso.

Continuando, para trocar a senha posteriormente, use o comando:

mysql> SET PASSWORD FOR phpbb = PASSWORD(‘JSAm950A‘);
(defina senha para o usuário phpbb, onde a senha é JSAm950A)

Este mesmo comando pode ser usado para trocar a senha do root, como em:

mysql> SET PASSWORD FOR root = PASSWORD(‘V5LQSxqL‘);

Se mais tarde você precisar remover as permissões de acesso de um usuário anteriormente criado (em um site com vários webmasters, onde um se desligou da equipe, por exemplo) use o comando:

mysql> REVOKE ALL ON phpbb.* FROM phpbb;
(remova todos os direitos para a base phpbb, para o usuário phpbb)

mysql> FLUSH PRIVILEGES;

Com isso, o usuário deixará de ter acesso à base de dados especificada, mas ainda continuará existindo no sistema e poderá acessar outras bases de dados a que tenha acesso. Para realmente remover o usuário, usamos o comando “DROP USER”, como em:

mysql> DROP USER phpbb

O comando “DROP USER” é suportado apenas pelas versões recentes do MySQL. Caso você esteja usando uma versão antiga, onde ele ainda não seja suportado, pode usar o comando “DELETE FROM mysql.user WHERE User=”, como em:

mysql> DELETE FROM mysql.user WHERE User=’phpbb’;

Para remover uma base de dados, use o comando “DROP DATABASE”, como em:

mysql> DROP DATABASE phpbb;

Todos estes comandos devem ser dados dentro da base de dados “mysql”, a base de dados interna usada pelo MySQL, acessada por default ao abrir a interface. Se, por acaso, você tiver mudado a base de dados de trabalho anteriormente (usando o comando USE), use o comando abaixo para voltar à base administrativa:

mysql> USE mysql;

Veja que os comandos usados dentro do prompt do MySQL seguem uma linguagem literal, usando palavras do inglês. Quem tem uma boa familiaridade com a língua tem bem mais facilidade em dominar os comandos.

Outra observação é que os comandos não são case sensitive. Tanto faz escrever “CREATE DATABASE phpbb;” ou “create database phpbb;”. Escrever os comandos em maiúsculas é apenas uma forma de dar mais destaque a eles.

Instalando o phpMyAdmin

Depois dessa configuração inicial, você pode experimentar instalar um gerenciador gráfico para facilitar a manutenção do seu servidor MySQL. Uma boa opção neste caso é o phpMyAdmin.

Para instalá-lo, basta instalar o pacote “phpmyadmin”, como em:

# apt-get install phpmyadmin

ou:
# yum install phpmyadmin

O pacote para instalação em outras distribuições, que não incluam o pacote por padrão, pode ser encontrado no: http://www.phpmyadmin.net/.

O phpMyAdmin é um gestor de configuração escrito em PHP que trabalha em conjunto com o Apache. Ele permite que você crie bases de dados, ajuste as permissões de acesso dos usuários, faça backup, e diversas outras atividades administrativas de uma forma mais simples que através do prompt de comando.

Uma vez instalado, ele pode ser acessado através do endereço “http://servidor/phpmyadmin/” ou “https://servidor/phpmyadmin/“. Na tela inicial, você pode se logar usando qualquer uma das contas registradas no MySQL. Use o root para tarefas administrativas, quando for necessário ter acesso a todas as bases ou fazer backup de tudo, e uma das contas restritas para acessar uma base específica:

O acesso via HTTPS é preferível para acessos feitos via web, já que evita que as senhas de acesso e outras informações fiquem circulando em texto puro por aí. O pacote do Debian se encarrega de ativar o suporte a SSL no phpMyAdmin automaticamente, mas para usá-lo é necessário também ativar o suporte a SSL na configuração do Apache, como veremos no tópico seguinte.

Caso, mesmo depois de gerar o certificado e ativar o SSL no Apache, você continue recebendo um erro ao tentar acessar a interface do phpMyAdmin via SSL, experimente reconfigurar o pacote usando o dpkg-reconfigure, como em:

# dpkg-reconfigure phpmyadmin

Selecione a opção “apache2″ quando o script perguntar sobre o servidor web usado e responda “sim” quando ele perguntar se você deseja reiniciar o serviço:

No CentOS e em diversas outras distribuições o phpMyAdmin vem configurado por padrão para permitir conexões apenas a partir da máquina local, uma precaução de segurança. Com isso, ao tentar acessar a interface remotamente, você recebe um “Forbidden. You don’t have permission to access /phpmyadmin/ on this server”. Para solucionar o problema, edite o arquivo “/etc/httpd/conf.d/phpmyadmin.conf” e comente a linha “Deny from All”, dentro da seção “<Directory “/usr/share/phpmyadmin”>”, como em:

<Directory “/usr/share/phpmyadmin”>
Order Deny,Allow
# Deny from all
Allow from 127.0.0.1
</Directory>

Uma observação importante é que ao ser usado em conjunto com o Apache, instalado no mesmo servidor que ele, o MySQL é acessado apenas localmente, através da interface de loopback. O Apache envia a requisição ao módulo PHP que faz o acesso ao banco de dados, tudo localmente. Nessa configuração, o servidor MySQL não deve ficar disponível para a Internet. Configure o firewall para bloquear a porta 3306 usada pelo servidor MySQL, além de todas as outras portas que não forem explicitamente necessárias.

Caso o servidor MySQL precise ficar acessível para outros servidores (você pode configurar o phpBB e outros scripts para utilizarem um servidor MySQL externo), configure o firewall para deixar a porta aberta apenas para os endereços IP dos servidores que forem ter acesso. Como os servidores dedicados sempre utilizam endereços fixos (ao contrário dos servidores domésticos), esta configuração fica mais simples.

Para administrar seu servidor MySQL remotamente, o ideal é que se conecte ao servidor via SSH e faça todo o trabalho através dele. Se precisar acessar diretamente alguma ferramenta de configuração, como o Webmin ou o phpMyAdmin, você pode criar um túnel (novamente usando o SSH) ligando a porta correspondente do servidor a uma porta da sua máquina e fazer o acesso através dela. Veremos em detalhes como usar o SSH e criar túneis encriptados no capítulo dedicado a ele.

Ativando o SSL

O SSL (Secure Socket Layer) é o protocolo usado para criar páginas seguras, encriptando toda a transmissão entre o cliente e o servidor. Os dois usos mais comuns são em páginas de comércio eletrônico, onde é necessário oferecer um ambiente seguro para concluir a transação e transmitir dados confidenciais e também na criação de ambientes administrativos, como os usados pela maioria dos gestores de conteúdo, que permitem que você gerencie o conteúdo do site.

Na grande maioria das distribuições, o pacote com o mod_ssl é instalado juntamente com o pacote principal do Apache, ou é pelo menos disponibilizado como um pacote separado, instalável através do gerenciador de pacotes.

No caso das distribuições derivadas do Debian, você precisa apenas ativar o módulo usando o comando “a2enmod”. Reinicie o serviço para que a alteração entre em vigor:

# a2enmod ssl
# /etc/init.d/apache2 force-reload

No caso do CentOS, é necessário instalar o pacote “mod_ssl” usando o yum. O script de pós-instalação se encarrega de adicionar o script de carregamento na pasta “/etc/httpd/conf.d” automaticamente, concluindo a instalação. Não se esqueça de reiniciar o serviço para que a alteração entre em vigor:

# yum install mod_ssl
# service httpd restart

Com o módulo carregado, fica faltando apenas o componente mais importante, que é o certificado SSL propriamente dito.

Se você quer ativar o SSL para testes ou para uso interno (para acessar alguma ferramenta administrativa instalada no servidor, ou para uso em uma página disponibilizada apenas para um grupo de amigos, por exemplo), você pode simplesmente gerar seu próprio certificado, o que é rápido, grátis e indolor. Se, por outro lado, você está ativando o SSL para uso em um site de comércio eletrônico, é necessário obter um certificado reconhecido através da Verisign ou outra entidade certificadora.

Os certificados caseiros são chamados de certificados self-signed (auto-assinados), já que você mesmo faz o papel de entidade certificadora, gerando e assinando o certificado. O algoritmo de encriptação usado é o mesmo, de forma que um certificado self-signed corretamente gerado oferece a mesma segurança que um certificado reconhecido. O grande problema é que os navegadores nos clientes não serão capazes de verificar a autenticidade do certificado, de forma que os visitantes receberão um aviso de “certificado não reconhecido” ao acessarem a página:

O propósito de entidades certificadoras, como a Verisign, é confirmar a titularidade dos certificados, confirmando que o certificado recebido ao acessar determinado site pertence realmente à entidade que o está fornecendo. É isso que garante que você está mesmo acessando o home banking do banco em que tem conta e não o site de um script kiddie qualquer. Certificados assinados por entidades certificadoras são automaticamente aceitos pelos navegadores (já que sua identidade já foi confirmada pela entidade certificadora), o que evita a exibição da mensagem.

Vamos então começar com a configuração de um certificado self-signed, e em seguida entender o que muda ao utilizar um certificado reconhecido.

Usando um certificado self-signed

No Debian e derivados você pode gerar um certificado caseiro utilizando o script “make-ssl-cert”, instalado através do pacote “ssl-cert”:

# apt-get install ssl-cert

Ao usar o script, você deve especificar o arquivo com o template (/usr/share/ssl-cert/ssleay.cnf) e o arquivo onde o certificado será salvo (/etc/apache2/ssl/apache.pem, para gerar um certificado padrão para o servidor), como em:

# mkdir /etc/apache2/ssl/
# cd /etc/apache2/ssl/
# make-ssl-cert /usr/share/ssl-cert/ssleay.cnf apache.pem -days 1095

A opção “-days” especifica a validade do certificado, que no exemplo será de 3 anos. O script solicitará as informações sobre a organização que serão incluídas no certificado, incluindo o código de país, estado, cidade e o nome da empresa. Estes são dados públicos, que serão exibidos aos clientes como parte das propriedades do certificado. O mais importante vem no final, quando o script pergunta:

Common Name (eg, your name or your server’s hostname) []:

Nesse ponto, você deve sempre fornecer a URL completa do servidor onde o certificado será usado, como em “www.gdhpress.com.br” ou “ssl.gdhn.com.br”. Se você especificar um domínio diferente, o cliente receberá um aviso adicional ao se conectar, avisando do problema. Isso afastará visitantes, já que muitos pensarão tratar-se de uma fraude.

Com o certificado gerado, abra agora o arquivo “/etc/apache2/ports.conf” e adicione a linha “Listen 443″ (a porta usada pelo https), como em:

Port 80
Listen 443

Com isso, o Apache 2 já está configurado. Falta apenas ativar o uso do SSL dentro da configuração do(s) virtual host(s) onde ele for ser utilizado. Para testar, vamos ativá-lo na página padrão que usamos para testar o servidor.

Abra o arquivo “/etc/apache2/sites-available/default“. No início do arquivo, substitua a linha “NameVirtualHost *”, por:

NameVirtualHost *:443
NameVirtualHost *:80

Isso explica que o Apache deve escutar tanto a porta 80 padrão, quanto a porta 443, usada pelo SSL. Logo em seguida, substitua a linha “<VirtualHost *>”, por:

<VirtualHost *:80>

Até aqui, dividimos a configuração em duas seções, uma para a porta 80, outra para a porta 443, usada pelo SSL. Falta agora adicionar a seção referente à configuração do SSL no final do arquivo:

<VirtualHost *:443>
DocumentRoot /var/www/
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/access.log combined
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.pem
</VirtualHost>

Reinicie o servidor (/etc/init.d/apache2 restart) e acesse o endereço “https://127.0.0.1” para testar a configuração. Ao conectar, o navegador exibe um aviso “O certificado do servidor falhou no teste de autenticidade” ou similar, o que é normal ao usar um certificado caseiro.

O CentOS não inclui o make-ssl-cert, mas inclui um outro script bastante prático, disponível dentro da pasta “/etc/pki/tls/certs”:

# cd /etc/pki/tls/certs

Uma vez dentro da pasta, use o comando “make” seguido pelo nome do arquivo que será gerado, como em:

# make apache.pem

Por default, a validade do certificado gerado pelo script será de 365 dias. Para usar outro valor, edite o arquivo “make-dummy-cert” dentro da pasta, substituindo o “-days 365″ na quinta linha de baixo para cima pelo valor desejado antes de gerar o certificado.

Isso gerará o arquivo “/etc/pki/tls/certs/apache.pem“, contendo o certificado. Para que ele seja usado, abra o arquivo “/etc/httpd/conf.d/ssl.conf” e localize a linha:

#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

Descomente-a e indique a localização do arquivo gerado, como em:

SSLCACertificateFile /etc/pki/tls/certs/apache.pem

A partir daí, você pode reiniciar o serviço httpd e testar a configuração acessando o endereço “https://servidor”.

Diferente do Debian, não é necessário adicionar a linha “Listen 443″ na configuração do Apache, pois a linha faz parte do arquivo “/etc/httpd/conf.d/ssl.conf”, que é criado automaticamente ao instalar o pacote mod_ssl. Dentro do arquivo, você encontra as linhas:

# When we also provide SSL we have to listen to the
# the HTTPS port in addition.
#
Listen 443

Em outras distribuições, você pode usar diretamente o openssl para gerar o certificado. Nesse caso, o comando é maior, já que precisamos especificar manualmente um volume maior de parâmetros. Scripts como o make-ssl-cert são desenvolvidos justamente para tornar a geração do certificado mais simples.

# openssl req -new -x509 -days 1095 -sha1 -newkey rsa:1024 -nodes \
-keyout server.key -out meuservidor.csr

Este comando gera dois arquivos separados, o “server.key”, que contém a chave criptográfica e o “meuservidor.csr”, que contém o certificado que será fornecido aos clientes. Estes dois arquivos tem a mesma função do arquivo “.pem” que é gerado pelos scripts do Debian e do CentOS, apenas desmembrado em dois arquivos separados. Para usá-los, você precisa apenas adicionar duas linhas separadas dentro do arquivo de configuração principal do Apache (“/etc/apache2/httpd.conf” no caso do Debian ou “/etc/httpd/conf/httpd.conf”, no caso do CentOS), especificando as localizações dos dois arquivos:

SSLCertificateFile /etc/apache2/ssl/meuservidor.csr
SSLCertificateKeyFile /etc/apache2/ssl/server.key

Não esqueça de ativar o mod_ssl e incluir a linha “Listen 443″ na configuração do Apache, para que ele passe a escutar a porta do SSL. Certifique-se também de que a porta 443 está aberta na configuração do firewall.

Usando um certificado reconhecido

Finalmente, temos a configuração para um certificado reconhecido, que será assinado por uma entidade certificadora, que você utilizaria em um site de comércio eletrônico aberto ao público.

Uma das entidades certificadoras mais tradicionais é a Verisign (http://www.verisign.com/), que oferece uma série de garantias sobre os certificados emitidos. O grande problema com relação à Verisign é o preço: o certificado de validação mais simples custa nada menos de US$ 499 anuais, com opções de até US$ 1499. Com preços tão altos, não é de se estranhar que existam inúmeras outras entidades certificadoras, que oferecem preços mais competitivos.

Alguns exemplos são a Thawte (http://www.thawte.com) a GeoTrust (http://www.geotrust.com), a NetworkSolutions (http://www.networksolutions.com), a Digicert (http://www.digicert.com/) e a Comodo (http://www.instantssl.com), que possui opções a partir de US$ 79 anuais.

A Comodo é a mesma empresa que desenvolve o Comodo Firewall, distribuído gratuitamente como uma forma de divulgação dos serviços de certificação. No site está disponível também a opção de gerar um certificado de teste (válido por 90 dias) gratuitamente, que você pode usar para fins de teste, ou quando quiser colocar uma loja virtual no ar rapidamente, deixando para aderir a um dos planos pagos mais tarde:

Existem ainda casos de empresas que oferecem certificados de baixo custo, como a Godaddy (http://www.godaddy.com, a mesma que faz registro de domínios), que oferece certificados a partir de US$ 29.90.

Em termos de segurança, não existe muita diferença entre um certificado emitido pela Godaddy ou pela Verisign, as principais diferenças são o nível de validação e as garantias oferecidas por cada uma em caso de fraude ou de quebra da chave criptográfica. Assim como em outras áreas, o principal fator na decisão acaba sendo a questão da confiança.

Muitos serviços de hospedagem oferecem a possibilidade de utilizar um certificado compartilhado, onde a empresa responsável “empresta” seu próprio certificado para uso dos clientes, em troca de uma taxa de manutenção anual. Esta opção pode parecer interessante devido ao baixo custo e à facilidade de implementação, mas não é o mesmo que obter seu próprio certificado, já que muito provavelmente você precisará hospedar seu site em um subdomínio e os clientes verão o nome da empresa de hospedagem e não o nome da sua empresa ao examinarem as propriedades do certificado.

Existe ainda a possibilidade de obter um certificado gratuito no http://www.cacert.org/. Ele é reconhecido pela CAcert, mas o certificado raiz deles não vem pré-instalado na maioria dos navegadores, o que faz com que os clientes continuem recebendo a mensagem de certificado não válido ao acessar o servidor, de forma similar ao que temos ao usar um certificado self-signed.

Ao contratar os serviços de uma entidade certificadora, sua parte no trabalho é a de gerar uma chave de encriptação e uma requisição de certificado, o que é novamente feito usando o openssl:

# openssl req -new -nodes -keyout gdhn.key -out gdhn.csr

O “gdhn.key” e o “gdhn.csr” indicam os arquivos com a chave e com a requisição do certificado que serão gerados. Você precisará responder as mesmas perguntas sobre o país, estado, cidade, nome da empresa, etc., que precisam ser respondidas corretamente, já que as informações serão examinadas não apenas pela entidade certificadora, mas também pelos clientes:

Country Name (2 letter code) [AU]: BR
State or Province Name (full name) [Some-State]: Estado
Locality Name (eg, city) []: Cidade
Organization Name (eg, company) []: Minha Empresa LTDA
Organizational Unit Name (eg, section) []: Vendas
Common Name (eg, YOUR name) []: ssl.minhaempresa.com.br

Como comentei anteriormente, o campo “Common Name” deve ser preenchido com o domínio onde o certificado será usado (incluindo o “www” ou o subdomínio usado), caso contrário os clientes receberão um aviso ao acessarem o site:

Em geral, as entidades certificadoras oferecem a opção de obter um certificado curinga (wildcard), que cobre automaticamente todos os subdomínios usados no site. Entretanto, como eles abrem a possibilidade de usar vários subdomínios usando um único certificado, as certificadoras cobram bem mais caro por eles. A Comodo, por exemplo, cobra nada menos do que US$ 449.95 anuais, mais de 5 vezes o valor do certificado regular:

No final do processo, o openssl oferece a opção de especificar uma senha (challenge password) para o certificado. É importante deixá-la em branco, caso contrário você precisará fornecê-la cada vez que o servidor web for iniciado, incluindo casos de reboots acidentais. O arquivo do certificado é armazenado em uma pasta protegida do servidor, fora do diretório disponível para a web, de forma que se um atacante chega ao ponto de obter acesso a ele, significa que o problema é mais embaixo e ele muito provavelmente já obteve acesso completo ao servidor de qualquer forma.

Depois de gerar a requisição, o próximo passo é enviar o arquivo .csr para a entidade certificadora, que o usará para gerar o certificado. O arquivo .csr é na verdade um arquivo de texto plano, cujo conteúdo pode ser copiado e colado em um formulário web. Depois de confirmada sua identidade e feito o pagamento, você receberá de volta o certificado assinado, que pode ser então usado na configuração do Apache.

A configuração consiste em adicionar as linhas “SSLCertificateFile” e “SSLCertificateKeyFile”, indicando a localização dos arquivos .crt e .key recebidos. Em muitos casos, você receberá também um terceiro arquivo, com extensão “ca-bundle” ou similar, que é usado em conjunto com uma terceira opção, a “SSLCertificateChainFile”.

Este terceiro arquivo contém uma combinação de certificados, que permitem aos clientes chegarem até o certificado raiz da entidade certificadora, de forma a comprovarem a autenticidade do seu certificado. Devido a isso, ele é também chamado de certificado intermediário (Intermediate Certificate). Temos aqui um exemplo de configuração com as três opções:

<VirtualHost *:443>
DocumentRoot /var/www/gdhn
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl_gdhn_com_br.crt
SSLCertificateKeyFile /etc/apache2/ssl/gdhn_com_br.key
SSLCertificateChainFile /etc/apache2/ssl/ssl_gdhn_com_br.ca-bundle
</VirtualHost>

O processo de emissão do certificado inclui uma verificação de identidade, que é justamente um dos principais papéis da entidade certificadora, já que se qualquer um pudesse gerar certificados válidos no nome de qualquer outro, o sistema perderia completamente o sentido. Nos planos mais simples, como no certificado gratuito oferecido pela Comodo, é feita uma simples verificação de titularidade via e-mail, onde você deve confirmar um código enviado para uma conta administrativa, como “admin@meudominio” ou “hostmaster@meudominio”. Nos planos mais caros (onde a entidade certificadora realmente oferece garantias, inclusive financeiras sobre o certificado emitido), o processo é mais burocrático, incluindo o envio de documentos.

Usando o SSL para pastas específicas

Em geral, você vai desejar usar o SSL apenas para seções específicas do site, como no caso de páginas de cadastro e de vendas, por exemplo. Na maioria dos casos, o cliente navega livremente pelo site, usando o protocolo HTTP não encriptado e acessa uma área protegida pelo SSL ao concretizar a compra ou ao acessar uma área onde precisa fornecer dados pessoais. Isso acontece por um motivo muito simples: servir páginas em HTTPS é caro em termos de processamento, de forma que encriptar o acesso a todo o site acabaria gerando um grande desperdício de recursos.

Você tem então duas opções. Usar um domínio separado para a área protegida, como “ssl.minhaempresa.com”, de forma que ela fique completamente separada do restante do site, ou proteger apenas uma pasta específica do site, tornando mandatário o uso do HTTPS ao acessá-la.

Para a primeira solução, você usaria uma configuração similar a essa dentro da configuração do Apache:

<VirtualHost *:80>
ServerName www.gdhn.com.br
DocumentRoot /var/www/gdhn
</VirtualHost>

<VirtualHost *:443>
ServerName ssl.gdhn.com.br
DocumentRoot /var/www/gdhn-ssl
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl_gdhn_com_br.crt
SSLCertificateKeyFile /etc/apache2/ssl/gdhn_com_br.key
SSLCertificateChainFile /etc/apache2/ssl/ssl_gdhn_com_br.ca-bundle
</VirtualHost>

Veja que, nesse caso, temos essencialmente dois sites separados, um acessível apenas via HTTP e outro apenas via HTTPS. Ao acessar o “http://www.gdhn.com.br” o visitante acessaria a pasta “/var/www/gdhn”, que conteria o conteúdo geral do site, enquanto ao acessar o “https://ssl.gdhn.com.br” ele acessaria as páginas da seção segura, armazenadas na pasta “/var/www/gdhn-ssl”. A interligação entre as duas partes seria então feita através de links, que levariam o visitante de uma seção à outra do site.

A segunda opção, usar uma pasta para o SSL, é um pouco mais elegante, mas demanda uma configuração um pouco mais cuidadosa. Imagine que a seção segura do site será armazenada dentro da pasta “/var/www/gdhn/loja”, que deverá ser acessada apenas via HTTPS.

Ao acessar o “https://www.gdhn.com.br” o visitante cairá direto na pasta segura e, ao tentar acessar o “http://www.gdhn.com.br/loja” ele será automaticamente redirecionado ao “https://www.gdhn.com.br“. Nesse caso, você utilizaria uma configuração similar a essa:

<VirtualHost *:80>
ServerName www.gdhn.com.br
DocumentRoot /var/www/gdhn
<Directory /var/www/gdhn/loja>
SSLRequireSSL
</Directory>
Redirect /loja https://www.gdhn.com.br
</VirtualHost>

<VirtualHost *:443>
ServerName www.gdhn.com.br
DocumentRoot /var/www/gdhn/loja
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl_gdhn_com_br.crt
SSLCertificateKeyFile /etc/apache2/ssl/gdhn_com_br.key
SSLCertificateChainFile /etc/apache2/ssl/ssl_gdhn_com_br.ca-bundle
</VirtualHost>

Veja que agora, usamos o domínio “www.gdhn.com.br” nas duas seções da configuração, tanto para HTTP quanto para HTTPS, entretanto, a seção com a configuração do HTTPS aponta para a pasta “/var/www/gdhn/loja”.

Como a idéia é que os arquivos da pasta possam ser acessados apenas usando o SSL, adicionamos uma diretiva para a pasta (<Directory /var/www/gdhn/loja>), dizendo que ela só pode ser acessada via HTTPS (SSLRequireSSL).

Para que os visitantes que tentarem acessar a pasta via HTTP sejam encaminhados para a área protegida, usamos uma regra de encaminhamento (Redirect /loja https://www.gdhn.com.br). Esta regra utiliza o módulo “rewrite”, que precisa estar ativo na configuração do Apache. Caso necessário, ative-o usando o comando “a2enmod rewrite”.

Finalmente, caso você queira que todo o conteúdo do site fique disponível via HTTPS e que os visitantes que tentarem acessar o http://www.gdhn.com.br/ sejam encaminhados para o https://www.gdhn.com.br, a configuração seria similar a essa:

<VirtualHost *:80>
ServerName www.gdhn.com.br
DocumentRoot /var/www/gdhn
<Directory /var/www/gdhn/>
SSLRequireSSL
</Directory>
Redirect / https://www.gdhn.com.br
</VirtualHost>

<VirtualHost *:443>
ServerName www.gdhn.com.br
DocumentRoot /var/www/gdhn/
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl_gdhn_com_br.crt
SSLCertificateKeyFile /etc/apache2/ssl/gdhn_com_br.key
SSLCertificateChainFile /etc/apache2/ssl/ssl_gdhn_com_br.ca-bundle
</VirtualHost>

Como pode ver, a configuração é quase idêntica à do exemplo anterior. As únicas diferenças são que agora a seção com a configuração do HTTPS aponta para o diretório raiz do site e a regra de redirecionamento encaminha todos os acessos feitos feitos via HTTP para o https://www.gdhn.com.br, fazendo com que o acesso a qualquer página do site seja feito via SSL.

Ativando o uso de Virtual Hosts

O suporte a virtual hosts é um daqueles recursos fundamentais, que possibilitaram o surgimento da Internet da forma como a conhecemos hoje. Ele permite hospedar diversos sites, com domínios ou subdomínios diferentes usando um único servidor e um único endereço IP. Os únicos limitantes com relação ao volume de sites que é possível hospedar são os recursos de hardware do servidor e a banda disponível.

Serviços de hospedagem compartilhada (os planos de shared hosting) utilizam este recurso de forma intensiva, de forma a espremer o maior número possível de clientes em cada servidor, sem falar nos serviços de hospedagem gratuita onde, em muitos casos, um único servidor pode hospedar dezenas de milhares de sites diferentes.

Ao usar virtual hosts, os arquivos de cada site ficam guardados em uma pasta diferente e o servidor se encarrega de direcionar cada visitante à pasta correta. Os recursos do servidor (HD, memória, processamento e link) são divididos entre os sites hospedados, assim como vários programas abertos simultaneamente disputam os recursos da máquina. Isso faz muito sentido no caso de sites pequenos ou médios, que não possuem um número suficiente de visitas para saturarem, sozinhos, o servidor.

Em geral, o servidor é configurado de forma que os usuários tenham direito a uma determinada quota de espaço em disco, possam acessar os arquivos do site via FTP ou SFTP e tenham acesso a uma ou mais bases de dados do servidor MySQL, o que permite a instalação de gestores de conteúdo como o WordPress. Entretanto, eles não podem instalar novos pacotes nem alterar a configuração do servidor. Feitas as apresentações, vamos à configuração.

Invariavelmente, ao hospedar vários domínios, você precisa configurar um servidor DNS para responder por todos os domínios hospedados no servidor, entregando o endereço IP do seu servidor Apache. O cliente acessa então o servidor, solicitando o site desejado, como em “joao.com.br”; o servidor web verifica a configuração e entrega os arquivos apropriados ao cliente.

A configuração do servidor DNS é pouco intuitiva, mas não chega a ser tão complicada quanto muitos dizem. Em resumo, você precisaria instalar o bind no servidor e editar a configuração, adicionando uma nova configuração de zona para cada domínio hospedado. Isso é feito em duas etapas. Na primeira, você edita o arquivo named.conf, adicionando uma entrada com esta, especificando o domínio e o arquivo com a configuração:

zone “joao.com.br” IN {
type master;
file “/etc/bind/db.joao”;
allow-transfer { 64.234.23.13; };
};

Dentro do arquivo “/etc/bind/db.joao”, especificado no arquivo, iria uma configuração similar a esta, especificando o domínio, o nome do servidor e o endereço IP usado por ele, assim como o nome e o endereço IP do servidor DNS secundário:

@ IN SOA servidor.joao.com.br. hostmaster.joao.com.br. (
2008061645 3H 15M 1W 1D )
NS servidor.joao.com.br.
NS ns2.joao.com.br.
IN MX 10 servidor.joao.com.br.
joao.com.br. A 64.234.23.12
www A 64.234.23.12
ns1 A 64.234.23.13

Não é necessário que o DNS esteja instalado no mesmo servidor que o Apache, a função dele será unicamente responder às requisições dos clientes, fornecendo o IP correto. Vamos estudar a configuração do DNS em detalhes no próximo capítulo, dedicado unicamente ao assunto. Este foi apenas um exemplo rápido para que você tenha uma idéia geral sobre a configuração. Por enquanto, vamos nos concentrar na configuração do Apache propriamente dito.

Para ativar o uso dos virtual hosts, o primeiro passo é criar uma pasta separada para cada site que será hospedado. Você pode usar a própria pasta “/var/www”, como em:

# mkdir /var/www/joao
# mkdir /var/www/maria

Em seguida, é necessário adicionar uma nova seção dentro da configuração do Apache para cada um, logo depois da configuração do site default.

Nas distribuições derivadas do Debian, são usados arquivos de configuração separados para cada site, armazenados na pasta “/etc/apache2/sites-available”. Imagine que vamos hospedar os sites “www.joao.com.br” e “www.maria.com.br”, usando as duas pastas criadas anteriormente. Criaríamos, então, um arquivo para cada site, contendo o seguinte:

- /etc/apache2/sites-available/joao:

<VirtualHost *:80>
ServerAdmin joao@joao.com.br
ServerName www.joao.com.br
ServerAlias joao.com.br www.joao.com.br
DocumentRoot /var/www/joao
</VirtualHost>

- /etc/apache2/sites-available/maria:

<VirtualHost *:80>
ServerAdmin maria@gmail.com
ServerName www.maria.com.br
ServerAlias maria.com.br www.maria.com.br
DocumentRoot /var/www/maria
</VirtualHost>

Note que adicionei uma nova diretiva, a “ServerAlias”, que permite que o site seja acessado tanto com, quanto sem o “www”. A linha “ServerAdmin” é, na verdade, opcional, contém apenas o e-mail de contato do administrador do site.

A mesma configuração é usada se você quiser hospedar os sites usando subdomínios, como em “joao.gdhn.com.br” e “maria.gdhn.com.br”. Nesse caso, não usamos o “www” e, por isso, não precisamos da linha “ServerAlias”:

<VirtualHost *:80>
ServerAdmin hostmaster@gdhn.com.br
ServerName maria.gdhn.com.br
DocumentRoot /var/www/maria
</VirtualHost>

Depois de feita a configuração, ative ambos os sites usando o comando a2ensite, o que criará links para eles na pasta “/etc/apache2/sites-enabled”:

# a2ensite joao
# a2ensite maria

Para que a configuração funcione, é necessário editar também o arquivo “/etc/apache2/sites-available/default“, substituindo as linhas:

NameVirtualHost *
<VirtualHost *>

Por:

NameVirtualHost *:80
<VirtualHost *:80>

Essa configuração é necessária para que você possa ativar o suporte a SSL para os virtual hosts. Sem ela, além do SSL não funcionar, você precisaria modificar a configuração de cada um, usando sempre “<VirtualHost *>” ao invés de “<VirtualHost *:80>”.

Você pode adicionar quantos sites quiser usando esses mesmos passos. Sempre que alterar a configuração, é necessário atualizar a configuração do Apache. Nesse caso, o parâmetro “reload” é suficiente (o “force-reload” é necessário apenas ao ativar ou desativar módulos):

# /etc/init.d/apache2 reload

Além de configurar o servidor web, é preciso configurar também um servidor FTP ou SFTP, para que os usuários possam acessar os arquivos de suas respectivas pastas, a fim de atualizarem seus sites. A forma mais simples de fazer isso é criar um usuário para cada um e dar acesso a eles via FTP (mais adiante veremos como configurar o servidor FTP com o Proftpd). Outra opção é utilizar o SFTP, que permite acesso seguro. Veremos mais detalhes sobre ele no capítulo sobre o SSH.

Veja que as três coisas acabam se integrando: o Bind resolve os nomes de domínio, o Apache fornece as páginas e o FTP ou SFTP permite que os webmasters atualizem os sites.

Continuando, ao utilizar o Fedora, CentOS ou outra distribuição derivada do Red Hat, a configuração de todos os virtual hosts é adicionada na seção final do arquivo “/etc/httpd/conf/httpd.conf“, depois do “# Section 3: Virtual Hosts”. Procure pela seção “Virtual Hosts”, perto do final do arquivo, e descomente a linha:

NameVirtualHost *:80

A partir daí, você pode adicionar cada um dos sites hospedados no servidor usando a mesma configuração que vimos anteriormente, como em:

<VirtualHost *:80>
ServerName www.joao.com.br
ServerAlias joao.com.br www.joao.com.br
DocumentRoot /var/www/joao
</VirtualHost>

<VirtualHost *:80>
ServerName www.maria.com.br
ServerAlias maria.com.br www.maria.com.br
DocumentRoot /var/www/maria
</VirtualHost>

A principal diferença nesse caso é que para desativar um determinado site você precisa abrir novamente o arquivo de configuração e remover (ou comentar) a seção referente a ele, em vez de utilizar o “a2dissite”, como no Debian.

Depois de fazer alterações no arquivo, é necessário recarregar a configuração para que elas entrem em vigor:

# service httpd reload

Fazendo dessa forma, os logs de acessos serão misturados no log principal do Apache, o “/var/log/apache2/access.log”. Isso não é problema se você está utilizando o Google Analytics ou outra ferramenta externa para auditar os acessos dos sites (ou se simplesmente você não está preocupado em medir os acessos), mas é um grande obstáculo se você pretende usar o webalizer para gerar os relatórios de acesso.

Para que cada site tenha seus logs separados, você deve adicionar duas linhas adicionais, na configuração de cada virtual host, especificando a localização do arquivo que será usado. Você com certeza não gostaria que os logs ficassem disponíveis ao público, por isso é importante usar diretórios diferentes para os arquivos do site e para os logs, como em:

<VirtualHost *:80>
ServerAdmin joao@joao.com.br
ServerName www.joao.com.br
ServerAlias joao.com.br www.joao.com.br
DocumentRoot /var/www/joao/html
ErrorLog /var/www/joao/logs/error.log
CustomLog /var/www/joao/logs/access.log combined
</VirtualHost>

Você pode também salvar os logs na pasta de logs padrão do Apache, de forma a se beneficiar do rotacionamento automático de logs oferecido pelo logrotate. Nesse caso, você precisa apenas especificar um arquivo de log diferente para cada site, todos salvos dentro da pasta padrão, como em:

<VirtualHost *:80>
ServerAdmin joao@joao.com.br
ServerName www.joao.com.br
ServerAlias joao.com.br www.joao.com.br
DocumentRoot /var/www/joao/html
ErrorLog /var/log/apache2/joao.error.log
CustomLog /var/log/apache2/joao.access.log combined
</VirtualHost>

Note que, como todos os sites ficam hospedados no mesmo servidor, a única forma de chegar ao site desejado é fazendo o acesso através do domínio. Se você tentar acessar diretamente o IP do servidor, vai cair no site padrão (configurado através do arquivo “/etc/apache2/sites-available/default”), que, por padrão, usa o raiz da pasta “/var/www”. Esta página default pode ser usada para mostrar alguma publicidade da empresa responsável pelo servidor, ou uma lista dos sites hospedados, por exemplo.

Concluindo, caso queira ativar o suporte a SSL para algum dos virtual hosts, adicione a sessão referente ao SSL dentro da configuração de cada site, indicando corretamente a pasta do site e os arquivos de log. O SSL pode ser tanto ativado para o raiz do site, permitindo que os visitantes visualizem qualquer parte do site usando o “https://”, ou utilizar uma pasta separada, onde está a parte de comércio eletrônico do site, por exemplo, como em:

<VirtualHost *:443>
ServerName www.joao.com.br
DocumentRoot /var/www/joao/ssl
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.pem
</VirtualHost>

Neste caso, ao acessar o “http://www.joao.com.br“, o visitante visualizará o conteúdo da pasta “/var/www/joao/html”, enquanto ao acessar o “https://www.joao.com.br“, visualizará a “/var/www/joao/ssl”.

Como vimos no tópico anterior, certificados SSL são válidos apenas para um domínio específico. Se você deseja oferecer suporte a SSL para vários subdomínios hospedados no servidor, a melhor opção é adquirir um certificado wildcard, que é valido para qualquer subdomínio dentro do domínio principal da sua empresa. Isso permite que você crie diversos virtual hosts, como “loja1.minhaempresa.com” e “loja2.minhaempresa.com”, utilizando o mesmo certificado.

Essa configuração manual funciona para pequenos servidores, que hospedam algumas dezenas ou centenas de páginas. Grandes serviços de hospedagem geralmente acabam desenvolvendo algum tipo de sistema para automatizar a tarefa. Nos serviços de hospedagem gratuita, por exemplo, onde o número de clientes é assustadoramente grande, as alterações são feitas de forma automática quando o visitante faz seu cadastro, geralmente através de um sistema escrito em PHP ou Java.

Conforme o número de usuários cresce e o espaço em disco no servidor começa a ficar escasso, você começará a sentir falta de um sistema de quotas, que limite o espaço que cada usuário pode usar. Para isso, consulte o tópico sobre quotas de disco, mais adiante.

Gerando estatísticas

O Webalizer é um gerador de estatísticas de acesso para o servidor web. O Apache, por si só, loga todos os acessos feitos ao servidor, incluindo as páginas acessadas, o tráfego gerado, os navegadores e os sistemas operacionais usados pelos clientes, entre outras informações úteis para entender os hábitos e interesses de seus visitantes.

Com o Apache funcionando, é simples instalar o Webalizer: procure pelo pacote “webalizer” dentro do gerenciador de pacotes. Ele é incluído em todas as principais distribuições. Nas derivadas do Debian, você pode instalá-lo via apt-get:

# apt-get install webalizer

Ao contrário do Apache, o Webalizer não é um serviço que fica residente, mas sim um executável que precisa ser chamado cada vez que quiser ver a página de estatísticas atualizada (assim como o Sarg, que vimos no capítulo sobre o Squid). Basta chamá-lo como root:

# webalizer

Por padrão, a página de estatísticas é armazenada na pasta “webalizer/”, dentro do seu servidor web. Se o Apache estiver configurado para armazenar as páginas dentro do diretório “/var/www”, então as estatísticas vão para a pasta “/var/www/webalizer”.

O arquivo de configuração do Webalizer é o “/etc/webalizer.conf“. É importante que você revise o arquivo de configuração, indicando pelo menos a localização correta do arquivo de log do Apache e alterando a pasta onde as estatísticas ficarão armazenadas, caso não queira que elas fiquem disponíveis ao público. Você pode armazená-las em uma pasta isolada no servidor web, como, por exemplo, “/var/webalizer”, de forma que elas fiquem disponíveis apenas localmente ou através de um script. As duas opções “essenciais” dentro do arquivo são:

LogFile /var/log/apache/access.log
OutputDir /var/www/webalizer

Para não precisar executar o comando “webalizer” manualmente sempre que precisar atualizar as estatísticas, você pode configurar o cron para executá-lo automaticamente uma vez por dia ou uma vez por hora. Para isso, basta criar um script dentro da pasta “/etc/cron.daily/” ou “/etc/cron.hourly/“, contendo o comando “webalizer“.

Todos os scripts colocados dentro dessas pastas são, respectivamente, executados todos os dias de manhã, ou uma vez por hora. Para que funcione, é importante verificar se o serviço “cron” ou “crond” está ativo. No caso do Debian, o script para execução do webalizer através do cron é criado automaticamente e configurado para ser executado uma vez por dia.

Em um servidor Apache com vários virtual hosts, é possível fazer com que o Webalizer gere estatísticas separadas para cada um, com uma configuração um pouco mais cuidadosa. Em primeiro lugar, você deve configurar o Apache para gerar arquivos de log separados para cada site hospedado, como no exemplo que vimos há pouco:

<VirtualHost *:80>
ServerAdmin joao@joao.com.br
ServerName www.joao.com.br
ServerAlias joao.com.br
DocumentRoot /var/www/joao/html
ErrorLog /var/www/joao/logs/error.log
CustomLog /var/www/joao/logs/access.log combined
</VirtualHost>

Configurando dessa forma, os logs do site “joao.com.br” ficarão armazenados no arquivo “/var/www/joao/logs/access.log”, os do “maria.com.br” no “/var/www/maria/logs/access.log” e assim por diante, sempre separados dos arquivos disponíveis ao público, que vão na pasta “html”.

O próximo passo é criar um arquivo de configuração do Webalizer separado para cada um. Para manter as coisas organizadas, crie o diretório “/etc/webalizer” e crie uma cópia do arquivo webalizer.conf original para cada site, dentro da pasta, como em:

# mkdir /etc/webalizer
# cd /etc/webalizer
# cp webalizer.conf joao.conf
# cp webalizer.conf maria.conf

Precisamos agora editar cada um dos arquivos, informando o arquivo de log, domínio e diretório onde ficarão armazenados os relatórios de cada site. No arquivo “/etc/webalizer/joao.conf”, por exemplo, você teria (além das outras linhas do arquivo padrão) as linhas:

LogFile /var/www/joao/logs/access.log
OutputDir /var/www/joao/html/webalizer
HostName joao.com.br

Depois de gerar os arquivos de configuração para todos os sites, falta fazer com que o Webalizer processe todos automaticamente. Uma forma rápida de fazer isso (dica do próprio FAQ do webalizer) é usar o comando:

# for i in /etc/webalizer/*.conf; do webalizer -c $i -q; done

Esse é, na verdade, um mini-script, que vai executar o Webalizer uma vez para cada arquivo “.conf” encontrado no diretório “/etc/webalizer”, gerando todas as estatísticas em uma tacada só. Para que o comando seja executado todos os dias automaticamente, coloque-o dentro de um script no diretório “/etc/cron.daily“.

No Debian, temos o script “/etc/cron.daily/webalizer“, que é criado automaticamente durante a instalação do pacote e se encarrega de gerar as estatísticas diariamente, lendo o arquivo “/etc/webalizer.conf”. Podemos modificá-lo para que ele leia também os arquivos dentro do diretório “/etc/webalizer”. Para isso, edite o arquivo e substitua as linhas:

# Run webalizer quietly
${WEBALIZER_BIN} -c ${WEBALIZER_CONF} -q
${WEBALIZER_BIN} -c ${WEBALIZER_CONF} -q ${nonrotatedlog}

Por:

# Run webalizer quietly
${WEBALIZER_BIN} -c ${WEBALIZER_CONF} -q
${WEBALIZER_BIN} -c ${WEBALIZER_CONF} -q ${nonrotatedlog}

for i in /etc/webalizer/*.conf; do ${WEBALIZER_BIN} -c $i -q; done
for i in /etc/webalizer/*.conf; do ${WEBALIZER_BIN} -c $i -q ${nonrotatedlog}; done

Um problema comum é como restringir o acesso às estatísticas, afinal, na maioria dos casos, elas não devem ficar disponíveis ao público. A solução mais simples nesse caso é usar um arquivo .htaccess, que permite restringir o acesso ao diretório, exigindo login e senha.

O primeiro passo é criar um arquivo de senhas, usando o comando “htpasswd“, que faz parte do pacote “apache2-utils” (o mesmo que utilizamos para gerar as senhas do Squid). O arquivo de senhas deve, preferencialmente, ser armazenado em uma pasta fora do diretório com os arquivos do site. Se possível, use um arquivo separado para cada site hospedado. Vou usar como exemplo a pasta “/etc/apache2/auth”:

# mkdir /etc/apache2/auth
# cd /etc/apache2/auth
# touch joao.auth
# htpasswd joao.auth joao

New password:
Re-type new password:

Aqui, criamos o arquivo “/etc/apache2/auth/joao.auth”, contendo o usuário “joao” e a senha digitada, armazenada de forma encriptada. Você pode armazenar vários logins no mesmo arquivo, executando o comando uma vez para cada usuário.

Com o arquivo de senhas criado, crie um arquivo de texto chamando “.htaccess” no raiz do diretório das estatísticas, contendo o seguinte:

AuthName “Acesso Restrito”
AuthType Basic
AuthUserFile /etc/apache2/auth/joao.auth
require valid-user

A linha “AuthName” contém o texto que será mostrado na tela de login exibida para o cliente, enquanto o “AuthUserFile” contém o arquivo de senhas gerado.

Concluindo, embora o webalizer ofereça bons recursos, o uso de relatórios de estatísticas locais está saindo um pouco de moda devido à popularização do Google Analytics, o serviço de geração de estatísticas oferecido pelo Google, que permite gerar estatísticas muito mais detalhadas e pode ser integrado ao AdSense e ao AdWords: http://www.google.com/analytics/.

Enquanto o Webalizer trabalha gerando os relatórios a partir das estatísticas do Apache, o Analytics os gera a partir de um pequeno javascript que é incluído nas páginas e executado diretamente pelos clientes. Isso faz com que os relatórios do Analytics acabem oferecendo números mais próximos da realidade, já que excluem o tráfego gerado pelos crawlers dos mecanismos de busca e outros tipos de tráfego automatizado, que acabam inflando bastante as estatísticas do Webalizer.

Um ponto negativo do Analytics é que ele não computa acessos de visitantes que bloqueiam a execução de javascript no navegador (como os visitantes usando a extensão NoScript do Firefox) ou que acessam o site usando navegadores primitivos, sem suporte a javascript, como no caso de muitos navegadores móveis.

Com isso, os números mostrados pelo Webalizer acabam sempre ficando bem acima dos acessos reais, enquanto os do Analytics ficam sempre um pouco abaixo. Como nenhuma das duas ferramentas é perfeita, muitos preferem simplesmente usar as duas.

Gestores de conteúdo e add-ons

Agora que já estudamos sobre a instalação do servidor LAMP e sobre a configuração dos virtual hosts, vamos a alguns exemplos de instalação de gestores de conteúdo que você pode instalar no servidor.

Com o MySQL instalado e o suporte a PHP ativo, você tem pronta a estrutura necessária para instalar os diversos scripts de fórum, chat, gestores de conteúdo e outros. A maioria destes scripts é simples de instalar, você precisa apenas criar uma base de dados no MySQL ou Postgre, copiar os arquivos para uma pasta dentro do servidor web e editar um arquivo (ou acessar uma página de configuração através do navegador) para incluir as informações sobre o servidor (base de dados a ser usada, login e senha, etc.) e concluir a configuração.

Note que, embora o Apache e o MySQL sejam bastante seguros, nada garante que os scripts desenvolvidos por terceiros também serão. De nada adianta ter um servidor web extremamente seguro, se o script de gerenciamento de conteúdo que você instalou tem um buffer overflow no campo de login que permite executar comandos arbitrários, obter a senha do servidor MySQL (que o script usa para fazer seu trabalho) ou fazer alterações no conteúdo do site.

O ponto fraco na segurança de qualquer site ou fórum é quase sempre a segurança do script usado. Não escolha qual usar pensando apenas na facilidade de uso. Investigue o histórico de segurança e, uma vez escolhido qual usar, fique de olho nas atualizações de segurança.

Para os exemplos, escolhi o phpBB, o WordPress e o Ruby on Rails. O phpBB é um sistema de fórum open-source que além de muito usado é surpreendentemente robusto e expansível; o WordPress é uma solução bastante flexível de gestor de conteúdo, que além de ser usado em blogs, pode ser adaptado para uso em diversas outras frentes, enquanto o Ruby on Rails é um meta-framework com muitos recursos, usado em um volume cada vez maior de sites com páginas dinâmicas e aplicativos web em geral.

Solucionando problemas com o charset

Um problema muito comum ao utilizar o Apache 2 sobre uma distribuição Linux recente é os caracteres acentuados das páginas hospedadas aparecerem trocados por interrogações, quadrados ou vírgulas em alguns navegadores, como nesse screenshot:

Isso acontece em situações onde os arquivos das páginas hospedadas no servidor foram salvos usando o charset ISO-8859-1 (ou outro dos charsets pré-unicode) e o servidor Apache está configurado para usar UTF-8, que é o default no Ubuntu e na maioria das distribuições atuais.

Para solucionar o impasse, você tem basicamente três opções. A primeira é especificar o charset correto no header de cada página do site, o que é feito adicionando uma tag “meta” dentro da seção “head” da página, como em:

<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ />
ou:
<meta http-equiv=”Content-Type” content=”text/html; charset=ISO-8859-1″ />

Algumas versões antigas do Internet Explorer entendem apenas a tag “http-equiv…”. Você pode adicioná-la também, de forma a manter compatibilidade com elas, como em:

<http-equiv=”Content-Type” content=”text/html; charset=utf-8″>

Continuando, a segunda opção é mudar a configuração do Apache para que ele passe a utilizar o ISO-8859-1 como charset padrão, em vez do UTF-8. Nas distribuições derivadas do Debian, isso é definido no arquivo “/etc/apache2/conf.d/charset“. Edite o arquivo, substituindo a linha:

AddDefaultCharset UTF-8

por:

AddDefaultCharset ISO-8859-1

Se, por acaso, o arquivo “/etc/apache2/conf.d/charset” não estiver disponível (ou a configuração não surtir efeito), edite o arquivo “/etc/apache2/apache2.conf“, descomentando (ou adicionando) a mesma linha.

No Fedora/CentOS a opção é incluída diretamente no arquivo “/etc/httpd/conf/httpd.conf” (perto do final do arquivo), basta substituir a linha “AddDefaultCharset UTF-8″ por “AddDefaultCharset ISO-8859-1″, assim como no Debian.

Se o servidor hospeda páginas escritas em português, é recomendável editar também a linha:

LanguagePriority en da nl et fr de el it ja ko no pl pt pt-br ltz ca es sv tw

… no “/etc/apache2/apache2.conf”, mudando a ordem das linguagens, de forma que o pt-br e o pt fiquem no início:

LanguagePriority pt-br pt en da nl et fr de el it ja ko no pl ltz ca es sv tw

Para que a configuração entre em vigor, é preciso fazer com que o Apache 2 recarregue a configuração:

# /etc/init.d/apache2 reload

ou:
# service httpd reload

O charset padrão do servidor é aplicado a todas as páginas onde o charset não é diretamente especificado na seção <head>, ajudando em casos em que você tem um grande volume de páginas antigas, onde o charset não é especificado.

Uma terceira opção, mais radical, seria mudar o charset de todas as páginas hospedadas (se você usa um gestor de conteúdo, muitas vezes esta opção estará disponível nas configurações) de “ISO-8859-1″ para “UTF-8″. Diversos editores de texto, incluindo o kwrite e o gedit, permitem trocar o charset usado, basta especificar qual quer usar nas configurações.

É possível também converter os arquivos diretamente, usando o comando “recode“, que está disponível nos repositórios de praticamente todas as distribuições que adotaram o uso do UTF8. Comece instalando o pacote, como em:

# apt-get install recode

ou:
# yum install recode

Para converter um arquivo, use o comando “recode -d ISO-8859-1..UTF-8″ seguido pelo arquivo a ser convertido, como em:

$ recode -d ISO-8859-1..UTF-8 arquivo.txt

Você pode também converter de uma vez diversos arquivos, como em:

$ recode -d ISO-8859-1..UTF-8 *.html

ou:
$ recode -d ISO-8859-1..UTF-8 *.php

O recode não salva cópias dos arquivos originais, por isso é importante que você sempre execute o comando sobre uma cópia dos arquivos, substituindo os arquivos originais só depois de verificar e testar. Concluindo, é possível também fazer o caminho inverso, convertendo arquivos de UTF-8 para ISO-8859-1, invertendo a sintaxe do comando, como em:

$ recode -d UTF-8..ISO-8859-1 *.html

A principal observação nesse caso é que o recode só consegue converter caracteres UTF-8 que possuem um correspondente dentro da codificação ISO-8859-1, por isso não deve ser usado em textos que incluam caracteres de línguas asiáticas, por exemplo.

Otimizando a configuração do Apache

Ao colocar um site no ar, seu objetivo é quase sempre fazer com que ele seja acessado pelo maior volume possível de visitantes. Entretanto, o sucesso tem um preço: o maior volume de requisições faz com que seu servidor web seja mais exigido e ele passe a consumir mais recursos da máquina. A partir de um certo ponto, o servidor passará a ficar saturado nos horários de maior acesso, tornando o acesso ao site lento e fazendo com que o site comece a perder visitantes.

Uma das soluções seria simplesmente atualizar o hardware do servidor, resolvendo o problema na base da força bruta. A segunda seria otimizar a configuração do Apache, fazendo com que ele trabalhe de forma mais eficiente. Não existe uma “configuração perfeita” para o Apache, já que a configuração ideal varia de acordo com o tipo de tráfego do site, mas aqui vão algumas dicas que podem ajudar.

Uma das configurações mais diretamente relacionadas à performance do servidor e ao consumo de memória é o número de instâncias do servidor httpd. O Apache é capaz de responder a um número indefinido de acessos simultâneos, de acordo com a velocidade do link e dos recursos da máquina. Para cada requisição simultânea, é necessário que exista uma instância do Apache carregada na memória.

Quando o cliente acessa uma página, ele monopoliza uma dessas instâncias abertas até que a requisição seja concluída, ou seja, até que a página seja carregada ou o arquivo baixado. Em horários de alta demanda, são abertas mais instâncias do servidor Apache, que vão sendo fechadas (para economizar memória) conforme os acessos diminuem.

Nos momentos de pico, o Apache precisa manter mais processos ativos, o que aumenta o consumo de memória no servidor. O uso de processamento, por sua vez, varia bastante de acordo com o tipo de páginas servidas. Páginas em PHP com código não otimizado, scripts em CGI ou servlets Java, por exemplo, podem consumir bastante processamento, fazendo com que o processador se torne um gargalo muito antes da memória RAM, enquanto páginas estáticas ou arquivos disponibilizados para download consomem pouco processamento, fazendo com que a memória RAM e a otimização do servidor sejam as principais prioridades.

Ajustando o número de processos

O primeiro passo é verificar se está sendo usado o módulo mpm-prefork (usado por default na maioria das distribuições) ou o módulo mpm-worker, já que ambos são configurados em seções diferentes do arquivo.

No caso das distribuições derivadas do Debian, as duas versões são disponibilizadas através de pacotes separados, de forma que você precisa apenas verificar qual dois dois está instalado, usando o comando “dpkg -l | grep apache”. Ele retornará uma lista como:

# dpkg -l | grep apache

ii apache2 2.2.3-4+etch4 Next generation, scalable, extendable web se
ii apache2-mpm-prefork 2.2.3-4+etch4 Traditional model for Apache HTTPD 2.1
ii apache2-utils 2.2.3-4+etch4 utility programs for webservers
ii apache2.2-common 2.2.3-4+etch4 Next generation, scalable, exten
ii libapache2-mod-fcgid 1.10-2 an alternative module compat with mod_fastcg
ii libapache2-mod-php5 5.2.0-8+etch11 server-side, HTML-embedded scri

No exemplo, podemos ver que está sendo usado o pacote “apache2-mpm-prefork”, que é justamente a versão usada por padrão.

O mpm-prefork é a versão tradicional do Apache, onde cada instância inicia um único thread e atende a uma única requisição por vez, isolando o processamento de cada página servida. Isso torna a operação do servidor mais estável e menos vulnerável a módulos ou páginas mal escritas, mas, em compensação, consome um pouco mais de memória RAM que o mpm-worker, onde cada instância do Apache pode abrir vários threads, de acordo com a necessidade.

Para pequenos servidores, onde você não precise necessariamente extrair cada gota de desempenho do servidor, o mpm-prefork é a escolha mais segura, mas em casos em que o servidor precise operar no limite, você pode realizar testes com o mpm-worker de forma a avaliar se a redução no consumo de memória é significativa.

Voltando à configuração, o número de instâncias abertas (ao usar o mpm-prefork) é determinada pela seção abaixo dentro do arquivo “/etc/apache2/apache2.conf“:

# prefork MPM
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>

A opção “StartServers” determina o número padrão de instâncias do Apache que ficarão carregadas na memória, respondendo a requisições. Cada instância ocupa cerca de 7 MB de memória (variando de acordo com as opções de compilação usadas ao gerar o pacote e os módulos carregados), de forma que 5 instâncias consomem cerca de 35 MB de memória do servidor.

Além das instâncias principais, temos instâncias “reservas” (spares), que ficam disponíveis para absorver rapidamente picos de acesso, sem que o Apache tenha que perder tempo carregando mais instâncias para só depois começar a responder às requisições. As opções “MinSpareServers” e “MaxSpareServers” determinam o número mínimo e máximo de “reservas”, sendo que o número real flutua entre os dois parâmetros, de acordo com a demanda.

A opção “MaxClients” é a parede de concreto, o número máximo de conexões simultâneas que o Apache aceita manter abertas, independentemente da demanda. Quando esse número é atingido, o acesso ao site fica cada vez mais lento, pois cada novo visitante “entra na fila” e precisa esperar que uma das instâncias do Apache fique livre, antes de conseguir carregar cada página.

Essa configuração default do Apache é adequada a um site de baixa demanda, onde o servidor passa a maior parte do tempo atendendo a um pequeno volume de requisições simultâneas, mas recebe picos de tráfego esporadicamente. Por padrão, o servidor carregará apenas 5 processos, manterá mais 5 a 10 spares ativos e poderá carregar mais instâncias conforme necessário, até o limite máximo de 150 instâncias permitidas.

Para um servidor dedicado, que hospede um site com muitas visitas, é interessante ajustar estes valores de acordo com a demanda. Uma forma fácil de verificar o status do servidor é ativar a diretiva “server-status” dentro do arquivo “/etc/apache2/apache2.conf”. Adicione as linhas abaixo no final do arquivo:

<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 200.234.23.233
# (onde o 200.234.23.233 é o IP de onde o relatório será acessado)
</Location>

Ative a configuração usando o comando “/etc/init.d/apache2 reload”. A partir daí, você pode ver um instantâneo do status do servidor acessando a pasta “server-status”, como em “http://www.gdhn.com.br/server-status“, a partir do navegador.

A oitava linha indica o número de instâncias abertas, como em:

8 requests currently being processed, 5 idle workers

Nesse exemplo temos 8 conexões abertas e 5 instâncias reservas do Apache abertas, prontas para receber novas conexões. A velocidade do acesso ao site está normal. Mas, o que acontece no caso de um pico de acesso, com mais do que 150 acessos simultâneos? Na configuração padrão você teria:

150 requests currently being processed, 0 idle workers

Ou seja, o Apache responde às primeiras 150 conexões e coloca as demais na fila, fazendo com que os visitantes precisem esperar até que algum dos processos abertos termine de atender o visitante anterior antes de servirem a requisição. Nesse ponto o acesso ao site começa a ficar lento, com as páginas demorando mais e mais para começarem a ser carregadas. Em casos mais extremos, o tempo de espera poderia ser tamanho que o site ficaria virtualmente fora do ar. É o que muitas vezes acontece com links publicados em sites muito acessados, como o slashdot.org.

Isso pode ser minimizado de duas formas. A primeira é aumentando o número de instâncias ativas do Apache (de forma que o servidor tenha instâncias suficientes para atender a todas as requisições sem precisar abrir novos processos) e aumentando o valor configurado na opção “MaxClients”, de forma que o servidor possa atender a um volume maior de requisições nos horários de pico.

Os valores ideais variam de acordo com o volume de memória disponível no servidor e a quantidade de memória usada por cada processo do Apache. Comece usando o comando “ps -ylC apache2 –sort:rss” (no Debian/Ubuntu) ou “ps -ylC httpd –sort:rss” (no Fedora/CentOS) para verificar o volume de memória usado por cada instância do Apache:

# ps -ylC apache2 –sort:rss

O comando exibe uma linha para cada processo do Apache ativo, de forma que a lista pode ser longa. O volume de memória gasto por cada um (em kbytes) é mostrado na oitava coluna. Descartando as primeiras e as últimas linhas, você tem uma boa aproximação dos valores médios, como em:

S 33 17530 16102 0 78 0 6008 5038 341548 ? 00:00:00 apache2
S 33 17491 16102 0 75 0 6036 5036 354540 ? 00:00:00 apache2
S 33 17529 16102 0 75 0 6036 5038 357283 ? 00:00:00 apache2
S 33 17472 16102 0 75 0 6044 5038 359161 ? 00:00:00 apache2
S 33 17438 16102 0 75 0 6056 5036 351130 ? 00:00:00 apache2

Veja que no exemplo cada processo consome aproximadamente 6 MB de memória RAM. Estes valores não devem ser levados ao pé da letra, pois o ps não leva em conta as áreas de memória compartilhadas entre os processos (como vimos no capítulo 1), de forma que na prática o consumo total é sempre um pouco mais baixo. De qualquer forma, estes são os melhores números que temos.

O próximo passo é verificar quanto os demais serviços ativos no servidor (MySQL, servidor de e-mails, etc.) consomem, de forma a ter uma estimativa de quanta memória está disponível para uso do Apache. Uma forma simples de fazer isso é desativar temporariamente o Apache (/etc/init.d/apache2 stop) e usar o comando “free” para ver a memória disponível, como em:

# free

total used free shared buffers cached
Mem: 127132 124640 2492 0 40732 45236
-/+ buffers/cache: 35804 91328
Swap: 409616 48 409568

A linha “Mem” mostra o total de memória usada, incluindo o cache de disco. Ela sempre mostra que quase toda a memória está ocupada, pois é normal que o sistema utilize a memória disponível para fazer cache de disco. O que realmente nos interessa é a segunda linha (-/+ buffers/cache), que no exemplo mostra que o servidor possui cerca de 90 MB de memória disponível (nesse exemplo estou usando um VPS com apenas 128 MB de memória, que serve como exemplo de servidor com poucos recursos).

Se cada processo do Apache ocupa cerca de 6 MB de memória, significa que o servidor poderia manter de 15 a 18 instâncias carregadas na memória (levando em conta que o consumo real é sempre um pouco inferior ao mostrado pelo ps) antes de começar a usar um volume significativo de memória swap. Uma boa configuração nesse caso seria:

# prefork MPM
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 18
MaxRequestsPerChild 0
</IfModule>

Permitir que o Apache abra mais instâncias acabaria sendo contra produtivo, pois o uso de muita memória swap derrubaria o desempenho do servidor, fazendo com que cada instância demorasse mais para processar cada página. Com isso, o número total de páginas servidas acabaria sendo menor do que usando apenas 18 processos.

No caso de um servidor com 1 GB de memória RAM, por outro lado, provavelmente teríamos 900 MB ou mais de memória disponível para o Apache, de forma que uma configuração mais adequada seria:

# prefork MPM
<IfModule mpm_prefork_module>
StartServers 25
MinSpareServers 25
MaxSpareServers 50
MaxClients 200
MaxRequestsPerChild 0
</IfModule>

Com isso, teríamos 25 processos “fixos” do Apache, complementados por mais 25 a 50 spares, número que pode crescer até um máximo de 200 processos simultâneos nos horários de pico. A partir daí, você poderia monitorar o volume de memória livre no servidor (através do comando “free”) e o volume de acessos através da página de estatísticas e ajustar as opções “StartServers” e “MinSpareServers” de acordo com o número médio de acessos simultâneos, de forma que o número de processos do Apache e de spares disponíveis seja sempre um pouco maior do que o número médio de conexões ao servidor:

Outras opções

A opção “MaxRequestsPerChild”, incluída logo depois no arquivo, limita o número de requisições que cada processo do Apache pode responder antes de ser encerrado e substituído por outro. Ela não tem um efeito direto sobre o desempenho, servindo apenas como uma proteção contra eventuais vazamentos de memória, que pudessem fazer o processo crescer até ocupar toda a memória do servidor. Uma boa configuração é o valor “1000″, que evita que os processos sejam fechados muito freqüentemente (o que prejudicaria o desempenho), mas ao mesmo tempo faz com que a opção atenda a seu propósito:

MaxRequestsPerChild 1000

Como de praxe, a solução definitiva para melhorar o desempenho do servidor, permitindo que ele atenda a mais requisições simultâneas, é instalar mais memória RAM, de forma que ele possa manter mais instâncias do Apache carregadas na memória e possa fazer mais cache de disco (reduzindo o volume de operações de leitura no HD). É importante monitorar constantemente o uso de memória do servidor e atualizar o servidor conforme necessário.

Outra opção que afeta negativamente o desempenho é a “HostNameLookups”, que faz com que o Apache verifique a origem de cada acesso, fazendo uma busca de domínio. Ativar essa opção permite criar estatísticas de acesso mais detalhadas, incluindo os países e provedores de acesso usados pelos visitantes, mas tem um impacto negativo muito grande na performance de um servidor congestionado. No Apache 2 ela já vem desativada por padrão, mas em versões antigas era necessário desativá-la manualmente:

HostNameLookups Off

Se você faz questão de gerar estatísticas de acesso detalhadas, pode obter o mesmo resultado usando o “logresolve”, um aplicativo que realiza as operações de resolução de nomes diretamente nos arquivos de log. Você pode criar um script para fazer com que ele seja executado uma vez por dia, por exemplo. A sintaxe do comando é a seguinte:

# logresolve -s access.stats -c < access.log > access_log.new

No exemplo, o “access.log” é o arquivo original de log, o “access_log.new” é o arquivo modificado que será gerado e o “access.stats” é o arquivo onde serão salvas as estatísticas.

Continuando, se o seu servidor já está operando no limite, recebendo mais requisições do que consegue atender nos horários de pico, uma foma simples de reduzir o carregamento do servidor é ajustar a opção “KeepAliveTimeout”, que determina o tempo que os processos do Apache devem aguardar por novas requisições do mesmo cliente antes de serem finalizadas.

A idéia por trás dessa opção é permitir que a mesma conexão TCP seja usada para enviar diversos arquivos, se possível toda a página que está sendo carregada, incluindo as imagens. Com isso, o tempo de carregamento é reduzido (já que não é mais necessário abrir uma nova conexão para cada elemento da página a ser carregado) e os processos do Apache ficam logo livres para responder a outras requisições.

O default são 15 segundos, o que é um valor seguro, já que mesmo as conexões mais lentas não chegam a ter um tempo de latência tão alto. O problema é que o tempo de espera faz com que os processos fiquem ativos na memória por até 15 segundos a mais do que realmente precisariam, consumindo memória e reduzindo o número de clientes simultâneos que o servidor pode atender.

Você pode aumentar de forma considerável o volume de requisições atendidas pelo servidor reduzindo o valor de 15 para 3 segundos. Um exemplo de configuração completa é:

KeepAlive On
MaxKeepAliveRequests 180
KeepAliveTimeout 3

A opção “KeepAlive On” deve estar presente, já que é ela a responsável por ativar o recurso. A opção “MaxKeepAliveRequests” determina o número máximo de conexões que devem ser mantidas ativas. Ela deve ser setada com um valor um pouco mais baixo que o da opção “MaxClients”, que vimos anteriormente.

Concluindo, você pode simular tráfego no seu servidor, verificando como ele se comporta com níveis variados de tráfego usando o comando “ab”, que faz parte do pacote “apache2-utils”. Chame-o indicando o número de requisições simultâneas e a página que será carregada, como em:

$ ab -n 1000 -c 20 http://www.meusite.com/teste.php

Nesse exemplo, estamos fazendo 1000 acessos à página, mantendo 20 requisições simultâneas. Se possível, lance o teste a partir de outro servidor com link rápido, ou peça para vários amigos rodarem o comando simultaneamente, cada um usando sua própria conexão. Isso transformará o teste em algo mais parecido com uma situação normal, onde o servidor receba um pico de acessos.

Uma opção que não tem a ver com o desempenho, mas que ajuda a reduzir o volume de ataques casuais contra o seu servidor é a opção “ServerTokens”. Na maioria das distribuições, ela vem configurada com o valor “Full”, que faz com que seu servidor disponibilize informações detalhadas sobre a versão do apache e os módulos utilizados, como “Apache/2.2.3 Debian PHP/5.2.0-8etch11″, o que facilita bastante o trabalho dos atacantes. Você pode evitar isso configurando a opção com o valor “Prod”, que faz com que o servidor responda apenas “Apache”, sem nenhum detalhe adicional (caso a linha não esteja presente, basta adicioná-la no final do arquivo):

ServerTokens Prod

Outra configuração importante é bloquear o acesso a includes e arquivos de configuração em geral colocados dentro dos diretórios de dados do site. Isso evitará que arquivos .inc, .tpl, .sql e de outras extensões tipicamente usadas em arquivos de configuração e em includes usados na montagem das páginas possam ser acessados diretamente pelos visitantes. Para isso, inclua na configuração uma seção “filesmatch”, especificando as extensões cuja exibição deve ser bloqueada, como em:

<filesmatch “\.(inc|tpl|h|ihtml|sql|ini|conf|bin|spd|sh|theme|module)$”>
Deny from all
</filesmatch>

Depois de terminar a edição do arquivo “/etc/apache2/apache2.conf”, não se esqueça de aplicar as alterações usando o comando:

# /etc/init.d/apache2 reload

ou:
# service httpd reload

Módulos do Apache e add-ons

Como comentei no início do capítulo, o principal ponto forte do Apache é o grande volume de módulos disponíveis para ele. Sempre que você precisa de algum recurso em especial, o primeiro passo é fazer uma pesquisa na web por algum módulo que desempenhe a função desejada. Se o recurso que precisa for uma necessidade comum, muito provavelmente você encontrará um módulo já pronto que se propõe a resolver o problema.

Como tanto o servidor Apache quanto a maior parte dos módulos disponíveis são open-source, existe também a possibilidade de modificar módulos já existentes, adicionando novas funções ou adaptando-os ao que precisa, ou mesmo desenvolver novos módulos do zero. Aqui vão alguns exemplos de módulos comumente usados, que você provavelmente vai querer manter ativos no servidor:

mod_rewrite

O mod_rewrite tem a função de reescrever URLs a partir de um conjunto de parâmetros especificado por você. O uso mais simples para ele é quando você muda o domínio de acesso do site e quer que todos os links sejam redirecionados para o novo endereço.

Imagine, por exemplo, que você migrou do http://dominio.provedor.com.br para http://www.dominio.com.br. Você poderia simplesmente criar um arquivo “index.php” no diretório raiz do antigo endereço com o seguinte conteúdo:

<?php
header(“HTTP/1.1 301 Moved Permanently”);
header(“location:http://www.dominio.com.br“);
exit;
?>

Este é um modelo simples de redirecionamento, que faz com que o servidor passe a encaminhar os acessos para o endereço especificado, usando o código 301, que indica que a página mudou permanentemente de endereço.

O problema é que fazendo isso o redirecionamento funcionaria apenas para os visitantes que acessassem a página principal do site. Um visitante que tentasse acessar o “http://dominio.provedor.com.br/produtos/index.php?id=312“, por exemplo, receberia um erro 404.

Usando o mod_rewrite, você poderia solucionar isso de forma muito simples. O primeiro passo é verificar se o módulo está carregado na configuração do Apache 2. No caso das distribuições derivadas do Debian, você pode ativá-lo usando o comando a2enmod:

# a2enmod rewrite

Muito provavelmente você receberá um “This module is already enabled!” como resposta, já que ele vem ativo por padrão na maioria das instalações. No caso do Fedora, CentOS e outras distribuições derivadas do Red Hat, verifique o arquivo “/etc/httpd/conf/httpd.conf” e, caso necessário, descomente as linhas:

LoadModule rewrite_module modules/mod_rewrite.so
AddModule mod_rewrite.c

Depois de checar a ativação do módulo, falta apenas a configuração, que é feita através do arquivo “.htaccess“, criado no diretório raiz do site antigo (ou seja, na pasta de arquivos do “http://dominio.provedor.com.br”). Embora o .htaccess seja geralmente associado com o uso de senhas, ele na verdade tem diversos outros usos, incluindo a configuração do mod_rewrite.

Para que o mod_rewrite passe a encaminhar todas as requisições automaticamente, o conteúdo do arquivo “.htaccess” seria:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule (.*) http://www.dominio.com.br/$1 [R=301,L]
</IfModule>

A linha “RewriteEngine On” é a responsável por encaminhar as requisições ao mod_rewrite, enquanto a linha “RewriteRule (.*) http://www.dominio.com.br/$1 [R=301,L]” explica o que deve ser feito.

Apesar de parecer estranha à primeira vista, ela segue na verdade uma lógica bastante simples. O “(.*)” cria uma regra de encaminhamento, que será aplicada a qualquer URL dentro do domínio. A página especificada pelo visitante ao acessar o site vira uma variável ($1), que é então usada no parâmetro seguinte, o “http://www.dominio.com.br/$1” onde é indicado o novo domínio do site.

Com isso, se o visitante tentar acessar o “http://dominio.provedor.com.br/produtos/index.php?id=312” do exemplo anterior, a variável “$1″ será carregada com o valor “produtos/index.php?id=312″ e ele será encaminhado ao “http://www.dominio.com.br/produtos/index.php?id=312“. O mesmo se aplica a qualquer outra URL que ele vier a tentar acessar.

Concluindo, o “[R=301,L]” é o código de retorno que será enviado ao cliente. No caso estamos usando o código 301, que é o código de redirecionamento permanente. Além de encaminhar os visitantes, ele faz com que o Google indexe a nova página e transfira o pagerank da página antiga para ela. Normalmente, a atualização do pagerank demora cerca de 3 meses, mas depois de feita a atualização o novo endereço deverá receber o mesmo pagerank do antigo.

Outro uso comum para o mod_rewrite é a simplificação dos links, transformando URLs de páginas dinâmicas, como, por exemplo, “http://www.dominio.com.br/produtos/index.php?id=312” em URLs mais simples, como “http://www.dominio.com.br/produtos/312/” ou “http://www.dominio.com.br/312.htm“

Nesse caso, criamos regras do rewrite que o orientam a detectar acessos à URL simplificada e encaminhar as requisições para a URL “real” de forma transparente, novamente através do uso de variáveis.

Para converter as URLs do formato “http://www.dominio.com.br/index.php?id=numero” para “http://www.dominio.com.br/numero/”, você usaria o seguinte modelo de arquivo .htaccess:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule (.*)/$ /index.php?id=$1
</IfModule>

Com isso, ao acessar o “http://www.dominio.com.br/512/“, por exemplo, o visitante veria a página “http://www.dominio.com.br/index.php?id=512“, o que mascara a complexidade da URL. Se você preferir que os links abreviados tenham a aparência de páginas com extensão .htm, em vez de pastas, o arquivo .htaccess ficaria:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule (.*)\.htm$ /index.php?id=$1
</IfModule>

A mesma regra pode ser aplicada também a pastas específicas. Se você quiser que ela se aplique apenas à pasta “produtos”, sem ser aplicada a outras pastas do servidor, por exemplo, você poderia usar uma regra como:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule /produtos/(.*)\.htm$ /produtos/index.php?id=$1
</IfModule>

É possível também usar diversos parâmetros simultaneamente, facilitando o acesso a URLs que incluam um grande volume de argumentos, como em “http://www.dominio.com.br/index.php?cat=produtos&cat=info&id=23“, desde que você consiga bolar um formato de URL que permita incluir todos os parâmetros necessários, como em:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule (.*)/(.*)/(.*)/$ /index.php?cat=$1&cat=$2&id=$3
</IfModule>

Com isso, os três parâmetros que precisam ser incluídos na URL são digitados pelo usuário na forma de uma sequência de subpastas, como em “http://www.dominio.com.br/produtos/info/23/” e o mod_rewrite converte automaticamente as URLs ao formato usado pelo servidor.

À primeira vista, pode parecer uma mera mudança cosmética, mas o uso das URLs amigáveis facilita bastante a navegação do visitante e pode ajudar até mesmo na indexação por parte dos mecanismos de busca.

mod_deflate

O mod_deflate permite comprimir de forma automática as páginas html (e também outros tipos de arquivos) enviados aos clientes, de forma a economizar banda e a reduzir o tempo de carregamento das páginas. Se os sites hospedados no servidor utilizam páginas com grandes volumes de texto, a redução pode ser bastante significativa.

O uso de compressão é negociado entre o servidor e o cliente no momento em que ele requisita a página, de forma que você não precisa se preocupar em excluir navegadores móveis ou clientes com browsers antigos. Ao perceber que o cliente não suporta o recurso, o servidor simplesmente envia a página sem compressão.

O uso do deflate aumenta sutilmente o uso de processamento no servidor, já que ele terá o trabalho de comprimir cada página solicitada antes de enviá-la ao cliente, mas isso é compensado pelo fato de o cliente demorar menos tempo para carregar cada página, o que permite que o servidor mantenha um número menor de instâncias do Apache carregadas na memória.

Do ponto de vista do cliente, o deflate é bastante benéfico, pois o texto das páginas carrega mais rápido. Uma página html comprimida pelo deflate fica com, tipicamente, um quarto do tamanho original. Com isso, uma página de 100 KB, que demoraria até 15 segundos para ser carregada por um cliente acessando via modem, passaria a ser carregada em apenas 3 ou 4 segundos. Depois disso, ainda teríamos o tempo de carregamento das imagens e de outros elementos da página, como de praxe, mas com o html carregado o cliente pode já ir adiantando a leitura.

Note que, as “páginas em html” que citei no parágrafo anterior, incluem também páginas dinâmicas em php e em outras linguagens, pois, de qualquer forma, depois de serem processadas pelo servidor, elas são enviadas ao cliente como uma página html.

Nas distribuições derivadas do Debian, o módulo é ativado usando o a2enmod:

# a2enmod deflate

Nas distribuições derivadas do Red Hat, verifique se a linha a seguir está presente dentro da seção “Dynamic Shared Object (DSO) Support” do arquivo “/etc/httpd/conf/httpd.conf“. Adicione-a manualmente caso necessário (não se esqueça de reiniciar o Apache para que a configuração entre em vigor):

LoadModule deflate_module modules/mod_deflate.so

Esta linha tem exatamente a mesma função desta outra, usada em algumas distribuições. A única diferença é que neste segundo exemplo é especificado o caminho completo até o arquivo: LoadModule deflate_module /usr/lib/apache2/modules/mod_deflate.so Em seguida, vem a configuração do módulo. No Debian, a configuração vai no arquivo “/etc/apache2/mods-available/deflate.conf“, enquanto do CentOS e no Fedora é usado o arquivo “/etc/httpd/conf.d/httpd-deflate.conf“.

Uma configuração simples, e bastante usada, é fazer com que o deflate comprima apenas arquivos em html, texto puro ou xml, sem tentar comprimir outros tipos de arquivos (como imagens ou arquivos diversos disponibilizados para download, que via de regra já estarão compactados). Esta configuração exige uma única linha e é a configuração padrão no Debian:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml
</IfModule>

Outra abordagem é orientar o deflate a comprimir todos os tipos de arquivos, com exceção das imagens em .gif, .png e .jpg. Isso pode ser interessante se, além das páginas html, você disponibiliza arquivos em formatos com baixos índices de compressão, como arquivos do MS Office, por exemplo. Nesse caso, a configuração ficaria:

<IfModule mod_deflate.c>
# Comprime tudo, com exceção de arquivos .gif, .jpg e .png:
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
</IfModule>

Note que esta configuração deve ser usada apenas em casos específicos, pois ela faz com que o servidor tente comprimir todo tipo de arquivos, incluindo arquivos em formatos já compactados, o que resultará em um grande aumento no uso de processamento, sem que haja uma redução tangível no tamanho dos arquivos.

Concluindo, uma recomendação geral é incluir exceções para versões antigas do Netscape 4 e do IE 3 que não são capazes de negociar a compressão de páginas com o servidor corretamente. Estes navegadores são extremamente raros hoje em dia, por isso mesmo os sites movimentados não recebem mais do que um punhado de visitas diárias de clientes utilizando um deles, mas não custa deixar o servidor preparado para atender a esses casos específicos. Para isso, são incluídas três linhas adicionais na configuração:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>

mod_cband

O mod_cband permite limitar o uso de banda ou o número de requisições simultâneas atendidas pelos sites hospedados no Apache. Como você pode imaginar, ele é extremamente popular em serviços de shared hosting, já que permite limitar o volume de banda utilizado por cada site (ou por cada usuário que acessa o servidor) e estabelecer quotas de tráfego.

Nas distribuições derivadas do Debian, ele pode ser instalado através do pacote “libapache2-mod-cband”, como em:

# apt-get install libapache2-mod-cband

Com o módulo instalado, use o comando a2enmod para ativá-lo:

# a2enmod cband

No CentOS, é necessário instalar o pacote a partir do código fonte. Comece instalando o pacote “httpd-devel” usando o yum:

# yum install httpd-devel

Em seguida, baixe a versão mais recente do pacote no: http://sourceforge.net/projects/cband/

Para instalar, descompacte o arquivo, acesse o diretório que será criado e rode os comandos “./configure”, “make” e “make install”, como em:

# tar -zxvf mod-cband-0.9.6.1.tgz
# cd mod-cband-0.9.6.1
# ./configure
# make
# make install

O script de instalação se encarrega de instalar o módulo na pasta “/usr/lib/httpd/modules/” e adicionar uma linha similar à linha a seguir no arquivo “/etc/httpd/conf/httpd.conf”, de forma que ele seja carregado:

LoadModule cband_module /usr/lib/httpd/modules/mod_cband.so

Falta agora apenas editar a configuração de cada virtual host, definindo os limites desejados, como em:

<VirtualHost *:80>
ServerAdmin joao@joao.com.br
ServerName www.joao.com.br
ServerAlias joao.com.br
DocumentRoot /var/www/joao
CBandSpeed 1024kbps 10 20
CBandRemoteSpeed 512kbps 5 3
</VirtualHost>

A opção “CBandSpeed” determina os limites para o tráfego total do site, especificando o volume máximo de banda que pode ser usado, o número máximo de requisições de páginas e/ou arquivos por segundo e o número máximo de instâncias do Apache que podem ser utilizadas. No exemplo, limitei o tráfego do site a 1024 kbps, com um máximo de 10 requisições por segundo e um máximo de 20 conexões simultâneas.

Em seguida, temos a opção “CBandremoteSpeed”, que permite definir limites individuais para os visitantes, impedindo que um único usuário monopolize toda a banda disponível (pense no caso de um site que disponibiliza arquivos para download, por exemplo). No exemplo, cada usuário ficará limitado a um máximo de 256 kbps, com até 3 requisições por segundo e um máximo de três conexões simultâneas.

Como acabamos de ativar o módulo, é necessário reiniciar o Apache para que as alterações entrem em vigor, mas, quando você for apenas alterar os limites posteriormente, pode usar o “reload” para atualizar a configuração sem derrubar o servidor.

# /etc/init.d/apache2 force-reload

A partir daí, você pode verificar a aplicação dos limites simplesmente baixando um arquivo disponível no site. A taxa de transferência vai variar ao longo do download, ficando um pouco acima ou um pouco abaixo do estabelecido, mas na média a transferência não ultrapassa a quota estabelecida:

Nesse primeiro exemplo, estabelecemos apenas um limite de uso de banda e um número máximo de requisições simultâneas, mas não estabelecemos nenhum limite de tráfego, de forma que o webmaster do site poderia utilizar quanta banda quisesse, ficando restrito apenas ao limite total de 1024 kbps, de forma similar a uma conexão doméstica.

Os 1024 kbps estabelecidos podem parecer pouco, mas se eles forem utilizados 24 horas por dia, 7 dias por semana (pense no caso de um site de downloads), o site consumirá no final do mês um tráfego total de pouco mais de 300 GB. Se o mesmo limite for aplicado a todos os sites hospedados, teremos uma situação onde o acesso por parte dos visitantes será relativamente lento (apenas 512 kbps por visitante) e que não impedirá que os sites que hospedem predominantemente arquivos consumam um volume considerável de banda.

Outra questão importante é que limitando as taxas de download de cada usuário, os downloads demorarão mais tempo, o que fará com que cada instância do Apache fique mais tempo atendendo ao mesmo cliente, aumentando o consumo de memória do servidor.

Devido a essas desvantagens, a restrição com base no uso de banda tem se tornado menos comum, dando lugar a quotas de tráfego. No novo modelo, o site pode consumir quanta banda precisar, desde que não ultrapasse uma determinada quota de tráfego mensal.

Para definir a quota de tráfego, o primeiro passo é criar uma pasta onde o cband armazenará informações sobre o tráfego usado por cada host. Você pode tanto criar uma pasta dentro do diretório do site e restringir o acesso a ela quanto criar uma pasta em outro diretório do sistema. O mais importante é que você ajuste as permissões de acesso, de forma que o dono seja o usuário usado pelo Apache (“www-data” no Debian, ou “apache” no CentOS), como em:

# mkdir /var/www/scoreboard
# chown www-data:www-data /var/www/scoreboard/

ou:
# mkdir -p /var/spool/cband/scoreboard
# chown apache:apache /var/spool/cband/scoreboard

Dentro desse diretório, criamos um arquivo vazio para cada site onde formos ativar o cband, novamente dando a posse para o usuário usado pelo Apache, como em:

# touch /var/www/scoreboard/joao
# chown www-data:www-data /var/www/scoreboard/joao

Em seguida, precisamos alterar a configuração dos sites (dentro da pasta “/etc/apache2/sites-available” ou dentro do arquivo “/etc/httpd/conf/httpd.conf”), especificando a nova configuração, como em:

<VirtualHost *:80>
ServerAdmin joao@joao.com.br
ServerName www.joao.com.br
ServerAlias joao.com.br
DocumentRoot /var/www/joao
CBandLimit 100G
CBandPeriod 4W
CBandScoreboard /var/www/scoreboard/joao
CBandExceededURL http://provedor.com/quota_excedida.htm
</VirtualHost>

Como você pode imaginar, a opção “CBandLimit” especifica a quota de tráfego do site, que no exemplo foi definida como 100 GB (além do “G” você pode especificar o volume em “M”, de megabytes ou “K”, de kbytes).

A linha seguinte, “CBandPeriod”, determina o período de aplicação da quota, depois do qual a contagem é zerada. No exemplo usei “4W”, que especifica um período de 4 semanas, ou seja, 28 dias. Você poderia usar outros valores, como por exemplo “30D” (30 dias) ou “24H” (24 horas).

Em seguida, temos a opção “CBandScoreboard”, que indica o arquivo onde serão armazenadas as informações sobre o uso de banda do site (que criamos no passo anterior) e a CBandExceededURL, que permite especificar uma página de erro, que será exibida aos visitantes dos sites que ultrapassarem a quota de tráfego. Esta página continua sendo exibida (deixando o site essencialmente fora do ar) até o início do próximo período, quando a contagem é zerada.

O uso da página de erro não é muito bem visto entre os webmasters, pois faz com que o site fique fora do ar, fazendo com que visitas sejam perdidas e que as páginas percam posições nos mecanismos de busca. Em vez de tirar as páginas do ar, você pode simplesmente reduzir a velocidade de acesso, substituindo a opção “CBandExceededURL” pela “CBandExceededSpeed”, como em:

<VirtualHost *:80>
ServerAdmin joao@joao.com.br
ServerName www.joao.com.br
ServerAlias joao.com.br
DocumentRoot /var/www/joao
CBandLimit 100G
CBandPeriod 4W
CBandScoreboard /var/www/scoreboard/joao
CBandExceededSpeed 256kbps 3 5
</VirtualHost>

Nesse caso, ao ultrapassar a quota o site ficará limitado a 256 kbits, com direito a três requisições por segundo e um máximo de cinco requisições simultâneas. Ou seja, continuará no ar, mas o acesso ficará bastante lento (você pode ajustar os limites de acordo com a situação). Em um serviço comercial, o ideal seria combinar a aplicação da quota com o envio de um e-mail de aviso, explicando que a quota foi excedida e oferecendo a possibilidade de migrar para um plano com uma quota maior.

É possível também combinar o uso da limitação de banda e de conexões simultâneas com o uso da quota mensal, evitando assim que os sites consumam a quota muito rapidamente, prejudicando o desempenho dos outros sites hospedados no servidor. Nesse caso, combinamos as opções que acabamos de ver com as opções CBandSpeed e CBandRemoteSpeed, como em:

CBandLimit 100G
CBandPeriod 4W
CBandScoreboard /var/www/scoreboard/joao
CBandExceededSpeed 256kbps 3 5

CBandSpeed 1024kbps 10 20
CBandRemoteSpeed 512kbps 5 3

Depois de definidas as quotas, você pode concluir a configuração ativando o relatório de tráfego oferecido pelo cband. O relatório é atualizado em tempo real, mostrando detalhes sobre o uso de banda e o percentual da quota já consumido, permitindo que o próprio webmaster do site acompanhe e administre o tráfego do site e não seja pego de surpresa quando a quota for ultrapassada.

O cband oferece dois painéis de administração separados, um feito para ser acessado pelos usuários (o cband-status-me) e outro para uso do administrador (cband-status), que permite ver o tráfego de todos os sites e resetar os contadores de tráfego manualmente.

Para disponibilizar o painel de usuário, você adicionaria a entrada a seguir dentro da configuração do virtual host, logo depois das demais linhas de configuração do cband, que inserimos anteriormente:

<Location /cband-status-me>
SetHandler cband-status-me
</Location>

Isso fará com que o painel fique disponível dentro da pasta “cband-status-me”, dentro da URL do site. Se quiser usar outra pasta, basta especificá-la na primeira linha, alterando o “Location /cband-status-me”:

Para ativar o painel de acesso administrativo, adicione as linhas a seguir no arquivo principal de configuração do Apache (o apache2.conf ou httpd.conf). Isso faz com que ele fique disponível dentro da pasta “cband-status” de cada site, sem que você precise repetir a configuração dentro da seção referente a cada um. Note que, diferente da configuração anterior, criamos uma restrição de acesso, que permite o acesso apenas a partir do seu próprio endereço IP (de forma que apenas você tenha acesso). Se você usa uma conexão com IP dinâmico, vai precisar lembrar de alterar a configuração antes de cada acesso:

<Location /cband-status>
SetHandler cband-status
Order deny,allow
Deny from all
allow from 201.86.208.237
</Location>

Assim como no exemplo anterior, o relatório pode ser acessado via navegador, acessando a pasta “cband-status” de qualquer um dos sites hospedados no servidor.

Uma observação importante é que, no Debian Etch, os painéis de acesso são ativados, por padrão, através da configuração incluída no arquivo “/etc/apache2/mods-available/cband.conf“:

<IfModule mod_cband.c>
<Location /cband-status>
SetHandler cband-status
</Location>
<Location /cband-stats>
SetHandler cband-status-me
</Location>
</IfModule>

Essa configuração essencialmente desativa a aplicação das quotas, pois permite que qualquer um acesse o relatório administrativo através do “http://site.com/cband-status” e resete o contador na hora em que quiser.

A menos que você queira virar motivo de piada entre os usuários, é necessário editar o arquivo, limitando o acesso à pasta cband-status apenas para seu próprio endereço IP, como em:

<IfModule mod_cband.c>
<Location /cband-status>
SetHandler cband-status
Order deny,allow
Deny from all
allow from 201.86.208.237
</Location>
<Location /cband-stats>
SetHandler cband-status-me
</Location>
</IfModule>

Depois de cada alteração, não se esqueça de atualizar a configuração do Apache para que ela entre em vigor:

# /etc/init.d/apache2 reload

Concluindo, se o objetivo for apenas proteger o servidor contra usuários armados com programas aceleradores de download (que abrem um número muito grande de conexões simultâneas, com o objetivo de tornar a transferência de arquivos mais rápida) ou com programas que tentam baixar todo o site para leitura offline, sem estabelecer quotas ou limites de tráfego, você pode usar uma configuração mais simples, usando apenas a opção “CBandremoteSpeed”. Ela pode ser incluída diretamente no arquivo principal de configuração do Apache, o que faz com que ela seja aplicada automaticamente para todos os sites hospedados.

No caso do Debian, você poderia incluí-la no final do arquivo “/etc/apache2/apache2.conf”, antes da linha “Include /etc/apache2/sites-enabled/”, que carrega a configuração dos virtual-hosts, como em:

CBandRemoteSpeed 1024kbps 3 2

# Include the virtual host configurations:
Include /etc/apache2/sites-enabled/

No exemplo, limitei os clientes a um máximo de três requisições por segundo e duas conexões simultâneas, uma configuração que é similar à usada em muitos sites de download.