On 13 Dec 2001, at 15:54, Suleyman Kutlu wrote: > Hi everybody. > > 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 > 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. > > By the way firewall is Checkpoint Firewall-1 (not sure about the version). > > Thanks for your comments / suggestions. > > Regards. > > * Suleyman Nazif Kutlu Office: +90 212 317 1536 Fax: +90 212 324 1521
As long as the communication is initiated from the secure intranet, the firewall should be able to allow the responses from the DMZ as part of an established session. The problem comes when the communication is initiated in the other direction. When the machine in the DMZ tries to connect to the intranet server on port 1030, how does the firewall know that it's because that's what the portmapper told it to use? Three answers: 1. Assume it, and let the traffic through. This is indistinguishable from enabling all 1024+ ports, although you can specify that that only applies to this specific pair of machines. Neither of us likes this answer. 2. Have the firewall listen in on (or perhaps proxy) the portmapper traffic to learn what ports it is assigning. This requires a bunch of work on the part of the firewall, but it also means you have to let the DMZ machine contact the portmapper service on the intranet machine. Even if FW-1 can do it, I'm not comfortable that this is the right choice. 3. The distinction between intranet and DMZ is a matter of degree of trust. If the placement of these machines correctly implements the organization's trust model, I'd argue that it should be appropriate to take the position that RPC communication between these two machines must be initiated from the intranet side. I've successfully gotten users to accept that some of the things they wanted to do, in terms of, say, archiving logs from DMZ servers, had to be initiated from the trusted network and not from the DMZ. There *may* be some reason why that stance doesn't work in your case, but in that case the fix is not necessarily to dump a complex requirement on the firewall -- it may be simpler to change the trust model, move the intranet machine to the DMZ, or modify the application to be more "security friendly". David Gillett _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
