E ai galera, bão?
Li um artigo muito bom e completo no The Hacker News, que se
tornou uma literatura diária para mim, daí a inspiração para escrever
sobre essa vulnerabilidade e retomar as atividades do blog, veja a página no link ao lado.[Link1]
HeartBleed é uma vulnerabilidade do OpenSSL usando as extensões de heartbeat dos protocolos TLS/DTLS.
O Ataque consiste em abrir uma conexão SSL em um servidor, e solicitar através dos pacotes de Heartbeat (pequenos pacotes que matem uma conexão TCP ativa) mais bits do que a sua conexão está transferindo (Limitado a 64 bits por transmissão). Quando você faz uma solicitação deste tipo o servidor responde ao seu heartbeat com o a sua informação e com os próximos bits que estão na memória RAM do servidor (que são dados de outras conexões abertas do mesmo servidor).
Estes dados podem ser logins e senhas, número de cartão de crédito, dados bancários, imagens e qualquer outra informação que esteja na memória do servidor naquele momento.
O OpenSSL é largamente utilizado na internet para fazer a criptografia de conexões TCP tanto em clientes (Notebooks e smartphones) quanto em servidores. Para corrigir esta vulnerabilidade é necessário atualizar a versão do OpenSSL contido nos dispositivos, em smartphones esta atualização pode ser mais lenta pois depende da implementação da correção por parte dos fabricantes de celulares e tablets.
Os firewalls UTM são uma boa ferramenta para mitigar este tipo de ameaça, pela funcionalidade de análise de pacotes na camada de aplicação caracteristica deste tipo de equipamento.
A Sonicwall criou um artigo mostrando como foram identificados pacotes que exploram esta vulnerabilidade, quais assinaturas ela criou para que seus appliances passem a bloquear este tipo de ameaça. [Link2]
Links:
Link 1 - http://thehackernews.com/2014/04/heartbleed-bug-explained-10-most.html
Link 2 - https://www.mysonicwall.com/sonicalert/searchresults.aspx?ev=article&id=668
Follow up de 18/04/2014 sobre o número de ataques diário deste tipo de vulnerabilidade (Reportados pela Sonicwall).
https://www.mysonicwall.com/sonicalert/searchresults.aspx?ev=article&id=671
Grande abraço!
segunda-feira, 28 de abril de 2014
terça-feira, 15 de janeiro de 2013
Padrão IEEE 802.11ad o famoso Wi-Gig
Fala galera blza?
O IEEE Anunciou no International CES, em Las Vegas USA, evento que aconteceu entre os dias 08 e 11 de Janeiro de 2013) a assinatura do protocolo 802.11ad, conhecido comercialmente como Wi-Gig, ou Gigabit Wireless.
Este padrão trará como novidade a a utilização da banda de 60 GHz para transmissão de pacotes, o novo padrão continuará dando suporte às frequências anteriormente utilizadas, 2,4 e 5,0 GHz, então poderemos utilizar equipamentos Wi-Gig com nossos devices atuais, o roteador Wi-Gig reconhecerá nosso dispositivo e vai transmitir dados para ele na melhor banda compatível entre os dois equipamentos.
O que mais chama atenção é a velocidade máxima da nova tecnologia, o Wi-Gig pode chegar a in criveis 7 Gbps, o que é mais que o dobro do padrão anterior 802.11N, e terá como foco principal transmissão de streamimg, um tipo de dado que requer baixo atraso e jitter, pontos que já foram dor de cabeça de muitas implementações wireless que já fiz, sem contar na maldita inteferencia eletro magnética, espero que tenhamos avanços nesses pontos também.
O lançamento oficial, divulgado via site da IEEE não trás muitos detalhes técnicos sobre a nova tecnologia, mas a gama de serviços móveis que podemos pensar utilizando esta tecnologia é grande, então fica aí a espectativa pelo novo protocolo, e pelos serviços que serão criados e expandidos com ele.
Grande abraço a todos e Feliz 2013 !!!
É possível obter mais informações pelos links abaixo:
http://standards.ieee.org/news/2013/802.11ad.html - Anuncio oficial do novo padrão
http://standards.ieee.org/develop/wg/WG802.11.html - Página da equipe de desenvolvimento do padrão IEEE 802.11
O IEEE Anunciou no International CES, em Las Vegas USA, evento que aconteceu entre os dias 08 e 11 de Janeiro de 2013) a assinatura do protocolo 802.11ad, conhecido comercialmente como Wi-Gig, ou Gigabit Wireless.
Este padrão trará como novidade a a utilização da banda de 60 GHz para transmissão de pacotes, o novo padrão continuará dando suporte às frequências anteriormente utilizadas, 2,4 e 5,0 GHz, então poderemos utilizar equipamentos Wi-Gig com nossos devices atuais, o roteador Wi-Gig reconhecerá nosso dispositivo e vai transmitir dados para ele na melhor banda compatível entre os dois equipamentos.
O que mais chama atenção é a velocidade máxima da nova tecnologia, o Wi-Gig pode chegar a in criveis 7 Gbps, o que é mais que o dobro do padrão anterior 802.11N, e terá como foco principal transmissão de streamimg, um tipo de dado que requer baixo atraso e jitter, pontos que já foram dor de cabeça de muitas implementações wireless que já fiz, sem contar na maldita inteferencia eletro magnética, espero que tenhamos avanços nesses pontos também.
O lançamento oficial, divulgado via site da IEEE não trás muitos detalhes técnicos sobre a nova tecnologia, mas a gama de serviços móveis que podemos pensar utilizando esta tecnologia é grande, então fica aí a espectativa pelo novo protocolo, e pelos serviços que serão criados e expandidos com ele.
Grande abraço a todos e Feliz 2013 !!!
É possível obter mais informações pelos links abaixo:
http://standards.ieee.org/news/2013/802.11ad.html - Anuncio oficial do novo padrão
http://standards.ieee.org/develop/wg/WG802.11.html - Página da equipe de desenvolvimento do padrão IEEE 802.11
terça-feira, 7 de agosto de 2012
NAT Transversal ou Encapsulamento UDP
Fala Galera blz?
Estudando IPSec, para desempenhar minhas novas atividades, conheci uma forma de NAT em que a tradução do endereço IP não é realizada através das portas de comunicação, o NAT-T é uma técnica onde os dois equipamentos que estão configurados para se conectar utilizando IPSec verificam inicialmente se são compatíveis com a tecnologia, em seguida os dois equipamentos devem detectar se existe ou não a tradução de endereços e em que parte do caminho a tradução ocorre. Por fim, deve-se negociar os parâmetros do protocolo (portas utilizadas para encapsulamento, utilização de cookies, etc) e em seguida iniciar a transmissão de dados utilizando pacotes encapsulados.
Toda essa negociação e troca de cookies (arquivos de texto contendo informações sobre a transmissão) se deve porque o ESP (Encapsulating Security Payload) que é o protocolo responsável por transmitir o payload do pacote IPSec não utiliza o mesmo conceito de portas utilizado nos protocolos TCP e UDP e, portanto, não é possível fazer a tradução de endereço através do NAT Tradicional.
No NAT Transversal cada conexão é enviada com os respectivos dados de tradução (porta de origem: porta de destino) e a resposta só é enviada após a recepção da primeira conexão. Desta forma é configurado um novo NAT a cada conexão entre cliente e servidor IPSec. Neste conceito existem três tipos de NAT-T:
No Full Cone NAT também conhecido como NAT 1 para 1, nele o cliente utiliza um endereço IP1:Porta1 para se comunicar com um servidor pelo IP2:porta2 sendo a resposta deste servidor enviada para a porta IP2:Porta2 e assim por diante, nesta forma de NAT o cliente pode contactar mais de um servidor em paralelo (1 para muitos).
No Restricted Cone NAT vemos que a comunicação se dá por duas portas mas apenas entre cliente e servidor (1 para 1). Caso um segundo servidor tentar responder o pacote será dropado pelo dispositivo que está fazendo o NAT-T.
No Port Restricted Cone NAT vemos que a restrição agora é por porta, onde apenas uma é utilizada para a comunicação entre cliente e servidor, no caso acima o servidor deve utilizar a porta que recebeu a comunicação para responder ao cliente e o Server 2 deve aguardar a conexão do cliente para então poder se comunicar.
Este terceiro caso é muito semelhante ao restricted cone, sendo a única diferença que o vinculo 1 para 1 é vinculado a porta, enquanto no restricted cone o vínculo é cliente servidor.
Além do ESP protocolos não vinculados a conexão como SIP e P2P também utilizam o NAT-T como uma forma de fazer NAT sem manter preso o número de porta a aplicação
A nível de sistemas operacionais, Windows a partir da versão 200 e XP (Artigo Microsoft Article ID: 818043) suportam nativamente o NAT-T para conexões VPN, como o applience que estou estudando também suporta nativamente este protocolo todos os sistemas Linux também suportam esta tecnologia.
O NAT-T está definido na RFC3947 que está na sessão de links abaixo.
Este conceito de NAT é muito semelhante ao modelo tradicional, eu compreendi claramente a diferença ao considera-lo orientado a pacotes, até por isso é chamado de encapsulamento UDP por alguns fabricantes.
Grande abraaaaço!
Fonte:
RFC 3947: http://www.ietf.org/rfc/rfc3947.txt
Artigo Microsoft ID818043: http://support.microsoft.com/kb/818043/en-us
Wikipedia EN: http://en.wikipedia.org/wiki/Network_address_translation
Wikipedia PT: http://pt.wikipedia.org/wiki/NAT_transversal
Materiais eLearning Sonicwall disponíveis em https://www.mysonicwall.com/Login.asp
(É necessário se registrar para ter acesso ao conteúdo).
Estudando IPSec, para desempenhar minhas novas atividades, conheci uma forma de NAT em que a tradução do endereço IP não é realizada através das portas de comunicação, o NAT-T é uma técnica onde os dois equipamentos que estão configurados para se conectar utilizando IPSec verificam inicialmente se são compatíveis com a tecnologia, em seguida os dois equipamentos devem detectar se existe ou não a tradução de endereços e em que parte do caminho a tradução ocorre. Por fim, deve-se negociar os parâmetros do protocolo (portas utilizadas para encapsulamento, utilização de cookies, etc) e em seguida iniciar a transmissão de dados utilizando pacotes encapsulados.
Toda essa negociação e troca de cookies (arquivos de texto contendo informações sobre a transmissão) se deve porque o ESP (Encapsulating Security Payload) que é o protocolo responsável por transmitir o payload do pacote IPSec não utiliza o mesmo conceito de portas utilizado nos protocolos TCP e UDP e, portanto, não é possível fazer a tradução de endereço através do NAT Tradicional.
No NAT Transversal cada conexão é enviada com os respectivos dados de tradução (porta de origem: porta de destino) e a resposta só é enviada após a recepção da primeira conexão. Desta forma é configurado um novo NAT a cada conexão entre cliente e servidor IPSec. Neste conceito existem três tipos de NAT-T:
Este terceiro caso é muito semelhante ao restricted cone, sendo a única diferença que o vinculo 1 para 1 é vinculado a porta, enquanto no restricted cone o vínculo é cliente servidor.
Além do ESP protocolos não vinculados a conexão como SIP e P2P também utilizam o NAT-T como uma forma de fazer NAT sem manter preso o número de porta a aplicação
A nível de sistemas operacionais, Windows a partir da versão 200 e XP (Artigo Microsoft Article ID: 818043) suportam nativamente o NAT-T para conexões VPN, como o applience que estou estudando também suporta nativamente este protocolo todos os sistemas Linux também suportam esta tecnologia.
O NAT-T está definido na RFC3947 que está na sessão de links abaixo.
Este conceito de NAT é muito semelhante ao modelo tradicional, eu compreendi claramente a diferença ao considera-lo orientado a pacotes, até por isso é chamado de encapsulamento UDP por alguns fabricantes.
Grande abraaaaço!
Fonte:
RFC 3947: http://www.ietf.org/rfc/rfc3947.txt
Artigo Microsoft ID818043: http://support.microsoft.com/kb/818043/en-us
Wikipedia EN: http://en.wikipedia.org/wiki/Network_address_translation
Wikipedia PT: http://pt.wikipedia.org/wiki/NAT_transversal
Materiais eLearning Sonicwall disponíveis em https://www.mysonicwall.com/Login.asp
(É necessário se registrar para ter acesso ao conteúdo).
terça-feira, 15 de maio de 2012
NIC.br e ICANN anunciam resolução DNS ainda mais segura e rápida no Brasil
O Núcleo de Informação e Coordenação do Ponto BR (NIC.br), emcooperação com a Internet Corporation for Assigned Names and Numbers(ICANN) instalaram, nos últimos dois meses, 14 novas cópias anycast doservidor L da ICANN, originalmente instalado na Califórnia - EUA.
A partir de hoje, as cópias de l.root-servers.net operam juntamente com servidores do .br nos Pontos de Troca de Tráfego no Brasil (PTTMetro). Das atuais 20 localidades que contam com Pontos de Troca de Tráfego do PTTMetro, as 14 que serão atendidas por essa melhoria são Belo Horizonte, Brasília, Campinas, Curitiba, Florianópolis, Fortaleza, Londrina, Porto Alegre, Rio de Janeiro, Salvador, São Paulo, São José dos Campos, Belém e Natal. Com isso, as cinco regiões do país serão beneficiadas pela nova infra estrutura de resolução de nomes.
Somados aos servidores que já existiam em operação, essa infra estrutura amplia substancialmente, e de forma distribuída, a capacidade de resolução de nomes e consequentemente a resiliência para suportar possíveis abusos ou ataques ao serviços DNS. Ela propicia também a continuidade operacional de regiões do país que estejam temporariamente segregadas tanto dos canais internacionais quanto da comunicação com outras regiões, por exemplo em função de múltiplos rompimentos na rede de longa distância das operadoras.
Anycast
Anycast é um serviço em que duas ou mais máquinas respondem pelo mesmo endereço IP,o servidor físico que responderá a solicitação é determinado de acordo com a rota IP a ser percorrida pelo cliente até o servidor, o servidor mais próximo responderá a solicitação.
O endereço IP do nó mais próximo configurado no Anycast é difundido pelo protocolo de roteamento BGP, e pode ser atualizado a cada atualização de roteamento deste protocolo, como o endereço do nó pode mudar conforme a disponibilidade de rota até ele, o anycast funciona melhor com protocolos não orientados a conexão (utilizam o UDP na camada de transporte).
Maiores detalhes, mapa com a localização dos servidores DNS da antigae nova estrutura dos servidores root-servers.net e .br neste LINK.
Fonte:
Registro.br
A partir de hoje, as cópias de l.root-servers.net operam juntamente com servidores do .br nos Pontos de Troca de Tráfego no Brasil (PTTMetro). Das atuais 20 localidades que contam com Pontos de Troca de Tráfego do PTTMetro, as 14 que serão atendidas por essa melhoria são Belo Horizonte, Brasília, Campinas, Curitiba, Florianópolis, Fortaleza, Londrina, Porto Alegre, Rio de Janeiro, Salvador, São Paulo, São José dos Campos, Belém e Natal. Com isso, as cinco regiões do país serão beneficiadas pela nova infra estrutura de resolução de nomes.
Somados aos servidores que já existiam em operação, essa infra estrutura amplia substancialmente, e de forma distribuída, a capacidade de resolução de nomes e consequentemente a resiliência para suportar possíveis abusos ou ataques ao serviços DNS. Ela propicia também a continuidade operacional de regiões do país que estejam temporariamente segregadas tanto dos canais internacionais quanto da comunicação com outras regiões, por exemplo em função de múltiplos rompimentos na rede de longa distância das operadoras.
Anycast
Anycast é um serviço em que duas ou mais máquinas respondem pelo mesmo endereço IP,o servidor físico que responderá a solicitação é determinado de acordo com a rota IP a ser percorrida pelo cliente até o servidor, o servidor mais próximo responderá a solicitação.
O endereço IP do nó mais próximo configurado no Anycast é difundido pelo protocolo de roteamento BGP, e pode ser atualizado a cada atualização de roteamento deste protocolo, como o endereço do nó pode mudar conforme a disponibilidade de rota até ele, o anycast funciona melhor com protocolos não orientados a conexão (utilizam o UDP na camada de transporte).
Maiores detalhes, mapa com a localização dos servidores DNS da antigae nova estrutura dos servidores root-servers.net e .br neste LINK.
Fonte:
Registro.br
sexta-feira, 30 de março de 2012
BHack Conference
Para minha felicidade ontem, lendo o blog do SegInfo [1] tomei conhecimento do BHack Conference, por ter as iniciais da minha cidade logo me empolguei, trata-se de uma conferência de segurança da informação organizada pelo DcLabs [2] que irá contar com palestrantes de peso da área técnica,gestão de segurança e direito digital.
Dentre os palestrantes confirmados estão:
Nelson Brito, Anchises Moraes, Tony Rodrigues Thiago Bordini e Rafael Soares com quem tive o prazer de aprender muita coisa sobre Forense Digital baseado em software livre em um curso da Clávis.
Agora é convidar nossos amigos de SI para prestigiar o evento para que este seja o primeiro de muitos, e para que Minas Gerais seja cada vez mais bem representada a nível de Brasil na área de Segurança da Informação.
Forte abraço até lá
Mais informações sobre o BHack Conference nos links abaixo:
Site
Facebook
Twitter
Fonte:
[1] Blog SegInfo
[2] DcLabs
Dentre os palestrantes confirmados estão:
Nelson Brito, Anchises Moraes, Tony Rodrigues Thiago Bordini e Rafael Soares com quem tive o prazer de aprender muita coisa sobre Forense Digital baseado em software livre em um curso da Clávis.
Agora é convidar nossos amigos de SI para prestigiar o evento para que este seja o primeiro de muitos, e para que Minas Gerais seja cada vez mais bem representada a nível de Brasil na área de Segurança da Informação.
Forte abraço até lá
Mais informações sobre o BHack Conference nos links abaixo:
Site
Fonte:
[1] Blog SegInfo
[2] DcLabs
terça-feira, 14 de fevereiro de 2012
Domain-based Message Authentication, Reporting and Conformance DMARC
O DMARC traduzindo, Autenticação resposta e conformidade baseada em domínios é um documento (tratado), que têm por objetivo minimizar o envio de mensagens indesejadas (SPAM) pela internet, este documento está em desenvolvimento e tem apoio dos grandes provedores de e-mail gratuito da internet, dentre eles estão Google, Yahoo, Microsoft, Facebook, LinkedIn, entre outros [1].
Este documento consiste na combinação do SPF (Send Policy Framework) e DKIM (Domain Key Identify Mail) além de técnicas que permitem o rastreamento de informações de tentativas de autenticação sem sucesso, então além de prevenir o envio de SPAMS há um esforço para identificar os responsáveis pela mensagem barrada pelos servidores configurados sob o DMARC, vamos conhecer um pouco mais do SPF e do DKIM, que são a base do DMARC?
SPF traduzindo, plataforma de políticas de envio
O SPF é um padrão aberto que permite através do registro TXT de um domínio DNS identificar quais servidores (Endereços IP's) podem enviar mensagem utilizando o nome de domínio em que o registro está configurado.
A Sintaxe do SPF é simples e pode agrupar um grande número de endereços IP's pois ele suporta a inclusão de CIDR's além de endereços IP's separados, maiores detalhes sobre o SPF podem ser encontrados no site do padrão [2].
DKIM traduzindo, Chave Identificadora de Domínio de E-mail
O DKIM anexa um novo identificador de nome de domínio nas mensagens usando técnicas de criptografia para validar que aquela mensagem foi enviada com autorização do provedor de e-mail, este identificador é independente de qualquer outro identificador do e-mail (Campo De:, Assunto: SMTP-ID e etc.). O resumo do DKIM é definido pela RFC 5585, e mais informações podem ser obtidas no site do projeto [3].
Ambas técnicas são conhecidas no mercado, eu conheci o SPF pela primeira vez em meados de 2009 quando estava reforçando as configurações do sistema de e-mails da minha atual empresa, já o DKIM é foi desenvolvido por um longo tempo e teve sua primeira utilização em 2005 pelo Yahoo! e pela Cisco Inc. Somadas as duas técnicas são poderosas, e podem tornar um protocolo tão importante para a internet mais seguro.
Fonte:
Links:
[1] DMARC - Specifications
[2] Open SPF Project
[3] Domain Keys Identified Mail (DKIM)
Forte abraço, feliz 2012 e até a próxima!!!
Este documento consiste na combinação do SPF (Send Policy Framework) e DKIM (Domain Key Identify Mail) além de técnicas que permitem o rastreamento de informações de tentativas de autenticação sem sucesso, então além de prevenir o envio de SPAMS há um esforço para identificar os responsáveis pela mensagem barrada pelos servidores configurados sob o DMARC, vamos conhecer um pouco mais do SPF e do DKIM, que são a base do DMARC?
SPF traduzindo, plataforma de políticas de envio
O SPF é um padrão aberto que permite através do registro TXT de um domínio DNS identificar quais servidores (Endereços IP's) podem enviar mensagem utilizando o nome de domínio em que o registro está configurado.
A Sintaxe do SPF é simples e pode agrupar um grande número de endereços IP's pois ele suporta a inclusão de CIDR's além de endereços IP's separados, maiores detalhes sobre o SPF podem ser encontrados no site do padrão [2].
DKIM traduzindo, Chave Identificadora de Domínio de E-mail
O DKIM anexa um novo identificador de nome de domínio nas mensagens usando técnicas de criptografia para validar que aquela mensagem foi enviada com autorização do provedor de e-mail, este identificador é independente de qualquer outro identificador do e-mail (Campo De:, Assunto: SMTP-ID e etc.). O resumo do DKIM é definido pela RFC 5585, e mais informações podem ser obtidas no site do projeto [3].
Ambas técnicas são conhecidas no mercado, eu conheci o SPF pela primeira vez em meados de 2009 quando estava reforçando as configurações do sistema de e-mails da minha atual empresa, já o DKIM é foi desenvolvido por um longo tempo e teve sua primeira utilização em 2005 pelo Yahoo! e pela Cisco Inc. Somadas as duas técnicas são poderosas, e podem tornar um protocolo tão importante para a internet mais seguro.
Fonte:
Links:
[1] DMARC - Specifications
[2] Open SPF Project
[3] Domain Keys Identified Mail (DKIM)
Forte abraço, feliz 2012 e até a próxima!!!
quinta-feira, 22 de dezembro de 2011
Gerencia de porta 25
No mês passado foi assinado pela CGI, Anatel e o Sindicato Nacional das Empresas de Telefonia e de Serviço Móvel Celular e Pessoal um acordo que altera a topologia de envio de e-mails entre os computadores pessoais (via Client de e-mail e os servidores emissores de e-mail, esta alteração visa diminuir o número de SPAM enviados e endereços IP's listados em BlackList, segundo o acordo as empresas de telefonia celular e fixa terão 12 meses para se adequar ao novo modelo.
Como funciona o envio de e-mails hoje, todos computadores com software cliente de e-mail instalado enviam mensagens utilizando a porta padrão do protocolo SMTP 25 como se fossem um relay do servidor que hospeda a caixa e-mails, desta forma hackers conseguem executar scripts de envio de spam através de computadores infectados (com um trojan por exemplo).
O acordo proposto pelo CGI propõe implementação do recurso de Submissão de mensagem para e-mail (Message Submission for Mail RFC 4409) que consistem em apontar o envio de e-mails dos clientes para os servidores utilizando uma porta TCP587 ou TCP465 (quando utilizamos SMTPS), possibilitando que os provedores utilizem autenticação nesta porta, filtros para e-mails não desejados e até controle de fluxo futuramente.
Desta forma a porta SMTP 25 ficaria destinada aos servidores de e-mail dos provedores do serviço e empresas que possuem servidores de e-mail interno. E todo o trafego da porta 25 vindo de computadores pessoais (por links ADSL/Cable Modem) residenciais serão eliminados tirando de operação os scripts de envio de e-mail malicioso.
Este acordo foi assinado devido a posição de atenção e que o Brasil está no Ranking mundial de envio de SPAM e número de IP's listados em CBL's, segundo o abuseat.org estamos em segundo lugar, mas no site antispam.br é possível ver que já fomos os primeiros nesta lista, quando o assunto é envio de SPAM já fomos o terceiro colocado em relação ao mundo (dados de 2010) com estas ações além de melhorar nossa reputação na internet teremos uma diminuição do uso de banda e recursos computacionais para envio de SPAMs que muitas vezes são destinados a outros países no exterior.
Fonte:
Gerencia da Porta 25 Antispam.br / CGI.br
Globo.com - Acordo entre Anatel/CGI e SindTeleBrasil
Olhar Digital - Brasil é o Terceiro Maior emissor de Spam
Grande abraço e boas festas!!! Plínio Devanier de Oliveira
Como funciona o envio de e-mails hoje, todos computadores com software cliente de e-mail instalado enviam mensagens utilizando a porta padrão do protocolo SMTP 25 como se fossem um relay do servidor que hospeda a caixa e-mails, desta forma hackers conseguem executar scripts de envio de spam através de computadores infectados (com um trojan por exemplo).
Desta forma a porta SMTP 25 ficaria destinada aos servidores de e-mail dos provedores do serviço e empresas que possuem servidores de e-mail interno. E todo o trafego da porta 25 vindo de computadores pessoais (por links ADSL/Cable Modem) residenciais serão eliminados tirando de operação os scripts de envio de e-mail malicioso.
Fonte:
Gerencia da Porta 25 Antispam.br / CGI.br
Globo.com - Acordo entre Anatel/CGI e SindTeleBrasil
Olhar Digital - Brasil é o Terceiro Maior emissor de Spam
Grande abraço e boas festas!!! Plínio Devanier de Oliveira
Assinar:
Postagens (Atom)
