[isapros] Re: FW: FWENGMON issue for the brain trust

  • From: "Thor (Hammer of God)" <thor@xxxxxxxxxxxxxxx>
  • To: "isapros@xxxxxxxxxxxxx" <isapros@xxxxxxxxxxxxx>
  • Date: Fri, 07 Jul 2006 08:26:20 -0700

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
> 
> 
> 
> 
> 
> 


Other related posts: