Well, having received a few replies from firewalls readers and one from
TIS (none of which helped much), I found the problem myself - I'd neglected
to give "hosts" something to match about and had "hosts -dest" which should
have been (at least) "hosts * -dest".
What concerns me though is that numerous people seemed confused about what
I was trying to do - sorry - and kept suggesting "permit-hosts" (and kin)
which wasn't what I was trying to fiddle...
> Does anyone here use the ftp-gw s/w in the TIS firewall toolkit ?
>
> I'm interested in knowing how to get it to deny being used as a
> proxy agent for reaching internal hosts (for which it only knows
> an IP#) whilst allowing internal hosts to use it as a proxy and
> everyone to use it as an anonymous ftp server itself.
>
> (Is this too much to expect from it ??)
>
> It seems to behave fine as a proxy server going out, but it doesn't
> seem to like things like this:
> ftp-gw: hosts -dest !10.*
^^^ nothing there and *bang* big problem!
Hopefully there will be something in a future release to pickup typos
which result in a valid (and non-functioning) syntax.
> Does anyone have a sample set of netperm entries they could share
> showing how to achieve it properly ? I'm very worried that if
> someone does "ftp @
10 .
0 .
0 .
51" the ftp-gw s/w will allow that through...
> even if you only have "-dest !*.foo.bar" in your netperm file!
> (Although "ftp @
fubar .
foo .
bar" is blocked).
>
> I'm using version 1.1...what have I done wrong ? This just doesn't
> make sense to me :/
Now that it works (and quite nicely - my users appreicate it too :)
Both for proxy and anonymous ftp :)
Seems netacl will work when run via tcpd too (for those who enjoy
logging) :
ftp stream tcp nowait root /usr/etc/tcpd ftp-netacl in.ftpd
works as you'd expect, tcpd runs, logs it as ftp-netacl, runs netacl and
that runs and logs for in.ftpd. Someone mentioned redundant logging ;)
Oh, and then either wu's ftpd or ftp-gw finally get run...*phew*!
Something else, which seems (partially) relevant here is that having an
account *outside* the network you want to protect (say from a providor
like netcom or netsys) and using that to test your own integrity on the
premis that you don't trust anything "out there" may be as much of an
aid as hiring a tiger team - in the least it should be an account such
that there are no special allowances for it in hosts.deny, netperm-table,
etc. I'm not sure if that got mentioned in the tiger team noise...
cheers,
darren
|
|
