IP Spoofing

am 20.01.2008 22:47:34 von Asusbob

Hey,

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

thx for help
Asus

Re: IP Spoofing

am 21.01.2008 00:04:51 von Jerry Stuckle

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

Re: IP Spoofing

am 21.01.2008 09:30:08 von Jonas Werres

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

Re: IP Spoofing

am 21.01.2008 09:48:17 von rf

"Jonas Werres" 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.

Re: IP Spoofing

am 21.01.2008 19:04:45 von Jonas Werres

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

Re: IP Spoofing

am 21.01.2008 20:35:35 von Jerry Stuckle

Re: IP Spoofing

am 21.01.2008 23:36:28 von Courtney

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.

Re: IP Spoofing

am 21.01.2008 23:54:30 von Courtney

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.

Re: IP Spoofing

am 21.01.2008 23:56:45 von Jerry Stuckle

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

Re: IP Spoofing

am 22.01.2008 00:20:39 von Jerry Stuckle

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

Re: IP Spoofing

am 22.01.2008 01:52:34 von Baho Utot

Re: IP Spoofing

am 22.01.2008 01:58:57 von Baho Utot

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

Re: IP Spoofing

am 22.01.2008 03:50:37 von Jerry Stuckle

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 help:
>
> http://www.linuxsecurity.com/resource_files/documentation/tc pip-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
==================

Re: IP Spoofing

am 22.01.2008 04:03:13 von Courtney

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
>

Re: IP Spoofing

am 22.01.2008 04:04:22 von Courtney

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.

Re: IP Spoofing

am 22.01.2008 04:11:42 von Jerry Stuckle

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

Re: IP Spoofing

am 22.01.2008 04:13:36 von Jerry Stuckle

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

Re: IP Spoofing

am 22.01.2008 04:32:47 von Courtney

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

>

Re: IP Spoofing

am 22.01.2008 04:44:37 von Jerry Stuckle

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.

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

Re: IP Spoofing

am 22.01.2008 09:27:57 von Jonas Werres

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

I am quite optimistic that you can find everything needed to solve this
problem on the the internet ;)

Re: IP Spoofing

am 22.01.2008 09:47:01 von Willem Bogaerts

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

Stupid question maybe, but can such a signal be sent anyway or does it
require some part of the question it answers to? If it can be sent
anyway and be recognized as valid, you would still be able to send data
and have the returns sent to the wrong destination.

As you have guessed, I did not study the TCP/IP protocol.

Regards,
--
Willem Bogaerts

Application smith
Kratz B.V.
http://www.kratz.nl/

Re: IP Spoofing

am 22.01.2008 13:25:16 von Courtney

Re: IP Spoofing

am 22.01.2008 13:27:56 von Courtney

Jerry Stuckle wrote:
> 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.
>
Right. Its official, Jerry has more knowledge than is contained in the
whole Internet.

Next time he tells you to 'google it yourself' you know he is lying.
Only he knows the answer.

Jerry is short for Jesus Christ Incarnate.;-)

Re: IP Spoofing

am 22.01.2008 13:31:37 von Courtney

Jerry Stuckle wrote:
> 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.
>

Oh dear. No jerry, its a lot more than I have SAID, its not a lot more
than I THINK, but it is a LOT more than you KNOW.

The code for the tpcp layers is open source. Why not educate yourself.

I leave you with one final thought.
eel could fling established packets with spoofed source addresses all
round the place and get servers to act on them, how come the Internet
isn't brought crashing to its knees every day by someone doing just that?

Re: IP Spoofing

am 22.01.2008 13:35:01 von Courtney

Jerry Stuckle wrote:

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

The RFC's are public domain Jerry. You know they are.. Or perhaps you
don't know what an RFC is?

The truth is available to anyone who cares to look for it. Its all on
the internet.

I know you don't like me showing you up, but that is really your problem.

Re: IP Spoofing

am 22.01.2008 14:10:34 von Willem Bogaerts

>>> 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.
>>
>> Stupid question maybe, but can such a signal be sent anyway or does it
>> require some part of the question it answers to? If it can be sent
>> anyway and be recognized as valid, you would still be able to send data
>> and have the returns sent to the wrong destination.
>>
>> As you have guessed, I did not study the TCP/IP protocol.
>>
>
> If you send a SYN packet - a a request to open, it will be answered.
>
> If you send an ESTABLISHED packet, if its not part of a recognized
> established session it will be junked. Unless its some new TCP/IP
> software that is more full of bugs than Jerries head..

What I mean is, could you send a stream of packages (even if a lot of
them are junked), such that some of them will always respond to the
server? I don't know how many possibilities or how much time this would
take, but I am just trying to see if the anonymous injection attack
mentioned earlier could work.

Instead of:
> Client --- Host
> SYN -->
> <-- SYN+ACK
> ACK -->
Would it be possible to do:
Client --- Host
SYN -->
(pause)
ACK -->
Inother words, a "brute force ACKing"?

Just curious,
--
Willem Bogaerts

Application smith
Kratz B.V.
http://www.kratz.nl/

Re: IP Spoofing

am 22.01.2008 14:28:05 von Jerry Stuckle

Willem Bogaerts wrote:
>> 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.
>
> Stupid question maybe, but can such a signal be sent anyway or does it
> require some part of the question it answers to? If it can be sent
> anyway and be recognized as valid, you would still be able to send data
> and have the returns sent to the wrong destination.
>
> As you have guessed, I did not study the TCP/IP protocol.
>
> Regards,

With the correct hacker tools, it can be done. It's not easy, but it
could be useful in certain circumstances.

It's not being done because it's of limited use. If you can't get any
data back, it doesn't do a lot of good.

But also, fortunately, it's beyond the ability of most hackers. It
takes an intimate knowledge of the TCP/IP protocol and the weaknesses in
it (and yes, there are some). And it requires the ability to exploit
those weaknesses. You won't be able to do it with the TCP/IP stack in
most systems; you'll have to build your own packets. That requires a
fair amount of code.

So yes, it can be done. But it's difficult, and there are much easier
ways to get the job done, i.e. anonymous proxies, bot nets, etc.

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

Re: IP Spoofing

am 22.01.2008 14:29:11 von Jerry Stuckle

Re: IP Spoofing

am 22.01.2008 20:00:33 von Tim Streater

In article <1200972764.6582.0@proxy00.news.clara.net>,
The Natural Philosopher wrote:

> Jerry Stuckle wrote:

[snip]

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

We do transit for our customers. We discard packets which have a source
address which isn't registered to the customer or one of *its* customers.

Re: IP Spoofing

am 22.01.2008 20:09:08 von Tim Streater

In article ,
Jerry Stuckle wrote:

> The Natural Philosopher wrote:
[snip]

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

Errm, no, typical core routers don't do that. They route packets.

Re: IP Spoofing

am 22.01.2008 20:21:55 von Jerry Stuckle

Tim Streater wrote:
> In article ,
> Jerry Stuckle wrote:
>
>> The Natural Philosopher wrote:
> [snip]
>
>>> 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.
>
> Errm, no, typical core routers don't do that. They route packets.
>

It depends on the routers. Some ISP's nowadays also cache commonly
requested pages.

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

Re: IP Spoofing

am 22.01.2008 20:22:19 von Jerry Stuckle

Tim Streater wrote:
> In article <1200972764.6582.0@proxy00.news.clara.net>,
> The Natural Philosopher wrote:
>
>> Jerry Stuckle wrote:
>
> [snip]
>
>>> 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?
>
> We do transit for our customers. We discard packets which have a source
> address which isn't registered to the customer or one of *its* customers.
>

Then you're a good ISP :-)

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

Re: IP Spoofing

am 22.01.2008 20:33:31 von Tim Streater

In article ,
Jerry Stuckle wrote:

> Tim Streater wrote:
> > In article ,
> > Jerry Stuckle wrote:
> >
> >> The Natural Philosopher wrote:
> > [snip]
> >
> >>> 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.
> >
> > Errm, no, typical core routers don't do that. They route packets.
> >
>
> It depends on the routers. Some ISP's nowadays also cache commonly
> requested pages.

