Archive for the ‘sysadmin’ Category

Full Disclosure and why Vendors Hate it (Jonathan A. Zdziarski)

(via RISKS Digest)

Jonathan A. Zdziarski, May 2008

I did a talk recently at O’Reilly’s Ignite Boston party about the exciting
iPhone forensics community emerging in law enforcement circles. With all of
the excitement came shame, however; not for me, but for everyone in the
audience who had bought an iPhone and put something otherwise embarrassing
or private on it. Very few people, it seemed, were fully aware of just how
much personal data the iPhone retains, in spite of the fact that Apple has
known about it for quite some time. In spite of the impressive quantities of
beer that get drunk at Tommy Doyle’s, I was surprised to find that many
people were sober enough to turn their epiphany about privacy into a
discussion about full disclosure. This has been a hot topic in the iPhone
development community lately, and I have spent much time pleading with the
different camps to return to embracing the practice of full disclosure.

The iPhone is shrouded in secrecy on both sides – Apple (of course) uses
their secrets to instill hype (and gloss over many otherwise obvious privacy
flaws), while the iPhone development community uses their secrets to ensure
they can exploit future versions of the firmware to find these flaws (along
with all the other fun stuff we do). The secrets on both sides appear to
have not only hurt the product, but run the risk of devolving an otherwise
amazing device into the next surveillance fear. With the military and
federal agencies testing the iPhone for possible use, some of the long-held
secrets surrounding the iPhone even run the risk of affecting national
security. …



Read Full Post »

After a long negotiation process between my DNS provider and the registrar of the domain thieves, virtual.net is back where it has belonged since early 1993: with me.  Huzzah!

My advice, in retrospect, is that if your domain is hijacked, immediately file with ICANN, over the protests of your registrar if necessary.  Fortunately I got my domain back, but if the remote registrar had not finally given it back (after making my registrar send some kind of “we won’t sue you” papers), I’d have been SOL, as the ICANN waiting period for opening a case had already expired.

How did I eventually lose the domain?  My provider offers both secure and non-secure login pages, and I believe that I accidentally logged into a non-secure page while at a public wireless location.  At first we thought my email provider had been compromised, but we found nothing but my home network access in the logs, and no suspicious activity.  The fact that the thieves had to change the contact email to “inbox@greatdomains.com” to get the transfer key is further proof that they had no access to my email.

If your provider offers non-secure login pages, make a bookmark to their secure page and only use that bookmark for login, never surf there directly or use a sidebar login on a provider’s main page– unless it says “secure login”.  There’s really no excuse for offering non-secure logins in this age of ubiquitous wireless– I’ve mentioned to my provider that they’re a bad idea, we’ll see if they go away.  I was on my laptop, with a new hard drive, and I hadn’t pulled over my bookmarks yet, so I think that’s how I screwed up.

Read Full Post »

I thought email had gotten very quiet over the last day or so. Better yet, we’ve been painting the livingroom, so I’ve been off the net mostly for the past few days. Yesterday my email seemed a little off, and today it was pretty much nonexistent. Now I know why. Some sleazeball apparently got access to my domain hosting account, apparently from intercepting email (!!!!!), and transferred my domain out. The one I’ve had since 1993.

The domain provider is getting it back. There’s an ICANN procedure for this kind of thing. Un-freaking-believable.

I wonder if I can sue them or get them in trouble otherwise in DK? As this smoking-gun photo shows, backed up by my domain provider’s logs, they broke into my domain provider account and deliberately hijacked it:

Domain Name: virtual.net

Registrant Contact
Name: Domain Manager : GreatDomains@inbox.com
Address: Sattarkhan Blvd.
Copenhagen, DK 2400

Email Address: greatdomains@inbox.com
Phone Number: (+45)331-530

Administrative Contact
Name: Domain Manager : GreatDomains@inbox.com
Address: Sattarkhan Blvd.
Copenhagen, DK 2400
Email Address: greatdomains@inbox.com
Phone Number: (+45)331-530

Technical Contact
Name: Domain Manager : GreatDomains@inbox.com
Address: Sattarkhan Blvd.
Copenhagen, DK 2400
Email Address: greatdomains@inbox.com
Phone Number: (+45)331-530

Record Created on…….. 1993-04-14 00:00:00.000
Record last updated on… 2007-12-27 23:02:08.956
Expire on……………. 2009-04-15 00:00:00.000

Read Full Post »

Over the past 6 years I’ve taught literally hundreds of sysadmins, network admins, and other IT professionals the fundamentals of a streamlined project management process that I call “Practical Project Management”. For the past 3 years, I’ve also taught “Project Troubleshooting”. All this time, the folks in the classes have said, “This is really great. You should put all this into a book!”

I’m very pleased to announce that, in partnership with the excellent folks at NoStarch Press, that’s exactly what is happening. We’ll be substantially expanding the material I’ve been teaching, as well as adding material on enhancements such as web-based PM tools and so-called “agile” and “lean” methodologies– which, oddly enough, bear a strong resemblance to what we already do! We’ll also be incorporating some of the great feedback I’ve gotten from my tutorial students over the years.

I’ll be putting out a call to senior colleagues early in the coming year for peer review of some of the chapters and topics. If you’re interested, please drop me a note. [Please include a brief CV or resume, if we’re not already well-acquainted.]

In the meantime, you can pick up a copy of TPOSANA for light reading over the holiday break!

The Practice of System and Network Administration, 2nd Edition (Limoncelli, Hogan, Chalup)

Read Full Post »

So here I am in Dallas TX, at the annual LISA conference for systems administrators. It’s been a great conference so far, even though I haven’t gotten out of the hotel since I arrived on Sunday evening. Heck, I haven’t gotten off the lobby/2nd/3rd floor zone!

I love it when I can do all my teaching early in a conference and then just relax and enjoy myself. I did two half-day sessions on Monday, and both went really well– interested and involved participants, and compliments afterwards. I started off with my tried and true favorite Practical Project Management, that I ‘ve been teaching and refining for several years now. I estimate that I’ve trained over 200 IS professionals in project management at this point, with typical class sizes of 45 – 50, and in one case, 89 or 90 attendees. This year we didn’t do the advanced class, Project Troubleshooting, although we had a great session of that in June at the Usenix Annual Technical Conference.

The afternoon tutorial was a fairly new class that I developed in 2005, Problem-Solving for IT Professionals. We had a really spirited class discussion, and I was pointed to a great resource after class, a book (and Wikipedia entry about the book) called How to Solve It: A New Aspect of Mathematical Method, by Gregor Polya. It has a set of rules for generalizing problems, and looks useful in building more problem-solving processes. In the class I teach generalized processes, which I hesitate to call “patterns” as they’re not sufficiently rigorously expressed yet, such as server-client interactions, and introduce modified process taskflow diagrams that aid in debugging. It’s possible to debug applications that you have never seen before if you have a strong understanding of fundamental patterns of design and interaction in computer applications and systems.

Right now I’m liveblogging from the Advanced Topics Workshop. I’d been a regular at this workshop since 1996, but had missed the last couple of years due to scheduling conflicts (read: being scheduled to teach!). We’ve had an exhilarating day of sharing experiences, technology to watch out for, and learning what we’ve all been up to for the past year or so. Tomorrow are the keynote speeches, a quick tour of the vendor exhibits, and a book signing session from 12:30pm – 2pm at the conference bookstore. Then it’s back on a plane, back home to Sunnyvale!

Read Full Post »

I’d been completely stumped earlier this year while attempting to try Second Life– the Mac client just “no va”, wouldn’t go, for me. I got an error suggesting that my DNS was busted and that I should try connecting to http://www.secondlife.com, and open a ticket if that didn’t work. How I was supposed to open said ticket if I had no IntarWebZ is left as a thought exercise, I suppose.

At any rate, after leaving it alone for the longest time, I was re-inspired to investigate this evening and found the problem. If I’d been a bit more Mac-savvy, I’d have found it long since– a good reminder that Mac OS is Not Unix, but something that Strongly Resembles Unix But With Quirks. Here is what I sent to the nice support folks at Second Life (who were quite helpful, but equally stumped along with me) this evening when I reopened the ticket:

I am reopening this so I can share the solution that I discovered with you. It turns out to be a very simple, yet very profound issue, and is easily diagnosed and corrected, so I want to be sure you add it to your solution base. It’s something to watch out for on folks running the Mac OS X client specifically.

Under Mac OS X, system applications, like Firefox, Safari, etc, use the built in resolver libraries. The Second Life client, like the nslookup utility, apparently is using classical DNS rather than the system libraries and using only /etc/resolv.conf to get information. The problem was that my /etc/resolv.conf file was no longer a link to /var/run/resolv.conf, and thsu was not supplying the correct information. This can happen for various reasons, including system updates, or booting without a network cable.

The symptom to identify this is if the person CAN get to http://www.secondlife.com from a browser, do ssh from a terminal/shell window, etc, but the Second Life client claims that there is a DNS error. This shows that the operating system is correctly doing name lookups via the built-in libraries, but that DNS is not correctly configured.

Diagnosis: Have the customer open up a terminal window and do “ls -l /etc/resolv.conf” and see if it is a symbolic link or a plain file. It should be a link to /var/run/resolv.conf.

Correction: If not, they should fix it: “sudo rm /etc/resolv.conf; sudo ln -s /var/run/resolv.conf /etc/resolv.conf”

If this does not resolve the problem, inspect the contents of /var/run/resolv.conf. If there is a problem with the network DHCP, there will not be any correct nameserver lines in the resolv.conf, and then that’s a client network problem not subject to quick fixes. 🙂

best regards,
Strata aka Maybear

See you online!

Read Full Post »

The Practice of System and Network Administration, 2nd Edition (Limoncelli, Hogan, Chalup)

Handbook of Network and System Administration

Read Full Post »

Older Posts »