FAQ |
Kalender |
|
![]() |
#1 | |||
|
||||
Bara ett inlägg till!
|
Citat:
Ä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. 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). |
|||
![]() |
![]() |
![]() |
#2 | |||
|
||||
Mycket flitig postare
|
Citat:
![]() 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. |
|||
![]() |
![]() |
![]() |
#3 | ||
|
|||
Flitig postare
|
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.
|
||
![]() |
![]() |
![]() |
#4 | |||
|
||||
Bara ett inlägg till!
|
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... |
|||
![]() |
![]() |
Svara |
|
|