Prev: Pictures conversion with ImageMagick
Next: inconsistent HTTP download speeds on a LAN
From: Nowitzki Rados on 23 Apr 2008 09:52
Hello, I need to filter packets that are comming from certain server (IP
address/port number). Server sends packets to my client program, but some of
those packets cause client to crash (those packets are generated by other
server users because of hole in chat program). So I tried to configure
iptables
to search data section of tcp packets comming from that IP address
and if it finds "unwanted pattern that crash client", it should drop
packets. I managed to do that, but it seems like it was bad solution.
Problem is that when packet from server is dropped by iptables, my client
application stop working properly (I think it stops comunication with server
because of packet loss, but I am not sure). I read that when iptables drop
packet it does not notify sender about it. Does that means that sender
continue to send same packet over and over again? (and because there is no
response from client side they stop to communicate).
If that is true is there any way to drop packet and to tell server to send
next one? Altough I can see another problem there because if that happens
client side would have wrong sequence number for next packet? Anyone have
idea how could I solve this problem?
I also thought about changing tcp packet data. Is there any way to do
something like this:
-when packet arives, program (or iptables) search pattern in its data
-if pattern is found, program (or iptables, but i doubt it has that feature)
change data in tcp packet, so that "unwanted pattern that cause buffer
overflow" is removed from it.
-changed packet is forwarded to client like nothing happened

I think this would solve my problem, but I know that I would have to write
this program myself, and it probably means some driver level programming. Is
it possible to do something like this? Any links where I can read more about
it?

If anyone have solution to this problem (with iptables, or on by any other
means), or can give me any useful info on subject, I would be very
thankfull.
Thanks!

p.s. sorry for my bad English, it is not my main language.


From: Rick Jones on 23 Apr 2008 14:45
Nowitzki Rados <Nowitzki.Rados(a)gmail.com> wrote:
> Hello, I need to filter packets that are comming from certain server
> (IP address/port number). Server sends packets to my client program,
> but some of those packets cause client to crash (those packets are
> generated by other server users because of hole in chat program). So
> I tried to configure iptables to search data section of tcp packets
> comming from that IP address and if it finds "unwanted pattern that
> crash client", it should drop packets. I managed to do that, but it
> seems like it was bad solution. Problem is that when packet from
> server is dropped by iptables, my client application stop working
> properly (I think it stops comunication with server because of
> packet loss, but I am not sure). I read that when iptables drop
> packet it does not notify sender about it. Does that means that
> sender continue to send same packet over and over again? (and
> because there is no response from client side they stop to
> communicate).

Yes. Assuming this chat stuff runs over a protocol such as TCP, TCP
will continue to retransmit the segments which remain unACKed by the
receiving TCP until it either receives an ACK from the
remote/receiving TCP or it hits its retransmission limits and aborts
the connection.

> If that is true is there any way to drop packet and to tell server
> to send next one?

No. TCP is all about doing its level best to get all the data sent to
the other side, in the order in which it was sent.

> Altough I can see another problem there because if that happens
> client side would have wrong sequence number for next packet? Anyone
> have idea how could I solve this problem?

Fix the source of bad data, or detect and deal with it in the
receiving application.

> I also thought about changing tcp packet data. Is there any way to
> do something like this:
> -when packet arives, program (or iptables) search pattern in its
> data
> -if pattern is found, program (or iptables, but i doubt it has that
> feature) change data in tcp packet, so that "unwanted pattern that
> cause buffer overflow" is removed from it.
> -changed packet is forwarded to client like nothing happened

> I think this would solve my problem,

No, it would kludge around your problem, a solution would elimitate
the root cause. That would be eliminating the bug in the sending
application, and also eliminating the bug in the client.

rick jones
--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Nowitzki Rados on 23 Apr 2008 20:13
> No, it would kludge around your problem, a solution would elimitate
> the root cause. That would be eliminating the bug in the sending
> application, and also eliminating the bug in the client.
>
> rick jones


I agree with you, but problem is that client is flash aplication in browser,
and it seems that overflow happens inside flash player itself.
Server side is not patchable because people who made it are not answering to
mails sent to them. Bugs are known for more than year
and it seems that they do not care. So it is on us (users) to do whatever we
can to avoid this client side crashing.
I would really like to have server code so I could eliminate bugs, but there
is no chance for it.
Anyway, thank you very much for answering on my questions.

Best regards


From: Rick Jones on 23 Apr 2008 21:20
Nowitzki Rados <Nowitzki.Rados(a)gmail.com> wrote:
> > No, it would kludge around your problem, a solution would elimitate
> > the root cause. That would be eliminating the bug in the sending
> > application, and also eliminating the bug in the client.
> >
> > rick jones


> I agree with you, but problem is that client is flash aplication in
> browser, and it seems that overflow happens inside flash player
> itself.

Is the flash player not supported or something? Is there no newer
version of the flash player if this is a bug known for a year?

> Server side is not patchable because people who made it are not
> answering to mails sent to them. Bugs are known for more than year
> and it seems that they do not care.

Time to find another server?

> So it is on us (users) to do whatever we can to avoid this client
> side crashing.
> I would really like to have server code so I could eliminate bugs,
> but there is no chance for it.

Papering over stuff like this is only going to mushroom.

rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Pascal Hambourg on 24 Apr 2008 10:41
Hello,

Nowitzki Rados a �crit :
> Hello, I need to filter packets that are comming from certain server (IP
> address/port number). Server sends packets to my client program, but some of
> those packets cause client to crash (those packets are generated by other
> server users because of hole in chat program). So I tried to configure
> iptables to search data section of tcp packets comming from that IP address
> and if it finds "unwanted pattern that crash client", it should drop
> packets. I managed to do that, but it seems like it was bad solution.

As Rick said, a better solution would be to patch/fix/update the client
or stop using that service.

> Problem is that when packet from server is dropped by iptables, my client
> application stop working properly (I think it stops comunication with server
> because of packet loss, but I am not sure). I read that when iptables drop
> packet it does not notify sender about it.

The REJECT target can notify the sender with various ICMP error types or
a TCP reset. TCP reset would close the connexion, not sure about ICMP
error types.

> Does that means that sender
> continue to send same packet over and over again? (and because there is no
> response from client side they stop to communicate).

Yes, TCP segments need to be acknowledged by the receiver.

> If that is true is there any way to drop packet and to tell server to send
> next one? Altough I can see another problem there because if that happens
> client side would have wrong sequence number for next packet? Anyone have
> idea how could I solve this problem?
> I also thought about changing tcp packet data. Is there any way to do
> something like this:
> -when packet arives, program (or iptables) search pattern in its data
> -if pattern is found, program (or iptables, but i doubt it has that feature)
> change data in tcp packet, so that "unwanted pattern that cause buffer
> overflow" is removed from it.
> -changed packet is forwarded to client like nothing happened

I guess this could be done with the QUEUE target in iptables, which
queues packets to userland. I cannot tell more about this. However there
is no guaranty that the whole pattern is contained in a single segment,
it could be split across two segments.

A better solution would be to use a proxy which would do the filtering
(matching and mangling) in the data stream at application level rather
than with iptables.
 | 
Pages: 1
Prev: Pictures conversion with ImageMagick
Next: inconsistent HTTP download speeds on a LAN