sexta-feira, 17 de outubro de 2008

SSH no celular

Por Carlos E. Morimoto 28/04/2008
http://www.guiadohardware.net/dicas/ssh-celular.html
Dicas do Guia do Hardware

Com a popularização dos smartphones e do acesso web via GPRS, EDGE e conexões 3G, já é perfeitamente possível administrar um servidor remotamente utilizando apenas o celular, conectando-se via SSH para reiniciar serviços, atualizar o sistema ou fazer ajustes na configuração.

O SSH é uma boa opção de software de administração remota para uso em celulares, pois além de bastante seguro, o protocolo é relativamente leve e o uso de uma conexão em modo texto consome pouca banda, permitindo que você o utilize mesmo em planos onde o tráfego é cobrado por megabyte transferido, o que não seria viável em protocolos mais pesados, como no caso do VNC.

Nada melhor do que receber uma chamada no celular avisando de um problema no servidor e poder solucioná-lo de onde estiver, usando o próprio aparelho. Vamos então a um apanhado geral das opções de clientes SSH disponíveis para diversas plataformas de celulares e smartphones.

Para os aparelhos baseados no Symbian S60, como os Nokia E61 e E62, a melhor opção é o S2PuTTY (PuTTY for Symbian), disponível no http://s2putty.sourceforge.net/.

Ele é uma implementação completa do protocolo SSH2, que funciona tanto nos modelos com teclado QWERT quanto nos modelos mais simples, com teclado numérico (embora o uso seja bem menos conveniente). Pressionando a tecla "send" você tem acesso a um menu para a inserção de caracteres especiais (como o TAB). Aqui temos o S2PuTTY rodando em um Nokia E62:

m4b505c23

O S2PuTTY deu origem ao PuTTY for UIQ3 uma versão atualizada, que funciona nos novos smartphones baseados no UIQ3, como o Sony-Ericsson P990i e W950. Ele pode ser baixado no: http://coredump.fi/putty.

4d9e02ab

m3e09dd3


PuTTY for UIQ3 no Sony-Ericsson P990i

Embora tanto o S60 quanto o UIQ3 sejam baseados na plataforma Symbian, os dois sistemas são plataformas bem diferentes, daí o surgimento de versões separadas do PuTTY. O S60 é desenvolvido pela Nokia e licenciado para a LG, Samsung e outros fabricantes, enquanto o UIQ é encontrado em aparelhos da Sony-Ericsson e da Motorola.

Continuando, temos o PocketPuTTY, que atende aos usuários de palmtops e smartphones baseados no Windows Mobile 2003 ou Windows Mobile 5.0. Ele está disponível no: http://www.pocketputty.net/.

Embora tenha nascido como uma projeto hobbistico, ele evoluiu rapidamente, passando a oferecer quase todos os recursos disponibilizados pelo PuTTY original, incluindo a criação de túneis encriptados. Ele é ainda um projeto em desenvolvimento, por isso não é completamente estável, mas ele funciona bem na maioria dos aparelhos.

7bc3daaf

Para os smartphones com o PalmOS, incluindo o Treo 600, 650 e 680, você pode utilizar o pSSH, disponível no: http://www.sealiesoftware.com/pssh/. Aqui o estou utilizando em um Treo 650 para editar um arquivo de configuração usando o mcedit:

2be309dd

O tamanho das fontes, assim como diversas outras opções são configuráveis, por isso não se assuste com o tamanho do texto no screenshot, eles foram tirados usando as fontes em tamanho mínimo, de forma a maximizar o volume de caracteres mostrados na tela. Além dos Treos, ele pode ser usado também em palms sem teclado, nesse caso com a ajuda de um teclado onscreen. Você pode utilizá-lo em um Palm TX conectado via Wi-FI, por exemplo.

Diferente de clientes SSH mais antigos para o PalmOS, como o TuSSH e o TGssh (que suportam apenas o SSH 1), o pSSH oferece suporte ao SSH 2, usado atualmente. A maior deficiência é que o pSSH utiliza uma implementação relativamente insegura do protocolo, que gera chaves de autenticação relativamente previsíveis, fato que é apontado por muitos como uma brecha de segurança (o próprio programa avisa disso ao realizar a primeira conexão). Em tese, alguém que conseguisse capturar a transmissão através da rede celular, soubesse que você está usando o pSSH e tivesse uma dose de paciência, poderia quebrar a encriptação, obtendo assim acesso aos dados. De qualquer forma, interceptar dados em redes de celular GSM não é algo trivial, de forma que (a menos que você seja um administrador paranóico), o risco é aceitável.

Concluindo, temos também o MidpSSH, uma implementação do SSH2 em Java, que pode ser usada até mesmo nos aparelhos mais simples, que ofereçam suporte à linguagem. Basicamente, qualquer aparelho onde você pode rodar o Opera Mini ou jogos em Java é um forte candidato a rodar o MidpSSH sem grandes percalços, como no caso desse Nokia 6230:

45e2ec33

Nada impede também que ele seja usado em aparelhos com mais recursos, como no caso dos Blackberrys.

A página do projeto é a http://xk72.com/midpssh e você pode ver uma lista dos aparelhos suportados no http://www.xk72.com/midpssh/wiki/supported-devices.

O MidpSSH pode ser instalado de duas maneiras. A mais simples é acessar o endereço http://xk72.com/wap no próprio aparelho e fazer o download diretamente. A segunda é baixar o programa no http://xk72.com/midpssh/download.php e transferir manualmente os arquivos .jad e .jar para o aparelho, de forma a realizar a instalação.

As melhores ferramentas de segurança pra Linux

Artigo muito bom, leiam e aproveitem... créditos de Hugo Doria.

Existem várias ferramentas de segurança que podem auxiliar a vida de um administrador de redes/sistemas. Resolvi fazer um compilado rápido das melhores ferramentas para ajudar a vida destas pessoas. ;-)

É claro que esta lista não é definitiva e reflete apenas o meu gosto e o que uso. Se alguém tiver alguma sugestão de ferramenta para adicionar aqui é só entrar em contato que adicionarei com prazer. Com o tempo eu vou adicionando mais informações nesta página para torná-la ainda mais completa.

Bem, vamos à lista (que não está em nenhuma ordem definida):

Nmap

Quando eu penso em ferramenta de segurança o nmap é a primeira que me vem em mente. Provavelmente por ser a que mais uso. #)

Para quem ainda não conhece (há alguém?), o nmap é um port scanner capaz de detectar várias informações sobre o host como, por exemplo, sistema operacional, serviços rodando (e suas versões), uptime e algumas outras coisas. Ah! E ele, obviamente, verifica quais portas estão abertas, ou não.

Site: http://nmap.org/
Tutorial: http://www.guiadohardware.net/dicas/usando-nmap.html

Wireshark

Antigamente chamado de Ethereal, o Wireshark é um poderoso sniffer, que permite que você capture pacotes e te ajuda a analisar a rede, detectar possíveis problemas e entender melhor alguns protocolos. Ele possui uma boa interface gráfica e várais opções que podem te auxiliar.

Quem quiser pode usar o tshark, a versão em modo texto do wireshark. (Dica do usuário milopi)

Site: http://www.wireshark.org/
Tutorial: http://www.guiadohardware.net/tutoriais/wireshark/

Nessus

Do guiadohardware: “O Nessus é uma ferramenta de auditoria muito usada para detectar e corrigir vulnerabilidades nos PCs da rede local. Ele realiza uma varredura de portas, detectando servidores ativos e simulando invasões para detectar vulnerabilidades. Uma característica importante é que o Nessus procura por servidores ativos não apenas nas portas padrão, mas em todas as portas TCP. Ele será capaz de detectar uma vulnerabilidade em um servidor Apache escondido na porta 46580, por exemplo.”

Site: http://www.nessus.org/
Tutorial: http://www.guiadohardware.net/tutoriais/usando-nessus/

Tripwire

O Tripwire é um software utilizado para verificar a integridade de arquivos e diretórios do seu sistema. Ele gera uma base de informação sobre estes arquivos e, a partir dai, consegue detectar mudanças. Se for instalar o tripwire é extremamente recomendado que o faça o mais cedo possível. Instalar o tripwire em uma máquina que já roda há 4 anos e/ou que há suspeitas de ser sido invadida é perigoso, pois ele pode gerar uma base de dados errada.

Quando um arquivo é alterado o Tripwire é capaz de te informar sobre isso e, assim, você pode tomar as devidas providências.

Site: http://sourceforge.net/projects/tripwire/
Tutorial: http://www.linuxjournal.com/article/8758

Rkhunter

O Rkhunter é um anti-rootkit não tão conhecido quanto o chkrootkit, mas que eu considero uma melhor alternativa. Rootkits são ferramentas utilizadas, geralmente, com o objetivo de ocultar a presença de invasores nas máquinas. Com essas ferramentas alguém não-autorizado, mas que já conseguiu entrar na máquina, pode ter controle sobre a máquina e nem ser notado.

Muitos rootkits acompanham uma gama de binários (como o ls, ps, who, find etc) modificados para que os processos rodados pelo invasor não possam ser vistos pelo administrador da máquina. Além disso, muitos vírus atuais utilizam rootkits.

