Rompimento de cabo deixa assinantes da GVT sem acesso a sites internacionais

 Leitura Recomendada  Comentários desativados em Rompimento de cabo deixa assinantes da GVT sem acesso a sites internacionais
fev 262013
 

A semana não começou boa para a GVT. Desde a segunda-feira (25) clientes da empresa em diversas regiões do país estão encontrando dificuldades em acessar sites e servidores fora do Brasil. O problema parece estar, no entanto, fora da rede da GVT. Especificamente a rede das companhias Level 3 e Global Crossing, que fornecem serviço para a GVT, estão com alguma dificuldade nas suas redes dentro dos EUA. Em nota, a operadora afirma que regularizou a situação.

 

Rota até o serviço Rdio

Rota até o serviço Rdio

Um teste rápido usando ferramentas de rede mostrou que um traceroute para o serviço de streaming de música Rdio, que tem servidores nos EUA, atingiu 25% de perda de pacotes – algo alto para esse tipo de acesso. O mesmo aconteceu com o Twitter e Facebook, que atingiram respectivamente 25% e 33% de perdas em testes executados agora há pouco.

As rotas feitas pelos pacotes também não são nada animadoras: no lugar de chegar pelo cabo submarino em Miami, clientes da GVT estão tendo seu tráfego direcionado por terra – o que indicaria potenciais problemas nos cabos submarinos usados pela empresa. A lista de indisponibilidade de redes [caiu] também acusa problemas. Dentre as cidades afetadas estão São Paulo, Florianópolis, Porto Alegre, Santos, Olinda, Brasília, Maringá, Vitória e Belo Horizonte.

A GVT admitiu o problema em um comunicado enviado às 15h09. De acordo com a operadora, a falha ocorre devido a um rompimento de cabo na região de Santos (SP) decorrente de chuva forte e deslizamento de terra. “A transmissão de dados passou a ocorrer por rotas alternativas, existentes para minimizar o impacto em situações como esta, mas alguns clientes foram afetados.”

Clientes da empresa com dúvidas devem acessar o “Fale conosco” do site ou telefonar para 10325.

Atualizado às 15h44

MySQL Workbench no Slackware 14.0

 Clusterweb, Linux, Redes  Comentários desativados em MySQL Workbench no Slackware 14.0
fev 262013
 

Introdução

O MySQL Workbench é uma ferramenta visual unificada para arquitetos de banco de dados, desenvolvedores e DBAs. Ela oferece recursos para modelagem de dados, desenvolvimento de Scripts SQL, administração do servidor, entre outros.

Neste artigo, passarei um pouco da experiência e problemas que tive ao instalar e executar esta ferramenta no Slackware 14.0 (64 bits).

A instalação do MySQL Workbench no Slackware é totalmente manual, portanto, vamos ter que começar pelas suas dependências.

As dependências necessárias são:

  1. libsigc++-2.2.10;
  2. glibmm-2.32.1;
  3. cairomm-1.10.0;
  4. pangomm-2.28.4;
  5. atkmm-2.22.6;
  6. gtkmm-2.24.2;
  7. lua-5.1.5;
  8. ctemplate-2.2.

Todas as dependências acima foram baixadas do SlackBuilds, facilitando bastante o processo de instalação.

A instalação de um pacote do SlackBuilds é bastante simples, sendo necessário apenas baixar os scripts de instalação (SlackBuild) e o respectivo código fonte. Para exemplificar, vamos instalar, passo a passo, a primeira dependência da lista (libsigc++-2.2.10):

Passo 1: Baixar o SlackBuild “libsigc++.tar.gz” e o código fonte “libsigc++-2.2.10.tar.xz” em um diretório de sua preferência. No meu caso, os salvei em /usr/local/src.

Passo 2: Descompactar o pacote do SlackBuild:

# tar -zxvf libsigc++.tar.gz

Passo 3: Mover o código fonte do “libsigc++” para a pasta descompactada do SlackBuild:

# mv libsigc++-2.2.10.tar.xz libsigc++

Passo 4: Entrar na pasta do SlackBuild:

# cd libsigc++

Passo 5: Executar o script: “libsigc++.SlackBuild”

# ./libsigc++.SlackBuild

Ao final deste processo, o “libsigc++.SlackBuild” irá gerar um arquivo “.tgz” no diretório /tmp.

Passo 6: Entrar no diretório /tmp e instalar o pacote “.tgz” gerado:

# cd /tmp
# installpkg libsigc++-2.2.10-x86_64-1_SBo.tgz

* É importante ressaltar: O SlackBuild não resolve dependências, portanto, será necessário instalar as dependências na ordem nas quais foram colocadas acima, para evitarmos este tipo de problema.

Instalação do MySQL Workbench

Após instalar todas as dependências, vamos baixar e instalar o MySQL Workbench. Para baixá-lo, acesse:

Selecione a opção “Source Code” em “Select Platform”, e em seguida, a opção “Generic Linux“.

Salve o arquivo “mysql-workbench-gpl-5.2.46-src.tar.gz” em um diretório de sua preferência. No meu caso, o salvei em /usr/local/src.

A instalação do MySQL Workbench é muito simples, basta seguir o roteiro padrão (./configure, make, make install e make clean):

# tar -zxvf mysql-workbench-gpl-5.2.46-src.tar.gz
# cd mysql-workbench-gpl-5.2.46-src
# ./configure
# make

Neste momento, tive o primeiro problema ao compilar. Estava gerando um erro do tipo:

libtool: compile: cannot determine name of library object from `’: command not found

Caso você tenha este problema, basta executar o comando autoreconf e, em seguida, o comando de compilação novamente:

# autoreconf -fi
# make
# make install

O comando autoreconf -fi irá refazer todos os scripts de configuração, incluindo qualquer arquivo que esteja faltando no pacote.

Por padrão, o comando make install instala os pacotes de comando em /usr/local/bin, arquivos include em /usr/local/include etc.

Você poderá especificar outro local de instalação usando a opção –prefix=PREFIX na hora de executar o ./configure.

Por fim, para executar o MySQL Workbench:

# usr/local/bin/mysql-workbench

Com o MySQL Workbench aberto, selecione a opção “New Connection”, entre com o usuário e senha do MySQL e execute a opção “Test Connection”.

Aqui, tive um novo problema: Não conseguia estabelecer uma conexão SSH com o MySQL e no log do Workbench dizia que ele não conseguia importar o módulo paramiko.

Para resolver este problema, basta baixar e instalar os módulos “pycrypto-2.6” e “paramiko-1.7.7.1”, nesta ordem. Ambos podem ser baixados no SlackBuilds e instalados conforme orientação das dependências no começo deste artigo.

O “paramiko” é um módulo Python que implementa o protocolo SSH2 com o objetivo de garantir a segurança nas autenticações com máquinas remotas.

Observium – Monitoramento de Rede

 Clusterweb, Linux, Redes  Comentários desativados em Observium – Monitoramento de Rede
fev 262013
 

Observe sua rede com o Observium

Quando se fala em “sistema de monitoramento de rede open source”, um nome vem a cabeça: Cacti. É quase uma unanimidade, pela facilidade de utilização, por estar “empacotado” para as principais distribuições GNU/Linux, bastando um apt-get/yum install cacti e o sistema já está instalado. E também pela ampla documentação.

Há algum tempo atrás, por uma indicação de um colega da lista de discussão GTER, conheci o Observium e o tenho utilizado desde então, não como um substituto ao Cacti, mas sim como um complemento.

Sei que isso não é uma métrica muito confiável, mas fazendo uma busca pelo termo “cacti network monitoring” nos principais mecanismos de busca que temos hoje, os números são consideráveis.

Busca pelo termo “cacti network monitoring”:

  • Google: Aproximadamente 154.000 resultados;
  • Bing: Aproximadamente 104.000 resultados;
  • Yahoo: Aproximadamente 102.000 resultados.

Busca pelo termo “observium network monitoring”:

  • Goggle: Aproximadamente 8.460 resultados;
  • Bing: Aproximadamente 6.300 resultados;
  • Yahoo: Aproximadamente 6.320 resultados.

Em alguns sites do Brasil:

Este guia mostra como instalar o Observium no CentOS/RHEL/Scientific Linux.

Neste exemplo usei o CentOS 6.3 64 bits, mas para outras distribuições o processo é semelhante, pois a instalação do Observium é feita por SVN.

Repositórios

Para obter todos os módulos adicionais, é ideal ter os repositórios adicionais RPM Forge e EPEL:

# rpm –import http://apt.sw.be/RPM-GPG-KEY.dag.txt
# rpm -Uvh http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
# rpm -Uvh http://mirror.globo.com/epel/6/x86_64/epel-release-6-8.noarch.rpm

Pacotes:

# yum install httpd.x86_64 mysql-server.x86_64 mysql.x86_64 php-gd.x86_64 php-mcrypt php-mysql.x86_64 php-pear net-snmp.x86_64 php-pear.noarch php-snmp.x86_64 php.x86_64 fping.x86_64 graphviz.x86_64 ImageMagick.x86_64 jwhois.x86_64 net-snmp-utils.x86_64 nmap.x86_64 OpenIPMI-tools.x86_64 rrdtool.x86_64 subversion.x86_64 vixie-cron.x86_64

# pear install Net_IPv6
# pear install Net_IPv4

Instalação do Observium

Criar o diretório:

# mkdir -p /opt/observium && cd /opt

Checar a última versão no repositório do Subversion:

# svn co http://www.observium.org/svn/observer/trunk observium

Mudar para o diretório de instalação:

# cd /opt/observium

Base de Dados

Criar a base de dados e o usuário:

mysql> CREATE DATABASE observium;
mysql> GRANT ALL PRIVILEGES ON observium.* TO ‘observium’@’localhost’ IDENTIFIED BY ‘<Senhas>’;

Configuração

Copie o arquivo de configuração padrão e faça as alterações necessárias:

# cp config.php.default config.php

Adicione uma entrada para o fping:

$config[‘fping’] = “/usr/sbin/fping”;

Configure o schema da base de dados:

# php includes/sql-schema/update.php

Alguns erros devem aparecer, isso é normal. Mas se forem mais do que 6, revise sua configuração.

Crie os diretórios “graphs” e “rrd” (* Lembre-se: ainda estamos abaixo do diretório /opt/observium):

# mkdir graphs rrd
# chown apache.apache graphs rrd

Obs.: O sistema não aceita rodar como um diretório. Exemplo: http://www.dominio.com/observium

Adicionar o primeiro usuário (use o nível 10 para admin):

# cd /opt/observium
# ./adduser.php <username> <password> <level>

Adicione o primeiro dispositivo para ser monitorado:

# ./addhost.php <hostname> <community> v2c

Obs.: DEVE-SE, obrigatoriamente, ter um nome válido, seja por DNS ou pelo /etc/hosts.

Faça uma verificação inicial do novo dispositivo:
# ./discovery.php -h all
# ./poller.php -h all

Adicione na crontab (Ex.: /etc/cron.d/observium) o conteúdo abaixo:

33 */6  * * *   root    /opt/observium/discovery.php -h all >> /dev/null 2>&1
*/5 *  * * *    root   /opt/observium/discovery.php -h new >> /dev/null 2>&1
*/5 *  * * *    root   /opt/observium/poller.php -h all >> /dev/null 2>&1

Faça um reload/restart no serviço:

# /etc/init.d/crond reload/restart

O sistema já estará disponível em: http://<server ip>

Atualização

É utilizado o SVN para a atualização, bastando executar o comando abaixo:

# cd /opt/observium
# svn update
# ./discovery.php -h new

Billing e outras configurações

Billing

Uma função muito útil e interessante é o Billing, onde você pode contabilizar a utilização de uma ou mais portas.

Como podemos ver na imagem, pelo menos aqui, o Barrichello está na frente de do Schumacher e do Senna. 🙂

Para ativá-lo, altere a linha abaixo no “config.php”:

$config[‘enable_billing’] = 1;

E adicione as linhas abaixo no /etc/cron.d/observium:

*/5 *  * * *   root    /opt/observium/poll-billing.php >> /dev/null 2>&1
01 *  * * *   root    /opt/observium/billing-calculate.php >> /dev/null 2>&1

 

Desativar itens

Por padrão, quando você adiciona um dispositivo, ele traz todas as configurações de rede.

Num servidor Windows, que eu usei como exemplo para montar este tutorial, ele acaba trazendo uma série de interfaces que não precisam ser vistas, o que num primeiro momento pode deixar o visual um pouco poluído, ao contrário do Cacti, que você precisa especificar o quer que seja monitorado.

Na imagem abaixo podemos ver o Item Ports com todos os itens habilitados:

Para desativar estes itens, siga os passos abaixo ao acessar a interface WEB:

Devices → All Devices → *NomeDoServidor* → Edit (a chave que fica bem escondida bem à direita) → Ports

Nas colunas “Polling” e “Alerts”, deixe todos os itens no “No”, com exceção da placa de rede que você quer monitorar.

Na mesma tela no item “Modules”, estão todos os módulos que, por padrão, vem todos ativados:

Redirecionar todo tráfego HTTP para HTTPS

Pode parecer óbvio, mas tenho por padrão não usar HTTP para qualquer serviço WEB, somente HTTPS.

Para isso, redireciono todo o tráfego alterando os arquivos abaixo:

1. /etc/httpd/conf/httpd.conf:

NameVirtualHost *:80

<VirtualHost *:80>

RewriteEngine    on
RewriteCond      %{SERVER_PORT} ^80$
RewriteRule       ^(.*)$ https://%{SERVER_NAME}$1 [L,R]

</VirtualHost>

2. /etc/httpd/conf.d/ssl.conf (arquivo padrão do SSL):

LoadModule ssl_module modules/mod_ssl.so

Listen 443

SSLPassPhraseDialog builtin

SSLSessionCache   shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout  300
NameVirtualHost *:443

SSLMutex default

SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin

SSLCryptoDevice builtin

<VirtualHost *:443>

ServerName wiki.domain.net:443
ServerAlias wiki.domain.com:443

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

SSLEngine on

SSLProtocol all -SSLv2

SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

SSLCertificateFile /etc/pki/tls/certs/localhost.crt

SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

<Files ~ “\.(cgi|shtml|phtml|php3?)$”>
SSLOptions +StdEnvVars
</Files>
<Directory “/home/viaza132/www/cgi-bin”>
SSLOptions +StdEnvVars
</Directory>

SetEnvIf User-Agent “.*MSIE.*” \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

CustomLog logs/ssl_request_log \
“%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \”%r\” %b”

</VirtualHost>

3. /etc/httpd/conf.d/ssl-observium.conf (este arquivo não existe, deve ser criado):

<VirtualHost *:443>

ServerName observium.domain.net:443
ServerAlias observium.domain.com:443

DocumentRoot “/opt/observium/html”

<Directory /opt/observium/html/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
AuthUserFile /home/viaza132/www/.htpasswd
AuthName “Please enter your ID and password”
AuthType Basic
require valid-user
Order allow,deny
Allow from all
</Directory>

ErrorLog logs/ssl-observium_error_log
TransferLog logs/ssl-observium_access_log
LogLevel warn

SSLEngine on

SSLProtocol all -SSLv2

SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

SSLCertificateFile /etc/pki/tls/certs/localhost.crt

SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

<Files ~ “\.(cgi|shtml|phtml|php3?)$”>
SSLOptions +StdEnvVars
</Files>
<Directory “/home/viaza132/www/cgi-bin”>
SSLOptions +StdEnvVars
</Directory>

SetEnvIf User-Agent “.*MSIE.*” \     nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

CustomLog logs/ssl_request_log \
“%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \”%r\” %b”

</VirtualHost>

Além de tudo, proteger o acesso com senha:

# htpasswd /home/viaza132/www/.htpasswd admin

Tela dos dispositivos configurados com algumas informações básicas:

Tela de status dos dispositivos:

Algumas outras checagens que ele faz por padrão (Memory, CPU e Disk Usage):

UltraSurf – Bloqueio definitivo

 Clusterweb, Firewall, Leitura Recomendada, Linux, Redes  Comentários desativados em UltraSurf – Bloqueio definitivo
fev 252013
 
Introdução

Que tal passar horas planejando e configurando o controle de acesso a conteúdo de uma rede, ir dormir feliz da vida com o gostinho do dever cumprido e acordar no dia seguinte, com o pesadelo de saber que foi tudo em vão, pois os usuários estão acessando o conteúdo bloqueado normalmente?

O objetivo aqui não é entrar na discussão se o controle de acesso a conteúdo deve ou não ser realizado na navegação WEB de uma empresa, instituições de ensino, residências ou onde quer se seja.

O fato é que, se por algum motivo, determinado conteúdo teve que ser bloqueado ou monitorado, este deve ser bloqueado, ou monitorado, de forma que os usuários da rede não consigam burlar tais controles. Sendo necessário assim, prever e tratar todos os possíveis desvios que, eventualmente, os usuários tentem utilizar para burlar os controles estipulados.

Muitas são as técnicas que os usuários de uma rede de computadores acabam recorrendo na tentativa, em geral com sucesso, de burlar os controles impostos. Entre essas técnicas, podemos citar como exemplo:

  • https;
  • tunneling;
  • socks;
  • proxy anônimo;
  • webproxy;
  • ferramentas como HotSpot Shield, HideIpPlatinum, JAP ou o implacável UltraSurf.

Sendo o UltraSurf, atualmente, a grande dor de cabeça de muitos administradores de redes, e o grande motivador deste trabalho.

O foco aqui não é detalhar o comportamento ou uso de todas as técnicas ou ferramentas acima citadas, afinal, facilmente você encontra este conteúdo na Internet.

Aqui vamos bater de frente com o grande vilão da vez, o UltraSurf, indo na sequência vendo os meios utilizados, já com sucesso, para banir em definitivo, esta e todas as técnicas e ferramentas citadas da rede.

UltraSurf – Problemas comuns

Pense, se existisse um aplicativo executável, não instalável, com menos de 1.4 MB, que ao ser executado, por exemplo de um pendrive, passasse dando ‘risada’ pelos bloqueios de conteúdo configurados em sua rede, sem sequer deixar rastros, ou então te dar tchau!

Pois é, esse aplicativo já existe, e se chama UltraSurf!

O UltraSurf, desenvolvido pela empresa UltraReach, foi desenvolvido para burlar qualquer bloqueio de conteúdo configurado na rede.

Ao ser executado, conecta-se com seus servidores e cria uma espécie de proxy local na máquina do usuário, saindo toda a navegação realizada pelo usuário por esse proxy local, passando assim, por cima de qualquer controle de conteúdo imposto.

Ao rodar o UltraSurf, ele inicia sua busca incansável por uma brecha no firewall, por onde possa passar e estabelecer a conexão com seus servidores externos. Inicialmente, tenta estabelecer a conexão via porta 443 em um dos endereços IP de seus infinitos servidores, não conseguindo via porta 443, passa a tentar a conexão em uma série de outras portas, e incansavelmente, segue esta rotina de ir trocando porta e IP, até conseguir estabelecer a conexão.

Confesso aqui, que chega a ser divertido ficar monitorando todo esse processo via tcpdump.

Caso não tenha êxito na conexão padrão, vamos imaginar que você já tenha realizado bloqueios que o impediram de conectar, o usuário vai ao UltraSurf e facilmente configura o IP e porta de um servidor proxy, que pode ser o próprio proxy da sua rede, ou então um externo, conseguindo dessa forma, fazer a conexão com um de seus servidores por dentro do proxy informado.

Aproveito, e deixo aqui meus parabéns à equipe por trás desta respeitável ferramenta!

Problemas comuns na tentativa do bloqueio

Na busca por meios de bloqueio do UltraSurf na Internet, é comum cair em alternativas que sugerem bloquear uma relação interminável de endereços IP, tidos como sendo os servidores utilizados para conexão, bloquear a porta 443, liberando esta somente para os IPs necessários para uso na rede, utilizar o Snort etc…

Sendo comum ver nos comentários dos posts, coisas do tipo: “comigo funcionou perfeitamente!”, “testando com a versão X funciona, mas com a Y não”, “comigo continua acessando normalmente”, “rodo o UltraSurf e o Snort não detecta que ele está rodando”.

Isto se deve ao fato de que a cada nova versão lançada do UltraSurf, novas faixas de IP e portas são utilizadas, o padrão de conexão é redefinido, anulando assim, todos os bloqueios antes configurados, tornando a tentativa de bloqueio do UltraSurf, por este paradigma, totalmente impraticável, trabalhosa e ineficaz.

Como podemos observar na descrição do comportamento do UltraSurf, é comum que técnicas e ferramentas utilizadas para burlar os controles de uma rede façam uso de comportamentos e portas de uso padrão e necessário em uma rede, conseguindo com isso, dificultar bastante as tentativas de bloqueio.

A solução

A solução aqui demostrada foi estudada, configurada, colocada em produção e amplamente testada na rede acadêmica do Senac Lages/SC, onde o objetivo principal foi possibilitar aos alunos do Curso Técnico em Redes de Computadores, turma que se forma no final do primeiro semestre de 2012, a possibilidade de vivenciar problemas reais de campo, possibilitando desta forma, uma construção significativa do conhecimento, e deixando-os preparados para a cruel realidade do mundo do trabalho.

Para resolver o problema, entrou na ‘jogada’ o Mutley, servidor rodando FreeBSD que fornece com exclusividade para toda a rede acadêmica, os serviços: DHCP, DNS, Gateway e Proxy.

O bloqueio do UltraSurf e das outras técnicas relacionadas é relativamente simples, bastando ter as portas corretas fechadas no firewall e o uso de um proxy não transparente.

Na sequência, veremos a estrutura/características do servidor Mutley, as regras aplicadas e as implicações que cada ação reflete.

Estrutura/Características do servidor Mutley

FreeBSD 9 configurado como gateway da rede disponibilizando os seguintes serviços:

  • DHCP
  • DNS
  • PROXY
  • FIREWALL

PF utilizado como firewall, configurado dentro do conceito de politicas Default Deny, onde somente são abertas as portas que realmente são utilizadas na rede.

Portas SSH, 80, 53 e 3128 abertas somente para acesso ao próprio servidor, porta 443 fechada para qualquer uso.

Com isso, já evitamos que seja possível utilizar técnicas de tunneling, socks, proxy anônimo, além de já impedir que o UltraSurf e similares consigam conectar.

Exemplo da regra no PF

# permite às máquinas da redeLan, acessar as portas listadas somente via ipLan
pass in quick on $intLan proto { tcp, udp } from $redeLan to $ipLan port { 53, 80, 3128, 22 } keep state

Squid configurado como proxy NÃO transparente, onde toda navegação, sem exceção, de http, https e ftp, somente será permitida via proxy, estando as respectivas portas devidamente fechadas no firewall.

O Dquid tem sua configuração padrão e dentro da sua necessidade, a única coisa adicionada se deu ao fato de que ferramentas como UltraSurf permitem que seja configurado o endereço de proxy da rede, conseguindo desta forma, funcionar por dentro do proxy mesmo.

Para impedir que isso aconteça, foi criada uma ACL para não permitir a navegação direta por IP.

Exemplo da ACL

# acl para não permitir nagevacao por IP
acl naoIP dstdom_regex -i ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}($|:.+|/))
http_access deny CONNECT naoIP

Revisando a solução

  • Firewall configurado dentro dos padrões de Default Deny;
  • Liberar somente as portas necessárias para funcionamento da rede;
  • Portas SSH, 80, 53 e 3128 liberadas exclusivamente para acesso ao IP da LAN do servidor;
  • Proxy não transparente, atuando como saída exclusiva de HTTP, HTTPS e FTP;
  • Bloqueio no proxy de navegação por IP.

Com estes passos simples, conseguimos com mínimo esforço, eliminar por completo o uso do UltraSurf e das ferramentas, ou técnicas, mencionadas para burlar os controles de conteúdo da rede.

Toda ação, gera uma reação

Claro que toda ação gera um reação, e com o Mutley rodando a todo vapor e os bloqueios funcionando perfeitamente, acabaram surgindo alguns pontos, já devidamente resolvidos, que mereceram um pouco mais de estudo.

Seguem abaixo os problemas detectados e as soluções já implementadas para resolvê-los.

Problemas detectados com a aplicação do Mutley na rede:

Como está sendo utilizado proxy NÃO transparente, há a necessidade de configurar o endereço do proxy nos navegadores para poder navegar, o que pode ser considerado um problema para alguns usuários.

Solução: Para resolver isso, foi implementado no Mutley, a solução de configuração automática de proxy, WPAD.

O WPAD permite que os navegadores, rodando em máquinas Windows, consigam obter, de forma 100% automática, a configuração de proxy da rede via DHCP ou DNS.

Como a base de funcionamento da nossa rede é Windows, com a implantação do WPAD, já ficou resolvido o problema da configuração de proxy nos navegadores.

Nos clientes não-Windows, como por exemplo GNU/Linux, se faz necessária a configuração manual do proxy no navegador.

* A configuração de proxy foi automatizada via WPAD para os navegadores, mas temos uma serie de aplicações que usam as portas 80, HTTPS ou FTP, e que não permitem configuração de proxy automática ou manual em suas interfaces. O Windows Update é um desses casos.

Solução: Para resolver este problema, foram utilizados aplicativos do próprio Windows (proxycfg, netsh winhttp set proxy) para realizar a configuração do proxy a nível de sistema operacional.

Criada uma ACL para liberar a navegação por IP para casos específicos, por exemplo, a realização de FTP.

Exemplo:

# acl para permitir navegacao por ip para ftp
acl ftpporip url_regex ftp://[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*
http_access allow ftpporip

Considerações finais

É isso pessoal, espero que as dicas aqui passadas possam ser úteis.

Reforço que a solução aqui proposta já se encontra em uso a mais de um ano!

Servidor de e-mails vinculado ao AD (Postfix + Courier)

 Clusterweb, Linux, Redes, Servidor de E-mail  Comentários desativados em Servidor de e-mails vinculado ao AD (Postfix + Courier)
fev 252013
 
Cenário

Apresento aqui um exemplo do cenário que encontrei quando houve a solicitação da criação do servidor de e-mail:

Servidor 1:

  • Windows 2003 ou 2008
  • Controlador de Domínio (AD)
  • Servidor DNS
  • Host: wolverine
  • IP: 192.168.1.203
  • Domínio: www.xmen.com.br

Obs.: não entrarei em detalhes da instalação do Windows ou AD.

Servidor 2:

  • Debian Squeeze
  • Instalação dos pacotes básicos
  • host: storm
  • IP: 192.168.1.200

Obs.: não entrarei em detalhes da instalação do Debian.

Instalação do Samba + Kerberos

O primeiro passo da preparação do servidor de e-mail é a instalação do Samba + Kerberos. E com estes pacotes teremos acesso aos usuários e grupos do AD.

Os pacotes necessários, são:

  • krb5-user;
  • samba;
  • samba-common;
  • winbind;
  • ntpdate.

Então, para a instalação executamos o seguinte comando:

# aptitude install krb5-user samba samba-common winbind ntpdate

Todos os pacotes serão automaticamente instalados e devemos, neste passo, selecionar a opção recomendada pelo instalador, caso seja solicitado.

Após a instalação iniciaremos as configurações, começando pelo arquivo /etc/hosts, onde faremos a indicação dos endereços de algumas máquinas importantes na nossa rede.

Execute e comando:

# vi /etc/hosts

Adicione as linhas abaixo ao final do arquivo:

192.168.1.203  wolverine.xmen.com.br  wolverine
192.168.1.200  storm.xmen.com.br        storm

Seguindo as configurações editaremos o arquivo /etc/resolv.conf. Nele, indicaremos qual será o nosso servidor DNS (o mesmo servidor do AD).

Vamos editar o arquivo “resolv.conf” com os dados do domínio e o DNS do AD. Execute e comando:

# vi /etc/resolv.conf

Substitua todo o conteúdo do arquivo pelas linhas abaixo (lembrando de substituir os nomes para sua realidade):

domain xmen.com.br
search xmen.com.br
nameserver 192.168.1.203

Configuração do Kerberos

Kerberos é o protocolo que faz com que as informações trafeguem com segurança pela rede. Ele requer uma configuração específica para o servidor que controla o domínio.

Vamos editar o arquivo /etc/krb5.conf com os dados da nossa rede. O que está em maiúsculo deve permanecer em maiúsculo.

Execute e comando:

# vi /etc/krb5.conf

Substitua todo o conteúdo do arquivo pelas linhas abaixo (lembrando de substituir os nomes para sua realidade):

[libdefaults]
default_realm = XMEN.COM.BR
dns_lookup_realm= true
dns_lookup_kdc= true
ticket_lifetime= 24h
forwardable= yes

krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true

v4_instance_resolve = false
v4_name_convert = {
host = {
rcmd = host
ftp = ftp
}
plain = {
something = something-else
}
}
fcc-mit-ticketflags = true

[realms]
XMEN.COM.BR= {
kdc= wolverine.xmen.com.br
admin_server= wolverine.xmen.com.br
default_domain= XMEN.COM.BR
kpasswd_server= XMEN.COM.BR
}

[domain_realm]
.xmen.com.br= XMEN.COM.BR
xmen.com.br= XMEN.COM.BR

[login]
krb4_convert = true
krb4_get_tickets = false

#Fim do arquivo

Agora testaremos as configurações e a comunicação segura com o AD. Execute e comando:

# kinit administrator@XMEN.COM.BR

Se o seu Windows está em pt_BR, provavelmente você deverá usar: administrador@XMEN.COM.BR.

Será solicitada a senha do usuário indicado do AD, não deverá aparecer qualquer erro.

Configuração do Samba + Ingresso no domínio

Nesta etapa vamos fazer a configuração do Samba, onde poderemos, além de usarmos os usuários do AD, compartilhar diretórios diretamente da máquina GNU/Linux.

Para configurar o Samba editaremos o arquivo /etc/samba/smb.conf. Arquivo onde, posteriormente, poderemos configurar outras funções de compartilhamentos.

Execute e comando:

# vi /etc/samba/smb.conf

Substitua todo o conteúdo do arquivo pelas linhas abaixo (lembrando de substituir os nomes para sua realidade):

[global]
#Domínio no qual o servidor fará parte
workgroup = XMEN
#Nome que o servidor será visto quando visualizada a rede
server string = Servidor Emails
#Nome NetBIOS do servidor (hostname)
netbios name = storm
#Domínio para login
realm = XMEN.COM.BR
#Arquivo onde será gerado o log do Samba
log file = /var/log/samba/%m.log
#Nível do log
os level = 20
#Tamanho máximo do arquivo de log
max log size = 50
#Nível do debug
debug level = 1
#Tipo de segurança de autenticação
security = ADS
encrypt passwords = yes
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
unix charset = UTF-8
password server = *
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yes

#Faixa de IDs dos grupos do AD
idmap uid = 10000-20000
#Faixa de IDs dos usuários do AD
idmap gid = 10000-20000
#Diretório padrão dos usuários do AD
template homedir = /home/%U
#bash padrão dos usuários do AD
template shell = /bin/bash
winbind use default domain = yes

#Fim do arquivo

Agora configuraremos o sistema para que ele solicite as senhas dos usuários também no servidor AD. Então editamos o arquivo /etc/nsswitch.conf com o parâmetro necessário.

Execute e comando:

# vi /etc/nsswitch.conf

Substitua o conteúdo das linhas abaixo:

passwd: compat
group: compat
shadow: compat

Pelo seguinte conteúdo:

passwd: compat winbind
group: compat winbind
shadow: compat winbind

Com todas as configurações feitas, podemos fazer o ingresso do servidor de e-mails como um cliente do nosso domínio Windows.

Para ingressar no domínio, execute o comando:

# net ads join -U administrator

Obs.: Se o seu Windows está em pt_BR, provavelmente você devera usar “administrador”.

Será solicitada a senha do administrador e a máquina será adicionada ao domínio.

Para concluir as configurações é necessário a reinicialização dos serviços Samba e Winbind. Execute os comandos:

# /etc/init.d/samba restart
# /etc/init.d/winbind restart

Para verificarmos a comunicação de todos os serviços devemos executar os seguintes comandos:

1. Mostra que o terminal está devidamente configurado no servidor:

# net ads testjoin

2. Mostra que a comunicação com o servidor está OK:

# wbinfo -t

3. Lista os usuários do AD:

# wbinfo -u

4. Lista os grupos do AD:

# wbinfo -g

5. Lista todos os usuários do sistema (GNU/Linux + AD):

# getent passwd

6. Lista todos os grupos do sistema (GNU/Linux + AD):

# getent group

Instalação e configuração do Postfix + Courier

Postfix é um agente de transferência de e-mails (MTA) prático, seguro e fácil de administrar. Será o principal serviço do nosso servidor GNU/Linux.

Para instalar o Postfix execute o comando:

# aptitude install postfix postfix-doc

Obs.: Na instalação será questionado qual o tipo do servidor. Deve ser selecionada a opção: “Servidor de Internet”

A configuração desse serviço é bem simples, basta editarmos o arquivo /etc/postfix/main.cf. Execute o comando:

# vi /etc/postfix/main.cf

Substitua todo o conteúdo do arquivo pelas linhas abaixo (lembrando de substituir os nomes para sua realidade):

#Especifique seu domínio
mydomain = xmen.com.br
#hostname do servidor de e-mails
myhostname = storm.$mydomain
#Domínio remetente do e-mail
myorigin = $mydomain
#Domínios que esse servidor vai receber como destinatário
mydestination = $myhostname, $mydomain
#Especifique aqui a sua rede
mynetworks = 127.0.0.0/8 192.168.1.0/24
#Diretório destino da mensagem dentro do diretório de cada usuário
home_mailbox = Maildir/

#Fim do arquivo

Depois de salvo o arquivo, faremos um reload no serviço do Postfix para que ele assuma as novas configurações. Execute o comando:

# postfix reload

Em seguida usamos uma ferramenta do próprio Postfix para verificar a integridade das configurações. Execute o comando:

# postfix check

O retorno desse comando deve ser vazio!

Nesse ponto já podemos fazer um teste do funcionamento do Postfix. Para isso usaremos o comando mail. Execute o comando:

# echo “Teste de funcionamento do POSTFIX” | mail -s “Criação de Conta” root

Verifique no diretório /root se foi criado o diretório Maildir. Dentro do novo diretório deve existir a mensagem no diretório new, até que ela seja lida.

Finalização

Para acessarmos a caixa de mensagens de cada um dos usuários usaremos o Courier, mais especificamente o pacote IMAP, já que esse tipo de comunicação já mantém os arquivos no servidor criando um repositório em uma única máquina.

Para instalar o Courier execute o comando:

# aptitude install courier-authdaemon courier-imap

Script de criação do diretório Maildir

Nesse ponto já temos funcionando os serviços de transmissão e entrega de e-mails aos usuários. Mas esses e-mails serão entregues no diretório padrão de cada usuário, que no caso dos usuários do AD, configuramos como /home/$user lá no “smb.conf”.

Acontece que estes diretórios não são criados automaticamente, como na criação de um usuário no próprio GNU/Linux. Então criei um script que vai listar os usuários novos na base do AD e criar os diretórios para estes novos usuários.

Para executarmos o script, criaremos o seguinte diretório: /usersdominio. Execute o comando:

# mkdir /usersdominio

Crie o script. Execute o comando:

# vi /usersdominio/criacontas.sh

Acrescente o seguinte conteúdo:

#!/bin/bash
/etc/init.d/winbind restart

#### Lista as contas que ja existem e ordena
ls /home > /usersdominio/existentes.txt
sort /usersdominio/existentes.txt > /usersdominio/existentes_alf.txt

#### Lista as contas do AD e compara definindo as novas
wbinfo -u | grep -v ‘\$’ | sort > /usersdominio/noAD.txt
comm -13 /usersdominio/existentes_alf.txt /usersdominio/noAD.txt > /usersdominio/novos.txt

#### Rotina para criacao dos diretorios e MAILDIR

for usuario in `cat /usersdominio/novos.txt`
do
mkdir /home/$usuario
chown -R $usuario /home/$usuario
echo “Bem Vindo a sua nova Caixa Postal” | mail -s “Criação de Conta” $usuario
done

#### Deleta a lista dos novos
rm -f /usersdominio/novos.txt

#Fim do arquivo

Agora vamos deixá-lo executável. Execute o comando:

# chmod +x /usersdominio/criacontas.sh

Se quiser é possível agendar para que o script rode a cada período deixando a criação mais automática.

Agora basta configurar a conta no seu leitor de e-mail preferido ou instalar um Webmail (que poderá ser tema de um outro artigo).

* Lembrando: para a autenticação das contas usamos os usuários e senhas do AD.

DHCP com controle de IP e compartilhamento no Debian Squeeze

 Clusterweb, Linux  Comentários desativados em DHCP com controle de IP e compartilhamento no Debian Squeeze
fev 252013
 
Introdução

Você deverá ter duas placas de rede instaladas no computador, que será o servidor DHCP.

Todo servidor deve ser configurado para iniciar automaticamente em caso de queda de energia. A configuração deve ser feita acessando-se o Setup do CMOS (o popular BIOS) da placa-mãe.

Geralmente, essa configuração está na aba “Power” ou “Energy” ou “Advanced” ou similar. A opção a ser configurada, geralmente, aparece como “Restore on AC Power Loss” ou similar.

Esta opção deve ser colocada como “Power on”. Isto fará com que a máquina seja reiniciada automaticamente. Com essa opção ligada (Power on), a placa-mãe detectará o retorno da energia e ligará a máquina automaticamente colocando o servidor em funcionamento.

1. Instalar o pacote DHCP como root:

# aptitude safe-upgrade
# apt-get update
# aptitude install isc-dhcp-server

Aguarde terminar a instalação. Deverá dar falha: “failed”, em vermelho – Isso é normal, uma vez que ainda não configuramos o DHCP.

Antes do próximo passo, você já deverá ter sua subnet (subrede) planejada com seus endereços IPs. O IP da placa de rede que irá servir o DHCP será também, automaticamente, o IP do gateway/compartilhamento da nossa configuração (no caso, a eth0).

Tecnicamente falando, quando fazemos o compartilhamento, não estamos transformando o GNU/Linux em um roteador, somente estamos compartilhando os dados de entrada de uma interface de rede com a(s) outra(s).

2. Configure os endereços IPs das placas de rede:

# vim /etc/network/interfaces

Não mexa nas linhas iniciais do arquivo. As configurações abaixo das linhas iniciais devem ficar como está abaixo.

* Lembrando que a placa de rede Onboard nem sempre é a eth0 e a Offboard nem sempre é a eth1.

O arquivo abaixo é somente o exemplo da nossa configuração:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The looback network interface
auto lo
iface lo inet loopback

# Primeira interface de rede – offboard
auto eth0
allow-hotplug   eth0
iface  eth0  inet  static
address  192.168.2.1
netmask  255.255.255.0
broadcast  192.168.2.255

# Segunda interface de rede – onboard
auto eth1
allow-hotplug  eth1
iface  eth1  inet  dhcp

Salve e saia do arquivo.

Os números de IPs devem estar de acordo com o arquivo /etc/dhcp/dhcpd.conf, que você mesmo irá configurar mais adiante.

A placa de rede que recebe a Internet é a eth1. Deixei ela com IP dinâmico. Caso queira fixar o IP da placa que recebe a Internet, no caso a eth1, ela deverá ter como gateway, o IP do roteador ADSL ou do roteador da rede.

* Lembrando que, no arquivo /etc/network/interfaces, você deve acrescentar todas as placas de rede que estiverem instaladas na máquina: eth0, eth1, eth2 e assim por diante.

3. Verifique também o arquivo /etc/resolv.conf, que deverá estar com um ou dois DNSs adicionados.

Exemplo:

# vim /etc/resolv.conf

Dentro do arquivo deverá ter:

domain xxxxxxxxxxxx
search xxxxxxxxxxxxx
nameserver xxx.xxx.xxx.xxx
nameserver xxx.xxx.xxx.xxx

Onde:

  • Em “domain” e “search”, os xxx são nomes de domínio (se houver);
  • Em “nameserver”, os xxx são números de IPs de DNS.

Caso não tenha nada no arquivo, acrescente o IP do Gateway (roteador) ou do DNS da rede (se houver). Este arquivo se renova a cada reinicialização da máquina. Se não tiver esse arquivot você deve ciá-lo:

# vim /etc/resolv.conf

E acrescentar, pelo menos, um “nameserver”. Na próxima reinicialização ele virá correto.

4. Para configurar o serviço DHCP, devemos alterar somente dois arquivos:

  • /etc/default/isc-dhcp-server
  • /etc/dhcp/dhcpd.conf

Entre no arquivo com o seu editor de texto favorito, o Nano, o Pico, o Vim, etc. Usarei o Vim como exemplo:

# vim /etc/default/isc-dhcp-server

Na linha onde diz:

INTERFACES=””

Coloque entre as aspas a interface de rede que irá responder pelo DHCP. Exemplo:

INTERFACES=”eth0

Salve e saia do arquivo.

5. Abra o arquivo /etc/dhcp/dhcp.conf:

# vim /etc/dhcp/dhcpd.conf

Comente as duas linhas que iniciam com “option domain” colocando um “#” na frente.

Procure a linha onde tem escrito:

# authoritative;

E se já não estiver sem, tire o “#” da frente.

Após, procure a linha onde diz:

# This is a very basic subnet declaration

Dê um ENTER colocando uma linha em branco e acrescente (antes leia abaixo a definição das linhas do arquivo):

subnet  192.168.2.0  netmask  255.255.255.0  {
range  192.168.2.5   192.168.2.125;
option  routers  192.168.2.1;
option  broadcast-address  192.168.2.255;
option domain-name-servers 192.168.2.2, xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx, 192.168.2.1;
}
deny unknown-clients;
ignore unknown-clients;
group servidores {
use-host-decl-names true;
host dhcp {
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address 192.168.2.1;
}
host dns {
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address 192.168.2.2;
}
}
group clientes {
use-host-decl-names true;
host maquina01 {
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address 192.168.2.5;
}
}

Acrescente tantos quantos hosts forem necessários para você.

Na primeira linha definimos:

  • A nossa subrede: 192.168.2.0
  • E a máscara dessa subrede: 255.255.255.0

Escolhemos isso dentro das 3 faixas de IPs reservadas para redes internas privadas de acordo com a RFC 1918:

10.0.0.0-10.255.255.255
172.16.0.0-172.31.255.255
192.168.0.0-192.168.255.255

Definição:

  • Na linha “range”, definimos a nossa faixa e a quantidade de IPs que queremos que o DHCP distribua (depende do número de computadores que temos na rede). Esta linha deve ser comentada, caso as opções “deny unknown” e “ignore” estejam descomentadas, senão o DHCP continuará distribuindo IPs fora do cadastro dos grupos “servidores” e “clientes”.
  • Na linha “option routers”, definimos o IP do roteador que, no nosso caso, deve ser o mesmo da placa de rede que responde pelo DHCP, no caso, a eth0.
  • Na linha “option broadcast-address”, definimos o broadcast da rede.
  • Na linha “option domain-name-servers”, definimos, por primeiro, o DNS interno da rede (se houver) seguido de DNSs públicos e abertos (os xxx são endereços de IP de DNS públicos e abertos) e terminando sempre com o IP do gateway/roteador para redundância. Caso não tenha DNS interno na sua rede, retire o IP, no caso, 192.168.2.2 e o “host dns” não precisa ter.
  • As linhas “deny unknown-clients” e “ignore unknown-clients”, fazem com que o DHCP distribua IPs somente para as máquinas que estiverem com o MAC cadastrado nos grupos acima. Ao acrescentar os IPs com os MACs na tabela ARP através do arquivo /etc/ethers (abaixo) você deve comentar essas linhas colocando um “#” na frente delas.

* Importante: Se você deixar as linhas “deny …” e “ignore …” descomentadas, as máquinas clientes que estiverem com IP automático e não estiverem cadastradas, NÃO obterão IP e, logicamente, só navegarão se o IP for fixado manualmente na própria máquina.

No grupo “servidores” estamos fixando os IPs dos servidores através do MAC da placa de rede.

Para ver o MAC da placa de rede, execute ifconfig e veja o HW da placa de rede que responde pelo servidor e coloque ali em cima. Caso não haja DNS interno na rede, o “host dns” deve ser omitido.

No grupo “clientes”, definimos os IPs dos clientes através do MAC da placa de rede de cada máquina.

A opção GROUP serve para separar a configuração por grupos dentro da mesma rede/subrede. Por exemplo, você quer que um determinado grupo composto por algumas máquinas tenha uma configuração distinta de outro grupo ou do resto da rede e quer que usem, por exemplo, um outro gateway (option routers), ou qualquer outra configuração permitida a somente uma máquina pelo dhcpd.conf, você pode especificar isso através do “group” sem aplicar para toda a rede.

Salve e saia do arquivo.

Habilitando o compartilhamento

6. Compartilhando a conexão.

Criando o arquivo de configuração do IPtables:

# vim /etc/init.d/firewall.sh

Obs.: Aqui você pode dar o nome que quiser ao arquivo.

Dentro do arquivo coloque exatamente o seguinte:

#!/bin/bash
modprobe iptable_nat
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Onde:

  • A placa eth1 é a placa que recebe a Internet. Se a sua for a eth0, você deve colocar: -o eth0

    * Atente para isso: A interface que vai ali é SEMPRE a interface que recebe a Internet, ou seja, é nesta placa de rede que deverá ser conectado o “fio” de entrada dos dados/Internet.

  • A primeira linha é somente um comentário que identifica o interpretador de comandos, no caso o bash.
  • Na segunda linha estamos levantando o módulo de compartilhamento.
  • Na terceira linha estamos ativando o compartilhamento.
  • Na quarta linha estamos dizendo para o IPtables que tudo que entrar pela placa de rede eth1, deve ser compartilhado com as outras placas de rede do computador.

Salve e saia do arquivo.

É uma configuração extremamente básica e sem segurança nenhuma. Para maior aprofundamento, estude as regras do IPtables.

Vamos transformar o arquivo que criamos em um arquivo executável:

# chmod +x /etc/init.d/firewall.sh

Agora vamos fazer com que esse arquivo seja executado automaticamente na inicialização. Entre no arquivo “rc.local”:

# vim /etc/rc.local

Logo acima da linha “exit 0”, coloque o caminho para o arquivo, ficando assim:

/etc/init.d/firewall.sh   start
exit   0

Salve e saia do arquivo.

7. Reinicie o sistema:

# shutdown -r now

Com isso, o servidor deverá estar fazendo o compartilhamento e servindo endereços IPs para a rede local (Lan).

A lógica é a seguinte: A Internet entra por uma placa de rede, o sistema “pega” essa Internet e através do arquivo do IPtables, faz com que ela seja distribuída para as outras placas de rede, não importando quantas mais tenha na máquina.

Para remover completamente o serviço de DHCP da máquina, se for o caso, execute:

# apt-get purge isc-dhcp-server

Depois coloque todas as placas de rede com IP automático (DHCP) e reinicie:

# shutdown -r now

Daí é só reinstalar o serviço e fazer as configurações novamente.

Controle de IPs pela tabela ARP

8. Para evitar que algum cliente acesse a Internet fixando manualmente o IP na sua máquina, devemos acrescentar na tabela ARP os IPs, criando o arquivo /etc/ethers:

# vim /etc/ethers

Coloque dentro do arquivo o IP e o MAC da seguinte maneira, um por linha:

192.168.2.2   xx.xx.xx.xx.xx.xx
192.168.2.3   xx.xx.xx.xx.xx.xx

E assim por diante.

Você pode também preencher com MACs falsos, os IPs que não estão em uso, por exemplo:

192.168.2.126   00:00:00:ff:ee:11

Ficaria assim o arquivo /etc/ethers:

192.168.2.5   xx.xx.xx.xx.xx.xx
192.168.2.6   xx.xx.xx.xx.xx.xx
192.168.2.126   00:00:00:ff:ee:11
192.168.2.127   00:00:00:ff:ee:11

* Lembrando que os IPs que não estão em uso, são os que não estão cadastrados nos grupos “servidores” e “clientes”.

Se você tem uma faixa de IPs classe C (recomendada para estes casos), então são 253 linhas para você colocar no /etc/ethers, entre IPs em uso e não-uso. O endereço do gateway, da rede e do broadcast não é necessário colocar.

Agora, precisamos carregar o arquivo /etc/ethers na tabela ARP durante a inicialização. Entre no arquivo /etc/rc.local e coloque “arp -f” acima da linha exit 0:

/etc/init.d/firewall.sh   start
arp -f
exit 0

Para o controle de MAC por ARP funcionar, o servidor GNU/Linux terá que ser o gateway da rede, ou seja, deverá haver o compartilhamento.

E, não esqueça, quando a linha “range” estiver descomentada, as linhas “deny…” e “ignore…” devem estar comentadas e vice-versa.

Assim, se alguém não cadastrado no DHCP fixar manualmente um IP na máquina, mesmo estando dentro da faixa de rede utilizada, a máquina não navegará na Internet.

Você pode fazer esse controle de IPs por MAC também pelo IPtables, porém, tendo muitas máquinas na rede tornará o servidor um pouco lento. É preferível fazer pela tabela ARP.

Compilando kernel no Debian Squeeze

 Clusterweb, Linux  Comentários desativados em Compilando kernel no Debian Squeeze
fev 252013
 

Procedimentos

1. Instalar os pacotes necessários:

# apt-get update
# aptitude safe-upgrade

Tem alguns pacotes a mais do que o necessário, mas neste caso, o que abunda não prejudica.

# aptitude install build-essential module-init-tools kernel-package initramfs-tools libaal-dev wget liblzo2-dev gzip expectk libncurses5-dev dpatch udev

2. Fazer o download do kernel desejado no site kernel.org.

O download pode ser feito via navegador ou pelo terminal. No terminal, utiliza-se o pacote wget:

# wget http://caminho_completo_do_kernel

Exemplo:

# wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.7.6.tar.bz2

Obs.: O kernel será baixado no diretório/pasta onde você estiver.

# ls  #Para ver o arquivo baixado

3. Descompactar o arquivo do kernel:

# tar -jxvf nome_do_arquivo.tar.bz2  #Para arquivos: .tar.bz2
# tar -vzxf nome_do_arquivo.tar.gz  #Para arquivos: .tar.gz
# ls  #Para ver o arquivo descompactado

4. Copiar o kernel para o diretório /usr/src (diretório/pasta padrão de compilação do kernel no Debian):

# cp -R linux-x.x.x /usr/src
# cd /usr/src  #Entrar no diretório
# ls  #Verificar se o arquivo foi copiado

5. Nas opções de configuração (make menuconfig), as opções marcadas com “M” indicam que a instalação se dará como módulos, ou seja, não farão parte do bloco monolítico do kernel.

As opções marcadas com “*” (asterisco) indicam que serão instaladas dentro do kernel, ou seja, farão parte do bloco monolítico do kernel, e os drivers e módulos iniciarão junto com o sistema. Em alguns casos, isto é interessante para melhorar o desempenho.

Executar os comandos abaixo em sequência (aguardar o final após cada comando e sempre ler as mensagens de retorno para ver se deu algum erro):

# ln -s linux-x.x.x linux  #Cria um link simbólico necessário para a compilação
# ls  #Confirmar se o arquivo foi criado
# cd linux  #Entra no diretório criado
# make-kpkg clean  #Limpa prováveis compilações anteriores
# make mrproper  #Limpa prováveis compilações anteriores
# make menuconfig  #Entra nas configurações do kernel

Para alterar de “M” para “*” e vice-versa, é só pressionar a barra de espaços.

Vá em “Processor type and features”, e marque (barra de espaços) a opção que corresponde ao processador da máquina.

Mais abaixo, vá em “Timer frequency”. Se a sua instalação for do tipo servidor marque, a opção 100 HZ (isso melhorará o tempo de resposta do servidor para as requisições). Para Desktop, deixe como está.

Retorne ao menu principal.

Vá em: Networking support → Networking options → Network packet filtering framework (netfilter) → IP: netfilter configuration

Verifique se “IPv4 connection tracking support (required for NAT)” está marcada.

Mais abaixo, marque as opções:

IPv4 NAT
MASQUERADE target support
NETMAP target support
REDIRECT target support

Volte ao menu principal.

Vá em “File Systems”, marque os sistemas de arquivo utilizados no particionamento da instalação com: “*”

Mais abaixo, vá em “Native language support” e marque com “*” as opções:

Codepage 860 (Portuguese)
ASCII (United…)
NLS 8859-1 (Latin 1, …)
NLS UTF-8

Retorne ao menu principal dando EXIT. Após o último EXIT, aparecerá a janela “Do you wish…”, deixe como: “Yes”

Compilação

6. Compile:

# make config_debug_section_mismatch=y  #Compila e previne possíveis erros durante a compilação, deverá demorar de uma a duas horas
# make modules  #Compila os módulos
# make modules_install  #Instala os módulos
# make install  #Instala o kernel
# cd /lib/modules  #Entrar no diretório
# ls  #Confirmar que foi criado o arquivo x.x.x, no caso, 3.7.6
# mkinitramfs -o /boot/initrd.img-x.x.x /lib/modules/x.x.x  #Cria a imagem do kernel
# cd /boot  #Entrar no diretório /boot e conferir se o arquivo foi criado
# cd  #Entra no diretório raiz
# update-grub  #Atualiza o GRUB
# shutdown -r now  #Reinicia

Ao reiniciar, o novo kernel deverá aparecer nas opções do GRUB.

Depois, atualize o sistema (opcional):

# aptitude update
# aptitude safe-upgrade

Em caso de erro em alguma etapa da compilação:

  • Apague os arquivos criados do novo kernel dentro dos diretórios: /boot e /lib/modules
  • Recomece a partir do comando: make-kpkg clean (estando dentro do link: linux)

E seja feliz com seu novo e atualizado kernel.