Thanks for the great replies--I had a hunch that the hole opened up is
precisely why W2003 comes set as it does as a default.
What I will do is:
1. Enquire with the vendor whether the machine can be set to sign(It's a
rebranded Ricoh machine)
2. Look into the ftp suggestion-this seems much more 'secure' at this point
and I did know that ftp could be enabled on a W2003 machine but this
particular DC is doing more tasks than I think it should but it will take a
while before we get approval for another box. (Can you believe that the man
at the top of an international company has to give approval for anything
higher than $1000 dollars?)
3. Serge's idea for the local folders is a good one too--but we do have a
lot of roaming so will need to figure that one out if this is the path to
use.
4. Take a deep breath.
5. see if I can find the setting that Laura mentioned. ('whenever possible')
Murad
-----Original Message-----
From: David LeBlanc [mailto:dleblanc@mindspring.com]
Sent: Wednesday, May 04, 2005 8:58 AM
To: 'Soluk, Kirk'; 'Murad Talukdar'; focus-ms@securityfocus.com
Subject: RE: To disable SMB packet and secure channel signing enforcement on
Windows Server 2003-based domain controllers
I replied privately to Murad, but something I'd like to add -
Some copiers do run on OS/2 and Linux (though IIRC, samba has been able to
do signing for a while), so that's probably a good guess.
As you point out, the attacks enabled by turning down security are severe,
but if they're in a situation where you're using a DC as a file server, then
it's probably a very small org. I'd venture that the chances of anyone
popping up on the network who can launch these attacks are slim, and if a
hacker does get in, this is unlikely to be the weakest link.
I wouldn't push back hard right now - I'd try and get a dedicated file
server ASAP. I'd also want to be sure I had all my other bases covered -
routine checks for bad passwords, and so on. The problem is that you're not
going to win this one now. They already have the copier - if this was caught
pre-purchase, you might be able to win it. An arcane security problem that's
hard to explain which has a number of preconditions is a losing proposition
when going up against the boss' shiny new toy.
One work-around that can be done right away would be to use FTP - all
Windows servers have a FTP server that can be installed and this would seem
to be a relatively low-risk option if the files are pushed out without
authentication. If they use passwords, then FTP is a big step backwards.
*****************************
My opinion, and should not be construed as a statement on behalf of my
employer.
*****************************
-----Original Message-----
From: Soluk, Kirk [mailto:kmsoluk@umich.edu]
Sent: Tuesday, May 03, 2005 1:09 PM
To: Murad Talukdar; focus-ms@securityfocus.com
Subject: RE: To disable SMB packet and secure channel signing
enforcement on Windows Server 2003-based domain controllers
If you disable the SMB signing requirement it means that all
your SMB based DC to member communications will be subject to
MITM attacks. The primary concern here is your group policy
download. In short, the SMB signing requirement provides the
assurance that your group policies do not get tampered with
in transit. Similarly, disabling the secure channel
encryption\signing requirement means that you have no
guarantees on all your DC to DC secure channel data (although
sensitive information within the secure channel session (e.g.
password derived data) will always be encrypted.
It makes absolutely no sense to me how an app could be
forcing this issue unless it's really old or running on a
SAMBA machine. Is that the case?
I would push back hard on this. You do not want to take this
step backward. You have to be running some pretty old or
insecure stuff to have to disable these settings - SMB
signing was introduced in NT4 Service Pack 3!
Kirk Soluk
University of Michigan
Information Technology Security Services
-----Original Message-----
From: Murad Talukdar [mailto:talukdar_m@subway.com]
Sent: Tuesday, May 03, 2005 3:32 AM
To: focus-ms@securityfocus.com
Subject: To disable SMB packet and secure channel signing
enforcement on Windows Server 2003-based domain controllers
Hi All,
We have had arrival of new scanner/printer/copier in office.
It uses SMB to scan files to shared folders on our W2003
network. In order for it to work however, I have had to do
the following;
1. From Administrative Tools open Domain Controller Security Policy 2.
Smile 3. Select \Security Settings\Local Policies\Security
Options folder. 4. In the details pane, double-click
Microsoft network server:
Digitally sign communications (always), and then click
Disabled to prevent SMB packet signing from being required.
5. Click OK. 6. In the details pane, double-click Domain
member: Digitally encrypt or sign secure channel data
(always), and then click Disabled to prevent secure channel
signing from being required. 7. Click OK.
Before that, the scan would fail to be sent to the server in question.
What are the implications of this--given that we do not
ostensibly use SMB for anything else.
I've heard scare stories of SMB man in the middle attacks and
was under the impression that this is what these specific
security settings were pertaining to but am not sure.
There are other options for the scanning ie ftp/email but
neither would work as we cannot get approval for cost of ftp
server nor can the email system take the file sizes that are
often req'd by scans our users make.
I can see there will be advice against having shared user
folders etc on DC's too but the big boss wants more from less
if you see what I mean.
Kind Regards
Murad Talukdar
--------------------------------------------------------------
----------
---
--------------------------------------------------------------
----------
---
--------------------------------------------------------------
-------------
--------------------------------------------------------------
-------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
