Internet Information Services (IIS) contains several components that perform
important functions for the application and Web server roles in Windows Server.
As it is designed to be used in an enterprise environment, the security of this
system must be kept at a high level.
By default IIS implements a lot of basic security measures, but are these the
relevant ones to protect your business?
In order to answer this question for one of our customers, we have compiled the
most relevant security settings in an IIS 7.5 Hardening Guide for you. In this
guide we define a baseline security level, which is to be used for so called
“crash and burn systems” (systems with non-critical data, systems whose
availability have no business relevant impact) and a security level high, which
includes all other systems. The mitigations in the baseline section are
non-critical and therefore no further test are necessary. The mitigation in the
section high, are critical in terms of availability and need to be tested
extensively. The system owner must decide, which security level is the right one
for their system, and which mitigation from section high are mandatory for their
system.
In the course of a customer project I recently documented some thoughts and
general objectives of IPv6 address planning, expanding on stuff I wrote a while
ago in the
series on “Address Plan Considerations”.
An excerpt of that (newer) document
can be found here.
Due to the context it originates from it’s in German, still I hope it’s useful
for some readers.
If you’re interested in the topic it might be a good idea to listen to
Tom Coffeen‘s talk at the upcoming
IPv6 Business Conference, too.
I wrote a small python script that extracts the content from Alcatel .tim
firmware files. It took some time staring at hex values, as well as a fair
amount of guess work to figure out the file format.
All .tim files start with a common header, containing the TiMOS version string,
the build string, the used compression algorithm and the number of segments
included in the file. The common header is followed by a header for each segment
in the file. The segment header contains values like the name of the segment,
the beginning of the segment in the image file, the size of the segment,
compressed as well as extracted, a checksum of the decompressed data and also
the base address and entry point of the data in the routers memory. A segment
header can look like this:
“The security of IPv4 is roughly equivalent to IPv6. So why do we expect more
from IPv6?”
While I highly value Scott’s IPv6 expertise – not least because I learned a lot
about IPv6 security from
the book on the topic
he wrote together with Eric Vyncke – I
strongly disagree with his statement, mainly with the first part. In this post I
will lay out why I think that IPv6 is actually less secure than IPv4.
IPv6 is often called a “complex protocol”, not least by myself (for example in
my
keynote to the IPv6 Security Summit 2014). In
this post I want to have a quick look at three questions:
– Can IPv6 be considered a “complex protocol”?
– Is it “more complex” than IPv4?
– Can we expect IPv6 networks to be “complex networks”?
I’d like to start with some clarifications and a definition. First of all: when
I discuss IPv6 “as a protocol”, this actually means “the IPv6 procotol family”
incl. those helper protocols needed to support (“core”) IPv6 in performing
properly in most networks, like ICMPv6 and MLD.
Then, of course, we have to define the term “complexity”, which is a difficult
task in itself. [MITCHELL2009] gives an overview of several potential
(definition) approaches in a dedicated chapter and the same undertaking is
performed – in quite different ways – by most of the authors of individual
contributions to [PELITI1988].
In our
talks
in the past we showed what might be possible if an attacker gets access to
backhaul and/or core network of a telecommunication provider. In a security
analysts perspective this is really disgusting, but provider always will
argument that those attack scenarios are not realistic.
Because of legal restrictions we are not able to demonstrate this in practice
(e.g. by breaking in into a BTS environment somewhere in the woods) but what we
can do is this: building a lab.
Sometimes it is really shocking what you can buy on Ebay, right? Here we got one
very interesting component: a Huawei BBU3900 BaseStation which is used by a
couple of providers. Okay, it is for GSM-Rail, but the technology behind is very
equal. And for 100 dollars (plus shipping) you don’t ask further questions…
The purpose of this blog post is to elucidate how and why MLD, an IPv6 protocol
we’ve been lately talking quite a bit about, is an unnecessarily complex beast
. This article should also serve to summarize a couple of points we’ve mentioned
during our talks about MLD but which because of time constraints never make it
into the main discussion. We’ve talked about
other aspects of MLD in previous posts.
So, have a look at those if this is a topic which you find interesting. Without
further ado, let’s start for today.
We’ve just released a whitepaper discussing the behavior of different operating
systems once they receive IPv6 configuration parameters from different sources.
For that purpose a number of lab tests were conducted.
In short, it’s a mess.
Again, RFC ambiguity and/or
(perceived) vendor implementation freedom suck big time. For us practitioners
out (t)here this means (once more) we need extensive test labs and good
troubleshooting guides for large scale IPv6 deployments.
Troopers is right around the corner and as
I am responsible for the whole conference network I wanted to make sure that
everything is working as expected. I went to the venue on Friday because of two
things I wanted/needed to setup. Compared to last year’s setup we had a couple
of changes in regards to the provider connection (resulting in some changes for
our network setup). First, we now have a rather big pipe for the uplink and more
importantly (well that depends on the point of view ;)) there is a native IPv6
connection. Before that I had to tunnel all IPv6 traffic from the venue to one
of our gateways and to forward it out (as native IPv6) from there. As this step
isn’t necessary anymore, and the staff on the venue isn’t that experienced with
IPv6, I had in mind to setup and verify that IPv6 is working as desired. The
router used over there is a
Mikrotek Routerboard. As I haven’t
worked with these devices before, I was curious whether everything works as it
should ;).