Site: http://www.rootkit.nl/
Tutorial: http://hdoria.archlinux-br.org/blog/2008/06/05/procurando-rootkits-no-seu-sistema/pt/

Netcat

Como muita gente fala por aí: O Netcat é o canivete suiço do TCP/IP. Se trabalhasse em uma empresa com certeza ele seria um estagiário (não por não ser importante, mas sim por fazer de tudo). Ele pode ser usado como port scanner, brute force, telnet e mais uma porrada de coisa que a “leitura” e “escrita” em uma conexão de rede permita.

Site: http://netcat.sourceforge.net/
Tutorial: http://www.vivaolinux.com.br/artigo/Netcat-O-canivete-suico-do-TCP-IP

Snort

Daqui: “O Snort é um software livre de detecção de intrusão para rede (NIDS) desenvolvido inicialmente por Martin Roesch, capaz de desenvolver análise de tráfego em tempo real e registro de pacote em redes IP. Executa análise de protocolo, busca/associa padrões de conteúdo e pode ser usado para detectar uma variedade de ataques, tais como buffer overflows, stealth port scans, ataques CGI, SMB probes, OS fingerprinting, entre outras”.

Site: http://www.snort.org/
Tutorial: http://tiagolima.wordpress.com/2008/04/24/instalacao-do-snort-base-no-debian-etch-pelos-fontes/

Ettercap

Ettercap é mais um poderoso sniffer e que usa muito Arp Spoofing. Com ele você pode filtrar pacotes, injetar caracteres, indentificar o SO etc.

Site: http://ettercap.sourceforge.net/
Tutorial: http://queroquero.lncc.br/~lrodrigo/wiki9/index.php/Ettercap

Aircrack-ng

O aircrack é uma ótima ferramenta para se quebrar chaves WEP e WPA e servir como auditoria de redes wireless.

Site: http://www.aircrack-ng.org/
Tutorial: http://my.opera.com/Ricardo%20Belfiglio/blog/2008/02/08/aircrack-ng-atacando-a-rede-wireless-e-quebrando-senhas-wep-e-wap1

Tcpdump

O tcpdump é um dos sniffers mais populares no Linux. Com ele é possível monitorar o tráfego, analisar e solucionar problemas. Ele é bem simples e fácil de usar.

Site: http://www.tcpdump.org/
Tutorial: http://www.vivaolinux.com.br/dica/tcpdump-Monitorando-conexoes/

Créditos: Hugo Doria

http://hdoria.archlinux-br.org/blog/2008/09/24/as-melhores-ferramentas-de-seguranca-pra-linux/pt/#more-263

quarta-feira, 21 de maio de 2008

Ativando o Mysql no Slackware

Ativando o Mysql no Slackware 10.X e 11.0

Como todos sabem, o Slackware Linux 10.X e 11.0 já trazem em meio a seus pacotes o MySQL.
O pacote vem instalado, mas não ativado.

A seguir segue uma dica rápida de como ativar:


root@slackware:~# sudo mysql_install_db
root@slackware:~# chown mysql.mysql /var/lib/mysql/ -R


"-R" para dar permissão ao usuário mysql sobre o diretório e subdiretórios do diretório).

root@slackware:~# chmod +x /etc/rc.d/rc.mysqld
root@slackware:~# /etc/rc.d/rc.mysqld start


Agora crie uma senha pra acesso ao BD MySQL:


root@slackware:~# mysqladmin -u root password sua_senha


Rápido, prático e simples como o próprio MySQL.

Créditos:
Rodrigo Ribeiro
http://www.vivaolinux.com.br/dicas/verDica.php?codigo=7613

LILO - Configurar tempo de inicialização

Para os iniciantes que não querem perder tempo esperando a contagem regressiva na inicialização so Linux, basta alterar o timeout no LILO.

Veja como:

*logo no linux como root
*entre na pasta /etc
*edite o arquivo lilo.conf

cd /etc
pico lilo.conf

*na linha 8, onde está timeou = 1200, troque para
timeout = 10

* o tempo está em milesegundos, entao 10 é 1 segundo, se vc colocar 1 não irá funcionar...
* agora, tecle CTRL + X p/ fechar e Y para salvar as alterações
* digite agora lilo (se nao digitar não irá salvar as alterações)
lilo

* é isso, simples e prático... boa sorte
By Eder Závoli

sexta-feira, 16 de maio de 2008

NoCatAuth - Construindo um firewall/gateway autenticado

Por Patrick Brandão
http://www.patrick.eti.br
contato@patrick.eti.br

O programa NoCatAuth, criado pela nocat.net tem o propósito de evitar que pessoas não autorizadas tenham acesso a internet em rede wireless. Para isso, esse programa em Perl captura o tráfego na porta 80 e o desvia para um servidor HTTP, onde haverá uma página solicitando usuário e senha, e opcionalmente, uma página para cadastro.

O NoCat também pode ser usado para simplesmente obrigar o usuário a ler uma página de splash antes de navegar, onde se pode colocar um termo de uso, um aviso ou simplesmente a página do provedor de acesso.

O NoCat pode ser configurado para rodar em três modos:
  • OPEN - O tráfego na porta 80 é capturado e redirecionado para uma página de splash, após a página ter sido carregada, o acesso à internet é liberado para o host.
  • PASSIVE - O tráfego dos usuários não autenticados para a porta 80 será capturado, após a autenticação, uma regra de firewall (iptables ou ipchains) permitirá o acesso à internet por meio de NAT.
  • CAPTIVE - Semelhante ao PASSIVE, porém, ao se identificar com sucesso, o acesso à internet será liberado, mas sem NAT.

O NoCatAuth funciona com duas instâncias nos modos PASSIVE e CAPTIVE, uma, NoCat Gateway, e outra NoCat Auth, o Gateway redirecionará o tráfego HTTP para a porta 80 do servidor Auth que após autenticar o usuário, se conectará na porta 5280 do Gateway para dar permissão de passagem ao host. A conexão do servidor Auth na porta 5280 do Gateway é criptografada com PGP para dar suporte a casos em que o servidor Auth tem uma conexão não confiável com o servidor Gateway.

Tomei a iniciativa de escrever este tutorial ao ver que não encontrava, nem no Google, nem na própria página no NoCat, um tutorial que me ensinasse com clareza como se usa este programa.


Objetivo


  • Permitir acesso à internet somente a usuários autenticados;
  • A autenticação terá que ser feita em uma página web e a base de dados deverá ser armazenada em um banco de dados MySQL;
  • Usar HTTPS na página de autenticação;
  • Os hosts devem receber um endereço IP dinâmico e inválido (não roteável);
  • Os usuários devem ter acesso por NAT, que será feito no gateway;
  • Os servidores NoCatAuth e NoCatGateway deverão ser instalados no mesmo computador.

Tecnologias usadas e ambiente de laboratório

  • Linux 2.4.26 (distribuição Slackware 10.0 - instalação FULL)
  • Apache 2.0.50/mod_ssl
  • OpenSSL 0.9.7d
  • GnuPG 1.2.2
  • NocatAuth 0.82
  • MySQL 4.0.20
  • Perl 5.8.4
  • DHCPD 1.3.0pl2
  • BIND 9.2.3
  • IPTABLES 1.2.10

Computador de laboratório:
  • Processador: K6-II 500MHz
  • Memória: 128 MB
  • HD: 15GB ( Particionamento: 1 - 512 MB Swap, 2 - 14200 MB EXT3)
  • Placas de rede: 2 - 3COM (eth0 192.168.150.21, eth1 192.168.10.1)
  • Sistema operacional: Linux Slackware 10.0 (instalação FULL).
  • CDROM 52x

Material mínimo necessário:
Computador com 2 interfaces de rede e drive cdrom/dvdrom, cd de instalação do Slackware 10.0, acesso a internet no momento da instalação (downloads de pendências).


Instalação dos programas

O Slackware 10.0 vem com o Apache 1.3, mas eu particularmente prefiro o Apache 2.0.50, por isso vou usá-lo nesta solução. Se você tem experiência como Apache 1.3.x, fique a vontade em usá-lo, senão:

Removendo Apache 1.3:

# removepkg apache-1.3.31-i486-2

O OpenSSL versão 0.9.7.d, GnuPG 1.2.4, MySQL 4.0.20 e Perl 5.8.4 (e modulo perl Digest::MD5) já vêem instalados por padrão (instalação FULL) no Slack 10.

Instalação do Apache 2.0.50

# cd /usr/local/src
# wget http://apache.usp.br/httpd/httpd-2.0.50.tar.gz
# tar xvzf httpd-2.0.50.tar.gz
# cd httpd-2.0.50
# ./configure --enable-ssl --enable-cgi --enable-suexec --enable-so
# make
# make install


O Apache será instalado no diretório /usr/local/apache2, os arquivos de configuração ficarão na pasta usr/local/apache2/conf.

Módulos Perl

Os módulos usados pelo NoCat para esta solução são:
  • Net::Netmask
  • DBI
  • DBD::mysql
  • Digest::MD5

