Fórumok
Sziasztok,
az egyik ügyfelem weboldalát állandóan feltörik, azaz bemásolnak egy scriptet és onnan spammalnek, ami miatt ügyfeleim blacklistára kerülnek.
Már minden jelszót megváltoztattam, frissítettem a drupalt (mindenből a legújabb modul van fenn), de mégis valahogy bejut az a script.
Kérdés:
Létezik-e olyan program Ubuntu-ra, ami figyelné egy mappát, s ha felmásolnak egy fájlt, akkor küldjön egy mailt nekem?
Esetleg a clam (vagy akármelyik) víruskeresőt be lehet állítani úgy, hogy "állandóan" figyeljen egy-egy mappát?
Köszönöm, ha válaszoltok.
Hozzászólások
Ehhez nem kell víruskereső. inotify.
Erről az inotify-ról nem sok mindent ad ki (főleg magyarul) a Google. Írnál két mondatot erről? Telepít-beállít-használ?
Két párhuzamos terminál eredményét kopizom ide:
[code]
term1 $>cd /tmp
term1 $>mkdir inotify-test
term1 $>cd inotify-test/
term2 #>while : ; do inotifywait --format '%f: %e' /tmp/inotify-test; done
Setting up watches.
Watches established.
term1 $>touch file1
term1 $>touch file1
term1 $>date > file1
term1 $>rm file1
(term2)
file1: CREATE
Setting up watches.
Watches established.
file1: OPEN
Setting up watches.
Watches established.
file1: MODIFY
Setting up watches.
Watches established.
file1: DELETE
Setting up watches.
Watches established.
[code/]
De ha mégsem zavar egy kicsi angol: https://github.com/rvoicilas/inotify-tools/wiki
(Egyébként amikor odaszületik a szkript, nem törölném, hanem felülírnám olyan mennyiségű random adatot küldő kóddal, ami a gépemet nem zavarja, de a hívatlan vendégre hosszú távon jó pedagógiai hatással bír.)
+1
A feltett kerdesre a megoldas inotify de talan http://iwatch.sourceforge.net/documentation.html -al konnyebben boldogulsz, de a leirt problemara pedig rosz a kerdes.
Mod_php-t vagy mod_fastcgi/mod_fcgi-t hasznalsz?
Lehetseges, hogy mas feltort/bug-os site alol torik fel ezt a site-ot? Esetleg valamelyik (virusos) kliensrol tudjak meg a jelszot rendszeresen?
Malware + virusok ellen: maldet + clamav
---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
Igen, sajnos az lehetséges, hogy nem mindegyik site biztonságos. (frissítenem kell az összes drupalos oldalt).
Csak néhány ügyfelemnek van (kért) FTP hozzáférést.
Igen, azt hiszem hogy így hívják ezt a levélküldő scriptet, hogy malware.
Erről a párosról írnál néhány szót: maldet + clamav. Hogy hogyan kell összehozni őket? (clamav van a szerveren)
Elnézést a konyhanyelvi megfogalmazásért, de annyira nem értek hozzá.
A malware az egy kategoria, magyarul kb. rosszindulatu program(ok)nak fordithato.
1. frissits minden oldalt (ne csak a drupalt, mas CMS-eket is ha vannak)
2. osszes FTP jelszo lecserelese, aki ftp-t hasznal ott megkerni oket, hogy legalabb arra a gepre tegyenek viruskeresot ahonnan hasznaljak a szervert (az FTP egy szukseges rossz)
3. clamav futtatasa cron-bol naponta az osszes site-on (sajnos nem sok malware-t tud megfogni)
4. maldet telepitese, meg kell neki mondani merre keresgeljen, naponta fut alap telepitessel (ez joval tobb malware-t ismer, de bejelez nem virusos allomanyokra is)
5. tobbek altal hasznalt szerveren a mod_php lecserelese mod_fcgi-re (vagy hasonlora, mod_fastcgi, stb.) es minden site kulon user neveben fusson, igy ha egy site-ot feltornek akkor csak az lesz feltorve, a tobbit nem veszelyeztetik
6. Google a baratod a fentiekkel kapcsolatban :)
---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
Köszönöm a részletes tanácsot.
Végigmegyek rajtuk. :)
esetleg ha megoldhato akkor az adott mappaba egy kulon particiot mountolsz noexec-kel, vagy symlinkeled egy olyan particiora, amit noexec-kel mountolsz.
A noexec-el mount-olt particionak szerintem nem lesz semmi hatasa php scriptekre...
---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
php-scriptre teny, hogy nincs hatassal
Hali!
Mindig ugyanabba a mappába teszik a skriptet? Esetleg megoldás lehet, ha letiltod az oda kerülő állományok futtatását...
pl. images mappákban alkalmazható lehet a megoldás.
Bérces Miklós
A futtatas letiltasa itt sem segit, ez csak egy ertelmezett script (feltetelezem, hogy mod_php-t hasznal).
---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
Sajnos nem. Mindig egy weboldal mappájában találom csak, de változó, hogy melyik almappában.
Ideiglenes megoldasnak jo, ha orankent (esetleg gyakrabban) futtatsz egy "grep akarmi *.php | mail email-cimem"-t az adott site gyokereben ahol "akarmi" egy a scriptben megtalalhato (feltehetoen nem valtozo) string. Igy amig nem foltozod be a lyukat ahol bejottek ki tudod irtani a feltoltott scriptet.
---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
Feltelepítettem a maldet-et. Köszönöm a tippet. Futtattam, s a jelentést elolvastam.
S ez alapján kijött, hogy egy másik ügyfelem régi weboldalát is felörhették. (php + spaw2-vel lett készítve még vagy 5 éve)
S a spaw2 mappában láttam ilyet, hogy Injekt meg INJECTION alpmappák s abban php fájlokat. Valószínű, hogy innen elérték az összes többit.
Amúgy a clamav simán figyelmen kívűl hagyta ezt spaw2 mappát.
Hatalmas -1 az egész threadre.
Adott egy szerver, ami rommá van törve, ki-be járkálnak a támadók, tele van nyomva malware-re, stb. Ezt inkább be kéne szántani, nem inotify-jal figyelni, hogy na, vajon ma törik meg újra a gépet, vagy csak holnap.
Reszben egyetertek, de a te javaslatod nem jarhato ut a kerdezonek a problema azonnali kezelesere, a kesobbiekben viszont ajanlott.
A kerdezo nem ert hozza elegge, ha utanaolvas az ujratelepites utan egy jobb rendszere lesz es tanulni fog vele.
Ha csak siman ujrahuzza a gepet a jelenlegi tudasaval akkor 2 napon belul ujra ott a virus/malware.
Masreszt nem tudjuk, hogy hasznaltak-e valamilyen exploit-ot es ezek utan kerult-e a szerverre rootkit. Ha csak a webszerver jogaival tenykedtek a script kiddie-k azt siman helyre lehet hozni ujratelepites nelkul.
---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
A gép kb 2 éve lett felépítve debiannal. Nem én csináltam, hanem - s ez késöbb derült ki -, hogy egy kókler. Kb 50 weboldal van rajta, így az, hogy dobjuk ki a kukába az egészet őket is érintené. Nem egyszerű eset lenne.
Viszont érdekel a dolog, és szeretnék is tanulni.
A maldet megmutatta, hogy melyik oldalakon keresztűl jöhettek be. Azokat javítottam, s megváltoztattam a jelszavukat.
Azt, hogy rootként jelentkeztek volna-e be... nem tudom. Remélem, hogy nem.
/ Már azon is gondolkoztam, hogy keresek valakit aki ért a hekkerkedéshez, hogy próbálja feltörni s adjon tanácsot, hogy mit csináljak. /
Egyszer örököltem én is egy hasonló szervert és -nem akarlak elkeseríteni- minden hasonló megoldás csak ideiglenes volt. Az elb@szott munkaóra ezekre a végén több lett, mint egy komplett migrálás. Tény viszont, hogy ott magát a szervert zúzták meg.
Ha te is a migrálást választod, akkor célszerű egy frissen telepített vasra áttolni az egészet. (A régi addig marad) Ha beállítottál mindent (webszerver, levelezés,etc.), akkor leállítod a régit, tisztítod, majd cp-vel áttolsz mindent a www alól. Utána indítod az újat. Persze ha tényleg csak a www-t zúzzák (régi cms bugokon keresztül), akkor ez nem fog segíteni.
Nálam is volt hasonló (ezeréves e107) két felszólítás ment a júzernak (kb. mint a falra hányt borsó), aztán jegeltem a domaint, akkor mondjuk rögtön megtalálta a válasz gombot a levelezőjébe... :)
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
+1111111111111
--
PtY - www.onlinedemo.hu, www.westeros.hu
- Letiltani a verbe a php-n keresztuli levelezest?
- auth smtp-t hasznalni?
- spoofing controlt bekapcsolni ? (Mindenki csak sajat accountrol kuldhet nincs olyan hogy gipsz jakab account-al gipsz fruzsi neveben kuldenek levelet ( ez meg elment 10 evvel ezelott de mar 2015 van ))
Off: szokás az ilyen rendszerekben különválasztani a PHP-kódot az adatoktól? Azt gondolnám, hogy célszerű lenne a 'www-data' user számára írhatatlan fájlokban és könyvtárakban tartani a kódot, de lehet, hogy a való világ nem így működik...
Célszerű lenne, de amióta megjelentek ezek a PHP-s CMS szarok, azóta sajnos a trend az, hogy az r=1bit CMS-admin szeretné webfelületről frissítani a szarát. Ami tökéletesen ellentmondásban van azzal, hogy a PHP ne tudja átírni a PHP kódot. És némelyik CMS egészen odáig vetemedett, hogy konkrétan feltelepíteni sem tudod, ha nem adsz neki írásjogot a saját könyvtárára! Egész egyszerűen nincs ledokumentálva, hogy hogyan lehet command-line-ból full feltelepíteni, hogyan lehet pl. modult hozzáadni.
Na ezeket nyugodtan be lehetne szántani a francba, mert architekturálisan vannak elbaszva...
Köszi a választ! (Ezek szerint túl optimista voltam, amikor azzal áltattam magam, hogy 'á, csak nem hagynak ekkora biztonsági lyukat').
Nézd, a PHP nem a biztonságról szól. Akik kitalálták, azok a programnyelv íráshoz sem értettek, a biztonságot meg még fogalmilag sem ismerték... lásd register_globals. Szerintem PHP hosting környezetet üzemeltetni kb. a reménytelen vállalkozás biztonsági szempontból.
"register_globals"
"This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0."
Haladni kell a korral :)
+1
Nagyon igaz.
+1
(Nemrég azt hittem, feltaláltam a spanyolviaszt: drupal X jogán acl alapon, drush Y jogán posix jogokkal írhat. Csakhogy drupal drágának nagyon nem tetszik, hogy posix alapon nincs tulajdonjoga egyes könyvtárakra, úgyhogy hagytam a francba az egészet.)
a webrol frissites teljesen jo, ha az megfeleloen mukodik.
--
"Van olyan ember sok az oldalon, akinek a kommentjeinek 100%-a zaj, oket miert nem kommentelitek ilyen lelkesen?" (hrgy84)
De nem működik rendesen. A PHP biztonsági megoldásai kb. garantálják, hogy amíg világ a világ, ez folyamatos problémagóc legyen.
mondjuk python vagy perl eseten ez mennyiben mehetne maskent?
--
"Van olyan ember sok az oldalon, akinek a kommentjeinek 100%-a zaj, oket miert nem kommentelitek ilyen lelkesen?" (hrgy84)
Nagy különbség nincs a koncepciójuk között (parse-olt nyelvek, vm nélkül).
Na, mégegy Java fan...
Mesélj a Java biztonsági koncepciójáról please. Minden applet futása előtt 20 quízkérdés személyre szabottan? 40 kattintással elérhető konfigtoolban fehérlista kezelés kattintásonkénti konfirmációval?
Emberbarát. :)
--
PtY - www.onlinedemo.hu, www.westeros.hu
Milyen PHP biztonsági megoldás miatt probléma ez? Nekem nagyon nem úgy tűnik, hogy a probléma php specifikus lenne, de világosíts fel.
Teljesen igazad van. A baj csak az, hogy erre van igény, és ráadásul maga az igény érthető és elfogadható - főleg azóta, hogy instant VPS-t lehet venni 2 kattintással. Ezt az igényt pedig ki kell elégíteni, és a fejlesztőknek nem csak arra kéne ügyelni, hogy maga a kibocsátott kód az adott pillanatban a lehető legbiztonságosabb legyen, hanem arra is, hogy az esetleges sechole-okra minél előbb legyen patch.
Amúgy pont nem azt tartom nagyobb hibának, hogy egy cms webről frissíthető, hanem azt, ha ennek ellenére a tulaj szarik rá, és nem frissíti. Az esetek 90%-ában ezen múlik, hogy egy oldalt feltörnek-e, vagy sem.
Amúgy le van dokumentálva, hogy mit hogyan lehet frissíteni (joomla esetén biztos) CL-ból. Van egy SQL patch, az app meg felülírandó. Főverzió váltása esetén meg szokott lenni egy howto, ha valami ennél bonyolultabb.
--
PtY - www.onlinedemo.hu, www.westeros.hu
akkor meg azert sirnak, mert nem tudnak ftp-vel feltolteni/torolni a www-data user lektrehozta konyvtarakba. Szoval sok egymasnak ellentmondo conflict kozott kell egyensulyozni...
--
"Van olyan ember sok az oldalon, akinek a kommentjeinek 100%-a zaj, oket miert nem kommentelitek ilyen lelkesen?" (hrgy84)
Kivételesen +1.
Bár FTP-t soha nem adnék (chrootolt sftp az jóság), ha valaki annyira CL-ban akar bűvészkedni, miért gáz írni egy scriptet, ami a cache/temp mappákon kívül mindent root jogra ír át, és vissza, ha épp frissíteni kell?
Macera? Ja, a webről frissítés is egy macera elkerülő megoldás.
A lusta üzemeltető panaszkodik, hogy a user lusta, és emiatt van sechole, ami meg csak akkor igaz, ha mindkettő egyszerre lusta. :)
--
PtY - www.onlinedemo.hu, www.westeros.hu
Tanácsból sosem fogyunk ki :)
Logold az ftp file műveleteket.
olyan is van, hogy nem maga a cms a szar, hanem a hozza irt, 3rd party modulok kozott van a hunyo...
--
"Van olyan ember sok az oldalon, akinek a kommentjeinek 100%-a zaj, oket miert nem kommentelitek ilyen lelkesen?" (hrgy84)
Akkor is a CMS-ek architektúrája a szar: mert ugyanazokkal a jogosultságokkal megy az egész.
mar megis milyen mas jogosultsagokkal mehetne, mint amit a rendszergazdak beallitottak az adott site-ra?
--
"Van olyan ember sok az oldalon, akinek a kommentjeinek 100%-a zaj, oket miert nem kommentelitek ilyen lelkesen?" (hrgy84)
Hát mondjuk mehetne az egyik fele írási jogosultságokkal, a másik fele meg read-onlyként. Tudod, oda rakja az ember a megbízhatatlan random modulokat. Sőt, ez utóbbiakat lehetne valami értelmes subsetre korlátozni API tekintetében.
ertjuk a problemat? Van egy alkalmazas, amit kompletten felul kell irni a frissites soran...
--
"Van olyan ember sok az oldalon, akinek a kommentjeinek 100%-a zaj, oket miert nem kommentelitek ilyen lelkesen?" (hrgy84)
Húsvéti offolás sonkával és tojással:
- Ha van ssh hozzáférés, a root belépést tiltani, más portra tenni.
- Nem derült ki, hogy annak a usernek van-e ftp hozzáférése, akit mindig feltörnek, de ha igen, akkor megkérni, hogy a TC-ben ne tárolja az ftp jelszót :) (de ez igaz minden ftp userre)
- fail2ban-t (vagy ilyesmit) felrakni (ha nincs), és szigorúbban bekorlátozni (pld. ssh esetén max. 2 próbálkozás, utána 6 óra pihi, meg ilyesmi) A fail2ban noscript logok (is) ráadásul elég beszédesek tudnak lenni, hogy éppen milyen módon próbálkoznak betörni.
- ha van phpmyadmin, akkor azt elrakni valami "vad" helyre
- ha konkrétan egy bizonyos állomány kerül fel mindig, akkor létrehozni egy ugyanolyan nevűt ártalmatlan tartalommal minden könyvtárba, és letiltani a világ számára a hozzáférést :)
Tudom ezek a tippek sokak szerint csak "halottnak a csók" hatásúak, ráadásul nem is az eredeti kérdésre válaszok. Valamint ha maga a szerver van rommá törve, akkor tényleg semmit sem érnek.
Ne kattints ide!