Default Passwords for World Wide Packets/Lightning Edge Equipment

Mailman List Mirror (Read Only)
1

While we're on the subject, a lot of leibert gear has a dip switch/jumper
block to turn passwords off entirely. (of course, that requires physical
access and a power cycle.)

So do a lot of HP/Compaq servers with integrated lights out management.
Don't think you even need to power cycle (whether you're brave enough to
go poking around the deep innards of an energized server is another
matter). I know the DIP switch on older DL385's is a micro DIP switch
and it's inconveniently located in the middle of the server behind some
stuff.

The good part is that you can clear out unknown passwords as long as you
have access to the chassis innards. The bad part is that I've seen these
left in password bypass mode (though the BIOS thoughtfully warns you of
the status if you do that).

... JG

2

A password recovery method I've found very frustrating is to use the
serial number or similar value that's on a label on the bottom of the
equipment. It's just fine for desktop hardware - but for rack-mounted
gear, it's not uncommon to find out that you need this information
*after* somebody's racked and stacked the hardware, and therefore you
either need to unscrew it (if it was screwed into the rack) or drag it
out (if it wasn't screwed in for some reason like missing
wing-brackets or 23-inch telco racks or random junk piled on top of
it, etc.), and possibly uncable it as well, depending on how much
slack is in the cabling, and you almost certainly want to power it
down first, and you need to have enough flashlights and reading
glasses to deal with reading the bottom of the equipment lying down on
the floor of the data center.

Yes, you *should* be able to find the serial number by looking in the
accurate complete up-to-date spreadsheet of equipment inventory
records, or at least the previous-user-printed Dymo-label on the front
of the box. But if you had that quality of records, you probably
wouldn't need to be running password recovery anyway.