Se você deseja usar outro tipo de autenticação, consulte a documentação do NoCat. Várias tecnologias são suportadas: IMAP, LDAP, SAMBA, PAM, RADIUS, etc.

A primeira vez que você invocar o CPAN do Perl, ele solicitará algumas configurações do sistema e da localidade, basta responder N que ele usará a configuração padrão. Necessário estar conectador.

# perl -MCPAN -e shell
cpan> install Bundle::CPAN (ENTER para todas as perguntas)
cpan> install DBI
cpan> install DBD::mysql
cpan> install Digest::MD5
cpan> install Net::Netmask
cpan> exit

Atenção, as linhas seguintes testam os módulos e não podem retornar erros:

# perl -MDBI
# perl -MDBD::mysql
# perl -MDigest::MD5
# perl -MNet::Netmask


Agora o Perl está completo para o NoCat.

Ativar MySQL

Vamos ativar o MySQL, pois no Slackware 10.0 ele se encontra instalado, porém alguns ajustes são necessários para colocá-lo rodando.

Como nós iremos usar o MySQL apenas para armazenar algumas centenas de logins, não convém reservar recursos desnecessários. Por isso será usado o arquivo de configuração my-small.cnf (ver documentação do MySQL).

Em seguida criaremos um banco de dados para o NoCatAuth e um login de acesso para ele.

# cp /etc/my-small.cnf /etc/my.cnf
# mysql_install_db
# chown mysql.mysql /var/lib/mysql /var/run/mysql -R
# chmod +x /etc/rc.d/rc.mysqld
# /etc/rc.d/rc.mysqld start


Conferindo se o servidor MySQL esta de pé:

