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
>