Has anyone out there got any ideas as to what I can do to stop these
people out there? I think we've just got above the radar...

Sep 22 16:41:26 server sm-mta[8493]: l8M4fQrs008493: [75.80.10.54] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 22 16:41:26 server sm-mta[8494]: l8M4fQ7l008494: [69.254.104.182] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 22 16:41:26 server sm-mta[8505]: l8M4fQ1L008505: [60.53.236.147] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 22 16:41:26 server sm-mta[8515]: l8M4fQDJ008515: [86.45.72.162] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 22 16:41:26 server sm-mta[8529]: l8M4fQhN008529: [220.245.110.133] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 22 16:41:26 server sm-mta[8533]: l8M4fQia008533: [24.176.217.93] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 22 16:41:26 server sm-mta[8544]: l8M4fQu8008544: [83.208.25.114] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 22 16:41:26 server sm-mta[8547]: l8M4fQ5O008547: [203.228.99.254] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 22 16:41:26 server sm-mta[8548]: l8M4fQtk008548: [87.241.209.2] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 22 16:41:27 server sm-mta[8549]: l8M4fRqK008549: [84.102.37.43] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 22 16:41:27 server sm-mta[8550]: l8M4fRR3008550: [24.6.173.151] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 22 16:41:27 server sm-mta[8553]: l8M4fRG0008553: [201.160.128.190] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Sep 22 16:41:27 server sm-mta[8554]: l8M4fRxw008554: [60.48.62.65] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

Is a very small excerpt from the mail log. I've put on a greet pause of 5
seconds, but that doesn't really seem to have made much impression. I've
got about 50,000 ip addresses firewalled, but this obviously isn't the
solution.

Problem is that we're using this as a honeypot, so we want as much cr*p as
we can get!

Any suggestions will be gratefully received.

Steve

Steve wrote:
> Has anyone out there got any ideas as to what I can do to stop these
> people out there? I think we've just got above the radar...
>
> Sep 22 16:41:26 server sm-mta[8493]: l8M4fQrs008493: [75.80.10.54] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8494]: l8M4fQ7l008494: [69.254.104.182] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8505]: l8M4fQ1L008505: [60.53.236.147] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8515]: l8M4fQDJ008515: [86.45.72.162] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8529]: l8M4fQhN008529: [220.245.110.133] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8533]: l8M4fQia008533: [24.176.217.93] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8544]: l8M4fQu8008544: [83.208.25.114] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8547]: l8M4fQ5O008547: [203.228.99.254] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8548]: l8M4fQtk008548: [87.241.209.2] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:27 server sm-mta[8549]: l8M4fRqK008549: [84.102.37.43] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:27 server sm-mta[8550]: l8M4fRR3008550: [24.6.173.151] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:27 server sm-mta[8553]: l8M4fRG0008553: [201.160.128.190] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:27 server sm-mta[8554]: l8M4fRxw008554: [60.48.62.65] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>
> Is a very small excerpt from the mail log. I've put on a greet pause of 5
> seconds, but that doesn't really seem to have made much impression. I've
> got about 50,000 ip addresses firewalled, but this obviously isn't the
> solution.
>
> Problem is that we're using this as a honeypot, so we want as much cr*p as
> we can get!
>
> Any suggestions will be gratefully received.
>
> Steve

If this is a honeypot why are you even using the greet pause? A honeypot
should not have *ANY* restrictions.

On Fri, 21 Sep 2007 23:55:04 -0700, Scott Grayban wrote:

> Steve wrote:
>> Has anyone out there got any ideas as to what I can do to stop these
>> people out there? I think we've just got above the radar...
>>
>> Sep 22 16:41:26 server sm-mta[8493]: l8M4fQrs008493: [75.80.10.54] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>> Sep 22 16:41:26 server sm-mta[8494]: l8M4fQ7l008494: [69.254.104.182] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>> Sep 22 16:41:26 server sm-mta[8505]: l8M4fQ1L008505: [60.53.236.147] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>> Sep 22 16:41:26 server sm-mta[8515]: l8M4fQDJ008515: [86.45.72.162] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>> Sep 22 16:41:26 server sm-mta[8529]: l8M4fQhN008529: [220.245.110.133] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>> Sep 22 16:41:26 server sm-mta[8533]: l8M4fQia008533: [24.176.217.93] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>> Sep 22 16:41:26 server sm-mta[8544]: l8M4fQu8008544: [83.208.25.114] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>> Sep 22 16:41:26 server sm-mta[8547]: l8M4fQ5O008547: [203.228.99.254] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>> Sep 22 16:41:26 server sm-mta[8548]: l8M4fQtk008548: [87.241.209.2] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>> Sep 22 16:41:27 server sm-mta[8549]: l8M4fRqK008549: [84.102.37.43] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>> Sep 22 16:41:27 server sm-mta[8550]: l8M4fRR3008550: [24.6.173.151] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>> Sep 22 16:41:27 server sm-mta[8553]: l8M4fRG0008553: [201.160.128.190] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>> Sep 22 16:41:27 server sm-mta[8554]: l8M4fRxw008554: [60.48.62.65] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>
>> Is a very small excerpt from the mail log. I've put on a greet pause of 5
>> seconds, but that doesn't really seem to have made much impression. I've
>> got about 50,000 ip addresses firewalled, but this obviously isn't the
>> solution.
>>
>> Problem is that we're using this as a honeypot, so we want as much cr*p as
>> we can get!
>>
>> Any suggestions will be gratefully received.
>>
>> Steve
>
> If this is a honeypot why are you even using the greet pause? A honeypot
> should not have *ANY* restrictions.
What use is a honeypot that's being ddosed? We're getting almost no
'legitimate' spams through now, just the connections at shown from the log.

