Posts de Novembro, 2007

vnstat – Monitor de trafego de rede

Novembro 18, 2007

O vnStat é um monitor de tráfego para Linux, podendo gerar relatórios de tráfego por hora, dia, mês, top10 e outros.
Ideal para quem utiliza planos de transferencia de dados em GNU/Linux e deseja controlar o uso do serviço.

Para instalar o vnStat no Ubuntu/Debian:

apt-get install vnstat

Para dar as permissões aos usuários:

sudo chmod o+x /usr/bin/vnstat
sudo chmod o+wx /var/lib/vnstat/

Feito isso, há a necessidade de se criar um job no cron para que o vnStat passe a coletar as informações de tráfego:

vnstat -u -i ethx

ou

vnstat -u -i pppx

substituindo “x” pela id de sua interface (0, 1, etc)

Utilize o ifconfig para visualizar suas interfaces de rede

Agora execute o vnStat pelo console (Digitar “vnstat” no prompt):

Saida padrão vnstat:

root@andre-desktop:/usr/bin# vnstat
Database updated: Sun Nov 18 16:25:01 2007

ppp0

received: 25.48 MB (83.3%)
transmitted: 5.03 MB (16.7%)
total: 30.51 MB

rx | tx | total
———————–+————+———–
yesterday 12.68 MB | 3.07 MB | 15.75 MB
today 11.16 MB | 1.74 MB | 12.91 MB
———————–+————+———–
estimated 16 MB | 1 MB | 17 MB

Parametros do vnstat:

Tráfego diário:

$ vnstat -d

Saida do comando:

root@andre-desktop:/usr/bin# vnstat -d

ppp0

day rx | tx | total
————————+————-+————–
16.11. 1.63 MB | 0.20 MB | 1.83 MB
17.11. 12.68 MB | 3.07 MB | 15.75 MB
18.11. 11.16 MB | 1.74 MB | 12.91 MB
————————+————-+————–
estimated 16 MB | 1 MB | 17 MB

Tráfego mensal:

$ vnstat -m

Saida do comando:

root@andre-desktop:/usr/bin# vnstat -m

ppp0

month rx | tx | total
————————+—————+—————
Nov ‘07 25.48 MB | 5.03 MB | 30.52 MB
————————+—————+—————
estimated 42 MB | 8 MB | 50 MB

Para listar todos os parametros do vnstat, utilize o comando vnstat –help

Saida do comando:

root@andre-desktop:/usr/bin# vnstat –help
vnStat 1.4 by Teemu Toivola

-q, –query query database
-h, –hours show hours
-d, –days show days
-m, –months show months
-w, –weeks show weeks
-t, –top10 show top10
-s, –short use short output
-u, –update update database
-i, –iface change interface (default: ppp0)
-?, –help short help
-v, –version show version
-tr, –traffic calculate traffic

Você também poderá obter mais informações utilizando o man vnstat.

Boa sorte.

Ambiente de rede virtual – Microsoft Loopback Adapter

Novembro 14, 2007

O Microsoft Loopback Adapter é uma ferramenta de testes para um ambiente de rede virtual no qual o acesso à rede não está disponível. Além disso, é possivel usar o adaptador de Loopback se houver conflitos com um adaptador de rede ou com um driver de adaptador de rede.

Caso você utilize uma maquina virtual (MS Virtual PC), você poderá fazer a conexão entre o host virtual e o host que hospeda suas maquinas virtuais.

Instalação:

Para instalar manualmente o Microsoft Loopback Adapter no Windows XP ou Windows 2003, execute as seguintes etapas:

1 – Clique em Iniciar e em Painel de controle.
2 – Se estiver no modo de exibição Clássico, clique em Alternar para o modo de exibição por categoria em Painel de controle no painel à esquerda.
3 – Clique duas vezes em Impressoras e outros itens de hardware e clique em Avançar.
4 – Em Consulte também no painel à esquerda, clique em Adicionar hardware e em Avançar.
5 – Clique em Sim, já conectei o item de hardware e em Avançar.
6 – Na parte inferior da lista, clique em Adicionar novo dispositivo de hardware e em Avançar.
7 – Clique em Instalar o hardware que eu selecionar manualmente em uma lista e em Avançar.
8 – Clique em Adaptadores de rede e em Avançar.
9 – Na caixa Fabricante, clique em Microsoft.
10 – Na caixa Adaptador de rede, clique em Microsoft Loopback Adapter e em Avançar.
11 – Clique em Concluir.

Após a instalação do adaptador ser concluída com êxito, você poderá configurar manualmente suas opções, da mesma forma que qualquer outro adaptador.

Se as propriedades TCP/IP estiverem configuradas para usar DHCP, o adaptador usará, eventualmente, um endereço autonet (169.254.x.x/16) uma vez que ele não está realmente conectado a uma mídia física.

Observação Por padrão, as propriedades TCP/IP são configuradas para usar o DHCP.

Aumentando a vida útil dos HDs – GNU/Linux

Novembro 9, 2007

Excelente artigo sobre o problema de redução de vida util dos discos rigidos em algumas distribuições GNU/Linux, escrito pelo Prof Alex França em seu blog.

Introdução

Recentemente, uma notícia no br-linux alertou sobre a possibilidade do gerenciamento de energia de algumas distribuições GNU/Linux, do Ubuntu em especial, estarem reduzindo a vida útil dos discos rígidos (HDs). Como noticiado em diversos sites da internet, isto não é um bug do Ubuntu. Na verdade, o Ubuntu apenas segue as recomendações equivocadas fornecidas pelos próprios fabricantes de notebooks e desktops. Neste artigo, o problema é explicado em detalhes e uma solução bastante simples é apresentada. Esta é baseada em um script que necessita ser executado uma única vez e faz todo o trabalho para correção do problema. Além disso, o artigo termina fazendo uma breve discussão sobre o pacote smartmontools que monitora o estado do HD e informa quando este está na eminência de sofrer alguma falha.

Entendo o problema

Pode-se pensar em um HD como aqueles antigos toca-discos usados com os LPs de vinil. Neste caso, o disco de vinil é a superfície de armazenamento, enquanto a agulha pode ser considerada a cabeça de gravação. Normalmente, no caso dos HDs, a cabeça de gravação não toca a superfície do disco. Ao invés disso, esta fica a uma distância segura. Evidentemente, o contato da cabeça de gravação com a superfície do disco durante uma queda ou tombo pode danificá-lo. Então, para permitir o transporte seguro dos equipamentos, foi criada a tecnologia de carga/descarga (load/unload). Basicamente, tal tecnologia permite que a cabeça de gravação seja movida para uma região bem distante da superfície do disco quando este não estiver sendo utilizado, por exemplo, quando o equipamento está em estado de hibernação para economizar energia. É claro, antes do HD poder ser utilizado novamente, a cabeça deve retornar para a sua posição de operação normal.

Desktops também, mas principalmente os notebooks possuem um sistema de gerenciamento de energia. Este desliga alguns dispositivos do hardware que não estão sendo utilizados. É claro que isso também se aplica aos HDs. Assim, para economizar energia, muitas vezes os HDs têm sua rotação reduzida ou até mesmo são desligados temporariamente. Além de economizar energia, se for feito de forma eficiente, isto aumenta a vida útil do HD, pois mantém a sua temperatura mais baixa.

Quando entram em modo de economia de energia, a cabeça de leitura/gravação dos HDs também podem ser descarregadas (unloaded). Quem decide quando fazer isso é o sistema operacional, através de seu sistema de gerenciamento de energia. Este é um ponto importante, pois existe um limite máximo de vezes que a cabeça de gravação pode ser carregada/descarregada. Um valor bastante aceito pare este limite é 600.000 vezes. Contudo, outros autores afirmam que este valor vale apenas para HDs da Hitachi. Para HDs de outros fabricantes, o valor é apenas 200.000. Após ultrapassar este limite, o HD tem uma grande chance de apresentar perdas de dados.

