Feltört oldalak, spammelés figyelése webszerveren

Szerverek

Sziasztok,

létezik olyan megoldás, amely figyelné azt, ha feltörték valamelyik oldalam, s elkezd spammelni a debian alapú webszerverem?

Az van, hogy üzemeltetek egy ilyen szervert, van rajta kb 30 drupal oldal. S néha napján előfordul, hogy email blacklistára kerül a gép, merthogy elkezdtek rajta spammelni. Azaz feltörnek egy régebbi oldalamat, s spammelő scripteket töltenek fel valahogy.

Ilyenkor végignézem a clamscannal az oldalakat (kb 7 óra) mire kiderül, hogy melyik oldalt törték fel.
Ezután jön a manuális megoldás: letisztítás, visszaállítás a korábbi mentésből, biztonsági foltozgatás s kézzel leszedegetni a listákról a szervert.

Erre keresek valamilyen figyelmeztető/riasztó megoldást. Ilyenek jutottak eszembe:

- jó lenne valamilyen olyan program(?), amely figyeli, ha php-html fájlokat érkeznek a public_html mappákba, s azonnal figyelmeztető emailt küldene nekem.
- A qshape deferred parancsra rengeteg emailt ír ki olyan esetben, ha spammel a gépem. Azt nem lehet figyeltetni valahogy?
- Mindennap biztonsági másolatotat készítek az oldalakról (persze ezeket előzőleg 7 napra elmentem) rsynckel a saját asztali gépemre ezzel a paranccsal:
rsync -avz --delete -e "ssh -pPORTSZÁM" root@SZERVERNÉV:/home/vhosts/ /media/307gb/vhosts/
Esetleg ez az rsync is 'szólhatna' ha php, html fájlokkal találkozik, ami még tegnap nem volt ott.

----
Elnézést a pongyola, konyhanyelvi megfogalmazásért. Sajnos nem nagyon értek hozzá.
Kérem, hogy a lenéző, s a "na az ilyen kóklerek miatt spammelnek" és hanonló stílusú tanácsokat mellőzzük.

Minden más ötletnek örülök.

  • 4520 megtekintés

( meridian v | 2016. 12. 04., v – 21:10 )

tiltsd le a mail() parancsot, használjon mindenki smtp-t s akkor azonnal látod ki küldözget...

Azt nem letiltani kell, mert csillió szoftver csak azt tudja használni, hanem a /usr/sbin/sendmail-t kell lecserélni egy naplózó/kvótázó/riasztó replacementre. Ez a téma rendszeresen előkerül itt, kb. 1-2 hónapja is volt erről hosszabb diskurzus. (Írd be a keresőbe, hogy sendmail wrapper)

( _ventura_ v | 2016. 12. 04., v – 21:10 )

Nálunk eleve van postfwd, amivel kevés levél küldhető ki. Ha elkezdenek spammelni akkor a mailq, telik erre meg riaszt a nagios.

Fedora 24, Thinkpad x220

Amikor egy anekdota úgy kezdődik, hogy "egy ismerősöm...", elég gyakran bizonyul fiktív személynek az illető :) A másik lehetőség a botcsinálta szakértő, aki visel egy beosztást a szükséges előképzettség nélkül. A harmadik természetesen a félreértés, no meg a tény, miszerint ezzel nem segítünk, csupán olyasvalamin agyalunk, amin felesleges...
------------------------
{0} ok boto
boto ?

( sj | 2016. 12. 04., v – 21:37 )

Esetleg ez az rsync is 'szólhatna' ha php, html fájlokkal találkozik, ami még tegnap nem volt ott.

ezen a ponton tenyleg zokogni lett volna kedvem. De hogy 1-2 hasznos tanacsot is adjak:

- limitalni az idoegyseg alatt kikuldheto levelek szamat (pl. policy demonnal is, ld. a lentebbi postfwd, megoldhato)

- a kimeno leveleket kuldd at spamassassin-on, es ha spam a verdikt, akkor discard

- vhost-onkent definialni egy feladot, es csak azzal mehet ki level a vhost-rol. Ha mas a felado, akkor reject.

- a mail logot figyelni, es a vhost-okra jellemzo mintakat feljegyezni. Ha ettol a mintatol jelentosen elter egy vhost levelezese, akkor letiltani az adott vhost felado cimet (ld. fentebb).

- folyamatosan nezni, hogy fent vagy-e rbl listakon. Ha igen, akkor beavatkozol.

- kicsit vad otlet, de ha egy vhost tartalma nem valtozik surun, akkor megfontolando, hogy read-only lassa a webszerver

( Nyosigomboc v | 2016. 12. 04., v – 22:37 )

Azon a meglevo kb. 30 oldalon van egyebkent igeny mailkuldesre? Mert ha nincs, letilthatod en bloc az egesz funkciot. (akar a mail() oldalon, akar tuzfalon)
Ezeket egyebkent te tartod karban, vagy csak hostolod? Utobbi esetben nem biztos, hogy belenyulhatsz (viszont akkor basztathatod azt, aki csinalta). Elobbi esetben meg frissitsd oket, es akkor nem nyomjak fel ismert sebezhetosegeken keresztul.
Beallithatsz Snortot vagy masik IDS-t, pont erre valo.

--
A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

Igen, van igény mailküldésre. Pl:
- webáruház is üzemel (drupal és commerce) s hát rendelés esetén kapniuk kell emailt mind a rendelőnek mind az üzemeltetőnek
- van egy-két cég aki igényt tart saját domainos emailcímre is, amit aktívan használnak outlookon és webes felületen is (roundcube)

Ez a "snort" és az "IDS" nekem új. Továbbítom a rendszergazdámnak.

( gee v | 2016. 12. 04., v – 23:51 )

Érdekel a téma, mert van egy gépem, amire hamarosan egy php-re épülő oldal kerül, aminek levelet is kell küldenie. Tartok tőle, hogy valamilyen hiba vagy rossz beállítás esetén esetleg fel tudják nyomni. Ilyen esetben nem lenne jó, ha spammelni tudnának.
Az oldalt nem én készítem, de ha itt jó ötleteket olvasok, akkor alkalmazhatom egyiket-másikat.

A gépemen postfix van, és csak submission porton, felhasználónév + jelszó azonosítás után fogad el kifelé menő emailt kézbesítésre. Én eddig arra gondoltam, hogy a php programozó embert megkérem, hogy tárolja el valami konfigurációban az azonosításhoz szükséges adatokat és ahol levelet akar küldeni, nyisson egy kapcsolatot a submission portra.
Plusz a kimenő smtp kapcsolatok mennyiségét limitálni tervezem.

Valaki le tudja írni, hogyan megy php-ból a levél küldés, mik a szokások?
Pl. amit meridian írt, hogy letiltani a mail() parancsot és helyette smtp-t használni, ez mit jelent egyszerűen?

Gyors google kereséssel megnéztem, hogyan működik a mail() parancs. Azt látom, hogy kell használni, de azt nem, hogy mit is csinál a háttérben. Meghívja a sendmail parancsot direktben?

Azt reméltem, ha valami hibán keresztül távolról fel tud tölteni valaki egy php oldalt, és abból akar simán levelet küldeni, akkor majd a felhasználónév + jelszó nélkül ez nem fog menni.
Tipikusan a spam küldéssel hogyan próbálkoznak az ilyen feltöltött vagy módosított oldalak? Meghívják a mail függvényt, és remélik, hogy megy?

( Dyl4n | 2016. 12. 05., h – 00:11 )

Kb 2 hónapja használom ezt:
https://www.rfxn.com/projects/linux-malware-detect/

Eddig bevált, naponta 1x fut és az 1 napos fájlokat szkenneli végig.
Beállítható, hogy szóljon vagy egyből karanténba tegye a gyanús fájlokat.

Elvileg tudna egyéb extrákat is, de még nem volt időm a többi lehetőséget rendesen belőni.
Amúgy nekem segített az, hogy a 25-s portot kifelé tiltom, csak hitelesített user küldhet levelet, a php mailt pedig logolom.

Nekem ez a 2 topik segített sokat:
http://hup.hu/node/122043#comment-1570653
http://hup.hu/node/148730

( xclusiv v | 2016. 12. 05., h – 00:20 )

"Sajnos nem nagyon értek hozzá."

Már bocsánat, de arra esetleg nem gondoltál, hogy ha nem értesz a szerverüzemeltetéshez (a post alapján még alapszinten sem) akkor nem csinálod?

Az egyik haver webfejlesztéssel foglalkozik, ahhoz ért, a szerverüzemeltetéshez nem. Ő webtárhelyet bérel, sose hallottam tőle hogy feltörték volna, szerintem még olcsóbb is mint a hosting / vps téma.

Ez is megvolt, ugye?

"Kérem, hogy a lenéző, s a "na az ilyen kóklerek miatt spammelnek" és hanonló stílusú tanácsokat mellőzzük."

Írta is az illető kommentekben, hogy külön rendszergazdája van. Mondjuk én úgy tudom (lehet rosszul) hogy nem a szerverüzemeltetés miatt törik fel ezeket az oldalakat, hanem a drupal meg a wordpress stb hibái miatt. Persze tény, hogy ellen is lehet (részben?) védekezni szigorúbb szerverbeállításokkal.

Először én is gondoltam, hogy reagálok erre a "ha nem értesz hozzá, miért csinálod" tipusú üzenetre, de nem szerettem volna ha elmegy a témáról fókusz.
---

Én is azt vettem észre, hogy ha spammelnek, akkor mindig találok valamilyen feltört, nem frissített oldalt.

A kérés dacára mégsem biztos, hogy jó "másfelé nézni"; a problémát én nem ott látom, hogy a kérdező maga járatlan a témában - sokkal inkább ott, hogy valószínűsíthetőleg a "rendszergazdája" sem. Amíg pedig ezt nem ismeri fel, hogy kellő súlyú kockázatként kezelhesse, jó eséllyel nem fog valóban megoldódni a problémája.
------------------------
{0} ok boto
boto ?

