Re: [44net] Critical vulnerability in Intel Active Management Technology (CVE2017-5689)]
To help prevent this from affecting AMPRNet systems, I am now blocking inbound port 16992 at the amprgw gateway. I hope this won't cause you any difficulties.
Thanks for the hint. It is surprisingly difficult to get technical information from the Intel documents. Do you block TCP only or also UDP? And what about ports 16993 and 16994? (and maybe even 623 and 664?)
The nice thing about such new vulnerabilities is that they allow you to identify the aforementioned scanners and put them on the permanent blacklist. Aside from shodan.io (that were already on the blocklist) I also see 52.174.52.33 census01.project-magellan.com Yet another annoying "research" project...
You could try to get 44.0.0.0/8 opted out via research@project-magellan.com
Rob
I'm blocking both TCP and UDP port 16992. I don't think the UDP block is necessary, as apparently what is on TCP 16992 is an HTTP server of some sort, but with ipfw it's less work to block both TCP and UDP with the same rule. I don't know anything about those other ports. (Most of what I got was obtained by looking through the nmap script description, not the Intel documents.) At work, so far, they have identified a small number of exposed hosts, all of which were listening on tcp port 16992, which they are blocking at the network border.
A 10-second snapshot just now shows 1323 connection attempts to 16992 on amprgw. (That's after excluding anything coming from known shodan addresses, which are taken care of by an earlier rule.) - Brian
On Fri, May 12, 2017 at 09:31:33AM +0200, Rob Janssen wrote:
Thanks for the hint. It is surprisingly difficult to get technical information from the Intel documents. Do you block TCP only or also UDP? And what about ports 16993 and 16994? (and maybe even 623 and 664?)
The recommendation now is to block TCP to all those ports, plus 16995.
The ipfw rule I'm using is deny ip from any to any in dst-port 623,664,16992,16993,16994,16995 and I've seen over 1500 connection attempts in a 10-second snapshot just now.
As I understand it, since the vulnerability exists in the machine's management firmware, a host-based firewall is ineffective; the block has to be in the router serving the particular subnet. - Brian
On Fri, May 12, 2017 at 09:31:33AM +0200, Rob Janssen wrote:
Thanks for the hint. It is surprisingly difficult to get technical information from the Intel documents. Do you block TCP only or also UDP? And what about ports 16993 and 16994? (and maybe even 623 and 664?)
-
Brian Kantor -
Rob Janssen