Extra Pepperoni

The Register has an interesting article on how to “safely” take your computer to Defcon, with the very wise suggestion that you’re safer if your laptop does not go to Defcon. Cellular phones without 802.11 are probably okay for this year at least. They refer back to a much more hard-core SANS post on the same topic.

The exercise is more involved for the fully paranoid, or generally when preparing to enter a truly hostile network. I assume that someone at Black Hat/Defcon has an unannounced exploit that I’d be vulnerable to. This implies you shouldn’t have any sensitive data or access to sensitive machines. Since you wouldn’t need a laptop without data or access, you probably need to mitigate the consequences of getting hacked.

1. Make up a couple disposable passwords just to use at the conference, one for this machine and one for outside accounts. Destroy them later.
2. Bring an empty USB thumb drive.
3. Create a new email account, so you can send yourself notes/presentations for later.
4. Forward your important email accounts to the new one (keep copies on the normal accounts), so you don’t have to check them.
5. Note that if you have a hosting plan like DreamHost’s, you can create brand-new ssh and email accounts free. I believe DH offers SSL webmail, if you can ignore the certificate warnings.
6. Get a cheap monthly VPN account, as suggested by Glenn Fleishmann; this is much simpler than establishing a trusted Squid proxy on a non-sensitive box, as originally suggested by SANS; note that you are then trusting the VPN provider.
7. If you have any untrusted protocols, try to access them from your temporary shell account via ssh, or though an ssh tunnel.
8. Back up your data (image the drive — you will need it later, and a full image is fastest to restore).
9. Wipe your laptop.
10. Install your OS, creating a new account with your new local password.
11. If you have a built-in webcam with an independently software-controlled active light, tape over it. If you feel comfortable opening up your laptop, disconnect its internal microphone.
12. Create a new ssh keypair. If you know the netblock, only allow access from Defcon machines and your own personal host(s); I have some info on doing this in authorized_keys in Take Control of SSH, Draft Excerpt: Public Key Authentication. Make sure your laptop trusts your other (home) machines.
13. Only as needed, trust this new key on your other systems.

14. In your local firewall, block outbound access except to the ports you intend to use; this is easy in Linux, but a bit more complicated on Macs, where you need to write your own startup script (or .command script in Login Items). This is obviously overridable, but an effective way to make sure you don’t accidentally connect without encryption, either from habit or because a website redirects you to unencrypted HTTP to save encryption cycles (common). For services where you know what host you’ll be connecting to, embed that. Here’s a sample of what you might add to add Apple’s ipfw. Note that it’s easy to shoot your own foot off with outbound firewall restrictions.

    ipfw add 01010 allow tcp from any to 4.2.2.1 dst-port 53 out
    ipfw add 01020 allow udp from any to 4.2.2.1 dst-port 53 out
    ipfw add 01030 allow tcp from any to 4.2.2.2 dst-port 53 out
    ipfw add 01040 allow udp from any to 4.2.2.2 dst-port 53 out
    ipfw add 01110 allow tcp from any to any dst-port 22 out
    ipfw add 01120 allow tcp from any to any dst-port 443 out
    ipfw add 01030 allow tcp from any to smtp.dreamhost.com dst-port 587 out
    ipfw add 01040 allow tcp from any to mail.dreamhost.com dst-port 993 out
    ipfw add 01900 deny tcp from any to any out
    

15. Restore only required information to your laptop.

Enjoy the conference. Hi, Rich!

When you’re back home, connect from your home machines to the untrusted laptop, rather than the other way around, retrieve any data on it, and then boot from CD/DVD/PXE and reinstall, or restore from your image if you can do that without using the untrusted OS on the laptop’s hard drive.

The Super-Tent/IT Pavilion/Big Top/Big House fronts on the main RU parking lot, at the other end of which is the 66th St Gate. Except that after we moved in, they walled in the lot and started digging:

They still haven’t started on Smith Hall, though, which makes me wonder why we couldn’t still be in a proper building now. In the meantime, the main campus entrance and driveway are closed, along with the parking lot, under which a new electrical vault will be built. Getting around campus is much more complicated now than 6 months ago. This is especially true for IT, moving equipment around the tent, as the pathways and steps around the periphery don’t quite work for carts.

Our new main data center is nearing completion. It was previously our backup/disaster recovery site, so needed a lot of build-out to fit the rest of our servers. The swap from the older/smaller UPS system to the newer/larger one will be tricky, as several live servers will be switched over while running. Later we get to swap systems end-for-end across campus, so the primaries are in the primary DC, once their current location becomes the DR site. Needless to say, most of our systems are not redundant, so there will be a bunch of minor disruptions.

Stu, who is overseeing the build-out of what will largely be ‘his’ DC, showed me why Cat6A cabling is so much thicker (and thus harder to work with) than old-school Cat5 UTP (”Unshielded Twisted Pair”) — the internal copper wiring is twisted around itself many more times to reduce interference, and the whole thing is cradled by a plastic framework shaped like a plus sign. This framework is twisted as well, so as the Cat6A cables lay next to each other in cable trays, the individual conductor strands don’t align with neighboring Cat6A cables, again helping to avoid signal transference between what should be independent connections. The idea is that in 10 years, when everybody is demanding 10GE connections, we’ll be able to simply re-patch uplinks into 10GE switch ports as needed. Otherwise the rewiring would be painful for individual machines, and impossibly disruptive to do in bulk.

Unfortunately, the heavier-duty Cat6A is also heavier and bulkier, thus significantly harder to work with and slower to run. Each of the 24 new 42U racks is getting 48 runs, from 2 1U patch panels in each rack, back to 6 patch panels (96 connections) in each of the new network racks, where switches and other Cat5-based gear, such as terminal servers and KVM switches, will go. This is new 1,152 runs in addition to the slightly older stuff at the South end of the room, which is still our DR site during this construction.

My question is: How long will it be before we need more than 48 connections in a rack? Our non-blade Linux servers tend to have 3 Cat5 connections: Ethernet, serial console, and KVM; Windows systems don’t need serial consoles, so they get 2. A rack of 1U Linux servers maxes out at 40 1U servers and 120 Cat5 connections, which just won’t fly here. 8 2U Linux servers (24 connections) and 12 Windows servers (another 24 connections) fill a rack, meaning as time goes on and we are again someday tight for space, we might run out of network connections sooner. At that point we could put a KVM server in every third rack and reclaim a lot of cabling for Ethernet, but it violates our model of having everything run patched to the switch racks. We’ll see what the world looks like when we actually get there…

I discovered yesterday that they’re also simultaneously digging up the driveway between Founders Hall and Flexner — not sure why, but it looks like pipe-laying for plumbing.

Update According to Stu, this is actually conduit for electrical wiring, from the vault under our parking lot up through to an electrical switching station in Flexner.

Many more RU photographs are up at http://www.reppep.com/~pepper/album/ru/