SCIENTIFIC-LINUX-USERS Archives

June 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Michael Tiernan <[log in to unmask]>
Reply To:
Date:
Mon, 23 Jun 2014 08:38:48 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (55 lines)
As a member of LOPSA http://lopsa.org I recently got this message and I
thought I'd share it with this group.

I realize this isn't specific to SL but I wanted to make sure everyone
is as aware as possible.

-------- Original Message --------

Date: Fri, 20 Jun 2014 16:12:50 -0700 (PDT)
From: Paul Heinlein
To: [log in to unmask]
Subject: [lopsa-tech] Supermicro IPMI mitigation

You've undoubtedly seen reports of the vulnerability in Supermicro's BMC
implementation that allows IPMI usernames and passwords to be retrieved
via a simple HTTP GET query to port 49152:

http://blog.cari.net/carisirt-yet-another-bmc-vulnerability-and-some-added-extras/

I ended up taking two different remediation tacks.

First, in our local server room, all IPMI interfaces are connected to a
single subnet. Our room is small enough that they're all connected to a
single Cisco switch, but the same mitigation would work with a
VLAN-based subnet. I created an access list that only allows tcp access
to the http and https ports. All other tcp requests get blocked.

More tricky was a single server we have running in a remote data center
that I manage via IPMI. The Supermicro web interface allows firewall
configuration based on source IP address, so most pokes at port 49152
would be rejected -- but our local network setup is such that a visitor
to our office could conceivably contact that port.

Thankfully it's Linux and iptables under the hood, so

1. Launch ssh session to remote BMC.
2. Upon login run "shell sh" to get a command-line shell.
3. # iptables -I INPUT -m tcp -p tcp --dport 49152 -j DROP
4. # iptables-save > /nv/ipctrl/rultbl.sav

I'm not yet clear what will happen to the new rule if we reconfigure the
firewall from the web gui (presumably, it will get wiped out, but I'm
just not sure) -- but for now it gives me some level of comfort.
-
Paul Heinlein
[log in to unmask]
45°38' N, 122°6' W

-- 
  << MCT >>   Michael C Tiernan xmpp:[log in to unmask] +1 (617) 324-9173
  MIT - Laboratory for Nuclear Science - http://www.lns.mit.edu
  High Perf Research Computing Facility at The Bates Linear Accelerator
    Please avoid sending me MS-Word or MS-PowerPoint attachments.
    See http://www.gnu.org/philosophy/no-word-attachments.html

ATOM RSS1 RSS2