|
|
Posted by Jerry Stuckle on 01/22/08 03:44
The Natural Philosopher wrote:
> Jerry Stuckle wrote:
>> The Natural Philosopher wrote:
>>> Jonas Werres wrote:
>>>>> Nothing at all to do with PHP.
>>>>
>>>> I think you did not understand what I wrote.
>>>>
>>>> The OP asked if one can spoof the IP address while requesting a
>>>> document.
>>>> Jerry says (correctly) that it would not be possible to get the
>>>> answer. That might imply that is IS possible to make a request, but
>>>> the answer goes nowhere. That would be enough if the purpose of the
>>>> request was e.g. to delete a database by SQL injection. The answer
>>>> is unimportant.
>>>>
>>>> What I said was that I think it is not even possible to make a
>>>> request (regardless where the answer would go), because that would
>>>> require a connection which cannot be established with a spoofed IP.
>>>
>>>
>>> A request implies an open TCP connection, which implies that a
>>> session has been set up.
>>>
>>
>> Not the way TCP/IP works. You can send up to 7 packets before an ACK
>> is required by the sender.
>
> Not on connection open you cant. and its not 7 either.
>
> It can be actually as big a chunk of data AFTER you have opened the
> session as allowed in the session TCP window.
>
Oh dear. You really need to learn how things go under the covers. You
have no real idea.
>
>> This is all done by the transport layer, and the web server has no
>> idea what's going on.
>>
> Quite. And if its not done right the web server will never see it
> either. The transport layer will simply discard it.
>
Oh dear. You really should learn what you're talking about before
opening you mouth.
>
>> In that 7 packets you can get several pieces of information. It will
>> go to the web server and be processed.
>>
>
> No, it won't. It won't go anywhere at all unless it is recognized as
> part of an established TCP/IP connection. To do that is a lot more than
> just having the right destination address and a spoofed source address.
> It needs to correspond to an established source port number and be in
> the sequence of packet number associated with that stream ID.
>
>
Wrong again. For a legitimate connection this is true. But a spoofed
IP isn't a legitimate connection, is it?
>
>
>> The web server doesn't reply until it gets the HTTP request - which
>> can be much later.
>
> Indeed. So how come it has just 'recieved those 7 packets of data and
> processed them'
>
> Even in the context of your own words, you are contradicting yourself.
>
Not at all. I am contradicting nothing - other than your misunderstanding.
>>
>> If the web server's TCP/IP doesn't get the packet, obviously the ACK
>> won't be returned. So after a timeout period, the sender's TCP/IP
>> resends it (if, instead, the ACK got lost on the return, it is the web
>> server's TCP/IP which sorts it out).
>>
>
> Oh dear.
>>> You cannot *set up* a session without a valid return path.
>>>
>>
>> But no session is needed. Just the request to the server.
>
> That comes over a valid TCP IP CONNECTION, or SESSION.
>
Sorry. Wrong.
> In fact, as
>> far as TCP/IP goes, there is no such thing as a "session". Each
>> packet is sent independently, and successive packets may very well
>> take different routes.
>>
>
> What has that got to do with there being an established connection?I.e.
> session?
>
I'm using your terminology. So maybe you can understand. But obviously
it's lost on you.
> Jerry. Listen up sweetie pie, Just go here and educate yourself so you
> don't look quite such a dork next time.
>
> http://en.wikipedia.org/wiki/Transmission_Control_Protocol
>
Listen up, sweetie pie. Any time you have to quote wikipedia as a
reference, it's obvious you have no idea at all what's going on.
Learn how it really works, not what some wikipedia article say. That
way you won't BE such a dork next time.
>
>
>>> That is, you would never get as far as being able to send a request
>>> to a server, since that must be done over and establsihed session.
>>>
>>
>> Nope. The server gets the request and tries to reply. Now obviously
>> the server's TCP/IP probably won't get an ACK from the reply because
>> the message went to a bogus IP address, but eventually after retrying
>> the web server's TCP/IP will return a timeout to the web server.
>
> Jerry,. don't open your mouth any wider than is necessary to put both
> feet in.
>
Like you do? Oh, I forgot. You can't stick your feet in your mouth.
Your head is too far up your ass.
> Hint. ChecK out SYN, ESTABLISHED, TCP WINDOW SIZE, SOURCE PORT and other
> magic spells in the spellbook I pointed you at.
>
Hint - check out the real internals of tcp/ip. Not some wikipedia
article.
>>
>> However, this isn't done until after the web server replies to the
>> request - which is after processing for the page has been completed.
>
> No, it will neverr get that far.
>
Bullshit.
> If its a SYN packet, a request to OPEN a TCP connection, the server will
> return it to where it thinks it came from. But thats all. If its marked
> ESTABLISHED, uneless therE IS an established session - i.e. an ongoing
> TCP/IP conversation with the server from the spoofed address, it will be
> discarded as out of sequence, and/or unknown. The key here is that every
> time the bowser opens a TP connection, it uses a random port. That port,
> and that source addrss, together form a unique ID as far as the server
> is concerned. Every packet in that connection is numbered. To get to the
> WEB server, you have to guess the right port, the right IP address and
> the right sequence number of a conversation that is HAPPENING ALREADY.
> And since the HTTP protocol closes the comnectiuon after EACH request,
> you have a pretty damn narrow time window to do this in.
>
Try again, dork.
>
>
>>
>>> IP spoofing as far as I can think, can only be utilised if one has
>>> admin level access to routing. Typically if uou are on the same
>>> NETWORK as the address you are spoofing, or in control of a router
>>> between it and its target.
>>>
>>> i.e. if you sit at an ISP, and stuff in a piece of kit on someone
>>> elses IP address, and do clever things with a core router, you MIGHT
>>> be able to patch a route to that address into the ISPs routers.
>>>
>>
>> You don't have to be at an ISP to do it. You could actually do it on
>> your own system, with the right tools and know-how. All you need is
>> an ISP which will accept packets with an illegal address.
>
>
> Oh, if all you want to do is throw noise into the system, sure. No one
> checks *source* addresses anyway as far as routing goes. No pint, since
> the rest of the protocols make it a fairly pointless thing to spoof them.
Keep trying to evade the question, dork.
>>
>> A correctly configured ISP will only accept IP's from its own CIDR.
>> But not all ISP's are properly configured.
>
> Total crap. What about packets coming from across the far side of the
> world and using them as transit?
>
Yep, your updates are total crap. As usual.
> Once you are unto the Internet core you route anyone's packets from
> anywhere. Off your network as fast as you can..;-)
>
Again, you have no idea what you're talking about. You've read a third-
graders introduction to TCP/IP and think you're an expert on it - like
you think you're an expert on everything.
>>
>>> I don't actually know if this has ever happened outside of e.g. a
>>> large campus network where security was pretty lax. It would be an
>>> instant firing if an ISP admin did that.
>>>
>>
>> Yes, it has. You don't hear about it very often because it's of very
>> limited use on the web.
>>
>>> Or possibly someone sniffing a wifi network could grab some login
>>> details to a site..not easy, but possible, and spoof via that.
>>>
>>
>> That's also possible, especially if the wifi network is using no
>> encryption (even WEP is very poor security). Again, anyone with the
>> correct tools can watch each packet going over the network; if it's
>> not encrypted, everything can be read.
>>
>
> Sure,. Thats Wifi for you. But that LAN rather than WAN issues.
>
You brought it up, not me. But then you're good at trying to deflect
attention when you don't have a valid argument.
>>> Network layer code is pretty robust: its much easier to hack using
>>> application layer exploits.
>>>
>>>
>>
>> It's robust, but that doesn't mean it can't be fooled.
>
> Not as easily as you seem to think some readers here can be, anyway ;-)
>
>>
>
I thought you were going to plonk me. I really wish you would. Because
I'm not going to respond to any more of your crap.
Get your head out of your ass, understand how the protocol really works
- and I'm not talking about some third-grade text from wikipedia - and
you can understand what I'm saying.
But you've already proven you aren't capable of that. Many times.
So long, dork.
<plonk>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|