{"id":23396,"date":"2026-05-18T13:43:04","date_gmt":"2026-05-18T13:43:04","guid":{"rendered":"https:\/\/atalnetworks.com\/?p=23396"},"modified":"2026-05-18T14:23:38","modified_gmt":"2026-05-18T14:23:38","slug":"how-to-use-ipmi-out-of-band-server-management","status":"publish","type":"post","link":"https:\/\/atalnetworks.com\/de\/how-to-use-ipmi-out-of-band-server-management\/","title":{"rendered":"How to Use IPMI for Out-of-Band Server Management"},"content":{"rendered":"

IPMI (Intelligent Platform Management Interface) is a standardized protocol for out-of-band server management, giving you hardware-level access to a server independent of its operating system. The BMC (Baseboard Management Controller) is the dedicated processor on the server motherboard that implements IPMI. It runs on standby power and stays operational even when the OS crashes, SSH becomes unreachable, or the server powers off. Through IPMI, you can power a server on or off, read temperature and fan sensors, view the hardware event log, launch a KVM remote console, and access the server via Serial over LAN, all without touching the machine physically. IPMI 2.0, the current standard published by the DMTF on February 12, 2004, added Serial over LAN, enhanced RMCP+ authentication, VLAN support, and cipher suites. This guide covers everything from initial setup to security hardening, incident recovery, and Ansible automation.\u00a0<\/span><\/p>\n

Every data center operator knows the situation: a production server stops responding. SSH times out. Ping fails. You have a choice between opening an urgent support ticket and waiting for a technician, or connecting directly to the server’s BMC through IPMI and resolving the issue yourself in minutes.<\/span><\/p>\n

IPMI is the difference between those two outcomes.<\/span><\/p>\n

This guide covers the complete IPMI workflow, BMC architecture, setup commands, power control, sensor monitoring, KVM console, SOL access, network isolation, security hardening, Redfish integration, and Ansible automation. Every section is practical, every command is tested, and every security recommendation reflects real CVEs, not generic advice.<\/span><\/p>\n

\"IPMI1<\/h2>\n

IPMI and BMC: How Out-of-Band Management Actually Works<\/b><\/h2>\n

The BMC is a separate SoC (System-on-Chip) embedded on the server motherboard. It has its own processor, its own NIC (either dedicated or shared with the host), its own memory, and its own firmware running independently of the host OS. The BMC draws power from the 3.3V standby rail, which means it stays operational when the main server is powered off as long as the power supply is plugged in.<\/span><\/p>\n

This physical separation is the entire point of out-of-band management. Your SSH connection requires a working OS, a working network stack, and a working NIC driver. The moment any of those fails, SSH dies. IPMI never touches any of them.<\/span><\/p>\n

In-Band vs Out-of-Band: The Critical Difference<\/b><\/h3>\n\n\n\n\n\n\n\n\n\n
Factor<\/b><\/td>\nIn-Band Management<\/b><\/td>\nOut-of-Band (IPMI)<\/b><\/td>\n<\/tr>\n
Requires OS to be running<\/span><\/td>\nYes<\/span><\/td>\nNo<\/span><\/td>\n<\/tr>\n
Survives kernel panic<\/span><\/td>\nNo<\/span><\/td>\nYes<\/span><\/td>\n<\/tr>\n
Survives network driver crash<\/span><\/td>\nNo<\/span><\/td>\nYes<\/span><\/td>\n<\/tr>\n
Works with server powered off<\/span><\/td>\nNo<\/span><\/td>\nYes (standby power)<\/span><\/td>\n<\/tr>\n
Tools<\/span><\/td>\nSSH, RDP, SNMP<\/span><\/td>\nipmitool, iDRAC, iLO, iKVM<\/span><\/td>\n<\/tr>\n
Physical path<\/span><\/td>\nProduction NIC<\/span><\/td>\nDedicated or shared management NIC<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Concrete scenario: a server running a busy database enters a kernel panic at 3 am. The OOM killer ran, a driver deadlocked, and the kernel threw a null pointer dereference. SSH dies instantly. Your monitoring system fires an alert. You open an ipmitool connection to the BMC, read the System Event Log to see what triggered the panic, launch the KVM console to view the kernel crash output on screen, and power-cycle the server, all within five minutes without a support ticket.<\/span><\/p>\n

IPMI Architecture: BMC, IPMB, SDR, and SEL<\/b><\/h3>\n

Five components form the IPMI management stack. Each has a specific role:<\/span><\/p>\n

    \n
  1. BMC (Baseboard Management Controller)<\/b>: the main IPMI processor embedded on the motherboard; handles all management functions<\/span><\/li>\n
  2. IPMB (Intelligent Platform Management Bus)<\/b>: I\u00b2C-based bus connecting the BMC to satellite management controllers on expansion cards and chassis components<\/span><\/li>\n
  3. ICMB (Intelligent Chassis Management Bus)<\/b>: connects management controllers across multiple chassis in a blade or rack system<\/span><\/li>\n
  4. SDR (Sensor Data Record)<\/b>: a database stored on the BMC containing sensor definitions, threshold values, and alert conditions for every hardware sensor<\/span><\/li>\n
  5. SEL (System Event Log)<\/b>: a hardware event log stored on the BMC that records every monitored hardware event with timestamps; survives OS crashes and power cycles<\/span><\/li>\n<\/ol>\n

    Understanding the SDR and SEL is the difference between reactive and proactive server management. The SDR stores the thresholds that trigger alerts. The SEL records every time a threshold was crossed. Many hardware failures leave SEL entries hours or days before the system fails, correctable memory errors accumulating before an uncorrectable error crashes the system, fan RPM dropping below threshold before a CPU overheats.<\/span><\/p>\n

    \"IPMI<\/h2>\n

    IPMI Versions: 1.0, 1.5, and 2.0<\/b><\/h2>\n

    IPMI has evolved through three major versions. Knowing which version your hardware supports determines which features are available.<\/span><\/p>\n\n\n\n\n\n\n\n
    Version<\/b><\/td>\nRelease Date<\/b><\/td>\nKey Features<\/b><\/td>\n<\/tr>\n
    IPMI 1.0<\/span><\/td>\nSeptember 16, 1998<\/span><\/td>\nBasic sensor monitoring, power control, event logging<\/span><\/td>\n<\/tr>\n
    IPMI 1.5<\/span><\/td>\nFebruary 21, 2001<\/span><\/td>\nIPMI over LAN, IPMI over serial\/modem, LAN alerting<\/span><\/td>\n<\/tr>\n
    IPMI 2.0<\/span><\/td>\nFebruary 12, 2004<\/span><\/td>\nSerial over LAN (SOL), RMCP+ authentication (RAKP), VLAN support, cipher suites, firmware firewall<\/span><\/td>\n<\/tr>\n
    IPMI 2.0 Rev 1.1<\/span><\/td>\nOctober 1, 2013<\/span><\/td>\nIPv6 addressing support added<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Virtually every server sold after 2004 supports IPMI 2.0. If you are running hardware from the last 20 years, you have IPMI 2.0. Three IPMI 2.0 features matter most in daily operations:<\/span><\/p>\n

    **Serial over LAN (SOL): Text console access through the IPMI channel, showing BIOS output, kernel boot messages, and OS console before SSH becomes available. SOL requires serial console configuration in BIOS and OS bootloader (covered in the KVM and SOL section below).<\/span><\/p>\n

    **RMCP+ with RAKP: The IPMI 2.0 authentication protocol using HMAC-based key exchange. Stronger than IPMI 1.5’s MD5 authentication. Critical note: RMCP+ still has known vulnerabilities through RAKP hash attacks (CVE-2013-4786) if cipher 0 is enabled: covered in the security section.<\/span><\/p>\n

    **Cipher Suites: AES-128 channel encryption for IPMI 2.0 communications. Cipher 17 (HMAC-SHA256 + AES-CBC-128) is the secure option. Cipher 0 allows authentication bypass. Cipher 3 uses MD5 which is cryptographically broken. These specifics matter: the security section covers exact commands to disable the insecure ciphers.<\/span><\/p>\n

    \"Vendor<\/h2>\n

    Vendor Implementations: iDRAC, iLO, Supermicro IPMI, XClarity, and IMM<\/b><\/h2>\n

    IPMI 2.0 is the standard, but vendors build proprietary implementations on top of it. Standard ipmitool commands work across all of them for core operations. Vendor-specific features require vendor tools.<\/span><\/p>\n\n\n\n\n\n\n\n\n
    Vendor<\/b><\/td>\nIPMI Implementation<\/b><\/td>\nWeb Interface URL<\/b><\/td>\nDefault Username<\/b><\/td>\nDefault Password<\/b><\/td>\n<\/tr>\n
    Dell<\/span><\/td>\niDRAC (Integrated Dell Remote Access Controller)<\/span><\/td>\nhttps:\/\/IDRAC_IP<\/span><\/td>\nroot<\/span><\/td>\ncalvin<\/span><\/td>\n<\/tr>\n
    HP \/ HPE<\/span><\/td>\niLO (Integrated Lights-Out)<\/span><\/td>\nhttps:\/\/ILO_IP<\/span><\/td>\nadmin<\/span><\/td>\n(printed on server label)<\/span><\/td>\n<\/tr>\n
    Supermicro<\/span><\/td>\nSupermicro IPMI<\/span><\/td>\nhttps:\/\/IPMI_IP<\/span><\/td>\nADMIN<\/span><\/td>\nADMIN<\/span><\/td>\n<\/tr>\n
    Lenovo<\/span><\/td>\nXClarity Controller (XCC)<\/span><\/td>\nhttps:\/\/XCC_IP<\/span><\/td>\nUSERID<\/span><\/td>\nPASSW0RD<\/span><\/td>\n<\/tr>\n
    IBM<\/span><\/td>\nIMM2 (Integrated Management Module 2)<\/span><\/td>\nhttps:\/\/IMM_IP<\/span><\/td>\nUSERID<\/span><\/td>\nPASSW0RD<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    These are factory defaults. Change every one of them immediately after first login. Every default password above is publicly documented, indexed by Shodan, and actively exploited by automated scanners. Thousands of internet-accessible BMC interfaces still run on factory credentials.<\/span><\/p>\n

    Vendor extensions beyond IPMI standard:<\/b> iDRAC adds WSMAN, Redfish, and Lifecycle Controller for OS deployment. iLO adds the iLO RESTful API. XClarity adds XClarity Administrator integration for fleet management. Standard ipmitool commands cover power control, sensors, SEL, and SOL across all vendors. For vendor-specific features, Dell uses <\/span>racadm<\/span>, HP uses <\/span>hpilo<\/span> and the iLO API, and Supermicro uses <\/span>IPMIView<\/span> and <\/span>SMCIPMITool<\/span>.<\/span><\/p>\n

    \"Setting<\/h2>\n

    Setting Up IPMI Access: Step-by-Step<\/b><\/h2>\n

    Before running any management commands, the BMC needs a network address and your machine needs ipmitool installed.<\/span><\/p>\n

    Install ipmitool:<\/b><\/p>\n

    # Debian \/ Ubuntu<\/span><\/p>\n

    sudo apt update && sudo apt install -y ipmitool<\/span><\/p>\n

     <\/p>\n

    # RHEL \/ CentOS \/ Rocky \/ AlmaLinux<\/span><\/p>\n

    sudo yum install -y ipmitool<\/span><\/p>\n

    # or on newer systems:<\/span><\/p>\n

    sudo dnf install -y ipmitool<\/span><\/p>\n

     <\/p>\n

    # Load required kernel modules for in-band access<\/span><\/p>\n

    sudo modprobe ipmi_msghandler<\/span><\/p>\n

    sudo modprobe ipmi_devintf<\/span><\/p>\n

    sudo modprobe ipmi_si<\/span><\/p>\n

     <\/p>\n

    # Make modules persistent across reboots<\/span><\/p>\n

    echo “ipmi_msghandler” | sudo tee -a \/etc\/modules<\/span><\/p>\n

    echo “ipmi_devintf”\u00a0 \u00a0 | sudo tee -a \/etc\/modules<\/span><\/p>\n

    echo “ipmi_si” \u00a0 \u00a0 \u00a0 \u00a0 | sudo tee -a \/etc\/modules<\/span><\/p>\n

     <\/p>\n

    # Verify the device node exists<\/span><\/p>\n

    ls \/dev\/ipmi0<\/span><\/p>\n

     <\/p>\n

    Step 1: Check BMC Network Configuration<\/b><\/h3>\n

    # View current BMC network settings (in-band, from the running OS)<\/span><\/p>\n

    sudo ipmitool lan print 1<\/span><\/p>\n

     <\/p>\n

    # Expected output:<\/span><\/p>\n

    # IP Address Source : Static Address<\/span><\/p>\n

    # IP Address\u00a0 \u00a0 \u00a0 \u00a0 : 192.168.100.50<\/span><\/p>\n

    # Subnet Mask \u00a0 \u00a0 \u00a0 : 255.255.255.0<\/span><\/p>\n

    # Default Gateway \u00a0 : 192.168.100.1<\/span><\/p>\n

    # MAC Address \u00a0 \u00a0 \u00a0 : XX:XX:XX:XX:XX:XX<\/span><\/p>\n

    # VLAN ID \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 : Disabled<\/span><\/p>\n

     <\/p>\n

    # If channel 1 returns nothing, try channel 2 or 3<\/span><\/p>\n

    sudo ipmitool lan print 2<\/span><\/p>\n

     <\/p>\n

    Step 2: Set a Static IP for the BMC<\/b><\/h3>\n

    Static IP configuration is mandatory for production environments. DHCP addresses change and you lose access.<\/span><\/p>\n

    # Set static IP assignment mode<\/span><\/p>\n

    sudo ipmitool lan set 1 ipsrc static<\/span><\/p>\n

     <\/p>\n

    # Set the BMC IP address<\/span><\/p>\n

    sudo ipmitool lan set 1 ipaddr 192.168.100.50<\/span><\/p>\n

     <\/p>\n

    # Set subnet mask<\/span><\/p>\n

    sudo ipmitool lan set 1 netmask 255.255.255.0<\/span><\/p>\n

     <\/p>\n

    # Set default gateway<\/span><\/p>\n

    sudo ipmitool lan set 1 defgw ipaddr 192.168.100.1<\/span><\/p>\n

     <\/p>\n

    # Enable IPMI over LAN<\/span><\/p>\n

    sudo ipmitool lan set 1 access on<\/span><\/p>\n

     <\/p>\n

    # Verify the changes<\/span><\/p>\n

    sudo ipmitool lan print 1<\/span><\/p>\n

     <\/p>\n

    Critical:<\/b> Never put the BMC IP on the same subnet as your public-facing production NIC. The management interface must sit on a separate, isolated network, covered fully in the network architecture section.<\/span><\/p>\n

    Step 3: Access via Web Browser<\/b><\/h3>\n

    Open a browser and navigate to <\/span>https:\/\/[BMC_IP]<\/span>. Accept the self-signed certificate. Log in with vendor credentials from the table above and change the password immediately.<\/span><\/p>\n

    The dashboard shows: current power state, CPU and memory health, recent SEL entries, and active alerts. The Remote Console or Virtual Console menu item launches the KVM over IP session. Note that modern BMC firmware (post-2015 iDRAC 7+, iLO 4+, Supermicro X10+) uses an HTML5 console that works in any modern browser without plugins. Older firmware requires a Java KVM applet, a clear sign that firmware needs updating.<\/span><\/p>\n

    Step 4: Connect via ipmitool Remotely (Out-of-Band)<\/b><\/h3>\n

    # Remote out-of-band connection syntax<\/span><\/p>\n

    # -H = BMC IP address<\/span><\/p>\n

    # -U = username<\/span><\/p>\n

    # -P = password<\/span><\/p>\n

    # -I lanplus = IPMI 2.0 with RMCP+ (required for encrypted sessions)<\/span><\/p>\n

    # -C 17 = cipher suite 17 (SHA256 + AES256, most secure)<\/span><\/p>\n

     <\/p>\n

    ipmitool -H 192.168.100.50 -U admin -P yourpassword -I lanplus -C 17 chassis status<\/span><\/p>\n

     <\/p>\n

    # Check power state<\/span><\/p>\n

    ipmitool -H 192.168.100.50 -U admin -P yourpassword -I lanplus -C 17 power status<\/span><\/p>\n

     <\/p>\n

    # Get BMC firmware version and hardware info<\/span><\/p>\n

    ipmitool -H 192.168.100.50 -U admin -P yourpassword -I lanplus -C 17 bmc info<\/span><\/p>\n

     <\/p>\n

    Always use <\/b>-I lanplus<\/b> for remote connections, not <\/span>-I lan<\/span>. The <\/span>lan<\/span> interface uses IPMI 1.5 with MD5 authentication. The <\/span>lanplus<\/span> interface uses IPMI 2.0 RMCP+ with AES-128 encryption. Adding <\/span>-C 17<\/span> explicitly requests the strongest cipher suite and avoids falling back to weaker ciphers.<\/span><\/p>\n

    \"core<\/h2>\n

    Core IPMI Operations: Power Control, Sensors, and Event Logs<\/b><\/h2>\n

    This section is the practical reference. Every command runs over an out-of-band connection using the pattern above.<\/span><\/p>\n

    Power Control<\/b><\/h3>\n

    # Check current power state<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 power status<\/span><\/p>\n

     <\/p>\n

    # Power on (works even when server is completely off on standby power)<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 power on<\/span><\/p>\n

     <\/p>\n

    # Graceful shutdown, sends ACPI signal, OS shuts down cleanly<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 power soft<\/span><\/p>\n

     <\/p>\n

    # Hard power off, immediate, no OS shutdown; use only when OS is unresponsive<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 power off<\/span><\/p>\n

     <\/p>\n

    # Hard power cycle, off then on with pause; correct for hung servers<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 power cycle<\/span><\/p>\n

     <\/p>\n

    # Hardware reset, sends RESET signal, like pressing the physical reset button<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 power reset<\/span><\/p>\n

     <\/p>\n

    # Detailed chassis status (power state, intrusion, buttons)<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 chassis status<\/span><\/p>\n

     <\/p>\n

    Use <\/span>power soft<\/span> whenever the OS is still running, it shuts down gracefully and protects filesystem integrity. Use <\/span>power cycle<\/span> for unresponsive servers rather than separate <\/span>power off<\/span> + <\/span>power on<\/span> commands, the cycle command includes a mandatory pause between off and on states that prevents power supply stress.<\/span><\/p>\n

    Hardware Sensor Monitoring<\/b><\/h3>\n

    # List all sensors (temperature, voltage, fan speed, current)<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 sdr list full<\/span><\/p>\n

     <\/p>\n

    # Filter by sensor type<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 sdr type Temperature<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 sdr type Fan<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 sdr type Voltage<\/span><\/p>\n

     <\/p>\n

    # Get sensor readings with threshold values<\/span><\/p>\n

    # Thresholds show: Lower Non-Recoverable, Lower Critical, Lower Non-Critical<\/span><\/p>\n

    # and: Upper Non-Critical, Upper Critical, Upper Non-Recoverable<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 sensor list<\/span><\/p>\n

     <\/p>\n

    # Watch live sensor readings (refreshes every 2 seconds)<\/span><\/p>\n

    watch -n 2 “ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 sdr list full \\<\/span><\/p>\n

    \u00a0\u00a0| grep -iE ‘Temp|Fan|Volt'”<\/span><\/p>\n

     <\/p>\n

    The SDR database contains threshold values for every sensor. When a reading exceeds the Upper Critical threshold, the BMC typically triggers an automatic protective shutdown. Catching a temperature or fan reading at the Upper Non-Critical level, before it hits Upper Critical, gives you time to respond before the hardware takes the protective action for you.<\/span><\/p>\n

    System Event Log (SEL): The Most Underused IPMI Feature<\/b><\/h3>\n

    # View the SEL with full descriptions<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 sel elist<\/span><\/p>\n

     <\/p>\n

    # SEL info (total entries, free space)<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 sel info<\/span><\/p>\n

     <\/p>\n

    # Save SEL to a log file before clearing<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 sel elist \\<\/span><\/p>\n

    \u00a0\u00a0> \/var\/log\/sel-$(hostname)-$(date +%Y%m%d-%H%M%S).txt<\/span><\/p>\n

     <\/p>\n

    # Clear the SEL after saving and resolving issues<\/span><\/p>\n

    ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 sel clear<\/span><\/p>\n

     <\/p>\n

    The SEL stores hardware events with precise timestamps, power supply failures, over-temperature events, correctable and uncorrectable memory errors, and chassis intrusion events. These entries survive server reboots, OS crashes, and power cycles because they live in the BMC’s non-volatile storage, not on the main server disk.<\/span><\/p>\n

    A server that rebooted unexpectedly with no OS crash dump almost always left SEL entries. Check the SEL first, before application logs, before OS logs. A correctable memory error entry at 2:47am followed by a system restart at 2:47am is a failing DIMM, not a random reboot. That distinction saves hours of unnecessary troubleshooting.<\/span><\/p>\n

    \"KVM<\/h2>\n

    KVM Console and Serial over LAN: Remote Screen Access<\/b><\/h2>\n

    IPMI gives you two ways to access a remote console when SSH is unavailable.<\/span><\/p>\n

    KVM over IP: Full Graphical Console<\/b><\/h3>\n

    KVM over IP streams the server’s physical display output to your browser, along with keyboard and mouse input. You see exactly what a physical monitor connected to the server would show: BIOS\/UEFI setup screens, POST messages, the OS boot sequence, and the desktop or terminal after boot.<\/span><\/p>\n

    Combined with virtual media (ISO mounting), KVM over IP gives you the same capability as standing in front of the server. You can boot from a remote ISO, reinstall the OS, enter BIOS to change boot settings, and respond to a boot failure, all remotely.<\/span><\/p>\n

    Launch the KVM console from the web interface:<\/b><\/p>\n

      \n
    1. Log into https:\/\/[BMC_IP]<\/span><\/li>\n
    2. Navigate to the remote console section (Dell: Virtual Console; HP: Remote Console; Supermicro: Remote Control)<\/span><\/li>\n
    3. Select HTML5 Console for modern firmware or Java Console for legacy firmware<\/span><\/li>\n
    4. HTML5 works in any browser without plugins; Java requires JRE and opens port 5900<\/span><\/li>\n<\/ol>\n

      If your firmware only offers a Java console, prioritize BMC firmware updates. The Java applet is deprecated, has known security issues, and frequently breaks with OS security updates that restrict unsigned Java execution.<\/span><\/p>\n

      Serial over LAN (SOL): Text Console Access<\/b><\/h3>\n

      SOL is a text-only serial console over the IPMI connection. It captures the server’s serial port output and sends it through the IPMI channel, giving you visibility into BIOS text output, the bootloader, kernel early boot messages, and OS console, before the OS reaches the point where SSH works.<\/span><\/p>\n

      SOL requires serial console configuration in both BIOS and the OS bootloader.<\/span><\/p>\n

      Configure GRUB for serial console (Linux):<\/b><\/p>\n

      # Edit GRUB configuration<\/span><\/p>\n

      sudo nano \/etc\/default\/grub<\/span><\/p>\n

       <\/p>\n

      # Add these lines<\/span><\/p>\n

      GRUB_CMDLINE_LINUX=”console=tty0 console=ttyS0,115200n8″<\/span><\/p>\n

      GRUB_TERMINAL=”console serial”<\/span><\/p>\n

      GRUB_SERIAL_COMMAND=”serial –unit=0 –speed=115200″<\/span><\/p>\n

       <\/p>\n

      # Apply the changes<\/span><\/p>\n

      sudo update-grub<\/span><\/p>\n

       <\/p>\n

      # Reboot to activate serial console<\/span><\/p>\n

      sudo reboot<\/span><\/p>\n

       <\/p>\n

      Also enable serial console in BIOS before using SOL:<\/b> Navigate to BIOS Advanced Settings and enable Serial Console Redirection on COM1 or COM2 at 115200 baud. The exact path varies by vendor, check your motherboard documentation.<\/span><\/p>\n

      SOL connection commands:<\/b><\/p>\n

      # Activate SOL console (connects to serial console through IPMI)<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 sol activate<\/span><\/p>\n

       <\/p>\n

      # The console will appear after pressing Enter<\/span><\/p>\n

      # To exit: use Ctrl+] or the sequence ~ + .<\/span><\/p>\n

       <\/p>\n

      # Deactivate from a second terminal if the session is stuck<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 sol deactivate<\/span><\/p>\n

       <\/p>\n

      # Check SOL configuration<\/span><\/p>\n

      sudo ipmitool sol info<\/span><\/p>\n

       <\/p>\n

      SOL is the correct tool for low-bandwidth connections (VPN over a slow link), automated recovery scripts, and situations where you only need text output. KVM is the correct tool when you need a graphical display or need to interact with a BIOS that does not support text mode.<\/span><\/p>\n

      \"IPMI<\/h2>\n

      IPMI Network Architecture: Isolation and VLAN Configuration<\/b><\/h2>\n

      The most dangerous IPMI deployment mistake is putting the BMC on the same network as production traffic, or worse, exposing it to the internet. Because the BMC has hardware-level server control (power, console, firmware), it requires stricter network isolation than any other service you run.<\/span><\/p>\n

      The Three-Network Architecture<\/b><\/h3>\n

      Correct IPMI deployment uses three separate networks:<\/span><\/p>\n

      Production network:<\/b> Application traffic, SSH from jump hosts, load balancer backends. Standard server NICs.<\/span><\/p>\n

      Management network (out-of-band):<\/b> BMC interfaces only. Dedicated out-of-band management switch. Isolated VLAN with no routing to the production network or internet. Access only via VPN or a hardened bastion host.<\/span><\/p>\n

      Bastion host (jump server):<\/b> A single hardened server with two NICs, one on the production network, one on the management network. All IPMI access routes through this bastion host. The bastion host logs all sessions and requires MFA for access.<\/span><\/p>\n

      Internet<\/span><\/p>\n

      \u00a0\u00a0\u00a0|<\/span><\/p>\n

      \u00a0\u00a0\u00a0VPN endpoint<\/span><\/p>\n

      \u00a0\u00a0\u00a0|<\/span><\/p>\n

      Bastion Host (production NIC + management NIC)<\/span><\/p>\n

      \u00a0\u00a0\u00a0|<\/span><\/p>\n

      Management VLAN switch (isolated, no internet routing)<\/span><\/p>\n

      \u00a0\u00a0\u00a0|\u00a0 |\u00a0 |\u00a0 |<\/span><\/p>\n

      \u00a0BMC1 BMC2 BMC3 BMC4<\/span><\/p>\n

      \u00a0\u00a0|\u00a0 \u00a0 |\u00a0 \u00a0 |\u00a0 \u00a0 |<\/span><\/p>\n

      Srv1\u00a0 Srv2\u00a0 Srv3\u00a0 Srv4<\/span><\/p>\n

       <\/p>\n

      This topology means there is no direct path from the internet to any BMC. Even a compromised production server cannot reach the management VLAN without going through the bastion host’s management NIC, which has its own access controls.<\/span><\/p>\n

      VLAN Configuration on the BMC<\/b><\/h3>\n

      # Enable VLAN tagging on the BMC (requires IPMI 2.0)<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 lan set 1 vlan id 100<\/span><\/p>\n

       <\/p>\n

      # Verify VLAN is configured<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 lan print 1 | grep -i vlan<\/span><\/p>\n

       <\/p>\n

      # Disable VLAN tagging (revert to untagged)<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 lan set 1 vlan id off<\/span><\/p>\n

       <\/p>\n

      Verify that your BMC firmware supports VLAN before configuring. Older firmware may accept the command but not apply it correctly. Confirm the VLAN assignment is active by pinging the BMC IP from a host on the management VLAN after configuration.<\/span><\/p>\n

      \"ipmi<\/h2>\n

      IPMI Security Hardening: The 8-Step Checklist<\/b><\/h2>\n

      IPMI has a documented history of exploitable vulnerabilities. The root cause in most real-world breaches is not the protocol itself, it is misconfiguration. Exposed interfaces, default credentials, and cipher 0 still running are responsible for the vast majority of IPMI compromises. The checklist below fixes every common misconfiguration with exact commands.<\/span><\/p>\n

      Step 1: Disable Cipher 0 (Authentication Bypass)<\/b><\/h3>\n

      Cipher 0 allows any user to authenticate with any password, including an empty one. It was enabled by default on virtually all IPMI 2.0 implementations until major vendors began patching it. Many production servers still have it enabled.<\/span><\/p>\n

      # Check which ciphers are currently enabled<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus channel getciphers ipmi<\/span><\/p>\n

       <\/p>\n

      # Disable cipher 0 on channel 1<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus channel setcipher ipmi 1 0 readonly<\/span><\/p>\n

       <\/p>\n

      # Verify cipher 0 is disabled<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus channel getciphers ipmi<\/span><\/p>\n

       <\/p>\n

      Step 2: Enforce Cipher Suite 17 for All Connections<\/b><\/h3>\n

      Cipher 17 uses HMAC-SHA256 for authentication and AES-CBC-128 for encryption, the strongest standard cipher suite in IPMI 2.0.<\/span><\/p>\n

      # Always specify cipher 17 explicitly when connecting<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus -C 17 chassis status<\/span><\/p>\n

       <\/p>\n

      # Never use cipher 3 (MD5, cryptographically broken)<\/span><\/p>\n

      # Never use cipher 0 (auth bypass, disabled in Step 1)<\/span><\/p>\n

      # -C 17 prevents fallback to weaker ciphers<\/span><\/p>\n

       <\/p>\n

      Step 3: Change All Default Credentials<\/b><\/h3>\n

      # List current IPMI user accounts<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus user list 1<\/span><\/p>\n

       <\/p>\n

      # Change password for user ID 2 (the main admin account on most systems)<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus user set password 2 ‘YourStrongPassword!’<\/span><\/p>\n

       <\/p>\n

      # Disable user ID 1 (anonymous\/null user present on most systems)<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus user disable 1<\/span><\/p>\n

       <\/p>\n

      Step 4: Create Named User Accounts<\/b><\/h3>\n

      Named accounts enable session auditing. You can trace which administrator performed which action in the BMC audit log.<\/span><\/p>\n

      # Create a named admin account (slot 3)<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus user set name 3 “j.smith”<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus user set password 3 ‘UniqueStrongPassword1!’<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus user enable 3<\/span><\/p>\n

       <\/p>\n

      # Set privilege level on channel 1<\/span><\/p>\n

      # Privilege levels: 2=User, 3=Operator, 4=Administrator<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus channel setaccess 1 3 \\<\/span><\/p>\n

      \u00a0\u00a0link=on ipmi=on callin=on privilege=4<\/span><\/p>\n

       <\/p>\n

      # Verify access configuration<\/span><\/p>\n

      ipmitool -H $BMC -U $USER -P $PASS -I lanplus channel getaccess 1 3<\/span><\/p>\n

       <\/p>\n

      Step 5: Restrict BMC Access at the Network Layer<\/b><\/h3>\n

      Apply firewall rules on the management VLAN gateway to restrict which hosts can reach the BMC management ports.<\/span><\/p>\n

      # Allow only the bastion host (192.168.200.10) to reach IPMI ports<\/span><\/p>\n

      iptables -I INPUT -p udp –dport 623 -s 192.168.200.10 -j ACCEPT<\/span><\/p>\n

      iptables -I INPUT -p udp –dport 623 -j DROP<\/span><\/p>\n

       <\/p>\n

      # Restrict web interface (port 443) to bastion host<\/span><\/p>\n

      iptables -I INPUT -p tcp –dport 443 -s 192.168.200.10 -j ACCEPT<\/span><\/p>\n

      iptables -I INPUT -p tcp –dport 443 -j DROP<\/span><\/p>\n

       <\/p>\n

      # Make rules persistent<\/span><\/p>\n

      iptables-save > \/etc\/iptables\/rules.v4<\/span><\/p>\n

       <\/p>\n

      Step 6: Keep BMC Firmware Updated<\/b><\/h3>\n

      BMC firmware vulnerabilities are patched by vendors regularly. Outdated firmware is the second most common IPMI attack vector after default credentials. Set a quarterly firmware review schedule.<\/span><\/p>\n