-----Original Message-----
From: Soluk, Kirk [mailto:kmsoluk@umich.edu]
Sent: Wednesday, May 04, 2005 5:57 AM
To: David LeBlanc; Murad Talukdar; focus-ms@securityfocus.com
Subject: RE: To disable SMB packet and secure channel signing
enforcement on Windows Server 2003-based domain controllers
All great points, as usual from David, but at least make "the boss"
aware of the risks that result from the new toy and have the
business owners accept that risk. Then you have done your
job and the decision (and potential consequences) of
ratcheting down the default level of security lies with them
- not you. Unless there is some level of pushback and some
dissatisfaction gets relayed back to the vendor, they just
keep shipping this stuff.
-----Original Message-----
From: David LeBlanc [mailto:dleblanc@mindspring.com]
Sent: Tuesday, May 03, 2005 6:58 PM
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
--------------------------------------------------------------
----------
---
--------------------------------------------------------------
----------
---
--------------------------------------------------------------
-------------
--------------------------------------------------------------
-------------
