February 2006 Archives

The professor in question has revised the assignment. The only networks the students can scan are those who the professor has received permission from. At a minimum this is the Computer Science network, but I know several of my collegues here who have thrown him an IP or two of test servers or other not-mainline servers that can stand probing.

And it has been stressful around here. The SANs posting on the topic just added heat to a fire that was already growing internally. Now that the key issue is handled, now we get to deal with the fallout. According to the SANs posting, there are those clamoring to release the organizational name of the Higher Ed institution at fault. Thanks to this blog, a bit of google will give them that without too much work.

By all accounts this particular prof knows his stuff. I'm convinced this was just a sin-of-omission, rather than ill intent on the part of the professor. Unfortunately it was a very key detail missing, but that has been fixed. With luck, none of the students have commited an illegal act as a result of it yet. We hope.

Also, as near as I can delve into wa.gov, port-scanning by itself isn't a crime in this state. Of course, I Am Not A Layer. This does not hold true in other states, however, so the risk is quite present. According to one class-member who works in our office the professor said to perform the scans (of the CS network) outside of WWU's router-cloud in order to not have an unfair advantage in identifying exposed ports. Being a university, we're pretty permissive about traffic coming into our network, so that will still get them useful information.

Aye. Long week.

Oh wait, it's Tuesday.

The word has come down from on high:

