Search the Community

A gigante do comércio eletrônico recentemente lançou uma advertência para sites de comércio eletrônico realizar atualizações o mais rápido possível para evitar ataques. A plataforma que muitas lojas virtuais ao redor do mundo utiliza diariamente, é o alvo favorito do coletivo Magecart de grupos de ameaças que desnatam cartões de crédito clonado. A popular plataforma de comércio eletrônico Magento esta incentivando os administradores da Web a instalar sua mais recente atualização de segurança para se defender contra ataques maliciosos que possam explorar uma vulnerabilidade crítica à execução remota de código. Embora a empresa não tenha especificado quais tipos de ataques em potencial os sites deveriam se preocupar (Threatpost entrou em contato para comentar sobre isso), o Magento é um alvo comum para a associação de grupos de ameaças Magecart , que compromete sites construídos em e-commerce sem patches. plataformas para injetar scripts de leitura de cartões nas páginas de checkout. Os scripts roubam os detalhes do cartão de pagamento dos clientes e outras informações inseridas nos campos da página. A vulnerabilidade ( CVE-2019-8144 ), que possui uma classificação de gravidade de 10 em 10 na escala CVSS v.3, pode permitir que um usuário não autenticado insira uma carga maliciosa no site de um comerciante através dos métodos de modelo do Page Builder e execute isto. O Page Builder permite que os sites projetem atualizações de conteúdo, visualizem-nas ao vivo e planejem que sejam publicadas. O bug existe especificamente na função de visualização. A falha afeta o Magento 2.3 e foi corrigida no Magento e-commerce 2.3.3 com o patch apenas de segurança 2.3.2-p2, lançado em outubro . A empresa alertou que o patch terá o efeito colateral de "impedir que os administradores visualizem pré-visualizações de produtos, blocos e blocos dinâmicos"; mas disse que reativará a funcionalidade de visualização o mais rápido possível. “Recomendamos que todos os comerciantes, mesmo aqueles que já fizeram o upgrade para o 2.3.3 ou tenham aplicado o patch apenas de segurança 2.3.2-p2, revisem a segurança do site Magento para confirmar que não estavam potencialmente comprometidos antes da atualização”, Piotr Kaminski da equipe de segurança do Magento escreveu em uma postagem em 11/11/2019." A aplicação dessa correção ou atualização, ajudará a defender sua loja contra possíveis ataques daqui para frente, mas não abordará os efeitos de um ataque anterior. A mesma atualização corrige várias outras falhas críticas de execução remota com uma pontuação CVSS v.3, igual a 9 ou acima, além de problemas de script entre sites (CSS). O aviso ocorre quando a atividade e a infraestrutura do Magecart continuam saturando a web. De acordo com a análise do RiskIQ no mês passado, agora existem 573 domínios de comando e controle (C2) conhecidos para o grupo, com cerca de 10.000 hosts carregando ativamente esses domínios. Ao todo, o RiskIQ detectou quase 2 milhões (2.086.529) de instâncias dos binários javaScript da Magecart, com mais de 18.000 hosts de comércio eletrônico violados diretamente. "É lamentável que esse tipo de ataque ainda seja bem-sucedido, embora uma atenuação seja bastante direta", disse Mounir Hahad, chefe do Juniper Threat Labs da Juniper Networks, por e-mail." Como último recurso, os proprietários de sites devem verificar periodicamente a integridade de seu código de script, o que pode ser tão simples quanto calcular uma soma de verificação a cada poucos minutos para procurar uma mudança inesperada." Quais são os principais riscos para as empresas modernas na era de pico de violações de dados? A Delta Servers está constantemente atualizando os sistemas de segurança para essa plataforma e-commerce, recomendamos que façam o mesmo.

Olá pessoal estou abrindo este tópico para compartilhar com vocês mais um segredo para aumentar a segurança dos seus servidores. Essa segurança visa bloquear o acesso ao admin do wordpress para ips internacionais. É bom lembrar que sistemas automatizados tentam fazer brutal force nas admins gerando alto consumo de CPU. Esperar pelos usuários para que os mesmos deixem seus Wordpress seguros é bastante arriscado e você pode ter problemas de estabilidade. Para instalar essa segurança extra, crie um arquivo chamado .htaccess e coloque dentro da /home/ e cole as linhas deste arquivo presente no link abaixo http://www.myway.com.br/security/htaccess.txt Não esqueça de deixar o arquivo no servidor chamado de .htaccess ( ponto htaccess ) ( INCLUA O IP DO SEU SERVIDOR EM UMA LINHA DE ALLOW ) Nós atualizamos os ips nacionais hoje nesta lista e regularmente atualizamos também em http://www.myway.com.br/security/IpsBrasilFinal.txt Nós temos outro tutorial onde ensinamos a manter essa lista atualizada no link abaixo Veja que se você atualizar os ips, você precisará também colocar um ( Allow from ) ao lado esquerdo da faixa nova. Caso tenha dúvidas para instalar essa proteção extra para Wordpress, responda esse tópico Sucesso a todos !

Seu site é feito com WORDPRESS? Então assista a essa aula agora e aprenda o processo de blindagem no seu WordPress acesse agora: https://www.youtube.com/watch?v=5sxgcTzVGP0

Se você usa o Maldet junto com o Modsecurity - para verificação de vírus em uploads de arquivos através do navegador - em servidores com muitos acessos, talvez tenha notado que o Maldet passa muito tempo para verificar o arquivo e muitas vezes redireciona para uma página de erro. Isso acontece por o Maldet verificar as pastas /dev/shm /var/tmp e /tmp sempre que um escaneamento é feito. Então, havendo muitos arquivos, o escaneamento se torna lento. O seguinte patch evita isso e também adiciona o parâmetro --notmp para pular a verificação de arquivos nas pastas acima. Localize: tmpdir_paths="/dev/shm /tmp /var/tmp" Acrescente abaixo: if [ ! -z "$notmp" ]; then tmpdir_paths=""; fi Localize: if [ -z "$setmodsec" ]; then eout "{scan} building file list for $spath, this might take awhile..." 1 fi $find $spath $tmpdir_paths -maxdepth $maxdepth -type f -size +${minfilesize}c -size -$maxfilesize $ignore_fext | grep -vf $ignore_paths > $find_results Substitua por: if [ -z "$setmodsec" ]; then eout "{scan} building file list for $spath, this might take awhile..." 1 $find $spath $tmpdir_paths -maxdepth $maxdepth -type f -size +${minfilesize}c -size -$maxfilesize $ignore_fext | grep -vf $ignore_paths > $find_results else echo "$spath" > $find_results fi Localize: --modsec) setmodsec=1 ;; Acrescente abaixo: -T|--notmp) notmp=1 ;; Para evitar que automaticamente seja feito escaneamento da pasta /tmp toda vez que um escaneamento em outro diretório é feito, use o parâmetro --notmp ou -T Infelizmente esta edição será desfeita se o Maldet for atualizado. Para evitar isso, torne o arquivo imutável: chattr +ia /usr/local/maldetect/maldet

Olá amigos, tudo bom? Gostaria de saber se existem regras padrão para o Mod Security. Como os usuários mais experientes do fórum devem ter percebido, sou novo como "root" e tenho me dedicado bastante a aprender a gerenciar e tornar meu servidor mais seguro. Tentei incluir isso aqui: Peguei neste site aqui. Mas ficou dando erro. Alguma sugestão?

Olá amigos! Algum de vocês usam Cloudmark para eliminar spam, malware, phishing e diminuir a rotatividade? recomendam?

Olá amigos! Desde 2007, quando comecei a trabalhar com hospedagem, depois revenda, vps e agora dedicado, fui atacado, quando ainda contratava plano de revenda compartilhada, por 2 ocasiões onde hackers substituíram todos os "index" por páginas personalizadas. Nestas 2 vezes, a mensagem deixada tinha haver com o Islamismo e geralmente a partir de países do oriente médio. Quando passei a ter acesso Root e poder configurar o Firewall, comecei a pensar se não vale a pena bloquear o acesso à países reconhecidamente origens de ataques hackers. Configuro meu CSF para bloquear IPs quando a tentativa de login dos principais serviços (SSH, FTP, Email, etc) falham por 5 vezes consecutivas. Pelo log, 80% vêm da ásia e oriente médio, sendo este último, responsável pela maior parte das tentativas de login ao servidor. Como 90% do público alvo é brasileiro, sendo 4% português e os 6% restantes de vários países, geralmente formados por EUA e Europa, com excessão da China e Japão, tenho interesse em bloquear no CSF o acesso à alguns países como Iraque, Arábia, Emirados, Afeganistão, Azerbaijão, etc... o que me dizem? Ou seria interessante, talvez, bloquear TODOS os acessos de países, fora o Brasil, para determinados serviços, como o SSH ou WHM, por exempo, através do bloqueio das portas que estes serviços usam, para determinados países, o que acham? Fora a minha experiência, que não é muito vasta, onde poderia encontrar relatos ou estatísticas com os principais países de onde se originam os ataques? Desde já, obrigado.

Olá pessoal do PDH estou aqui para alertar, alguns empresas que anda oferecendo revenda de hospedagem no "CANADA" dizendo que é no "BRASIL". Cuidado antes de contratar pesquise se realmente a empresa oferece serviços no Brasil e se é uma empresa de confiança para hospedar seu site.

Oi Estou com problemas no Firewall CSF do meu VPS Tipo, ele não esta bloqueando IP, o IP aparece na lista mais não bloqueia e não barra ataque DoS... Já instalei o DDoS Deflate também não barrou, o IP também aparece na lista de IP's bloqueado mais não bloqueia... Alguém pode me ajudar? Obs: uso cPanel e ja reinstalei o CSF e nada resolveu, antes bloqueava, agora não sei o que deu.

Olá boa noite; Sempre faço uma análise em todas as contas do servidor após a ativação, e uma conta que foi ativada ontem, ao verificar o conteúdo do site me deparo com a seguinte página: Borrei algumas partes e inclusive o nome do script por motivos de segurança para que outras pessoas (que não conheçam isto) nem venham a conhecer. Pois bem, analisando pasta por pasta encontrei uma cheio de arquivos .txt e para meu espanto estava lá uma copia dos arquivos config.php do WordPress de todas as contas do servidor. Minha primeira reação ao ver isto, foi suspender imediatamente a conta e trocar a senha de algumas contas, porém precisaria saber de uma solução para evitar que isto funcione. Segui as dicas deste post do nosso amigo donruan http://blog.totals.com.br/?p=120 e desativei algumas funções do PHP (que na hora que tirei o print da tela não havia nenhuma função desativada) Mas o que poderia estar fazendo para que este script não funcione mais. Seria habilitar ou desabilitar alguma função no firewall, no PHP? Obrigado e um feliz 2014!

Salve pessoal do PDH, venho aqui através deste ticket a passar umas dicas de urgência para você atualizar no seu HOSTMGR. Um hacker conseguiu encontrar a conexão do mysql do arquivo config.php da raiz do HOSTMGR. Dicas: Não utilizar a senha do CPANEL na conexão do mysql no arquivo config.php, crie um usuário no MySQL e faça assim, seus dados estará mais seguros. Não responda a um ticket que peça que troque a senha do seu MySQL da conexão do hostmgr, caso você encontrar um ticket em sua central com o mesmo desconsidere, e informe urgentemente ao Fernando dono da HOSTMGR. Fiquem atentos a atualização que assim que sair, atualizem urgentemente para sua segurança. E não se esqueça nunca use a mesma senha do cpanel na conexão do MySQL. Há um processo aberto junto com o Fernando para resolver o problema.

Caros amigos, eu preparei um tutorial completo (pelo menos a intenção é que seja) sobre configuração de segurança de VPS/DEDICADOS. Trata-se de um passo-a-passo bem explicado sobre cada configuração - porém este post não é definitivo, caso vc tenha alguma dica a adicionar eu edito o tópico adicionando-a e colocando seus devidos créditos. Via SSH - acesso Shell Instale o ELS: wget --output-document=installer.sh http://servermonkeys.com/projects/els/installer.sh; chmod +x installer.sh; sh installer.sh; els --update; els --chkrootkit; els --rkhunter; els --chmodfiles; els --disabletelnet; els --hardensysctl; els --libsafe; els --mytop; els ---securepartitions O ELS "Easy Linux Security" é um instalador de módulos e pequenos scripts de segurança atualizados. Existem muitos módulos disponíveis, vc pode lista-los executando simplesmente o comando els em seu shell. O que instalo acima são os que fazem mais diferença em termos de segurança do servidor: chkrootkit (rootkit), rkhunter (outro rootkit melhor ainda), chmodfiles (ele muda as permissões de acesso e execução de alguns scripts/comandos no servidor para apenas o root executa-los), disabletelnet (desabilita/desliga o telnet, deixando apenas o SSH), hardensysctl (faz um tunnig de sua interface de rede), instala o libsafe (apenas para sistemas 32 bits), mytop (instala um visualizador de processos mysql como o comando TOP faz com o sistema). Instale o logview: wget http://www.logview.org/logview-install[/code] É um visualizador de logs via navegador, vc não precisa abrir o SSH para ver os logs intrincados do sistema, com este addon do WHM vc os vê via seu painel WHM. [b]Instale o CMM:[/b] [code]wget http://www.configserver.com/free/cmm.tgz; tar -xzf cmm.tgz; cd cmm; ./install.sh[/code] [b]Instale o CMQ:[/b] [code]wget http://www.configserver.com/free/cmq.tgz; tar -xzf cmq.tgz; cd cmq; ./install.sh[/code] Não tem muito a ver com segurança, mas são dois addon do WHM que podem ajudar e muito na configuração e monitoramento de seu uso relacionado a contas de emails. [b]Instale o CMC:[/b] [code]wget [url="http://www.configserver.com/free/cmc.tgz"]http://www.configser...om/free/cmc.tgz[/url] ; tar -xzf cmc.tgz; cd cmc; ./install.sh[/code] O CMC (Configserver ModSec Control - http://www.configser...com/cp/cmc.html) é um addon do WHM que te permite configurar quais regras do MOD_SECURE determinados dominios ou subdominios ou mesmo usuários do seu servidor serão executados. Sugiro usar com parcimônia e verificar antes de tudo porque o script de seu usuário/cliente está sendo bloqueado pelo MOD_SECURE. No caso vc pode peritir a execução do script de seu usuário sem passar pro nenhuma regra ou mesmo apenas desabilitar uma regra especifica para o dominio especifico. [b]Instale o MOD_SECURE atualizado:[/b] Veja o link: http://cpanelmania.b...tualizadas.html [b]Configurando a porta do SSH:[/b] Para configurar/mudar a porta execute: [code]pico -w /etc/ssh/sshd_config[/code] E mude a linha "Port 22" para a porta que vc deseja (lembre-se de adicionar a porta em seu firewall ANTES ou vc não conseguirá acessar mais o servidor). [b]Aviso de acesso ROOT[/b] Edite ".bash_profile" o com o comando: [code]cd root; pico -w /root/.bash_profile[/code] Adicione o código abaixo no final do arquivo após a linha "unset USERNAME": [code] # # GRAVA LOG E HISTORICO DE ACESSOS ROOT # echo `who` >> .access # # EMAIL DE AVISO ACESSO ROOT # rootalert() { echo 'ALERTA - Acesso ROOT SHELL' echo echo 'Servidor: '`hostname` echo 'Data: '`date` echo 'Usuario: '`who | awk '{ print $1 }'` echo 'TTY: '`who | awk '{ print $2 }'` echo 'Origem: '`who | awk '{ print $6 }' | /bin/cut -d '(' -f 2 | /bin/cut -d ')' -f 1` echo echo 'ACESSO ROOT EXECUTADO.' echo echo 'Estes usuários estão ativos neste instante como root:' echo `who | awk '{print $6}'` echo echo 'Últimos 10 acessos efetuados:' echo `last -n 10` echo echo 'Informações: Horário deste acesso, Uptime e Load Averange atual' echo `uptime` echo } rootalert | mail -s "Alerta: Acesso ROOT [`hostname`]" SEUEMAILAQUICARAMBA[/code] Note que este script vai criar um arquivo .access no diretório /root e criará um histórico de acesso com a data, hora e IP de cada acesso ocorrido via root. Ele tb adiciona outras infos quando ocorrerem o acesso root, assim como litara os últimos 10 IPs que acessaram via root, além do atual e envia tudo para o seu email. [b]Tunando seu /tmp[/b] Faça uma cópia do /etc/fstab e edite o arquivo original: [code] cp /etc/fstab /etc/fstab.OLD pico /etc/fstab [/code] E mude as linhas abaixo: [code] tmpfs /dev/shm tmpfs defaults 0 0 /tmp /var/tmp ext3 defaults,bind 0 0 [/code] Para: [code] tmpfs /dev/shm tmpfs defaults,noexec,nosuid 0 0 /tmp /var/tmp ext3 defaults,bind,noauto,usrquota,noexec,nosuid,nodiratime,noatime 0 0 [/code] Importante: após isso feito geralmente eu restarto o server. Porem vc tem que tomar cuidado, qualquer erro no fstab e seu servidor não voltará online, vc terá de acionar o seu IDC e pedir para eles restaurarem o fstab.OLD ou cergirem o fstab atual. [b]Instale o CSF Firewall:[/b] [code]wget http://www.configserver.com/free/csf.tgz; tar -xzf csf.tgz; cd csf; sh install.sh[/code] Eu estou preparando um novo tópico completo apenas para o CSF. Assim que terminar vou posta-lo em outro tópico (ele é bem extenso e completo). [b]Remova o Lynx:[/b] Primeiro identifique o pacote que vc tem instalado: [code]rpm -qa | grep lynx[/code] Depois execute: [code]rpm -e lynx NOMEDOPACOTE[/code] [b]Instalando e configurado corretamente o Maldetec:[/b] [code]wget http://www.rfxn.com/downloads/maldetect-current.tar.gz ; tar -xzf maldetect-current.tar.gz ; cd maldetect-* ; sh ./install.sh ; maldet --update-ver ; maldet --update[/code] Agora configurando, edite o arquivo "conf.maldet" em /usr/local/maldetect, editando a linha "email_alert=0" para "email_alert=1" e a linha "email_addr=" colocando o seu email que receberá o relatório. Você pode executar ele na linha de comando especifica, por exemplo: [code]maldet -a /home/USUARIO/[/code] Ou escanear TODOS os usuários de seu diretório HOME: [CODE]maldet -a /home?/?/public_html[/code] Aqui vai uma dica um tanto que radical: Vc pode configurar o maldetec para ele tentar limpar possíveis trojans ou códigos maliciosos que "colam" em códigos PHP intregos, e caso não consiga ele move o script/arquivo todo para o diretório /usr/local/maldetect/quarantine/. Para isso edite a linha "quar_hits=0" para 'quar_hits=1" e "quar_clean=0" para "quar_clean=1". O maldetec será executado diarimente em seu servidor e lhe enviará um relatorio via email, por exemplo: No caso acima ele identificou um scritp malicioso dentro do public_html/plugins/system, e moveu o mesmo para a quarentena. O que fazemos aqui (sim temos esta opção de quarentena habilitada em TODOS os nossos servidores) - é logo nas primeiras horas do dia pegarmos todos os relatórios e analisar quais arquivos foram movidos para a quarentena. Criamos um email padrão no WHMCS o e mandamos para o cliente/usuário informando sobre o problema. Raramente o sistema move um arquivo que faz parte realmente do site/aplicação do usuário, mas já ocorreu aqui, por isso é importante contactar o cliente após você analisar o log. Geralmente quando isso ocorre ele consegue limpar o arquivo, removendo o código malicioso que foi adicionado a programação. Por exemplo: É importante vc ter também o CLAMAV instalado e atualizado. O MALDETEC usa a enguine do CLAMAV para o scaneamento e identificação "heurística" o que adiciona pouco load no servidor durante sua execução. [b]Usando o KSPLICE[/b] Agora papo de gente grande. O KSPLICE aplica em seu kernel (LINUX) todos os updates e correções (paths de segurança inclusive) sem rebotar o seu servidor e de forma automatizada. Este é um sistema OBRIGATÓRIO que vc deve ter instalado, pois o custo é ridículo: RHEL, CentOS, Debian, Ubuntu:$3.95 each system per month RHEL, CentOS, Debian, Ubuntu:$2.95 each system per month (volume discount after 20 systems) Virtuozzo, OpenVZ:$9.95 each system per month Virtuozzo, OpenVZ:$7.95 each system per month (volume discount after 20 systems) Ubuntu Server (9.04 and 9.10):$3.95 each system per month Ubuntu Server (9.04 and 9.10):$2.95 each system per month (volume discount after 20 systems) Para verem como é importante, todos devem se lembrar dos problemas de segurança que a LOCAWEB teve em uma penca de Servers LINUX (http://cpanelmania.b...i-invadida.html). Se ela tivesse adotado o KLSPICE em seus servidores pagando uma micharia não teria tido este problema e nem a publicidade negativa que ela teve de lidar. Você acessa o sistema via um painel de controle (https://uptrack.ksplice.com) e lista quais servidores terão o KSPLICE instalado. A instalação é fácil e rápida (https://www.ksplice....uptrack/install) [FIM DA PARTE I]

O que é SSH? Secure Shell (SSH) é um protocolo de internet para comunicação e transferência de dados em segurança, em que o acesso é feito normalmente por um cliente chamado Putty (download aqui) e as ações são dadas por comandos. É uma maneira de acessar e administrar seu servidor linux, assim como se administra um VPS/Dedicado Windows pela "Área de trabalho remota". Pelo SSH é possível instalar sistemas e programas, fazer downloads, criar pastas, etc. Como tornar o SSH de seu servidor seguro? Dica 1. Altere a porta de conexão padrão do SSH. Todo serviço voltado para a conexão pela internet possui uma porta de conexão. Por padrão, a porta de conexão do SSH é a 22. Para alterá-la, siga os passos abaixo: 1. Digite nano /etc/ssh/sshd_config e dê enter. 2. Procure por #Port 22 . 3. Apague o # e altere o valor de 22 para uma porta qualquer que não esteja em uso - recomendamos portas entre 3000 e 7000 - de maneira que fique como este exemplo: Port 5002. 4. Segure a tecla CTRL e depois a tecla X , após isso digite a letra y e dê enter para fechar e salvar o arquivo. 5. Lembre-se de liberar a porta escolhida por você e bloquear a padrão (22) no Firewall do servidor, caso ele tenha. 6. Digite agora service sshd restart para reiniciar o SSH. 7. Pronto! Seu SSH já está funcionando pela porta alternativa escolhida por você. Dica 2. Configure bem um firewall e sistemas de seguranças para bloquear o IP do usuário caso erre a senha do SSH mais de 5 ou 7 tentativas, evitando que descubram sua senha por um método chamado "Brute Force". Dica 3. Caso você utilize o cPanel/WHM, em Security Center dentro do WHM (acesso root), existe um menu chamado Host Access Control em que é possível bloquear o acesso SSH para todos e liberar apenas para um ou mais IPs específicos, como nos exemplos abaixo: -Observação: sshd é a mesma coisa que ssh, mas para que funcione no Host Access Control, é necessário preencher como sshd. -Observação 2: No local onde está 189.59.206.56, deverá ficar o seu IP que pode ser encontrado no sitemeuip.com.br. Dica 4. Use sempre senhas complicadas, não ligadas a sua vida (tanto pessoal quanto a de trabalho) e modifique sua senha frequentemente. Se sua empresa chama Host1, evite senhas como senhaHost1. Apenas isso. Preocupe-se sempre com a segurança de seu servidor.

PARALLELS PLESK PANEL – SECURITY ADVISORY Parallels Plesk Panel Customer: Please read this message in its entirely and take the recommended actions. On February 9, we notified you of a security vulnerability in some older versions of Parallels Plesk Panel (see below). In that notification, we recommended updating to one of several versions of Plesk where this vulnerability had already been patched. We sent a reminder e-mail on February 21. This notification is just another reminder. If you have already applied the recommended update or were already running an up-to-date version, no further action is required. Patches are available for: Plesk 10.3 Plesk 10.2 Plesk 10.1 Plesk 10.0 Plesk 9.5 Plesk 9.3 Plesk 9.2 Plesk 9.0 Plesk 8.6 Plesk 8.4 Plesk 8.2 Please follow our Knowledge Base article for instructions to install these patches:http://kb.parallels.com/en/113321 PLEASE NOTE: If you have already been affected by this vulnerability, it is recommend that, after you apply the patches, you should change all account passwords including the password for 'admin'. Parallels has made available a utility to enable changing of these passwords en masse:http://kb.parallels.com/en/113391 Parallels takes the security of our customers very seriously and encourages you to take the recommended actions as soon as possible. Thanks,

Boa tarde amigos do forum ! Essa semana meu servidor sofreu varias tentativas de invasão, graças a Deus ficou só nas tentativas. Estava pensando, como melhorar a segurança de um servidor usando apenas as configurações do whm / cpanel ? tem como bloquear qualquer acesso via SSH ? (fechando totalmente a porta via SSH) Tem como bloquear acesso a determinado país ou IP ? (de onde surgiu a tentativa de ataque) E por onde mais um servidor pode ser atacado exeto por whm / whmcs / ssh ? Vamos fazer aqui em conjunto uma revisão de segurança a um dedicado simples :D .

