Hey,

I was wondering if it is possible to spoof the ip address for request a
document on an other server?

thx for
Asus

Asusbob wrote:
> Hey,
>
> I was wondering if it is possible to spoof the ip address for request a
> document on an other server?
>
> thx for
> Asus
>

Not if you want a response, you can't.

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

> Not if you want a response, you can't.
>
Can you even get to the point, where PHP is executed? I'm not that much into
TCP/IP, but I don't think so.

"Jonas Werres" <jonas@example.org> wrote in message
news:47945810$0$25370$9b4e6d93@newsspool4.arcor-online.net...
>> Not if you want a response, you can't.
>>
> Can you even get to the point,

What point?

Spoof (that is lie about) your IP address and just where is the response
going to go? Hint, it won't be *your* IP address. It would be just like
leaving a voicemail on somebodys telepone answerering service and asking
them to call you back, but lying about your own phone number. Who they gonna
ring?

> where PHP is executed?

Nothing at all to do with PHP.

--
Richard.

> 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.

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 :-)

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

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.

You cannot *set up* a session without a valid return path.

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.

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.

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.

Or possibly someone sniffing a wifi network could grab some login
details to a site..not easy, but possible, and spoof via that.

Network layer code is pretty robust: its much easier to hack using
application layer exploits.

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.

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.

OR you need to set up your own session. To do that needs bidirectional
communication with the server.

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.

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.

I.e. your government can probably do it, Possibly the top techie at an
ISP, given some fancy kit, but not anyone else.

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. This is all done by the transport layer, and
the web server has no idea what's going on.

In that 7 packets you can get several pieces of information. It will go
to the web server and be processed.

The web server doesn't reply until it gets the HTTP request - which can
be much later.

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).

> You cannot *set up* a session without a valid return path.
>

But no session is needed. Just the request to the server. 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.

> 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.

However, this isn't done until after the web server replies to the
request - which is after processing for the page has been completed.

> 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.

A correctly configured ISP will only accept IP's from its own CIDR. But
not all ISP's are properly configured.

> 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.

> 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.

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

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. There is nothing in the TCP/IP protocol which disallows it,
and the packets will be quite happily sent to the server.

> 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.

> 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.

> 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.

> 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.

> 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.


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

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. This is all done by the transport layer, and
> the web server has no idea what's going on.
>
> In that 7 packets you can get several pieces of information. It will go
> to the web server and be processed.
>
> The web server doesn't reply until it gets the HTTP request - which can
> be much later.
>
> 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).

I am missing something....What are you trying to say here?

TCP/IP from a proper stack (non microsoft) requires

Client --- Host
SYN -->
<-- SYN+ACK
ACK -->

to open a connection.

Now data can be exchanged.
Then the 7 packet rule comes into play, you must establish a "connection"
first.

This link may :

http://www.linuxsecurity.com/resourc...-security.html

[putolin]

--
Dancin in the ruins tonight
Tayo'y Mga Pinoy

Jerry Stuckle wrote:

[putolin]

> No session needed. In fact, as far as TCP/IP goes, there is no such
> thing as a session.

I think he means connection, TCP/IP is a connection orientated protocol.

Perhaps you are thinking UDP.

--
Dancin in the ruins tonight
Tayo'y Mga Pinoy

Baho Utot 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. This is all done by the transport layer, and
>> the web server has no idea what's going on.
>>
>> In that 7 packets you can get several pieces of information. It will go
>> to the web server and be processed.
>>
>> The web server doesn't reply until it gets the HTTP request - which can
>> be much later.
>>
>> 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).
>
> I am missing something....What are you trying to say here?
>
> TCP/IP from a proper stack (non microsoft) requires
>
> Client --- Host
> SYN -->
> <-- SYN+ACK
> ACK -->
>
> to open a connection.
>
> Now data can be exchanged.
> Then the 7 packet rule comes into play, you must establish a "connection"
> first.
>
> This link may :
>
> http://www.linuxsecurity.com/resourc...-security.html
>
> [putolin]
>

Wrong, as usual, Baho. The connection is an application level concept.
It is not required for a request to be sent to a web server.

Your link is completely unrelated to what I'm discussing.

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

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
>

Baho Utot wrote:
> Jerry Stuckle wrote:
>
> [putolin]
>
>> No session needed. In fact, as far as TCP/IP goes, there is no such
>> thing as a session.
>
> I think he means connection, TCP/IP is a connection orientated protocol.

A connectiuon is functionally fairly equivalent to a php session, which
is why I used the term.

>
> Perhaps you are thinking UDP.
>

I don't think he is thinking at all.

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
==================

The Natural Philosopher wrote:
> Baho Utot wrote:
>> Jerry Stuckle wrote:
>>
>> [putolin]
>>
>>> No session needed. In fact, as far as TCP/IP goes, there is no such
>>> thing as a session.
>>
>> I think he means connection, TCP/IP is a connection orientated protocol.
>
> A connectiuon is functionally fairly equivalent to a php session, which
> is why I used the term.
>

Which shows how little you understand about TCP/IP.

>>
>> Perhaps you are thinking UDP.
>>
>
> I don't think he is thinking at all.
>
>

No, it's obvious you aren't. You have shows a complete lack of
understand of the inner workings of TCP/IP - only the superficial
knowledge of the aspects you can find described on the internet.

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

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.


> 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.


> 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.




> 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.

>
> 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.

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?

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/Transmi...ntrol_Protocol



>> 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.

Hint. ChecK out SYN, ESTABLISHED, TCP WINDOW SIZE, SOURCE PORT and other
magic spells in the spellbook I pointed you at.

>
> 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.

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.



>
>> 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.
>
> 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?

Once you are unto the Internet core you route anyone's packets from
anywhere. Off your network as fast as you can..;-)

>
>> 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.

>> 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 ;-)

>

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