Restrict IPMI access on Dell BMC and iDRAC to an allowed IP range

Question

I'm trying to secure the iDRAC's and BMC's on some of my Dell servers (R210, R410, R510). I want to restrict access to IPMI commands to only a few IP addresses. I've successfully restricted access to the iDrac using the instructions from http://support.dell.com/support/edocs/software/smdrac3/idrac/idrac10mono/en/ug/html/racugc2d.htm#wp1181529 , but the IP restrictions do not affect IPMI. A separate management network is not practical at this time because of lack or ports and some Dell BMC's don't offer a separate port. I'm told by my networking group that our switches don't support trunking, so using the vlan tagging is not an option either.

Is there a way restrict the IPMI access to a list of allowed addresses?

FYI, for various reasons, I have a mix of Dell servers with BMC's, iDrac Express and iDrac enterprise management features.

Update: All out my boxes are in a switched environment. There is no NAT going on between my servers or my work desktop. I'm using ipmitool -I lanplus -H myhost -u root -p password -K sol activate" to talk to the serial console over IPMI.

Update2: While I'm in a switched environment, I don't have access to change the network switches, which are managed by a different department. The networking department doesn't like setting ACL's on routers and can't/won't use vlan tagging on our ports.

Why do you need IPMI at all if iDRAC is available? Do you need this for cases, where iDRAC is not available? — Nils, Jun 16 '12 at 21:15
The majority of our boxes don't have DRACs, so I need it for them. I can use IPMI to get a serial console for the DRAC express card, which don't offer a remote console. TO add to the mix, we might be adding HP server to the mix. We have remote KVM and power steips, or DRACs for most or all of our machines, but the interfaces are different, and it's easy to connect to the wrong machine. I want ot use IPMI to provide a unified way to manage servers. I also want to start using scripts to automates some things, so consistency is key. — edgester, Jun 16 '12 at 23:06
Since I always used a DRAC-version that allowed for a remote console - can you outline how that serial console via ipmi works? Additional question (please update question): Do you have a fully switched environment, or are all of your servers placed "behind" routers? — Nils, Jun 17 '12 at 20:21

Andrew Smith · Accepted Answer · 2012-06-21T08:32:30.320

4

If you have switched environment and you need to restrict access to IPMI, the way to do it is to make ACL policy on the core switch, so this way you can restrict access from particular networks to this subnet or service. You can use only INPUT chain to do this, for example, if your IPMI is on 192.168.110.0/24 VLAN1 and your Desktop is on 10.0.0.0/24 VLAN2 and isolated LAN on 10.0.1.0/24 VLAN3, you can setup rule as on below example. However, if you want to restrict it on the same subnet, it is not done and cannot be done this way, the restricted client must be on different LAN (routable ip range).

So simply, on the core switch you can load the policy and specify

#Allow Broadcast
From Any To ff:ff:ff:ff:ff:ff Permit

#Allow Multicast
From Any To 224.0.0.0/4 Permit

#Anti-spoofing rules
From 192.168.110.0/24 to 0.0.0.0/0 VLAN1 Permit
From 0.0.0.0/0 to 192.168.110.0/24 VLAN1 Permit
From 10.0.0.0/24 to 0.0.0.0/0 VLAN2 Permit
From 0.0.0.0/0 to 10.0.0.0/24 VLAN2 Permit
From 10.0.1.0/24 to 0.0.0.0/0 VLAN3 Permit
From 0.0.0.0/0 to 10.0.1.0/24 VLAN3 Permit

#Permit IPMI from VLAN2
#You can narrow this rule to allow IPMI only
From 10.0.0.0/24 to 192.168.110.0/24 Permit
From 192.168.110.0/24 to 10.0.0.0/24 Permit

#Allow VLAN3 to VLAN1
From 10.0.1.0/24 to 10.0.0.0/24 Permit
From 10.0.0.0/24 to 10.0.1.0/24 Permit

#Block any other VLAN to VLAN communication, and allow internet browsing for VLAN3 (destination 0.0.0.0/0)
From 10.0.0.0/8 to 10.0.0.0/8 Deny
From 192.168.0.0/16 to 192.168.0.0/16 Deny
From 10.0.0.0/8 to 192.168.0.0/16 Deny
From 192.168.0.0/16 to 10.0.0.0/8 Deny

From 10.0.1.0/24 to 0.0.0.0/0 Permit
From 0.0.0.0/0 to 10.0.1.0/24 Permit

From 0.0.0.0/0 to 0.0.0.0/0 Deny

ps. Your core switch (router forwarding between VLANs) definitely supports this kind of ACL.

edited Jun 21 '12 at 08:32

answered Jun 21 '12 at 07:51

Andrew Smith

1,123
13
23

