90% dos sites estão Vulneráveis

No final do mês passado (23/04/12) foi divulgada uma interessante pesquisa feita pela Trustworthy Internet Movement (TIM) à respeito da segurança em diversos sites da Internet.

Foram analisados sites de redes sociais, instituições financeiras, e-commerce, etc. Os testes consistiam basicamente em testar a segurança da criptografia usada nesses sites (SSL e TLS em todas as verões). Foram analisados aproximadamente 200.000 sites e, surpreendentemente, 90% dos sites não foram robustos o suficiente para impedir que informações sensíveis fossem capturadas através de ferramentas de captura de tráfego e quebra de criptografia.

Detalhes da pesquisa: https://www.trustworthyinternet.org/ssl-pulse/

É uma boa pesquisa para ficarmos alertas quanto a segurança dos serviços que usamos ou servimos aos nossos clientes. Obviamente a captura de informações desse tipo é um pouco complexa para uma pessoa normal, porém algo trivial para um especialista em Segurança da Informação.

Recentemente fui contratado para um Pentest e fiz um teste semelhante em uma das redes privadas com cerca de 10 usuários. Estendi o teste durante 1 hora e, surpreendentemente, consegui coletar informações sensíveis de todos os usuários que usaram essa rede durante o período.

As dicas que recomendo para evitarmos a captura das nossas informações sensíveis:

- Evite, ao máximo, usar qualquer rede aberta, pública e compartilhada.

- Se precisar usar uma rede compartilhada, jamais acesse sites com suas informações pessoais. Para ser bem claro, não coloque sua senha em nenhum site ou serviço.

- Aquela rede Wireless aberta do seu visinho pode não ser apenas um Access Point mal configurado. Pode estar aberta de propósito. : )

- Caso precise de Internet para o seu note em "qualquer lugar", compre um modem 3G com um plano que lhe atenda. Existem planos bem acessíveis e certamente mais baratos que o prejuízo possível caso suas informações sejam comprometidas.

Jboss 7.1 + CentOS 6.2

Buenas!

Pessoal, por esses dias precisei fazer uma implementação do Jboss 7.1 em cima de um CentOS 6.2 x86_64.

Bom, dei uma olhada na net se já havia alguma documentação mais prática para esse cenário, como não encontrei algo atualizado resolvi compartilhar meus passos.

Basicamente os passos são:

1 - Instalação mínima do CentOS

2 - Instalação de algumas dependências.

3 - Instalação do JDK.

4 - Instalação do Jboss.

5 - Configuração do serviço Jboss.

6 - Configurações do Jboss.

1 - Instalação mínima do CentOS.

Basicamente é instalar o SO sem qualquer pacote desnecessário. No menu de instalação do CentOS existe a opção "Minimal". Escolha ela e mande bala.

2 - Instalação de algumas dependências.

Esse ponto é opcional, mas eu costumo fazer para facilizar o trabalho e agora e posteriormente.

yum install vim tcpdump iptraf wget gunzip

yum upgrade

3 - Instalação do JDK.

Pode ser usado o OpenJDK ou o JDK da Sun. Eu preferi colocar o JDK da Sun devido a maior demanda deste por parte dos programadores que conheço.

- Download do JDK:

wget http://download.oracle.com/otn-pub/java/jdk/7u3-b04/jdk-7u3-linux-x64.rpm

Essa é a última versão enquanto escrevo esse artigo.

- Instale o RPM:

rpm -ivh jdk-7u3-linux-x64.rpm

Ele deve instalar a estrutura principal em /usr/java/jdk*

OBS.: Onde eu coloco *, ajuste de acordo com o nome correto da pasta.

Uma prática legal é criar link simbólico padrão para o jdk. Dessa forma, sempre que precisar atualizar bastará alterar o link. Nesse exemplo criei uma pasta em /opt chamada java:

mkdir /opt/java

Dentro dessa pasta criei um link para o jdk instalado.

cd /opt/java

ln -s /usr/java/jdk* jdk

- Criar as variáveis de ambiente

cd /etc/profile.d

Cria o arquivo java.sh  e colocar o conteúdo abaixo:

vim java.sh

################

JAVA_HOME=/opt/java/jdk
PATH=$PATH:$JAVA_HOME/bin
CLASSPATH=$JAVA_HOME/lib
LD_LIBRARY_PATH=$JAVA_HOME/jre/lib/amb64

export JAVA_HOME PATH CLASSPATH LD_LIBRARY_PATH

################

chmod 755 java.sh

4 - Instalação do Jboss

- Fazer o download da última versão:

 wget http://download.jboss.org/jbossas/7.1/jboss-as-7.1.1.Final/jboss-as-7.1.1.Final.zip

- Descompacte em um lugar de sua escolha:

No meu caso decompactei em uma área reservada montada em /storage

cd /storage

gunzip jboss-as-7.1.1.Final/jboss-as-7.1.1.Final.zip

Assim como o JDK, criaremos um link para essa pasta:

cd /opt/java

ln -s /storage/jboss-as-7.1.1.Final jboss

- Criar as variáveis de ambiente:

cd /etc/profile.d

Criar o arquivo jboss.sh e colocar o conteúdo abaixo:

vim jboss.sh

################

JBOSS_HOME=/opt/java/jboss
PATH=$PATH:$JBOSS_HOME/bin

export JBOSS_HOME PATH

################ 

chmod 755 jboss.sh

- Criar usuário para executar o Jboss:

useradd jboss

passwd jboss

5 - Configuração do serviço Jboss. 

Esse passo é para criarmos um script de inicialização do Jboss, ou seja, padronizarmos a aplicação.

O próprio Jboss já vem com o exemplo de script para o init.d, usaremos ele fazendo apenas alguns ajustes.

cd /etc/init.d

cp -a  /opt/java/jboss/bin/init.d/jboss-as-standalone.sh jboss

Agora precisamos apenas ajustar a variável JBOSS_HOME nesse script. Ela fica na linha 28.

vim jboss

JBOSS_HOME=/opt/java/jboss

A documentação oficial sugere a criação de uma pasta para colocar o conf de inicialização:

mkdir /etc/jboss-as

cd /etc/jboss-as

cp -a /opt/java/jboss/bin/init.d/jboss-as.conf .

OBS.: Isso não influencia no funcionamento do Jboss. É apenas para o script de inicialização.

Nesse arquivo, apenas descomentei a variável JBOSS_USER colocando o usuário criado para o jboss.

No meu caso:

JBOSS_USER=jboss

- Criar entrada no chkconfig:

chkconfig --add jboss

chkconfig jboss on

6 - Configurações do Jboss.

 

