Re: Proxies, opensource and the general market: what's wrong with us?
[email protected] Thu, 28 Apr 2011 18:27:16 -0700 (PDT)
| Newsgroups | gmane.comp.security.firewalls.wizards |
|---|---|
| Message-ID | <[email protected]> |
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 >