Re: Post connection SYN

[Ravi Kumar <ravivsn () roc co in>]

Hi Raghuveer,
        I am giving pictorial diagram of the problem you are
       describing. Then I try to give my solution to the problem

       TCPClient----------Firewall------------TCPServer

          ----------------------SYN ---------------------->
           <----------------SYN+ACK------------------
         --------------------- ACK---------------------->
                   Data transfer
         TCPClient machine rebooted abnormally.
          -----------------------SYN with same Source Port)--------->

         There was already firewall session with this TCP information.
         Now the question is what to do with the new SYN packet?
         If you silently drop, TCP Client takes minutes before deciding that
            connection could not go through.
         So, it is better to send RST back to the client.

         Think of the case where you don't have Firewall - or - you have
          proxy firewalls. I guess RST will be sent.  So, your firewall 
sending
          RST for SYN packet would be fine.

          It might look that it can become an attack if MITM frames SYN 
packet.
          I would not worry about that. What should it take MITM to frame 
RST packet
          and send it to the client? It might take same amount of time or 
even lesser time
          to frame RST packet.

         Having said that, it is better to have configuration which most 
of firewalls have.
         It is called stealth mode. In non- stealth mode, RST packet can 
be sent for 'Post connection
        SYN'. In stealth mode, RST packet should not be generated.

 Regards
 Ravi


At 02:13 PM 10/17/03 +0530, Raghuveer wrote:
> Hi,
> I would like to know how SPI-firewall/IDS would handle the following
> scenario.
>
> Setup:
> A server, Public-Server1, is hosted behind a firewall/IDS capable of
> detecting post-connection SYN attack. A remote PC in the Internet,
> Remote-Client2, connects to Public-Server1 on TCP port 80 (and source port
> TCP1024).
>
> Details:
> Upon establishment of connection, Remote-Client2 gets rebooted without a
> normal shutdown and then starts a fresh connection to Public-Server1. This
> time it so happens that the new connection is generated with the same
> selector information (Src IP, DstIp, SPrt, Dprt & protocol). This
> connection request (SYNC) would be treated by the firewall device as post
> connection SYN attack and might drop the connection request. The client is
> not aware of this and keeps trying until the request times out.
> There are certain protocols that might work on fixed source & destination
> ports. In such cases, the chances of firewall/IDS detecting the connection
> request as post connection SYN could be quite high.
> How can SPI-firewalls/IDS in general handle such genuine scenarios at the
> same time avoid potential attacks?
>
> - B. Raghuveer.
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () honor icsalabs com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards


----------
<http://www.roc.co.in/>ROCs Ambassador product: iSecure
 iSecure is comprehensive security appliance with stateful inspection 
Firewall and IPSEC/IKE based VPN. Firewall supports several ALGs, 
cyber-defense engine and powerful session lookup engine. VPN is based on 
latest IPSEC and IKE RFCs and supports preshared key and RSA/DSA 
certificate authentication.
The Views Presented in this mail are completely mine. The company is not 
responsible for what so ever.

----------
Ravi Kumar CH
Rendezvous On Chip (I) Pvt Ltd
Hyderabad, INDIA

<http://www.roc.co.in/>ROC HOME PAGE:
http://www.roc.co.in


_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards