"because some can't learn how to use it, the technique is flawed"? That's some really twisted logic... -----Original Message----- From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Amy Babinchak Sent: Tuesday, June 03, 2008 7:17 AM To: isapros@xxxxxxxxxxxxx Subject: [isapros] Re: ISA/IAG Topologies The newb and even those that shouldn't be newb have a difficult time understand the basic concept of an authenticated DMZ. To most DMZ means that you stick the server out there naked. Press the DMZ button and allow full access to the server. Don't bother to patch it because you'll probably have to re-image it from time to time anyway, since it's being constantly hacked upon. It's this attitude that causes me to say DMZ is dead. It's old outdated terminology that shouldn't be used anymore. ISA may have the ability to authenticate and protect servers in the DMZ but most don't. I really think that ISA needs a new term. thanks, Amy Babinchak Harbor Computer Services |(248) 850-8616 Learn about the perfect storm of rebates: June 10th at 9:00am and save money on your SBS 2008 upgrade. Join the meeting. Conference Bridge 866-500-6738 PC: 3876393 Tech Blog http://securesmb.harborcomputerservices.net Client Blog http://smalltechnotes.blogspot.com Website http://www.harborcomputerservices.net -----Original Message----- From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder Sent: Tuesday, June 03, 2008 10:11 AM To: isapros@xxxxxxxxxxxxx Subject: [isapros] Re: ISA/IAG Topologies Yo Jim, Now that is an interesting topic. A paper airplane is simple compared to a B1 bomber, but I'd argue that the B1 probably provides a higher level of security :) Bringing the analogy down a bit, "complexity" is operator dependent. Creating anonymous and authenticated access DMZs is simple for us, but complex for the ISA firewall neophyte. Does that mean the auth and anon DMZ concept is not secure? Or is it secure for us, but not secure for nEwB? Just playing with the idea of "complexity is the enemy of security". It sounds right to me, just trying to figure out the corrolary arguments. Thomas W Shinder, M.D. Site: www.isaserver.org Blog: http://blogs.isaserver.org/shinder/ Book: http://tinyurl.com/3xqb7 MVP -- Microsoft Firewalls (ISA) > -----Original Message----- > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf > Of Jim Harrison > Sent: Tuesday, June 03, 2008 9:00 AM > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Re: ISA/IAG Topologies > > Since "better" is subjective, I'd be more inclined to call it "better-isolated". > In general, any time you can functionally isolate (whether this is literal isolation is > another discussion) inbound and outbound traffic, your firewall policies and > requirements become simplified. It's a given that since complexity increases the odds > of human error, complexity must therefore be the enemy of security. > > > -----Original Message----- > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf > Of Jason Jones > Sent: Tuesday, June 03, 2008 3:35 AM > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Re: ISA/IAG Topologies > > So, in this scenario, I am right to consider a combined solution to get a "better" > security solution - yes? > > -----Original Message----- > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf > Of Jim Harrison > Sent: 02 June 2008 16:43 > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Re: ISA/IAG Topologies > > MS separates inbound and outbound arrays. > You're right; IAG sux as a fwd proxy and ISA bows to IAG remote client trust > mechanisms. > > > -----Original Message----- > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf > Of Jason Jones > Sent: Monday, June 02, 2008 7:16 AM > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Re: ISA/IAG Topologies > > As ever, I have left out the details until someone volunteers to help J > > > > I know that IAG *is* ISA, but in the current solution set the ISA "bit" doesn't scale very > well if you are looking at multiple IAG units to protect a data centre for all inbound and > outbound access. In this sort of scenario, IAG can't really cut it on it's own to facilitate > system -to-system communications (and authenticated outbound/forward access) and > ISA seems much more appropriate. I know ISA could be configured to do some of this, > but having to create firewall policy rules on each appliance and synchronise them > across several IAG appliances doesn't seem very elegant to me... > > > > So assuming we are looking at an Internet datacentre model (e.g. all the clients and > untrusted systems are on the outside) I am thinking that both IAG and ISA would be > needed to provide an elegant solution - yes? > > > In this model, it seemed to make sense to put ISA on the edge as it can provide LB/HA > out of the box (with NLB), whereas IAG cannot. ISA can then be used for "protection" > and IPSec VPN with IAG added for more advanced publishing with/without endpoint > checking as required. > > > > In the above model, I am leaning towards putting the external interface of IAG into an > ISA anonymous access DMZ, with both devices connected directly to the internal > protected network. However, I am curious if this provides little benefit and I may as > well simplify things by placing IAG in parallel if it will be dedicated for remote access > duties... > > > > Any chance of a hint at what MS IT do?? ;-) > > > > Jason Jones | Security | Silversands Limited | Desk: +44 (0)1202 360489 | Mobile: +44 > (0)7971 500312 | Email/MSN: jason.jones@xxxxxxxxxxxxxxxxx > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf > Of Jim Harrison > Sent: 02 June 2008 14:47 > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Re: ISA/IAG Topologies > > > > ..pick one. > > ..no; really - there is no "boilerplate". > > > > It depends on what you have for application and security requirements. > > IAG *is* ISA with some kewl stuff tossed into the mix. > > Thus, the question of whether to place IAG or ISA at the edge is equivalent to asking > "should I place ISA or ISA at the edge?" > > Deploying ISAG and ISA side-by-side will be determined by the tasking for each as > well. > > In general, using IAG for fwd traffic is; shall we say, a bit less than easy. > > Likewise, trying to duplicate the functionality IAG brings to the application publishing > game is impossible. > > > > IOW, their relative merits in a given scenario depend largely on what you want them to > do. > > > > Jim > > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf > Of Jason Jones > Sent: Monday, June 02, 2008 2:34 AM > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] ISA/IAG Topologies > > > > Hi All, > > > > I was wondering what sort of topologies you guys had used for customers who were > looking at combined ISA Server and IAG deployments? > > > > For example: > > > > Should ISA be the edge device with IAG in an ISA protected perimeter network? > > > > Should ISA and IAG be placed in parallel? > > > > Should IAG be placed between two ISA Server edge firewalls (e.g. between front-end > and back-end ISAs)? > > > > Any feedback appreciated... > > > > Cheers > > > > JJ > > > > > > > > > > ________________________________ > > This email and any files transmitted with it are confidential and intended solely for the > use of the individual to whom it is addressed. If you have received this email in error, > or if you believe this email is unsolicited and wish to be removed from any future > mailings, please contact our Support Desk immediately on 01202 360360 or email > helpdesk@xxxxxxxxxxxxxxxxx > > If this email contains a quotation then unless otherwise stated it is valid for 7 days and > offered subject to Silversands Professional Services Terms and Conditions, a copy of > which is available on request. Any pricing information, design information or > information concerning specific Silversands' staff contained in this email is > considered confidential or of commercial interest and exempt from the Freedom of > Information Act 2000. > > Any view or opinions presented are solely those of the author and do not necessarily > represent those of Silversands > > Silversands Limited, 3 Albany Park, Cabot Lane, Poole, BH17 7BX. > Company Registration Number : 2141393. > > > ________________________________ > > This email and any files transmitted with it are confidential and intended solely for the > use of the individual to whom it is addressed. If you have received this email in error, > or if you believe this email is unsolicited and wish to be removed from any future > mailings, please contact our Support Desk immediately on 01202 360360 or email > helpdesk@xxxxxxxxxxxxxxxxx > > If this email contains a quotation then unless otherwise stated it is valid for 7 days and > offered subject to Silversands Professional Services Terms and Conditions, a copy of > which is available on request. Any pricing information, design information or > information concerning specific Silversands' staff contained in this email is > considered confidential or of commercial interest and exempt from the Freedom of > Information Act 2000. > > Any view or opinions presented are solely those of the author and do not necessarily > represent those of Silversands > > Silversands Limited, 3 Albany Park, Cabot Lane, Poole, BH17 7BX. > Company Registration Number : 2141393. > > > > This email and any files transmitted with it are confidential and intended solely for the > use of the individual to whom it is addressed. If you have received this email in error, > or if you believe this email is unsolicited and wish to be removed from any future > mailings, please contact our Support Desk immediately on 01202 360360 or email > helpdesk@xxxxxxxxxxxxxxxxx > > If this email contains a quotation then unless otherwise stated it is valid for 7 days and > offered subject to Silversands Professional Services Terms and Conditions, a copy of > which is available on request. Any pricing information, design information or > information concerning specific Silversands' staff contained in this email is > considered confidential or of commercial interest and exempt from the Freedom of > Information Act 2000. > > Any view or opinions presented are solely those of the author and do not necessarily > represent those of Silversands > > Silversands Limited, 3 Albany Park, Cabot Lane, Poole, BH17 7BX. > Company Registration Number : 2141393. > > > >