Packets will never get back to the originating host if the source ip is
spoofed. Using a proxy / wingate is the only way around this.
All other spoofing attacks other than DoS (like a SYN attack which you
aren't expecting a response to) are 'blind' attacks.
This is where TCP sequence numbering (and psuedo-random number
generators) become important in system security, otherwise it becomes too
easy to create 'phantom' connections to a remote host, or exploit trust
relationships through IP filtering mechanisms.
Unless the software on the remote host is pulling a return IP out of the
packet body, (which the software on the source side is inserting),
you won't get a response to a spoofed packet. There
is nowhere inside the generic TCP / IP packet headers for extra return
host information.
In other words, you can do anything in software (and trojans / bots /
malware could be cleverly coded to bounce packets all over the show) - but
no mechinism exists within TCP / IP itself.
-jonny
On Tue, 11 Sep 2001, Nathan Boettcher wrote:
> Okay, I see the point isn't getting across. I am looking at the event that
> someone is spoofing or redirecting through a proxy and the information IS
> going back to the source. I am thinking in terms of scanning, not
> attacking or using it for a DOS or anything. I know that's the primary use
> of it. One person replied and said that spoofing was taking the origional
> and throwing it in with a bunch of others but that's not always the case.
> Take Nmap for example. It amy be a not-so-general example, but we'll use
> it anyway. Every time you use a decoy ip it will show up as that specific
> ip. It won't change each time as if someone were throwing it in a group of
> ips. So, there has to be a way for information to travel back to the
> originating host. Where is that info and how does one get it? That's the
> question to be answered. My GUESS, and that's why I am asking you all, is
> that it's contained somewhere in the packets. But I don't know exactly how
> all packets are constructed(even ones constructed by hand) but I do know
> there has to be some way for the info to get back to the originating host.
>
> A proxy may be completely different in the sense that it might be using a
> table or something in which case a traceroute might actually work, so lets
> just stick to spoofing.
>
> -Nathan
>
>
> -------
> > It is quite easy to put a packet out with the wrong
> > IP information. With a bit more access to the Ethernet
> > driver, it is quite easy to put an arbitrary hardware
> > source address. Putting this into a forceful DOS attack
> > is described in a number of places.
> >
> > Packets are no harder to forge than business cards.
> -------
> > Actually, there is no practical way to trace those packets. A spoofed =
> > attack
> > generally doesn=92t care about return packets; it=92s primarily a blind =
> > attack.
> > It=92s usually a denial-of-service (DOS) attack intended to bring down =
> > a site.
> > The attacker isn=92t looking for =93legal (that is, the normal =
> > packet-then-ack
> > traffic)=94 traffic. They=92re simply interested in killing a =
> > resource/site.
>
> > Theoretically, if the attack was continuing, one could talk to each =
> > carrier,
> > who might be able to tell where it=92s coming from, but that=92s =
> > certainly not
> > feasible in real life.
> -------
> Nathan Boettcher
> swighost@xxxxxxxx
>
> "Windows: A 32-bit patch to a 16-bit graphical interface based on an 8-bit
> operating system origionally encoded for a 4-bit processor written by a
> 2-bit company that can't stand 1-bit of competition."
>
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>