Por último precisamos ajustar as permissões de acesso ao Jboss.

Inicialmente basta publicarmos a console de gerenciamento dele para uma interface acessível remotamente.

OBS.: Por padrão ela vem publicada apenas em localhost.

cd /opt/java/jboss/standalone/configuration/

vim standalone.xml

Perto da linha 275 edite o endereço das interfaces "public" e "management":

################

    <interfaces>
       <interface name="management">
           <inet-address value="${jboss.bind.address.management:0.0.0.0}"/>
        </interface>
        <interface name="public">
            <inet-address value="${jboss.bind.address:0.0.0.0}"/>
        </interface>
        <!-- TODO - only show this if the jacorb subsystem is added  -->
        <interface name="unsecure">
            <!--
              ~  Used for IIOP sockets in the standard configuration.
              ~                  To secure JacORB you need to setup SSL
              -->
            <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
        </interface>
    </interfaces>

################

Assim você já conseguirá acessar e usar o seu jboss, mas ainda aconselho fortemente ler as dicas de segurança no endereço abaixo (em referências).

Pessoal, desculpe se eu esquecer algum detalhe mas escrevi bem rápido com a maioria das informações de cabeça (fiz a instalação esses dias). Se lembrar de mais alguma informação vou colocando aqui e se verificarem que esqueci algo, por favor, fiquem a vontade para contribuir.

Em breve pretendo publicar algo sobre hardening em Jboss.

Abraço!

Referências adicionais:

https://docs.jboss.org/author/display/AS7/Admin+Guide#AdminGuide-WebManagementInterface

http://thewiki4opentech.org/index.php/How_to_install_JBoss_AS_in_CentOS_/_RedHat_/_Fedora

Boas Práticas de Segurança - Apache

Seguem algumas boas práticas de Segurança para protejer um servidor apache.

Fiz todos os testes com uma distro CentOS Linux.

Remover página de teste (Welcome)

1 - Edite o arquivo /etc/httpd/conf.d/welcome.conf.

2 - Comente todas as linhas desse arquivo.

#
#    Options -Indexes
#    ErrorDocument 403 /error/noindex.html
#

3 - Recarregue a configuração do apache: /etc/init.d/httpd reload

Personalizar página default para endereço não publicado

1 - Acesse o diretório /etc/httpd/conf.d e crie um arquivo de configuração seguindo o exemplo abaixo:

# vim security.conf

    Options -Indexes
    ErrorDocument 403 /error/security.html

    Options -Indexes
    ErrorDocument 403 /error/security.html

2 - Depois é só criar e personalizar a página security.html

Desabilitar versão do Apache

1 - Edite o arquivo httpd.conf

2 - Modifique a linha ServerTokens para:

ServerTokens Prod

3 - Recarregue as configurações do apache.

http://httpd.apache.org/docs/current/mod/core.html#servertokens

Desabilitar assinatura do servidor

Quando uma página que não existe é acessada, por exemplo, o apache mostra uma página de erro default com informações do servidor, porta, etc.

Não há nenhuma necessidade disso ser mostrado.

1 - Edite o arquivo httpd.conf.

2 - Modifique a linha ServerSignature para:

ServerSignature Off

3 - Recarregue a configuração do apache.

http://httpd.apache.org/docs/current/mod/core.html#serversignature

Desabilitar Trace

1 - Edite o arquivo httpd.conf.

2 - Adicione a linha abaixo no final do arquivo:

TraceEnable Off

3 - Recarregue a configuração do apache.

http://httpd.apache.org/docs/current/mod/core.html#traceenable

Negar acesso ao /

1 - Edite o arquivo httpd.conf.

    Options FollowSymLinks
    AllowOverride None
    Order Deny,Allow
    Deny from all

OBS.: Se tiver mais algum diretório que não precise ser publicado, bloqueie também.

Bom, conforme eu for me lembrando de mais dicas, vou colocando aqui.

Caso alguém tenha mais dicas, por favor, fique a vontade para comentar.

Abraço!

Segurança em Firewalls 2012

Boa noite pessoal!

Gostaria de divulgar também aqui no blog a turma do Curso de Segurança em Firewalls de 2012.

Trata-se de um curso completamente desenvolvido por mim no final de 2008. Desde lá o curso vem recebendo um gratificante feedback dos alunos e um ótimo reconhecimento no mercado por se tratar de um curso ímpar e completamente voltado a prática.

A grade, a qual venho atualizando de acordo com realidade, segue no link abaixo para maiores detalhes de datas, assuntos, etc:

http://www.scribd.com/doc/76481616/Grade-Seguranca-em-Firewalls-2012

Essa turma de 2012 ainda está com 3 vagas em aberto caso alguém tenha interesse em participar. Devido a alguns projetos pessoais e profissionais lamento informar que não tenho previsões de novas turmas para os próximas anos.

Caso tenham interesse no curso ou qualquer dúvida, por favor, entre em contato.

Gostaria de desejar um Feliz Natal e um excelente 2012 para todos.

Abração!

Roubo de avião militar em pleno vôo

Bom dia!

As vezes demoro para atualizar o blog, outras vezes coloco um monte de posts ao mesmo tempo, mas o importante é que ainda está ativo e sempre que possível colocarei informações interessantes.

Essa manhã, lendo alguns informativos de Segurança fiquei surpreso com a audácia descrita em uma notícia.

Trata-se de um sequestro de um avião militar americano em pleno vôo.

Idenpendente de quais governos estejam envolvidos, o que eu gostaria de destacar foi a forma que o sequestro foi realizado. Isso é o que chamo de "técnicas de ponta". O que não se discute nesse caso é a enorme habilidade de quem (possivelmente uma equipe) executou o ataque.

Segundo a fonte, um especialista iraniano conseguiu cortar a comunicação do sistema de GPS do avião com a base. Em seguida conseguiu fazer um update do programa de rotas que direcionou a nave para uma base iraniana. O plano inicial era que pousasse em uma base americana, no Afeganistão.

O mais impressionante é que a nave está intacta. Caso queiram ver mais detalhes, no final coloquei a fonte dessa notícia, a qual já deve ser encontrada em outras fontes também.

Confesso que fiquei preocupado com essa notícia. Se vermos a história da segurança da informação, é comum tecnologias militares chegarem aos civís depois de um certo tempo (cada vez menor). A diferença é que os sistemas comerciais normalmente seguem padrões de segurança mais tênues que no meio militar e, infelizmente, é comum ser controlado por profissionais não tão qualificados para aquela tecnologia. É a partir daí que começa minha preocupação. Sempre que uma nova forma de ataque, fraude, crime, etc é publicada, a curiosidade dos mal-intencionados, assim como dos bem intencionados é instigada e, com certeza, em proporções diferentes.