# nmap localhost -p 3306
Starting nmap 3.50 ( http://www.insercure.org/nmap/ ) at 2004-07-26 16:02 Interesting ports on localhost (127.0.0.1):
PORT STATE SERVICE
3306/tcp open mysql
Nmap run completed - 1 IP address (1 host up) scanned in 0.331 seconds

Ajustando a senha do root mysql:

# mysqladmin password senhadorootmysqlaqui
# mysql -u root -psenhadorootmysqlaqui

mysql> CREATE DATABASE nocat;
mysql> GRANT ALL PRIVILEGES ON nocat.* TO nocat@localhost IDENTIFIED BY "senhadonocat" WITH GRANT OPTION;
mysql> FLUSH PRIVILEGES;
mysql> exit

Substitua "senhadorootmysqlaqui" pela senha de root do MySQL, cuidado com esta senha. Faça o mesmo com "senhadonocat".

NoCAT

Todos os códigos necessários para construção do nosso servidor, tanto Auth como Gateway estão no mesmo pacote:

# wget http://nocat.net/download/NoCatAuth/NoCatAuth-0.82.tar.gz # tar -xvzf NoCatAuth-0.82.tar.gz # cd NoCatAuth-0.82

NoCAT Gateway

# make PREFIX=/usr/local/nocat/gw gateway

NoCAT Auth

# make PREFIX=/usr/local/nocat/authserv authserv

Chave PGP

A chave de PGP deve ser a mesma para ambas as instâncias para que elas se comuniquem, portanto, vamos criá-la no authserv e copiá-la para o gateway. Não defina uma senha para esta chave.

# make PREFIX=/usr/local/nocat/authserv pgpkey
# cp /usr/local/nocat/authserv/trustedkeys.gpg /usr/local/nocat/gw/pgp


Pronto, a instalação já está feita, agora vamos configurar tudo, começando pelo Apache.

Configuração

Apache

Criando certificados:
Como não temos dinheiro sobrando para comprar um certificado da VeriSign (pelo menos eu não), vamos ser nossa própria entidade certificadora. Crie um diretório na pasta raíz do Apache com o nome ssl:

# cd /usr/local/apache2
# mkdir ssl
# cd ssl


Vamos criar os certificados:

# openssl genrsa -out nocat.key 1024

Criar assinatura do certificado digital:

# openssl req -new -key nocat.key -out nocat.csr

Certificado auto-assinado:

# openssl x509 -days 365 -req -in nocat.csr -signkey nocat.key -out nocat.crt

Configurando HTTPS e CGI-BIN

Edite o arquivo /usr/local/apache2/conf/httpd.conf e procure onde está a definição da pasta virtual cgi-bin:

ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/

AllowOverride None
Options None
Order allow,deny
Allow from all


Altere para o exemplo abaixo:

ScriptAlias /cgi-bin/ /usr/local/nocat/authserv/cgi-bin/

SetEnv PERL5LIB /usr/local/nocat/suthserv/lib
SetEnv NOCAT /usr/local/nocat/authserv/nocat.conf

Edite o arquivo /usr/local/apache2/conf/ssl.conf e preencha com o seguinte conteúdo:

SSLRandomSeed startup builtin
SSLRandomSeed connect builtin

Listen 443
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
SSLPassPhraseDialog builtin
SSLSessionCache dbm:/usr/local/apache2/logs/ssl_scache
SSLSessionCacheTimeout 300
SSLMutex file:/usr/local/apache2/logs/ssl_mutex

DumentRoot /usr/local/apache2/htdocs
ServerName authserv.dominio.com.br:443
ServerAdmin contato@patrick.eti.br
ErrorLog /usr/local/apache2/logs/erros_log
TransferLog /usr/local/apache2/logs/access_log
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /usr/local/apache2/ssl/nocat.crt
SSLCertificateKeyFile /usr/local/apache2/ssl/nocat.key

SSLOptions +StdEnvVars


SSLOptions +StdEnvVars

SetEnvIf User-Agent .*MSIE.* \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog /usr/local/apache2/logs/ssl_request_log \
%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \%r\ %b


NoCatAuth

Vá até o diretório /usr/local/nocat/authserv, edite o arquivo nocat.conf e confira os parâmetros:

Verbosity 10
PGPKeyPath /usr/local/nocat/authserv/pgp
HomePage http://www.dominio.com.br/
DocumentRoot /usr/local/nocat/authserv/htdocs

# configuraçao do banco de dados MySQL
# reveja a ativação do mysql para conferir a senha que você configurou
DataSource DBI
Database dbi:mysql:database=nocat
DB_User nocat
DB_Passwd senhadonocat

Os demais parâmetros devem permanecer inalterados, a menos que você saiba o que esta fazendo. Na ativação do MySQL, nós apenas criamos o banco de dados nocat, agora vamos criar as tabelas. No pacote de instalação do NoCat há uma pasta etc e dentro dela um arquivo chamado nocat.schema. Execute o seguinte comando para criar a estrutura de tabelas:

# mysql -u root -psenhadorootmysqlaqui nocat < /usr/local/src/NoCatAuth-0.82/etc/nocat.schema

MUITO IMPORTANTE:
Já vi varias perguntas na internet sobre um erro:

"INTERNAL SERVER ERROR"

Quando se solicita a autenticação. Como o nocat auth roda por meio de cgi, o usuario que acessa os arquivos em /USR/LOCAL/NOCAT/AUTHSERV/* é o usuario do Apache. Para que esse erro desapareça, dê o domínio desses arquivos para o Apache, execute:

# chown apacheuser.apachegroup /usr/local/nocat/authserv -R
# chmod 700 /usr/local/nocat/authserv -R


LEMBRANDO QUE: apacheuser e apachegroup deverá ser substituído pelo usuário e grupo que roda o Apache.

NoCatGateway

Edite agora o arquivo nocat.conf do diretório /usr/local/nocat/gw e confira os parâmetros abaixo:

Verbosity 10
GatewayName Domínio Gateway - Autenticação

# se o gateway também faz NAT, você deve usar Passive, senão, use Captive
GatewayMode Passive
LoginTimeout 86400
HomePage http://www.dominio.com.br/
DocumentRoot /usr/local/nocat/gw/htdocs

# Coloque no parâmetro abaixo, os logins que tem livre acesso separados de espaço
# ou comentar essa linha para que todos autentiquem
Owners contato@patrick.eti.br tol83@bol.com.br

# ip da interface em contato com rede wireless ou rede local
AuthServiceAddr 192.168.10.1
AuthServiceURL https://$AuthServiceAddr/cgi-bin/login
LogoutURL https://$AuthServiceAddr/logout.html

# interface com ip roteável na internet
ExternalDevice eth0

# interface com usuários (192.168.10.1)
InternalDevice eth1

# apenas este DNS poderá ser usado na rede dos usuários, caso
# este parâmetro não seja definido, serão liberados os endereços
# dos servidores no arquivo /etc/resolv.conf
# lembre-se de colocar os mesmos servidores na configuração do DHCPD
DNSAddr 192.168.10.1 192.168.150.56

Os demais parâmetros devem permanecer inalterados, a menos, é claro, que você saiba o que está fazendo.

Configurando DHCPD

Para que os usuários não tenham que trocar nas configurações de rede dos seus computadores, vamos configurar o gateway para servir isso para eles. Edite o arquivo /etc/dhcpd.conf e preencha com as linhas:

ddns-update-style none;
default-lease-time 600;
max-lease-time 600000;
option broadcast-address 192.168.10.255;

# desativar dhcpd para a interface 192.168.150.21
subnet 192.168.150.0 netmask 255.255.255.0 {}
subnet 192.168.10.0 netmaks 255.255.255.0 {
range 192.168.10.100 192.168.10.200;
option routers 192.168.10.1;
option domain-name "dominiowireless.com.br";
option domain-name-servers 192.168.10.1;
}
# mais informacoes: # man dhcpd.conf

Opcional: Servidor DNS

É recomendável que você tenha um servidor DNS no gateway, portando adiciona o NAMED na inicialização do Slackware 10.0:

# chmod +x /etc/rc.d/rc.bind

Iniciando o servidor

Por motivos de segurança, já que o Apache 1.3 foi removido, desative o rc.httpd com o comando:

# chmod -x /etc/rc.d/rc.httpd

Crie o arquivo /etc/rc.d/rc.nocat com o seguinte conteúdo:

#!/bin/sh
NC=/usr/loca/nocat/gw
export PERL5LIB=$NC/lib:$PERL5LIB
export NOCAT=$NC/nocat.conf
case "$1" in
start)
echo "Starting the NoCat gateway ..."
$NC/bin/gateway
;;
stop)
echo "Stopping the NoCat gateway ..."
killall gateway 2>/dev/null
restart)
$0 stop
sleep 1
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac

E torne-o executável:

# chmod +x /etc/rc.d/rc.nocat

Execute os comandos abaixo para rodar o DNS e o MySQL na inicialização do sistema:

# chmod +x /etc/rc.d/rc.bind
# chmod +x /etc/rc.d/rc.mysqld


Vamos agora configurar o servidor para levantar os serviços de forma organizada. Edite o arquivo /etc/rc.d/rc.local e certifique-se de que há as seguintes linhas (adicione as que faltarem):

# iniciando servidor DHCPD
dhcpd

# iniciando apache com suporte a SSL
If [ -x /usr/local/apache2/bin/apachectl ]; then
/usr/local/apache2/bin/apachectl startssl
fi

# iniciando NoCatGateway
/etc/rc.d/rc.nocat start

Agora, reinicie o servidor. Seu gateway autenticado está pronto!

Créditos:
Patrick Brandao
http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=1338&pagina=1

Estrutura do Iptables

Introdução: o que esperar deste artigo

Ao contrário de outros artigos e tutoriais sobre iptables, este não se dispõe a ensinar sua sintaxe, como construir regras e como bloquear este ou aquele tipo de pacote. Artigos meus futuros poderão passear por este caminho, muito embora já se tenha muito material na Internet sobre isto.

Ele se destina a explicar a origem dos termos "tabelas" do iptables, o que é e para que servem as tabelas nat, filter e mangle. Onde, ou seja, em qual tabela se deve colocar as regras para este ou aquele objetivo.

Este artigo aproveita também para esclarecer algumas diferenças interessantes, como para que serve o REJECT e qual a diferença dele para o DROP?

Algumas definições serão relevantes e merecem serem citadas antes da leitura:

Quando falo de "nível" no artigo (ex: nível de Enlace) estou me referindo ao modelo de camadas TCP/IP, composto por apenas QUATRO camadas e não SETE como no modelo OSI. No modelo TCP as camadas são o ENLACE, onde se tem na sua imensa maioria o padrão de rede Ethernet como referência:
  • O nível de REDE, responsável pelo roteamento, onde se tem o IP na sua versão 4 como mais significativo;
  • O nível de TRANSPORTE, com seus pacotes UDP e TCP, dentre outros;
  • O o nível de aplicação, com os protocolos FTP, HTTP, etc;
  • O nível FÍSICO não faz parte do modelo de camadas TCP/IP, pois é restrito ao fabricante da placa.

Em termos de nomenclatura geralmente se generaliza chamando tudo de pacote. Porém, quando se quer deixar mais específico em qual nível estamos lidando, pode-se se usar a nomenclatura "quadro" para o nível de Enlace, "datagrama" ip para o nível de rede e "pacote" para o de transporte (sendo que o TCP muitas vezes usam a palavra "segmento"). Na aplicação o que tem são dados.

Mas como o iptables atua em princípio nas camadas de rede, ip de origem ou de destino, e na de transporte (porta origem e destino), o pacote pode ser considerado, neste artigo, como um termo genérico (OBS: é certo que o iptables também permite atuar no enlace e até mesmo na aplicação, com os devidos módulos adicionados).

Por onde passa um datagrama

O iptables, presente no Linux a partir do kernel 2.4, usa o conceito de "ganchos" do netfilter, permitindo avaliar um datagrama em alguns pontos dentro do kernel.



Conforme pode ser observado na Figura 1, um datagrama IP dentro do kernel do Linux passa por várias etapas. Basicamente um datagrama IP é de um dentre três tipos:
  1. O datagrama chegou por uma de suas interfaces, o nível de enlace viu o seu mac address no quadro ethernet. Contudo o datagrama não é destinado ao número IP desta máquina. Se a máquina não for configurada para atuar como roteador, o datagrama é descartado. Se a máquina estiver atuando como roteador, o datagrama deve ser roteado por ela.
  2. O datagrama chegou por uma de suas interfaces, o nível de enlace viu o seu mac address no quadro ethernet e ele é destinado ao IP desta máquina, logo deve ser entregue a um de seus processos locais (se for HTTP, por exemplo, deve ser entregue ao apache).
  3. O datagrama IP foi gerado por um de seus processos locais, por um cliente de email por exemplo, e deve ser repassado a outra máquina.
    Cada datagrama passa por uma etapa de roteamento, onde o kernel decide para onde ele vai. Nesta etapa é que são consultadas, se for o caso, as tabelas de roteamento. Os do tipo 1 devem serem roteados para fora da máquina, que no caso deve estar atuando como roteador, sendo que na etapa de roteamento o kernel decide qual o próximo ponto de rota que deve ser usada. Se for para o IP desta máquina, é o roteamento que verifica isto (isto é, recebe o datagrama, vê que é local e entrega ao nível de transporte, que irá repassá-lo ao processo correspondente).

    Da mesma forma, pacotes os gerados por processos locais também passam pelo roteamento para serem encaminhados. Logo, todos os datagramas passam, de uma forma ou de outra, pela etapa de roteamento.

    Caso ele precise ser repassado a outra máquina (somente se ela estiver atuando como roteador IP), a etapa de "repasse de pacotes" realiza as alterações necessárias, como a reescrita total do cabeçalho de enlace (trocando o MAC origem para o seu), atualização do TTL, etc. Evidente que isto após a decisão de roteamento, pois a escrita do cabeçalho de enlace leva em conta o destino.

Ganchos do netfilter

O netfilter introduziu "ganchos", pontos ao longo do ciclo de vida de um datagrama onde o mesmo pode ser avaliado por regras de firewall. A Figura 2 destaca estes pontos.



Pode-se observar pela Figura 2, que:
  • Um datagrama destinado ao processo local:
    • Pode ser capturado para avaliação ao entrar na Interface, pelo gancho 1, chamado pelo kernel de PREROUTING.
    • Pode ser capturado para avaliação pelo gancho 4, chamado pelo kernel de INPUT.

  • Um datagrama gerado por um processo local:
    • Pode ser capturado para avaliação pelo gancho 5, chamado pelo kernel de OUTPUT.
    • Pode ser capturado para avaliação pelo gancho 3, chamado de POSTROUTING.

  • Um datagrama que esteja apenas passando por esta máquina, não gerada e não destinada ao ip ela:
    • Pode ser capturado para avaliação ao entrar na Interface, pelo gancho 1, chamado pelo kernel de PREROUTING.
    • Pode ser capturado para avaliação pelo gancho 2, chamado pelo kernel de FORWARD.
    • Pode ser capturado para avaliação pelo gancho 3, chamado de POSTROUTING.


Por existirem estes ganchos e a possibilidade de avaliar um datagrama e tomar decisões de firewall sobre ele nestes pontos, o iptables introduz filas de regras (listas) nestes pontos. Cada gancho pode possuir um ou mais conjuntos de regras.


Enfim, as tabelas

Ao todo são três as tabelas mais importantes do iptables:
  • filter
  • nat
  • mangle

A tabela filter deve conter apenas regras que determinam se um pacote deve ser aceito ou não. Nesta tabela não é possível colocar regras para alterar algum parâmetro, como ip ou porta.

A tabela nat serve para realizar operações de tradução sobre IP e/ou porta, tanto de origem como de destino, muito embora também permita recusá-lo (não será abordada neste artigo).

Por fim a tabela mangle serve para realizar alterações mais profundas e bizarras nos pacotes, como alterar o TTL, TOS, etc (não será abordada neste artigo).

As ações operadas sobre um pacote basicamente podem ser recusá-lo ou deixá-lo passar, mas o iptables possui várias maneiras de "recusar" e ainda permite realizar logs. Como dito, operações de alteração de pacotes, seja IP ou porta, não pode ser realizada na tabela filter, mas sim na nat ou mangle.

Em termos de filtragem, para impedir que pacotes que não queremos entrem na máquina, é a tabela filter que nos interessa.

A tabela filter

Entram nesta tabela o conjunto de regras com finalidades gerais, como bloquear, negar, realizar logs. As regras existentes nesta tabela não tem poder de alterar as configurações dos pacotes. Basicamente todas as regras de filtragem estão nesta tabela, pois ela é de uso geral.

Para inserir uma regra em uma lista, pode-se usar -A para APPEND, inserindo-a no final, ou -I para INSERT, inserindo-a NO INÍCIO (a sintaxe profunda das regras não é o foco deste artigo).

A tabela filter possui três conjuntos de regras, ou seja, três listas sendo que cada uma delas está associada a um gancho:
  • INPUT: esta fila de regras recebe este nome justamente por ser aplicada aos pacotes na posição do gancho 4. Logo apenas os pacotes destinados ao ip da máquina atual serão avaliados por eventuais regras existentes nesta tabela. Sintaticamente para inserir regras nesta lista usa-se os parâmetros de iptables (o comando está incompleto):

    iptables -t filter -A INPUT [regra]

  • OUTPUT: esta fila de regras recebe este nome justamente por atuar no gancho 5 (também chamado pelo kernel de OUTPUT). Logo serão avaliados pelas regras presentes nesta lista apenas os pacotes originados por processos locais da máquina. Sintaticamente para inserir uma regra nesta lista usa-se o comando:

    iptables -t filter -A OUTPUT [regra]

  • FORWARD: esta fila de regras recebe este nome justamente por atuar no gancho 2 (também chamado pelo kernel de FORWARD). Logo serão avaliados por estas regras os pacotes que estão sendo repassados por esta máquina, não são para ela e nem originados por ela. Sintaticamente para inserir uma regra nesta lista usa-se o comando:

    iptables -t filter -A FORWARD [regra]

A tabela filter é a tabela básica do iptables e são em suas listas que devem ser inseridas regras de filtragens gerais, que não são complexas, como proibir ou permitir ips, portas, etc. Na Figura 3 pode ser observado a atuação do conjunto de regras desta tabela sobre os ganchos.



Cada regra pode realizar uma determinada ação ao pacote (representado graficamente por -j), sendo que na filter as seguintes ações são possíveis:
  • REJECT: o pacote, uma vez que casou com a regra, é rejeitado. Demais regras existentes são ignoradas e o pacote definitivamente já teve seu destino selado: será descartado. Se for usado REJECT o remetente do pacote será avisado com uma mensagem de erro, normalmente um ICMP de "porta inatingível" (mas o iptables permite ao usuário mudar o tipo de retorno se ele quiser). Em termos de segurança pode não ser interessante devolver uma resposta ao remetente, pois isto iria inevitavelmente dar a conhecer a ele o número IP do firewall.
  • DROP: o DROP tem o mesmo efeito do REJECT e a mesma aplicação, com a diferença de que não é retornado nenhuma mensagem de erro ao remetente (ele não saberá o que aconteceu com o pacote). Em se tratando de FORWARD (repasse) pode ser conveniente usar DROP ao invés de REJECT para que um possível atacante não saiba o IP do firewall que rejeitou o seu pacote. Mas isto deve ser bem analisado, pois se o remetente não souber o que ocorreu, ele poderá ficar ainda tentando várias vezes até desistir por time out. Se o teu firewall é o roteador principal, não tem porque escondê-lo, pois ele é um ponto de rota mesmo. Mas se ele for transparente (atuando em modo bridge), aí pode ser uma boa estratégia não dar nada ao remetente.
  • ACCEPT: Aceita um pacote, deixando que ele siga o seu percurso. O ACCEPT, como os anteriores, causa o término de teste nesta tabela, ou seja, o pacote já foi aceito e não será mais testado por nenhuma outra regra posterior nesta tabela (mas ainda poderá ser testado por outra tabela, como pela mangle ou nat, por exemplo. Acredito que o único exemplo onde isto possa acontecer é ele ser ACEITO no filter FORWARD, mas ser DROPADO no nat POSTROUTING, já que o nat tem também o poder de realizar DROP).
  • LOG: realiza um log deste pacote no sistema (geralmente no /var/log/syslog ou messages). Ao contrário das demais ações (DROP, ACCEPT e REJECT), ao aplicar um log no pacote o mesmo ainda continua sendo testado pelas regras seguintes da fila atual. Uma ação do tipo LOG não causa o término do teste. Caso seja do interesse do usuário ele pode configurar uma mensagem de log que aparecerá nos logs facilitando a análise.

Conclusão

Este artigo teve como motivação apenas mostrar a estrutura interna do iptables e não ensinar a escrever regras sintaticamente corretas e poderosas.

Através do entendimento correto de como o iptables atua, pode-se determinar onde e de que forma pacotes devem ser filtrados:
  • Se estou configurando um firewall pessoal, na minha máquina desktop ou no meu servidor, sendo que ela não é roteador: as regras para filtrar o conteúdo deverão ir na tabela filter, na lista INPUT para filtrar o que está entrando na minha máquina, destinada ao IP dela e na tabela filter, lista OUTPUT para os pacotes gerados pela minha máquina.
  • Se estou configurando um firewall de rede, que filtra todo o conteúdo que entra e sai da minha rede para o mundo: as regras irão todas na tabela filter, lista FORWARD. Para representar o destino (está entrando ou está saindo) posso usar o parâmetro -i interface ou -o interface (o FORWARD é o único que permite -i e -o na mesma regra, querendo dizer, se estiver entrando por aqui e saindo por ali...).
  • Se meu firewall é um firewall de rede, mas também possui alguns serviços nele, como proxy ou de email, devo inserir regras tando no filter INPUT/OUTPUT para definir a política dele enquanto servidor, como no filter FORWARD para proteger minha rede. Regras adicionadas no filter FORWARD não atuam sobre pacotes destinados ao número IP de uma máquina.
  • Se desejo alterar características de ip ou porta, trocando-as, devo usar a tabela nat e para isto preciso aguardar o próximo artigo. :-D

Créditos:
Elgio Schlemer
http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=6834&pagina=1

Tabela Filter - IPTABLES

FIREWALL COM IPTABLES

Tabela Filter

Vejamos o funcionamento da tabela filter (default) e as suas respectivas chains:

São três, as possíveis chains:

--> INPUT: utilizada quando o destino final é a própria máquina filtro;

--> OUTPUT: qualquer pacote gerado na máquina fltro e que deva sair para a rede será tratado pela chain OUTPUT;

--> FORWARD: qualquer pacote que atravessa o fltro, oriundo de uma máquina e direcionado a outra, será tratado pela chain FORWARD.

Regras de filtragem

As regras (rules) de fitragem, geralmente, são compostas assim:

#iptables [-t tabela] [opção] [chain] [dados] -j [ação]

Exemplo:

#iptables -A FORWARD -d 192.168.1.1 -j DROP

A linha acima determina que todos os pacotes destinados à máquina 192.168.1.1 devem ser descartados. No caso:

tabela: filter (é a default)

opção: -A

chain: FORWARD

dados: -d 192.168.1.1

ação: DROP

Existem outras possibilidades que fogem à sintaxe mostrada anteriormente. É o caso do comando #iptables -L, que mostra as regras em vigor.


Ações

As principais ações são:

ACCEPT --> Aceitar. Permite a passagem do pacote.

DROP --> Abandonar. Não permite a passagem do pacote, descartando-o. Não avisa a origem sobre o ocorrido.

REJECT --> Igual ao DROP, mas avisa a origem sobre o ocorrido (envia pacote icmp unreachable).

LOG --> Cria um log referente à regra, em /var/log/messages. Usar antes de outras ações.

Exemplos comentados de regras de filtragem (tabela filter)

---------------------------------------

#iptables -L

Lista todas as regras existentes.

---------------------------------------

#iptables -F

Apaga todas as regras sem alterar a política.

---------------------------------------

#iptables -P FORWARD DROP

Estabelece uma política de proibição inicial de passagem de pacotes entre sub-redes.

---------------------------------------

#iptables -A FORWARD -j DROP

Todos os pacotes oriundos de qualquer sub-rede e destinados a qualquer sub-rede deverão ser descartados.

---------------------------------------

#iptables -A FORWARD -j ACCEPT

Todos os pacotes oriundos de qualquer sub-rede e destinados a qualquer sub-rede deverão ser aceitos.

---------------------------------------

#iptables -A FORWARD -s 10.0.0.0/8 -d www.chat.com.br -j DROP

Os pacotes oriundos da sub-rede 10.0.0.0 (máscara 255.0.0.0) e destinados aos hosts cujos endereços IP respondem pelo nome www.chat.com.br deverão ser descartados. Note que se a máquina possuir domínios virtuais, todos esses serão bloqueados.

---------------------------------------

#iptables -A FORWARD -s 10.0.0.0/8 -d www.chat.com.br -j REJECT

Os pacotes oriundos da sub-rede 10.0.0.0 (máscara 255.0.0.0) e destinados aos hosts cujos endereços IP respondem pelo nome www.chat.com.br deverão ser descartados. Deverá ser enviado um ICMP avisando à origem.

---------------------------------------

#iptables -A FORWARD -d www.chat.com.br -j DROP

Os pacotes oriundos de qualquer lugar e destinados aos hosts cujos endereços IP respondem pelo nome www.chat.com.br deverão ser descartados.

---------------------------------------

#iptables -A FORWARD -d 10.0.0.0/8 -s www.chat.com.br -j DROP

Os pacotes destinados à sub-rede 10.0.0.0 (máscara 255.0.0.0) e oriundos aos hosts cujos endereços IP respondem pelo nome www.chat.com.br deverão ser descartados.

---------------------------------------

#iptables -A FORWARD -s www.chat.com.br -j DROP

Os pacotes oriundos aos hosts cujos endereços IP respondem pelo nome www.chat.com.br e destinados a qualquer lugar deverão ser descartados.

---------------------------------------

#iptables -A FORWARD -s 200.221.20.0/24 -j DROP

Os pacotes oriundos da sub-rede 200.221.20.0 (máscara 255.255.255.0) e destinados a qualquer lugar deverão ser descartados.

---------------------------------------

#iptables -A FORWARD -s 10.0.0.5 -p icmp -j DROP

Os pacotes icmp oriundos do host 10.0.0.5 e destinados a qualquer lugar deverão ser descartados.

---------------------------------------

#iptables -A FORWARD -i eth0 -j ACCEPT

Os pacotes que entrarem pela interface eth0 serão aceitos.

---------------------------------------

#iptables -A FORWARD -i ! eth0 -j ACCEPT

Os pacotes que entrarem por qualquer interface, exceto a eth0, serão aceitos.

---------------------------------------

#iptables -A FORWARD -s 10.0.0.5 -p tcp --sport 80 -j LOG

O tráfego de pacotes TCP oriundos da porta 80 do host 10.0.0.5 e destinados a qualquer lugar deverá ser gravado em log. No caso, /var/log/messages.

---------------------------------------

#iptables -A FORWARD -p tcp --dport 25 -j ACCEPT

Os pacotes TCP destinados à porta 25 de qualquer host deverão ser aceitos.

---------------------------------------

Créditos:
João Eriberto Mota Filho

Veja o artigo completo em http://www.eriberto.pro.br/iptables/

FIREWALL COM IPTABLES

2. GENERALIDADES

Sistemas de Firewall

Muitos não conhecem o verdadeiro significado do vocábulo firewall. Firewall é um sistema integrado, utilizado em redes de computadores para a sua proteção. Tal sistema é composto por filtros de pacotes, filtros de estados, IDS, IPS, proxies etc. Assim sendo, é errado dizer que uma máquina rodando Iptables é o firewall de uma rede. Isso por que o Iptables é um mero filtro de pacotes e estados. Assim sendo, só consegue analisar dados contidos no cabeçalho IP do pacote que trafega. Ele, por exemplo, não consegue verificar o conteúdo de um pacote. Com isso, um ataque ou um vírus poderão adentrar à rede.

A figura a seguir mostrará um exemplo de um sistema de firewall. A área cinza representa tal sistema.


É possível concluir que um único programa, como o Iptables, não constitui um firewall e sim parte dele. Um administrador de rede deve considerar o uso de outros elementos de segurança. RECOMENDO, DENTRE OUTROS, O USO DO IPS HLBR, DISPONÍVEL EM http://hlbr.sourceforge.net, juntamente com o Iptables. Se preferir, clique aqui para fazer download.

Filtragem de Pacotes

O Iptables é um filtro de pacotes. Essa filtragem poderá ocorrer em duas sitações:

--> diretamente em uma máquina de destino;

--> em uma máquina intermediária responsável pelo roteamento de dados entre segmentos de rede.

Vamos considerar a filtragem de pacotes no caso de controle do roteamento. Então, vamos configurar uma máquina capaz de tomar decisões em relação ao tráfego de rede. Assim, analisaremos o filtro de pacotes existente no Linux. Ele verifica apenas o cabeçalho de cada pacote. Basicamente, só entende endereço IP, máscara de sub-rede, portas e tipos de protocolos IP. Não analisa o conteúdo do pacote e nem identifica ataques.

A filtragem de pacotes é uma atividade interna do kernel.

Os filtros Linux

O filtro de pacotes, na maioria das vezes, atua como um roteador controlado. É uma atividade interna, uma propriedade, do kernel.

São os seguintes, os filtros existentes:

--> kernel 2.0.x: ipfwadm;

--> kernel 2.2.x: ipchains;

--> kernel 2.4.x: iptables;

--> kernel 2.6.x: iptables.

Obs: um kernel é estável quando o algarismo existente entre os dois pontos é par. Exemplo: x.2.x é estável. Já o x.3.x não é estável.

O Kernel 2.4, por questões de compatibilidade, mantém os filtros ipfwadm e ipchains. No entanto, eles não funcionam completamente com esse kernel. Além disso, se o ipchains estiver ativo, o iptables não irá funcionar. Assim, no Red Hat, torna-se necessário entrar no #setup e:

--> habilitar o iptables;

--> desabilitar o ipchains.

Se a distribuição utilizada não possuir o comando #setup, utilize o comando #rmmod ipchains. Cabe ressaltar que o iptables terá os seus módulos básicos carregados quando for utilizado pela primeira vez.

Como funciona um filtro de pacotes?

O FILTRO DE PACOTES do Linux funciona mediante regras estabelecidas. Todos os pacotes entram no kernel para serem analisados. As CHAINS (correntes) são as situações possíveis dentro do kernel. Quando um pacote entra no kernel, este verifica o destino do pacote e decide qual chain irá tratar do pacote. Isso se chama roteamento interno. Os tipos de chains irão depender da tabela que estaremos utilizando no momento. Existem 3 tabelas possíveis:

--> filter: é a tabela default. Quando não especificarmos a tabela, a filter será utilizada. Refere-se às atividades normais de tráfego de dados, sem a ocorrência de NAT. Admite as chains INPUT, OUTPUT e FORWARD.

--> nat: utilizada quando há NAT. Exemplo: passagem de dados de uma rede privada para a Internet. Admite as chains PREROUTING, OUTPUT e POSTROUTING.

--> mangle: basicamente, trabalha com marcação de pacotes e QoS. Neste tutorial, não trataremos dessa tabela.

O Iptables é stateful, ou seja, trabalha com os estados das conexões. O ipfwadm e o ipchais são stateless.

Créditos:

João Eriberto Mota Filho
www.eriberto.pro.br/iptables

IPTABLES

FIREWALL COM IPTABLES

1. IP FORWARD

Considerações iniciais

O IP FORWARD é um tipo de roteamento. É estabelecido quando colocamos uma máquina entre dois ou mais segmentos de rede, permitindo a livre passagem de pacotes entre estes sempre que for necessário. É importante ressaltar que o roteamento só irá funcionar quando for feito entre REDES DIFERENTES. Não se pode colocar um roteador entre dois segmentos de rede iguais. Esse procedimentonão serve apenas para estabelecer a comutação de segmentos. Ele também é útil para diminuir o tráfego na rede como um todo, pois só deixa o pacote mudar de segmento se isso for realmente necessário.

Veja a figura a seguir:

Para fazer o IP FORWARD, o micro roteador deverá possuir uma placa de rede com endereço IP pertencente a cada segmento. Também deveremos informar, em cada máquina de cada seguimento, quem será o micro responsável pelo roteamento. O nome técnico desse micro é gateway.

No caso do esquema anterior, temos as seguintes situações:

* Gateway para 10.0.0.1, 10.0.0.2 e 10.0.0.3: a máquina 10.0.0.10

* Gateway para 172.20.0.1, 172.20.0.2 e 172.20.0.3: a máquina 172.20.0.10

É importante que, nos dois lados, todos os micros saibam quem é o seu gateway pois, do contrário, os hosts não saberão para onde enviar os pacotes destinados à rede oposta. Exemplo:

A máquina 10.0.0.1 sabe que 10.0.0.10 é o seu gateway. A máquina 172.20.0.1 não sabe quem é o seu gateway. Um ping de 10.0.0.1 para 172.20.0.1 sairá de 10.0.0.1, passará por 10.0.0.10, seguirá por 172.20.0.10 e chegará em 172.20.0.1. Como 172.20.0.1 não sabe quem é o seu gateway para a rede 10.0.0.0, não conseguirá responder. O ping vai morrer por timeout. Houve o icmp echo request mas será impossível gerar o icmp echo reply.

Fazendo o IP FORWARD

Para estabelecermos o IP FORWARD entre dois segmentos de rede, basta:

* inserir um micro com duas placas de rede entre os segmentos de rede, configurando-as corretamente;

* definir, em cada máquina, de cada segmento, quem é o seu gateway;

* ativar o IP FORWARD via kernel.

O estabelecimento de IP FORWARD entre mais de dois segmentos de rede segue o mesmo princípio, bastando acrescer quantas placas de rede forem necessárias no gateway. Também é possível utilizar placas de fax-modem em conjunto com placas de rede.

Definindo o gateway

Para definirmos o gateway em cada cliente, devemos:

--> No Linux Red Hat/Fedora

Editar o arquivo /etc/sysconfig/network e inserir a linha:

GATEWAY=ip_do_gateway

Em seguida, devemos reiniciar a rede:

#/etc/rc.d/init.d/network restart

--> No Linux Slackware

Editar o arquivo /etc/rc.d/rc.inet1.conf e configurar a linha:

GATEWAY="ip_do_gateway"

Em seguida, devemos reiniciar a rede:

#/etc/rc.d/rc.inet1 restart

--> No Linux Debian

Editar o arquivo /etc/network/interfaces e inserir a linha:

gateway ip_do_gateway

Em seguida, devemos reiniciar a rede:

#/etc/init.d/networking restart

--> No Windows 9x

Nas Propriedades do protocolo TCP/IP, há uma seção gateway. Basta inserir o IP do gateway nessa seção. Exemplo:

--> No Windows XP

Nas Propriedades do protocolo TCP/IP, há uma entrada gateway. Basta inserir o IP do gateway. Exemplo:

--> Outras versões de Windows

Em outras versões de Windows, o procedimento é similar.

Ativando o roteamento via kernel no Linux

O roteamento via kernel será ativado com o comando:

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

Esse roteamento será perdido se a rede (e, em conseqüência, a máquina) for reinicializada (#/etc/rc.d/init.d/network restart).

Poderíamos inserir a regra no fim do arquivo /etc/rc.d/rc.local, para que a mesma seja ativada a cada reinicialização do sistema. No entanto, um reinício da rede mataria o roteamento novamente.

No Red Hat, uma forma de deixar a regra de roteamento permanentemente ativada, resistindo a qualquer tipo de reinicialização, seria a alteração do arquivo /etc/sysctl.conf:

net.ipv4.ip_forward = 1

Já no Debian, a linha a seguir deve ser inserida no arquivo /etc/sysctl.conf:

net/ipv4/ip_forward=1

Teste do roteamento

O teste do roteamento pode ser feito por intermédio do comando ping. Basta "pingar" uma máquina que esteja após o roteador.

Caso não haja resposta, faça um teste progressivo para tentar deduzir o problema:

--> pingue a placa do roteador que esteja dentro do seu segmento de rede;

--> pingue a placa do roteador que esteja no outro segmento;

--> pingue outra máquina do outro segmento.

O programa IPTRAF poderá ajudar a debugar a conexão. Execute a opção "IP traffic monitor" do citado programa na máquina roteadora e verifique se o ICMP echo request está saindo e se o ICMP echo reply está voltando. Se não voltar, o problema estará no segmento de destino do ping.



Créditos:
João Eriberto Mota Filho
http://www.eriberto.pro.br/iptables/

HTB-Tools: exemplos práticos de configuração

O HTB-Tools é uma excelente ferramenta de auxílio na configuração do HTB (Hierarchical Token Bucket) para limitação de uso de banda. Como o primeiro artigo sobre o HTB-Tools explicando o uso da ferramenta gerou muitas consultas e dúvidas dos leitores resolvi escrever uma pequena complementação. Agora vou dar exemplos mais concretos de configurações específicas de uso cotidiano.

SE VOCÊ NÃO SABE O QUE É HTB OU HTB-TOOLS LEIA O PRIMEIRO ARTIGO ANTES!

OS EXEMPLOS A BAIXO SÃO MERAMENTE ILUSTRATIVOS!

1. Download e Upload com taxas diferentes

Partindo do exemplo do próprio artigo vamos supor que os cliente deveriam ter a mesma taxa de download do exemplo, mas que o upload seria limitado à metade ou seja 96kbps e 128kbps para upload, garantidos e máximo,repectivamente.

Supondo que a sua interface LAN seja a mesma eth0 vamos controlar o upload/download criando o arquivo /etc/htb/eth0-qos.cfg com o seguinte conteúdo:

class Wireless {

bandwidth 480;
limit 512;
burst 2;
priority 1;

client cliente_1down {
bandwidth 192;
limit 256;
burst 2;
priority 1;
dst {
192.168.1.2/24;
};
};

client cliente_1up {
bandwidth 96;
limit 128;
burst 2;
priority 1;
src {
192.168.1.2/24;
};
};

client cliente_2down {
bandwidth 192;
limit 256;
burst 2;
priority 1;
dst {
192.168.2.2/24;
};
};

client cliente_2up {
bandwidth 96;
limit 128;
burst 2;
priority 1;
src {
192.168.1.2/24;
};
};

};
class default { bandwidth 8;};

Entendendo: Para o cliente_1 quando o tráfego se destinar (dst) a ele a taxa será de no máximo 256kbps, porém qualquer tráfego que se originar (src) do cliente_1 será limitado à 128kbps, ou seja o cliente_1 não vai conseguir enviar nenhum pacote a mais de 128kbps (taxa de upload). O mesmo vale para o cliente_2 que poderia estar limitado à outras taxas de forma independente. Por fim, a classe default destina 8kbps para todo o resto do tráfego não contemplado nas classes anteriores.

2. Compartilhando conexão a uma taxa fixa

Um caso comum que pode ocorrer é você ter uma boa conexão e um cliente quer um link mais dedicado com servidor próprio. Supondo que você tenha um link de 1Mbps e o cliente contrate 360kbps que deve ser compartilhados através de um servidor próprio do cliente (qualquer pentium 100 já serve). Vamos considerar que a interface WAN seja a eth1 e a LAN a eth0. Na LAN não será preciso nenhuma limitação, contudo para a interface WAN (eth1) criamos o seguinte arquivo de configuração - /etc/htb/eth1-qos.cfg :

class eth1-WAN {
bandwidth 100000;
limit 100000;
burst 64;
priority 1;
client WAN {
bandwidth 100000;
limit 100000;
burst 64;
priority 1;
dst {
X.X.X.X/X; # ip/máscara da sua rede WAN
};
src {
X.X.X.X/X; # ip/máscara da sua rede WAN
};
};

};

class eth1-WAN-cliente {
bandwidth 360;
limit 360;
burst 8;
priority 1;
client DEDICADO_1 {
bandwidth 360;
limit 360;
burst 8;
priority 1;
src {
0.0.0.0/0;
};
dst {
0.0.0.0/0;
};
};

};
class default { bandwidth 8; };

Entendendo: Dentro do arquivo eth1-qos.cfg temos duas classes especiais: eth1-WAN (client WAN) e eth1-WAN-cliente (client DEDICADO_1). A classe eth1-WAN estipula um limite de 100.000 kbps para tráfego para a sua própria rede (src e dst). A outra classe eth1-WAN-cliente vai limitar o tráfego para o "mundo externo" em 360kbps tanto para download (dst) quanto para upload (src). O que deve ser observado é que a classe eth1-WAN dá prioridade e libera a sua rede WAN para qualquer velocidade de tráfego enquanto a classe eth1-WAN-cliente limite todo o resto à 360kbps. O problema ocorre quando na LAN você tem diversos clientes concorrentes entre si pelos 360kpbs e ainda . Este caso é tratado em seguida.

3. Limitando apenas as conexões para a Internet

Uma caso muito frequente é quanto temos um gateway em nossa rede que além de compartilhar a Internet fornece aos usuários de nossa WAN/LAN outros serviços como servidor de arquivo, ftp, etc. Se limitarmos o tráfego de acordo com o primeiro exemplo conseguimos controlar o uso do link da Internet, contudo todos os outros serviços fornecidos pelo gateway também serão "estrangulados", tornado o uso da rede insuportável! O que fazer então? O segundo exemplo consegue resolver em parte nosso problema pois limita o tráfego globalmente apenas para conexões externas (WAN) e as conexões da LAN fluirão livremente. Mas por outro lado se tivermos qualquer serviço rodando pelo lado externo / WAN e que deve ser utilizado a partir de outra rede externa será limitado à 360kbps. Para resolver este problema existe duas alternativas: 1ª incluir as redes de onde serão acessados os serviços no "client WAN" da classe eth1-WAN (exemplo 2) ou 2ª limitar o tráfego apartir da interface da LAN (eth0), sem limitar o tráfego interno. A primeira alternativa pode se tornar um pouco inconveniente se os clientes/usuários externos acessarem de redes diversas. A segunda solução é a mais usual para a maioria dos casos. Então vamos deixar a WAN (eth1) com o tráfego liberado e faremos o controle de banda pela LAN (eth0), devemos criar o seguite arquivo /etc/htb/eth0-qos.cfg:

class eth0-LAN {
bandwidth 100000;
limit 100000;
burst 32;
priority 1;
client LAN-LAN {
bandwidth 100000;
limit 100000;
burst 32;
priority 1;
src {
X.X.X.X/X; # ip/máscara da sua rede WAN
192.168.0.0/24; # ip/máscara da sua rede LAN
};
dst {
X.X.X.X/X; # ip/máscara da sua rede WAN
192.168.0.0/24; # ip/máscara da sua rede LAN
};
};

client LAN0-WAN {
bandwidth 360;
limit 360;
burst 8;
priority 1;
dst {
0.0.0.0/0;
};
src {
0.0.0.0/0;
};
};

};

class default { bandwidth 8; };

Entendendo: Sempre que o destino ou a origem do tráfego for a nossa própria rede teremos uma taxa de 100.000kbps. Para todos os outros destinos e origens (0.0.0.0/0) estaremos limitando o tráfego à 360kbps.

4. Conclusão

A dupla HTB e HTB-Tools fazem a alegria de qualquer administrador de redes! @;)


Créditos:
wandersonsreis (a) gmail.com
http://www.wasare.net/home/node/17

Controle de Banda Descomplicado com HTB-Tools

O HTB (Hierarchical Token Bucket) é uma boa alternativa em
substituição ao CBQ (Class Based Queueing) pois este é mais preciso e
fácil de utilizar com o auxilio da excelente ferramenta HTB-Tools.

1. Introdução

O HTB (Hierarchical Token Bucket) é uma boa alternativa em
substituição ao CBQ (Class Based Queueing) pois este é mais preciso e
fácil de utilizar (será? Para mim foi). A diferença para o CBQ é que
ele aloca banda para uma ou mais classes ("links virtuais") e toma
emprestada temporariamente a banda de outra classe que não esteja sendo
utilizada completamente. Ainda diferentemente do CBQ você pode alocar
diversos clientes em uma mesma classe.

Para utilizar o HTB você precisa de um kernel maior ou igual 2.4.20
e da ferramenta tc (Traffic Control) incluída no pacote iproute2 sendo
requerido o pacote iproute2 >= 2.6.10-ss050124. Eu utilizei apenas o
Slackware 10.2 (kernel 2.4.31 ou kernel 2.6.13) com o pacote
iproute2-2.6.11_050330 (série n do slackware) instalado.

Para configurarmos o HTB temos basicamente três alternativas: Criar
um script com todos os comandos (se você souber quais é claro);
Utilizar o utilitário htb.init script semelhante ao cbq.init e que
demanda uma série de configurações, bem familiar para quem já utiliza o CBQ ou utilizar a ferramenta HTB Tools. Como eu quero simplificar e não tenho experiência com o CBQ optei pelo HTB Tools criada dentro da filosofia do Slackware.

2. Instalação

Faça o download do HTB-tools-0.2.7.tar.gz em:

http://htb-tools.arny.ro/download.php

Caso não goste de instalar manualmente e queira pular para a
configuração baixe o pacote no formato .tgz no mesmo link acima ou
em:

http://www.linuxpackages.net/pkg_details.php?id=8121

Descompacte o pacote com os fontes e execute:

root@ice:~# cd  HTB-tools-0.2.7 ; make ; make install

Para completar a instalação, execute os seguintes comandos:

root@ice:~/HTB-tools-0.2.7# mkdir -p /etc/htb
root@ice:~/HTB-tools-0.2.7# cp sys/scripts/rc.htb /etc/rc.d/rc.htb
root@ice:~/HTB-tools-0.2.7# cp sys/cfg/eth0-qos.cfg /etc/htb/eth0-qos.cfg
root@ice:~/HTB-tools-0.2.7# cp sys/cfg/eth1-qos.cfg /etc/htb/eth1-qos.cfg

Acima copiamos os arquivos de configuração de exemplo para as
interfaces eth0 e eth1 e o script de inicialização rc.htb.

Para o formato .tgz , execute apenas:

root@ice:~# installpkg HTB-tools-0.2.7-i486-1wsa.tgz

3. Configuração

Instalado o HTB Tools seu Slackware terá os executáveis:

  • q_parser - lê o arquivo de configuração onde os clientes, as
    classes, e a banda alocada é definida e gera um script conforme as
    configurações estabelecidas;
  • q_show - exibe em tempo real a banda usada/alocada para cada
    classe/cliente de acordo com a configuração;
  • q_checkcfg - verifica a sintaxe do arquivo de configuração;
  • htb - script que executa rotinas com os binários q_show,
    q_parser, q_checkcfg;
  • htbgen - utilitário para gerar arquivos de configuração para
    redes classes C.

Os arquivos de configuração ficam em /etc/htb. Utilizando o HTB
Tools conseguimos simplificar bastante a configuração e monitoramento
de alocação de banda tanto para upload como para download.

A grande sacada do criador do HTB Tools foi definir uma configuração
semelhante a do arquivo named.conf (quem nunca deu uma espiada?).

Vamos ao exemplo: você possue um link de 512kbps compartilhado entre
dois clientes , teoricamente cada um deveria ter 256kbps garantidos
(QOS), contudo você deixou a coisa frouxa e um dos clientes começa a
reclamar que o link está muito lento e que não consegue realizar
transações importantes. Não precisa dizer mais nada, o outro cliente
está "abusando" do link. A culpa não é dele, pois você deixou, não é
mesmo? Para resolver este problema vamos de fato distribuir o link da
seguinte forma: cada cliente terá 192kbps garantidos e no máximo 256kbps
para upload/download.

Supondo que a sua interface LAN seja a eth0 vamos controlar o
upload/download criando o arquivo /etc/htb/eth0-qos.cfg com o seguinte
conteúdo:

class Wireless {

bandwidth 480;
limit 512;
burst 2;
priority 1;

client cliente_1 {
bandwidth 192;
limit 256;
burst 2;
priority 1;
src {
192.168.1.2/24;
};
dst {
192.168.1.2/24;
};
};

client cliente_2 {
bandwidth 192;
limit 256;
burst 2;
priority 1;
src {
192.168.2.2/24;
};
dst {
192.168.2.2/24;
};
};


};

class default {
bandwidth 8;
};

Como podemos observar a configuração é auto explicativa. Mas para
não deixar dúvidas podemos observar que o src, como devemos suspeitar,
é o source ou seja a origem do tráfego, por tando estamos limitando a
saída (upload). No caso da diretiva dst controlamos o destino ou seja a
entrada (download). A estrutura básica pode ser resumida em uma classe
principal que é subdividida dentro de outras classes secundárias.
Quando existe mais de uma classe principal estas não compartilham banda
entre elas. As classes secundárias (clientes) podem compartilhar banda
entre elas de acordo com a configuração (limit maior). Cada classe
principal possue uma ou mais classes secundárias (clientes). A classe
especial default especifica uma banda para os outros clientes/tráfegos
que não estejam contemplados na configuração. A taxa de transferência e
dada em kbit por segundo(kpbs).

Para controlar o download/upload na eth1 basta criar um arquivo
semelhante ao /etc/htb/eth0-qos.cfg em /etc/htb/eth1-qos.cfg supondo
que a sua interface eth1 seja da outra LAN ou a própria WAN. Em
/etc/htb/eth1-qos.cfg crie a classe principal e as classes clientes
conforme as necessidades.

Em configurações mais complexas você pode especificar diversos IP's
ou redes (rede/máscara) dentro de uma mesma classe secundária entre as
chaves do src ou dst, sempre um(a) por linha e finalizado por um
ponto-e-vírgula. Agora caso você queira limitar a banda para um serviço
específico por exemplo ftp ou http dê um espaço e coloque a porta do
serviço (em src ou dst), assim :

...
dst {

192.168.3.0/24 21;
192.168.4.0/24 80;

};
...

Atenção: cuidado ao criar as classes pois estará limitando
todo o tráfego para aquele cliente/ip para todos os protocolos. Combine
várias classes e configurações até chegar ao controle ideal.

Antes de ativar o controle de banda é recomendável verificar a
sintaxe da configuração:

root@ice:~# q_checkcfg  /etc/htb/eth0-qos.cfg
root@ice:~# q_checkcfg /etc/htb/eth1-qos.cfg

4. Ativando o HTB

Para facilitar as coisas tornamos o rc.htb executável:

root@ice:~# chmod +x /etc/rc.d/rc.htb

Com este script não precisamos executar diretamente os binários do
HTB Tools. Para ativarmos o htb para a eth0 executarmos dentro de
/etc/rc.d:

root@ice:/etc/rc.d# ./rc.htb start_eth0

Faça o mesmo para eth1 obviamente fazendo a substituição necessária
de eth0 por eth1. Caso possua mais de duas interfaces altere o rc.htb
de acordo com suas necessidades. Estando tudo correto vamos cuidar para
que o HTB seja ativado a cada boot, acrescentando os comandos acima no
rc.local ou em outro script de inicialização de sua preferência.
Exemplo:

root@ice:/etc/rc.d# echo "/etc/rc.d/rc.htb start_eth0" >> /etc/rc.d/rc.local
root@ice:/etc/rc.d# echo "/etc/rc.d/rc.htb start_eth1" >> /etc/rc.d/rc.local

5. Monitorando o Controle de Banda

Iniciado o HTB, você pode monitorar o uso do link em tempo real,
para monitorar individualmente cada cliente fazendo upload ou download,
respectivamente, execute:

root@ice:/etc/rc.d# ./rc.htb show_eth0
root@ice:/etc/rc.d# ./rc.htb show_eth1

Dê uma olha no pacote HTB Tools e você ainda poderá lançar mão do
utilitário htbgen para gerar o arquivo de configuração via assistente e
terá uma forma de monitorar a utilização da banda pela web
(q_show.php). É mole ou que mais!

Espero que consigam descomplicar o controle de banda com HTB-Tools
assim como eu consegui.

Artigo publicado na SlackwareZine #9

Crédito:
wandersonsreis (a) gmail.com
http://www.wasare.net/home/node/2