http://news.zdnet.com/2100-1009_22-5560664.html Precis: Spam levels expected to rise with suddenness soon, as blacklists become less effective. -- -- dman
(Continue reading)Dallman Ross wrote:<> http://news.zdnet.com/2100-1009_22-5560664.html <> <> Precis: Spam levels expected to rise with suddenness <> soon, as blacklists become less effective. The "trick" of sending out spam via the hosts' legitimate mail relays has been seen in the wild for about 18 months now. It's not new, just new to the media :-/ (AOL reported seeing it that long ago, anyway) There are a number of fixes, of course: 1a. Separate your outgoing relays from your inbound MX hosts. Some of the trojans do a PTR lookup on their address, then an MX query on the forward zone. 1b. Configure your MX hosts to not accept mail from INSIDE your network and configure your outbound relays to not accept mail from OUTSIDE your network. 2. Enable SMTP AUTH 3. Implement rate limiting on outbound email The thing that seems to be overlooked about this spammer trick is that it puts the cost exactly where it ought to be -- if your network tolerates zombie hosts and spammers, then YOUR relays get hammered, not mine (well, at least yours get hit before mine do). Finally, some motivation for companies like comcast and verizon to clean up their acts.
The problem with 1a and 1b is that some networks won't accept mail from non mx hosts. Curtis R A Lichtensteiger wrote:(Continue reading)>Dallman Ross wrote: > ><> http://news.zdnet.com/2100-1009_22-5560664.html ><> ><> Precis: Spam levels expected to rise with suddenness ><> soon, as blacklists become less effective. > >The "trick" of sending out spam via the hosts' legitimate mail relays >has been seen in the wild for about 18 months now. It's not new, just >new to the media :-/ (AOL reported seeing it that long ago, anyway) > >There are a number of fixes, of course: > > 1a. Separate your outgoing relays from your inbound MX hosts. > Some of the trojans do a PTR lookup on their address, then > an MX query on the forward zone. > 1b. Configure your MX hosts to not accept mail from INSIDE your > network and configure your outbound relays to not accept mail > from OUTSIDE your network. > > 2. Enable SMTP AUTH > > 3. Implement rate limiting on outbound email > >The thing that seems to be overlooked about this spammer trick is that >it puts the cost exactly where it ought to be -- if your network >tolerates zombie hosts and spammers, then YOUR relays get hammered, not >mine (well, at least yours get hit before mine do). Finally, some >motivation for companies like comcast and verizon to clean up their >acts. > >Reto, not too unhappy > >
(Continue reading)Curtis Maurand wrote:{Edited to fix top posting} <> R A Lichtensteiger wrote: <> <> >There are a number of fixes, of course: <> > <> > 1a. Separate your outgoing relays from your inbound MX hosts. <> > Some of the trojans do a PTR lookup on their address, then <> > an MX query on the forward zone. <> > 1b. Configure your MX hosts to not accept mail from INSIDE your <> > network and configure your outbound relays to not accept mail <> > from OUTSIDE your network. <> The problem with 1a and 1b is that some networks won't accept mail from <> non mx hosts. Curtis, Are you referring to SPF or to the silliness that Verizon has implemented? Or something else entirely? SPF isn't constrained to MXes; you can "announce" any host as a valid mail relay for your domain. Verizon's probe back at the MX to see if the username is valid is a pimple on the ass of the Internet for sure, but the back query would still work in the above case. If something else, can you cite? I'm ignorant about who might have
(Continue reading)R A Lichtensteiger wrote: >Curtis Maurand wrote: > >{Edited to fix top posting} > ><> R A Lichtensteiger wrote: ><> ><> >There are a number of fixes, of course: ><> > ><> > 1a. Separate your outgoing relays from your inbound MX hosts. ><> > Some of the trojans do a PTR lookup on their address, then ><> > an MX query on the forward zone. ><> > 1b. Configure your MX hosts to not accept mail from INSIDE your ><> > network and configure your outbound relays to not accept mail ><> > from OUTSIDE your network. > ><> The problem with 1a and 1b is that some networks won't accept mail from ><> non mx hosts. > >Curtis, > >Are you referring to SPF or to the silliness that Verizon has >implemented? Or something else entirely? > >SPF isn't constrained to MXes; you can "announce" any host as a valid >mail relay for your domain. > >Verizon's probe back at the MX to see if the username is valid is a >pimple on the ass of the Internet for sure, but the back query would >still work in the above case. > >If something else, can you cite? I'm ignorant about who might have >implemented what ... > >Reto (Errm ... perhaps off list as we're straying ...) > >I get the following from both bellsouth and verizon. Feb 3 18:33:42 [postfix/smtp] 1F09C203B9A: to=<ALN <at> SKYPOINT.COM>, relay=minuet. skypoint.net[199.86.32.2], delay=52414, status=deferred (host minuet.skypoint.ne t[199.86.32.2] said: 451 4.1.8 Domain of sender address apache <at> orion.xyonet.com does not resolve (in reply to RCPT TO command)) Feb 3 18:33:42 [postfix/smtp] C4961203EA8: to=<GARDENELF <at> VERIZON.NET>, relay=re lay.VERIZON.NET[206.46.170.12], delay=167144, status=deferred (host relay.VERIZO N.NET[206.46.170.12] said: 450 Unable to find orion.xyonet.com (in reply to RCPT TO command)) both of those messages are the results from an ecommerce system. both are sending from a machine that posts via "/usr/sbin/sendmail -t" instead of making a connection. the relevant section on the source address of the email: ;; QUESTION SECTION: ;141.141.49.69.in-addr.arpa. IN PTR ;; ANSWER SECTION: 141.141.49.69.in-addr.arpa. 10800 IN PTR orion.xyonet.com. So you see, mail confirmation of the users orders get rejected. I'm
At 18:16 2005-02-03 +0100, Dallman Ross did say:(Continue reading)>http://news.zdnet.com/2100-1009_22-5560664.html > >Precis: Spam levels expected to rise with suddenness >soon, as blacklists become less effective.Er, spammers have been using trojans for a while now already. Yes, traditionally, the user's own PC is converted into a mail server and it delivers mail directly. With some large ISPs (earthlink comes to mind) blocking outgoing SMTP originating from user systems, this technique isn't very effective. However, viruses have for some time used the user's own ISP mail server (or at least that of the forged address snarfed from their saved email) to deliver messages, thereby lending some apparent legitimacy to the message (for instance, you can't block them using a dial-up list type DNSBL, because the machine passing the message to your host is an actual ISP mailserver, not the user's own machine). Yes, blacklists aren't particularly effective against this chuff. Ironically, effecive post-reception filters are still successful at eliminating virtually all the spam, but once they've brought the crap INTO my server is when I get especially pissed about it - the messages rejected during the SMTP connection have a minimal impact - they don't generate a lot of net traffic or CPU load (though gobs and gobs of them can still borderline a DoS). once you've forced your way into my mail host, you're providing me with further identifyable information - complete headers, URLs in the spew, etc - which can be used to identify the spammer. Plus, for those areas which have anti-spam "laws" (such as they are), actually having the spam in hand is a crucial part of being able to prosecute them - rejecting a billion SMTP connections based on the originating IP wouldn't prove to be concrete evidence that those POTENTIAL messages would have actually been spam.
PSE-L <at> mail.professional.org (Professional Software Engineering) writes:(Continue reading)> One solution (until the miscreants decide to rummage PCs looking for > login data) is for affected ISPs to start REQUIRING SMTP > authenticationThis solution of smtp authentication assumes that creating accounts with the given provider is secure against fraudulent signups. If fraudulent account signups can be easily scripted/automated, then an smtp authenticated server becomes a de facto open relay, since IP access from external networks is usually not restricted (and usually enhanced via listening on port 587 for access via external networks that block port 25). Whats more, this allows the possibility (and already practiced) spamming vector of: A) Spammer signs up fraudulent account B) Spammer then spews from numerous zombie hosts through provider's ASMTP rotor using fraudulent login, thus continuing to leverage zombies for obfuscation of origin, while at the same time capitalizing on the good reputation/trust the provider has with other networks by routing spam from: 'random zombie host' -> 'provider's ASMTP server' -> Internet ...which of course also avoids the traditional DNSBL's. ...and then there's always brute force attacks, which Alan Ralsky has apparently been experimenting with since at least 2003. These avenues of attack can be prevented if they're considered when implementing authenticated SMTP, but that's unfortunately not the immediate reality.
At 17:25 2005-02-03 -0500, Robert Arnold wrote: >This solution of smtp authentication assumes that creating accounts with >the given provider is secure against fraudulent signups. If fraudulent That's a matter between the ISP and their customer base. The point of using SMTP Auth is that only customers have access to your mailserver. Sure, the login can be compromised - but it tracks directly to a customer, and can be independantly disabled. I wish ISPs would adopt a "we're going to charge your credit card if you send spam" policy. Right there on your signup. >account signups can be easily scripted/automated, Uh, I'm not talking about Yahoo, Hotmail, and other freemail providers. I'm talking about real ISPs, providing dialup lines, etc. There needs to be more accountability. Heck, if ISPs maintained a list of deadbeat customers, tracking names associated with creditcards (and, say, the verifyable billing addresses associated with same), there could be an ISP blacklist to keep problematic users from signing up for accounts with ISPs which want to stick to reputable users. >25). Whats more, this allows the possibility (and already practiced) >spamming vector of: > > A) Spammer signs up fraudulent account Solution: ISP requires use of credit card or electronic cheque for signup. Sure, they can use stolen materials -- but that handily turns their offence from some vague and hardly prosecuteably "spam" thing into a very real credit card fraud and/or identity theft matter, where the authorities may take more of a direct interest in prosecuting someone. > B) Spammer then spews from numerous zombie hosts through > provider's ASMTP rotor using fraudulent login, .. which could be disabled at will by the ISP once they realize there's a spam situation. This beats the turd out of relaying for everything that has a From: at the domain (regardless of who is ACTUALLY sending(Continue reading)
Toen wij Robert Arnold kietelden, kwam er dit uit:> Professional Software Engineering: >> One solution (until the miscreants decide to rummage PCs looking for >> login data) is for affected ISPs to start REQUIRING SMTP >> authentication > This solution of smtp authentication assumes that creating accounts > with the given provider is secure against fraudulent signups. If > fraudulent account signups can be easily scripted/automated, then an > smtp authenticated server becomes a de facto open relay, since IP > access from external networks is usually not restricted (and usually > enhanced via listening on port 587 for access via external networks > that block port 25).Important is: SMTP authentication for existing local users. Access from external networks to the SMTP-server is blocked by most ISPs. There is no real need to open it up for smtps. My ISP is secure against fraudulent signups, so it allows sending messages with SSL through port 465. That allows me to use my portable PC via external networks, without sending plain passwords over a stranger's lines. -- -- Grtz, Ruud
"Ruud H.G. van Tol" <rvtol <at> isolution.nl> writes:> Important is: SMTP authentication for existing local users. > > Access from external networks to the SMTP-server is blocked by most > ISPs. There is no real need to open it up for smtps.SPF requires it. If you're away from your "home" internet connection and connected via some other network, and you want to send email using your "usual" address, you're going to need to use your ISP's mailserver, otherwise you'll fail an SPF check on the recipient's end. Regards, Robert Arnold
At 18:37 2005-02-03 -0500, Robert Arnold wrote: > > Access from external networks to the SMTP-server is blocked by most > > ISPs. There is no real need to open it up for smtps. > >SPF requires it. If you're away from your "home" internet connection and >connected via some other network, and you want to send email using your >"usual" address, you're going to need to use your ISP's mailserver, >otherwise you'll fail an SPF check on the recipient's end.SPF is already broken for users who cannot relay via their own mailserver (say, connected via Earflink but they have a domain hosted elsewhere). Plus, both SPF and Domainkeys present specific problems for listserves and mail forwarding services, which must change how they do things or risk generating bounced mail from delivery endpoints. --- Sean B. Straw / Professional Software Engineering Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html> Please DO NOT carbon me on list replies. I'll get my copy from the list.
Toen wij Robert Arnold kietelden, kwam er dit uit:> Ruud H.G. van Tol: >> Important is: SMTP authentication for existing local users. >> >> Access from external networks to the SMTP-server is blocked by most >> ISPs. There is no real need to open it up for smtps. > SPF requires it. If you're away from your "home" internet connection > and connected via some other network, and you want to send email > using your "usual" address, you're going to need to use your ISP's > mailserver, otherwise you'll fail an SPF check on the recipient's end.I don't endorse SPF, but an ssh-tunnel would also do. -- -- Grtz, Ruud
"Ruud H.G. van Tol" <rvtol <at> isolution.nl> writes:> I don't endorse SPF, but an ssh-tunnel would also do.While ssh tunneling may be an option for some, I doubt large ISPs will ever consider it as "Best Practice" for sending mailRegards, Robert Arnold
Toen wij Robert Arnold kietelden, kwam er dit uit:> Ruud H.G. van Tol: >> I don't endorse SPF, but an ssh-tunnel would also do. > While ssh tunneling may be an option for some, I doubt large ISPs will > ever consider it as "Best Practice" for sending mailThe context is: SPF .AND. external network. For that combination, I don't see why not. -- -- Grtz, Ruud
"Ruud H.G. van Tol" <rvtol <at> isolution.nl> writes:>> While ssh tunneling may be an option for some, I doubt large ISPs will >> ever consider it as "Best Practice" for sending mailYou seem to be implying that validating SPF checks is an obscure concern, and can therefore be pacified with an obscure solution. I don't know what the situation is in your neck of the woods, but the larger American ISPs are currently working to make SPF (along with DomainKeys) pragmatic solutions to sender authentication. If they wish for that to happen, then the transition has to be easy if not nearly transparent to the end user. Requesting that Aunt Nellie change her outbound mail server/port is realistic, expecting her to port forward via ssh is not. I'll end with that, as I've clearly strayed off-topic. Regards, Robert Arnold
On 03, 2005 at 09:45:26AM -0800, Professional Software Engineering wrote: > At 18:16 2005-02-03 +0100, Dallman Ross did say: > >http://news.zdnet.com/2100-1009_22-5560664.html > > > >Precis: Spam levels expected to rise with suddenness > >soon, as blacklists become less effective. > > Er, spammers have been using trojans for a while now already. Yes, > traditionally, the user's own PC is converted into a mail server and > it delivers mail directly. Yes, and that's a crucial difference. > However, viruses have for some time used the user's own ISP mail > server (or at least that of the forged address snarfed from their > saved email) to deliver messages, thereby lending some apparent > legitimacy to the message (for instance, you can't block them using a > dial-up list type DNSBL, because the machine passing the message to > your host is an actual ISP mailserver, not the user's own machine). The forgeries are a good tip for Virus Snaggers(tm), for example. It looks for them. But, look: if a worm or zombie spam now gets sent by the virtual server coded into the Trojan/zombie/worm program itself, it's one thing. The mail typically arrives at the recipient's server with a fake server name and very few Received headers. (Vsnag looks for that kind of thing too.) But if the mail is going to go out via the ISP's usual channels, then the heuristic for identifying it gets a bit tougher. That's what caught my interest. -- -- dman(Continue reading)
On Thu, 03 Feb 2005 21:56:07 +0100, Dallman Ross <dman <at> nomotek.com> wrote: > On 03, 2005 at 09:45:26AM -0800, Professional Software > Engineering wrote: > > Er, spammers have been using trojans for a while now already. Yes, > > traditionally, the user's own PC is converted into a mail server and > > it delivers mail directly. > > Yes, and that's a crucial difference. Maybe we will finally see ISPs take proactive measures (limiting outbound email to 500/day or some number) and shutting off the pipe the instant spam is reported. The large ISPs still have the attitutde that the spammer/zombie si their 'customer.' That has to change and the access to outbound email has to be cut-off very quickly until the infected machines can be cleaned up. > that kind of thing too.) But if the mail is going to go out via > the ISP's usual channels, then the heuristic for identifying it > gets a bit tougher. That's what caught my interest. ISPs will be blacklisted for allowing spam through if they don't do anything about it. -- -- <http://2blog.kreme.com/>
On Thu, 3 Feb 2005, Cerebus the Aardvark wrote: > ISPs will be blacklisted for allowing spam through if they don't do > anything about it.They already are blacklisted, and many dont do a thing about it (except maybe threaten to sue the blacklists). -Dan
> But, look: if a worm or zombie spam now gets sent by the virtual > server coded into the Trojan/zombie/worm program itself, it's one > thing. The mail typically arrives at the recipient's server with > a fake server name and very few Received headers. (Vsnag looks for > that kind of thing too.) But if the mail is going to go out via > the ISP's usual channels, then the heuristic for identifying it > gets a bit tougher. That's what caught my interest.New trojans even sent out spam directly from the users outlook, hotmail, yahoo etc. However 95% of spammers are relay on URL's and that's a major factor for most AI. Blacklisting url's is more popular these days. Marek
At 21:56 2005-02-03 +0100, Dallman Ross wrote: >But, look: if a worm or zombie spam now gets sent by the virtual >server coded into the Trojan/zombie/worm program itself, it's one >thing. The mail typically arrives at the recipient's server with >a fake server name and very few Received headers. _typically_ (i.e. MOST malware) yes. There's a small number that relay through legit ISP SMTP hosts (and no, not your own inbound servers). Not forged EHLO either. It isn't a new technique there, and since spammers have been shifting towards virus/trojan applications to take over computers for bandwith, address lists, and obfuscating the true source of the spam, this "new" twist with spam should come as no surprise since it's already been employed with viruses. >the ISP's usual channels, then the heuristic for identifying it >gets a bit tougher. That's what caught my interest. The heuristic to catch the message via header-only criteria would be very difficult indeed. IIRC, SA spots forged Outbreak headers - that may be something to check for with spam relaying. --- Sean B. Straw / Professional Software Engineering Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html> Please DO NOT carbon me on list replies. I'll get my copy from the list.
Professional Software Engineering wrote: > At 21:56 2005-02-03 +0100, Dallman Ross wrote: > > >the ISP's usual channels, then the heuristic for identifying it gets > >a bit tougher. That's what caught my interest. > > The heuristic to catch the message via header-only criteria would be > very difficult indeed. IIRC, SA spots forged Outbreak headers - that > may be something to check for with spam relaying.Agreed. I have had a forged-"HOTHOO" (as I call it -- that's even the name of my var) recipe set in place for three years now, and it works very well indeed. (Headers-only, as usual.) -- -- dman
> -----Original Message----- > From: Sean B. Straw > > At 18:16 2005-02-03 +0100, Dallman Ross did say: > >http://news.zdnet.com/2100-1009_22-5560664.html > > > >Precis: Spam levels expected to rise with suddenness > >soon, as blacklists become less effective. > > Er, spammers have been using trojans for a while now already. Yes, > traditionally, the user's own PC is converted into a mail > server and it > delivers mail directly. With some large ISPs (earthlink > comes to mind) > blocking outgoing SMTP originating from user systems, this > technique isn't > very effective. > > However, viruses have for some time used the user's own ISP > mail server (or > at least that of the forged address snarfed from their saved > email) to > deliver messages, thereby lending some apparent legitimacy to > the message > (for instance, you can't block them using a dial-up list type DNSBL, > because the machine passing the message to your host is an actual ISP > mailserver, not the user's own machine). > > Yes, blacklists aren't particularly effective against this > chuff. Well not sure where your getting your info from but my maillog and the feedback from many other mail server admins seems to refute your stand. We block literally thousands of emails on a weekly basis using those same DNSBL lists. Sendmail configured to use the 'dnsbl' FEATURE with one or more lists is a highly effective method of spam stomping. These lists don't care what address there is on the inbound email, only what IP address was given by the relays (or the server it's self) as to where it was coming from. As for virii worms using the ISP's mail servers for relaying, not true. The SMTP server in the virii does it's own DNS look up for the target domains MX record and then does the connection it's self. You might be confusing 'zombie' spam from spam sent from spam servers that have not been identified or those dynamic IP ranges that were missed. Once identified it's rare you see mail from that IP again once they are on the list(s). > Ironically, effecive post-reception filters are > still successful > at eliminating virtually all the spam, No more so than a good 'dnsbl' setup at the MTA level is/was. In fact it's best to do both so your bases are covered. The funny thing is that one of the most popular post-reception filters (Spamassassin) uses DNSBL lists also and I'm sure a few others do as well. So they too will be affected by this since they look for the same info and it will no longer be as effective or useful as it was before. > but once they've brought the crap > INTO my server is when I get especially pissed about it - the > messages > rejected during the SMTP connection have a minimal impact - > they don't > generate a lot of net traffic or CPU load (though gobs and > gobs of them can > still borderline a DoS). once you've forced your way into my > mail host, > you're providing me with further identifyable information - complete > headers, URLs in the spew, etc - which can be used to identify the > spammer. Plus, for those areas which have anti-spam "laws" > (such as they > are), actually having the spam in hand is a crucial part of > being able to > prosecute them - rejecting a billion SMTP connections based on the > originating IP wouldn't prove to be concrete evidence that > those POTENTIAL > messages would have actually been spam. > I'd prefer to not waste the CPU cycles in allowing these onto my server.(Continue reading)
At 13:20 2005-02-03 -0600, Pettit, Paul wrote:
> > (for instance, you can't block them using a dial-up list type DNSBL,
> > because the machine passing the message to your host is an actual ISP
> > mailserver, not the user's own machine).
> >
> > Yes, blacklists aren't particularly effective against this
> > chuff.
>
>Well not sure where your getting your info from but my maillog and the
>feedback from many other mail server admins seems to refute your stand.
I *DID* *NOT* say that blacklists are ineffective. What I said is that
they're ineffective for blocking zombie-spew being relayed via legitimate
ISPs (by CUSTOMERS of those ISPs) - that'd be the "this chuff" which was
outlined in the paragraphs preceeding my DNSBL comment.
Go grab another coffee and put less milk in it this time.
>As for virii worms using the ISP's mail servers for relaying, not true.
Yes, the vast majority of viruses deliver directly from the infected host
to your MX. There are tens upon tens of thousands of viruses - every last
one of them doesn't do it's thing the exact same way as all the others.
I assure you, there are viruses which relay using either the mailserver for
the infected user or the mailservers associated with the email addresses
they're forging themselves to be from - while outbound SMTP servers are not
necessarily the same as the inbound ones (for small outfits, they often
are, but larger shops generally segregate them on performance grounds), and
the latter are the only ones which have a defined standard for identifying
in DNS, since such viruses are most often extracting addresses from saved
email, they've got access to headers right there. It's all pretty trivial
to do.
I am NOT confusing a bogus hostname provided in the SMTP EHLO greeting here
either. Here's an example set of received headers from malware using an
ISP mailserver:
Received: from mwinf0809.wanadoo.fr (smtp8.wanadoo.fr [193.252.22.23])
by **DELTED** (8.12.10/8.12.10) with ESMTP id i98KiF2O003931
for <**DELETED**>; Fri, 8 Oct 2004 13:44:16 -0700
(Continue reading)
Toen wij Pettit, Paul kietelden, kwam er dit uit:> Well not sure where your getting your info from but my maillog and the > feedback from many other mail server admins seems to refute your > stand.You fail to grok what Sean wrote. Please read it again. -- -- Grtz, Ruud
Toen wij Dallman Ross kietelden, kwam er dit uit:> http://news.zdnet.com/2100-1009_22-5560664.html > Precis: Spam levels expected to rise with suddenness > soon, as blacklists become less effective.I see this as an advantage. A last, ISPs are forced to take prompt measures against infected machines of customers (or become and remain blacklisted). -- -- Grtz, Ruud
RSS Feed