You started it

[network-nerd.livejournal.com]

Yet another user installed an application that tries to sidestep firewalls -- in this case, some Yahoo VOIP thing that first tries port 5061, but if it can't get through then it falls back to 443 and finally 80, even though it's using SIP and not HTTP or HTTPS.

Grrr...

The best definition I know of for "firewall" is "Network Policy Enforcement Device". So if you engineer an app to bypass typical firewalls, what you've created is, by definition, a "Network Policy VIOLATION Device". So the end users you're trying to help go from just not being able to use an unauthorized application, to potentially being FIRED for trying. User friendly? Hardly.

Look, guys: If you build your nifty thingamabob assuming that network security is your users' enemy, guess what? IT WILL BE.

Play nice. Use your own ports, register and document them. I routinely Google on "product name" and "firewall" to learn what I have to do to allow my users to use said product, and make the appropriate adjustments, usually within 24 hours of the first request from a user that gets approved.

But pull a stunt like Yahoo, and I have to start blocking addresses and checking the status of funding for an SSL proxy and possibly making it a bit hard for our users to get to some approved destinations while figuring out how to block your crap. Result is that I'm not happy, and neither are my users, and so when it reaches someone who can approve the use of your app -- or NOT! -- on our network, my recommendation is going to be "No, we can't trust them" and odds are that the blocks will be made permanent.

And it will be your own fault.

Comments

[thecrazyfinn.livejournal.com]

One issue, and much of the reason for this sort of engineering, is getting around el-cheapo routers and certain large home ISP's that are known to do some port filtering. This is far more of a concern to the app designers than the problems with Corporate Firewalls.

[manuka.livejournal.com]

FWIW, Cisco's 7.x release of the PIX code will detect applications attempting to tunnel through http.

[samwize.livejournal.com]

"Play nice. Use your own ports, register and document them. I routinely Google on "product name" and "firewall" to learn what I have to do to allow my users to use said product, and make the appropriate adjustments, usually within 24 hours of the first request from a user that gets approved."

Yeah, that's great, and we're all real proud of you, and I hate to break it to you, but it doesn't matter AT ALL in the tiniest amount what _you_ do. What matters is what 90% of the people using the service experience. Most of them haven't a clue as to what a "firewall" is; they don't have the wherewithal to google useful technical information; they certainly aren't going to be able to open up a port for themselves. Even the ones that have sysadmins aren't much better off as most of them are too busy/constrained/inexperienced with security to do anything useful.

In short, you are blaming software developers for the fundamental tension between security and usability and their (perfectly reasonable) decision to opt for usability.

Honestly, if you're that much of a network nazi, why the hell are these people even allowed to install/run anything? For god's sake, just drop a group policy out there, lock down their workstations to business software, and be done with it.

samwize FTW!

[ihateemo.livejournal.com]

LOL @ "network nazi". But I agree with the thrust of the comment - disable admin rights on user workstations and the problem goes away. People don't NEED admin rights to do their jobs. By default, n00bs here don't have admin rights on their workstations because they install all kinds of shit that a) eats up drive space and b) has nothing to do with their jobs.

I have admin rights on mine, but then I've been here two years and I have the added bonus of not being a retard...