 kpatz MY HEAD A SPLODE Premium join:2003-06-13 Manchester, NH
| reply to BlitzenZeus Re: Messenger Spam on 1026 - Bad News Kids
Also, from what I've heard is the spammer doesn't have to "listen" for the response either, unless they want to confirm that the spam was received. By setting certain flags in the RPC data the spam will pop up with no handshake required, thus allowing mass "mailing" of messenger spam Slammer style, and the source IPs can even be spoofed.
I've been running a listener program, similar to your PortPuker (initially on 135, but now I run it on 1026-1028) on my Linux box and have captured over 2,300 messenger spams so far. The majority of them, ironically, are advertising ways to stop messenger spam.
Of course the good news is this garbage is easy to block, preferably with a firewall, or by turning off the Messenger service. Still, how much bandwidth is being wasted on this garbage.
I like that name PortPuker. I've made utilities with cool names in the past, my favorite is when I write data import utilities and call them DataSuckers. 
KJP [text was edited by author 2003-09-16 08:32:47] |
  Link Logger Premium,MVM join:2001-03-29 Calgary, AB
·Shaw
| There is no handshaking required in UDP traffic, which is one reason why UDP traffic is faster then TCP traffic.
PortPeeker is basically a listener; PortPuker is the data transmitter and given it sends out 'custom' traffic we are hesitant to release it as it definitely has a black hat side (custom packet content crafter and sender for TCP/UDP/ICMP and captures the response, sound like a potential hacker test tool) that we wouldn't want to see it used by someone with less then honourable intentions.
Blake |