Olá! Amigos Do portaldohost! Primeiramente Gostaria de Alertar A todos Sobre Um novo Exploit Baseado em php Capaz de Danificar seu servidor, um cliente meu possui um servidor virtual Cpanel, ele me comunicou que o servidor estava fora do ar Openvz, fui verificar loguei pelo Dedicado é entrei no servidor virtual pois estava sem acesso Pelo SSH, dei comando service cpanel restart estava falando que o cpanel Não existe, fui verificar no top os processos tinha um processo com nome de um usuario que ele tinha Na conta cpanel executando Um Arquivo perl que danificou o servidor do cliente todo, infelizmente a programação foi complicada apagou tudo até mesmo /home Alem de danificar o cpanel perca total de contas eu na hora se toquei que se trata de um exploit, perguntei se ele sabia algo ele disse que vendeu uma hospedagem cpanel para um cara que comprou poucas horas antes de acontecer isso, ele me passou usuario dele que foi criado no whmcs no caso era brevol mesmo usuario com o processo que verifiquei no top,executando um arquivo perl, o meu cliente disse que verificou arquivos dele antes de acontecer isso tinha o arquivo injection.pl injection.php php.ini perguntei se ele Havia visto o codigo fonte ele me informou que o codigo fonte estava criptografado Com Ioncube. o arquivo perl ele verificou mais não entende nada dessa programação achou que faz parte de algum funcionamento do site, no arquivo php.ini ele me disse que estava safemode dentro, me falou apenas isso eu acredito que seja safe_mode = Off pois, o safemode estava ativo por padrao no php. intão, como o servidor dele é gerenciado basico coloquei CSF,Proteção total em diretorios, Mod_security,ClamAv rodando scanner em todos usuarios funçoes desativadas como shell_exec,passthru,exec,system,proc_ open entre outros perigosos. mais como o safemode estava desativado pelo usuario tenho certeza que ele foi vitima de um exploit não comum como c99shell. Acredito que o exploit Funciona da seguinte Forma o php executa o perl por Algum comando que estava desativado No Safemode é o perl faz as funçoes total de danificar o servidor. não vejo solução se for o que estou pensando, pois safemode ativado se ele colocar o php.ini consegue totalmente rodar comandos perigosos. venho alertar A todos caso notar arquivos parecidos Ou usuario, se algum leitor souber uma solução com base em que falei talvez desativar a modificaçao no php.ini seria uma solução, ou a outra seria não permitir o usuario Rodar .pl no servidor Não sei se e possivel, desculpe o texto Enorme "biblia" Mais achei que deveria Alertar A todos, pois trata-se de um Assunto serio, e peço se alguem souber como desativar o php.ini no diretorio ou desativar .pl para rodar sem ser usuario root Compartilhe conosco! Muito Obrigado A todos! Fiquem Com Deus

Caros existe alguma forma de alterar TODAS as senhas de acesso de um servidor sejam do WHM (revendas) e cpanel ? Existe o recurso do "Configure Security Policies" no WHM colocando o para alteração em um ou 2 dias, porem existe outra forma ?