Re: forged localhost sender test

At 18:30 2004-12-13 +0100, Dallman Ross wrote:

> Well, first, the host domain is parsed from $HOST in procmail
> using a bit of code that attempts to strip (does a pretty good job at
> stripping) down things like
>
>    somehost.somedomain.[a-z]{2,3}[^.]
>    somehost.somedomain.co.uk
>
> and so on to what I call the "stub" ("somedomain").
> It works well, but there naturally could be some odd cases
> where it wouldn't work right, in which case the user is
> encouraged to override with a manual entry in the myvars file.
Yea, the chief issue I saw was that the hostname being used could be any of 
a number of aliases, not just what the hostname is defined as 
locally.  Say, if your mail is hosted on someone else's server but you have 
DNS records under your own domain.  the $HOST may be 
"www.hostingdomain.tld", but you might have "mail.yourdomain.tld", and that 
can legitimatley appear in the message headers.  The spammer has probably 
come to you through your own domain name, since it's affiliated with the 
email address they're spamming at.
> The vsnag code also considers private IP address space and
> localhost when it looks -- not dissimilar to what I noticed in
> your script.
Well, I wasn't too concerned with non-routed IP space, since those would 
imply delivery from another host within one's own non-routed network, 
though if one were running a server via NAT and the locally defined IP 
address were non-routed, that could be an issue - easily handled by having 
an explicit declaration of that IP (much like localhost).
I'd considered having a config script that could run ifconfig and extract 
the list of IP addresses which refer to the local host, but that doesn't 
get us the hostnames, and seemed like a bit of extra work for an incomplete 
solution.

BTW, concurrent with this update, I also investigated using a call to 
sendmail to validate local senders - people claiming to be on the local 
host, generally using trumped-up local username portions stuffed in front 
of your domain (also frightfully popular with viruses, but creeping into 
spam as well).

:0
* FROM_DOMAIN ?? ^regexp_for_your_local_domain$
{
        VALIDUSER=`$SENDMAIL -bv $CLEANFROM`
        :0
        * ! VALIDUSER ?? deliverable:
        {
                SPAMVAL="+180"
                SPAMMISHNESS="${SPAMMISHNESS}${SPAMVAL}"
                SPAMNOTES="${SPAMNOTES}SPAM: ${SPAMVAL} spoofed local user 
$CLEANFROM${NL}"
        }
}

(CLEANFROM and FROM_DOMAIN are extracted from the From: as a matter of 
course in my basic procmailrc -- the code is in my sandbox template).
Basically, if I parse "deliverable" from the string returned by the 
sendmail invocation, sendmail sees it as a valid address (either local, or 
a remote server handles it, which should generally not be the case if it's 
actually a local user).  Anything else, and it would appear to be bogus 
(bad domain, deliberatley rejected in the sendmail settings, etc).
I dunno how well this would work for anyone on some big ISP server (besides 
being sendmail-centric), but on a locally administered server, I know that 
usernames should validate correctly.  If your ISP/office uses LDAP, I 
suppose one could use a client to validate those addresses as well.
The above recipe caught several locally spoofed messages.  Granted, several 
other messages also bore valid usernames (forged, but otherwise valid 
addresses), and those won't be caught by this, but the idea here is to nab 
the messages which have invalid local usernames on them.  Since so little 
of my legit mail will come from the local host (I don't tend to send myself 
a lot of messages, and there's not an abundance of correspondance with 
other local users), the hit from invoking the mta to validate the users is 
nominal.
Since my use of DNSBLs and some stuff at the MTA level has proven 
reasonably effective in blotting out 90+ percent of the chuff I'd otherwise 
have to locally process, I don't know what the effectiveness of this 
approach would be across a more average distribution of spam messages.  If 
anyone happens to have a wildly large spam corpus, I'd be interested in 
hearing how well this performs.
Documenting invocations for other MTAs to do the same thing (and/or 
alternate result strings to look for) would be useful as well.
---
 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.


____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail