FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 03-26-2008, 10:23 AM
Rodolfo Alcazar Portillo
 
Default HELP!!! mail attack

Hello. Since monday, our mailserver (FC5), behind a firewall, is
suffering a heavy DoS mail attack. We have a user account,
amanda.davila@padep.org.bo and it is receiving millions of emails from
very different sites of the planet. Since now, my only action was
deleting the account from /etc/password, and the traffic permits
working. We suspect a virus attack...

What else can we do? We would appreciate any help with this issue. Here,
a 20 seconds log by 07:15 GMT-4 (too early, many pcs off).

# tethereal |grep RCPT

0.030421 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
0.084245 193.195.46.98 -> 192.168.1.15 SMTP Command: RCPT To:<amanda.davila@padep.org.bo>
0.813207 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
1.196831 221.246.173.133 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
1.214975 221.246.173.133 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
1.330348 203.162.4.185 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
1.633672 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
1.999373 64.22.97.151 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
2.674852 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
2.783758 212.241.250.110 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
3.420356 71.86.28.162 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
3.785264 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
4.742188 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
5.525666 81.80.63.187 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
5.617303 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
5.854842 71.86.28.162 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
5.863718 70.103.68.218 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
5.868905 70.103.68.218 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
6.096777 59.124.4.190 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
6.436249 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
6.466815 66.249.92.172 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
7.262385 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
7.397907 71.86.28.162 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
10.592647 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
10.594863 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
10.646376 81.72.107.178 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
11.262748 212.135.207.34 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
11.383742 203.162.4.185 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
11.538739 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
11.568291 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
11.988369 203.190.60.202 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
12.501307 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
12.528634 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
12.807326 220.152.32.164 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
13.115271 212.135.207.34 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
13.453285 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
13.474763 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
14.099809 212.135.207.34 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
14.393268 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
14.429214 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
15.034781 212.135.207.34 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
15.053775 212.135.207.34 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
15.337869 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
15.378731 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
15.868339 189.32.131.187 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
16.258275 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
16.312235 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
16.633300 210.162.25.47 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
17.149183 210.147.8.9 -> 192.168.1.15 SMTP Command: RCPT To:<amanda.davila@padep.org.bo>
17.225328 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
17.237639 189.32.131.187 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
17.272639 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
17.673762 84.12.48.115 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
17.698118 84.12.48.115 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
18.182747 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
18.206657 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
18.422710 141.156.107.252 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
18.433819 141.156.107.252 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
18.588780 189.32.131.187 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
18.810259 210.162.25.47 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
19.128838 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
19.167259 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>

Here you can find a more detailed log:
http://www.padep.org.bo/log20080325/

Thanks, again...
----------------------------------------------
Rodolfo Alcazar - rodolfo.alcazar@padep.org.bo
otbits.blogspot.com / counter.li.org: #367962
----------------------------------------------
"Träume nicht dein Leben, lebe deinen Traum."
- Unbekannter Autor


--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-26-2008, 11:12 AM
Craig White
 
Default HELP!!! mail attack

On Wed, 2008-03-26 at 07:23 -0400, Rodolfo Alcazar Portillo wrote:
> Hello. Since monday, our mailserver (FC5), behind a firewall, is
> suffering a heavy DoS mail attack. We have a user account,
> amanda.davila@padep.org.bo and it is receiving millions of emails from
> very different sites of the planet. Since now, my only action was
> deleting the account from /etc/password, and the traffic permits
> working. We suspect a virus attack...
>
> What else can we do? We would appreciate any help with this issue. Here,
> a 20 seconds log by 07:15 GMT-4 (too early, many pcs off).
----
That account has likely been 'Joe Jobbed' and you are seeing the
backscatter. Google 'Joe Job' or find it on Wikipedia for an
explanation.

If you have a mail server, an account, and e-mails arriving, there's
little you can do in a specific sense but you have to evaluate your
overall mail scheme.

I will explain in a general way, how I set up my mail servers and
perhaps this may help.

I use postfix but the only difference I have found between postfix and
sendmail is that postfix is a little easier to setup/maintain.

My first 'defense' is greylisting, run as a policy in postfix.
Greylisting maintains a database (MySQL) primarily using a table of
'tuples' of sender, recipient, mailhost (smtp server trying to deliver
the mail). Greylisting sends a tempfail on the first attempt by sender,
to recipient from particular mail server. This eliminates much e-mail
sent by 'bot' systems that are just spraying e-mail around and are not
true SMTP servers and thus don't attempt 're-delivery'

