Posted by Jerry Stuckle on 01/22/08 03:11

The Natural Philosopher wrote:
> Jerry Stuckle wrote:
>> The Natural Philosopher wrote:
>>> Jerry Stuckle 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.
>>>>>
>>>>
>>>> Actually, you probably could send out a request from a faked IP
>>>> address with the correct hacker tools. But it would have to be
>>>> short (everything would have to fit in 7 packets). But it would
>>>> depend on an ISP which would accept the spoofed IP address.
>>>> Correctly configured, they shouldn't. But we also know how
>>>> *everyone* has *everything* correctly configured, don't we :-)
>>>>
>>> You would not need to keep it in 7 packets, merely to send in a TCP
>>> window - pretty large these days, BUT you would also need to cut in
>>> on an existing ESTABLISHED session.
>>>
>>> If we are talking HTTP, there is no such thing really. Every call to
>>> a URL is a` NEW TCP session. Every request is a new session, which
>>> is closed once the data has been dleivred and an ACK recived from the
>>> far end.
>>>
>>> So whilst the TCP session is stateful, the HTTP is not.
>>>
>>> In essence a URL call, be it a form full of data or whatever goes
>>> like this
>>>
>>> 1/. browserIP:random_port->server:80 OPEN TCP SESSION
>>> 2/. Server:80-->browserIP:random_port ACK + TCP +SESSION STUFF
>>> 3/. browserIP:random_port ACK DATA ESTABLISHED SESSION STUFF
>>> 4/. Server:80-->browserIP ACK CLOSE SESSION.
>>>
>>
>> Ah, but your first step is incorrect.
>>
>> The standard tools open a session. But that's at the application
>> layer. From the TCP/IP end, there is no need to do so. With the
>> correct hacker tools, it is quite possible to send packets to the
>> server without anything.
>
> Indeed. But the server will disregard them.
>

Actually, no. The server will respond.

>
> There is nothing in the TCP/IP protocol which disallows it,
>> and the packets will be quite happily sent to the server.
>>
>
> wher they will be dropped.
>

Sorry, they will be accepted and acted upon. The server does not
require acknowledgment of the connection.

>>> To hijack that session you need to jump in at point 3/. and replace
>>> the packet with your own. You need to know all about the TCP session
>>> as well as the senders IP address AND current sender port number, or
>>> the packet will be discarded as not part of any TCP session the
>>> server knows about.
>>>
>>
>> No, because your point 1 is incorrect.
>>
>
> Yes,beacuse you don't understand te TCP initialisation protocol.
>

Actually, I do. I was writing TCP/IP code back in the 80's when I
worked at IBM.

>>> OR you need to set up your own session. To do that needs
>>> bidirectional communication with the server.
>>>
>>
>> No session needed. In fact, as far as TCP/IP goes, there is no such
>> thing as a session.
>>
>
> Oh dear. You don't know very much do you?
>

Obviously a lot more than you do.

> TCP/IP is a Guaranteed connection protocol. It has a session that
> establishes each end point, an number associated with that session, a
> packet number inside that session, and various flags to say whether the
> packet is a new session request, and etablished session, and ack for a
> recieved packet and LOADS more stuff.
>

At the application layer, yes, it is. However, with hacker tools you
can burrow down below that level and get the server to perform using
spoofed IP addresses.

You really don't know much, do you?

>
> Don't confuse it with pure IP..which has none of the above, and is
> merely the underlying packet routing mechanism.
>

I'm not.

>>> People claim that firewalls that only allow connection from a given
>>> IP address are not secure (enough). That IP addresses can be spoofed.
>>> So they can, but I have never heard of it being done in practice in
>>> the real world, other than in a particular artificial environment.
>>> Certainly NOT by Andy Hacker masturbating in his bedroom with a copy
>>> of Linux for Geeks on the floor.
>>>
>>
>> Yes, unfortunately, it has been done in real world. But the effects
>> are rather limited. One of the things it was used for before bot nets
>> was DDOS attacks on a server.
>>
>
> thats IP attack, not TCP/IP attack.
>

This attack is effective because it gets the server to respond to all of
these messages. It doesn't just overload the network connection; it
overloads the server.

So if you say this is only an IP attack, and the sever will not respond,
please explain the effectiveness of this attack.

> We wer talking in te context of actuallky causing a server to execute
> code via an HTTP connection. Its somply not possible with IP spoofing
> UNLESS yuou can latch into an establsihed TCP/IP connection.
>

Exactly. That's why this attack can be successful. Otherwise, one
machine could not overload a server.

> HINT: Look at your firewall and you may see 'Established' as an
> allowable thing for incoming packets. Why? because ESTABLISHED packets
> are those on a connection YOU have opened OUTWARDS, and you want
> responses to them to come back to you. No UN-ESTABLISHED packets are
> allowed in, so no one can OPEN a port on your machine.
>

Which has absolutely nothing to do with this discussion. Sorry.

>
>>> You need very high level access to core routers to be able to *see*
>>> the traffic session flow and enough ability to reconfigure core
>>> internet routers to do that. AND the sort of kit that can keep UP
>>> with the traffic flow on a router like that is basically NSA level kit.
>>>
>>
>> Not at all. Any server along the route can monitor all traffic going
>> through its servers. But because different packets can take different
>> routes, the most effective monitoring is at either end of the
>> connection. In the middle there's much less chance you will get all
>> of the packets.
>
> They are not servers Jerry, they are routers.
>

Most are also servers. They do more than just route traffic. They can
cache and server pages, for instance.

> Before you open your mouth, do your homework next time.
>

Yes, you really should.

>>
>>> I.e. your government can probably do it, Possibly the top techie at
>>> an ISP, given some fancy kit, but not anyone else.
>>>
>>>
>>>
>>
>> It doesn't take that much of a techie to do it, unfortunately.
>>
>
> I an assure you it does, if you want to operate interactively with a
> remote machine on TCP connection
>>
>

Yes, it would take a someone far beyond your capability. But not
beyond a competent sysadmin.

You really have a superficial understanding of TCP/IP and the protocol.
It's a lot more than what you think.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]