They may well do, but I doubt the routers do it. We use Juniper M160 and
T640 routers with plenty of 10Gbps interfaces (actually we are in the
process or replacing all the M160). Such routers have no facilities for
doing layer 3 stuff, as far as I know. I've not heard of the Cisco
equivalents doing it either.

Re: IP Spoofing

am 22.01.2008 21:27:22 von Courtney

Re: IP Spoofing

am 22.01.2008 22:53:05 von Baho Utot

Jerry Stuckle wrote:

> 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 help:
>>
>>
http://www.linuxsecurity.com/resource_files/documentation/tc pip-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.
>

Me thinks you don't understand that the web port 80 _IS_ a TCP/IP
connection.
The web server will not see any datagram until TCP/IP has finished its
handshaking connection, only then will the server see the data.

Any way just what is it you were dicussing?

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

Re: IP Spoofing

am 22.01.2008 23:30:09 von Baho Utot

Jerry Stuckle wrote:

[putolin]

>>
>> Indeed. But the server will disregard them.
>>
>
> Actually, no. The server will respond.

No, the TCP/IP stack will drop the connection

Quoting RFC 793

Connections:

The reliability and flow control mechanisms described above require
that TCPs initialize and maintain certain status information for
each data stream. The combination of this information, including
sockets, sequence numbers, and window sizes, is called a connection.
Each connection is uniquely specified by a pair of sockets
identifying its two sides.

When two processes wish to communicate, their TCP's must first
establish a connection (initialize the status information on each
side). When their communication is complete, the connection is
terminated or closed to free the resources for other uses.

Since connections must be established between unreliable hosts and
over the unreliable internet communication system, a handshake
mechanism with clock-based sequence numbers is used to avoid
erroneous initialization of connections.

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

That right, the socket (port 80) will never see the data until the
connection is established.

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

The socket doesn't but the TCP/IP stack does.

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

You need to know the ISN of the datagram to hijack a connection, you will
need to watch out for SYN+ACK RST and will have to "swamp the host" to
hijack.

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

Did it work?

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

You only control one end of the connection, The TCP/IP stack on the other
will drop the connection.

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

Or UDP

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

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

Correct. Connection hijacking exploits desynchronized state in TCP. You
will need to desynchronize the host until they (hosts) will discard
datagrams from each other, then you can inject your modified datagrams. It
could be done at the handshake or in the middle of an established
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.
>

Why the firewall will toss the traffic

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

Huh. Me thinks there are very few "servers" on the backbone.
Inside your own network well..... whatever you want.

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

Grab a Cisco manual, a few RFCs and a copy of Wireshark.

Go ahead I'll wait :)

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

I agree that it is difficult, you need a modified TCP/IP stack + "tools".
A lot of free time also helps.

If your talking snooping then that is easy, All one needs is Wireshark.

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

Re: IP Spoofing

am 23.01.2008 00:01:44 von Baho Utot

Willem Bogaerts wrote:

[putolin]

> What I mean is, could you send a stream of packages (even if a lot of
> them are junked), such that some of them will always respond to the
> server? I don't know how many possibilities or how much time this would
> take, but I am just trying to see if the anonymous injection attack
> mentioned earlier could work.
>
> Instead of:
>> Client --- Host
>> SYN -->
>> <-- SYN+ACK
>> ACK -->
> Would it be possible to do:
> Client --- Host
> SYN -->
> (pause)
> ACK -->
> Inother words, a "brute force ACKing"?
>
> Just curious,

There is a "state machine" for every connection.
For a detailed description on the state machine refer to RFC 793.
TCP connections are in the CLOSED state (the default).
TCP connections require the SYN+ACK from the "other end".
You have 75 seconds to complete the TCP handshake , otherwise the "opening
connection" is tossed.

Your ACK would simply be tossed on the receiving side.

If you send a batch of SYN packets in less than 75 seconds the "TCP state
machine" for the host may become "full" and it will ignore any more SYN
attempts. Your classic denial-of-service attack.

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

