Archief
- De topics van lang geleden
MS / Hotmail negeert open proxies
27-05-2002, 09:31 door Anoniem, 4 reacties
Na veel mailwisseling weigert Hotmail om mail van open proxies (bv. de beruchte Koreaanse servers) te blokkeren. Resultaat: wij hebben al 7000 mailtjes met viri en spam als onbestelbaar teruggekregen. Niet door ons gestuurd, wel met ons als afzender.
Allemaal gericht aan, inderdaad, hotmail accounts en gestuurd via open proxies.
Ron Roozendaal
RSI-Centrum
Allemaal gericht aan, inderdaad, hotmail accounts en gestuurd via open proxies.
Ron Roozendaal
RSI-Centrum
Reacties (4)
03-06-2002, 10:03 door
bustersnyvel
Gewoon alle mail van Hotmail blokkeren. Willen mensen je spreken, moeten ze maar een email adres bij een redelijke partij nemen. Gratis adressen genoeg te vinden op internet.
Dit is vrij ~simpel~ op te lossen:
Onze mailserver wordt de laatse tijd ook gebombardeerd door [xxxx]@hotmail.com bagger.
Waarom? Nou, we hebben zoiets als Klez.H tegenwoordig ( en meer mass-mailing-shite).
Klez.H plukt uit het adresboek (start -> find -> *.WAB) een random adres en gebruikt dat als afzender, en aangezien de halve wereld tegenwoordig hotmail heeft, komt dat neer op een paar honderd 'relays' uit naam van een hotmail-user per dag..
Hotmail heeft zijn/haar/het eigen SMTP range, dus: als niet X-originating IP = een hotmail SMTP dan bagger.
* welcome to my killfile :-) *
Onze mailserver wordt de laatse tijd ook gebombardeerd door [xxxx]@hotmail.com bagger.
Waarom? Nou, we hebben zoiets als Klez.H tegenwoordig ( en meer mass-mailing-shite).
Klez.H plukt uit het adresboek (start -> find -> *.WAB) een random adres en gebruikt dat als afzender, en aangezien de halve wereld tegenwoordig hotmail heeft, komt dat neer op een paar honderd 'relays' uit naam van een hotmail-user per dag..
Hotmail heeft zijn/haar/het eigen SMTP range, dus: als niet X-originating IP = een hotmail SMTP dan bagger.
* welcome to my killfile :-) *
04-06-2002, 20:49 door
Grepmaster
Zelf gebruiken wij de volgende "doordachte" methode om hotmail te weren:
Als ik in het onderstaande uit sendmail documentatie citeer dan is dat uit de file "op.me" van sendmail 8.11.6. Op mijn Slackware 8.0 is dat: /usr/doc/sendmail/op/op.me
Mijn eerste gedachte was om het in de ruleset "Local_check_mail" op te lossen. Als je kijkt naar het begin van de ruleset "Basic_check_mail" dan worden daar enkele controles op de afzender gedaan. Eerst wordt het domain van de (envelope) sender bekeken. Als dat "localhost", "localhost.some.domain" of "[127.0.0.1]" is dan moet de macro $&{client_name} expanderen tot een "local client". Idem als de afzender helemaal geen domain name specificeert. Ik dacht dit over te kunen nemen in "Local_check_mail". Een paar kleine aanpassingen om te testen op "hotmail.com" i.p.v. "localhost", en klaar is Kees. Maar waarschijnlijk gaat dat niet werken.
In mail afkomstig van hotmail.com tref je headers aan als onderstaand:
Received: from hotmail.com (f213.law7.hotmail.com [216.33.237.213])
by mail.mitch-it.com (8.9.3/8.9.3) with ESMTP id VAA22455
for <michel@mitch-it.com>; Sun, 14 Apr 2002 21:33:34 +0200
En als dan zoekt in de documentatie (op.me) naar ${client_name} dan vind je:
${client_name}
The host name of the SMTP client. This may be
the client's bracketed IP address in the form [
nnn.nnn.nnn.nnn ] if the client's IP address is
not resolvable, or if it is resolvable but the IP
address of the resolved hostname doesn't match
the original IP address. Defined in the SMTP
server only.
Met de "Recieved:" header die ik hieboven citeerde krijg je dan al heel snel het vermoeden dat ${client_name} in dit geval zal expanderen tot het "bracketed IP address" en _niet_ tot "hotmail.com". Daar hebben we dus niets aan. Een andere complicatie is dat mail via een van je eigen lager gewaardeerde MX hosts binnen kan komen. In dat geval dan ben je ook de oorspronkelijke client kwijt. Bovendien zou je op deze manier alleen de "envelope sender" controleren en niet de "header sender".
Kan het nog anders?. Ja, het is ook mogelijk om willekeurige headers van een mailtje te analyseren. Je zou de "from:" header (en eventueel "resend-from:", "sender:", ...) kunnen controleren. Als daar "@hotmail.com" in voorkomt dan moet ook "hotmail.com" ergens in een of meer "received:" headers staan:
Received: from hotmail.com (bla bla) by ...
Received: from blabla by hotmail.com ...
In "op.me" staat een aardig voorbeeldje (paragraaf 5.1.4.5. check_eoh). In dat voorbeeld wordt een ruleset gekoppeld aan de "Message-Id:" header. Als die ruleset wordt aangeroepen (d.w.z. de "Message-Id:" header is aanwezig) dan wordt een globale vlag gezet. Nadat de laatste header gelezen is wordt dan in de ruleset "check_eoh" getest of die betreffende vlag geset werd.
Zo zou je ook een ruleset kunnen koppelen aan de "From:" header, waarin je een vlag zet als in het afzender-adres "@hotmail.com" voorkomt. Indien gewenst kan je diezelfde ruleset ook koppelen aan de "resend-from:", "sender:" enz. headers. Verder kan je diezelfde ruleset ook aanroepen in "Local_check_mail" om de "envelope sender" te checken. Je maakt een tweede ruleset, gekoppeld aan de "Received:" headers, waarin je een tweede vlag zet als "hotmail.com" in de received header voorkomt. In ruleset "check_eoh" test je dan die twee vlaggen. Als je een afzender had afkomstig van het "hotmail.com" domain dan moet je ook een overeenkomstige "Received:" header gehad hebben. Niet vergeten om beide vlaggen weer te resetten! Veel ingwikkelder dan het voorbeeldje van paragraaf 5.1.4.5 hoeft het niet te worden.
Is deze controle waterdicht? Nee zeker niet.
Elke afzender kan in principe alvast een "Received:" header in zijn mailtje zetten, speciaal om jouw filter te onzeilen. Kwaadwillende afzenders met een eigen domain kunnen ook een host name toekennen als "hotmail.com.some.evil.domain", en dan komen ze ook door het filter heen. Maar de meeste troep zul je er wel mee tegenhouden.
Sarcastic mode on:
Lange read maar ik wil niet meer het risico lopen om voor blater uitgemaakt te worden :D
Als ik in het onderstaande uit sendmail documentatie citeer dan is dat uit de file "op.me" van sendmail 8.11.6. Op mijn Slackware 8.0 is dat: /usr/doc/sendmail/op/op.me
Mijn eerste gedachte was om het in de ruleset "Local_check_mail" op te lossen. Als je kijkt naar het begin van de ruleset "Basic_check_mail" dan worden daar enkele controles op de afzender gedaan. Eerst wordt het domain van de (envelope) sender bekeken. Als dat "localhost", "localhost.some.domain" of "[127.0.0.1]" is dan moet de macro $&{client_name} expanderen tot een "local client". Idem als de afzender helemaal geen domain name specificeert. Ik dacht dit over te kunen nemen in "Local_check_mail". Een paar kleine aanpassingen om te testen op "hotmail.com" i.p.v. "localhost", en klaar is Kees. Maar waarschijnlijk gaat dat niet werken.
In mail afkomstig van hotmail.com tref je headers aan als onderstaand:
Received: from hotmail.com (f213.law7.hotmail.com [216.33.237.213])
by mail.mitch-it.com (8.9.3/8.9.3) with ESMTP id VAA22455
for <michel@mitch-it.com>; Sun, 14 Apr 2002 21:33:34 +0200
En als dan zoekt in de documentatie (op.me) naar ${client_name} dan vind je:
${client_name}
The host name of the SMTP client. This may be
the client's bracketed IP address in the form [
nnn.nnn.nnn.nnn ] if the client's IP address is
not resolvable, or if it is resolvable but the IP
address of the resolved hostname doesn't match
the original IP address. Defined in the SMTP
server only.
Met de "Recieved:" header die ik hieboven citeerde krijg je dan al heel snel het vermoeden dat ${client_name} in dit geval zal expanderen tot het "bracketed IP address" en _niet_ tot "hotmail.com". Daar hebben we dus niets aan. Een andere complicatie is dat mail via een van je eigen lager gewaardeerde MX hosts binnen kan komen. In dat geval dan ben je ook de oorspronkelijke client kwijt. Bovendien zou je op deze manier alleen de "envelope sender" controleren en niet de "header sender".
Kan het nog anders?. Ja, het is ook mogelijk om willekeurige headers van een mailtje te analyseren. Je zou de "from:" header (en eventueel "resend-from:", "sender:", ...) kunnen controleren. Als daar "@hotmail.com" in voorkomt dan moet ook "hotmail.com" ergens in een of meer "received:" headers staan:
Received: from hotmail.com (bla bla) by ...
Received: from blabla by hotmail.com ...
In "op.me" staat een aardig voorbeeldje (paragraaf 5.1.4.5. check_eoh). In dat voorbeeld wordt een ruleset gekoppeld aan de "Message-Id:" header. Als die ruleset wordt aangeroepen (d.w.z. de "Message-Id:" header is aanwezig) dan wordt een globale vlag gezet. Nadat de laatste header gelezen is wordt dan in de ruleset "check_eoh" getest of die betreffende vlag geset werd.
Zo zou je ook een ruleset kunnen koppelen aan de "From:" header, waarin je een vlag zet als in het afzender-adres "@hotmail.com" voorkomt. Indien gewenst kan je diezelfde ruleset ook koppelen aan de "resend-from:", "sender:" enz. headers. Verder kan je diezelfde ruleset ook aanroepen in "Local_check_mail" om de "envelope sender" te checken. Je maakt een tweede ruleset, gekoppeld aan de "Received:" headers, waarin je een tweede vlag zet als "hotmail.com" in de received header voorkomt. In ruleset "check_eoh" test je dan die twee vlaggen. Als je een afzender had afkomstig van het "hotmail.com" domain dan moet je ook een overeenkomstige "Received:" header gehad hebben. Niet vergeten om beide vlaggen weer te resetten! Veel ingwikkelder dan het voorbeeldje van paragraaf 5.1.4.5 hoeft het niet te worden.
Is deze controle waterdicht? Nee zeker niet.
Elke afzender kan in principe alvast een "Received:" header in zijn mailtje zetten, speciaal om jouw filter te onzeilen. Kwaadwillende afzenders met een eigen domain kunnen ook een host name toekennen als "hotmail.com.some.evil.domain", en dan komen ze ook door het filter heen. Maar de meeste troep zul je er wel mee tegenhouden.
Sarcastic mode on:
Lange read maar ik wil niet meer het risico lopen om voor blater uitgemaakt te worden :D
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
