Blog

Posted on

Practical Packet Analysis, 2nd Edition

The second edition of Chris Sanders‘ Practical Packet Analysis is about twice as large as the first edition and twice as useful.

I learned Wireshark in the traditional manner: got annoyed with tcpdump, installed Wireshark, and started poking menus and buttons until I got a result. Chapters 1-5 of PPA takes you through the important menus and buttons. There’s not much you can do to make descriptions of software options interesting, but Sanders demonstrates real-world uses as he goes along. Demonstrating how to use round-trip-time graphing with real data, for example, gives the buttons and menus relevance to our work. Chapters 6 and 7 cover a few basic network protocols, from ICMP to HTTP to social media logins and DHCP and so on, to ground you in what traffic should look like.

The really interesting part of the book is the second half. Starting in Chapter 8, Sanders dives into real-world problems and shows how to investigate them with Wireshark. He covers topics from difficult developers to network latency to security. What does a worm look like on the network? How about wireless?

The book organization invites me to keep it at hand for troubleshooting. The next time I investigate a slow network, I’ll turn to PPA2e chapter 9. And that’s perhaps the best praise I can offer on any technical book.

Practical Packet Analysis invites comparison with my own Network Flow Analysis. As you might guess, I consider network awareness skills absolutely vital for any network engineer. Where my work is about broad-scale network flows, however, Sanders’ work lets you dig deep into individual packets. Jitter, latency, loss, and all the details of protocol transactions are resistant to flow analysis, whereas packet analysis will lay them bare. I know my readers have already bought and devoured my book, but you really need to master both tools.

Plus, the author proceeds from Practical Packet Analysis are all being donated to the Rural Technology Fund. The narrator of NFA recommends using flow analysis to blackmail your coworker into washing and waxing your car. I am forced to conclude that Sanders is probably a better human being than I am.

Buy this book.

Disclaimer: No Starch Press also publishes books by yours truly. I have no problem calling them out if I disagree with them. Watch, I’ll demonstrate:

“Hey, guys, I really liked the color text boxes we did in PGP & GPG. I know they were more expensive than plain black and white pages, and I know that book sold fewer copies than anything else I’ve written, but it looked really cool. Why don’t we do that everywhere?”

OK, maybe that’s me being an entitled prima donna rather than disagreeing with them, but still, I wouldn’t write a positive review on a book I didn’t like.

Posted on

How to Lose your Job with SSH, part 1

A less sensational title for this post would have been “SSH Remote Forwarding,” but that’s not nearly as fun.

I used to be responsible for one of the few entry points into a global network. The company had actual manufacturing secrets — their products included various machines of war. We had internal firewalls to protect sites from each other, even when the site didn’t have Internet access. All Internet connections had to go through proxies. We did not allow external DNS to reach the desktop. If you typed ping google.com on your desktop, you’d get a “host unknown” error. The company had invested in VPN technology that blocked all but approved clients, and only permitted clients on the approved list if they were running the approved anti-virus scanners and other security software.

I was frequently asked to open direct Internal access for random applications. Most of these requests were rejected unless the user could explain what they wanted and why it was business-critical. Some of the people who asked were technically literate, and became indignant when I rejected their request for outbound SSH to external servers or equipment. After all, SSH is “Secure Shell.” It says secure RIGHT IN THE NAME. They just want to check their personal email. How could I possibly reject this eminently sensible request?

I’ve since had left this job, but I’ve had the same discussion more than once afterwards.

Most SSH users have no idea of SSH’s flexibility. Arbitrary SSH connections are a nightmare for maintaining any sort of secure information perimeter. Remote port forwarding is one reason why.

When most people mention SSH port forwarding, they’re thinking of local port forwarding. You forward a TCP port on your client to a TCP port on the SSH server. This lets you, say, tunnel SMTP inside SSH, so your client can relay mail through your server without any complicated Sendmail rules.

Remote forwarding lets you do the reverse: forward a TCP port on the SSH server to a TCP port on the SSH client.

Suppose I permit a user to SSH to an external server. The desktop is behind a NAT. There are no port mappings from the NAT to the desktop; it has the same connectivity you might give a secretary, except for the outbound SSH access to a single host. That user sets up remote port forwarding from a TCP port attached to the server’s public IP to the client’s SSH daemon. I’m using an OpenBSD desktop, but you can get SSH clients for most other operating systems, including Windows. I’m using OpenSSH, of course, but most clients (including PuTTY) does remote port forwarding.

To do remote port forwarding in OpenSSH, run:

$ ssh -R remoteIP:remoteport:localIP:localport hostname

If you don’t specify an IP address to attach to the SSH server, the server attaches to 127.0.0.1. (You can also skip the first colon in this case.)

My desktop runs sshd. I want to attach port 2222 on the SSH server pride.blackhelicopters.org to port 22 on my SSH client using remote port forwarding.

client$ ssh -R 2222:localhost:22 pride

I leave this connection up and go home. Perhaps I run top in the command window, to prevent the SSH session from timing out at the corporate firewall. Now at home, I log into the SSH server and run:

pride$ ssh -p 2222 localhost