My second defense is to use rbl's (abuseat / spamhaus / dsbl) to
otherwise block KNOWN blacklisted sources

My third defense is to require:
- reverse DNS of sender
- fqdn of sender
- valid hostname
- valid recipient

This all happens before I choose to accept mail.

Once I have accepted e-mail, it is shuffled to 'MailScanner' which is a
wrapper program that sends e-mail through clamav and then through
spamassassin, where it is cleaned and scored.

Finally, I have 'sieve' rules for all users which puts high spam score
e-mails into a users 'SPAMBOX' folder of which everything that is older
than 7 days is automatically cleaned out.

The notion of rejecting most e-mail before you ever accept it is really,
really important because it minimizes the very expensive computing costs
of inspection by clamav and spamassassin.

Craig

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-26-2008, 11:36 AM
Tim
 
Default HELP!!! mail attack

On Wed, 2008-03-26 at 05:12 -0700, Craig White wrote:
> My first 'defense' is greylisting, run as a policy in postfix.

Though do so with the knowledge that it may mean some mail never gets
delivered/accepted. Greylisting, for both cases of rejecting spam and
accepting ham, requires the services sending to you to work in certain
way [1], and they don't all do that [2].

1. They reject the initial attempt, tell the sender to resend later, and
accept the resend.

2. Some senders never resend, causing mail to get lost permanently.
Some resends come from a different server, and that can get rejected,
too - causing long delays, or permanently lost mail. Some resend
attempts come after a very long delay, which can be annoying or business
destroying, or can cause another reject.

I've experienced all of the above bad scenarios.

--

Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-26-2008, 12:35 PM
Craig White
 
Default HELP!!! mail attack

On Wed, 2008-03-26 at 23:06 +1030, Tim wrote:
> On Wed, 2008-03-26 at 05:12 -0700, Craig White wrote:
> > My first 'defense' is greylisting, run as a policy in postfix.
>
> Though do so with the knowledge that it may mean some mail never gets
> delivered/accepted. Greylisting, for both cases of rejecting spam and
> accepting ham, requires the services sending to you to work in certain
> way [1], and they don't all do that [2].
>
> 1. They reject the initial attempt, tell the sender to resend later, and
> accept the resend.
>
> 2. Some senders never resend, causing mail to get lost permanently.
> Some resends come from a different server, and that can get rejected,
> too - causing long delays, or permanently lost mail. Some resend
> attempts come after a very long delay, which can be annoying or business
> destroying, or can cause another reject.
>
> I've experienced all of the above bad scenarios.
----
I had heard that before I set it up but I have been running this same
setup on servers for 7 separate businesses and besides the initial
complaints of delays, it has been completely a non-issue. Few delays
have ever been longer than 30 minutes.

On the other hand, my setup has completely lightened the mail load.

And for an amusing side note to this...

My boss forwarded an e-mail to me which was a newsletter that he gets
via e-mail. I asked him what he expected me to do with it and he pointed
out to me a paragraph about their upcoming changes and that subscribers
should alter their 'filters' to be sure that they receive it.

I pointed out to him that on our network, I don't know of a single user
that has had to implement 'user level filters' for spam because so few
spam messages get through (I get about 5 a week and I am a very heavy
e-mail user). I pointed out that my methodology at the server level has
been so effective that I have no 'whitelisted' senders, no 'special
handling rules' at all beyond the high scoring spamassassin filter that
each user automatically inherits.

He replied back - never mind and later expressed to me that yeah, he
never gets spam and manages to get all of his e-mail.

Greylisting has been a very effective tool for me and I have had NO
complaints about it at all. There's actually a way around it in a
crunch...I've put a 5 minute window. The sender need only wait 5 minutes
and send the e-mail again which ultimately means that 2 copies show up
but the second one is delivered immediately and the first one is
delivered when their SMTP server decides to try again which is almost
always 15-30 minutes later.

Craig

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-26-2008, 01:09 PM
"Patrick O'Callaghan"
 
Default HELP!!! mail attack

