Ik moest toch een keus maken toen, daarna ben ik overgestapt op SuPHP met voor elk account een eigen php.ini zodat alles flexibel aan te passen is.Citaat:
Oorspronkelijk geplaatst door Wido
Afdrukvoorbeeld
Ik moest toch een keus maken toen, daarna ben ik overgestapt op SuPHP met voor elk account een eigen php.ini zodat alles flexibel aan te passen is.Citaat:
Oorspronkelijk geplaatst door Wido
Even voor mijn begrip: Die virussen draaien dus lokaal bij iemand die zulke FTP gegevens gebruikt? Dus daar moet in ieder geval ook wat gebeuren, anders heb je ze zo weer op de server zitten? Is dat correct?Citaat:
Oorspronkelijk geplaatst door Wido
Ik adviseer ik ieder geval om flink op virussen te scannen en Hitman Pro (of vergelijkbaar) er maar eens over te halen.
Maar vraag me nu af of dat wel een goed advies is.
Vr.gr. Eef
Ja, dat klopt, het virus draait lokaal en steelt/snift daar FTP gegevens. Als je daar niets aan doet komt het gewoon weer vrolijk terug.
Wat ik echter zie is dat de meeste geïnfecteerde scripts in April/Mei geplaatst zijn en nu pas actief worden. Ze zijn dus in die tijd geüpload, maar worden nu pas aangeroepen.
En toch komen ze daar ook nog vrolijk doorheen, althans, ik heb er 2 gehad.Citaat:
Oorspronkelijk geplaatst door Herbert
2 verschillende accounts, maar wel van een zelfde gebruiker, die een bepaald web develop progje gebruikt voor zijn websites (Web To Date 2). Dit programma maakt zelf nummerieke submappen aan creeert zelf de links daar naar toe.
Ben dus oon nog aan het zoeken naar een link met dit progje, hoe deze via ftp gegevens achterlaat / vrijgeeft / whatever.
(evt. met een open router :s )
Duidelijk. Dat wordt nog een puzzle dus (zie ook reactie van Geert-Jan) om die dingen op te sporen. Ik hoor van mijn klanten nl dat virusscanners, Hitman Pro, etc. niets fouts kunnen vinden op de PC van de gebruiker, terwijl duidelijk is dat zij als enige gebruik maken van zo'n FTP account. Hoe vindt je de boosdoener??Citaat:
Oorspronkelijk geplaatst door Wido
Vr.gr. Eef
Pas als je het botje ziet draaien of als je logins ziet vanaf rare IP's.Citaat:
Oorspronkelijk geplaatst door aristo
Zie ook: http://www.uptime.cz/100452-site-a-i...he-Attack.html (staat veel info!)
Zoek anders maar eens op: beladen.net (het is namelijk een variant van die trojan)
ik heb dus op 1 v.d. sites met bovenstaand commando wat gevonden. Maar wat nu te doen? Gewoon die php wegmikken? Er staat bij 1 v.d. klanten in een images-dir een .php file met wat meuk van http://xoops.instant-zero.com/
afhankelijk van wat je in je voorwaarden hebt staan even contact opnemen met de klant dat hij/zij dit oplost binnen afzienbare tijd. En anders zelf stappen ondernemen. toch?
Het beste kun je nu gaan zoeken in de log files wie dat bestand heeft geupload.Citaat:
Oorspronkelijk geplaatst door 1mind
Je hebt nu immers een bestand gevonden, de rest is nu makkelijk te achterhalen.
Als je het bestand zomaar verwijderd en niets doet dan is het probleem daarmee niet opgelost.
Ik heb dus nog steeds 1 klant met het probleem. Ik heb de /home dir gescand op de base64_decode (lekker command wido :) ) waarin (gelukkig) helemaal niets gevonden.
Na contact met de klant krijg ik de volgende reactie terug van hem:
Mijn eerste advies was dus om die opgeslagen accounts en passwords er uit te gooien, maar dan nog blijven we met de vraag hoe we dit kunnen gaan voorkomen, zonder dat de klanten daarvoor veel hinder gaan ondervinden.Citaat:
Mijn machine was inderdaad besmet en sinds dit weekend schoon...
Ik gebruik filezilla met opgeslagen ftp paswoords die ik nu dus
allemaal ga wijzigen zodat de Trojan die gedraait heeft en ftp
paswords van mij heeft er niks meer mee kan.
De IP adressen die voor acces zijn gebruikt komen overigens overal vandaan, een range blokken heeft geen nut...
ssh / scp (winscp) met ssh-keys ?
Is een tijdje terug meen ik (help mijn geheugen) in een ander topic ook een besproken. Technisch goed natuurlijk, maar voor iedere klant....????
Ter beeldvorming: met een suPHP, mod_ruid, wordt het initiele script als de gebruiker geladen - ik neem aan dat ze hier geen workaround voor hebben. Het is me even te laat om de code welke op de link die Wido gaf door te lezen, maar wat gebeurd erna?
Wat is het proces wat plaats vindt vanaf het laden van de pagina met het base64_decode verhaal? Misschien mis ik wat, maar ik vind veel nog erg onduidelijk. Ik kan me lastig voorstellen dat hier geen gemakkelijke oplossing voor is.