On Thu, 13 Dec 2001, Suleyman Kutlu wrote: > Hi everybody.
Hi somebody, > > The question below may seem to you stupid, but I am not an expert on RPC > stff. > > In on of our customers, I have two machines running softwares communicating > eachother via RPC. One of the machines is on Intranet (secure network) the > other is on DMZ. > > The programs uses RPC, so portmap is in effect and it uses arbitrary ports > (from 1024+) to communicate to the other machine. But as all you can guess, > customer does not want to enable all 1024+ ports on the firewall. Is there Allowing RPC over the trust boundary defined by a firewall is probably a very bad idea. Depending on the services running on the DMZ host, and the configuration of both machines, it could be exceedingly bad. The first thing you should consider is rearchitecting the process to use protocols and services that are more firewall-friendly and risk adverse. > any way to fix the port used by portmap for that specific software ? Or is > there any way to guess the port that portmap assigned by the firewall on > the fly ? I mean what the port is used by portmap, the firewall will > discover it (via some scripts may be) and create a rule autoatically. If you're silly enough to be passing NFS or NIS+ over a DMZ, and want to continue to be provided the chance to shoot your own foot off, see: http://www.math.ualberta.ca/imaging/snfs/ > > By the way firewall is Checkpoint Firewall-1 (not sure about the version). > > Thanks for your comments / suggestions. Honestly, consider alternatives before poking something like portmapper and an RPC service through a firewall. There's almost always a better alternative to allowing such holes. Since you don't mention the particular service, it's difficult to give examples. If it's a custom channel, then I'd recommend changing the channel figuring a way to encapsulate it in a less open form. 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