(Disclaimer: I'm currently working in a development lab, not
operations, so ideally this doesn't reflect the state of our
production data centers :slight_smile: Most of the time it doesn't reflect our
lab either, but occasionally it does, and of course loaner equipment
often arrives in random condition.

3

Related pet peeve: Inventory and asset control people that stick a sticker on
hardware and then expect to be able to scan the barcode at a later date. Works
fine if the barcode sticker actually ends up facing the front or the back of
the rack. But occasionally, the sticker ends up stuck on an empty space on the
printed circuit board of a upgrade blade that's plugged into a chassis...

4

Dymo-style solutions are somewhat lacking when it comes to some complex
boxes.
Equipment configs, mods, firmware versions, etc can all be fitted onto a
nice big sheet that can be slipped back into the rack without much
problem in most <pun> cases </pun>

A nifty solution I often claim to have invented in the last century is
to spray-adhesive an A4 (or equivalent US size) plastic pocket/"punched
pocket" on the TOP face of the equipment before you slide it in, such
that a single piece of A4 just protrudes from the front of the rack when
you use a self-adhesive tab on it's TOP edge.

(the TOP 's above are emphasized, ignore them at your peril; in the
first <pun> case </pun> the plastic will be destroyed the first time the
equipment is de-racked and in the second the tab will pull off easily.
Problems can be prevented by placing two tabs on the paper, one on each
side, exactly over each other.)

The trick, to ensure subsequent re-insertion (which is much harder than
it seems if you don't) is to also firmly stick a tab to the UPPER INSIDE
of the plastic wallet opening. To re-insert, gently lift the plastic tab
up.

All of this takes up under a millimeter and (unless the equipment
designer was drunk) doesn't affect ventilation. On rolling ships,
however, the papers require a bit of insulation tape across adjacent
case-fronts after each use.

/end_stationary_geek_mode

pics off-list on request if that doesn't make sense.

Gord

5

Sounds like RFID FTW!

Actually, I have no idea if it'd work, maybe someone else does. Seems
like it'd be nice to be able to just wand a rack and poof out comes a
list of everything in it.

6

That would be excellent for both the administrator, and anyone walking
down the row with a wand in their pocket.

7

Barry's right, for at least some scenarios. If I have an unauthorized somebody
walking down the row with a wand in their pocket, the fact they have a wand in
their pocket is the least of my problems.

It's of course different if your biggest competitor is colo'd in the same
room, two cages over.

8

We have an internally written app that allows us to either find where in the data center a server is, or pull up a rack and see what's in it. It wouldn't be a very big leap to assign each rack a bar code and have an app (you could even write it as a smartphone app) that scans the bar code and looks up what's in the rack. Of course, without access to (authentication is required) the web app front end for the database of what's where, just scanning the bar code wouldn't get you anything but a rack serial number...so you don't have to worry about random people scanning the rack bar code.

BTW...a friend who works for a mostly failed .com patented something like this some years ago. I think his patent was actually for a system in which a bar code on the front of a server could be scanned by a portable device, and you'd get current system health information for that system.

9

I'm not sure there's an attack vector utilizing inventory ID numbers. Even if there is, they can just as easily scan a barcode or read a label from that distance, so I'm not sure there's a huge difference.

Best Regards,
Nathan Eisenberg

10

That would be excellent for both the administrator, and anyone walking

> down the row with a wand in their pocket.

All an RFID wand would give you is a unique id number for each tag in
range which someone with access to an inventory database would look up
to find the associated record for other info.

It would be mostly useless info to "anyone...with a wand."

I suppose my question is more in the realm of whether the environment
is too RF noisy for RFIDs to be reliable, do such systems exist at
that scale (can I buy 1,000 RFID tags and a wand? I'd think so but I
don't know.) Also, would RF shielding in racks make it tricky to get a
good wanding?

Anyhow, just a thought.

11

Barry's right, for at least some scenarios. If I have an unauthorized somebody
walking down the row with a wand in their pocket, the fact they have a wand in
their pocket is the least of my problems.

Encrypt the data?

12

There seem to be a lot of misconceptions about RFID tags. I'm hardly
an expert but I do know this much:

RFID tags are generic, you don't put data into them unique to your
application.

All they are is a range of long serial numbers guaranteed to be
globally unique, like ethernet macs more or less.

You get an RFID tag, associate it with a piece of equipment, enter the
tag serial number and other info INTO YOUR OWN INVENTORY DATABASE, and
stick it on the equipment.

Then you can later use a wand which can retrieve the RFID tag number
at some distance, a few feet, think: supermarket checkout.

The big advantage of RFIDs is that you don't need line of sight access
like you do with bar codes, they use RF, radio frequency.

Think: anti-shoplifting tags, most of them are basically RFID tags tho
older ones don't have a unique id which is why they had to be
physically removed or disabled.

More modern anti-shoplifting systems wand the tag id (possibly via an
externally printed bar code because point of sale (POS) systems aren't
quite there yet) into the POS system so the anti-shoplifting exit
system can look it up to see if the item has been paid for.

A system which also used these to track equipment being removed from
an area or building would be a relatively straightforward plus.

It may not stop someone but it might know exactly what time it passed
out the door to help with any investigation, or in a more secure
environment one might have to mark the RFID tag as authorized to go
out the door via some security process, or at least associate its
leaving with a security badge or whatever id is used.

It's much better than sliced bread for some apps except that they make
for really lousy BLTs.

13

Which is also a big disadvantage in a datacenter. Ever tried to use a radio in one?

The RF noise generated by digital equipment seriously erodes signal quality. Considering the relatively weak signal returned from RFID tags, I'd be surprised if you'd get any kind of useful range.

Has anybody tried it out?

14

RFID tags are generic, you don't put data into them unique to your
application.

Field programmable RFID-like tags do exist. They aren't common, but
they're out there.

15
16

Part of the original (or at least early) context for this thread was recovery of default passwords. If the password is F(ser#), it's only learnable if you know both F() and ser#. The vendor knows F() -- who knows ser#? If it's in an RFID tag, or is DBlookup(tag#,vendor_db), being able to read this admittedly-arbitrary number may indeed be a threat.

    --Steve Bellovin, http://www.cs.columbia.edu/~smb

17

I have something akin to experience in this arena at least as it applies
to the ambient RF environment and the security of the data transferred.
As a matter of fact the two usually go hand in hand. The issue that I
usually see is how to protect your new drivers license / passport / ID
badge (with embedded RFID) from someone stopping next to you at a subway
station with an RFID reader hidden in their briefcase, although densely
populated CoLo's wouldn't be much different. The preferred standard is
usually the FIPS 201 standard and is deployed at 13.56Mhz which ensures
you have to be pretty darn near the transceiver to "get a read" but also
makes the problem of ambient (RF) noise pretty much a non-issue. The
issue arises in tags placed so close together that they are in the read
field at the same time causing multiple emitters in the same channel.
Recent implementations have a built in collision avoidance mechanism
that eliminates the issue entirely in my testing (understanding channel
contention for this exercise is at most dozens of transmitters, and
wouldn't scale up to anything larger). These same recent implementations
use 3DES to secure the open-air channel, reducing prevalence of
man-in-the-middle type attacks. Finally, it is common now to retrieve
the encrypted contents of the RFID tags and require that a CA hierarchy
validate both sides of the transaction prior to decryption which can
contain 4K in the data sectors or more.

Brandon L.

18

FYI: Looked into this in my previous job-project, and bookmarked this as a
positive record of such:
http://www.datacenterknowledge.com/archives/2008/11/03/rfid-in-the-data-center/I
think it works.

***Stefan Mititelu
http://twitter.com/netfortius
http://www.linkedin.com/in/netfortius

19

Not if you change the default password like any sane admin does...

20

Steven Bellovin wrote:

There seem to be a lot of misconceptions about RFID tags. I'm hardly
an expert but I do know this much:

RFID tags are generic, you don't put data into them unique to your
application.

Not true, the simplest rfid tags are energized and play back whatever
string is embedded, passive tags, however, plenty of device that fall
under the moniker rfid are at a minimum field programmable. Moreover
when you get beyond passive tags, the devices can be found with full on
java stacks, challenge response system, fips certified crypto engines,
flash for stored value etc.