Filter or change tcp packets - Networking

This is a discussion on Filter or change tcp packets - Networking ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Filter or change tcp packets

  1. Filter or change tcp packets

    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.



  2. Re: Filter or change tcp packets

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

  3. Re: Filter or change tcp packets

    > 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



  4. Re: Filter or change tcp packets

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

  5. Re: Filter or change tcp packets

    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.

+ Reply to Thread