• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 109
  • Last Modified:

Security Policy: MS servers (2003, 2008, 2012, ++) file transfer question.

Hi,
Thank you for any assistance you can provide.  

Q:  How can files be copied between MS servers with the below security requirements:
\\server111\c$\folder\file  -->  \\share$\folder\file   -->  \\server222\c$\folder\file

Main Goal: For MS servers (2003, 2008, 2012, ++), only Users with ADMIN permission Users are allowed on the c$ drive.  
IIS Developers are not given Admin permissions.  
Developers are given a specific GPO to allow only what is required for them to do their job with a higher then default User permissions, but lower then ADMIN permissions.  

With the following mostly related to, but not limited to, MS IIS web development process:  DEV   -->  Staging -->  Production  and the transfer of files between the 3 phases.  With DEV, Staging & Production environments having its own server instance.

My company has the following security requirements #1-5 below.

1.      No Local Shares (except for Users Home drives)
1.a.      This is for the purpose of preventing a Public server being mapped to a Private share.
2.  IIS Developers do not have Admin permissions
3.  RDP by Admin User not allowed
4.  share$ are accessed by Admin permission only
5.  No file transfer agent (FTP, SFTP, ect)
6.  Local Admin User is not allowed

Thanks, Scott
0
stepnharp
Asked:
stepnharp
1 Solution
 
NVITCommented:
> No Local Shares

Without creating a share, users can't see, and thus, copy files.
0
 
Dan McFaddenSystems EngineerCommented:
The security requirements are quite extreme and IMO overkill.

Typically "Public" accessible servers are placed on a DMZ subnet.  A network that exists between the Internet and your internal network.  In this scenario, the DMZ'ed servers should have no internal network access except over well defined and controlled ports.  If these were web servers, the access profile would be something like (not an exhaustive list):

From Internet to DMZ:
http (80/tcp) - allow anonymous  {web traffic}
https (443/tcp) - allow anonymous  {web traffic}
inbound smtp (25/tcp) - allow anonymous  {unknown inbound email traffic}
outbound smtp (25/tcp) - allow internal email server IPs  {your company outbound email traffic}

From Internet to internal network:
Deny All

From DMZ to internal:
Deny All
* this may need to be modified depending on your infrastructure, but it should be highly controlled

From internal network to DMZ:
http (80/tcp) - allow
https (443/tcp) - allow
ftp (20-21/tcp) - allow specific IPs
rdp (3389/tcp) - allow specific IPs
in & out smtp - allow to DMZ smtp relays

OK, I'm off my soap box, every company has their own reasons for security requirements.

Anyway, to your points"

1.  SysAdmins should work with a minimum of 2 accounts.

1) their regular day account. this account has no admin privileges!
2) their admin account.  this account is used for RDP or running process with a "Run as different user" functionality.  This account does not need an mailbox or user drives.
** this prevents your point 1a.
2. Developers do not need admin access to production servers.  This includes publish access to web applications.
3.  No RDP for Sysadmins is unbelievably restrictive.  I've never had this restriction in place in even the most secure of networks.  Management has to trust at least 1 sysadmin!
4. $ shares... access by only admins as expected
5. No file transfer agents... on the server side, ok.  But running an (S)FTP(S) Service on a server is a normal task.  No FTP traffic should be out of a server in a DMZ.
No file transfer protocols, means no file transfer.
BTW, http & https are essentially file transfer protocols!
6. "Local Admin User is not allowed"  is a bad policy.  If your domain connection is in some way disrupted and the local server will not recognize the cached domain credentials, you have no way of getting on to the machine until connectivity is restored.

To perform publishing of applications to web servers, with the above severe restrictions in place you could use 1 of the methods below.  Though they may stretch your company's secure policy.

1. Replication or synchronization software running as a service on a publisher device.  It would use the Admin share(s) to move files around.  Software packages use various file transfer methods.  OS copy, ftp, ftps, sftp, etc.  
2. Microsoft Web Deploy.  Only valid for IIS7+

Someway or another, you will have to enable a file transfer process with permission to Read, Write and Delete files on your servers.

Dan
0
 
stepnharpAuthor Commented:
Dan,  Thanks for your input.
0

Featured Post

Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now