Via ISPs spammende zombies geen groot probleem?
Afgelopen donderdag kwamen de experts van het SpamHaus Project met de waarschuwing dat er een nieuw Trojaans paard ontdekt was dat zombie PCs spam via de e-mail server van de betreffende internet service provider liet sturen. Hierdoor zou het bestrijden van spam een stuk lastiger worden, aangezien het geen zin heeft om grote ISPs te blacklisten. Volgens filterbedrijven en aanbieders van anti-spam oplossingen is de waarschuwing van SpamHaus niet nauwkeurig en is er sprake van overreageren. Dit soort spam kan namelijk ook worden afgevangen, zo laat filterbedrijf Postini weten.
Veel ISPs zouden het SpamHaus project al om advies hebben gevraagd hoe men het probleem kan stoppen. "Dit heeft al voor problemen gezorgd. Grote e-mailbedrijven kunnen niet vertellen dat ze onder druk staan. Ze kunnen niets tegen de pers vertellen, omdat er anders aan hun vermogen om e-mail af te handelen wordt getwijfeld. Wij zien dit niet als hype. Er zijn zeker oplossingen om dit te voorkomen. We raden alleen aan om het snel te doen. De ISPs hebben laten weten dat ze op de hoogte zijn. De meeste aanbieders zeggen dat hun produkt het probleem kan oplossen. Het is echter niet effectief om alleen maar produkten te kopen." aldus Steve Linford van het SpamHaus Project.
Reacties (16)
Tja wij gebruiken smtp authenticatie, is voor de meeste
klanten een kwestie van 1 vinkje in het mail programma
aanvinken en klaar ben je. Als je smtp auth of pop4smtp
gebruikt, kan je het toch al een heel stuk reduceren of denk
ik nou te makkelijk?
klanten een kwestie van 1 vinkje in het mail programma
aanvinken en klaar ben je. Als je smtp auth of pop4smtp
gebruikt, kan je het toch al een heel stuk reduceren of denk
ik nou te makkelijk?
Veel ISP's zijn nog steeds niet of nauwelijks bereid om het
probleem bij de bron aan te pakken, nl. door klanten met
zombie-PC's (gedeeltelijk) af te sluiten, tot het probleem
gefixed is; dit is vervelend werk en kost gewoon geld. De
angst om klanten te verliezen kan daarbij ook een rol bij
spelen.
Door dat niet te doen verschuiven ze het probleem
naar email ontvangers, die o.a. door blacklists als Spamcop
en XBL te gebruiken de effecten van het probleem proberen te
verminderen. Dat betekent dat ontvangers opdraaien voor de
kosten. N.B. ISP's berekenen deze kosten natuurlijk
gewoon door aan hun klanten.
Wat bijna altijd vergeten wordt, is het probleem dat spam
van zombie PC's met gefalsificeerde afzender adressen wordt
verzonden (de zgn. Joe-job). Daarvan bestaat het host-deel
bijna altijd, en het volledige adres (inclusief username)
soms. In beide gevallen wordt spam die niet kan worden
afgeleverd, of die om andere reden wordt geweigerd,
gebounced naar een server van een onschuldige derde, waarbij
deze bounces soms in bestaande mailboxen terechtkomen. In
elk geval krijgt zo'n mailserver bergen bounces te
verwerken. Ik heb dat op een servertje dat ik beheerde zien
oplopen tot meer dan 100.000 per dag, iets waar je NIETS
tegen kunt doen.
Ik heb respect voor ISP's die "poort 25 dichtzetten" (ik heb
er geen bezwaar tegen als ze op verzoek uitzonderingen maken
voor personen en bedrijfjes die hun zaakjes goed voor elkaar
hebben) en hun klanten zo dwingen van de ISP mailserver(s)
als relay gebruik te maken. Zodra ze dat doen zullen ze
betrekkelijk eenvoudig zombie-PC's bij hun klanten kunnen
ontdekken (niet alleen spam- maar ook worm/virus
verspreiders), en zullen daar, nu ook uit eigen belang,
ASAP maatregelen tegen moeten nemen.
Het lijkt me een goed plan als een klant wiens PC
"gezombificeerd" blijkt, op z'n minst opnieuw aansluitkosten
(en wellicht administratiekosten) moet voldoen. Laat de
vervuiler nu maar eens betalen!
Erik van Straten
probleem bij de bron aan te pakken, nl. door klanten met
zombie-PC's (gedeeltelijk) af te sluiten, tot het probleem
gefixed is; dit is vervelend werk en kost gewoon geld. De
angst om klanten te verliezen kan daarbij ook een rol bij
spelen.
Door dat niet te doen verschuiven ze het probleem
naar email ontvangers, die o.a. door blacklists als Spamcop
en XBL te gebruiken de effecten van het probleem proberen te
verminderen. Dat betekent dat ontvangers opdraaien voor de
kosten. N.B. ISP's berekenen deze kosten natuurlijk
gewoon door aan hun klanten.
Wat bijna altijd vergeten wordt, is het probleem dat spam
van zombie PC's met gefalsificeerde afzender adressen wordt
verzonden (de zgn. Joe-job). Daarvan bestaat het host-deel
bijna altijd, en het volledige adres (inclusief username)
soms. In beide gevallen wordt spam die niet kan worden
afgeleverd, of die om andere reden wordt geweigerd,
gebounced naar een server van een onschuldige derde, waarbij
deze bounces soms in bestaande mailboxen terechtkomen. In
elk geval krijgt zo'n mailserver bergen bounces te
verwerken. Ik heb dat op een servertje dat ik beheerde zien
oplopen tot meer dan 100.000 per dag, iets waar je NIETS
tegen kunt doen.
Ik heb respect voor ISP's die "poort 25 dichtzetten" (ik heb
er geen bezwaar tegen als ze op verzoek uitzonderingen maken
voor personen en bedrijfjes die hun zaakjes goed voor elkaar
hebben) en hun klanten zo dwingen van de ISP mailserver(s)
als relay gebruik te maken. Zodra ze dat doen zullen ze
betrekkelijk eenvoudig zombie-PC's bij hun klanten kunnen
ontdekken (niet alleen spam- maar ook worm/virus
verspreiders), en zullen daar, nu ook uit eigen belang,
ASAP maatregelen tegen moeten nemen.
Het lijkt me een goed plan als een klant wiens PC
"gezombificeerd" blijkt, op z'n minst opnieuw aansluitkosten
(en wellicht administratiekosten) moet voldoen. Laat de
vervuiler nu maar eens betalen!
Erik van Straten
Dit is een vraag. Als zo'n Trojaan op een zombie-pc een
eigen smtp engine heeft, gebruikt-ie de mail-server van de
isp toch om te relayen? Als de isp z'n relaying goed heeft
staan, lijkt mij dat vrij lastig.
Op http://www.abuse.net/relay.html kun je je eigen
mailservert testen i.e.g.
eigen smtp engine heeft, gebruikt-ie de mail-server van de
isp toch om te relayen? Als de isp z'n relaying goed heeft
staan, lijkt mij dat vrij lastig.
Op http://www.abuse.net/relay.html kun je je eigen
mailservert testen i.e.g.
Door Anoniem
Tja wij gebruiken smtp authenticatie, is voor de meeste
klanten een kwestie van 1 vinkje in het mail programma
aanvinken en klaar ben je. Als je smtp auth of pop4smtp
gebruikt, kan je het toch al een heel stuk reduceren of denk
ik nou te makkelijk?
Tja wij gebruiken smtp authenticatie, is voor de meeste
klanten een kwestie van 1 vinkje in het mail programma
aanvinken en klaar ben je. Als je smtp auth of pop4smtp
gebruikt, kan je het toch al een heel stuk reduceren of denk
ik nou te makkelijk?
Er wordt ook veel misbruik gemaakt van de smtp auth functie.
Er wordt zelfs aangeraden 'm uit te zetten bij het configureren van een
mailserver.
MVG
Rocky McG
06-02-2005, 13:59 door
Eugene Page
Offtopic: dit is berichtnummer 10000. Gaat dit ongemerkt verder voorbij?
Door Eugene Page
Offtopic: dit is berichtnummer 10000. Gaat dit ongemerkt verder voorbij?
Nee hoor. Ik zag het ook.Offtopic: dit is berichtnummer 10000. Gaat dit ongemerkt verder voorbij?
Door Anoniem
Veel ISP's zijn nog steeds niet of nauwelijks bereid om het
probleem bij de bron aan te pakken, nl. door klanten met
zombie-PC's (gedeeltelijk) af te sluiten, tot het probleem
gefixed is
Zelf vind ik dat een ISP alleen maar hoeft te zorgen voorVeel ISP's zijn nog steeds niet of nauwelijks bereid om het
probleem bij de bron aan te pakken, nl. door klanten met
zombie-PC's (gedeeltelijk) af te sluiten, tot het probleem
gefixed is
een dikke vette pijp naar het internet en niet met wat daar
doorheen gaat.
Hoe kan je als ISP zien dat vanaf een klant-pc veel spam
komt? Wat nou als die klant diverse domeinen host en daar
mail voor ontvangt en verstuurt?
Het geeft de isp, denk ik, een hoop extra werk.
Ik heb respect voor ISP's die "poort 25 dichtzetten"
smtp-servertje hebt staan? Moet je dan eerst moeilijk gaan
doen om alsjeblieft poort 25 open te krijgen?
Ik vind dat een ISP zich niet bezig zou moeten houden met
het filteren van verkeer. Als je het probleem bij de bron
aanpakt, is dat m.i. ook niet nodig.
Het lijkt me een goed plan als een klant wiens PC
"gezombificeerd" blijkt, op z'n minst opnieuw aansluitkosten
(en wellicht administratiekosten) moet voldoen. Laat de
vervuiler nu maar eens betalen!
gewoon gezellig internetten. Krijgen ze opeens een factuur
voor heraansluiting enz. in de bus?! Heb je dit idee al met
de Consumentenbond besproken?
Op zondag 06 februari 2005 15:19 schreef Anoniem onder meer:
> Als je het probleem bij de bron aanpakt, is dat m.i. ook
> niet nodig.
Volgens mij ben je een troll, want mijn stellingen waar je
kennelijk geen weerwoord op hebt laat je weg, en oplossingen
geef je niet. Alleen jouw bovenstaande regel doet me twijfelen.
Hoe stel jij dan voor dat het probleem van alsmaar
meer zombie PC's wordt aangepakt, en wie dat dan wel
moet betalen? Rekening houdend met het feit dat ISP's van
deze onwetende en/of lakse klanten er (volgens het
security.nl artikel) in toenemende mate zelf last van
hebben? Uitvoerbare en betaalbare oplossingen graag!
Erik van Straten
> Als je het probleem bij de bron aanpakt, is dat m.i. ook
> niet nodig.
Volgens mij ben je een troll, want mijn stellingen waar je
kennelijk geen weerwoord op hebt laat je weg, en oplossingen
geef je niet. Alleen jouw bovenstaande regel doet me twijfelen.
Hoe stel jij dan voor dat het probleem van alsmaar
meer zombie PC's wordt aangepakt, en wie dat dan wel
moet betalen? Rekening houdend met het feit dat ISP's van
deze onwetende en/of lakse klanten er (volgens het
security.nl artikel) in toenemende mate zelf last van
hebben? Uitvoerbare en betaalbare oplossingen graag!
Erik van Straten
Op zondag 06 februari 2005 13:13 schreef Anoniem onder meer:
> Dit is een vraag. Als zo'n Trojaan op een zombie-pc
> een eigen smtp engine heeft, gebruikt-ie de
> mail-server van de isp toch om te relayen? Als
> de isp z'n relaying goed heeft staan, lijkt mij
> dat vrij lastig.
De meeste spammende zombie-PC's maken direct contact met de
mailserver van de spam-ontvanger. Als jij bij
chello.nl zit en een zombie PC bij Comcast (een beruchte USA
ISP met veel zombies) stuurt jou spam, dan zal die Comcast
PC de spam direct aanbieden op smtp.chello.nl.
Sommige ISP's blokkeren uitgaand SMTP verkeer waardoor dit
niet kan. Dat, tezamen met het succes van blacklists als
Spamcop en XBL (zie
http://www.spamhaus.org/xbl/index.lasso), heeft
vermoedelijk geleid tot een trojan die dit NIET doet, maar
die de spam "netjes" op de mailserver van de eigen ISP
aanbiedt, zoals bijna iedereen met z'n gewone email
programma doet.
De ISP heeft als taak om email van haar eigen klanten
te relayen (aan te nemen en door te sturen), maar kan niet
zonder meer zien of de email door een trojan of door een
legitieme gebruiker wordt aangeboden.
Door zaken als "pop before smtp" of "authenticated smtp" kun
je het trojans wel een stuk lastiger maken, maar het wachten
is op malware die de benodigde info uit de registry haalt,
of snifft zodra de gebruiker zelf een email verstuurt.
ISP's kunnen uitgaande mail natuurlijk ook op
virussen en spam checken, evt. gecombineerd met
rate-limiting (in principe hoeven ze hier poort 25 niet eens
voor te blokkeren, ze kunnen deze aftappen zonder dat de
klant dit merkt, iets dat ze binnenkort toch al moeten van
de overheid).
Daardoor komen ze er snel en eenvoudig achter als hun
klanten zich misdragen. Een groot probleem voor ISP's is dat
het vaak erg moeilijk is om hun klanten te bereiken, uit te
leggen wat het probleem is, om er vervolgens achter te komen
dat niet alle backdoors verwijderd zijn op het moment dat de
klant weer wordt aangesloten.
Erik van Straten
> Dit is een vraag. Als zo'n Trojaan op een zombie-pc
> een eigen smtp engine heeft, gebruikt-ie de
> mail-server van de isp toch om te relayen? Als
> de isp z'n relaying goed heeft staan, lijkt mij
> dat vrij lastig.
De meeste spammende zombie-PC's maken direct contact met de
mailserver van de spam-ontvanger. Als jij bij
chello.nl zit en een zombie PC bij Comcast (een beruchte USA
ISP met veel zombies) stuurt jou spam, dan zal die Comcast
PC de spam direct aanbieden op smtp.chello.nl.
Sommige ISP's blokkeren uitgaand SMTP verkeer waardoor dit
niet kan. Dat, tezamen met het succes van blacklists als
Spamcop en XBL (zie
http://www.spamhaus.org/xbl/index.lasso), heeft
vermoedelijk geleid tot een trojan die dit NIET doet, maar
die de spam "netjes" op de mailserver van de eigen ISP
aanbiedt, zoals bijna iedereen met z'n gewone email
programma doet.
De ISP heeft als taak om email van haar eigen klanten
te relayen (aan te nemen en door te sturen), maar kan niet
zonder meer zien of de email door een trojan of door een
legitieme gebruiker wordt aangeboden.
Door zaken als "pop before smtp" of "authenticated smtp" kun
je het trojans wel een stuk lastiger maken, maar het wachten
is op malware die de benodigde info uit de registry haalt,
of snifft zodra de gebruiker zelf een email verstuurt.
ISP's kunnen uitgaande mail natuurlijk ook op
virussen en spam checken, evt. gecombineerd met
rate-limiting (in principe hoeven ze hier poort 25 niet eens
voor te blokkeren, ze kunnen deze aftappen zonder dat de
klant dit merkt, iets dat ze binnenkort toch al moeten van
de overheid).
Daardoor komen ze er snel en eenvoudig achter als hun
klanten zich misdragen. Een groot probleem voor ISP's is dat
het vaak erg moeilijk is om hun klanten te bereiken, uit te
leggen wat het probleem is, om er vervolgens achter te komen
dat niet alle backdoors verwijderd zijn op het moment dat de
klant weer wordt aangesloten.
Erik van Straten
HOERA! HOERA!
10.000 artikelen op security.nl.
HOERA HOERA!
Zo, nu weer aan het werk.
10.000 artikelen op security.nl.
HOERA HOERA!
Zo, nu weer aan het werk.
Door Anoniem
Op zondag 06 februari 2005 15:19 schreef Anoniem onder meer:
> Als je het probleem bij de bron aanpakt, is dat m.i. ook
> niet nodig.
Volgens mij ben je een troll, want mijn stellingen waar je
kennelijk geen weerwoord op hebt laat je weg, en oplossingen
geef je niet. Alleen jouw bovenstaande regel doet me twijfelen.
Hoe stel jij dan voor dat het probleem van alsmaar
meer zombie PC's wordt aangepakt, en wie dat dan wel
moet betalen? Rekening houdend met het feit dat ISP's van
deze onwetende en/of lakse klanten er (volgens het
security.nl artikel) in toenemende mate zelf last van
hebben? Uitvoerbare en betaalbare oplossingen graag!
Erik van Straten
Troll?Op zondag 06 februari 2005 15:19 schreef Anoniem onder meer:
> Als je het probleem bij de bron aanpakt, is dat m.i. ook
> niet nodig.
Volgens mij ben je een troll, want mijn stellingen waar je
kennelijk geen weerwoord op hebt laat je weg, en oplossingen
geef je niet. Alleen jouw bovenstaande regel doet me twijfelen.
Hoe stel jij dan voor dat het probleem van alsmaar
meer zombie PC's wordt aangepakt, en wie dat dan wel
moet betalen? Rekening houdend met het feit dat ISP's van
deze onwetende en/of lakse klanten er (volgens het
security.nl artikel) in toenemende mate zelf last van
hebben? Uitvoerbare en betaalbare oplossingen graag!
Erik van Straten
De dingen die ik aanhaalde waren de enige dingen in jouw
verhaal, waar ik vragen bij had.
:-S
Wat bijna altijd vergeten wordt, is het probleem dat spam
van zombie PC's met gefalsificeerde afzender adressen wordt
verzonden (de zgn. Joe-job). Daarvan bestaat het host-deel
bijna altijd, en het volledige adres (inclusief username)
soms. In beide gevallen wordt spam die niet kan worden
afgeleverd, of die om andere reden wordt geweigerd,
gebounced naar een server van een onschuldige derde, waarbij
deze bounces soms in bestaande mailboxen terechtkomen. In
elk geval krijgt zo'n mailserver bergen bounces te
verwerken. Ik heb dat op een servertje dat ik beheerde zien
oplopen tot meer dan 100.000 per dag, iets waar je NIETS
tegen kunt doen.
van zombie PC's met gefalsificeerde afzender adressen wordt
verzonden (de zgn. Joe-job). Daarvan bestaat het host-deel
bijna altijd, en het volledige adres (inclusief username)
soms. In beide gevallen wordt spam die niet kan worden
afgeleverd, of die om andere reden wordt geweigerd,
gebounced naar een server van een onschuldige derde, waarbij
deze bounces soms in bestaande mailboxen terechtkomen. In
elk geval krijgt zo'n mailserver bergen bounces te
verwerken. Ik heb dat op een servertje dat ik beheerde zien
oplopen tot meer dan 100.000 per dag, iets waar je NIETS
tegen kunt doen.
Goed dat je dat weer eens naar voren brengt. Veel mail servers accepteren
mail zonder controle of de mail wel te bezorgen is. Die controle moet je
dus altijd doen aan de poort, tijdens de SMTP sessie, direct na ontvangst
van RCPT TO. Zo voorkom je dat je onbezorgbare mail hoeft te queuen en
zo stuur je zelf nooit Delivery Status Notifications naar vervalste afzenders.
Daarmee voorkom je ook problemen als je zelf wordt aangevallen, want
dan is de server snel weer beschikbaar om nieuwe mail aan te nemen als
een geadresseerde niet bestaat.
Wanneer bestaande e-mail adressen worden gebruikt als vervalste
afzender -dat zullen vrijwel altijd maar een beperkt aantal zijn- weiger je die
tijdelijk of filter je die op DSN berichten of je zet alle mail op een zijspoor,
etc.
Het probleem is dus wel te managen.
Jeroen
Op maandag 07 februari 2005 00:39 schreef Jeroen onder meer:
> Het probleem is dus wel te managen.
Alleen voor zover het bounces betreft die daadwerkelijk in
user mailboxes terechtkomen, zoals je aan het einde van je
post beschijft. D.w.z. met een kleine bijwerking, nl. dat
eventuele bounces die echt voor lokale users bestemd
zijn, ook op een zijspoor worden gezet.
> Goed dat je dat weer eens naar voren brengt. Veel
> mail servers accepteren mail zonder controle of de
> mail wel te bezorgen is. Die controle moet je dus
> altijd doen aan de poort, tijdens de SMTP sessie,
> direct na ontvangst van RCPT TO. Zo voorkom je
> dat je onbezorgbare mail hoeft te queuen en zo
> stuur je zelf nooit Delivery Status Notifications naar
> vervalste afzenders.
Volstrekt mee eens! Echter, door af te sluiten met "Het
probleem is dus wel te managen" wek je voor minder
ingewijden de indruk dat dit iets is dat ik kan doen
om m'n probleem op te lossen, maar dat is natuurlijk niet
zo. De rest van de wereld, inclusief Yahoo en AOL zouden dit
moeten doen - maar dat doen zij helaas niet!
Ook andere grote organisaties doen dit zelden; het vereist
nl. dat alle usernames (en aliases) op alle "border"
mailservers (dus ook alle backup MXen) bekend zijn. Forward
verification is ook een oplossing, maar die stelt wel eisen
aan bereikbaarheid binnen een organisatie. Een argument dat
tegenstanders van dit "aan de poort checken en rejecten" ook
wel noemen is dat spammers zo snel naar nieuwe
spam-slachtoffers kunnen scannen (m.i. is dat grotendeels te
verhinderen). Zolang grote ISP's niet doen wat jij
voorstelt, sta je machteloos als je site ge-Joe-jobbed wordt.
De enige oplossing die ik zie is het aanpakken van zombie
PC's die, soms zeer vulgaire, spam verzenden uit naam van
organisaties (of zelfs bestaande personen) die er niets mee
te maken hebben. Met als gevolg dat die organisaties,
behalve onterechte negatieve publiciteit, ook bergen bounces
te verwerken krijgen. Ik ben er dan ook niet rouwig om dat
lakse ISP's nu ook zelf hinder ondervinden van hun spammende
klanten.
Erik van Straten
> Het probleem is dus wel te managen.
Alleen voor zover het bounces betreft die daadwerkelijk in
user mailboxes terechtkomen, zoals je aan het einde van je
post beschijft. D.w.z. met een kleine bijwerking, nl. dat
eventuele bounces die echt voor lokale users bestemd
zijn, ook op een zijspoor worden gezet.
> Goed dat je dat weer eens naar voren brengt. Veel
> mail servers accepteren mail zonder controle of de
> mail wel te bezorgen is. Die controle moet je dus
> altijd doen aan de poort, tijdens de SMTP sessie,
> direct na ontvangst van RCPT TO. Zo voorkom je
> dat je onbezorgbare mail hoeft te queuen en zo
> stuur je zelf nooit Delivery Status Notifications naar
> vervalste afzenders.
Volstrekt mee eens! Echter, door af te sluiten met "Het
probleem is dus wel te managen" wek je voor minder
ingewijden de indruk dat dit iets is dat ik kan doen
om m'n probleem op te lossen, maar dat is natuurlijk niet
zo. De rest van de wereld, inclusief Yahoo en AOL zouden dit
moeten doen - maar dat doen zij helaas niet!
Ook andere grote organisaties doen dit zelden; het vereist
nl. dat alle usernames (en aliases) op alle "border"
mailservers (dus ook alle backup MXen) bekend zijn. Forward
verification is ook een oplossing, maar die stelt wel eisen
aan bereikbaarheid binnen een organisatie. Een argument dat
tegenstanders van dit "aan de poort checken en rejecten" ook
wel noemen is dat spammers zo snel naar nieuwe
spam-slachtoffers kunnen scannen (m.i. is dat grotendeels te
verhinderen). Zolang grote ISP's niet doen wat jij
voorstelt, sta je machteloos als je site ge-Joe-jobbed wordt.
De enige oplossing die ik zie is het aanpakken van zombie
PC's die, soms zeer vulgaire, spam verzenden uit naam van
organisaties (of zelfs bestaande personen) die er niets mee
te maken hebben. Met als gevolg dat die organisaties,
behalve onterechte negatieve publiciteit, ook bergen bounces
te verwerken krijgen. Ik ben er dan ook niet rouwig om dat
lakse ISP's nu ook zelf hinder ondervinden van hun spammende
klanten.
Erik van Straten
07-02-2005, 07:35 door
Walter
Door Anoniem
Dit is een vraag. Als zo'n Trojaan op een zombie-pc een
eigen smtp engine heeft, gebruikt-ie de mail-server van de
isp toch om te relayen? Als de isp z'n relaying goed heeft
staan, lijkt mij dat vrij lastig.
Lijkt mij dat je als ISP in ieder geval voor al je klantenDit is een vraag. Als zo'n Trojaan op een zombie-pc een
eigen smtp engine heeft, gebruikt-ie de mail-server van de
isp toch om te relayen? Als de isp z'n relaying goed heeft
staan, lijkt mij dat vrij lastig.
(jouw IP reeks) zult moeten relayen. Dus als die trojan op
jouw netwerk zit, relay je ervoor, omdat je anders wel
erg veel klachten van je klanten gaat krijgen dat ze
niet kunnen e-mailen.
Alleen voor zover het bounces betreft die daadwerkelijk in
user mailboxes terechtkomen, zoals je aan het einde van je
post beschijft. D.w.z. met een kleine bijwerking, nl. dat
eventuele bounces die echt voor lokale users bestemd
zijn, ook op een zijspoor worden gezet.
user mailboxes terechtkomen, zoals je aan het einde van je
post beschijft. D.w.z. met een kleine bijwerking, nl. dat
eventuele bounces die echt voor lokale users bestemd
zijn, ook op een zijspoor worden gezet.
Dat is in de praktijk een verwaarloosbare bijwerking. Het gaat immers
maar om een tijdelijke maatregel voor een beperkt aantal gebruikers, niet
voor alle gebruikers. Van die gebruikers verzendt er misschien maar één
een onbezorgbaar bericht per dag.
Volstrekt mee eens! Echter, door af te sluiten met "Het
probleem is dus wel te managen" wek je voor minder
ingewijden de indruk dat dit iets is dat ik kan doen
om m'n probleem op te lossen, maar dat is natuurlijk niet
zo. De rest van de wereld, inclusief Yahoo en AOL zouden dit
moeten doen - maar dat doen zij helaas niet!
Yahoo en AOL doen het allebei wel :-). Het zijn vooral de niet-IT/niet-ISP
bedrijven die het niet doen, bijvoorbeeld bedrijven met een uitgebreide
Exchange of Notes infrastructuur.
Het probleem kun je grotendeels voor jezelf oplossen door
bezorgbaarheidcontrole aan de poort toe te passen. De impact van een
Joe-job op het domein is dan minimaal. Die gaan vaak naar niet
bestaande adressen.
Als je een piepkleine mail server hebt aan een 128 k lijntje heb je wel een
probleem. Maar in deze tijd zou bandbreedte geen bottleneck meer
moeten zijn.
Het is hoe dan ook te achterhalen welke adressen bezorgbaar zijn, tenzij
de mail infra is opgezet als zwart gat. Er zijn grofweg drie manieren:
1. VRFY
2. error code na RCPT TO of DATA
3. bounce bericht ontvangen van interne mail server
Scannen naar nieuwe adressen is voor spammers tamelijk zinloos en je
zult dat daarom zelden zien. Het resultaat van miljarden combinaties zal
marginaal zijn. Goede mail servers merken dat er veel pogingen worden
gedaan en die zullen daarom langzaam antwoorden of IP's tijdelijk
blokkeren.
De eerste twee methoden kunnen wel net wat makkelijker worden gebruikt
door spammers om een adressenlijst op te schonen en door te verkopen.
Maar dat kan ook met de derde methode. Legale mailing lists doen
overigens soortgelijke dingen, maar dan wel met hen bekende adressen.
Inderdaad, ISP's moeten de handen uit de mouwen steken. Maar je zult
ook zelf actie moeten ondernemen.
Jeroen
probleem is dus wel te managen" wek je voor minder
ingewijden de indruk dat dit iets is dat ik kan doen
om m'n probleem op te lossen, maar dat is natuurlijk niet
zo. De rest van de wereld, inclusief Yahoo en AOL zouden dit
moeten doen - maar dat doen zij helaas niet!
Yahoo en AOL doen het allebei wel :-). Het zijn vooral de niet-IT/niet-ISP
bedrijven die het niet doen, bijvoorbeeld bedrijven met een uitgebreide
Exchange of Notes infrastructuur.
Het probleem kun je grotendeels voor jezelf oplossen door
bezorgbaarheidcontrole aan de poort toe te passen. De impact van een
Joe-job op het domein is dan minimaal. Die gaan vaak naar niet
bestaande adressen.
Als je een piepkleine mail server hebt aan een 128 k lijntje heb je wel een
probleem. Maar in deze tijd zou bandbreedte geen bottleneck meer
moeten zijn.
Ook andere grote organisaties doen dit zelden; het vereist
nl. dat alle usernames (en aliases) op alle "border"
mailservers (dus ook alle backup MXen) bekend zijn. Forward
verification is ook een oplossing, maar die stelt wel eisen
aan bereikbaarheid binnen een organisatie. Een argument dat
tegenstanders van dit "aan de poort checken en rejecten" ook
wel noemen is dat spammers zo snel naar nieuwe
spam-slachtoffers kunnen scannen (m.i. is dat grotendeels te
verhinderen). Zolang grote ISP's niet doen wat jij
voorstelt, sta je machteloos als je site ge-Joe-jobbed wordt.
nl. dat alle usernames (en aliases) op alle "border"
mailservers (dus ook alle backup MXen) bekend zijn. Forward
verification is ook een oplossing, maar die stelt wel eisen
aan bereikbaarheid binnen een organisatie. Een argument dat
tegenstanders van dit "aan de poort checken en rejecten" ook
wel noemen is dat spammers zo snel naar nieuwe
spam-slachtoffers kunnen scannen (m.i. is dat grotendeels te
verhinderen). Zolang grote ISP's niet doen wat jij
voorstelt, sta je machteloos als je site ge-Joe-jobbed wordt.
Het is hoe dan ook te achterhalen welke adressen bezorgbaar zijn, tenzij
de mail infra is opgezet als zwart gat. Er zijn grofweg drie manieren:
1. VRFY
2. error code na RCPT TO of DATA
3. bounce bericht ontvangen van interne mail server
Scannen naar nieuwe adressen is voor spammers tamelijk zinloos en je
zult dat daarom zelden zien. Het resultaat van miljarden combinaties zal
marginaal zijn. Goede mail servers merken dat er veel pogingen worden
gedaan en die zullen daarom langzaam antwoorden of IP's tijdelijk
blokkeren.
De eerste twee methoden kunnen wel net wat makkelijker worden gebruikt
door spammers om een adressenlijst op te schonen en door te verkopen.
Maar dat kan ook met de derde methode. Legale mailing lists doen
overigens soortgelijke dingen, maar dan wel met hen bekende adressen.
De enige oplossing die ik zie is het aanpakken van zombie
PC's die, soms zeer vulgaire, spam verzenden uit naam van
organisaties (of zelfs bestaande personen) die er niets mee
te maken hebben. Met als gevolg dat die organisaties,
behalve onterechte negatieve publiciteit, ook bergen bounces
te verwerken krijgen. Ik ben er dan ook niet rouwig om dat
lakse ISP's nu ook zelf hinder ondervinden van hun spammende
klanten.
PC's die, soms zeer vulgaire, spam verzenden uit naam van
organisaties (of zelfs bestaande personen) die er niets mee
te maken hebben. Met als gevolg dat die organisaties,
behalve onterechte negatieve publiciteit, ook bergen bounces
te verwerken krijgen. Ik ben er dan ook niet rouwig om dat
lakse ISP's nu ook zelf hinder ondervinden van hun spammende
klanten.
Inderdaad, ISP's moeten de handen uit de mouwen steken. Maar je zult
ook zelf actie moeten ondernemen.
Jeroen
Op maandag 07 februari 2005 16:41 schreef Jeroen onder meer:
> Yahoo en AOL doen het allebei wel :-).
Nee, beiden accepteren eerst alle mail en gaan dan pas
checken. Hetzelfde geldt ook voor andere grote jongens als
postini, pobox en messagelabs. Als test heb ik nog even een
mailtje naar een niet bestaand AOL account gestuurd, dat
leverde na enige tijd een door AOL gegenereeerde
bounce op. Niet afleverbare mail wordt dus NIET
gereject met een 550 code o.i.d. (dan had ik hem meteen
teruggehad):
Return-Path: <>
From: Mail Delivery Subsystem <MAILER-DAEMON@aol.com>
Subject: Returned mail: User unknown
Die mail is aan mijn MTA aangeboden door omr-m02.mx.aol.com
[64.12.138.2], die de mail op zijn beurt van
rly-xk03.mail.aol.com [172.20.83.40] kreeg (behoorlijk
intern dus). Hier full headers posten wordt een rommelje,
stuur zelf maar een mailtje naar een niet bestaand account
als je me niet gelooft.
> Als je een piepkleine mail server hebt aan een
> 128 k lijntje heb je wel een probleem.
Dikke pijp, wel een klein doosje; geen technische
problemen dankzij Postfix. Maar er zijn zat "minder
gelukkige" admins, vooral van kleine bedrijfjes en
(vrijwilligers-) organisaties. Ik heb meerdere keren gezien
dat zo'n site de overlast niet aankan en hun mailserver
blokkeren. De volgende is wel heel "fraai", telkens de
rechterhelft van een MX lookup van pe1chl.ampr.org:
40 localhost.
10 pe1chl-ampr-org.domain.is.abused.by.russian.
20 spammers.as.forged.sender.domain.
30 i.have.nothing.to.do.with.this.spam.
Jeroen schreef verder:
> Scannen naar nieuwe adressen is voor spammers
> tamelijk zinloos en je zult dat daarom zelden zien.
Hmm... google: spammer dictionary attack
Veel mensen (soms ik ook) kiezen zo kort mogelijke usernames
of aliases, wat het succes van dictionary attacks vergroot.
En met een zombie netwerk hoef je zo'n attack niet in 1
avond vanaf 1 PC uit te voeren. Als je dat spreidt en genoeg
randomness in je messages stopt (maar ze wel ze op normale
messages laat lijken) kun je vast wel, zeker bij grotere
ISP's, onder de radar blijven.
> Maar je zult ook zelf actie moeten ondernemen.
Klopt. Een van de dingen die ik probeer, is lezers van deze
site (mail admins?) bewust te maken van de problematiek. Het
zombie-PC-, en daarmee een groot deel van het spamprobleem,
lossen we zeker niet op door allemaal ons email adres
"geheim" te houden zoals sommigen hier bij herhaling
suggereren (en dan maar duimen dat een admin bij je eigen
ISP, of die van een vriendje met wie je mailt, jouw email
adres niet doorverkoopt aan spammers).
Erik van Straten
> Yahoo en AOL doen het allebei wel :-).
Nee, beiden accepteren eerst alle mail en gaan dan pas
checken. Hetzelfde geldt ook voor andere grote jongens als
postini, pobox en messagelabs. Als test heb ik nog even een
mailtje naar een niet bestaand AOL account gestuurd, dat
leverde na enige tijd een door AOL gegenereeerde
bounce op. Niet afleverbare mail wordt dus NIET
gereject met een 550 code o.i.d. (dan had ik hem meteen
teruggehad):
Return-Path: <>
From: Mail Delivery Subsystem <MAILER-DAEMON@aol.com>
Subject: Returned mail: User unknown
Die mail is aan mijn MTA aangeboden door omr-m02.mx.aol.com
[64.12.138.2], die de mail op zijn beurt van
rly-xk03.mail.aol.com [172.20.83.40] kreeg (behoorlijk
intern dus). Hier full headers posten wordt een rommelje,
stuur zelf maar een mailtje naar een niet bestaand account
als je me niet gelooft.
> Als je een piepkleine mail server hebt aan een
> 128 k lijntje heb je wel een probleem.
Dikke pijp, wel een klein doosje; geen technische
problemen dankzij Postfix. Maar er zijn zat "minder
gelukkige" admins, vooral van kleine bedrijfjes en
(vrijwilligers-) organisaties. Ik heb meerdere keren gezien
dat zo'n site de overlast niet aankan en hun mailserver
blokkeren. De volgende is wel heel "fraai", telkens de
rechterhelft van een MX lookup van pe1chl.ampr.org:
40 localhost.
10 pe1chl-ampr-org.domain.is.abused.by.russian.
20 spammers.as.forged.sender.domain.
30 i.have.nothing.to.do.with.this.spam.
Jeroen schreef verder:
> Scannen naar nieuwe adressen is voor spammers
> tamelijk zinloos en je zult dat daarom zelden zien.
Hmm... google: spammer dictionary attack
Veel mensen (soms ik ook) kiezen zo kort mogelijke usernames
of aliases, wat het succes van dictionary attacks vergroot.
En met een zombie netwerk hoef je zo'n attack niet in 1
avond vanaf 1 PC uit te voeren. Als je dat spreidt en genoeg
randomness in je messages stopt (maar ze wel ze op normale
messages laat lijken) kun je vast wel, zeker bij grotere
ISP's, onder de radar blijven.
> Maar je zult ook zelf actie moeten ondernemen.
Klopt. Een van de dingen die ik probeer, is lezers van deze
site (mail admins?) bewust te maken van de problematiek. Het
zombie-PC-, en daarmee een groot deel van het spamprobleem,
lossen we zeker niet op door allemaal ons email adres
"geheim" te houden zoals sommigen hier bij herhaling
suggereren (en dan maar duimen dat een admin bij je eigen
ISP, of die van een vriendje met wie je mailt, jouw email
adres niet doorverkoopt aan spammers).
Erik van Straten
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime
Ben jij er klaar voor om de leiding te nemen in het bevorderen van de regionale samen-werking in de strijd tegen gedigitaliseerde criminaliteit en cybercrime? Samen met collega's, politie en regionale en landelijke partners? Dan is de dynamische rol van Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime bij het Regionaal Samenwerkingsverband Integrale Veiligheid (RSIV) jouw op het lijf geschreven!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.