Re: IP Spoofing

am 23.01.2008 01:14:14 von Jerry Stuckle

Tim Streater wrote:
> In article ,
> Jerry Stuckle wrote:
>
>> Tim Streater wrote:
>>> In article ,
>>> Jerry Stuckle wrote:
>>>
>>>> The Natural Philosopher wrote:
>>> [snip]
>>>
>>>>> 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.
>>> Errm, no, typical core routers don't do that. They route packets.
>>>
>> It depends on the routers. Some ISP's nowadays also cache commonly
>> requested pages.
>
> They may well do, but I doubt the routers do it. We use Juniper M160 and
> T640 routers with plenty of 10Gbps interfaces (actually we are in the
> process or replacing all the M160). Such routers have no facilities for
> doing layer 3 stuff, as far as I know. I've not heard of the Cisco
> equivalents doing it either.
>

Yep, some of them do. It all depends on the router.

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

Re: IP Spoofing

am 23.01.2008 01:21:47 von Jerry Stuckle

Willem Bogaerts wrote:
>>>> 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.
>>> Stupid question maybe, but can such a signal be sent anyway or does it
>>> require some part of the question it answers to? If it can be sent
>>> anyway and be recognized as valid, you would still be able to send data
>>> and have the returns sent to the wrong destination.
>>>
>>> As you have guessed, I did not study the TCP/IP protocol.
>>>
>> If you send a SYN packet - a a request to open, it will be answered.
>>
>> If you send an ESTABLISHED packet, if its not part of a recognized
>> established session it will be junked. Unless its some new TCP/IP
>> software that is more full of bugs than Jerries head..
>
> What I mean is, could you send a stream of packages (even if a lot of
> them are junked), such that some of them will always respond to the
> server? I don't know how many possibilities or how much time this would
> take, but I am just trying to see if the anonymous injection attack
> mentioned earlier could work.
>
> Instead of:
>> Client --- Host
>> SYN -->
>> <-- SYN+ACK
>> ACK -->
> Would it be possible to do:
> Client --- Host
> SYN -->
> (pause)
> ACK -->
> Inother words, a "brute force ACKing"?
>
> Just curious,

Willem,

One thing I should also add. You'll find a few people here who think
they can read a couple of RFC's or Wikipedia and be experts in TCP/IP.

I agree the RFC's indicate how something *should* operate. But hackers
operate outside the bounds of normal protocols, and take advantage of
hole in the protocol.

These guys have no *real* idea what they're talking about, and no
knowledge of how to exploit the holes in the protocols. But they
continue to refer you to Wikipedia and RFC's to prove their case.

The problem is - they prove nothing. But they're too stoopid to
understand that.

There *are* numerous holes in the TCP/IP architecture. You found one of
them - it is quite easy to spoof a connection as you indicated. But
there are other, much more efficient ways to do so, also.

I'm not going to get into them here because 1) it's off-topic for a php
newsgroup, and 2) I'm not going to give these idiots clues on how they
can hack other peoples' systems.

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

Re: IP Spoofing

am 23.01.2008 11:11:37 von Courtney

Baho Utot wrote:
> Willem Bogaerts wrote:
>
> [putolin]
>
>> What I mean is, could you send a stream of packages (even if a lot of
>> them are junked), such that some of them will always respond to the
>> server? I don't know how many possibilities or how much time this would
>> take, but I am just trying to see if the anonymous injection attack
>> mentioned earlier could work.
>>
>> Instead of:
>>> Client --- Host
>>> SYN -->
>>> <-- SYN+ACK
>>> ACK -->
>> Would it be possible to do:
>> Client --- Host
>> SYN -->
>> (pause)
>> ACK -->
>> Inother words, a "brute force ACKing"?
>>
>> Just curious,
>
> There is a "state machine" for every connection.
> For a detailed description on the state machine refer to RFC 793.
> TCP connections are in the CLOSED state (the default).
> TCP connections require the SYN+ACK from the "other end".
> You have 75 seconds to complete the TCP handshake , otherwise the "opening
> connection" is tossed.
>
> Your ACK would simply be tossed on the receiving side.
>
> If you send a batch of SYN packets in less than 75 seconds the "TCP state
> machine" for the host may become "full" and it will ignore any more SYN
> attempts. Your classic denial-of-service attack.
>
Its no use quonting facts at Jerry.

Like god, he is right, by *definition*. ;-)

Re: IP Spoofing

am 23.01.2008 11:19:32 von Courtney

Jerry Stuckle wrote:
> Willem Bogaerts wrote:
>>>>> 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.
>>>> Stupid question maybe, but can such a signal be sent anyway or does it
>>>> require some part of the question it answers to? If it can be sent
>>>> anyway and be recognized as valid, you would still be able to send data
>>>> and have the returns sent to the wrong destination.
>>>>
>>>> As you have guessed, I did not study the TCP/IP protocol.
>>>>
>>> If you send a SYN packet - a a request to open, it will be answered.
>>>
>>> If you send an ESTABLISHED packet, if its not part of a recognized
>>> established session it will be junked. Unless its some new TCP/IP
>>> software that is more full of bugs than Jerries head..
>>
>> What I mean is, could you send a stream of packages (even if a lot of
>> them are junked), such that some of them will always respond to the
>> server? I don't know how many possibilities or how much time this would
>> take, but I am just trying to see if the anonymous injection attack
>> mentioned earlier could work.
>>
>> Instead of:
>>> Client --- Host
>>> SYN -->
>>> <-- SYN+ACK
>>> ACK -->
>> Would it be possible to do:
>> Client --- Host
>> SYN -->
>> (pause)
>> ACK -->
>> Inother words, a "brute force ACKing"?
>>
>> Just curious,
>
> Willem,
>
> One thing I should also add. You'll find a few people here who think
> they can read a couple of RFC's or Wikipedia and be experts in TCP/IP.
>

Some people spent years implementing TCP/IP systems on international
networks, and even giving tedious training course in basic and advanced
security. Some people spent weeks attending Interop and studying RFCS
and packet sniffers to work out why early TCP implementations didn't
work with each other

Some people had a company that actually employed security specialists,
with Phds in cryptography, and listened to what they said.

Some people had to debug early TCP/IP code.

Not claim they wrote a couple of lines of code from a crib manual for IBM.

Some people have remembered why they sold it all,and retired early, so
they could code for fun and not have to deal with arrogant arseholes
who are more interested in showing off to nerdy geeks than in getting
their work done.

Who DO you work for Jerry?

> I agree the RFC's indicate how something *should* operate. But hackers
> operate outside the bounds of normal protocols, and take advantage of
> hole in the protocol.
>
> These guys have no *real* idea what they're talking about, and no
> knowledge of how to exploit the holes in the protocols. But they
> continue to refer you to Wikipedia and RFC's to prove their case.
>
> The problem is - they prove nothing. But they're too stoopid to
> understand that.
>
> There *are* numerous holes in the TCP/IP architecture. You found one of
> them - it is quite easy to spoof a connection as you indicated. But
> there are other, much more efficient ways to do so, also.
>
> I'm not going to get into them here because 1) it's off-topic for a php
> newsgroup, and 2) I'm not going to give these idiots clues on how they
> can hack other peoples' systems.
>

Re: IP Spoofing

am 24.01.2008 02:49:15 von Baho Utot

Jerry Stuckle wrote:

>
> One thing I should also add. You'll find a few people here who think
> they can read a couple of RFC's or Wikipedia and be experts in TCP/IP.

I see, May we have the knowledge of what your qualifications are?

> I agree the RFC's indicate how something *should* operate.

The RFCs in comment here are Standards......... or as others have said

RFCs are the last word on Internet standards, and can be found at the IETF's
Web site (http://www.ietf.org)

> But hackers
> operate outside the bounds of normal protocols, and take advantage of
> hole in the protocol.

I prefer this definition:

Many programmers have been labeled "great hackers,"[12] but the specifics of
who that label applies to is a matter of opinion. Certainly major
contributors to computer science such as Edsger Dijkstra and Donald Knuth,
as well as the inventors of popular software such as Linus Torvalds
(Linux), and Dennis Ritchie and Ken Thompson (the C programming language)
are likely to be included in any such list; see also List of programmers.
People primarily known for their contributions to the consciousness of the
academic hacker culture include Richard Stallman, the founder of the free
software movement and the GNU project, president of the Free Software
Foundation and author of the famous Emacs text editor as well as the GNU
Compiler Collection (GCC), and Eric S. Raymond, one of the founders of the
Open Source Initiative and writer of the famous text The Cathedral and the
Bazaar and many other essays, maintainer of the Jargon File (which was
previously maintained by Guy L. Steele, Jr.).
Within the academic hacker culture, the term hacker is also used for a
programmer who reaches a goal by employing a series of modifications to
extend existing code or resources. In this sense, it can have a negative
connotation of using kludges to accomplish programming tasks that are ugly,
inelegant, and inefficient. This derogatory form of the noun "hack" is even
used among users of the positive sense of "hacker" (some argue that it
should not be, due to this negative meaning; others argue that some kludges
can, for all their ugliness and imperfection, still have "hack value"). In
a very universal sense, a hacker also means someone who makes things work
beyond perceived limits in a clever way in general, for example reality
hackers.[13]

http://linuxreviews.org/dictionary/Hacker/

> These guys have no *real* idea what they're talking about, and no
> knowledge of how to exploit the holes in the protocols.

You don't know that nor can you prove that.

> But they
> continue to refer you to Wikipedia and RFC's to prove their case.
>

What!!!!!!!!

THE RFCs aren't real....

DAMN..... now's a fine time to inform me of that fact.

A little bit of reference material never hurt anyone has it?

Besides I don't have a case to prove.

> The problem is - they prove nothing. But they're too stoopid to
> understand that.

Lets see we have RFCS (PROTOCOL SPECIFICATION) and Wikipedia that may have
been written by networking experts verses what you have said without any
truth, let alone any reference material.

RFC791 - Internet Protocol
Description: 0791 Internet Protocol. J. Postel. Sep-01-1981. (Format:
TXT=97779 bytes) (Obsoletes RFC0760) (Updated by RFC2474) (Also STD0005)
(Status: STANDARD)
Filter list: ftp|*|*|rfc791*
Section maint.: Erwin Lemmers
Timestamp: 2003-09-15 22:03 UTC

RFC793 - Transmission Control Protocol

Description: 0793 Transmission Control Protocol. J. Postel. Sep-01-1981.
(Format: TXT=177957 bytes) (Also STD0007) (Status: STANDARD)
Filter list: ftp|*|*|rfc793*
Section maint.: Erwin Lemmers
Timestamp: 2003-09-15 22:03 UTC

Oh LOOK two standards

Want to guess which one I will believe?

Want to tell me how my TCP/IP stack differs from the RFCs mister expert?

>
> There *are* numerous holes in the TCP/IP architecture. You found one of
> them - it is quite easy to spoof a connection as you indicated. But
> there are other, much more efficient ways to do so, also.
>
> I'm not going to get into them here because 1) it's off-topic for a php
> newsgroup, and

OK it's now off topic? I thought it was off topic here from the beginning,
was I too stupid to know that?

> 2) I'm not going to give these idiots clues on how they
> can hack other peoples' systems.
>

Psst no one tell them about Google, 2600 or CULT OF THE DEAD COW ...Oops too
late.

Anyway who said anything about intrusions into others computers?
Hijacking a TCP/IP connection is not an intrusion.... Not ethical but
certainly not an intrusion.

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

Re: IP Spoofing

am 24.01.2008 02:54:55 von Baho Utot

The Natural Philosopher wrote:

[putolin]

>>
> Its no use quonting facts at Jerry.
>
> Like god, he is right, by *definition*. ;-)

But I don't believe in any God :)

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

Re: IP Spoofing