Em tese, os fabricantes dos notebooks são os mais indicados para decidir a melhor estratégia de carga/descarga dos HDs. Apensar disso, as versões do Windows e do MacOS ignoram as recomendações dos fabricantes e impõem suas próprias estratégias de gerenciamento de energia. Ao contrário, por serem mais fieis aos padrões da indústria, distribuições baseadas no GNU/Linux como, por exemplo, o Ubuntu, realizam o gerenciamento de energia segundo as recomendações dos fabricantes. O problema é que (pasmem) a maioria dos fabricantes fornecem parâmetros absurdos ao sistema operacional. Em alguns casos, se forem seguidos, tais parâmetros podem fazer com que o HD seja carregado/descarregado até 3 vezes por minuto. Neste caso, a vida útil do HD chega ao fim apenas após alguns meses de uso.

Detectando o problema

No Ubuntu, para verificar se o gerenciamento de energia está impondo ciclos de carga/descarga demais ao HD, é necessário instalar o smartmontools. Para isso, simplesmente, deve ser executado o comando a seguir.

sudo apt-get install smartmontools

Com o smartmontools instalado, pode-se utilizar o smartctl como segue para visualizar o número de ciclos de carga que o HD já foi submetido.

sudo smartctl -A /dev/sda | grep Load_Cycle_Count

Evidentemente, /dev/sda deve ser substituído com o dispositivo que deseja-se inspecionar.

A saída do comando anterior é algo como segue.

193 Load_Cycle_Count 0×0032 189 189 000 Old_age Always – 35715

Em tal saída, a informação importante é o último número, o 35715. Este é o número de ciclos de carga do HD. Deve-se esperar algo em torno de 10 ou 20 minutos antes do smartctl ser executado novamente. Isso dará uma estimativa de quantas vezes por minuto o HD está sofrendo um ciclo de carga/descarga. Sabendo que um HD pode sofrer 200.000 ciclos desse tipo, pode-se estimar quantas horas de vida útil ele tem. O ideal é que, durante o intervalo de uns 20 minutos, não seja feito (quase) nenhum ciclo de carga. Contudo, ao invés disso, se o sistema de gerenciamento de energia estiver sendo muito agressivo com o HD, deve-se corrigir o problema.

Corrigindo o problema

Para corrigir o problema, a forma mais prática talvez seja executando o script abaixo como root.

#!/bin/sh

PARAM=255
HD=/dev/sda

echo “#!/bin/sh” > 99-hdd-spin-fix.sh
echo “hdparm -B $PARAM $HD” >> 99-hdd-spin-fix.sh

chmod +x 99-hdd-spin-fix.sh

cp 99-hdd-spin-fix.sh /etc/acpi/suspend.d/
cp 99-hdd-spin-fix.sh /etc/acpi/resume.d/
mv 99-hdd-spin-fix.sh /etc/acpi/start.d/

Parâmetros importantes do script acima são as variáveis PARAM e HD. A variável PARAM pode ser igual a 255 ou 254. O valor 255 desliga o gerenciamento de energia do HD completamente. Assim, os ciclos de carga serão mínimos, mas o HD ficará a uma temperatura mais elevada que o normal. Contudo, é consenso que o HD pode lidar melhor com alguns graus de temperatura a mais do que muitos ciclos de carga. Por outro lado, o PARAM=254 faz com que o gerenciamento de energia para o HD continue ativo, mas de uma forma menos agressiva. Por último, a variável HD deve ser alterada se o dispositivo do HD que se deseja proteger seja diferente de /dev/sda.

Antes de executar o script anterior deve-se copiar e colar as linhas de código acima em um arquivo texto, salva-lo como hdd-spin-fix.sh e executá-lo como segue.

sudo sh hdd-spin-fix.sh

Pronto! Após isso, a próxima vez que o sistema for iniciado, gerenciamento de energia será bem mais gentil com o HD.

Monitorando outros problemas

