(this is being sent to both the firewall-1 and firewalls lists)
Again, thank you all, for responding. I have a question for
Carson(or anyone) down the post a short distance.
We have a solution.
We finally had GEIS come in house and 'lo-and-behold', they
brought a patch for the bug that was found. Yes, it was a
bug...errr more of a code change they made on purpose for the
sake of appeasing their larger customer(small automotive co. near
Detroit.)
The code they introduced was to allow for their software to use
random high ports to for the source DATA port. This is what I was
seeing in the traces I had done(and consequently the firewall was
dropping.) If you weren't using their software through a firewall,
you never noticed this. But for the ones who were, they had to weaken
the firewall to allow for it. I did not accept weakening our firewall
as an answer to their problem.
The fix was made to allow for those customers like ourselves to add
a command line option to bypass (-by) this anomaly and make the
software use the correct DATA port specified in the /etc/services &/or
entservices(which could be as simple as a pointer back to /etc/services.)
You must have this code change for this option to be recognized.
Carson Gaspar said:
>This is because only idiots run public FTP servers as root. If you
>don't run as root, most UNIX boxen won't let you bind port 20. The
>RFC does _not_ require that data connections originate from port
>20. It _recommends_ that they originate from (control port - 1),
>which is 20 in the default case, but it's only a SHOULD, not a
>MUST. If your firewall insist on port 20, it's broken. Fix it.
I can only assume that your company does not let you speak directly
to your customer. :)
Question. Do you force your customers to specify a port when they FTP
to/from you? I made not have mentioned it in the original post,
but we didn't want to force our customers into opening holes in their
firewalls &/or have to specify specific port numbers when FTPing to us.
I did understand the RFC and yes I agree on your semantics above.
GEIS on the otherhand was randomly(their terminology) choosing a high
port to initiate the communications for the DATA channel. This is where
the firewall did it's job.
I am open to suggestions(firewall specific ;-) on how to
accomplish FTP and be more secure, while keeping it as simplistic as
possible for our customers.
Again, thank you all for your help.
Robert
>>> "J. T. B." <[EMAIL PROTECTED]> 03/02/00 10:26AM >>>
>
>Is there a way for you to tell GEIS to use a specific high port and lock
>that ONE port in so you can set the rule in FW-1?
>This is a problem I've come up against working with a couple of vendors who
>want to talk to us through our firewall, I've literally had to sit in front
>of the logs as people hammer away on the vendors app and watch for dropped
>ports, just to add them to the rule to get it to work...
>Good luck working with GEIS, let us know if they come up with an answer...
>
>
>
>>From: "Robert MacDonald" <[EMAIL PROTECTED]>
>>To: [EMAIL PROTECTED], [EMAIL PROTECTED]
>>Subject: Re: How FW-1 calculates PORT numbers
>>Date: Wed, 01 Mar 2000 12:01:52 -0500
>>
>>J. T. B.,
>>
>>Thanks for responding(your the second one in two weeks.)
>>
>>Yes, if I specifically tell the firewall to allow these connections
>>back, it works. But I want to run GEIS over the ports 21/20
>>and allow FW-1 to track the sessions as a 'normal' FTP. IOW,
>>I don't want to open these higher ports, just for the sake of
>>'fixing' GEIS.
>>
>>If I only use 'normal' FTP, it works great. The firewall handles
>>the whole session. I have enabled the data port in the policy
>>properties.
>>
>>After speaking with GEIS technical support, I seemed to have
>>come across something GEIS is aware of(and has other customers
>>complaining about the same thing.)
>>
>>Their software ignores the port command and digs out the port#
>>the client requested from deeper within the packet(this is supposedly
>>how they know about the original port#.) GEIS said that this is the
>>'newer' standard, but I have not been able to find RFC info on this.
>>Any help on this 'standard' is welcome.
>>
>>It also seems that GEIS software is not responding from the port#
>>defined for the DATA(20) port. They seem to arbitrarily pick a high port
>>to respond with. GEIS is looking into this.?? If their software responded
>>back with the right source port to the right destination port, I'm positive
>>the firewall rules set for 'normal' FTP will prevail.
>>
>>btw, the other response I received, wanted to make
>>sure that snoop wasn't cutting off(via the display) the port command after
>>the 20th byte, so it appeared to be different from the normal. I don't
>>think
>>that's whats happening, but to be sure I'm going to run a real sniffer on
>>it
>>later today.
>>
>>With all that said. If anyone has a definite answer to my original question
>>-
>>like FW-1 is no different than any other system, when it comes to the PORT
>>command, I'm all ears. Thanks.
>>
>>Sorry for the long winded-ness,
>>Robert
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
