We were recently approached by a customer asking us for support along the lines
of “do you have any recommendations as for strict hardening of IPv6 parameters
on Linux systems?”. It turned out that the systems in question process quite
sensitive data and are located in certain, not too big network segments with
very high security requirements.
They indicated they were willing to spend significant operational resources on
“securely configuring them”. So Antonios deciced to write a small hardening
guide for IPv6 on Linux, mostly focusing on manual configuration of pretty much
everything (including neighbor cache entries 😉 with accompanying deactivation
of all automatic mechanisms, together with ip6tables based local packet
filtering.
The document
can be found here.
We just released a white paper authored by
Antonios Atlasis that provides an
overview which pentesting tools currently support IPv6 and how to (still) use
them if that’s not the case. It can be found
in our newsletter section.
Mike Ossmann: RF Retroreflectors, Emission
Security and SDR
Synopsis: The leaked pages from the NSA ANT catalog provided a glimpse into the
modern world of emission security. Extending beyond passive monitoring of
unintentional emissions, today’s spooks employ active attacks with tools such as
RF retroreflectors. I’ll report on my experiments to reproduce such techniques
with open source hardware and software, primarily using SDR.
When planning for IPv6 addressing, many organizations – rightfully & wisely –
decide to go with global unicast addresses (GUAs) only (hence not to use
unique local addresses/ULAs as of
RFC 4193 at all), in order to avoid
address selection hell or just for
simplicity & consistency reasons. This
post discusses security implications and complementary security controls of such
an approach.
In their IPv4 networks, most of these organizations currently use RFC 1918
space, combined with NAT for specific connections or use cases. Ideally NAT is
only in place “where strictly needed”, in practice it’s often used as a
kludge to
conceal of all types of bad network design or debatable application
architectures. I won’t enter the “is NAT a security control?” debate here, one
statement might be allowed though: as of section 3 (“Because private addresses
have no global meaning, routing information about private networks shall not be
propagated on inter-enterprise links, and packets with private source or
destination addresses should not be forwarded across such
links.”) RFC 1918 space is usually not
reachable from the Internet. So using such address space for internal networks
is a nice example of the isolation principle as of the
“Seven Sisters”
approach we like to use. Now, bringing NAT into these networks enables
connections (usually between trusted and untrusted networks) which simply would
not be possible without it [NAT], so this actually breaks the isolation
property. Question: how can one ever call something that increases the
number of possible interactions between assets and potential attack originators
a ‘security control’?!
In one of our customer environments each vendor offering an IT product/solution
is asked to fill out a questionnaire collecting information on a number of
technical parameters with regard to their product[s]. We were recently asked
to come up with a proposal of 8 to 10 IPv6-related questions to be added to the
questionnaire/process. Here’s what we suggested:
When displaying, storing or exporting IP addresses, can your solution correctly
handle IPv6 addresses of all types (link-local, ULAs, GUAs)?
When receiving IP addresses as input or processing them (e.g. in a database),
can your solution correctly handle IPv6 addresses of all types (link-local,
ULAs, GUAs) and of variable length?
Does your solution implement RFC 5952 in the sense that input (of IPv6
addresses) can be in any format, but output (e.g. in log files) follows the RFC
5952 recommendation?
Can your solution handle both A and AAAA records from DNS?
Does your solution use link-local or GUAs/ULAs for intra-subnet communication?
Which is the default and can both types of addresses be configured?
Does your product/offering comply with any of the profiles in the ripe-554
requirements specification?
[http://www.ripe.net/ripe/docs/ripe-554]
Do all security-related functions of your solution (e.g. traffic filtering/ACLs,
blacklisting, logging) fully support IPv6, with performance being equal to that
of IPv4?
Do all implementations of management interfaces & protocols (SNMP, syslog etc.)
used within your solution fully support IPv6?
Does your solution have a built-in webserver? Can this be configured to listen
on an IPv6 address and has it been tested to successfully work in an IPv6-only
or dual-stack setting?
Has your solution been thoroughly tested in an IPv6 only or in a dual-stack
setting? Please provide proper test documentation.
In dual-stack settings which approach (e.g. Happy Eyeballs as of RFC 6555) does
your solution follow as for preferring IPv6 over IPv4 or vice versa? Can this be
configured/adjusted if needed?
On Thursday the 20^(th) Enno, Jayson and I had the pleasure to present our
latest research results regarding MLD at
Deepsec 2014, both from vendors’
implementation perspective as well as regarding protocol design flaws (some
preliminary results as well as our testing methodology were discussed
here and
here).
For refreshing out memory, in a nutshell, the purpose of MLD, a subprotocol of
IPv6, is to inform routers about the presence of nodes which are interested in
receiving specific multicast traffic
(RFC 2710). The newer version of MLD,
MLDv2 adds the ability for source address selection
(RFC 3810).
As you might know we are continuously doing
research on medical devices.
I presented some of the new results at
Power of Community 2014
last week and we thought we would share some of the details with you here. The
focus of the previous work was testing medical devices that are used in
hospitals like patient monitors, syringe pumps or even MRIs. This time we looked
at a device that every user can use at home and which is available to anyone on
the market: A smart scale.
We’re delighted to provide the first announcement of talks of next year’s
Troopers edition. Looks like it’s going to be a
great event again
.
Here we go:
Jacob Torrey – The foundation is rotting and the basement is flooding: A deeper
look at the implicit trust relationships in your organization FIRST
TIME MATERIAL
Synopsis: In this session, a new hardware-level attack on PCIe is presented as
an example for the implicit trust your organization places in 3rd parties. These
implicit trust relationships that are typically overlooked will be closely
examined under the lens of “InfoSec debt” and providing guidance to InfoSec
decision makers on the ROI or risks of adding additional IT services/appliances
to an organization’s network.
The “InfoSec debt” metric can then be tracked over time and provides an
intuitive way to explain the cost/benefits of IT security to other
organizational stakeholders.
Recently we had the pleasure to take a look at GitHub’s Enterprise appliance.
The appliance allows one to deploy the excellent GitHub web interface locally to
host code on-site. Besides the well known interface, which is similar to the one
hosted at github.com, the appliance ships with a separate
interface called the management console, which is used for administrative tasks
like the configuration of the appliance itself. This management interface is
completely decoupled from the user interface.
.