Evasion Tunnel Mac OS
An open source SSL tunneling proxy solution that is available on multiple operating systems and can be accessed via the macOS Terminal.app Using SSL encryption to secure the connection between a remote client and the server is highly advisable. What's new with TunnelBear for macOS? Check out release notes and version history here. See full list on evasions.checkpoint.com.
kProxy_start), a message containing data to be forwarded (kProto_data), an explicit acknowledgement of received packets (kProto_ack, a close message (kProto_close) or an authentication challenge/response (kProto_authenticate). Second, it indicates who sent the message: A message sent by the client will have the kUser_flag bit set, whereas a message sent by the proxy has the kProxy_flag bit set. This is necessary since a ping request will cause the operating system on the proxy computer to return its own echo reply, which is identical to the packet we just sent to the proxy.The ack and seq fields are tightly related. Modelled after the use of acknowledgements in TCP, the ptunnel protocol places the sequence number of the last packet received into the ack field of any outgoing message. The seq field is a monotonically increasing 16-bit counter, that is allowed to wrap around (ok, so I guess it's monotonic until it wraps around). Whenever an outgoing packet has been waiting for an acknowledgement too long, the peer will attempt to resend the first packet not yet acknowledged.The length field simply indicates the length of the data portion of the packet, and is 0 for all other state values than kProto_data. Finally the rsv field contains two bytes that are reserved (for now they serve as padding).
On receiving a kProxy_start request, a proxy will open a TCP connection to the server given by the ip and port fields. As data comes in over the TCP connection, the proxy will convert the data to ICMP echo reply packets, and send them to the remote peer. The client will do the same, except its packets will always be echo request packets.
Authentication
As of version 0.60, Ping Tunnel supports authentication. The authentication used is very simple, and works as follows. The user first specifies a password or passphrase, which is then hashed using the MD5 algorithm (Ping Tunnel uses the implementation by L. Peter Deutsch, available here. Note that the implementation is included with Ping Tunnel, so there is no need to download it separately).Whenever a proxy receives a request for a new tunnel, it will respond with an authentication challenge. The challenge consists of a timestamp augmented with random data, totalling 32 bytes. The response is calculated as follows (the + denotes string concatenation):
md5(challenge + md5(password))
The proxy verifies the result by computing the same md5 sums, and then comparing the two. If authentication succeeds, the proxy allows TCP traffic to start flowing in either direction; if not, the connection is torn down.
Handling multiple connections
The proxy handles multiple different connections by using the ICMP identifier field. A client will randomly generate an identifier when it starts a session, and the remote peer will use this identifier to associate the packets with a connection. The mechanism is not foolproof, but works acceptably as long as no two instances attempt to use the same identifier (there is currently no mechanism for reporting such errors).The ICMP sequence number field is not used by ptunnel, mostly due to fears that some routers might drop packets whose sequence number repeats. Instead, a separate sequence number is used as part of the ptunnel packet format (see above).
Send and receive windows
Ptunnel uses the simple concept of send and receive windows for controlling the number of packets that can be in-flight at the same time. The window is currently statically allocated at 64 packets, but the number can be tweaked by modifying the ptunnel header file (yes, a recompile is required). Increasing the window size will improve the maximum potential bandwidth.The send and receive windows are simply implemented as a set of circular arrays, with pointers indicating the next available send/receive slot, and the first non-acked packet.Handling packet loss
Ptunnel handles packet loss by resending (presumably) lost packets. As it sends packets, it will increment a sequence number. Both the client and proxy maintain their own sequence number, and also a number indicating the last sequence number acknowledged by the remote peer. Whenever too much time (1.5 seconds) passes without a packet being acknowledged, the peer will resend that packet.Note that the peer will only resend the first missing packet. Once that packet has been acknowledged, it may resend the next packet(s), depending on how many packets were acknowledged. If the next few packets are acknowlegded as well, they are removed from the send queue. It is not uncommon for one packet to get lost, with most of the others making it through. This mechanism avoids unecessary resends as much as possible.
Congestion control
Ptunnel currently does no explicit congestion control. It will send as many ping packets as the window size allows, as slowly or as quickly as it sees fit. This might be improved in the future, if it turns out to be a problem (which is not at all unlikely..).When things don't work
There are a number of situations where ptunnel will fail. They can briefly be put into the following categories:- Outgoing/incoming ping not allowed, or filtered by a gateway somewhere along the way
- Operating system causing trouble
- Probably some other failures as well ;)
We can't handle the first failure - if our packets are filtered before we can get at them, there's little we can do. It is possible to deal with the second scenario by using the packet capturing library to get the packets before the OS sees them. This is necessary on Mac OS X, and may be necessary on other platforms as well. The problem lies in that the OS may occasionally not deliver ICMP packets to the raw socket we have opened for sending and receiving. This happens when the ICMP packet is an echo request (which the OS handles by itself) or when the ICMP packet is a resend (for some weird reason). The workaround is to use packet capture, however this tends to diminish bandwidth by quite a bit. For this reason, you should always try to run the proxy without packet capturing, and see if that works first. (This is the default mode.)
From OS X Scientific Computing
|
Telnet and FTP?
Never, ever, use telnet. Ever. Or ftp. These programs send you password through the aether as clear text, opening you to exploits by all kinds of nefarious evildoers. Instead, learn to use ssh, scp, and sftp.
Fugu: A nice, free, GUI for sftp
I'm generally a command-line person, but this free little application provides a nice intuitive and visually pleasing GUI interface that also permits integrated editing of remote files and so forth. Here's a screen shot grabbed from their website:
SSH: the basics
How to log in remotely to another machine using ssh
If you want to log in remotely to your account on another machine, simply issue the command
If you want to display X-windows programs on your machine that are run remotely, then include the -X or -Y flags:
Try -X first, as it is more secure. If there are problems, try the -Y option instead.
How to avoid interrupted connections
My DSL service provider seems to delight in causing my ssh connections to hang up. This irks me. I finally discovered a very simple solution. Create a file called ~/.ssh/config and put into it the following three lines:
Problem solved (at least for me).
How to set up passwordless logins
Generate a public key on the computer you want to log in from:
.......
Copy the public key to the computer you want to log in to.
Log into the remote computer
and append that public key to the appropriate file in your remote account's .ssh directory:
If the .ssh directory does not exist, you must first issue the command
and if the file ~/.ssh/authorized_keys does not yet exist, replace the above cat command with
(but do this only if ~/.ssh/authorized_keys does not yet exist, or it will clobber the file rather than append to the bottom of it.
With the 10.9 update, I found that I had to copy authorized_keys2 to authorized_keys
Test it.
It should now be set up for passwordless secure login.
Connecting securely with ssh tunnels
The idea of how to establish and use ssh tunnels, and why you might want to do this, is best illustrated with some examples. I have chosen two examples that you might very well want to put to use: Using a web proxy to access restricted websites (like scientific literature your library has a subscription to), and connecting to a mail server from anywhere, even if your local service provider tries to prevent this (DSL home service providers, hotel internet, etc).
Example One: Tunneling to a proxy server for web browsing
- Problem: I want to read restricted-access journals from home, but I only have access from work.
- Solution: Configure Firefox or SeaMonkey to use your work computer as a proxy.
For example, I can access most scientific journals on-line from machines that have recognized IP addresses (i.e., are affiliated with our university, whose library has paid for on-line access). If I am at home or on the road, I cannot do this easily unless I use a proxy server. Fortunately, this is fairly easy to do.
Establish the SSH tunnel connection
The syntax for establishing tunnel connections is as follows:
Choose a port, 8080, or any un-used non-root port. The -N flag says to establish the connection but not to make it a login shell, and the -D flag says to use dynamic port forwarding with ssh acting as a SOCKS server.
Configure FireFox or SeaMonkey Preferences to use a proxy
On Mac OS X, I use Safari as my primary web browser, but I keep several on hand. Because of this, I can dedicate FireFox as my proxy web browser. If FireFox is your primary web browser, other browsers in the Mozilla family, such as SeaMonkey, have this capability as well.
- In Firefox.app, go to Preferences > General and hit the 'Connection Settings' button on the lower right side of the panel. A second panel will be revealed. Enter what is shown here:
Then click the 'OK' button.
Mac Os Catalina
Thanks very much to James Davis and Adam Smith of UCSC SOE for the tip.
- With SeaMonkey, go to Preferences > Advanced > Proxies > Manual Proxy Configuration > Advanced and you will get essentially the same configuration pane as pictured above. (SeaMonkey also has a nice free WYSIWYG HTML editor, called Composer.)
.
Evasion Tunnel Mac Os Catalina
Example Two: Tunneling to a remote mail server
- Problem: I want access to my email securely from any connection point in the world.
- Solution: Configure smtp and pop or imap SSH tunnels.
Apple's Mail program logs onto a mail server computer every time it checks your mail, and every time it sends your mail. Depending on your mail server, it might send your password over the internet in clear text, as our POP3 server does. This is something worth avoiding, especially if you are on the road or using a commercial internet service provider. To get around this problem, you can create a 'tunnel' using ssh. Essentially, you can trick the mail program into using a pre-established ssh connection instead of using the insecure connection, thereby avoiding having to send your password in clear text. In fact, if you have enabled passwordless login, you can avoid dealing with passwords altogether. As side benefits, the connection seems to be established faster, and you can send mail from anywhere that allows you to make an ssh connection to the mail-server computer. (Many locations and DSL providers forbid you to make an smtp connection to your own mail server to avoid spamming issues and to try to force you to use theirs.)
Establish the SSH tunnel connection
The syntax for establishing tunnel connections is as follows:
That is pretty much all there is to establishing the required tunnels for POP3 mail, but a bit of explanation is in order. If you would normally log into the computer that is your email host with a command of the form
then just subtitute what you would actually type for this to the right of the -N option flag in the above two tunnel commands. (These are the same names you put in the email program for POP3 mail server and smtp server, respectively.) The ports (110 and 25) are the (insecure) ports used for POP3 and smtp mail. (If you are using the ssl secure ports, there is no need to be doing this). Again, these are the same as you used for configuring mail. The -N flag says to establish the connection but not to make it a login shell. Don't change ``localhost.' The other two ports (1110 and 2525) are arbitrary choices. You can pick any (unused) port (although the ones below 1024 are reserved for root). The -L flag tells ssh to do port forwarding (i.e., to establish the tunnel, treating the local port 1110 as if it were the remote port 110). The (optional) -C flag is for compression. This is handy on a lower-speed connection, but might actually slow stuff down on a high-speed connection.
How to get the Mail.app program to use the tunnels
To get Mail.app to use your ssh tunnels, you have to reconfigure its settings.
- First, establish the above tunnels.
- Then open Mail.app and under Preferences, go to Accounts and open the Account Information tab. Where it says Incoming Mail Server, you should enter 127.0.0.1 and where it says Outgoing Mail Server (SMTP), you should change the Server Settings by clicking the button, and add in 127.0.0.1 and port 2125 (or whatever port number corresponds to what you chose for the second tunnel command) and make these the default settings. This is illustrated in the following two screen shots below:
- Then go to Advanced tab, click on it to reveal the new pane, and enter the port 1110 (or whatever you picked for the first tunnel). You should now be set to collect and send your mail via ssh tunnels. If the tunnels become interrupted, you will have to re-establish them.
SSH Tunnel Manager
I find that it is easy to start and maintain the tunnels using a simple free gui application called SSH Tunnel Manager. This saves you typing and remembering the above commands. Should you require permanent, always-on tunnels, it might be better to run a launchd item to do this.