If you own a couple of workstations or servers, remote management becomes extremely important. One of the technologies that has been on the market for a long time is Intel Active Management Technology (AMT). However, information is unfortunately very hard to find. Awareness about security issues and mitigation is extremely important. The majority of PC users is unaware to the risk of back-doors into their laptops.
This post is what I wished I could have learned from the Internet on the day I learned about the existence of AMT.
AMT is an out-of-band management technology running on the “Management Engine” (ME) baked into a dedicated microprocessor on most Intel chip-set motherboards since mid 2006.
The great thing is that it is possible to control and query the hardware over Ethernet from the moment you plug in the power supply, that is read configuration information while the system is turned off, booting the system, etcetera. Communication with ME is completely out of the path and independent of BIOS, bootloader, or OS. ME communicates directly with an Ethernet controller.
The terrible side of this is that the technology is Intel-proprietary, top-secret and therefore impossible to trust, and vulnerable to newly discovered exploits. The kernel code ThreadX by Express Logic (now Microsoft) is proprietary and secret. Intel’s AMT application, part of Intel’s “vPro” brand, is running on the ME, and is kept secret as well.
The fact that ME cannot be disabled on modern systems is undoubtedly bad for individual freedoms. That is not the topic of this post; this is about understanding it.
As often is the case with extremely powerful technologies it can be extremely dangerous as well. The proprietary nature makes things only worse. If not properly managed you could expose your infrastructure to a range of attacks. Depending on the use-case and trust in Intel you may want to disable AMT altogether, or just control any vulnerabilities. However, disabling ME is becoming close to impossible.
The least you should do is install the latest ME update, specific to your major ME version. AMT-enabled Ethernet ports should probably be on isolated networks and when not in use I would turn the network off completely. The workstations and servers should also be physically safe from intrusion.
ME updates for HP servers are available from HP. Installation is similar to BIOS updates. It can be done from a bootable MSDOS USB stick. Note that you must use the update tool and update firmware specific to the major ME version you have, so check that first in the BIOS (after enabling AMT in BIOS first and after re-booting).
A list of known Intel Active Management Technology vulnerabilities and exploits is here.
Now that that is out of our way, we have come to the fun part of this post. The information below is based on experience with enterprise hardwaee of 2012 with ME versions 7 or 8. (This could be a sweet-spot for AMT management vs user control!) Let’s focus on the positives of the technology.
AMT (not ME) may be disabled by default, and only accessible through a specific Ethernet port. On z620 and z820 servers one of the ports is labeled “AMT”, IP address allocation can be setup manually, or via DHCP. In the latter case you will need a DHCP server on the subnet attached to the AMT port. A client can be routed to the AMT port from anywhere, unless the subnet is isolated. The third part is a client. This can be a web browser, a special client.
Intel Active Management Technology (not ME) is enabled in your BIOS, and once enabled and machine rebooted, configurable during system boot. On HP z620 and z820 servers you press <Ctrl><p> to configure AMT through “MEBx”.
The password can be set the first time you try to configure AMT. The default is “admin”. Use a really strong password for this and keep it safe. If you cannot login, you must un-provision AMT in BIOS to reset everything to default. You should probably set a new strong password even if you plan to disable AMT, and password protect your BIOS with a power-on password as well to prevent access to MEBx remotely.
If you have DHCP set-up for your subnet, then simply enable network access, and reboot. That’s it! The option to enable is in the AMT configuration menu, under “Activate Network Access.” A user guide for MEBx 7 for example can be found here.
Connect any computer to the same subnet, check IP reservations given out by the DHCP server, or try all the possible IP addresses in the following step. Start a browser and browse to http://<amt-ip-address>:16992 where the WebUI exists. Note that this is un-encrypted so you need to keep your subnet secure. Also, configure TLS to use https instead at port 16993.
Once logged-on, entering username admin and the password set through MEBx configuration. Multiple users and passwords can be configured to control access to AMT but that is detail.
Once the connection is established from your browser, you can see hardware information, and control the power state of the system, as well as control AMT ME configuration such as network settings.
Another great method is the excellent and free NodeJS version of MeshCommander, The creator’s homepage is here. with other versions and related software. This software offers much beyond the capabilities of the WebUI.
If you have setup your network to route to/from your AMT subnet, you can access your computes from anywhere int the same way. If you use DHCP you can at least reserve IP based on AMT capable Ethernet port MAC address, to address the right machine easily.
With AMT versions 6 and higher, It is possible to view remotely the screen of the server using out-of-band KVM and VNC, but this seems to require integrated video on the motherboard. (So as a user, be aware that someone may be spying on you, no matter how secure your OS purports to be!!) This function is not needed if you have set-up a remote access service in your OS so we will skip this.
The serial console redirection (SOL or Serial over LAN) capability, however, is an excellent way to remotely configure a machine’s BIOS, or gaining a TTY terminal login to the running OS.
Configuring the BIOS Remotely
MeshCommander mentioned before has a built-in terminal. The terminal can connect to a machine during boot, and enter the BIOS setup screen. Issue the commands from the UI to Power on to BIOS or Reset to BIOS to end up in BIOS configuration.
Fedora and CentOS, and possibly other OSes have a tools amtterm, that can be used to access SOL from the linux commandline. Fedora also supposedly has a tool called gamt.
To use the virtual serial port beyond boot to BIOS, you need to configure the OS and GRUB. If you want to use SOL to connect to the OS after boot you need to configure the getty service using systemd.
Following GRUB2 Boot Process Remotely
By configuring GRUB it is possible to enable to control the boot menu and the process. The following is for GRUB2 (v2). However, I could not confirm correct operation. If you know why, leave a message below and I will update this section.
[ ] On target edit /etc/default/grub
sudo vi /etc/default/grub
[ ] Append to the line with GRUB_CMDLINE_LINUX
| To get e.g.: GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos_hostname/root rd.lvm.lv=centos_hostname/swap console=tty0 console=ttyS0,115200n8"
[ ] Append at the bottom
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0"
[ ] Exit vi
[ ] Regenerate GRUB2 config
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
At reboot you should see the GRUB menu and follow the boot process on both SOL as well as regular console.
Accessing the Linux Console Remotely
It is possible, at least in Linux, to redirect the console to the out-of-band AMT serial port:
[ ] On target ensure that AMT is enabled
[ ] Check for an ttyS serial port
sudo dmesg | grep tty
| HP z620/CentOS7 it's: ttyS0 at I/O 0xe060 (irq = 17) ...
[ ] Connect using MeshCommander or amtterm from another system
[ ] On target start a terminal and check login on SOL terminal
sudo /sbin/agetty ttyS0 115200
[ ] If this worked configure systemd to keep service running
sudo systemctl enable [email protected]
[ ] Confirm the symbolic link is created
ls -l /etc/systemd/system/getty.target.wants/
[ ] Reboot the system
sudo reboot now
After rebooting the SOL terminal will show the login prompt and you can use it. You cannot use than more than one terminal client at a time. The console worked fine with MeshCommander for any of the settings in the lower right corner. However, LF on enter worked best.
Do not forget to logout when done because terminating the SOL terminal will not log you out automatically. You can reconnect any time without entering a password.
You can do much more using Intel Active Management Technology, including booting from a server using IDE-R. One day I may update this blog after gaining some experience with such features.
photo: ideanist M