Home / server / Questions / 504069
In Process
William Hilsum
Asked: 2013-05-02 02:09:30 +0800 CST

How do I secure a Dell Idrac card?

  • 772

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.

security

4 Answers

  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.

    • 5

  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.

    • 3

  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.

    • 2

  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.

    • 2