[lug] using tcpdump to emulate effects of packet dump

D. Stimits stimits at comcast.net
Thu Jul 17 22:03:28 MDT 2003


George Sexton wrote:

> You cannot do what you want.
>
> Calling CreateMailSlot() just gives you a file handle that you can 
> then use
> with ReadFile(). You get no information about the source of the data. By
> convention applications can write their source host name, and user 
> name but
> it is totally worthless.
>
It seems like this is not necessarily a problem, as I can block all UDP 
1026 (from a windows app running on windows) that is not specifically 
from a known source.

>
>
> >>both 2k and 98.
>
>
> One practical bit of advice, is that on NT a read for 0 bytes will 
> block if
> there is no data. In Win98, a 0 byte read will not block.
>
> Filtering port 1026 for Windows machines would not randomly break DNS,
> because the port is already bound to the messenger service and could 
> not be
> used to send out DNS requests.

Not on the windows machine...but it will break it on linux. The machines 
being talked about are either straight windows, or multi-boot 
windows/linux. Cutting all traffic on the bridge to port 1026 is not 
suitable, nor is cutting it via destination IP or MAC address (the 
bridge does not know whether the destination is booted to linux or to 
windows).

I can use a snort-style system to scan inbound port 1026 on the bridge 
(linux), and block if it finds the popup initial data (sort of like a 
virus scanner), but then I'm the only one that can use it...my goal is 
to write something that makes it trivial to destroy www.byebyeads.com 
and popup vulnerability spam in general. By writing a web page that 
tells me I can do nothing about it, and by telling me that no laws apply 
because they are using a vulnerability instead of a email, I am 
extremely irritated and not willing to turn the other cheek. The 
discussions on how to stop it and how to emulate the packet dump as a 
test tool are aimed at reverse engineering their exploit from linux and 
then writing a windows-based tool that nullifies their disgusting 
tactics for every windows user. I have the data due to snort and 
tcpdump, now I need create my own popup spam tool and write something to 
defeat it.

D. Stimits, stimits AT comcast DOT net

>
> -----Original Message-----
> From: lug-admin at lug.boulder.co.us [mailto:lug-admin at lug.boulder.co.us]On
> Behalf Of D. Stimits
> Sent: Thursday, July 17, 2003 8:10 PM
> To: lug at lug.boulder.co.us
> Subject: Re: [lug] using tcpdump to emulate effects of packet dump
>
>
> George Sexton wrote:
>
>
> >FWIW, the general technology that you would have to use to write a
> >filter to
> >block them would be to to start a service that opens that mailslot
> >(\\.\mailslot\messngr) and listens for incoming data, and then filter the
> >data, displaying alerts you want to see.
> >
> >For general information on Mailslots, search the MSDN on 
> CreateMailSlot().
> >
> >In general, it's a lot easier to just not run the messenger service.
> >Running
> >this service on a machine that is directly connected to the internet is
> >probably a bad idea anyhow.
> >
>
>
> I want to limit the popup to have it work only if the popup does not
> arrive on a particular interface. I want it to continue working on the
> serial port, and any network card that is deemed to allow it. An
> interface-by-interface yes/no allow/deny.
>
> FYI, this machine has a Linux filtering bridge on it, stopping the
> usually garbage that comes in below port 1024. It isn't acceptable to
> ban port 1026 udp as this would break a lot of applications, including
> (randomly) host lookups, as the lowest open udp port is often the
> recipient of dns replies.
>
> The CreateMailSlot() sounds like the right starting spot. Being able to
> detect what interface the popup is coming from would be the next task,
> and linking them together on a configurable menu to allow or deny. One
> of the bigger problems is that I'll have to write it for both 2k and 98.
>
> D. Stimits, stimits AT comcast DOT net
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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
>





More information about the LUG mailing list