Thanks for the reply! :) On Tue, 2005-11-15 at 14:49 -0800, Jim Harrison (ISA) wrote: > This: > " The only last point I'd make is that I'd be hesitant in deploying ISA > in an internet facing role (although I do and have done that before) - > but I don't really have a justification for this aside from "it just > doesn't feel quite right". > " > > ..statement is something that is expressed fairly often, but fortunately > has not a single grain of substance to it. To James' credit, he does > qualify his hesistation...
Actually, a lot of my unease comes from the fact that I just don't understand it. I'm sorry to drag another thread into a windows vs. linux comparison, but going with what I know which is !windows, I know (fairly well) how netfilter mangles my packets when I setup a ruleset, I can debug it when it breaks, etc (I can follow the code) - I can't say the same about ISA Server, and I put a lot of faith in the product working as advertised when I use it. Part of my unease is attributable to this! > I know it sounds like marketing spew, but the simple fact is; in 5+ > years of service on anything from an SBS server, OEM appliance to HUGE > enterprise deployments, ISA server has the distinction of not having > been the recipient of one single exploit in the wild. Don't get me wrong - I frequently work with systems using ISA on such a scale, and I very much think that it's a capable firewall, proxy server, router, etc - but to say that there isn't one single exploit for ISA, although semantically correct, is something I'd necessarily agree with the truthfulness of (respectfully!) with regard to firewall *deployments*... > Yes; we've shipped patches for it and the odds are (realistically > speaking), we may well do so again. So do Cisco, Juniper, et al and we > don't hear the "just doesn't feel right" when they need patching. When you say that Cisco, Juniper, et al require patches, you're not comparing the firewalling stack of a Cisco firewall with the firewalling stack of an ISA Server Deployment, you're comparing the Cisco solution with the firewalling stack of an ISA Server Deployment - the two (obviously) are firewalls distributed in different manners.. If you are going to consider the Cisco firewall as a whole, you need to consider the ISA Server as a whole as well, and generally when there's an exploit for IOS released, I think I'm right in saying that it's for code which - in IOS - is analogous to Windows, the TCP/IP Stack, the remote administration method, or a daemon of some kind (IIS, WLBS, etc). Saying that if there's a patch required to address a RDP vulnerability it isn't anything to do with ISA is all well and good, but if every ISA Server is administrated via RDP (and realistically, most of them are) and there's a bug in RDP, then it doesn't matter technically whether the stack which is exploitable comes from one product team or other - the flaw for the consumer is in the *solution*. It is all Microsoft software, after all! This applies to TCP/IP, RDP, IIS, and many other services which frequently run on ISA boxes. I could equally say that there isn't a single exploit which has ever been released for netfilter (the firewalling layer in the linux kernel) because (as far as I'm aware - if I'm wrong correct me), but I'd simply be lying if I said that there had never been any exploits written for a firewall built on linux. The "firewall built on" caveat is really what's important and it applies as much to ISA as it does to netfilter. In a solution by solution comparison I'm fairly sure ISA and IOS (or Checkpoint, or Linux, or anything else for that matter) would stack up in a slightly different way. Going back to Cisco, I don't know the architecture of IOS well enough to specifically identify the components analogous to ISA, and all I can do is guess based on the vulnerabilities I've seen when I make the comparison. This isn't to say that ISA is a bad product - again, let me make myself quite clear in saying that I use, deploy, recommend, and enjoy using ISA - but it's far from perfect, just like any piece of software. > Contrast this with literally *no other* firewall maker (truthfully) > making this claim and you have quite a piece of information at your > disposal when you present your options in CxO-land. > > Jim Harrison > Security Platform Group (ISA SE) > If We Can't Fix It - It Ain't Broke! regards, - James. > -----Original Message----- > From: James Eaton-Lee [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 15, 2005 1:28 PM > To: Marcos Marrero > Cc: [email protected] > Subject: Re: ISA Server or Firewall Appliance? > > On Tue, 2005-11-15 at 11:58 -0500, Marcos Marrero wrote: > > Hello to all, > > > > I have a question to see what everyone out there thinks. Here it > goes... > > > > Is it better to have a firewall appliance (Checkpoint, Juniper, etc) > or > > is ISA server enough to use as a firewall (along with all of the other > > options it provides)? > > > > Of course the ISA server would sit facing the internet, like a > firewall > > would and it would have to sit on a hardened machine. > > > > Just want to know what everyone out there thinks about this > > configuration or idea? > > What you have to bear in mind here is that an appliance is, generally, a > hardware platform fairly similar to that which you might deploy ISA on > top of, with a proprietary operating system (typically based on freebsd, > or some other BSD-derived OS). Oftentimes these firewalls will run from > flash memory rather than hard disks, but that aside there can be very > few differences - I've seen more than one appliance (checkpoint being > just one) based around a fairly standard ATX motherboard with an > AthlonXP chip! > > Appliances have advantages in some instances and not in others. > > Specifically, due to the overhead of running ISA (which is harder to > chop down to provide a subset of the capabilities of a simpler package) > and a large, general purpose operating system, you'll almost find that > an appliance will handle a greater load then ISA on a similar box, > particularly if you're doing anything remotely intensive (although with > modern hardware you'll frequently hit hardware limitations first). > > Arguably, due to the dedicated nature of an appliance, it's also securer > as there are fewer running services, and there's more operating system > hardening and more functionality gutted out of the operating system - > less to go wrong, and less to exploit when something does. > > There are also disadvantages to appliances - they're, generally > speaking, not designed to be administered in as comprehensive-a manner > as their 'software' counterparts - meaning that when you do need to > remove or add something it can be harder. This argument applies equally > to adding NICs and, for instance, adding proxying capability. > > Specific to ISA, ISA is extremely flexible, and you'll probably find is > far more capable of being deployed in different roles than, for > instance, checkpoint. This is also a mixed blessing (as you don't > necessary want ISA providing routing for your internet backbone, even if > you can use it for this). It also benefits from domain integration, and > (in my opinion), this is one of the most compelling arguments in its > favour. > > You could also argue that if you want separation between different > segments of your security strategy, this is a bad thing when compared to > a set of checkpoint firewalls. > > You'll get a different argument on this from everyone (everyone has > their favourite firewall), but hopefully that's outlined some of the > broader arguments in favour of appliances vs. software firewalls. > > It's also worth looking (shudder the thought) at 'free' alternatives, if > you're doing a comparison - and there are just as many different options > here as there are in the commercial world, from the use of an operating > system which provides routing/firewalling capability through > kernel&userspace tools generally bundled with the OS (such as openbsd > with pf, freebsd with ipfw, or linux with iproute2/netfilter) to an > 'appliance' based on BSD or linux. > > The latter choice starts to become more appealing when you bear in mind > that plenty of vendors (checkpoint, juniper and borderware being just a > few) base their network devices on BSD (and some on linux, like > linksys). It's another debate entirely what they add to bog-standard > BSD, but the comparison is worth making. > > m0n0wall, ipcop, smoothwall and redwall are all worth looking at in > these situations - m0n0wall being perhaps the most appropriate for > deployments you may be looking at. They are worth at least looking at > when in the commercial world, license fees are such a large > consideration! > > The only last point I'd make is that I'd be hesitant in deploying ISA in > an internet facing role (although I do and have done that before) - but > I don't really have a justification for this aside from "it just doesn't > feel quite right". > > Hope that helps! :) > > - James. > > > Regards > > Marcos Marrero * Banking Officer * Data Security > > Lloyds TSB Bank * US Information Technology > > _________________________________ > > Tel: (305) 347-6421 * Fax (305) 371-8607 > > > > > > > > ********************************************************************** > > This Email is intended for the exclusive use of the addressee only. > > If you are not the intended recipient, you should not use the > > contents nor disclose them to any other person and you should > > immediately notify the sender and delete the Email. > > > > Lloyds TSB Bank plc is registered in England and Wales Number: 2065. > > Registered office: 25 Gresham Street, London EC2V 7HN. > > > > ********************************************************************** > > > > > > This email has been scanned for all viruses by the MessageLabs SkyScan > > service. > > > > > ------------------------------------------------------------------------ > --- > > > ------------------------------------------------------------------------ > --- > > > > > ------------------------------------------------------------------------ > --- > ------------------------------------------------------------------------ > --- > --------------------------------------------------------------------------- ---------------------------------------------------------------------------
