Para obter a resposta específica à sua pergunta, consulte /magento//a/72700/361
fundo
Em primeiro lugar, não há exploração específica - há uma série de artigos em andamento no momento que interpretaram mal e entenderam mal o artigo de origem.
O artigo original apenas dizia (e estou parafraseando),
Se um hacker foram capazes de obter acesso a seus arquivos Magento, eles poderiam capturar informações de seu cliente
A parte principal é o hacker que realmente precisa acessar seu servidor e modificar arquivos.
Não entre em pânico ... isso não é nada específico do Magento
Em termos de captura de informações, não há nada específico para Magento do que qualquer outro site / plataforma. Se um hacker obtém acesso aos seus arquivos, seu jogo acaba efetivamente - ele poderá capturar qualquer informação que deseje.
O melhor que você pode fazer (e, finalmente, o mínimo que deve fazer) é manter uma boa política de segurança que atenda aos padrões de segurança PCI do setor de processamento de pagamentos. Você pode encontrar a lista aqui, https://www.pcisecuritystandards.org /documents/Prioritized_Approach_for_PCI_DSS_v3_.pdf
Endurecer sua loja
Você pode realmente bloquear facetas da sua loja que reduzem bastante a área de ataque de superfície de um hacker ou, pelo menos, retardam o progresso se conseguirem entrar /
Bloquear permissões
Você pode restringir permissões na raiz do documento para permitir apenas a gravação em diretórios essenciais ( /vare /media)
É o que fazemos por padrão no MageStack ,
echo -n "Fixing ownership"
chown -R $SSH_USER:$WEB_GROUP $INSTALL_PATH && echo " ... OK" || echo " ... ERROR"
INSTALL_PATH="/path/to/public_html"
chmod 750 $INSTALL_PATH
find $INSTALL_PATH -type d ! -perm 750 -exec chmod 750 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing file permissions"
find $INSTALL_PATH -type f ! -perm 740 -exec chmod 740 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing cron permissions"
find $INSTALL_PATH/*/cron.sh -type f ! -perm 750 -exec chmod 750 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing media/var file permissions"
chmod -R 760 $INSTALL_PATH/*/media $INSTALL_PATH/*/var && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing media/var directory permissions"
find $INSTALL_PATH/*/media $INSTALL_PATH/*/var -type d ! -perm 770 -exec chmod 770 {} \; && echo " ... OK" || echo " ... ERROR"
Ajuste INSTALL_PATH,SSH_USER,WEB_GROUPpara se adequar. O que é importante é que você SSH_USERnão é o mesmo usuário que o PHP usa para o processo do servidor da Web; caso contrário, você essencialmente forneceria acesso total de gravação ao servidor da Web (atenuando quaisquer benefícios).
Bloqueie seu acesso de administrador / downloader
No MageStack, você configuraria isso em ___general/x.conf
set $magestack_protect_admin true;
set $magestack_protect_downloader true;
No Nginx, você pode usar isso,
location ~* ^/(index.php/)?admin{
satisfy any;
allow x.x.x.x;
auth_basic "Login";
auth_basic_user_file /microcloud/data/domains/x/domains/x/___general/.htpasswd;
deny all;
location ~* \.(php) {
include fastcgi_params;
}
try_files $uri $uri/ /admin/index.php ;
}
Há um pouco mais de documentação sobre como preparar um .htpasswdarquivo aqui
Envolva o cron.shprocesso
Encontrei outros provedores de hospedagem usando máquinas dedicadas para uso do cron / admin - o que significa que a modificação do cron.sharquivo permitiria a execução remota de código no cron / admin sem precisar acessar. Encerrar o processo com o usuário certo em um fakechroot pode ir um pouco mais além para bloquear o processo.
Há muito código para eu postar, mas há um script aqui . É específico para o MageStack, mas pode ser ajustado para uso em configurações de servidor menos elegantes :)
Auditoria, auditoria, auditoria
O Linux é fantástico em termos de registro e acesso, oferecendo uma visão completa do que seu servidor está fazendo.
Um recurso fantástico no MageStack é a ferramenta de auditoria que registra todos os tipos de acesso e até alterações de arquivos diariamente. Você pode encontrar os logs aqui,
/microcloud/logs_ro
|-dh[0-9]+
|---access-YYYY-MM-DD.log.gz
|---backup-YYYY-MM-DD.log.gz
|---magescan-YYYY-MM-DD.log.gz
|---php-differential-YYYY-MM-DD.log.gz
|-acc[0-9]+
|---access-YYYY-MM-DD.log.gz
Se você não estiver usando o MageStack, poderá replicar parte disso com seu próprio provedor de hospedagem com bastante facilidade, rsyncsendo a ferramenta mais simples para fazer isso.
Por exemplo. Se seus backups estiverem disponíveis localmente, você poderá fazer o seguinte. Isso fará a comparação a seco de dois diretórios e produzirá uma lista de patches diff.
rsync -na /path/to/public_html/ /path/to/backup/public_html/ > change.log
grep -E '\.php$' change.log | while read FILE; do
diff -wp /path/to/public_html/$FILE /path/to/backup/public_html/$FILE >> php-differential.log
done
As mudanças no PHP são tão raras que você pode agendar isso para ser executado diariamente (ou várias vezes ao dia) e notificá-lo por e-mail se houver uma alteração no arquivo PHP.
Em suma
- Use o controle de versão, é mais fácil rastrear alterações
- Apenas ter um certificado SSL não é suficiente para tornar seu site seguro
- Não espere ser hackeado para considerar a segurança
- Só porque você redireciona para seu provedor de gateway de pagamento (versus captura de informações) - isso não significa que você pode evitar a conformidade com PCI, você ainda precisa
- Seja proativo, seguro e completo - verifique o código do módulo antes de instalá-lo, verifique os arquivos PHP diariamente, revise os logs, verifique o acesso FTP / SSH, altere as senhas regularmente
Seus clientes depositam uma enorme confiança em você quando repassam todas as suas informações privadas - e se você trair essa confiança ao não operar uma empresa segura, perderá o costume e todo o futuro.
As investigações forenses da PCI são incrivelmente caras, demoradas e acabam arriscando sua capacidade de receber pagamentos com cartão novamente. Nunca se deixe nessa posição!
Receba atualizações
Ultimamente, havia uma série de patches lançados pelo Magento que corrigiam buracos, incluindo alguns que permitiam a execução remota de código. Você pode buscá-los aqui, https://www.magentocommerce.com/products/downloads/magento/
Mas esses novos artigos não estão se referindo a uma nova exploração, eles estão simplesmente declarando como os hackers estão aproveitando as explorações históricas (ou qualquer outro vetor de ataque) para poder capturar informações do titular do cartão.
Fontes