On Wed, 2008-03-26 at 06:35 -0700, Craig White wrote:
> On Wed, 2008-03-26 at 23:06 +1030, Tim wrote:
> > On Wed, 2008-03-26 at 05:12 -0700, Craig White wrote:
> > > My first 'defense' is greylisting, run as a policy in postfix.
> >
> > Though do so with the knowledge that it may mean some mail never gets
> > delivered/accepted. Greylisting, for both cases of rejecting spam and
> > accepting ham, requires the services sending to you to work in certain
> > way [1], and they don't all do that [2].
> >
> > 1. They reject the initial attempt, tell the sender to resend later, and
> > accept the resend.
> >
> > 2. Some senders never resend, causing mail to get lost permanently.
> > Some resends come from a different server, and that can get rejected,
> > too - causing long delays, or permanently lost mail. Some resend
> > attempts come after a very long delay, which can be annoying or business
> > destroying, or can cause another reject.
> >
> > I've experienced all of the above bad scenarios.
> ----
> I had heard that before I set it up but I have been running this same
> setup on servers for 7 separate businesses and besides the initial
> complaints of delays, it has been completely a non-issue. Few delays
> have ever been longer than 30 minutes.
>
> On the other hand, my setup has completely lightened the mail load.
>
> And for an amusing side note to this...
>
> My boss forwarded an e-mail to me which was a newsletter that he gets
> via e-mail. I asked him what he expected me to do with it and he pointed
> out to me a paragraph about their upcoming changes and that subscribers
> should alter their 'filters' to be sure that they receive it.
>
> I pointed out to him that on our network, I don't know of a single user
> that has had to implement 'user level filters' for spam because so few
> spam messages get through (I get about 5 a week and I am a very heavy
> e-mail user). I pointed out that my methodology at the server level has
> been so effective that I have no 'whitelisted' senders, no 'special
> handling rules' at all beyond the high scoring spamassassin filter that
> each user automatically inherits.
>
> He replied back - never mind and later expressed to me that yeah, he
> never gets spam and manages to get all of his e-mail.
>
> Greylisting has been a very effective tool for me and I have had NO
> complaints about it at all. There's actually a way around it in a
> crunch...I've put a 5 minute window. The sender need only wait 5 minutes
> and send the e-mail again which ultimately means that 2 copies show up
> but the second one is delivered immediately and the first one is
> delivered when their SMTP server decides to try again which is almost
> always 15-30 minutes later.

Greylisting is indeed a very effective and I would say essential tool,
however we're seeing the effectiveness being reduced as time goes on
because spammers are getting smarter. This is an arms race and it's not
going to end in the foreseeable future.

poc

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-26-2008, 01:28 PM
Tim
 
Default HELP!!! mail attack

On Wed, 2008-03-26 at 06:35 -0700, Craig White wrote:
> Greylisting has been a very effective tool for me and I have had NO
> complaints about it at all.

The problem with thought process is thus: Admin says, "We don't get any
complaints." And the reason for that is that outsiders are unable to
make any contact to lay a complaint. It happens all the time, and
admins are unable to get their head around the issue...

I've had the same from people who don't answer their phone, and say that
they've not had any complaints about it. And yet they expect other
people to answer phone calls that they make. I just shake my head and
wonder how stupid they really are.

> There's actually a way around it in a crunch...I've put a 5 minute
> window.

That's really not a solution. While your server may say, come back in
5, you don't have any control over how, when, or if, the sender will
actually retry. And neither do us have any control over how our ISPs
configure their SMTP servers that we're forced to post through.

As soon as you implement greylisting, you *WILL* make it completely
impossible for *some* people to email you. It's an inescapable fact.
Trying to guess how much you will lose, and the worth of that loss, is a
pointless exercise.

It's not good for business, nor even personal relations. Some people
will try to contact you via an alternative method, some will not. I am
one of those who puts little effort into contacting someone that makes
it hard to do so, and I am not alone in that regard.

A case in point, the greylisting response that killed a message I tried
sending to someone, to whom I had no other way to get in touch with:

This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 24 hours on the queue ...[snip]...

The message identifier is: ...[snip]...
The subject of the message is: ...[snip]...
The date of the message is: Sun, 10 Feb 2008 21:49:26 +1030

The address to which the message has not yet been delivered is:

...[snip@chariot.net.au]...
Delay reason: SMTP error from remote mail server after RCPT TO:...[snip]...@chariot.net.au>:
host secmx.vic.chariot.net.au [203.87.83.188]:
450 4.7.1 <...[snip]...@chariot.net.au>: Recipient address rejected:
Greylisted for 1 minutes

The message said to try again in 1 minute, it never succeeded. The
error message, about it, came to me two days later. I saw no point in
trying to send again, the system had tried to resend and failed, by
itself. There's nothing I can do to change how it was going to try.

Taking a day to try and e-mail someone, and being informed two whole
days after posting that it failed, is just pathetic. Email should take
mere seconds, no matter what some dingbats think about it.

