Re: [44net] Critical vulnerability in Intel Active Management Technology (CVE2017-5689)]
12 May
2017
12 May
'17
3:31 a.m.
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(a)project-magellan.com
Rob
12 May
12 May
3:54 a.m.
New subject: Critical vulnerability in Intel Active Management Technology (CVE2017-5689)
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?)
10:46 a.m.
New subject: Critical vulnerability in Intel Active Management Technology (CVE2017-5689)]
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?)
2751
days inactive
2751
days old
2 comments
2 participants
participants (2)
-
Brian Kantor -
Rob Janssen