Re: Barracuda Networks Spam Firewall
"Jared B. Reimer" <jared@theriver.com> 5/17/04 2:48:16 PM >>> We have done an eval of this same product (model 400). It is very cool in virtually every regard except one: performance. We were facing 1+ hour mail delays (!) through the device when pumping less than 1,000,000 messages per day through it. Given that they claim it can handle ten
times that much, I am left wondering what happened. Very disappointing in that regard; the eval unit is being shipped back as a result. -- Jared
Did you not receive some basic support from them during your evaluation? A perceived 90% drop in performance is pretty significant and I'd imagine that they'd be interested in helping to determine the cause. John --
Did you not receive some basic support from them during your evaluation? A perceived 90% drop in performance is pretty significant and I'd imagine that they'd be interested in helping to determine the cause.
Sadly, they have not responded to my email on the topic, sent four days ago. However, someone unrelated to the company emailed me off-list saying that basically this is a known flaw in the product with back-end systems like qmail that asynchronously bounce mail for invalid recipients. See below quote:
We had this problem when our inbound-smtp server ( the server the barracuda is dumping mail to) was accepting all RCPT TOs: As a result dictionary attacks were getting through and creating 'unique recipients' on the Barracuda. As soon as I fixed my mail server to reject with a 220 error on bogus RCPT TOs the problem cleared up.
This is a pretty serious flaw IMHO, if it is (in fact) true. qmail isn't the only mailer that behaves this way. It looks like they may have tried to kludge their way around this with LDAP in the case of MS Exchange, which also does asynchronous bouncing of undeliverable mail IIRC. -- Jared
On Mon, 17 May 2004, Jared B. Reimer wrote:
We had this problem when our inbound-smtp server ( the server the barracuda is dumping mail to) was accepting all RCPT TOs: As a result dictionary attacks were getting through and creating 'unique recipients' on the Barracuda. As soon as I fixed my mail server to reject with a 220 error on bogus RCPT TOs the problem cleared up.
This is a pretty serious flaw IMHO, if it is (in fact) true. qmail isn't the only mailer that behaves this way. It looks like they may have tried to kludge their way around this with LDAP in the case of MS Exchange, which also does asynchronous bouncing of undeliverable mail IIRC.
The fault here is with qmail. The barracuda was doing exactly what it was designed to do. qmail can be patched to be smarter (google for qmail spamcontrol or magic smtpd). Accept all, then try to bounce, is a recipe for disaster with today's dictionary attackers and virii that will send to randomly created destinations from randomly created forged froms. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Mon, May 17, 2004 at 02:26:37PM -0700, Jared B. Reimer wrote:
This is a pretty serious flaw IMHO, if it is (in fact) true. qmail isn't the only mailer that behaves this way. It looks like they may have tried to kludge their way around this with LDAP in the case of MS Exchange, which also does asynchronous bouncing of undeliverable mail IIRC.
Quite frankly, I'm at a loss as to why anyone would wish to accept and queue mail that they cannot deliver. Queuing everything just allocates disk unnecessarily and results in a lot of delayed bounce backscatter, almost always directed at a third party (in the common case of spoofed from: headers). Accepting everything simply because you don't wish to give away valid addresses doesn't work; the spam bots just jabber more loudly at you. In the past year I've had two domains joe jobbed, generating thousands of those helpful delayed bounce messages per hour for my role accounts. If, after RCPT TO, you do not have a valid destination, just refuse it. My role accounts thank you. --msa
On Tue, 18 May 2004 10:11:20 PDT, "Majdi S. Abbas" said:
Quite frankly, I'm at a loss as to why anyone would wish to accept and queue mail that they cannot deliver. Queuing everything just allocates disk unnecessarily and results in a lot of delayed bounce backscatter, almost always directed at a third party (in the common case of spoofed from: headers).
Well.. you're somewhat right - *IF* the mail gateway is able to make the determination quickly and definitively, reacting as soon as you see the RCPT TO: is a good idea. However, that can be a big 'if' in some configurations... Traditionally, "accept and queue" was a reasonable way for a gateway mail relay to function (and if you think about it, it's usually the ONLY way for an off-site secondary MX to function). You'd accept and queue everything, and then forward it to an internal machine that actually knew what mailboxes were valid addresses. If you don't do that, then you have to make your authentication system visible to machines on your DMZ, which has it's own touchy implications.... For high-volume sites, there are also firewall state issues - if you're getting 100K messages/hour, and each one has to be open for 5 seconds because of authentication issues on the RCPT TO:, you'll average 138 open connections. If you accept, queue, and deal with it later, you can get it down to 1 second and then you only average 27 open connections (numbers for illustration purposes only).
On Tue, 18 May 2004 Valdis.Kletnieks@vt.edu wrote:
and then forward it to an internal machine that actually knew what mailboxes were valid addresses. If you don't do that, then you have to make your authentication system visible to machines on your DMZ, which has it's own touchy implications....
Or push a list of valid addresses to the secondaries that they keep locally and use, update as needed. You don't need to 'authenticate' -- just know what is/isn't valid. For a few hundred, or a few thousand accounts rsync/ssh/make could do the job. If you're AOL, I'm sure there is a solution too. ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
On Tue, 18 May 2004 14:52:54 EDT, "Christopher X. Candreva" <chris@westnet.com> said:
Or push a list of valid addresses to the secondaries that they keep locally and use, update as needed. You don't need to 'authenticate' -- just know what is/isn't valid.
Remember to ask the auditors what they think of having such a list on a box in the DMZ. ;)
On Tue, 18 May 2004 Valdis.Kletnieks@vt.edu wrote: : > Quite frankly, I'm at a loss as to why anyone would wish to accept : > and queue mail that they cannot deliver. : Well.. you're somewhat right - *IF* the mail gateway is able to make the : determination quickly and definitively, That "if" is rapidly becoming a *requirement*. I invite you to participate in SPAM-L@PEACH.EASE.LSOFT.COM is you somehow feel differently. : Traditionally, "accept and queue" was a reasonable way for a gateway : mail relay to function (and if you think about it, it's usually the ONLY way : for an off-site secondary MX to function). Then make the offsite MX use a user list, or else don't use an offsite MX at all. Sending mail exchangers will retry when the recipient servers are down; that's mandated by SMTP. You don't need an offsite secondary MX that has no access to a valid address list. Sorry to burst your bubble, but as of this year, where the levels of virus bounce spam as hreached obscene levels, this is no longer a valid excuse. : For high-volume sites, there are also firewall state issues Then upgrade your firewall. This is certainly not a valid excuse. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
On Mon, 17 May 2004, Jared B. Reimer wrote: : >We had this problem when our inbound-smtp server ( the server the : >barracuda is dumping mail to) was accepting all RCPT TOs : This is a pretty serious flaw IMHO, if it is (in fact) true. qmail isn't : the only mailer that behaves this way. And, regardless of what the Barracuda box did, you should fix your qmail install. This behavior is no longer considered acceptable by the 'net at large, because accept-then-bounce is the biggest cause of virus spew bounceback spam. (As a result, people have begun widely blocking MXs that accept-then-bounce. You'd do yourself quite a favor to convert to reject-at-SMTP now, before you get blocked too.) -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
on Tue, May 18, 2004 at 04:01:40PM -0400, Todd Vierling wrote:
On Mon, 17 May 2004, Jared B. Reimer wrote:
: >We had this problem when our inbound-smtp server ( the server the : >barracuda is dumping mail to) was accepting all RCPT TOs
: This is a pretty serious flaw IMHO, if it is (in fact) true. qmail isn't : the only mailer that behaves this way.
And, regardless of what the Barracuda box did, you should fix your qmail install. This behavior is no longer considered acceptable by the 'net at large, because accept-then-bounce is the biggest cause of virus spew bounceback spam.
(As a result, people have begun widely blocking MXs that accept-then-bounce. You'd do yourself quite a favor to convert to reject-at-SMTP now, before you get blocked too.)
At present, thanks to a recent massive joe job against one of the domains we host, I've got a list of ~16100 mailhosts that I no longer accept null sender mail* from. Most of them are running qmail, based on some unscientific analysis I did when compiling the list. All of them accepted, then bounced, mail from spammers HELO'ing with that domain "back" to the victim. Several hundred also sent us DSNs from virus forgeries. All of them were unnecessary. Sad, really, especially given that patches exist to fix this problem. Steve * or postmaster/Symantec_Antivirus/Webshield/VirusWall/JCT/etc. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com Buy "Cascading Style Sheets: Separating Content from Presentation, 2/e" today! http://www.amazon.com/exec/obidos/ASIN/159059231X/heskecominc-20/ref=nosim/
participants (8)
-
Christopher X. Candreva -
Jared B. Reimer -
jlewis＠lewis.org -
John Neiberger -
Majdi S. Abbas -
Steven Champeon -
Todd Vierling -
Valdis.Kletnieks＠vt.edu