Right now I'm mentally picturing what should happen to spammers that
caused the invention of greylisting now DoSing us, it involves baseball
bats, steel-capped workboots, and broken bones...

--
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-26-2008, 01:59 PM
Craig White
 
Default HELP!!! mail attack

On Thu, 2008-03-27 at 00:58 +1030, Tim wrote:
> On Wed, 2008-03-26 at 06:35 -0700, Craig White wrote:
> > Greylisting has been a very effective tool for me and I have had NO
> > complaints about it at all.
>
> The problem with thought process is thus: Admin says, "We don't get any
> complaints." And the reason for that is that outsiders are unable to
> make any contact to lay a complaint. It happens all the time, and
> admins are unable to get their head around the issue...
----
again... 3 years, 7 servers tells me that this is not only eminently
workable but an important tool.

YMMV - I'm comfortable with that.
----
>
> > There's actually a way around it in a crunch...I've put a 5 minute
> > window.
>
> That's really not a solution. While your server may say, come back in
> 5, you don't have any control over how, when, or if, the sender will
> actually retry. And neither do us have any control over how our ISPs
> configure their SMTP servers that we're forced to post through.
>
> As soon as you implement greylisting, you *WILL* make it completely
> impossible for *some* people to email you. It's an inescapable fact.
> Trying to guess how much you will lose, and the worth of that loss, is a
> pointless exercise.
>
> It's not good for business, nor even personal relations. Some people
> will try to contact you via an alternative method, some will not. I am
> one of those who puts little effort into contacting someone that makes
> it hard to do so, and I am not alone in that regard.
----
You speak in absolutes but your absolutes choose a window that is
incomplete. It's bad for business to have a server tied up in trying to
run clamav and spamassassin scan a batch of e-mails that 70% would never
reach the queue if you run greylisting.

We are not talking about an insignificant number of computer cycles at
all.

As for making it impossible for *some* people to e-mail accounts on
these servers...I haven't had a single report to that effect, again, 3
years, 7 mail servers.
----
> A case in point, the greylisting response that killed a message I tried
> sending to someone, to whom I had no other way to get in touch with:
>
> This message was created automatically by mail delivery software.
> A message that you sent has not yet been delivered to one or more of its
> recipients after more than 24 hours on the queue ...[snip]...
>
> The message identifier is: ...[snip]...
> The subject of the message is: ...[snip]...
> The date of the message is: Sun, 10 Feb 2008 21:49:26 +1030
>
> The address to which the message has not yet been delivered is:
>
> ...[snip@chariot.net.au]...
> Delay reason: SMTP error from remote mail server after RCPT TO:...[snip]...@chariot.net.au>:
> host secmx.vic.chariot.net.au [203.87.83.188]:
> 450 4.7.1 <...[snip]...@chariot.net.au>: Recipient address rejected:
> Greylisted for 1 minutes
>
> The message said to try again in 1 minute, it never succeeded. The
> error message, about it, came to me two days later. I saw no point in
> trying to send again, the system had tried to resend and failed, by
> itself. There's nothing I can do to change how it was going to try.
>
> Taking a day to try and e-mail someone, and being informed two whole
> days after posting that it failed, is just pathetic. Email should take
> mere seconds, no matter what some dingbats think about it.
----
you are throwing out the baby with the bath water. Just because some
system out there is configured poorly doesn't mean that the underlying
technology isn't sound.

Craig

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-26-2008, 01:59 PM
John Summerfield
 
Default HELP!!! mail attack

Rodolfo Alcazar Portillo wrote:

Hello. Since monday, our mailserver (FC5), behind a firewall, is
suffering a heavy DoS mail attack. We have a user account,
amanda.davila@padep.org.bo and it is receiving millions of emails from
very different sites of the planet. Since now, my only action was
deleting the account from /etc/password, and the traffic permits
working. We suspect a virus attack...

What else can we do? We would appreciate any help with this issue. Here,
a 20 seconds log by 07:15 GMT-4 (too early, many pcs off).


I use postfix; I can do this:
[root@mail.js.id.au sysconfig]# tail /etc/postfix/header_checks
/^Received.*UNITED.CO.UK/ REJECT No thanks
/^Received.*HAPPYGROUP.CO.UK/ REJECT No thanks
/^Received:.*ceres.concept.net.nz/ REJECT Bloody twits
/^Received:.*dizinc.com/ REJECT No thanks
/CentOS-announce Digest/ REJECT I don't want these
/yourshopineu/ REJECT Bloody spammer

Those are Perl regular expressions.

One can enable the checks thus:
header_checks = pcre:/etc/postfix/header_checks
body_checks = pcre:/etc/postfix/body_checks

Now, if you're not using postfix you may be able to do something similar....

That rejects the email about as fast as you can, you're rejecting it
during the connexion.


Those will be logged. I'd then develop a script to munge the messages to
extract the remote IP address and generate iptables rules to block
entire /24 network addresses containing the offenders.


I would drop, not reject the connexions.

You need also to work with your IAP who, presumably, has more bandwidth
than you, and can defend more clients from the remote attackers.


Probably you should also involve your relevant law enforcement agency.







# tethereal |grep RCPT

0.030421 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
0.084245 193.195.46.98 -> 192.168.1.15 SMTP Command: RCPT To:<amanda.davila@padep.org.bo>
0.813207 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
1.196831 221.246.173.133 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
1.214975 221.246.173.133 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
1.330348 203.162.4.185 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
1.633672 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
1.999373 64.22.97.151 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
2.674852 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
2.783758 212.241.250.110 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
3.420356 71.86.28.162 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
3.785264 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
4.742188 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
5.525666 81.80.63.187 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
5.617303 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
5.854842 71.86.28.162 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
5.863718 70.103.68.218 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
5.868905 70.103.68.218 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
6.096777 59.124.4.190 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
6.436249 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
6.466815 66.249.92.172 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
7.262385 193.115.206.80 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
7.397907 71.86.28.162 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
10.592647 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
10.594863 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
10.646376 81.72.107.178 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
11.262748 212.135.207.34 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
11.383742 203.162.4.185 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
11.538739 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
11.568291 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
11.988369 203.190.60.202 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
12.501307 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
12.528634 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
12.807326 220.152.32.164 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
13.115271 212.135.207.34 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
13.453285 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
13.474763 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
14.099809 212.135.207.34 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
14.393268 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
14.429214 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
15.034781 212.135.207.34 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
15.053775 212.135.207.34 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
15.337869 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
15.378731 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
15.868339 189.32.131.187 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
16.258275 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
16.312235 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
16.633300 210.162.25.47 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
17.149183 210.147.8.9 -> 192.168.1.15 SMTP Command: RCPT To:<amanda.davila@padep.org.bo>
17.225328 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
17.237639 189.32.131.187 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
17.272639 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
17.673762 84.12.48.115 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
17.698118 84.12.48.115 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
18.182747 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
18.206657 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
18.422710 141.156.107.252 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
18.433819 141.156.107.252 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
18.588780 189.32.131.187 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
18.810259 210.162.25.47 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
19.128838 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>
19.167259 140.186.109.125 -> 192.168.1.15 SMTP Command: RCPT TO:<amanda.davila@padep.org.bo>

Here you can find a more detailed log:
http://www.padep.org.bo/log20080325/

Thanks, again...
----------------------------------------------
Rodolfo Alcazar - rodolfo.alcazar@padep.org.bo
otbits.blogspot.com / counter.li.org: #367962
----------------------------------------------
"Träume nicht dein Leben, lebe deinen Traum."
- Unbekannter Autor





--

Cheers
John

-- spambait
1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-26-2008, 02:00 PM
Craig White
 
Default HELP!!! mail attack