ps. Your NAT device could be 10.0.3.1 in this case, so this would be default gateway for your core switch. – Andrew Smith Jun 21 '12 at 08:33
ps2. This is better method than anything else, because it gives secure and stable IPMI LAN and built-in firewalls and other restrictions do not, the IPMIs even with some kind of filtering will crash if there is e.g. some things flooding or scanning, so the core switch ACL is not only needed to secure it mainly from the public. – Andrew Smith Jun 21 '12 at 08:40
Our networking group doesn't want to set ACL's or use vlan tagging on the same port. On top of that, our server rooms are spread between three buildings. If I can't do it on the idrac or host itself, then it's a non-starter. – edgester Jun 23 '12 at 03:14
You could use "Bound network to VLAN", so you dont use tagging on the port but the switch is tagging packets if they match specific address. ACLs doesnt slow down anything as well. – Andrew Smith Jun 24 '12 at 18:49
Sorry, I'm not allowed to use VLANs, and BMC's don't have a extra network port to plug into a separate network. I can't modify the switching/routing rules at all. – edgester Jun 24 '12 at 19:17
I'm giving some, but not all of the bounty, because I can't use this solution in my environment, due to politics. I was asking if there was something I could do within the DRAC/VMC itself. – edgester Jun 24 '12 at 19:21
You cant secure DRAC on itself because you need to do it on the device connecting to it. Otherwise is not big difference to just changing password. Also, policy on the router and network admin separation is a critical and major requirement. It's not good solution to run IPMI and servers on the same subnet for many reasons - stability, security, they will either start crashing due to broadcast from switch or multicast from windows servers etc. – Andrew Smith Jun 24 '12 at 19:51
I'm not saying that it's a great idea, but it's what I'm stuck with for now. – edgester Jun 25 '12 at 03:57

Brennan · Answer 2 · 2012-06-24T00:39:12.163

Here is an alternative approach, which may or may not be feasible depending on your switch functionality and feature set.

You'll need to do your own research in order to expand this, based on the BMC, IPMI, and DRAC versions you have.

Below is a list of DRAC's ports and protocols. Configure your entire network to only make these accessible to a select few hosts, or better yet, a bastion host, alternatively, reset connections using an IPS which may not work for any UDP based protocols..

DRAC6

iDRAC6 Server Listening Ports 
Port Number  Function
22* SSH
23* Telnet
80* HTTP
443* HTTPS
623 RMCP/RMCP+
5900* Console Redirection keyboard/mouse, Virtual Media Service, Virtual Media Secure Service, Console Redirection video
Configurable port*

Table 1-4. iDRAC6 Client Ports 

Port Number Function
25 SMTP
53 DNS
68 DHCP-assigned IP address
69 TFTP
162 SNMP trap
636 LDAPS
3269 LDAPS for global catalog (GC)

DRAC5

Port Number     Function
(Server ports)
22*             Secure Shell (SSH)
23*             Telnet
80*             HTTP
161         SNMP Agent
443*            HTTPS
623             RMCP/RMCP+
3668*       Virtual Media server
3669*       Virtual Media Secure Service
5900*       Console Redirection keyboard/mouse
5901*       Console Redirection video

Configurable port*

Table 1-3. DRAC 5 Client Ports
Port Number     Function
25          SMTP
53          DNS
68          DHCP-assigned IP address
69          TFTP
162             SNMP trap
636             LDAPS
3269            LDAPS for global catalog (GC)

DRAC 4

 
DRAC 4 Port Number Used For 

Ports on DRAC 4 listening for connection (server):
23 Telnet (configurable)
80 HTTP (configurable)
161 SNMP Agent (not configurable)
443 HTTPS (configurable)
3668 Virtual Media server (configurable)
5869 Remote racadm spcmp server (not configurable)
5900 Console Redirection (configurable)

Ports that DRAC 4 uses as a client:
25 SMTP (not configurable)
69 TFTP (not configurable)
162 SNMP trap (not configurable)
53 DNS
636 LDAP
3269 LDAP for global catalog (GC)

DRAC 3 ports

Port Number Protocol Usage Is the Port Configurable?

7 UDP/TCP Used for Ping (Echo) No
22 SSH Secure Shell default port No
23 Telnet Telnet default port Yes
25 SMTP Simple Mail Transfer Protocol port No
53 DNS Domain name server (DNS) default port No
68 bootstrap Wake-on-LAN default port Yes
69 TFTP Trivial File Transfer Protocol port No 
80 HTTP  DRAC 4, DRAC III, DRAC I11/XT, ERA, ERA/O, ERA/MC, and DRAC/MC default port Yes
161 SNMP (get/set) SNMP agent port used by Dell OpenManage Array Manager, DRAC 4, DRAC III, DRAC I11/XT, ERA, ERA/O, ERA/MC, and DRAC/MC No
162 SNMP (traps) SNMP traps listener port No
623  Telnet Baseboard Management Controller (BMC) Management Utility default port Yes
636 LDAP Lightweight Directory Access Protocol (LDAP) port No
443 HTTPS (SSL) DRAC 4 default port Yes
1311 HTTPS (SSL) Dell OpenManage Server Administrator default port Yes
2148 Used by Array Manager clients to connect 
2606 TCP/IP Communication between the Dell OpenManage IT Assistant connection service and network monitoring service Yes
2607 HTTPS Communication between the IT Assistant user interface and connection service
Yes
3269  LDAP LDAP for global catalog (GC) port No
3668 VMS Virtual Media server Yes
4995 TCP/IP Dell OpenManage Client Connector (OMCC) default port Yes
5869 spcmp server Remote racadm spcmp server No
5900 VNC proxy server Console redirection default port for DRAC III, DRAC III/XT, ERA, and ERA/O Yes 5900

References used:

DRAC 6 http://support.dell.com/support/edocs/software/smdrac3/idrac/idrac11mono/en/ug/html/racugc1.htm

DRAC 5 http://lists.us.dell.com/pipermail/linux-poweredge/2006-July/026495.html

DRAC 4 http://support.dell.com/support/edocs/software/smdrac3/drac4/1.1/en/UG/racugc1.htm

DRAC 3 http://support.dell.com/support/edocs/software/smsom/4.4/en/ug/security.htm