Intel Open Port: Intel vPro Expert Center Blog : Tags : reflector

As many of you may know, there are two ways of contacting Intel AMT: The remote network interface and the local LMS/HECI interface. These interfaces are very different; the remote interface that is available thru the wired and sometimes wireless Ethernet and is rich with features while the local Intel AMT interface is very limited. Intel AMT was designed this way from the start for security. Intel AMT acting as an IT agent on desktops and laptops could not be allowed to be meddled with by the local user or local applications that could try to use or deactivate Intel AMT. That at least was the original design intent.

Times have changed it seems and many users of Intel AMT don’t see local users and applications as being always hostile. There are many reasons why it would be very interesting to access all of the features of Intel AMT locally. For example

If the user changes the name of the computer is the OS, it would be nice to have a local agent sync up the Intel AMT network with the OS name automatically. This way, when the computer goes to sleep next, Intel AMT will report the correct new name.
Circuit breaker policies could be used as a local firewall implemented in hardware. Set it once and the gigabit network chip does all the filtering and counters at gigabit speeds.
On a mobile platform, wireless profiles could also be synched up automatically. The user adds a new wireless profile with a WPA key and this profile is automatically added to Intel AMT.
Enterprise provisioning of Intel AMT could be done entirely locally using local software removing the need for complicated centralized servers.

Instead of seeing the local user as hostile, the local application now cooperate to setup Intel AMT so that if something goes wrong, it’s ready to be used to recover the computer. All this and more would be possible if Intel AMT allows the local applications full access to all the remote interface features.

A local application can’t simply connect to TCP port 16992 or 16993 and access all of the Intel AMT features since the traffic has to flow thru the gigabit network interface. Connecting to 127.0.0.1 will not work, that will access the more limited local interface.

A solution is to use a reflection application like Intel DTK Network Reflector found in the Intel AMT DTK. This tool runs on a central always on server and simply reflects back all TCP connections back to the source on ports 16992 to 16995. Using this tool an Intel AMT console or even a web browser can connect to "http://reflector:16992" and log into its own Intel AMT remote services. However, there are issues with this solution: You need this reflector tool running and know where on the network it is running. Also, a rogue application could log into the remote interface and put an annoying circuit breaker policy to drop all packets, etc.

In the future, Intel AMT itself could be modified to allow all services on the local interface removing the need for the reflector. There are security considerations of course, but feedback from users of Intel AMT on this idea would be appreciated.

Ylian (Intel AMT Blog)

http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/1391/Reflector.jpg

0 Comments Permalink Tags: ylian, intel, amt, dtk, reflector, local, remote, developer_tool_kit

Hi all. I wanted to announce the release of the Intel AMT DTK v0.51 on the public web site. As usual, lots of improvements have been made since the last version thanks for much testing and feedback from users. There are a few things that are particularly interesting about this new release of the Intel AMT DTK and lets get right to it:

Build-in C# WSMAN stack. As Intel AMT is transitioning to WSMAN calls for remote managibility, adding WSMAN support into the DTK has been increasly important. In the past, the DTK made use of WinRM, a Microsoft component that needed to be installed and configured. With version 0.51 of the DTK, I build my own WSMAN stack in C# right into the DTK stack. As a result, no more dependency on WinRM at all and no more compile problems. Additionaly, the DTK is now much faster at making WSMAN calls since all HTTP requests are now pipelined, and the DTK can connect to AMT computers that have invalid TLS certificates (a warning will be displayed of course). This is big news for anyone interested in WSMAN work. If you build your own managibility solution, I suggest you look at grabbing at least that part of the DTK source code.
Intel AMT Flash Tool. This version of the DTK adds a new Intel AMT Flash Tool. It will help users correctly setup a USB flash key so that it can be use to provision Intel AMT computers. As many of you many know, Intel AMT will in the right conditions, read a setup.bin file in a USB flash key when booted and use the information to help setup Intel AMT. The setup.bin file must be at the very start of the USB key and this new tool with help with that. The new tool is based on a similar tool that has already been released on the Intel Pro Center.
Intel AMT Reflector tool. Another new tool is a TCP connection reflector. It's a small generic tool that accepts connections and forwards the data back to the source IP address on a target port. It's useful for accessing Intel AMT from your own computer using a reflector on a different computer. I use it for recording some of my demonstration videos, but it can also be used by agents running localy that want to re-configure Intel AMT on itself. For example, detecting an OS name change and updating Intel AMT.

Many more changes and fixes have also been done, for example the terminal now correctly detects Serial-over-LAN disconnection, etc. For a full list, the DTK includes a change log.

Intel AMT DTK v0.51x Audio Blog (.mp3)

Ylian (Intel AMT Blog)