Posts Tagged proteção

Entendendo a criptografia RSA – Parte 1

Muito se ouve falar sobre criptografia e, mais especificamente, da eficiência da RSA para proteção de dados. Mas é menos comum ver explicações acerca dos motivos que a tornam tão boa no que se propõe. Mais que isso, como são relativamente simples as teorias nas quais se embasaram Rivest, Shamir e Adleman para sua criação. Claro que não dá para falar tudo num só post! Por isso, dedicarei a próxima série a este fascinante assunto: A teoria matemática por trás da criptografia RSA.

Desde que li O livro dos códigos, sou fascinado pelo assunto “criptografia”. Em especial, o livro me despertou um enorme interesse pela Enigma e pela criptografia RSA. Apesar de não ter informações muito técnicas, conta a história por trás das coisas e foi justamente isso que me interessou. Especificamente sobre a RSA, fiquei curioso por entender como algo tão “simples” pudesse ser tão eficiente. Até porque, sempre achei que as soluções simples são as mais elegantes.

Antes de qualquer coisa, é preciso entender que tudo se baseia na matemática modular. Apesar do nome soar estranho aos ouvidos de alguns e, ainda, as coisas parecerem ainda mais esquisitas quando se ouve dizer que pode acontecer 9  + 7 = 4 em matemática modular; posso afirmar que tratam-se de conceitos que usamos quase naturalmente no cotidiano. O exemplo mais ilustrativo é o cálculo de horas num relógio de ponteiro: suponha que o ponteiro das horas esteja no nove, onde ele estará depois de sete horas? Viu como não é mais tão inconsebível 9 + 7 = 4?

Outros exemplos simples de contas que custumeiramente fazemos usando matemática modular podem ser o cálculo de que dia da semana será daqui a cinco dias ou em quantos anos acontecerá o próximo ano bissexto. Iniciando uma “tradução” para matemática, dizer que 9 + 7 = 4 num relógio de ponteiro é o mesmo que dizer “9 + 7 deixa resto 4 quando dividido por 12”. Aliás, esta é a principal ideia na matemática modular: buscamos sempre o resto da divisão de um número por outro. Voltando ao relógio, para calcularmos onde o ponteiro estará depois de 49 horas ao invés de 7, teríamos que somar 49 + 9 = 58 e achar o resto da divisão por 12 que é 10. Neste caso, 49 + 9 = 10.

Tendo já um conceito acerca da matemática modular, é importante que saibamos como tudo isso é formalmente escrito. Abstraindo o conceito de congruência, para dizer que 9 + 7 deixa resto 4 ao ser dividido por 12 ou que 49 + 9 deixa resto 10 na mesma divisão, precisamos escrever 9 + 7 = 4 (mod 12) e 9 + 49 = 10 (mod 12). Melhor explicando, dizer que a + b = c (mod x)(lê-se a mais b é igual a c módulo x), é o mesmo que dizer que a + b deixa resto c ao ser dividido por x.

Explicado tudo isso, vamos a resultados práticos! Dois deles podem ser ditos assim: a + b (mod x) = a (mod x) + b (mod x). Apesar de parecer um resultados sem muita utilidade, imagine-se calculando onde estaria o ponteiro do relógio já citado se passassem 13 horas e, depois, mais 25 horas! Normalmente, somaríamos 9 + 13 + 25, dividiríamos por 12 e acharíamos o resto. Seria como calcular 9 + 13 + 25 (mod 12), o que pode não ser um cálculo tão trivial. Mas pode ser simplificado se fizermos 9 (mod 12) + 13 (mod 12) + 25 (mod 12), ou seja, calcular os restos antes de somar. Teríamos então: 9 + 1 + 1 = 11 (mod 12). Viu como as contas ficam mais simples?! O mais impressionante é que o mesmo se aplica à multiplicação, mas isso fica para o próximo post.

Fonte: http://dascoisasqueaprendi.com.br/

Lomadee, uma nova espécie na web. A maior plataforma de afiliados da América Latina.

, , , , ,

Comments

Debugando Squid lento.

Esta semana notei que a Internet, em determinados momentos, estava muito lenta somente durante a navegação em páginas. Imediatamente dei um # tail -f /var/log/squid/access.log para ver como estava o fluxo. Notei que havia problemas, pois não era raro as coisas ficarem bem lentas. Algo considerado normal era de 5 a 30 linhas de log por segundo. De repente, o fluxo passava para 1 linha a cada 3 ou 5 segundos. Era evidente que algo estava errado.

A caçada ao problema

A próxima providência foi observar o log /var/log/squid/cache.log. Esse log é muito útil em casos de panes. Assim sendo, encontrei entradas como essas:

2011/03/01 11:33:08| WARNING! Your cache is running out of filedescriptors
2011/03/01 11:33:24| WARNING! Your cache is running out of filedescriptors
2011/03/01 11:33:40| WARNING! Your cache is running out of filedescriptors
...
2011/03/01 11:37:49| comm_open: socket failure: (24) Too many open files
2011/03/01 11:37:49| comm_open: socket failure: (24) Too many open files
2011/03/01 11:37:49| comm_open: socket failure: (24) Too many open files
2011/03/01 11:37:49| comm_open: socket failure: (24) Too many open files
2011/03/01 11:37:49| comm_open: socket failure: (24) Too many open files

A primeira atitude foi parar o Squid para extinguir conexões e liberar a memória. Ao parar o Squid, o log cache.log mostrou várias linhas similares às seguintes:

2011/03/01 11:39:56| WARNING: Closing client 172.20.11.8 connection due to lifetime timeout
2011/03/01 11:39:56|    http://212.95.32.228/
2011/03/01 11:39:56| WARNING: Closing client 172.20.11.8 connection due to lifetime timeout
2011/03/01 11:39:56|    http://pornorus.info/
2011/03/01 11:39:56| WARNING: Closing client 172.20.11.8 connection due to lifetime timeout
2011/03/01 11:39:56|    http://212.95.32.228/
2011/03/01 11:39:56| WARNING: Closing client 172.20.11.8 connection due to lifetime timeout
2011/03/01 11:39:56|    http://212.95.32.228/
2011/03/01 11:39:56| WARNING: Closing client 172.20.11.8 connection due to lifetime timeout
2011/03/01 11:39:56|    http://pornorus.info/

