Hi, Martin.
What is an "echo mail reflector?" Is this something I could provide?
It basically allow you to "bounce" mail off of the address and
returns a copy of your mail replete with headers. Useful for
testing mail configuration, latency, etc.
Someone just pinged me and said that echo@psi.net<- is still
operational.
We built systems like this for AOL (to monitor the latency of the Internet mail gateway system), but we didn't bother using "echo" accounts at other providers. We simply set up accounts at other sites and had them set up to forward everything they got back to a central monitoring account.
For those systems we wanted to test against but where we couldn't set up our own account, we'd just send a message to an obviously non-existant address, and make sure that the envelope sender address was set correctly to direct the bounces to that same central account.
Indeed, I had not considered the usefulness of setting up "echo" accounts. Seems to me that they could be easily abused.
What kinds of anti-abuse protection methods have people used for "echo" accounts that they have set up?
Brad Knowles(brad.knowles@skynet.be)@2002.08.16 19:48:10 +0000:
What kinds of anti-abuse protection methods have people used for
"echo" accounts that they have set up?
- scoreboard: one mail from one source addres in one minute time window
- gnupg: mail needs to be signed to fire a return mail. key of the
signer must belong to the robot's gpg trust web.
regards,
/k
Brad Knowles(brad.knowles@skynet.be)@2002.08.16 19:48:10 +0000:
What kinds of anti-abuse protection methods have people used for
"echo" accounts that they have set up?- scoreboard: one mail from one source addres in one minute time window
Yeah, but then abusers could easily generate elephantine quantities of messages, simply by randomly generating return addresses (if they wanted to DoS you or your network), or by randomly generating the user portion of return addresses (if they wanted to abuse you to DoS someone else). If they know that there are multiple domains handled by the same servers, they could randomly generate addresses within that set of domains.
- gnupg: mail needs to be signed to fire a return mail. key of the
signer must belong to the robot's gpg trust web.
Ooh, so in order to use the echo server, they have to send a PGP signed message? Wow, that's pretty expensive. That sounds like a really excellent way to DoS your server.
Thanks for sharing!
I'm not sure why this is such a worry since a lot of these
responders have been working for over a decade, and they've
all been just fine operating the way they are.
-M
Most security holes are not anything to worry about -- until someone takes advantage of them.
Do you just queue messages from source addresses, so that you don't generate more than one echo in a minute, or do you throw away every message from that source address which was generated less than one minute ago?
Also, how do you handle echoes of echoes? For example, if I forged e-mail as being from echo@psi.net and addressed that to echo@rohrbach.de (or whatever), would this generate an endless loop?
What if I put "echo@psi.net,echo@psi.net" as the return address? Would you send back two copies?
Just curious. Thanks!
Brad Knowles(brad.knowles@skynet.be)@2002.08.16 22:27:08 +0000:
> Brad Knowles(brad.knowles@skynet.be)@2002.08.16 19:48:10 +0000:
>> What kinds of anti-abuse protection methods have people used for
>> "echo" accounts that they have set up?
>
> - scoreboard: one mail from one source addres in one minute time windowYeah, but then abusers could easily generate elephantine
quantities of messages, simply by randomly generating return
addresses (if they wanted to DoS you or your network), or by randomly
generating the user portion of return addresses (if they wanted to
abuse you to DoS someone else). If they know that there are multiple
domains handled by the same servers, they could randomly generate
addresses within that set of domains.
...ip source address that is, thought it was obvious. a very logical
algorithm would be ``n source ip adresses per /16 per minute'' which
would catch at least the badly distributed DDoS attacks and does not
impose large processing overhead in cycles and memory, i think.
i don't think that an echo service would be this popular that it
needs to process very many messages for the same /16 in a short period
of time.
> - gnupg: mail needs to be signed to fire a return mail. key of the
> signer must belong to the robot's gpg trust web.Ooh, so in order to use the echo server, they have to send a PGP
signed message? Wow, that's pretty expensive. That sounds like a
really excellent way to DoS your server.
it was just a quick idea. but queueing and (rapidly) scheduled weedouts
of those queues are nothing new, when you guard services with gpg/pgp.
other soft capacity limitings can be done if the rate limiting
described above lets through too much, such as deleting queue entries by
random when hitting an excessive queue length. when measuring of link
latency is done with it, the gpg approach might impose problems, since
you need to rely on the outgoing mail timestamp of the echo relay
because of variable queue length and gpg processing time.
Thanks for sharing!
you're welcome.
/k
Brad Knowles(brad.knowles@skynet.be)@2002.08.16 23:46:51 +0000:
> - scoreboard: one mail from one source addres in one minute time window
Do you just queue messages from source addresses, so that you
don't generate more than one echo in a minute, or do you throw away
every message from that source address which was generated less than
one minute ago?
please, see the other answer in this thread.
Also, how do you handle echoes of echoes? For example, if I
forged e-mail as being from echo@psi.net and addressed that to
echo@rohrbach.de (or whatever), would this generate an endless loop?
X-Loop:
What if I put "echo@psi.net,echo@psi.net" as the return address?
Would you send back two copies?
No.
Just curious. Thanks!
regards,
/k
I have some fairly popular echoes at gurus.com, the most popular of
which is internet@gurus.com (an address that never appeared anywhere,
oddly enough, although versions like internet8@gurus.com appear in
my books.)
It remembers each message it sends, and won't send more than five
messages per hour to any target mailbox. Messages above that are
dropped, not delayed.
I don't ever recall a deliberate mailbomb, but I do get spam blasts
that would reverse mailbomb the forged From: address in the spam, and
the occasional loop. The rate limit has sufficed to keep things under
control.
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
"Just how much hay did we buy?" asked Tom, balefully.
...ip source address that is, thought it was obvious.
You mean, the IP address of the machine contacting you, or the IP address of the originating machine? If the former, keep in mind that many providers host a large number of customers, and you could deny service to a lot of innocent people. If the latter, then you would be vulnerable to forging.
a very logical
algorithm would be ``n source ip adresses per /16 per minute'' which
would catch at least the badly distributed DDoS attacks and does not
impose large processing overhead in cycles and memory, i think.
Assuming you're talking about the transmitting relay (which would be difficult to fake), this would be some additional protection.
i don't think that an echo service would be this popular that it
needs to process very many messages for the same /16 in a short period
of time.
Unless someone is trying to DoS your machine. Heck, they could just generate zillions of SYN packets with random source IP addresses, and that could cause you some significant problems.
it was just a quick idea. but queueing and (rapidly) scheduled weedouts
of those queues are nothing new, when you guard services with gpg/pgp.
Cron job every minute? Would you use a program to pull down the mailbox with POP3 or IMAP or somesuch, or would you directly access & process the mailbox? Or maybe pre-filter the messages with procmail into seperate mailbox files which could then be further processed by your script?
What do you do if they decide to start sending you a large number of really huge messages? They could potentially fill up your mailbox space on the disk, even in just a single minute.
other soft capacity limitings can be done if the rate limiting
described above lets through too much, such as deleting queue entries by
random when hitting an excessive queue length. when measuring of link
latency is done with it, the gpg approach might impose problems, since
you need to rely on the outgoing mail timestamp of the echo relay
because of variable queue length and gpg processing time.
Yeah, lots of interesting things to think about.
Thanks for an interesting discussion! This is turning out to be very educational.
Hmm. If they send back the entire message as a forward (which would be reasonable), do you scan for this header in the body (i.e., in the forwarded part), or just in the headers of the message that you are receiving?
Thanks again!
a very logical
algorithm would be ``n source ip adresses per /16 per minute'' which
would catch at least the badly distributed DDoS attacks and does not
impose large processing overhead in cycles and memory, i think.Assuming you're talking about the transmitting relay (which would
be difficult to fake), this would be some additional protection.
Of course, it now occurs to me that there are plenty of providers which may not own the entire /16 that they are in, and therefore they could also get hurt by abuse being generated by near-by networks. Unfortunately, I'm not sure that there's too much you can do about this, because the consequences could be extremely severe.
Unless someone is trying to DoS your machine. Heck, they could
just generate zillions of SYN packets with random source IP
addresses, and that could cause you some significant problems.
OTOH, this doesn't really have anything particular to do with the service you'd be providing, and would not be any additional risk that you would not already be experiencing.
Brad Knowles(brad.knowles@skynet.be)@2002.08.17 23:36:49 +0000:
> ...ip source address that is, thought it was obvious.
You mean, the IP address of the machine contacting you, or the IP
address of the originating machine? If the former, keep in mind that
many providers host a large number of customers, and you could deny
service to a lot of innocent people. If the latter, then you would
be vulnerable to forging.
every machine connecting to an smtp port is a potential transmitting
relay...
> a very logical
> algorithm would be ``n source ip adresses per /16 per minute'' which
> would catch at least the badly distributed DDoS attacks and does not
> impose large processing overhead in cycles and memory, i think.Assuming you're talking about the transmitting relay (which would
be difficult to fake), this would be some additional protection.
thinking twice about the pseudo algo up there, it would be rotten easy
to DoS the systems for connections from ``well-known'' systems which
might depend on the service (latency measurement, again). one would need
to have a white list for those ip adresses.
> i don't think that an echo service would be this popular that it
> needs to process very many messages for the same /16 in a short period
> of time.Unless someone is trying to DoS your machine. Heck, they could
just generate zillions of SYN packets with random source IP
addresses, and that could cause you some significant problems.
syn-cookies, where's the problem?
> it was just a quick idea. but queueing and (rapidly) scheduled weedouts
> of those queues are nothing new, when you guard services with gpg/pgp.Cron job every minute? Would you use a program to pull down the
mailbox with POP3 or IMAP or somesuch, or would you directly access &
process the mailbox? Or maybe pre-filter the messages with procmail
into seperate mailbox files which could then be further processed by
your script?
hmmm, cron job is simple, but intermediate storage of the incoming
mails might pose problems, you're prefectly right...
What do you do if they decide to start sending you a large number
of really huge messages? They could potentially fill up your mailbox
space on the disk, even in just a single minute.
deliver to a filter that limits max. size of messages by lines?
then stuff its output in a fifo with a daemon listening on the other
side:
head -n200 >/var/whereever_not_tmp/echofifo
implement the fifo listener as a small daemon that select()s on the fifo
and processes the mails.
regards,
/k
I've been thinking about this a bit more. I think the best way to implement protection mechanisms for something like this is using a "milter" plug-in for sendmail. It would get called after the message has been transmitted by the sending relay, but before your mail server returns "250 Okay".
This milter would do whatever you programmed it to do, but would be able to check databases, compare times of previous messages from the same IP address or network, etc.... Once a message passes all the checks, the milter plug-in would return a code that tells the sendmail program to accept the message, where the actual work is performed by another program.
The advantage of milter is that it is inherently multi-threaded, asynchronous, and capable of using an arbitrary number of off-system back-end milter servers.