Agreed, but the OP was talking about a product that his client is selling. Consulting with their customers about their network/domain design may be way beyond the scope of their business. I interpreted the post as looking for suggestions to improve the security of the product that might be installed on any number of widely varying domain and network configurations. What would you suggest in that regard?
Jeff On Fri, Oct 8, 2010 at 4:52 AM, Alan Davies <adav...@cls-services.com>wrote: > That's not really security. Once you have an account on a domain, you > are far more likely to be able to privilege escalate and further penetrate > the network/domain. The solution depends on how deep your pockets are and > how critical the data is. You could do it with a DMZ based domain I guess > .. at least you're not exposing your internal network then and making swiss > cheese out of your firewall! Still not ideal. > > Realistically, if this is critical and you're serious about protecting it, > the internal domain is never exposed to a DMZ. That's way OTT for a lot of > smaller companies though. You need a risk assessment of what you're trying > to protect, how strong your current mitigating controls are, etc. before you > can figure out what's cost effective. > > One suggestion was to pass authentication back to the DB tier - this is > very poor practice and should not be done for Internet facing services. > Ideally, you should be able to invoke any code at all from the web app until > you pass through a separated authentication layer. This way anonymous users > can never attempt to directly attack your application or database. > > > > a > > ------------------------------ > *From:* Jeff Bunting [mailto:bunting.j...@gmail.com] > *Sent:* 07 October 2010 22:05 > > *To:* NT System Admin Issues > *Subject:* Re: Need System/Application Security Advice > > Wouldn't restricting the systems the account can logon to in AD prevent > this? I've done this in the past, but the web servers were in their own > domain. > > Jeff > > On Thu, Oct 7, 2010 at 1:53 PM, Klint Price <kpr...@arizonaitpro.com>wrote: > >> So what steps should be taken to secure it since no instructions are >> provided to do so? >> >> >> >> Because IIS knows the password for the xyzweb account. If someone can get >> IIS to execute arbitrary code (e.g. by uploading some of their own webpages) >> then IIS can connect to serverB using the domain\xyzweb account, and that >> account has privileges on serverB. >> >> >> >> By running your website as a domain user it is basically giving permission >> to your web server to access anything that the user has access to on the >> entire domain. Wouldn’t that mean that >> if someone manages to take advantage of one of the many IIS >> vulnerabilities they very well may have access to information all over your >> network instead of just the one machine? >> >> >> >> A workaround or possible solution would be to instruct the customer that >> if they are going to use a domain account (which by architecture they are >> forcing them to do), that they should use a non-privileged account, and >> remove it from the “domain users” group. That way the account can be >> considered “authenticated”, but has no other default rights on the domain. >> Additional settings should be implemented to prevent the password from >> expiring, and locking out. >> >> >> >> >> >> >> >> *From:* Brian Desmond [mailto:br...@briandesmond.com] >> *Sent:* Thursday, October 07, 2010 10:49 AM >> >> *To:* NT System Admin Issues >> *Subject:* RE: Need System/Application Security Advice >> >> >> >> *It’s very common. There are many things you simply cannot do if you run >> in a local security context. FYI if you run the app pool as Network Service >> on a domain joined machine that provides it the domain rights of the >> server’s computer account.* >> >> ** >> >> *If an internet facing app even not in a corp environment runs on a web >> farm and is anything other than static content you’re almost guaranteed to >> have a domain and shared domain accounts running it too.* >> >> ** >> >> *Thanks,* >> >> *Brian Desmond* >> >> *br...@briandesmond.com* >> >> ** >> >> *c - 312.731.3132* >> >> ** >> >> ** >> >> *From:* Klint Price [mailto:kpr...@arizonaitpro.com] >> *Sent:* Thursday, October 07, 2010 7:36 PM >> *To:* NT System Admin Issues >> *Subject:* RE: Need System/Application Security Advice >> >> >> >> Internal corporate, yes. Directly exposed to the internet? I would hope >> not. >> >> >> >> *From:* Brian Desmond [mailto:br...@briandesmond.com] >> *Sent:* Thursday, October 07, 2010 10:34 AM >> *To:* NT System Admin Issues >> *Subject:* RE: Need System/Application Security Advice >> >> >> >> *Ermm what you describe (as I understand it) is probably how 75-90 >> percent of apps run on IIS in a corporate environment.* >> >> ** >> >> *Thanks,* >> >> *Brian Desmond* >> >> *br...@briandesmond.com* >> >> ** >> >> *c - 312.731.3132* >> >> ** >> >> ** >> >> *From:* Klint Price [mailto:kpr...@arizonaitpro.com] >> *Sent:* Thursday, October 07, 2010 7:28 PM >> >> *To:* NT System Admin Issues >> *Subject:* Need System/Application Security Advice >> >> >> >> My off-hour job is consulting for various companies. One such small >> company puts out a product that I feel needs to be fixed. >> >> >> >> Company sells two products; ProductA integrates with ProductB which both >> manage sensitive data and are exposed to the public Internet >> >> >> >> Windows Forms Authentication is tied to LDAP to authenticate users prior >> to allowing them into the inner-workings of the system. >> >> >> >> ProductA and ProductB are configured so that IIS allows a domain account >> to run the entire website for anonymous users (the equivalent of running an >> app pool with a domain account). >> >> >> >> Because the entire site runs under the domain account, there are inherent >> security risks which Company fails to disclose. >> >> >> >> I am about to send off an e-mail to the higher ups detailing why this is a >> bad idea without instructing the customer on the possible security risks, >> and associated steps to mitigate, let alone re-architect the application to >> reduce this exposure. >> >> >> >> Why is it a bad idea to configure a site in this way out-of-the-box, and >> what articles can you point me to? Any security articles would also be >> appreciated. >> >> >> >> At minimum I think the domain user should be removed from the “domain >> users” group, with additional GPO’s applied to lock down the account. >> >> >> >> What say ye? >> >> >> >> >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: >> http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to listmana...@lyris.sunbeltsoftware.com >> with the body: unsubscribe ntsysadmin >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: >> http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to listmana...@lyris.sunbeltsoftware.com >> with the body: unsubscribe ntsysadmin >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: >> http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to listmana...@lyris.sunbeltsoftware.com >> with the body: unsubscribe ntsysadmin >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: >> http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to listmana...@lyris.sunbeltsoftware.com >> with the body: unsubscribe ntsysadmin >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: >> http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to listmana...@lyris.sunbeltsoftware.com >> with the body: unsubscribe ntsysadmin >> > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > > > ************************************************************************************ > > WARNING: > > The information in this email and any attachments is confidential and may > be legally privileged. > > > > If you are not the named addressee, you must not use, copy or disclose this > email (including any attachments) or the information in it save to the named > addressee nor take any action in reliance on it. If you receive this email > or any attachments in error, please notify the sender immediately and then > delete the same and any copies. > > > > "CLS Services Ltd × Registered in England No 4132704 × Registered Office: > Exchange Tower × One Harbour Exchange Square × London E14 9GE" > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
