Re: Re: Virus emails
Title: Message MS Corporation Security Center [EMAIL PROTECTED]
Re: Virus emails
On Wed, Sep 24, 2003 at 12:44:50PM -0500, Gunnar Wolf <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows dijo [Wed, Sep 24, 2003 at 01:10:57PM -0400]: > > > And I insist... Do you want to stop every mail which is (peeking at my > > > inbox) between 1887 and 2183 bytes long just because it might be a > > > virus? > > > > Um, those are line counts, not byte counts. 1889 lines is about 140k > > on the one I just received. > > Are they? hmmm... Ok, that weakens my statement ;-) But anyway, there > are way too many 140K legitimate messages. Heh, good one :-) Daniel -- / Daniel Burrows <[EMAIL PROTECTED]> ---\ | "Fluble, the others want you to know that we| | have you surrounded with tranquilizer rifles | | and are prepared to use them. Again." -- Fluble | \- The Turtle Moves! -- http://www.lspace.org /
Re: Virus emails
On Wed, Sep 24, 2003 at 10:05:54AM -0500, Gunnar Wolf <[EMAIL PROTECTED]> was heard to say: > Wouter Verhelst dijo [Wed, Sep 24, 2003 at 09:03:39AM +0200]: > > > I don't think so - And if so, this could break many client MTAs. > > > According to the protocol definition [1], > > > > [...] > > > > > [1] http://www.ietf.org/rfc/rfc0821.txt > > > > MTAs that still stick to nothing but RFC821 are horribly outdated > > nowadays. Modern MTAs support the ESMTP SIZE command, which should take > > care of this problem. > > > > Of course, that assumes the other end isn't lying, which probably is an > > incorrect assumption... > > And I insist... Do you want to stop every mail which is (peeking at my > inbox) between 1887 and 2183 bytes long just because it might be a > virus? Um, those are line counts, not byte counts. 1889 lines is about 140k on the one I just received. Daniel -- / Daniel Burrows <[EMAIL PROTECTED]> ---\ |He had a terrible memory. He remembered everything. | \-Evil Overlord, Inc: planning your future today. http://www.eviloverlord.com-/
Re: Virus emails
On Tue, 2003-09-23 at 03:44, Lars Wirzenius wrote: > I favor this approach over simple applications of violence, such as > using an axe on any computer infected by a virus. Why punish the hardware for what is clearly a wetware problem? signature.asc Description: This is a digitally signed message part
Re: Virus emails
On Mon, Sep 22, 2003 at 04:53:16PM +0200, Matthias Urlichs wrote: > The list of hardware required to stop this spam unfortunately seems to > include a time machine. Just because you can't afford one... Another (cheaper) solution though would be to pull the plug ;-). There! No more spam problems! (PS: Make sure you pull *all* the required plugs, just in case your computer has multiple redundant connections...) -- Brian May <[EMAIL PROTECTED]>
Re: Virus emails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 23 September 2003 01:48, Gunnar Wolf wrote: > Mike Hommey dijo [Tue, Sep 23, 2003 at 12:28:44AM +0200]: > > Maybe I'm wrong, but I think an MTA rejecting a mail because of oversized > > body doesn't have to get the whole body before rejecting the mail. Based > > on this, it should be possible to reject the mail before it gets fully > > transfered to the server. > > I don't think so - And if so, this could break many client MTAs. The client-MTA in question has a name: swen. I wouldn't give a rat's ass, as our Lacrosse-coach says ... in other words, there are no rules in war, not even RFCs. Or am I missing something? Uli -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/cKYswVdGSYi8Mq8RAkilAKC1VolbmQdMbkztBWEtkHXReK+0lACeNezi rETrxn/QCo98I7hTz8qvkig= =9/C/ -END PGP SIGNATURE-
Re: Virus emails
Hi, Steve Lamb wrote:
> What would help is to be able to block an IP once it's been hit.
That won't work for people who have a secondary MX record.
I've set up a second mailer which simply rejects everything (one that
speaks correct SMTP... :-/ ), and the source addresses which flood me
with viruses get redirected to that when they connect to port 25.
*Sigh*.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Sacher's Observation:
Some people grow with responsibility -- others merely swell.
Re: Virus emails
Hi,
Graham Wilson wrote:
> On Mon, Sep 22, 2003 at 04:53:16PM +0200, Matthias Urlichs wrote:
> > A pure MTA solution would still need to scan the body and thus would
> > still eat your bandwidth.
>
> i have postfix's body_checks setup to reject lines that match the
> following regular expression (this is the first line of the base64
> encoded virus):
>
> /^TVqQAAME\/\/8AALgAQAA
>A$/
>
> i'm not sure when postfix closes the connection,
It nees to receive all the data. Otherwise the sender will treat the closed
connection as a temporary failure and try again a few minutes later.
An aggressive solution would remember the IP address and reject the next email
from that destination, but I don't think postfix does that.
--
Matthias Urlichs|{M:U} IT Design @ m-u-it.de |[EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.debian.net
- -
Kramer's Law:
You can never tell which way the train went by looking at the tracks.
Re: Virus emails
On Wed, Sep 24, 2003 at 07:37:03AM -0700, Steve Lamb wrote: > > Runs spamc twice. Usually it won't matter, but with higher traffic, the load > > will increase for obvious reasons... > > spamc isn't run twice. exiscan-acl *can* run the mail through SA as a > test. It doesn't /have/ to. So if one is using sa-exim one just does not > have exiscan-acl check SA. That's not how I interpreted what you said: > It's generally accepted that for robust handling of Spam SA-Exim is the > better route. For simple handling as well as virus scanning Exiscan-ACL > is the better route. Lots of people just use both. I thought you meant both as in both Exiscan-ACL and SA-Exim. -- 2. That which causes joy or happiness.
Re: Virus emails
On Wed, Sep 24, 2003 at 06:33:45PM +0200, Wouter Verhelst wrote: > Op wo 24-09-2003, om 17:05 schreef Gunnar Wolf: > > And I insist... Do you want to stop every mail which is (peeking at my > > inbox) between 1887 and 2183 bytes long just because it might be a > > virus? > > Hm. I was under the impression that they were a lot larger. i think he might mean lines. the messages seem to average about 250 kbytes. -- gram signature.asc Description: Digital signature
Re: Virus emails
Daniel Burrows dijo [Wed, Sep 24, 2003 at 01:10:57PM -0400]: > > And I insist... Do you want to stop every mail which is (peeking at my > > inbox) between 1887 and 2183 bytes long just because it might be a > > virus? > > Um, those are line counts, not byte counts. 1889 lines is about 140k > on the one I just received. Are they? hmmm... Ok, that weakens my statement ;-) But anyway, there are way too many 140K legitimate messages. Greetings -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Virus emails
Op wo 24-09-2003, om 17:05 schreef Gunnar Wolf: > And I insist... Do you want to stop every mail which is (peeking at my > inbox) between 1887 and 2183 bytes long just because it might be a > virus? Hm. I was under the impression that they were a lot larger. OK, never mind... -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "Stop breathing down my neck." "My breathing is merely a simulation." "So is my neck, stop it anyway!" -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Virus emails
Wouter Verhelst dijo [Wed, Sep 24, 2003 at 09:03:39AM +0200]: > > I don't think so - And if so, this could break many client MTAs. > > According to the protocol definition [1], > > [...] > > > [1] http://www.ietf.org/rfc/rfc0821.txt > > MTAs that still stick to nothing but RFC821 are horribly outdated > nowadays. Modern MTAs support the ESMTP SIZE command, which should take > care of this problem. > > Of course, that assumes the other end isn't lying, which probably is an > incorrect assumption... And I insist... Do you want to stop every mail which is (peeking at my inbox) between 1887 and 2183 bytes long just because it might be a virus? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Virus emails
On Wed, 24 Sep 2003 16:17:45 +0200 Josip Rodin <[EMAIL PROTECTED]> wrote: > Runs spamc twice. Usually it won't matter, but with higher traffic, the load > will increase for obvious reasons... spamc isn't run twice. exiscan-acl *can* run the mail through SA as a test. It doesn't /have/ to. So if one is using sa-exim one just does not have exiscan-acl check SA. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpy4YgfbXUsz.pgp Description: PGP signature
Re: Virus emails
On Tue, Sep 23, 2003 at 12:52:30PM -0700, Steve Lamb wrote: > > > Same here though I am sticking with SA-Exim because it saves the mail > > > in a certain range so I can throw it at the Bayesian classifier. > > > I usually don't have large enough partitions to hold all the spam (!) > > Certain range. Here it is things scored between 5 and 8. 5 is where > things are considered spam. 8 is where I reject things outright. 12 is where > autolearn is set. I want to send things in that range to the Bayesian > classifier so the score would creep up hopefully to the point of being > rejected. Comes out to about 1-2 a day. Even so, on most of my servers the traffic is much higher. :/ > > > It also has the option of teergrubing. > > > I'm a bit scared of turning it on, didn't (see|read) enough documentation > > for it. > > Simple concept, if a message scores high enough (25 is default) you just > string the connection out for 5 minutes. I'll have to turn that on then. > > > It's generally accepted that for robust handling of Spam SA-Exim is the > > > better route. For simple handling as well as virus scanning Exiscan-ACL > > > is the better route. Lots of people just use both. > > > Isn't that pretty wasteful? > > Depends on what you consider wasteful. Runs spamc twice. Usually it won't matter, but with higher traffic, the load will increase for obvious reasons... -- 2. That which causes joy or happiness.
Re: Virus emails
Op di 23-09-2003, om 01:48 schreef Gunnar Wolf: > Mike Hommey dijo [Tue, Sep 23, 2003 at 12:28:44AM +0200]: > > > > helps catching 95%... But the bandwidth is still used... I'm still > > > > looking for a pure MTA solution... > > > > > > A pure MTA solution would still need to scan the body and thus would still > > > eat your bandwidth. > > > > Maybe I'm wrong, but I think an MTA rejecting a mail because of oversized > > body > > doesn't have to get the whole body before rejecting the mail. Based on > > this, > > it should be possible to reject the mail before it gets fully transfered to > > the server. > > I don't think so - And if so, this could break many client MTAs. > According to the protocol definition [1], [...] > [1] http://www.ietf.org/rfc/rfc0821.txt MTAs that still stick to nothing but RFC821 are horribly outdated nowadays. Modern MTAs support the ESMTP SIZE command, which should take care of this problem. Of course, that assumes the other end isn't lying, which probably is an incorrect assumption... -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "Stop breathing down my neck." "My breathing is merely a simulation." "So is my neck, stop it anyway!" -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Virus emails
On Tue, 23 Sep 2003 21:07:46 +0200 Josip Rodin <[EMAIL PROTECTED]> wrote: > On Tue, Sep 23, 2003 at 10:43:30AM -0700, Steve Lamb wrote: > > Same here though I am sticking with SA-Exim because it saves the mail > > in a certain range so I can throw it at the Bayesian classifier. > I usually don't have large enough partitions to hold all the spam (!) Certain range. Here it is things scored between 5 and 8. 5 is where things are considered spam. 8 is where I reject things outright. 12 is where autolearn is set. I want to send things in that range to the Bayesian classifier so the score would creep up hopefully to the point of being rejected. Comes out to about 1-2 a day. > > It also has the option of teergrubing. > I'm a bit scared of turning it on, didn't (see|read) enough documentation > for it. Simple concept, if a message scores high enough (25 is default) you just string the connection out for 5 minutes. > > It's generally accepted that for robust handling of Spam SA-Exim is the > > better route. For simple handling as well as virus scanning Exiscan-ACL > > is the better route. Lots of people just use both. > Isn't that pretty wasteful? Depends on what you consider wasteful. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpAfnIiHxhgH.pgp Description: PGP signature
Re: Virus emails
On Tue, Sep 23, 2003 at 10:43:30AM -0700, Steve Lamb wrote: > > For now I'm using the SA-Exim method because even though it's clumsy (needs > > the .so file compiled from source so distribution isn't as trivial as an > > apt-get invocation), I used it before the Exiscan patch was available and it > > was reliable. (I'd welcome suggestions from other users about this issue.) > > Same here though I am sticking with SA-Exim because it saves the mail > in a certain range so I can throw it at the Bayesian classifier. I usually don't have large enough partitions to hold all the spam (!) > It also has the option of teergrubing. I'm a bit scared of turning it on, didn't (see|read) enough documentation for it. > It's generally accepted that for robust handling of Spam SA-Exim is the > better route. For simple handling as well as virus scanning Exiscan-ACL > is the better route. Lots of people just use both. Isn't that pretty wasteful? -- 2. That which causes joy or happiness.
Re: Virus emails
Steve Lamb dijo [Tue, Sep 23, 2003 at 10:29:51AM -0700]: > Gunnar Wolf <[EMAIL PROTECTED]> wrote: > > Steve Lamb dijo [Mon, Sep 22, 2003 at 07:21:05PM -0700]: > > > Gunnar Wolf <[EMAIL PROTECTED]> wrote: > > > > [1] http://www.ietf.org/rfc/rfc0821.txt > > > > And what does RFC2821 have to say about it? > > > I would not trust every MTA to implement newer versions of the RFC - > > However, it is up to you to decide ;-) > > Well that's the thing, isn't it. At some point we will have to work with > that document and not legacy documents. Besides, you're operating under the > impression that spamming software follow either. Ok... You got me on this one - I just went and checked the document. It is, however, quite a recent document (April 2001), and there are still too many people using older software. I prefer having the old, trusted phylosophy - Be strict on what you send, relaxed on what you receive. Now, I am not reading the whole document just to check this out. Skimming it, I found many reasons for the 'DATA' command to return a 4xx or 5xx error code, but didn't find a reason to interrupt the client. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Virus emails
On Tue, 23 Sep 2003 16:45:55 +0200 Josip Rodin <[EMAIL PROTECTED]> wrote: > For now I'm using the SA-Exim method because even though it's clumsy (needs > the .so file compiled from source so distribution isn't as trivial as an > apt-get invocation), I used it before the Exiscan patch was available and it > was reliable. (I'd welcome suggestions from other users about this issue.) Same here though I am sticking with SA-Exim because it saves the mail in a certain range so I can throw it at the Bayesian classifier. It also has the option of teergrubing. It's generally accepted that for robust handling of Spam SA-Exim is the better route. For simple handling as well as virus scanning Exiscan-ACL is the better route. Lots of people just use both. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpczfRvlVnu7.pgp Description: PGP signature
Re: Virus emails
On Tue, 23 Sep 2003 08:39:02 -0400 "H. S. Teoh" <[EMAIL PROTECTED]> wrote: > On Mon, Sep 22, 2003 at 08:46:15PM -0700, Steve Lamb wrote: > > Except it never hits SA nor do I even have procmail installed. Can't > > stand the ugly beast. > It never hits SA? Almost all Swen mails I got were caught by my bogofilter > + SA setup. (It only missed like 2-3 out of at least 5000 per day.) Exiscan-ACL gets the message before Spamassassin does. So the checks are: Exiscan-ACL says Malformed MIME? Reject. Clamav says Malware (virus, worms, trojans, etc)? Reject. Spamassassin says its spam? Reject. > I noticed this also. However, I found that some of the subnets I blocked > "rested" for several hours, and then started bombarding me again. So I'm > leaving the rules in for at least a couple o' days before cleaning out > those with 0 count. Hrm, well the cycle of when to remote and reset could be tuned for daily or weekly operation. :) -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpzy3zr8Pr0U.pgp Description: PGP signature
Re: Virus emails
You are aware Mutt is perfectly capable of responding to the list. Learn it, love it, USE IT! On Tue, 23 Sep 2003 10:20:46 -0500 Gunnar Wolf <[EMAIL PROTECTED]> wrote: > Steve Lamb dijo [Mon, Sep 22, 2003 at 07:21:05PM -0700]: > > Gunnar Wolf <[EMAIL PROTECTED]> wrote: > > > [1] http://www.ietf.org/rfc/rfc0821.txt > > And what does RFC2821 have to say about it? > I would not trust every MTA to implement newer versions of the RFC - > However, it is up to you to decide ;-) Well that's the thing, isn't it. At some point we will have to work with that document and not legacy documents. Besides, you're operating under the impression that spamming software follow either. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpUaCpPytag6.pgp Description: PGP signature
Re: Virus emails
Steve Lamb dijo [Mon, Sep 22, 2003 at 07:21:05PM -0700]: > Gunnar Wolf <[EMAIL PROTECTED]> wrote: > > [1] http://www.ietf.org/rfc/rfc0821.txt > > And what does RFC2821 have to say about it? I would not trust every MTA to implement newer versions of the RFC - However, it is up to you to decide ;-) -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Virus emails
On Tue, Sep 23, 2003 at 08:39:02AM -0400, H. S. Teoh wrote:
> > > What are the exim rules you used to catch these things?
> >
> > exiscan-acl calling clamav and dropping it with a 550. A full log
> > line would be:
> >
> > 2003-09-22 07:38:05 1A1RpB-0007Xd-Of H=(smtp21.singnet.com.sg)
> > [165.21.101.201] F=<[EMAIL PROTECTED]> rejected after DATA: This
> > message contains a viru s or other malware (Worm.Gibe.F).
>
> I see. Thanks for the info, I'll look it up.
exim4-daemon-heavy includes the Exiscan patch that allows one to scan for
malformed MIME, viruses and spam during the SMTP dialogue.
Install clamav-daemon and in the general settings block add:
av_scanner = clamd:/var/run/clamd.ctl
And in the ACL block after DATA, you put something like:
deny message = Message contains malware ($malware_name)
demime = *
malware = *
Works wonders.
There are also similar low-level interfaces to SpamAssassin: one is via a
sa-exim.so that is loaded via the local_scan() interface,
local_scan_path = .../somewhere/sa-exim-3.0.so
And another one is via an exiscan ACL setting for it (also in the DATA ACL),
deny message = Classified as spam (score $spam_score)
condition = ${if <{$message_size}{80k}{1}{0}}
condition = ${if <{$spam_score_int}{120}{1}{0}}
spam = nobody
(that 120 is 12.0 in SA terms)
For now I'm using the SA-Exim method because even though it's clumsy (needs
the .so file compiled from source so distribution isn't as trivial as an
apt-get invocation), I used it before the Exiscan patch was available and it
was reliable. (I'd welcome suggestions from other users about this issue.)
> > > If you want to automate this more, you could write a spamassassin rule
> > > that matches Swen mails, then use procmail to filter it (match against the
> > > rule name in X-Spam-Status) through a script that grabs the IP address and
> > > enters it into the firewall.
> >
> > Except it never hits SA nor do I even have procmail installed. Can't
> > stand the ugly beast.
>
> It never hits SA?
Because his antivirus ACL kills it before that.
--
2. That which causes joy or happiness.
Re: Virus emails
Lars Wirzenius writes: > I favor this approach over simple applications of violence, such as using > an axe on any computer infected by a virus. Psychiatry just for sending viruses? I don't know. Seems pretty extreme to me. Are you sure simple beatings would not suffice? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Virus emails
On Tue, Sep 23, 2003 at 02:31:22PM +0200, Josip Rodin wrote: > On Mon, Sep 22, 2003 at 07:34:58PM -0400, H. S. Teoh wrote: > > I've resorted to blocking port 25 to subnets from which these spams > > originate. Currently I have about 45 subnets (/24 and a few /16) on my > > blacklist, and so far 409 connections have been dropped. > > The sad thing about this is that there are parts of the Internet that aren't > subnet'ed properly. My mail server happens to be in the same /16 as about > two hundred entirely different locations, so whenever someone gets one of > those from whatever lamer in some shithole 900km away from me, my IPs get > blocked as well. Our NOC, collateral damage, and life in general for that > matter, suck. :) [snip] Which is why I've mostly refrained from /16's unless there are a lot of different addresses therein that have been infected. Although I admit to having a /8 for 212.* since there is just an amazing variety of addresses in that block that flood me with Swen. Ah, that ipv6 would be widely adopted soon... T -- LINUX = Lousy Interface for Nefarious Unix Xenophobes.
Re: Virus emails
On Mon, Sep 22, 2003 at 08:46:15PM -0700, Steve Lamb wrote: > On Mon, 22 Sep 2003 22:44:50 -0400 > "H. S. Teoh" <[EMAIL PROTECTED]> wrote: > > Another major source is rr.com, which not only gives me tons of Swen, but > > also other spam in general. I've blacklisted rr.com in /etc/hosts.deny, > > but obviously I'm missing something obvious, 'cos rr.com spam still gets > > through unless I block them on the firewall. > > rr.com pisses me off. They RBL other ISP provider's customer blocks so > we can't complain about their mess. Pathetic. Apparently rr.com has a reputation for being a spamhaus since years ago, in spite of their advertisements to the contrary. [snip] > > What are the exim rules you used to catch these things? > > exiscan-acl calling clamav and dropping it with a 550. A full log line > would be: > > 2003-09-22 07:38:05 1A1RpB-0007Xd-Of H=(smtp21.singnet.com.sg) > [165.21.101.201] F=<[EMAIL PROTECTED]> rejected after DATA: This > message contains a viru s or other malware (Worm.Gibe.F). I see. Thanks for the info, I'll look it up. [snip] > > For me, I just created a special iptables chain in the NAT table and wrote > > a script to put DROP rules into it. Then I have a rule in PREROUTING that > > diverts all port 25 traffic to that chain (so that other stuff doesn't > > incur too much overhead---the chain is quite long and growing rapidly). > > True. I'm just doing a blanket blacklist since I figure if they're > infected with this, what else will they hit? So far, I haven't got anything except port 25 connections from infected hosts. But then again, I have very few open ports on my machine, so who knows. > > If you want to automate this more, you could write a spamassassin rule > > that matches Swen mails, then use procmail to filter it (match against the > > rule name in X-Spam-Status) through a script that grabs the IP address and > > enters it into the firewall. > > Except it never hits SA nor do I even have procmail installed. Can't > stand the ugly beast. It never hits SA? Almost all Swen mails I got were caught by my bogofilter + SA setup. (It only missed like 2-3 out of at least 5000 per day.) [snip] > > But according to my observations from today, it's not a big deal if the > > first few messages get through---all my firewall rules were hand-added > > (only partially automated with some scripts), and they still catch a lot > > of subsequent crap. From the looks of it, infected machines are liable to > > repeatedly resend messages to the same target. The fact that you *did* > > blackhole the IP or subnet probably saves you from a lot of subsequent > > crap. > > True. Right now I'm just adding IPs by awking out the IPs, cleaning off > the brackets and tacking it onto the end of shorewall's blacklist. I've resorted to blocking wide subnets. 202.248.37.0/24 alone has had 3858 hits since yesterday, and still counting. Last night alone (about the past 8 hours or so) the firewall blocked about 6000+ port 25 connections, and shows no sign of slowing down. In fact, the rate seems to be increasing from the per minute scale and approaching the per second scale. [snip] > Ahhh, here's an interesting tidbit. From shorewall's status. > > Chain blacklst (2 references) > pkts bytes target prot opt in out source destination >40 2400 DROP all -- * * 128.118.141.31 0.0.0.0/0 >48 2880 DROP all -- * * 128.118.141.35 0.0.0.0/0 > 0 0 DROP all -- * * 128.83.126.136 0.0.0.0/0 > 1087 52176 DROP all -- * * 129.79.1.71 0.0.0.0/0 > 686 32928 DROP all -- * * 129.79.1.72 0.0.0.0/0 > > This in interesting. Some of these are hitting me a LOT and others have > not hit at all. I guess this means I can drop the ones with a 0 count, reset > the counts and let it go. This would, in theory, weed out the cleaned up > hosts while leaving in the infected, no? [snip] I noticed this also. However, I found that some of the subnets I blocked "rested" for several hours, and then started bombarding me again. So I'm leaving the rules in for at least a couple o' days before cleaning out those with 0 count. T -- To err is human; to forgive is not our policy. -- Samuel Adler
Re: Virus emails
On Mon, Sep 22, 2003 at 07:34:58PM -0400, H. S. Teoh wrote: > I've resorted to blocking port 25 to subnets from which these spams > originate. Currently I have about 45 subnets (/24 and a few /16) on my > blacklist, and so far 409 connections have been dropped. The sad thing about this is that there are parts of the Internet that aren't subnet'ed properly. My mail server happens to be in the same /16 as about two hundred entirely different locations, so whenever someone gets one of those from whatever lamer in some shithole 900km away from me, my IPs get blocked as well. Our NOC, collateral damage, and life in general for that matter, suck. :) -- 2. That which causes joy or happiness.
Re: Virus emails
Hi, Is there something similar for exim (woody version)? I don't care too much about the incoming bandwidth, but more about the resources that the spam and virus checks consume, especially during these spam virus waves. So I could add a (hopefully) cheap check at MTA level to reject these mails until the wave is over. Joachim Am Di, 2003-09-23 um 04.29 schrieb Graham Wilson: > On Mon, Sep 22, 2003 at 04:53:16PM +0200, Matthias Urlichs wrote: > > Hi, Mike Hommey wrote: > > > helps catching 95%... But the bandwidth is still used... I'm still > > > looking for a pure MTA solution... > > > > A pure MTA solution would still need to scan the body and thus would still > > eat your bandwidth. > > i have postfix's body_checks setup to reject lines that match the > following regular expression (this is the first line of the base64 > encoded virus): > > /^TVqQAAME\/\/8AALgAQAAA$/ > > i'm not sure when postfix closes the connection, whether its after > recieving a matching line, or after the client is done sending data. if > the former though, this would be a good "pure" mta solution that doesn't > conserve too much bandwidth. > > as to effectiveness, i've blocked 664 messages since saturday afternoon. > i still get some swen messages through, but they have had the virus > stripped already, so the message is considerably smaller. -- Joachim "nomeata" Breitner e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189 Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V? PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z? Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Virus emails
On Tue, Sep 23, 2003 at 12:28:44AM +0200, Mike Hommey wrote: > Maybe I'm wrong, but I think an MTA rejecting a mail because of > oversized body doesn't have to get the whole body before rejecting the > mail. You can issue a permanent error only after you have received the body.
Re: Virus emails
On Tuesday 23 September 2003 01:45, Bernd Eckenfels wrote: > On Tue, Sep 23, 2003 at 12:28:44AM +0200, Mike Hommey wrote: > > Maybe I'm wrong, but I think an MTA rejecting a mail because of oversized > > body doesn't have to get the whole body before rejecting the mail. Based > > on this, it should be possible to reject the mail before it gets fully > > transfered to the server. > > Well, you can reject on the size argument, if you see one, and if it is not > faked. Otherwise you have to read up to x bytes until you can drop the > conncetion. > > But this has nothing to do with the worms, unless you want to limit your > mails to max 10k :) In case of spam and virus checking you have to read at > least the headers, and most likely a lot of the body (till you know the > attachement type) Indeed, but you don't have to get the whole 150KB of mail... Mike -- "I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'enculé de ta mère. It's like wiping your ass with silk! I love it." -- The Merovingian, in the Matrix Reloaded
Re: Virus emails
On ma, 2003-09-22 at 17:53, Matthias Urlichs wrote: > The list of hardware required to stop this spam unfortunately seems to > include a time machine. Oh, that's not required at all. A simple couch will do. The couch will require a team of psychiatrists surrounding it, of course. They will then interview, for extended periods of time, whoever sends spam, writes viruses, or runs an insecure computer attached to the Internet. After the healing process is done, the culprits can then rejoin society as productive and wholesome individuals. I favor this approach over simple applications of violence, such as using an axe on any computer infected by a virus. -- http://liw.iki.fi/liw/photos/swordmaiden/
Re: Virus emails
On Mon, 22 Sep 2003 22:44:50 -0400
"H. S. Teoh" <[EMAIL PROTECTED]> wrote:
> Another major source is rr.com, which not only gives me tons of Swen, but
> also other spam in general. I've blacklisted rr.com in /etc/hosts.deny,
> but obviously I'm missing something obvious, 'cos rr.com spam still gets
> through unless I block them on the firewall.
rr.com pisses me off. They RBL other ISP provider's customer blocks so we
can't complain about their mess. Pathetic.
> [snip]
> > [EMAIL PROTECTED]:/var/log/exim4# grep -i malware mainlog | awk '{print
> > $5}' |
> > sort| wc -l
> > 743
> > [EMAIL PROTECTED]:/var/log/exim4# grep -i malware mainlog | awk '{print
> > $5}' |
> > sort| uniq | wc -l
> > 336
> What are the exim rules you used to catch these things?
exiscan-acl calling clamav and dropping it with a 550. A full log line
would be:
2003-09-22 07:38:05 1A1RpB-0007Xd-Of H=(smtp21.singnet.com.sg)
[165.21.101.201] F=<[EMAIL PROTECTED]> rejected after DATA: This
message contains a viru s or other malware (Worm.Gibe.F).
> For me, I just created a special iptables chain in the NAT table and wrote
> a script to put DROP rules into it. Then I have a rule in PREROUTING that
> diverts all port 25 traffic to that chain (so that other stuff doesn't
> incur too much overhead---the chain is quite long and growing rapidly).
True. I'm just doing a blanket blacklist since I figure if they're
infected with this, what else will they hit?
> If you want to automate this more, you could write a spamassassin rule
> that matches Swen mails, then use procmail to filter it (match against the
> rule name in X-Spam-Status) through a script that grabs the IP address and
> enters it into the firewall.
Except it never hits SA nor do I even have procmail installed. Can't
stand the ugly beast.
> Caution is advised, though---some Swen mails are coming through the Debian
> lists, so you want to make sure you don't accidentally blacklist murphy or
> gluck. :-)
... Carp, so much for that idea, eh? :/
> But according to my observations from today, it's not a big deal if the
> first few messages get through---all my firewall rules were hand-added
> (only partially automated with some scripts), and they still catch a lot
> of subsequent crap. From the looks of it, infected machines are liable to
> repeatedly resend messages to the same target. The fact that you *did*
> blackhole the IP or subnet probably saves you from a lot of subsequent
> crap.
True. Right now I'm just adding IPs by awking out the IPs, cleaning off
the brackets and tacking it onto the end of shorewall's blacklist.
> I can literally watch the firewall counters go up every minute. Sometimes
> it's 3 or 4 per second. The stuff that still gets through ends up in my
> spam box at about 2-3 per 20 minutes or so. (Much better than the 120/hour
> during the weekend.)
Ahhh, here's an interesting tidbit. From shorewall's status.
Chain blacklst (2 references)
pkts bytes target prot opt in out source destination
40 2400 DROP all -- * * 128.118.141.31 0.0.0.0/0
48 2880 DROP all -- * * 128.118.141.35 0.0.0.0/0
0 0 DROP all -- * * 128.83.126.136 0.0.0.0/0
1087 52176 DROP all -- * * 129.79.1.71 0.0.0.0/0
686 32928 DROP all -- * * 129.79.1.72 0.0.0.0/0
This in interesting. Some of these are hitting me a LOT and others have
not hit at all. I guess this means I can drop the ones with a 0 count, reset
the counts and let it go. This would, in theory, weed out the cleaned up
hosts while leaving in the infected, no?
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
pgpsg99Ynf1Pk.pgp
Description: PGP signature
Re: Virus emails
On Mon, Sep 22, 2003 at 07:18:56PM -0700, Steve Lamb wrote:
> On Mon, 22 Sep 2003 19:34:58 -0400
> "H. S. Teoh" <[EMAIL PROTECTED]> wrote:
> > I've resorted to blocking port 25 to subnets from which these spams
>
> What would help is to be able to block an IP once it's been hit. Thing is
> I cannot for the life of me figure out a way to do it. Here's the first 25
> that hit me today:
>
> [12.166.16.7]
[snip]
Strange, I didn't get any from 12.0.0.0/8 at all.
> [128.143.2.219]
> [128.143.2.219]
Now *this* looks familiar.
> [128.146.216.43]
> [128.146.216.45]
> [129.82.100.130]
[snip]
Didn't see these either.
> [132.64.1.17]
Saw this one, and none of the others.
> Notice the duplicates. Now if I could enter a blacklist entry into
> shorewall after the first hit...
There is definitely a lot of duplicates, which was what drove me to ban it
at the IP level in the first place. Looking at my firewall counters, I've
had 138 attempts from 212.216.0.0/16 alone. (Granted, that was a wide
netblock, but I don't get mail from .it, and tons of virus mails were
coming from there.)
Another major source is rr.com, which not only gives me tons of Swen, but
also other spam in general. I've blacklisted rr.com in /etc/hosts.deny,
but obviously I'm missing something obvious, 'cos rr.com spam still gets
through unless I block them on the firewall.
[snip]
> [EMAIL PROTECTED]:/var/log/exim4# grep -i malware mainlog | awk '{print $5}'
> | sort
> | wc -l
> 743
> [EMAIL PROTECTED]:/var/log/exim4# grep -i malware mainlog | awk '{print $5}'
> | sort
> | uniq | wc -l
> 336
What are the exim rules you used to catch these things?
> I'd drop the load from 743 down to 336. Assuming all of those are Swen
> or some variant then it would be a savings of about 4Mb so far today.
For me, I just created a special iptables chain in the NAT table and wrote
a script to put DROP rules into it. Then I have a rule in PREROUTING that
diverts all port 25 traffic to that chain (so that other stuff doesn't
incur too much overhead---the chain is quite long and growing rapidly).
If you want to automate this more, you could write a spamassassin rule
that matches Swen mails, then use procmail to filter it (match against the
rule name in X-Spam-Status) through a script that grabs the IP address and
enters it into the firewall. Caution is advised, though---some Swen mails
are coming through the Debian lists, so you want to make sure you don't
accidentally blacklist murphy or gluck. :-)
But according to my observations from today, it's not a big deal if the
first few messages get through---all my firewall rules were hand-added
(only partially automated with some scripts), and they still catch a lot
of subsequent crap. From the looks of it, infected machines are liable to
repeatedly resend messages to the same target. The fact that you *did*
blackhole the IP or subnet probably saves you from a lot of subsequent
crap.
> Of course that's what's gotten past the IPs I've already blacklisted.
[snip]
I can literally watch the firewall counters go up every minute. Sometimes
it's 3 or 4 per second. The stuff that still gets through ends up in my
spam box at about 2-3 per 20 minutes or so. (Much better than the 120/hour
during the weekend.)
T
--
Too many people have open minds but closed eyes.
Re: Virus emails
On Mon, Sep 22, 2003 at 04:53:16PM +0200, Matthias Urlichs wrote: > Hi, Mike Hommey wrote: > > helps catching 95%... But the bandwidth is still used... I'm still > > looking for a pure MTA solution... > > A pure MTA solution would still need to scan the body and thus would still > eat your bandwidth. i have postfix's body_checks setup to reject lines that match the following regular expression (this is the first line of the base64 encoded virus): /^TVqQAAME\/\/8AALgAQAAA$/ i'm not sure when postfix closes the connection, whether its after recieving a matching line, or after the client is done sending data. if the former though, this would be a good "pure" mta solution that doesn't conserve too much bandwidth. as to effectiveness, i've blocked 664 messages since saturday afternoon. i still get some swen messages through, but they have had the virus stripped already, so the message is considerably smaller. -- gram signature.asc Description: Digital signature
Re: Virus emails
On Mon, 22 Sep 2003 18:48:58 -0500 Gunnar Wolf <[EMAIL PROTECTED]> wrote: > [1] http://www.ietf.org/rfc/rfc0821.txt And what does RFC2821 have to say about it? -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpcssJgAdQlp.pgp Description: PGP signature
Re: Virus emails
On Mon, 22 Sep 2003 19:34:58 -0400
"H. S. Teoh" <[EMAIL PROTECTED]> wrote:
> I've resorted to blocking port 25 to subnets from which these spams
What would help is to be able to block an IP once it's been hit. Thing is
I cannot for the life of me figure out a way to do it. Here's the first 25
that hit me today:
[12.166.16.7]
[12.166.16.7]
[12.166.16.7]
[12.166.16.7]
[12.166.16.7]
[12.166.16.7]
[12.166.16.7]
[12.166.16.7]
[12.17.134.9]
[128.143.2.219]
[128.143.2.219]
[128.146.216.43]
[128.146.216.45]
[129.82.100.130]
[129.82.100.130]
[130.244.199.129]
[130.244.199.132]
[132.64.1.17]
[142.165.19.3]
[142.165.19.5]
[142.169.1.100]
[144.135.24.153]
[144.135.24.153]
Notice the duplicates. Now if I could enter a blacklist entry into
shorewall after the first hit...
[EMAIL PROTECTED]:/var/log/exim4# grep -i malware mainlog | awk '{print $5}' |
sort
| wc -l
743
[EMAIL PROTECTED]:/var/log/exim4# grep -i malware mainlog | awk '{print $5}' |
sort
| uniq | wc -l
336
I'd drop the load from 743 down to 336. Assuming all of those are Swen or
some variant then it would be a savings of about 4Mb so far today.
Of course that's what's gotten past the IPs I've already blacklisted.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
pgpqCXSI4C5gg.pgp
Description: PGP signature
Re: Virus emails
Mike Hommey dijo [Tue, Sep 23, 2003 at 12:28:44AM +0200]: > > > helps catching 95%... But the bandwidth is still used... I'm still > > > looking for a pure MTA solution... > > > > A pure MTA solution would still need to scan the body and thus would still > > eat your bandwidth. > > Maybe I'm wrong, but I think an MTA rejecting a mail because of oversized > body > doesn't have to get the whole body before rejecting the mail. Based on this, > it should be possible to reject the mail before it gets fully transfered to > the server. I don't think so - And if so, this could break many client MTAs. According to the protocol definition [1], after the DATA command the server will reply with a 354 code, which means 'Start mail input; end with .'. The client might not be expecting anything until the . has been sent. If you suddenly send a 5xx error code, the client might never receive it. You may close the connection, but th client might then retry - and consume your bandwith over and over. Greetings, [1] http://www.ietf.org/rfc/rfc0821.txt -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Virus emails
On Tue, Sep 23, 2003 at 12:28:44AM +0200, Mike Hommey wrote: > Maybe I'm wrong, but I think an MTA rejecting a mail because of oversized > body > doesn't have to get the whole body before rejecting the mail. Based on this, > it should be possible to reject the mail before it gets fully transfered to > the server. Well, you can reject on the size argument, if you see one, and if it is not faked. Otherwise you have to read up to x bytes until you can drop the conncetion. But this has nothing to do with the worms, unless you want to limit your mails to max 10k :) In case of spam and virus checking you have to read at least the headers, and most likely a lot of the body (till you know the attachement type) Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Virus emails
On Mon, Sep 22, 2003 at 04:53:16PM +0200, Matthias Urlichs wrote: > Hi, Mike Hommey wrote: > > > helps catching 95%... But the bandwidth is still used... I'm still looking > > for > > a pure MTA solution... > > A pure MTA solution would still need to scan the body and thus would still > eat your bandwidth. So I noticed. Very few (only 2-3 out of about 500/day for about 5 days now) actually managed to get past my bogofilter+SA setup, but it's using up a lot of bandwidth. I'd hate to have to pay for wasted bandwidth. > The list of hardware required to stop this spam unfortunately seems to > include a time machine. [snip] I've resorted to blocking port 25 to subnets from which these spams originate. Currently I have about 45 subnets (/24 and a few /16) on my blacklist, and so far 409 connections have been dropped. This is only since 2pm today. The problem with this is that you have to hand-pick subnets to prevent inadvertently blocking legitimate mails. I hate to be spending so much time on this, but I really can't see myself paying for extra bandwidth caused by this spam. It's sorta a last-resort thing. Unfortunately, this is not a safe thing to do on the Debian mailing list servers. T -- Long, long ago, the ancient Chinese invented a device that lets them see through walls. It was called the "window".
Re: Virus emails
On Monday 22 September 2003 16:53, Matthias Urlichs wrote: > Hi, Mike Hommey wrote: > > helps catching 95%... But the bandwidth is still used... I'm still > > looking for a pure MTA solution... > > A pure MTA solution would still need to scan the body and thus would still > eat your bandwidth. Maybe I'm wrong, but I think an MTA rejecting a mail because of oversized body doesn't have to get the whole body before rejecting the mail. Based on this, it should be possible to reject the mail before it gets fully transfered to the server. Mike
Re: Virus emails
Hi, Daniel Burrows wrote:
> On Fri, Sep 19, 2003 at 10:45:57AM -0500, Luca - De Whiskey's - De Vitis
> <[EMAIL PROTECTED]> was heard to say:
>> I'm getting one evry 30 minutes, more or less... but i've read on irc that
>> this is quite common now...
>
> You mean "seconds", not "minutes", right? :-(
>
Sounds about right for my mailbox. 2000+/day, and no sign of slowing down.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
:hungry puppy: n. Syn. {slopsucker}.
Re: Virus emails
Hi, Mike Hommey wrote:
> helps catching 95%... But the bandwidth is still used... I'm still looking
> for
> a pure MTA solution...
A pure MTA solution would still need to scan the body and thus would still
eat your bandwidth.
The list of hardware required to stop this spam unfortunately seems to
include a time machine.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
One principle object of good-breeding is to suit our behavior to the three
several degrees of men -- our superiors, our equals, and those below us.
-- Jonathan Swift
