While it would be an ³improvement,² I think it would only be a ³feel-good² measure. The same malicious admin would just clear the logs. t On 7/7/06 7:03 AM, "Young, Gerald G" <Gerald.Young@xxxxxxxxxx> spoketh to all: > Hmmm? > > I¹m afraid to voice my opinion because I certainly don¹t want to be shunned > but? > > Would it be that hard to add the event log and auditing features to the tool > or the APIs? I mean, that would be an ³improvement², wouldn¹t it? > > And there are different levels of abuse this tool or APIs could potentially > allow. Suppose an unethical admin out there used it to create a bypass to a > questionable website or something. Does the bypass mean that ISA wouldn¹t even > log the traffic? Or, reverse that and suppose the unethical admin is working > with an outside source and he creates an incoming bypass. If you can¹t see > the bypass, chances are inbound traffic won¹t be noticed unless it¹s pervasive > or something else brings attention back to the firewall. > > And keep in mind that someone could create another utility that makes use of > those APIs by playing with ISA on their own and then publish that utility once > they figure out what those APIs are. > > In my opinion, if adding that functionality to the tool or APIs helps to > minimize those kinds of risks, it makes sense to me to add it. > > Cordially yours, > Jerry G. Young II > MCSE (4.0/W2K) > Atlanta EES Implementation Team Lead > ECNS Microsoft Engineering > Unisys > > 11493 Sunset Hills Rd. > Reston, VA 20190 > Office: 703-579-2727 > Cell: 703-625-1468 > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > > > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On > Behalf Of Jim Harrison > Sent: Friday, July 07, 2006 1:12 AM > To: isapros@xxxxxxxxxxxxx > Subject: RE: [isapros] FW: FWENGMON issue for the brain trust > > > I do, but Danny made me wait until I stopped spitting expletives. > > > > I agree with message #2 - if the app isn't there, the functionality isn't > available. > > Granted, the Mark Russonovich's or Tim Mullens could probably sniff out the > APIs and create all manner of H&D, but so what - anyone of that skill level > that has direct local-admin access to your box just got themselves a free > server anyway. > > > > If the app isn't left on the box and the attacker doesn't have local-logon, > admin rights (oh damn; game over), then WTF cares what APIs may exist that you > can't get to without prior knowledge (and not-insignificant programming > skills) or a product-team-provided debugging tool? IOW, if they're all that > worried about who can do what when they log onto the ISA locally as an ISA > admin, they've already lost the war. > > > > This guy has way too much time on his hands if this is the sort of thing he > gets wound up about. Was this Andy? > > > > We now return you to your regularly scheduled profanity-filled retorts. > > > > > From: isapros-bounce@xxxxxxxxxxxxx on behalf of Thomas W Shinder > Sent: Thu 7/6/2006 2:22 PM > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] FW: FWENGMON issue for the brain trust > > No one gots no opinion on this one? > > -----Original Message----- > From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] > On Behalf Of Thomas W Shinder > Sent: Wednesday, July 05, 2006 9:10 PM > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] FWENGMON issue for the brain trust > > Hey folks, > > There was a discussion on the beta newsgroup that I thought would be > interesting to put in front of the brain trust. There's nothing NDA > here, so it's cool. My impression is that the person who was concerned > about the fwengmon /allow option is akin to the IPv6 issue -- if the > admin is incompetent, malicious or both, then of course the fwengmon > /all option can be abused. But the same incompetent and malicious admins > can hork any other kind of firewall. > The example of the SBSer reading e-mail on the box is archetypal > for the idiot admin who goes out of his way to subvert firewall > security, so how is this different from creating an "allow all from > everyone to everywhere" which you can do on any firewall, including the > ISA firewall? > Wondering if customers really need to get their undies in a > bunch about this or its is calling "fire" at a weenie roast? > > =========================== > Message 1: > In my personal opinion, the interface method which "fwengmon.exe /allow" > > calls should not exist; there should be no such bypass-the-firewall > method, > even if it is handy for troubleshooting. > > If it can't be removed, then there should at least be an Event Log > message > whenever it's invoked, and the fwengmon.exe tool should be able to > display > whether or not there are any bypasses currently configured so that it > can be > audited (the "/noallow" switch will turn any bypasses off, but it > doesn't > indicate whether it did anything or what the IP addresses were in the > cancelled bypass). > > I'm sure the ISA development team uses the bypass feature constantly, > but > that's development/debug code, and it wouldn't have to exist when the > final > product ships. Whenever I show others the "/allow" switch and its > invisibility of operation, the response is always very negative. > > Message 2: > Yes, but you have to get the file on the box. If I can place files on > the > firewall without your knowledge, the game is already over, isn't it? > > Message 3: > I agree it's a bit paranoid, but I think the even greater threat comes > from > external buffer overflow attacks that call that method or malware that > does > the same when invoked by an interactively-logged on administrator who > browses the net or reads e-mail as admin while at the ISA box (which > will > probably be running SBS, yet it will be ISA that gets the blame for it > when > the vulnerability is published). In these cases, fwengmon.exe wouldn't > even > have to be on the local drive. At a minimum, it would be nice if > invoking > that method --whatever it is-- at least wrote a message to an Event Log. > (I > also don't like how "lockdown mode" does not drop all existing > connections > and still allows new outbound connections, but that's another story and > easy > enough to fix with a custom panic script.) > > On a purely marketing level, too, ISA has lots of prejudice to overcome, > so > I've encountered anti-Microsoft sysadmins who jump all over this > "invisible > hole feature" to undermine ISA as a trustworthy firewall (and then this > can > sway the fence-sitters in the room to lean to the negative side). I'd > still > prefer it if this firewall-bypass functionality didn't exist at all... > ====================== > > > Thomas W Shinder, M.D. > Site: www.isaserver.org <http://www.isaserver.org/> > Blog: http://blogs.isaserver.org/shinder/ > Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7> > MVP -- ISA Firewalls > > > > > >