On Wed, 2008-03-26 at 09:39 -0430, Patrick O'Callaghan wrote:
> On Wed, 2008-03-26 at 06:35 -0700, Craig White wrote:
> > On Wed, 2008-03-26 at 23:06 +1030, Tim wrote:
> > > On Wed, 2008-03-26 at 05:12 -0700, Craig White wrote:
> > > > My first 'defense' is greylisting, run as a policy in postfix.
> > >
> > > Though do so with the knowledge that it may mean some mail never gets
> > > delivered/accepted. Greylisting, for both cases of rejecting spam and
> > > accepting ham, requires the services sending to you to work in certain
> > > way [1], and they don't all do that [2].
> > >
> > > 1. They reject the initial attempt, tell the sender to resend later, and
> > > accept the resend.
> > >
> > > 2. Some senders never resend, causing mail to get lost permanently.
> > > Some resends come from a different server, and that can get rejected,
> > > too - causing long delays, or permanently lost mail. Some resend
> > > attempts come after a very long delay, which can be annoying or business
> > > destroying, or can cause another reject.
> > >
> > > I've experienced all of the above bad scenarios.
> > ----
> > I had heard that before I set it up but I have been running this same
> > setup on servers for 7 separate businesses and besides the initial
> > complaints of delays, it has been completely a non-issue. Few delays
> > have ever been longer than 30 minutes.
> >
> > On the other hand, my setup has completely lightened the mail load.
> >
> > And for an amusing side note to this...
> >
> > My boss forwarded an e-mail to me which was a newsletter that he gets
> > via e-mail. I asked him what he expected me to do with it and he pointed
> > out to me a paragraph about their upcoming changes and that subscribers
> > should alter their 'filters' to be sure that they receive it.
> >
> > I pointed out to him that on our network, I don't know of a single user
> > that has had to implement 'user level filters' for spam because so few
> > spam messages get through (I get about 5 a week and I am a very heavy
> > e-mail user). I pointed out that my methodology at the server level has
> > been so effective that I have no 'whitelisted' senders, no 'special
> > handling rules' at all beyond the high scoring spamassassin filter that
> > each user automatically inherits.
> >
> > He replied back - never mind and later expressed to me that yeah, he
> > never gets spam and manages to get all of his e-mail.
> >
> > Greylisting has been a very effective tool for me and I have had NO
> > complaints about it at all. There's actually a way around it in a
> > crunch...I've put a 5 minute window. The sender need only wait 5 minutes
> > and send the e-mail again which ultimately means that 2 copies show up
> > but the second one is delivered immediately and the first one is
> > delivered when their SMTP server decides to try again which is almost
> > always 15-30 minutes later.
>
> Greylisting is indeed a very effective and I would say essential tool,
> however we're seeing the effectiveness being reduced as time goes on
> because spammers are getting smarter. This is an arms race and it's not
> going to end in the foreseeable future.
----
ride the wave...agreed on the arms race but so far, greylisting easily
skims about 70% of the useless cruft off the top at a very low
computational cost.

Craig

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 03-26-2008, 02:02 PM
John Summerfield
 
Default HELP!!! mail attack

Craig White wrote:

On Wed, 2008-03-26 at 07:23 -0400, Rodolfo Alcazar Portillo wrote:

Hello. Since monday, our mailserver (FC5), behind a firewall, is
suffering a heavy DoS mail attack. We have a user account,
amanda.davila@padep.org.bo and it is receiving millions of emails from
very different sites of the planet. Since now, my only action was
deleting the account from /etc/password, and the traffic permits
working. We suspect a virus attack...

What else can we do? We would appreciate any help with this issue. Here,
a 20 seconds log by 07:15 GMT-4 (too early, many pcs off).

----
That account has likely been 'Joe Jobbed' and you are seeing the
backscatter. Google 'Joe Job' or find it on Wikipedia for an
explanation.

If you have a mail server, an account, and e-mails arriving, there's
little you can do in a specific sense but you have to evaluate your
overall mail scheme.

I will explain in a general way, how I set up my mail servers and
perhaps this may help.

I use postfix but the only difference I have found between postfix and
sendmail is that postfix is a little easier to setup/maintain.

My first 'defense' is greylisting, run as a policy in postfix.
Greylisting maintains a database (MySQL) primarily using a table of


greylisting is of limited use, spammers know that technique and how to
work around it. Otherwise we're in pretty fair agreement.





'tuples' of sender, recipient, mailhost (smtp server trying to deliver
the mail). Greylisting sends a tempfail on the first attempt by sender,
to recipient from particular mail server. This eliminates much e-mail
sent by 'bot' systems that are just spraying e-mail around and are not
true SMTP servers and thus don't attempt 're-delivery'

My second defense is to use rbl's (abuseat / spamhaus / dsbl) to
otherwise block KNOWN blacklisted sources

My third defense is to require:
- reverse DNS of sender
- fqdn of sender
- valid hostname
- valid recipient

This all happens before I choose to accept mail.

Once I have accepted e-mail, it is shuffled to 'MailScanner' which is a
wrapper program that sends e-mail through clamav and then through
spamassassin, where it is cleaned and scored.

Finally, I have 'sieve' rules for all users which puts high spam score
e-mails into a users 'SPAMBOX' folder of which everything that is older
than 7 days is automatically cleaned out.

The notion of rejecting most e-mail before you ever accept it is really,
really important because it minimizes the very expensive computing costs
of inspection by clamav and spamassassin.

Craig




--

Cheers
John

-- spambait
1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 

Thread Tools




All times are GMT. The time now is 03:08 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org