[ecstyle]

Ursprungligen postat av jonny

Först skriver du om ftp-loggen, men sedan är det inte där du har tittat?

Ja, FTP är ett osäkert protokoll och lösenord skickas i klartext, men intrång sker i princip aldrig via FTP.

Förmodligen är det ett säkerhetshål i din phpkod eller i värsta fall i någon annan kunds phpkod på samma server.

Det senaste året är det många som har drabbats och det är tydligen så att hackarna verkar ha kommit åt FTP-uppgifterna. Detta har skett i många olika system. Är datorn eller servern övervakad så bör det inte vara några problem att komma över FTP-uppgifter som skickas i klartext, inte heller om du har drabbats av en keylogger.

[grinditwp]

Tack för allt intresse.
Det är väldigt skumt.

Jag förstår verkligen inte hur någon skulle kunna komma åt några inloggningsuppgifter via cms:ett.

Även om de på något vis skulle kunna göra en SQL-Injektion, så finns det inte känsliga uppgifter sparade någonstans.

Angående chmod, så går det inte att skriva till någon mapp, förutom i en mapp längre in i filsystemet.

/www/images/user_image/

SKulel det kunna vara en risk? och vad gör jag för att skydda mig i så fall?

[ecstyle]

Har du kollat så att du inte har en keylogger?
I och för sig har du det så återkommer säkerligen hacket.
Här kan du läsa mer:
http://billing.handsonwebhosting.com...article&id=220

[grinditwp]

Ursprungligen postat av ecstyle

Har du kollat så att du inte har en keylogger?
I och för sig har du det så återkommer säkerligen hacket.
Här kan du läsa mer:
http://billing.handsonwebhosting.com...article&id=220

Tack för svaret, scannar datorn nu. ska be kunden scanna sin oxå. Det låter ju högst sannolikt.

[grinditwp]

Nu har jag scannat min dator med Avira AntiVirus samt SpyBoy Search & Destroy. Men de hittar inga fel, några andra tips på program?
Något annat jag kan göra för att gå vidare och inte se till så att sidan attackeras mer?

[ecstyle]

Ursprungligen postat av grinditwp

Nu har jag scannat min dator med Avira AntiVirus samt SpyBoy Search & Destroy. Men de hittar inga fel, några andra tips på program?
Något annat jag kan göra för att gå vidare och inte se till så att sidan attackeras mer?

Jag i länken du fick fanns det länk till ett gratisprogram som skall vara bra på att hitta keyloggers. Testa det. Comodo är ett annat gratisprogram som jag tycker är bättre än avira. Jag har kört SpyBoy Search & Destroy en gång i tiden och var inte speciellt imponerad.

Det är inte säkert att det är keyloggers, men att dom på något sätt fick tag på FTP-uppgifterna. I så fall så kan du försöka att logga in krypterat istället för okrypterat i fortsättningen.

[emilv]

Ursprungligen postat av ecstyle

Det senaste året är det många som har drabbats och det är tydligen så att hackarna verkar ha kommit åt FTP-uppgifterna. Detta har skett i många olika system.

Jag kan intyga detta. Vi ser det på Levonline också. Typiskt är att någon bot går in och redigerar alla filer som heter något med index och default, men det har även hänt att alla filer som slutar på .php och .html har ändrats. Attackerna sker alltid via FTP med rätt lösenord.

Även om man rensar filerna så brukar botarna komma tillbaka rätt snart. Det brukar dock hjälpa att ändra lösenordet på FTP-kontot, och allra bäst är som redan sagts att köra SCP eller SFTP (som egentligen är samma protokoll). En del FTP-klienter har inbyggt stöd för SFTP/SCP. För Windows rekommenderar vi annars WinSCP.

Ursprungligen postat av Mortekai

Jag gissar att sidan som du har problem med är antingen en Joomla sida eller ett forum? Alternativt något skript som har uppladdningsfunktion av någon form....

