Windows Server 2000/2003 Thread, GPO "Security Options" in Technical; I have been reviewing our GPO settings in the category: Security Settings\Local Policies\Security Options. Some of them were lowered for ...
15th April 2012, 11:11 PM #1
GPO "Security Options"
I have been reviewing our GPO settings in the category: Security Settings\Local Policies\Security Options. Some of them were lowered for compatibility with Windows 98 clients, now long gone, and the defaults do not seem that secure.
I have found this Microsoft Support Article useful, but I wondered if anyone had any warnings of compatibility or performance issues caused by raising the settings.
I am thinking it would be a good idea to force traffic to be signed, that is turning on:
Digitally encrypt or sign secure channel data (always)
Microsoft network client: Digitally sign communications (always)
Microsoft network server: Digitally sign communications (always)
Require strong (Windows 2000 or later) session key
Though I don't know that man-in-the-middle attacks are that likely in our environment, and there are warnings of a 15% performance hit. For the last setting the article I cite above says "Enabling the Domain member: Require strong (Windows 2000 or later) session key setting is a harmful configuration setting.", but then appears to spend the rest of section saying what a good idea to set it is unless you have windows NT on your network.
I am also thinking it would be a good idea to disable all the anonymous access options.
Network access: Allow anonymous SID/Name translation - thinking disable
Network access: Do not allow anonymous enumeration of SAM accounts and shares - thinking enable
Thoughts? What do you have set?
IDG Tech News
22nd April 2012, 12:44 PM #2
I checked two 2008 R2 domains I support:
Domain member: Digitally encrypt or sign secure channel data (always) - Not Defined
Microsoft network client: Digitally sign communications (always) - Not Defined
Microsoft network server: Digitally sign communications (always) - Disabled
Domain member: Require strong (Windows 2000 or later) session key - Not Defined
Network access: Allow anonymous SID/Name translation - Not Defined
Network access: Do not allow anonymous enumeration of SAM accounts and shares - Not Defined
Thanks to Michael from:
Jollity (22nd April 2012)
22nd April 2012, 12:50 PM #3
This hardening may work fine for the workstations but if you use anything like a NAS or linux gear it may well break it as practically none of it supports the higher security levels by default or in many cases at all.
Thanks to SYNACK from:
Jollity (22nd April 2012)
22nd April 2012, 01:57 PM #4
That's the kind of thing I am worried about. We do not have any linux machines, and no NASes at the moment. Network printers seem likely thing to break and perhaps the couple of Macbooks on the network.
Originally Posted by SYNACK
The fact that no one has come forward to support tightening the settings rather cools my heels. I was worried it was an area our security was slack, but it seems that we would be going above and beyond.
I might have a go at tightening up the anonymous access settings - it seems less likely anything is using that, and I can't see how it could affect performance.
22nd April 2012, 05:48 PM #5
To be honest, having a properly managed hardware firewall and WSUS are the way to go instead of tweaking the above settings, which as Synack pointing out can be more trouble than they're worth. Best leave well alone
23rd April 2012, 10:38 AM #6
@Jollity I was also worried about this. @Michael This is more to do with Internal security rather than external (internet facing) threats. I know it's possible for all server client packets to be authenticated and encrypted but I also know that I don't fully understand what will break if I do that.
Currently it's possible for a malicious user to hook a PC into a lanport here arp spoof and wireshark to read all the data flying around my network. My switches can halt some mischeif but I think they could cripple my network if determined enough. I think server client encryption would further reduce the risk but I lack the technical knowhow.
23rd April 2012, 01:52 PM #7
Well you could use group policy to enforce IPSec encrypted connections between all clients and servers or even only some servers and their clients but you may well be getting into overkill land.
Keeping devices off can be partially done using 802.11x on your switches and blocking unknown MAC addresses but the workaround is to simply clone an existing station MAC. You can further split the network into VLANs and subnets with ACLs inbetween to prevent leakage of certain kinds of traffic from one secton to another. You can also use something like packetfence to keep a close eye on the traffic and watch for ARP poisoning etc but you are rapidly approaching overkill land again. Even most universities don't go that far when it comes to proofing their networks. Usually the CS one gets a little extra scrutiny but other than that it is usually jsut VLANs and 802.11x in my experience.
What level of security are you trying to achive?
23rd April 2012, 10:47 PM #8
Interesting to hear what could be done. Definitely heading into overkill in our case - relatively small primary. I am not aiming for much in the way of protection from a human hacker with a direct physical connection to the LAN, but I would like to stop anything easily exploitable. It seems to me that a man-in-the-middle attack on windows traffic would be pretty difficult to get right and would likely involve luck or planning in finding an exploitable connection, but maybe someone has automated the process...
Which measure does that refer to?
Originally Posted by SYNACK
24th April 2012, 10:35 AM #9
Originally Posted by Jollity
The danger is more from traffic intersecption or from ARP poisoning redirecting stuff to a differnet server which is largely taken care of with existing end to end verification and decent network partitioning.
Out CS department had a strictly firewalled section all to itself and with 802.11x auth and staticlly assigned addresses (not that that last bit actually helped much).
By CyberNerd in forum Scripts
Last Post: 13th August 2009, 01:56 PM
By rush_tech in forum General Chat
Last Post: 25th March 2009, 03:23 PM
By broken_url in forum Windows
Last Post: 16th May 2008, 11:07 PM
By sahmeepee in forum Bad Experiences
Last Post: 4th July 2006, 11:43 AM
By NetworkGeezer in forum *nix
Last Post: 5th May 2006, 10:49 AM
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)