+10 Have the production server generate a report or otherwise provide feedback into the DMZ that it is up-to-date and eliminate this hideous security problem waiting to happen.
-ASB: http://XeeSM.com/AndrewBaker On Wed, Apr 7, 2010 at 9:16 AM, <[email protected]> wrote: > > Yup! > > Furthermore, it seems that, if all they want is to see if new data are > being incorporated into the app on the DMZ machine, they can just watch > that. > > Lonely down here in the boiler room, and SAs get insufficient respect... > > Thanks again! > -- > richard > > "Erik Goldoff" <[email protected]> wrote on 04/07/2010 08:12:00 AM: > > > > Maybe not my business, but > > > > > Why would the vendor need access to production servers once > > connected to DMZ ??? > > Would not a trusted VPN ( with signed agreements on usage and > > security ) for your vendor to access the production server be better > > than DMZ access if they truly do have a business need ??? > > > > Erik Goldoff > > IT Consultant > > Systems, Networks, & Security > > ' Security is an ongoing process, not a one time event ! ' > > From: [email protected] [mailto:[email protected]] > > Sent: Wednesday, April 07, 2010 9:03 AM > > To: NT System Admin Issues > > Subject: RE: Secure remote data entry > > > > > > Thanks! > > > > That is pretty much the way things are set now... > > > > DBA is relaying complaints from the vendors who insist that they > > need to get into the production servers once they are connected to > > the DMZ server. I say we need a different vendor (unfortunately notmy > call). > > > > > My heels are now dug in a bit deeper, however. > > > > Thanks again... > > -- > > richard > > > > "Erik Goldoff" <[email protected]> wrote on 04/07/2010 07:55:03 AM: > > > > > Why not have a database in the DMZ, and have the production database > > > pull added transactional data from the DMZ database via a one-way > > > trust into the domain. Don’t allow the production domain to trust > > > any connection initiated from the DMZ. > > > > > > Erik Goldoff > > > IT Consultant > > > Systems, Networks, & Security > > > ' Security is an ongoing process, not a one time event ! ' > > > From: [email protected] [mailto:[email protected]] > > > Sent: Wednesday, April 07, 2010 8:38 AM > > > To: NT System Admin Issues > > > Subject: Secure remote data entry > > > > > > > > > Greetings! Our DBA has a project going (with the help of an outside > > > vendor) in which animal welfare agents will enter stats into our > > > (internal) databases. > > > > > > This vendor says to set up a web server in a DMZ (done). Then, open > > > a port between this DMZ machine and our production database server. > Right! > > > > > > I can open that port in 2 minutes or less. It seems that, in 3 > > > minutes (a minute or less after I open that port), someone in > > > Tashkhent or Baku now owns our entire network (including main HQ a > > > half-continent away)... > > > > > > Our DMZ currently has no "DMZ to Trusted" policies, and it seems > > > that is what defines DMZ. A DMZ box gets compromized, but > > > attackers have no route on through to "Trusted". > > > > > > I'm catching some bad stares (and worse) for my stand on this, but > > > such is the life of a SysAdmin... > > > > > > SO, as nobody here manages a web-based point-of-sales operation, how > > > does one set up a secure remote data entry system? Our entire > > > economy seems to be based more and more on web-based (presumably) > > > secure sales transactions, so it can't be that difficult. > > > > > > Thanks! > > > -- > > > Richard D. McClary > > > Systems Administrator, Information Technology Group > > > ASPCA® > > > 1717 S. Philo Rd, Ste 36 > > > Urbana, IL 61802 > > > > > > [email protected] > > > > > > P: 217-337-9761 > > > C: 217-417-1182 > > > F: 217-337-9761 > > > www.aspca.org > > > > > > The information contained in this e-mail, and any attachments > > > hereto, is from The American Society for the Prevention of Cruelty > > to Animals® > > > (ASPCA®) and is intended only for use by the addressee(s) named > > > herein and may contain legally privileged and/or confidential > > > information. If you are not the intended recipient of this e-mail, > > > you are hereby notified that any dissemination, distribution, > > > copying or use of the contents of this e-mail, and any attachments > > > hereto, is strictly prohibited. If you have received this e-mail in > > > error, please immediately notify me by reply email and permanently > > > delete the original and any copy of this e-mail and any printout > thereof. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
