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

[david () lang hm]

On Thu, 28 Apr 2011, ArkanoiD wrote:

> On Wed, Apr 27, 2011 at 05:20:17PM -0700, david () lang hm wrote:
> > > At the moment I am trying to offload non protocol-related http checks 
> > > to external ICAP filters.. For XML, I have some raw prototype, but I 
> > > do not like the fact it is based on libxml2 and inherits all potential 
> > > vulnerabilities (as it is a huge piece of code) and still there is a 
> > > lack of automated tool that can be used to "formalize" "normal" xml 
> > > flow to check for anomalies later. For several well-documented 
> > > protocols it is not needed, but aiming at SOA it is probably a must 
> > > :-(
> >
> > I'm happy to hear of this work, is the prototype available somewhere?
>
> Not yet, it is more an ugly PoC atm :-( But I am going to polish at a bit and
> include in main source tree.

Ok, I'll keep an eye out for it.

> > > I am thinking about adding radius and/or pam backends support, but still
> > > had no time to implement that.
> >
> > there's a authsrv pam module floating around already for fwtk,
>
> Yes, and there is a slightly modified version of it included in the distribution.
> The change is quite simple: the "comment" field from "authorize" command is no longer actually
> a "comment", as native TIS proxies provided some useful information there like proxy name and
> peer address, I decided to document that and make it a part of protocol specification.
> Some third-party software that did not honor this informal convention got broken and required minor
> patches.

Ok, I'll take a look at that.

> > I have no problem saying that things like log analysers are out of scope,
> > but (at least when initially released) the documentation was saying that
> > things like ssh and http were out of scope (and with telnet and FTP being
> > so insecure, I was remembering that you didn't implement them, leaving
> > little that would use authentication, which is probably why I was thinking
> > that authsrv wasn't implemented)
>
> http was there from the very beginning. ssh, yes, still somehow out, 
> actually not much (well, nothing!) was changed since my old ugly openssh 
> hack to implement simple proxy functionality. It is time to revisit that 
> as well. The part I get paid for at the moment is http/emstp/pop3 (and 
> imap is planned) with SSL support, but I hope I can get some free time.. 
> SSH is definitely high priority task, but I am still unsure what the 
> architecture and technical requirements should be. Do you have any 
> wishes, what is essential for you -- key management functions, whatever?

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.

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

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.

> > 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.

David Lang
_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards