Menu

Apache symlink hack WordPress és Joomla ellen

Megírtuk már a blogunkban, hogy egyik szerverünkön több Joomla és WordPress alapú oldalt is feltört egy (vagy több hekker). De hogyan történhetett ez? Hogy lehetséges, hogy hozzáfértek az oldalak jelszavaihoz, és megváltoztatták a template fájlokat? A teljes történet megértéséhez kezdjük egy kis háttérinformációval.

A korlátlan tárhelynek ára van

Szolgáltatásainkkal szeretnénk megrendelőinket maximálisan kiszolgálni, ezért a tárhely szolgáltatásaink kidolgozásakor úgy döntöttünk, hogy a lehető legkevesebb akadályt gördítjük a fejlesztők elé, és mindent engedélyezünk a szerver konfigurációs fájlokban. Azt nagyon gyorsan az indulás után beláttuk, hogy nem működőképes a dolog. A rengeteg biztonsági rés és az okos hekker toolok pillanatok alatt kiszúrják az ilyen szervereket. Így a beállításokat folyamatosan optimalizáljuk, hogy a nyílt forráskódú platformok könnyedén telepíthetők legyenek, és általában mindenkinek megfeleljenek a szerverek, de biztonságosak maradjanak. Számos programot, toolt és tűzfalat használunk, hogy kiderüljenek a biztonsági rések, és megfogjuk az esetleges illegális tevékenységet.

Mire gondoltunk először?

Természetesen arra, hogy a feltörést az oldalakon keresztül követték el, és minden feltört oldalban van valami közös, például, hogy régi verziók, vagy egy sebezhető plugin vagy template van rájuk telepítve.

Ez a feltételezés részben igaz volt. Rengeteg megrendelőnk használ 2009-es Joomlát vagy  a hekker iskola első napján kötelező oktatási anyagként szereplő timthumb.php-t. Ez úton is felhívom mindenki figyelmét a folyamatos frissítésre, amiben segít az adminisztrátori felületen levő telepítő azzal is, hogy figyelmeztetést küld az új verziókról!

Sajnos azonban észrevettük, hogy ez nem minden oldalra igaz. Tehát az oldalakat úgy törték fel, fértek hozzá a jelszavakhoz és deface-elték, hogy voltak köztük friss telepítések is.

Jó tudni!

Vigyázat mélyvíz! Technikai részletek következnek, ha nem érdekelnek a programkódok vagy szerver konfiguráció, akkor olvasd el blogbejegyzésünket!

A felhasználók jogai a szerveren

Egyik biztonsági megoldás például, hogy a szervereken levő PHP programok minden esetben az operációs rendszerben létrehozott felhasználó nevében futnak. Tehát mindenkinek a szerveren van saját valódi felhasználója, és ezek a felhasználók nem férnek  hozzá a másik felhasználók könyvtáraihoz, mert a PHP-t futtató kód ezt megakadályozza. Tehát a domainA felhasználó nem tudja futtatni a /home/domainB könyvtárban levő dolgokat, csak a /home/domainA-t.

DomainA egyáltalán nem férhet hozzá a DomainB könyvtárában levő wp-config.php (wordpress) vagy configuration.php (Joomla) fájlokhoz, mert a PHP futtató ezt megakadályozza.

Apache symlink trükk

Ahhoz, hogy hozzáférjünk a szerveren a felhasználók WordPress és Joomla jelszavaihoz, először fel kell törni egy régebbi rendszert, hogy hozzáférésünk legyen egy tárhelyhez. Erre tökéletesen megfelel például egy 2009-es Joomla, aminek a könyvtárait telipakolhatjuk a saját fájljainkkal, és utána futtathatjuk is azokat. (A feltörés pontos módját azt hiszem érthető okoknál fogva nem írom le.)

Tehát már tudunk mindenféle PHP parancsot futtatni a szerveren, de csak domainA felhasználó nevében, és nem férünk hozzá domainB felhasználó fájljaihoz, mert a PHP futtató ezt megakadályozza.

Azonban ha az egyik kis okos programunkkal készítünk egy symlinket domainB felhasználó könyvtárára, és .htaccess fájlban azt mondjuk, hogy a PHP fájlokat ne a PHP futtató hajtsa végre, hanem az Apache web szerver kezelje a PHP kiterjesztésű fájlokat szövegfájlként, domainB könyvtárából olvasni tudjuk a PHP fájlokat abban az esetben ha azok jogosultságai ezt lehetővé teszik, például az adatbázis hozzáféréseket tartalmazó konfigurációs fájlokat.

Ha már megvannak ezek a jelszavak, akkor az adatbázisokban könnyedén módosíthatjuk az admin jelszavakat, és mindent amit csak akarunk. Aztán az admin jelszóval bejelentkezve a felületre Joomla és WordPress esetében is lehetőségünk van a téma megváltoztatására, így könnyedén módosíthatjuk azt.