How would you separate the two???

Steve wrote:
> On Fri, 21 Sep 2007 23:55:04 -0700, Scott Grayban wrote:
>
>> Steve wrote:
>>> Has anyone out there got any ideas as to what I can do to stop these
>>> people out there? I think we've just got above the radar...
>>>
>>> Sep 22 16:41:26 server sm-mta[8493]: l8M4fQrs008493: [75.80.10.54] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>> Sep 22 16:41:26 server sm-mta[8494]: l8M4fQ7l008494: [69.254.104.182] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>> Sep 22 16:41:26 server sm-mta[8505]: l8M4fQ1L008505: [60.53.236.147] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>> Sep 22 16:41:26 server sm-mta[8515]: l8M4fQDJ008515: [86.45.72.162] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>> Sep 22 16:41:26 server sm-mta[8529]: l8M4fQhN008529: [220.245.110.133] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>> Sep 22 16:41:26 server sm-mta[8533]: l8M4fQia008533: [24.176.217.93] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>> Sep 22 16:41:26 server sm-mta[8544]: l8M4fQu8008544: [83.208.25.114] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>> Sep 22 16:41:26 server sm-mta[8547]: l8M4fQ5O008547: [203.228.99.254] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>> Sep 22 16:41:26 server sm-mta[8548]: l8M4fQtk008548: [87.241.209.2] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>> Sep 22 16:41:27 server sm-mta[8549]: l8M4fRqK008549: [84.102.37.43] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>> Sep 22 16:41:27 server sm-mta[8550]: l8M4fRR3008550: [24.6.173.151] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>> Sep 22 16:41:27 server sm-mta[8553]: l8M4fRG0008553: [201.160.128.190] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>> Sep 22 16:41:27 server sm-mta[8554]: l8M4fRxw008554: [60.48.62.65] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>>
>>> Is a very small excerpt from the mail log. I've put on a greet pause of 5
>>> seconds, but that doesn't really seem to have made much impression. I've
>>> got about 50,000 ip addresses firewalled, but this obviously isn't the
>>> solution.
>>>
>>> Problem is that we're using this as a honeypot, so we want as much cr*p as
>>> we can get!
>>>
>>> Any suggestions will be gratefully received.
>>>
>>> Steve
>> If this is a honeypot why are you even using the greet pause? A honeypot
>> should not have *ANY* restrictions.
> What use is a honeypot that's being ddosed? We're getting almost no
> 'legitimate' spams through now, just the connections at shown from the log.
>
> How would you separate the two???

First off 99% of zombies don't even obey the greet pause so that is useless
anyways and probably why you are getting DDosed.

So what you get is a zombie trying over and over trying to connect and that
probably is what is going on.

I really doubt your getting ddosed. I looked at a sample of the ip's
connecting and they are all listed.

On Sat, 22 Sep 2007 02:36:02 -0700, Scott Grayban wrote:

> Steve wrote:
>> On Fri, 21 Sep 2007 23:55:04 -0700, Scott Grayban wrote:
>>
>>> Steve wrote:
>>>> Has anyone out there got any ideas as to what I can do to stop these
>>>> people out there? I think we've just got above the radar...
>>>>
>>>> Sep 22 16:41:26 server sm-mta[8493]: l8M4fQrs008493: [75.80.10.54] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>>> Sep 22 16:41:26 server sm-mta[8494]: l8M4fQ7l008494: [69.254.104.182] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>>> Sep 22 16:41:26 server sm-mta[8505]: l8M4fQ1L008505: [60.53.236.147] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>>> Sep 22 16:41:26 server sm-mta[8515]: l8M4fQDJ008515: [86.45.72.162] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>>> Sep 22 16:41:26 server sm-mta[8529]: l8M4fQhN008529: [220.245.110.133] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>>> Sep 22 16:41:26 server sm-mta[8533]: l8M4fQia008533: [24.176.217.93] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>>> Sep 22 16:41:26 server sm-mta[8544]: l8M4fQu8008544: [83.208.25.114] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>>> Sep 22 16:41:26 server sm-mta[8547]: l8M4fQ5O008547: [203.228.99.254] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>>> Sep 22 16:41:26 server sm-mta[8548]: l8M4fQtk008548: [87.241.209.2] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>>> Sep 22 16:41:27 server sm-mta[8549]: l8M4fRqK008549: [84.102.37.43] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>>> Sep 22 16:41:27 server sm-mta[8550]: l8M4fRR3008550: [24.6.173.151] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>>> Sep 22 16:41:27 server sm-mta[8553]: l8M4fRG0008553: [201.160.128.190] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>>> Sep 22 16:41:27 server sm-mta[8554]: l8M4fRxw008554: [60.48.62.65] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>>>>
>>>> Is a very small excerpt from the mail log. I've put on a greet pause of 5
>>>> seconds, but that doesn't really seem to have made much impression. I've
>>>> got about 50,000 ip addresses firewalled, but this obviously isn't the
>>>> solution.
>>>>
>>>> Problem is that we're using this as a honeypot, so we want as much cr*p as
>>>> we can get!
>>>>
>>>> Any suggestions will be gratefully received.
>>>>
>>>> Steve
>>> If this is a honeypot why are you even using the greet pause? A honeypot
>>> should not have *ANY* restrictions.
>> What use is a honeypot that's being ddosed? We're getting almost no
>> 'legitimate' spams through now, just the connections at shown from the log.
>>
>> How would you separate the two???
>
> First off 99% of zombies don't even obey the greet pause so that is useless
> anyways and probably why you are getting DDosed.
>
> So what you get is a zombie trying over and over trying to connect and that
> probably is what is going on.
>
> I really doubt your getting ddosed. I looked at a sample of the ip's
> connecting and they are all listed.

Is it just me, or do I just not understand what a greet pause is intended
to do?

Like I said, I'm getting ddosed, and have banned about 50,000 ip
addresses so far. The few lines from the log were to show what the
attackers were doing, not tell you who was attacking me. Is there anyone
out there who can actually offer helpful advice?

I'm not a grumpy old s*d, really. I'm just out there fighting spam (:

Steve

Steve wrote:
>> First off 99% of zombies don't even obey the greet pause so that is useless
>> anyways and probably why you are getting DDosed.
>>
>> So what you get is a zombie trying over and over trying to connect and that
>> probably is what is going on.
>>
>> I really doubt your getting ddosed. I looked at a sample of the ip's
>> connecting and they are all listed.
>
> Is it just me, or do I just not understand what a greet pause is intended
> to do?

Yup it's you. You are NOT getting ddosed in the conventional sense. You are
getting ddosed by zombie computers infected with a virus to send out spam.
Your greet pause does nothing to those zombie computers because they DO NOT
OBEY ANY RFC and that is your problem. Sorry your a idiot about this.


> Like I said, I'm getting ddosed, and have banned about 50,000 ip
> addresses so far. The few lines from the log were to show what the
> attackers were doing, not tell you who was attacking me. Is there anyone
> out there who can actually offer helpful advice?
>
> I'm not a grumpy old s*d, really. I'm just out there fighting spam (:

Sure you are...

In article <fd26kh$42v$1 [at] lust.ihug.co.nz>, Steve <steve [at] yobank.com>
wrote:

> Has anyone out there got any ideas as to what I can do to stop these
> people out there? I think we've just got above the radar...
>
> Sep 22 16:41:26 server sm-mta[8493]: l8M4fQrs008493: [75.80.10.54] did not
> issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8494]: l8M4fQ7l008494: [69.254.104.182] did not
> issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8505]: l8M4fQ1L008505: [60.53.236.147] did not
> issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8515]: l8M4fQDJ008515: [86.45.72.162] did not
> issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8529]: l8M4fQhN008529: [220.245.110.133] did
> not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8533]: l8M4fQia008533: [24.176.217.93] did not
> issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8544]: l8M4fQu8008544: [83.208.25.114] did not
> issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8547]: l8M4fQ5O008547: [203.228.99.254] did not
> issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:26 server sm-mta[8548]: l8M4fQtk008548: [87.241.209.2] did not
> issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:27 server sm-mta[8549]: l8M4fRqK008549: [84.102.37.43] did not
> issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:27 server sm-mta[8550]: l8M4fRR3008550: [24.6.173.151] did not
> issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:27 server sm-mta[8553]: l8M4fRG0008553: [201.160.128.190] did
> not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
> Sep 22 16:41:27 server sm-mta[8554]: l8M4fRxw008554: [60.48.62.65] did not
> issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>
> Is a very small excerpt from the mail log.