Segundo os donos do avião, isso foi um "acidente" e continuarão usando o sistema. Concordo que acidentes sempre podem acontecer. Mas acredito que em determinadas profissões com determinadas responsabilidades alguns "acidentes" de determinadas proporções simplesmente não podem acontecer. Devemos tomar todas as providências cabíveis antes que algo pior aconteça.

Fonte da notícia: http://www.csmonitor.com/World/Middle-East/2011/1215/Exclusive-Iran-hijacked-US-drone-says-Iranian-engineer-Video

Ataques e Invasões - Uma abordagem jurídica

Bom dia!

Pessoal, estou fazendo esse post para um artigo bem interessante escrito pela Advogada Gisele Truzzi, especializada em direito digital. Ela esclarece algumas dúvidas jurídicas quanto a ataques e invasões.

Recomendo a leitura:
http://www.truzzi.com.br/blog/2011/06/23/grupo-lulzsecbrazil-e-o-ataque-aos-sites-da-presidencia-e-da-receita-federal/

Grande abraço!

Palestra FISL 12

Boa noite pessoal!!

Bom, primeiramente eu gostaria de agradecer a todos que votaram para que minha palestra fosse ao FISL 12 e aos que estiveram presentes na apresentação. É sempre uma grande satisfação poder contribuir de alguma forma e por 3 anos consecutivos com ideias e conhecimentos, ainda mais em um evento do porte do FISL. Realmente muito obrigado!!

O título da minha palestra foi "Ultrasurf - Entendendo e Bloqueando". Apresentei ela na quinta-feira (30/06), as 13 horas no Auditório do Prédio 11.

A ideia da apresentação foi explicar didaticamente como funciona a técnica de tunelamento e após isso passar a ideia da importância de termos políticas restritivas em ambientes que precisamos realmente controlar os acessos e garantir a Segurança da Informação.

Os slides podem ser vistos no seguinte link:
http://www.slideshare.net/marcusburghardt/ultrasurf-entendendo-e-bloqueando
 ou
http://www.scribd.com/doc/59260776

Qualquer dúvida, por favor, poste aqui ou me mande por e-mail.

Grande abraço!

Curso - Segurança em Firewalls

Boa tarde!

No próximo sábado (03/06) iniciarei uma nova turma do Curso de Segurança em Firewalls na FTEC Caxias do Sul. O curso está em sua quarta turma e possui um histórico bastante positivo.

No momento ainda estou com 1 vaga em aberto. Quem tiver interesse, por favor, entre em contato pelo meu e-mail que mando maiores detalhes.

ABAIXO COLOQUEI ALGUNS DOS TÓPICOS ABORDADOS:


Relação entre firewall e camadas do modelo TCP/IP.
Filtros de pacotes.
Como funcionam?
Quais as funções?
Papel do kernel.
Evolução dos filtros de pacotes no Linux.
Ipfwadm.
Ipchains.
Iptables.
Nftables (futuro).
Iptables.
Tabelas do iptables.
Tabela FILTER.
Fluxos da tabela.
Entendendo e praticando a tabela Filter.
Sintaxe de comandos.
INPUT/OUTPUT.
FORWARD.
CHAINS.
Extensões do Iptables.
Categorias de Firewalls.
Firewall Bridge.
Firewall StateLess.
Firewall StateFull.
Estados de conexões.
Firewall Proxy.
Tabela NAT
Conceitos de NAT.
Conceitos de PAT.
Fluxos da Tabela.
Tipos de NAT.
PREROUTING.
POSTROUTING.
MASQUERADE.
REDIRECT.
Vantagens e desvantagens de NAT.
Principais aplicações.
Tabela MANGLE
Campo TOS.
Customizando conexões.
Preparando pacotes para QoS.
Tabela RAW.
Rastremento de pacotes.
Otimizando conexões de alta disponibilidade.
Exploração de todos os módulos do Iptables.
Ataques x Defesas.
Conceitos de ataque.
Ataques locais.
Ataques remotos.
Ataques remotos.
Ataques de spoofing.
Ataques de flood.
ICMP Flood.
SYN Flood.
Ataques DoS.
Ataques DdoS.
Ataques RDDoS.
Ataques de Estado.
Ataques locais.
Exploits
Juntando ataques locais com ataques remotos.
Criando uma botnet.
Aplicando um exploit remotamente.
Burlando firewall com protocolo SSH.
Scanner de Rede
NMAP
Tácnicas de Scan e exploração de informações.
Dicas e exemplos de técnicas de Incident Response.
Introdução ao ISA Server 2006.

Grande abraço!

Palestra TcheLinux FTEC 2010

Olá!

Nesse final de semana (19/06/10) ocorreu na FTEC Caxias do Sul o evento TchêLinux, o qual fui palestrante.

Conforme comentei com o pessoal, estou disponibilizando aqui no Blog a palestra e os scripts usados na apresentação.

A palestra intitulada "Técnicas Avançadas de Segurança com Iptables" foi apresentada previamente no Forum Internacional do Software Livre 10º Edição e mostrei técnicas não tão comuns e muito interessantes para aplicar defesas na estrutura de Firewalls.

Baixar apresentação e scripts:

https://docs.google.com/uc?id=0B6WjflOn-lVFN2FlNTA4NjYtY2ZjYi00NDQwLThiYWItMGJhYzVhZDM5MDg2&export=download&hl=en

Video da palestra gravada no 10º Forum Internacional do Software Livre:

Lembrando que no dia 03/07/10 iniciarei uma turma do Curso de Segurança em Firewalls na FTEC Caxias do Sul. Ainda estou com algumas vagas em aberto...

Qualquer dúvida, por favor, entre em contato.

Grande abraço!

Squid + AD + Kerberos - Uma solução decente.

Buenas!!

Após um tempinho de correria voltei para publicar aqui mais uma ótima solução para nosso dia-a-dia.
Todos conhecem Squid e todos conhecem AD.

É muito comum termos organizações com as bases de usuários totalmente centralizadas no AD. Isso é fato.
Porém sempre houve uma dificuldade de se implementar ótimos proxies como o Squid por motivos que não nos estressam, mas estressam os usuários. O maior exemplo disso é a maldita janela de autenticação.

O motivo!
Em uma estrutura que administro, após uma mudança de topologias de Firewall precisei instalar proxies em cada filial (antes todas usavam o proxy da Matriz).

