I have a question concerning client security.

We have a demo copier that can send scanned documents in a PDF format to a
shared folder destination on a workstation in our local domain by means of
either SMB or FTP.

With SMB, the copier uses an older method of authentication (NTLM v. 0.12)
so it is incapable of accessing a folder on our Windows Small Business Server
2003 which requires the digital signing. In order for this copier to send to
a folder on our server we would have to disable the digital signing on the
server. That is not an option. We need to keep the server secure.

Since this device can access a folder on a workstation via SMB by the method
described, my question is - will this scenario compromise the overall
security of our network? Will the separation from the server by scanning to a
workstation allow for greater security considering the logon limitations of
the copier?

The ultimate goal is to place scans in a common folder on the Windows Small
Business Server 2003 that can be accessed only by authorized network clients
- either locally or remotely.

As I also mentioned, there is a possibility of using FTP to put scans on the
workstation. Only the workstation will have to have an FTP server running to
accept the scans from the copier. I had heard that we should not run FTP
server software on our Windows Small Business Server 2003. How will this
affect our network's security to run an FTP Server on the workstation?

I know that our security is only as strong as the weakest link. I am curious
about the implications of either method and the effect on our secure
environment.

Thank you for your answers.

Marvin

Re: XP client security by Steven

Steven
Thu Nov 04 10:33:52 CST 2004

The problem with the Windows ftp server is that you have to use either
anonymous or basic authentication which uses clear text for user passwords.
SMB signing in itself is not a strong security method, though it makes sense
to use it where you can. It does make sure that the packets have not been
modified but it does not encrypt the packets and ensure authenticity like
ipsec will using ESP and AH. NTLM is a much more secure authentication
method than LM, so at least you have that going for you. You can also use
security policy to change SMB signing so that it will be used "when
possible" which means that it will be used whenever it communicates with a
W2K/W2003/XP Pro but allow communications with computers that can not use it
like your copier which is what I would recommend rather that try to use ftp.
The link below is to the XP/2003 Threats and Countermeasures Guide which
explains many more options to secure your network. --- Steve

http://www.microsoft.com/technet/Security/topics/hardsys/tcg/tcgch00.mspx


"M" <M@discussions.microsoft.com> wrote in message
news:AFAC75DA-5C0D-4E46-8FFC-52F6FD6335A7@microsoft.com...
>I have a question concerning client security.
>
> We have a demo copier that can send scanned documents in a PDF format to a
> shared folder destination on a workstation in our local domain by means of
> either SMB or FTP.
>
> With SMB, the copier uses an older method of authentication (NTLM v. 0.12)
> so it is incapable of accessing a folder on our Windows Small Business
> Server
> 2003 which requires the digital signing. In order for this copier to send
> to
> a folder on our server we would have to disable the digital signing on the
> server. That is not an option. We need to keep the server secure.
>
> Since this device can access a folder on a workstation via SMB by the
> method
> described, my question is - will this scenario compromise the overall
> security of our network? Will the separation from the server by scanning
> to a
> workstation allow for greater security considering the logon limitations
> of
> the copier?
>
> The ultimate goal is to place scans in a common folder on the Windows
> Small
> Business Server 2003 that can be accessed only by authorized network
> clients
> - either locally or remotely.
>
> As I also mentioned, there is a possibility of using FTP to put scans on
> the
> workstation. Only the workstation will have to have an FTP server running
> to
> accept the scans from the copier. I had heard that we should not run FTP
> server software on our Windows Small Business Server 2003. How will this
> affect our network's security to run an FTP Server on the workstation?
>
> I know that our security is only as strong as the weakest link. I am
> curious
> about the implications of either method and the effect on our secure
> environment.
>
> Thank you for your answers.
>
> Marvin
>
>



Re: XP client security by M

M
Thu Nov 04 11:09:03 CST 2004

Thanks for your input Steven.

I was looking at the copier and there is a place to indicate DNS Servers
along with giving the copier a host name and specifying the local domain. It
also appears to be able to perform DNS Dynamic Update as well.

Does it seem feasible in our case to create a domain user account for the
copier under which it can log on to the client workstation to access the
shared folder with permissions to write to the folder since it will be
sending scans to the shared folder?

Thanks again-

Marvin

"Steven L Umbach" wrote:

