Web Server - User Access and Priviledges.

Web Server - User Access and Priviledges.

am 22.09.2004 16:15:59 von The Poster

G/Day Forum,

I'm currently hardening access to all my IIS 5.0 and IIS 6.0 servers, that
are located within multiple DMZ environments in multiple locations.



All servers are Firewalled and are administered through VPN's using Terminal
Services/RDP. Recently, I encountered a (self induced)problem with one of
these Servers where I mucked up the password change (on the only
Administrator account on the server) on one of our Production Systems - NOT
GOOD BUT I LEARNED MY LESSON. I managed to access the Sam database and reset
my password - thus enabling me to log back into the system. This required a
site visit and more importantly it created downtime that shouldn't have
happened if there was a fall back mechanism in place that corrects/prevents
this from happening.



Here is what I think should be done:

Create a second Administrator account on each Web Server. Take it that each
account password is 10 characters long and meets the complexity requirements
dictated by the local security policy - roughly 48 bit in strength. This
account will prevent anything like the incident above from happening.



For the purposes of deploying content and other information, I've created a
hidden share on the server - accessible from our corporate LAN environment
only. I've also created a user called 'ShareUser', specifically used for
accessing this hidden share. I've modified the NTFS and Share permissions to
reflect this user's required access. This will eliminate the administrators
from using the server Administrator credentials to access the we server
share for the future deployment of content to the WS. I also added this
account to the 'Deny Log on Locally' section of the Local Security Policy.



I'm also tempted to create another user specifically for Terminal Services
connections (thus removing the right of an Administrators to log on under a
Terminal Services session) - if they want Admin privileges then let that TS
user escalate to Admin through the usage of an Admin command shell or 'runas
'. I've read a few articles by Keith Brown - pluralsight.com (yep your
still talking to a Network Engineer) with regards to the utilisation of the
thinking that 'least privilege is best'. I agree and want to enforce. A
helpful blog that I found on running the explorer.exe process under a
different user can be found at
http://blogs.msdn.com/aaron_margosis/archive/2004/07/07.aspx



So what you ask am I posting to the newsgroup for? I'm trying to provoke a
response where my (maybe silly, ludicrous and daft) ideas are challenged,
corrected and hopefully improved.



Regards,

Steve.

Re: Web Server - User Access and Priviledges.

am 23.09.2004 02:50:04 von Steven L Umbach

It makes sense to have more than the built in administrator account. It also makes
sense to rename the built in administrator account and configure it's account
properties to not allow logon though TS as it is the top target of hackers. In
Windows 2003 Servers the built in administrators account can be disabled which I
think is a good idea. That account could still logon in safe mode. Non administrators
can access a server in Remote Administration mode if they have the right to logon
locally [ or through Terminal Services for W2003 ] and have user permissions to the
RDP protocol in Terminal Services Configuration. While hidden shares can be helpful
keep in mind that they are not hard to find and that ultimately you can not restrict
an administrator as an administrator can always take ownership and give themselves
permissions to anything on the computer that they have administrative rights on.
Ipsec filtering policies on a computer can also be used to restrict access to port
3389 used for TS from only authorized IP addresses. Ipsec policies do not require a
reboot when assigned or unassigned. For the IIS 5.0 server be sure to consider
running the IIS Lockdown/URLscan tool if you have not already but I would recommend
that you first backup at least the System State and IIS configuration. Be sure to
read the options closely for the IIS lockdown tool when it comes to what best
describes your IIS server needs. --- Steve

http://www.microsoft.com/downloads/details.aspx?FamilyID=dde 9efc0-bb30-47eb-9a61-fd755d23cdec&displaylang=en

"The Poster" wrote in message
news:uwQC44KoEHA.1300@TK2MSFTNGP12.phx.gbl...
> G/Day Forum,
>
> I'm currently hardening access to all my IIS 5.0 and IIS 6.0 servers, that
> are located within multiple DMZ environments in multiple locations.
>
>
>
> All servers are Firewalled and are administered through VPN's using Terminal
> Services/RDP. Recently, I encountered a (self induced)problem with one of
> these Servers where I mucked up the password change (on the only
> Administrator account on the server) on one of our Production Systems - NOT
> GOOD BUT I LEARNED MY LESSON. I managed to access the Sam database and reset
> my password - thus enabling me to log back into the system. This required a
> site visit and more importantly it created downtime that shouldn't have
> happened if there was a fall back mechanism in place that corrects/prevents
> this from happening.
>
>
>
> Here is what I think should be done:
>
> Create a second Administrator account on each Web Server. Take it that each
> account password is 10 characters long and meets the complexity requirements
> dictated by the local security policy - roughly 48 bit in strength. This
> account will prevent anything like the incident above from happening.
>
>
>
> For the purposes of deploying content and other information, I've created a
> hidden share on the server - accessible from our corporate LAN environment
> only. I've also created a user called 'ShareUser', specifically used for
> accessing this hidden share. I've modified the NTFS and Share permissions to
> reflect this user's required access. This will eliminate the administrators
> from using the server Administrator credentials to access the we server
> share for the future deployment of content to the WS. I also added this
> account to the 'Deny Log on Locally' section of the Local Security Policy.
>
>
>
> I'm also tempted to create another user specifically for Terminal Services
> connections (thus removing the right of an Administrators to log on under a
> Terminal Services session) - if they want Admin privileges then let that TS
> user escalate to Admin through the usage of an Admin command shell or 'runas
> '. I've read a few articles by Keith Brown - pluralsight.com (yep your
> still talking to a Network Engineer) with regards to the utilisation of the
> thinking that 'least privilege is best'. I agree and want to enforce. A
> helpful blog that I found on running the explorer.exe process under a
> different user can be found at
> http://blogs.msdn.com/aaron_margosis/archive/2004/07/07.aspx
>
>
>
> So what you ask am I posting to the newsgroup for? I'm trying to provoke a
> response where my (maybe silly, ludicrous and daft) ideas are challenged,
> corrected and hopefully improved.
>
>
>
> Regards,
>
> Steve.
>
>