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.
At 12:53 PM -0400 2002/08/16, Martin Hannigan wrote:
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.
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> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
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 --
To avoid criticism, do nothing, say nothing, be nothing. --Elbert Hubbard WebMonster Community Project -- Reliable and quick since 1998 -- All on BSD http://www.webmonster.de/ - ftp://ftp.webmonster.de/ - http://www.rohrbach.de/ GnuPG: 0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4 A113 B393 6BF4 DEC9 48A6 REVOKED: 0x2964BF46 D/E 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 REVOKED: 0x4C44DA59 RSA F9 A0 DF 91 74 07 6A 1C 5F 0B E0 6B 4D CD 8C 44 My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/ Please do not remove my address from To: and Cc: fields in mailing lists. 10x
At 9:43 PM +0200 2002/08/16, Karsten W. Rohrbach wrote:
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! -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
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 On Fri, 16 Aug 2002, Brad Knowles wrote:
At 9:43 PM +0200 2002/08/16, Karsten W. Rohrbach wrote:
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!
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
At 4:33 PM -0400 2002/08/16, Martin Hannigan wrote:
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.
Most security holes are not anything to worry about -- until someone takes advantage of them. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
Brad Knowles(brad.knowles@skynet.be)@2002.08.16 22:27:08 +0000:
At 9:43 PM +0200 2002/08/16, Karsten W. Rohrbach wrote:
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.
...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 -- WebMonster Community Project -- Reliable and quick since 1998 -- All on BSD http://www.webmonster.de/ - ftp://ftp.webmonster.de/ - http://www.rohrbach.de/ GnuPG: 0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4 A113 B393 6BF4 DEC9 48A6 REVOKED: 0x2964BF46 D/E 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 REVOKED: 0x4C44DA59 RSA F9 A0 DF 91 74 07 6A 1C 5F 0B E0 6B 4D CD 8C 44 My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/ Please do not remove my address from To: and Cc: fields in mailing lists. 10x
At 3:48 AM +0200 2002/08/17, Karsten W. Rohrbach wrote:
...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. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
At 11:36 PM +0200 2002/08/17, Brad Knowles wrote:
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> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
Brad Knowles(brad.knowles@skynet.be)@2002.08.17 23:36:49 +0000:
At 3:48 AM +0200 2002/08/17, Karsten W. Rohrbach wrote:
...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 --
"Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick-les Worth). Which is to say that Europeans call him by name, but Americans call him by value." WebMonster Community Project -- Reliable and quick since 1998 -- All on BSD http://www.webmonster.de/ - ftp://ftp.webmonster.de/ - http://www.rohrbach.de/ GnuPG: 0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4 A113 B393 6BF4 DEC9 48A6 REVOKED: 0x2964BF46 D/E 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 REVOKED: 0x4C44DA59 RSA F9 A0 DF 91 74 07 6A 1C 5F 0B E0 6B 4D CD 8C 44 My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/ Please do not remove my address from To: and Cc: fields in mailing lists. 10x
At 11:36 PM +0200 2002/08/17, Brad Knowles wrote:
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.
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. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
At 9:43 PM +0200 2002/08/16, Karsten W. Rohrbach wrote:
- 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? 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> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
Brad Knowles(brad.knowles@skynet.be)@2002.08.16 23:46:51 +0000:
At 9:43 PM +0200 2002/08/16, Karsten W. Rohrbach wrote:
- 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 --
Nuclear war can ruin your whole compile. --Karl Lehenbauer WebMonster Community Project -- Reliable and quick since 1998 -- All on BSD http://www.webmonster.de/ - ftp://ftp.webmonster.de/ - http://www.rohrbach.de/ GnuPG: 0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4 A113 B393 6BF4 DEC9 48A6 REVOKED: 0x2964BF46 D/E 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 REVOKED: 0x4C44DA59 RSA F9 A0 DF 91 74 07 6A 1C 5F 0B E0 6B 4D CD 8C 44 My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/ Please do not remove my address from To: and Cc: fields in mailing lists. 10x
At 3:55 AM +0200 2002/08/17, Karsten W. Rohrbach wrote:
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:
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! -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
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.
participants (4)
-
Brad Knowles -
johnl＠iecc.com -
Karsten W. Rohrbach -
Martin Hannigan