Um fato importante a ser observado é que o smartctl não fornece apenas informações sobre a quantidade de ciclos de carga. Por exemplo, o comando a seguir fornece dezenas de informações sobre o HD em /dev/sda.

sudo smartctl -a /dev/sda

Há um excelente artigo do Linux Journal que explica todas as informações retornadas pelo smartctl. Tais informações fornecem estimativas bastantes exatas de quando e porque o HD dará problema. Contudo, não é necessário usar o smartctl frequentemente para monitorar a saúde do HD. Ao invés disso, o pacote smartmontools instala um daemon (o smartd) que é ativado na carga do sistema. Assim, basta instalar o smart-notifier com o comando a seguir para ser notificado por uma janela pop-up quando o HD tem uma grande probabilidade de dar problema.

sudo aptitude install smart-notifier

Evidentemente, para funcionar de forma adequada, o smart-notifier deve ser executado sempre que uma nova sessão for iniciada.

fonte

Boot rápido e serviços balanceados para Linux.

Novembro 7, 2007

Texas Flood Init System.

Este é um freeware desenvolvido por Luciano Andress Martini e Lúcia Yulle Krüger Paes

Como a edição Generic foi recentemente criada, seu número mudou
de 2.5 para 0.1 visando uma melhor organização.

Última Versão: Texas Flood 0.1 Beta2

change-log:
Change-Log Ver. 0.1 generic (Beta2)
-Correção de bug: serviços do terceiro estágio eram carregados sem log e de forma que atrapalhava
em muito o desempenho em sistemas modo texto, não mudando em nada o tempo de carga.
-Corrigido comando para atribuição de serviços nas instruções de uso: dia 05/11/2007 20:11
Change-Log Ver. 0.1 generic (Beta1)
-Correção de bug: serviços do terceiro estágio eram ignorados
Como funciona o Texas Flood?
Change-Log Ver. 0.1 generic (Beta0)
-Correção de bug para desinstalar, backups eram sobrescritos
-Adição do programa texasflood-remove para remover o texas flood, através de um único comando.
-Adição de um arquivo com documentação em português
-Correção do suporte à linguas(português) no arquivo /etc/texasflood.conf
Change-Log Ver 0.1 generic (Alpha)
-Tentativa de implementar suporte a distribuições diversas
-Injeção direta de Init

Como funciona?

O Texas Flood reduz o tempo de boot e de resposta do seu sistema, divindo-o em 3 linhas de processo.
Estas linhas de processo são capaz de reagir de forma inteligente entre si calculando dependências e prioridades. O resultado é um boot limpo e rápido com quantos serviços você quiser atribuir.

Para finalizar o texas flood ajusta a prioridade dos programas, e a forma como o seu sistema gerencia a memória deixando sua distribuição muito mais rápida.

Como surgiu?

Desenvolvido originalmente para a distribuição linux Resulinux,
o Texas Flood é uma alternativa poderosa ao SYSVINIT capaz de reduzir assustadoramente os tempos de boot e de resposta dos programas.
Até bem pouco tempo atras o programa era suportado apenas por esta distribuição, mas numa tentativa de contribuir com o
mundo livre, o Texas Flood começou a lançar versões entituladas como “GENERIC/VERY EXPERIMENTAL”.
A primeira tentativa de portar o Texas Flood para outras distribuições foi com a criação do Texas Flood 2.1 Green Edition sucedido apenas em distribuições baseadas no Debian(excluindo as que usam Upstart como o Ubuntu)
Apesar disso o número de peculariedades que vinham do Resulinux eram muito grande nesta versão.
Com a criação da versão 0.1 Generic, o Texas Flood assumiu o papel do INIT e o número de peculariedades diminuiu, alem disso ele ganhou um controle personalizavel(leia as instruções de uso).

Instruções de Uso:

1.0 Instalação:
Para instalar o Texas Flood deve-se proceder da seguinte maneira:

1.1 Executando o setup
Baixe o texasflood0.1.tar.gz do site do Texas Flood.
Rode os seguintes comandos:
tar -zxf texasflood0.1.tar.gz – Para descompactar o arquivo
cd texasflood0.1 – Para entrar na pasta gerada pela descompactação
./setup (faça isso estando no seu ambiente gráfico, se você possuir um) – Para iniciar o instalador

