WP-sajter hos Oderland hackade, fler än jag?
 

Jag har 10 WP uppsatta hos Oderland på servern Hiruko (91.201.60.43) vilka hackats. En snabb sökning gjorde att jag hittade: http://eckstein.id.au/10952/wordpres...o-take-hacked/
Enl den texten så ligger problemet troligen på servernivå, så har fler än jag drabbats?
Jag har många WP's med liknande uppsättningar plugins, men bara de hos Oderland har drabbats

Du kan kolla om webbhotellet har någon form av säkerhetsskydd genom att tex. lägga till ?cmd=uname%20-a som en variabel till php. Du ska få sidan blockerad om det är som det ska vara, om du går till denna adressen som exempel så ser du att du blir blockerad: http://www.danielos.com/?cmd=uname%20-a
Denna typ av skydd tycker jag är det minsta jag tycker man ska kräva av sitt webbhotell.

Jo vi använde också mod_sec när vi körde i mindre skala... Det finns fler nackdelar än fördelar dock.

Hur som helst N!cklas, du fick svar på ditt ärende, vill inte gå in mer på det här, men det fanns en del att ta tag i där.
Svara på ärendet om du känner dig osäker så skall vi hjälpa dig så gott det går.

Där ser man, än har vi själva inte hittat några nackdelar.

Man kan också stänga av PHP_Uname men då kommer den att skapa error_log fil som fylls på med följande rader:

php_uname() has been disabled for security reasons in /home/XXXXX/public_html/piller/wp-admin/includes/class-pclzip.php on line 5672

Lösningen är att manuellt editera filen: class-pclzip.php och sätta ett @ framför php_uname.

Jo, men du har ju även en mängd andra attacker än just uname, det var mest ett exempel.

Det absolut farligaste måste väll ändå vara php_exec ?

Där kunden har tillåtelse om dom fått in fina perl/bash script eller annat o köra dessa?

Ska man jobba efter utmaningar så ska man ju lyckas stänga av alla funktioner i C99 shell :)

Men det är ju tyvärr så att stänger man av så många funktioner så fungerar inte riktigt alla sidor optimalt. Sen är ju ModSecure 2.0 bra men kan vara problem ibland på vissa sidor.

Sen kan man alltid lösa mycket med Chroot men kan bli en jobbig lösning på alla säkerhetsproblem.

Då håller man sig sysselsatt iallafall.

Som kund och ägare av en site kan man inte heller bara sitta på rumpan och utgå från att det kommer att funka. Wordpress har blivit så pass stort nu att det finns mängder av människor som bara sitter och letar säkerhetshål för att kunna infektera andra siter, det kan vara hål i allt från core till en sketen plugin. Som kund måste man hålla sina siter uppdaterade, och lägga den tid det tar att underhålla sin plattform.

Som hostingbolag ska man se till att servern är uppdaterad och att man täppt till dom ev. hål som finns där, sen om man väljer att erbjuda applikationsbrandväggar eller inte, det får stå för varje leverantör och där får man som kund göra ett avvägande. Kommersiella regler för modsecure är inte gratis, och det är ytterliggare en aspekt man måste ta med i sina rutiner för underhåll och administration.

Jag kan personligen känna att modsecure kan vara ett tillval för dom som är beredda att betala för det, men jag tycker nog inte att man behöver ha det i sitt standarderbjudande.

Saken är väl också den att för de flesta webbhotellskunder kommer det som en chock att ens webbhotell har dålig säkerhet eller ingen alls. Många vet tex. inte ifall ens hotell kör modsecurity eller något annat säkerhetssystem eller hur pass bra koll webbhotellet har på sina konton samt om tex. php körs chrootat eller inte. För mig är det en gåta att de flesta webbhotell inte kör modsecurity, men jag tror det beror på okunskap hur man använder och konfigurerar det på rätt sätt så man inte får som oderland säger en massa riktiga anrop som blockeras.

Bra, nu vet jag att jag aldrig någonsin ska bli kund hos Egenreklam.se.
mod_security trodde jag dött runt 1998. Ungefär i samma veva som safe_mode slutade användas dvs.

Typexempel av varför; Danielos hade säkerhetshål och rättighetsproblem i sitt system senast jag kollade ÄNDÅ - trots att han använder mod_sec :) Eller hur, Daniel?

EDIT:
För att vara lite ontopic med; Det kan ha varit ett simpelt säkerhetshål i WP eller något plugin till WP som ledde till att sajterna hackades (iom att dom låg under samma konto).

Mod_sec hjälper föga om plugin:et innehåller säkerhetshål som medför att en inloggad användare (ej administratör) t.ex. kan ändra källkod för plugin/tema/dylikt - sk. privilege escalation.