> The problem with the Windows ftp server is that you have to use either
> anonymous or basic authentication which uses clear text for user passwords.
> SMB signing in itself is not a strong security method, though it makes sense
> to use it where you can. It does make sure that the packets have not been
> modified but it does not encrypt the packets and ensure authenticity like
> ipsec will using ESP and AH. NTLM is a much more secure authentication
> method than LM, so at least you have that going for you. You can also use
> security policy to change SMB signing so that it will be used "when
> possible" which means that it will be used whenever it communicates with a
> W2K/W2003/XP Pro but allow communications with computers that can not use it
> like your copier which is what I would recommend rather that try to use ftp.
> The link below is to the XP/2003 Threats and Countermeasures Guide which
> explains many more options to secure your network. --- Steve
>
> http://www.microsoft.com/technet/Security/topics/hardsys/tcg/tcgch00.mspx
>
>
> "M" <M@discussions.microsoft.com> wrote in message
> news:AFAC75DA-5C0D-4E46-8FFC-52F6FD6335A7@microsoft.com...
> >I have a question concerning client security.
> >
> > We have a demo copier that can send scanned documents in a PDF format to a
> > shared folder destination on a workstation in our local domain by means of
> > either SMB or FTP.
> >
> > With SMB, the copier uses an older method of authentication (NTLM v. 0.12)
> > so it is incapable of accessing a folder on our Windows Small Business
> > Server
> > 2003 which requires the digital signing. In order for this copier to send
> > to
> > a folder on our server we would have to disable the digital signing on the
> > server. That is not an option. We need to keep the server secure.
> >
> > Since this device can access a folder on a workstation via SMB by the
> > method
> > described, my question is - will this scenario compromise the overall
> > security of our network? Will the separation from the server by scanning
> > to a
> > workstation allow for greater security considering the logon limitations
> > of
> > the copier?
> >
> > The ultimate goal is to place scans in a common folder on the Windows
> > Small
> > Business Server 2003 that can be accessed only by authorized network
> > clients
> > - either locally or remotely.
> >
> > As I also mentioned, there is a possibility of using FTP to put scans on
> > the
> > workstation. Only the workstation will have to have an FTP server running
> > to
> > accept the scans from the copier. I had heard that we should not run FTP
> > server software on our Windows Small Business Server 2003. How will this
> > affect our network's security to run an FTP Server on the workstation?
> >
> > I know that our security is only as strong as the weakest link. I am
> > curious
> > about the implications of either method and the effect on our secure
> > environment.
> >
> > Thank you for your answers.
> >
> > Marvin
> >
> >
>
>
>

Re: XP client security by Steven

Steven
Sat Nov 06 21:33:19 CST 2004

That should be fine. Otherwise you would probably have to enable the guest
account on that computer to enable it to send scans to a share. A normal
domain user account would be the way to go. --- Steve


"M" <M@discussions.microsoft.com> wrote in message
news:697EEEA1-B07A-430B-889E-877CD5E11268@microsoft.com...
> Thanks for your input Steven.
>
> I was looking at the copier and there is a place to indicate DNS Servers
> along with giving the copier a host name and specifying the local domain.
It
> also appears to be able to perform DNS Dynamic Update as well.
>
> Does it seem feasible in our case to create a domain user account for the
> copier under which it can log on to the client workstation to access the
> shared folder with permissions to write to the folder since it will be
> sending scans to the shared folder?
>
> Thanks again-
>
> Marvin
>
> "Steven L Umbach" wrote:
>
> > The problem with the Windows ftp server is that you have to use either
> > anonymous or basic authentication which uses clear text for user
passwords.
> > SMB signing in itself is not a strong security method, though it makes
sense
> > to use it where you can. It does make sure that the packets have not
been
> > modified but it does not encrypt the packets and ensure authenticity
like
> > ipsec will using ESP and AH. NTLM is a much more secure authentication
> > method than LM, so at least you have that going for you. You can also
use
> > security policy to change SMB signing so that it will be used "when
> > possible" which means that it will be used whenever it communicates with
a
> > W2K/W2003/XP Pro but allow communications with computers that can not
use it
> > like your copier which is what I would recommend rather that try to use
ftp.
> > The link below is to the XP/2003 Threats and Countermeasures Guide which
> > explains many more options to secure your network. --- Steve
> >
> >
http://www.microsoft.com/technet/Security/topics/hardsys/tcg/tcgch00.mspx
> >
> >
> > "M" <M@discussions.microsoft.com> wrote in message
> > news:AFAC75DA-5C0D-4E46-8FFC-52F6FD6335A7@microsoft.com...
> > >I have a question concerning client security.
> > >
> > > We have a demo copier that can send scanned documents in a PDF format
to a
> > > shared folder destination on a workstation in our local domain by
means of
> > > either SMB or FTP.
> > >
> > > With SMB, the copier uses an older method of authentication (NTLM v.
0.12)
> > > so it is incapable of accessing a folder on our Windows Small Business
> > > Server
> > > 2003 which requires the digital signing. In order for this copier to
send
> > > to
> > > a folder on our server we would have to disable the digital signing on
the
> > > server. That is not an option. We need to keep the server secure.
> > >
> > > Since this device can access a folder on a workstation via SMB by the
> > > method
> > > described, my question is - will this scenario compromise the overall
> > > security of our network? Will the separation from the server by
scanning
> > > to a
> > > workstation allow for greater security considering the logon
limitations
> > > of
> > > the copier?
> > >
> > > The ultimate goal is to place scans in a common folder on the Windows
> > > Small
> > > Business Server 2003 that can be accessed only by authorized network
> > > clients
> > > - either locally or remotely.
> > >
> > > As I also mentioned, there is a possibility of using FTP to put scans
on
> > > the
> > > workstation. Only the workstation will have to have an FTP server
running
> > > to
> > > accept the scans from the copier. I had heard that we should not run
FTP
> > > server software on our Windows Small Business Server 2003. How will
this
> > > affect our network's security to run an FTP Server on the workstation?
> > >
> > > I know that our security is only as strong as the weakest link. I am
> > > curious
> > > about the implications of either method and the effect on our secure
> > > environment.
> > >
> > > Thank you for your answers.
> > >
> > > Marvin
> > >
> > >
> >
> >
> >