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 ;).