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.
Similar to the documents we released for Linux and Windows (and actually inspired by a comment to the post on the Linux guide) Antonios wrote another guide, this time for Mac OS X.
It can be found here. We hope some of you might find it helpful.
Have a great day
Following up on this post, we want to provide some details on two rather new (well, compared to its lifespan) Linux kernel parameters — and emphasize the need to enable those:
fs.protected_hardlinks
fs.protected_symlinks
For BSD, similar parameters for hardlinks exist: security.bsd.hardlink_check_uid/security.bsd.hardlink_check_gid.
Those parameters control whether users are allowed to create links pointing to files which are not owned by them. If fs.protected_hardlinks/symlinks is set to 1, users can only create links to files which they own. Attackers have used this possibility for a long time, and here are some sample attack scenarios:
After we recently released the “Linux IPv6 Hardening Guide” we got a number of suggestions “could you pls provide a similar document for $OS?” (btw: thanks to you all for the overwhelming interest in the Linux document and the active discussion of ip6tables rule approaches on the ipv6hackers mailing list).
Hence Antonios thankfully decided to put together a list of configuration steps for Windows servers. It can be found here.
Once more we’d like to emphasize that the approach described is only suited for very specific environments with high security requirements and an associated ratio of “generous operational resources”. From our perspective this guide is intended mostly to serve as a source of inspiration (“what could be done”) and for documentation purposes (“how to do it”). Everything described should be carefully tested in your specific environment.
For example, we were recently involved in IPv6 security planning in an organization where the Windows guys (completely legitimately) came up with a stance of “before we fully accept and ratify the strategy and policy just discussed, we’d like to get feedback from Microsoft, if we still have full support once we follow this path”.
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.
continuing our tradition from last year (see here and here), we summarized more of our hardening recommendations for you. This guide is covering Tomcat 7 and is supposed to provide a solid base of hardening measures. It includes configuration examples and all necessary commands for each control, specifically for the most recent branch of Tomcat as there were some significant changes. Download: ERNW_Checklist_Tomcat7_Hardening.pdf
SUSE Linux Enterprise Server (SLES) has been around since 2000. As it is designed to be used in an enterprise environment the security of these systems must be kept at a high level. SLES implements a lot of basic security measures that are common in most Linux systems, but are these enough to protect your business? We think that with a little effort you can raise the security of your SLES installation a lot.
In the course of a recent endpoint assessment, we also had a OS X 10.8 client system as a target. While we still rely on the Firewire “capability” of unlocking systems on a regular base (using this great tool), we noticed that Apple released a patch to disable Firewire DMA access whenever the system is in a locked state (e.g. with an active screensaver or no user logged in). As we test the Firewire DMA access vulnerability quite often (at least we thought so 😉 ) to prepare for demonstrations in the board room or client assessments, we were quite surprised that we must have actually missed that nice update. In order to verify the effectiveness of the patch, we ran our typical test bed and can quite happily confirm that the update successfully mitigates Firewire DMA access in locked system states.
Hi everybody,
eye-catching title of this post, huh?
Actually there is some justification for it ;-), that is bringing this excellent document covering the exact topic to your attention.
Other than that this post contains some unordered reflections which arose in a recent meeting in a quite large organization on the “common current iPad topic” (executives would like to have/use an iPad, infosec doesn’t like the idea, business – as we all know – wins, so bring external expertise in “to help us find a way of doing this securely” yadda yadda yadda).
Which – given those nifty little boxes are _consumer_ devices which were probably never meant to process sensitive corporate data – might be a next-to-impossible task… at least in a way that satisfies business expectations as for “usability”…[btw: can anybody confirm my observation that there’s a correlation between “rigor of restriction approach” to “number of corporate emails forwarded to private webmail accounts”?]
I can’t help myself. And I fully understand that some of you, dear readers, might get a bit annoyed by always hearing the same tune from our side. This post is, surprise!, about yesterday’s Microsoft Patch Tuesday which – as can be seen here and here – disclosed quite a number of vulnerabilities in various Microsoft components. To make the point evoked in this post’s title I’d like to draw your attention to two particular bulletins, both rated as critical.