On Thu, 3 Jan 2002, Jonas M Luster wrote: > You *do* know how HTTP, the Hypertext Transfer Protocol, works? To even > imply, WebEx "does it over HTTP" makes me shudder. WebEx uses a > Website to establish the initial meeting parameters and, from there on, > could potentiall use every Port available. Which is, btw., not that
"Could," but that's not what's implied by their literature: http://www.webex.com/home/services_oncall.html?Track=hometext "WebEx OnCall agents can instantly engage customers in on-line interactive support sessions live over the Web without the need to pre-install or pre-configure any software. " "the Web" being the operative phrase. Maybe to you the Web means "TCP," but that's not the accepted definition. Futher on down the same page: "Netscape Communicator 4.x or Microsoft Internet Explorer 4.x, JavaScript and cookies enabled" If they're opening sockets and not tunneling over HTTP using Netscape and Javascript (note: not Java- Javascript) then they've got some pretty darned impressive programmers. [snip] > > Perhaps you will _if_ you're an intentionally malicious user, but we have > > two issues here that aren't covered by that, the first is an oppertunity > > for a released employee, and the second is for a user to lower the overall > > Please, show me a usage scenario in which a released employee, from > remote, activates this remote control functionality. He will need > exactly that level of access he would gain by activating this feature > to activate it. IF the user has the ability to start the client, he > already HAS full access to the desktop. Certainly he does- however unlike Sub7 who's ~350 variants can be automatically be put into the malcode category, suddenly firewalls are supposed to automatically know which support connections are "good" and which are "bad." Such trends reduce the protective value of the firewall's protection model significantly- and with cooperative engineering need not do so. > The WebEx client is not bound to a socket, cannot be accessed inbound > and requires ative interaction *on the shared dektop* to share the > desktop. Again, how would you propose I'd do that? There are plenty of record/playback features which can be automated and scheduled. > > > Aggreed. Poor business decisions should not be blamed on vendors or > > > concepts, though. It seems you have not had a look into the way WebEx > > > works: > > > > It seems you've only looked at the "meeting" feautre, and not the "remote > > support" feature. > > In fact, I looked at exactly this feature a lot lately. An awful lot. > > > Apples and oranges are alike because they are both fruit, claiming that > > So, what you're saying here, is that you compare apples and oranges to > draw your conclusions? What I'm saying is that when one talks about fruit, the difference between an apple and and orange isn't as significant as the difference between an apple and a rock. > > > Assuming the administrator still has enough access to activate the > > > sharing, the NetSec dept. has a bigger problem than WebEx being > > > installed. There is NO way to connect to a box with WebEx' client > > > installed. The client connects outbound. > > > > If you can't automate an outbound connection... > > If you can automate an outbound connection, you do not need WebEx. I > can use a web browser for this kind of exploit, a mail program, an IRC > client, a telnet client, a ftp client, yada yada. At that point, you > just declared *everything* on a computer a severe security risk. What > is to stop me from automating MSIE to connect to Port 80 on my > malicious server, download payload and execute payload, e.g. a program > to project dektop data hidden in seemingly legitimate HTTP requests > and receiving commands via HTTP responses? It's easy. To decry WebEx > as any kind of security threat, just because it can be used like any > other software out there, is irrational. To ignore tunnels because they're easy to make is silly. To promote products which tunnel without any enterprise control features which will then become mandated into support contracts and the like sillier still. Such products *can* be made *security friendly* by vendors instead of simply security agnostic like everything else. > > Absolutely- there's no way I'd allow a tunnel like SSH inbound- it'd be > > silly to complain about tunnels if I simply allowed them. > > You just told me, you allow VNC over SSH inbound. No, what I said was two seperate things- if I used VNC, I'd use it over SSH, and that if I needed to allow remote access to a machine for support work, I'd be much happier to control the inbound access to that facility with something firewall-friendly enough to allow specific host/date/time access rather than something that's deep down in the weeds with the other Web traffic. > > Absolutely- I guess you're aware that not everyone runs packet filtering > > only firewalls in "let it all through" mode? > > A firewall is, first and foremost, a concept. It's a divider between > two networks, which is one of the reasons the name "Personal Firewall" > for those "Packet-Filter-IDS-Application-Blocker"-Monsters is a > misnomer. How I run firewalls is a question of network design, and > hopefully no two setups are alike. To assume anything, from "packet > filtering only firewalls in "let it all through" mode" to full fledged > layers of pyaload inspection, promotes insecurity. So does misnoming > and confusing servers with clients (hint: man bind(2)) Perhaps you should go look up the meaning of server again- a server isn't simply the thing that listens, it's the thing that serves resources- hence the usual confusion over X servers. Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact." _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
