Gateway autenticado com Apache, Iptables e CGI em shell

capitainkurn

Procurando uma solução que fosse ao mesmo tempo simples de ser implementada e de grande eficiência comparados aos gateways mais sofisticados que empregam bancos de dados e etc, cheguei a esta solução ideal para ser usada em provedores wireless ou a cabo. Ela ainda está em desenvolvimento e dada a sua enorme simplicidade de seu conceito pode servir de base para projetos mais elaborados.

[ Hits: 86.936 ]

Por: Carlos Affonso Henriques. em 27/07/2007

0 0

Denuncie Favoritos Indicar Impressora

A topologia da rede

Costumo fazer redes condominiais onde é necessário que os clientes não se enxerguem por meio da difusão de nomes netbios, por isso costumo atribuir cada IP de cada uma das estações em uma sub-rede separada, mas podemos fazer tudo em uma única separadas pelo domínio de broadcast de uma máscara de sub-rede alta 255.255.255.254 ou /31 por exemplo enquanto o gateway fica em uma máscara mais baixa 255.255.0.0 ou /16. em nosso exemplo usei a primeira técnica.

Então ficamos com o gateway configurado da seguinte forma:

interface interna: eth0 192.168.10.1/16 ou 255.255.0.0;
interfaces externas: eth1 sem IP atribuído e ppp0 obtida por um modem ADSL em modo bridge e um cliente PPPoE. Não mencionarei a configuração do pppoe pois não é o objetivo deste artigo e aqui mesmo no Viva o Linux há inúmeros artigos e dicas sobre isso.

Para simplificar nossa administração empregaremos um servidor DHCP onde o arquivo /etc/dhcpd.conf ficará da seguinte forma.

option domain-name "meudominiolocal.net";
# option domain-name-servers 200.149.55.142, 200.165.132.155; #telemar
# option domain-name-servers 200.184.26.10, 200.184.46.2; #intelig
option domain-name-servers 192.168.10.1; #Bind
ddns-update-style ad-hoc;
option routers 192.168.10.1;

subnet 192.168.0.0 netmask 255.255.0.0 {
        ddns-updates on;
        default-lease-time 86400;
        max-lease-time 150000;
        deny unknown-clients;

host ap101            {hardware ethernet 00:1B:24:13:EF:78;option subnet-mask 255.255.255.254;fixed-address 192.168.10.10;}
host ap102              {hardware ethernet AA:1C:D3:54:32:91;option subnet-mask 255.255.255.254;fixed-address 192.168.11.10;}
host ap201              {hardware ethernet 00:11:5B:26:A3:23;option subnet-mask 255.255.255.254;fixed-address 192.168.12.10;}
}

Atentem para o parâmetro "option domain-name-servers 192.168.10.1; #Bind", é que implemento um DNS cache no próprio gateway, porém não mencionarei neste artigo pelos mesmos motivos que citei acima.

Leiam minha dica sobre uma maneira diferente de escrever o /etc/dhcpd.conf em:

Uma maneira diferente de escrever o dhcpd.conf

Quando trabalhamos com um número elevado de subredes pode ocorrer o neighbor table overflow, não se assustem com isso, a solução está em uma dica minha aqui mesmo no VOL em:

Eliminando o Neighbour table overflow

Página anterior Próxima página

Páginas do artigo

   1. Preparando o Apache
   2. Configurando o SSL no Apache
   3. A topologia da rede
   4. O firewall
   5. A página de autenticação
   6. O arquivo de contas
   7. O script CGI de autenticação
   8. O script para desfazer a autenticação
   9. A tabela ARP estática
   10. O controle de banda
   11. Notas e agradecimentos

Outros artigos deste autor

O que é ForceCommand

Debian sem Systemd

Access Point com cartão Atheros em Slackware 12.0

Enviando e-mail pelo shell com smtp remoto

Sistema de arquivos criptografado

Leitura recomendada

Quão segura é a sua senha?

Resenha do livro: Praticando a Segurança da Informação

Backup gerenciável usando tar

Entendendo o que é Engenharia Social

Melhorando a segurança do seus servidores em FreeBSD

Comentários

[1] Comentário enviado por removido em 27/07/2007 - 15:57h

Olá Amigo,

Bom, para deixar seu artigo ainda mais rico eu gostaria de dar uma opinião! No caso de um hijack bem feito (roubo de seção), quando o cliente cai e em seguida entra o hijack seu arping vai consultar ele tranqüilamente! Concorda!? Espero que sim, pois eu já fiz testes com isso e infelizmente da certo! A solução é simples, ao invés de fazer o servidor consultar quem está de pé ou não, o que dependendo do número de estações tem um tempo elevado, eu sugiro mudar para o comando at. Como já uso o servidor Radius, foi fácil, no comando AT eu agendo uma verificação pra saber se o IP tal é do fulano de tal conectado no radius, aí sim, se não for a regra dele é derrubada! Pra substituir o uso do radius, pode-se pensar em cookie, por exemplo!

T+

0 0

[2] Comentário enviado por capitainkurn em 27/07/2007 - 17:50h

Boa! nem havia me ocorrido o at.

Quando elaborei aquele while de arping, pensei em coloca-los isoladamente rodando sob um shell filho do mac_accept4.cgi que seria chamado em background, mas esbarrei em um problema... não entendí ainda o por que de não conseguir rodar um loop em um shell filho a partir de um CGI, mas é uma coisa que estou bolando e a sua idéia do at foi grande.
Obrigado pela dica, e espero que tenha gostado do artigo.

0 0

[3] Comentário enviado por fabiorvs em 22/04/2008 - 19:07h

Ola tem como fazer a autenticação só por usuário, sem o MAC e ip, pois trabalho em uma faculdade e preciso cadastrar todos os alunos.

0 0

[4] Comentário enviado por capitainkurn em 23/04/2008 - 10:03h

É mais fácil ainda, a única razão para eu atrelar o ip ao mac address é o controle de banda, pois provedores em geral possuem planos de velocidade diferentes e se não houver vínculo entre o IP e o login e senha o usuário poderia configurar um IP manualmente e usar uma velocidade maior do que a contratada.

0 0

[5] Comentário enviado por cleibson em 03/05/2009 - 22:57h

Como o cliente será diretionado para autenticação, sendo que não há nenhuma regra redirecionando sua navegação para a porta 443 obrigando-o a autenticar antes de navegar

0 0

[6] Comentário enviado por removido em 06/05/2010 - 09:29h

òtima dica para o combate de ataques do TIPO MITM, originados por arpspoof.

0 0

[7] Comentário enviado por douglassironi em 28/06/2011 - 18:38h

Sobre a questão de atrelar MAC, podemos fazer isso com PHP, no momento que o cliente se cadastra e cria seu usuario e senha, podemos tranquilamente pegar o MAC dele com a função, abaixo tem um link explicando como fazer.

http://scriptbrasil.com.br/forum/index.php?showtopic=70543

No momento que o usuario/cliente se cadastrar, pode ser gerado o arquivo do DHCP atrelando um ip para o mac capturado.

Recomendo ultilizar um banco de dados para salvar as informações dos clientes/usuarios.
O freeradius tem as tabelas prontas em vários tipos de BD.

Qualquer duvida, estou a disposição.
contato@douglassironi.com

0 0