If that's all you're seeing, it may be wrong to call it a DDoS. I've
been seeing a sporadically higher rate of bogus connections on a gang of
corporate mail servers that no one has any reason to be trying to pound
on. I don't think it's a DDoS attack intentionally, but rather a broken
botnet out there having convulsions

On the other hand, I've seen reports of the latest Storm herd looking
like it has scan detection and counterpunch features. That can't explain
the 1000 unique IP's per minute I have seen episodically this week on
the system I mentioned, but if you're actually seeing a more concerted
attack


> I've put on a greet pause of 5
> seconds, but that doesn't really seem to have made much impression. I've
> got about 50,000 ip addresses firewalled, but this obviously isn't the
> solution.

On an operational inbound-only (i.e. no submission from end users
running garbageware) mail server, you can usually get away with
aggregating such blocking rather aggressively. It's a very rare /27 with
a zombie that also has a legitimate mail server, and I've never run into
trouble with a 2% threshold, i.e. if there are 6 addresses well-spread
around a /24 acting like zombies towards one place today, there's not
likely going to be any loss from blocking the whole /24.


> Problem is that we're using this as a honeypot, so we want as much cr*p as
> we can get!

In that case, it seems like you'd want to be able to beef up the target
machine to handle the abuse rather than figure out ways to shun
attackers. Frankly, Sendmail is not the best SMTP server for a honeypot,
because it doesn't handle huge connection onslaughts very well. You'd be
better off with a purpose-built SMTP conversation handler that doesn't
trouble itself with actually routing messages, or maybe with Postfix 2.4
on a suitable OS (i.e. with epoll/kqueue/devpoll support.) getting
Sendmail to handle really high concurrency well is difficult to the
extent that it is probably not worth doing for a honeypot.

--
Now where did I hide that website...

In article <fd2sso$430$2 [at] lust.ihug.co.nz>, Steve <steve [at] yobank.com>
wrote:

> Is it just me, or do I just not understand what a greet pause is intended
> to do?

Maybe.

GreetPause is only really helpful for identifying connections where the
sender isn't behaving by fundamental SMTP norms and so does not need to
be treated with any sort of real care, i.e. violating the GreetPause
triggers Sendmail to reject all commands rather than to actually do
anything. Arguably a better approach would be to close the connection on
a violation, but that's not what Sendmail does currently. You know where
to get the source code, and you can modify it to suit your needs...


> Like I said, I'm getting ddosed, and have banned about 50,000 ip
> addresses so far. The few lines from the log were to show what the
> attackers were doing, not tell you who was attacking me. Is there anyone
> out there who can actually offer helpful advice?

How's this: honeypotting with Sendmail is analogous to bow-hunting for
elephants.

Calling this a DDoS is perhaps technically true, but it is probably not
a directed attack, since everyone with an exposed system seems to be
seeing the same stuff. Handling it for a production mail system consists
largely of automating packet filtering and throwing a lot of RAM and CPU
power at the problem. Since you did not choose to share any of your
configuration or really even problem details, no one can make any
specific suggestions for change to handle your problem. When you call
this a DDoS, you are not describing the actual problem with your system,
i.e. why are a dozen connections/second causing you so much trouble?


> I'm not a grumpy old s*d, really. I'm just out there fighting spam (:

I am proof that this is not a strict either/or choice.

--
Now where did I hide that website...

In comp.mail.sendmail Steve <steve [at] yobank.com>:
> Has anyone out there got any ideas as to what I can do to stop these
> people out there? I think we've just got above the radar...

> Sep 22 16:41:26 server sm-mta[8493]: l8M4fQrs008493:
> [75.80.10.54] did not issue MAIL/EXPN/VRFY/ETRN during
> connection to MTA

> Sep 22 16:41:26 server sm-mta[8494]: l8M4fQ7l008494:
> [69.254.104.182] did not issue MAIL/EXPN/VRFY/ETRN during
> connection to MTA

> Sep 22 16:41:26 server sm-mta[8505]: l8M4fQ1L008505:
> [60.53.236.147] did not issue MAIL/EXPN/VRFY/ETRN during
> connection to MTA

[more logs like the above]

> Is a very small excerpt from the mail log. I've put on a greet pause of 5
> seconds, but that doesn't really seem to have made much impression. I've
> got about 50,000 ip addresses firewalled, but this obviously isn't the
> solution.

> Problem is that we're using this as a honeypot, so we want as much cr*p as
> we can get!

> Any suggestions will be gratefully received.

Doesn't look like a ddos trial to me, more like broken ratware.
It's not much anyway, get far more "real" connections from
ratware 24/7...

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry [at] urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 405: Sysadmins unavailable because they are in
a meeting talking about why they are unavailable so much.

On Sat, 22 Sep 2007 10:44:23 -0400, Bill Cole wrote:
[snip]

Many thanks for the info. A lot of food for thought in there...