Any suggestions on how to stem the flow other than closing port 25 which
would only defer the problem? My email server is UW7.1.0 with PTF7130e
installed. I even though about rejecting any messages with attachments but
am not sure how to do that with sendmail.
The main headache it is causing me today is that it takes so much of my
very limited bandwidth that the only thing I can do is send
(hopefully!) and receive (definately!) email. Everything else, including
pings time out with Unknown Host.
Thank you,
Lucky
Lucky Leavell Phone: (800) 481-2393 (US/Canada)
UniXpress - Your Source for SCO OR: (812) 366-4066
1560 Zoar Church Road NE FAX: (812) 366-3618
Corydon, IN 47112-7374 Email: lu...@UniXpress.com
WWW Home Page: http://www.UniXpress.com
The solution would be to tell your firewall to limit port 25 traffic, while
speeding through port 80. You can do this (traffic shaping? TOS bits?) but I
don't know how to do it on my system, let alone yours.
Tell sendmail, perhaps, to limit it to one concurrent connection?
NYZ
--
_________________________________________
Nachman Yaakov Ziskind, EA, LLM aw...@egps.com
Attorney and Counselor-at-Law http://ziskind.us
Economic Group Pension Services http://egps.com
Actuaries and Employee Benefit Consultants
I hate sendmail and run smail here. It pipes incoming main to Chip
Salzenburg's 'deliver'; ~part~ of my /usr/local/lib/deliver.sys reads:
#!/bin/ksh
# /usr/local/lib/deliver.sys
# 1.4 JPR 18Sep03
typeset -l TO=`header -f To -f Cc -f Apparently-To -f Sender $HEADER`
ID=`header -f Message-ID $HEADER`
typeset -l FR=`header -f From $HEADER | sed '
s/.*<\(.*\)>.*/\1/
s/[("].*[)"]//
s/ //g'`
typeset -l CT=`header -f Content-Type $HEADER | sed 's/;.*//'`
typeset -l CN=`header -f Control $HEADER`
IP=`header -f Received $HEADER | sed -n '1s .*\\[\\(.*\\)].* \\1 p'`
: ${IP:=localhost}
USER=$1
# Configure the email server to block or remove email that contains file
# attachments that are commonly used to spread viruses, such as .vbs, .bat,
# .exe, .pif and .scr files.
for X in EXE BAT PIF SCR VBS
do
grep -iq "^Content-.*name=.*\.$X" $BODY &&
echo "A .$X file mailed by $FR\nto $TO\nvia $IP\nwas dumped in the garbage."|
mutt -s "Dumped .$X file" $USER &&
/usr/local/bin/addfilter $IP &&
echo DROP &&
exit
done
/usr/local/bin/addfilter collects IP addresses which an overnight cron
job adds to my local RBL list.
--
JP
> Lucky Leavell typed (on Fri, Sep 19, 2003 at 06:21:32PM +0000):
> |
> | The main headache it is causing me today is that it takes so much of my
> | very limited bandwidth that the only thing I can do is send
> | (hopefully!) and receive (definately!) email. Everything else, including
> | pings time out with Unknown Host.
>
> I hate sendmail and run smail here.
JP;
Your solution is certainly much more elegant than the temporary solution
I came up with: set the maximum message size to, say, 130K which would be
a Q&D (quick and dirty) way to reclaim my bandwidth as, if I understand
the Sendmail Operations Guide, would prevent my system from even accepting
the message to begin with.
I intend to do a little server shuffle this fall:
The SCO Linux box will become UnixWare 7.1.3 with LKP and OKP
The current [aged] UnixWare 7.1 box will become OpenBSD 3.4
and the new email server/backup internet gateway to
The MultiTech RF550VPN will get replaced by a RF600VPN which can
do virus scanning and content filtering
>I know I am one of very many hapless souls receiving message after message
>totaling around 150K/message purporting to be M$ patches or undeliverable
If you're running OSR5 and MMDF, add to you .maildelivery file:
### Eat the worms
From microsoft destroy A -
To microsoft destroy A -
Subject microsoft destroy A -
If you want to save the crap (and fill up your hard disk with spam):
### Save the worms
From microsoft > ? /u/junk/spam
To microsoft > ? /u/junk/spam
Subject microsoft > ? /u/junk/spam
If you're on one of the Microsloth mailing lists, add something like
this *ABOVE* the spam filters:
From newsletters.microsoft.com > ? /u/ms/newsletters
From whatever.microsoft.com > ? /u/ms/whatever
Some of the messages that it misses include "MS" in the Subject line.
I'm currently playing with trapping those. For some odd reason:
Subject " MS " > ? /u/junk/ms
doesn't seem to work.
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831.336.2558 voice http://www.LearnByDestroying.com
# je...@comix.santa-cruz.ca.us
# 831.421.6491 digital_pager je...@cruzio.com AE6KS
"Lucky Leavell" <lu...@unixpress.com> wrote in message
news:Pine.UW2.4.21.030919...@ris7.UniXpress.com...
>On Fri, 19 Sep 2003 18:21:32 GMT, Lucky Leavell <lu...@unixpress.com>
>wrote:
>
>>I know I am one of very many hapless souls receiving message after message
>>totaling around 150K/message purporting to be M$ patches or undeliverable
>
>If you're running OSR5 and MMDF, add to you .maildelivery file:
>
> ### Eat the worms
> From microsoft destroy A -
> To microsoft destroy A -
> Subject microsoft destroy A -
>
>If you want to save the crap (and fill up your hard disk with spam):
> ### Save the worms
> From microsoft > ? /u/junk/spam
> To microsoft > ? /u/junk/spam
> Subject microsoft > ? /u/junk/spam
>
>If you're on one of the Microsloth mailing lists, add something like
>this *ABOVE* the spam filters:
>
> From newsletters.microsoft.com > ? /u/ms/newsletters
> From whatever.microsoft.com > ? /u/ms/whatever
>
A bit more if you're using MMDF. The bozo the wrote this worm in
Visual C++ wasn't into software efficiency. The 150KB/message is
overflowing my undersized mail spool. Unlike spam and virus filters
that work on each individual email message as it arrives, my ancient
UuCP over TCP implimentation requires that *ALL* the mail must be
download before the .maildelivery file can sort through the crud and
remove the worms. I've tried various methods of emptying the mail
spool without much success. No matter what I do, it overflows, LCK's
the connection, and generates a huge backlog of incoming worms that
must be manually vaporized.
Being lazy, I decided that elegance and finese were for those with
diskspace and programming abilities. So, I used cron and a big
hammer. I noticed that all the worms are between 130KB and 160KBytes
big.
cd /usr/spool/uucp/[isp-name]
find . \( -size +130 -a -size -160 \) -exec rm {} \;
will obliterate all these size files from the UUCP spool. The same
can be probably be done with the SMTP spool in:
/usr/spool/mmdf/lock/home/q.*
There's probably a better way to do this, but for now, it's working
well enough.
Incidentally, in the past 24 hours, my mail server has digested
210MBytes of worms with no end in sight.
I'm still getting them, 1 ever 4-5 minutes.. Over 3000 of them over the
past weekend.
Just spending more time deleting crap than I usually do..
bkx
> Are you still getting those emails? I thought the worm was suppose to time
> out around Sept. 10th.
>
Different Worm - The one you are referring to was SoBig.F which was fairly
easy to deal with once I noticed that all the spam I received came from
the same [infected] IP address. I added a line in my .maildelivery to
dispatch all messages from that IP address to the bit bucket.
Yesterday's worm was reportedly the Swen variant of Gibe (whatever on
earth they are!) and offers few means of identifying the messages. I
finally settled on using the sendmail MaxMessageSize which doesn't prevent
wasted bandwidth downloading the messaged (as the SEndmail Operations
Guide seems to imply) and does increase internet traffic by bouncing the
rejects back to whence they came from. Things finally settled down last
night and today to mangeable volumes.
(It should be noted that at no time were any of my systms actually
infected by the worm as I do not allow M$ systems to touch email; I was
merely the lucky recipient of spam generated by other, infected systems.)
Guess I better start saving my pennies so I can upgrade my MultiTech
Rf550VPN to the RF600VPN which offers optional virus scanning and content
filtering.
(I wish these latest bozos would realize that when they clog us low
bandwidth folks with their worm-generated spam, it hampers our ability to
receive all the "normal" spam!)
That was the old worm. This is the new one, Swen. It started
going around on Thursday the 18th.
I usually receive a few worms/viruses by mail every week.
I've received - no word of a lie - over a thousand copies of this
@%$#&%^& thing since Thursday. It can't infect me, using a
Unix mailreader on a Unix box with no ability to run Microsoft
executables, but at 150 kB per copy, this worm has wasted
150 MB of my bandwidth so far. Thank goodness I don't pay by
the megabyte.
I can't stop 'em from being sent to me, but I _can_ stop
'em from getting into my mailbox. Here's one way of handling
it.
I have spamassassin running on my system. For those not familiar
with SA, it runs a whole pile of tests against each message. Each
test has a score associated with it; tests which usually indicate
ham (non-spam) messages have a negative score, and tests which
usually indicate spam have a positive score. After all the tests
have been run, the scores are added up, and if the overall score is
above a certain level, it's flagged as spam. This is a better
way than blocking based on black/white rules; after all, 90% of
the mail you get with the word Viagra in it is probably spam,
but 10% are jokes your buddies sent you, and you want to be able
to read the jokes, so a filtering system that treats spamminess
as shades of gray is a good thing.
SA also includes header fields in all messages indicating which
tests the message triggered, regardless of whether the message was
determined to be spam or ham. Two useful tests here are
MICROSOFT_EXECUTABLE, which is self-explanatory, and MIME_SUSPECT_NAME.
The latter indicates that the MIME type doesn't match the file's
extension; this usually is an attempt to exploit a bug in many
versions of Outlook/Outlook Express such that if you use a MIME
type that's supposed to be harmless (e.g. tag your attachment
as a MIDI or WAV file), Outlook runs it. Many worms use this
by giving the attachment one of these two types, yet making
the file extension something that the operating system
recognizes as an executable, so that the worm's code gets run
automatically - you don't even have to click on it to get infected.
(Microsoft released patches for this long ago, but lots of clueless
users haven't bothered installing them.)
I rarely, if ever, get a legitimate email with a MICROSOFT_EXECUTABLE
attachment, so I kill any of those. I should never receive an attachment
that has a MIME type of MIDI or WAV or whatever but has a file extension
of .PIF or .SCR or .EXE or .BAT or whatever, so I've started killing
all of those - they're all worms. Every copy of Swen that I've
seen triggers the MICROSOFT_EXECUTABLE test; every copy of Swen
that claims to be a failure message triggers the MIME_SUSPECT_NAME
test, while the copies that claim to be the latest patch don't
(they rely on the user being naive enough to run the attachment).
So the following two .maildelivery lines manage to keep Swen,
and many other viruses/worms, from getting into my mailbox:
--------------------8<--------(cut here)--------->8-------------------
X-Spam-Status MICROSOFT_EXECUTABLE destroy A -
X-Spam-Status MIME_SUSPECT_NAME destroy A -
--------------------8<--------(cut here)--------->8-------------------
--
Stephen M. Dunn <ste...@stevedunn.ca>
>>>----------------> http://www.stevedunn.ca/ <----------------<<<
------------------------------------------------------------------
Say hi to my cat -- http://www.stevedunn.ca/photos/toby/
# grep -c WORM_SWEN virus.log.2003.09.{19,2*}
virus.log.2003.09.19:194
virus.log.2003.09.20:435
virus.log.2003.09.21:313
virus.log.2003.09.22:249
Go virus scanner on Linux gateway .. ;)
>(I wish these latest bozos would realize that when they clog us low
>bandwidth folks with their worm-generated spam, it hampers our ability to
>receive all the "normal" spam!)
You can see the increase in spam traffic since mid July in some of the
international backbone traffic statistics.
http://west-boot.mfnx.net/traffic/backbone/index.html
This is China Telecom to Palo Alto.
http://west-boot.mfnx.net/traffic/peers/pao1-chinatelecom.html
Note the drastic increase on the Yearly graphs. Most of the other
international traffic shows no such increase.
I've also noticed that my local non-Swen spam traffic has decreased
somewhat in the last week. My guess(tm) is that some of the spammers
mail servers crashed as a result of the Swen worm.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com AE6KS
je...@comix.santa-cruz.ca.us je...@cruzio.com
"Stuart J. Browne" <stu...@promed.com.au> wrote in message
news:3f6e2f22$1...@dnews.tpgi.com.au...