1999-05-27-18:11:05 Andy:
> I'm even less than a security novice, but I have been tasked to build a
> client-server application with a custom protocol that will need to traverse
> various firewalls at the client's LAN's.
That would be pretty distressing if I thought it were entirely true --- but
between your presence on this forum, and the trend of your thoughts, I think
your disclaimer is way over-strong. You care about security and know something
about it. Would that more network app architects shared those virtues.
So on to your specific situation. My first big recommendation is to seriously
try and see if any existing, widely-deployed, widely-used protocol would be
suitable for running your service; if so, then you can enjoy the security
analysis and understanding that the existing protocol enjoys and avoid any
new issues of your own. Be careful what existing protocol you pick; if e.g.
you choose straight, standards-conforming email, and are intelligent and
reasonable in what you do with it, then firewalls are nearly always perfectly
transparent to you; at the opposite extreme, if you use wassname, H.323,
T.120, and friends, the Netmeeting protocol suite, then you will find all
firewalls completely closed to you (there are boxes that may even be labelled
"firewalls" that will let netmeeting through, but the people who label 'em
"firewalls" wouldn't hang out hereabouts:-). But even if you end up deciding
that some complete bletcherous loser of a protocol is the best fit for your
app, you've still profited: use the security criticisms levelled at that
protocol to improve your design.
If no existing protocol is suitable, then the analysis that convinced you of
that will produce as a happy byproduct a statement --- hopefully short and
simple --- of what is special and new about your protocol that requires that
you write a new one. That's one big component of the package you need to hand
to a firewall admin to get 'em to tear open a hole for you.
Here's another one: what's your network protocol. What bytes are you going to
be passing over your connection, to do what?
And here's another: what's your security model? Do you handle only
non-security-sensitive information ("world-readable") and carefully ensure
that no query can change or damage the server? Or do you perhaps offer
carefully-defined and -controlled facilities for making changes, after
suitable authentication? And if so do you include crypto of your own, or are
you dependant on the network implementation around you to prevent password
capture, session hijacking, and other such problems?
I can't think of too many other such questions. Get that lot wrapped in a tidy
little pamphlet, and the only firewall admins that'll give you grief are just
BOFHs enjoying abusing their users; fw admins who actually care about security
will welcome you with open arms.
Oh, and if when you get done you aren't sure if your pamphlet is really ready
to do the job, feel free to circulate it here; plenty of the best brains in
the business will be happy to critique your work for free, as a sort of
welcome to the fraternity of people making internet security better rather
than worse.
-Bennett
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
