segunda-feira, 4 de outubro de 2010

Load Average

Boa tarde pessoal!

Estive um pouco sumido, mas para dar um sinal de vida estou postando um artigo bem simples e claro para entender os conceitos de Load Average. Acredito que será interessante para muitos.


Grande abraço!

quinta-feira, 29 de julho de 2010

Palestra FISL 11

Boa noite!

Pessoal, finalmente consegui um tempinho para postar a minha palestra sobre Políticas de Segurança, a qual foi apresentada na 11° edição do FISL (Fórum Internacional do Software Livre), mais especificamente no dia 23/07/10.

Ao mesmo tempo que a agradeço todos que compartilharam seu tempo comigo enquanto apresentava a palestra, peço desculpas por ter postado os slides apenas agora.

Infelizmente, no final da palestra acabei tendo que dar uma corrida para terminar os assuntos importantes, não restando tempo para dúvidas, mas fico à disposição para esclarecer qualquer dúvida que esteja ao meu alcance aqui pelo Blog ou por e-mail.


Resumo

"Irei compartilhar minha experiência com Políticas de Segurança da Informação dando dicas e exemplos para elaboração de uma Política de qualidade, justa e autêntica. É normal ouvirmos sobre políticas de segurança fracassadas, burláveis ou mesmo utópicas. Essas são algumas das inúmeras consequências de políticas mal elaboradas que, além de fracassadas, baixam a credibilidade dos profissionais que as propõem. Mostrarei porquê e como elaborar uma política da melhor forma."


Apresentação



OBS.: Assim que a organização da TV Software Livre divulgar os vídeos das palestras eu atualizo aqui.


Grade abraço!

sexta-feira, 9 de julho de 2010

Concursos na Área de TI

Buenas!

Pessoal, estão abertos dois concursos na área de TI que são bem atraentes.
Um deles é para o TCU e outro para o MPU.

Vale a pena dar uma conferida.
O prazo para inscrição no TCU é até domingo.

Salário R$ 10.775,00 (bomzinho né?!)

Maiores informações: http://www.cespe.unb.br/concursos/

Grande agraço!

terça-feira, 29 de junho de 2010

Consultas LDAP no AD

Bom dia!

Um pouco atrasado mas sempre pode ajudar alguém.
Quem vêm do mundo Linux e está familiarizado com o OpenLDAP ou semelhantes certamente fica triste quando precisa fazer uma consulta LDAP em um AD e não encontra um ldapsearch nas estações disponíveis ou mesmo no servidor.

Antes de continuar... As pessoas, assim como eu, que tiveram o privilégio de aprender mexer com servidores em Linux para só então mexer em Windows (se é que precisa aprender mexer... hehehe) jamais enfrentaram algum problema com ferramentas semelhantes no Windows. OpenLDAP e AD, por exemplo, são a mesma coisa apenas com alguns schemas modificados e uns atributos diferentes. Certa vez ouvi um MCSE falando que modificar schemas do AD era coisa de outro mundo, algo extremamente complexo. Mostrei para ele como que isso era algo rotineiro para quem trabalhava com OpenLDAP e sem nunca ver um schema do AD antes, consegui interpretá-lo normalmente. hehe Ele ficou bem desapontado.

Agora, para quem conhece OpenLDAP e tenta user AD tira de letra. O contrário, por convivência, digo com propriedade que é muito raro. hehe Em Linux, a menos que não queira, você aprende como tudo funciona. Esse negócio de segurança por obscuridade até pode ter alguns argumentos positivos, mas no fim não resolve em nada os problemas de segurança.


Chega de filosofar...
Minha necessidade foi extrair todos os usuários de um grupo do AD para um arquivo texto para então fazer um relatório. Se tem uma forma de fazer isso pelo AD eu não encontrei, mas nem pensei muito. Fui direto para a raíz do problema. AD + Usuáios = LDAP.

Encontrei alguma documentação sobre a ferramenta ldifde que por sinal é muito parecida com o ldapsearch. Bastou um /h para ver as opções e montar a consulta abaixo:

ldifde -s server -d "dc=dominio,dc=com" -f users.txt -p subtree -r (memberof="cn=Grupo,ou=users,dc=dominio,dc=com") -l samAccountName

-s: Servidor onde farei a consulta.
-d: meu dn.
-f: onde vou salvar a saída do comando.
-p: tipo de busca.
-r: filtro de pesquisa.
-l: atributo que quero listar.

