[lug] using tcpdump to emulate effects of packet dump

[D. Stimits]

jd wrote:

> On Thu, 2003-07-17 at 22:07, D. Stimits wrote:
>
> >jd wrote:
> >
> >
> >>netsend
> >>
> >>or
> >>
> >>smbclient -M
> >>
> >>this will be suffcant to spam most people....however there is a newer
> >>style that uses rpc i guess. I would just classify the traffic and then
> >>only allow it from my ups
> >>
> >>here is some fun i had with my roomate...had to edit the text for the
> >>list though.....
> >
> >smbclient is using something on I think port 135 or 137 through 139.
> >This message service has *multiple* ways in, it is not a single API.
> >Ports 135 and 137:139 are already blocked 100% to and from the outside
> >world. ZoneAlarm also deals with those ports. What I need is to clone
> >the tcpdump packet and send it to port 1026 of my local test machine and
> >see it pop up. Then start developing a tool that will neutralize it from
> >windows, and publish the tool for free. In no case has bybyeads.com been
> >hitting a port below 1024.
> >
> >I was hoping that a raw packet dump or hex readout of bytes in the UDP
> >spam packet could be sent out without writing a new tool, but apparently
> >not. I'll write a linux based simple UDP blind sender that only sends
> >this copy of their bytes on UDP to the test machine (hopefully it will
> >"do the right thing", it will be harder if a simple clone of the UDP
> >packet data is only part of reproducing it).
> >
> >D. Stimits, stimits AT comcast DOT net
>
>
>
> according to this.....
>
> http://www.mynetwatchman.com/kb/security/articles/popupspam/netsend.htm
>
> it would seem you are allowing port 135 udp.....


No, port 135, all protocols, all sources, all destinations, are 100% 
blocked at the bridge. Not one single port 135 activity is possible 
across the bridge (aptly named "charon"). What the article fails to say 
is that there are *more* than the mentioned ways of getting popups.

Consider that udp is connectionless...these guys are simply flooding, 
blindly, to 1026. I have snort and tcpdump running 24/7, and the 
addresses that are doing the spam are 100% logged for all packets, in or 
out, any protocol, any port. I can guarantee nothing 135 is *required*, 
it is only used to talk nicely to a windows box, but is not mandatory if 
you wish to blindly flood.

I also recently set up a cron job to copy a grepped log file (for udp 
traffic of particular ip's and/or ports) to a web server (not available 
to the outside world). I watch this in real time and see what goes 
on...port 135 is *not* used. NO port below 1024 is ever used. The 
article is only correct for people that use the popup protocol as MS 
said to use it...these people are bypassing 135 and directly/blindly 
flooding 1026. tcpdump, ipchains, and snort all verify this.

D. Stimits, stimits AT comcast DOT net

>
> below is a small piece of the article from the above link..
> discussing RPC popups....also goes into smb style pop ups.
>
>
> Note that the initial communication is targetted to udp/135. Subsequent
> communication is via random ephemeral (> 1024) ports... in this case
> udp/2307 and udp/5196. Since Frame 2 is generated FROM the target TO the
> initiator, this will be treated as outbound traffic by the clients
> firewall and thus will not likely be blocked. So it seems that all that
> is required for this technique to work is allowing inbound udp/135.
>
>
>
> >>.#! /usr/bin/perl -w
> >>
> >>$z = '1';
> >>while($z){
> >>open( PIPE, "|/usr/bin/smbclient -M THEBUSCUIT");
> >>print PIPE "\n";
> >>$it = ;
> >>print PIPE "SEE THIS TEXT BJ?";
> >>
> >>close(PIPE);
> >>print "IT =  $it";
> >>}
> >>
> >>
> >>hth,
> >>jd
> >
> >
> >
> >_______________________________________________
> >Web Page:  http://lug.boulder.co.us
> >Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >Join us on IRC: lug.boulder.co.us port=6667 channel=#colug