My SSH request to the local machine will get tunneled inside the existing SSH connection out of the network. I will get a logon prompt for my client inside the secure network. When I can access one supposedly secure machine, I can start ripping data out of the local file servers and maybe even access other internal sites. All of the trouble the company expended to prevent unauthorized access is now moot.

If you attach the remote port forwarding to the server’s public IP, then anyone on the Internet can attack your desktop’s SSH daemon. People are attacking SSH servers, even on odd ports.

Of course, remote port forwarding in this environment would violate company policy. If caught, you’d lose your job. But to catch this abuse, the network administrator would need to realize that large data transfers were taking place in off hours over these limited-use channels. You could, say, use flow analysis to write automated reports that notice and alarm when large amounts of traffic pass over these “rarely-used” channels. You’d have to be a real bastard to think of that. But the reports are easy to write, and the look on the abuser’s face when you confront them with graphs and numbers is priceless.

The point is, the next time your employer’s network administrator rejects your sensible request for SSH access to your home server, don’t be too hard on the poor slob.

Want more SSH fun? Check out the book recommended by the OpenSSH project, SSH Mastery.

Posted on

creating FreeNAS 8 iSCSI target

I didn’t find an up-to-date tutorial on how to set up a FreeNAS 8 iSCSI target, so I took notes as I set one up. Figuring this out by brute force is fairly straightforward: just keep adding iSCSI stuff until you can actually discover iSCSI targets. But for those of you who value your time, here’s how you do it.

1) Go to services, enable iscsi. Under iSCSI, choose Target Global Configuration. In Discovery Auth Method choose CHAP. Leave all other settings unchanged

2) It seems that FreeNAS doesn’t yet let you export a whole drive via iSCSI; you must create an extent. Under iSCSI, select Extents, then Add Extent. Name your extent, give it a path, and set a size.

3) On the Target Global Configuration, on the “authentication” tab, create an iSCSI user and assign it a secret

4) You need an iSCSI Portal. Click the Portals tab. This is where you define the iSCSI target. The default is to listen for iSCSI connections on all IP addresses, on port 3260. If you have multiple IP addresses, and want separate portals for each, be more specific.

5) You must authorize initiators. Choose “Authorized Initiator,” then “Add Authorized Initiator.” List the IP subnet of your initiators under Authorized Network.

6) Go to the Targets tab. Add a target.

  • Give the target a name and and an alias.
  • The type will be “disk.”
  • flags read-write
  • portal group ID is the number of the portal (probably 1)
  • initiator group ID is the number of the authorized initiators you created (probably 1)
  • Set auth method to CHAP
  • authentication group number from the user you created (also probably 1)

    • 7) Under “Associated Targets,” attach the extent to the target.

    Now go to your iSCSI initiator and log in.

    To create new iSCSI targets, create a device extent, add a target for that extent, and attach the extent to the target.

    Posted on

    SSH Book Title

    I’m at a publishing workshop, learning how to write pitches, blurbs, and promotions. That drove home that my SSH book title might not be the best choice.

    I’ve been planning to use the title “OpenSSH: Your Next Steps.” The book will take you to SSH competence, making sure that you use basic security precautions, master using keys for authentication, SSH tunneling, and so on. That title’s fine. As far as it goes.

    But I think I can do better. I’m pondering calling it “SSH with OpenSSH and PuTTY” instead. The first title, I’d have to rely on keyword search to bring up SSH. This title brings all the key words into plain sight.

    I learned with PGP and GPG that a title is important. If I had called that book “Email Encryption for Everyone,” I would have sold a lot more copies.

    So, what do you lot think?

    Posted on

    FreeNAS 8.0 and SNMP

    Today, I learned that FreeNAS 8.0’s SNMP isn’t quite all one could hope for. The good news is, the bugs will be fixed in 8.0.1. I’m posting this in the hope of saving others the annoyances I had.

    To SNMP query a FreeNAS 8.0 host, you must force the client to use SNMPv2.

    # snmpwalk -c public -v 2c freenashost

    Additionally, you can’t change the community name (at least on the amd64 version). You must use public.

    This is fixed in 8.0.1. Still, it makes me glad I hacked a firewall into my FreeNAS box.

    Posted on

    Full up on OpenSSH reviewers

    I now have all the reviewers I can manage, and am not looking for more. I’d make an exception if you’re, say, an OpenSSH or PuTTY developer, but other than I’m not accepting any more. I’d like to thank everyone who has volunteered to review this book.

    Posted on

    add PF to FreeNAS 8

    I won’t put any system on the Internet without some sort of packet filter or firewall. Especially not a file server containing important data. While I have a FreeNAS 8 box, it doesn’t come with a firewall. FreeBSD includes three firewalls, IPFW, IPF, and PF. Any one of these would do, but I’m most comfortable with PF, so I decided to add PF to my FreeNAS install.

    This will not add a firewall to the GUI. You must manage your rules remotely. The FreeNAS backup will not back up your rules. The good news is, once your firewall works the rules don’t change very frequently.

    First, get the appropriate kernel module. You’ll need the ISO for the version of FreeBSD that your FreeNAS is based on. FreeNAS 8.0 is based on FreeBSD 8.2. I’m running the amd64 version of FreeNAS, so I need the amd64 version of FreeBSD 8.2. The version must match as exactly as possible: your 8-stable amd64 desktop might work, but it might make your FreeNAS box crash and die.

    Mount the ISO.

    $ mdconfig -a -t vnode -f $HOME/FreeBSD-8.2-RELEASE-amd64-livefs.iso
    md0
    $ mount -t cd9660 /dev/md0 /mnt

    I previously installed FreeNAS on a 2GB USB stick. For this process, I shut down my FreeNAS box and mounted the USB drive on my FreeBSD machine. You could work directly on the FreeNAS image and re-install it on the USB drive, or even work directly on the live FreeNAS box. I’m assuming you’re working on a USB stick.

    $ mount /dev/da0s1 /mnt

    Start by getting the PF kernel module from the ISO onto your USB drive.

    $ cp /media/boot/kernel/pf.ko /mnt/boot/kernel/

    Now for the tricky bit. FreeNAS is based on the FreeBSD diskless system. (Obligatory plug: I did half a chapter on diskless operation in Absolute FreeBSD.) It uses the /conf directory to create a series of memory-based filesystem overlays, creating a MFS /tmp, /etc, and so on. This means that any changes you make to, say, /etc/pf.conf will not survive a reboot. You must edit the original versions of these files, in /conf/base/etc.

    In /conf/base/etc/rc.conf, add

    pf_enable=YES

    Put your pf.conf in the same directory. Configuring PF is left as an exercise for the reader.

    Any firewall changes made to a running system must appear in /etc/pf.conf and in /conf/base/etc/pf.conf. I suggest changing the base file, and copying changes to /etc.

    Posted on

    FreeNAS 8 on Intel SS4200-E

    The boss snagged an Intel SS4200 NAS as part of the corporate “redundant array of inexpensive crap” strategy. Basically, it’s a small, headless amd64 machine with 512MB RAM, four SATA ports, plus eSATA and USB. Add four 1TB hard drives, and you have a decent small storage device. I decided to try FreeNAS 8, so I could get ZFS, NFS, and iSCSI.

    FreeNAS 8 installs on a USB drive. I got a 2GB USB from Micro Center checkout counter, and escaped the store without purchasing anything else.

    Start by getting the FreeNAS full install, aka FreeNAS-8.0-RELEASE-i386.Full_Install.xz. Verify the checksum, then decompress the image.

    $ unxz FreeNAS-8.0-RELEASE-i386.Full_Install.xz

    Use file(1) to check it.

    $ file FreeNAS-8.0-RELEASE-i386.Full_Install
    FreeNAS-8.0-RELEASE-i386.Full_Install: x86 boot sector; partition 1: ID=0xa5, active, starthead 1, startsector 63, 953505 sectors; partition 2: ID=0xa5, starthead 1, startsector 953631, 953505 sectors; partition 3: ID=0xa5, starthead 0, startsector 1907136, 3024 sectors; partition 4: ID=0xa5, starthead 0, startsector 1910160, 41328 sectors, code offset 0x31

    My USB drive is available as /dev/da0. Copy the image to the drive.

    $ dd if=FreeNAS-8.0-RELEASE-i386.Full_Install of=/dev/da0 bs=5k

    While that’s running, console into the SS4200. The serial console connector seems to be a standard DB9 connector, so you can just pull one off of an old motherboard. If your null-modem cable doesn’t seem to work, try reversing the connector on the motherboard. I connected with 115200 8n1, no flow control.

    Go into the BIOS. Select Advanced, then go down to USB. Set your USB emulation type to “hard disk.” Then go into the boot order and have it boot from hard drives. Go to the Hard Disk Drives menu beneath that and make your USB device first on the list.

    If you don’t have the console connection, boot the SS4200 from USB by holding down the reset button (tiny black dot by the rear USB port) for about 2 seconds while powering on. The light will turn amber to show that it’s booting from USB. This will work for home use, although you’ll need to do this every time you reboot the NAS. You’re really better off setting the BIOS properly.

    Once dd finishes, plug the USB drive into the SS4200 and power up. The default FreeNAS IP is 192.168.1.250, but if you have a DHCP server it will grab a proper local IP. Check your DHCP server logs for a host called “freeNAS,” and point your browser at that address.

    Once I was in, I easily added data storage, creating two 931-GB ZFS mirrors.

    I successfully created group for my new account. I couldn’t create a user, but it’s a known problem with workarounds.

    Lastly I enabled the serial console by going to System->Settings. Oddly, there’s no setting to set the console speed. You can change the SS4200 serial port to 9600 in the BIOS, but that seems less than optimal. It’s a petty issue, however, as I can reconfigure my serial connection trivially.

    I found a FreeNAS 7/SS4200 tutorial buried inside the FreeNAS forums. While all the FreeNAS stuff has changed, it was quite helpful for setting up the SS4200 hardware and BIOS.

    Overall, FreeNAS 8 looks pretty. The real test will start when I put a bunch of diskless NFS and iSCSI clients on it and watch for stuff to break. It must have better iSCSI than the Iomega NAS’s I’ve been arguing with…