security should be the issue here, especially with X sesions as X is a
well known risk and has been since the old mitnick days and prior...
Thanks,
Ron DuFresne
On Thu, 18 Jan 2001, Noonan, Wesley wrote:
> Unfortunately, I am being told that Solaris does not ship with SSH and it
> would take making some changes to the classrooms that they aren't prepared
> to make right now. I think this is something that we will probably pursue as
> a long term solution though, based on what I am hearing in this thread and
> from the trainers involved. In the short term though, I need to get access
> working. Would those conduits do the trick? Am I correct in thinking that it
> isn't working because the server needs to send data back on different ports
> to the clients and those ports are closed? Would it be better to use the
> established command?
>
> One thing to keep in mind right now is that security isn't the high priority
> here. We aren't sending any data across the internet.
>
> We are currently running 5.1(2). Let me see what I can dig up on 5.1(3).
>
> Thanks again.
>
> Wes Noonan, MCSE/MCT/CCNA/NNCSS
> Senior QA Rep.
> BMC Software, Inc.
> (713) 918-2412
> [EMAIL PROTECTED]
> http://www.bmc.com
>
> -----Original Message-----
> From: Rich Pitcock [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 18, 2001 11:30
> To: 'Noonan, Wesley' '
> Cc: '[EMAIL PROTECTED]' '
> Subject: RE: Permiting X through a PIX
>
> SSH is the way to go but if it is not an option then PIX Firewall ver 5.13
> supports XDMCP (X Display Manager Control Protocol) XWindows TCP back
> connection. XDMCP uses UDP port 177. XWindows uses TCP ports 6000 through
> 6063.
>
> Rich
>
> -----Original Message-----
> From: Ron DuFresne
> To: Ng, Kenneth (US)
> Cc: 'Noonan, Wesley'; '[EMAIL PROTECTED]'
> Sent: 1/18/01 12:21 PM
> Subject: RE: Permiting X through a PIX
>
>
> He';s still going to need to open his 600 port though.
>
> Thanks,
>
> Ron DuFresne
>
> On Thu, 18 Jan 2001, Ng, Kenneth (US) wrote:
>
> > Allow ssh to go through instead. The user will log onto the machine
> via
> > ssh. ssh will set the DISPLAY environment variable so that when apps
> are
> > started up, they tunnel back to the user's workstation. On the whole
> I
> > think this is a better way to do it if you need X. Also works great
> if you
> > need to run through NAT.
> >
> > -----Original Message-----
> > From: Noonan, Wesley [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, January 18, 2001 11:49 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: Permiting X through a PIX
> >
> >
> > Hello all. I need some advice from the experts around here.
> >
> > I have a situation where I have a PIX with 4 interfaces. 2 are inside
> and
> > outside and 2 are considered DMZ1 and DMZ2. DMZ2 is a higher security
> than
> > DMZ1 (thus all traffic is permitted outbound from DMZ2 to DMZ1). We
> have
> > various machines on DMZ2 than need to access 2 servers on DMZ1 via X.
> For
> > some reason this is not working, and unfortunately, I am not a Unix
> guru and
> > know very little about X. My suspicion is that X requires that the
> target
> > machine (the server) be able to send data back to the clients, which
> of
> > course is being blocked by the firewall.
> >
> > Here is a little diagram
> > Server2
> > DMZ2----PIX----DMZ1---[
> > Server1
> >
> > So, what I am wondering is how to proceed. I am pretty sure that X
> uses TCP
> > and UDP 6000-6063. Based on that, one of my ideas is to setup a
> conduit as
> > follows:
> > Conduit permit tcp 172.16.0.0 255.255.255.0 range 6000 6063 host
> 172.16.1.2
> > Conduit permit udp 172.16.0.0 255.255.255.0 range 6000 6063 host
> 172.16.1.2
> > Conduit permit tcp 172.16.0.0 255.255.255.0 range 6000 6063 host
> 172.16.1.3
> > Conduit permit udp 172.16.0.0 255.255.255.0 range 6000 6063 host
> 172.16.1.3
> >
> > The other idea is to use the established command, but I am not very
> familiar
> > with it's use.
> >
> > Any ideas? TIA
> >
> > Wes Noonan, MCSE/MCT/CCNA/NNCSS
> > Senior QA Rep.
> > BMC Software, Inc.
> > (713) 918-2412
> > [EMAIL PROTECTED]
> > http://www.bmc.com
> >
> > -
> > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > "unsubscribe firewalls" in the body of the message.]
> >
> ************************************************************************
> *****
> > The information in this email is confidential and may be legally
> privileged.
> > It is intended solely for the addressee. Access to this email by
> anyone else
> > is unauthorized.
> >
> > If you are not the intended recipient, any disclosure, copying,
> distribution
> > or any action taken or omitted to be taken in reliance on it, is
> prohibited
> > and may be unlawful. When addressed to our clients any opinions or
> advice
> > contained in this email are subject to the terms and conditions
> expressed in
> > the governing KPMG client engagement letter.
> >
> ************************************************************************
> *****
> > -
> > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > "unsubscribe firewalls" in the body of the message.]
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Cutting the space budget really restores my faith in humanity. It
> eliminates dreams, goals, and ideals and lets us get straight to the
> business of hate, debauchery, and self-annihilation." -- Johnny Hart
> ***testing, only testing, and damn good at it too!***
>
> OK, so you're a Ph.D. Just don't touch anything.
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***
OK, so you're a Ph.D. Just don't touch anything.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
