levelek limitalasa

Spam, Adathalászat

Mostanaban ismet beindult a 'ha nincs eleg penzed, tanulj meg keresni' levelszemet hullam, es (amugy egeszen mas miatt) arra gondoltam, kene egy cucc, amivel limitalni lehet a levelek szamat.

Konkretan arrol lenne szo, hogy adott egy webszerver, amin potencialisan bugos alkalmazasok vannak, amelyeket megpatkolva a spammerek egy csomo spamet tolhatnak ki. Ez persze faj, mert a webszerveren levo egyeb site-ok levelezese is a karat lathatja ennek.

Ezt a kart kellene valahogy csokkenteni. A kerdes pedig az, te hogy csokkented kart / eliminalod a problemat?

  • 13482 megtekintés

( mauzi v | 2013. 02. 14., cs – 12:35 )

1.) levélküldés kifelé csak a helyi, authentikációval rendelkező SMTP szerveren keresztül. (minden más tűzfalon bezárva)
2.) SMTP szerverbe per-júzer napi limit beállítása

ez jol hangzik, csak 1 aprosag miatt nem kivitelezheto egy webszerver eseten: egy csomo user mar hasznalja a mail() fuggvenyt, ami nem feltetlen tamogatja az smtp auth-ot, ill. meg ha meg is tudna mondani a user, hogy kedves mail() fuggveny ezzel az account-tal kuldd ki a levelet, az sem eleg jo, mert a usernek modositani kell a php scriptjet, es 98%-ban ez problema ilyen-olyan okok miatt...

Diktatorok kezikonyve

Nyilvan sarkitottam, nem akartam egy ertelmetlen vitaba belevinni a kerdest.

Az a tapasztalat amugy, hogy a szamok messze nem ilyen komorak. A userek olyan 70-80%-a valami elore megirt frameworkot hasznal, amibe viszonylag egyszeruen beleszerkesztheto a PHPMailer tamogatas (ertsd: van hozza keszen letoltheto, harom kattintassal installalhato plugin), a maradek pedig ugyan maga irja az alkalmazas kodjat, de ha adsz neki egy peldakodot, akkor meg tudja oldani a kerdest. Van az az elenyeszo kisebbseg, akiknel a fejleszto el lett ragozva mult idoben, de meg itt is ket ut all a megoldasra:
- SMTP kepes sendmail provider (msmtp), SMTP FROM mezo kitoltve -> rate limit
- Csinalsz nekik egy bortont (chroot, jail, vm, szabadon valasztott), es bezsuppolod oket, spammeljek szet egymas fejet.

Azt mar nem is akarom nagyon feszegetni, hogy az internet tele van a mail fuggvennyel kompatibilis PHPMailer wrapper fuggvenyek kodjaival.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( rts | 2013. 02. 14., cs – 13:16 )

1: A második fele jó, de miért kellene autentikálni egy webszerveren ha localhoston keresztül küldök?
2: feltételezve, hogy nem mindenki www-data@* -val küldi a levelet

\o\ |o| /o/

Én is ezt az authentikációt javasoltam volna, pont azért, hogy a legegyszerűbb PHP mail() függvény minden szinten ki legyen iktatva a sima sendmail-el együtt - ez szerintem az ilyen webszerverekről indított spam-elések ~70-80%-át ellehetetleníti bármiféle peruser limit nélkül is.
A rendeltetésszerű mail-ek kiküldésére pedig adottak az authentikált SMTP-t használó függvények (akár pl. php-ban programoz valaki maga, akár Joomla-t, Drupal-t, vagy egyéb elterjedt motorral épít weboldalt magának)

Itt akkor különböztessük meg a feltört (zombi) weboldalakról idegen kóddal kiküldött emaileket és a programozó hibájából adódóan a saját kóddal idegen címre küldött emaileket. Előbbi ellen tényleg védhet az autentikáció, feltéve, hogy a hack közben nem viszik el az smtp jelszót is.

\o\ |o| /o/

( Proci85 v | 2013. 02. 14., cs – 15:16 )

PHP-ból csak belső SMTP-n lehet levelet küldeni. Közvetlen kifelé még phpmailerrel sem. Tűzfalon csak a postfix UID-ja van engedve a 25-ös portra.
+
Nekem van egy netes + saját fejlesztésű kombóm ami a következőt teszi:
PHP mail() -> sendmail előtt egy wrapper fogadja a leveleket, megnézi, hogy adott vuID-val adott időszakban hány levelet küldtek. Ha még benne van a limitben, akkor átadja a sendmailnek kiküldésre, ha nem, elutasítja.
SQL-ben vuID-ra lebontva kvótát lehet adni, ha nem talál kvótát, akkor a default értéket olvassa ki.

