Scott Adkins writes:
At this point, I am familiar enough with the code to know that it probably
would be hard to add some lines of code to deal with connections in a secure
manner. If I get time, I will do it myself :-)
By the way, I meant "probably would *not* be hard to add some lines of
Hi Tom -
On Sun, 31 Oct 1999, tom minchin wrote:
On Sat, Oct 30, 1999 at 07:00:07AM -0600, Chris M wrote:
Is it a better practice to use IP addresses instead of names for
Client? What about using both (if DNS fails for some reason it can
check the IP)?
I suspect it doesn't make
Hugh Irvine writes:
On Sun, 31 Oct 1999, Scott Adkins wrote:
I would suggest a couple new features that would allow the above suggestion
from John work, similar to how Apache does it:
LIMIT
Order Deny,Allow
AllowFrom IP_PATTERN IP_PATTERN ...
DenyFrom IP_PATTERN
On Sat, Oct 30, 1999 at 07:00:07AM -0600, Chris M wrote:
Is it a better practice to use IP addresses instead of names for
Client? What about using both (if DNS fails for some reason it can
check the IP)?
I suspect it doesn't make much difference, if DNS has failed then well
probably
John Coy writes:
I use Tom's approach -- set all the secrets the same on
all my NAS' and then use a default client statement. It
will protect you any which way.
Personally, I think this can pose a security risk. Using the same secrets
on all the NAS's isn't so bad, though, not quite secure,
Scott certainly makes some valuable points.
As with anything in the networking world, there are
several ways to "skin the cat". I think when you're
managing a network of hundreds of NASs, having
a different secret for each, and a different Client
clause makes things just a bit unmanagable.
