| Author |
Dictionary Attack Help?
|
|
|
| I received this from my host today:
"The account ********.com had to be null routed today due to a very severe
dictionary attack launched against the site (an e-mail based Denial of
Service Attack).
We can attempt to enable the account again in 24 hours if you like...I do
need to let you know though that if this happens again we will have to ask
for the site to be removed."
Any thoughts on how I can prevent this?
Heidi
| |
|
| Heidi wrote:
> I received this from my host today:
>
> "The account ********.com had to be null routed today due to a very
> severe dictionary attack launched against the site (an e-mail based
> Denial of Service Attack).
>
> We can attempt to enable the account again in 24 hours if you
> like...I do need to let you know though that if this happens again we
> will have to ask for the site to be removed."
>
> Any thoughts on how I can prevent this?
>
> Heidi
You're on Beachcomber right?
They should have this prevention installed server wide.
http://www.configserver.com/free/eximdeny.html
Also make sure:
http://www.configserver.com/free/fail.html
| |
|
| G wrote:
: Heidi wrote:
:: I received this from my host today:
::
:: "The account ********.com had to be null routed today due to a very
:: severe dictionary attack launched against the site (an e-mail based
:: Denial of Service Attack).
::
:: We can attempt to enable the account again in 24 hours if you
:: like...I do need to let you know though that if this happens again we
:: will have to ask for the site to be removed."
::
:: Any thoughts on how I can prevent this?
::
:: Heidi
:
: You're on Beachcomber right?
: They should have this prevention installed server wide.
: http://www.configserver.com/free/eximdeny.html
: Also make sure:
: http://www.configserver.com/free/fail.html
Yes the site in question is on beachcomber... I thought they should have it
taken care of but I guess they don't.
I will check those links, thanks. I am also waiting for tech support chat to
be back so I can talk to someone. =)
Heidi
| |
|
| Heidi wrote:
> G wrote:
>
> Yes the site in question is on beachcomber... I thought they should
> have it taken care of but I guess they don't.
>
> I will check those links, thanks. I am also waiting for tech support
> chat to be back so I can talk to someone. =)
>
> Heidi
If you can get into your cpanel, login and make sure your default email is
set to :fail:
| |
| Heidi 2007-10-26, 10:18 pm |
| So far a few of the domains I checked have :fail: No Such User Here for the
default.
Shouldn't that have stopped a dictionary attack from doing any real harm?
The site in question should have also had that although I can't look just
now as it is offline
by the host.
Heidi
| |
| Heidi 2007-10-26, 10:18 pm |
| G wrote:
: If you can get into your cpanel, login and make sure your default
: email is set to :fail:
I can't get into that one but my other hosted domains are.
All of the other domains I host have ":fail: No Such User Here" for the
default. about 30 in all.
Should I change it to just :fail: ?
Heidi
| |
|
| Heidi wrote:
> G wrote:
>
> I can't get into that one but my other hosted domains are.
>
> All of the other domains I host have ":fail: No Such User Here" for
> the default. about 30 in all.
>
> Should I change it to just :fail: ?
>
>
> Heidi
Nah. What you have should stop most crap from coming in.
Is the domain in question set the same?
| |
|
| G wrote:
> Heidi wrote:
>
> Nah. What you have should stop most crap from coming in.
> Is the domain in question set the same?
Sorry, responded to your last ;)
| |
| Beauregard T. Shagnasty 2007-10-26, 10:18 pm |
| Heidi wrote:
> Should I change it to just :fail: ?
How about : :blackhole:
This way you don't send an email back to the victim's forged address the
spammer used, like you do with ":fail: No Such User Here"
--
-bts
-Motorcycles defy gravity; cars just suck
| |
|
| Beauregard T. Shagnasty wrote:
> Heidi wrote:
>
>
> How about : :blackhole:
>
> This way you don't send an email back to the victim's forged address
> the spammer used, like you do with ":fail: No Such User Here"
huh?
There are sound technical reasons that you should only use :fail: and not
:blackhole: on a cPanel server running exim. We have conducted quite
extensive testing to establish this configuration is best and outline the
reasons here.
In general the two different settings both discard email not destined for a
POP3 account, an alias or a catchall alias. However, ever since cPanel
included the verify = recipient code in the standard cPanel ACL section for
exim, the way email is discarded differs with the two methods quite starkly:
Using :blackhole: email is accepted and received into the server in its
entirety. It is then processed through exim and only on delivery is it
written to the null device (/dev/null) and silently ignored.
This wastes server bandwidth as the email data, or body, of the email is
accepted into the server
This wastes server resources (CPU, memory and disk I/O) as the email is
fully processed by exim before being finally written to /dev/null
Because the blackholed email is still processed through the whole of exim
before it is finally deleted, if any of the usual checks and routing that
any email goes through fails, such email can be placed in the exim mail
queue for later reprocessing. This can lead to tens of thousands of
blackholed emails accumulating in the exim mail queue which in turn can
cause a range of serious server performance and resource problems and will
affect the normal and timely delivery of email
This actually breaks the SMTP RFC's because you're not notifying the sending
SMTP server that the email is undelivered, which is a requirement
Causes emails that will never be delivered onto the exim mail queue because
checks such as sender verification are still carried out when processing
such emails and if they cannot complete they will stay on the exim mail
queue and repeatedly reprocess the email until it is finally discarded
(usually 4+ days). This can cause very large mail queues full of spam which
is repeatedly processed causing severe performance degradation
Using :fail: the email is never accepted into the server. During the initial
SMTP negotiation when the senders SMTP server connects to your SMTP server,
the sending SMTP server issues a RCPT command notifying your server which
email address the email to follow is intended for. Your server then checks
whether the recipient email actually exists on your server (a POP3 account,
an alias or a catchall alias) and if it does not, it issues an SMTP DENY
which terminates the attempt to deliver the email.
This saves bandwidth as the email data is never received into your server
This saves server resources as the email never has to be processed
This complies with the SMTP RFC's because the sending SMTP server receives
the DENY command
Your server does not send a bounce message (just the DENY command)
Your server does not send anything to the sender of the email (i.e. the
address in the From: line)
The sending SMTP server is responsible for notifying the original sender
| |
| Jerry Stuckle 2007-10-26, 10:18 pm |
| G wrote:
> Beauregard T. Shagnasty wrote:
>
> huh?
>
> There are sound technical reasons that you should only use :fail: and not
> :blackhole: on a cPanel server running exim. We have conducted quite
> extensive testing to establish this configuration is best and outline the
> reasons here.
> In general the two different settings both discard email not destined for a
> POP3 account, an alias or a catchall alias. However, ever since cPanel
> included the verify = recipient code in the standard cPanel ACL section for
> exim, the way email is discarded differs with the two methods quite starkly:
>
> Using :blackhole: email is accepted and received into the server in its
> entirety. It is then processed through exim and only on delivery is it
> written to the null device (/dev/null) and silently ignored.
> This wastes server bandwidth as the email data, or body, of the email is
> accepted into the server
> This wastes server resources (CPU, memory and disk I/O) as the email is
> fully processed by exim before being finally written to /dev/null
> Because the blackholed email is still processed through the whole of exim
> before it is finally deleted, if any of the usual checks and routing that
> any email goes through fails, such email can be placed in the exim mail
> queue for later reprocessing. This can lead to tens of thousands of
> blackholed emails accumulating in the exim mail queue which in turn can
> cause a range of serious server performance and resource problems and will
> affect the normal and timely delivery of email
> This actually breaks the SMTP RFC's because you're not notifying the sending
> SMTP server that the email is undelivered, which is a requirement
> Causes emails that will never be delivered onto the exim mail queue because
> checks such as sender verification are still carried out when processing
> such emails and if they cannot complete they will stay on the exim mail
> queue and repeatedly reprocess the email until it is finally discarded
> (usually 4+ days). This can cause very large mail queues full of spam which
> is repeatedly processed causing severe performance degradation
>
> Using :fail: the email is never accepted into the server. During the initial
> SMTP negotiation when the senders SMTP server connects to your SMTP server,
> the sending SMTP server issues a RCPT command notifying your server which
> email address the email to follow is intended for. Your server then checks
> whether the recipient email actually exists on your server (a POP3 account,
> an alias or a catchall alias) and if it does not, it issues an SMTP DENY
> which terminates the attempt to deliver the email.
> This saves bandwidth as the email data is never received into your server
> This saves server resources as the email never has to be processed
> This complies with the SMTP RFC's because the sending SMTP server receives
> the DENY command
> Your server does not send a bounce message (just the DENY command)
> Your server does not send anything to the sender of the email (i.e. the
> address in the From: line)
> The sending SMTP server is responsible for notifying the original sender
>
>
>
Horse hockey.
Those RFC's were written before spam became the problem it is today.
Spammers use those bounces to remove invalid emails from their lists.
A good ISP will blackhole the messages so the spammer has no idea if the
message got through or not.
It's time to update the RFCs.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
| |
| Jerry Stuckle 2007-10-26, 10:18 pm |
| Heidi wrote:
> So far a few of the domains I checked have :fail: No Such User Here for the
> default.
> Shouldn't that have stopped a dictionary attack from doing any real harm?
>
> The site in question should have also had that although I can't look just
> now as it is offline
> by the host.
>
> Heidi
>
>
>
The problem with :fail is the spammer knows the message wasn't
delivered. Those which aren't bounced are by default good email
addresses. That's part of the reason for a dictionary attack.
With :blackhole he has no idea whether the address is good or not.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
| |
| Beauregard T. Shagnasty 2007-10-26, 10:18 pm |
| Jerry Stuckle wrote:
> G wrote:
<snip essay>
[color=darkred]
> Horse hockey.
>
> Those RFC's were written before spam became the problem it is today.
> Spammers use those bounces to remove invalid emails from their lists.
When did spammers start removing emails from their lists? And wouldn't
the victim whose address was used in the forged FROM field get any
bounces? Spammers certainly never see them.
> A good ISP will blackhole the messages so the spammer has no idea if
> the message got through or not.
>
> It's time to update the RFCs.
So which of you is the expert?
--
-bts
-Motorcycles defy gravity; cars just suck
| |
| Jerry Stuckle 2007-10-26, 10:18 pm |
| Beauregard T. Shagnasty wrote:
> Jerry Stuckle wrote:
>
> <snip essay>
>
>
> When did spammers start removing emails from their lists? And wouldn't
> the victim whose address was used in the forged FROM field get any
> bounces? Spammers certainly never see them.
>
From what I understand, quite a few of them do. It helps keep the
number of messages they send down and can get more messages out to good
addresses before they get booted by their hosting company.
Not all spammers use compromised computers!
>
> So which of you is the expert?
>
No expert, but I read a lot of the IT newsletters. And they've talked a
lot about not bouncing bad emails for this very reason.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
| |
|
|
|
| Jerry Stuckle wrote:
> Beauregard T. Shagnasty wrote:
>
>
> From what I understand, quite a few of them do.
You might feel differently about this if you had an inbox full of
bounces from forged headers. I've got a filter for the occaisional deluge.
Most of those go somewhere. And probably most of the unfortunate
recipients are ill prepared.
Frankly I wish ISPs would do something about their mail policies. From
all the bandwidth it eats you'd think they'd have an incentive.
Jeff
It helps keep the
> number of messages they send down and can get more messages out to good
> addresses before they get booted by their hosting company.
>
> Not all spammers use compromised computers!
>
>
> No expert, but I read a lot of the IT newsletters. And they've talked a
> lot about not bouncing bad emails for this very reason.
>
| |
| Jerry Stuckle 2007-10-26, 10:18 pm |
| Jeff wrote:
> Jerry Stuckle wrote:
>
> You might feel differently about this if you had an inbox full of
> bounces from forged headers. I've got a filter for the occaisional deluge.
>
Why would I? I don't bounce bad addresses. They go in the bit bucket
(or actually the "packet bucket") :-)
> Most of those go somewhere. And probably most of the unfortunate
> recipients are ill prepared.
>
> Frankly I wish ISPs would do something about their mail policies. From
> all the bandwidth it eats you'd think they'd have an incentive.
>
> Jeff
>
>
> It helps keep the
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
| |
|
| On 2007-10-27, Beauregard T. Shagnasty <a.nony.mous@example.invalid> wrote:
[...]
> When did spammers start removing emails from their lists?
There is/was an anti-spam approach that consisted of refusing (whether
it was a DENY or a bounce I don't know) _all_ emails the first time
around. Apparently the spambots don't bother to resend, but proper
email servers do. Once it has been resent then you whitelist it.
Something like that anyway.
Spammers probably do try to refine their lists, after all they've got
finite resources too.
| |
| Red E. Kilowatt 2007-10-27, 6:22 pm |
| Steve Sobol <sjsobol@JustThe.net> wrote in message:
slrnfi54c1.gri.sjsobol@amethyst.justthe.net,
> On 2007-10-26, Heidi <blackcat2@XXXXXXXXXX> wrote:
>
>
> That's something the host needs to take care of instead of threatening
> its customers. Buncha losers, if you ask me. :P
I agree. That's a terrible policy. It's punishes the victim without even
giving any instructions for what to do.
--
Red
| |
| Mark Goodge 2007-10-27, 6:22 pm |
| On Sat, 27 Oct 2007 11:37:07 -0500, Ben C put finger to keyboard and
typed:
>On 2007-10-27, Beauregard T. Shagnasty <a.nony.mous@example.invalid> wrote:
>[...]
>
>There is/was an anti-spam approach that consisted of refusing (whether
>it was a DENY or a bounce I don't know) _all_ emails the first time
>around. Apparently the spambots don't bother to resend, but proper
>email servers do. Once it has been resent then you whitelist it.
>Something like that anyway.
It's called greylisting. The way it works is that the first attempt is
neither accepted nor denied; instead, the receiving server returns a
"temporarily unavailable" response (exactly the same as it would do if
it was suffering some kind of fault or inability to accept mail, such
as a full disk). A correctly configured sender system will simply
store the mail it's trying to send and retry a bit later - typically,
it will wait an hour before a second attempt. On the second attempt,
the receiving system will recognise that it's a second attempt to send
the same mail and accept it this time round.
As a method of reducing spam it's very effective, because most spam
systems don't bother storing and resending mail if it doesn't get
through the first time. That's because the economics of sending spam
rely on sending very large quantities of email messages as quickly and
cheaply as possible without really caring what happens to them after
they're sent; if the spam senders had to use systems that can handle
transient errors then the costs of sending spam would rise
considerably. The downside of greylisting, though, is that it will not
only reduce spam but it also means you won't get mail from any
"normal" sending system that happens to not be correctly configured to
handle recipients with temporary errors. And there are, unfortunately,
quite a lot of those - even some large ISPs often can't configure
their mail systems correctly.
Mark
--
Blog: http://Mark.Goodge.co.uk Photos: http://www.goodge.co.uk
"Love is a precious thing, worth the pain and suffering"
| |
| (PeteCresswell) 2007-10-27, 10:16 pm |
| Per Jeff:
>Frankly I wish ISPs would do something about their mail policies. From
>all the bandwidth it eats you'd think they'd have an incentive.
Earthlink seems to have adopted a challenge-response system.
All the people who seem to know say it's a very bad idea, but,
unencumbered by any technical knowledge, I've got to wonder: if
everybody did it, wouldn't spamming become a thing of the past,
since the payoff would drop to zero?
--
PeteCresswell
| |
| Scott Bryce 2007-10-27, 10:16 pm |
| (PeteCresswell) wrote:
> Earthlink seems to have adopted a challenge-response system.
>
> All the people who seem to know say it's a very bad idea, but,
> unencumbered by any technical knowledge, I've got to wonder: if
> everybody did it, wouldn't spamming become a thing of the past,
> since the payoff would drop to zero?
Spamming may stop, but there would be other problems.
I have an automated script that sends out about 20 emails each night.
These emails are informing subscribers to my site that their
subscriptions are about to expire.
When I get emails from Earthlink asking me to identify myself as the
sender of the emails, I don't know if the email in question is one of
the emails sent out by my script, or a spam email with my return address
spoofed in the headers.
I suppose if there was no spam, I would know that the emails were legit
(or some spammer is counting on me coming to that conclusion) but I
would still have to go the Earthlink's site and type in that string of
illegible letters and numbers.
| |
| Jerry Stuckle 2007-10-27, 10:16 pm |
| (PeteCresswell) wrote:
> Per Jeff:
>
> Earthlink seems to have adopted a challenge-response system.
>
> All the people who seem to know say it's a very bad idea, but,
> unencumbered by any technical knowledge, I've got to wonder: if
> everybody did it, wouldn't spamming become a thing of the past,
> since the payoff would drop to zero?
As soon as enough ISP's institute such a system, someone will break it.
From what I understand, the images in some of the CAPTCHA systems have
already been broken.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
| |
|
| Scott Bryce wrote:
> (PeteCresswell) wrote:
>
>
>
> Spamming may stop, but there would be other problems.
>
> I have an automated script that sends out about 20 emails each night.
> These emails are informing subscribers to my site that their
> subscriptions are about to expire.
>
> When I get emails from Earthlink asking me to identify myself as the
> sender of the emails, I don't know if the email in question is one of
> the emails sent out by my script, or a spam email with my return address
> spoofed in the headers.
Lovely.
Earthlink has consistently made SPAM someone else's problem. At first
they ignored it then they institute changes that cause others grief.
I suppose Eartlink doesn't bother to check if you have a SPF.
As long as there is no system to check for forged headers (and
retribution for those caught forging) SPAM will never be controlled.
I don't trust anything Earthlink does... (my ISP BTW, but not my POP).
Jeff
>
> I suppose if there was no spam, I would know that the emails were legit
> (or some spammer is counting on me coming to that conclusion) but I
> would still have to go the Earthlink's site and type in that string of
> illegible letters and numbers.
| |
| (PeteCresswell) 2007-10-28, 7:19 pm |
| Per Jeff:
>
> As long as there is no system to check for forged headers (and
What about some scheme for authenticating sender's addresses?
My understating is that it's not possible under Internet 1.0
today - but might authenticated addresses be some kind of option
under the next version of the IP protocol?
--
PeteCresswell
| |
| Jerry Stuckle 2007-10-28, 7:19 pm |
| (PeteCresswell) wrote:
> Per Jeff:
>
> What about some scheme for authenticating sender's addresses?
>
> My understating is that it's not possible under Internet 1.0
> today - but might authenticated addresses be some kind of option
> under the next version of the IP protocol?
That would be great, and it's been proposed in the past. But the
problem is getting everyone to move to the new protocol.
It's hard enough getting people to move to ipv6!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
|
|
|
|
| Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |