Re: Spam sent from compromised (web)hosts vs botnet spam

On Mar 21, 2013, at 10:48, Chris Lewis <[email protected]> wrote:

> On 13-03-21 12:20 PM, Dan Oetting wrote:
>> 
>> On Mar 21, 2013, at 2:51 AM, "Emanuele Balla (aka Skull)" <[email protected]> wrote:
>> 
>>> The side effect is the colo doesn't see any significant traffic, as the
>>> only traffic going in and out the machine they host is return traffic
>>> (non-tunneled going IN, tunneled going OUT). So, unless you (as colo)
>>> know what to look at, there's nothing triggering your alarms…
>> 
>> Many years ago, i suggested a simple solution. In cases where traffic is presumed to be abusive such as an SMTP transaction involving multiple invalid accounts, send back an ICMP error that network providers would be able to watch for as a hint to what traffic they should be monitoring. Since these reports would be returning in real time, automated monitoring tools could be developed to snapshot the transactions that triggered the report so the provider would have all the evidence from their own network if they chose to look into it. The tools themselves could even do much of the preliminary analysis looking for common patterns and triggering alarms when problems are discovered.
> 
> Many years ago, RFG did something similar.  Spam traffic inbound to him
> would result in a remote syslog back.
> 
> Then we had an unapproved (aka "unknown to the guys authorized to run
> email servers") MTA go "multi-stage open relay".
> 
> EVEN THOUGH the remote syslog text was sorta clear as to what it was (in
> an RFG-esque sense ;-), the rsyslog flood and resulting consternation
> churned up many manhours in network and corporate security groups, and
> was about to trigger a formal LE complaint, until _I_ found out about
> it.  By accident...
> 
> "oh", I sez, "I know what _that_ crap is, I'll deal with it".
> 
> RFG later blamed it on Dave Rand.
> 
> [RFG doesn't like me reminding people of it.  He should be glad.  I
> saved him from a sticky time with the cops.]
> 
> You don't want to be blamed for this, do you? <grin>
> 
> This'd have to be some sort of "opt-in" service.  IOW the network
> provider has to somehow advertise "I want this feedback ...".

So you were flooding RFG with spam. You should be glad he didn't send a swat team out to deal with it. :)

RFG was sending a packet using a different port, would require a human to parse because it didn't follow an existing standard, was presumed to consume resources at the receiving end and if sent to a server that didn't like it that implemented the same rule would result in a loop.

The abuse packet I was suggesting is an ICMP sent in response to a received packet. Rules for handling ICMP packets are well known, the ruled specifically forbid sending an ICMP in response to an ICMP, the ICMP contains the details of the abusive packet in a format that is well known, you have already opted it to receive ICMP packets by sending the packet which the ICMP Is responding to and unless you specifically look for the ICMP packets you aren't going to see them.

 -- Dan Oetting


-
This is the asrg mailing list.  To change your subscription settings, see
http://lists.services.net/cgi-bin/mj_wwwusr/domain=lists.gurus.org