vuID= virtuális user azonosító, mivel minden weboldal külön azonosítóval fut.

Azt kell mondjam, gyönyörűen működik :)

Irányadó cikkek:
http://rackerbox.com/wiki/index.php/PHP_sendmail_wrapper
http://www.iezzi.ch/archives/217

jelenleg egy olyan policy daemon-on (postfix/exim-hez) dolgozom, ami szinten szamolja mail from (=envelope from) alapjan a leveleket, es egy limit folott discard-olja a cuccot.

Annyiban jobb (lehet), hogy nem kell minden egyes web szerveren nyilvantartani a user/limit adatokat, hanem eleg csak az smtp szerveren. (Nagy?) hatranya, hogy a user nem kap ertesitest arrol, ha eldobom a levelet. Mondjuk egy jol belott kvotanal ez valoszinuleg nem erint sok usert.

Max azokat a kis ugyeseket, akik egy webszervert hasznalnak hirlevel (sic!) kikuldesre...

Diktatorok kezikonyve

Ez a vonal majd engem is érdekelne. Eredetileg ezen szerettem volna elindulni, de az előzöhöz képest nagyobb falatnak tűnt + nem láttam annyira létjogosultságát.
A te megoldásod már a vírussal lefertőzött gépeket is kiszűrni, ahol outlookban el van mentve az smtp auth. Ez a ptenciális veszélyforrás nálam még nem merült fel, így nem akartam túlbonyolítani :)

annyi megkotes azert van a dologban, hogy az envelope from-nak fixnek kell lennie. De en csak a sendmail binarist adom, hogy a mail() fv boldog legyen (az fsockopen es baratai, amivel kozvetlenul 25-os portra lehetne tolni a szemetet, le vannak tiltva). A php safe mode pedig abban segit, hogy az envelope from-ot ne ne lessen spoof-olni.

A jelenlegi verzio*: http://pastebin.com/32MBcTyY

*: a postgrey-bol indultam el, es trimmeltem meg, ill. modositottam, ahol kellett ;-)

Diktatorok kezikonyve

Köszönöm!

Most értem oda, hogy ráfeküdjek. Reggel óta csavargatom a témában fellelhető serviceket.

A tiéddel kezdtem, de nem sikerült beröffenteni. Szerintem valami felett elsiklottam, mert ezt írja:
# ./sj.pl --inet 500
2013/09/17-14:10:30 postgate (type Net::Server::Multiplex) starting! pid(32063)
Binding to TCP port 500 on host localhost
Setting gid to "1001 1001"
Setting uid to "1001"
DBI connect('database=/var/spool/postfix/postgate/postgate.sdb','',...) failed: unable to open database file at ./sj.pl line 383
cannot open database: /var/spool/postfix/postgate/postgate.sdb at ./sj.pl line 383.

A sdb pedig létezik. Nem tudom kell-e bele valami tábla séma, mert a forráskód alapján úgy látom, ha nem létezik, létrehozza.

No mind1, nézelődtem és ezt találtam: https://github.com/bejelith/send_rate_policyd

Jónak tűnik. Egyszerűbb, rövidebb kód. Egyelőre ebbe mélyedtem bele.
Azért a tiédre is kíváncsi lennék majd.

Igen.
/var/spool/postfix/postgate# ls -la
összesen 12
drwxr-xr-x 2 postgate postgate 4096 szept 17 14.10 .
drwxr-xr-x 21 root root 4096 szept 17 08.02 ..
-rw------- 1 postgate postgate 0 szept 17 14.10 postgate.lock
-rw------- 1 postgate postgate 2048 szept 17 08.16 postgate.sdb

A lock létrejön, de a progi nem fut és a fenti hibával kilép. Ha a lockot törlöm, szintén.
A postgate.sdb elkészítésében van valami trükk vagy elég akár egy touch postgate.sdb is?

ReadThatFineManual :)

A problema egyebkent ott van, hogy a kivalo programirok sajnos nem epitenek rate limitet vagy retryt a kuldesi mechanizmusba, igy inkabb azt kell csinalni, hogy ket kulon Exim instance van, a masodik rate limitel es visszavagja az elso szervernek a queue-jaba a leveleket. Igy nem vesznek el a levelek.

Áá, egy exim szakértő. :) Köszi, a ratelimit az megvolt, de az nem, hogy menet közben hogy lehet dinamikusan módosítani. Régebben system_filterrel próbáltam játszani, de ez manapság már nem divat.
--
#conf t
#int world
#no shut