Depois de ver tais ocorrências nos logs, coloquei novamente o Squid no ar e iniciei uma sessão tcpdump analisando os pacotes oriundos da máquina 172.20.11.8 (# tcpdump -n src host 172.20.11.8 -i any). O resultado, assustador, foi o seguinte (apenas parte dele):

13:14:43.987252 IP 172.20.11.8.57275 > 69.172.201.37.80: Flags [R.], seq 181, ack 222, win 0, length 0
13:14:44.409406 IP 172.20.11.8.57267 > 66.147.233.129.80: Flags [S], seq 1898618422, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.409410 IP 172.20.11.8.57258 > 199.59.164.43.80: Flags [S], seq 55279041, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.409421 IP 172.20.11.8.57259 > 216.67.236.203.80: Flags [S], seq 932004311, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.409452 IP 172.20.11.8.57261 > 206.188.192.114.80: Flags [S], seq 2750519905, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.409462 IP 172.20.11.8.57264 > 66.147.233.129.80: Flags [S], seq 1119544921, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.409473 IP 172.20.11.8.57266 > 206.188.192.114.80: Flags [S], seq 590383906, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.409475 IP 172.20.11.8.57262 > 97.74.233.172.80: Flags [S], seq 2639837201, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.409485 IP 172.20.11.8.57263 > 199.59.164.43.80: Flags [S], seq 2739288678, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.409495 IP 172.20.11.8.57268 > 212.95.32.228.80: Flags [S], seq 2977967308, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.440659 IP 172.20.11.8.57270 > 97.74.233.172.80: Flags [S], seq 3954006774, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.440659 IP 172.20.11.8.57269 > 212.95.32.228.80: Flags [S], seq 2623039428, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.471860 IP 172.20.11.8.57271 > 216.67.236.203.80: Flags [S], seq 3118322633, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.483034 IP 172.20.11.8.57254 > 69.172.201.37.80: Flags [R.], seq 158, ack 222, win 0, length 0
13:14:44.487431 IP 172.20.11.8.57273 > 184.154.10.250.80: Flags [S], seq 3904042156, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.518571 IP 172.20.11.8.57274 > 66.147.233.129.80: Flags [S], seq 1708211931, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.525773 IP 172.20.11.8.57285 > 216.67.236.203.80: Flags [R.], seq 132, ack 285, win 0, length 0
13:14:44.525840 IP 172.20.11.8.57293 > 212.95.32.228.80: Flags [R.], seq 185, ack 263, win 0, length 0
13:14:44.534239 IP 172.20.11.8.57750 > 206.188.192.114.80: Flags [FP.], seq 0:193, ack 1, win 64240, length 193
13:14:44.598544 IP 172.20.11.8.57755 > 66.147.233.129.80: Flags [S], seq 2940124690, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.598893 IP 172.20.11.8.57755 > 66.147.233.129.80: Flags [.], ack 1072162614, win 64240, length 0
13:14:44.599643 IP 172.20.11.8.57755 > 66.147.233.129.80: Flags [P.], seq 0:209, ack 1, win 64240, length 209
13:14:44.599676 IP 172.20.11.8.57755 > 66.147.233.129.80: Flags [F.], seq 209, ack 1, win 64240, length 0
13:14:44.643413 IP 172.20.11.8.57729 > 212.95.32.228.80: Flags [S], seq 1694411187, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.643434 IP 172.20.11.8.57731 > 69.172.201.37.80: Flags [S], seq 3071298608, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.643451 IP 172.20.11.8.57728 > 216.67.236.203.80: Flags [S], seq 3961495832, win 8192, options [mss 1460,nop,nop,sackOK], length 0
13:14:44.643712 IP 172.20.11.8.57729 > 212.95.32.228.80: Flags [.], ack 1069583567, win 64240, length 0
13:14:44.643860 IP 172.20.11.8.57731 > 69.172.201.37.80: Flags [.], ack 1068018127, win 64240, length 0
13:14:44.643875 IP 172.20.11.8.57728 > 216.67.236.203.80: Flags [.], ack 1060616693, win 64240, length 0
...

Bem, foram cerca de 250 transações por segundo. Estava evidente que era vírus. E a quantidade de conexões em massa estava exaurindo os recursos do Squid. Então, liguei para o usuário e solicitei que retirasse o cabo de rede (eu poderia ter utilizado uma regra de iptables ao invés disso). Reiniciei o Squid para que o mesmo rompesse as conexões estabelecidas. No mesmo instante a rede voltou ao normal.

A desinfecção da máquina

O próximo passo foi ir ao usuário. Eu queria ver qual era o worm que estava destruindo a minha rede. A máquina estava com um Windows Vista. Instalei o Zone Alarm Free para ver quais programas iam tentar acessar a Internet quando eu reiniciasse o computador. Um dos primeiros foi um tal svajnager.exe, localizado em c:\windows\system32\drivers. Um lugar suspeitíssimo, uma vez que lá só há arquivos .sys. Imediatamente, realizei um boot com um pendrive contendo um Debian, montei a partição e apaguei o arquivo. Reiniciei o Windows. A máquina ficou mais rápida e a rede normal.

A prevenção contra problemas futuros

Bem, para evitar problemas futuros, criei um shell script que varre o log cache.log a cada 10 minutos (via cron), procurando por anomalias. Caso encontre alguma coisa, esse shell me avisa, via Jabber, sobre o ocorrido. Para entender como configurar isso e para ver o script, acesse este post.

Conclusão

Se você procurar na Internet pelas mensagens de erro mostradas, verá que a maioria dos posts manda aumentar a quantidade possível de arquivos abertos ou outras soluções numéricas. O problema é que isso é uma solução paliativa. Na verdade, temos que descobrir a causa do problema, ao invés de darmos um jeito de convivermos com ele. Então, neste post, vimos como descobrir tal causa.

 

fonte: http://www.eriberto.pro.br

 

Lomadee, uma nova espécie na web. A maior plataforma de afiliados da América Latina.

, , , , , , , , , , , ,

Comments

Mac Flooding – Entendendo melhor o ataque.

O Mac flooding (não é nome de sanduiche novo) é geralmente usado para atacar Switches da sua rede. Neste tipo de ataque eles bombardeiam seu dispositivo com vários números MAC de origem falsos com a intenção de consumir toda memória reservada a tabela de endereços físicos do seu dispositivo. A famosa tabela ARP.

Quando isso acontece o Switch pode responder de duas maneiras:

  1. O switch simplesmente trava.
  2. Ele começa a operar no modo Failopen.

Como no primeiro modo, ao travar o Switch, iria derrubar todas as conexões que estivessem feitas a ele a maioria das fabricantes prefere usar o segundo modo, afinal, Switch travando não é uma boa propaganda.

Porém, ao se utilizar o modo Failopen, o Switch abandona a tabela ARP e começa a trabalhar como se fosse um Hub onde os pacotes são endereçados a todas as portas em Broadcast. Sendo assim é possível a captura de pacotes em toda a sua rede utilizando um Sniffer.

Para demonstrar o ataque é possível utilizar uma ferramenta que faz parte da suíte Dsniff o MACOF (nome sugestivo né?).

  1. Fazendo o download – Para baixar acesse a pagina da suíte clicando AQUI, ou simplesmente digite no seu terminal Debian o comando #apt-get install dsniff
  2. Utilizando – A utilização é mais simples ainda, após instalando digite no seu terminal #mcof –i eth0 –n 100000. O –i indica por qual interface iremos lançar os pacotes e o –n indica a quantidade de pacotes com Mac falsos.

Agora vamos ver como se defender usando algumas técnicas para prevenir o ataque:

  1. Implementar filtros de segurança L2 (MAC filter).
  2. Permitir que apenas um número limitado de MAC Address seja aprendido automaticamente por porta.
  3. Implementar Port Security com bloqueio automático de portas em caso de tentativa de intrusão.

Mas como aplicar no meu dispositivo? (Utilizando um switch da Cisco)

A Cisco tem uma funcionalidade chamada switchport port-security, que protege contra esse tipo de ataque. Você pode usar essa funcionalidade para restringir a entrada de um número grande de endereços MAC em uma interface limitando e identificando endereços MAC de estações que podem ter acesso as portas.

Existem três modos de endereços MAC:

  1. Endereços MAC estáticos: Esses são configurados manualmente usando o comando: switchport port-security mac-address mac-address interface configuration. O endereço é guardado na tabela e adicionado ao “running config” do dispositivo.
  2. Endereços MAC dinâmicos: Esses, como o nome diz, são aprendidos dinamicamente.  O endereço é guardado na tabela, porém não é adicionado ao “running config” e é removido casso o switch reinicie.
  3. Endereços MAC “sticky”: Esses podem ser aprendidos dinamicamente ou manualmente adicionados. O endereço é guardado na tabela e adicionado ao “running config”. Se os endereços forem salvos no “running config” não precisam ser aprendidos novamente quando o switch reiniciar.

Uma porta segura pode ter de 1 a 132 endereços associados a ela. Porém o numero total de endereços seguros em um switch é de 1024. Quando o número máximo de endereços MAC seguros é atingido e uma estação que não tem seu endereço MAC na tabela do dispositivo tenta um acesso na interface uma violação de segurança ocorre.

O Switch pode reagir de três maneiras a essa violação de segurança:

  1. Modo Protect: Todos os pacotes vindos de estações com o endereço desconhecido serão descartados até que você libere um número suficiente de endereços MAC seguros ou aumente o número de endereços seguros permitidos. Neste modo você não será notificado das violações de segurança.
  2. Modo Restrict: Exatamente igual ao modo Protect. Porém, nesse modo, você é notificado das violações de segurança. É enviada uma trap SNMP, uma mensagem ao syslog e o contador de violações e incrementado.
  3. Modo Shutdown: Nesse modo uma violação de segurança muda o estado da porta para “error-disabled” o que desativa a porta (até os leds). Também envia uma trap SNMP, uma mensagem ao syslog e incrementa o contador de violações.

Mão na massa:

Vamos, como exemplo, limitar a 10 o número de endereços MAC, dois deles serão do tipo estático (aaaa.aaaa.aaaa, bbbb.bbbb.bbbb), na interface FastEthernet 0/1. Usaremos o modo Restrict.

R1# conf t
R1(config)# interface fastethernet0/1
R1(config-if)# switchport mode access
R1(config-if)# switchport port-security
R1(config-if)# switchport port-security maximum 10
R1(config-if)# switchport port-security violation restrict
R1(config-if)#switchport port-security mac-address sticky 
R1(config-if)# switchport port-security mac-address aaaa.aaaa.aaaa
R1(config-if)# switchport port-security mac-address bbbb.bbbb.bbbb

Sendo:

switchport mode access: O port-security funciona apenas em portas do tipo acesso.
switchport port-security: Habilita o port security na interface.
switchport port-security maximum 10: Seta o número máximo de endereços MAC da interface para 10.
switchport port-security violation restrict: Defines o modo de utilização “restrict”.
switchport port-security mac-address aaaa.aaaa.aaaa: Define o endereço MAC estático. Quando você cadastrar menos endereços do que os definidos como máximo os restante será aprendido dinamicamente.

Não podemos utilizar o port security se a porta estiver configurada como: Trunk, Dynamic, Dynamic-access, EtherChannel, 802.1X, Switch Port Analyzer (SPAN) destination.

Davi Sabino Barros
*Todo conteúdo pode e deve ser copiado, desde que mantidos o autor e o endereço original.

Lomadee, uma nova espécie na web. A maior plataforma de afiliados da América Latina.

, , , , , , , , , , , , , , , , , , , , ,

Comments

Crie senhas perfeitas automaticamente.

Site promete criar senhas perfeitas!
Ao acessar o site da Gibson Research Corporation podemos utilizar gratuitamente a ferramenta de geração de chaves (senhas) que nunca se repetem, são unicas e somente para você. Com a opção de 64 caracteres em Hexadecimal e 63 em ASCII ou Alfa Numéricos criamos uma senha que é muito improvável que se quebre. Levaria, por exemplo, alguns anos com um ataque de forca bruta.

Clique AQUI para gerar sua senha.

Para os que querem criar suas senhas observe algumas regras básicas para melhorar a segurança.
1. A senha deve ser aleatória, não utilize sequências ou mesmo palavras inteiras, embaralhe.
2. Misture com números e símbolos.
3. Alterne entre maiúsculas e minúsculas.
4. Senhas longas.
5. Diferentes senhas para diferentes sites.

Davi Sabino Barros
*Todo conteúdo pode e deve ser copiado, desde que mantidos o autor e o endereço original.

 

Lomadee, uma nova espécie na web. A maior plataforma de afiliados da América Latina.

, , , , , , , , , , , ,

Comments

Com abrir um pdf protegido?

Com o software PDF Password Recovery Tool é possível descobrir a senha que foi utilizada para proteger um arquivo PDF. Com ele podemos utilizar bácisamente dois tipos de ataques: O de força bruta ou dicionário.

Passo a passo:

1. Faça o download do software clicando AQUI ou vá para a página www.appnimi.com

2. Após instalar o software, selecione o arquivo pdf que você quer descobrir a senha, comprimento mínimo e máximo da senha (quanto maior as possibilidades mais tempo irá demorar) , o tipo de ataque e clique em “start”

Agora é so aguardar o software encontrar a senha e acessar o arquivo!

Força Bruta

 

Dicionário

 

Senha descoberta

 

Davi Sabino Barros

*Todo conteúdo pode e deve ser copiado, desde que mantidos o autor e o endereço original.

Lomadee, uma nova espécie na web. A maior plataforma de afiliados da América Latina.

, , , , , , , , , , , , ,

Comments