Fotinakis.com Blog


Secure Screen Sharing in OS X Leopard Through SSH Tunneling

February 13, 2008


Here's a quick tutorial on how to secure the Screen Sharing application in Leopard by tunneling your connection through an encrypted SSH channel.

The new Screen Sharing application is basically just glorified VNC, but it does come with some nice features (dual-screen view, for example). However, just turning on the service will open up a couple of ports that may expose your system to exploitation.

WaterRoof MenuFirst, we'll want to lock down your firewall. Leopard comes with two firewalls: ipfw (ipfirewall—the underlying Unix firewall) and an application layer firewall (the one that pops up sometimes and asks if you want to allow an application to accept incoming connections). You can manage the application layer firewall through System Preferences > Security > Firewall, but in order to block some ports we'll need to set up some rules through ipfw. In order to do this, you can either learn the shell syntax (which isn't terribly complicated) or use a GUI app to interface with it. I chose to use WaterRoof—a frontend open-source GUI for ipfw.

Once you have downloaded WaterRoof, run the application and click on Static Rules. Click the + icon to add a new rule, and use the following information:

Protocol: IP
Rule Action: Deny
Source: not me
Port or range: (leave blank)
Destination address, subnet, or network: me
Port or range: 5900
In, Out, or In/Out: Select the In radio button

This will block port 5900, the default VNC listening port that is opened when you start Screen Sharing. Also, you'll want to block port 88 unless you are using Kerberos for authentication (I believe this is also opened by Screen Sharing and a couple of other apps). Add a new rule and use the same above parameters, but use incoming port 88 instead of 5900.

You should now have two new rules in your table:

deny ip from not me to me dst-port 5900 in
deny ip from not me to me dst-port 88 in

Click Tools > Rules Configuration > Save to startup configuration. Then, click Tools > Startup Script > Install Startup Script. This will make these new rules persist when you restart (otherwise, the system will reset to defaults on the next restart).

Open up Terminal and edit your /etc/sshd_config file with your favorite editor. In order to enable port forwarding add this line to the end of the file:

GatewayPorts yes

Now, open System Preferences > Sharing and enable the Screen Sharing and Remote Login services.

On your other Mac...

Now, from your client computer, open up Terminal and run the following (for reasoning, see the LifeHacker article Add More Functionality to Leopard's Screen Sharing):

defaults write com.apple.ScreenSharing ShowBonjourBrowser_Debug 1

and (to enable quality control settings)...

defaults write com.apple.ScreenSharing \
'NSToolbar Configuration ControlToolbar' -dict-add 'TB Item Identifiers' \
'(Scale,Control,Share,Curtain,Capture,FullScreen,GetClipboard,SendClipboard,Quality)'

Finally...

Now, any time you want to securely connect to your Mac, all you have to do is type the following in Terminal:

ssh username@ip_address_or_hostname -L 5900:localhost:5900

Leopard Screen Sharing Application WindowThe -L flag is the key to all this—it enables local port forwarding and specifies that anything that happens on the specified local port will be forwarded to the given remote host and port (see the man page for more info). The format of the -L option is port:host:hostport so the first 5900 is your local client port, the next option is the host to which to forward, and the third is the remote port. It's slightly confusing at first, but this localhost isn't the client you're connecting from, it is the remote computer to which you are connecting—it means that when the remote host gets forwarded data, it won't pass it on to some other host.

Now, leave that terminal window open and open up /System/Library/CoreServices/Screen Sharing.app (you can drag it to your dock).

In the connect field, type localhost:0 (don't forget the :0). The last part is important because it means to connect to display zero, which translates to port 5900 in VNC land and, for some reason, Leopard will tell you that "You cannot share your own computer" if you type in just localhost (though, you actually can by enabling Screen Sharing and typing that same host, it just creates an pseudo-infinite loop of VNC windows).

Once you type in your username and password, you're done! You can now control your computer remotely through Leopard's Screen Sharing app over a tunneled SSH connection. Here's an example of the Screen Sharing interface (notice the nice dual-monitor support):

Leopard Screen Sharing

Also, because Screen Sharing uses VNC as its base protocol you can interface with your Mac from any Linux, Mac, or Windows VNC client by port forwarding in the same way (on Windows, you'll have to use an SSH client like PuTTY) and connecting to localhost port 5900 with any standard VNC client.

Dirty business: Network Solutions domain registration

January 20, 2008


When a company employs questionable tactics in its business practices, it is many times appropriate to chagrin it publicly in order to make others aware. In that vein, I would simply like to spread the news that Network Solutions (a company who used to be the only registrar of .com's and other domains) has begun a very questionable tactic of automatically registering any domain that is searched for on its site.

TechCrunch's Michael Arrington writes, "So far they’ve registered over 72,000 domain names based on user searches. ... This isn’t costing the company anything, either. Registrars are permitted to register domains for five days without paying any fees to the domain name registry." After the five day period, they likely delete the domain in order to not pay for its actual registration. This five-day leniency was meant to allow registrars to efficiently deal with credit card fraud, but "the fact that Network Solution is using the grace period to stop users from going to competitors is well outside of the original reasons for the rule."

Though domain tasting is not in any way new, this seems to be a twist on the already abused grace period—one that I hope doesn't become commonplace and isn't copied by other registrars.

For more information, see the article on Domain Name News or the TechCrunch article.

Networking Via Carrier Pigeon

December 31, 2007


Let me just trace where this is coming from for you: while laughing again at an XKCD comic, I was led to Google the name "Eric S. Raymond" (the references to Richard Stallman and Linus Torvalds I got, but I didn't know much about ESR), which then led me to his home page and then to the Jargon file (a classic collection of terms and information on hacker culture) and to the Meaning of Hack section.

This story is probably well-known to many seasoned hackers, but it gave me a good laugh:

1990's addition to the hallowed tradition of April Fool RFCs was RFC 1149, A Standard for the Transmission of IP Datagrams on Avian Carriers. This sketched a method for transmitting IP packets via carrier pigeons.

Eleven years later, on 28 April 2001, the Bergen Linux User's Group successfully demonstrated CPIP (Carrier Pigeon IP) between two Linux machines running on opposite sides of a small mountain in Bergen, Norway. Their network stack used printers to hex-dump packets onto paper, pigeons to transport the paper, and OCR software to read the dumps at the other end and feed them to the receiving machine's network layer.

Here is the actual log of the ping command they successfully executed. Note the exceptional packet times.

Script started on Sat Apr 28 11:24:09 2001
vegard@gyversalen:~$ /sbin/ifconfig tun0
tun0      Link encap:Point-to-Point Protocol
          inet addr:10.0.3.2  P-t-P:10.0.3.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:150  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0
          RX bytes:88 (88.0 b)  TX bytes:168 (168.0 b)

vegard@gyversalen:~$ ping -i 450 10.0.3.1
PING 10.0.3.1 (10.0.3.1): 56 data bytes
64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=6165731.1 ms
64 bytes from 10.0.3.1: icmp_seq=4 ttl=255 time=3211900.8 ms
64 bytes from 10.0.3.1: icmp_seq=2 ttl=255 time=5124922.8 ms
64 bytes from 10.0.3.1: icmp_seq=1 ttl=255 time=6388671.9 ms

— 10.0.3.1 ping statistics —
9 packets transmitted, 4 packets received, 55% packet loss
round-trip min/avg/max = 3211900.8/5222806.6/6388671.9 ms
vegard@gyversalen:~$ exit

Script done on Sat Apr 28 14:14:28 2001

A web page documenting the event, with pictures, is at http://www.blug.linux.no/rfc1149/. In the finest Internet tradition, all software involved was open-source; the custom parts are available for download from the site.

While all acknowledged the magnitude of this achievement, some debate ensued over whether BLUG's implementation was properly conformant to the RFC. It seems they had not used the duct tape specified in 1149 to attach messages to pigeon legs, but instead employed other methods less objectionable to the pigeons. The debate was properly resolved when it was pointed out that the duct-tape specification was not prefixed by a MUST, and was thus a recommendation rather than a requirement.