Sziasztok!
Nagy fába vágtuk a fejszénket. Az ügyfeleink érdekében a következőt kezdtük el megvalósítani:
Azok a tárhelyes ügyfeleink, akik igényt tartanak rá rendszeres értesítőt kapnak arról, ha új biztonsági frissítés jelent meg a Drupalhoz.
Az értesítésben benne lesz a fontos tudnivalók és az is, hogy ha nem tudják megoldani a frissítést, akkor kihez fordulhatnak.
(Nagyon sok olyan cég van, akinek valaki beállított anno egy drupal rendszert olcsón, de támogatást nem adott hozzá. Érthető, hogy ezeket idővel a robotok feltörik)
Két dolgot szeretnék tőletek:
- Hogyan lehet az adatbázis alapján egyértelműen megállapítani, hogy drupal rendszerről van szó és hol található az adatbázisban a verzió szám.
- Ki az aki pénzért vállalná, hogy igény esetén elvégzi a szükséges frissítést az ügyfelünk drupal rendszerében
Lehetőleg az első pontra ide írjátok a válaszokat, míg a második esetén privátot kérek ár és kapacitás megjelölésével.
Ha esetleg rossz helyre írtam a kérésemet, kérlek jelezzétek, mert a törlés túl kevés információt hordoz.
ui.: Ha az elképzelésünkről van véleményed, azt is szívesen fogadom.
jó ötlet
Nagyon jó ötletnek tartom.
Drupal webhelyek beazonosítására két jó módszer van:
1. http://isthissitebuiltwithdrupal.com/ :)
2. A HTTP header vizsgálata: http://www.lullabot.com/articles/is-site-running-drupal
Expires: Sun, 19 Nov 1978 (A Drupal-alapító Dries Buytaert születésnapja)
kiegészítő modulok?
Viszont a kiegészítő modulokat is frissíteni kell. Igazából azok jelentik a nagy biztonsági kockázatot... Javaslom megnézni a Drush-t.
Erre nem is gondoltunk
Szóval akkor azt mondod, hogy hiába tudom meg a fő drupal verziót, mert lehet az friss, de a kiegészítő rejti a biztonsági kockázatot?
Ez a drush pontosan mire jó, mert megnéztem a linket, de nem lettem sokkal okosabb.
Biztonságos Domain Regisztráció
sokféle kockázati tényező van
A fő verzió, a drupal.org-ról letöltött kiegészítő modulok és sminkek, saját fejlesztésű modulok és sminkek, nem megfelelően beállított jogosultságok... ajánlom a Cracking Drupal c. könyvet.
Drush: PHP parancssoros interfészre (CLI) épülő, a Drupal fájlrendszert és adatbázist menedzselő alkalmazás. Parancssorból lehet telepíteni, frissíteni, stb.
Mit javasoltok?
Sajnos nem lehetünk minden cms szakértői. Azonban Drupalban ti vagytok a legjobbak.
A probléma a következő. Sokan telepítenek egy drupalt, beállítják az ügyfélnek és aztán eltűnnek.
A céges honlap működik, aztán egyszer csak jönnek a problémák a spamek és a feltörések miatt.
Ezt kizárandó arra gondoltunk, hogy felkutatjuk automatikusan a tárhelyünkön lévő drupla rendszereket és a tulajdonosnak szólunk, hogy a drupalja biztonsági kockázatot jelent.
Majd felkínáljuk neki, hogy ha Ő nem tudja frissíteni, akkor ajánlunk neki szakembert. Valakit közületek.
Úgy gondolom, hogy az adatbázis ellenőrzése jó módszer, mert a Joomla és a Wordpress esetén működik. A drupálnál ezt hogyan lehetne megoldani?
Sajnos nincs kapacitás könyveket átolvasni és valószínű minden modult sem lehet ellenőrizni, viszont egy köztes és elég jó megoldásra kell törekednünk. Reméljük, hogy ebben tudtok segíteni.
Biztonságos Domain Regisztráció
köszi
Ez nagyon gyors volt. Úgy látom pörög a közösség. Büszkék lehettek ilyen aktivitásra.
1, Megnéztem, de nekünk ez nem jó, mert azt kellene tudni, hogy milyen verziót használ a user.
2, Ez már egy jó megoldás lehet.
Igazából tudunk fájlokat is vizsgálni, de eddig szinte mindegyik CMS rendszernél elég volt az adatbázist, ezért ha van megoldás arra, hogy az adatbázis alapján megállapítsuk a verziót, akkor ahhoz ragaszkodnék. Ha nincs megoldás, akkor foglalkoznánk a fájlok vagy a HTTP header vizsgálatával.
Biztonságos Domain Regisztráció
bootstrap.inc 11. sor
Én nem tudok róla, hogy az adatbázisból nagy biztonsággal meg lehetne állapítani. Az includes/bootstrap.inc-ben van definiálva a fájlrendszer verziószáma.
A legtobb felhasznalo nem
A legtobb felhasznalo nem torli ki a kapcsolodo fajlokat a Drupal konyvtarabol, igy megoldas lehet a CHANGELOG.txt megnezese, altalaban a legelso bejegyzes az aktualis Drupal verzio kiadasi megjegyzese. Ezt osszevetve a drupal.org -on talalhato aktualis verzioszammal, el lehet jutni bizonyos kovetkeztetesekre.
Persze ez kozel sem szazszazalekos megoldas, de talan egy lepessel kozelebb visz.
Meg egy lepessel kozelebb vihet a modulok .info fajljanak ellenorzese. Ezekben (mar amelyik modul a drupal.org -rol van) szinten megtalalhato az illeto modul aktualis verzioszama, es szerintem a drupal.org biztosit valami api-szeruseget, amivel ez szinten lekerdezheto (vegulis a drush is igy mukodik).
Amiert en nem drush-t valasztanek erre a feladatra, az az, hogy egy oldal sokfele szempontbol lehet torott, es kozel sem biztos, hogy barmilyen drush parancs lefut az adott oldal gyokeren. Ezen felul a tapasztalatok azt mutatjak, hogy a drush kimenete varatlanul megvaltozhat, ezt parzolni szinten nem egyszeru, es hibakra ad lehetoseget.
Szoval ha csak a verzio ellenorzes a cel, en errefele indulnek. Persze, az is elmond valamit az illeto oldalrol, ha a drush mindenfele random hibakat dobal es errorral lep ki, de ehhez az is kell, hogy vilagos legyen a cel, amit el szeretnetek erni: azt szeretnetek tudni, hogy elavult-e az oldal, vagy azt, hogy kompletten rossz.
--
()=() Ki oda vagyik, ('Y') hol szall a galamb C . C elszalasztja a ()_() kincset itt alant.Drush a legkényelmesebb
Ellenőrzés Drush-sal.
Nem egyszerű a verziószám kiderítése; command line, PHP-script
Az még önmagában megoldható lenne, hogy egyetlen Drupal verziószámát lekérdezzük egy PHP-scripttel, úgy, hogy a
DRUPAL_BOOTSTRAP_CONFIGURATIONfázisban inicializáljuk a Drupalt, majd a definiáltVERSIONkonstans értékét megnézzük.A probléma az, hogy úgy emlékszem, ez a konstans csak 6-ostól van meg (de korrigáljatok, ha korábban is létezett).
Lásd a
bootstrap.incfájlt:http://api.drupal.org/api/drupal/includes%21bootstrap.inc/7
define('VERSION', '7.16-dev');Az viszont már problémát jelent, hogy runtime-ban meg kell határozni az aktuálisan vizsgált Drupalnál a
DRUPAL_ROOTkonstanst, és ezt majd később felül kellene tudni definiálni, ha pl. az ügyfelek Drupaljain egy ciklussal kellene végigmenni. Plusz ugye aVERSIONkonstanst is felül kellene tudni definiálni ilyen esetben, mert minden ügyfélnél más-más lehet.Ezért kerülő megoldás lehet, ha mondjuk az aktuális Drupal-könyvtárat argumentumként adjuk be egy PHP-scriptnek, ez a script megkapja ezt, ez alapján dolgozik, megvizsgálja az adott könyvtárat, majd végez. Ezt a scriptet pedig ciklikusan futtathatná egy akármilyen shell script vagy batch script.
De ez csak egy gyors ötletelés, és valószínű, hogy így sem feltétlenül teljesértékű megoldás - pl. ha korai verzió, nem biztos, hogy létezik a
VERSIONkonstans; de ez persze egyben egy szűrő is lehet, ha túl régi változat (if(!defined('VERSION')){ /* túl régi... */ }).Az alábbi kód útmutatást adhat kezdetnek, természetesen annyiban módosítani kellene az előbb leírtaknak megfelelően, hogy a
$drupal_root_directoryváltozó a command line-tól kapott valamelyik argumentummal (http://php.net/manual/en/reserved.variables.argv.php) lenne egyenlővé téve.============
Szerk.:
most látom, hogy a
VERSIONkonstanst már említette előttem Illyés Edith.A fentire kapott -1 szavazat okára kíváncsi lennék, hogy a szavazó szerint mi nem stimmel (igaz, elvileg csak ötletelés zajlik); mindannyian tanulhatnánk belőle (legfőképpen én). Tényleg érdekelne, mi a rossz a gondolatmenetben.
Következő lépés
Köszönöm a segítséget!
Sikerült megoldani a feladatot és most már tudjuk, hogy kinek küldjünk drupal frissítéseket.
A kiküldött értesítőbe szeretnénk rakni tájékoztatást is, hogy milyen biztonsági beállításokat érdemes elvégezni, azonban erre vonatkozóan nem találtam semmilyen leírást a neten.
Joomla rendszerhez már készítettünk egyet:
http://domain.domainflotta.hu/joomla-biztonsag
Tudtok abban segíteni, hogy hol találok leírást a drupalhoz? Persze vannak dolgok, amiket mindenkinek érdemes megcsinálni a biztonság érdekében, de most kifejezetten drupal specifikus dolgok, kiegészítők érdekelnek.
ui.: Úgy vettem észre a drupal a legbiztonságosabb cms, már csak azért is, mert akik használják jobban értenek hozzá, mint pl.: Joomla vagy Wordpress -t használók.
Biztonságos Domain Regisztráció
Konkrétan?
Melyik megoldást választottátok?
A zzzinterneten. :) Na jó, bocs, konkrétan mire vagytok kíváncsiak? A hivatalos http://drupal.org honlapon számtalan nagyon hasznos és fontos leírás található, meg nyilván a http://drupal.hu is rengeteg segítséget nyújt (lásd pl. Kézikönyv), de ezenkívül még rengeteg ügyes Drupal-fejlesztő saját honlapját, tutorialjait, beszámolóját is érdemes olvasgatni; a különböző előadásokról készült videókról már nem is beszélve.
Így általánosságban nem lehet megmondani, hogy na EZ lesz az, ami nektek kell, konkretizálva talán több esély van.
(nem-fejlesztői) security útmutatások
http://www.madirish.net/242
http://www.acquia.com/resources/acquia-tv/conference/cracking-drupal-pro...
http://drupal.org/project/security_review
...és ha marad rá idő/érdeklődés, akkor esetleg itt is lehet még keresgélni:
http://groups.drupal.org/best-practices-drupal-security
(a kereső kifejezés a hardening drupal és a cracking drupal voltak)
A lényeg valóban, hogy naprakészen kell tartani az installációt.
Ehhez segítség, ha feliratkoztok ennek az oldalnak a tartalmára akár email-hírlevél formában (drupal.org user létrehozásával), akár rss-en keresztül: http://drupal.org/security/
köszönöm
Ezt kerestem. Hála a segítségért!
Biztonságos Domain Regisztráció
Drupal Biztonság
Sziasztok!
Elkészült a drupal biztonság leírása:
Drupal Biztonság
Kérlek egészítsétek ki, ha valami még eszetekbe jut.
Továbbá...
Várom még azok jelentkezését, akik az ügyfeleink drupal rendszerének frissítését elvégeznék.
Biztonságos Domain Regisztráció
Jó ötlet
Most láttam a kezdeményezéseteket a fórumban, és nagyon jó ötletnek tartom, hogy erre is figyeltek!
Legelső észrevétel (nem tudom, hogy más jelezte-e már)
A főoldalatokon alul a Legújabb cikkeknél most rossz a Drupal biztonsághoz tartozó link:
http://www.domainflotta.hu/tudasbazis/idx.php/22/180/Hasznos-segtsgek/ar...
(Bár emellett több törött link is van ott)
A drupal.hu fórumba berakott link jól működik:
http://domain.domainflotta.hu/drupal-biztonsag
4 helyen is a PrestaShop-ra hivatkoztok a Drupal helyett:
A 4., a 8., és a 9. pontokban, és a legvégén a "Ha segítség kell..." résznél.
Az 5. pontban a "Sose telepíts az éles oldaladba "dev" modult." erősnek érzem, mert van olyan, amikor nem tudod kikerülni a dev modulok használatát. Szerintem ha ki van tesztelve az oldaladdal a dev modul, és nem egy olyanról beszélünk, amit tegnap adtak ki, akkor lehet telepíteni.
A 8. és a 9. pontnak ugyan az a tartalma.
A 11. pontban elírások:
"A drupla oldalak" Egyébként ezt én inkább úgy írnám, hogy "Sajnos a drupal oldalak is ki vannak téve a spam támadásoknak" :)
"email ím"
Szintén a 11. pontban:
"Az is egy jó módszer, ha csak regisztrált felhasználók szólhatnak hozzá"
A CAPTCHA akkor is kell, ha csak a regisztrált tagok szólhatnak hozzá.
Írj rám, ha érdekel a Győri Drupal Használói Találkozó.
Csatlakozom
A Drupal nem keretrendszer (framework), hanem CMS. A kettő nagyon nem ugyanaz!
Nem minden Drupal-oldalon történik valódi pénzmozgás... Ezt is egy kissé pontosítani kéne.
Ezután több pontba szedett lista következik. Hol van ez a hivatalos ajánlás? Egy hivatalos link nem ártana. Rákeresve például sehol nem találok olyan hivatalos ajánlást, amiről Ti beszéltek pl. az első pontban (
<FilesMatch "(authorize|cron|install|upgrade).php"> Order deny,allow deny from all Allow from 127.0.0.1 </FilesMatch>).Valószínűleg azért, mert nincs ilyen hivatalos ajánlás. :) Ha valami tutorialban ez olvasható, az közel sem hivatalos információ.
Valószínűleg a továbbiak nagy része is inkább Drupal-felhasználók által írt javaslatok.
Ami a
.htaccess-ben eleve benne van, az az alábbi (7.16, részlet):Ezeknek mi értelme van? Semmi. Ez nem növeli a biztonságot.
SŐT, például a
web.configtörlése kifejezetten káros, mivel semmi nem zárja ki, hogy valaki költöztetni szeretné a Drupalját Apache-ról IIS-re, aztán esetleg onnan vissza. Ne az legyen az alapfeltételezés, hogy mindenki Apache-szervert használ.Ezek a törölgetések teljesen értelmetlenek, csak a biztonság hamis látszatát keltik, de pozitív hatásuk nincs, sőt.
Milyen „alapértelmezett "admin" felhasználót”? Nem tudok ilyenről; a telepítés során meg kell adni, milyen felhasználónevet fog megadni az illető. Ha az instrukció arra vonatkozott, hogy telepítéskor a felhasználónévnek ne az "admin" karaktersorozatot adjuk meg, akkor valahogy így kéne hangzania. :)
Először disabled-re rakni, utána uninstallálni, majd ezt követően törölni. Volt már pár embernek problémája itt drupal.hu-n is amiatt, mert egyszerűen csak törölte az adott modult, mert nem tudta, hogy előtte le is kéne tiltani, meg uninstallálni. Pedig kell.
Egyetértek az előttem szólóval, ez így önmagában egyáltalán nem igaz: vicces, de előfordul, hogy éppen a "dev" állapotú modul a stabilabb (pl. ha kiderül az elvileg stabil verzió egy gyengesége).
Ez miért lenne jó? Az alkalmazás dolga elintézni ezt, a webszerver ebbe ne akarjon beleokoskodni.
Nem véletlen, hogy a Drupal .htaccess fájlban is benne van:
"titkosított a forráskódja"
Mutathatna nekem valaki olyan Drupal-modult, aminek ilyenje van. :)
dev security
Hi, két dolog:
A htaccess körüli tanács (csak 127.0.0.1-ről allow) a madirish.net-es cikkben van, amit feljebb linkeltem ebben a topicban (hozzáteszem, anélkül, hogy alkalmas lennék a benne foglaltak szakmai lektorálására).
A félreértés a "dev" verziójú modulok körül abból a körülményből származhat, hogy a Drupal Security Team ezekhez nem biztosít értesítőket (csak X.Y-1.0-tól kezdődően) (illetve esetleg csak rendhagyó esetben).
Egészen pontosan: "The development branch of Drupal is not intended for production use. Security problems are fixed, but security announcements are not issued." (CTRL+F → "Which versions are supported" ezen az oldalon.)
Emiatt én úgy fogalmaznék, hogy lehetőség szerint kerülendő a "dev" verziójú modulok használata, amennyiben azonban mégis alkalmazásra kerül ilyen, akkor a honlap tulajdonosa legyen tisztában vele, hogy a fentiekből eredően lehetséges, hogy biztonsági kockázatot vállal.
hivatalos?
nem keretrendszer, nem CMS: mindkettő
A Drupal nem pusztán keretrendszer és nem csak CMS. Ha ezt a kettőt tekintjük végletekként, akkor a Drupalt középre pozicionálnám úgy, hogy bármelyik irányba kiterjeszthető. Pl. használtam már úgy keretrendszerként a Drupalt, hogy csak az adatbázis-alrendszer kellett belőle és se node-ok, se felhasználók nem voltak.
Kicsit bővebben itt: Mi a Drupal, mire használható?
A fórumtéma indítójának pedig különösen ajánlom még a következő linket, illetve az egész témát is: http://drupal.hu/comment/61939#comment-61939
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
érdekes ötlet
Hmm, érdekes elképzelés, nekem még ilyen nem jutott eszembe, vagy legalábbis nem volt erre igényem. De egyébként érdekelne a dolog, milyen jellegű webalkalmazásnál lehet ez indokolt? Mi az oka, hogy a Drupal által kínált "keretet", függvényeket használod, és nem mondjuk egy más, jóféle, PHP-alapú ORM-et az adatbázis-kezelésre (ha erre a példára koncentrálunk), vagy akár egy tök független keretrendszert, ami a CMS-ek hozzáadott sallangjaitól mentes? Szimpla "megszokás", tehát hogy már jól kiismerted a Drupalt, és ez gyorsítja a munkádat? Vagy más okai vannak?
hasznos
Köszi ez valóban hasznos volt.
Az, hogy mi a drupal nem célom megítélni, de a cikkben nem javítom, mert így gondolom. Ti vitatkozzatok rajta, ha akartok :)
A szerveren a legtöbb problémát, amit felvetnek megoldottuk, legyen szó a fejlett hibakezelés bekapcsolásáról (http://domain.domainflotta.hu/Fejlett-hibakereses#content) vagy az 500 hibákról.
Az utóbbiról szintén e-mail értesítést küldünk, mert a legtöbben bele se néznek a tárhelyükön lévő error_log fájlba.
Biztonságos Domain Regisztráció
Javítva
Mivel nem értek a drupalhoz marad a nagy G. Az ott talált információkból próbáltam összerakni egy cikket. Miután készen lett írtam, hogy Ti akik értetek hozzá javítsátok, egészítsétek ki. Kérdéseket ne tegyél fel, mert nem tudok rá válaszolni :)
A kivonat:
Biztonságos Domain Regisztráció
"Mivel nem értek a drupalhoz
"Mivel nem értek a drupalhoz marad a nagy G"
aztán nevergone-nak azt írod:
"Az, hogy mi a drupal nem célom megítélni, de a cikkben nem javítom, mert így gondolom. Ti vitatkozzatok rajta, ha akartok :)"
Ha nem értesz hozzá, miért akarod megmondani róla a frankót? Ha már véleményt kértél, hallgass a tanácsokra. Ne jelents ki valamit, aminek a hátterével egyáltalán nem vagy tisztában.
Ha meg a Google segítségével talált dolgokra hivatkozol, és még forrást sem mutatsz, nehogy már hivatalosnak tüntess fel bármilyen információt, főleg olyat ne, ami nyilvánvaló, hogy NEM AZ. Hiszen éppen te magad mondtad: "Mivel nem értek a drupalhoz marad a nagy G"... A net tele van baromságokat tartalmazó cikkekkel, magukat hozzáértőnek képzelő emberkék tollából. Ne hagyd, hogy a Te oldalad is baromságokat tartalmazzon, teljes magabiztossággal állítva téves információkat.
Ez még mindig nem jó. Nem "megváltoztatni" tudja, mivel az elején MEG KELL ADNI a felhasználónevet (mi legyen a főadmin felhasználóneve??), meg jelszót, tehát legfeljebb valaki szándékosan ADJA MEG ezt a felhasználónevet. Nem megváltoztatja adminról valami másra, mert nincs megadva a főadmin neve, nincs default, mint mondtam.
"Az esetek 50% -ban ezzel a felhasználónévvel törik fel a Drupal oldalt."
Milyen statisztika alapján? Ezt is a nagy G mondta? Korábban itt a PrestaShop szerepelt, valaki szólt is, hogy ezt javítsd már, tehát azt egyszerűen csak átírtad Drupalra, és minden rendben, biztos arra is igaz?
Még egyébként olyan szabály is van, hogy ugyan lehet pénzért árusítani modult, de hagyni kell, hogy valaki azt módosítsa, újraértékesítse - tehát akár ingyen is megoszthatja. Hogy legalább én hivatkozzak hivatalos információra: http://drupal.org/licensing/faq/#q9 .
Eleinte tök szimpatikus volt, hogy szolgáltatóként próbáltok minél helyesebb és teljesebb információkkal szolgálni a felhasználók számára, de most már úgy tűnik, hogy ragaszkodsz a saját véleményedhez, meg ahhoz, amit "a nagy G mondott". Ez már kevésbé jó hozzáállás, ha már ennyien szánták az idejüket arra, hogy korrigálják az oldalatokon szereplő állításokat.
Ahogy elnézem, amúgy sem sok mindent javítottál azok közül, amiket javasoltunk.
nem vitatkozok
Köszönöm hosszú soraidat. Nyilvánvalóvá vált, hogy konfliktuskereső típus vagy, azonban én nem fogom kielégíteni a vágyaidat. Inkább elhajolok :)
Sajnálom, inkább kötekedésnek tűnik a hozzászólásod, mint értékteremtőnek. Miből gondolom? Nem adsz megoldást, csak problémákat vetsz fel.
UI.: A zend nem obfuszkál, hanem titkosít :)
Biztonságos Domain Regisztráció
nem lerohanás, hanem segítség, javaslat!
Sajnálom, ha úgy tűnt, hogy konfliktuskeresés volt a célja a hozzászólásomnak, pedig nagyon nem ezért írtam ennyit. Bocs, ha a stílus esetleg támadó volt, nem ez volt a cél, hanem pusztán szakmai vita. Azért sejtheted, hogy nem rossz szándékból szántam ennyi időt a probléma megvitatására... :) Kicsit félreértelmezted a szándékot (vagy csak valamiért nem szeretted volna elfogadni az ellenérveket).
Azt írod, nem adtam "megoldást", pedig épp azt próbáltam kifejteni, mi a baj a megnevezett pontokkal, mit kellene rajtuk korrigálni. Próbáld meg nem negatívan hozzáállva is elolvasni a tanácsokat. :)
A másik oldalról meg úgy tűnik, nem hajlasz egy ponton túl a segítség elfogadására. Kikérted a véleményünket a cikkedről, én is leírtam a sajátomat, lehet, hogy nyersen fogalmaztam, és ez számodra sértőnek tűnt, de a segítő szándék vezérelt. Szerintem a cikkben pár említett helytelen pont megváltoztatását még egyszer megfontolhatnád.
Javítva
Köszönöm az észrevételeket. Javítottam a cikket :)
Biztonságos Domain Regisztráció
A 11. pontban van jó néhány
A 11. pontban van jó néhány helyesírási hiba, illetve a kezdő mondat elég félrevezető értelmű: "A drupla oldalak sajnos ki vannak téve a spam támadásoknak..."
Helyette talán: "Minden weboldal ki van téve a spam támodásoknak..."
...mit tudok: http://web.termuves.hu