[ITS director] has chosen to take no action relative to [prof's] CS class assignment. He did have me [Tech Services director] write a note to [Prof] stating our concern. We specifically asked to have all ITS sub-nets exempted from the scans.

I also stated that our policy is to terminate machines we see engaged in this behavior and sort out later if they had authorization or not. So we will continue to do our job in a normal manner and see what fallout there will be.

Indeed.

My Spidersense still smells fallout incoming.

A notice was sent out to the LAN administrators today that raised eyebrows into orbit. Apparently one of the profs in CSci is teaching a Computer Security class, and passed out a competely unethical assignment.

Task
You are to perform a remote security evaluation of one or more computer systems. The evaluation should be conducted over the Internet, using tools available in the public domain.
Your evaluation should determine some or all of the following:

• Host name and IP address.
• Operating system, version, last update, patch status.
• Open ports and, where possible, suggestion of the type of service provided on each port.
• Shared disk drives and printers.
• Network traffic.
• Vulnerabilities.

What you must submit
In conducting this work, you should imagine yourself to be a security contracted by the owner of the computer system(s) to perform a security evaluation. You provide a written report which has the following sections:

• Executive summary.
• Description of tools and techniques used.
• Examples of data collected during your investigation.
• The evaluation data, listed above.
• Overall evaluation of the system(s), including vulnerabilities.

Note:
Since your remote evaluations of computer systems cannot be purely passive, you must take care to ensure that your actions are not seen as intrusive or threatening to the computer site being investigated.
You are to conduct your investigation using tools available in the public domain and must not attempt to hack into the system. If you detect vulnerabilities in the system, you must not exploit those vulnerabilities.
If you are challenged by a system manager, you may explain your actions and provide a copy of this document. You may also offer to provide a copy of your report to the system manager on completion of your evaluation. If asked to cease and desist, you are to do so immediately and consider another site for your investigation.

In short, this professor has given as an assignment to his students the task of performing an unethical action. By the Student Access Policy of this very university, if we catch these students scanning any of our systems their accounts will be disabled and they will be referred to the Student Dean for disciplinary action.

The very foundation of this sort of action is getting permission first. The disclaimer:

In conducting this work, you should imagine yourself to be a security contracted by the owner of the computer system(s) to perform a security evaluation.

Is wrong from the start. When doing these sorts of scans you need to have the consent of the administration of the network in question. This statement is not a proxy for permission, especially when combined with this requirement:

The evaluation should be conducted over the Internet, using tools available in the public domain.

Which pretty much says, "you can't use your home network."

In some states, this sort of unsolicited scanning is technically illegal. Admittedly, it is never prosecuted unless there is a greater offence being dealt with that this will assist with, but still illegal. This is a grossly unfair assignment for the students, and completely unethical as presented.

http://www.ndsengineers.com/

A nice site, which I've linked to for a while. Their chief claim to fame (IMHO, of course) is that they provide a better web front-end to the NNTP-driven support forums than Novell does. This is handy for those folk who prefer a web-browser to a news client. Plus they have the usual assortment of chatrooms and suchlike.

Go check it out!

Scheduling opened up on Monday, but I forgot about it until late Tuesday. Because of that, I won't be going to any of the ATT sessions. Darnit.

On the other hand, it looks like Lunch will be a hit-and-miss thing this year. The sessions that I have that block out a lengthy lunch are ones I kinda want to go to. Lunch is served from 11:00-2:30, so it gives a wide range to get fed. We need it.

Monday: Lunch-break! Yay!
Tuesday: 15 minutes between "Securely Locking Down Your SLES/OES Server" and "Wiki Collaboration and Community Culture: Putting the Best of Open Source to Work"
Wednesday: 15 minutes between "AppArmor Profiling of Applications for System Administrators and Software Vendors" (which runs from 11:00-1:45. WTF?) and "Kernel Optimization / Tuning"
Thursday: 30 minutes at 2:00 right after "Using eDirectory for much more than just an LDAP store"
Friday: 45 minutes at 1:45 right after "OES Cluster and Disaster Recovery Roadmap and Futures"

So when I can get lunch, it'll be late. Me thinks I'll be smuggling bagels out of Breakfast again.

In other news, there isn't a lot of wiggle-room in the schedule. Some of the lunch-obscuring sessions may get skipped. Thursday's session is right up there, especially if I'm partially burned out and the topic doesn't grab me. Friday's 11:00 session, YaST Architecture, may get droped in a fit of "I don't care" as well. As expected, I'm catching a LOT of linux sessions. One session I wanted, Deploying Novell Storage Services (NSS) on OES Linux, has already filled up so I can't go.

I'll also be going to a couple of the 'Birds of a Feather' sessions. BOF177, Communities and Sharing Information (a.k.a. peer-support options for Novell) Monday night, and BOF175, Higher Education Wednesday night. I went to the Higher Ed one last year, and it was pretty good. It proves that WWU is just a mid-sized university, dispite our warm-body-count of around 18,000 students.

Gonna be a busy one.

I'm in NOV-3038 this week, so posting volume will be lighter than normal. Though if we do have internet access in the class-room, likely considering how YaST and RedCarpet handle updates, it might be a bit more than I'm expected.

Oh, and RedCarpet? Use the "patches" tab, not the "updates" tab with the human readable names and clear information about what's being updates. Not that one. The one with the cryptic "patch-1138" patches that require you to click in Information for each one to know what they do. Otherwise bad things happen. Just saying. Perhaps there is an enhancement request somewhere in there...

Not that I have anything to complain about. That's how Microsoft patches work. Or rather, we KNOW what we're patching, but we have no choice about patching since work operates on what is essentially a public-access network.

Apparently Google Groups received a new feature recently. If you do a search, there is a "view profile" link next to posters. From there you can get the most recent posts, and the newsgroups that particular e-mail address was used to post.

What is interesting, is that the X-No-Archive: bit appears to not prevent information disclosure here. While the posts themselves may be gone, the profile still lists the group and posting frequency. Group-names can be just as damning as the content of the posts, and going through the delete process does not remove that post from the post-count.

The Google help for profiles.

So if you're going to work for, oh, Paramont, and were an avid poster to alt.wesley.crusher.die.die.die circa 1994, perhaps you might have a problem should the hiring manager plop that e-mail address you've had since the dark-ages into google-groups.

My storage-tracker has a year and a half worth of data in it. Last night we processed the winter-quarter student deletes. It did drop the student data a bit, but not anywhere near the level that the Fall delete did.

Chart here

The Fall delete happened about 11/20/05, and you can see the big hunk of space liberated by that action. Another thing of note is that the slope of the 'wuf-students' line is steeper than the Wuf-FacStaff line, so student data is growing faster that non-student data. But, thanks to regular user purges, overall growth is closer to normal.

The big anomaly of this summer on the facstaff line is due to the migration of three Shared volumes to one monolithic Shared volume. We were running in parallel for a while. What I found interesting is that the line either side of the big bump seems to match up well with growth patterns.

The Exchange line is pretty short as well. We're a bunch of quota-scrooges around here when it comes to mail, so mail growth is kept in check far better than file-storage. The mid-december blip is due to a realign of Exchange drives that the monitor didn't catch in time. The reallign also got rid of an annoying data-artifact we had; about 20GB of space on one Exchange drive was flagged (in error) bad-cluster, and this reported as 'used data'.

Something went pear-shaped in the install, and I'm not sure what it was. We were caught a bit off guard when we learned that it would require putting the Big-IP in the router-path to the servers we're balancing between. This is required if we desire our log-files to be meaningful and not be 100% full of IPs from the Big-IP.

On the other hand, it is really neat.

Today we're getting the Big-IP installed. This devices will be driving the Blackboard upgrade this summer. The plan is to 'make it more reliable', which is a challenge with this product. But the happy bit is, Big-IPs are just so darned useful that we'll find other things to do with all that extra power.

Anyone who has worked in this field for a while had heard the arguments for and against 'free' linux distros. Heck, my distro of choice, Slackware, is free. Debian and FreeBSD. Small-business folk, and anyone working on a shoe-string IT budget, has been through this one. Which is why this quote just makes it all work out:

Remember kids, Linux is only free if your time is worthless.

Yep, that's it right there. A well known adage, but still, bears repeating.

Over the last couple of days I've been doing some tests of temps. The issue of datacenter cooling has come up again, and I want more data. I strongly suspect that some past-practices we've inherited don't scale well to pizza-box and blade-server densities. Heck, when I got here in December of 2003 the only rack-dense servers we had in the datacenter were the three student nodes in the NetWare cluster (2U servers, even though 1U would have worked), and a pair of Active Directory root-domain DC's. Since then we've installed 19-20 blade-servers, converted a whole bunch of circa 2000 server hardware to be test and development servers, and picked up a couple more 1U and 2U servers as well.

One of the bigger problems in my opinion are the doors to the racks. The front doors are plexiglass fronted doors with maybe a 5-10% perforation, and the back doors are big metal doors with perfs at the top and bottom for maybe 2% perforation if that much. To handle airflow, there are big ole fans in the tops of the racks. This setup was just fine for whitebox and other machinery that isn't rack-dense.

Just by changing the front door to the blade-rack (back when it was 16 blade-servers) from the plexi-front to a fully-perfed door we dropped exhaust temps 10-15 degrees. There was recirculation going on there!

Right now it looks like rack-ambient temps are about 10 degrees F above room-ambient. When the rack-fans are turned off the increase goes to 18-20 degrees F, so those rack-fans are doing work. If I open the front door and leave it there, rack-ambient drops to room-ambient. Clearly, a fully perforated door is what we want.

On the other hand, even with the rack-fan off the servers are still within their operating spec. But then, who wants to run near the top of the spec when these things are supposed to last 5-6 years. Perhaps this data will convince TPTB to liberate fundage to start converting our doors to the fully perforated ones.

Another area we'd get benefit from once the doors are in: blanking panels. We're getting noticible recirculation. Happily, the heat of the recirculated air is not enough to run the servers out of spec, but recirculation is an abomination unto Nuggen and can not be tolerated. Ahem. We'll do that once we yank the CRTs out of the racks too. THEN we'll be sitting pretty for true rack-dense stuff!