How do I secure a Dell Idrac card?

Question

I'm trying to completely lock down a server which has to exist outside of a firewall/directly routed to the internet and whilst I have hardened the base OS to the best of my ability, I had a moment of horror when I thought that if the worst should happen and someone was able to gain access, it may be possible that the DRAC could be used as a back door to our management network.

As far as I am aware, it is not possible to just connect and run arbitrary commands, you need a username and password - however, if given unlimited time and root access, I suppose a brute force may be possible, so, I was wondering how would I go about securing the DRAC?

Other than the last crash screen feature, I can't really think of any reason that the local host even needs access to the DRAC, so, I would like to completely disable local access.

Is running the following sufficient from the drac:

racadm config -g cfgRacTune -o cfgRacTuneLocalConfigDisable 1

And by running this, are there any down sides?

I could only find a small guide for the old iDrac 5, but, I was wondering if anything has changed/been added since?

update

This is a dedicated Drac (add on) card with a dedicated network port and the management network is a completely different subnet/network.

Whilst logged on via SSH to the Drac, I notice that you can do some funky stuff, I simply want to make sure that if the box was ever rooted/hacked, it is not possible to log on to the DRAC (even if given unlimited time/brute force from host) and basically make sure it is completely 100% isolated.

Solution 1

Remote management controllers are generally problematic from a security perspective because they're fairly full-featured systems (the (i)DRAC series, like many others, is Linux-based) that are dropped onto a card with full access to your server hardware and rarely, if ever, updated. Accessing them from a dedicated management network (as you're doing) is a necessary minimum level of security.

You're concerned, however, about someone gaining access to your server and then managing to get through the DRAC into your management network. This is in theory possible but difficult because the data exchanged between the systems is fairly minimal. If you're willing to live with the drawbacks, disabling as much communication between the system and the DRAC as possible will reduce your attack surface.

One thing to be aware of is that local access to the DRAC requires administrative access to the OS running on the server but does not require authentication beyond that. If you're running Unix and run racadm or omconfig (or one of the IPMI tools) as root, you will have administrative access to the DRAC.

The main drawback to disabling local DRAC access with racadm config -g cfgRacTune -o cfgRacTuneLocalConfigDisable 1, is that you will no longer be able to change the DRAC's configuration locally, which will probably have the greatest potential impact if you need to reconfigure the DRAC's network settings at some point. Doing that will require care, because you could render yourself unable to configure it further remotely. As far as I can tell, you will still be able to modify DRAC settings through the server's BIOS even with local configuration disabled.

Note that this setting does not disable communication between the two; local programs will still be able to read configuration parameters from the DRAC. IPMI-based tools should see the same effects as racadm; all settings should be read-only, but things like sensor readings will still work. If you you have the OpenManage Server Administrator software installed, you'll have to see what DRAC-related settings you can alter with omconfig (hopefully, none).

Mxx mentioned disabling "OS To iDRAC Pass-through". I haven't worked with iDRAC7s yet (I have a few on order), but the documentation indicates that this is a faster communications channel between the main system and the DRAC. Disabling it probably won't make a functional difference for you--communication between the two will still take place, just over IPMI instead of via the NIC--but it also won't inconvenience you (since you want to limit communication as much as possible), so I'd go ahead and disable it.

Solution 2

Dell recommends the iDRAC port be on a physically dedicated LAN, and blows off many of the concerns one would rationally have about such a feature.

Solution 3

I'm not familiar with racadm commands, but in iDRAC7 gui, there's an option called OS To iDRAC Pass-through. Its description is:

Use this page to enable the internal system communication channel that provides a high-speed bi-directional in-band communication between iDRAC7 and the host operating system through a shared LOM or a dedicated NIC. This is applicable for systems that have Network Daughter Card (NDC) or LAN On Motherboard (LOM) devices.

I think this is something you would want to make sure is disabled.

Additionally, instead of using local user accounts, perhaps it makes sense to implement AD/LDAP authentication. That way you can setup failed login notification/lockouts.

Solution 4

What is your concern here? That your iDRAC, configured with a public IP is going to be compromised? Or that someone might compromise the host machine and somehow use the iDRAC to launch attacks against other management controllers?

For the former, I'd suggest you not leave the iDRAC directly exposed to the internet. Use some ACLs in your router to prevent unauthorized IPs from accessing it. If you can, put it on a private IP block so this is less of an issue.

For the latter, a similar thing works. Use router ACLs to ensure that the iDRAC can only talk to authorized management machines, and not to whatever the hell it feels like.

View more solutions

Comments

[asciiphil]

Do you have the dedicated NIC for your iDRAC or are you using one of the server's NICs? If the latter, are you sharing the NIC between the server and the iDRAC or are you reserving it for the iDRAC? If the iDRAC has its own NIC (either dedicated or reserved), is there a separate management network, or is management traffic carried on the same physical subnet that the server itself uses?

[William Hilsum]

@asciiphil - updating question in a few minutes...

[ewwhite]

What type of "funky stuff" are you referring to?

[William Hilsum]

@ewwhite - ok, not that funky! Just SSH/ping/basic network stuff to other hosts... my fear is if you have managed to get on locally, given unlimited time, can you brute force other devices on the management network.

[William Hilsum]

updating question in a few minutes... I am personally worried that AD/LDAP isn't enough... e.g. if given root access to the host, am I able to simply run arbitrary commands on the DRAC.

[William Hilsum]

The DRAC is on a private management network, however, the host is on a public IP - I am thinking worst case scenario, and if someone was to gain root access on the host, could they run attacks on the management network (or possibly further)..... I already protect everything to the best of my ability, but, there are some ports that need to be open and I am worried that there could be an exploit on the service that is public ally accessible that opens up these other vectors. I will look in to ACL on the management network.

[asciiphil]

Yes, LDAP authentication (or local authentication, if you're not using LDAP) only applies to remote access, and remote access in this case is already physically segregated from the server's network access.

[William Hilsum]

I feel evil saying this after reading how much you put in, but, after reading this answer... I don't really feel like anything has been answered and don't think this deserves the bounty... I already stated (first two paragraphs) that I am worried about that... 3rd paragraph - I know - that is why I am asking the question. 4th, well, I know that... 5th/6th - this is what I am worried about and what I need an answer on and you have just stated hopefully/not sure!

[asciiphil]

That seems fair. I've foregone marking answers as accepted on questions of mine because I didn't really feel the given answers really addressed what I was asking. Since I've looked into the security of DRACs, albeit mostly from the perspective of preventing the DRAC from being a vector for system compromise, I thought I'd add what information I could in the hopes that it might be helpful.