A opção!
Obviamente a solução de proxy escolhida para as filiais foi o Squid. Há quem diga que ele não é bom, mas basta ler e estudar suas funcionalidades que rapidamente achará diferenciais que colocam outros proxies vários anos atrás. O que você prefere para suas soluções? Algo fácil e medilcre ou a melhor e mais segura solução mesmo que você precise estudá-la e entendê-la? Estudar não mata ninguém!! O que ferra é o "profissional" ter a cara de pau de implementar algo "nas coxas" mesmo sabendo que podia ser melhor. Mas cada caso é um caso. No meu caso essa foi a MELHOR solução. : )

O problema!
Todos os usuários estavam acostumados com uma estrutura completamente integrada, onde a única vez que ele precisava colocar sua senha para serviços de rede era na autenticação do Windows. Todo o resto era feito através de kerberos, o que particularmente acho muito interessante. Para que fazer trabalho repetitivo se o objetivo final é o mesmo?
Outro fato é que essa solução de Squid integrado com Kerberos, AD e fazendo controles baseados em usuários e grupos é muito difícil de ser encontrada até mesmo pela sua complexidade. Não basta dar um "rpm -ivh" e fazer algumas configurações que o negócio saí funcionado. Isso seria ótimo!!! Até tive uma idéia: Vou mandar um e-mail para o pessoal do Squid e/ou gerar os pacotes para as distros que uso.

A solução!
Bom, vamos dar um jeito de fazer isso funcionar de forma profissional. Gambiarras qualquer um consegue fazer. Vamos fazer algo um pouco mais decente do que os preguiçosos costumam fazer... hehehehe Não é nada pessoal com ninguém, mas para o seu próprio bem, espero que o chapéu não sirva... e por favor, se alguém achar uma solução ainda melhor compartilhe. Sempre temos algo para aprender com os próximos.
Também é fato que muitos profissionais bons nem mesmo sabiam dessa possibilidade. Não devemos julgar ninguém ainda mais de forma preconceituosa. Para isso estou colocando a solução aqui. Algo construtivo.

Importante: Não é integração com LDAP, isso é fácil e está cheio de tutorial na Internet. Isso é Kerberos!

Resumo:
Basicamente faremos uma compilação da última versão do squid pois nas versões das oferecidas pelas distros (testei em CentOS) não vem com o módulo de integração com kerberos.
Depois vamos baixar e compilar um módulo bem interessante para fazermos buscas de grupos e usuários através de kerberos.
Por fim vamos ajustar nosso SO para se comunicar com o servidor kerberos e criar um arquivo de credenciais para consultas vindas do Squid.
Se tudo funcionar legal você pode pedir aumento, replicar a solução, abrir uma cerveja, pagar um churras para os amigos (me chama), etc etc... Como preferir.


Let's Start!!

FQDN do meu servidor Squid: squidserver.macus.net
FQDN do meu servidor AD: adserver.marcus.net
Distro Linux: CentOS 5.5 x86
Versão AD: 2008 R2

Preparando o Squid
Fiz o download da última versão do Squid no site http://www.squid-cache.org/. Antes do download dê uma olhada se já não tem uma versão mais nova.

$ wget http://www.squid-cache.org/Versions/v3/3.1/squid-3.1.4.tar.gz

$ tar -xvzf squid-3.1.4.tar.gz
$ cd squid-3.1.4

As opções em negrito são importantes na hora de compilar, pode colocar outras se quiser...
$ ./configure --enable-negotiate-auth-helpers=squid_kerb_auth --enable-stacktraces --prefix=/opt/squid-3.1

$ make
$ make install


Antes de configurarmos nosso Squid vamos fazer os outros procedimentos que ele depende.

Compilando módulo de consulta em grupos por Kerberos
Bem interessante esse módulo, mas infelizmente não vem nativamente no Squid.

$ cvs -z3 -d:pserver:anonymous@squidkerbauth.cvs.sourceforge.net:/cvsroot/squidkerbauth co -P squid_kerb_ldap
$ cd squid_kerb_ldap
$ ./configure ; make
$ cp -a squid_kerb_ldap /opt/squid-3.1/sbin


Gerando o Keytab pelo Windows
Para que o Squid consiga trocar tickets com o servidor kerberos, o mesmo precisa de credenciais para isso. Não temos como ficar autenticando o squid manualmente a cada incialização do mesmo, por isso vamos criar um arquivo keytab e adicioná-lo no nosso arquivo de inicialização do Squid.

Esse processo pode ser feito pelo próprio Linux usando o msktutil, mas encontrei alguns problemas nele quando o servidor Squid não está no domínio. Como não vou colocar ele no domínio usei a própria ferramenta do Windows 2008 (AD) que é nativa no SO.

Antes de gerar o keytab é necessário criar um usuário no AD que será cadastrado nessas credenciais.
No meu caso criei o usuário "squid.filial" e rodei o seguinte comando no meu PDC.

C:\> ktpass -princ HTTP/squidserver.marcus.net@MARCUS.NET -mapuser marcus.net\squid.filial -crypto All -mapop set -pass senha -ptype KRB5_NT_SRV_HST -out squid.filial.keytab

Mande o arquivo keytab gerado para o servidor Squid. No meu caso coloquei na pasta /opt/squid.


Em alguns materiais da Internet o pessoal usava criptografia "rc4-hmac-nt", mas tive alguns problemas com autenticação. Dei uma pesquisada por cima e encontrei algumas referênias dizendo que no Windows 7 e 2008 foram alteradas algumas questões de criptografia. Com o all todos os serviços funcionaram legal. Algo interessante é usar o Wireshark para monitorar as requisições de tickets entre cliente e servidor.

Adicione as estradas do keytab no script de inicialização do Squid.
Caso não tenha o script de inicialização do mesmo, aconselho pegar de um pacote do squid específico da distro.

De volta ao Linux
No arquivo /etc/init.d/squid adicione as seguintes linhas:

KRB5_KTNAME=/opt/squid/squid.filial.keytab
export KRB5_KTNAME

Kerberos Client
Edite o arquivo /etc/krb5.conf

No meu caso ficou assim:
##################
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = MARCUS.NET
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 forwardable = yes

; for Windows 2008 with AES
      default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
      default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
      permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5

[realms]
 MARCUS.NET = {
  kdc = adserver.marcus.net:88
  admin_server = adserver.marcus.net:749
  default_domain = marcus.net
 }

[domain_realm]
 .marcus.net = MARCUS.NET
 marcus.net = MARCUS.NET

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }
##################


Configurações do Squid
Antes de mexer no squid copiei mais um arquivo para a pasta sbin.

$ cd /opt/squid-3.1
$ cp -a libexec/squid_kerb_auth sbin/

Dentre as demais configurações, o que interessa para a autenticação kerberos é:

##################
# KERBEROS - Integracao completa com AD
auth_param negotiate program /opt/squid-3.1/sbin/squid_kerb_auth -s HTTP/squidserver.marcus.net
auth_param negotiate children 10
auth_param negotiate keep_alive on

# ACLs externas para buscar grupo baseado em Kerberos.
external_acl_type Internet_Full ttl=3600 negative_ttl=3600 %LOGIN /opt/squid-3.1/sbin/squid_kerb_ldap -g Internet_Full
##################

Beleza! Feito isso é só criar os diretórios de cache e iniciar o squid.
Configure o proxy e porta no navegador das estações e teste.

Detalhes e Dicas:
- Certifique-se que os servidores conseguem resolver nomes DNS do Squid e do AD.
- Verifique as permissões dos arquivos e pastas do Squid.
- Verifique se os horários dos servidores e clientes estão sincronizados.
- Observe o arquivo cache.log do Squid para resolver problemas ou entender o funcionamento.
- Da para colocar os módulos squid_kerb_auth e squid_kerb_ldap em modo dedug apenas adicionando um "-d" depois do comando no squid.conf.


Fontes que li durante a implementação

Belo Tutorial:
http://klaubert.wordpress.com/2008/01/09/squid-kerberos-authentication-and-ldap-authorization-in-active-directory/

Squid Kerb Helper
http://sourceforge.net/projects/squidkerbauth/

Informações sobre KeyTabs
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tsec_SPNEGO_config_dc.html

Informações sobre erros comuns:
http://sammoffatt.com.au/jauthtools/Kerberos/Troubleshooting

Roteamento Avançado em Linux

Olá!

Essa é uma técnica bem simples porém muito útil quando temos dois links de Internet. Felizmente o Linux, como de costume, permite mexermos em qualquer funcionalidade dele.

Nesse caso, faremos uma alteração relacionada à tabelas de roteamento podendo direcionar tráfegos bem específicos para o link que quisermos.

A situação mais comum para usarmos essa técnica é a de uma empresa com dois Links de Internet sendo um deles o principal, ou seja,  por onde saem todos os serviços e por onde estão publicados endereços externos, etc e um outro usado apenas como redundância para acesso a Internet.

Já que o link principal normalmente é o mais usado, nosso link secundário acaba sendo subutilizado. Por experiência, posso garantir que o trafego Web (tcp/80 - http e tcp/443 - https) é um dos maiores consumidores de link. Isso é lógico, cada vez mais dependemos da Internet.

Então, nesse post fareia seguinte configuração: Tudo que for serviço sai pelo Link Principal e tudo que for tráfego Web sai pelo Link Secundário. Isso vai garantir que os dois links sejam utilizados de forma equilibrada. Lembrando que isso não é regra!! Podem ter situação que outros tráfegos possam predominar, portanto faça uma análise da sua rede antes de seguir esse post.

Mãos-a-obra

Nosso objetivo é fazer essa façanha simplesmente manipulando tabelas de roteamento do nosso Firewall.

Para isso a primeira dependência que temos é o pacote iproute2. Normalmente ele já vem instalado na maioria das distros. Senão estiver instalado? Da um jeito de instalar ué!!

Bom, começaremos editando o arquivo /etc/iproute2/rt_tables.

Esse arquivo já vem com 3 tabelas de roteamento por default como no exemplo abaixo:

$ cat /etc/iproute2/rt_tables
255     local
254     main
253     default

OBS: Quanto maior o número, maior a prioridade da tabela no sistema.

Local: Essa é uma tabela padrão criada pelo Kernel que serve para gerenciar todos os endereços locais da máquina. Ela possui todos os endereços cadastrados na interface do firewall. Não tem necessidade de mexermos nela a não ser que você seja um maníaco testador.

Comando bacana:

$ ip route show table local

Main: Essa e principal tabela do sistema. É nela que criamos rotas, adicionamos nosso default gateway, etc. Todos os comando de roteamento, por padrão, apontam para ela.

Comandos bacanas:

$ ip route show table main

$ route -n

Default: Como quase tudo que é desenvolvido, principalmente na área de redes, os desenvolvedores sempre criar algo que poderá ser utilizado no futuro caso haja a necessidade de algo que não foi previsto enquanto ele digitava o código desse treco, ou seja, essa tabela de roteamento vem vazia e não serve para nada a não ser que mandemos ela fazer algo.

Legal vamos deixar esse default bem quietinha no lugar dela e vamos criar uma nova tabela. Edite o arquivo rt_tables e adicione uma nova tabela.

Ex:

$ cat /etc/iproute2/rt_tables
255     local
254     main
253     default

100     link_sec

Por quê o número 100?

Porque acho um número fácil de digitar, decorar e também misterioso para os leigos... heheheh Na verdade você pode usar qualquer número entre 1 e 255. Mas recomendo fortemente usar algum menor que os números das tabelas default. Caso duvide pode fazer um teste. É bem divertido.

Com essa alteração criamos uma tabela nova e zerada. Nenhum tráfego vai passar por ela, pois na pior das hipóteses ele vai casar com o default gateway da tabela main. É bem isso que queremos. Continue funcionando perfeitamente e especificaremos minuciosamente o que vamos mandar para a nova tabela.

Mas antes disso, vamos criar uma rota ou gateway nessa nova tabela.

$ ip route add default via "gateway" table link_sec

Para conferir:

$ ip route show table link_sec

Beleza! Agora tudo que cair nessa tabela vai para o link secundário.

Selecionando o Tráfego

Podemos fazer isso diretamente com parâmetros do ip rule, mas eles são um pouco limitados e como sou um adorador do iptables, usarei a extensão MARK dele para fazer isso.

Como quero que todo o tráfego WEB saia pelo Link Secundário, criarei a seguinte linha do iptables:

# iptables -t mangle -A PREROUTING -j MARK --set-mark 1 -p tcp -m multiport --dports 80,443 -i "interface interna" -d ! "rede interna ou dmz"

Essa linha colocará uma marca/garimbo em cada pacote que contiver 80 ou 443 na porta de destino e não for direcionado para o servidor local. Resumindo, marcará tudo que for navegação para fora da empresa.

Pronto, temos a tabela de roteamento criada, uma rota default dela para meu link secundário e todos os pacotes marcados.

Só falta jogarmos esses pacotes para a nova tabela e automaticamente eles sairão pelo link secundário.

Direcionando o Tráfego

Como já temos os pacotes marcados pelo iptables, vamos criar uma rule para eles.

# ip rule add fwmark 1 table link_sec

Prontinho, seu link tráfego já estará direcionado para o Link Secundário.

Observações:

- Verifique se as regras de Postrouting ficaram de acordo, senão não vai conseguir navegar em função do mascaramento incorreto.

- Instale um agente/gerenciador SNMP para monitorar as interfaces. Fica bacana. O Zenoss já serve.

- Não tente mexer nas outras tabelas com o comando ip. Isso pode causar um caos mundial em servidores de produção.

Abraço!

Cisco Port Security

Buenas!

Mais uma breve postagem sobre segurança de portas em Switches.

Para fazermos um switch funcionar, basicamente precisamos comprá-lo, ligá-lo na energia e plugarmos os hosts em suas portas. Simples e fácil. Isso é uma opção dos fabricantes em tornar o dispositivo o mais fácil possível, porém todos os fabricantes recomendam fortemente configurações avançadas de segurança. 

Uma delas é o Port Security que trata-se de uma tecnologia para limitar e controlar a quantidade de dispositivos ligados em uma porta. Imagine a situação na qual você tem uma sala isolada em sua empresa com apenas uma porta LAN liberada para a única estação de trabalho que se encontra nessa salinha. Essa estação controla algumas câmeras IP e precisa estar sempre conectada mesmo que quase ninguém vá até a sala. Hehehe, que exemplo... : ).

Bom, mas onde eu quero chegar é que qualquer pessoa pode entrar nessa sala, plugar um HUB nesse ponto de rede, ligar a estação no HUB e mais um notebook. Pronto! Teremos uma máquina estranha conectada em nossa rede sem o nosso conhecimento e que pode estar transmitindo vírus, fazendo varreduras ou mesmo DoS na nossa LAN. Esse é um exemplo de risco com switches mal configurados.

Com Port Security podemos especificar que essa porta aceitará tráfego de apenas um  (ou mais) MAC Address e caso um segundo MAC tente trafegar por essa porta, caracterizando a situação acima, o Swicth tome algumas ações automaticamente:

protect: Simplesmente descartará qualquer pacote vindo desse MAC não autorizado.

restrict: Fará a mesma coisa que o protect além de também enviar TRAPs SNMP informando o que está ocorrendo.

shutdown: Essa é a mais drástica. Dará um shutdown administrativo na porta, o que significa que ela só voltará a funcionar se o administrador conectar no switch e mandar a porta funcionar novamente.

Particularmente acho a opção restrict mais vantajosa, pois sempre que houver uma violação o "atacante" não conseguira acesso à LAN e ainda poderei ver as informações do que está ocorrendo através do SNMP. Uma dica é utilizar uma ferramenta de monitoramento como o Zenoss para ajudar nessa tarefa.

Caso eu escolha shutdown, por exemplo, posso estar dando chance para o DoS e se um larápio souber disso ele vai se divertir nas suas custas.

Mas como ele fará o controle do MAC?

Podemos optar entre duas formas sendo a primeira manual e a segunda automática.

Mas como, câmbio?

Quando habilitamos Port Security em uma porta, temos que definir a quantidade de MACs que a porta aceitará. Por padrão ela aceitará apenas 1 MAC. Independente do número x de MACs que for configurado, poderemos especificar manualmente esses endereços ou ligar a opção sticky que irá liberar os primeiros x MAC a chegarem na interface. Fique calmo que colocarei os comandos depois. : )

Eu particularmente acho a opção do Sticky muito mais vantajosa pela menor esforço no gerenciamento, mas para estruturas realmente pequenas isso pode ser interessante olhando pelo lado da segurança.

Como configurar?

Exemplo bem breve e prático de como configurar:

! Acessa um range de portas para configurar tudo de uma só vez.

# interface range FastEthernet 0/1 - 24

! Tem que ser interface de acesso. Não pode ser trunk, por exemplo.

(config-if) # switchport mode access

! Habilita Port security.

(config-if) # switchport port-security 

! Define que a porta aceitará apenas 2 MACs.

(config-if) # switchport port-security maximum 2

! Se um terceiro MAC tantar acesso será descartado e traps SNMP serão enviadas.

(config-if) # switchport port-security violation restrict

! Os dois primeiros MAC que passarem pela porta serão cadastrados automaticamente.

! No lugar do sticky também pode ser digitado o MAC caso queira especificá-lo xxxx.xxxx.xxxx

(config-if) # switchport port-security mac-address sticky

Pronto!

Dicas de Segurança:

- Deixe todas as portas configuradas como portas de acesso para evitar que alguém se conecte em uma porta trunk e acesse todas as VLANs.

- Coloque portas que não são usadas em VLANs que não existem.

- Dê um shutdown administrativos em todas as portas que não estão em uso.

- Mantenha um capacitor sempre carregado para dar choque em quem tente atazanar sua LAN.

Em breve falarei sobre o 802.1x.

Abraço!

Falha em GSM / 3G

Olá!

Resolvi postar esse tópico pois envolve segurança e se trata de um problema gravíssimo relacionado a privacidade dos usuários de telefonia móvel, mais especificamente GSM e 3G. Embora o assunto seja muito importante, as mídias (com execção dos sites de segurança) não estão divulgando a mesma.

No final do ano passado, durante a Chaos Communication Conference em Berlim, foi divulgada uma falha no algoritmo de criptografia A5/1, um algoritmo de 64 bits usado na criptografia de comunicações GSM.

Mais informações: http://idgnow.uol.com.br/seguranca/2009/12/29/crackers-mostram-que-grampear-celular-gsm-e-mais-facil-do-que-se-pensa/

http://www.baboo.com.br/conteudo/modelos/Falha-no-sistema-GSM-deixa-telefones-vulneraveis-a-escuta_a7047_z0.aspx

Na prática, antes de criptografar a conversa, o algoritmo faz uma "limpeza" de ruídos antes de enviar o sinal para a central e é nessa etapa que o algoritmo sofre o ataque.

É uma falha semelhante à encontrada no protocolo WEB de redes Wireless na qual o algoritmo de criptografia executa ciclos repetidos de chaves passando por momentos onde a probabilidade de chaves é muito baixa tornando uma quebra dessa chave muito fácil por um interceptador.

Tudo bem. Logo em seguida os engenheiros divulgaram o sucessor A5/3, o qual corrigia essas vulnerabilidades e foi desenvolvido especificamente para o sitema 3G.

O problema é que esse kra também está vulnerável. Uma explicação mais matemática da falha está em http://threatpost.com/en_us/blogs/second-gsm-cipher-falls-011110 e uma mais exclarecedora em http://emergentchaos.com/archives/2010/01/another-week-another-gsm-cipher-bites-the-dust.html.

E aqui uma prova prática de como o processo de clonagem é fácil: http://tecnologia.ig.com.br/noticia/2010/01/26/campus+party+2010+mitnick+clona+celular+ao+vivo+9376814.html