Megoldás symlink feltörés ellen

Első körben az Apache szervereket beállítottuk, hogy ne kövessék a szimbolikus linkeket, szigorítva az első részben írt “korlátlanságon”. Ezt az Options beállítás teszi lehetővé. Ettől a beállítástól a Joomla oldalak kiakadtak, számomra érthetetlen oknál fogva a Joomlának szüksége van a szimbolikus linkekre. Szóval gyorsan visszaállítottuk az eredeti beállítást.

Szerencsére van megoldás, mégpedig szintén az Options beállításnál a SymLinksIfOwnerMatch. Ez akkor teszi lehetővé a szimbolikus linkek követését, ha annak tulajdonosa egyezik a programot futtató felhasználóval. Így más könyvtárába nem lát bele az Apache processz.

Mit tehet a tárhely tulajdonos

A fentebbinél egyszerűbb megoldás, ha mindenki odafigyel rá, hogy a szenzitív fájlok ne legyen olvashatók az egész világnak. Tehát mindenképp be kell állítani a konfigurációs fájlok jogosultságát 600-ra, hiszen pl. 644 azt jelenti, hogy a fájl bárki, például a szerver többi felhasználója számára is olvasható. Ezt a beállítást most egy szkripttel el is végeztünk az oldalakon, de természetesen egy új telepítésnél mindenkinek magának kell beállítania.

Természetesen azoknak a fájloknak a jogait melyeket a böngésző felhasználók láthatnak (például index.php vagy képek) nem szabad átállítani, csakúgy mint a publikus mappa jogait, mert az oldal elérhetetlenné válik.

Jó tudni!

  • A szervereket nem törték fel.
  • A hekker tárhely szolgáltatásokat tört fel úgy, hogy kihasználta az oda telepített program hibáit
  • A fentebbi leírás szándékosan nem tartalmaz konkrétumokat, nem hekker képzést szerettem volna tartani
  • A fentebbi módszer ellen a Tárhelypark szerverei már védettek, minden próbálkozásról naplóbejegyzés készül

 

Régi fájlok törlése parancssorból

Számos esetben fordul elő, hogy egy könyvtárból törölni szeretnénk egy időpontnál régebbi fájlokat. Most az egyik szerver /tmp köyvtárában voltak igen régi fájlok, de mivel az Apache web szerver is itt tárolja a session adatokat, azért csak a 10 napnál régebbieket szerettem volna törölni. A megoldás:

Fontos a -type f opció, ami azt mondja, hogy a find csak a normál fájlokat találja meg, így a könyvtárak és egyéb fájlok nem törlődnek.

Jó tudni!

A find és rm rossz paraméterezésével könnyen törölhetsz olyan fájlokat is, amiket eredetileg nem szerettél volna, például symlinkeken keresztül!

WordPress sebesség probléma, wp_option tábla

Sok megrendelőnk használ WordPress blog motort, ami nem csoda, hiszen a nemzetközi kimutatások alapján ez az egyik legelterjedtebb ingyenes blog engine, ráadásul adminisztrátori felületünkről egyszerűen telepíthető is. Egy bizonyos látogató szám elérése után azonban nem ritka, hogy sebesség problémák jelentkeznek, amik hatványozottak ha több, esetleg nem jól tesztelt plugin-t telepítün fel.

Az egyik legfőbb probléma a MySQL adatbázis indokolatlan terhelése még akkor is, ha valamilyen cache megoldást már telepítettünk. Az adatbázis log elemzését követően gyorsan kiderül, hogy a nagy számú lekérdezés mögött egyetlen select utasítás áll, ami a konfigurációs paramétereket olvassa. Ez a select gyakorlatilag minden szerverünkön a legtöbbet futtatott sql művelet, naponta átlagosan több mint 750.000-szer fut le.

Egy gyors, tíz perces időszak elemzése után ezt kapom az egyik szerverünkön:

Az elemzés ideje alatt a lekérdezés 16.328-szor futott, ez összesen 568 másodpercig tartott, ebből 458 másodpercig zárolta a táblát, és a lényeg: eredményül 385 sort adott vissza amihez 6.292.345 sort vizsgált át. Huh, nem valami hatékony!

A gyors megoldást egy index elhelyezése jelenti a wp_options táblán:

Ha az index létrehozása után elemezzük a lekérdezést a MySQL beépített Explain parancsával, akkor már látható, hogy használni fogja az indexet:

A témáról a WordPress support fórumon is találtam bejegyzéseket, talán ez a leghasznosabb bejegyzés: http://wordpress.org/support/topic/prefix-the-length-of-indexes

Kinek érdemes indexet létrehozni?

Ha szerverünkön kíváncsiak vagyunk, hogy ki az a felhasználó akinek létre kéne hoznia ilyen indexet, akkor az alábbi utasítással könnyedén lekérdezhetjük:

Ez után már csak szólnunk kell neki, vagy akár létrehozhatjuk az indexet magunk is, ha van hozzáférésünk.

Google maps használata offline módban

Minden alkalommal amikor külföldre megyek a határon döbbenek rá, hogy a Google Maps nem működik az Androidon ha nincs net. Márpedig külföldön az adat romaing árak igencsak borsosak, így nem engedélyezem. Szóval a határon a telefon adat kommunikáció kikapcsol, és ennyi. Még évekkel ezelőtt hallottam, hogy létezik a funkció, amivel egy térkép részlet SD kártyára menthető, és így a Google Maps képes offline működésre, ez persze eddig soha nem jutott eszembe az út előtt, csak a határon. Most a helyzet azonban változott. Holnap indulunk Krakkóba a Railsberry konferenciára, és végre eszembe jutott.

A funkció már évek óta létezik Pre-cache map area néven, csak egy kicsit el van dugva. A működéshez a Settings > Labs menüben ki kell választani a Pre-cache map area opciót, ezzel engedélyezzük a funkciót. Ezek után ha a térképen kiválasztunk egy címet (hosszan tapizunk a képernyő egy részén, és a felbukkanó buborékban a kis nyílra bökünk) akkor a cím menü alján megtaláljuk a Pre-cache lehetőséget.

A Pre-cache funkcióval a Maps letölti a kiválasztott cím 10 mérföldes (kb. 16 km) körzetét (igazándiból egy tízszer tíz mérföldes részt, nem kört) a telefon SD kártyájára, így azt akkor is használni tudjuk, ha nincs adatkapcsolat. Jó dolog, hogy akár több térkép részlet is letölthető, gondolom a korlát a memória vagy SD kártya mérete.

Az SD kártyára letöltött adatokat törölni is tudjuk, hogy ne foglaljanak helyet a Settings > Cache settings > Pre-cached map areas menüben. Itt akár a nevüket is megváltoztathatjuk, aminek nem sok jelentőségét látom egyelőre.

Update: az offline mód távolról sem váltotta be a hozzá fűzött reményeket. Gyakorlatilag használhatatlan navigációra, mert a pre-cached térképen nem lehet keresni és a navigáció sem működik. A navigáció addig működni tud, amíg ki nem lépünk belőle, vagy le nem térünk az útról, mert ez végzetes, nem működik tovább. Belátható, hogy ez egy 7 órás krakkói úton elkerülhetetlen, így meg is történt. Nagyjából a Cseh-Lengyel határon adta fel a navigáció, minek eredménye képp jól el is tévedtem, pedig ki is volt nyomtatva az út.

Tanulva a hibából, letöltöttem egy valódi navigációs szoftvert. A Sygic 8 napos kipróbálást ad, így nem kell látatlanba fizetni. A használatával gyorsan megváltozott a Google Maps-hez ragaszkodásom. A két térkép fényévekre van egymástól, természetesen a Sygic mindent tud az utazásról, még a trafiopaxokat is. Mindenkinek ajánlom, felejtse el a Google maps-et ha valódi navigációra és utazási információra van szüksége!

Perl folyamat gyilkolás

Sajnos előfordul, hogy tárhely szerverünkön hekkerek feltörnek egy-egy oldalt, és sikerül elindítaniuk egy-két szkriptet, melyek általában Perl alapúak. Ezek aztán memóriát és processzort nem kímélve próbálják feltörni a szervert, jelszavakat, adatbázist stb. Szerencsére sok kárt nem tudnak okozni, és aránylag könnyen lelepleződnek, mert a szerver CPU használata igencsak megnő. De mit lehet tenni, ha már észrevettük a problémát?

(tovább…)

Felhasználó leveleinek törlése Exim mail queue-ból

Elég gyakran adódik, hogy egy feltört cPanel tárhelyen keresztül levelek tízezreit próbálják kiküldeni az ügyes kezű hekkerek. Ez általában addig működik, amíg a szerver le nem tiltja a levélküldést mert eléri az óránként pár ezres limitet a felhasználó. Ekkor kezd el nőni az Exim queue az egekbe, de mit lehet tenni a beragadt Spam levelekkel? (tovább…)

Signed request több Facebook tab-on és Suhosin

Új Facebook játékunkat fejlesztem, és úgy döntöttem az eddigi gyakorlat helyett nem VPS-en fogom tárolni a programot, hanem normál tárhelyen szerverünkön. Egymás után két problémába is beleütköztem: először is mivel Facebook tab-on szerettem volna megjeleníteni az oldalt kezelnem kell a signed request paramétert, másodszor pedig a paraméter méretéből adódóan konfigurálnom kellett a Suhosint a tárhely szerveren. (tovább…)