How to stop address harvesting?
Brett Mueller
Hash: SHA1
I've been seeing a new twist [at least to me] on dictionary email
address harvesting directed at one of my servers over the past few days.
~ The remote client uses a fqdn EHLO (that changes each session), so
reject_unauth_pipelining has no effect. The sender address also changes
each session, but comes from a resolvable domain. It then proceeds to
run through a batch of around 20 [mostly] dictionary names on the local
system, *but never sends any data,* even when hitting on a legitimate
address. Obviously the remote client is simply collecting data for
future spam use.
One thing I've learned by reading back through the archives is that I
should take advantage of the smtpd_hard_error_limit and
smtpd_error_sleep_time parameters. Also, if I was using
reject_unknown_client, this particular host would be refused, but
there's plenty of legitimate mail that would fall by the wayside as
well. Short of making more complex (and therefore less guessable) mail
accounts, does anyone have any further thoughts on how to automatically
detect and stop this?
A sample session follows at the end...
Thanks to all of the contributors who make this list a treasure chest of
information!
- --
~ Give a man a match, and he'll be warm for a minute;
~ but set him on fire, and he'll be warm for the rest of his life.
Brett E. Mueller (WA7V) <>< System Administrator / Network Analyst
Umatilla County Emergency Management http://www.csepp.net
4700 NW Pioneer Place 541-966-3707
Pendleton, OR 97801 FAX: 541-966-3760
Postfix SMTP server: errors from unknown[66.28.240.70]
Transcript of session follows.
Out: 220 wally.csepp.net ESMTP Postfix
In: EHLO mail.dataforce.net
Out: 250-wally.csepp.net
Out: 250-PIPELINING
Out: 250-SIZE 5120000
Out: 250-VRFY
Out: 250-ETRN
Out: 250-XVERP
Out: 250 8BITMIME
In: MAIL From: <re...@dataforce.net>
Out: 250 Ok
In: RCPT To:<s...@csepp.net>
Out: 250 Ok
In: RCPT To:<ri...@csepp.net>
Out: 550 <ri...@csepp.net>: User unknown
In: RCPT To:<ma...@csepp.net>
Out: 550 <ma...@csepp.net>: User unknown
In: RCPT To:<la...@csepp.net>
Out: 550 <la...@csepp.net>: User unknown
In: RCPT To:<k...@csepp.net>
Out: 550 <k...@csepp.net>: User unknown
In: RCPT To:<ke...@csepp.net>
Out: 550 <ke...@csepp.net>: User unknown
In: RCPT To:<ja...@csepp.net>
Out: 550 <ja...@csepp.net>: User unknown
In: RCPT To:<r...@csepp.net>
Out: 550 <r...@csepp.net>: User unknown
In: RCPT To:<r...@csepp.net>
Out: 550 <r...@csepp.net>: User unknown
In: RCPT To:<t...@csepp.net>
Out: 250 Ok
In: RCPT To:<fr...@csepp.net>
Out: 550 <fr...@csepp.net>: User unknown
In: RCPT To:<pe...@csepp.net>
Out: 550 <pe...@csepp.net>: User unknown
In: RCPT To:<rob...@csepp.net>
Out: 550 <rob...@csepp.net>: User unknown
In: RCPT To:<gr...@csepp.net>
Out: 550 <gr...@csepp.net>: User unknown
In: RCPT To:<j...@csepp.net>
Out: 550 <j...@csepp.net>: User unknown
In: RCPT To:<7813S26512...@csepp.net>
Out: 550 <7813S26512...@csepp.net>: User unknown
In: RCPT To:<d...@csepp.net>
Out: 550 <d...@csepp.net>: User unknown
In: RCPT To:<an...@csepp.net>
Out: 550 <an...@csepp.net>: User unknown
In: RCPT To:<fr...@csepp.net>
Out: 550 <fr...@csepp.net>: User unknown
In: RCPT To:<ja...@csepp.net>
Out: 550 <ja...@csepp.net>: User unknown
In: RCPT To:<do...@csepp.net>
Out: 550 <do...@csepp.net>: User unknown
In: RSET
Out: 250 Ok
In: QUIT
Out: 221 Bye
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
iD8DBQE9tZqe7K5JOxeDDkoRAg2FAJ9W34xi6lE/68CRyDalbrGgHknXWgCgkxJU
Cj68lUfvpOBk2/LQT++OyTc=
=yuIs
-----END PGP SIGNATURE-----
-
To unsubscribe, send mail to majo...@postfix.org with content
(not subject): unsubscribe postfix-users
Len Conrad
>I've been seeing a new twist [at least to me] on dictionary email
>address harvesting directed at one of my servers over the past few days.
>~ The remote client uses a fqdn EHLO (that changes each session), so
>reject_unauth_pipelining has no effect.
erroneous conclusion
>The sender address also changes each session, but comes from a resolvable
>domain.
> It then proceeds to
>run through a batch of around 20 [mostly] dictionary names on the local
>system, *but never sends any data,* even when hitting on a legitimate
>address. Obviously the remote client is simply collecting data for
>future spam use.
What data are they collecting? that your post-RCPT TO: action didn't
reject the recipient, thereby validating the client?
>One thing I've learned by reading back through the archives is that I
>should take advantage of the smtpd_hard_error_limit
I set mine to 2, and get no complaints. It's the best tarpitting action.
> and
>smtpd_error_sleep_time parameters.
Don't waste your SMTPD's time by sleeping, rather disconnect ASAP.
> Also, if I was using
>reject_unknown_client, this particular host would be refused, but
>there's plenty of legitimate mail that would fall by the wayside as
>well.
so you can't use it.
>Short of making more complex (and therefore less guessable) mail
>accounts, does anyone have any further thoughts on how to automatically
>detect and stop this?
Tail or otherwise periodically scan the maillog file and tote up the ip's
from /smtpd.*too many errors after (HELO|RCPT|DATA)/ and add those ip's to
your mta_clients_toomany.map file.
this command gives you the MTA's:
grep -i "too many errors after" /var/log/maillog | cut -d " " -f 12 | sort
-f | uniq -ic | sort -rf | less
... as in:
5102 intermesh-nt.indiamart.com[207.228.233.9]
1471 host-62-245-144-4.customer.m-online.net[62.245.144.4]
619 coloc73-139.singnet.com.sg[165.21.73.139]
422 unknown[213.56.134.17]
220 200-207-92-4.dsl.telesp.net.br[200.207.92.4]
206 CE129087.user.veloxzone.com.br[200.164.129.87]
188 CE129025.user.veloxzone.com.br[200.164.129.25]
185 CPE-203-45-243-67.qld.bigpond.net.au[203.45.243.67]
178 umail.mtu.ru[195.34.32.101]
166 200-171-155-161.dsl.telesp.net.br[200.171.155.161]
157 200-158-202-36.dsl.telesp.net.br[200.158.202.36]
149 12-240-137-86.client.attbi.com[12.240.137.86]
147 unknown[200.47.159.21]
121 smtp17.dreamnet.ne.jp[202.217.109.105]
121 cmn1lsm2.beliefnet.com[129.33.230.90]
113 unknown[61.177.60.218]
98 smtp15.dreamnet.ne.jp[202.217.109.104]
94 smtp5.dreamnet.ne.jp[202.217.109.101]
93 dC8545A9C.dslam-10-4-2-05-2-02.cao.dsl.cantv.net[200.84.90.156]
93 200-168-1-112.dsl.telesp.net.br[200.168.1.112]
91 cmn1lsm4.beliefnet.com[129.33.230.138]
90 smtp50.dreamnet.ne.jp[202.235.81.180]
90 MG000125.user.veloxzone.com.br[200.165.0.125]
89 smtp12.dreamnet.ne.jp[202.217.109.118]
86 smtp.via.or.jp[202.217.109.150]
83 dsl-200-67-177-130.prodigy.net.mx[200.67.177.130]
81 unknown[194.183.213.174]
80 unknown[202.217.109.222]
80 smtp6.dreamnet.ne.jp[202.217.109.117]
77 200-207-83-131.dsl.telesp.net.br[200.207.83.131]
75 ip-170-149-193.xdsl-fixo.ctbcnetsuper.com.br[200.170.149.193]
Len
Cybertime Hostmaster
> address harvesting directed at one of my servers over the past few days.
> ~ The remote client uses a fqdn EHLO (that changes each session), so
> each session, but comes from a resolvable domain. It then proceeds to
> run through a batch of around 20 [mostly] dictionary names on the local
> system, *but never sends any data,* even when hitting on a legitimate
> address. Obviously the remote client is simply collecting data for
> future spam use.
>
> smtpd_error_sleep_time parameters. Also, if I was using
> reject_unknown_client, this particular host would be refused, but
> there's plenty of legitimate mail that would fall by the wayside as
> accounts, does anyone have any further thoughts on how to automatically
> detect and stop this?
The other solution I have seen is harvesting to a firewall.
You harvest the IP address(es) of this type of attack. Some log grepping
and parsing will be required.
If they are blocked at the firewall for your mail server, they can not send
any commands to Postfix.
The care that you will need to take is making sure you only get badguys.
This will be based off of error volume, and how often you parse things out.
--Eric
Thomas -Balu- Walter
> >One thing I've learned by reading back through the archives is that I
> >should take advantage of the smtpd_hard_error_limit
>
>
> > and
> >smtpd_error_sleep_time parameters.
>
> Don't waste your SMTPD's time by sleeping, rather disconnect ASAP.
Since they are trying all addresses one after another (at my servers
too, btw), it is not a bad idea to make this scanning take a lot longer.
Balu
Vivek Khera
>> >smtpd_error_sleep_time parameters.
>>
>> Don't waste your SMTPD's time by sleeping, rather disconnect ASAP.
T> Since they are trying all addresses one after another (at my servers
T> too, btw), it is not a bad idea to make this scanning take a lot longer.
Sometimes I wish the sleep time could be made exponential after some
number of errors... For a long while I had some bogon dictionary
scanning my mail server for weeks on end. All this for a domain with
about 10 valid addresses. Go figure.
Bill Campbell
>>>>>> "T" == Thomas <-Balu- Walter <list+post...@b-a-l-u.de>> writes:
>
>>> >smtpd_error_sleep_time parameters.
>>>
>>> Don't waste your SMTPD's time by sleeping, rather disconnect ASAP.
>
>T> Since they are trying all addresses one after another (at my servers
>T> too, btw), it is not a bad idea to make this scanning take a lot longer.
>
>Sometimes I wish the sleep time could be made exponential after some
>number of errors... For a long while I had some bogon dictionary
>scanning my mail server for weeks on end. All this for a domain with
>about 10 valid addresses. Go figure.
That's when I add their IPs to my border router blocks using DENY
not REJECT so they don't get host unreachable returns (might as
well make them wait for timeouts).
Bill
--
INTERNET: bi...@Celestial.COM Bill Campbell; Celestial Software LLC
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/
``Anyone who thinks Microsoft never does anything truly innovative isn't
paying attention to the part of the company that pushes the state of
its art: Microsoft's legal department.''
--Ed Foster, InfoWorld Gripe Line columnist
Michael Tokarev
>
[]
> this command gives you the MTA's:
>
> grep -i "too many errors after" /var/log/maillog | cut -d " " -f 12 |
> sort -f | uniq -ic | sort -rf | less
Note the cut command usage here: it is incorrect. It will fail at the
beginning of every month, namely, first 9 days, due to the extra space
in the syslog's date field:
Oct 6 06:49:00 hobbit....
^^ two spaces here, and one extra field for cut -d " ".
Use awk here instead, like:
grep -i "too many errors after" /var/log/maillog | awk '{print $12}' |
sort -f | uniq -ic | sort -rf | less
or, shorter:
awk '/too many errors after/ {print $12}' /var/log/maillog |
sort -f | uniq -ic | sort -rf | less
/mjt