-----Original Message-----
From: Murad Talukdar [mailto:talukdar_m@subway.com]
Sent: Tuesday, May 03, 2005 7:32 PM
To: 'David LeBlanc'
Subject: RE: To disable SMB packet and secure channel signing
enforcement on Windows Server 2003-based domain controllers
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
--------------------------------------------------------------
----------
---
--------------------------------------------------------------
----------
---
--------------------------------------------------------------
-------------
--------------------------------------------------------------
-------------
--------------------------------------------------------------
-------------
--------------------------------------------------------------
-------------