"Írta is az illető kommentekben, hogy külön rendszergazdája van"

Most már látom, tegnap amikor a kommentet írtam még nem láttam ilyet. A topicindítóban viszont még ma is E/1-es mondatok vannak: "üzemeltetek egy ilyen szervert", "végignézem a clamscannal az oldalakat", ilyenek,

De TFH van egy rendszergazdája, és a rendszergazda (és nem a fejlesztő) hibája miatt törik fel rendszeresen, aztán szétspammeli a világot. Aztán nem az történik, hogy:
a, megrépázza a rendszergazdát h végezze normálisan a munkáját
b, kirúgja a rendszergazdát és felvesz/megbíz helyette valakit aki képes ellátni a feladatot
c, keres egy szolgáltatót aki képes up2date drupal-t alátenni a vackainak
d, megállapítja hogy senkiháziak kezében van a popszakma és a spam-ek/vírusok visszatérő terjesztése helyett választ inkább egy másik szakmát.

Nem, nem ez történik, hanem a _webfejlesztő_ kezd el egy fórumon tanácsokat kérni és amit kap azt továbbítja a rendszergazdához. Egészen hihetően hangzik...

Legalább az IP címét (címeit) megoszthatná hogy tilthassam mindenhol...

( ang | 2016. 12. 05., h – 08:30 )

auditd ?

http://php.net/manual/en/mail.configuration.php ?

mail.add_x_header bool
Add X-PHP-Originating-Script that will include UID of the script followed by the filename.

mail.log string
The path to a log file that will log all mail() calls. Log entries include the full path of the script, line number, To address and headers.

( gelei v | 2016. 12. 05., h – 14:01 )

> néha napján előfordul
> Sajnos nem nagyon értek hozzá.
vs
> Kérem, hogy a lenéző, s a "na az ilyen kóklerek miatt spammelnek" és hanonló stílusú tanácsokat mellőzzük.

Én sem értek hozzá. Ez nem szégyen. Az viszont igen, ha ennek tudatában sem keresel jobb megoldást.

( Swifty v | 2016. 12. 05., h – 14:01 )

Igazán nem megoldást ajánlok, mármint nem a figyelést, hanem inkább egy prevenciós eszközt:

chattr

És ennek főleg ezt a részét:

"A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute."

--
Debian Linux rulez... :D
RIP Ian Murdock

Nem rossz, ezt én sem ismertem, köszi. Itt sok mindenre viszont nem jó, mert jellemzően nem fájlokat módosít, hanem mappába helyez el sunyi fájlokat. Template és hasonló mappa védelmekre jó, de ha upload mappába helyezi el, akkor sajnos nem tudod letíltani.

@többieknek: az a tapasztalat, hogy a monitoring felületes megoldás, Védelemnek semmiképp sem nevezhető, mert mire reagál az ember, már kiment pár ezer spam, ami elég egy spam listára kerüléshez.
Szóval hard quota kell (esetleg adaptív) + figyelmeztetés ha elérte a user.

"nem fájlokat módosít, hanem mappába helyez el sunyi fájlokat."

A chattr +i használható könyvtárakon is, ezzel megelőzve az új fájlok létrehozását.

"ha upload mappába helyezi el"

A webszervert úgy kell konfigurálni, hogy az upload mappa tartalmát csak statikusan szolgálja ki, ne lehessen futtatni az oda rakott php-ket.

Azért vannak lehetőségek bőven. A mail() függvény már manapság tiltható és lehet auth only smtp, a normális CMS-ek már régen támogatják és aki meg komolyan gondolja az beizzítja a phpmailert. Ezen felül felrakható néhány globális és néhány per site szabály is, a topikindításban lévő Drupal esetén a /sites/*/files/*.php, a WordPress-nél (ha jól emlékszem) a wp-content/uploads/*.php tiltható per oldal vagy akár globálisan is. Aztán biztosan van olyan ámokfutó, aki mindenképp onnan akar php-t futtatni, ne akarjon. Lehet még mod_security-t vagy más hasonló védelmet is feltenni, de a folyamatosan frissítést nem lehet igazán kiváltani.

Mar az elso lekapcsolas es figyelmeztetes utan kattannak a fogaskerekek es frissitenek. Raadasul neha kapnak csak ugy is figyelemfelhivast. A renitensek pedig lelepnek, mert mit kepzelek. A lelepesben csak az szomoru, hogy mindig talalnak egy helyet, ahol elturik vagy rosszabb esetben nem
is foglalkoznak vele.

( csardij v | 2016. 12. 05., h – 14:29 )

CSF + LFD tudja figyelni az emaileket is, és értesítést küldeni, de akár nagiosból is fel tudsz állítani szabályokat. Valamint a Sitelock szolgáltatási lehetnek jók neked.

( hokuszpk | 2016. 12. 06., k – 18:39 )

php ini -ben a sendmail_path megvaltoztatsa :

sendmail_path = /usr/sbin/sendmail -t -i -f sajatemailcim

ha hirtelen teli lesz a postafiokod visszapattanoval tutti eszreveszed.