|
|
Posted by The Natural Philosopher on 01/22/08 03:03
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.
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.
>> 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.
>> 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?
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.
Don't confuse it with pure IP..which has none of the above, and is
merely the underlying packet routing mechanism.
>> 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.
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.
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.
>> 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.
Before you open your mouth, do your homework next time.
>
>> 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
>
Navigation:
[Reply to this message]
|