You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Christopher Bort <to...@thehundredacre.net> on 2008/07/21 21:30:46 UTC
[OT] Odd spammer tactic?
This is really not a SpamAssassin issue, but since this list is
populated by people who are interested in spammer behavior, I'm
throwing it out for comment. If it's too far off topic, my
apologies and I'll let it go at that.
At $DAYJOB I run a mail server and a name server for several
domains, both our own and for clients. At home, I run a mail
server and a name server for a couple of personal domains. The
home name server is a slave for most of the domains hosted at
$DAYJOB. The home mail server is _not_ configured to handle mail
for any of the $DAYJOB domains and it is _not_ an MX for any of
those domains. The only connection is that it is an NS for the
$DAYJOB domains. These domains _do_ have $DAYJOB mail server as
their MX.
For a while now, I've been seeing attempts to send mail to the
home server for addresses in $DAYJOB domains. This is not a
problem since the volume is low and they are being properly
rejected as third-party relay attempts (authentication required
- relay not permitted). However, the fact that someone is
apparently trying to send mail to an NS instead of an existing
MX has piqued my curiosity. It looks like it's all spam (the
sender addresses tend to support that). So, has anyone else seen
this sort of behavior and what could be the rationale for trying
to deliver mail to an NS like this?
--
Christopher Bort
<to...@thehundredacre.net>
<http://www.thehundredacre.net/>
Re: [OT] Odd spammer tactic?
Posted by DAve <da...@pixelhammer.com>.
Christopher Bort wrote:
> This is really not a SpamAssassin issue, but since this list is
> populated by people who are interested in spammer behavior, I'm throwing
> it out for comment. If it's too far off topic, my apologies and I'll let
> it go at that.
>
> At $DAYJOB I run a mail server and a name server for several domains,
> both our own and for clients. At home, I run a mail server and a name
> server for a couple of personal domains. The home name server is a slave
> for most of the domains hosted at $DAYJOB. The home mail server is _not_
> configured to handle mail for any of the $DAYJOB domains and it is _not_
> an MX for any of those domains. The only connection is that it is an NS
> for the $DAYJOB domains. These domains _do_ have $DAYJOB mail server as
> their MX.
>
> For a while now, I've been seeing attempts to send mail to the home
> server for addresses in $DAYJOB domains. This is not a problem since the
> volume is low and they are being properly rejected as third-party relay
> attempts (authentication required - relay not permitted). However, the
> fact that someone is apparently trying to send mail to an NS instead of
> an existing MX has piqued my curiosity. It looks like it's all spam (the
> sender addresses tend to support that). So, has anyone else seen this
> sort of behavior and what could be the rationale for trying to deliver
> mail to an NS like this?
>
I have, I have also seen attempts to send to the A record as well. I see
no rational explanation except for the hope a poorly configured server
running multiple services (DNS, Web, Mail, etc) will let something slip
through.
DAve
--
Don't tell me I'm driving the cart!
Re: [OT] Odd spammer tactic?
Posted by Marc Perkel <ma...@perkel.com>.
Christopher Bort wrote:
> This is really not a SpamAssassin issue, but since this list is
> populated by people who are interested in spammer behavior, I'm
> throwing it out for comment. If it's too far off topic, my apologies
> and I'll let it go at that.
>
> At $DAYJOB I run a mail server and a name server for several domains,
> both our own and for clients. At home, I run a mail server and a name
> server for a couple of personal domains. The home name server is a
> slave for most of the domains hosted at $DAYJOB. The home mail server
> is _not_ configured to handle mail for any of the $DAYJOB domains and
> it is _not_ an MX for any of those domains. The only connection is
> that it is an NS for the $DAYJOB domains. These domains _do_ have
> $DAYJOB mail server as their MX.
>
> For a while now, I've been seeing attempts to send mail to the home
> server for addresses in $DAYJOB domains. This is not a problem since
> the volume is low and they are being properly rejected as third-party
> relay attempts (authentication required - relay not permitted).
> However, the fact that someone is apparently trying to send mail to an
> NS instead of an existing MX has piqued my curiosity. It looks like
> it's all spam (the sender addresses tend to support that). So, has
> anyone else seen this sort of behavior and what could be the rationale
> for trying to deliver mail to an NS like this?
>
I don't consider it off topic at all. I'm going to look into this. Seems
like a way to feed right into my blacklist.
Re: [OT] Odd spammer tactic?
Posted by Jack Pepper <pe...@autoshun.org>.
Quoting Matus UHLAR - fantomas <uh...@fantomas.sk>:
>
> On 24.07.08 14:35, Michelle Konzack wrote:
>> Are there ANY leagal reasons to declare someons MX as there MX?
>
> Yes, a mistake, or a false assumption by ISP's client.
We have DNS server sharing relationships with some of our biz
partners. It gives us control over the DNS without having to horse
around with ISPs that never get it right. So we all get free backup
DNS.
In one case that I know of, a friend of mine outsourced his DNS to a
hosting provider just too be rid of the headache.
jp
--
Framework? I don't need no steenking framework!
----------------------------------------------------------------
@fferent Security Labs: Isolate/Insulate/Innovate
http://www.afferentsecurity.com
Re: [OT] Odd spammer tactic?
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> Am 2008-07-22 20:23:42, schrieb mouss:
> > There is one caveat in this argument. yes, an MTA would lookup the MX.
> > but it is the MX as seen in DNS, not as seen in _your_ zone.
> >
> > in short, if someone declares you as their MX (without your
> > authorization), you should not start listing clients that try to send
> > mail to such domains.
On 24.07.08 14:35, Michelle Konzack wrote:
> Are there ANY leagal reasons to declare someons MX as there MX?
Yes, a mistake, or a false assumption by ISP's client.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Remember half the people you know are below average.
Re: [OT] Odd spammer tactic?
Posted by mouss <mo...@netoyen.net>.
ram wrote:
> On Fri, 2008-07-25 at 18:15 +0200, Jonas Eckerman wrote:
>[snip]
>
> I think I still miss the point. How can someone else declare the MX of
> my domain. ( dns poisoning ignored ). If that were possible , he would
> be getting my mails which is much more a serious issue
>
- I buy a domain, say foobar.example.
- I declare the MX to point to your IP (your mailserver or anything else)
- I write a message from mouss@foobar.example to sales/infos/jobs/....
at some company, or I send a subscription request to a mailing-list
- said company or mailing-list will then connect your your server trying
to delivered to mouss@foobar.example
- you consider this as a relay attempt and blocklist the _innocent_
client IP.
is it clear now?
in short, if you see mail coming in that shouldn't come in, don't list
the source without investigation.
>
> Anyway for the stats I just created two brand new "A" records with
> mail.domain.com just for testing , and pointed to a fake smtp server
> No Mxes pointing to that IP so no real mail should come here
> For the last 3 days , 154 distinct ips have connected and of them 144
> are already listed in zen.spamhaus.org
>
> So it doesnt seem to be a very useful effort afterall to list those
> ips :-(. I would have blocked those mails with spamhaus anyway
for people who want to reduce external calls (for both their good and
that of spamhaus and friends), a local blacklist is advantageous.
however, it doesn't come for free. you need to be careful when listing
an IP, and you need to maintain the list (machines get fixed, IPs get
reassigned, ... etc). if this is too much work, then forget about it.
Re: [OT] Odd spammer tactic?
Posted by ram <ra...@netcore.co.in>.
On Fri, 2008-07-25 at 18:15 +0200, Jonas Eckerman wrote:
> Michelle Konzack wrote:
>
> >> in short, if someone declares you as their MX (without your
> >> authorization), you should not start listing clients that try to send
> >> mail to such domains.
>
> > Are there ANY leagal reasons to declare someons MX as there MX?
>
> You miss mouss' point.
>
> If someone (maliciously or by mistake) declare your system as
> their MX, innocent third party mail servers may through no fault
> of their own connect to your system in order to send mail to
> addresses for wich your system is not a MX.
I think I still miss the point. How can someone else declare the MX of
my domain. ( dns poisoning ignored ). If that were possible , he would
be getting my mails which is much more a serious issue
Anyway for the stats I just created two brand new "A" records with
mail.domain.com just for testing , and pointed to a fake smtp server
No Mxes pointing to that IP so no real mail should come here
For the last 3 days , 154 distinct ips have connected and of them 144
are already listed in zen.spamhaus.org
So it doesnt seem to be a very useful effort afterall to list those
ips :-(. I would have blocked those mails with spamhaus anyway
Thanks
Ram
Re: [OT] Odd spammer tactic?
Posted by mouss <mo...@netoyen.net>.
Jonas Eckerman wrote:
> Michelle Konzack wrote:
>
>>> in short, if someone declares you as their MX (without your
>>> authorization), you should not start listing clients that try to send
>>> mail to such domains.
>
>> Are there ANY leagal reasons to declare someons MX as there MX?
>
> You miss mouss' point.
>
> If someone (maliciously or by mistake) declare your system as their MX,
> innocent third party mail servers may through no fault of their own
> connect to your system in order to send mail to addresses for wich your
> system is not a MX.
>
> If you allow the connecting system to get as far as RCPT TO: you could
> check if someone has set the MX for the recipient address(es) to point
> at your system before listing the client (and that would also give the
> opportunity to contact whoever is responsible for the bad MX record).
>
> For a well known connection trap, this might well be a very important
> precaution as spammers might otherwise try to poison the list.
>
exactly.
More generally all the approches that are based on "this pattern means
this is an attacker" must be seriously analyzed. this includes
- "nobody should try to connect to this port". if you don't allow for a
tcp session to be established, an attacker can spoof an IP and you would
list an innocent IP.
- "spammers close the connection without a quit". probably, but a
connection may be broken for other reasons (system reboot, lost
connectivity, ...).
- "only spammers go to my second MX when my first is up". sure, but just
because you see it p doesn't mean other people can connect to.
- "this address only gets spam" (spamtrap). probably. but can you prove it?
- ... etc
what I mean is that you need to analyze your "rule" before implementing
it. and you need to analyze your implementation as well.
people often take care against many sorts of attacks. but when blocking,
they don't realize that they are vulnerable to similar attacks. remember
that fail2ban "injection" attack (you put the victim IP in the login, so
that fail2ban blocks the victim IP)? and how many people try to block
IPs because of port scans just to block victims of IP spoofing? ... etc.
Re: [OT] Odd spammer tactic?
Posted by Jonas Eckerman <jo...@frukt.org>.
Michelle Konzack wrote:
>> in short, if someone declares you as their MX (without your
>> authorization), you should not start listing clients that try to send
>> mail to such domains.
> Are there ANY leagal reasons to declare someons MX as there MX?
You miss mouss' point.
If someone (maliciously or by mistake) declare your system as
their MX, innocent third party mail servers may through no fault
of their own connect to your system in order to send mail to
addresses for wich your system is not a MX.
If you allow the connecting system to get as far as RCPT TO: you
could check if someone has set the MX for the recipient
address(es) to point at your system before listing the client
(and that would also give the opportunity to contact whoever is
responsible for the bad MX record).
For a well known connection trap, this might well be a very
important precaution as spammers might otherwise try to poison
the list.
Regards
/Jonas
--
Jonas Eckerman, FSDB & Fruktträdet
http://whatever.frukt.org/
http://www.fsdb.org/
http://www.frukt.org/
Re: [OT] Odd spammer tactic?
Posted by Michelle Konzack <li...@tamay-dogan.net>.
Am 2008-07-22 20:23:42, schrieb mouss:
> There is one caveat in this argument. yes, an MTA would lookup the MX.
> but it is the MX as seen in DNS, not as seen in _your_ zone.
>
> in short, if someone declares you as their MX (without your
> authorization), you should not start listing clients that try to send
> mail to such domains.
Are there ANY leagal reasons to declare someons MX as there MX?
Only the owner of a BOTNET would do this...
> This is one problem with the MX "standard". anybody can list your
> servers as their MX. there is no authorization mechanism.
>
> so when collecting such "anomalies", you need to do some checks before
> listing the client. as a result, you need the "intended" recipient. in
> which case, a real smtp daemon is the right choice.
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Re: [OT] Odd spammer tactic?
Posted by mouss <mo...@netoyen.net>.
Ramprasad wrote:
> Marc Perkel wrote:
>> There's people out there who are better and faster programmers than I
>> am. I need a simple utility written We can post it on the SA Wiki when
>> we're done.
>>
>> I don't care what it's written in but I'm thinking that xinetd might
>> be easiest. What I want is something to record the IP address of any
>> host connection to port 25. Then going to need it to run a one line
>> script file that runc netcat (nc) and sends me data. Basically I just
>> need te IP address. I have a collector program listening that feeds
>> the blacklist system. The collector is.
>>
>> echo "$*" | nc -w 2 <host> <port>
>> exit 0
>>
> You mean you need a script will listen to port 25 instead of a smtpd
> daemon ?
> Will be a trivial thing to do?
> What should this do , just log to syslog the IP's and break connection
> immediately after connect
>
>
>
>
>
>> The idea of this project is to collect hits on port 25 of computers
>> that shouldn't be hit on port 25. Thses hits would be 100% spambots
>> and hackers. They hit it - they get listed.
>>
>> I'll share my collector code, which is a one line script.
>>
>> socat -u TCP4-LISTEN:<port>,reuseaddr,fork OPEN:/logfile &
>>
>> The pair of these programs can be used to collect any kind of data
>> base on trouble makers hitting port that shouldn't be hit. This could
>> be used for ssh attempts - anything. These programs feed IP collection
>> systems and then some task manages the list, rotates it, and generates
>> DNS blacklists.
>>
>> I'm thinking such a system might be really useful.
> Yes , I think that would give a zero fp blacklist on ip's
> Any real MTA would mx lookup ,
> IMO If mail is sent on non mx ips the mail is spam and the ip is of a
> spammer
> (internal misconfigured transport relays need to be excluded )
There is one caveat in this argument. yes, an MTA would lookup the MX.
but it is the MX as seen in DNS, not as seen in _your_ zone.
in short, if someone declares you as their MX (without your
authorization), you should not start listing clients that try to send
mail to such domains.
This is one problem with the MX "standard". anybody can list your
servers as their MX. there is no authorization mechanism.
so when collecting such "anomalies", you need to do some checks before
listing the client. as a result, you need the "intended" recipient. in
which case, a real smtp daemon is the right choice.
Re: [OT] Odd spammer tactic?
Posted by Jack Pepper <pe...@autoshun.org>.
Quoting Marc Perkel <ma...@perkel.com>:
>
>
> Ramprasad wrote:
>>> I don't care what it's written in but I'm thinking that xinetd
>>> might be easiest. What I want is something to record the IP
>>> address of any host connection to port 25. Then going to need it
>>> to run a one line script file that runc netcat (nc) and sends me
>>> data. Basically I just need te IP address. I have a collector
>>> program listening that feeds the blacklist system. The collector is.
>>>
Here is a little program I wrote a while back for just this purpose.
Change lines 58ff as you see fit for your purposes. I have modified
the listening port to 25 and put a plausible looking banner lines on it.
also I have attached an RC file to start it up. Let me know how it works out.
jp
--
Framework? I don't need no steenking framework!
----------------------------------------------------------------
@fferent Security Labs: Isolate/Insulate/Innovate
http://www.afferentsecurity.com
Re: [OT] Odd spammer tactic?
Posted by Marc Perkel <ma...@perkel.com>.
Ramprasad wrote:
> Marc Perkel wrote:
>> There's people out there who are better and faster programmers than I
>> am. I need a simple utility written We can post it on the SA Wiki
>> when we're done.
>>
>> I don't care what it's written in but I'm thinking that xinetd might
>> be easiest. What I want is something to record the IP address of any
>> host connection to port 25. Then going to need it to run a one line
>> script file that runc netcat (nc) and sends me data. Basically I just
>> need te IP address. I have a collector program listening that feeds
>> the blacklist system. The collector is.
>>
>> echo "$*" | nc -w 2 <host> <port>
>> exit 0
>>
> You mean you need a script will listen to port 25 instead of a smtpd
> daemon ?
> Will be a trivial thing to do?
> What should this do , just log to syslog the IP's and break connection
> immediately after connect
>
>
Yes - the idea being that you have some service, like a name server,
that there is no reason at all that anything should be connecting to
port 25 on and everything that attempts to connect on it is spam. So
it's not an MTA but just a script (xinetd -> shel script - or perl) that
closes the connection immediately and sends the IP to a central
collector that accumulates information and builds blacklists that can be
used by Spamassassin.
>
>
>
>> The idea of this project is to collect hits on port 25 of computers
>> that shouldn't be hit on port 25. Thses hits would be 100% spambots
>> and hackers. They hit it - they get listed.
>>
>> I'll share my collector code, which is a one line script.
>>
>> socat -u TCP4-LISTEN:<port>,reuseaddr,fork OPEN:/logfile &
>>
>> The pair of these programs can be used to collect any kind of data
>> base on trouble makers hitting port that shouldn't be hit. This could
>> be used for ssh attempts - anything. These programs feed IP
>> collection systems and then some task manages the list, rotates it,
>> and generates DNS blacklists.
>>
>> I'm thinking such a system might be really useful.
> Yes , I think that would give a zero fp blacklist on ip's
> Any real MTA would mx lookup ,
> IMO If mail is sent on non mx ips the mail is spam and the ip is of a
> spammer
> (internal misconfigured transport relays need to be excluded )
>
>
Yep - you got it.
Re: [OT] Odd spammer tactic?
Posted by Ramprasad <ra...@netcore.co.in>.
Marc Perkel wrote:
> There's people out there who are better and faster programmers than I
> am. I need a simple utility written We can post it on the SA Wiki when
> we're done.
>
> I don't care what it's written in but I'm thinking that xinetd might
> be easiest. What I want is something to record the IP address of any
> host connection to port 25. Then going to need it to run a one line
> script file that runc netcat (nc) and sends me data. Basically I just
> need te IP address. I have a collector program listening that feeds
> the blacklist system. The collector is.
>
> echo "$*" | nc -w 2 <host> <port>
> exit 0
>
You mean you need a script will listen to port 25 instead of a smtpd
daemon ?
Will be a trivial thing to do?
What should this do , just log to syslog the IP's and break connection
immediately after connect
> The idea of this project is to collect hits on port 25 of computers
> that shouldn't be hit on port 25. Thses hits would be 100% spambots
> and hackers. They hit it - they get listed.
>
> I'll share my collector code, which is a one line script.
>
> socat -u TCP4-LISTEN:<port>,reuseaddr,fork OPEN:/logfile &
>
> The pair of these programs can be used to collect any kind of data
> base on trouble makers hitting port that shouldn't be hit. This could
> be used for ssh attempts - anything. These programs feed IP collection
> systems and then some task manages the list, rotates it, and generates
> DNS blacklists.
>
> I'm thinking such a system might be really useful.
Yes , I think that would give a zero fp blacklist on ip's
Any real MTA would mx lookup ,
IMO If mail is sent on non mx ips the mail is spam and the ip is of a
spammer
(internal misconfigured transport relays need to be excluded )
===================================================================
sms START NEWS <your city> to 09845398453 for Breaking News and Top
Stories on Business, Sports & Politics. For more services visit
http://www.mytodaysms.com
===================================================================
Re: [OT] Odd spammer tactic?
Posted by Marc Perkel <ma...@perkel.com>.
Jonas - thanks for your code. I ran it on one of my name servers that is
the name server for several hundred domains. Unfortunately in the last
hour only 3 IP addresses have hit trying to talk to port 25. So this
isn't turning out to be the wellspring of blacklist data I had hoped it
would be.
Jonas Eckerman wrote:
> Marc Perkel wrote:
>
>> I don't care what it's written in but I'm thinking that xinetd might
>> be easiest. What I want is something to record the IP address of any
>> host connection to port 25.
>
> You don't really need to accept the connection. Just logging
> connection attenmpts should be enough.
>
> As an examplem something like this (watch for wrapping):
>
> tcpdump -lnpqt -i vr0 'tcp[13] & 2 != 0 and dst port 25 and dst host
> 195.67.112.220'
>
> Should output lines like:
>
> 213.163.128.161.48278 > 195.67.112.220.25: tcp 0 (DF)
> 213.163.128.161.48279 > 195.67.112.220.25: tcp 0 (DF)
> 190.84.222.78.2106 > 195.67.112.220.25: tcp 0 (DF)
>
> for each connection attempt to port 25 on 195.67.112.220.
>
> If port 25 is firewalled usinbg pf, vr0 should probably be replaced
> with "pflog0". Similar setup should be doable with other firewalls
> that create a log interface for tcpdump.
>
> Then you can filter that output to remove evevrything but the IP address.
>
> For example
>
> tcpdump -lnpqt -i vr0 'tcp[13] & 2 != 0 and dst port 25 and dst host
> 195.67.112.220' | sed -e 's/\.[0-9]* .*$//'
>
> should output just the IP numbers.
>
> So maybe something like this should work:
>
> tcpdump -lnpqt -i <interface> 'tcp[13] & 2 != 0 and dst port 25 and
> dst host <host>' | sed -e 's/\.[0-9]* .*$//' | nc -u 2 <host> <port>
>
> It could be running in a detached session. (And yes, the '-u' is on
> purpose, I think UDP is good for this kind of thing.)
>
> Please not that the above is untested and that I'm not used to working
> with sed or netcat.
>
> Regards
> /Jonas
Re: [OT] Odd spammer tactic?
Posted by Jonas Eckerman <jo...@frukt.org>.
Marc Perkel wrote:
> I don't care what it's written in but I'm thinking that xinetd might be
> easiest. What I want is something to record the IP address of any host
> connection to port 25.
You don't really need to accept the connection. Just logging
connection attenmpts should be enough.
As an examplem something like this (watch for wrapping):
tcpdump -lnpqt -i vr0 'tcp[13] & 2 != 0 and dst port 25 and dst
host 195.67.112.220'
Should output lines like:
213.163.128.161.48278 > 195.67.112.220.25: tcp 0 (DF)
213.163.128.161.48279 > 195.67.112.220.25: tcp 0 (DF)
190.84.222.78.2106 > 195.67.112.220.25: tcp 0 (DF)
for each connection attempt to port 25 on 195.67.112.220.
If port 25 is firewalled usinbg pf, vr0 should probably be
replaced with "pflog0". Similar setup should be doable with other
firewalls that create a log interface for tcpdump.
Then you can filter that output to remove evevrything but the IP
address.
For example
tcpdump -lnpqt -i vr0 'tcp[13] & 2 != 0 and dst port 25 and dst
host 195.67.112.220' | sed -e 's/\.[0-9]* .*$//'
should output just the IP numbers.
So maybe something like this should work:
tcpdump -lnpqt -i <interface> 'tcp[13] & 2 != 0 and dst port 25
and dst host <host>' | sed -e 's/\.[0-9]* .*$//' | nc -u 2 <host>
<port>
It could be running in a detached session. (And yes, the '-u' is
on purpose, I think UDP is good for this kind of thing.)
Please not that the above is untested and that I'm not used to
working with sed or netcat.
Regards
/Jonas
--
Jonas Eckerman, FSDB & Fruktträdet
http://whatever.frukt.org/
http://www.fsdb.org/
http://www.frukt.org/
Re: [OT] Odd spammer tactic?
Posted by Marc Perkel <ma...@perkel.com>.
There's people out there who are better and faster programmers than I
am. I need a simple utility written We can post it on the SA Wiki when
we're done.
I don't care what it's written in but I'm thinking that xinetd might be
easiest. What I want is something to record the IP address of any host
connection to port 25. Then going to need it to run a one line script
file that runc netcat (nc) and sends me data. Basically I just need te
IP address. I have a collector program listening that feeds the
blacklist system. The collector is.
echo "$*" | nc -w 2 <host> <port>
exit 0
The idea of this project is to collect hits on port 25 of computers that
shouldn't be hit on port 25. Thses hits would be 100% spambots and
hackers. They hit it - they get listed.
I'll share my collector code, which is a one line script.
socat -u TCP4-LISTEN:<port>,reuseaddr,fork OPEN:/logfile &
The pair of these programs can be used to collect any kind of data base
on trouble makers hitting port that shouldn't be hit. This could be used
for ssh attempts - anything. These programs feed IP collection systems
and then some task manages the list, rotates it, and generates DNS
blacklists.
I'm thinking such a system might be really useful.
Who likes this idea?
Re: [OT] Odd spammer tactic?
Posted by Ramprasad <ra...@netcore.co.in>.
Christopher Bort wrote:
> This is really not a SpamAssassin issue, but since this list is
> populated by people who are interested in spammer behavior, I'm
> throwing it out for comment. If it's too far off topic, my apologies
> and I'll let it go at that.
>
> At $DAYJOB I run a mail server and a name server for several domains,
> both our own and for clients. At home, I run a mail server and a name
> server for a couple of personal domains. The home name server is a
> slave for most of the domains hosted at $DAYJOB. The home mail server
> is _not_ configured to handle mail for any of the $DAYJOB domains and
> it is _not_ an MX for any of those domains. The only connection is
> that it is an NS for the $DAYJOB domains. These domains _do_ have
> $DAYJOB mail server as their MX.
>
> For a while now, I've been seeing attempts to send mail to the home
> server for addresses in $DAYJOB domains. This is not a problem since
> the volume is low and they are being properly rejected as third-party
> relay attempts (authentication required - relay not permitted).
> However, the fact that someone is apparently trying to send mail to an
> NS instead of an existing MX has piqued my curiosity. It looks like
> it's all spam (the sender addresses tend to support that). So, has
> anyone else seen this sort of behavior and what could be the rationale
> for trying to deliver mail to an NS like this?
>
I have seen that spammers usually target most available "A" records of
a domain
So if a domain is example.com All machines , mail.example.com ,
example.com , ns.example.com etc are all targeted.
Remove the A record ns.example.com ( if possible ) and you will see
spams disappear
Unfortunately this works :-( in evading spam filters in far too many
cases. A lot of domains host their websites/mailboxes/DNS on shared
servers who do not offer any protection at SMTP levels .Even if the
customer subscribes to a third party Antispam solution and points his MX
to a spam filter the spammer easily sends his mail to the unportected
mailhost server and gets straight to the inbox. We ourselves had
extremely tough times explaining to clients
Probably Spamassassin Comunity needs to develop a email client plugin
that can detect such mails
Thanks
Ram
===================================================================
sms START NEWS <your city> to 09845398453 for Breaking News and Top
Stories on Business, Sports & Politics. For more services visit
http://www.mytodaysms.com
===================================================================
Re: [OT] Odd spammer tactic?
Posted by John Hardin <jh...@impsec.org>.
On Mon, 2008-07-21 at 12:30 -0700, Christopher Bort wrote:
> For a while now, I've been seeing attempts to send mail to the
> home server for addresses in $DAYJOB domains. This is not a
> problem since the volume is low and they are being properly
> rejected as third-party relay attempts (authentication required
> - relay not permitted). However, the fact that someone is
> apparently trying to send mail to an NS instead of an existing
> MX has piqued my curiosity. It looks like it's all spam (the
> sender addresses tend to support that).
Marc, this might be another way for you to collect your spam zombie
data. Offer a free public secondary-DNS service and run your dummy MTA
on that box. That way you're inherently rewarding (at least a little
bit) the people who are cooperating to provide you data.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
If Microsoft made hammers, everyone would whine about how poorly
screws were designed and about how they are hard to hammer in, and
wonder why it takes so long to paint a wall using the hammer.
-----------------------------------------------------------------------
Today: the 39th anniversary of Man's first steps on the Moon
Re: [OT] Odd spammer tactic?
Posted by mouss <mo...@netoyen.net>.
Matus UHLAR - fantomas wrote:
>> On Tue, Jul 22, 2008 at 12:00 PM, Bob McClure Jr <bo...@bobcatos.com> wrote:
>>> I figure only the latter will be the Final Solution to spam. But
>>> there are probably only two chances of that - slim and none.
>
> Guess which one are you?
>
> http://www.rhyolite.com/anti-spam/you-might-be.html
>
> On 22.07.08 16:01, Noel Jones wrote:
>> There isn't a Final Solution without replacing SMTP with something else,
>> and there is no agreement on what the "something else" should look like.
>> Likely it too would be exploited, but in new and interesting ways...
>
> and what about you?
>
> http://www.rhyolite.com/anti-spam/you-might-be.html#programmer-11
>
>
The way I understand it, Noel meant that there are problems that are
inherent to smtp, so you can't fix them without replacing smtp.
anyway, for all what it's worth, rhyolite is not the bible. there are
too many opinions and I'm happy with that, as long as people don't try
to convince us that their way is the only one. Bomb Irak if that gets
you elected, but count me out.
Re: [OT] Odd spammer tactic?
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> On Tue, Jul 22, 2008 at 12:00 PM, Bob McClure Jr <bo...@bobcatos.com> wrote:
> > I figure only the latter will be the Final Solution to spam. But
> > there are probably only two chances of that - slim and none.
Guess which one are you?
http://www.rhyolite.com/anti-spam/you-might-be.html
On 22.07.08 16:01, Noel Jones wrote:
> There isn't a Final Solution without replacing SMTP with something else,
> and there is no agreement on what the "something else" should look like.
> Likely it too would be exploited, but in new and interesting ways...
and what about you?
http://www.rhyolite.com/anti-spam/you-might-be.html#programmer-11
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Enter any 12-digit prime number to continue.
Re: [OT] Odd spammer tactic?
Posted by Richard Frovarp <ri...@sendit.nodak.edu>.
Noel Jones wrote:
> On Tue, Jul 22, 2008 at 12:00 PM, Bob McClure Jr <bob@bobcatos.com
> <ma...@bobcatos.com>> wrote:
>
> If I may extend this OT thread, I'd like to know how draconian admins
> get with their mail servers. Without considering RBLs, how much do
> you limit client connections:
>
> Allow only those with (PTR and/or A) DNS records?
>
>
> It's becoming common to reject clients with no PTR, but there are
> still many legit hosts using an ISP that doesn't offer PTR. So this
> is not universally acceptable and prone to false positives. This also
> isn't terribly effective since many botted machines have proper DNS
> entries.
>
> It would be nice if all ISP's firewalled port 25 and offered a
> self-service interface so the customer could unblock it if they run a
> server. 99% of customers would never notice that port 25 was blocked.
>
>
Many do. That is why 587 is becoming popular for authenticated mail.
Without it, many users would notice, as they would no longer be able to
use their work's SMTP for those email addresses.
Richard
Re: [OT] Odd spammer tactic?
Posted by Noel Jones <no...@gmail.com>.
On Tue, Jul 22, 2008 at 12:00 PM, Bob McClure Jr <bo...@bobcatos.com> wrote:
> If I may extend this OT thread, I'd like to know how draconian admins
> get with their mail servers. Without considering RBLs, how much do
> you limit client connections:
>
> Allow only those with (PTR and/or A) DNS records?
It's becoming common to reject clients with no PTR, but there are still many
legit hosts using an ISP that doesn't offer PTR. So this is not universally
acceptable and prone to false positives. This also isn't terribly effective
since many botted machines have proper DNS entries.
It would be nice if all ISP's firewalled port 25 and offered a self-service
interface so the customer could unblock it if they run a server. 99% of
customers would never notice that port 25 was blocked.
> Allow only those with MX records?
You mean only accept mail if the sender domain lists the client as an MX?
That doesn't work - too many orginazations use split systems where sending
and receiving hosts are on different IPs or even different netblocks.
SPF is a start at giving the sender control over what IPs are allowed to
send mail, but it's not without problems.
>
>
> I figure only the latter will be the Final Solution to spam. But
> there are probably only two chances of that - slim and none.
There isn't a Final Solution without replacing SMTP with something else, and
there is no agreement on what the "something else" should look like. Likely
it too would be exploited, but in new and interesting ways...
--
Noel Jones
Re: [OT] Odd spammer tactic?
Posted by mouss <mo...@netoyen.net>.
Bob McClure Jr wrote:
> [snip]
>> - delay (or block, depending on your implementation) good networks in
>> case of DNS problems. (the dspam domain was once under DDoS. delaying
>> their _sollicted_ mail is not really nice).
>
> Yeah, bummer. Maybe make an exception if DNS is unavailable, or soft
> fail.
>
In this case, greylisting is safer.
>>> Allow only those with MX records?
>> if the envelope sender domain has no MX nor A record (or has an invalid
>> or borked MX), you can block. but this doesn't catch much junk. It does
>> however catch legitimate mail in case of misconfiguration.
>
> No, I don't mean that of the envelope sender - that means nothing. I
> mean that the client machine must be listed as an MX. That said, yes,
> I know, many installations (e.g. two of my clients) have separate IPs
> for sending and receiving mail, so the sender is not listed as an MX.
> And if it were so listed as a (secondary) MX and did not accept mail,
> then it's busted for being a bogus MX. <sigh> Never mind.
>
as you say, there is no reason for an "RMX" to be an MX, and there is no
way to know whether an IP is an RMX (well, there is SPF, but let's not
restart the old debate...).
>>> I figure only the latter will be the Final Solution to spam.
>> final what? fussp?
>>
>>
>> since spammers forge the sender, sender checks don't buy you much.
>>
>>> But
>>> there are probably only two chances of that - slim and none.
>
> Where is the Lone Ranger when you need him? (Silver bullet reference.)
he went to buy some petrol for cheap :)
Re: [OT] Odd spammer tactic?
Posted by Bob McClure Jr <bo...@bobcatos.com>.
On Tue, Jul 22, 2008 at 08:38:09PM +0200, mouss wrote:
> Bob McClure Jr wrote:
> >On Tue, Jul 22, 2008 at 11:37:39AM -0400, Kevin Parris wrote:
> >><snippage>
> >>
> >>The spammers are spending other people's money, since much of their
> >>"work" is done by hijacked machines, thus they do not care how
> >>'expensive' their project might be, and any responses they do get
> >>are practically pure profit. So to probe a million targets and find
> >>even one vulnerable is "worth the trouble" since it is not their own
> >>trouble.
> >>
> >>The flaw in your logic is that you are thinking logically, working
> >>from the premise that any intelligent administrator (such as
> >>yourself) would never create a machine that is susceptible to this
> >>particular attack. Maybe YOUR server is not a viable avenue for the
> >>spammer, but there are SO many servers out there - finding a few
> >>that ARE viable is almost a certainty, since some people who connect
> >>systems to the internet are not so well-informed as we here.
> >>
> >>I believe that until a technique is discovered to eliminate
> >>ignorance and gullibility from the human population, there will be
> >>no solution to the spam problem.
> >
> >If I may extend this OT thread, I'd like to know how draconian admins
> >get with their mail servers. Without considering RBLs, how much do
> >you limit client connections:
> >
> >Allow only those with (PTR and/or A) DNS records?
>
> unfortunately, this would
> - block silly networks with misconfigured DNS, but from which you still
> want to get mail.
Yeah, I know that, and, in fact, one of my clients' DNS was
misconfigured (not in my power to fix) until recently. Be nice if
there were some suitable mechanism to feed such info back to owner
besides the distant end calling/emailing to say, "Hey, did you know
your DNS is fubar?" I'm still not all that far from imposing such a
restriction on my own server.
> - delay (or block, depending on your implementation) good networks in
> case of DNS problems. (the dspam domain was once under DDoS. delaying
> their _sollicted_ mail is not really nice).
Yeah, bummer. Maybe make an exception if DNS is unavailable, or soft
fail.
> >Allow only those with MX records?
>
> if the envelope sender domain has no MX nor A record (or has an invalid
> or borked MX), you can block. but this doesn't catch much junk. It does
> however catch legitimate mail in case of misconfiguration.
No, I don't mean that of the envelope sender - that means nothing. I
mean that the client machine must be listed as an MX. That said, yes,
I know, many installations (e.g. two of my clients) have separate IPs
for sending and receiving mail, so the sender is not listed as an MX.
And if it were so listed as a (secondary) MX and did not accept mail,
then it's busted for being a bogus MX. <sigh> Never mind.
> >
> >I figure only the latter will be the Final Solution to spam.
>
> final what? fussp?
>
>
> since spammers forge the sender, sender checks don't buy you much.
>
> > But
> >there are probably only two chances of that - slim and none.
Where is the Lone Ranger when you need him? (Silver bullet reference.)
Cheers,
--
Bob McClure, Jr. Bobcat Open Systems, Inc.
bob@bobcatos.com http://www.bobcatos.com
Jesus turned and saw her. "Take heart, daughter," he said, "your faith
has healed you." And the woman was healed from that moment.
Matthew 9:22 (NIV)
Re: [OT] Odd spammer tactic?
Posted by mouss <mo...@netoyen.net>.
Bob McClure Jr wrote:
> On Tue, Jul 22, 2008 at 11:37:39AM -0400, Kevin Parris wrote:
>> <snippage>
>>
>> The spammers are spending other people's money, since much of their
>> "work" is done by hijacked machines, thus they do not care how
>> 'expensive' their project might be, and any responses they do get
>> are practically pure profit. So to probe a million targets and find
>> even one vulnerable is "worth the trouble" since it is not their own
>> trouble.
>>
>> The flaw in your logic is that you are thinking logically, working
>> from the premise that any intelligent administrator (such as
>> yourself) would never create a machine that is susceptible to this
>> particular attack. Maybe YOUR server is not a viable avenue for the
>> spammer, but there are SO many servers out there - finding a few
>> that ARE viable is almost a certainty, since some people who connect
>> systems to the internet are not so well-informed as we here.
>>
>> I believe that until a technique is discovered to eliminate
>> ignorance and gullibility from the human population, there will be
>> no solution to the spam problem.
>
> If I may extend this OT thread, I'd like to know how draconian admins
> get with their mail servers. Without considering RBLs, how much do
> you limit client connections:
>
> Allow only those with (PTR and/or A) DNS records?
unfortunately, this would
- block silly networks with misconfigured DNS, but from which you still
want to get mail.
- delay (or block, depending on your implementation) good networks in
case of DNS problems. (the dspam domain was once under DDoS. delaying
their _sollicted_ mail is not really nice).
> Allow only those with MX records?
if the envelope sender domain has no MX nor A record (or has an invalid
or borked MX), you can block. but this doesn't catch much junk. It does
however catch legitimate mail in case of misconfiguration.
>
> I figure only the latter will be the Final Solution to spam.
final what? fussp?
since spammers forge the sender, sender checks don't buy you much.
> But
> there are probably only two chances of that - slim and none.
Re: [OT] Odd spammer tactic?
Posted by Bob McClure Jr <bo...@bobcatos.com>.
On Tue, Jul 22, 2008 at 11:37:39AM -0400, Kevin Parris wrote:
> <snippage>
>
> The spammers are spending other people's money, since much of their
> "work" is done by hijacked machines, thus they do not care how
> 'expensive' their project might be, and any responses they do get
> are practically pure profit. So to probe a million targets and find
> even one vulnerable is "worth the trouble" since it is not their own
> trouble.
>
> The flaw in your logic is that you are thinking logically, working
> from the premise that any intelligent administrator (such as
> yourself) would never create a machine that is susceptible to this
> particular attack. Maybe YOUR server is not a viable avenue for the
> spammer, but there are SO many servers out there - finding a few
> that ARE viable is almost a certainty, since some people who connect
> systems to the internet are not so well-informed as we here.
>
> I believe that until a technique is discovered to eliminate
> ignorance and gullibility from the human population, there will be
> no solution to the spam problem.
If I may extend this OT thread, I'd like to know how draconian admins
get with their mail servers. Without considering RBLs, how much do
you limit client connections:
Allow only those with (PTR and/or A) DNS records?
Allow only those with MX records?
I figure only the latter will be the Final Solution to spam. But
there are probably only two chances of that - slim and none.
> <snippage>
>
> --
> Christopher Bort
> <to...@thehundredacre.net>
> <http://www.thehundredacre.net/>
Cheers,
--
Bob McClure, Jr. Bobcat Open Systems, Inc.
bob@bobcatos.com http://www.bobcatos.com
Jesus turned and saw her. "Take heart, daughter," he said, "your faith
has healed you." And the woman was healed from that moment.
Matthew 9:22 (NIV)
Re: [OT] Odd spammer tactic?
Posted by John Hardin <jh...@impsec.org>.
On Tue, 2008-07-22 at 11:37 -0400, Kevin Parris wrote:
> I believe that until a technique is discovered to eliminate ignorance and gullibility from the human population, there will be no solution to the spam problem.
Nah, spammers just need to start dying messy, well-publicised deaths.
The cost side of the cost/benefit analysis needs to be increased, and
trying to increase that cost within the technology-based part of the
system is doomed to failure given the amazing ability of technology to
reduce communication costs.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
End users want eye candy and the "ooo's and aaaahhh's" experience
when reading mail. To them email isn't a tool, but an entertainment
form. -- Steve Lake
-----------------------------------------------------------------------
13 days until the 273rd anniversary of John Peter Zenger's acquittal
Re: [OT] Odd spammer tactic?
Posted by Kevin Parris <KP...@ed.sc.gov>.
Spammers operate on the premise that lots of stupid people read email. For example, only stupid people would actually respond to an offer to sell medications, from a service that does not spell the product name correctly (they are either too stupid to recognize the deviant spelling even though the correct version is all over TV and magazines, or too stupid to realize it means the offeror is ethics challenged). But these offers are getting responses, or the spammers would not keep sending them.
The spammers are spending other people's money, since much of their "work" is done by hijacked machines, thus they do not care how 'expensive' their project might be, and any responses they do get are practically pure profit. So to probe a million targets and find even one vulnerable is "worth the trouble" since it is not their own trouble.
The flaw in your logic is that you are thinking logically, working from the premise that any intelligent administrator (such as yourself) would never create a machine that is susceptible to this particular attack. Maybe YOUR server is not a viable avenue for the spammer, but there are SO many servers out there - finding a few that ARE viable is almost a certainty, since some people who connect systems to the internet are not so well-informed as we here.
I believe that until a technique is discovered to eliminate ignorance and gullibility from the human population, there will be no solution to the spam problem.
>>> Christopher Bort <to...@thehundredacre.net> 07/21/08 3:30 PM >>>
This is really not a SpamAssassin issue, but since this list is populated by people who are interested in spammer behavior, I'm throwing it out for comment. If it's too far off topic, my apologies and I'll let it go at that.
At $DAYJOB I run a mail server and a name server for several domains, both our own and for clients. At home, I run a mail server and a name server for a couple of personal domains. The home name server is a slave for most of the domains hosted at $DAYJOB. The home mail server is _not_ configured to handle mail for any of the $DAYJOB domains and it is _not_ an MX for any of those domains. The only connection is that it is an NS for the $DAYJOB domains. These domains _do_ have $DAYJOB mail server as their MX.
For a while now, I've been seeing attempts to send mail to the home server for addresses in $DAYJOB domains. This is not a problem since the volume is low and they are being properly rejected as third-party relay attempts (authentication required - relay not permitted). However, the fact that someone is apparently trying to send mail to an NS instead of an existing MX has piqued my curiosity. It looks like it's all spam (the sender addresses tend to support that). So, has anyone else seen this sort of behavior and what could be the rationale for trying to deliver mail to an NS like this?
--
Christopher Bort
<to...@thehundredacre.net>
<http://www.thehundredacre.net/>
Re: [OT] Odd spammer tactic?
Posted by Bob Proulx <bo...@proulx.com>.
Christopher Bort wrote:
> Bob Proulx wrote:
> > You are trying to apply logic to a situation to which no reason can be
> > applied. Spammers do not operate with a sanity of reason and logic.
> > There is intelligence. But bludgeoning others for their own gain only
> > makes sense to them and not to members of society.
>
> True enough. I suppose it's a good thing that I'm not entirely
> able to think like a spammer. ;-)
People who see the exploits that are possible but work for the good of
others are called "whitehats". Bruce Schneier made an interesting
comment concerning ant farms related to this type of mindset[1].
I think the important thing is that if you are one of those that
always see how things can fail or be exploited that you work to solve
the problems. (This is where test driven development comes from and
where security comes from and so forth.) And that if you are not one
of those people that you don't become a block to improvements. Too
often people close their eyes, put their fingers in their ears and
hum. Instead they should be receptive to people trying to help them.
> > Spammers base their existence upon extremely low probabilities
> > multiplied by very large numbers of messages.
>
> True again. Your comments essentially reflect my own assessment,
> but I was curious enough about it to bring it up on a list like
> this one to see if I was missing some twist that would make an
> iota of sense, but I guess not.
It does make sense. You don't see it from the spammer's perspective.
Someone who is running a nameserver for a domain just might at some
very small probability be slightly more likely to allow relaying for
that domain than other random servers on the network.
But I think it is the reverse. I think a nameserver for a domain is
more likely to be locked down for relays to that domain. I think
nameservers for a domain would be less likely to relay than random
other machines on the network. But obviously at least one spammer is
testing this theory.
Spammers are already working at very, very low probabilities and so
poking at another low one isn't a problem. So for the spammer it
makes sense to try wild ideas even if the likelihood is extremely
small of it being fruitful.
> I'll let it go now. 8^) Even though there's no actual problem, it's
> still a low grade irritant to me that someone out there is stupid
> enough to bang their head against this wall.
I think it is good that you brought this up and allowed people to
notice this behavior. Perhaps it will be useful to use in relation to
generating block lists. Who knows? It is interesting. I don't think
it is particularly unexpected. In this particular case though they
are way behind the power curve. They are working behind the years of
learning and selection that running any type of open mail relay is
unacceptable.
As far as spammers being stupid, I disagree. I think they show
definite intelligence. The first time I observed a distributed
spamming engine in operation I was definitely impressed.
Unfortunately it is an evil intelligence. It works not for the public
good but against it. Being annoying along the way is just one of the
lessor ways that they show that they care nothing about others.
Bob
[1] http://www.wired.com/politics/security/commentary/securitymatters/2008/03/securitymatters_0320
Re: [OT] Odd spammer tactic?
Posted by Christopher Bort <to...@thehundredacre.net>.
On 07/21/08 14:09, bob@proulx.com (Bob Proulx) wrote:
>Christopher Bort wrote:
>>In all of the relay attempts I'm seeing on this mail server, the
>>recipient addresses are in domains for which the server is an NS.
>
>They are looking for any connection possible. A nameserver is an
>association. They will hope that perhaps it allows mail. Unlikely to
>the extreme but not inconceivable.
>
>>I think, that they do care that it's an NS. It seems like they're
>>looking for hosts that will deliver|relay messages for specific
>>domains, so why don't they just use the existing MX rather than
>>trying an NS host with which there's no reasonable expectation that
>>it will relay for the target domain?
>
>You are trying to apply logic to a situation to which no reason can be
>applied. Spammers do not operate with a sanity of reason and logic.
>There is intelligence. But bludgeoning others for their own gain only
>makes sense to them and not to members of society.
True enough. I suppose it's a good thing that I'm not entirely
able to think like a spammer. ;-)
>>I suppose they could be looking for back doors, but that seems like
>>it would be a very low probability undertaking.
>
>Spammers base their existence upon extremely low probabilities
>multiplied by very large numbers of messages.
True again. Your comments essentially reflect my own assessment,
but I was curious enough about it to bring it up on a list like
this one to see if I was missing some twist that would make an
iota of sense, but I guess not. I'll let it go now. 8^) Even
though there's no actual problem, it's still a low grade
irritant to me that someone out there is stupid enough to bang
their head against this wall.
--
Christopher Bort
<to...@thehundredacre.net>
<http://www.thehundredacre.net/>
Re: [OT] Odd spammer tactic?
Posted by Bob Proulx <bo...@proulx.com>.
Christopher Bort wrote:
> In all of the relay attempts I'm seeing on this mail server, the
> recipient addresses are in domains for which the server is an NS.
They are looking for any connection possible. A nameserver is an
association. They will hope that perhaps it allows mail. Unlikely to
the extreme but not inconceivable.
> I think, that they do care that it's an NS. It seems like they're
> looking for hosts that will deliver|relay messages for specific
> domains, so why don't they just use the existing MX rather than
> trying an NS host with which there's no reasonable expectation that
> it will relay for the target domain?
You are trying to apply logic to a situation to which no reason can be
applied. Spammers do not operate with a sanity of reason and logic.
There is intelligence. But bludgeoning others for their own gain only
makes sense to them and not to members of society.
> I suppose they could be looking for back doors, but that seems like
> it would be a very low probability undertaking.
Spammers base their existence upon extremely low probabilities
multiplied by very large numbers of messages.
Bob
Re: [OT] Odd spammer tactic?
Posted by John Hardin <jh...@impsec.org>.
On Mon, 2008-07-21 at 14:01 -0700, Christopher Bort wrote:
> I suppose they could
> be looking for back doors, but that seems like it would be a
> very low probability undertaking.
Other people's CPU cycles and net bandwidth are cheap (at least for
spammers). If they hit one in fifty thousand as an open relay, it's a
net win for them.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
If Microsoft made hammers, everyone would whine about how poorly
screws were designed and about how they are hard to hammer in, and
wonder why it takes so long to paint a wall using the hammer.
-----------------------------------------------------------------------
Today: the 39th anniversary of Man's first steps on the Moon
Re: [OT] Odd spammer tactic?
Posted by Christopher Bort <to...@thehundredacre.net>.
On 07/21/08 13:04, mouss@netoyen.net (mouss) wrote:
>Christopher Bort wrote:
>>
>>For a while now, I've been seeing attempts to send mail to the
>>home server for addresses in $DAYJOB domains. This is not a
>>problem since the volume is low and they are being properly
>>rejected as third-party relay attempts (authentication
>>required - relay not permitted). However, the fact that
>>someone is apparently trying to send mail to an NS instead of
>>an existing MX has piqued my curiosity. It looks like it's all
>>spam (the sender addresses tend to support that). So, has
>>anyone else seen this sort of behavior and what could be the
>>rationale for trying to deliver mail to an NS like this?
>
>it's the same as port scans. they look for open relays. they don't
>care if the host is an MX, an NS, a www or anything. they just connect
>to the IP and try to relay. I've seen this on hosts that "nobody
>should have known about".
But they don't seem to be randomly looking for any open relay.
If they were just looking for open relays, wouldn't you expect
to see domains in the recipient addresses that have no
connection whatsoever with the target machine? In all of the
relay attempts I'm seeing on this mail server, the recipient
addresses are in domains for which the server is an NS. I don't
see any relay attempts where that is not true which implies, I
think, that they do care that it's an NS. It seems like they're
looking for hosts that will deliver|relay messages for specific
domains, so why don't they just use the existing MX rather than
trying an NS host with which there's no reasonable expectation
that it will relay for the target domain? I suppose they could
be looking for back doors, but that seems like it would be a
very low probability undertaking.
>On the other hand, I also see attempts to connect to A hosts (thus
>ignoring MX definitions) and to old MXes. This is different as there
>is no relay attempt.
The RFCs allow for A hosts to be tried in the absence of MX
records, so there is some rationale for that, however weak it
may be.
--
Christopher Bort
<to...@thehundredacre.net>
<http://www.thehundredacre.net/>
Re: [OT] Odd spammer tactic?
Posted by mouss <mo...@netoyen.net>.
Christopher Bort wrote:
> This is really not a SpamAssassin issue, but since this list is
> populated by people who are interested in spammer behavior, I'm throwing
> it out for comment. If it's too far off topic, my apologies and I'll let
> it go at that.
>
> At $DAYJOB I run a mail server and a name server for several domains,
> both our own and for clients. At home, I run a mail server and a name
> server for a couple of personal domains. The home name server is a slave
> for most of the domains hosted at $DAYJOB. The home mail server is _not_
> configured to handle mail for any of the $DAYJOB domains and it is _not_
> an MX for any of those domains. The only connection is that it is an NS
> for the $DAYJOB domains. These domains _do_ have $DAYJOB mail server as
> their MX.
>
> For a while now, I've been seeing attempts to send mail to the home
> server for addresses in $DAYJOB domains. This is not a problem since the
> volume is low and they are being properly rejected as third-party relay
> attempts (authentication required - relay not permitted). However, the
> fact that someone is apparently trying to send mail to an NS instead of
> an existing MX has piqued my curiosity. It looks like it's all spam (the
> sender addresses tend to support that). So, has anyone else seen this
> sort of behavior and what could be the rationale for trying to deliver
> mail to an NS like this?
>
it's the same as port scans. they look for open relays. they don't care
if the host is an MX, an NS, a www or anything. they just connect to the
IP and try to relay. I've seen this on hosts that "nobody should have
known about".
On the other hand, I also see attempts to connect to A hosts (thus
ignoring MX definitions) and to old MXes. This is different as there is
no relay attempt.