generated from cotes2020/chirpy-starter
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #54 from harshityadav95/TCP-Tunneling
Create 2023-08-03-TCP-Tunneling.md
- Loading branch information
Showing
1 changed file
with
82 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,82 @@ | ||
| --- | ||
| title: TCP Tunnerling | ||
| author: harshityadav95 | ||
| date: 2023-08-03 00:00:00 +0530 | ||
| categories: [Backend Engineering] | ||
| tags: [Backend Development, Networking] | ||
|
|
||
| --- | ||
|
|
||
| {% include embed/youtube.html id='iR4jLbG9KXw' %} | ||
|
|
||
| - Tunneling is the process of converting protocol A to protocol B usually protocol one of the protocols is blocked or unavailable | ||
|
|
||
| ### TCP Connection | ||
|
|
||
|  | ||
|
|
||
|
|
||
| - Client C1 wants to connect to System S1, IP address with an open port on 22 | ||
| - To establish a bi-directional connection | ||
| - We add the frames to data with info on source, client, port of receiver, and port from the receiver and send it to the client and server processes the request and sends back the data response in the similar format | ||
|
|
||
| ### TCP Tunneling | ||
|
|
||
| - We want to reach the destination that is blocked from the client, it can be blocked by a firewall or internal network | ||
| - we can establish a standard tcp connection on port 22 , but instead of sending the data we send another TCP packet inside the data | ||
|
|
||
|  | ||
|
|
||
|
|
||
| - If we send the data its completely legitimate but inside the data we are sending another request that no one else can see since the data itself is another data packet with encryption, so the firewall allows this packet to smuggle another packet to go through | ||
|
|
||
|  | ||
|
|
||
|
|
||
| - The S2 has no idea the packet is coming from S1 and for it receiving as it is coming from C1 | ||
|
|
||
|  | ||
|
|
||
|
|
||
| - The identity of S1 remains unknown, when the response is received the data response is smuggled again and the packet is sent over | ||
|
|
||
|  | ||
|
|
||
|
|
||
| - The Client received the data response as intended as if it was receiving the repsonse from S2 | ||
| - There are a lot of TCP connections going | ||
|
|
||
| ## Applications | ||
|
|
||
| - By bypassing the firewall on blocked ports, firewall can see the TCP port and cannot see the data and the port number being smuggled into the pocket | ||
|  | ||
|
|
||
|
|
||
| - Solution Local port forwarding tunnel | ||
|
|
||
|  | ||
|
|
||
|
|
||
| - Internal IP problem: local IP cannot be accessed from outside the network | ||
|
|
||
|  | ||
|
|
||
|
|
||
| - Solution: Reverse Port Forwarding Tunnel | ||
|
|
||
|  | ||
|
|
||
|
|
||
| - Blocked Website | ||
|
|
||
|  | ||
|
|
||
|
|
||
| - SOCKS proxy (dynamic port) tunneling, we create a proxy on a machine and make all the requests coming from our machine go through that proxy (Used by Fiddler for HTTP proxy debugging) all our traffic goes through the proxy and captures it | ||
| - We make a request to Server 1 and [localhost](http://localhost) 8080 to smuggle the requests , all the traffic goes through it (similar to VPN) , ISP is not aware of it | ||
|
|
||
|  | ||
|
|
||
|
|
||
| ## Pros and Cons | ||
|  |