am 24.01.2008 05:13:39 von Jerry Stuckle

Baho Utot wrote:
> Jerry Stuckle wrote:
>
>> One thing I should also add. You'll find a few people here who think
>> they can read a couple of RFC's or Wikipedia and be experts in TCP/IP.
>
> I see, May we have the knowledge of what your qualifications are?
>

Over 40 years of programming, over 20 of that in TCP/IP. Including
working on the internals of the protocol.

>> I agree the RFC's indicate how something *should* operate.
>
> The RFCs in comment here are Standards......... or as others have said
>

Sure. But that does NOT mean there are not holes in the protocol which
can be used by hackers.

> RFCs are the last word on Internet standards, and can be found at the IETF's
> Web site (http://www.ietf.org)
>
>> But hackers
>> operate outside the bounds of normal protocols, and take advantage of
>> hole in the protocol.
>
> I prefer this definition:
>
> Many programmers have been labeled "great hackers,"[12] but the specifics of
> who that label applies to is a matter of opinion. Certainly major
> contributors to computer science such as Edsger Dijkstra and Donald Knuth,
> as well as the inventors of popular software such as Linus Torvalds
> (Linux), and Dennis Ritchie and Ken Thompson (the C programming language)
> are likely to be included in any such list; see also List of programmers.
> People primarily known for their contributions to the consciousness of the
> academic hacker culture include Richard Stallman, the founder of the free
> software movement and the GNU project, president of the Free Software
> Foundation and author of the famous Emacs text editor as well as the GNU
> Compiler Collection (GCC), and Eric S. Raymond, one of the founders of the
> Open Source Initiative and writer of the famous text The Cathedral and the
> Bazaar and many other essays, maintainer of the Jargon File (which was
> previously maintained by Guy L. Steele, Jr.).
> Within the academic hacker culture, the term hacker is also used for a
> programmer who reaches a goal by employing a series of modifications to
> extend existing code or resources. In this sense, it can have a negative
> connotation of using kludges to accomplish programming tasks that are ugly,
> inelegant, and inefficient. This derogatory form of the noun "hack" is even
> used among users of the positive sense of "hacker" (some argue that it
> should not be, due to this negative meaning; others argue that some kludges
> can, for all their ugliness and imperfection, still have "hack value"). In
> a very universal sense, a hacker also means someone who makes things work
> beyond perceived limits in a clever way in general, for example reality
> hackers.[13]
>
> http://linuxreviews.org/dictionary/Hacker/
>

Use whatever definition you want. I really don't care.

>> These guys have no *real* idea what they're talking about, and no
>> knowledge of how to exploit the holes in the protocols.
>
> You don't know that nor can you prove that.
>

You've already proven that, Baho, by your lack of understanding. You
think RFC's are the only thing going. Sorry, Charlie. They show how
things *should work* - but don't go into what *can* be done by a hacker.

>> But they
>> continue to refer you to Wikipedia and RFC's to prove their case.
>>
>
> What!!!!!!!!
>
> THE RFCs aren't real....
>

I never said the RFC's aren't real. Don't put words in my mouth.

> DAMN..... now's a fine time to inform me of that fact.
>
> A little bit of reference material never hurt anyone has it?
>

I am not going to teach you how to hack TCP/IP.

> Besides I don't have a case to prove.
>

I really don't give a damn. I have nothing to prove.

>> The problem is - they prove nothing. But they're too stoopid to
>> understand that.
>
> Lets see we have RFCS (PROTOCOL SPECIFICATION) and Wikipedia that may have
> been written by networking experts verses what you have said without any
> truth, let alone any reference material.
>
> RFC791 - Internet Protocol
> Description: 0791 Internet Protocol. J. Postel. Sep-01-1981. (Format:
> TXT=97779 bytes) (Obsoletes RFC0760) (Updated by RFC2474) (Also STD0005)
> (Status: STANDARD)
> Filter list: ftp|*|*|rfc791*
> Section maint.: Erwin Lemmers
> Timestamp: 2003-09-15 22:03 UTC
>
> RFC793 - Transmission Control Protocol
>
> Description: 0793 Transmission Control Protocol. J. Postel. Sep-01-1981.
> (Format: TXT=177957 bytes) (Also STD0007) (Status: STANDARD)
> Filter list: ftp|*|*|rfc793*
> Section maint.: Erwin Lemmers
> Timestamp: 2003-09-15 22:03 UTC
>
> Oh LOOK two standards
>
> Want to guess which one I will believe?
>

Go ahead. Keep quoting the RFC's. It continues to show how little you
understand what *can* be done.

> Want to tell me how my TCP/IP stack differs from the RFCs mister expert?
>

I never said it did.

>> There *are* numerous holes in the TCP/IP architecture. You found one of
>> them - it is quite easy to spoof a connection as you indicated. But
>> there are other, much more efficient ways to do so, also.
>>
>> I'm not going to get into them here because 1) it's off-topic for a php
>> newsgroup, and
>
> OK it's now off topic? I thought it was off topic here from the beginning,
> was I too stupid to know that?
>

It always has been off-topic for this newsgroup.

>> 2) I'm not going to give these idiots clues on how they
>> can hack other peoples' systems.
>>
>
> Psst no one tell them about Google, 2600 or CULT OF THE DEAD COW ...Oops too
> late.
>
> Anyway who said anything about intrusions into others computers?
> Hijacking a TCP/IP connection is not an intrusion.... Not ethical but
> certainly not an intrusion.
>

How little you really understand.

But it's obvious - you're only arguing to argue. You're another I guess
I'm just going to have to *plonk* you again - like I did in a.w.w. You
were no more intelligent there, and we're glad you're gone.

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

Re: IP Spoofing

am 24.01.2008 22:22:39 von Baho Utot

Jerry Stuckle wrote:

> Baho Utot wrote:
>> Jerry Stuckle wrote:

[putolin]

>> I see, May we have the knowledge of what your qualifications are?
>>
>
> Over 40 years of programming, over 20 of that in TCP/IP. Including
> working on the internals of the protocol.

Oh then you know Jon Postel. Any way I don't believe you have that
experience. Sorry Jerry.

I could tell you of my experience but it is not relevant as I don't have an
ego to satisfy.

>
>>> I agree the RFC's indicate how something *should* operate.
>>
>> The RFCs in comment here are Standards......... or as others have said
>>
>
> Sure. But that does NOT mean there are not holes in the protocol which
> can be used by hackers.

Yes there are holes that can be exploited, but not as easily as you think.

[putolin]

>
>>> These guys have no *real* idea what they're talking about, and no
>>> knowledge of how to exploit the holes in the protocols.
>>
>> You don't know that nor can you prove that.
>>
>
> You've already proven that, Baho, by your lack of understanding. You
> think RFC's are the only thing going. Sorry, Charlie. They show how
> things *should work* - but don't go into what *can* be done by a hacker.
>

What don't I understand, you keep saying that but it don't make it true.
Want to tell me what I have for dinner?

>>> But they
>>> continue to refer you to Wikipedia and RFC's to prove their case.
>>>
>>
>> What!!!!!!!!
>>
>> THE RFCs aren't real....
>>
>
> I never said the RFC's aren't real. Don't put words in my mouth.

I am not...You imply they are not to be followed or of no value.

[putolin]

>
>> Besides I don't have a case to prove.
>>
>
> I really don't give a damn. I have nothing to prove.

OK

>
>>> The problem is - they prove nothing. But they're too stoopid to
>>> understand that.
>>

[putolin]

>
> Go ahead. Keep quoting the RFC's. It continues to show how little you
> understand what *can* be done.

I know what can be done, I don't live under a rock.

[putolin]

> How little you really understand.

I understand more than you give credit

>
> But it's obvious - you're only arguing to argue.

How so?

I posted facts and information, you posted.... well nothing but your rants.

> You're another I guess I'm just going to have to *plonk* you again - like
I did in a.w.w.

Thank you!

> You were no more intelligent there, and we're glad you're gone.
>

What do you have a mouse in your pocket?

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