I saw mention of the DualComm Ethernet switch/tap on my twitter feed a few weeks back from @Pauldotcom. It is really difficult to sniff traffic without a hub or business level switch. Or you could do a pass through feed using a dedicated pc. The DualComm tap provides a very simple and affordable way to tap traffic by putting a port replicator feature in a small switch.
So I ordered the USB Powered 10/100 Ethernet Tap DCSW-1005. It cost $59.95 and they take paypal.
It works like a champ. I plugged it into a spare apple usb power plug where all my network hardware is. Then I patched the cable from my router wan port to the port two of the switch. Port one then went to my cable modem. I tested and found all my Internet connectivity works fine without issue or performance hit. Then I just plugged the port five from the Ethernet tap to a old Thinkpad laptop I have for such things. I did have to order a Linksys USB Network adapter to have the second interface on the Thinkpad for sniffing the traffic. The onboard nic is used for normal network access, ssh, etc. Testing Ntop, Dsniff, URLSnarf etc all work perfectly. It was amazing that I could not find the USB wired network adapter in any local stores. I had to order that Linksys adapter from Amazon.
All said and done. The DualComm DCSW-1005 works great! And having it be usb powered means no dedicated power adapters to be lost or mislabeled. If you need an Ethernet tap for your security work this is a great find.
PS If you are like me and forget how to put an interface into promisc mode under Ubuntu linux. Andrew Hay has a great post on promisc mode setup I keep handy.
Sharetool is a bonjour relay tool over an SSH connection. It uses the existing Remote Login service built into OSX. It can take advantage of your existing setup connection if you already use SSH to access your network from remote. The one odd technical thing I have found is that it seems capable of ignoring the requirement for public key authentication on an existing setup Remote Login configuration. But only when using the ShareTool itself. It does not even provide a means of specifying use of an authentication key. It still honors any user name restrictions you setup under the Remote Login preference panel.
*UPDATE* I found even though I had thought I moved my ssh key out of my folder for testing it had hung onto a key in another location and my passphrase had been cached in my keychain. ShareTool will automatically use your key authentication if the key is present in your .ssh folder and is unable to login to your mac if you require key authentication and the key is missing. Very sweet.
Connecting to remote services adverstised by Bonjour, screen sharing, file sharing etc all worked surprisingly well.
Some additional very nice features are UPnP to automatically configure your router, wanting to use non standard random high ports to avoid SSH bot attacks, updating of Dynamic DNS services like DNS-o-Matic, DynDNS etc. Lastly it passes through access to all Bonjour services on the network you are connecting into.
They provide a evaluation version of the tool that allows 15 minutes of functionality at a time to see if it meets your needs.
One last odd thing about the product. They require you purchase one license for each machine you load the software on. This is only strange because you can only use it in a minimum of a pair. One on the machine you are connecting to and the machine you want to connect from. Usually software that has to work in a pair usually lets you run that with one license up front then just add singles after that. They want you to purchase a single license for $20 USD. At least they offer a “special” $30 USD for a pair of licenses. So look at the product as costing $30 out of the box then $20 for each additional single license after that. A pack of 5 licenses is $75 USD.
Well a nice long but fun screencast series is all in the can. You can find the first episode of eight over at typicalmacuser.com. I spent a good bit of time doing the recording and thanks to Victor for the editing and post production. By the time the series is over you will know pretty much everything I know about SSH. At least all the juicy functional parts. It is done for the target audience of Mac users so it is all about setting it up and tunneling all sorts of traffic through it to protect yourself when on public wifi hotspots or other risky public networks.
A while back I was messing with tunneling iTunes sharing through SSH. During that experimentation I noticed that there was a dynamic dns name showing up on my system of my dotMac username in this format: username.members.mac.com I found it by looking at Bonjour, aka mDNS traffic. That is kind of scary to think that anyone who knows your @me.com or @mac.com email address or iChat login could find the active IP address you are on just by resolving that name.
I revisited the issue today because I was thinking of the problem with syncing data between iPhone/iPod applications and their desktop mac cousins. Like syncing 1Password from my desktop to my iPod touch. They could theoretically leverage my MobileME user dynamic dns name to sync back to my desktop as long as I opened a custom port on my router.
Interestingly I can no longer resolve username.members.mac.com or username.members.me.com. So I am not sure if they just haven’t fixed that since the MobileME migration. Or did they realize the clear scriptable way someone could target mac users. Toss a dictionary at the front of members.mac.com/members.me.com and fire off an exploit just for Mac users. *shudder*
Here is an easy way to find all snmp devices on your network and check if they are running any of a list of common strings you want to test for. And do it without risking a write access check. I did the following with my Mac PowerBook just using the C compiler CC.
I was travelling this past week for my Grandfather’s funeral. He was 94 and did about everything you can imagine in his life.
We stopped at my dad’s place on the way home this weekend. I got to messing with iTunes over the Internet since I had not been able to sync my ipod etc during the week.
It seems iTunes checks the source address of any connections to streaming. So just opening TCP 3689 on my router via remote would not work. I had to trick it into thinking the connection was coming from the same private network segment as my main iTunes is on at home.
So you can add this to your SSH connection line when accessing your home Mac from remote. Replace the homeinternalIP as the local network IP of the mac doing the sharing inside your home network. It might be something like 10.0.1.200 if on an airport extreme N router. This will tell your SSH session to listen locally on the DAAP iTunes sharing port. One other thing. Make sure iTunes sharing on your laptop is off. That way the port is not already occupied.
Add a beacon that looks like the below image. You will need to make sure your SSH connection is up. Give it a minute and it should start showing in your iTunes on your laptop as the service name. The example below would be homeMac. That is all there is too it. If you have a decent connection speed on both ends you can stream just as if you were on the same network segment at home.
I have heard our sales group say our webmail goes down a lot at work. This is their justification for using free non Company webmail for business purposes. I feel for them if it is true, but for liability and eDiscovery purposes they need to use our own webmail as backup to their vpn based MS Outlook. With that said it is the responsibility of our IT department to ensure our webmail system stays up and is usable. So I aimed my VM based Smokeping setup at our webmail.
Our webmail requires use of HTTPS and does not reply to pings. Both very good things. So I just had to use a Curl probe setup in Smokeping. Curl is just a command line tool that fetches web pages as text. Below are the commands and the graphed results. It does at least respond to HTTP to redirect the person over to HTTPS so we can curl on HTTP.
First you need to install Curl in our Ubuntu VM
sudo apt-get install curl
Second you need to add the probe type under the +++ Probes section. Just sudo vi /etc/smokeping/config