XOOPS Hacked, Ajuda

  • Identifique-se para criar novos tópicos neste fórum
  • Visitantes anônimos não podem postar neste fórum
leomissao  Iniciante   Postagens: 0
Na administração do XOOPS, recebi alguns alertas do XOOPS sobre tentativa de ataque, mas como nunca tinha acontecido nem suspeitei, e simplesmente ao tentar ver as alterações feitas percebi que o portal foi hackeado.

Tento resolver peço ajuda dos nobres. site: http://iprjequie.org/
leomissao  Iniciante   Postagens: 0
Alteraram os arquivos index.html que antecede o diretório portal onde está instalado o XOOPS e também o index.php do XOOPS, baixando o pacote XOOPS 2.4.4 para recompor o index.php.

Lembrando que as pastas "xoops_data e xoops_lib" estão fora do diretório site.
leomissao  Iniciante   Postagens: 0
Colocado de novo o arquivo index.php do XOOPS e o portal aparentemente está normal (modo manutenção). Vou verificar se existe mais alterações para só depois liberar o site.

O que acho intrigante é que outro portal meu pxgade.com.br que eu nem estava editando e ao tentar ve-lo, o mesmo problema. Ainda não removi deixo para os nobres verem.
leomissao  Iniciante   Postagens: 0
Terei um grande trabalho pela frente.

Todos os index do portal foram alterados.
Edison Pinho  Iniciante   Postagens: 9
Acredito que eles só conseguem isso por alguma falha na segurança do XOOPS, do seu Servidor ou na sua máquina com algum malware instalado sugando sua senha e username, me corrige se estou cometendo alguma erro.

O caso é grave, depois que você descobrir como eles conseguiram entrar nos informe.
leomissao  Iniciante   Postagens: 0
Não sei ainda de onde veio a falha, afinal sou aprendiz XOOPS e não entendo quase nada, mas tenho outro portal no servidor(mesma empresa, não sei se mesma máquina) e teve o mesmo problema. Das opções citadas tenho tudo para crer que só não foi no meu notebook, pois estou usando ubuntu, e só instalei alguns programas do repósitorio oficial.

Agora é reenviar todos os arquivos index do portal (todos foram alterados) e só depois verificar se realmente é só isso. Lamentávelmente o último backup que fiz foi o mês passado.
Andrax  Ocasional   Postagens: 27
É bom dedicar uma atenção maior a essa verificação dos seus portais, normalmente, nesse tipo de ataque os caras deixam lá alguma brecha para que possam ter acesso ao servidor de uma forma mais fácil.

Uma recomendação que tive recentemente do pessoal lá do XOOPS.org foi de acrescentar um arquivo .htaccess (caso seu servidor dê suporte) com o conteúdo abaixo no diretório uploads. (por sinal a versão 2.4.5 já vem com esse arquivo)
 # secure directory by disabling script execution 

AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi .php5 .php4 .php3 .phps

Options -ExecCGI -Indexes
Isso evita que scripts enviados ao diretório uploads sejam executados.

É bom também procurar saber se algum dos módulos que você está utilizando tem alguma vulnerabilidade, manter as versões atualizadas reduz esse risco.

A verdade é que portais em servidores compartilhados estão sim mais suscetíveis a ataques... uma vez que uma outra conta no servidor tenha sido comprometida, existe a possibilidade de se ter acesso a outras contas no mesmo servidor... ou seja é possível que a porta de entrada não tenha sido exatamente o seu site... acredito que é uma boa ideia entrar em contato com seu servidor, informar do ataque e procurar saber se mais alguém também foi atacado... (o pessoal aqui que trabalha com hosts pode opinar melhor sobre isso do que eu... )

Espero que consiga consertar tudo direito.

Essa semana está muito corrida para mim (trabalhos de faculdade, provas e trabalho ), mas se puder ajudar é só avisar.
Rmarx  Iniciante   Postagens: 0
Se o seu servidor possuir antivirus no cpanel como por exemplo Clav rode-o pois ele encontrará com certeza os arquvos infectados.

Se não tiver o antivírus via FTP procure por arquivos de nome c.php, nst.php... ou ainda: /class/cache/file.php

Procure por arquivos "estranhos" que não são nativos do XOOPS.

Altere também a sua senha do Cpanel, de preferencia uge o gerenciador de senha para gerar automaticamente a senha.

Digo de experiência própria.
Edson Oliveira  Membro De: R. Liberdade, Centro, Atibaia - São Paulo, BR   Postagens: 730
Complementando o que o nosso amigo Ronaldo disse, verifique todas as pasta que tem permissão de escrita, principalmente as CHMOD-777, pois já tive problema com ela, a tempos atrás.
leomissao  Iniciante   Postagens: 0
Agradeço a todos os nobres pelas orientações.

Já havia alterado a senha do cpanel, logo que percebi que houve a invasão, mas obrigado pela dica.

Seguireio o conselho dos nobres e irei observar os conselhos aui dados.

Valeu.
leomissao  Iniciante   Postagens: 0
Para facilitar minha vida peguei um backup que tinha do portal apaguei todos os arquivos do portal e reenviei os mesmos, aproveitei e renomeei as pastas xoops_data e xoops_lib.

Ficou quase tudo perfeito, mas depois de tudo pronto, fui liberar o portal, e para minha surpresa:

Internal Server Error.

Já tive outras vezes este problema com alguns arquivos PHP e se não me engano, resolvi alterando as permissões.

Bom a permissão admin.php como da maioria dos arquivos PHP do XOOPS é 644. Alguém pode me socorrer?

Grato.
Carlos Eduardo Santana Lorenzon  Participativo De: Florianópolis - SC - Brasil  Postagens: 123
Os arquivos tem de estar com permissão 644 e os diretórios com permissão 755.

Caso você não tenha suphp configurado em seu servidor (oque seria uma boa se tivesse)

você tem de dar permissão 755 para as pastas de cache dentro do xoops_data e a pasta uploads
leomissao  Iniciante   Postagens: 0
Já estão com as permissões 755 para estes diretórios.

Agradeço pela dica.

Vou continuar pesquisando.
fernando  Iniciante   Postagens: 0
Aproveito esse tópico para solicitar que os nomes dos hosts hackeados sejam compartilhados, assim, teremos como correr dessas plataformas de hospedagem.

Já tive muitos problemas com serviço de hospedagem baratos mas sem o mínimo de segurança, já perdi domínio, já paguei multa e tudo por falta dos outros.
Rmarx  Iniciante   Postagens: 0
Você observou as permissões? Procurou por arquivos não nativos do XOOPS? Procure a pasta cache, template_c. Seu Servidor tem o Antivírus conforme citei?

Sr. Fernando Sanches, não existe servidor 100% seguro existem brechas deixar por usuários ou scripts, existe ebrute force, existe SQL injection, existem XOOPS instalados sem seguir algumas dicas enfim é muito fácil dizer que o servidor é inseguro.

Só lembrando que até mesmo os servidores do Pentágono foram invadidos.

Existem dezenas de formas de invadir um servidor, mas não vou postar aqui as formas, rss

Vamos dar atenção à solicitação do Leandro Angelo.

Leandro já te add no meu MSN.
leomissao  Iniciante   Postagens: 0
Observei sim as permissões, inclusive a do mainfile.php que tem que estar 400 depois do XOOPS instalado.
leomissao  Iniciante   Postagens: 0
Finalmente consegui resolver.

Devido o ataque sofrido resolvi observar as configurações de segurança do XOOPS que autora não conhecia e resolvi aplica-las.

O grande problema é que eu usava um código nas configurações Gerais - Motivo para fechamento do portal, este simplesmente tinha dados para acesso de e-mail do Google apps. Logo as configurações de segurança que apliquei barrava o salvamento das configurações gerais.

Removendo o código o problema foi sanado.

Agora colocarei o código para acesso ao e-mail no proprio theme.

Mais uma vez galera muito obrigado pela assistência e perdão o marinheiro de primeira viagem.
Alex Bezerra  Participativo De: Betim - MG  Postagens: 134
queria que postassem sobre a melhor forma de e quais arquivos para melhorar a segurança do abuso de servidores.

Ou seja tenho problemas com o uso demasiado do servidor.

Isso incomoda muito, preciso de dicas de como usar arquivos para segurança e onde usá-los.

Por exempo o php.ini, robots.txt e .htaccess

Abaixo achei um arquivo que parece bom, mas pode ser usado no XOOPS?

php.ini

#para usar estas 2 linhas abaixo é necessário desabilitar a compressão gzip do XOOPS php_flag zlib.output_compression on php_value zlib.output_compression_level 4 php_flag register_globals Off

#reenvia as páginas de erro para o index, assim não se perde visitantes com erros ErrorDocument 404 /index.htm ErrorDocument 500 /index.htm ErrorDocument 403 /index.htm

