Re: spoofing ip as broadcast

GW_at_deytriedtokillDADDYBWWwahhhh.com
Date: 12/13/03 

Date: 13 Dec 2003 22:58:16 +0100

In article <S4BPVCAX37968.0090162037@Gilgamesh-frog.org>,
Frog <FrogRemailer@bigfoot.com> aka <GW@deytriedtokillDADDYBWWwahhhh.com>
wrote:

Thanks to Walter and others very much for the detailed explaination.
Please excuse my relative ignorance about all of this, I'm trying to learn
as I go. I'm going to have to hit the books and study a little to understand
all of this. For everything I learn about computers, I am reminded of 5 different
things I am ignorant about. :-(

Walter observes:--- 

---
Those sound like questions associated with my earlier answer about
spoofs, not about my most recent answer about all the packets. ;-)
---
Yeah, if you knew what I had to go through for free, "anon" email, you'd 
laugh. :-) It's a wonder I'm able to answer at all.
---
A subnet broadcast is sent out to the MAC address ff:ff:ff:ff:ff:ff
and the broadcast IP address associated with your subnet. For example,
if you are at 4.11.9.12 subnet mask 255.255.255.240 then your broadcast IP
would be 4.11.9.15 so the broadcasts would have 4.11.9.15 in the IP
address. All hosts on the local segment will receive the packet, but
only hosts in the same subnet will pay attention to the packet; everything
else will discard it.
A global broadcast is sent out to the MAC address ff:ff:ff:ff:ff:ff
like subnet broadcasts, but it is addressed to IP address 255.255.255.255.
All hosts on the local segment will receive the packet and pay attention
to it [provided, of course, that the protocol / port combination is one
they have an active service for.]
The difference between the two comes when you have multiple subnets
sharing the same local segment. In the example above, a host
4.11.9.26 subnet mask 255.255.255.240 would not be in the same subnet
as 4.11.9.12/255.255.255.240 so 4.11.9.26 would just ignore broadcasts
addressed to 4.11.9.15, but 4.11.9.26 would not ignorre broadcasts
addressed to 255.255.255.255 [if both were on the same segment.]
Are we *there* yet??
---
Gee, duh, lemme see. I think I'm starting to get it, but I'll get back to you
on that one. :-) See below, may be combining things here, sorry.
---
Walter expains:
As far out as practical that you can arrange, you should filter packets
addressed to your broadcast IP. Your software firewall is only handling
your one host, so if there are any other hosts in the same subnet,
packets are still going to get through to them. Ideally you want to
get to the router responsible for your subnet and have it block the
packets; in the example I gave a moment ago, if 4.9.11.15 was the
broadcast IP, then at the router responsible for splitting up
4.9.11/24 you would want to block packets addressed to the "host" IP
address 4.9.11.15 .
If you only have a single internal IP that you have control over,
such as if you are on DSL or cable with PPPoE, then it does not
matter too much where you do the blocking -- in such a case you
are not -propagating- a smurf attack, and if you are the -target-
of a smurf attack, your ISP is already sending the packets to you
anyhow. A hardware firewall might take some load off your machine
if your machine is overloaded (e.g., trying to draw those
System Shock frames as fast as possible ;-) )  but if you have
the system capacity then it doesn't matter much, other than it
being a generally bad idea to trust MS security more than you have to.
-- 
Ok, but I don't have a hardware firewall right YET. I prob. should get one.
I notice I get IGMP and ICMP packets at frequent regular intervals, at every
move I make. These appear to be coming from the ISP router and IPs in the subnet
(by subnet, I surmise you're talking about the group of
IPs my local dialup is assigned to) The IGMPs, checking a sniffer are "Host
Membership Query"(ies). The ICMPs that they occur regularily with are Echos
Incoming. I also regularily get port 135 queries (these are share scanners,
right?; mine's disabled) Are some of these the broadcast packets you're speaking
of?
Unfortunately, I just haven't found time to install Linux yet :-(. I've tried
to arrange the fw rules in order of the percentage of nonsense packets I receive
per rule and this seems to help, so as to discard most of the junk immediately.
Several have said that a software firewall doesn't cut it, that you must have
a NAT or some hardware fw. I guess I better learn networking better before
I buy one. I'm speaking here of one machine, I do not have a network. Am I
correct in thinking a hardware fw
would be superior in that the packets never get to my various programs and
OS so the principal box doesn't have to process them?
BTW, how do you generate your varied cool sig. quotes. Is this a function of
your email provider, or some separate program?

Relevant Pages

  • Re: spoofing ip as broadcast
    ... A subnet broadcast is sent out to the MAC address ff:ff:ff:ff:ff:ff ... only hosts in the same subnet will pay attention to the packet; ... As far out as practical that you can arrange, you should filter packets ...
    (comp.security.misc)
  • Re: Unable to reach hosts outside my subnet after initial install
    ... with any hosts beyond the local subnet. ... the current situation is that I can ping hosts on the 128.32.157.* ... packets transmitted, 0 packets received, 100.0% packet loss ...
    (freebsd-questions)
  • Unable to reach hosts outside my subnet after initial install
    ... with any hosts beyond the local subnet. ... the current situation is that I can ping hosts on the 128.32.157.* ... packets transmitted, 0 packets received, 100.0% packet loss ...
    (freebsd-questions)
  • Re: spoofing ip as broadcast
    ... What's the diff tween a global broadcast and local broadcast? ... and the broadcast IP address associated with your subnet. ... only hosts in the same subnet will pay attention to the packet; ... All hosts on the local segment will receive the packet and pay attention ...
    (comp.security.misc)
  • Re: UDP broadcast and NAT
    ... A broadcast is directed to all hosts on the same subnet, ... the target of a broadcast can never be on the remote side of a NAT ...
    (comp.security.firewalls)
Loading