ATTN:
I STUMBLED IN TO YOUR CONTACT BY STROCK OF LUCK AFRTER
A LONG SEARCH FOR AN HONEST AND TRUST WORTHY PERSON WHO
COULD HANDLE ISSUE WITH HIGH CONFIDENTIALITY.
I WAS SO DELIGHTED WHEN I GOT YOUR CONTACT AND I DECIDED
TO CONTACT YOU AND SOLICITE FOR YOUR KIND ASSISTANCE.
I HOPE YOU WILL LET THIS ISSUE TO REMAIN CONFIDENTIAL EVEN
IF YOU ARE NOT INTERESTED BECAUSE OF MY STATUS.
I PRESUME THIS MAIL WILL NOT BE A SURPRISE TO YOU.
I AM AN ACCOUNTANT WITH THE MINISTRY OF MINERAL
RESOURCES AND ENERGY IN SOUTH AFRICA AND ALSO A MEMBER
OF CONTRACTS AWARDING COMMITTEE OF THIS MINISTRY UNDER
SOUTH AFRICA GOVERNMENT.
MANY YEARS AGO, SOUTH AFRICA GOVERNMENT ASKED THIS
COMMITTEE TO AWARDS CONTRACTS TO FOREIGN FIRMS, WHICH
I AND 2 OF MY PARTNERS ARE THE LEADER OF THIS
COMMITTEE, WITH OUR GOOD POSITION , THIS CONTRACRS
WAS OVER INVOICED TO THE TUNE OF US$25,600,000:00 AS A
DEAL TO BE BENEFIT BY THE THREE TOP MEMBER OF THIS
COMMITTEE.
NOW THE CONTRACTS VALUE HAS BEEN PAID OFF TO THE
ACTUAL CONTRACTORS THAT EXECUTED THIS JOBS, ALL WE
WANT NOW IS A TRUSTED FOREIGN PARTNER LIKE YOU THAT WE
SHALL FRONT WITH HIS BANKING ACCOUNT NUMBER TO CLAIM
THE OVER INFLATED SUM.
UPON OUR AGREEMEENT TO CARRY ON THIS TRANSACTION WITH
YOU, THE SAID FUND WILL BE SHARE AS FOLLOWS.
75% WILL BE FOR US IN SOUTH AFRICA.
20% FOR USING YOUR ACCOUNT AND OTHER CONTRIBUTION
THAT MIGHT REQIURED FROM YOU.
5% IS SET ASIDE FOR THE UP FRONT EXPENCES THAT
WILL BE ENCOUNTER BY BOTH PARTY TO GET ALL NECESSARY
DOCUMENTS AND FORMARLITIES THAT WILL JUSTIFY YOU AS
THE RIGHTFUL OWNER OF THIS FUND.
IF YOU ARE INTERESTED IN THIS TRANSACTION, KINDLY
REPLY THIS MASSEGE WITH ALL YOUR PHONE AND FAX
NUMBERS, TO ENABLE US FURNISH YOU WITH DETAILS AND
PROCEDURES OF THIS TRANSACTION.
GOD BLESS YOU
YOURS FAITHFULLY.
JOSEPH EDWARD.
> On Mon, 2002-06-03 at 20:23, Matti Aarnio wrote:
> I think there are several free codes of this kind
> available, but my time
> has been chronically over-subscribed to do radical things
> like taking this kind of codes into use.
I've been using SpamAssassin on lists.us.dell.com for a couple months now.
It's pretty effective, but of course not perfect - maybe one a month gets
through, though I'm dealing with less traffic than vger. I'm not actually
filtering linux-kernel-digest or -daily-digest, except to verify that the
mail actually was sent from vger and not some spammer. With procmail
recipies, it works quite well. Because I'm using mailman, it's a
multi-stage thing. Procmail does the heavy lifting, and mailman sticks
suspected spam in the moderator queue.
/etc/aliases has:
linux-poweredge: "|procmail -m /etc/procmailrcs/spamfilter post
linux-poweredge"
/etc/procmailrcs/spamfilter has:
# drop known spam senders in our killfile
:0
* ? formail -x"From" -x"From:" -x"Sender:" -x"X-Envelope-Sender:" | egrep
-is -f
/home/mailman/SPAMMERS
/dev/null
:0fw
| spamc
# This avoids having to moderate completely obvious spam.
# Send obvious spam to /var/spool/mail/caught-spam
# Eventually we'll just send it to /dev/null instead.
:0
* ? formail -x"X-Spam-Status:" | sed -e 's/hits=//g' | \
awk '{if ($2 < 10) exit 1}'
caught-spam
:0
|/home/mailman/mail/wrapper $1 $2
Messages that match known spammers are dropped.
Messages with scores < 5 are considered not spam.
Messages with scores 5-10 are caught by Mailman filters and dropped into
moderator queue
Messages with scores > 10 are stored in caught-spam, could be /dev/null - it
hasn't missed yet.
Mailman then has its own list of things to catch for moderation, and I've
mimic'd vger's filters too.
Successful messages give automatic whitelist points to the author, which
cuts down on false positives from people who post regularly. In all I'm
quite pleased. A useful addition would be automatic updates of rules as
they get added to CVS, but SpamAssassin isn't mature enough to allow such
quiet yet.
Thanks,
Matt
--
Matt Domsch
Sr. Software Engineer
Dell Linux Solutions http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
#1 US Linux Server provider for 2001! (IDC Mar 2002)
[email protected] wrote:
>I've been using SpamAssassin on lists.us.dell.com for a couple months now.
>It's pretty effective, but of course not perfect - maybe one a month gets
>through, though I'm dealing with less traffic than vger. I'm not actually
>filtering linux-kernel-digest or -daily-digest, except to verify that the
>mail actually was sent from vger and not some spammer. With procmail
>recipies, it works quite well.
>
I have been honing a set of procmail rules,
but it's a fine balance between thorough
checks and excessive slowdown of the
mail thoughput -
Anybody used spam assasin for a domain
handling say a few million messages and
a few hundred GB of mail every month,
to say 12,000 users?
I'm looking for a good tradeoff between
fairly good spam rejection, and keeping
the "fast path" from bogging down -
Will I just have to bite the bullet and use
a pair of quad CPU monsters for mail
to get good throughput?
Joe
On 2002-06-03, J Sloan <[email protected]> wrote:
> The thing with linux/unix "virii" is, they
> are actually for the most part trojans -
> they've been in labs for years, the problem
> is that there is no suitable transport vector!
> You'd have to dupe an unwitting superuser
> (now there's a dangerous combination) into
> running the "virus" by hand - sort of like
> the "honor system" virus....
...You mean like, get them to run './configure' ?[1][2]
...Or installing an RPM with trojanned binaries or install-time scripts,
without checking a signature?[3]
Unfortunately that's all too easy. Viruses, no. Malware, you bet. We
can't get too complacent while laughing at the virus phenomenon.
[1] http://marc.theaimsgroup.com/?l=bugtraq&m=102233939226053&w=2
http://marc.theaimsgroup.com/?l=bugtraq&m=102285523803434&w=2
[2] They don't have to do this as root, either. If they do it from an
account that can escalate privileges (i.e. is allowed to su or sudo)
then it's game over anyway, albeit with more steps.
[3] And of course signatures are useless if the signer was owned first.
Probably major distros are reasonably safe[4], but not Joe Random who
produces packages and distributes them...
[4] They're not out to get you; they've already got you:
http://www.acm.org/classics/sep95/
--
Hank Leininger <[email protected]>
ALL YOUR BASE ARE BELONG TO KEN THOMPSON
Hank Leininger wrote:
>On 2002-06-03, J Sloan <[email protected]> wrote:
>
>
>
>>The thing with linux/unix "virii" is, they
>>are actually for the most part trojans -
>>they've been in labs for years, the problem
>>is that there is no suitable transport vector!
>>
>>
>
>
>
>>You'd have to dupe an unwitting superuser
>>(now there's a dangerous combination) into
>>running the "virus" by hand - sort of like
>>the "honor system" virus....
>>
>>
>
>...You mean like, get them to run './configure' ?[1][2]
>...Or installing an RPM with trojanned binaries or install-time scripts,
>without checking a signature?[3]
>
>Unfortunately that's all too easy. Viruses, no. Malware, you bet. We
>can't get too complacent while laughing at the virus phenomenon.
>
>
Complacency is never a good idea - however,
let's give credit where credit is due - it's orders
of magnitude more difficult to do something like
this against a unix system - most script kiddies
will go for the easy targets (microsoft) instead
Joe
>
>
On Tue, 2002-06-04 at 19:36, J Sloan wrote:
> Complacency is never a good idea - however,
> let's give credit where credit is due - it's orders
> of magnitude more difficult to do something like
> this against a unix system - most script kiddies
> will go for the easy targets (microsoft) instead
Each of the major viruses has probably got one author singular.
There are ways of making systems much more resistant to attack including
viruses. Things like RSBAC and the NSA security modules help you get
into a situation where this kind of stuff doesn't occur
User1 gets a virus
User1 owns a binary root users
Root gets the virus
Splat
Because with a trust model it goes instead
User1 geta a virus
User1 owns a binary root users
User1 virus patches the binary
Root is refused permission to run the binary because it no longer has
a high enough integrity
Even before that the lack of people checking GPG keys on RPM and other
packages is disturbing.
Alan
"Michael H. Warfield" <[email protected]>:
...
>
> It's not theoretical and it's not just in the labs. It's real
> and it's in the wild now. It just doesn't have the population
> density and the monclonal culture to make it go BANG like the Windows
> worms go. Yet...
>
...
So which do you think is better:
1. buy/write/update virus software to catch/trap the virus
2. Fix the security hole.
I put my money on #2.
There are several ways to trap attacks on daemons that have such
vulnerabilities. And using virus scanners CANNOT keep up.
The obvious solution is:
1. Use one of the high security patches (SELinux or RSBAC) and use
compartmentalization to keep the problem under control.
2. Use the detected problem to locate and fix the security problem in
the daemon.
Virus scanners cannot keep up. The virus that does the damage is the one
the scanner doesn't recognize. This is equivalent to the bug that wasn't
fixed.
Generation and propagation of a patch is nearly as fast if not faster
than generating another virus signature; and is a LOT more effective.
The high security patches allow the system to continue functioning even
in the presence of the virus, as long as the virus itself is compartmented.
At one time, there was some discription of the Ramen/lion worm attempting
to attack a SELinux based system.. and failed. It did get in the daemon,
but was then isolated from the rest of the system.
I do believe that the kernel can be improved - not including daemon services
in the kernel itself is one (tux?,nfs?,... yes they work faster, but is it
worth the security risk?).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.