Funcionou legal. Obviamente usei o Linux para ordenar os resultados em ordem alfabética e remover alguns lixos da saída do comando. Tenta fazer isso em PS e notepad para ver a tortura... : )

OBS: Fiz isso através de uma estação logada no domínio.

Grande abraço!

Fonte de auxílio:
http://support.microsoft.com/?scid=kb%3Ben-us%3B555636&x=11&y=11

segunda-feira, 28 de junho de 2010

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!

segunda-feira, 21 de junho de 2010

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:

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!

quinta-feira, 17 de junho de 2010

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

quinta-feira, 13 de maio de 2010

Profissional de Segurança

Gostei dessa coluna:
http://idgnow.uol.com.br/seguranca/mente_hacker/idgcoluna.2010-04-08.2266571128/

Bem realista.

Abraço!

quarta-feira, 17 de março de 2010

Relatórios de Acesso do ISA Server com o SARG

Boa tarde!

Atualização 02/01/2012: A solução funciona perfeitamente com o TMG 2010.

Bom, estou colocando esse post mais para eu mesmo não mais esquecer... Já havia implementado essa solução tempos atrás mas não documentei. Hoje fiquei puto da cara pois tive que refazer alguns testes até ficar tudo ok, ou seja, perdi tempo.

Em fim. Meu objetivo aqui é mostrar como posso gerar logs de acesso à WEB pelo proxy do ISA Server 2004/2006 (Outras versões não testei).

Por que?
Simplesmente porque o ISA Server é muito pobre na questão de relatórios. Nativamente conseguimos apenas gerar um Report com os 10 usuários que mais acessaram determinados protocolos e tal. Claro! Ele permite que guardamos os logs em banco de dados (adivinha qual? SQLServer) e isso possibilitaria fazermos uma ferramenta que consulte esse banco e nos monte um relatório descente. Porém isso demanda tempo e trabalho.
Como muito admins não têm tempo sobrando para isso, a Microsoft tem uma série de partners que disponibilizam uma ferramentinha prontinha para isso. Viu como é esse meio do Software Proprietário? E os preços dessas ferramentinhas não é nada amigável.

Em fim. Como já estudei TUDO relacionado ao ISA Server na época que me certifiquei na versão 2006, lembrei-me que ele tem uma forma de gerar logs em padrão aberto (W3C). Perfeito!! Se ele consegue gerar logs assim eu consigo manipulá-lo.

E depois?
Bom, a menos que eu esteja completamente maluco, jamais cairia nesse golpe comercial comprando uma ferramenta que faz algo tão simples: Gerar relatórios de acesso Web. Falando desse assunto, ninguém melhor que o SARG (Squid Analyst Report Generator). Há quem diga que o MySAR é melhor, mas o testei e só achei uma vantagem em relação ao SARG, que salvar os dados em Banco de Dados. Tirando isso o SARG tem muito mais recurso, é bem mais flexível e maduro. Contudo respeito outras opiniões.

Bom como o próprio nome já diz, o SARG foi feito para ler logs do squid (normalmente o access,log).

Raciocínio!
- Tenho um ótimo gerador de logs, que simplesmente lê o access.log e faz um relatório bem bonitinho.
- Tenho acesso ao access.log, logo sei de tudo que o SARG precisa ou não.
- Tenho acesso ao arquivo W3C do ISA Server, logo posso comparar com o access.log e deixá-los mais parecidos possível.
- Vou ajustando, testando, ajustando, testando até funcionar.

O grande segredo!
Bom, o grande segredo dessa mágina está na forma de gerar o Log do ISA Server. O arquivo w3c nativo tráz uma porrada de informação que acho que somente o ISA sabe para que servem. O segredo é ajustarmos para ele gerar logs somente com a informação necessária ao SARG.

Mas como?
Serei bem breve, pois quem deseja fazer essa loucura pressuponho que já saiba mexer no ISA Server.
Acesse a sessão "Monitoring", depois clique em "Configure Web Proxy Logging" no Painel de Tarefas.
Na janelinha que abrirá escolha "File" e "W3C extended log file format". Em "Options" defina a pasta dos logs, rotações, etc.
Depois dessa maracutaia vá para a aba "Fields" e desmarque uma porrada de opções.
Tem que ficar apenas as seguintes:
- Client IP;
- Client Username;
- Log Date;
- Log Time;
- Destination Host Name;
- Destination IP;
- Processing Time;
- Bytes Received;
- Bytes Sent;
- Protocol;
- HTTP Method;
- URL;
- HTTP Status Code.

Feito isso dê um ok em tudo que for janela do Windows, aplique as configurações do ISA Server e já pode testar os logs com o SARG.

FAQ:
P: Como passar o arquivo de log do ISA Server para o servidor Linux?
R: Ótima pergunta. Primeiro o lugar do SARG é no Linux. Tem versão Windows tenho minhas dúvidas. Seria como rodar um Internet Explorer no Linux! hehehe Para transferir o arquivo de um jeito.

P: Meu ISA é em português. Quais os nomes dos campos?
R: Você é completamente maluco!!!

P: É só isso?
R: Dessa forma vai funcionar, mas se você for uma pessoa criteriosa vai ver que da para fazer MUITAS melhorias nos relatórios simplesmente com uma configuração bem feita do sarg.conf.

Agora nunca mais vou esquecer!!! hehehehe

Referência sobre campos dos Arquivos de Log do Squid:
http://wiki.squid-cache.org/SquidFaq/SquidLogs

Abraço!

segunda-feira, 15 de março de 2010

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!

terça-feira, 2 de março de 2010

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!

quinta-feira, 11 de fevereiro de 2010

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.



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.

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!

domingo, 24 de janeiro de 2010

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!

sábado, 23 de janeiro de 2010

Linux Shared Memory - Parte 2

Continuando...

SHMMNI

Esse parâmetro serve para definirmos o número máximo de segmentos de memória para todo o sistema, ou seja, quantas bloquinhos de memória compartilhada ele vai poder criar.

Esse parâmentro é bem tranquilo. Seria problema apenas se o valor dele mutiplicado pelo shmmax ultrapassasse o tamanho de memória disponível no sistema, passando a usar Swap e degradando a performance do sistema. Mas embora isso seja possível, nunca vi acontecer. Por outro lado se tiver um valor muito baixo pode ocorrer de alguma aplicação tentar criar um segmento e não conseguir acarretando uma corrupção de dados, travamento, etc.

Minha dica para a correta configuração desse parâmetro é definir um valor que multiplicado por SHMMAX fique um pouco (uns 25%) abaixo da memória total.

Algumas aplicações, como o Oracle 10g, já tráz em suas documentações o valores mínimos necessários na configuração... Mas não precisa ser levado à risca pois eles sempre chutam bem alto e raramente será usado o valor indicado por eles. O ideal é sempre adequar as proporções do servidor e da aplicação.

O que ocorre muito comunmente é colocarem valores enormes para "garantir" que nunca falte. Na minha opinião isso pode ser feito tranquilamente, mas quando não existe conhecimento para deixar com a configuração ideal.

A falta de conhecimento sempre gera medo!! Quer um exemplo? Já viu algum bastardo dar permissão 777 em um arquivo sem nem saber se o problema é permissão e ainda virar e falar: "É só para garantir! Depois eu arrumo!!" hehe Isso ali nunca mais vai ser arrumado.
O que me deixa feliz quanto à isso é que certamente esse administrador vai deixar um furo cedo ou tarde pela sua imprudência. E nesse caso eu poderei dar consultoria para ele e ganhar dinheiro. hehehe
Bom! Empolguei.

Ah, outro tópico importante nesse shmmni é que dificilmente os segmentos terão o tamanho de shmmax. Normalmente são bem menores.


SHMALL

Bom, o shmall define o tamanho máximo reservado para compartilhamento de memória em paginação do sistema. Ao contrário dos outros parâmentros ele é definido em página e não em bytes. Seu valor é bem relacionado com o shmmax, inclusive na maioria dos lugares que pesquisei o pessoal coloca como regra para seu valor a seguinte fórmula SHMMAX/PAGE_SIZE.

Isso não está errado, mas também não deve ser dito como um regra. A impressão que tenho é que as grandes empresas criam um padrão que acreditam agradar todos levando em consideração que nenhum administrador terá conhecimento para definir do seu próprio jeito. Depois esses adminsitradores lêem essa documentação e acreditam cegamente nela. O suporte técnico da ferramenta e qualquer outro administrador que não se interessa em pesquisar e estudar vão fazer a mesma coisa. Pronto!! Virou regra! Daí quando vem um louco que estudou sobre o assunto e disse aquele não é o valor mais adequado e todos tem a audácia de falar "Mas a documentação oficial manda fazer assim...!!". E assim termina a justificativa. Digo isso pois já passei por casos como esse com consultores SAP... Mas isso não interessa agora!! Putz, empolguei-me novamente. : )

Voltando ao que interessa... Essa dica para dividir o shmmax pelo valor de paginação funciona e é bem interessante. Um arquivo de paginação sempre tem um tamanho fixo e definido. As memórias compartilhadas serão formadas por arquivos de paginação. Logo o total de paginação não poderia ser maior que shmmax. Mas isso considerando apenas uma instância do oracle, por exemplo.

Tentarei ser mais claro. Seguindo as dicas que coloquei no post do shmmax, faremos um cálculo do que os SGAs, PGAs e SOs usarão de memória compartilhada no total. Feito isso temos o máximo de memória compartilhada que nosso servidor pode usar. Legal.
Agora vamos definir o shmall, que na mairia das distros é em páginas e não em bytes. Esse kra vai dizer qual o tamanho máximo de memória compartilhada em arquivos de paginação. Sabendo que nosso sistema tem páginas de tamanho 4096 bytes através do comando $ getconf PAGE_SIZE e que o tamanho máximo de memória compartilhada é igual a shmmax basta dividirmos SHMMAX por 4096 e fica legal.

Pronto! Explicada a regra milagrosa que quase todo mundo usa. Mas eis o ponto que quero chegar... O que eu faço com esses parâmentros se eu quiser uma segunda insttância do oracle com mesmo tamanho de SGA? hehe.
Ta bom! Vamos usar exemplos concretos. Tenho um SGA de 5G e PGA de 2G. Somo os dois e acrescento 25%. Isso daria 8.75G. Arredondei para 9G para ficar melhor já que isso não causa impacto. Transformo em bytes e tenho o shmmax de 9663676416. O tamanho do meu arquivos de paginação é de 4096 bytes.
Logo shmall é 9663676416 / 4096 = 2359296.

Agora se eu quiser colocar mais uma instância desse oracle exatamente igual, meu shmmax não mudará, pois a instância é igual. O que precisa ser mudado é o total de memória compartilhada para todo o sistema. Sendo um pouco menos burocrático podemos simplesmente consideram que teremos dois kras usando o valor de shmmax. Logo shmall = 9663676416 / 4096 = 2359296 * 2 = 4718592.

Espero que agora tenha ficado mais claro, pois eu perdi um tempo procurando documentação para entender isso. Pelo menos agora está documentado de forma clara (espero!!).



SHMMIN

Esse é o oposto do SHMMAX e significa o tamanho mínimo possível de um segmento de memória compartilhada. O padrão desse parâmentro já é 1 em quase todas as distros e outras nem mesmo o trazer disponível para alterações.

Pesquisei um monte e não encontrei nem consegui imaginar uma razão para deixar esse kra maior que 1. Talvez até tenha algum motivo que eu não conheça, mas por enquanto acho que é a mesma coisa que procurar chifre em cabeça de cavalo, ou seja, não vai melhorar em nada e ainda pode causar algum problema.

Aqui finalizo os posts sobre Linux Shared Memory. Acho que postarei alguns sobre semáforos qualquer hora dessas.

Abração!

Linux Shared Memory - Parte 1

Uepas!!

Bom, neste exato momento (05:22) de um sábado estamos executando um procedimento de Upgrade de Oracle 9i para 10g em um SLES 9 x86_64 e dentre os requisitos para o Oracle 10g estão os tunninngs de kernel para memória compartilhada, semáforos e manipulações de arquivos.

O que vem a ser memória compartilhada?
Atualmente, nos Sistemas Operacionais já é quase improvável um sistema grande, como um Oracle, SAP, Postfix e outros, trabalhar com apenas 1 processo. Usa vários processos torna tudo mais rápido pois diversos processos podem trabalhar em conjunto fazerndo diversas ações diferentes ou atendendo múltiplus clientes ao mesmo tempo.

Porém, quando uma aplicação usa multi-processos esses sempre chegarão em um ponto em comum. Em um banco de dados, por exemplo, existe apenas uma database e vários processos que precisam usá-la. Para garantir a integridade, os processos devem usá-la sequencialmente e de forma civilizada. Nosso fabuloso kernel faz esse serviço deslumbrante permitindo que apenas um processo use determinada informação por vez.

Agora imagine um sistema com 200 processos precisando manipular uma única informação. Em um ambiente sem memória compartilhada o kernel precisaria copiar toda a informação para a área de memória do processo que estava na vez, depois copiar novamente para o outro e assim por diante. Nossa!! Até para escrever isso já fica mais demorado : ), imagina um usuário cliquemaníaco esperando que seu processo seja concluído!!