Meio complexa a parte técnica, mas em resumo significa que qualquer pessoa que tenha as ferramentas adequadas pode “grampear” seu celular seja em voz ou dados, ou seja, NADA de informação crítica por celular GSM ou 3G.

Uma linha 3G, por exemplo, pode ser grampeade em apenas 2 horas.

Para Leigos

O funcionamento normal de um celular atual consiste sempre em codificar toda a comunicação entre dois ou mais aparelhos com a finalidade de tornar uma interceptação impossível por uma pessoa não autorizada.
Para que isso ocorra são usados algoritmos (processos) muito complexos matematicamente.

No final de 2009, em uma conferencia de Segurança da Informação em Berlin, especialistas em segurança divulgaram uma falha na forma como os celulares GSM transmitem suas informações. Com essa descoberta tornou-se possível que qualquer pessoa em posse de alguns equipamentos e softwares possa descobrir a codificação usada por um celular e clonar o mesmo a fim de grampear qualquer informação de Voz ou de Dados enviada ou recebida por este aparelho.

Logo em seguida o órgão responsável pelas comunicações em telefonia móvel (GSM Association) divulgou e implementou um novo algoritmo de codificação, o mesmo usado nos atuais celulares 3G. Porém, algumas semanas após a divulgação deste novo algoritmo pesquisadores já descobriram uma nova falha semelhante ao anterior e até mais fácil de ser explorada.

Em testes práticos, tais pesquisadores provaram que um celular 3G pode ser grampeado em menos de 2 horas sem a necessidade de equipamentos muito caros.

Até o momento não foram divulgadas correções nesse sistema e as mídias estão contendo a proliferação desta informação, mas ainda estamos todos vulneráveis.

A dica é que NÃO usem usem aparelhos celulares GSM ou 3G para trocar informações sigilosas, sejam elas no formato de Voz ou de Dados.

Grande abraço! 

Como os Switches processam seus frames?

Olá!

Esse é um tópico bem curtinho mas não menos importante para entendermos os Swicthes. O básico do seu funcionamento já sabemos, mas o objetivo aqui é vermos cada vez mais profundamente suas características.

Entendendo essas formas de processamento podemos designar a melhor forma de operação para a nossa topologia e saber o que é mito ou não. hehe

Bom, preciso deixar claro que os termos usados se baseiam em Cisco, pois estou estudando para a CCNA, mas outros fabricantes possuem os mesmo conceitos podendo trocar alguns nomes...

Basicamente os Switches possuem três formas de processamento de frames:

- Store-and-Forward - A padrão em quase todos os switches.

- Cut-through - A que eu menos indico.

- Fragment-free - Bem inteligente.

Store-and-forward

Como já dito acima, esse é o padrão em quase todos os switches (pelo menos nos que conheço). Nesse formato de processamento o swicth irá trasmitir os frames para a porta de destino apenas quando todos os fragmentos desse frame chegarem no switch e forem analisados. É a forma mais segura e confiável para um switch trabalhar. Da para fazer uma analogia com um servidor proxy, o qual só retransmite o site para o destinatário depois que todos os frames chegam e o proxy consegue montar o pacote completo. A única desvantegem desse modo de processamento em relação aos outros é referente à latência. Como ele espera que todos os frames cheguem para depois transmitir isso pode causar uma pequena latência. Mas na prática isso não é problema hoje em dia, pois nossas LANs dificilmente atuam em toda sua capacidade e ainda assim temos velocidades bem altas.

Portanto, é a forma de processamento mais indicada para a maioria dos casos.

Cut-through

Essa é uma opção que na minha opinião não vale a pena. Em um frame ethernet o endereço MAC sempre vem bem no ínicio do frame (nos primeiros bytes). Em um swicth isso é mais do que necessário para ele tomar a decisão de que porta transmitir o frame. Assim que consegue ler o MAC de destino já começa a retransmitir os fragmentos desse frame. Isso causa uma latência realmente muito baixa na comunicação. Os frames serão restransmitidos assim que possível. O problema desse modo é que cada cabeçalho de frame possui um campo chamado FCS que fica mais ao final do cabeçalho. Esse campo tráz um hash de todo o frame no momento em que ele foi gerado. Na outra ponta o dispositivo calcula novamente esse hash e compara com o resultado que veio no campo FCS. Caso seja igual significa que o frame foi transmitido com sucesso e está íntegro. Caso contrário o frame foi corrompido no caminho.

Como nesse modo o Swicth nem chega a ler o campo FCS, o frame é retransmitido mesmo estando corrompido causando uma transmissão desnecessária e consequentemente perda de desempenho na comunicação. Na minha opinião não vale a pena esse ganho na análise do cabeçalho perdendo com transmissões corrompidas. NÃO recomendo.

Fragment-free

Esse é um kra legal. Considero um intermediário entre o Store-and-forward e o Cut-through.

Ele não espera todos os fragmentos e nem lê apenas o DST MAC. Na verdade ele espera os primeiros 64 Bytes de um frame, os quais contém todo o cabeçalho. Dessa forma ele consegue ler informações de MAC e ainda verificar a integridade do cabeçalho evitando a restransmissão de pacotes corrompidos. Talvez seria interessante em estruturas de Cluster sobre LAN.

Conclusão: Usar sempre que possível o primeiro modo - Store-and-forward - pois ele satisfaz praticamente todas as necessidades sem causar perdas consideráveis no desempenho da nossa rede. Na pior das hipóteses use o Fragment-free mas jamais o Cut-throug.

Abração!

Divulgados videos do FISL 10

Bom dia!

Hoje lembrei de verificar novamente se os videos das palestras do FISL 10 já foram publicados. Para a minha surpresa eles já estão todos disponíveis e já faz alguns meses! hehehe

Esse é o link da minha palestra de Técnicar Avançadas de Segurança com Iptables.
http://stream.softwarelivre.org/video/tecnicas-avan%C3%A7adas-de-seguran%C3%A7-com-iptables

E no link http://stream.softwarelivre.org podem ser vistos todos os outros materiais da TV Software Livre.

Abraço!

LAN Switching

Buenas!!

Com esse post inicio uma série de posts relacionados à Networking. Estou estudando pela enésima vez para a CCNA e para ajudar na memoriazação e ainda no compartilhamento de informações publicarei informações quentinhas e sequenciais no decorrer dos estudos....

Conceitos de Switch

Bom, primeiramente vamos ao significado da palavra Switch. Acredito e sempre defendo que entender as origens dos nomes e conceitos é primordial para um entendimento claro. Fica muito mais fácil de memorizar e fazer analogias... Mas enfim... em todos os livros em português que já li sobre network o nome Switch é comumente traduzido para Comutador.

