piercing corporate FW outbound

[bscott at ntisys.com]

  First, let me add to what you astutely called a "political" discussion:

  Deliberately trying to bypass your employer's policies (firewall policy in
this case, but policy none-the-less) is not a good idea.  Even in the best
of cases, trying to bypass a security policy will likely get you fired.
Worst case, they get you charged with felony computer crime and you go to
jail.  I'm not being extreme; read up on what happened to Randall Schwartz
while he was working at Intel.

  If you hate what your employer is doing to you that much, say so.  Say you
feel you have been cheated, and that you're willing to quit over it.  If
they still won't budge, quit.  That's what employment at will is all about.  
They're not obligated to do what you want, and you're not obligated to work
for them.

On Fri, 6 Feb 2004, at 12:35pm, michael.odonnell at comcast.net wrote:
> ... because SSH isn't "secure", you see...

  Keep in mind that, in a corporate environment, "not secure" can include
"not being audited".  That is to say, your private use of SSH is resistant
to observation from corporate IT as well as from third-parties.  So they
can't know if you're using it right.  This is a very real thing.  As a
corporate IT manager, I don't care how secure a product *can* be; what I'm
interested in is how it fits into my security plan.  I don't let users make
those decisions for me.

  Now, on to the technical stuff...
  
On Fri, 6 Feb 2004, at 12:35pm, michael.odonnell at comcast.net wrote:
> Anyway, until recently I've still been able to get through by having my
> home server answer on port 80, as well, but now the IT geniuses have
> started doing some sort of traffic- or packet-analysis and squelching my
> SSH connection attempts on port 80, too. How do they do that?

  A computer protocol, by definition, has a fairly well defined structure.  
It's not hard to write a program to look at what is claiming to be HTTP
traffic and make sure it really is.  It's a bit harder to do it in real-time
in a firewall appliance, but there are plenty of products which do so.  The
techniques typically go by the name "application protocol inspection" or
"deep inspection", because they're not just looking at IP or TCP headers,
but all the way down into OSI Layer Seven.

  I've accomplished similar things using the Squid proxy/cache, an IPTables
firewall, and a transparent HTTP proxy.  Just deny the "CONNECT" method, and
everything that goes through at least has to smell like HTTP.

> Oh, I forgot to mention that there's a Nortel Contivity VPN rig involved,
> and they want me to go through that, and there's supposedly support for
> some Linux modules that allegedly work with it ...

  Yes.  While I don't have any real experience with them, my understanding 
that that Nortel's Contivity product line is a fairly large, full-featured 
security appliance, that supports both IPsec and PPTP.  Both are also 
supported under Linux.  For PPTP, look for "PoPToP".  For IPsec, look for 
"FreeS/WAN".

  FreeS/WAN is known to work, at least somewhat, with Nortel Contivity.

http://www.freeswan.org/freeswan_trees/freeswan-2.04/doc/interop.html#nortel

  If you're new to IPsec, I'll warn you upfront that it's complex as hell,
not well documented, and interoperability is a bear.  Feel free to ask for
help on this list.  I know we've got at least a couple people who work with
IPsec (I'm one of them), and while I don't know anything about Contivity, I
do know a fair bit about FreeS/WAN.

-- 
Ben Scott <bscott at ntisys.com>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.              |