Para evitar esse problema e dar uma velocidade realmente boa para essa briga desenfreada por manipulação de uma única informação, os processo usam memória compartilhada. Isso significa que a informação em comum para todos os processos ficará em uma área de memória acessível por todos eles. A diferença nessa ambiente é que o kernel precisará apenas controlar que processo terá acesso e não mais fazer a cópia da informação para a memória privada de cada processo. Felizmente isso existe e é muito usado.

Ah! O nome desse compartilhamento de informações entre processos chama-se Interprocess Communication (IPC). Por coincidência temos um comando chamado "ipcs" no Linux. : )

Ok! Agora que entendemos o que é memória compartilhada podemos seguir com o tunning de Kernel no Linux.

Como verifico os parametros atuais?
Através do diretório /proc, onde estão todos os arquivos de configuração que interagem diretamente com kernel e SO.
Ex: $ cat /proc/sys/kernel/shmmax

Outra forma de verificar essas opções é através do comando: $ sysctl -a
Esse comando vai listar todas as configurações do /proc. Daí é só fazer um fltro na saída.

Parâmetros de Memmória Compartilhada

Bom, falando em memória compartilhada em Linux temos as seguintes configurações principais:
SHM = Abreviatura de Shared Memory

SHMMAX
Esse parâmentro diz qual será o tamanho máximo de um bloco de memória compartilhada que poderá ser alocado por processo. Não existe uma receita de bolo para isso. Tudo vai depender do que você vai rodar nesse servidor. Na maioria dos casos esse parâmetro serve para todos os aplicativos do servidor, mas no caso do Oracle, por exemplo, podemos querer configurá-lo para um maior desempenho aumentando seu SGA (System Global Área) para 5 GB.

OBS.: Esses valores estou inventando agora apenas para explicar sobre o shmmax.

Nesse caso significa que precisaremos configurar nosso shmmax para um valor que seja, no mínimo, 5 GB.
Lembrando que o shmmax é sempre configurado em bytes.
Caso eu tenha uma aplicação que precise de um bloco de memória compartilhada maior do que está especificado no SHMMAX, as probabilidades dessa aplicação dar "zica" são bem grandes.

Exemplo de erro no Oracle decorrente disso:
ORA-27123: unable to attach to shared memory segment
Para verificarmos informações de memória compartilhada no nosso sitema podemos usar o seguinte comando:
$ ipcs -lm

DICA: Sempre que precisar alterar esses valores utilize o arquivo /etc/sysctl.conf.


Depois de pesquisar bastante e fazer alguns testes cheguei em uma "regra" para definirmos o valor mais adequado para shmmax. Devemos descobrir os tamanhos dos blocos utilizados pelas aplicações como SGA, PGA, etc. Os administradores de tais aplicações devem trabalhar em conjunto para isso.
Uma vez definidos os tamanhos de blocos usados pelas aplicações somamos todos eles e acrescentamos 25% para processos do Sistema Operacional (Gerenciamento). Ex: SGA=5G, PGA=2G. (5+2)+25% = 8.75G. Podemos até arredondar para 9G que está tranquilo.

Importante: Em estruturas 32 Bits procure evitar valores próximos ou maiores de 4G. Pois nesses casos o sistema usará swap/paginação e o tunning pode acabar andando na contra-mão.

Extra
Não existe limite para o valor de shmmax, porém alguns pontos devem ser considerados.
1 - Caso configure ele para um valor acima da memória total resultará em Swap e perda de desempenho. É, no mínimo, uma loucura!!
2 - Caso configure ele para um valor acima da memória disponível (sobrando) resultará em Swap e perda de desempenho caso as aplicações usem todo esse tamanho. É para quem gosta de emoção!!
Nesse caso seu sistema funcionará corretamente se as aplicações estiverem funcinando abaixo desse valor, mas qualquer alteração no comportamento dessas aplicações poderá afetar o sistema.
3 - Em alguns forum reportaram que foi feita uma instalação do Oracle com esse valor bem alto e depois baixada. Quando precisaram de suporte a Oracle se negou a continuar até que o valor voltasse para o valor inicial
http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1264240898189+28353475&threadId=811971

Por via das dúvidas, ajuste esse valor de acordo com as necessidades e depois vá aumentando caso necessário.

Como ficou grande esse post continuarei em outro...

segunda-feira, 18 de janeiro de 2010

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.