Stan Hoeppner wrote:
Jose-Marcio Martins da Cruz put forth on 12/2/2010 2:40 AM:
Victor Duchovni wrote:
On Wed, Dec 01, 2010 at 11:43:30PM -0600, Stan Hoeppner wrote:
The lookup is always a cache miss. Then an SMTP probe is sent. Dictionary
attacks always yield cache misses.
You are forgetting that dictionary attacks are almost exclusively queries
for non-existent users. Think clearly, and think outside the box about
worst-case behaviour.
Because I am not thinking about normal loads that don't matter. One
needs to survive hostile loads.
Just to illustrate with numbers, what Viktor says, a daily activity on
one of our servers (not a big one) : from all connections reaching a
"RCPT To" step, 18313 are to real users and 76623 to non existing users.
Well, this is a daily normal activity, not even a hostile load. Clearly,
most checks are cache misses.
Whether 'most' would be cache misses would depend on how you have your
verify(8) database cache configured (it does cache negative results),
and the nature of those 76623 connections. Search those 76623 and see
how many are duplicates. It's probably alot more than you'd think,
because spammers have been spamming to scraped message IDs for years.
I'm not using verify. I'm just telling the number of RCPT commands (18xxx + 76xxx), and how many of
them resulted in user unknown (76xxx) and user OK (18xxx). Should add those relaying denied and
other rejections.
On the other hand, real numbers should be much higher than I said as any SMTP commands are rejected
if the client do more than some number of RCPT errors. This is done by a milter and the potentially
real numbers aren't counted in the above.
So, to continue, I took longer times : 10 days, individually and 10 days all together. What is
constant is that from the list of unknown users, there are something like 1/4 are different
recipients, each day. But when I have the whole 10 days together, if falls just from ~25% to ~15%.
That means that the set of unique unknown recipients changes each day.
But indeed, and I insist to say, this is a normal situation. A hostile situation should be when
someone intentionnaly floods you with 10 times more than the usual "unknown users" rate, using
different recipients. You shall protect against this, not against normal situations. Still, my
numbers correspond to a small server.
As a comparable "side effect", in greylisting filters, you can think about the database of of
triplets waiting to be validated as some sort of cache. Well, some of these filters don't do
recipient check before adding pending entries in the database. A simple way to attack these filters
is to fill up their databases with a lot (a million or more) of entries which will never be
validated. Growing this "cache" without limits may not be a problem for small idle servers, but
indeed is for huge servers.
I'll have to do some checking, but I'm pretty sure that at $mydomain
about 80% of all spam addressed to non existent users is addressed to
scraped message IDs or butchered variants of them. This happens when
Please, check. Speculate is good to begin thinking about something, but better is to verify if the
first idea is good or not.
spammers pass/sell their lists amongst one another and don't take any
care when exporting/copying the address data. In the case of message ID
spam, the verify(8) cache would work well. Of note, I've never seen an
actual 'dictionary' attack on any of my MX machines. Note I didn't say
they don't occur, only that I've yet to see one. I have seen dictionary
attacks against FTP and SSH ports, but not SMTP. Given how fruitless
they are, I would suspect even dumb spammers probably avoid dictionary
spamming today.
I see every day. I can't tell that one kind of pattern is more frequent than others (cluttered
variants of existing addresses, common first names, random user parts, ...). I guess it's almost the
same. I see all of them.
