| Re: Note 1484.0 by CSC32::SHEAFFER
> The workaround for this scenario is to add the host to /etc/hosts.
> Anybody know if you can tell ftpxd or any/all of the proxy servers not
> to use PTR records?
Did you ever get an answer by any other means, Danny?
A customer of mine is asking this now.
In his case, however, the reverse lookup words but yields a name that
cannot be found on a subsequent forward lookup.
ftp.micronics.com -> 206.79.254.42 -> webhost.micronics.com -> invalid
James
|
| Regarding the problem described in the base note ...
Customer is asking me to raise this with Engineering as a product
design deficiency, in the hope that they will provide either
information on how to disable the behaviour, or a patch.
Would anyone like to comment?
I'll wait a bit before I raise an IPMT.
James Cameron
CSC Sydney
|
| Is this really a product deficiency? Shouldn't
the name to which the reverse address points have
an A record for that address?
Maybe I'm missing something, but it sounds like improper
DNS registrations in both those cases. E.g.
webhost.micronics.com used to exist, was pulled off the
network & its address was assigned to ftp.micronics.com,
but no one fixed the reverse address pointer (no one
ever remembers them until they cause problems) - isn't
the fix to correct the reverse address pointer?
The flaw is in depending on a well-managed DNS service
to help in validating systems.
|
| Re: Note 1484.3 by PARZVL::ogodhcp-125-128-185.ogo.dec.com::kennedy
>Is this really a product deficiency? Shouldn't
>the name to which the reverse address points have
>an A record for that address?
Yes, you're missing something. I wasn't clear enough, sorry. The DNS
is faulty, yes, but it isn't the customer's DNS that is at fault, but a
third-party DNS over which the customer has little control.
In the same way that smtpxd was allowed to accept connections from
hosts with PTR record, the customer is asking for the FTP proxy to be
able to do the same thing.
The customer has been made aware of the security implications. See
attached mail below.
James
--------------------------------------------------------------------------------
JAMES CAMERON <Mail to Customer> 07-FEB-1997 15:58
--------------------------------------------------------------------------------
From: GIDDAY::CAMERON "James Cameron 07-Feb-1997 1537 +1100" 7-FEB-1997 15:56:05.53
To: The Customer
Subj: RE: K20094 ftp to aliased DNS hosts fails
In response to your message ...
> You might remember we had the same problem with [mail] coming from hosts with
> invalid or no hostnames in dns. That is why there is a fakemail flag in
> the alarms and why we got a patch for 2.0
Yes, I recall that.
> As to the fact that the names should or should not be registered in dns
> is another issue.
No, not really. The DNS is critical to security of a firewall. Configuring
the firewall to refuse to talk to any host that is improperly registered does
enhance the security of the firewall. I know of many customers who do this.
Here is why:
Almost all the simple attacks on firewalls begin from a machine which is not
registered in a DNS. The attacker chooses a random unused IP address,
advertises a route to it, and is then able to attack your system without you
being able to easily trace the attack.
Because of this, it is standard practice in the Firewall "industry" to disallow
connections to improperly registered nodes, depending on the security
requirements of the organisation.
> >>>The firewall software relies on successful forward and backward address
> >>>translation for access verification.
> Is this the case? The only specification is whether nodes are
> internal/external. This is done by ip address and not name. Or am I
> wrong?
I did not explain correctly. I was pointing out that the access verification
part of the ftpxd relies on the nodes being properly registered, and if they
are not, then access is denied.
I do not know of any configuration option for turning this off.
I do know that placing the host in /etc/hosts will allow connection, and I
gather it is important to list the alias name as well, like this:
206.79.254.42 ftp.micronics.com webhost.micronics.com
It seems to me that the product should have the ability to allow FTP access to
hosts that are improperly registered, if enabled by the security policy.
Either it does already, and I just don't know how to do it, or it doesn't.
I suggest the following courses of action:
a) use the workaround and put up with the problem, and/or;
b) ask me to raise this with Engineering as a product design
deficiency, in the hope that they will provide either information
on how to disable the behaviour, or a patch.
Please pick.
--
James Cameron ([email protected])
Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800
|