Mas o que é comutar? Pelo menos para mim era uma palavra bem incomum de ser usada no dia-a-dia. Para poupar o trabalho de quem está lendo, já fiz uma boa pesquisa tempos atrás e o melhor significado da palavra (relacionada a networking) está em unir, ou seja, um comutador/switch tem a função de unir equipamentos em um site. Mais especificamente criar uma LAN.

Hub x Switch

Aos conceitos... Normalmente vemos escreverem HUB e não Hub, como se fosse a sigla para algum conjunto de palavras como LAN, WAN, etc. Isso está errado. Hub não é uma sigla. É uma palavra inglêsa que significa cubo e diversas outras palavras. Esse equipamento foi chamado assim devido à uma analogia com as rodas raiadas de carros da época. Tais rodas possuiam um cubo/hub que interligava todos os raios formando uma estrela. Em network o que o hub faz é exatamente isso. Liga os raios/hosts.

Atualmente nem vemos muitos HUBs por aí (Isso me deixa muito feliz). Posso dizer que Hubs são equipamentos defasados e contra-indicados para as nossas nessecidades de networking. Ainda podem ser usados em casa para criar uma pequena rede domestica sob única justificativa de preço ou por administradores de rede para analises de tráfego (sniffing). Tirando essas situações o Hub não possui nenhuma vantagem em relação ao Switch.

Hub é um dispositivo que atua na camada 1 do modelo OSI, ou seja, a única coisa que ele faz e amplificar o sinal elétrico e repetí-lo para todas as suas portas com excessão da porta que recebeu o sinal original. Isso é um caos para a segurança e para o desempenho da rede. Como um mesmo sinal é repetido em todas as portas chegamos a conclusão que apenas um host pode transmitir simultaneamente, ou seja, quando ligarmos uma rede usando Hubs jamais teremos uma conexão Full-Duplex. Será sempre Half-Duplex. Isso causa uma disperdício completamente desnecessário na LAN somado com as colisões que ocorrem caso dois hosts tentem trasmitir ao mesmo tempo. Na prática: Quanto mais hubs na nossa rede, maior será nossa tristeza. : )

Na área da segurança o Hub é o melhor amigo do atacante. Como os sinais são sempre repetidos em todas as interfaces, basta eu estar naquele domínio de colisão que poderei ver QUALQUER informação transmitida pelos hosts desse mesmo domínio.

Extra: Uma vez vi um projetos de Cluster Beowulf de pequeno porte que estava usando Hubs no lugar de Switches sob justificativa que os hubs eram mais rápidos na transmissão de pacotes do que os Switches pois cusavam um delay ao analisar os pacotes na camada 2. Foi bem engraçada a justificativa.

Primeiramente o tempo gasto na análise de camada 2 compensa tranquilamente o tempo perdido com colisões, retrasmissões e half-duplex. Além disso os switches gerenciáveis e semi-gerenciáveis permitem que confuguremos o modo de análise dos pacotes (Store-and-forward, Cut-through e Fragment-free).

Bridge

Bridges/Pontes são equipamentos usados para separar fisicamente pela camada 2 conjuntos de computadores. O que elas fazem é impedir que pacotes de camada 2 passem para o outro segmente desnecessáriamente. Para isso ela mantém uma lista de MAC Address de todos os dispositivos conectados em cada porta dela e quando chega algum pacote até ela, a mesma o retransmite apenas para a porta onde o MAC Address de destino se encontra.

Switch

Finalmente os Switches... Switches são como bridges multiportas, pois funcionam exatamente como as bridges, mas possuem bem mais que duas portas. O correto é ligarmos um host a cada porta do Switch.

Inicialmente e por pouquíssimo tempo, quanto os switches são ligados, atuam como Hubs, porém são dispositivos de camada 2 que trabalham com endereços MAC e toman decisões com eles.

Para tomada de decisões o switch pressisa de um banco de dados com informações de MAC Address conhecidos. Essa tabela chama-se tabela ARP. No momento que o Switch é ligado sua tabela ARP se encontra vazia e sua população ocorre na medida que pacotes vão chegando. Por exemplo, a máquina1 possui o MAC 11:11:11:11:11:11 e está ligada na porta 0/1. Assim que ela mandar um pacote para a rede esse pacote entrará no Swicth pela porta 0/1 e com o MAC de origem 11:11:11:11:11:11. O Switch fará uma associação na tabela ARP entre essa porta e esse MAC e quando o Swicth receber um pacote com destino ao MAC 11:11:11:11:11:11 já saberá que o pacote deve ser encaminhado para a porta 0/1. Isso ocorre sucessivamente até a tabela ficar completa.

Resumo: Para popular a tabela ARP o que importa é o endereço de origem e sempre que um pacote chega no switch a tabela ARP é consultada antes de encaminhar o pacote.

Caso chegue um pacote com destino à um endereço que não consta na tabela ARP daquele switch o mesmo enviará um broadcast (flooding) de camada 2 (FF:FF:FF:FF:FF:FF) pedindo quem possui determinado MAC. Na resposta ele já atualiza a tabela ARP.

Com essa tabela bem definida, o Switch consegue criar circuitos virtuais entre hosts que estão se comunicando, ou seja, uma comunicação ocorrerá somente entre os hosts interessados. Dessa forma o sniffing não poderá ser feito de forma normal e todas as máquinas poderão trafegar em Full-Duplex.

Forward x Filter Decision

A situação descrita acima consiste em Forward, ou seja, o Switch aprende o MAC conforme os pacotes vão chegando e armazena na tabela ARP associado com uma porta.
Quando algum pacote passa por ele, o Switch lê o MAC de destino e consulta sua porta na tabela ARP. Se não existir ele manda um broadcast de camada 2 pedindo quem o possui e armazena na tabela. Caso o MAC de destino esteja na tabela e associado à uma porta diferente da qual o pacote chegou, o switch repassa esse pacote, ou seja, forward.
Caso o MAC esteja na tabela, mas associado à mesma porta que o pacote chegou o switch fará um filter, ou seja, descartará o pacote. Isso caracteriza, por exemplo, uma comunicação entre duas máquinas ligadas à um Hub que está ligado à uma porta do Switch. Não faz sentido o switch repassar esse pacote.

Conclusão: Hub é um lixo comparado aos Switches. Use switches sempre que possivel e seja feliz.

EXTRA: Tabela ARP também é chamada de Content Addressable Memory (CAM) devido ao tipo de memória física usada para isso. Ela é especial para converter IP em MAC muito rapidamente.

Até a próxima.