Csak hangosan gondolkodom: valahogy meg lehet valositani a visszajelzest is, mert a postgrey is intezi valahogy a dolgokat, es ott van visszajelzes SMTP-n, hogy bocs, de nem vettuk at. Kliens oldalrol pedig a PHPMailer tud visszajelzest adni, a mail() nem, de aztat meg le kell tiltani osz'tannyi.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

biztos? A relay valoban jelez(hetne) smtp-n (ha pl. 550-et valaszolna a postgate), igy a webszerveren futo smtp szerver tudna, hogy kaka van. A kerdes mar csak az, hogy mit tud kezdeni ezzel a webszerveren futo smtp szerver, es hogy jut el az info a kuldo alkalmazashoz. Azzal meg ne is torodjunk (most), hogy na es a kuldo alkalmazas kepes-e figyelembe venni ezt az infot?

Szoval eppen ezert vagy dunno vagy discard a postgate valasza a relay-n futo postfix fele.

a PHPMailer tud visszajelzest adni, a mail() nem, de aztat meg le kell tiltani osz'tannyi.

lehet, hogy te megtilthatod, de en nem tehetem ezt meg, maradjunk ennyiben. En pl. aligha orulnek annak, ha a site-om nalad futna, a mail()-t hasznalna, te meg egyszer csak hipp-hopp letiltod a mail() fv-t, mondvan hogy hasznalj phpmailer-t. Nalad ez biztos elfogadhato, de par ortodox helyen ez elfogadhatatlan.

Diktatorok kezikonyve

Miert gondolod azt, hogy en hirtelen otlettol vezerelve szoktam ilyen donteseket hozni? Azert, mert nem irom le minden alkalommal, hogy "az ugyfelek kiertesitese utan egy honappal..." attol meg ez mukodhet igy, nem? Gondolom, hogy az ilyesmi alapveto es trivialis egy tarhelyszolgaltato mukodeseben, de talan tevedek.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

en ugyan at tudom irni 1 munkanapon belul, hogy mail() helyett phpmailer, de van egy csomo pistike-szajt (a php pistike analogiajara), akik ezt nem tudjak megtenni.

De abban sem vagyok biztos, hogy a leggyakoribb alkalmazasok is mind fel vannak ra keszitve, hogy a mail() helyett a phpmailer-t hasznaljak. Masreszt, ha csinalsz valakinek egy szepen mukodo oldalt, es aztan 2 ev mulva nyavogni fog, hogy 'jaj, ezt a levelet kuldte a hoszting ceg, ...', akkor bizony valoszinuleg penzt fogsz kerni a modositasert...

Diktatorok kezikonyve

1 dolog felett elsiklasz: smtp authos phpmaileres tárhelyről is lehet nyomni a spamet. 2 eset rögtön van: ügyfél szándékosan vagy ügyfelet felnyomták és egy human szét is nézett a tárhelyen, aki megtalálta az accot. Már mit sem ér az smtp auth.

Élő, kissé más példa: ami miatt most nekem kell, ott külső smtp auth acc került ki valahogy és tonnányi spamet nyomtak ki postfixen.
Hiába volt frankó php mail limitáló wrapperem, nem onnan jöttek :)
Szóval tényleg az a legbiztosabb, ha MTA szinten fogja meg az ember és "X db mail/user" szintel limitálja.

A phpmailert pedig ne szeresd annyira, ha phpmailerrel kicsatlakoznak egy idegen smtp-re és spammelnek egy nagyot, a te forrás IP-d (tárhely) is benne lesz a fejlécben és kapod a jókora blacklisteket. Sajnos estem már bele. Attól a percről lett tíltva minden 25-ös portra+idegen IP-re kimenő forgalom (kivéve MTA UIDja)
Az iptables logból látszanak is a rendszeres idegen SMTP-re menő próbálkozások.

Hal' istennek nekem eddig meg nem akartak kicsatlakozni, sokkal jobban szerettek volna a keznel levo SMTP-vel kuldozgetni. Mivel egy gep a levelezo meg a webszerver, igy nem bocsatkoztak kiserletezgetesbe.

Az SMTP auth pedig korlatozhato IP-re is, vagyis hogy csak localhostrol vagy a gep valamely sajat IP-jerol jovo authot engedje.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

ha bekapcsolod a safe mode-ot, akkor nem tudja a spammer modositani a php konfigban megadott envelope from cimet, ill. ha van egy listad, akkor siman (spoof-olas cimszoval) eldobhatsz minden olyan levelet, aminek nem a listaban szereplo envelope from cime van. Szoval nem marad az 1-en, ne felj...

Diktatorok kezikonyve

Ha deprecated, akkor nem szabad epiteni ra. Az, hogy meg mukodik, az azert van, mert van egy kazal regi rendszer, amit tamogatni kell. De ha mindenki hasznalja a safe mode-t, mert "meg mukodik" akkor csunya meglepetesek lesznek, amikor kijon a PHP6. Kb. mint amikor kijott a PHP5. Biztos, hogy ezt megint mindenkinek el kell jatszani?
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

nem kell tul aggodni a dolgot. Azert epitunk jelenleg ra, mert hasznos ez a feature. Ha deprecated utan obsoleted/removed/eol/... lesz a feature, _addigra_ kitalalunk valamit, esetleg lesz a mail fuggvenyhez egy opcio, hogy ne lehessen az envelope sendert arbitrary ertekre beallitani, vagy irok en egy patch-et a php mail fuggvenyhez, nem tudom meg. De azt tudom, hogy _jelenleg_ nagyon jo ez a feature.

Diktatorok kezikonyve

Ilyen postfix policy daemon-nál hogy lehet beállítani, hogy csak smtp authos usereknél fusson le? Jelenleg minden ki és bemenő levélnél meghívódik, ami felesleges ellenőrzést és terhelést generál. Jelenleg csak az smtp auth során küldött levelek számát számolom. Elég lenne csak akkor meghívódnia.

2 otlet:

- a smtpd_recipient_restrictions felsorolasban tedd a policy check ele a permit_sasl_authenticated-et
- a policy demont kell ugy beallitani, hogy ha kap sasl_username erteket is, akkor engedje at rogton

A legtutibb azonban az, ha szetvalasztod a kimeno es bejovo levelek kezeleset, tisztabb, szarazabb erzes.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

( janoszen v | 2013. 02. 14., cs – 16:11 )

Alapvetoen az a baj, hogy egyre tobb olyan spamet latok, ami berelt VPS-rol jon. Innentol kezdve baromi nehez limitalni. Ha a szolgaltato limitalja a levelkuldest, nem tud ugyfeleket szerezni, ha nem limitalja, jon a szemet.

Ez a másik oldal. Sj-nek az a problémája, hogy a shared hosting webszerverről smappelnek, így az összes onnan futó levelező szív, mert spamlistára, IP szintű blokkolásra kerülnek más hülyesége miatt. Ez pedig tényleg meg kell és meg is lehet fogni. Napi párszáz mail limit sok embernek bőven elég. Egy spammer viszont sokat nem tud ártani vele. Ha adott user mindig eléri a kvótát, lehet mail a tulajnak, rendszergazdának, hogy gyanús.

Én azon gondolkodom, hogy ők küldhetik a szarjukat, mert céges címre, stb. stb., én viszont tilthatom a kékeresbe a szolgáltatót is, aki ilyet engedélyez.

Namost amíg csak én csinálnék ilyet, addig nyilván még egy keserű mosolyt se csalnék ki se a szolgáltató, se a spammer bandából, de ha többen reagálnának hasonlóan, akkor annak lehetne foganatja.

Az a kérdés, hogy a VPS bérbeadásnak hány százalékát teszik ki az egyszer használatos IP címek, amik egy-egy kampányhoz vannak bérelve. Ha a szolgáltató ebből él, akkor nem fogja kikötni, hogy márpedig tőle nem lehet kiküldeni még ilyen legális spamot se.

vegyunk egy spammert, akivel biztosan mindenki talalkozott mar: pongracz andras. A magyar spammer egyik kommenteloje osztotta meg az infot, hogy ennek a balf*sznak a havi kerete (amit a spam infrastrukturara kolt[ene]) 3-4k HUF. Ha kijon ebbol egy vps, akkor meg van oldva a dolog, es nem kell egyszer hasznalatos vps-t keresnie.

Ha a szolgáltató ebből él, akkor nem fogja kikötni, hogy márpedig tőle nem lehet kiküldeni még ilyen legális spamot se.

pedig van ilyen szolgaltato, amelyik erre a bevetelre is epit, pl. invitel. Meg tavaly nyaron jeleztem nekik, hogy egy szinten kozismert spammer bunozo - navipro magyarorszag (ha jobban tetszik: navipro international) az rphirek, a richpoi es mas hulladek elkovetoje - ipari mennyisegben zuditja a szemetet a netre az invitel halozatarol.

Erre az invitel kerdese az volt: miert nem iratkozol le? Kisnyulert, te barom, aze'. Idokozben igertek, hogy felszolitjak a spammereket, hagyjak abba. LOL. Mig egy bo honap utan abban maradtunkazzal hajtottak el, hogy iratkozzak le, ha nem tetszik. Meg kozben azt is felvetettem, hogy az esetleg nem zavarja oket, hogy egy csomo netezot irrtialnak meg a navipro spammer bunozok? Szerinted zavarta az invitelt?

Diktatorok kezikonyve