https://sourceforge.net/p/cch/home/Home/Recent changes to HomeenSun, 11 Sep 2011 20:18:15 -0000https://sourceforge.net/p/cch/home/Home/<pre>--- v10 +++ v11 @@ -18,7 +18,7 @@ CCH leverages this by ignoring the fact that the initial requests aren't received and responding anyway. This requires a fair amount of out-of-band -coordination between the two peers but DNS can be user to provide this. +coordination between the two peers but DNS can be used to provide this. Once those coordinated responses are received, each of the clients' firewall behaves as if their peer has just initiated a perfectly normal TCP connection. </pre>elswareSun, 11 Sep 2011 20:18:15 -0000https://sourceforge.net1a465bae519c2327e9201e97a002808c405d3575https://sourceforge.net/p/cch/home/Home/<pre>--- v9 +++ v10 @@ -1,6 +1,3 @@ -[Details] -[Blocking RST and ICMP Responses] - This utility was used as part of a presentation I made at CISCon 2011. It allows the creation of an otherwise normal TCP connection between two firewalled clients. Moreover, it offers a working example of using DNS for </pre>elswareSun, 11 Sep 2011 19:34:55 -0000https://sourceforge.net091dd53d048390c5c139ab3dfce2ef903ae274c6https://sourceforge.net/p/cch/home/Home/<pre>--- v8 +++ v9 @@ -1,29 +1,30 @@ - +[Details] +[Blocking RST and ICMP Responses] + This utility was used as part of a presentation I made at CISCon 2011. It allows the creation of an otherwise normal TCP connection between two firewalled clients. Moreover, it offers a working example of using DNS for command and control messaging. A firewalled client is able to create a TCP connection with the outside world because the initiating packet (SYN) pokes a limited hole in the firewall protecting the client. The firewall is then expecting and will allow a response from whatever peer the client was attempting to reach (SYN/ACK). Once the client accepts that response and completes the handshake (ACK), the firewall will allow data to flow between the two hosts in either direction. The reason two firewalled clients aren't normally able to create a TCP connection is that their respective firewalls are configured to drop the other's initial requests (SYN packets). However, even though the remote peer's firewall drops the initial SYN, the local client's firewall will still accept a response (SYN/ACK) from the remote peer. CCH leverages this by ignoring the fact that the initial requests aren't received and responding anyway. This requires a fair amount of out-of-band coordination between the two peers but DNS can be user to provide this. Once those coordinated responses are received, each of the clients' firewall behaves as if their peer has just initiated a perfectly normal TCP connection. This allows, as one would expect, full communication between the two entirely firewalled clients. -[Blocking RST and ICMP Responses] </pre>elswareSun, 11 Sep 2011 19:33:14 -0000https://sourceforge.net92d5b641a01342e3a239d2df26db2d2c31e36685https://sourceforge.net/p/cch/home/Home/<pre>--- v7 +++ v8 @@ -1,28 +1,29 @@ - This utility was used as part of a presentation I made at CISCon 2011. It allows the creation of an otherwise normal TCP connection between two firewalled clients. Moreover, it offers a working example of using DNS for command and control messaging. A firewalled client is able to create a TCP connection with the outside world because the initiating packet (SYN) pokes a limited hole in the firewall protecting the client. The firewall is then expecting and will allow a response from whatever peer the client was attempting to reach (SYN/ACK). Once the client accepts that response and completes the handshake (ACK), the firewall will allow data to flow between the two hosts in either direction. The reason two firewalled clients aren't normally able to create a TCP connection is that their respective firewalls are configured to drop the other's initial requests (SYN packets). However, even though the remote peer's firewall drops the initial SYN, the local client's firewall will still accept a response (SYN/ACK) from the remote peer. CCH leverages this by ignoring the fact that the initial requests aren't received and responding anyway. This requires a fair amount of out-of-band coordination between the two peers but DNS can be user to provide this. Once those coordinated responses are received, each of the clients' firewall behaves as if their peer has just initiated a perfectly normal TCP connection. This allows, as one would expect, full communication between the two entirely firewalled clients. + +[Blocking RST and ICMP Responses] </pre>elswareSun, 11 Sep 2011 19:32:10 -0000https://sourceforge.netecad7a9ea68e120f20323c583d65ca566ffcf1d4https://sourceforge.net/p/cch/home/Home/<pre>--- v6 +++ v7 @@ -1,4 +1,4 @@ -[Home] [Details] + This utility was used as part of a presentation I made at CISCon 2011. It allows the creation of an otherwise normal TCP connection between two </pre>elswareSun, 11 Sep 2011 19:26:45 -0000https://sourceforge.neta87a54d4d4a7e7a5dacca7e8d4bac0393fbcc113https://sourceforge.net/p/cch/home/Home/<pre></pre>elswareSun, 11 Sep 2011 19:26:31 -0000https://sourceforge.net285830bbfb3af1d01d9bc37e7b1e7ee27a7afcdehttps://sourceforge.net/p/cch/home/Home/<pre></pre>elswareSun, 11 Sep 2011 19:26:15 -0000https://sourceforge.net59911346adaacfbff422d6a1b3affc824032611fhttps://sourceforge.net/p/cch/home/Home/<pre>--- v3 +++ v4 @@ -1,3 +1,5 @@ +[Home] [Details] + This utility was used as part of a presentation I made at CISCon 2011. It allows the creation of an otherwise normal TCP connection between two firewalled clients. Moreover, it offers a working example of using DNS for </pre>elswareSun, 11 Sep 2011 19:26:01 -0000https://sourceforge.net22bedaf65503dc4903cb7007fa77a239d6cb15b4https://sourceforge.net/p/cch/home/Home/<pre>--- v2 +++ v3 @@ -1,1 +1,26 @@ -Rules are meant to be broken! +This utility was used as part of a presentation I made at CISCon 2011. It +allows the creation of an otherwise normal TCP connection between two +firewalled clients. Moreover, it offers a working example of using DNS for +command and control messaging. + +A firewalled client is able to create a TCP connection with the outside world +because the initiating packet (SYN) pokes a limited hole in the firewall +protecting the client. The firewall is then expecting and will allow a +response from whatever peer the client was attempting to reach (SYN/ACK). +Once the client accepts that response and completes the handshake (ACK), the +firewall will allow data to flow between the two hosts in either direction. + +The reason two firewalled clients aren't normally able to create a TCP +connection is that their respective firewalls are configured to drop the +other's initial requests (SYN packets). However, even though the remote peer's +firewall drops the initial SYN, the local client's firewall will still accept +a response (SYN/ACK) from the remote peer. + +CCH leverages this by ignoring the fact that the initial requests aren't +received and responding anyway. This requires a fair amount of out-of-band +coordination between the two peers but DNS can be user to provide this. + +Once those coordinated responses are received, each of the clients' firewall +behaves as if their peer has just initiated a perfectly normal TCP connection. +This allows, as one would expect, full communication between the two entirely +firewalled clients. </pre>elswareSun, 11 Sep 2011 19:09:31 -0000https://sourceforge.net629570b6d3d1f215344fda1131d217f52b3a1f2ahttps://sourceforge.net/p/cch/home/Home/<pre>--- v1 +++ v2 @@ -1,5 +1,1 @@ -Welcome to your wiki! - -This is the default page, edit it as you see fit. To add a page simply reference it within brackets, e.g.: [SamplePage]. - -The wiki uses [Markdown](/p/cch/home/markdown_syntax/) syntax. +Rules are meant to be broken! </pre>elswareMon, 22 Aug 2011 19:57:32 -0000https://sourceforge.net21f82abcbe5db98e9d495d5cfa35f723fd8784f1