Re: Proxies, opensource and the general market: what's wrong with us?

ArkanoiD <[email protected]> Fri, 29 Apr 2011 03:46:35 +0400
Newsgroups gmane.comp.security.firewalls.wizards
Message-ID <[email protected]>
On Thu, Apr 28, 2011 at 11:01:45AM -0700, [email protected] wrote:
> 
> Ok, I'll take a look at that.
> 
Please use CVS snapshot, the current one should be ok (I will probably mark it
with some tag), tarballs and rpms are too old.

> for an ssh proxy, what I minimally need is the ability to be a direct 
> replacement for tn-gw and ftp-gw without it enabling tunneling.

That might be relatively easy if we are not going to dive deep in key management.
I hope I will make some hack (at least better one that patched openssh I used before) soon.

> something like tn-gw where the user connects to the firewall then 
> specifies where to go from there for an interactive terminal session, with 
> port forwarding
> disabled

Yes, it was the only thing it did provide.

> something like ftp-gw where an authenticated user is able to transfer 
> files through the connection and log what's moved
> 
> both of these authenticated to authsrv
> 
> future enhancements:
> 
> optionally allow port forwarding
> 
> add the ability to do firewalling for the ports forwarded through ssh
> 
> add the ability to specify what commands can be executed to a destination 
> through the proxy (as opposed to the default login)
> 
> add key management (for incoming, support using the ssh identity as the 
> userid, with our without additional authentication with authsrv, for 
> outbound, support different client certs for different userids, possibly 
> for different userid/destination pairs) potentially doing the keyserver 
> relay back to the client. This is the lowest priority item for me.

Sounds reasonable.

> >>I actually don't have an objection to the firewall being a collection of
> >>different tools gathered togeather (that's just good code re-use in the
> >>best opensource tradition), it may require some tweaks to code, or some
> >>scripts to create the appropriate config files for some of the tools, but
> >>that is far better than having to completely re-write the tools.
> >
> >That's why I was talking about "kickstart" -- a set of configuration 
> >templates that eases this task.
> 
> actually, I was not thinking in terms of templates, but rather something 
> that would let you define access in terms of groups like the traditional 
> authsrv entries in netperm-table and have a script that would create the 
> corresponding config for squid (picking an example). I actually have 
> something along these lines today that is a script running out fo 
> cron that checks the timestamp on netperm-table and anytime it 
> changes it looks for authsrv lines with http or https types and creates 
> files for the groups allowing those groups to go to the destinations 
> specified and then kicks squid with a reconfigure (I ahve other processes 
> to do authentication for IPs to populate what the sources for each group 
> are). This allows the use of a fairly mature tool without the people 
> implementing the permissions having to worry about learning a different 
> config file format. they just make authsrv entries and everything else is 
> taken care of for them.

There is a tool like that to configure djbdns forwarder service (dnsctl).
Maybe other companion tools might be useful, to configure, say, packet filtering
(or VPN, or whatever else).