1.2 Editando o arquivo /etc/texasflood.conf
É recomendável que você leia com atenção(incluindo comentários) todo o arquivo /etc/texasflood.conf
sem pular nenhuma virgula verificando se tudo esta configurado como deveria, e se os comandos que ele esta usando
para chamar suas aplicações de fato existem. Lembre-se que esta é uma versão instável.
Se você tiver de mudar algum comando, informe isto em nosso fórum de suporte, não se
esqueça de falar qual é a distribuição utilizada.

1.3 Reiniciando pela primeira vez:
Note que o seu sistema perdeu a capacidade de reiniciar, agora que você instalou o Texas Flood.
Isso porque o init é o processo 0 da máquina, e ao modifica-lo o Kernel costuma reagir
de uma maneira confusa.
Va para o modo texto e execute:
reboot –real.
Uma vez no próximo boot, o texas flood sendo executado volta a ser possivel reinciar o computador.
Isto esta sendo corrigido na versão Beta2.

2.0 Gerenciamento de Serviços:
O texas flood não esta interessado em remover seus serviços de boot
apesar de isso ocorrer quando você estiver instalando-o pela primeira vez, assim como ocorre na instalação de um SYSVINIT diferente do instalado anteriormente numa distribuição.
Você poderá atribuir seus serviços de uma forma parecida com aquela feita no SYSVINIT.

2.1 Serviços do terceiro estágio:
É aqui que serão atribuidos praticamente todos os seus serviços como apache, sshd, cupsys(que já vem atribuido), e outros.
Ainda é possível alterar a prioridade desses serviços na linha S3_PRIORITY contida no /etc/texasflood.conf
Exemplo de atribuição de serviços no estágio 3:
ln -sf /etc/init.d/apache /etc/texasflood/stage3
Outro exemplo útil: Atribuindo todos os serviços do RUNLEVEL 5 do SYSVINIT no estágio Terceiro estágio do Texas Flood:
ln -sf /etc/rc5.d/* /etc/texasflood/stage3
(Nota o comando cp -a /etc/rc5.d/* /etc/texasflood/stage3 foi retirado daqui porque estava com problemas.)

2.2 Serviços do segundo estágio:
O segundo estágio é virtual e representa o Xorg se presente, por isso não é recomendável atribuir serviços à ele somente se isso de fato for necessário.
Vide /etc/texasflood.conf

2.3 Serviços do primeiro estágio:
O estágio 1 não é o lugar certo para colocar servidores ou serviços em geral, ainda que isso seja possível.
Coloque aqui somente o que precisa ser carregado antes do XORG, e para deixar claro praticamente nenhum serviço precisa ser colocado aqui, porque o Texas Flood já carrega estes tipos de serviço, mas quando isso não acontece é preciso atribui-los aqui manualmente.
Ainda é possível alterar a prioridade desses serviços na linha S1_PRIORITY contida
no /etc/texasflood.conf
Exemplo de atribuição de serviços essenciais para o Xorg no estágio 1:
ln -sf /etc/init.d/xfs /etc/texasflood/stage1/xfs
(comparação com o SYSVINIT : ln -sf /etc/init.d/xfs /etc/rc5.d/S01xfs)

3.0 Balanceamento de prioridades em tempo real
(/etc/texasflood.list):

Alem das prioridades fixas que podem ser ajustadas em /etc/texasflood.conf.
O texas flood ainda permite que o usuário ajuste prioridades de processos que estarão executando no pós-boot.
Isto é feito no arquivo /etc/texasflood.list, que contém uma lista de processos com suas respectivas prioridades.

3.1 Sintaxe:
Para editar o arquivo /etc/texasflood.list, utilize a seguinte sintaxe:
Processo Prioridade.
Onde a prioridade é um valor de 20 a -20.
Valores NEGATIVOS definem prioridades mais ALTAS(o programa rodará mais rápido em relação aos demais).
Valores POSITIVOS definem prioridades mais BAIXAS(o programa rodará mais lentamente).

3.2 Exemplos:
Veja um exemplo de entradas do arquivo /etc/texasflood.list:
#Prioridade máxima para o firefox:
firefox -20
#Prioridade minima para o kdesktop:
kdesktop 20
#Prioridade normal para o kwin
kwin 0
#Prioridade alta para o vi
vi -12
#Prioridade 4 para o kedit
kedit 4
#Prioridade -17 para o bash
bash -17
Ao definir as prioridades no arquivo /etc/texasflood.list, o Texas Flood é capaz de perceber isso
enquanto esta em execução sem necessidade de reinicialização.
Portanto salve o arquivo e o observe numa ferramenta como o ksysguard como os processos
que você definiu vão mudando de prioridade aos poucos.

3.3 Erros de sintaxe:
Exemplo de erro de sintaxe:
vi -12 #Isto é um comentário
O caracter # faz com que o CONTROLLER_B ignore toda a linha, por isso esta linha não teria nenhum efeito sobre o sistema.

3.4 Limitações:

gcc -8
O controller B pode demorar para perceber que determinado processo entrou na memória, portanto o gcc sai e entra muitas vezes enquanto um programa esta sendo compilado, fazendo com que a linha abaixo não chege a surtir os efeitos desejados, ainda que seja possível defini-la:

4.0 Arquivos:

4.1 Arquivos de configuração:
/etc/texasflood.conf – Contém as configurações básicas para o funcionamento do Texas Flood
/etc/texasflood.list – Contém as entradas para o balanceamento de processos(vide 3.0 Controller B)

4.2 Arquivos de usuário:
/sbin/texasflood-remove – Remove o Texas Flood

4.3 Arquivos de controle:
/etc/texasflood-signal – Contém o sinal atual do Texas Flood (não altere isso, a menos que saiba o que esta fazendo)

4.4 Arquivos executáveis:
/sbin/init – Controller A e B
/sbin/shutdown – Apenas para compatibilidade com Shutdown(sendo melhorado, no momento só faz reboot ou desliga, sem esperar)
/sbin/halt – Desliga o computador (sinal 0)
/sbin/reboot – Reinicia o computador (sinal 6)
/sbin/texasflood-start – Controle de Estágios
/sbin/direct_reboot – Reboot físico (Assembler)
/sbin/direct_halt – Halt físico (Assembler)
/sbin/killall5 – Herdado do SYSVINIT, mata todos os processos em execução (em C)

5.0 Desinstalação:
Para desinstalar o texasflood execute o seguinte comando como root:
texasflood-remove

6.0 Sobre:
O Texas Flood é o sistema de boot desenvolvido para a distribuição Linux Resulinux.
Até bem pouco tempo atras o programa era suportado apenas por esta distribuição, mas numa tentativa de contribuir com o
mundo livre, o Texas Flood começou a lançar versões entituladas como “GENERIC/VERY EXPERIMENTAL”.
A primeira tentativa de portar o Texas Flood para outras distribuições foi o Texas Flood 2.1 Green Edition
sucedido apenas em distribuições baseadas no Debian(excluindo as que usam Upstart como o Ubuntu)
Apesar disso o número de peculariedades que vinham do Resulinux era muito grande nessa versão, com a criação da versão 0.1 Generic, o Texas Flood assumiu o papel do INIT e o número de peculariedades diminuiu,
alem disso ele ganhou um controle de prioridade fácil de personalizar.
Para o Resulinux o Texas Flood é um programa estável, mas para outras distribuições, ele ainda pode causar alguns problemas.

Download:

Suporte

Site da Oi é modificado para infectar visitantes

Novembro 6, 2007

Hoje em uma das empresas onde trabalho, “surgiu” uma maquina infectada por um trojan, o antivirus (NOD32) detectou o arquivo, mas não conseguia exclui lo.
Utilizei o programa Process Explorer da microsoft para encontrar o processo e o mesmo utilizando uma de suas funções me direcionou para o site da Intercraft para obter informações a respeito do trojan.

Segue abaixo a materia, uma screen do Process Explorer indicando o serviço correspondente ao trojan e o processo para solucionar o problema.

A Linha Defensiva tomou conhecimento (21/09), às 22:46, de que o site da operadora de telefonia Oi — www.oi.com.br — estaria infectado e servindo um cavalo de tróia que rouba senhas de banco (Banker). A presença do código malicioso foi confirmada por testes da equipe de análise da Linha Defensiva e, de acordo informações de um atendente da Oi, a empresa de telefonia já estaria ciente do problema existente em seu site.

O código malicioso servido pelo site é capaz de roubar senhas de banco. O ladrão de senhas possui um tamanho de 13,7MB — um tamanho pouco otimizado para pragas digitais, considerando-se que tamanhos menores favorecem a instalação rápida do vírus. Este componente do vírus, chamado de Windows32.exe, é detectado por diversos antivírus. Outro componente da praga, de 5MB, foi detectado por apenas 3 dos 33 antivírus do site VirusTotal.

SysInternal

O vírus é instalado por meio de uma falha de segurança no Internet Explorer: qualquer usuário de Internet Explorer que não estiver com o patch instalado e visitar o site malicioso terá seu computador infectado automaticamente, sem a necessidade de autorizar a execução ou o download de qualquer arquivo.

Logo depois de ser instalado, o trojan desativa o firewall embutido do Windows XP e tentará remover o programa de segurança G-Buster Browser Defense, comumente instalado pelos bancos.

O site www.oi.com.br continua infectado até o momento da publicação desta matéria. É provável que o código malicioso tenha sido colocado no site em uma invasão executada pelos próprios criadores do ladrão de senhas. Acessos pelos endereços www.telemar.com.br e www.novaoi.com.br não resultam em uma infecção.

A ferramenta de remoção gratuita BankerFix, da Linha Defensiva, foi atualizada para remover cavalo de tróia. O Yahoo!, responsável pela hospedagem do vírus, e o MelbourneIT, serviço de registro usado pelo site malicioso, foram avisados para retirar a praga digital do ar.

Como saber se você está infectado
Estas instruções servem para Windows 2000 e mais recentes:

Aperte CTRL+SHIFT+ESC (segure CTRL e SHIFT ao mesmo tempo e então aperte ESC)
Clique na aba Processos
Se você encontrar o Windows32.exe na lista, você está infectado
No caso de Windows ME, 98/SE e 95:

Vá até o C:\
Verifique a presença de um arquivo chamado start
Vá até a pasta Arquivos de Programas
Confirme a presença de um arquivo chamado Windows32 que possui um ícone de programa de instalação
Se você encontrar estes dois arquivos, seu sistema está infectado
Se a infecção for confirmada, o BankerFix pode ser usado para removê-la.

Recomendações
Vários outros sites foram vítimas de criminosos que modificaram as páginas de forma maliciosa para infectar visitantes. Recentemente, anúncios maliciosos circularam no Photobucket e no MySpace e o site do Banco da Índia foi alterado para instalar um ladrão de senha em seus visitantes.

Em janeiro de 2006, o fórum da fabricante de processadores AMD foi modificado para incluir um arquivo de imagem WMF malicioso que infectava usuários. Em abril deste ano, o mesmo ocorreu com o site da também fabricante de hardware ASUS.

Para evitar ser infectado neste tipo de situação em que um site legítimo é comprometido por criminosos, mantenha seu navegador atualizado usando o recurso de atualização automática. No caso do Internet Explorer, que é o alvo deste ataque, o Windows Update é uma alternativa, mas prefira as atualizações automáticas (que podem ser configuradas no Painel de Controle).

Se você utiliza um navegador como Firefox ou Opera, ainda é importante usar a versão mais recente. Estes navegadores possuem sistemas de atualização automática que podem lhe avisar quando uma correção de segurança está disponível

Fonte

Download do BankerFix