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

Could you please share it?

I started hacking something like that with clish, but it was never finished.

On Thu, Apr 28, 2011 at 06:27:16PM -0700, [email protected] wrote:
> one other SSH related thing, a SSH enabled version of cmd-gw
> 
> I hacked in support for simple authentication (validating the user with 
> authsrv) and then added the ability to do some tests and simple work 
> through it (do a ps to see what proxies are running, show what the rules 
> are for a given proxy, execute hping2 to see if you can get to the 
> destination on a given port, etc) and it has proven to be a wonderful tool 
> by allowing other teams to execute commands from the firewalls without 
> having to give them local logins. One thing that I have found is that I 
> need the ability to set permissions per command, not just allowing or 
> disallowing users (similar to how ftp-gw could be configured to allow get 
> but not put)
> 
> David Lang
> 
> 
>  On Fri, 29 Apr 2011, ArkanoiD wrote:
> 
> >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).
> >
> >
> >
> >_______________________________________________
> >firewall-wizards mailing list
> >[email protected]
> >https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
> >
> _______________________________________________
> firewall-wizards mailing list
> [email protected]
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
> 
> email protected and scanned by AdvascanTM - keeping email useful - 
> www.advascan.com 
>