broadcast packets
Hi, I'm Marco from Italy and I'm working on a security LAN project. I have to analyze all the hosts on my ethernet relying on their broadcast packets. Already exists a tool that accomplishes this task?? Where can I find a list of broadcast packets sent by all Operating Sysyems?? Thanks, Marco Antonioli
RE: MBone (virus on sniffers.pdf file download)
gm From: Gary E. Miller [mailto:[EMAIL PROTECTED]] gm Sent: Monday, September 23, 2002 2:24 PM gm Here is a link to how it is done: gm http://dhar.homelinux.com/dhar/downloads/Sniffers.pdf gm Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gm [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 Just a note: yesterday my attempt to follow the link above from (I know, it was my stupidity) Microsoft Outlook lead to my machine being (unsuccessfully) attacked by the virus Norton calls JS.Exception.Exploit. Attempts today to download that PDF file in a more properly controlled fashion fail with the file not available. Just a note for the archives and a word of warning. Jim Davis Agilent Technologies
Re: broadcast packets
On Wed, 25 Sep 2002 10:33:52 +0200, [EMAIL PROTECTED] [EMAIL PROTECTED] said: I'm Marco from Italy and I'm working on a security LAN project. I have to analyze all the hosts on my ethernet relying on their broadcast packets. If a tree doesn't fall in the forest, what sound doesn't it make? (Think about it - if a machine doesn't drop a broadcast packet, or not enough to analyze, what do you do?) Where can I find a list of broadcast packets sent by all Operating Sysyems?? A better approach would be to ask What services use broadcast packets and then ask what systems implement that service. Also, you may want to think about the following question: How do you distinguish between a Microsoft Windows system issuing a broadcast packet on port 139, and a Linux system running Samba issuing the same packet on port 139? You might want to ask yourself exactly what you're trying to accomplish by trying to fingerprint systems based only on broadcast packets? What problem will you solve by doing this? Is this just a see if it can be done project, or are you really expecting to get a major gain from it? If so, what gain are you expecting? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09015/pgp0.pgp Description: PGP signature
Re: broadcast packets
[EMAIL PROTECTED] wrote: On Wed, 25 Sep 2002 10:33:52 +0200, [EMAIL PROTECTED] [EMAIL PROTECTED] said: I'm Marco from Italy and I'm working on a security LAN project. I have to analyze all the hosts on my ethernet relying on their broadcast packets. You might want to ask yourself exactly what you're trying to accomplish by trying to fingerprint systems based only on broadcast packets? Maybe he meant broadcast at the physical layer? I.e., he's on a hub, and he's sniffing the traffic. Marco, is that what you intend? -- /===\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centivinc.com| |Centiv|My opinions are my own. | |===| |Ea est fabula nostra, et non mutabimus eam! --House Falconguard| |and Affiliated Scum| \===/
Re: Datagram? Packet? (was : APEX)
Lloyd; At 05:44 PM 9/24/2002 +0200, TOMSON ERIC wrote: Last, while I definitely, clearly prefer calling Layer 2 data units FRAMES, I sometimes [over-]simplify the terminology of Layer 3 by making the following distinction : a datagram is the data unit before fragmentation ; a packet is a piece of a fragmented datagram. :^) A fragment of a datagram is itself a datagram; after you re-assemble them, the result is still a datagram. A datagram is self-describing; full source and destination. That's the essential property. That is, an ATM cell or an X.25 packet actually is not a datagram, because it does not have full information on source nor destination. It, instead, has full information on a VC, forwarding for which relies on rather static information stored on intermediate systems at the time of signalling. A fragment (IPv4 fragment) may not be. An IPv4 fragment, however, has full information on source and destination hosts and is a datagram, though, it does not have full information on source and destination ports, which is not an internetworking issue. Masataka Ohta
Re: Datagram? Packet? (was : APEX)
At 01:12 PM 9/25/2002 +0100, Lloyd Wood wrote: A datagram is self-describing; full source and destination. A fragment (IPv4 fragment) may not be. you sure? take a GOOD look at RFC 791... It is completely self-describing in terms of getting itself there and where it belongs in the reassembled datagram. If the other bits and pieces don't arrive, there is another matter, but it is at that point a host issue, not a forwarding issue.
Re: Datagram? Packet? (was : APEX)
Hello Lloyd, Wednesday, September 25, 2002, 2:12:13 PM, you wrote: the following distinction : a datagram is the data unit before fragmentation ; a packet is a piece of a fragmented datagram. :^) A fragment of a datagram is itself a datagram; after you re-assemble them, the result is still a datagram. Yes, I agree, though the definition has - in common habit and use - quite fuzzy contours. In theory, theory would be like pratice; but in practice, pratice isn't theory. ;) A datagram is self-describing; full source and destination. A fragment (IPv4 fragment) may not be. Don't be misled by the word fragment: in the IP case, it retains src and dst info as well. No RFC needs to be read to confirm that ;), a little thinking shows that: how could it be routed at layer 3 on an internet, otherwise? In the fragmentation process a datagram/packet may lose in its self contained unit ULP information, like TCP ports, but that's not matter of IP. .FT