Jag har inte sett någon uppenbar koppling mellan färdiga CMS och dessa FTP-hack. Det är lika ofta hemmasnickrad kod som drabbas, eller sajter helt utan PHP (enbart HTML).

[Mortekai]

Ursprungligen postat av emilv

Jag har inte sett någon uppenbar koppling mellan färdiga CMS och dessa FTP-hack. Det är lika ofta hemmasnickrad kod som drabbas, eller sajter helt utan PHP (enbart HTML).

Då har ni antingen ovanligt få eller ovanligt många tillbud, jag hoppas på det förra Småhackers kan norpa ett FTP konto och busa runt lite, men den stora massan med hackade webbplatser sker med bottar direkt fokuserade på kända säkerhetshål.

Jag skrev en post om Joomla moduler som hade säkerhetsbrister och jag tror jag har haft 5-10.000 försök från bottar dom senaste två åren riktade just mot den posten

Skript som tillåter uppladdningar och där det krävs CHMOD 777 för att skriptet ska fungera är rena julafton för dom här bottarna vilket är en bra anledning till varför kunder aldrig ska behöva ge högre rättigheter än 755 på kataloger och 644 på filer.

Att få en iframe injicerad i en sida är ett typiskt angrepp mot bland annat PHPBB och gamla IPB forum som jag vet om, annars brukar det vara vanligare med en defacial när man byter ut förstasidan till exempel om man får tillgång till en kunds FTP uppgifter eller att man lägger in skript gömda i användarens kataloger som sedan används för phishing, spam eller att vidare infektera servern.

[taz76]

Kolla också kataloger och filer så inte någon har laddat upp något skumt som t.ex ett phpshell. En möjlighet är ju att nån använt ett säkerhetshål i en webbapplikation och laddat upp ett phpshell som sedan lämnar kontot öppet i stort sett.

[emilv]

Ursprungligen postat av Mortekai

...

Vi stoppar många "vanliga" injektionsattacker med hjälp av mod_security redan, vilket kanske förklarar varför vi inte alltid ser sås tora problem med färdiga system. Men visst har vi haft vår beskärda del av Joomla-hack också.

Jag håller inte med dig helt om rättigheterna. Webbservern ska inte kunna skriva till filer som har 755-rättigheter. Det är en större säkerhetslucka än att kräva 777-rättigheter imo.
Det är sällan som ett hack drabbar andra sajter än den sajt som blivit hackad, åtminstone har det vad jag vet aldrig hänt på Levonline, trots att vi kräver 777-rättigheter på de mappar som webbservern ska kunna skriva till.

Det är förvisso möjligt för andra kunder att ändra något på en 777:ad sajt, men det kräver att den som hackar vet vilka sajter som finns på andra kunders konton (eftersom vi inte ger other listrättigheter till public_html, och då måste man veta vilka domäner som användaren har där).

Å andra sidan kommer de flesta filer att ha skrivrättigheter för den egna användaren, eftersom användaren tycker det är opraktiskt att inte kunna ändra sina egna filer, och att ge webbservern skrivrättigheter till alla filer på kontot kan potentiellt ställa till mycket problem för den enskilda kunden. Att bara kräva 755-rättigheter för att webbservern ska kunna skriva (vilket råkar vara samma rättigheter som behövs för att den egna användaren ska kunna skriva till filerna) gör ju då i praktiken att webbservern kan skriva till hela kundens hemkatalog, vilket öppnar upp mycket för den som hittar säkerhetshål i kundens sajt. Med 777-rättigheter kan man i alla fall välja själv vilka mappar som ska vara skrivbara.

Min favoritlösning är en där det krävs 775-rättigheter för att webbservern ska kunna skriva till filer, och att man köra webbservern som en annan användare än kunden, men som en unik användare för varje kund och i en unik grupp. Eller ännu snyggare är om man lyckas sätta upp ordentliga SELinux-regler...