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

[david () lang hm]

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, david () lang hm 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
> firewall-wizards () listserv icsalabs com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards