Ik wil niet niet filteren op afzender ik constateer dat er gewoon gespammed wordt op generieke (ontvanger) email adressen dus gewoon een lijst met voornamen pakken en een mailtje naar #voornaam#@isp.ext sturen.Oorspronkelijk geplaatst door bakkerl
Likes: 0
19/12/06 12:27
Ik wil niet niet filteren op afzender ik constateer dat er gewoon gespammed wordt op generieke (ontvanger) email adressen dus gewoon een lijst met voornamen pakken en een mailtje naar #voornaam#@isp.ext sturen.
19/12/06 12:58
Om deze discussie even naar een praktisch nivo te tillen:
In hoeverre is het mogelijk om met een basic IPTables firewall etc op je eigen server het verzenden van spam door een gebruiker te voorkomen? Dus op het moment dat een gebruiker gedurende x meer dan y berichten verstuurd wordt hier een tijdelijke ban op gezet? En zo ook voor interne mail vanuit bijvoorbeeld apache processen?
19/12/06 13:20
Je kan dan het beste een wrapper schrijven om de sendmail binarie heen. Daarin kan je dan checks doen en eventuele limits opleggen.
19/12/06 13:28
Dit kan niet met iptables maar moet op applicatieniveau gedaan worden. Je kan bijvoorbeeld de connecties naar je smtp server onderscheppen en limiteren, of nog beter een uitbreiding schrijven op qmail / sendmail / whatever. Iets wat vast wel gedaan is trouwens.. dus misschien kan iemand even zoeken (heb zelf geen tijd helaas)
19/12/06 13:31
Cpanel heeft een functie er voor i.c.m. Exim, opzich best aardig. Wij limiten gewoon op 60 mailtjes per uur ongeveer tenzij ik weet dat er klanten zijn die nieuwsbrieven versturen.
Ik vind blocken van poort 25 geen goed idee, limieten stellen en strenger zijn wel. Ik block bijvoorbeeld ook alle dynamic IP's via RBL lijsten omdat daar 99% spam vandaan komt.
Skynet ICT B.V. - The cause of the problem is: the printer thinks its a router.
19/12/06 13:41
Intern vanaf apache zou je kunnen doen met php's auto_prepend_file setting, waarmee je de mail() functie herschrijft zodat er rate-limiting in zit; ook kan je er dan wat headers in proppen die aangeven vanaf welke website en script 't mailtje gestuurd is, wat het makkelijker maakt om bij eventuele klachten terug te zoeken waar de rommel vandaan komt.
Misschien is 't helemaal geen slecht idee om hier zelfs een eenvoudige standaard van te maken zodat 't voor ons webhosters makkelijker wordt om abuse terug te zoeken als je een klacht krijgt?
Even snel een voorbeeldje in elkaar gehacked om geforceerd headers toe te voegen aan alle mailtjes die vanuit PHP gestuurd worden:
http://www.westlandhosting.nl/gpl/mail.php
Hier is zonder al te veel moeite rate-limiting aan toe te voegen.
Als we als hosting providers allemaal zoiets invoeren, zou de spam vanaf onze servers een heel stuk makkelijker terug te vinden zijn en probleemscripts dus ook aan te wijzen en te verbeteren. Minder uitgaande spam en dus, op termijn, minder binnenkomende spam :-)
19/12/06 13:59
Zoiets ben ik al mee bezig om dat in de source van PHP er in te patchen.
Ik wil meesturen:
- $_SERVER['REMOTE_ADDR']
- $_SERVER['HTTP_HOST']
- $_SERVER['REQUEST_URI']
- $_SERVER['SCRIPT_FILENAME']
- $_SERVER['REQUEST_URI']
- De userID onder wie het mailtje verstuurd werd (dankzij mod_ruid!)
19/12/06 14:02
Ik heb zeker intresse hierin. Ik denk namelijk dat dit wel eens een hele efficiente oplossing kan zijn voor gehackte PHPBB fora en andere slechte scripts die gebruikt worden om te spammen...
19/12/06 14:27
Of het nou als sendmail wrapper, in PHP gepatched, of als auto_prepend_file gedaan wordt maakt niet echt veel uit, het doel is gelukkig bij allemaal hetzelfde, zo duidelijk mogelijk aangeven in de headers, uit welk script een mail()tje is verzonden, zodat je eindelijk eens kan vinden welk script van welke klant het probleem oplevert.
"beginnende programmeurs" zullen altijd "minder nette" code blijven schrijven waardoor spammers mail script kunnen misbruiken; het is een illusie om te denken dat we dat kunnen stoppen, het enige wat we kunnen doen is zoveel mogelijk relevante informate opnemen in de headers van alle mailtjes, zodat problemen zo snel mogelijk gevonden kunnen worden.
Als dit in de standaard PHP source opgenomen zou kunnen worden, dan zou dat een hele hoop hosting/netwerk providers erg blij maken, patches zijn dus zeer zeker welkom! Standaard header namen zijn hierbij zeker ook wenselijk, om eventueel automatische verwerking van abuse e-mail deels automatisch te kunnen verwerken.
Bijvoorbeeld:
X-Requesting-IPAddress: 192.168.0.0
X-Sent-From-Webpage: http://www.example.net/brakscript.php
X-Webpage-UserID: 666
X-Report-Abuse-To: abuse@example.net
ofzo
19/12/06 14:35
Denk er momenteel over na om alle uitgaande mail via een eigen smarthost te jagen die op spam kan scannen.
@Wido
Een degelijke patch bestaat volgens mij al voor php.. FF gezocht:
http://choon.net/php-mail-header.php
Nog niet gebruikt maar het schijnt goed te werken.
19/12/06 15:06
Die had ik inderdaad al als basis gepakt, ik krijg daarmee alleen segmentation faults
19/12/06 15:08
SIGSEGV's zijn altijd fijn
19/12/06 17:05
Ik ben even gaan spelen in de sourcode van PHP en ik krijg nu terug:
Was toch makkelijk dan ik dachtCode:X-Track-ServerName: XXX.pcextreme.nl X-Track-ServerIP: 85.92.129.XX X-Track-URI: /apache2-default/mail.php?ikbeneenl33teScriptor X-Track-RemoteIP: 85.92.XXX X-Track-Method: GET X-Track-UID: 33
Laatst gewijzigd door Wido; 19/12/06 om 17:16.
19/12/06 17:53
Heb je dit ook al werkend voor jullie dedi's met DA?Ik ben even gaan spelen in de sourcode van PHP en ik krijg nu terug:
Was toch makkelijk dan ik dachtCode:X-Track-ServerName: XXX.pcextreme.nl X-Track-ServerIP: 85.92.129.XX X-Track-URI: /apache2-default/mail.php?ikbeneenl33teScriptor X-Track-RemoteIP: 85.92.XXX X-Track-Method: GET X-Track-UID: 33
19/12/06 17:58
Ik heb hem geschreven voor PHP 5.2.0.
Dit is de patch: http://crew.pcextreme.nl/~wido/patch...2.0-mail.patch
Quote