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

On Mar 22, 2013, at 2:45, Paul Smith <[email protected]> wrote:

> On 22/03/2013 03:03, Dan Oetting wrote:
>> After all that abuse you inflicted on my server, you have the gall to say that my little ICMP packet is abusing your network
> 
> I agree with Dan here.
> 
> One 'legal' option is to send a bounce message, or a message back to 'abuse@<you>' (eg abuse@[1.2.3.4] or something more intelligent). No one would complain about those, or say that is abuse, even though that will use a lot more bandwidth and server load.
> 
> Alternatively you could send an ICMP packet back.
> 
> Seems to me that a little ICMP packet would 'abuse' a network much less than an email message... It would also be more useful as it can be monitored more easily at the gateway level rather that at the host level.
> 
> However, it would also make sense to have it be 'opt in', otherwise the ICMP packet will be ignored anyway (and does risk someone, somewhere taking offense). The problem is that I can't think of a good way to be able to 'opt in'. The only way I can come up with at the moment would be to piggy-back on rDNS, which would almost certainly not be allowed.


To show again how an ICMP is a legal option, at any time I can decide that I have taken enough abuse from your spammy system and I can tell my firewall to stop it. There is a message that seems to be specifically defined for this situation, ICMP type 3 code 13: communication denied, administratively prohibited.

At the time when the ICMP messages were defined, the Internet was a cooperative place. The designers weren't thinking about dealing with abuse so they didn't create any protocols to report it. Until a new series of ICMP codes are defined specifically for abuse reporting, type 3 code 13 is the best we have.

By default, this ICMP message will be delivered to the sending host through firewalls and even NAT gateways. No other out of band message will do that. This message already identifies the TCP stream it is being sent in response to so no protocol extension is required for the implementation. 

By being out of band, it is possible for any network administrator along the path to monitor their networks for this code. Since this is an advisory message, it is even possible for an ISP to intercept this message and replace it with a TCP RST which will have the same effect of shutting down the stream but denies their untrusted clients the feedback that they are being reported.


What is not known is how all TCP/IP stacks will respond to this message. The expected behavior is that it will either be ignored or have the same effect as a TCP RST. There is the possibility that it could trigger a local blacklist for the destination IP address/port. The effect on legitimate mail streams would need to be considered but some might see this as a bonus.

-- 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