<FilesMatch "\.(inc|tpl|h|ihtml|sql|ini|conf|class|bin|spd|theme|module)$"> deny from all </FilesMatch>

#Bloqueia o acesso ao .htaccess por curiosos <Files ~ "^\.ht"> Order allow, deny Deny from all Satisfy All </Files>

<Files ~ "\mainfile.php$"> deny from all </Files>

<Limit GET PUT POST> Order Allow, Deny Allow from all </Limit>

RewriteEngine on RewriteCond %{REQUEST_FILENAME} !-s

#As duas linhas abaixo fazem com que alguém acessando ideiafacil.com seja #direcionado ao www.ideiafacil.com, isso ajuda no Google e alguns portais de busca #mude para os dados de seu portal !

RewriteCond %{HTTP_HOST} !^www\.tribunadebetim\.com RewriteRule (.*) http://www.tribunadebetim.com/$1 [R=301, L]

#Linhas abaixo protegem contra coletores de email de spammers RewriteCond %{HTTP_USER_AGENT} ^InternetSeer.com [NC, OR] RewriteCond %{HTTP_USER_AGENT} ^E?Mail.?(Collect|Harvest|Magnet|Reaper|Siphon|Sweeper|Wolf) [NC, OR] RewriteCond %{HTTP_USER_AGENT} ^(Fresh|Lightning|Mass|Real|Smart|Speed|Star).?Download(er)? [NC, OR] RewriteCond %{HTTP_USER_AGENT} (DTS.?Agent|Email.?Extrac) [NC, OR] RewriteCond %{HTTP_USER_AGENT} ^(curl|Dart.?Communications|Enfish|htdig|Java|larbin) [NC, OR] RewriteCond %{HTTP_USER_AGENT} (FrontPage|Indy.?Library|RPT\-HTTPClient) [NC, OR] RewriteCond %{HTTP_USER_AGENT} ^(libwww|lwp|PHP|Python|www\.thatrobotsite\.com|webbandit|Wget|Zeus) [NC, OR] RewriteCond %{HTTP_USER_AGENT} ^Web.?(Auto|Cop|dup|Fetch|Filter|Gather|Go|Leach|Mine|Mirror|Pix|QL|RACE|Sauger) [NC, OR] RewriteCond %{HTTP_USER_AGENT} ^Web.?(site.?(eXtractor|Quester)|Snake|ster|Strip|Suck|vac|walk|Whacker|ZIP) [NC, OR] RewriteCond %{HTTP_USER_AGENT} ^BackDoorBot [OR] RewriteCond %{HTTP_USER_AGENT} ^Black.Hole [OR] RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR] RewriteCond %{HTTP_USER_AGENT} ^BlowFish [OR] RewriteCond %{HTTP_USER_AGENT} ^BotALot [OR] RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR] RewriteCond %{HTTP_USER_AGENT} ^DittoSpyder [OR] RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR] RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR] RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR] RewriteCond %{HTTP_USER_AGENT} ^EroCrawler [OR] RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR] RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR] RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR] # Isso acaba bloqueando alguns programas de download também como Flashgertt, gozilla, getright RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR] RewriteCond %{HTTP_USER_AGENT} ^Foobot [OR] RewriteCond %{HTTP_USER_AGENT} ^FrontPage [NC, OR] RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR] RewriteCond %{HTTP_USER_AGENT} ^Googlebot-Image [OR] RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR] RewriteCond %{HTTP_USER_AGENT} ^Harvest [OR] RewriteCond %{HTTP_USER_AGENT} ^hloader [OR] RewriteCond %{HTTP_USER_AGENT} ^HMView [OR] RewriteCond %{HTTP_USER_AGENT} ^httplib [OR] RewriteCond %{HTTP_USER_AGENT} ^HTTrack [NC, OR] RewriteCond %{HTTP_USER_AGENT} ^humanlinks [OR] RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR] RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR] RewriteCond %{HTTP_USER_AGENT} ^InfoNaviRobot [OR] RewriteCond %{HTTP_USER_AGENT} ^Internetseer [OR] RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR] RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR] RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR] RewriteCond %{HTTP_USER_AGENT} ^LexiBot [OR] RewriteCond %{HTTP_USER_AGENT} ^libWeb/clsHTTP [OR] RewriteCond %{HTTP_USER_AGENT} ^LinkextractorPro [OR] RewriteCond %{HTTP_USER_AGENT} ^LinkScan/8.1a.Unix [OR] RewriteCond %{HTTP_USER_AGENT} ^LinkWalker [OR] RewriteCond %{HTTP_USER_AGENT} ^lwp-trivial [OR] RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR] RewriteCond %{HTTP_USER_AGENT} ^Mata.Hari [OR] RewriteCond %{HTTP_USER_AGENT} ^Microsoft.URL [OR] RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR] RewriteCond %{HTTP_USER_AGENT} ^MIIxpc [OR] RewriteCond %{HTTP_USER_AGENT} ^Mister.PiX [OR] RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR] RewriteCond %{HTTP_USER_AGENT} ^moget [OR] RewriteCond %{HTTP_USER_AGENT} ^Mozilla/2 [OR] RewriteCond %{HTTP_USER_AGENT} ^Mozilla/3.Mozilla/2.01 [OR] RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*NEWT [OR] RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR] RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR] RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR] RewriteCond %{HTTP_USER_AGENT} ^NetMechanic [OR] RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR] RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR] RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR] RewriteCond %{HTTP_USER_AGENT} ^NICErsPRO [OR] RewriteCond %{HTTP_USER_AGENT} ^NPBot [OR] RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR] RewriteCond %{HTTP_USER_AGENT} ^Openfind [OR] RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR] RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR] RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR] RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR] RewriteCond %{HTTP_USER_AGENT} ^ProPowerBot/2.14 [OR] RewriteCond %{HTTP_USER_AGENT} ^ProWebWalker [OR] RewriteCond %{HTTP_USER_AGENT} ^ProWebWalker [OR] RewriteCond %{HTTP_USER_AGENT} ^QueryN.Metasearch [OR] RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR] RewriteCond %{HTTP_USER_AGENT} ^spanner [OR] RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR] RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR] RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR] RewriteCond %{HTTP_USER_AGENT} ^suzuran [OR] RewriteCond %{HTTP_USER_AGENT} ^Szukacz/1.4 [OR] RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR] RewriteCond %{HTTP_USER_AGENT} ^Teleport [OR] RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR] RewriteCond %{HTTP_USER_AGENT} ^Telesoft [OR] RewriteCond %{HTTP_USER_AGENT} ^The.Intraformant [OR] RewriteCond %{HTTP_USER_AGENT} ^toCrawl/UrlDispatcher [OR] RewriteCond %{HTTP_USER_AGENT} ^True_Robot [OR] RewriteCond %{HTTP_USER_AGENT} ^turingos [OR] RewriteCond %{HTTP_USER_AGENT} ^TurnitinBot\ [OR] RewriteCond %{HTTP_USER_AGENT} ^TurnitinBot/1.5 [OR] RewriteCond %{HTTP_USER_AGENT} ^URLy.Warning [OR] RewriteCond %{HTTP_USER_AGENT} ^VCI [OR] RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR] RewriteCond %{HTTP_USER_AGENT} ^[Ww]eb[Bb]andit [OR] RewriteCond %{HTTP_USER_AGENT} ^WWW-Collector-E [OR] #Proteção contra alguns virus e worms RewriteCond %{REQUEST_URI} /(admin|cmd|httpodbc|nsiislog|root|shell)\.(dll|exe) [NC, OR] RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR] RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR] RewriteCond %{HTTP_USER_AGENT} ^Zeus RewriteRule ^.*$ - [L]
Alex Bezerra  Participativo De: Betim - MG  Postagens: 134
Vi outra coisa, não sei se mais alguém está tendo problemas com uso demasiado de servidor.

Pude notar que um dos que mais visitam são os robôs da Google (googlebot).

Achei também na nave mãe XOOPS algo que fala sobre algo parecido.

e mostra sobre um link: Web Robots: DECLARE%20@S%20CHAR(4000);SET%20@S=CAST

E no XOOPS.org, tem uma postagem, porém antiga de 2008 que diz algo sobre isso: New SQL injection attacks

E outro endereço sobre como bloquear um ataque SQL Injection no apache:How can I block blind SQL injection attack?
Alex Bezerra  Participativo De: Betim - MG  Postagens: 134
Peço desculpas pela insistência, na verdade o que quero é impedir que spammers de "scanear" todo o meu site. Utilizando processamento e banda do meu servidor.

  Pesquisa avançada






Entrada

Codinome:


Senha:





Perdeu a senha?  |Cadastre-se!


Quem nos visita
Há 21 visitantes neste momento... (15 na seção Fóruns)

Associados: 0
Anônimos: 21

outros...

Banner XOOPS Cube